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
[音乐]