WEBVTT

00:00:00.000 --> 00:00:10.500
[MÚSICA].

00:00:10.500 --> 00:00:11.910
>> Oi e bem-vindo de volta.

00:00:11.910 --> 00:00:14.970
Meu nome é JRJ, e eu estou aqui
para falar sobre um dos

00:00:14.970 --> 00:00:18.915
o mais aguardado
recursos no SQL Server 2019,

00:00:18.915 --> 00:00:21.285
e isso é virtualização de dados.

00:00:21.285 --> 00:00:23.175
O que é a virtualização de dados,

00:00:23.175 --> 00:00:25.440
e por que é tão ansiosamente antecipado?

00:00:25.440 --> 00:00:27.510
Bem, simplificando,

00:00:27.510 --> 00:00:29.510
A virtualização de dados permite que você

00:00:29.510 --> 00:00:31.670
reunir todos os seus dados

00:00:31.670 --> 00:00:35.780
tempo de consulta em vez de ter que ter que
construir complexos oleodutos ETL em

00:00:35.780 --> 00:00:40.535
ordem para ser capaz de unificar
os dados em uma única consulta.

00:00:40.535 --> 00:00:44.150
Então, o que eu vou
fazer é ao invés de ir

00:00:44.150 --> 00:00:47.540
através dos detalhes dos dados
virtualização a nível conceptual,

00:00:47.540 --> 00:00:49.730
Só vou te mostrar.
as diferenças entre

00:00:49.730 --> 00:00:52.430
uma consulta local e um
consulta virtualizada,

00:00:52.430 --> 00:00:55.085
ambos parcialmente e totalmente virtualizados.

00:00:55.085 --> 00:00:56.280
Então, para fazer isso,

00:00:56.280 --> 00:00:58.010
o que vamos fazer é
vamos mudar.

00:00:58.010 --> 00:01:00.270
agora para o Azure Data Studio,

00:01:00.270 --> 00:01:03.035
e você pode ver aqui eu
ter uma agenda de trabalho aberta,

00:01:03.035 --> 00:01:08.990
e vamos entrar e
Comece a avaliar isso.

00:01:08.990 --> 00:01:13.625
Então aqui você pode ver eu
ter uma pergunta muito simples.

00:01:13.625 --> 00:01:17.030
Eu tenho dois locais
tabelas no meu banco de dados,

00:01:17.030 --> 00:01:19.160
e se eu executar essa consulta,

00:01:19.160 --> 00:01:23.405
você poderia imaginar o resultado
volta agradável e rapidamente.

00:01:23.405 --> 00:01:25.190
Eu tenho cerca de um segundo,

00:01:25.190 --> 00:01:28.045
e eu recebo o meu conjunto de dados
de volta ao caderno.

00:01:28.045 --> 00:01:31.630
No entanto, e se tudo isso
os dados não estavam no servidor SQL?

00:01:31.630 --> 00:01:36.200
E se esses dados fossem realmente
disponível em servidores SQL remotos,

00:01:36.200 --> 00:01:40.145
e queríamos ter acesso a isso
dados ao mesmo tempo?

00:01:40.145 --> 00:01:43.700
Bem, você pode usar a virtualização de dados
para resolver esse problema.

00:01:43.700 --> 00:01:45.050
Mas para fazê-lo,

00:01:45.050 --> 00:01:47.030
precisamos configurar alguns metadados.

00:01:47.030 --> 00:01:50.510
Então, a primeira coisa que precisamos
fazer é criar uma chave mestra,

00:01:50.510 --> 00:01:53.720
e uma chave mestra é uma chave no interior

00:01:53.720 --> 00:01:55.910
o banco de dados que usamos para proteger

00:01:55.910 --> 00:01:58.660
todos os outros metadados dentro dele.

00:01:58.660 --> 00:02:03.380
Você pode ver a partir dos metadados
aqui qual algoritmo estamos usando,

00:02:03.380 --> 00:02:06.110
quando é criado, e
coisas interessantes como essa.

00:02:06.110 --> 00:02:10.745
Agora eu preciso habilitar a PolyBase
recurso, a fim de ser capaz de

00:02:10.745 --> 00:02:16.310
acessar fontes remotas
e bancos de dados remotos,

00:02:16.310 --> 00:02:19.220
e criar uma credencial de banco de dados para

00:02:19.220 --> 00:02:23.495
ser capaz de autenticar
contra essas fontes remotas,

00:02:23.495 --> 00:02:28.835
e você pode ver aqui que eu tenho
criou alguns no passado,

00:02:28.835 --> 00:02:30.200
como um par de Oracle,

00:02:30.200 --> 00:02:32.225
e um par de SQL
os lá também.

00:02:32.225 --> 00:02:36.680
Mas hoje, nós vamos
contra uma fonte de dados SQL,

00:02:36.680 --> 00:02:39.650
e você pode ver aqui que
para fazer isso,

00:02:39.650 --> 00:02:41.730
Eu preciso criar um
fonte de dados externa.

00:02:41.730 --> 00:02:45.390
Aqui, eu especifico o meu
localização, neste caso,

00:02:45.390 --> 00:02:49.160
um endereço de servidor SQL
em algum lugar em Azure,

00:02:49.160 --> 00:02:51.874
e eu passo nessa credencial

00:02:51.874 --> 00:02:54.425
para habilitar essa autenticação
para ter lugar.

00:02:54.425 --> 00:02:56.590
Então, vamos em frente e criar isso,

00:02:56.590 --> 00:03:00.880
e você pode ver de novo, há
os metadados dentro do banco de dados.

00:03:00.880 --> 00:03:03.040
Agora, como regra geral,

