What’s new – Announcing new Azure Sentinel data residency locations: Japan, UK and Canada

by Contributed | Oct 22, 2020 | Technology

This article is contributed. See the original author and article here.

This installment is part of a broader series to keep you up to date with the latest features in Azure Sentinel. The installments will be bite-sized to enable you to easily digest the new content.

As you probably know, Azure Sentinel can be installed on workspaces located in any GA region where Log Analytics is available except China and Germany sovereign regions.

However, Azure Sentinel generates some additional data like Alert information, Incident details, Bookmarks, etc. that in some cases may be stored in a different region to where the workspace is located.

Today we are announcing the expansion of Azure Sentinel data residency to three additional geographies: Japan, United Kingdom and Canada. With these additions, the geographies where the Azure Sentinel data at rest is stored is summarized in the following table:

So, for example, any new or existing Sentinel workspaces created in Japan, will have all its Azure Sentinel data at rest stored within Japan. Similarly, workspaces located within Brazil, will have their Sentinel data at rest stored in the United States.

This is a very important achievement as we strive to provide customers and partners with the tools to comply with the different regulations applicable to each geography.

Please post a comment below if you have questions.

Thanks to @Koby Koren and @Michael Gladishev for their work on this feature! 

How to minimize data movements (Compatible and Incompatible Joins)

by Contributed | Oct 22, 2020 | Technology

This article is contributed. See the original author and article here.

In Azure Synapse Analytics, data will be distributed across several distributions based on the distribution type (Hash, Round Robin, and Replicated). So, on an operation like Join condition we may have Compatible Joins or Incompatible Joins which depends on the type of the joined table distribution type and location on the join (LEFT or RIGHT).

As part of query performance troubleshooting/ tuning, one of the main factors to enhance the query performance is to minimize the data movement between distributions. Customers can modify the join types / table distribution type (if applicable) to achieve that.

Below are two examples; the first shows how to get compatible join, and the other one shows how to minimize the data movement by modifying the table (incompatible join).

Examples:

compatible join example, for this example we have two tables [dbo].[DimCustomer] and [dbo].[FactSurveyResponse]

• [dbo].[DimCustomer] distributed as a hash on CustomerKey with integer as a data type


• [dbo].[FactSurveyResponse] distributed as a hash on CustomerKey with integer as a data type as well.

Based on the below reference (Table 1: Compatible Joins) , if we are joining two tables on the same key and same date type no data movements will be required.

CREATE TABLE [dbo].[DimCustomer]
(
	[CustomerKey] [int] NOT NULL,
	[GeographyKey] [int] NULL,
	[CommuteDistance] [nvarchar](15) NULL
)
WITH
(
	DISTRIBUTION = HASH ( [CustomerKey] ),
	CLUSTERED COLUMNSTORE INDEX
)

CREATE TABLE [dbo].[FactSurveyResponse]
(
	[SurveyResponseKey] [int] NOT NULL,
	[DateKey] [int] NOT NULL,
	[CustomerKey] [int] NOT NULL,
	[ProductCategoryKey] [int] NOT NULL
)
WITH
(
	DISTRIBUTION = HASH ( [CustomerKey] ),
	CLUSTERED COLUMNSTORE INDEX
)

SELECT FSR.* , DC.LastName , DC.FirstName
FROM [dbo].[FactSurveyResponse] FSR
INNER JOIN [dbo].[DimCustomer] DC
ON DC.[CustomerKey] = FSR.[CustomerKey]

By examining the produced query steps for the above query, no data movement happened as we have joined the two tables based on the same hash key (CustomerKey)

incompatible join example, for this example we have two tables [dbo].[ DimProductCategory] and [dbo].[FactSurveyResponse]

• [dbo].[ DimProductCategory] distributed as a hash on ProductCategoryKey


• [dbo].[FactSurveyResponse] distributed as a hash on CustomerKey as well.

Based on the below reference (Table 2: Incompatible Joins)  , if we are joining two tables on different keys additional data movements (e.g. BroadcastMoveOperation, ShuffleMoveOperation) will be required.

CREATE TABLE [dbo].[FactSurveyResponse]
(
	[SurveyResponseKey] [int] NOT NULL,
	[DateKey] [int] NOT NULL,
	[CustomerKey] [int] NOT NULL,
	[ProductCategoryKey] [int] NOT NULL
)
WITH
(
	DISTRIBUTION = HASH ( [CustomerKey] ),
	CLUSTERED COLUMNSTORE INDEX
)

