WEBVTT

00:00:00.000 --> 00:00:02.070
SQL Server grand
les groupes de données fournissent

00:00:02.070 --> 00:00:03.960
mécanismes de sécurité pour s'assurer

00:00:03.960 --> 00:00:06.150
l'accès à vos données est toujours sécurisé.

00:00:06.150 --> 00:00:08.220
Nellie est ici pour dire
nous tout sur

00:00:08.220 --> 00:00:10.350
il aujourd'hui sur les données exposées.

00:00:10.350 --> 00:00:21.210
[MUSIQUE]

00:00:21.210 --> 00:00:24.165
Salut et bienvenue dans un autre
épisode de Data Exposed.

00:00:24.165 --> 00:00:27.570
Je suis Jeroen votre hôte et
nous avons Nellie aujourd'hui avec

00:00:27.570 --> 00:00:30.990
nous de parler de la sécurité pour les grands
groupes de données. Salut, Nellie.

00:00:30.990 --> 00:00:31.860
Salut, Jeroen.

00:00:31.860 --> 00:00:32.700
Comment allez-vous ?

00:00:32.700 --> 00:00:33.750
Je vais bien. merci.

00:00:33.750 --> 00:00:36.930
D'accord. Donc, la sécurité
pour les clusters big data,

00:00:36.930 --> 00:00:38.340
cela doit sembler important.

00:00:38.340 --> 00:00:41.355
Pouvez-vous nous dire comment cela fonctionne?

00:00:41.355 --> 00:00:44.970
Bien sûr. Donc, si vous êtes
familier avec SQL Server,

00:00:44.970 --> 00:00:47.735
vous savez probablement que
la sécurité est toujours

00:00:47.735 --> 00:00:49.820
une priorité absolue pour nous

00:00:49.820 --> 00:00:53.540
et c'est la même chose
avec des clusters big data.

00:00:53.540 --> 00:00:56.180
Nous priorisons ce travail

00:00:56.180 --> 00:00:59.015
et notez à quel point
c'est à nos clients.

00:00:59.015 --> 00:01:04.340
Donc, je vais mettre en évidence certains
les choses autour de la sécurité aujourd'hui.

00:01:04.340 --> 00:01:06.485
Nous n'allons pas
couvrir tous les détails,

00:01:06.485 --> 00:01:10.430
mais nous allons essentiellement couvrir

00:01:10.430 --> 00:01:12.080
à haut niveau afin que vous sachiez

00:01:12.080 --> 00:01:15.170
les capacités de sécurité
du cluster Big Data.

00:01:15.170 --> 00:01:16.220
D'accord.

00:01:16.220 --> 00:01:17.870
Comme vous le savez, beaucoup de

00:01:17.870 --> 00:01:20.440
nos clients SQL Server
sont des clients d'entreprise,

00:01:20.440 --> 00:01:23.720
grandes entreprises qui
exécuter Active Directory.

00:01:23.720 --> 00:01:27.125
Nous devons nous assurer que tous les
vos applications, y compris

00:01:27.125 --> 00:01:29.420
SQL Serveur et Big Data
clusters et tous les

00:01:29.420 --> 00:01:32.525
ces solutions peuvent
s'intégrer bien à l'AD.

00:01:32.525 --> 00:01:33.515
Oui, c'est vrai.

00:01:33.515 --> 00:01:36.680
C'est la clé
capacité que nous sommes

00:01:36.680 --> 00:01:40.355
l'activation dans les clusters big data en 2019

00:01:40.355 --> 00:01:44.060
est de réellement pour
vous d'être en mesure de faire

00:01:44.060 --> 00:01:47.945
d'une manière transparente et facile.

00:01:47.945 --> 00:01:51.425
Maintenant, je vais vous dire pourquoi
J'ai mis l'accent sur la facilité et

00:01:51.425 --> 00:01:56.150
sans couture parce que généralement lorsque
vous avez affaire à des applications,

