Dremio: análisis de datos más simple y rápido

Jacques Nadeau es el CTO y cofundador de Dremio.

Ahora es un buen momento para ser desarrollador. Durante la última década, las decisiones sobre tecnología han pasado de la sala de juntas a los desarrolladores innovadores, que están construyendo con código abierto y tomando decisiones basadas en los méritos del proyecto subyacente en lugar de las relaciones comerciales proporcionadas por un proveedor. Han surgido nuevos proyectos que se centran en hacer que los desarrolladores sean más productivos y que son más fáciles de administrar y escalar. Esto es cierto para prácticamente todas las capas de la pila de tecnología. El resultado es que los desarrolladores de hoy tienen oportunidades casi ilimitadas para explorar nuevas tecnologías, nuevas arquitecturas y nuevos modelos de implementación.

En cuanto a la capa de datos en particular, los sistemas NoSQL como MongoDB, Elasticsearch y Cassandra han superado los límites en términos de agilidad, escalabilidad y rendimiento para aplicaciones operativas, cada una con un modelo de datos y un enfoque de esquema diferentes. A lo largo del camino, muchos equipos de desarrollo se trasladaron a un modelo de microservicios, distribuyendo datos de aplicaciones a través de muchos sistemas subyacentes diferentes.

En términos de análisis, las fuentes de datos antiguas y nuevas se han abierto camino en una combinación de almacenes de datos tradicionales y lagos de datos, algunos en Hadoop, otros en Amazon S3. Y el auge de la plataforma de transmisión de datos de Kafka crea una forma completamente diferente de pensar sobre el movimiento de datos y el análisis de datos en movimiento.

Con datos en tantas tecnologías diferentes y formatos subyacentes, el análisis de datos modernos es difícil. Las herramientas de análisis y BI como Tableau, Power BI, R, Python y los modelos de aprendizaje automático se diseñaron para un mundo en el que los datos viven en una única base de datos relacional de alto rendimiento. Además, los usuarios de estas herramientas (analistas comerciales, científicos de datos y modelos de aprendizaje automático) desean tener la capacidad de acceder, explorar y analizar datos por sí mismos, sin depender de TI.

Presentamos el tejido de datos de Dremio

Las herramientas de BI, los sistemas de ciencia de datos y los modelos de aprendizaje automático funcionan mejor cuando los datos se encuentran en una única base de datos relacional de alto rendimiento. Desafortunadamente, ahí no es donde viven los datos hoy. Como resultado, TI no tiene más remedio que cerrar esa brecha mediante una combinación de desarrollo ETL personalizado y productos patentados. En muchas empresas, la pila de análisis incluye las siguientes capas:

  • Puesta en escena de datos . Los datos se mueven desde varias bases de datos operativas a una única área de preparación, como un clúster de Hadoop o un servicio de almacenamiento en la nube (por ejemplo, Amazon S3).
  • Almacén de datos . Si bien es posible ejecutar consultas SQL directamente en Hadoop y el almacenamiento en la nube, estos sistemas simplemente no están diseñados para ofrecer un rendimiento interactivo. Por lo tanto, un subconjunto de los datos generalmente se carga en un almacén de datos relacional o en una base de datos MPP.
  • Cubos, tablas de agregación y extractos de BI . Para proporcionar un rendimiento interactivo en grandes conjuntos de datos, los datos deben agregarse previamente y / o indexarse ​​construyendo cubos en un sistema OLAP o tablas de agregación materializadas en el almacén de datos.

Esta arquitectura de múltiples capas presenta muchos desafíos. Es complejo, frágil y lento, y crea un entorno en el que los consumidores de datos dependen por completo de TI.

Dremio introduce un nuevo nivel en el análisis de datos que llamamos tejido de datos de autoservicio. Dremio es un proyecto de código abierto que permite a los analistas de negocios y científicos de datos explorar y analizar cualquier dato en cualquier momento, independientemente de su ubicación, tamaño o estructura. Dremio combina una arquitectura de escalamiento horizontal con ejecución y aceleración en columnas para lograr un rendimiento interactivo en cualquier volumen de datos, al tiempo que permite a TI, científicos de datos y analistas de negocios dar forma a los datos sin problemas de acuerdo con las necesidades del negocio.

Construido sobre Apache Arrow, Apache Parquet y Apache Calcite

Dremio utiliza almacenamiento y ejecución en columnas de alto rendimiento, impulsado por Apache Arrow (columna en memoria) y Apache Parquet (columna en disco). Dremio también utiliza Apache Calcite para el análisis de SQL y la optimización de consultas, basándose en las mismas bibliotecas que muchos otros motores basados ​​en SQL, como Apache Hive.

Apache Arrow es un proyecto de código abierto que permite el procesamiento e intercambio de datos en memoria en columnas. Arrow fue creado por Dremio e incluye colaboradores de varias compañías, incluidas Cloudera, Databricks, Hortonworks, Intel, MapR y Two Sigma.

