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