00:01:56.150 --> 00:01:58.070
disons que n'importe quel type d'application,

00:01:58.070 --> 00:02:01.220
rejoindre une application à AD
n'est pas un gros problème, non?

00:02:01.220 --> 00:02:04.280
Nous supposons simplement que toute application
prend en charge l'intégration AD.

00:02:04.280 --> 00:02:04.730
Bien sûr.

00:02:04.730 --> 00:02:07.640
Maintenant, pour les clusters big data,
c'est la même chose.

00:02:07.640 --> 00:02:09.185
Ca devrait marcher.

00:02:09.185 --> 00:02:11.090
C'est juste que nous devons

00:02:11.090 --> 00:02:13.890
souligner que nous sommes
en cours d'exécution dans une sorte complète de

00:02:13.890 --> 00:02:18.255
complètement conteneurisé
solution ici où

00:02:18.255 --> 00:02:20.240
tous les services sont en cours d'exécution dans

00:02:20.240 --> 00:02:22.160
conteneurs et tous les
services de soutien

00:02:22.160 --> 00:02:23.470
sont en cours d'exécution dans des conteneurs,

00:02:23.470 --> 00:02:25.370
et c'est en cours d'exécution
au-dessus de Kubernetes.

00:02:25.370 --> 00:02:25.955
C'est vrai.

00:02:25.955 --> 00:02:30.200
Nous avons donc beaucoup travaillé
sur s'assurer que vous obtenez

00:02:30.200 --> 00:02:33.200
un système entièrement automatisé et
expérience transparente de

00:02:33.200 --> 00:02:37.130
ce complètement conteneurisé
solution big data

00:02:37.130 --> 00:02:39.560
au-dessus de Kubernetes.

00:02:39.560 --> 00:02:41.600
Donc, fondamentalement, tout cela
fonctionne dans le conteneur de sorte que c'est

00:02:41.600 --> 00:02:43.820
pourquoi l'intégration est intéressante.

00:02:43.820 --> 00:02:45.170
Alors, qu'est-ce que cela signifie d'avoir

00:02:45.170 --> 00:02:47.360
un système entièrement automatisé
intégration? Qu'est-ce que j'ai ?

00:02:47.360 --> 00:02:50.510
Oui, c'est vrai. Donc pour ça,

00:02:50.510 --> 00:02:52.415
vous pourriez avoir besoin d'un peu
peu de fond.

00:02:52.415 --> 00:02:52.530
D'accord.

00:02:52.530 --> 00:02:55.700
Donc, quand vous vous joignez
une sorte de service à

00:02:55.700 --> 00:02:58.099
Annuaire actif ou Kerberos

00:02:58.099 --> 00:03:00.410
qui est en cours d'exécution à l'intérieur
un conteneur Linux,

00:03:00.410 --> 00:03:03.320
par exemple, c'est
absolument possible.

00:03:03.320 --> 00:03:04.670
C'est juste que vous devez appliquer

00:03:04.670 --> 00:03:07.655
quelques étapes manuelles pour
faire en sortir.

00:03:07.655 --> 00:03:10.430
Maintenant, imaginez que vous avez un
solution avec des centaines

00:03:10.430 --> 00:03:14.255
de ces conteneurs avec des centaines
des services en cours d'exécution là-dedans.

00:03:14.255 --> 00:03:16.580
Pour ce faire manuellement
ne serait évidemment pas

00:03:16.580 --> 00:03:19.730
réaliste et nous ne voulons pas
de demander cela à nos utilisateurs.

00:03:19.730 --> 00:03:22.130
Donc, par entièrement automatisé,

00:03:22.130 --> 00:03:23.795
Je veux dire essentiellement que nous sommes

00:03:23.795 --> 00:03:25.970
s'occuper de la
complexité pour vous.

00:03:25.970 --> 00:03:29.105
Nous avons un service qui s'appelle
service de soutien de sécurité.

00:03:29.105 --> 00:03:30.695
Donc, dans le cadre du déploiement,

