Inteligencia de Negocios

¿Es la arquitectura de Lakehouse una gran estandarización en el análisis de datos?

single-image


Haga clic aquí para obtener más información sobre el autor Arsalan Farooq.

No creo que sea una exageración decir que el análisis de datos ha demostrado su eficacia durante la última década. Lo que comenzó en la década de 1990 y principios de la de 2000 como un intento de extraer información empresarial de los datos transaccionales se ha convertido ahora en una función existencialmente crítica en la mayoría de las organizaciones. Más allá de los casos de uso tradicionales de OLTP / OLAP, ahora hay almacenamiento de datos en petabytes, análisis de transmisión, ciencia de datos, inteligencia artificial y aprendizaje automático, etc.

Al mismo tiempo, ha habido una explosión de nuevas herramientas, tecnologías, arquitecturas y principios de diseño para respaldar estos nuevos casos de uso: procesamiento por lotes con «big data», bases de datos en columnas, almacenes de valores clave, almacenes de datos en la nube, lagos de datos, datos arquitecturas de canalización y lambda, por nombrar solo algunas llamadas.

Recientemente ha surgido un concepto nuevo e interesante en este paisaje relativamente denso y maduro. La arquitectura de Lakehouse fue propuesta oficialmente por Armbrust, Ghodsi, Xin y Zaharia (Databricks, UC Berkeley y la Universidad de Stanford) a principios de este año e intenta estandarizar las áreas previamente diferentes de OLAP / almacenes clásicos y análisis avanzado de transmisión en tiempo real. Si esto se hiciera según lo previsto, sería un gran problema para el análisis de datos.

Para entender por qué, demos un paso atrás y veamos cómo llegamos a donde estamos hoy.

La dualidad intrínseca en la arquitectura de datos

Siempre que queremos guardar datos para su posterior recuperación, nos enfrentamos a una decisión fundamental: ¿debemos optimizar el diseño para el rendimiento de escritura o lectura? Esta «dualidad» es inherente a todos los esquemas de almacenamiento de datos, incluidos RDBMS, sistemas de archivos, almacenamiento en bloque, almacenamiento de objetos, etc.

A medida que hemos desarrollado esquemas, tecnologías y arquitecturas de almacenamiento de datos cada vez más complejos a lo largo del tiempo, esta dualidad fundamental persiste. Esquemas OLTP frente a OLAP, tablas estrechas frente a tablas anchas, memoria de columna frente a línea, ETL frente a ELT, esquema al escribir frente al esquema al leer, etc., todos se derivan de esta elección fundamental.

Estuve en Oracle a mediados de la década de 2000 y luchábamos por encontrar la compensación adecuada dado el número cada vez mayor de casos de uso de clientes. Tuvimos un rendimiento de OLTP (centrado en escritura) de primer nivel, pero ya estábamos viendo una explosión en los volúmenes de datos OLAP (centrados en escritura) para casos de uso de BI / EDSS. Los clientes esperaban un alto rendimiento OLAP, tal como esperaban de sus cargas de trabajo OLTP. Recuerdo las discusiones atormentadas sobre esquemas de estrellas, tablas estrechas versus anchas, cardinalidad versus dimensionalidad, etc. Debido a la dificultad fundamental de conciliar la escritura y los diseños centrados en la lectura, decidí a medias en broma llamar a esta dualidad el principio de datos de Heisenberg.

Aumento de los almacenes de datos en la nube (CDW)

Hay que trazar una línea recta entre los esfuerzos de OLAP / almacén hace una década y media y los CDW de hoy. El caso de uso principal de BI / EDSS / Analytics para almacén no ha cambiado. Cantidad de datos que tiene en su contra.

El diseño del almacén de datos que utiliza un RDBMS tradicional generalmente se limita a una estructura relacional, almacenamiento orientado a filas y, además, está limitado por la computación y el almacenamiento locales. Incluso con un diseño de esquema inteligente, esto limita el alcance y el rendimiento del sistema.

La llegada de la nube eliminó la mayoría, si no todas, estas limitaciones. Los CDW pueden acceder a una potencia informática casi ilimitada para poder escalar utilizando esquemas MPP personalizados. No está limitado por el tamaño o el tipo de memoria. La mayoría son de uso gratuito de almacenes de columnas compatibles con análisis en backends de almacenamiento personalizados. Nuevamente, esto funciona bien para particiones, compresión y otros esquemas inteligentes.

El resultado final es una oferta de análisis / BI totalmente administrada que prácticamente no depende de los datos y ofrece un rendimiento de consultas incomparable. Que es no amar

Datos no estructurados y aparición de lagos de datos

Dio la casualidad de que la gran explosión de datos de principios del siglo XXI no se limitó a las fuentes de datos tradicionales. Ha habido un aumento masivo de nuevas categorías de datos: datos web, datos publicitarios, datos de instrumentación, datos de comportamiento y datos de IoT, por nombrar algunos.

La ciencia de datos (modelos AI / ML), la transmisión en tiempo real y el análisis predictivo son los principales consumidores de estas nuevas categorías de datos. Han crecido rápidamente en importancia dentro de la organización, ya que ahora compiten con BI / análisis tradicionales en términos de valor comercial.

Resulta que los CDW no son los más adecuados para estas fuentes de datos nuevas, de volumen ultra alto, alta velocidad, menor calidad y, a menudo, semi o no estructuradas. Los CDW son sistemas de esquema en escritura que requieren procesos ETL torpes durante la grabación que agregan complejidad y limitan la velocidad. También dependen de cargas por lotes regulares que agregan demasiada latencia para el análisis de transmisión en tiempo real. Después de todo, su estructura de costos no es adecuada para grandes cantidades de datos, la mayoría de los cuales puede que nunca se utilicen o no se puedan utilizar. A pesar de los intentos concertados de adaptar los CDW a estos nuevos casos de uso (pequeños / mini lotes, tablas «externas», etc.), los problemas fundamentales de rendimiento, complejidad y costo consideran que los CDW son una solución incompleta en el mejor de los casos.

Para satisfacer esta necesidad, han surgido nuevas arquitecturas que favorecen la inclusión sin problemas en almacenes económicos y luego dejan tareas costosas y complejas como la limpieza de datos, la validación y la aplicación de esquemas. Estos son los lagos de datos.

Figura 1: Arquitectura de Data Lake
Fuente: bloques de datos

Los lagos de datos generalmente se crean utilizando formatos de almacenamiento abiertos (por ejemplo, Parquet, ORC, Avro) en el almacén (por ejemplo, S3, GCS, ADLS) para permitir la máxima flexibilidad a un costo mínimo. La validación y transformación de datos se produce solo cuando los datos se recuperan para su uso. Debido a que no existen barreras para el volumen o la velocidad de ingestión, y la validación / ETL se puede realizar según sea necesario, los lagos de datos han demostrado ser muy adecuados para ingerir grandes cantidades de datos potencialmente no estructurados y de baja calidad para el consumo selectivo por parte de la ciencia de datos y las aplicaciones de análisis de transmisión en tiempo real.

Sin embargo, esto tiene un costo. La mayoría de las organizaciones se apresuraron a mantener dos verticales paralelas para su arquitectura de datos: una canalización CDW de datos estructurados optimizada para el rendimiento de las consultas (centrada en la lectura) que se ejecuta junto a un lago de datos optimizado para la ingestión (centrado en la escritura) y el procesamiento vertical de datos. ciencia y análisis de transmisión. La dualidad continúa atormentándonos.

La arquitectura Lambda: «Si no puedes superarlo, únete a ellos en la cadera»

Como era de esperar, los arquitectos de datos no tardaron mucho en buscar una forma de reducir el costo y la complejidad de mantener dos arquitecturas paralelas. Esto llevó a la arquitectura Lambda.

Figura 2: Arquitectura Lambda
S.ource: arquitectura Lambda

En una arquitectura Lambda, todavía hay dos canalizaciones paralelas para el procesamiento por lotes y de flujo, pero las páginas Ingest y Consum (API) están consolidadas y optimizadas. De esta manera, las aplicaciones de BI / análisis y análisis de transmisión se presentan con una interfaz común. Por el contrario, también se reduce la deglución en el lado receptor.

Si bien este esquema optimiza algunos atributos comunes de las canalizaciones de procesamiento por lotes y de flujo, puede proporcionar algunos beneficios adicionales, como la tolerancia a errores y la eficiencia de las consultas. Sin embargo, ha demostrado ser complejo, costoso y en sí mismo difícil de mantener. Sincronizar las dos canalizaciones, duplicar datos, manejar errores, problemas de integridad de datos, etc., a menudo ha demostrado no ser trivial.

En el mejor de los casos, la arquitectura Lambda tiene como objetivo recuperar algunas ganancias de eficiencia arquitectónica simplificando los puntos en común entre las canalizaciones por lotes y en tiempo real. Sin embargo, no se trata de dualidad. Esta no es una gran unión.

La casa en el lago

Los datos sugerentes lago y Data Warecasa
Portmanteau, «Lakehouse» recuerda una fusión real de sus dos componentes. De hecho, la idea es que, dada la segregación informática y de almacenamiento que ofrecen los entornos de nube actuales, ahora es posible combinar los esquemas de almacén y marítimo en una arquitectura única y unificada: la casa del lago.

En una casa del lago, los datos estructurados, semiestructurados y no estructurados se almacenan en formatos de archivo de código abierto con acceso directo al almacén. Sin embargo, encima de este almacén de objetos base hay una capa que proporciona una abstracción de «tabla» tradicional y puede realizar transacciones ACID.

Figura 3: Arquitectura de Lakehouse
Fuente: CIDR

Las funciones clásicas de RDBMS, como el acceso basado en SQL, las transacciones ACID, la optimización de consultas, la indexación y el almacenamiento en caché, están disponibles para las aplicaciones tradicionales de BI / Analytics a través de este nivel. Al mismo tiempo, los casos de uso de Data Science / ML / Streaming Analytics conservan el acceso directo a los datos sin procesar. Mientras tanto, dado el almacenamiento de mercancías y los formatos abiertos, la ingesta de datos sigue siendo una perspectiva sencilla y económica.

Los efectos son asombrosos. Lakehouse cubre toda la gama de casos de uso, desde BI / EDSS / Analytics hasta Data Science / ML / Streaming Analytics en una arquitectura coherente. No más diferenciación entre el lago de datos y el almacén, no más separación BI / ML, no más duplicación de datos, no más canalizaciones paralelas torpes en las arquitecturas Lambda.

Entonces, Fait Accompli Entonces … ¿Unión al fin?

No, todavía no. El diablo está en los detalles.

Si bien los esfuerzos recientes, como el Proyecto Delta Lake y el Motor Delta de Databricks, demuestran la viabilidad de los elementos clave de una arquitectura Lakehouse, estas implementaciones están lejos de ser completas y quedan preguntas importantes.

Por ejemplo, ¿pueden la abstracción de la tabla administrada y sus implementaciones cumplir con las expectativas de rendimiento a gran escala? ¿Se pueden proporcionar funciones clave como gobernanza, controles de acceso detallados e integridad de datos mientras se mantiene el rendimiento y la compresión de la arquitectura? ¿Qué pasa con las funciones sofisticadas de SQL y DML en las que confían los veteranos del almacenamiento de datos y sin las cuales no se moverán? Es demasiado pronto para sacar una conclusión final y emitir un juicio.

No hay duda de que habrá una carrera armamentista entre los proveedores que intentan llevar una oferta de Lakehouse al mercado. La propuesta de valor y el impacto de una plataforma de análisis de datos unificada en el mercado son demasiado importantes para pasarlos por alto. Delta Engine de Databricks, AWS Lake Formation y Azure Synapse de Microsoft ya están promoviendo el análisis unificado. Seguramente otros seguirán pronto.

A pesar de todas las preguntas sin respuesta y preocupaciones legítimas, Lakehouse es un avance prometedor en la arquitectura de datos. Es muy posible que estemos observando el desplazamiento de placas tectónicas en el panorama del análisis de datos.

Una cosa es segura, no he estado tan entusiasmado con la arquitectura de datos desde que discutí sobre tablas «largas y delgadas» versus tablas «completas» hace más de una década.

También te gustará