WEBVTT

00:00:00.000 --> 00:00:02.070
>> SQL Server velký
datové clustery poskytují

00:00:02.070 --> 00:00:03.960
bezpečnostní mechanismy, aby bylo zajištěno, že

00:00:03.960 --> 00:00:06.150
přístup k datům je vždy zabezpečený.

00:00:06.150 --> 00:00:08.220
Nellie je tu, aby řekla
nám všechno o

00:00:08.220 --> 00:00:10.350
dnes na údajích vystavených.

00:00:10.350 --> 00:00:21.210
HUDBY

00:00:21.210 --> 00:00:24.165
>> Hi a Vítejte v jiném
epizodu exponovaných dat.

00:00:24.165 --> 00:00:27.570
Jsem Jeroen, váš hostitel a
Dnes máme Nellie s

00:00:27.570 --> 00:00:30.990
abychom mluvili o bezpečnosti pro velké
clustery dat. Ahoj, Nellie.

00:00:30.990 --> 00:00:31.860
>> Ahoj, Jeroene.

00:00:31.860 --> 00:00:32.700
>> Jak se máš?

00:00:32.700 --> 00:00:33.750
>> Jsem v pohodě. Dík.

00:00:33.750 --> 00:00:36.930
>> Dobře. Takže bezpečnost
pro velké clustery dat,

00:00:36.930 --> 00:00:38.340
To musí znít důležiti.

00:00:38.340 --> 00:00:41.355
Můžete nám říct, jak to funguje?

00:00:41.355 --> 00:00:44.970
>> Jistě. Takže jestli jsi
seznámeni se serverem SQL Server,

00:00:44.970 --> 00:00:47.735
pravděpodobně víte, že
zabezpečení je vždy

00:00:47.735 --> 00:00:49.820
nejvyšší priorita pro nás

00:00:49.820 --> 00:00:53.540
a to je ta samá věc
s velkými datovými clustery.

00:00:53.540 --> 00:00:56.180
Preferujeme tuto práci

00:00:56.180 --> 00:00:59.015
a Všimněte si, jak důležité
To je pro naše zákazníky.

00:00:59.015 --> 00:01:04.340
Takže zvýrazním některé
dnes věci kolem bezpečnosti.

00:01:04.340 --> 00:01:06.485
Nebudeme
pokrytí všech podrobností,

00:01:06.485 --> 00:01:10.430
ale v podstatě budeme krýt

00:01:10.430 --> 00:01:12.080
na vysoké úrovni, abyste věděli

00:01:12.080 --> 00:01:15.170
možnosti zabezpečení
velkého datového clusteru.

00:01:15.170 --> 00:01:16.220
>> Dobře.

00:01:16.220 --> 00:01:17.870
>> Jak víte, spousta

00:01:17.870 --> 00:01:20.440
naši zákazníci serveru SQL Server
jsou Podnikoví zákazníci,

00:01:20.440 --> 00:01:23.720
velké podniky, které
spustit službu Active Directory.

00:01:23.720 --> 00:01:27.125
Potřebujeme zajistit, aby všechny
vaše aplikace, včetně

00:01:27.125 --> 00:01:29.420
SQL Server a velká data
clustery a všechny

00:01:29.420 --> 00:01:32.525
Tato řešení mohou
dobře integrovat s AD.

00:01:32.525 --> 00:01:33.515
>> Ano.

00:01:33.515 --> 00:01:36.680
>> To je klíč
schopnost, kterou jsme

00:01:36.680 --> 00:01:40.355
povolení ve velkých datových clusterech v 2019

00:01:40.355 --> 00:01:44.060
je skutečně pro
abys mohl

00:01:44.060 --> 00:01:47.945
tak hladce a snadno.

00:01:47.945 --> 00:01:51.425
Teď ti povím, proč
Zdůraznil jsem snadné a

00:01:51.425 --> 00:01:56.150
bezešvé, protože obvykle
máte co do činění s aplikacemi,

00:01:56.150 --> 00:01:58.070
Řekněme jakýkoliv druh přihlášky,

00:01:58.070 --> 00:02:01.220
připojení k aplikaci AD
není to velká dohoda, že?

00:02:01.220 --> 00:02:04.280
Předpokládáme, že aplikace
podporuje integraci služby AD.

00:02:04.280 --> 00:02:04.730
>> Jistě.

00:02:04.730 --> 00:02:07.640
>> Nyní pro velké datové clustery,
To je to samý.