00:03:30.695 --> 00:03:32.090
que le service va prendre

00:03:32.090 --> 00:03:34.430
quelques informations de votre part
en tant qu'utilisateur qui déploie

00:03:34.430 --> 00:03:39.005
le cluster, puis le service
va essentiellement effectuer

00:03:39.005 --> 00:03:41.480
toutes ces étapes pour chaque
service unique dans le cluster

00:03:41.480 --> 00:03:44.045
pour s'assurer que
tout est AD rejoint.

00:03:44.045 --> 00:03:46.850
Wow, c'est impressionnant.
C'est très cool.

00:03:46.850 --> 00:03:48.890
Donc, fondamentalement, je peux juste laisser

00:03:48.890 --> 00:03:51.410
le cluster le configurer
et voilà, non ?

00:03:51.410 --> 00:03:52.475
Oui, exactement.

00:03:52.475 --> 00:03:53.005
Cool.

00:03:53.005 --> 00:03:55.145
Maintenant, en plus de cela,

00:03:55.145 --> 00:03:58.370
nous passons aussi beaucoup de temps à

00:03:58.370 --> 00:04:01.100
assurez-vous que nous obtenons un
l'expérience de sécurité intégrée.

00:04:01.100 --> 00:04:04.730
Par là, je veux dire que, par exemple,

00:04:04.730 --> 00:04:07.864
lorsque vous passez un
requête de Spark à HDFS,

00:04:07.864 --> 00:04:10.060
parce que dans le Big Data
cluster nous avons Spark,

00:04:10.060 --> 00:04:12.090
vous pouvez interroger des données dans HDFS.

00:04:12.090 --> 00:04:15.920
Ces composants déjà
jouer assez bien ensemble.

00:04:15.920 --> 00:04:19.700
Donc, ces composants sont
partie de la même pile,

00:04:19.700 --> 00:04:22.440
vous pouvez dire, une partie de
la pile Apache.

00:04:23.620 --> 00:04:27.260
Il y a donc beaucoup de fonctionnalités
nous pouvons déjà tirer parti là-bas.

00:04:27.260 --> 00:04:29.780
Mais quand il s'agit de SQL
Serveur et serveur SQL

00:04:29.780 --> 00:04:32.965
natif de parler à un
composante comme HDFS,

00:04:32.965 --> 00:04:35.480
c'est en fait une nouvelle fonctionnalité

00:04:35.480 --> 00:04:37.250
que nous introduisons là où nous

00:04:37.250 --> 00:04:41.280
avoir la capacité de SQL
Scénarios de requêtes serveur,

00:04:41.280 --> 00:04:43.110
Je dois souligner que si je

00:04:43.110 --> 00:04:45.495
transmettre une requête au SQL
Exemple maître de serveur,

00:04:45.495 --> 00:04:47.540
c'est juste une requête SQL
qui est d'interrogation

00:04:47.540 --> 00:04:49.970
sur une table externe
assis dans HDFS, non?

00:04:49.970 --> 00:04:52.295
Donc quand je fais ça,

00:04:52.295 --> 00:04:57.020
nous nous assurons que mon
l'identité en tant que personne qui est

00:04:57.020 --> 00:05:01.070
l'émission de cette requête coule tout le chemin

00:05:01.070 --> 00:05:03.410
à travers tous ces
différents composants

00:05:03.410 --> 00:05:05.600
sur le chemin vers le bas pour
HDFS où les données

00:05:05.600 --> 00:05:10.400
est de sorte que nous pouvons faire une autorisation
vérifier les données réelles,

00:05:10.400 --> 00:05:12.590
et c'est ce que je veux dire
avec une sécurité intégrée.

00:05:12.590 --> 00:05:14.615
Il est intégré par
tous ces composants.

00:05:14.615 --> 00:05:16.760
Donc, peu importe où je émets la requête,

00:05:16.760 --> 00:05:18.515
de Spark ou SQL Server,

