Implementar Lakehouse: Databricks y Delta Lake

La dicotomía entre el mundo estructurado y fiable de los almacenes de datos y el lago de datos escalable y flexible ha definido durante mucho tiempo la estrategia de datos de las empresas. Los almacenes de datos destacan en la inteligencia empresarial (BI) en datos estructurados, pero tienen dificultades con la escalabilidad, el coste y las cargas de trabajo de aprendizaje automático. Los lagos de datos, construidos sobre almacenamiento de objetos de bajo coste, pueden gestionar grandes volúmenes de datos diversos, pero a menudo se convierten en "pantanos de datos" poco fiables que carecen de transacciones ACID, control de calidad de los datos y rendimiento.

La arquitectura Lakehouse resuelve este conflicto. Implementa características similares a las de un almacén de datos, como las transacciones ACID, el cumplimiento de esquemas y la gobernanza, directamente sobre el almacenamiento de bajo costo y de formato abierto de un lago de datos. Este artículo proporciona una guía técnica para implementar una Lakehouse robusta utilizando Databricks y su marco de almacenamiento subyacente, Delta Lake, dirigida a directores de tecnología y ingenieros senior responsables de diseñar plataformas de datos de próxima generación.

La pila de tecnología

Una implementación exitosa de Lakehouse depende de dos tecnologías fundamentales: una capa de almacenamiento transaccional y un motor de consulta de alto rendimiento. Databricks ofrece una plataforma integrada que combina ambas.

Servicios de Ingeniería de Productos

Colabore con nuestros gestores de proyectos, ingenieros de software y probadores de calidad, para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo las metodologías Agile, DevOps y Lean.

Build with 4Geeks

Delta Lake: La base para la confiabilidad

Delta Lake no es un sistema separado, sino unacapa de almacenamiento transaccional de código abierto que se ejecuta sobre tu lago de datos en la nube existente (por ejemplo, AWS S3, Azure Data Lake Storage, GCS). Mejora tus archivos de datos Parquet con un registro de transacciones, proporcionando funciones de fiabilidad cruciales.

• Transacciones ACID: Delta Lake aporta atomicidad, consistencia, aislamiento y durabilidad a las operaciones del lago de datos. Esto significa que las lecturas y escrituras concurrentes no corromperán tus datos, y cada operación se registra y puede ser verificada. Esto se logra a través de un registro de transacciones (_delta_log) ubicado junto a tus datos, que sirve como la única fuente de verdad.
• Viaje en el tiempo (Versionado de datos): El registro de transacciones mantiene las versiones de los datos a medida que cambian. Esto permite la auditoría, la reversión de operaciones erróneas y la reproducción de experimentos o informes en un momento específico o número de versión.
• Aplicación y evolución del esquema: Por defecto, Delta Lake impide las escrituras que no coincidan con el esquema de la tabla, protegiendo la integridad de los datos. También admite la evolución explícita del esquema, lo que permite añadir nuevas columnas sin necesidad de reescribir todo el conjunto de datos, de forma sencilla, según los cambios en los requisitos de datos.
• Lote y flujo unificado: Las tablas de Delta Lake son una fuente y un destino tanto para consultas por lotes como para cargas de trabajo de flujo. Esto simplifica enormemente las arquitecturas eliminando la necesidad de sistemas separados (por ejemplo, una arquitectura Lambda) para gestionar datos en tiempo real e históricos.

Databricks: El motor de análisis unificado

Databricks proporciona el motor de cálculo y una suite de herramientas construidas en torno a una distribución de Apache Spark altamente optimizada.

• Motor Spark optimizado con Photon: Databricks ejecuta una versión mejorada de Spark. Su motor de próxima generación, Photon, es un motor de ejecución vectorial basado en C++ que proporciona mejoras significativas en el rendimiento para cargas de trabajo SQL y DataFrame sobre Spark estándar.
• Unity Catalog: Esta es la solución de gobierno para el Lakehouse. Proporciona una capa centralizada de metadatos para el control de acceso detallado (seguridad a nivel de fila y columna), descubrimiento de datos, trazabilidad de datos automatizada y auditoría en todos los espacios de trabajo.
• Entorno colaborativo: Las cuadernos y flujos de trabajo de Databricks proporcionan un entorno integrado para que los ingenieros de datos, los científicos de datos y los analistas trabajen juntos, desde la ingestión y ETL de datos hasta el entrenamiento de modelos (con MLflow) y BI.