00:02:07.640 --> 00:02:09.185
Mělo by to fungovat.

00:02:09.185 --> 00:02:11.090
Je to jen, že musíme

00:02:11.090 --> 00:02:13.890
zdůraznit, že jsme
běh v plném rozsahu

00:02:13.890 --> 00:02:18.255
kompletně kontejnerizovaná
roztok, kde

00:02:18.255 --> 00:02:20.240
všechny služby jsou spuštěny v

00:02:20.240 --> 00:02:22.160
kontejnery a všechny
podpůrné služby

00:02:22.160 --> 00:02:23.470
jsou spuštěny v kontejnerech,

00:02:23.470 --> 00:02:25.370
a toto je spuštěno
na vrcholu Kubernetes.

00:02:25.370 --> 00:02:25.955
>> Správně.

00:02:25.955 --> 00:02:30.200
>> Takže jsme strávili spoustu práce
při zajištění, že dostanete

00:02:30.200 --> 00:02:33.200
plně automatizovaný a
Bezproblémová zkušenost

00:02:33.200 --> 00:02:37.130
Toto kompletně kontejnerizovaná
velké datové řešení

00:02:37.130 --> 00:02:39.560
na vrcholu Kubernetes.

00:02:39.560 --> 00:02:41.600
>> V podstatě to všechno
běží v kontejneru, takže je

00:02:41.600 --> 00:02:43.820
Proč je integrace zajímavá.

00:02:43.820 --> 00:02:45.170
Co tedy znamená mít

00:02:45.170 --> 00:02:47.360
plně automatizovaný
Integrace? Co dostanu?

00:02:47.360 --> 00:02:50.510
>> Ano. Takže,

00:02:50.510 --> 00:02:52.415
Možná budete potřebovat trochu
bitu pozadí.

00:02:52.415 --> 00:02:52.530
>> Dobře.

00:02:52.530 --> 00:02:55.700
>> Takže když se připojíte k
druh služby pro

00:02:55.700 --> 00:02:58.099
Služba Active Directory nebo protokol Kerberos

00:02:58.099 --> 00:03:00.410
který běží uvnitř
Linuxová nádoba,

00:03:00.410 --> 00:03:03.320
je například
absolutně nemožné.

00:03:03.320 --> 00:03:04.670
Je to jen, že musíš aplikovat

00:03:04.670 --> 00:03:07.655
některé ruční kroky k
to dělat.

00:03:07.655 --> 00:03:10.430
Teď si představte, že máte
řešení se stovkami

00:03:10.430 --> 00:03:14.255
z těchto kontejnerů se stovkami
služeb, které tam běží.

00:03:14.255 --> 00:03:16.580
Chcete-li to provést ručně
očividně by nebylo

00:03:16.580 --> 00:03:19.730
realistické a nechceme
žádat od našich uživatelů.

00:03:19.730 --> 00:03:22.130
Proto je plně automatizován

00:03:22.130 --> 00:03:23.795
Myslím tím, že jsme

00:03:23.795 --> 00:03:25.970
starat se o
složitost.

00:03:25.970 --> 00:03:29.105
Máme službu, která se jmenuje
služby podpory zabezpečení.

00:03:29.105 --> 00:03:30.695
V rámci nasazení

00:03:30.695 --> 00:03:32.090
Tato služba bude trvat

00:03:32.090 --> 00:03:34.430
nějaké informace od vás
jako uživatel, který nasazuje

00:03:34.430 --> 00:03:39.005
cluster a potom služba
bude v podstatě provádět

00:03:39.005 --> 00:03:41.480
všechny tyto kroky pro každý
jedna služba v clusteru

00:03:41.480 --> 00:03:44.045
aby bylo zajištěno, že
všechno je spojené s AD.

00:03:44.045 --> 00:03:46.850
>> Wow, to je působivé.
To je skvělý.

00:03:46.850 --> 00:03:48.890
Takže v podstatě můžu jen nechat

00:03:48.890 --> 00:03:51.410
clusteru jej nakonfigurujte
a je to tady, že?

00:03:51.410 --> 00:03:52.475
>> Ano, přesně.

00:03:52.475 --> 00:03:53.005
>> Cool.

00:03:53.005 --> 00:03:55.145
>> Nyní kromě toho,

00:03:55.145 --> 00:03:58.370
Trávíme také spoustu času, abychom