00:05:18.515 --> 00:05:20.450
l'identité de l'utilisateur est toujours en cours

00:05:20.450 --> 00:05:22.895
à circuler à travers tous les
le chemin vers la source.

00:05:22.895 --> 00:05:25.640
D'accord. C'est très impressionnant
et très important pour

00:05:25.640 --> 00:05:27.560
toute entreprise travaillant avec ce genre

00:05:27.560 --> 00:05:29.570
de choses parce que vous voulez
savoir que vos données sont sécurisées.

00:05:29.570 --> 00:05:31.430
Exactement. Je veux dire
vous avez un audit,

00:05:31.430 --> 00:05:33.860
vous avez vos journaux d'audit à faire
s'assurer qu'ils sont à jour,

00:05:33.860 --> 00:05:36.425
et vous ne voulez pas un service
compte à afficher dans ceux-ci.

00:05:36.425 --> 00:05:37.190
Exactement.

00:05:37.190 --> 00:05:40.940
C'est donc l'une des exigences clés
de nos clients ainsi.

00:05:40.940 --> 00:05:42.860
En plus de cela,

00:05:42.860 --> 00:05:49.340
nous avons aussi l'intégration
l'expérience dans les formes de la façon dont vous,

00:05:49.340 --> 00:05:51.305
par exemple, interagir
avec le cluster.

00:05:51.305 --> 00:05:53.150
Nous avons des données Azure
Studio que vous pouvez

00:05:53.150 --> 00:05:56.370
utiliser pour se connecter à de grands
cluster de données, non?

00:05:56.540 --> 00:05:59.480
Nous voulons donner à la
expérience d'un seul

00:05:59.480 --> 00:06:03.110
se connecter pour autant de
scénarios que possible.

00:06:03.110 --> 00:06:05.295
Donc, quand je me connecte à
un cluster big data,

00:06:05.295 --> 00:06:07.345
En fait, je me connecte à
l'instance principale,

00:06:07.345 --> 00:06:11.030
mais nos outils feront en sorte
que j'ai aussi accès à Spark,

00:06:11.030 --> 00:06:12.590
dans HDFS, et tous ces autres

00:06:12.590 --> 00:06:15.010
composants qui sont intéressants
dans le cluster Big Data.

00:06:15.010 --> 00:06:16.895
Donc, c'est tout géré
transparent pour moi?

00:06:16.895 --> 00:06:18.185
Oui, exactement.

00:06:18.185 --> 00:06:19.250
D'accord. cool.

00:06:19.250 --> 00:06:22.375
Oui, c'est vrai. Enfin et surtout

00:06:22.375 --> 00:06:24.650
nous avons cryptage et

00:06:24.650 --> 00:06:27.125
le chiffrement est très important
pour nos utilisateurs, non?

00:06:27.125 --> 00:06:27.890
Bien sûr.

00:06:27.890 --> 00:06:30.965
Nous nous sommes assurés que
toute la communication,

00:06:30.965 --> 00:06:33.950
même interne et
communication externe,

00:06:33.950 --> 00:06:39.290
avec le cluster Big Data
est crypté SSL ou TLS.

00:06:39.290 --> 00:06:41.285
En outre,

00:06:41.285 --> 00:06:43.325
vous pouvez bien sûr tirer parti

00:06:43.325 --> 00:06:45.635
les nombreux différents
caractéristiques de cryptage de

00:06:45.635 --> 00:06:48.470
SQL Server que nous avons
et tous ceux qui sont

00:06:48.470 --> 00:06:49.985
pris en charge sur SQL Server sur Linux

00:06:49.985 --> 00:06:52.430
parce que nous courons sur
Conteneurs Linux ici.

00:06:52.430 --> 00:06:57.485
Nous travaillons également à l'expansion
ces capacités et ajouter

00:06:57.485 --> 00:07:00.710
Le cryptage HDFS bientôt
de sorte que nous avons aussi

00:07:00.710 --> 00:07:04.745
ces capacités pour les données
qui est crypté à risque.

