WEBVTT

00:00:00.000 --> 00:00:10.500
[MUSIC].

00:00:10.500 --> 00:00:11.910
>> Hola y bienvenidos de nuevo.

00:00:11.910 --> 00:00:14.970
Mi nombre es JRJ, y estoy aquí
para contarles acerca de uno de los

00:00:14.970 --> 00:00:18.915
el más esperado previsto
características de SQL Server 2019,

00:00:18.915 --> 00:00:21.285
y eso es virtualización de datos.

00:00:21.285 --> 00:00:23.175
¿Qué es la virtualización de datos,

00:00:23.175 --> 00:00:25.440
y ¿por qué se anticipa tan ansiosamente?

00:00:25.440 --> 00:00:27.510
Bueno, en pocas palabras,

00:00:27.510 --> 00:00:29.510
virtualización de datos le permite

00:00:29.510 --> 00:00:31.670
reunir todos sus datos en

00:00:31.670 --> 00:00:35.780
tiempo de consulta en lugar de tener que
construir oleoductos ETL complejos en

00:00:35.780 --> 00:00:40.535
para poder unificar
los datos en una sola consulta.

00:00:40.535 --> 00:00:44.150
Así que lo que voy a
hacer es en lugar de ir

00:00:44.150 --> 00:00:47.540
a través de los detalles de los datos
virtualización a nivel conceptual,

00:00:47.540 --> 00:00:49.730
Sólo voy a mostrarte
las diferencias entre

00:00:49.730 --> 00:00:52.430
una consulta local y un
consulta virtualizada,

00:00:52.430 --> 00:00:55.085
parcialmente y totalmente virtualizado.

00:00:55.085 --> 00:00:56.280
Así que para hacer eso,

00:00:56.280 --> 00:00:58.010
lo que vamos a hacer es
vamos a cambiar

00:00:58.010 --> 00:01:00.270
ahora a Azure Data Studio,

00:01:00.270 --> 00:01:03.035
y se puede ver aquí que
tener un libro de trabajo abierto,

00:01:03.035 --> 00:01:08.990
y vamos a entrar y
empezar a evaluar eso.

00:01:08.990 --> 00:01:13.625
Así que aquí se puede ver que
tener una consulta muy simple.

00:01:13.625 --> 00:01:17.030
Tengo dos locales
tablas en mi base de datos,

00:01:17.030 --> 00:01:19.160
y si ejecuto esa consulta,

00:01:19.160 --> 00:01:23.405
se podría imaginar el resultado
vuelve bien y rápidamente.

00:01:23.405 --> 00:01:25.190
Tengo un segundo,

00:01:25.190 --> 00:01:28.045
y obtengo mi conjunto de datos
de nuevo en el cuaderno.

00:01:28.045 --> 00:01:31.630
Sin embargo, ¿qué pasaría si todo eso
datos no estaban en SQL Server?

00:01:31.630 --> 00:01:36.200
¿Qué pasaría si esos datos fueran realmente
disponible en servidores SQL remotos,

00:01:36.200 --> 00:01:40.145
y queríamos acceder a eso
datos al mismo tiempo?

00:01:40.145 --> 00:01:43.700
Bueno, puede usar la virtualización de datos
para resolver ese problema.

00:01:43.700 --> 00:01:45.050
Pero para hacerlo,

00:01:45.050 --> 00:01:47.030
tenemos que configurar algunos metadatos.

00:01:47.030 --> 00:01:50.510
Así que lo primero que tenemos que
hacer es crear una clave maestra,

00:01:50.510 --> 00:01:53.720
y una llave maestra es una clave dentro

00:01:53.720 --> 00:01:55.910
la base de datos que utilizamos para proteger

00:01:55.910 --> 00:01:58.660
todos los demás metadatos dentro de él.

00:01:58.660 --> 00:02:03.380
Puede ver en los metadatos
aquí qué algoritmo estamos usando,

00:02:03.380 --> 00:02:06.110
cuando se crea, y
cosas interesantes como esa.

00:02:06.110 --> 00:02:10.745
Ahora necesito habilitar el PolyBase
características para poder

00:02:10.745 --> 00:02:16.310
acceder a fuentes remotas
y bases de datos remotas,

00:02:16.310 --> 00:02:19.220
y crear una credencial de base de datos para

00:02:19.220 --> 00:02:23.495
ser capaz de autenticar
contra esas fuentes remotas,

00:02:23.495 --> 00:02:28.835
y se puede ver aquí que he
creado unos pocos en el pasado,

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

00:02:30.200 --> 00:02:32.225
y un par de SQL
los que están ahí también.

00:02:32.225 --> 00:02:36.680
Pero hoy, vamos a ir
contra un origen de datos SQL,

00:02:36.680 --> 00:02:39.650
y se puede ver aquí que
para hacer eso,

00:02:39.650 --> 00:02:41.730
Necesito crear un
origen de datos externo.

00:02:41.730 --> 00:02:45.390
Aquí, especifico mi
ubicación, en este caso,

00:02:45.390 --> 00:02:49.160
una dirección de SQL Server
en algún lugar de Azure,

00:02:49.160 --> 00:02:51.874
y paso esa credencial

00:02:51.874 --> 00:02:54.425
para permitir esa autenticación
que se lleve a cabo.

00:02:54.425 --> 00:02:56.590
Así que vamos a seguir adelante y crear eso,

00:02:56.590 --> 00:03:00.880
y se puede ver de nuevo, hay
los metadatos dentro de la base de datos.

00:03:00.880 --> 00:03:03.040
Ahora, como regla general,

00:03:03.040 --> 00:03:06.290
Me gusta mantener el externo
tablas que definen

00:03:06.290 --> 00:03:08.465
esos objetos de origen de datos externos

00:03:08.465 --> 00:03:11.210
separadas de mis mesas internas,

00:03:11.210 --> 00:03:12.890
y lo hago usando un esquema.

00:03:12.890 --> 00:03:16.500
Así que vamos a seguir adelante y
crear un esquema externo,

00:03:17.660 --> 00:03:23.350
y ahora podemos venir aquí y
crear nuestra primera tabla externa.

00:03:23.350 --> 00:03:25.730
La primera tabla externa
vamos a crear es

00:03:25.730 --> 00:03:28.240
secuencias de clics web que
es la primera tabla,

00:03:28.240 --> 00:03:31.315
y en este caso es
más bien como una mesa de hechos,

00:03:31.315 --> 00:03:34.755
y vamos a guardar eso.

00:03:34.755 --> 00:03:36.490
Así que en esa base de datos externa,

00:03:36.490 --> 00:03:38.375
tenemos exactamente la misma base de datos.

00:03:38.375 --> 00:03:44.200
Sólo lo estamos usando de nuevo para
ilustrar este escenario.

00:03:44.200 --> 00:03:50.515
Ahora, podemos entrar en el proceso
de virtualizar una secuencia de clics,

00:03:50.515 --> 00:03:52.900
la tabla de secuencias de clics web.

00:03:52.900 --> 00:03:56.500
Aquí se puede ver que tengo el
mismas secuencias de clics web de tabla,

00:03:56.500 --> 00:03:58.660
pero ahora estoy usando el esquema EXT.

00:03:58.660 --> 00:04:01.060
Así que estoy accediendo a la tabla externa,

00:04:01.060 --> 00:04:02.440
pero a todos los efectos,

00:04:02.440 --> 00:04:05.630
el resto de la consulta
es exactamente lo mismo.

00:04:05.630 --> 00:04:08.225
Si ejecuto esa consulta ahora,

00:04:08.225 --> 00:04:10.120
digamos que se necesita un
un poco más porque

00:04:10.120 --> 00:04:12.100
vamos a ir y
obtener esos datos de forma remota,

00:04:12.100 --> 00:04:14.905
y se podría decir que es
unos 3,5 segundos.

00:04:14.905 --> 00:04:17.260
Pero podemos ver que tenemos

00:04:17.260 --> 00:04:20.785
que los datos aquí y
es exactamente lo mismo.

00:04:20.785 --> 00:04:23.710
Así que todo debajo del capó

00:04:23.710 --> 00:04:27.065
es completamente transparente
para mí como usuario.

00:04:27.065 --> 00:04:29.920
Ahora, ¿qué pasa si realmente sigo adelante y

00:04:29.920 --> 00:04:33.250
virtualizar el segundo
tabla externa en esta consulta?

00:04:33.250 --> 00:04:35.680
Recuerdas que la primera
uno era clipstreams web,

00:04:35.680 --> 00:04:38.905
que el segundo
es la tabla de elementos.

00:04:38.905 --> 00:04:41.090
Así que vamos a seguir adelante y hacer eso,

00:04:41.090 --> 00:04:45.650
y ahora tengo ambos
mesas virtualizadas.

00:04:47.290 --> 00:04:52.290
Así que ahora, ¿qué pasa cuando
¿Ejecuto esta última consulta?

00:04:52.290 --> 00:04:57.565
Esta última consulta va a
ejecutar exactamente la misma consulta,

00:04:57.565 --> 00:05:01.670
pero tanto externa
las mesas están virtualizadas,

00:05:01.940 --> 00:05:05.275
y se puede ver que en realidad
la consulta es casi como

00:05:05.275 --> 00:05:09.375
rápido como el primero
versión, la consulta local.

00:05:09.375 --> 00:05:12.530
¿Por qué es eso? ¿Por qué obtenemos
esta diferencia en el rendimiento?

00:05:12.530 --> 00:05:14.780
Bueno, la razón es
que si nos fijamos en

00:05:14.780 --> 00:05:17.000
los servidores SQL Server
lo suficientemente inteligente usando

00:05:17.000 --> 00:05:20.600
su optimizador basado en costos
para entender que

00:05:20.600 --> 00:05:24.725
ambas mesas son externas y
vienen de la misma fuente,

00:05:24.725 --> 00:05:28.400
y que puede ver que
puede empujar esta unión y

00:05:28.400 --> 00:05:32.030
la agregación hacia abajo
contra esa fuente remota.

00:05:32.030 --> 00:05:34.190
Así que estamos aprovechando el proceso de

00:05:34.190 --> 00:05:37.445
esa fuente remota para resolver
esta consulta en tiempo real.

00:05:37.445 --> 00:05:41.030
Pero eso le da una visión general rápida
de las capacidades que

00:05:41.030 --> 00:05:44.750
salir del uso de datos
tecnología de virtualización

00:05:44.750 --> 00:05:48.470
y cómo se puede realmente
presentar de forma transparente que los datos

00:05:48.470 --> 00:05:50.390
volver a un usuario final sin tener que

00:05:50.390 --> 00:05:52.520
hacer copias físicas de esos datos,

00:05:52.520 --> 00:05:54.410
sin tener que moverlo o construir

00:05:54.410 --> 00:05:56.420
un complejo gasoducto ETL en

00:05:56.420 --> 00:05:58.910
para poder
consultar datos en tiempo real.

00:05:58.910 --> 00:06:00.510
Muchas gracias por unirse,

00:06:00.510 --> 00:06:02.960
y espero con ansias atrapar
hasta con usted de nuevo pronto.

00:06:02.960 --> 00:06:17.560
[MUSICA]