WEBVTT

00:00:00.000 --> 00:00:03.000
SQL Server 2019 Big
Data Clusters fournit

00:00:03.000 --> 00:00:06.585
calculer les piscines à décharger
traitement des requêtes distribuées.

00:00:06.585 --> 00:00:10.350
UC est ici pour nous dire tout sur
ce aujourd'hui sur les données exposées.

00:00:10.350 --> 00:00:21.060
[MUSIQUE]

00:00:21.060 --> 00:00:25.215
Salut. Bienvenue dans un autre épisode
de données exposées. Je suis Jeroen.

00:00:25.215 --> 00:00:27.810
Aujourd'hui, je suis rejoint par UC
pour parler de calcul

00:00:27.810 --> 00:00:30.690
pools dans SQL Server
Clusters Big Data 2019.

00:00:30.690 --> 00:00:33.000
Salut, UC. Merci pour
rejoindre le spectacle à nouveau.

00:00:33.000 --> 00:00:34.155
Bien sûr.

00:00:34.155 --> 00:00:36.060
Les piscines de calcul?

00:00:36.060 --> 00:00:36.615
Oui, c'est vrai.

00:00:36.615 --> 00:00:37.815
Qu'est-ce que c'est ?

00:00:37.815 --> 00:00:40.980
Les piscines de calcul. Ils sont

00:00:40.980 --> 00:00:44.430
essentiellement cas SQL Server
dans un cluster big data,

00:00:44.430 --> 00:00:48.725
qui peut être utilisé pour décharger votre
traitement des requêtes distribuées.

00:00:48.725 --> 00:00:50.310
Donc, dans cette image,

00:00:50.310 --> 00:00:54.870
nous voyons les nombreux composants dans
un cluster SQL Server Big Data.

00:00:54.870 --> 00:00:58.570
Aujourd'hui, nous allons regarder
cette piscine de calcul ici.

00:00:58.570 --> 00:01:01.710
Qu'est-ce que c'est ? c'est
essentiellement un ensemble de

00:01:01.710 --> 00:01:03.825
Les instances SQL Server qui sont

00:01:03.825 --> 00:01:06.685
automatiquement brochured
à l'intérieur d'un cluster big data,

00:01:06.685 --> 00:01:10.475
et ils sont disponibles pour
faire une requête distribuée.

00:01:10.475 --> 00:01:11.405
D'accord.

00:01:11.405 --> 00:01:14.030
C'est similaire à la PolyBase

00:01:14.030 --> 00:01:17.585
Groupes d'scale-out dans SQL Server 2016.

00:01:17.585 --> 00:01:21.490
Cette capacité vous fournit maintenant

00:01:21.490 --> 00:01:25.174
ensemble de cas SQL,

00:01:25.174 --> 00:01:27.890
qui peut faire la plupart des
travail distribué pour vous.

00:01:27.890 --> 00:01:28.930
D'accord.

00:01:28.930 --> 00:01:32.540
Les requêtes peuvent soit utiliser
le pool de calcul ou ne pas utiliser

00:01:32.540 --> 00:01:35.540
le pool de calcul en fonction
sur le type de requête.

00:01:35.540 --> 00:01:38.570
Quel scénario aurais-je
choisir pour une piscine de calcul?

00:01:38.570 --> 00:01:40.720
Oui, c'est vrai. génial
Question. Voyons voir.

00:01:40.720 --> 00:01:44.270
L'un des scénarios courants est
dire que vous avez deux répertoires dans

00:01:44.270 --> 00:01:45.950
HDFS avec des centaines et des milliers de

00:01:45.950 --> 00:01:48.355
fichiers et vous souhaitez les rejoindre.

00:01:48.355 --> 00:01:50.000
Donc, dans ce scénario,

00:01:50.000 --> 00:01:53.390
vous ne voulez pas obtenir tous les
données sur votre serveur SQL.