00:07:04.745 --> 00:07:07.920
D'accord. cool. Alors pouvez-vous

00:07:07.920 --> 00:07:09.410
nous expliquer un peu
un peu plus sur la façon dont

00:07:09.410 --> 00:07:11.570
cela fonctionne sous Kerberos?

00:07:11.570 --> 00:07:16.070
Absolument. Donc, nous allons
mettre l'accent sur l'authentification

00:07:16.070 --> 00:07:18.770
d'abord parce que c'est
important pour vous de

00:07:18.770 --> 00:07:20.485
savoir quelle différence ou

00:07:20.485 --> 00:07:22.785
points d'entrée il ya
à la grappe, non?

00:07:22.785 --> 00:07:26.360
Ici vous voyez les cinq
différents points de terminaison

00:07:26.360 --> 00:07:28.490
ou les points d'entrée du cluster.

00:07:28.490 --> 00:07:30.485
Maintenant, nous avons ce cluster Kubernetes,

00:07:30.485 --> 00:07:32.660
donc nous devons essentiellement spécifiquement

00:07:32.660 --> 00:07:35.360
exposer certains paramètres que les utilisateurs

00:07:35.360 --> 00:07:37.430
ou des outils clients ou
toutes les applications peuvent

00:07:37.430 --> 00:07:40.865
interagir avec dans le cluster.

00:07:40.865 --> 00:07:44.475
Donc, si nous commençons avec le contrôleur,

00:07:44.475 --> 00:07:46.685
comme vous le connaissez peut-être,

00:07:46.685 --> 00:07:48.860
contrôleur est le
cerveau de la grappe.

00:07:48.860 --> 00:07:52.715
Le contrôleur est celui qui
garde une trace de tout,

00:07:52.715 --> 00:07:54.229
qui déploie le cluster,

00:07:54.229 --> 00:07:55.775
et toutes ces choses.

00:07:55.775 --> 00:07:58.580
Maintenant, pour atteindre le
points de terminaison contrôleur,

00:07:58.580 --> 00:08:02.500
vous pouvez voir ici que le principal
méthode que vous interagiriez

00:08:02.500 --> 00:08:04.885
avec elle serait
par le biais de l'azdata CLI

00:08:04.885 --> 00:08:06.850
mais aussi à travers nos outils.

00:08:06.850 --> 00:08:11.860
C'est principalement le point de terminaison qui
un administrateur utiliserait,

00:08:11.860 --> 00:08:14.005
par exemple, d'interagir
avec le cluster.

00:08:14.005 --> 00:08:16.180
Mais le contrôleur a aussi des pouvoirs magiques.

00:08:16.180 --> 00:08:20.470
Vous pouvez dire que le contrôleur peut trier
d'atteindre d'autres points de terminaison.

00:08:20.470 --> 00:08:23.890
Ainsi, par exemple, vous pouvez vous connecter à

00:08:23.890 --> 00:08:27.485
contrôleur par azdata et de

00:08:27.485 --> 00:08:29.920
il question des commandes qui seront

00:08:29.920 --> 00:08:32.710
vous emmener à SQL Server master
instance et vous venez de commencer à courir

00:08:32.710 --> 00:08:35.380
T-SQL ou vous pouvez exécuter des commandes HDFS

00:08:35.380 --> 00:08:38.665
directement dans une coquille HDFS
dans ce genre de choses.

00:08:38.665 --> 00:08:42.470
C'est donc ce que ce point de terminaison permet
vous faire entre autres choses.

00:08:42.470 --> 00:08:43.275
D'accord. Très cool.

00:08:43.275 --> 00:08:45.830
Oui, c'est vrai. Ensuite, un point de terminaison que vous

00:08:45.830 --> 00:08:47.690
peut-être entendu parler si vous avez

00:08:47.690 --> 00:08:49.860
utilisé des clusters big data
est la porte d'entrée.

00:08:49.860 --> 00:08:52.055
Maintenant, la passerelle est
en fait la même chose.

