de haute performance Análisis en tiempo real de datos Hadoop

El desafío

He pasado muchos años trabajando con los clientes de Actian en soluciones de bases de datos, y pensé que sería útil discutir una experiencia reciente de un cliente en una gran empresa de medios de comunicación (la llamaré "XYZCo"). Esta experiencia es similar a lo que sigo viendo con otros clientes, y las lecciones aprendidas se aplican tanto a los casos de uso de Hadoop como a los que no lo son.

En este caso, el equipo de Big Data Analytics de XYZCo acudió a Actian porque necesitaba análisis de alto rendimiento en tiempo real para sus datos Hadoop, y sus sistemas actuales no eran capaces de satisfacer las expectativas empresariales. Estaban sometidos a una enorme presión para mejorar la productividad de sus analistas de datos, ya que el análisis de algunos grandes conjuntos de datos nunca terminaba, y necesitaban reducir la sobrecarga y los retrasos en el procesamiento de datos para permitir el análisis y la generación de informes del almacén de datos en tiempo real.

La situación

El cliente tenía dos tablas de hechos y dimensiones muy grandes en su base de datos. Para responder a preguntas de negocio sobre la pérdida de clientes, el valor de vida y el mercado, necesitaban unir las dos tablas para ejecutar consultas.

Dado que las bases de datos heredadas y las soluciones Hadoop son tan ineficientes a la hora de unir datos (a veces, las grandes uniones nunca terminan), XYZCo había adoptado la práctica de unir las tablas y crear unatabla intermedia pre-unida/materializada, contra la que se ejecutaban las consultas posteriores. Esta metodología funcionaba, pero tenía varios problemas: la tabla pre-unida, la materialización, era ENORME; era exponencialmente del tamaño de la tabla1 y la tabla2 (no sólo copias de la tabla1 más la tabla2), y además, inmediatamente después de su creación, la materialización era "obsoleta"; no podía actualizarse constantemente a partir de las tablas1,tabla2, en constante cambio, sino que permanecía con los valores antiguos en el momento de su creación. Además, el rendimiento de las consultas con esta materialización no era muy bueno, y algunas consultas no funcionaban... los datos eran demasiado grandes.

Además, este cliente tenía grandes volúmenes de datos estructurados en un almacén de datos Hadoop. Actualmente utilizaba Hive junto con herramientas de análisis basadas en SQL, como Tableau. El cliente estaba acostumbrado a pre-unir datos en múltiples tablas de origen con la avantage "percibida" de una consulta más simple/rápida por parte de otras herramientas y procesos posteriores. Además, la mayoría de estos agregados/uniones se exportaban a CSV para introducirlos en otras herramientas o se materializaban para obtener un SQL "percibido" más sencillo, ya que el esquema se convertía en una tabla de origen aplanada.

Comparación de soluciones

Prueba de materialización de la vieja escuela

XYZCo nos pidió que también realizáramos la prueba de materialización al estilo de la vieja escuela utilizando Actian VectorH, la base de datos SQL columnar de haute performance de Actian que se ejecuta de forma nativa en Hadoop, con la idea de que fuera una comparación directa con Hive. Así lo hicimos.

Una gran parte de cualquier materialización es el tiempo incurrido haciendo I/O para escribir el gran conjunto de resultados materializados. Aunque VectorH fue mucho más rápido que Hive en la propia unión, la parte de E/S de todo el proceso de materialización empequeñeció cualquier componente de la unión, ya fuera rápido o lento. A pesar de ser mucho más rápido en la unión en sí, VectorH, en este caso, realizó todo el proceso de materialización en aproximadamente el mismo tiempo que Hive porque gran parte del tiempo era escribir el conjunto de resultados, que era el mismo para ambos productos.

Una vez construido, ejecutamos las consultas contra la materialización, VectorH fue aproximadamente dos veces más rápido que el otro producto. Recuerde para la lectura posterior que la materialización es exponencial en tamaño a las tablas de origen.

Aunque impresionantes, estos resultados palidecen en comparación con lo que les contaré a continuación sobre el enfoque a la carta de Actian.

