WEBVTT

00:00:00.000 --> 00:00:03.000
• SQL 服务器 2019 大
数据群集提供

00:00:03.000 --> 00:00:06.585
要卸载的计算池
分布式查询处理。

00:00:06.585 --> 00:00:10.350
UC 在这里告诉我们所有关于
今天的数据公开。

00:00:10.350 --> 00:00:21.060
[音乐]

00:00:21.060 --> 00:00:25.215
[ ] 嗨。欢迎来到另一集
数据暴露。我是杰琳

00:00:25.215 --> 00:00:27.810
今天，我加入了UC
谈论计算

00:00:27.810 --> 00:00:30.690
SQL Server 中的池
2019 大数据集群。

00:00:30.690 --> 00:00:33.000
嗨，加州大学谢谢
再次加入节目。

00:00:33.000 --> 00:00:34.155
* 当然可以。

00:00:34.155 --> 00:00:36.060
• 计算池？

00:00:36.060 --> 00:00:36.615
* 是的。

00:00:36.615 --> 00:00:37.815
• 它们是什么？

00:00:37.815 --> 00:00:40.980
• 计算池。他们是

00:00:40.980 --> 00:00:44.430
基本上 SQL Server 实例
在大数据群集中，

00:00:44.430 --> 00:00:48.725
可用于卸载您的
分布式查询处理。

00:00:48.725 --> 00:00:50.310
所以在这张照片里

00:00:50.310 --> 00:00:54.870
我们看到许多组件
SQL 服务器大数据群集。

00:00:54.870 --> 00:00:58.570
今天，我们来看看
此计算池在这里。

00:00:58.570 --> 00:01:01.710
那是什么？它
基本上是一套

00:01:01.710 --> 00:01:03.825
SQL Server 实例

00:01:03.825 --> 00:01:06.685
自动小册子
在大数据群集内，

00:01:06.685 --> 00:01:10.475
它们可用于
执行分布式查询。

00:01:10.475 --> 00:01:11.405
"好的。

00:01:11.405 --> 00:01:14.030
• 这与聚宝座类似

00:01:14.030 --> 00:01:17.585
SQL Server 2016 中的横向扩展组。

00:01:17.585 --> 00:01:21.490
此功能现在为您提供

00:01:21.490 --> 00:01:25.174
开箱即用的 SQL 实例集，

00:01:25.174 --> 00:01:27.890
可以做大部分
为您分配工作。

00:01:27.890 --> 00:01:28.930
"好的。

00:01:28.930 --> 00:01:32.540
• 查询可以使用
计算池或不使用

00:01:32.540 --> 00:01:35.540
计算池，具体取决于
查询类型。

00:01:35.540 --> 00:01:38.570
• 我什么情况
选择计算池？

00:01:38.570 --> 00:01:40.720
* 是的。伟大
问题。让我们看看。

00:01:40.720 --> 00:01:44.270
常见情况之一是
说你有两个目录

00:01:44.270 --> 00:01:45.950
拥有成百上千的 HDF

00:01:45.950 --> 00:01:48.355
文件，你想加入他们。

00:01:48.355 --> 00:01:50.000
所以在这种情况下，

00:01:50.000 --> 00:01:53.390
你不想得到所有的
数据转移到 SQL 服务器。

00:01:53.390 --> 00:01:53.720
* 否。

00:01:53.720 --> 00:01:55.760
• 哪个正在运行您的应用程序。

00:01:55.760 --> 00:01:57.785
所以，这就是
计算池有帮助。

00:01:57.785 --> 00:02:02.270
因此，它可以卸载大部分
工作交给 HDFS

00:02:02.270 --> 00:02:03.680
然后拉

00:02:03.680 --> 00:02:07.490
计算所需的数据
池，并在那里做联接。

00:02:07.490 --> 00:02:09.920
因此，这基本上卸载了他们所有，

00:02:09.920 --> 00:02:13.520
计算世界不同
SQL 服务器计算机，可以

00:02:13.520 --> 00:02:17.545
在 中的不同节点上
大数据集群，

00:02:17.545 --> 00:02:19.895
并使用这些资源。

00:02:19.895 --> 00:02:21.590
然后是其他场景，

00:02:21.590 --> 00:02:23.570
您正在加入来自

00:02:23.570 --> 00:02:26.780
不同的数据源
分区不同。

00:02:26.780 --> 00:02:31.760
所以，你必须统一
分区在某些时候，

00:02:31.760 --> 00:02:33.530
这就是
计算池有帮助。

00:02:33.530 --> 00:02:34.145
"好的。

00:02:34.145 --> 00:02:36.710
• 因此，如果一个表由

00:02:36.710 --> 00:02:40.465
客户 ID 和另一个
按订单 ID 分发，

00:02:40.465 --> 00:02:43.400
你仍然
按客户 ID 加入，

00:02:43.400 --> 00:02:46.590
它可以做
调节给你。

00:02:46.590 --> 00:02:47.400
"好的。