00:08:52.055 --> 00:08:53.885
Le détail de la mise en œuvre derrière cette

00:08:53.885 --> 00:08:56.735
c'est que c'est la porte Apache Knox.

00:08:56.735 --> 00:08:59.900
Il s'agit d'une passerelle qui
protège, vous pouvez dire,

00:08:59.900 --> 00:09:06.210
les composants Apache tels que
essentiellement du côté hadoopale.

00:09:06.210 --> 00:09:06.510
C'est vrai.

00:09:06.510 --> 00:09:07.980
Nous avons donc Spark, Livy,

00:09:07.980 --> 00:09:11.999
YARN si vous voulez vous connecter
hDFS via le web HDFS,

00:09:11.999 --> 00:09:13.705
c'est le point de terminaison que vous utilisez,

00:09:13.705 --> 00:09:17.165
ainsi que d'Azure Data Studio.

00:09:17.165 --> 00:09:19.160
Donc, c'est bon de savoir quand

00:09:19.160 --> 00:09:21.505
nous parlons de la
passerelle ce que nous voulons dire là-bas.

00:09:21.505 --> 00:09:23.990
Ensuite, nous avons le
proxy de gestion qui

00:09:23.990 --> 00:09:28.070
est la passerelle vers les mesures
et les outils d'exploitation forestière,

00:09:28.070 --> 00:09:31.490
et puis nous avons évidemment
Cas principal de serveur SQL.

00:09:31.490 --> 00:09:33.830
C'est juste SQL. C'est juste
un point de terminaison TDS où vous

00:09:33.830 --> 00:09:37.025
se connecter à partir de tous les outils
que vous connaissez.

00:09:37.025 --> 00:09:39.200
Le proxy de l'application, dernier
mais pas le moindre,

00:09:39.200 --> 00:09:41.780
qui est la façon dont vous pouvez

00:09:41.780 --> 00:09:43.310
accéder aux applications qui

00:09:43.310 --> 00:09:45.290
vous avez déployé à l'intérieur
le cluster Big Data.

00:09:45.290 --> 00:09:47.820
Maintenant, tous ces différents
les points de terminaison lorsque vous exécutez,

00:09:47.820 --> 00:09:49.305
par exemple, dans un mode sécurisé,

00:09:49.305 --> 00:09:50.760
lorsque le cluster est
en mode sécurisé,

00:09:50.760 --> 00:09:53.175
Je veux dire mode d'intégration AD,

00:09:53.175 --> 00:09:58.210
tous ces critères d'évaluation sont
permettant l'authentification AD.

00:09:58.210 --> 00:10:00.200
C'est ce que je voulais.
pour mettre en évidence ici.

00:10:00.200 --> 00:10:02.510
Donc, quand nous parlons
à propos de l'authentification AD,

00:10:02.510 --> 00:10:06.740
c'est une intégration complète avec
AD pour tous les points de terminaison.

00:10:06.740 --> 00:10:08.645
C'est vrai. Devant l'un des
cinq points de terminaison dans l'ensemble.

00:10:08.645 --> 00:10:09.335
Exactement.

00:10:09.335 --> 00:10:11.490
C'est pas le tout. d'accord.

00:10:12.740 --> 00:10:16.590
Oui, c'est vrai. Donc, c'est l'authentification
fondamentalement pour vous.

00:10:16.590 --> 00:10:19.755
En allant de l'avant, nous avons également
avoir l'autorisation.

00:10:19.755 --> 00:10:21.290
Il est très important de protéger

00:10:21.290 --> 00:10:23.780
vos données une fois qu'il est
à l'intérieur du cluster,

00:10:23.780 --> 00:10:26.720
une fois que vous avez réellement réussi à
connectez-vous et authentifiez..

00:10:26.720 --> 00:10:30.675
ouais. Donc, les parties clés que je
voulu mettre en évidence ici,

00:10:30.675 --> 00:10:31.920
et c'est encore un niveau élevé.

