{"id":672,"date":"2020-01-09T16:29:23","date_gmt":"2020-01-10T00:29:23","guid":{"rendered":"http:\/\/blog.nillsf.com\/?p=672"},"modified":"2020-01-09T16:29:55","modified_gmt":"2020-01-10T00:29:55","slug":"giving-azure-data-share-a-spin","status":"publish","type":"post","link":"https:\/\/blog.nillsf.com\/index.php\/2020\/01\/09\/giving-azure-data-share-a-spin\/","title":{"rendered":"Giving Azure Data Share a spin"},"content":{"rendered":"\n

Before the holidays, I blogged about sharing blob storage data with AAD B2B guests<\/a>. Peter Demeyere mentioned to me on LinkedIn that he likes to use Azure Data share to share blob data, as it has some more tracking data built in. And funnily enough, during my long run this weekend, I listened to an Azure podcast about Azure data share, so why not give it a spin?<\/p>\n\n\n\n

What is Azure Data Share?<\/h2>\n\n\n\n

Azure Data Share is a service that enables you to easily share data in Azure and track get greater control over your data sharing relationship. The service was announced in preview<\/a> in July 2019 and went GA<\/a> in November 2019 (must be close to record pace). Azure Data Share doesn’t only support blob and ADLS, but also SQL DBs and Azure Data Explorer (in preview)<\/p>\n\n\n\n

For now, when you use Azure Data Share, a snapshot of the source data will be taken. This means that the moment you accept a data share invite, you must provide it with a target storage account and you’ll create a copy of your data in your own environment. Additionally, you can configure snapshot schedules to receive incremental updates of the data as well.<\/p>\n\n\n\n

Seems pretty straighforward. Let’s give it a spin.<\/p>\n\n\n\n

Working with Azure Data Share<\/h2>\n\n\n\n

In my scenario, I’ll setup an Azure Data Share in my Microsoft subscription, and share data with my MSDN account. Let’s start with setting things up in my Microsoft subscription.<\/p>\n\n\n\n

Data Share is integrated into the portal. Just look for Data Shares, or use this link<\/a>. We’ll start by adding a new one.<\/p>\n\n\n\n

\"\"
We’ll hit the Add button to create the resource.<\/figcaption><\/figure>\n\n\n\n

The creation process is a single pane in the Azure portal. What I noticed here is that the Data Share service isn’t available in all regions. Luckily for me, my primary region (West US 2) is available, so I’ll create it there.<\/p>\n\n\n\n

\"\"
Single blade to create Azure Data Share. It shows limited amount of regions supported.<\/figcaption><\/figure>\n\n\n\n

This took me about 2 minutes to complete, let’s now go in and configure our data share.<\/p>\n\n\n\n

\"\"
We’ll hit the Start sharing your data button here to start our share.<\/figcaption><\/figure>\n\n\n\n

This gives us a 5 step data share creation. Step 1 is giving the share a name, a description and potentially custom Terms of use.<\/p>\n\n\n\n

\"\"
Step 1 is giving the name, description and terms of use.<\/figcaption><\/figure>\n\n\n\n

Next we’ll want to add our Datasets. We’ll select Blob storage here.<\/p>\n\n\n\n

\"\"
We’ll add a Blob storage dataset<\/figcaption><\/figure>\n\n\n\n

Next, you can select your storage account, your containers or even “subfolders” you might want to share with your data consumers. (I put subfolders in quotes, since blob doesn’t actually have a folder strucuture. But that’s a minor detail<\/a>.)<\/em><\/p>\n\n\n\n

\"\"
You can select full storage accounts, containers or even subfolders in a container to share.<\/figcaption><\/figure>\n\n\n\n

I ended up selecting the same container we shared in the earlier post, called test2b2. Finally, you’ll give your dataset a name (which can be different from the actual data name) and step 2 is done.<\/p>\n\n\n\n

\"\"
Give your dataset a name.<\/figcaption><\/figure>\n\n\n\n

It appears you can actually share multiple datasets in one single Data Share request.<\/p>\n\n\n\n

\"\"
You can add multiple datasets to a single Data Share.<\/figcaption><\/figure>\n\n\n\n

Next, you’ll want to enter your recipients. In my case, this is going to be my alter ego Ben. <\/p>\n\n\n\n

\"\"
Enter the recipients of this data share.<\/figcaption><\/figure>\n\n\n\n

You can optionally also set a snapshot schedule, either daily or hourly. I decided to set one up hourly.<\/p>\n\n\n\n

\"\"
Optionally, you can set a snapshot schedule.<\/figcaption><\/figure>\n\n\n\n
\"\"
Confirmation page, and then you can create your data share.<\/figcaption><\/figure>\n\n\n\n

Creating the actual data share only took a couple a seconds. Now I need to login to the Azure portal, and see if Ben can get to his data share.<\/p>\n\n\n\n

When I log in as Ben and head on over to Data Share invites, I can actually see the invite I just sent myself.<\/p>\n\n\n\n

\"\"
I can see my invite right there.<\/figcaption><\/figure>\n\n\n\n

Next up I need to configure a data share in my MSDN. One thing that annoys me here is that I cannot create a new resource group from this blade. So I first go ahead and create a new resource group.<\/p>\n\n\n\n

\"\"
There’s no ability to create a new resource group.<\/figcaption><\/figure>\n\n\n\n

Next up, I can create (from this blade) my Azure Data Share resource. However, I get an error here that the namespace is not registered. <\/p>\n\n\n\n

\"\"
Trying to create a data share resource.<\/figcaption><\/figure>\n\n\n\n
\"\"
Getting this error that the RP isn’t registered.<\/figcaption><\/figure>\n\n\n\n

No biggy, just head on over to the subscription blade and register the resource provider.<\/p>\n\n\n\n

\"\"
In the subscription blade, you can register the RP for DataShare.<\/figcaption><\/figure>\n\n\n\n

Once the RP is registered, we can hit Create and wait for the Data Share resource to be created. Again, this takes a couple minutes to complete. After that, we can accept our invite.<\/p>\n\n\n\n

\"\"
Accepting the invite.<\/figcaption><\/figure>\n\n\n\n

Next up, we’ll select our target storage account. I decided to create a new one for this demo.<\/p>\n\n\n\n

\"\"
Decided to create a new storage account.<\/figcaption><\/figure>\n\n\n\n

And with that, we have all our settings for the actual data share receiver.<\/p>\n\n\n\n

\"\"
Final configuration configuring the storage account.<\/figcaption><\/figure>\n\n\n\n

With that out of the way, our data should be getting copied at the scheduled snapshot time (which will be on the hour). And sure enough, my data did show up.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

I decided to add a new file to the source storage account, and wait for the hour for the snapshot to be taken to see all my new data appear. <\/p>\n\n\n\n

And, as I was expecting, the data actually showed up at the hour (2 min after the hour actually). <\/p>\n\n\n\n

\"\"
New data automatically shows up.<\/figcaption><\/figure>\n\n\n\n

From a data provider perspective, I can now see the full history of all data copies that happened. <\/p>\n\n\n\n

\"\"
Overview of copies from the data provider’s point of view.<\/figcaption><\/figure>\n\n\n\n

Conclusion<\/h2>\n\n\n\n

Azure Data Share enables you to easily share data with external users. The external user doesn’t get direct access to the source data, but rather gets a copy in their own storage account. <\/p>\n\n\n\n

The experience of setting up the share was pretty straightforward. Accepting the invite had a couple hick-ups, but in the end I think the service is pretty easy to use.<\/p>\n","protected":false},"excerpt":{"rendered":"

Before the holidays, I blogged about sharing blob storage data with AAD B2B guests. Peter Demeyere mentioned to me on LinkedIn that he likes to use Azure Data share to share blob data, as it has some more tracking data built in. And funnily enough, during my long run this weekend, I listened to an […]<\/p>\n","protected":false},"author":1,"featured_media":677,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[2,4],"tags":[8,68,71],"class_list":["post-672","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-azure","category-management","tag-azure","tag-blob","tag-data-share"],"jetpack_featured_media_url":"https:\/\/nillsfblog.blob.core.windows.net\/media\/2020\/01\/image-18.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/672","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/comments?post=672"}],"version-history":[{"count":3,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/672\/revisions"}],"predecessor-version":[{"id":698,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/posts\/672\/revisions\/698"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media\/677"}],"wp:attachment":[{"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/media?parent=672"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/categories?post=672"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.nillsf.com\/index.php\/wp-json\/wp\/v2\/tags?post=672"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}