00:02:47.400 --> 00:02:50.070
* 因此，这是一些方案。

00:02:50.070 --> 00:02:54.259
您也可以做类似
将数据导出到 HDFS，

00:02:54.259 --> 00:02:56.930
那是别的地方
计算池可以提供帮助。

00:02:56.930 --> 00:02:59.090
"好的。因此，计算
游泳池将帮助我

00:02:59.090 --> 00:03:01.550
并行化、横向扩展
我的[听不见]。

00:03:01.550 --> 00:03:02.185
* 是的。

00:03:02.185 --> 00:03:05.430
• 两个读数都来自 HDFS
和写信给HDFS？

00:03:05.430 --> 00:03:06.030
* 是。

00:03:06.030 --> 00:03:07.350
• 冷却。这是怎么回事？

00:03:07.350 --> 00:03:09.300
我是说，你能给我们看一个
一点点，是如何工作的？

00:03:09.300 --> 00:03:12.605
* 是的。确定。我们走这儿吧。

00:03:12.605 --> 00:03:16.885
我实际上连接到一个
SQL 服务器大数据群集，

00:03:16.885 --> 00:03:19.655
特别是掌握
实例如下所示。

00:03:19.655 --> 00:03:22.280
所以我们现在有一个新的DMV，

00:03:22.280 --> 00:03:24.775
称为计算池。

00:03:24.775 --> 00:03:25.545
"好的。

00:03:25.545 --> 00:03:28.610
• 基本上，它显示
计算池

00:03:28.610 --> 00:03:31.955
已预配且可用
在大数据群集中。

00:03:31.955 --> 00:03:35.960
默认情况下，只有一个
我们在这里显示信息。

00:03:35.960 --> 00:03:38.110
然后，您还可以看到

00:03:38.110 --> 00:03:42.465
实际有多少个节点
在计算池中。

00:03:42.465 --> 00:03:44.740
此查询实际上显示，

00:03:44.740 --> 00:03:47.525
除了这个特殊的
SQL 服务器实例，

00:03:47.525 --> 00:03:49.100
我有两个计算

00:03:49.100 --> 00:03:52.730
池实例，如所示
这些突出显示的行，对不对？

00:03:52.730 --> 00:03:53.405
* 是的。

00:03:53.405 --> 00:03:57.815
• 还有其他的 DMV
您可以使用来基本找到

00:03:57.815 --> 00:04:03.195
有关计算的信息
池像如何的CPU活动，

00:04:03.195 --> 00:04:05.745
已分配多少内存，

00:04:05.745 --> 00:04:09.900
它是否甚至可用于
查询等，对不对？

00:04:09.900 --> 00:04:10.200
* 正确。

00:04:10.200 --> 00:04:12.470
* 这些是信息
DBA 可以

00:04:12.470 --> 00:04:15.095
用于对计算池进行故障排除。

00:04:15.095 --> 00:04:16.145
* 当然可以。

00:04:16.145 --> 00:04:20.480
• 此外，您可以
在

00:04:20.480 --> 00:04:25.955
SQL Server 实际上可以
去并使用计算池。

00:04:25.955 --> 00:04:26.270
"好的。

00:04:26.270 --> 00:04:27.565
* 因此，在此示例中，

00:04:27.565 --> 00:04:32.869
我在 SQL 中加入本地表
在 HDFS 中具有某些数据的服务器，

00:04:32.869 --> 00:04:37.070
我也有一张桌子
甲骨文，我正在查询。

00:04:37.070 --> 00:04:40.265
因此，您基本上可以运行查询和

00:04:40.265 --> 00:04:42.290
查询优化器
自动数字

00:04:42.290 --> 00:04:44.570
出如何使用计算池。

00:04:44.570 --> 00:04:47.630
在这种情况下，它会
使用计算机池

00:04:47.630 --> 00:04:50.930
您的 HDFS 表和

00:04:50.930 --> 00:04:54.490
其余数据是
所有加入和返回。

00:04:54.490 --> 00:04:57.030
就是一个例子
计算池

00:04:57.030 --> 00:05:00.060
透明工作
为您获取结果。

00:05:00.060 --> 00:05:01.755
• 冷却。看起来真不错

00:05:01.755 --> 00:05:04.220
基本上，我可以编写此查询。

00:05:04.220 --> 00:05:07.040
我现在可以相信
计算池将执行步骤

00:05:07.040 --> 00:05:10.010
在它有意义的地方
优化性能，正确吗？

00:05:10.010 --> 00:05:10.535
* 是。

00:05:10.535 --> 00:05:13.115
* 真棒。谢谢
很多共享。

00:05:13.115 --> 00:05:14.015
* 当然可以。

00:05:14.015 --> 00:05:15.500
我希望这是有用的。

00:05:15.500 --> 00:05:20.150
请喜欢或订阅
视频和评论。

00:05:20.150 --> 00:05:22.340
希望下次能见到你。
谢谢你的收看。

00:05:22.340 --> 00:05:36.910
[音乐]