WEBVTT

00:00:00.000 --> 00:00:02.070
Сервер S'L большой
кластеры данных обеспечивают

00:00:02.070 --> 00:00:03.960
механизмы безопасности, чтобы убедиться,

00:00:03.960 --> 00:00:06.150
доступ к данным всегда безопасен.

00:00:06.150 --> 00:00:08.220
Нелли здесь, чтобы сказать
нам все о

00:00:08.220 --> 00:00:10.350
оно сегодня на данных подвергшся действию.

00:00:10.350 --> 00:00:21.210
(МУЗЫКА)

00:00:21.210 --> 00:00:24.165
Привет и добро пожаловать в другой
эпизод данных разоблачены.

00:00:24.165 --> 00:00:27.570
Я Джерун ваш хозяин и
у нас есть Нелли сегодня с

00:00:27.570 --> 00:00:30.990
нам говорить о безопасности для больших
кластеры данных. Привет, Нелли.

00:00:30.990 --> 00:00:31.860
Привет, Джеруан.

00:00:31.860 --> 00:00:32.700
Как ты?

00:00:32.700 --> 00:00:33.750
Я в порядке. Спасибо.

00:00:33.750 --> 00:00:36.930
Хорошо, хорошо. Таким образом, безопасность
для кластеров больших данных,

00:00:36.930 --> 00:00:38.340
, которые должны звучать важно.

00:00:38.340 --> 00:00:41.355
Так вы можете рассказать нам, как это работает?

00:00:41.355 --> 00:00:44.970
Конечно же. Так что если вы
знакомысив сервера S'L,

00:00:44.970 --> 00:00:47.735
Вы, наверное, знаете, что
безопасность всегда

00:00:47.735 --> 00:00:49.820
является главным приоритетом для нас

00:00:49.820 --> 00:00:53.540
и это одно и то же
с кластерами больших данных.

00:00:53.540 --> 00:00:56.180
Мы отоделим приоритеты этой работы

00:00:56.180 --> 00:00:59.015
и отметить, насколько важно
это для наших клиентов.

00:00:59.015 --> 00:01:04.340
Так что я собираюсь выделить некоторые
вещи вокруг безопасности сегодня.

00:01:04.340 --> 00:01:06.485
Мы не собираемся
покрыть все детали,

00:01:06.485 --> 00:01:10.430
но мы в основном собираемся для покрытия

00:01:10.430 --> 00:01:12.080
на высоком уровне, так что вы знаете,

00:01:12.080 --> 00:01:15.170
возможности безопасности
кластера больших данных.

00:01:15.170 --> 00:01:16.220
Хорошо, хорошо.

00:01:16.220 --> 00:01:17.870
Как вы знаете, многие

00:01:17.870 --> 00:01:20.440
наши клиенты сервера S'L
являются корпоративными клиентами,

00:01:20.440 --> 00:01:23.720
крупных предприятий, которые
запустить Active Directory.

00:01:23.720 --> 00:01:27.125
Мы должны убедиться, что все
ваши приложения, включая

00:01:27.125 --> 00:01:29.420
Сервер и большие данные
кластеров и всех

00:01:29.420 --> 00:01:32.525
эти решения могут
хорошо интегрироваться с AD.

00:01:32.525 --> 00:01:33.515
Да, да.

00:01:33.515 --> 00:01:36.680
Это ключ к
возможность, что мы

00:01:36.680 --> 00:01:40.355
включение в кластеры больших данных в 2019 году

00:01:40.355 --> 00:01:44.060
заключается в том, чтобы на самом деле для
Вы, чтобы быть в состоянии сделать

00:01:44.060 --> 00:01:47.945
это в бесшовной и простой способ.

00:01:47.945 --> 00:01:51.425
Теперь я скажу вам, почему
Я подчеркнул легко и

00:01:51.425 --> 00:01:56.150
плавные, потому что обычно, когда
вы имеете дело с приложениями,

00:01:56.150 --> 00:01:58.070
допустимые виды приложений,

00:01:58.070 --> 00:02:01.220
присоединение к aD
это не большое дело, не так ли?

00:02:01.220 --> 00:02:04.280
Мы просто предполагаем, что любое приложение
поддерживает интеграцию АД.

00:02:04.280 --> 00:02:04.730
Конечно же.

00:02:04.730 --> 00:02:07.640
Теперь для кластеров больших данных,
это одно и то же.

