WEBVTT

00:00:00.000 --> 00:00:10.500
[音樂]。

00:00:10.500 --> 00:00:11.910
• 嗨，歡迎回來。

00:00:11.910 --> 00:00:14.970
我的名字是JRJ，我在這裡
告訴你關於一個

00:00:14.970 --> 00:00:18.915
最熱切期待
SQL Server 2019 中的功能，

00:00:18.915 --> 00:00:21.285
這就是資料虛擬化。

00:00:21.285 --> 00:00:23.175
什麼是資料虛擬化，

00:00:23.175 --> 00:00:25.440
為什麼它如此熱切地期待？

00:00:25.440 --> 00:00:27.510
簡單地說

00:00:27.510 --> 00:00:29.510
資料虛擬化使您能夠

00:00:29.510 --> 00:00:31.670
彙集您的所有資料，

00:00:31.670 --> 00:00:35.780
查詢時間，而不必
在

00:00:35.780 --> 00:00:40.535
為了能夠統一
單個查詢中的資料。

00:00:40.535 --> 00:00:44.150
所以我要
做而不是去

00:00:44.150 --> 00:00:47.540
通過資料的細節
在概念層面實現虛擬化，

00:00:47.540 --> 00:00:49.730
我只是要告訴你
之間的差異

00:00:49.730 --> 00:00:52.430
本地查詢和
虛擬化查詢，

00:00:52.430 --> 00:00:55.085
部分和完全虛擬化。

00:00:55.085 --> 00:00:56.280
所以，這樣做，

00:00:56.280 --> 00:00:58.010
我們要做的是
我們要切換

00:00:58.010 --> 00:01:00.270
現在到 Azure 資料工作室，

00:01:00.270 --> 00:01:03.035
你可以看到在這裡我
打開活頁簿，

00:01:03.035 --> 00:01:08.990
讓我們進去
開始評估這一點。

00:01:08.990 --> 00:01:13.625
所以在這裡你可以看到我
有一個非常簡單的查詢。

00:01:13.625 --> 00:01:17.030
我有兩個本地
表，

00:01:17.030 --> 00:01:19.160
如果我運行該查詢，

00:01:19.160 --> 00:01:23.405
你可以想像結果
回來很好，很快。

00:01:23.405 --> 00:01:25.190
我還有一秒鐘

00:01:25.190 --> 00:01:28.045
我得到我的資料集
回到筆記本上。

00:01:28.045 --> 00:01:31.630
但是，如果所有這些
資料不在 SQL 伺服器中？

00:01:31.630 --> 00:01:36.200
如果資料實際上是
在遠端 SQL 伺服器中可用，

00:01:36.200 --> 00:01:40.145
我們想訪問
資料同時？

00:01:40.145 --> 00:01:43.700
那麼，您可以使用資料虛擬化
來解決這個問題。

00:01:43.700 --> 00:01:45.050
但為了做到這一點，

00:01:45.050 --> 00:01:47.030
我們需要設置一些中繼資料。

00:01:47.030 --> 00:01:50.510
所以，我們需要做的第一件事
做的是創建主金鑰，

00:01:50.510 --> 00:01:53.720
主金鑰是內部金鑰

00:01:53.720 --> 00:01:55.910
我們用來保護的資料庫

00:01:55.910 --> 00:01:58.660
裡面的所有其他中繼資料。

00:01:58.660 --> 00:02:03.380
你可以從中繼資料中看到
在這裡，我們使用的演算法，

00:02:03.380 --> 00:02:06.110
當它被創建，
有趣的事情。

00:02:06.110 --> 00:02:10.745
現在我需要啟用多邊形基礎
功能，以便能夠

00:02:10.745 --> 00:02:16.310
訪問遠端源
和遠端資料庫，

00:02:16.310 --> 00:02:19.220
並創建資料庫憑據

00:02:19.220 --> 00:02:23.495
能夠進行身份驗證
對這些遠端資源，

00:02:23.495 --> 00:02:28.835
你可以看到我在這裡
在過去創造了一些，

00:02:28.835 --> 00:02:30.200
作為甲骨文的一對夫婦

00:02:30.200 --> 00:02:32.225
和幾個SQL
一個在那裡，以及。

00:02:32.225 --> 00:02:36.680
但今天，我們要走了
針對 SQL 資料來源，

00:02:36.680 --> 00:02:39.650
你可以看到這裡，
為了做到這一點，

00:02:39.650 --> 00:02:41.730
我需要創建一個
外部資料源。

00:02:41.730 --> 00:02:45.390
在這裡，我指定我的
位置，在這種情況下，

00:02:45.390 --> 00:02:49.160
SQL 伺服器位址
在 Azure 的某處，

00:02:49.160 --> 00:02:51.874
我傳遞了那個憑據

00:02:51.874 --> 00:02:54.425
啟用該身份驗證
發生。

00:02:54.425 --> 00:02:56.590
因此，讓我們繼續前進，並創建，

00:02:56.590 --> 00:03:00.880
你可以再次看到，有
資料庫中的中繼資料。

00:03:00.880 --> 00:03:03.040
現在，作為一般規則，