00:03:03.040 --> 00:03:06.290
Gosto de manter o externo
tabelas que definem

00:03:06.290 --> 00:03:08.465
esses objetos externos de fonte de dados

00:03:08.465 --> 00:03:11.210
separado sminhas mesas internas,

00:03:11.210 --> 00:03:12.890
e eu faço isso usando um esquema.

00:03:12.890 --> 00:03:16.500
Então, vamos em frente e
criar um esquema externo,

00:03:17.660 --> 00:03:23.350
e agora podemos vir aqui e
criar a nossa primeira tabela externa.

00:03:23.350 --> 00:03:25.730
A primeira tabela externa
vamos criar

00:03:25.730 --> 00:03:28.240
web clique córregos que
é a primeira tabela,

00:03:28.240 --> 00:03:31.315
e neste caso é
mais como uma tabela de fatos,

00:03:31.315 --> 00:03:34.755
e vamos guardar isso.

00:03:34.755 --> 00:03:36.490
Então, nesse banco de dados externo,

00:03:36.490 --> 00:03:38.375
temos exatamente o mesmo banco de dados.

00:03:38.375 --> 00:03:44.200
Estamos apenas usando-o novamente para
ilustrar este cenário.

00:03:44.200 --> 00:03:50.515
Agora, podemos entrar no processo
de virtualizar um clickstream,

00:03:50.515 --> 00:03:52.900
a tabela de clickstreams da web.

00:03:52.900 --> 00:03:56.500
Aqui você pode ver que eu tenho o
Mesmo clique na web tabela,

00:03:56.500 --> 00:03:58.660
mas agora estou usando o esquema EXT.

00:03:58.660 --> 00:04:01.060
Então, eu estou acessando a mesa externa,

00:04:01.060 --> 00:04:02.440
mas para todos os efeitos,

00:04:02.440 --> 00:04:05.630
o resto da consulta
é exatamente o mesmo.

00:04:05.630 --> 00:04:08.225
Se eu executar essa consulta agora,

00:04:08.225 --> 00:04:10.120
Digamos que é preciso um
pouco mais porque

00:04:10.120 --> 00:04:12.100
vamos e
obter esses dados remotamente,

00:04:12.100 --> 00:04:14.905
e você poderia dizer que é
cerca de 3,5 segundos.

00:04:14.905 --> 00:04:17.260
Mas podemos ver que temos

00:04:17.260 --> 00:04:20.785
que os dados aqui e
É exatamente o mesmo.

00:04:20.785 --> 00:04:23.710
Então, tudo debaixo do capô

00:04:23.710 --> 00:04:27.065
é completamente transparente
para mim como usuário.

00:04:27.065 --> 00:04:29.920
Agora, e se eu realmente ir em frente e

00:04:29.920 --> 00:04:33.250
virtualizar o segundo
tabela externa nesta consulta?

00:04:33.250 --> 00:04:35.680
Você se lembra que o primeiro
um foi clipstreams web,

00:04:35.680 --> 00:04:38.905
que o segundo
é a tabela do artigo.

00:04:38.905 --> 00:04:41.090
Então, vamos em frente e fazer isso,

00:04:41.090 --> 00:04:45.650
e agora eu tenho os dois
tabelas virtualizadas.

00:04:47.290 --> 00:04:52.290
Então, agora, o que acontece quando
Eu faço esta última consulta?

00:04:52.290 --> 00:04:57.565
Esta última consulta vai
executar exatamente a mesma consulta,

00:04:57.565 --> 00:05:01.670
mas ambos externos
tabelas são virtualizadas,

00:05:01.940 --> 00:05:05.275
e você pode ver que, na verdade,
a consulta é quase tão

00:05:05.275 --> 00:05:09.375
jejum como o primeiro
versão, a consulta local.

00:05:09.375 --> 00:05:12.530
Agora, por que isso? Por que temos
essa diferença de desempenho?

00:05:12.530 --> 00:05:14.780
Bem, a razão é
que se você olhar para

00:05:14.780 --> 00:05:17.000
os servidores SQL
uso inteligente o suficiente

00:05:17.000 --> 00:05:20.600
seu otimizador baseado em custos
para entender isso

00:05:20.600 --> 00:05:24.725
ambas as tabelas são externas e
eles vêm da mesma fonte,

00:05:24.725 --> 00:05:28.400
e que ele pode ver que
ele pode empurrar esta junção e

00:05:28.400 --> 00:05:32.030
a agregação para baixo
contra essa fonte remota.

00:05:32.030 --> 00:05:34.190
Então, estamos aproveitando a computação de

00:05:34.190 --> 00:05:37.445
que a fonte remota para resolver
esta consulta em tempo real.

00:05:37.445 --> 00:05:41.030
Mas isso dá-lhe uma visão rápida
das capacidades que você

00:05:41.030 --> 00:05:44.750
sair do uso de dados
tecnologia de virtualização

00:05:44.750 --> 00:05:48.470
e como você pode realmente
apresentar transparentemente esses dados

00:05:48.470 --> 00:05:50.390
voltar a um usuário final sem ter que

00:05:50.390 --> 00:05:52.520
fazer cópias físicas desses dados,

00:05:52.520 --> 00:05:54.410
sem ter que movê-lo ou construir

00:05:54.410 --> 00:05:56.420
um complexo gasoduto ETL em

00:05:56.420 --> 00:05:58.910
fim a ser capaz de
dados de consulta em tempo real.

00:05:58.910 --> 00:06:00.510
Muito obrigado por se juntar,

00:06:00.510 --> 00:06:02.960
e estou ansioso para pegar
até com você novamente em breve.

00:06:02.960 --> 00:06:17.560
[MÚSICA]