Análisis en tiempo real con Actian VectorH On-Demand

Después de realizar la prueba de materialización intermedia de la vieja escuela, quisimos mostrar al cliente una forma mejor. Demostramos que con VectorH, las consultas contra los datos de base (sin paso de materialización intermedia) con la unión realizada bajo demanda, eran órdenes de magnitud más rápidas.

A continuación se muestran los datos sin procesar capturados en los sistemas Hive y VectorH del cliente para los resultados de una sola ejecución. Obsérvese que las pruebas de VectorH se realizaron en un clúster de la mitad de tamaño que el clúster de Hive. VectorH presenta excelentes características de escalabilidad lineal, por lo que normalizamos los resultados para una plataforma equivalente.

Como se mencionó anteriormente, una materialización estaba en el mismo parque de pelota, VectorH fue dos veces más rápido en las consultas contra una materialización. Sin embargo, lo más interesante son los casos en los que Hive fue incapaz de completar cualquier escenario de unión bajo demanda y Actian VectorH mostró una velocidad tremenda.

Las ventajas anteriores son para ejecuciones únicas. Qué ocurre en situaciones reales con cientos de consultas de clientes y actualización continua de datos?

A continuación se muestra una tabla que muestra lo que sucede con sólo 100 y 200 consultas de clientes subsiguientes, además de una actualización de los datos del cliente. Observe que con la velocidad de VectorH, la solución antigua, incluso utilizando pre-materializaciones es siempre más lenta, incurre en tiempo de re-materialización, y simplemente nunca se pondrá al día. El enfoque de Actian VectorH aplasta al competidor en rendimiento. Esto es además de los otros beneficios de los resultados que están en los datos actuales en lugar de datos antiguos, el ahorro de espacio en disco, menos administración, y así sucesivamente.

Tenga en cuenta también, que estos resultados ni siquiera permiten simultanéité. VectorH tiene simultanéité increíble. Los números observados arriba serían incluso mejores para VectorH si hubiéramos capturado tales números en una situación simultánea.

Conclusión

En la solución a petición, los resultados de las consultas reflejaban SIEMPRE los datos actuales y no los resultados de una materialización obsoleta, lo que permitía realizar análisis en tiempo real y obtener resultados más precisos.

Los analistas ya no tenían que esperar a que se creara una instantánea y sus uniones podían hacerse ad hoc.

El rendimiento neto fue significativamente más rápido que contra una preagregación gigante porque cada consulta escanea sólo los datos que necesita en lugar de cada fila en una materialización gigantesca, lo que resulta en menos I/O costoso y sin temps d'arrêt para reconstruir la materialización intermedia.

Las vistas se utilizaron para ocultar la lógica de unión a los usuarios finales, simplificando así las consultas. Al no haber duplicación de datos por materialización, el espacio de almacenamiento se reduce al mínimo.

Sin un motor JOIN rápido como VectorH, este enfoque suele ser poco práctico para conjuntos de datos muy grandes.

Próximos pasos

¿Desea obtener más información sobre Actian VectorH?

También puede descargar y probar Actian Vector usted mismo. No le decepcionará, y si necesita ayuda para descifrar las cosas, simplemente pregunte a la Comunidad o póngase en contacto con eval@actian.com para solicitar una evaluación de 30 días de VectorH con Soporte Empresarial gratuito.

Sobre Mary Schulte

Mary Schulte es ingeniera de ventas sénior en Actian y cuenta con décadas de experiencia con potentes proveedores de bases de datos como Informix y Netezza. Ha escrito miles de líneas de Informix 4GL y ESQL/C para clientes de todo el mundo, incluida la innovadora implementación de datablade de American Airlines. Mary ha impartido innumerables sesiones de formación, ayudando a las organizaciones a optimizar sus entornos de bases de datos. Conéctese con ella en LinkedIn https://www.linkedin.com/in/mary-schulte-2265081. Sus publicaciones en el blog de Actian se centran en el rendimiento de las consultas, bases de datos analíticas como Vector y consejos prácticos para aprovechar Informix. Consulte sus artículos para obtener orientación experta.