Esta entrada de blog se publicó en Hortonworks.com antes de la fusión con Cloudera. Es posible que algunos enlaces, recursos o referencias ya no sean precisos.
Un agradecimiento especial a Bill Preachuk y Brandon Wilson por revisar y brindar su experiencia
Introducción
El almacenamiento en columnas es un tema del que se habla a menudo en el mundo del almacenamiento y el procesamiento de big data en la actualidad:hay cientos de formatos, estructuras y optimizaciones en los que puede almacenar sus datos e incluso más formas de recuperarlos según lo que planee hacer. con eso. Esta plétora de opciones surgió debido a la necesidad no solo de ingerir datos rápidamente usando las herramientas de procesamiento transaccional en línea (OLTP), sino también por la necesidad de consumir y analizar datos con mayor eficiencia usando el procesamiento analítico en línea (OLAP). instrumentos. Miles de casos de uso diferentes tienen cada uno sus propias necesidades específicas y, por lo tanto, han surgido muchas opciones. Por ejemplo, leer los datos del mercado de valores requiere una mentalidad completamente diferente a la de analizar las métricas de calidad en una línea de fabricación. Con todas estas opciones, es fácil perderse al navegar hacia su objetivo final:elegir una herramienta que funcione para usted.
HDP incorpora una serie de soluciones de almacenamiento, cada una de las cuales está hecha a medida para casos de uso específicos. Queremos comenzar esta serie de blogs hablando de las siguientes tres herramientas/motores y sus formatos de almacenamiento asociados:
- Apache Hive usa Apache ORC como un formato de almacenamiento en columnas eficiente que permite el rendimiento para el procesamiento de consultas OLAP y SQL profundas
- Apache Phoenix/Apache HBase juntos forman una base de datos OLTP que permite consultas en tiempo real sobre miles de millones de registros y ofrece búsquedas aleatorias rápidas basadas en claves, así como actualizaciones
- Apache Druid es un almacén de datos de alto rendimiento que permite el análisis de series temporales en tiempo real en flujos de eventos y análisis OLAP sobre datos históricos con una latencia extremadamente baja
En este artículo, tenemos la intención de articular qué herramienta es adecuada para un caso de uso determinado, comparar y contrastar las diversas herramientas y brindar una guía básica para elegir la herramienta o el conjunto de herramientas adecuado para abordar su caso de uso.
Esto es muy parecido a jugar Tetris:cada pieza tiene un nicho diferente, pero cada una agrega un valor único a la estructura más grande
Procesamiento de Big Data y sus similitudes
Los datos se agrupan por columnas en el almacenamiento porque a menudo intentamos reducir las sumas, los promedios u otros cálculos en una columna específica. Imagine que es una aerolínea que intenta comprender cuánto combustible darle a un avión cuando está acoplado; es posible que desee calcular el promedio de millas recorridas por cada vuelo a partir de una tabla de datos de viaje de vuelo. Esto requeriría realizar la función promedio en una sola columna. Almacenaríamos estos datos en formato de columnas porque las lecturas secuenciales en el disco son rápidas, y lo que queremos hacer en este caso es leer una columna completa de la tabla secuencialmente (y luego realizar un cálculo promedio).
Existen muchas diferencias entre estos motores, pero independientemente del motor de procesamiento de datos que elija, se beneficiará de algunos puntos en común. Uno de ellos es la función compartida de almacenamiento en caché. Cada uno de estos tres motores trabaja de la mano con el almacenamiento en caché en memoria para aumentar el rendimiento de su procesamiento sin cambiar el formato de almacenamiento de back-end, logrando tiempos de respuesta inferiores a un segundo. HBase tiene BlockCache, Hive tiene la capa LLAP IO y Druid tiene varias opciones de almacenamiento en caché en memoria. A menudo, la parte costosa de atender una consulta implica analizar la solicitud e ir al almacenamiento persistente para recuperar el subconjunto de datos que le interesan al usuario. Sin embargo, ese paso completo se puede evitar cuando se usa un mecanismo de almacenamiento en memoria caché como muchos formatos de almacenamiento en columnas. uso, lo que permite que el proceso llegue a la memoria de los datos consultados previamente en fracciones de segundo. Volvamos a nuestro ejemplo de cálculo de combustible:supongamos que acabo de pedir el promedio de millas voladas para todos los vuelos de mi empresa, pero me doy cuenta de que los vuelos nacionales tendrán requisitos de combustible muy diferentes a los de los vuelos internacionales. Entonces querré filtrar mi consulta anterior con una cláusula WHERE country='US' (o código de país equivalente). Este patrón de consulta es muy común para la exploración de datos. Dado que ya tenemos los datos de la consulta anterior en la memoria, los resultados de esta consulta se pueden devolver sin tener que realizar una costosa lectura de disco.
La estructura de la capa LLAP de Hive:parte de su espacio de memoria se utiliza para el almacenamiento en caché, mientras que el almacenamiento a largo plazo se realiza en HDFS. HBase y Druid también tienen un concepto similar de caché y almacenamiento.
Existe otra similitud en los accesos directos que utiliza cada uno de estos motores para concentrarse en los datos específicos que se consultan. HBase tiene acceso aleatorio O(1) basado en HashMap, Druid usa índices de mapa de bits invertidos para averiguar qué valores de columna están en qué filas, y las tablas de Hive tienen estadísticas, índices y particiones para acortar el acceso a los datos. Estas características permiten que los motores combinen la forma en que se almacenan los datos con la forma en que se accede a ellos, lo que permite un análisis rápido mientras optimiza la eficiencia del hardware y aprovecha al máximo la CPU y la RAM disponibles.
La última similitud es la preparación empresarial de cada uno de estos motores. En el lado de la redundancia de datos, estos tres motores usan HDFS como su mecanismo de almacenamiento profundo; el factor de replicación HDFS de 3x garantiza que existan copias de los datos en otros lugares, incluso si dos nodos fallan simultáneamente. Los datos se pueden volver a replicar inmediatamente una vez más en nodos saludables para mantener la redundancia. Sobre el tema de la tolerancia a fallas dentro de un clúster, cada herramienta llena el vacío de alguna manera. HBase ofrece replicación de regiones, Druid tiene duplicación de componentes maestros y trabajadores, así como un mayor factor de replicación en HDFS, y Hive tiene HDFS junto con la lógica tolerante a fallas del marco YARN. La preparación empresarial garantiza que estos motores sean resistentes a fallas y estén listos para funcionar en producción desde el primer día.
Las diferencias entre nuestros motores de procesamiento de Big Data
¿Cuál es la mejor manera de ingerir datos? Una vez que haya ingerido sus datos, ¿cómo puede obtener información rápidamente de ellos? Profundicemos en cómo estos tres grandes motores de procesamiento de datos respaldan este conjunto de tareas de procesamiento de datos
Estos motores a veces se agrupan mentalmente y se consideran de manera similar debido a su capacidad para almacenar y procesar Big Data, pero como veremos, se eligen para casos de uso y propósitos que se adaptan específicamente a sus puntos fuertes. Verá que la colección de herramientas que contiene Hortonworks Data Platform se adapta bien a cualquier carga de trabajo de big data que pueda lanzar, especialmente con HDP 3.0 y las capacidades de base de datos en tiempo real que hemos introducido.
Hive es el motor OLAP que representa la mayor variedad de casos de uso, y generalmente emplea el sistema de archivos distribuidos de Hadoop (HDFS) como su capa de almacenamiento para permitir el almacenamiento de casi cualquier tipo de datos. Puede consultar, procesar y analizar datos de texto no estructurados, archivos CSV, XML, JSON semiestructurado, Parquet en columnas y muchos otros formatos. Hive también admite medios de almacenamiento alternativos, como almacenamiento en la nube, Isilon y otros. El estándar de almacenamiento de facto para Hive es ORC, que optimiza de manera más eficiente y aprovecha los beneficios del almacenamiento en columnas. Una vez convertidos a ORC, sus datos se comprimen y las columnas de su tabla se almacenan secuencialmente en el disco, lo que permite que la capa de almacenamiento en caché en memoria de Hive, LLAP, extraiga los datos del disco una vez y los sirva desde la memoria varias veces. La combinación de Hive+LLAP se usa para análisis ad-hoc, cálculo de grandes agregados e informes de baja latencia. Un gran caso de uso para Hive es ejecutar diariamente un conjunto de informes de panel para los usuarios; las consultas repetitivas no solo aprovechan la caché LLAP, sino también la función 'Caché de resultados de consultas', que devuelve resultados casi instantáneos si los datos no han cambiado (Aparte:la caché de resultados de consultas es una función disponible en Hive 3.0, lanzada en HDP 3.0). Además de eso, un Hive Data Warehouse es un gran uso del análisis ad-hoc que Hive es capaz de hacer; los usuarios pueden unir datos, ejecutar consultas simultáneas y ejecutar transacciones ACID. Considere que Hive es un conector SQL de todos los oficios en ese sentido, mientras que los otros dos motores brindan un rendimiento extremadamente rápido para casos de uso de nicho específico.
Nuestro segundo motor, HBase, es un almacén de clave-valor distribuido que tiene capacidades aleatorias de lectura, escritura, actualización y eliminación. HBase (una variante de NoSQL) está diseñado para ser un motor OLTP, lo que permite una arquitectura de operaciones transaccionales de gran volumen:piense en plataformas de mensajería con mensajes constantes que se intercambian entre usuarios o transacciones que se generan en un sistema financiero. HBase es extremadamente eficiente para traer datos rápidamente, almacenarlos y devolverlos:inserciones/actualizaciones/eliminaciones aleatorias de latencia ultrabaja. Para lo que no está diseñado es para agregar y unir datos:esta funcionalidad se logra a través de Phoenix, una capa SQL y un motor sobre HBase, pero no se recomienda para grandes cantidades de datos, ya que los datos no están estructurados de manera que se logre un nivel óptimo. rendimiento (utilice Hive en su lugar). En resumen, HBase es excelente para procesar grandes volúmenes de operaciones de creación, actualización y eliminación, pero se queda corto cuando llega el momento de presentar esos datos en un formato consumible para los usuarios.
Finalmente, Druid es el tercer motor y es adecuado para cargas de trabajo de series temporales OLAP de baja latencia, así como para la indexación en tiempo real de transmisión de datos. Druid proporciona consultas OLAP a velocidad de cubo para su clúster. La naturaleza de serie temporal de Druid es una piedra angular del motor; está diseñado de esta manera porque el tiempo es un filtro principal cuando se analizan datos basados en el tiempo. Piense en cuando está analizando los tiempos de vuelo para reservar un viaje:quiero saber cuál es el vuelo de menor costo a Italia dentro de este marco de tiempo particular de 2 semanas. Druid se ajusta al nicho de ser muy rápido para ingerir datos y localizarlos cuando se solicita. Por otro lado, también permite a los usuarios comerciales y analistas consultar los datos y comprenderlos a través de Superset, una capa de visualización estrechamente relacionada con Druid. Druid sobresale en la identificación de un puñado de filas de datos entre cientos de millones o miles de millones en menos de un segundo, y también sobresale en el cálculo de valores agregados sobre ese mismo volumen de datos extremadamente rápido. Sin embargo, no realiza uniones y, por lo tanto, no se puede utilizar para combinar conjuntos de datos para el análisis. Si planea analizar una combinación de conjuntos de datos en Druid, sería prudente unir previamente los datos antes de insertarlos en Druid o usar Hive (y las tablas de Hive respaldadas por Druid) para realizar uniones. Dicho en otras palabras, Druid encaja bien en el papel de ser la última parada para sus datos después de que se hayan procesado y transformado en la forma en que los usuarios comerciales accederán a ellos. Druid es excelente para los analistas de negocios, ya que pueden iniciar sesión en Superset y visualizar las métricas en forma de tablero sin tener que escribir ninguna consulta; simplemente usan una GUI para seleccionar la fuente de datos de la consulta y los filtros. También es excelente como fuente de datos de respaldo para los paneles del sistema, ya sea operativo o analítico, debido a sus rápidos tiempos de consulta.
Aquí hay una forma en que puede desglosar la toma de decisiones sobre qué herramienta usar para su carga de trabajo:
| HBase | Colmena | Druida |
| Acceso aleatorio de latencia ultrabaja (búsqueda basada en claves) | ACID, base de datos en tiempo real, EDW | OLAP de baja latencia, consultas simultáneas |
| OLTP de gran volumen | Interfaz SQL unificada, JDBC | Agregaciones, desgloses |
| Actualizaciones | Informes, por lotes | Series temporales |
| Eliminaciones | Uniones, grandes agregados, ad-hoc | Ingesta en tiempo real |
SQL unificado
Hemos discutido varios sistemas hasta este punto y cada uno tiene sus propias formas de acceder a sus datos. Esto es excelente cuando los usuarios saben cómo funcionan todas estas herramientas, pero es posible que se encuentren en una curva de aprendizaje antes de que puedan alcanzar la productividad total si provienen de un mundo de SQL, SQL y más SQL como lo hacen la mayoría de los analistas. Es por eso que hemos tratado de hacer esta interacción lo más simple posible; con Hive 3.0 en HDP 3.0, puede usar la sintaxis HQL similar a SQL de Hive para interactuar con tantos almacenes de datos diferentes en este espacio. Hive se puede usar como un portal para acceder y modificar Druid, HBase y cualquier cosa que proporcione una interfaz y un controlador JDBC. Hive se puede usar para administrar una tarea de ingesta de Druid que escucha a Kafka, lo que proporciona una forma sencilla de ingesta en tiempo real. Y, finalmente, Hive se puede usar para reunirlo todo:almacene sus datos donde tenga más sentido y acceda a ellos desde un solo lugar. Únalos, tal vez incluso almacene ese nuevo resultado en otra ubicación. Las posibilidades son muchas, pero la interfaz se ha simplificado mucho para que su base de usuarios pueda pasar menos tiempo aprendiendo otra herramienta y más tiempo aportando valor al negocio.
Conclusión
Hive, Druid y HBase tienen diferentes lugares en una arquitectura de datos como hemos visto en el análisis anterior. Sin embargo, son herramientas complementarias; podría ingerir datos transaccionales con HBase con sus búsquedas rápidas, mover esos datos a Druid para un desglose/agregación rápidos, y hacer que Hive integre los dos junto con sus propios datos administrados por Hive para permitir que los usuarios combinen datos dondequiera que residan para una vista única y una gran cantidad de ideas. Con este enfoque, Druid almacena datos a los que se puede acceder por sí solo, pero Hive aumenta esa funcionalidad, que puede extraer datos de Druid y unirlos con datos adicionales. Agregue a esto las principales mejoras que han entrado en juego con Hive 3.0, entre las que se encuentran las vistas materializadas, las integraciones mejoradas con Druid y muchos otros motores, y una mayor funcionalidad similar a la de un almacén de datos, y tiene un grupo. de herramientas que pueden resolver casi cualquier caso de uso.
Arquitecturas como la mencionada aportan lo mejor de cada herramienta para optimizar su flujo de trabajo y, al mismo tiempo, abstraer los detalles para aquellos usuarios que solo se preocupan por los datos. Los arquitectos configuraron las canalizaciones, colocando los datos donde pertenecen según el caso de uso. Eso luego lleva a los analistas de datos, que usan Hive como su interfaz única para obtener conocimientos y perspectivas. Pueden encontrar patrones interesantes en los datos en lugar de preocuparse por dónde se almacenan los datos o aprender una nueva sintaxis para acceder a ellos; le sorprendería saber con qué frecuencia vemos esto en el mundo.
En este punto, hemos demostrado las fortalezas, debilidades y mejores prácticas de cada herramienta; Esperamos que se vaya con una mejor comprensión de lo que encaja en cada lugar, así como con el panorama general de la combinación de los tres para obtener los mejores resultados.