00:03:03.040 --> 00:03:06.290
我喜歡保持外部
表，定義

00:03:06.290 --> 00:03:08.465
這些外部資料源物件

00:03:08.465 --> 00:03:11.210
從我的內部表分開，

00:03:11.210 --> 00:03:12.890
我使用架構來做到這一點。

00:03:12.890 --> 00:03:16.500
因此，讓我們繼續前進，
創建外部架構，

00:03:17.660 --> 00:03:23.350
現在我們可以來這裡
創建我們的第一個外部表。

00:03:23.350 --> 00:03:25.730
第一個外部表
我們要創造的是

00:03:25.730 --> 00:03:28.240
網路點擊流
是第一張桌子

00:03:28.240 --> 00:03:31.315
在這種情況下，它的
更像是一個事實表，

00:03:31.315 --> 00:03:34.755
我們要存儲它。

00:03:34.755 --> 00:03:36.490
所以在那個外部資料庫中

00:03:36.490 --> 00:03:38.375
我們有完全相同的資料庫

00:03:38.375 --> 00:03:44.200
我們只是再次使用它
說明此場景。

00:03:44.200 --> 00:03:50.515
現在，我們可以進入這個過程
虛擬化點擊流，

00:03:50.515 --> 00:03:52.900
網路點擊流表。

00:03:52.900 --> 00:03:56.500
在這裡你可以看到我有
相同的表 Web 點擊流，

00:03:56.500 --> 00:03:58.660
但現在我使用的是EXT架構。

00:03:58.660 --> 00:04:01.060
所以我正在訪問外部表，

00:04:01.060 --> 00:04:02.440
但出於所有意圖和目的，

00:04:02.440 --> 00:04:05.630
查詢的其餘部分
完全一樣。

00:04:05.630 --> 00:04:08.225
如果我現在運行該查詢，

00:04:08.225 --> 00:04:10.120
比說它需要一個
稍長一點，因為

00:04:10.120 --> 00:04:12.100
我們要去
遠端獲取資料，

00:04:12.100 --> 00:04:14.905
你可以說
約3.5秒。

00:04:14.905 --> 00:04:17.260
但是我們可以看到，我們已經得到了

00:04:17.260 --> 00:04:20.785
資料在這裡和
完全一樣

00:04:20.785 --> 00:04:23.710
所以引擎蓋下面的一切

00:04:23.710 --> 00:04:27.065
是完全透明的
作為一個使用者。

00:04:27.065 --> 00:04:29.920
現在，如果我真的繼續前進，

00:04:29.920 --> 00:04:33.250
虛擬化第二個
此查詢中的外部表？

00:04:33.250 --> 00:04:35.680
你記得第一個
一個是網路剪輯流，

00:04:35.680 --> 00:04:38.905
第二個
是項表。

00:04:38.905 --> 00:04:41.090
因此，讓我們繼續前進，做到這一點，

00:04:41.090 --> 00:04:45.650
現在我有兩個
表虛擬化。

00:04:47.290 --> 00:04:52.290
所以現在，會發生什麼
我運行了最後一個查詢？

00:04:52.290 --> 00:04:57.565
最後一個查詢將
運行完全相同的查詢，

00:04:57.565 --> 00:05:01.670
但兩個外部
表是虛擬化的，

00:05:01.940 --> 00:05:05.275
你可以看到，實際上
查詢幾乎一樣

00:05:05.275 --> 00:05:09.375
快作為第一
版本，本地查詢。

00:05:09.375 --> 00:05:12.530
為什麼會這樣？為什麼我們得到
這種性能差異？

00:05:12.530 --> 00:05:14.780
原因是
如果你看看

00:05:14.780 --> 00:05:17.000
SQL 伺服器
足夠智慧使用

00:05:17.000 --> 00:05:20.600
基於成本的優化器
明白，

00:05:20.600 --> 00:05:24.725
兩個表都是外部的，
他們來自同一個來源，

00:05:24.725 --> 00:05:28.400
它可以看到，
它可以推動這個聯接和

00:05:28.400 --> 00:05:32.030
聚合下來
對遠端源。

00:05:32.030 --> 00:05:34.190
因此，我們利用

00:05:34.190 --> 00:05:37.445
要解析的遠端源
此查詢即時。

00:05:37.445 --> 00:05:41.030
但是，這為您提供了快速概述
功能，你

00:05:41.030 --> 00:05:44.750
退出使用資料
虛擬化技術

00:05:44.750 --> 00:05:48.470
以及如何實際上
透明地呈現該資料

00:05:48.470 --> 00:05:50.390
返回最終使用者，而無需

00:05:50.390 --> 00:05:52.520
製作該資料的物理副本，

00:05:52.520 --> 00:05:54.410
而無需移動它或建立

00:05:54.410 --> 00:05:56.420
複雜的 ETL 管道

00:05:56.420 --> 00:05:58.910
為了能夠
即時查詢資料。

00:05:58.910 --> 00:06:00.510
非常感謝你加入

00:06:00.510 --> 00:06:02.960
我期待著趕上
很快又和你一起。

00:06:02.960 --> 00:06:17.560
[音樂]