00:02:07.640 --> 00:02:09.185
Он должен просто работать.

00:02:09.185 --> 00:02:11.090
Это просто, что мы должны

00:02:11.090 --> 00:02:13.890
подчеркнуть, что мы
работает в полностью своего рода

00:02:13.890 --> 00:02:18.255
полностью контейнеризованы
Решение здесь, где

00:02:18.255 --> 00:02:20.240
все службы работают в

00:02:20.240 --> 00:02:22.160
контейнеры и все
вспомогательные услуги

00:02:22.160 --> 00:02:23.470
работают в контейнерах,

00:02:23.470 --> 00:02:25.370
и это работает
на вершине Кубернета.

00:02:25.370 --> 00:02:25.955
В-право.

00:02:25.955 --> 00:02:30.200
Так что мы потратили много работы
на убедившись, что вы получите

00:02:30.200 --> 00:02:33.200
полностью автоматизированной и
бесшовный опыт

00:02:33.200 --> 00:02:37.130
это полностью контейнерной
решение для больших данных

00:02:37.130 --> 00:02:39.560
на вершине Кубернета.

00:02:39.560 --> 00:02:41.600
Так что в основном, это все
работает в контейнере, так что это

00:02:41.600 --> 00:02:43.820
почему интеграция интересна.

00:02:43.820 --> 00:02:45.170
Так что же значит иметь

00:02:45.170 --> 00:02:47.360
полностью автоматизированный
Интеграции? Что я получу?

00:02:47.360 --> 00:02:50.510
Да, да. Так что для этого,

00:02:50.510 --> 00:02:52.415
Вам может понадобиться немного
немного фона.

00:02:52.415 --> 00:02:52.530
Хорошо, хорошо.

00:02:52.530 --> 00:02:55.700
Поэтому, когда вы присоединяетесь
своего рода услуга

00:02:55.700 --> 00:02:58.099
Активный каталог или Керберос

00:02:58.099 --> 00:03:00.410
который работает внутри
Linux контейнер,

00:03:00.410 --> 00:03:03.320
например, это
абсолютно возможно.

00:03:03.320 --> 00:03:04.670
Это просто, что вы должны применить

00:03:04.670 --> 00:03:07.655
некоторые ручные шаги, чтобы
получить, что на работу.

00:03:07.655 --> 00:03:10.430
Теперь представьте, что у вас есть
решение с сотнями

00:03:10.430 --> 00:03:14.255
из этих контейнеров с сотнями
услуг, работающих там.

00:03:14.255 --> 00:03:16.580
Для этого вручную
очевидно, не будет

00:03:16.580 --> 00:03:19.730
реалистичным, и мы не хотим
спросить, что от наших пользователей.

00:03:19.730 --> 00:03:22.130
Таким образом, полностью автоматизированы,

00:03:22.130 --> 00:03:23.795
Я в основном означает, что мы

00:03:23.795 --> 00:03:25.970
заботиться о
сложности для вас.

00:03:25.970 --> 00:03:29.105
У нас есть сервис, который называется
службы поддержки безопасности.

00:03:29.105 --> 00:03:30.695
Таким образом, в рамках развертывания,

00:03:30.695 --> 00:03:32.090
что услуга собирается принять

00:03:32.090 --> 00:03:34.430
некоторую информацию от вас
как пользователь, который развертывает

00:03:34.430 --> 00:03:39.005
кластера, а затем службы
собирается в основном выполнять

00:03:39.005 --> 00:03:41.480
все эти шаги для каждого
единая услуга в кластере

00:03:41.480 --> 00:03:44.045
чтобы убедиться, что
все AD присоединился.

00:03:44.045 --> 00:03:46.850
Вау, это впечатляет.
Это очень круто.

00:03:46.850 --> 00:03:48.890
Так что в основном, я могу просто позволить

00:03:48.890 --> 00:03:51.410
кластера настроить его
и там мы идем, не так ли?

00:03:51.410 --> 00:03:52.475
Да, точно.

00:03:52.475 --> 00:03:53.005
Прохладный.

00:03:53.005 --> 00:03:55.145
В дополнение к этому,

00:03:55.145 --> 00:03:58.370
мы также тратим много времени, чтобы

00:03:58.370 --> 00:04:01.100
убедитесь, что мы получаем
интегрированный опыт обеспечения безопасности.