00:03:58.370 --> 00:04:01.100
Ujistěte se, že
integrované zabezpečení.

00:04:01.100 --> 00:04:04.730
Tím myslím, že například

00:04:04.730 --> 00:04:07.864
Když Míváš
dotaz z Spark na HDFS,

00:04:07.864 --> 00:04:10.060
protože ve velkých údajích
cluster máme jiskru,

00:04:10.060 --> 00:04:12.090
můžete zadávat dotazy na data v HDFS.

00:04:12.090 --> 00:04:15.920
Tyto komponenty již
hrát docela dobře spolu.

00:04:15.920 --> 00:04:19.700
Tyto komponenty jsou tedy
součástí stejného zásobníku,

00:04:19.700 --> 00:04:22.440
můžete říct, že část
Apačský balík.

00:04:23.620 --> 00:04:27.260
Takže je tu spousta funkcí
Můžeme se tam už opřít.

00:04:27.260 --> 00:04:29.780
Ale pokud jde o SQL
Server a SQL Server

00:04:29.780 --> 00:04:32.965
nativně hovořit s
součásti jako HDFS,

00:04:32.965 --> 00:04:35.480
To je ve skutečnosti nová funkčnost

00:04:35.480 --> 00:04:37.250
že nám Představujeme, kde jsme

00:04:37.250 --> 00:04:41.280
mít možnost SQL
Scénáře dotazů na server

00:04:41.280 --> 00:04:43.110
Musím zdůraznit, že kdybych

00:04:43.110 --> 00:04:45.495
předat dotaz SQL
Instance hlavního serveru,

00:04:45.495 --> 00:04:47.540
Jedná se pouze o dotaz SQL.
který se dotazuje

00:04:47.540 --> 00:04:49.970
přes externí tabulku
sedí v HDFS, že?

00:04:49.970 --> 00:04:52.295
Takže když to udělám,

00:04:52.295 --> 00:04:57.020
zajistili jsme, že moje
Identita jako osoba, která

00:04:57.020 --> 00:05:01.070
při vydávání tohoto dotazu jsou toky po celou cestu

00:05:01.070 --> 00:05:03.410
prostřednictvím všech těchto
různé součásti

00:05:03.410 --> 00:05:05.600
na cestě dolů do
HDFS, kde data

00:05:05.600 --> 00:05:10.400
je tak, abychom mohli provést autorizaci
zkontrolovat skutečná data,

00:05:10.400 --> 00:05:12.590
a to mám na mysli
s integrovaným zabezpečením.

00:05:12.590 --> 00:05:14.615
Je integrován prostřednictvím
všechny tyto součásti.

00:05:14.615 --> 00:05:16.760
Bez ohledu na to, kde mohu vydat dotaz,

00:05:16.760 --> 00:05:18.515
z Spark nebo SQL serveru,

00:05:18.515 --> 00:05:20.450
identita uživatele vždy probíhá

00:05:20.450 --> 00:05:22.895
přetékat všemi
cestu ke zdroji.

00:05:22.895 --> 00:05:25.640
>> Dobře. To je velmi působivé
a velmi důležité pro

00:05:25.640 --> 00:05:27.560
všechny organizace pracující s tímto druhem

00:05:27.560 --> 00:05:29.570
věcí, protože chcete
vědět, že data jsou zabezpečena.

00:05:29.570 --> 00:05:31.430
>> Přesně. Chci říct
máte auditování,

00:05:31.430 --> 00:05:33.860
protokoly auditu umožňují
jisti, že jsou aktuální,

00:05:33.860 --> 00:05:36.425
a nechcete, aby služba
účet, který se v nich zobrazí.

00:05:36.425 --> 00:05:37.190
>> Přesně.

00:05:37.190 --> 00:05:40.940
>> Takže je to jeden z klíčových požadavků
také od našich zákazníků.

00:05:40.940 --> 00:05:42.860
Kromě toho

00:05:42.860 --> 00:05:49.340
Máme také integrovaný
zkušenosti ve formě, jak vy,

00:05:49.340 --> 00:05:51.305
například interakce
s clusterem.

00:05:51.305 --> 00:05:53.150
Máme Azure Data
Studio, které můžete

00:05:53.150 --> 00:05:56.370
použít pro připojení k velkému
datový cluster, že?

00:05:56.540 --> 00:05:59.480
Chceme dát
zkušenost s jedním

00:05:59.480 --> 00:06:03.110
přihlášení pro libovolný počet
scénářů.