Planos arquitectónicos: La arquitectura Medallion

Un patrón comprobado para organizar datos dentro de un Lakehouse es la Arquitectura Medallón. Este enfoque de múltiples etapas refina progresivamente los datos a medida que fluyen a través del sistema, garantizando calidad, fiabilidad y rendimiento. Los datos se organizan en tres capas: Bronce, Plata y Oro.

Capa de Bronce: Ingestión de Datos Brutos

La capa de Bronce es la zona de aterrizaje para todos los datos de origen. El objetivo principal aquí es capturar los datos brutos en su formato y estructura originales, creando un archivo histórico duradero y con versiones.

• Propósito: Ingestar y conservar los datos originales con su fidelidad original. Los datos suelen ser agregados y el esquema se captura según llegan.
• Implementación: La forma más eficiente de ingerir datos de almacenamiento en la nube es con Databricks Autoloader. Procesa de forma incremental y eficiente nuevos archivos de datos a medida que llegan a tu lago de datos, sin necesidad de programación manual. Autoloader infiere automáticamente el esquema y puede manejar los cambios en el esquema de forma elegante.

Aquí se muestra un fragmento de código de Python funcional que utiliza Autoloader para crear una tabla de tipo "Bronze" a partir de archivos JSON de entrada:

# Configure the Autoloader stream
# This code block sets up a continuous or triggered stream to ingest raw JSON data
bronze_stream = (spark.readStream
  .format("cloudFiles")
  .option("cloudFiles.format", "json")
  # Path for Autoloader to track schema evolution
  .option("cloudFiles.schemaLocation", "/path/to/schema_logs/iot_events")
  # Path for schema hints if needed
  # .option("cloudFiles.schemaHints", "timestamp timestamp, device_id long")
  .load("/path/to/raw/iot_events_json")
)

# Write the stream to a Bronze Delta table
(bronze_stream.writeStream
  .format("delta")
  # Location for the stream's checkpoint data for fault tolerance
  .option("checkpointLocation", "/path/to/checkpoints/iot_events_bronze")
  # Trigger can be configured for continuous streaming or periodic batch processing
  .trigger(availableNow=True) 
  .toTable("bronze_iot_events")
)

Capa de Plata: Datos Limpios y Normalizados

Los datos de la capa de Bronce se limpian, validan y enriquecen para crear la capa de Plata. Esta capa representa una "fuente de datos única" y proporciona un conjunto de datos consultable para analistas y científicos de datos.

• Propósito: Proporcionar una visión de nivel empresarial de los datos aplicando reglas de calidad, resolviendo inconsistencias de tipo de datos, filtrando registros incorrectos y uniéndolos con otros conjuntos de datos para enriquecerlos.
• Implementación: Utilizar Spark SQL o PySpark para leer desde las tablas Bronze, aplicar transformaciones y escribir en las tablas Silver. La operación MERGE INTO es crucial aquí para gestionar actualizaciones, inserciones y eliminaciones (upserts), lo cual es un requisito común al sincronizar con sistemas de origen transaccionales.

Este ejemplo demuestra el uso de MERGE para actualizar una silver_users tabla con nuevos o modificados registros provenientes de una fuente Bronze:

MERGE INTO silver_users AS target
USING (
  SELECT 
    userId AS user_id,
    profile.firstName AS first_name,
    profile.lastName AS last_name,
    CAST(registration_ts AS timestamp) AS registration_timestamp,
    email
  FROM bronze_user_updates
  WHERE is_processed = false -- Example filter for incremental processing
) AS source
ON target.user_id = source.user_id

-- Update existing user records if their profile has changed
WHEN MATCHED THEN
  UPDATE SET
    target.first_name = source.first_name,
    target.last_name = source.last_name,
    target.email = source.email

-- Insert new user records
WHEN NOT MATCHED THEN
  INSERT (user_id, first_name, last_name, registration_timestamp, email)
  VALUES (source.user_id, source.first_name, source.last_name, source.registration_timestamp, source.email)

Capa de Oro: Agregados a nivel empresarial