00:04:01.100 --> 00:04:04.730
Под этим я подразумеваю, что, например,

00:04:04.730 --> 00:04:07.864
когда вы проходите
запрос от Spark до HDFS,

00:04:07.864 --> 00:04:10.060
потому что в больших данных
кластера у нас есть Искра,

00:04:10.060 --> 00:04:12.090
вы можете загонять данные в HDFS.

00:04:12.090 --> 00:04:15.920
Эти компоненты уже
играть очень хорошо вместе.

00:04:15.920 --> 00:04:19.700
Таким образом, эти компоненты
часть одного стека,

00:04:19.700 --> 00:04:22.440
Вы можете сказать, часть
стек Apache.

00:04:23.620 --> 00:04:27.260
Так что есть много функциональности
мы уже можем использовать там.

00:04:27.260 --> 00:04:29.780
Но когда дело доходит до S'L
Сервер и сервер S'L

00:04:29.780 --> 00:04:32.965
родной говорить с
компонент, как HDFS,

00:04:32.965 --> 00:04:35.480
это на самом деле новая функциональность

00:04:35.480 --> 00:04:37.250
что мы представляем, где мы

00:04:37.250 --> 00:04:41.280
иметь возможность для S'L
Сценарии запроса сервера,

00:04:41.280 --> 00:04:43.110
Я должен подчеркнуть, что если я

00:04:43.110 --> 00:04:45.495
передать запрос в S'L
Пример мастера сервера,

00:04:45.495 --> 00:04:47.540
это всего лишь запрос на S'L
то есть запрос

00:04:47.540 --> 00:04:49.970
за внешней таблицей
сидя в HDFS, не так ли?

00:04:49.970 --> 00:04:52.295
Поэтому, когда я делаю это,

00:04:52.295 --> 00:04:57.020
мы уверены, что мой
личность как человека, который

00:04:57.020 --> 00:05:01.070
выдача этого запроса течет всю дорогу

00:05:01.070 --> 00:05:03.410
через все эти
различные компоненты

00:05:03.410 --> 00:05:05.600
на пути вниз к
HDFS, где данные

00:05:05.600 --> 00:05:10.400
так, что мы можем сделать авторизацию
проверить фактические данные,

00:05:10.400 --> 00:05:12.590
и это то, что я имею в виду
с интегрированной безопасностью.

00:05:12.590 --> 00:05:14.615
Она интегрирована через
все эти компоненты.

00:05:14.615 --> 00:05:16.760
Поэтому независимо от того, где я выдаю запрос,

00:05:16.760 --> 00:05:18.515
от Spark или сервера S'L,

00:05:18.515 --> 00:05:20.450
личность пользователя всегда происходит

00:05:20.450 --> 00:05:22.895
протекать через все
путь к источнику.

00:05:22.895 --> 00:05:25.640
Хорошо, хорошо. Это очень впечатляет
и очень важно, чтобы

00:05:25.640 --> 00:05:27.560
любое предприятие, работая с такого рода

00:05:27.560 --> 00:05:29.570
вещей, потому что вы хотите
знаю, что ваши данные безопасны.

00:05:29.570 --> 00:05:31.430
Точно. Я имею в виду
у вас есть аудит,

00:05:31.430 --> 00:05:33.860
у вас есть журналы аудита, чтобы сделать
уверены, что они актуальны,

00:05:33.860 --> 00:05:36.425
и вы не хотите некоторое обслуживание
учетная запись, чтобы показать в них.

00:05:36.425 --> 00:05:37.190
Точно.

00:05:37.190 --> 00:05:40.940
Так что это одно из ключевых требований
от наших клиентов, а также.

00:05:40.940 --> 00:05:42.860
В дополнение к этому,

00:05:42.860 --> 00:05:49.340
у нас также есть интегрированные
опыт в формах, как вы,

00:05:49.340 --> 00:05:51.305
например, взаимодействовать
с кластером.

00:05:51.305 --> 00:05:53.150
У нас есть данные Azure
Студия, что вы можете

00:05:53.150 --> 00:05:56.370
использовать для подключения к большим
кластерданных, не так ли?

00:05:56.540 --> 00:05:59.480
Мы хотим дать
опыт одного

00:05:59.480 --> 00:06:03.110
войти в систему для как можно больше
сценарии, насколько это возможно.