00:06:03.110 --> 00:06:05.295
Takže když se připojím k
velký datový cluster,

00:06:05.295 --> 00:06:07.345
Skutečně se připojím k
hlavní instanci,

00:06:07.345 --> 00:06:11.030
ale naše nástroje zajistí
že také dostanu přístup k jiskru,

00:06:11.030 --> 00:06:12.590
v HDFS a všechny ostatní

00:06:12.590 --> 00:06:15.010
zajímavé součásti
ve velkém datovém clusteru.

00:06:15.010 --> 00:06:16.895
>> Takže to všechno zvládne
transparentně?

00:06:16.895 --> 00:06:18.185
>> Ano, přesně.

00:06:18.185 --> 00:06:19.250
>> Dobře. Cool.

00:06:19.250 --> 00:06:22.375
>> Ano. Poslední zoufalý pokus

00:06:22.375 --> 00:06:24.650
Máme šifrování a

00:06:24.650 --> 00:06:27.125
šifrování je velmi důležité
pro naše uživatele, že?

00:06:27.125 --> 00:06:27.890
>> Samozřejmě.

00:06:27.890 --> 00:06:30.965
>> Zajistili jsme, že
veškerou komunikaci,

00:06:30.965 --> 00:06:33.950
dokonce interní a
externí komunikace,

00:06:33.950 --> 00:06:39.290
s velkým datovým clusterem
je zašifrován protokol SSL nebo TLS.

00:06:39.290 --> 00:06:41.285
Kromě toho

00:06:41.285 --> 00:06:43.325
můžete samozřejmě využít

00:06:43.325 --> 00:06:45.635
mnoho různých
funkce šifrování

00:06:45.635 --> 00:06:48.470
SQL Server, který je
a všechny, které jsou

00:06:48.470 --> 00:06:49.985
podporováno na serveru SQL Server na platformě Linux

00:06:49.985 --> 00:06:52.430
protože jsme běžní
Linuxové kontejnery.

00:06:52.430 --> 00:06:57.485
Pracujeme také na rozšiřování
Tyto možnosti a přidat

00:06:57.485 --> 00:07:00.710
Šifrování HDFS brzy
Takže máme také

00:07:00.710 --> 00:07:04.745
Tyto možnosti pro data
To je ohrožené.

00:07:04.745 --> 00:07:07.920
>> Dobře. Cool. Takže můžete

00:07:07.920 --> 00:07:09.410
Vysvětlete nám trochu
trochu víc o tom, jak

00:07:09.410 --> 00:07:11.570
funguje v rámci protokolu Kerberos?

00:07:11.570 --> 00:07:16.070
>> Absolutně. Tak pojďme
zaměření na ověřování

00:07:16.070 --> 00:07:18.770
nejdříve proto, že je
důležité, abyste

00:07:18.770 --> 00:07:20.485
vědět, jaký je rozdíl nebo

00:07:20.485 --> 00:07:22.785
vstupní body jsou
do clusteru, že?

00:07:22.785 --> 00:07:26.360
Zde vidíte pět
různé koncové body

00:07:26.360 --> 00:07:28.490
nebo vstupní body clusteru.

00:07:28.490 --> 00:07:30.485
Teď máme tenhle Kubernetes cluster,

00:07:30.485 --> 00:07:32.660
Proto musíme především

00:07:32.660 --> 00:07:35.360
odhalit určité koncové body, které uživatelé

00:07:35.360 --> 00:07:37.430
nebo klientské nástroje nebo
všechny aplikace mohou

00:07:37.430 --> 00:07:40.865
v clusteru interaktivně pracovat.

00:07:40.865 --> 00:07:44.475
Takže když začneme s řadičem,

00:07:44.475 --> 00:07:46.685
Jak byste mohli být obeznámeni s

00:07:46.685 --> 00:07:48.860
Controller je
mozku clusteru.

00:07:48.860 --> 00:07:52.715
Řadič je ten, který
sleduje všechno,

00:07:52.715 --> 00:07:54.229
který implementuje cluster,

00:07:54.229 --> 00:07:55.775
a všechny tyhle věci.

00:07:55.775 --> 00:07:58.580
Nyní dosáhnete
koncové body řadiče,

00:07:58.580 --> 00:08:02.500
Zde můžete vidět, že hlavní
metodu, kterou byste mohli interaktivně používat