00:01:53.390 --> 00:01:53.720
Non, c'est pas le cas.

00:01:53.720 --> 00:01:55.760
Qui exécute votre application.

00:01:55.760 --> 00:01:57.785
C'est donc là que le
piscine de calcul aide.

00:01:57.785 --> 00:02:02.270
Ainsi, il peut décharger la plupart des
le travail à la HDFS

00:02:02.270 --> 00:02:03.680
et puis plus tard tirer

00:02:03.680 --> 00:02:07.490
les données nécessaires au calcul
piscine et faire la jointure là-bas.

00:02:07.490 --> 00:02:09.920
Donc, cela les décharge essentiellement tous,

00:02:09.920 --> 00:02:13.520
le monde de l'informatique à différents
Machines SQL Server qui peuvent être

00:02:13.520 --> 00:02:17.545
sur différents nœuds dans
ce cluster big data,

00:02:17.545 --> 00:02:19.895
et utiliser ces ressources.

00:02:19.895 --> 00:02:21.590
Puis les autres scénarios,

00:02:21.590 --> 00:02:23.570
vous joignez les données de

00:02:23.570 --> 00:02:26.780
différentes sources de données qui
sont partitionnés différemment.

00:02:26.780 --> 00:02:31.760
Donc là, vous devez unifier que
partitionnement à un moment donné,

00:02:31.760 --> 00:02:33.530
et c'est là que le
piscine de calcul aide.

00:02:33.530 --> 00:02:34.145
D'accord.

00:02:34.145 --> 00:02:36.710
Donc, si une table est distribuée par

00:02:36.710 --> 00:02:40.465
ID client et un autre est
distribué par Order ID,

00:02:40.465 --> 00:02:43.400
et vous êtes toujours
joint par Customer ID,

00:02:43.400 --> 00:02:46.590
il peut le faire
réconciliation pour vous.

00:02:46.590 --> 00:02:47.400
D'accord.

00:02:47.400 --> 00:02:50.070
C'est donc quelques-uns des scénarios.

00:02:50.070 --> 00:02:54.259
Vous pouvez aussi faire des choses comme
l'exportation de données vers HDFS,

00:02:54.259 --> 00:02:56.930
et c'est un autre endroit
où la piscine de calcul peut aider.

00:02:56.930 --> 00:02:59.090
D'accord. Donc, le calcul
piscine va m'aider à

00:02:59.090 --> 00:03:01.550
paralléliser, étendre
mon [inaudible].

00:03:01.550 --> 00:03:02.185
Oui, c'est vrai.

00:03:02.185 --> 00:03:05.430
Les deux lectures de HDFS
et d'écrire à HDFS à tous?

00:03:05.430 --> 00:03:06.030
Oui, c'est vrai.

00:03:06.030 --> 00:03:07.350
Cool. Comment cela fonctionne-t-il?

00:03:07.350 --> 00:03:09.300
Je veux dire, pouvez-vous nous montrer un
un peu de la façon dont cela fonctionne?

00:03:09.300 --> 00:03:12.605
Oui, c'est vrai. Sûr. Allons-y.

00:03:12.605 --> 00:03:16.885
Je suis en fait connecté à un
Cluster Big Data SQL Server,

00:03:16.885 --> 00:03:19.655
et plus particulièrement le Mastered
l'instance est montrée ici.

00:03:19.655 --> 00:03:22.280
Donc, nous avons maintenant un nouveau DMV,

00:03:22.280 --> 00:03:24.775
qui est appelé piscines de calcul.

00:03:24.775 --> 00:03:25.545
D'accord.

00:03:25.545 --> 00:03:28.610
En gros, il montre
les pools de calcul qui

00:03:28.610 --> 00:03:31.955
sont provisionnés et disponibles
dans le cluster Big Data.

00:03:31.955 --> 00:03:35.960
Par défaut, il n'y a qu'un seul et
nous montrons cette information ici.