00:06:03.110 --> 00:06:05.295
Поэтому, когда я подключаюсь к
кластер больших данных,

00:06:05.295 --> 00:06:07.345
Я на самом деле подключиться к
мастер-инстанции,

00:06:07.345 --> 00:06:11.030
но наши инструменты будут убедиться,
что я также получить доступ к Spark,

00:06:11.030 --> 00:06:12.590
в HDFS, и все эти другие

00:06:12.590 --> 00:06:15.010
компоненты, которые интересны
в кластере больших данных.

00:06:15.010 --> 00:06:16.895
Так что все обрабатывается
прозрачно для меня?

00:06:16.895 --> 00:06:18.185
Да, точно.

00:06:18.185 --> 00:06:19.250
Хорошо, хорошо. Классно.

00:06:19.250 --> 00:06:22.375
Да, да. И последнее, но не менее последнее,

00:06:22.375 --> 00:06:24.650
у нас есть шифрование и

00:06:24.650 --> 00:06:27.125
шифрование очень важно
для наших пользователей, не так ли?

00:06:27.125 --> 00:06:27.890
Конечно же.

00:06:27.890 --> 00:06:30.965
Мы позаботились о том, чтобы
все связи,

00:06:30.965 --> 00:06:33.950
даже внутренние и
внешней связи,

00:06:33.950 --> 00:06:39.290
с кластером больших данных
sSL или TLS зашифрованы.

00:06:39.290 --> 00:06:41.285
В дополнение к этому,

00:06:41.285 --> 00:06:43.325
Вы можете, конечно, рычаги

00:06:43.325 --> 00:06:45.635
много различных
функции шифрования

00:06:45.635 --> 00:06:48.470
Сервер СЗЛ, который у нас есть
и все они, которые

00:06:48.470 --> 00:06:49.985
поддерживается на сервере S'L на Linux

00:06:49.985 --> 00:06:52.430
потому что мы бежим на
Linux контейнеры здесь.

00:06:52.430 --> 00:06:57.485
Мы также работаем над расширением
эти возможности и добавить

00:06:57.485 --> 00:07:00.710
HDFS шифрование в ближайшее время
так что у нас также есть

00:07:00.710 --> 00:07:04.745
эти возможности для данных
это зашифровано в опасности.

00:07:04.745 --> 00:07:07.920
Хорошо, хорошо. Классно. Так что вы можете

00:07:07.920 --> 00:07:09.410
объяснить нам немного
немного больше о том, как

00:07:09.410 --> 00:07:11.570
это работает под Kerberos?

00:07:11.570 --> 00:07:16.070
Абсолютно. Так что давайте
сосредоточиться на аутентификации

00:07:16.070 --> 00:07:18.770
во-первых, потому что это
важно для вас, чтобы

00:07:18.770 --> 00:07:20.485
знать, какая разница или

00:07:20.485 --> 00:07:22.785
точки входа есть
в кластер, не так ли?

00:07:22.785 --> 00:07:26.360
Здесь вы видите пять
различные конечные точки

00:07:26.360 --> 00:07:28.490
или точки входа в кластер.

00:07:28.490 --> 00:07:30.485
Теперь у нас есть этот кластер Кубернете,

00:07:30.485 --> 00:07:32.660
так что мы должны в основном конкретно

00:07:32.660 --> 00:07:35.360
выставляют определенные конечные точки, которые пользователи

00:07:35.360 --> 00:07:37.430
или клиентские инструменты или
любые приложения могут

00:07:37.430 --> 00:07:40.865
взаимодействовать с в кластере.

00:07:40.865 --> 00:07:44.475
Так что, если мы начнем с контроллера,

00:07:44.475 --> 00:07:46.685
как вы могли бы быть знакомы с,

00:07:46.685 --> 00:07:48.860
контроллер является
мозга кластера.

00:07:48.860 --> 00:07:52.715
Контроллер является тот, который
отслеживает все,

00:07:52.715 --> 00:07:54.229
что развертывает кластер,

00:07:54.229 --> 00:07:55.775
и все эти вещи.

00:07:55.775 --> 00:07:58.580
Теперь, чтобы достичь
конечные точки контроллера,

00:07:58.580 --> 00:08:02.500
Вы можете видеть здесь, что основной
метод, который вы бы взаимодействовать

00:08:02.500 --> 00:08:04.885
с ним будет
через azdata CLI

00:08:04.885 --> 00:08:06.850
но и через наши инструменты.

00:08:06.850 --> 00:08:11.860
Это главным образом конечная точка, что
администратор будет использовать,

00:08:11.860 --> 00:08:14.005
например, для взаимодействия
с кластером.

00:08:14.005 --> 00:08:16.180
Но контроллер также обладает магическими способностями.

00:08:16.180 --> 00:08:20.470
Можно сказать, контроллер может сортировать
охвата к другим конечным точкам.

00:08:20.470 --> 00:08:23.890
Так, например, вы можете войти в

00:08:23.890 --> 00:08:27.485
через азданные и от

00:08:27.485 --> 00:08:29.920
там вопрос команды, которые будут

00:08:29.920 --> 00:08:32.710
отвезти вас к мастеру сервера S'L
экземпляр, и вы просто начать работать

00:08:32.710 --> 00:08:35.380
Т-СЗЛ или вы можете запускать команды HDFS

00:08:35.380 --> 00:08:38.665
непосредственно в оболочке HDFS
в такого рода вещах.

00:08:38.665 --> 00:08:42.470
Так вот что эта конечная точка позволяет
вы делаете среди прочего.

00:08:42.470 --> 00:08:43.275
Хорошо, хорошо. Очень круто.

00:08:43.275 --> 00:08:45.830
Да, да. Далее, конечная точка, что вы

00:08:45.830 --> 00:08:47.690
возможно, слышали о том, если вы

00:08:47.690 --> 00:08:49.860
использовали кластеры больших данных
является шлюзом.

00:08:49.860 --> 00:08:52.055
Теперь, шлюз
на самом деле то же самое.

00:08:52.055 --> 00:08:53.885
Деталь реализации, лежащая в основе этого

00:08:53.885 --> 00:08:56.735
является то, что это Apache Нокс Gateway.

00:08:56.735 --> 00:08:59.900
Это шлюз, который обычно
защищает, можно сказать,

00:08:59.900 --> 00:09:06.210
компоненты Apache, такие как
в основном на стороне Хадооп.

00:09:06.210 --> 00:09:06.510
В-право.

00:09:06.510 --> 00:09:07.980
Итак, у нас есть Искра, Ливи,

00:09:07.980 --> 00:09:11.999
YARN, если вы хотите подключиться
hdFS через веб-HDFS,

00:09:11.999 --> 00:09:13.705
это конечная точка, которую вы используете,

00:09:13.705 --> 00:09:17.165
а также из студии данных Azure.

00:09:17.165 --> 00:09:19.160
Так что это хорошо знать, когда

00:09:19.160 --> 00:09:21.505
мы говорим о
шлюз, что мы имеем в виду там.

00:09:21.505 --> 00:09:23.990
Тогда у нас есть
управление прокси, который

00:09:23.990 --> 00:09:28.070
является шлюзом к метрикам
и лесозаготовительные инструменты,

00:09:28.070 --> 00:09:31.490
и тогда у нас есть, очевидно,
Мастер-экземпляр сервера S'L.

00:09:31.490 --> 00:09:33.830
Это просто СЗЛ. Это просто
конечная точка TDS, где вы

00:09:33.830 --> 00:09:37.025
подключиться к любым инструментам
что вы знакомы с.

00:09:37.025 --> 00:09:39.200
Прокси-приложение, последний
но не в последнюю очередь,

00:09:39.200 --> 00:09:41.780
который является способом, которым вы можете

00:09:41.780 --> 00:09:43.310
доступ к приложениям, которые

00:09:43.310 --> 00:09:45.290
Вы развернуты внутри
кластер аготек больших данных.

00:09:45.290 --> 00:09:47.820
Теперь, все эти разные
конечных точек, когда вы работаете,

00:09:47.820 --> 00:09:49.305
например, в безопасном режиме

00:09:49.305 --> 00:09:50.760
когда кластер
работает в безопасном режиме,

00:09:50.760 --> 00:09:53.175
Я имею в виду режим интеграции Ад,

00:09:53.175 --> 00:09:58.210
все эти конечные точки
разрешение аутентификации АД.

00:09:58.210 --> 00:10:00.200
Так вот что я хотел
чтобы выделить здесь.

00:10:00.200 --> 00:10:02.510
Поэтому, когда мы говорим
о аутентификации АД,