00:08:02.500 --> 00:08:04.885
s ním by bylo
prostřednictvím rozhraní azdata CLI

00:08:04.885 --> 00:08:06.850
ale také skrze naše nástroje.

00:08:06.850 --> 00:08:11.860
Je to především koncový bod, který
použije správce,

00:08:11.860 --> 00:08:14.005
Chcete-li například interaktivně pracovat
s clusterem.

00:08:14.005 --> 00:08:16.180
Ale kontrolor má také magické schopnosti.

00:08:16.180 --> 00:08:20.470
Můžete říci, že ovladač může řadit
dosahu na jiné koncové body.

00:08:20.470 --> 00:08:23.890
Můžete se například přihlásit k

00:08:23.890 --> 00:08:27.485
řadičem prostřednictvím azdata a z

00:08:27.485 --> 00:08:29.920
Zde se vydávají příkazy, které budou

00:08:29.920 --> 00:08:32.710
vzít vás do hlavního serveru SQL Server
instanci a spustíte pouze spuštění

00:08:32.710 --> 00:08:35.380
T-SQL nebo můžete spustit příkazy HDFS

00:08:35.380 --> 00:08:38.665
přímo v prostředí HDFS
v tomto druhu věcí.

00:08:38.665 --> 00:08:42.470
Tento koncový bod tedy umožňuje
mezi jinými věcmi.

00:08:42.470 --> 00:08:43.275
>> Dobře. Moc dobrý.

00:08:43.275 --> 00:08:45.830
>> Ano. Dále se jedná o koncový bod, který jste

00:08:45.830 --> 00:08:47.690
mohl slyšet, pokud jste

00:08:47.690 --> 00:08:49.860
použití velkých datových clusterů
je brána.

00:08:49.860 --> 00:08:52.055
Nyní je brána
Vlastně to samý.

00:08:52.055 --> 00:08:53.885
Podrobnosti o implementaci tohoto

00:08:53.885 --> 00:08:56.735
je to, že to je Apači Knox Gateway.

00:08:56.735 --> 00:08:59.900
Toto je brána, která obvykle
chrání, můžete říct,

00:08:59.900 --> 00:09:06.210
komponenty Apache, například
v podstatě na straně Hadoop.

00:09:06.210 --> 00:09:06.510
>> Správně.

00:09:06.510 --> 00:09:07.980
>> Takže máme jiskru, Livy,

00:09:07.980 --> 00:09:11.999
PŘÍZE, pokud se chcete připojit
do HDFS prostřednictvím webových hbp,

00:09:11.999 --> 00:09:13.705
Toto je koncový bod, který používáte,

00:09:13.705 --> 00:09:17.165
a také z Azure Data Studio.

00:09:17.165 --> 00:09:19.160
Takže je dobré vědět, kdy

00:09:19.160 --> 00:09:21.505
Mluvíme tu o
bránu, co tam myslíme.

00:09:21.505 --> 00:09:23.990
Pak máme
Server proxy pro správu, který

00:09:23.990 --> 00:09:28.070
je brána k metrice
a protokolovací nástroje,

00:09:28.070 --> 00:09:31.490
a pak jsme očividně
Instance hlavního serveru SQL Server.

00:09:31.490 --> 00:09:33.830
Je to jen SQL. Je to jen
koncový bod TDS, na kterém

00:09:33.830 --> 00:09:37.025
připojit z libovolného nástroje
, o kterém jste obeznámeni.

00:09:37.025 --> 00:09:39.200
Proxy aplikace, poslední
ale ne nejméně,

00:09:39.200 --> 00:09:41.780
což je způsob, jak můžete

00:09:41.780 --> 00:09:43.310
přístup k aplikacím, které

00:09:43.310 --> 00:09:45.290
nasazené uvnitř
velký datový cluster.

00:09:45.290 --> 00:09:47.820
A teď všechny ty různé
koncových bodů, pokud jsou spuštěny,

00:09:47.820 --> 00:09:49.305
například v zabezpečeném režimu

00:09:49.305 --> 00:09:50.760
Pokud je cluster
spuštěn v zabezpečeném režimu,

00:09:50.760 --> 00:09:53.175
Chci říct integrační režim,

00:09:53.175 --> 00:09:58.210
všechny tyto koncové body jsou
povolení ověřování AD.

00:09:58.210 --> 00:10:00.200
Tak to jsem chtěl
zde zvýraznit.

00:10:00.200 --> 00:10:02.510
Takže, když mluvíme
o ověřování reklam,

00:10:02.510 --> 00:10:06.740
je to úplná integrace s
AD pro všechny koncové body.

00:10:06.740 --> 00:10:08.645
>> Správně. Před jedním z
pět koncových bodů v rámci hrací desky.

00:10:08.645 --> 00:10:09.335
>> Přesně.

00:10:09.335 --> 00:10:11.490
>> Wow. OK.

00:10:12.740 --> 00:10:16.590
>> Ano. To je ověření
v podstatě pro tebe.

00:10:16.590 --> 00:10:19.755
Při stěhování jsme také
mít autorizaci.

00:10:19.755 --> 00:10:21.290
Je velmi důležité chránit

00:10:21.290 --> 00:10:23.780
data, jakmile je
uvnitř clusteru

00:10:23.780 --> 00:10:26.720
Jakmile se skutečně podaří
přihlásit a ověřit.

00:10:26.720 --> 00:10:30.675
Ano. Takže klíčové části, které jsem
chtěl zde zvýraznit,

00:10:30.675 --> 00:10:31.920
a to je stále ještě vysoká úroveň.

00:10:31.920 --> 00:10:33.485
Jsem si jistá, že budeme mít

00:10:33.485 --> 00:10:35.660
Další rozhovory o
Podrobnosti o těchto věcech.

00:10:35.660 --> 00:10:37.335
Ale na vysoké úrovni,

00:10:37.335 --> 00:10:38.510
Existují dvě úrovně

00:10:38.510 --> 00:10:42.050
kontroly autorizace, které jste
ve velkých datových clusterech.

00:10:42.050 --> 00:10:44.750
Pokud začneme s SQL
Server, například

00:10:44.750 --> 00:10:48.050
Pokud vystavuji dotaz serveru SQL Server,

00:10:48.050 --> 00:10:50.420
Zaprvé, existují
kontroly autorizace

00:10:50.420 --> 00:10:52.100
na objektech serveru SQL Server.

00:10:52.100 --> 00:10:54.920
Potřebuji mít přístup k
tabulky, které chci vyhledat

00:10:54.920 --> 00:10:58.730
Například, abychom mohli vytvořit
jisti, že mohu získat přístup k datům.

00:10:58.730 --> 00:11:00.860
>> Ale to je to samý
kontroly autorizace

00:11:00.860 --> 00:11:02.330
jako v předchozích
verzemi se SQL?

00:11:02.330 --> 00:11:02.780
>> Ano, je to SQL.

00:11:02.780 --> 00:11:03.530
>> To se nezměnilo?

00:11:03.530 --> 00:11:04.280
>> Toto je pouze SQL.

00:11:04.280 --> 00:11:04.610
>> Dobře.

00:11:04.610 --> 00:11:07.160
>> V podstatě
model oprávnění

00:11:07.160 --> 00:11:08.945
SQL Server je stejný

00:11:08.945 --> 00:11:11.285
jestli běží ve velkém
v datovém clusteru nebo kdekoli jinde.

00:11:11.285 --> 00:11:13.490
Takže stále můžete udělovat oprávnění k

00:11:13.490 --> 00:11:16.950
konkrétní tabulky a specifické
objekty na serveru SQL Server, správně?

00:11:16.950 --> 00:11:17.915
>> Dobře.

00:11:17.915 --> 00:11:19.945
>> Ale kromě toho,

00:11:19.945 --> 00:11:21.845
Teď se podíváme na scénář, až budu

00:11:21.845 --> 00:11:23.990
vystavení dotazu proti datům, která jsou

00:11:23.990 --> 00:11:26.060
sezení v HDFS a dotazy

00:11:26.060 --> 00:11:28.715
externí tabulku přes
V tomto případě HDFS.

00:11:28.715 --> 00:11:31.790
Nejen to, že potřebuji
přístup k této tabulce,

00:11:31.790 --> 00:11:34.025
do databáze, ve které
Tato tabulka je umístěna

00:11:34.025 --> 00:11:36.320
Také potřebuji mít přístup k

00:11:36.320 --> 00:11:39.905
skutečných souborů a dat
To sedí v HDFS.

00:11:39.905 --> 00:11:40.145
>> Jistě.

00:11:40.145 --> 00:11:43.430
>> To je to, co jsem měl na mysli
kontroly autorizace na dvou úrovních.

00:11:43.430 --> 00:11:45.035
Takže v tomto případě je tu šek

