WEBVTT

00:00:00.000 --> 00:00:10.500
(Музыка).

00:00:10.500 --> 00:00:11.910
Привет и добро пожаловать обратно.

00:00:11.910 --> 00:00:14.970
Меня зовут JRJ, и я здесь
рассказать вам об одном из

00:00:14.970 --> 00:00:18.915
самых ожидаемых
функции в сервере S'L 2019,

00:00:18.915 --> 00:00:21.285
и это виртуализация данных.

00:00:21.285 --> 00:00:23.175
Что такое виртуализация данных,

00:00:23.175 --> 00:00:25.440
и почему это так с нетерпением ожидается?

00:00:25.440 --> 00:00:27.510
Ну, просто положи,

00:00:27.510 --> 00:00:29.510
виртуализация данных позволяет

00:00:29.510 --> 00:00:31.670
объединить все ваши данные в

00:00:31.670 --> 00:00:35.780
время запроса, а не того, чтобы
построить сложные конвейеры ETL в

00:00:35.780 --> 00:00:40.535
чтобы иметь возможность объединить
данные в одном запросе.

00:00:40.535 --> 00:00:44.150
Так что я собираюсь
делать, а не идти

00:00:44.150 --> 00:00:47.540
через детали данных
виртуализация на концептуальном уровне,

00:00:47.540 --> 00:00:49.730
Я просто покажу тебе.
различия между

00:00:49.730 --> 00:00:52.430
локальный запрос и
виртуализированный запрос,

00:00:52.430 --> 00:00:55.085
как частично, так и полностью виртуализировано.

00:00:55.085 --> 00:00:56.280
Чтобы сделать это,

00:00:56.280 --> 00:00:58.010
то, что мы собираемся сделать, это
мы собираемся переключиться

00:00:58.010 --> 00:01:00.270
теперь в Студию данных Azure,

00:01:00.270 --> 00:01:03.035
и вы можете видеть здесь я
иметь рабочую книгу открытой,

00:01:03.035 --> 00:01:08.990
и давайте видем и
начать оценку этого.

00:01:08.990 --> 00:01:13.625
Так вот вы можете видеть, что я
есть очень простой запрос.

00:01:13.625 --> 00:01:17.030
У меня есть два местных
таблицы в моей базе данных,

00:01:17.030 --> 00:01:19.160
и если я займусь этим запросом,

00:01:19.160 --> 00:01:23.405
Вы можете себе представить результат
возвращается красиво и быстро.

00:01:23.405 --> 00:01:25.190
У меня есть около секунды,

00:01:25.190 --> 00:01:28.045
и я получаю свой набор данных
обратно в блокнот.

00:01:28.045 --> 00:01:31.630
Однако, что, если все это
данных не было в сервере S'L?

00:01:31.630 --> 00:01:36.200
Что делать, если эти данные были на самом деле
доступны в удаленных серверах S'L,

00:01:36.200 --> 00:01:40.145
и мы хотели получить доступ к этому
данные все в то же время?

00:01:40.145 --> 00:01:43.700
Ну, вы можете использовать виртуализацию данных
для решения этой проблемы.

00:01:43.700 --> 00:01:45.050
Но для того, чтобы сделать это,

00:01:45.050 --> 00:01:47.030
нам нужно настроить некоторые метаданные.

00:01:47.030 --> 00:01:50.510
Так что первое, что нам нужно
сделать, это создать мастер-ключ,

00:01:50.510 --> 00:01:53.720
и мастер-ключ является ключом внутри

00:01:53.720 --> 00:01:55.910
база данных, которую мы используем для защиты

00:01:55.910 --> 00:01:58.660
все остальные метаданные внутри него.

00:01:58.660 --> 00:02:03.380
Вы можете видеть из метаданных
здесь, какой алгоритм мы используем,

00:02:03.380 --> 00:02:06.110
когда он создан, и
интересные вещи, как это.

00:02:06.110 --> 00:02:10.745
Теперь мне нужно включить PolyBase
для того, чтобы иметь возможность

00:02:10.745 --> 00:02:16.310
доступ к удаленным источникам
и удаленные базы данных,

00:02:16.310 --> 00:02:19.220
и создать учетные данные базы данных для

00:02:19.220 --> 00:02:23.495
иметь возможность аутентификации
против этих отдаленных источников,

00:02:23.495 --> 00:02:28.835
и вы можете видеть здесь, что я
создал несколько в прошлом,

00:02:28.835 --> 00:02:30.200
как пара Oracle,

00:02:30.200 --> 00:02:32.225
и несколько СЗЛ
те, там же.

00:02:32.225 --> 00:02:36.680
Но сегодня, мы собираемся пойти
против источника данных СЗЛ,

00:02:36.680 --> 00:02:39.650
и вы можете видеть здесь, что
для того, чтобы сделать это,

00:02:39.650 --> 00:02:41.730
Мне нужно создать
внешний источник данных.

00:02:41.730 --> 00:02:45.390
Здесь я укажу свой
местонахождение, в данном случае,

00:02:45.390 --> 00:02:49.160
адрес сервера S'L
где-то в Лазурном,

00:02:49.160 --> 00:02:51.874
и я прохожу в том, что полномочия

00:02:51.874 --> 00:02:54.425
для обеспечения того, чтобы аутентификация
иметь место.

00:02:54.425 --> 00:02:56.590
Итак, давайте идти вперед и создать это,

00:02:56.590 --> 00:03:00.880
и вы можете увидеть еще раз, есть
метаданные внутри базы данных.

00:03:00.880 --> 00:03:03.040
Теперь, как правило,

00:03:03.040 --> 00:03:06.290
Мне нравится держать внешние
таблицы, определяющие