00:10:02.510 --> 00:10:06.740
это полная интеграция с
Н.Е. для всех конечных точек.

00:10:06.740 --> 00:10:08.645
В-право. Перед одним из
пять конечных точек по всем направлениям.

00:10:08.645 --> 00:10:09.335
Точно.

00:10:09.335 --> 00:10:11.490
Вау. Хорошо.

00:10:12.740 --> 00:10:16.590
Да, да. Так что это аутентификация
в основном для вас.

00:10:16.590 --> 00:10:19.755
Двигаясь дальше, мы также
иметь разрешение.

00:10:19.755 --> 00:10:21.290
Очень важно защитить

00:10:21.290 --> 00:10:23.780
ваши данные, как только это
внутри кластера,

00:10:23.780 --> 00:10:26.720
как только вы на самом деле удается
войти в систему и проверить подлинность.

00:10:26.720 --> 00:10:30.675
Да. Таким образом, ключевые части я
хотел бы подчеркнуть здесь,

00:10:30.675 --> 00:10:31.920
и это все еще высокий уровень.

00:10:31.920 --> 00:10:33.485
Я уверен, что мы будем иметь

00:10:33.485 --> 00:10:35.660
дополнительные разговоры о
детали этих вещей.

00:10:35.660 --> 00:10:37.335
Но на высоком уровне,

00:10:37.335 --> 00:10:38.510
есть два уровня

00:10:38.510 --> 00:10:42.050
авторизация проверяет, что вы
в кластерах больших данных.

00:10:42.050 --> 00:10:44.750
Если мы начнем с S'L
Сервер, например,

00:10:44.750 --> 00:10:48.050
если я выдаю запрос сервера S'L,

00:10:48.050 --> 00:10:50.420
прежде всего,
проверки авторизации

00:10:50.420 --> 00:10:52.100
на объектах сервера S'L.

00:10:52.100 --> 00:10:54.920
Мне нужен доступ к
таблицы, которые я хочу задать,

00:10:54.920 --> 00:10:58.730
например, чтобы мы могли
уверен, что я могу получить доступ к данным.

00:10:58.730 --> 00:11:00.860
Но это то же самое
проверки авторизации

00:11:00.860 --> 00:11:02.330
как мы имели в предыдущих
релизы с помощью S'L?

00:11:02.330 --> 00:11:02.780
Да, это СЗЛ.

00:11:02.780 --> 00:11:03.530
Это не изменилось?

00:11:03.530 --> 00:11:04.280
Это всего лишь СЗЛ.

00:11:04.280 --> 00:11:04.610
Хорошо, хорошо.

00:11:04.610 --> 00:11:07.160
Таким образом, в основном,
разрешение модели

00:11:07.160 --> 00:11:08.945
Сервер S'L - это то же самое

00:11:08.945 --> 00:11:11.285
ли он работает в больших
кластера данных или где-либо еще.

00:11:11.285 --> 00:11:13.490
Таким образом, вы все еще можете предоставить разрешения на

00:11:13.490 --> 00:11:16.950
конкретные таблицы и конкретные
объекты в сервере S'L, не так ли?

00:11:16.950 --> 00:11:17.915
Хорошо, хорошо.

00:11:17.915 --> 00:11:19.945
Но в дополнение к этому,

00:11:19.945 --> 00:11:21.845
Теперь давайте по сценарию, когда я

00:11:21.845 --> 00:11:23.990
выдача запроса против данных,

00:11:23.990 --> 00:11:26.060
сидя в HDFS, и я запрос

00:11:26.060 --> 00:11:28.715
внешняя таблица над
HDFS в этом случае.

00:11:28.715 --> 00:11:31.790
Я не только должен иметь
доступ к этой таблице,

00:11:31.790 --> 00:11:34.025
в базу данных, где
этот стол сидит,

00:11:34.025 --> 00:11:36.320
Мне также необходимо иметь доступ к

00:11:36.320 --> 00:11:39.905
фактические файлы и данные
это сидит в HDFS.

00:11:39.905 --> 00:11:40.145
Конечно же.

00:11:40.145 --> 00:11:43.430
Вот что я имела в виду с
двухуровневые проверки авторизации.

00:11:43.430 --> 00:11:45.035
Так что в этом случае, есть проверка в

00:11:45.035 --> 00:11:48.620
Сервер сс-L и есть
дополнительная проверка в HDFS.