La capa de oro contiene datos que están altamente refinados y agrupados para casos de uso específicos de negocios, como paneles de control de BI, informes, o como características para modelos de aprendizaje automático.

• Propósito: Optimizar el rendimiento de las consultas y la facilidad de uso. Los datos a menudo se denormalizan y se agrupan en tablas específicas del proyecto.
• Implementación: Las tablas "Gold" se crean típicamente a partir de una o más tablas "Silver". El rendimiento es fundamental en esta etapa. Se utilizan técnicas como el "Z-Ordering" para ubicar la información relacionada en el mismo conjunto de archivos, reduciendo drásticamente la cantidad de datos que deben ser escaneados para consultas comunes.

Servicios de Ingeniería de Productos

Trabaje con nuestros gestores de proyectos, ingenieros de software y testers de calidad internos para desarrollar su nuevo producto de software personalizado o para apoyar su flujo de trabajo actual, siguiendo metodologías Agile, DevOps y Lean.

Build with 4Geeks

Este comando SQL crea una tabla "Gold" para el análisis de ventas diarias y luego optimiza su estructura física:

-- Create the aggregated gold table
CREATE OR REPLACE TABLE gold_daily_sales_summary AS
SELECT
  CAST(order_timestamp AS date) AS sale_date,
  product_category,
  SUM(sale_amount) AS total_sales,
  COUNT(DISTINCT order_id) AS total_orders
FROM silver_sales_orders
GROUP BY
  CAST(order_timestamp AS date),
  product_category;

-- Optimize the physical layout of the data for faster queries on sale_date and product_category
OPTIMIZE gold_daily_sales_summary
ZORDER BY (sale_date, product_category);

Optimizar con ZORDER es un paso crucial para ajustar el rendimiento. Reorganiza los archivos Parquet subyacentes para que los datos con fechas de venta_date y valores de product_category se almacenen físicamente juntos, lo que permite un acceso eficiente a los datos durante la ejecución de consultas.los valores se almacenan físicamente juntos, lo que permite saltar datos de manera muy eficiente durante la ejecución de las consultas.

Consideraciones de gobernanza y rendimiento

Para un director de tecnología, implementar la tecnología es solo la mitad de la batalla. Garantizar la gobernanza y el rendimiento es esencial para la adopción empresarial.

• Gobernanza centralizada con Unity Catalog: Utilice Unity Catalog para definir las políticas de acceso una sola vez y que se apliquen en todas partes. Puede otorgar a un usuario SELECT acceso a una tabla específica, y ese permiso se respetará, independientemente de si están consultando a través de un cuaderno, un punto final de Databricks SQL o una API REST. Su trazabilidad de datos integrada es también invaluable para el análisis de impacto y el cumplimiento normativo.
• Optimización del rendimiento: Además del orden Z, Databricks ofrece varias opciones para optimizar el rendimiento:
  • Motor Photon: Asegúrese de que esté habilitado en sus clústeres para obtener la máxima velocidad de consulta.
  • Caché Delta: Los clústeres de Databricks almacenan automáticamente los datos accedidos con frecuencia en el almacenamiento local del clúster, proporcionando un acceso extremadamente rápido para consultas posteriores.
  • Compresión de archivos: El comando OPTIMIZE no solo ordena Z, sino que también comprime los archivos pequeños en archivos más grandes, mitigando el "problema de los archivos pequeños" que afecta a muchos sistemas de big data y mejorando el rendimiento de lectura.

Conclusión

La arquitectura Lakehouse, implementada con Databricks y Delta Lake, proporciona una plataforma unificada y de alto rendimiento que elimina la necesidad de elegir entre una base de datos y un lago de datos. Al aprovechar formatos abiertos y un enfoque arquitectónico de múltiples capas, los equipos de ingeniería pueden construir un único sistema que soporta desde el análisis de BI y SQL hasta la ciencia de datos y el aprendizaje automático.

Este enfoque elimina las barreras entre los datos, reduce la complejidad arquitectónica y disminuye el costo total de propiedad. Para los líderes de ingeniería, adoptar el paradigma de Lakehouse es una decisión estratégica para construir una base de datos escalable, gobernada y apta para el futuro que puede acelerar la innovación en toda la organización.

Preguntas frecuentes