Dremio es el primer motor de ejecución construido desde cero en Apache Arrow. Internamente, los datos en la memoria se mantienen fuera del montón en el formato Arrow, y pronto habrá una API que devuelve los resultados de las consultas como búferes de memoria Arrow.

Una variedad de otros proyectos también han adoptado Arrow. Python (Pandas) y R se encuentran entre estos proyectos, lo que permite a los científicos de datos trabajar de manera más eficiente con los datos. Por ejemplo, Wes McKinney, creador de la popular biblioteca Pandas, demostró recientemente cómo Arrow permite a los usuarios de Python leer datos en Pandas a más de 10 GB / s.

Cómo Dremio habilita los datos de autoservicio

Además de la capacidad de trabajar de forma interactiva con sus conjuntos de datos, los ingenieros de datos, los analistas de negocios y los científicos de datos también necesitan una forma de curar los datos para que sean adecuados para las necesidades de un proyecto específico. Este es un cambio fundamental del modelo centrado en TI, donde los consumidores de datos inician una solicitud de un conjunto de datos y esperan que TI cumpla con su solicitud semanas o meses después. Dremio habilita un modelo de autoservicio, donde los consumidores de datos utilizan las capacidades de conservación de datos de Dremio para descubrir, seleccionar, acelerar y compartir datos de forma colaborativa sin depender de TI.

Se puede acceder a todas estas capacidades a través de una interfaz de usuario moderna, intuitiva y basada en web:

  • Descubrir . Dremio incluye un catálogo de datos unificado donde los usuarios pueden descubrir y explorar conjuntos de datos físicos y virtuales. El catálogo de datos se actualiza automáticamente cuando se agregan nuevas fuentes de datos y a medida que evolucionan las fuentes de datos y los conjuntos de datos virtuales. Todos los metadatos están indexados en un índice de búsqueda de alto rendimiento y expuestos a los usuarios a través de la interfaz de Dremio.
  • Cura . Dremio permite a los usuarios seleccionar datos mediante la creación de conjuntos de datos virtuales. Se admiten una variedad de transformaciones de apuntar y hacer clic, y los usuarios avanzados pueden utilizar la sintaxis SQL para definir transformaciones más complejas. A medida que las consultas se ejecutan en el sistema, Dremio aprende sobre los datos, lo que le permite recomendar diversas transformaciones, como uniones y conversiones de tipos de datos.
  • Dremio es capaz de acelerar los conjuntos de datos hasta 1000 veces más que el rendimiento del sistema de origen. Los usuarios pueden votar por conjuntos de datos que creen que deberían ser más rápidos, y la heurística de Dremio considerará estos votos para determinar qué conjuntos de datos acelerar. Opcionalmente, los administradores del sistema pueden determinar manualmente qué conjuntos de datos acelerar.
  • Dremio permite a los usuarios compartir datos de forma segura con otros usuarios y grupos. En este modelo, un grupo de usuarios puede colaborar en un conjunto de datos virtual que se utilizará para un trabajo analítico en particular. Como alternativa, los usuarios pueden cargar sus propios datos, como hojas de cálculo de Excel, para unirse a otros conjuntos de datos del catálogo empresarial. Los creadores de conjuntos de datos virtuales pueden determinar qué usuarios pueden consultar o editar sus conjuntos de datos virtuales. Es como Google Docs para sus datos.

Cómo funciona la aceleración de datos de Dremio

Dremio utiliza representaciones físicas altamente optimizadas de los datos de origen llamadas Reflejos de datos. Reflection Store puede vivir en HDFS, MapR-FS, almacenamiento en la nube como S3 o almacenamiento de conexión directa (DAS). El tamaño de Reflection Store puede exceder el de la memoria física. Esta arquitectura permite a Dremio acelerar más datos a un costo menor, lo que resulta en una tasa de aciertos de caché mucho mayor en comparación con las arquitecturas tradicionales de solo memoria. El optimizador basado en costos utiliza automáticamente las reflexiones de datos en el momento de la consulta.

Los reflejos de datos son invisibles para los usuarios finales. A diferencia de los cubos OLAP, las tablas de agregación y las extracciones de BI, el usuario no se conecta explícitamente a un reflejo de datos. En cambio, los usuarios emiten consultas contra el modelo lógico y el optimizador de Dremio acelera automáticamente la consulta al aprovechar las reflexiones de datos que son adecuadas para la consulta según el análisis de costos del optimizador.

Cuando el optimizador no puede acelerar la consulta, Dremio utiliza su motor de ejecución distribuida de alto rendimiento, aprovechando el procesamiento en memoria en columnas (a través de Apache Arrow) y pushdown avanzados en las fuentes de datos subyacentes (cuando se trata de fuentes RDBMS o NoSQL).

Cómo maneja Dremio las consultas SQL

Las aplicaciones cliente envían consultas SQL a Dremio a través de ODBC, JDBC o REST. Una consulta puede involucrar uno o más conjuntos de datos, que potencialmente residen en diferentes fuentes de datos. Por ejemplo, una consulta puede ser una combinación entre una tabla de Hive, Elasticsearch y varias tablas de Oracle.