00:10:31.920 --> 00:10:33.485
Je suis sûr que nous allons avoir

00:10:33.485 --> 00:10:35.660
d'autres discussions sur la
détails de ces choses.

00:10:35.660 --> 00:10:37.335
Mais à un haut niveau,

00:10:37.335 --> 00:10:38.510
il y a deux niveaux de

00:10:38.510 --> 00:10:42.050
vérifications d'autorisation que vous
dans les clusters Big Data.

00:10:42.050 --> 00:10:44.750
Si nous commençons avec SQL
Serveur, par exemple,

00:10:44.750 --> 00:10:48.050
si j'émets une requête SQL Server,

00:10:48.050 --> 00:10:50.420
tout d'abord, il y a
vérifications d'autorisation

00:10:50.420 --> 00:10:52.100
sur les objets SQL Server.

00:10:52.100 --> 00:10:54.920
J'ai besoin d'avoir accès à la
tables que je veux interroger,

00:10:54.920 --> 00:10:58.730
par exemple, afin que nous puissions faire
m'assurer que je peux accéder aux données.

00:10:58.730 --> 00:11:00.860
Mais c'est la même chose
vérifications d'autorisation

00:11:00.860 --> 00:11:02.330
comme nous l'avions dans le précédent
communiqués avec SQL?

00:11:02.330 --> 00:11:02.780
Oui, c'est SQL.

00:11:02.780 --> 00:11:03.530
Cela n'a pas changé ?

00:11:03.530 --> 00:11:04.280
Ce n'est que SQL.

00:11:04.280 --> 00:11:04.610
D'accord.

00:11:04.610 --> 00:11:07.160
Donc, fondamentalement, le
modèle d'autorisation de

00:11:07.160 --> 00:11:08.945
SQL Server est le même

00:11:08.945 --> 00:11:11.285
si elle fonctionne dans le grand
groupe de données ou n'importe où ailleurs.

00:11:11.285 --> 00:11:13.490
Ainsi, vous pouvez toujours accorder des autorisations sur

00:11:13.490 --> 00:11:16.950
tableaux spécifiques et spécifiques
objets dans SQL Server, non?

00:11:16.950 --> 00:11:17.915
D'accord.

00:11:17.915 --> 00:11:19.945
Mais en plus de ça,

00:11:19.945 --> 00:11:21.845
maintenant nous allons prendre le scénario quand je suis

00:11:21.845 --> 00:11:23.990
émettre une requête contre les données qui sont

00:11:23.990 --> 00:11:26.060
assis dans HDFS et je suis interroge

00:11:26.060 --> 00:11:28.715
une table externe sur
HDFS dans ce cas.

00:11:28.715 --> 00:11:31.790
Non seulement j'ai besoin d'avoir
l'accès à cette table,

00:11:31.790 --> 00:11:34.025
à la base de données où
cette table se trouve,

00:11:34.025 --> 00:11:36.320
J'ai aussi besoin d'avoir accès à

00:11:36.320 --> 00:11:39.905
les fichiers et les données réels
qui est assis dans HDFS.

00:11:39.905 --> 00:11:40.145
Bien sûr.

00:11:40.145 --> 00:11:43.430
C'est ce que je voulais dire avec le
contrôles d'autorisation à deux niveaux.

00:11:43.430 --> 00:11:45.035
Donc, dans ce cas, il ya un check-in

00:11:45.035 --> 00:11:48.620
SQL Server et il y a un
contrôle supplémentaire dans HDFS.

00:11:48.620 --> 00:11:48.920
D'accord.

00:11:48.920 --> 00:11:50.510
Du côté de Spark,

00:11:50.510 --> 00:11:53.660
essentiellement le Spark
les requêtes s'écouleront et

00:11:53.660 --> 00:11:56.000
le contrôle d'autorisation HDFS sera

00:11:56.000 --> 00:11:58.505
assurez-vous que le
les autorisations sont honorées.