00:11:48.620 --> 00:11:48.920
Хорошо, хорошо.

00:11:48.920 --> 00:11:50.510
На стороне Spark,

00:11:50.510 --> 00:11:53.660
в основном Искра
запросы будут поступать и

00:11:53.660 --> 00:11:56.000
проверка авторизации HDFS будет

00:11:56.000 --> 00:11:58.505
убедитесь, что
разрешения соблюдены.

00:11:58.505 --> 00:12:00.200
Хорошо, хорошо. Так что со всем этим,

00:12:00.200 --> 00:12:01.820
Я могу быть уверен, что

00:12:01.820 --> 00:12:04.370
исходного пользователя
идентичность передается через

00:12:04.370 --> 00:12:06.590
Сервер S'L до любого мира
данные, не так ли?

00:12:06.590 --> 00:12:09.455
HDFS или же я доступ к нему, правильно?

00:12:09.455 --> 00:12:15.390
Точно. Да. Тогда, как мы
рода коснулся раньше,

00:12:15.390 --> 00:12:18.825
Мы будем иметь этот сквозной идентичности

00:12:18.825 --> 00:12:22.670
это означает, что оригинал
идентификация пользователя будет течь

00:12:22.670 --> 00:12:26.810
вплоть до
данные, чтобы мы могли на самом деле

00:12:26.810 --> 00:12:27.980
проверить всю дорогу

00:12:27.980 --> 00:12:31.730
что это был пользователь, который
хотел получить доступ к данным.

00:12:31.730 --> 00:12:32.800
Хорошо, хорошо.

00:12:32.800 --> 00:12:38.820
Да, да. Таким образом, чтобы
в основном это резюме на

00:12:38.820 --> 00:12:41.390
высокий уровень безопасности
возможности вокруг

00:12:41.390 --> 00:12:44.780
интеграции АД конкретно
для кластеров больших данных.

00:12:44.780 --> 00:12:47.710
Так где же я могу узнать
больше, если я хочу нырять глубже?

00:12:47.710 --> 00:12:50.420
Да, да. Так что, если

00:12:50.420 --> 00:12:52.580
Вы хотите узнать больше о
кластеры больших данных в целом

00:12:52.580 --> 00:12:56.495
и у нас есть документы безопасности

00:12:56.495 --> 00:12:59.675
охватывающих детали того, что
Я только что объяснил сегодня,

00:12:59.675 --> 00:13:04.280
Вы должны пойти на это
короткое звено: aka.ms/sqlbdc.

00:13:04.280 --> 00:13:05.615
Хорошо, хорошо.

00:13:05.615 --> 00:13:09.455
Если вы идете туда, вы можете узнать
о кластерах больших данных.

00:13:09.455 --> 00:13:10.835
Все, что есть, чтобы учиться, не так ли?

00:13:10.835 --> 00:13:11.255
Да, да.

00:13:11.255 --> 00:13:12.560
Awesome. Так что ладно.

00:13:12.560 --> 00:13:14.210
Так что в основном, мне нужно туда

00:13:14.210 --> 00:13:16.750
и начать обучение и
начать загрузку.

00:13:16.750 --> 00:13:18.810
Могу ли я экспортировать его в большой PDF и

00:13:18.810 --> 00:13:21.990
Затем прочитать его в
в ночное время, чтобы узнать?

00:13:21.990 --> 00:13:25.095
Да, да. На самом деле, я думаю,
Вы можете сделать это. Да.

00:13:25.095 --> 00:13:27.120
Не печатайте его,
Хотя. Просто PDF, не так ли?

00:13:27.120 --> 00:13:27.300
Да, да.

00:13:27.300 --> 00:13:29.390
Хорошо, хорошо. Классно. Так что спасибо большое.

00:13:29.390 --> 00:13:31.295
Это было очень полезно.
Большое спасибо за обмен.

00:13:31.295 --> 00:13:32.030
Спасибо.

00:13:32.030 --> 00:13:33.950
Спасибо, что смотрели.

00:13:33.950 --> 00:13:35.960
Пожалуйста, подпишитесь,
и комментировать

00:13:35.960 --> 00:13:37.940
видео, и я надеюсь, что
Увидимся в следующий раз. Спасибо.

00:13:37.940 --> 00:13:52.600
(МУЗЫКА)