00:11:45.035 --> 00:11:48.620
SQL Server a existuje
Další kontrola v HDFS.

00:11:48.620 --> 00:11:48.920
>> Dobře.

00:11:48.920 --> 00:11:50.510
>> Na straně s jiskrou

00:11:50.510 --> 00:11:53.660
v podstatě jiskra
dotazy budou proudit a

00:11:53.660 --> 00:11:56.000
kontrola autorizace hbp bude

00:11:56.000 --> 00:11:58.505
Ujistěte se, že
jsou poctěna oprávnění.

00:11:58.505 --> 00:12:00.200
>> Dobře. Takže s tímhle vším,

00:12:00.200 --> 00:12:01.820
Můžu si být jistý, že

00:12:01.820 --> 00:12:04.370
původního uživatele
identita je předána prostřednictvím

00:12:04.370 --> 00:12:06.590
SQL Server kamkoli
data jsou, že?

00:12:06.590 --> 00:12:09.455
HDFS, nebo k němu mám přístup, správně?

00:12:09.455 --> 00:12:15.390
>> Přesně. Ano. Tak jak jsme
tak nějak se dotkla,

00:12:15.390 --> 00:12:18.825
budeme mít tuto prodanou identitu

00:12:18.825 --> 00:12:22.670
což znamená, že původní
bude proudit identita uživatele

00:12:22.670 --> 00:12:26.810
celou cestu až k
data, abychom mohli skutečně

00:12:26.810 --> 00:12:27.980
ověřit celou cestu

00:12:27.980 --> 00:12:31.730
Toto je uživatel, který
chtěli získat přístup k datům.

00:12:31.730 --> 00:12:32.800
>> Dobře.

00:12:32.800 --> 00:12:38.820
>> Ano. Aby
v podstatě je souhrnem

00:12:38.820 --> 00:12:41.390
na vysoké úrovni zabezpečení
možnosti v okolí

00:12:41.390 --> 00:12:44.780
integrace AD specificky
pro velké datové clustery.

00:12:44.780 --> 00:12:47.710
>> Tak kde mohu zjistit
víc, když se chci potápět hlouběji?

00:12:47.710 --> 00:12:50.420
>> Ano. Takže když

00:12:50.420 --> 00:12:52.580
Chcete získat další informace o
velké datové clustery obecně

00:12:52.580 --> 00:12:56.495
a máme bezpečnostní dokumenty

00:12:56.495 --> 00:12:59.675
pokrývající podrobnosti o tom, co
Dnes jsem to vysvětlil,

00:12:59.675 --> 00:13:04.280
měli byste jít na tuto
krátký odkaz: aka.ms/sqlbdc.

00:13:04.280 --> 00:13:05.615
>> Dobře.

00:13:05.615 --> 00:13:09.455
>> Když tam půjdeš, můžeš se naučit
tun o velkých datových clusterech.

00:13:09.455 --> 00:13:10.835
>> Všechno, co se má naučit, ne?

00:13:10.835 --> 00:13:11.255
>> Ano.

00:13:11.255 --> 00:13:12.560
>> Super. Tak dobře.

00:13:12.560 --> 00:13:14.210
Takže v podstatě tam musím jít

00:13:14.210 --> 00:13:16.750
a začněte se učit a
spuštění stahování.

00:13:16.750 --> 00:13:18.810
Lze jej exportovat do velkého PDF a

00:13:18.810 --> 00:13:21.990
Přečtěte si jej v
noc, abych se učil?

00:13:21.990 --> 00:13:25.095
>> Ano. Vlastně, myslím
to můžeš udělat. Ano.

00:13:25.095 --> 00:13:27.120
>> Netisknout,
I když. Jen PDF, správně?

00:13:27.120 --> 00:13:27.300
>> Ano.

00:13:27.300 --> 00:13:29.390
>> Dobře. Cool. Tak díky moc.

00:13:29.390 --> 00:13:31.295
To bylo velmi užitečné.
Díky moc za sdílení.

00:13:31.295 --> 00:13:32.030
>> Děkuji.

00:13:32.030 --> 00:13:33.950
>> Děkuji za sledování.

00:13:33.950 --> 00:13:35.960
Přihlaste se, prosím,
a komentář k

00:13:35.960 --> 00:13:37.940
video a doufám, že
Uvidíme se příště. Dík.

00:13:37.940 --> 00:13:52.600
HUDBY