Este artículo del blog fue escrito por: Sahaj Saini, PM en el equipo de Microsoft Analytics Platform System (APS).
En esta entrada de blog, proporcionaremos una rápida visión general del multiprocesamiento simétrico (SMP) frente al procesamiento paralelo masivo (MPP). Procesamiento paralelo masivo (MPP), cómo identificar los factores desencadenantes de la migración de SMP a MPP, las consideraciones clave a la hora de pasar a Microsoft Analytics Platform System (APS), y un debate sobre cómo aprovechar la potencia de una solución MPP como APS.
Comencemos con un escenario. Emma es la administradora de la base de datos de Adventure Works Cycles, una empresa de fabricación de bicicletas. En Adventure Works, Emma y su equipo utilizan SQL Server SMP tradicional como solución de almacenamiento de datos. La empresa ha crecido rápidamente y, debido a la creciente competencia en el sector de las bicicletas, los analistas empresariales de Adventure Works Cycles desean tener una visión más rápida de sus datos. Emma se enfrenta a los siguientes retos con la implantación de SMP –
- Alto volumen de datos y crecimiento de los mismos: Con el aumento de las ventas y una creciente base de clientes, el volumen de datos ha crecido rápidamente hasta superar los 10 TB.
- Tiempos de carga de datos/ETL más largos: Con la necesidad de producir informes diarios para la gerencia, Emma encuentra que la velocidad actual de ETL es inadecuada para admitir y procesar la creciente cantidad de datos que fluyen desde otros sistemas OLTP y no relacionales.
- Lentitud en la ejecución de consultas: Los tiempos de ejecución de las consultas se están ralentizando debido al aumento de los datos y cada vez es más difícil generar conocimientos para la elaboración de informes diarios en el momento oportuno.
- Largo tiempo de procesamiento de cubos: Con el actual tiempo de procesamiento de cubos, es difícil satisfacer las necesidades de elaboración de informes en tiempo real de la empresa.
Para superar estos retos, Emma y su equipo evalúan la compra de un conjunto de servidores y hardware de almacenamiento más grande, caro y potente para su centro de datos. Este enfoque resolvería su problema, pero sólo a corto plazo, ya que se espera que el crecimiento de los datos se dispare en los próximos 12 meses. Con el crecimiento de datos que Adventure Works espera ver, incluso las soluciones SMP más grandes y potentes se toparían con un muro muy rápidamente. A Emma le gustaría ver una solución que escalara a medida que sus necesidades de datos crecieran.
Antes de entrar a resolver los problemas de Emma, definamos rápidamente lo que son SMP y MPP. El multiprocesamiento simétrico (SMP) es un sistema multiprocesador estrechamente acoplado en el que los procesadores comparten recursos: instancias individuales del sistema operativo (SO), memoria, dispositivos de E/S y conectados mediante un bus común. SMP es la principal arquitectura paralela empleada en los servidores y se representa en la siguiente imagen.
El Procesamiento Masivamente Paralelo (MPP) es el procesamiento coordinado de una única tarea por parte de múltiples procesadores, cada uno de los cuales utiliza su propio sistema operativo y su propia memoria y se comunican entre sí utilizando algún tipo de interfaz de mensajería. El MPP puede configurarse con una arquitectura de disco compartido o de nada compartido.
En una arquitectura de nada compartido, no hay ningún punto de contención en el sistema y los nodos no comparten la memoria ni el almacenamiento en disco. Los datos se dividen horizontalmente entre los nodos, de manera que cada nodo tiene un subconjunto de filas de cada tabla de la base de datos. Cada nodo procesa entonces sólo las filas de sus propios discos. Los sistemas basados en esta arquitectura pueden alcanzar una escala masiva, ya que no hay ningún cuello de botella que ralentice el sistema. Esto es lo que busca Emma.
El MPP con arquitectura compartida-nada se representa en la siguiente imagen.
El Almacén de Datos Paralelo de Microsoft (PDW) que se ejecuta en un dispositivo del Sistema de Plataforma Analítica de Microsoft se implementa como una arquitectura compartida-nada del MPP. Consta de un nodo de control y de nodos informáticos conectados al almacenamiento e interconectados por Ethernet e Infiniband. El nodo de control alberga el motor PDW -el cerebro del sistema MPP- que crea planes de consulta paralelos, coordina la ejecución de las consultas en los nodos de cálculo y la agregación de datos en todo el dispositivo. Todos los nodos, incluidos los de control y los de cómputo, alojan un Servicio de Movimiento de Datos (DMS) para transferir datos entre nodos.
Para obtener más detalles sobre la arquitectura de PDW, puede leer el post Arquitectura del Sistema de Plataforma Analítica de Microsoft.
Transición a MPP
Para aprovechar el valor que ofrece MPP, Emma y su equipo adquieren un appliance Microsoft APS y comienzan la transición a MPP. Veamos cómo adaptan su solución para aprovechar al máximo la arquitectura MPP de APS.
Diseño de la tabla
Como se ha mencionado anteriormente, APS se basa en una arquitectura MPP de nada compartido, lo que significa que los nodos son autosuficientes y no comparten memoria ni discos. La arquitectura, por lo tanto, requiere que usted distribuya sus grandes tablas entre los nodos para obtener los beneficios del procesamiento masivamente paralelo. APS permite definir una tabla como distribuida o replicada. La decisión de elegir una u otra depende del volumen de datos y de la necesidad de acceder a todos los datos en un único nodo.
Tablas distribuidas
Una tabla distribuida es aquella en la que los datos de las filas de la tabla se distribuyen entre los nodos del dispositivo para permitir una escala masiva. Cada fila termina en una distribución en un nodo de cómputo como se muestra en la imagen de abajo.
Para aprovechar la naturaleza distribuida de APS, Emma modifica las tablas grandes, típicamente Fact y tablas de grandes dimensiones, para que sean distribuidas en APS como sigue:
CREATE TABLE .( NOT NULL, NOT NULL, . . NULL) WITH( DISTRIBUTION = HASH(ProductKey),CLUSTERED COLUMNSTORE INDEX);
Como puede ver, esta es una típica sentencia DDL para la creación de tablas con una adición menor para las tablas distribuidas. Las tablas se distribuyen mediante una función hash determinista aplicada a la columna de distribución elegida para esa tabla. Emma elige la Clave de Producto como columna de distribución en la tabla FactInternetSales debido a la alta cardinalidad y a la ausencia de sesgo, por lo que distribuye la tabla uniformemente entre los nodos.
Tablas Replicadas
Sin embargo, si todas las tablas estuvieran distribuidas, se requeriría una gran cantidad de movimiento de datos entre los nodos antes de realizar las operaciones de unión para todas las operaciones. Por lo tanto, para las tablas de dimensiones más pequeñas, como el idioma, los países, etc., tiene sentido replicar toda la tabla en cada nodo de computación. Es decir, los beneficios de permitir operaciones de unión locales con estas tablas superan el coste del almacenamiento extra consumido. Una tabla replicada es aquella que se replica en todos los nodos de computación, como se muestra a continuación.
Emma diseña las tablas pequeñas, normalmente tablas de dimensiones, para que se repliquen de la siguiente manera:
CREATE TABLE .( NOT NULL, . . (10) NOT NULL,)WITH(CLUSTERED COLUMNSTORE INDEX);
Diseñando adecuadamente las tablas distribuidas y replicadas, Emma alinea su solución con las mejores prácticas comunes de diseño de MPP y permite un procesamiento eficiente de grandes volúmenes de datos. Por ejemplo, una consulta contra 100 mil millones de filas en un entorno SQL Server SMP requeriría el procesamiento de todos los datos en un único espacio de ejecución. Con MPP, el trabajo se reparte entre muchos nodos para dividir el problema en formas más manejables y fáciles de ejecutar las tareas. En un dispositivo de cuatro nodos (véase la imagen de arriba), a cada nodo sólo se le pide que procese aproximadamente 25.000 millones de filas, una tarea mucho más rápida. Como resultado, Emma observa mejoras significativas en el tiempo de ejecución de las consultas y su empresa puede ahora tomar mejores decisiones, más rápidamente. Además, Emma puede hacer crecer el almacén de datos desde unos pocos terabytes hasta más de 6 petabytes de datos añadiendo «unidades de escala» a APS.
Carga de datos
Con SQL Server SMP, Emma y su equipo utilizaban procesos ETL a través de un conjunto de paquetes SSIS para cargar los datos en el almacén de datos: (1) Extraer los datos del OLTP y otros sistemas; (2) Transformar los datos en formato dimensional; y (3) Cargar los datos en las tablas de dimensiones o hechos de destino en el almacén de datos. Con el aumento de los volúmenes de datos, el SSIS sever en el medio se convierte en un cuello de botella al realizar las transformaciones, lo que resulta en la carga lenta de los datos.
Con APS, Emma y su equipo pueden utilizar ELT en su lugar, para Extraer los datos del OLTP y otros sistemas y Cargarlos a una ubicación de almacenamiento en APS. A continuación, los datos pueden transformarse en formato dimensional no con SSIS, sino con el motor APS, utilizando la naturaleza distribuida del dispositivo y la potencia del procesamiento en paralelo. En un dispositivo de 4 nodos, cuatro servidores estarían haciendo las transformaciones en subconjuntos de datos frente al servidor SSIS de un solo nodo.
Este procesamiento paralelo resulta en un aumento significativo del rendimiento de la carga de datos. Emma puede entonces utilizar la sentencia Create Table As Select (CTAS) para crear la tabla a partir de la tabla de preparación como se indica a continuación.
CREATE TABLE . WITH( CLUSTERED COLUMN INDEX, DISTRIBUTION = HASH (CustomerKey))ASSELECT * FROM .;
Al cambiar a un proceso ELT, Emma utiliza la potencia de procesamiento paralelo de APS para ver ganancias de rendimiento en la carga de datos.
En conclusión, Emma y su equipo han encontrado respuestas a sus problemas de SMP con MPP. Ahora pueden sentirse seguros manejando el volumen de datos y el crecimiento en Adventure Works con la capacidad de escalar el almacén de datos según sea necesario. Con ELT y la potencia del procesamiento paralelo en APS, pueden cargar los datos en APS más rápidamente y dentro de la ventana de tiempo prevista. Además, al alinearse con el diseño MPP de APS, pueden lograr un rendimiento de consulta extraordinario, lo que permite elaborar informes en tiempo real y conocer sus datos.