CREATE TABLE [dbo].[DimProductCategory]
(
	[ProductCategoryKey] [int] NOT NULL,
	[ProductCategoryAlternateKey] [int] NULL,
	[EnglishProductCategoryName] [nvarchar](50) NOT NULL,
	[SpanishProductCategoryName] [nvarchar](50) NOT NULL,
	[FrenchProductCategoryName] [nvarchar](50) NOT NULL
)
WITH
(
	DISTRIBUTION = HASH ( [ProductCategoryKey] ),
	CLUSTERED COLUMNSTORE INDEX
)

SELECT FSR.* , DPC.[EnglishProductCategoryName]
FROM [dbo].[FactSurveyResponse] FSR
INNER JOIN [dbo].[DimProductCategory] DPC
ON DPC.[ProductCategoryKey] = FSR.[ProductCategoryKey]

Based on the above there was a BroadcastMoveOperation which moved 4 rows, since we have joined the two tables on different keys (incompatible Join). One of the ways to remove the BroadcastMoveOperation is to use REPLICATE distribution type.

Note: The customer needs to consider the changes not CSS, since this might affect other queries and requires a structure redesign for related objects. In the next step we will create a new table by using CTAS with REPLICATE distribution data type.

Steps to minimize the data movements (Just an example).

• Create a new table with REPLICATE distribution by using CTAS, and verify that both left and right table has the predicate joins data type. (e.g. int = int)

Build the replicate cash.

CREATE TABLE [dbo].[DimProductCategory_Replicate] 
WITH (DISTRIBUTION=REPLICATE) 
AS SELECT * FROM [dbo].[DimProductCategory]

SELECT FSR.* , DPC.[EnglishProductCategoryName]
FROM [dbo].[FactSurveyResponse] FSR
INNER JOIN [dbo].[DimProductCategory_Replicate] DPC
ON DPC.[ProductCategoryKey] = FSR.[ProductCategoryKey]

• Based on the Compatible Joins table we can get a compatible join either by having the replicated table on left or right.

By examining the produced query steps for the above query, no data movement happened. Based on the below reference (Table 1: Compatible Joins)  if the left table is distributed and the right table is replicated along with inner join no data movement is required.

Compatible and Incompatible Joins table reference:

Compatible Joins: is a join that doesn’t require data movement before each compute node.

Table 1: Compatible Joins

Example:

Incompatible Joins is a join that requires data movement before each compute node.

Note: Data movement operations take extra time and storage and can negatively impact query performance.

Table 2: Incompatible Joins

How Surface Duo is helping health care providers

by Contributed | Oct 21, 2020 | Technology

This article is contributed. See the original author and article here.

See how deploying Surface Duo in a health care environment helps medical professionals in this video on the growing impact of telehealth and telemedicine. 

One of the big challenges right now is real estate. It’s difficult to really see a lot of what you need to see to do your job in medicine when you just have six inches of space. If you can have double that, if you have the ability to see multiple views, I think it makes it much easier to actually have a device in a hospital setting.

– Charles Drayton, Chief Technical Architect, Microsoft

I so often find myself talking to somebody and wanting to see something else and not being able to do that on a phone very easily.

– Clifford Goldsmith, M.D. US Chief Medical Officer, Microsoft

Kitchen Table Admin: Introduction to Microsoft Audio Conferencing

by Contributed | Oct 21, 2020 | Technology

This article is contributed. See the original author and article here.

Microsoft Teams Community,

We’re back with the second video in our Kitchen Table Admin series, an Introduction to Microsoft Audio Conferencing, or meeting dial-in.  We get a LOT of support volume on this topic and we hope to clear up some of the most common questions and issues we hear from Teams Administrators when first setting up this feature set.

Demo starts at about 0:53 into the video.  This is level 50/100 stuff here, so if you’re already familiar with Microsoft Audio Conferencing and using the feature, this information should be well known to you.  However, if you’re just getting started, check out the video we hope it is helpful to you.

As always we welcome your feedback in the blog comments.  We’re especially interested in topics you’d like to have us cover in a future video.

Thanks for watching!