00:03:06.290 --> 00:03:08.465
эти внешние объекты источника данных

00:03:08.465 --> 00:03:11.210
отдельно от моих внутренних таблиц,

00:03:11.210 --> 00:03:12.890
и я делаю это, используя схему.

00:03:12.890 --> 00:03:16.500
Так что давайте идти вперед и
создать внешнюю схему,

00:03:17.660 --> 00:03:23.350
и теперь мы можем спуститься сюда и
создать нашу первую внешнюю таблицу.

00:03:23.350 --> 00:03:25.730
Первая внешняя таблица
мы собираемся создать это

00:03:25.730 --> 00:03:28.240
веб-нажмите потоки, которые
это первая таблица,

00:03:28.240 --> 00:03:31.315
и в этом случае это
больше похоже на таблицу фактов,

00:03:31.315 --> 00:03:34.755
и мы будем хранить это.

00:03:34.755 --> 00:03:36.490
Итак, в этой внешней базе данных,

00:03:36.490 --> 00:03:38.375
у нас точно такая же база данных.

00:03:38.375 --> 00:03:44.200
Мы просто используем его снова, чтобы
иллюстрировать этот сценарий.

00:03:44.200 --> 00:03:50.515
Теперь мы можем перейти к процессу
виртуализации ссылки,

00:03:50.515 --> 00:03:52.900
таблица веб-потоков.

00:03:52.900 --> 00:03:56.500
Здесь вы можете видеть, у меня есть
те же таблицы веб-ссылки,

00:03:56.500 --> 00:03:58.660
но теперь я использую схему EXT.

00:03:58.660 --> 00:04:01.060
Так что я доступ к внешней таблице,

00:04:01.060 --> 00:04:02.440
но для всех намерений и целей,

00:04:02.440 --> 00:04:05.630
остальная часть запроса
точно так же.

00:04:05.630 --> 00:04:08.225
Если я займу этот запрос сейчас,

00:04:08.225 --> 00:04:10.120
скажем, он принимает
немного дольше, потому что

00:04:10.120 --> 00:04:12.100
мы собираемся пойти и
получить эти данные удаленно,

00:04:12.100 --> 00:04:14.905
и вы могли бы сказать, что это
около 3,5 секунд.

00:04:14.905 --> 00:04:17.260
Но мы видим, что у нас есть

00:04:17.260 --> 00:04:20.785
что данные здесь и
это точно так же.

00:04:20.785 --> 00:04:23.710
Так что все под капотом

00:04:23.710 --> 00:04:27.065
является полностью прозрачным
для меня, как пользователя.

00:04:27.065 --> 00:04:29.920
Теперь что, если я на самом деле идти вперед и

00:04:29.920 --> 00:04:33.250
виртуализация второго
внешняя таблица в этом запросе?

00:04:33.250 --> 00:04:35.680
Вы помните, что первый
один был веб-клипстрим,

00:04:35.680 --> 00:04:38.905
что второй
— таблица элементов.

00:04:38.905 --> 00:04:41.090
Так что давайте идти вперед и делать это,

00:04:41.090 --> 00:04:45.650
и теперь у меня есть оба
таблицы виртуализированы.

00:04:47.290 --> 00:04:52.290
Так что же происходит, когда
Я запускаю последний запрос?

00:04:52.290 --> 00:04:57.565
Этот последний запрос будет
запустить точно такой же запрос,

00:04:57.565 --> 00:05:01.670
но и внешние
столы виртуализированы,

00:05:01.940 --> 00:05:05.275
и вы можете видеть, что на самом деле
запрос почти как

00:05:05.275 --> 00:05:09.375
быстро, как первый
версия, локальный запрос.

00:05:09.375 --> 00:05:12.530
Почему это так? Почему мы получаем
эта разница в производительности?

00:05:12.530 --> 00:05:14.780
Ну, причина в том,
что если вы посмотрите на

00:05:14.780 --> 00:05:17.000
Серверы СЗЛ
достаточно умный с помощью

00:05:17.000 --> 00:05:20.600
его затратный оптимизатор
чтобы понять, что

00:05:20.600 --> 00:05:24.725
обе таблицы являются внешними и
они приходят из одного и того же источника,

00:05:24.725 --> 00:05:28.400
и что он может видеть, что
он может подтолкнуть это соединение и

00:05:28.400 --> 00:05:32.030
агрегации вниз
против этого удаленного источника.

00:05:32.030 --> 00:05:34.190
Таким образом, мы используя вычисления

00:05:34.190 --> 00:05:37.445
что удаленный источник для решения
этот запрос в режиме реального времени.

00:05:37.445 --> 00:05:41.030
Но это дает вам краткий обзор
возможностей, которые вы

00:05:41.030 --> 00:05:44.750
выйти из использования данных
Технология виртуализации

00:05:44.750 --> 00:05:48.470
и как вы можете на самом деле
прозрачно представить эти данные

00:05:48.470 --> 00:05:50.390
к конечному пользователю без необходимости

00:05:50.390 --> 00:05:52.520
сделать физические копии этих данных,

00:05:52.520 --> 00:05:54.410
без необходимости перемещать его или строить

00:05:54.410 --> 00:05:56.420
сложный конвейер ETL в

00:05:56.420 --> 00:05:58.910
для того, чтобы иметь возможность
данные запросов в режиме реального времени.

00:05:58.910 --> 00:06:00.510
Большое спасибо за присоединение,

00:06:00.510 --> 00:06:02.960
и я с нетерпением жду, чтобы ловить
с вами снова в ближайшее время.

00:06:02.960 --> 00:06:17.560
(МУЗЫКА)