00:03:35.960 --> 00:03:38.110
Ensuite, vous pouvez également voir

00:03:38.110 --> 00:03:42.465
combien de nœuds sont réellement
là dans la piscine de calcul.

00:03:42.465 --> 00:03:44.740
Cette requête montre en fait,

00:03:44.740 --> 00:03:47.525
en dehors de ce particulier
Instance SQL Server,

00:03:47.525 --> 00:03:49.100
J'ai deux calculer

00:03:49.100 --> 00:03:52.730
instances de pool comme le montre
ces lignes mis en évidence, non?

00:03:52.730 --> 00:03:53.405
Oui, c'est vrai.

00:03:53.405 --> 00:03:57.815
Il y a d'autres DMV qui
vous pouvez utiliser pour trouver essentiellement

00:03:57.815 --> 00:04:03.195
informations sur le calcul
piscine comme comment est l'activité CPU,

00:04:03.195 --> 00:04:05.745
combien de mémoire a été allouée,

00:04:05.745 --> 00:04:09.900
si elle est même disponible pour
la requête et ainsi de suite, non?

00:04:09.900 --> 00:04:10.200
C'est vrai.

00:04:10.200 --> 00:04:12.470
Il s'agit d'informations
qu'un DBA peut

00:04:12.470 --> 00:04:15.095
utiliser pour dépanner le pool de calcul.

00:04:15.095 --> 00:04:16.145
Bien sûr.

00:04:16.145 --> 00:04:20.480
En outre, vous pouvez
exécuter une requête complexe dans

00:04:20.480 --> 00:04:25.955
SQL Server qui peut réellement
aller utiliser la piscine de calcul.

00:04:25.955 --> 00:04:26.270
D'accord.

00:04:26.270 --> 00:04:27.565
Donc, dans cet exemple,

00:04:27.565 --> 00:04:32.869
Je me joins à une table locale à SQL
Serveur avec certaines données dans HDFS,

00:04:32.869 --> 00:04:37.070
et j'ai aussi une table dans
Oracle, que je interroge.

00:04:37.070 --> 00:04:40.265
Donc, vous pouvez essentiellement exécuter une requête et

00:04:40.265 --> 00:04:42.290
l'optimiseur de requêtes
chiffres automatiques

00:04:42.290 --> 00:04:44.570
comment utiliser le pool de calcul.

00:04:44.570 --> 00:04:47.630
Dans ce cas, il va
utiliser le pool informatique pour

00:04:47.630 --> 00:04:50.930
votre table HDFS et

00:04:50.930 --> 00:04:54.490
le reste des données est
tous rejoints et retournés.

00:04:54.490 --> 00:04:57.030
C'est un exemple
où une piscine de calcul

00:04:57.030 --> 00:05:00.060
travaille de manière transparente à
obtenir les résultats pour vous.

00:05:00.060 --> 00:05:01.755
Cool. C'est vraiment beau.

00:05:01.755 --> 00:05:04.220
Fondamentalement, je peux écrire cette requête.

00:05:04.220 --> 00:05:07.040
Je peux maintenant faire confiance à la
pool de calcul fera étape

00:05:07.040 --> 00:05:10.010
dans où il est logique de
optimiser les performances, correct?

00:05:10.010 --> 00:05:10.535
Oui, c'est vrai.

00:05:10.535 --> 00:05:13.115
C'est génial. Eh bien, merci
beaucoup pour le partage.

00:05:13.115 --> 00:05:14.015
Bien sûr.

00:05:14.015 --> 00:05:15.500
J'espère que c'était utile.

00:05:15.500 --> 00:05:20.150
S'il vous plaît aimer ou vous abonner
à la vidéo et au commentaire.

00:05:20.150 --> 00:05:22.340
J'espère vous voir la prochaine fois.
Merci d'avoir regardé.

00:05:22.340 --> 00:05:36.910
[MUSIQUE]