00:11:58.505 --> 00:12:00.200
D'accord. Donc, avec tout cela,

00:12:00.200 --> 00:12:01.820
Je peux être sûr que

00:12:01.820 --> 00:12:04.370
l'utilisateur d'origine
l'identité est transmise par

00:12:04.370 --> 00:12:06.590
SQL Server à n'importe où
les données sont, non?

00:12:06.590 --> 00:12:09.455
HDFS ou comment j'y accède, correct?

00:12:09.455 --> 00:12:15.390
Exactement. ouais. Alors que nous
une sorte de touché avant,

00:12:15.390 --> 00:12:18.825
Nous aurons cette identité de passage

00:12:18.825 --> 00:12:22.670
ce qui signifie que l'original
l'identité de l'utilisateur s'écoulera

00:12:22.670 --> 00:12:26.810
tout le chemin jusqu'à la
données afin que nous puissions réellement

00:12:26.810 --> 00:12:27.980
vérifier tout le chemin

00:12:27.980 --> 00:12:31.730
que c'était l'utilisateur qui
voulait accéder aux données.

00:12:31.730 --> 00:12:32.800
D'accord.

00:12:32.800 --> 00:12:38.820
Oui, c'est vrai. Et alors
est essentiellement un résumé sur

00:12:38.820 --> 00:12:41.390
niveau élevé sur la sécurité
capacités autour de

00:12:41.390 --> 00:12:44.780
les intégrations AD spécifiquement
pour les clusters big data.

00:12:44.780 --> 00:12:47.710
Alors, où puis-je trouver
plus si je veux plonger plus profondément?

00:12:47.710 --> 00:12:50.420
Oui, c'est vrai. Donc, si

00:12:50.420 --> 00:12:52.580
vous voulez en savoir plus sur
les clusters de données volumineuses en général

00:12:52.580 --> 00:12:56.495
et nous avons des documents de sécurité

00:12:56.495 --> 00:12:59.675
couvrant les détails de ce que
Je viens d'expliquer aujourd'hui,

00:12:59.675 --> 00:13:04.280
vous devriez aller à ce
lien court: aka.ms/sqlbdc.

00:13:04.280 --> 00:13:05.615
D'accord.

00:13:05.615 --> 00:13:09.455
Si vous y allez, vous pouvez apprendre
tonnes sur les clusters big data.

00:13:09.455 --> 00:13:10.835
Tout ce qu'il y a à apprendre, n'est-ce pas ?

00:13:10.835 --> 00:13:11.255
Oui, c'est vrai.

00:13:11.255 --> 00:13:12.560
C'est génial. D'accord.

00:13:12.560 --> 00:13:14.210
Donc, fondamentalement, j'ai besoin d'y aller

00:13:14.210 --> 00:13:16.750
et commencer à apprendre et
commencer à télécharger.

00:13:16.750 --> 00:13:18.810
Puis-je l'exporter vers un grand PDF et

00:13:18.810 --> 00:13:21.990
puis le lire dans le
la nuit pour apprendre?

00:13:21.990 --> 00:13:25.095
Oui, c'est vrai. En fait, je pense que
vous pouvez le faire. ouais.

00:13:25.095 --> 00:13:27.120
Ne l'imprimez pas,
bien que. Juste PDF, non?

00:13:27.120 --> 00:13:27.300
Oui, c'est vrai.

00:13:27.300 --> 00:13:29.390
D'accord. cool. Merci beaucoup.

00:13:29.390 --> 00:13:31.295
C'était très utile.
Merci beaucoup pour le partage.

00:13:31.295 --> 00:13:32.030
Merci.

00:13:32.030 --> 00:13:33.950
Merci d'avoir regardé.

00:13:33.950 --> 00:13:35.960
S'il vous plaît comme, abonnez-vous,
et commenter

00:13:35.960 --> 00:13:37.940
la vidé o et j'espère
on se voit la prochaine fois. merci.

00:13:37.940 --> 00:13:52.600
[MUSIQUE]