Dremio utiliza dos técnicas principales para reducir la cantidad de procesamiento requerido para una consulta:

  • Pushdowns sobre la fuente de datos subyacente . El optimizador considerará las capacidades de la fuente de datos subyacente y los costos relativos. Luego generará un plan que realiza las etapas de la consulta, ya sea en la fuente o en el entorno de ejecución distribuida de Dremio para lograr el plan general más eficiente posible.
  • Aceleración mediante reflejos de datos . El optimizador usará reflejos de datos para partes de la consulta cuando esto produzca el plan general más eficiente. En muchos casos, la consulta completa se puede atender desde Reflejos de datos, ya que pueden ser órdenes de magnitud más eficientes que procesar consultas en la fuente de datos subyacente.

Consultas pushdown

Dremio puede impulsar el procesamiento hacia fuentes de datos relacionales y no relacionales. Las fuentes de datos no relacionales normalmente no admiten SQL y tienen capacidades de ejecución limitadas. Un sistema de archivos, por ejemplo, no puede aplicar predicados o agregaciones. MongoDB, por otro lado, puede aplicar predicados y agregaciones, pero no admite todas las uniones. El optimizador de Dremio comprende las capacidades de cada fuente de datos. Cuando sea más eficiente, Dremio enviará la mayor cantidad posible de consultas a la fuente subyacente y realizará el resto en su propio motor de ejecución distribuido.

Descarga de bases de datos operativas

La mayoría de las bases de datos operativas están diseñadas para cargas de trabajo optimizadas para escritura. Además, estas implementaciones deben abordar estrictos SLA, ya que cualquier tiempo de inactividad o rendimiento degradado puede afectar significativamente al negocio. Como resultado, los sistemas operativos se aíslan con frecuencia del procesamiento de consultas analíticas. En estos casos, Dremio puede ejecutar consultas analíticas utilizando Data Reflections, que proporcionan el procesamiento de consultas más eficiente posible al tiempo que minimizan el impacto en el sistema operativo. Las reflexiones de datos se actualizan periódicamente en función de las políticas que se pueden configurar tabla por tabla.

Fases de ejecución de consultas

La vida de una consulta incluye las siguientes fases:

  1. El cliente envía la consulta al coordinador a través de ODBC / JDBC / REST
  2. Planificación
    1. El coordinador analiza la consulta en el modelo relacional universal de Dremio
    2. El coordinador considera las estadísticas disponibles sobre las fuentes de datos para desarrollar un plan de consulta, así como las habilidades funcionales de la fuente.
  3. El coordinador reescribe el plan de consultas para usar
    1. los reflejos de datos disponibles, teniendo en cuenta el orden, la partición y la distribución de los reflejos de datos y
    2. las capacidades disponibles de la fuente de datos
  4. Ejecución
  1. Los ejecutores leen datos en búferes Arrow desde fuentes en paralelo
    1. Los ejecutores ejecutan el plan de consulta reescrito.
    2. Un ejecutor fusiona los resultados de uno o más ejecutores y transmite los resultados finales al coordinador
  1. El cliente recibe los resultados del coordinador

Tenga en cuenta que los datos pueden provenir de Data Reflections o de las fuentes de datos subyacentes. Al leer de una fuente de datos, el ejecutor envía las consultas nativas (por ejemplo, MongoDB MQL, Elasticsearch Query DSL, Microsoft Transact-SQL) según lo determinado por el optimizador en la fase de planificación.

Todas las operaciones de datos se realizan en el nodo ejecutor, lo que permite que el sistema escale a muchos clientes simultáneos utilizando solo unos pocos nodos coordinadores.

Ejemplo de inserción de consultas

Para ilustrar cómo Data Fabric se adapta a su arquitectura de datos, echemos un vistazo más de cerca a la ejecución de una consulta SQL en una fuente que no es compatible con SQL.

Una de las fuentes de datos modernas más populares es Elasticsearch. Hay mucho que me gusta de Elasticsearch, pero en términos de análisis no es compatible con SQL (incluidas las uniones de SQL). Eso significa que herramientas como Tableau y Excel no se pueden usar para analizar datos de aplicaciones creadas en este almacén de datos. Existe un proyecto de visualización llamado Kibana que es popular para Elasticsearch, pero Kibana está diseñado para desarrolladores. No es realmente para usuarios comerciales.

Dremio facilita el análisis de datos en Elasticsearch con cualquier herramienta basada en SQL, incluido Tableau. Tomemos, por ejemplo, la siguiente consulta SQL para datos comerciales de Yelp, que se almacena en JSON:

SELECT estado, ciudad, nombre, review_count

DESDE elastic.yelp.business

DÓNDE

  estado NO EN ('TX', 'UT', 'NM', 'NJ') Y

  review_count> 100

ORDER BY review_count DESC, estado, ciudad

LÍMITE 10

Dremio compila la consulta en una expresión que Elasticsearch puede procesar: