Modernización de ETL de SQL en Lakehouse con patrones declarativos

Databricks está llevando el ETL declarativo a los flujos de trabajo de almacenamiento de datos en Lakehouse, lo que facilita a los profesionales de SQL la simplificación de lógicas de transformación complejas en los entornos familiares en los que ya trabajan.

Esto forma parte de una estrategia más amplia para llevar el modelo de ejecución declarativo detrás de Apache Spark™ Declarative Pipelines a más experiencias de creación en todo Databricks. En lugar de tener que trabajar en un entorno dedicado y orientado a canalizaciones, los usuarios de SQL ahora pueden definir patrones de ETL comunes directamente dentro de sus consultas SQL en Databricks Lakehouse.

Simplificación de los patrones de ETL recurrentes en Lakehouse

El ETL de SQL declarativo en Databricks no es algo nuevo. Hoy en día, miles de usuarios que priorizan SQL ya confían en primitivas declarativas como las Materialized Views y las Streaming Tables para simplificar las transformaciones recurrentes, mantener al día las tablas descendentes y acelerar las cargas de trabajo de BI.

Muchos patrones de ETL recurrentes son fáciles de describir pero difíciles de operar, ya que requieren una lógica SQL personalizada, programación manual y elementos de unión para la orquestación. Estos patrones incluyen la adición de nuevos registros, la aplicación de cambios de CDC y la actualización exclusiva de los datos que han cambiado.

Las primitivas declarativas funcionan porque permiten a los usuarios describir la tabla o vista que desean, en lugar de programar manualmente cada paso necesario para mantenerla actualizada. Databricks se encarga de la programación, la actualización y el procesamiento incremental cuando corresponde, de modo que los usuarios no tienen que escribir a mano la lógica necesaria para mantener las tablas al día.

Ahora estamos extendiendo ese mismo enfoque declarativo más allá del Lakeflow Pipelines Editor a más patrones de ETL recurrentes para profesionales de SQL y almacenamiento de datos. Ahora, los usuarios de Lakehouse pueden definir el patrón de ETL que deseen (directamente en el editor de SQL, por ejemplo), mientras que Databricks se encarga del procesamiento incremental, la lógica de actualización, la programación y la orquestación necesarias para ejecutarlo de manera confiable.

Las primeras primitivas declarativas disponibles en Lakehouse

Las primeras operaciones declarativas disponibles en el editor de SQL de Lakehouse se corresponden con tres patrones de ETL recurrentes comunes: actualizaciones de solo adición, captura de datos de cambio y sobreescrituras por lotes.

Muchos de estos patrones ya están disponibles a través de API declarativas como AUTO CDC en Lakeflow; el cambio aquí consiste en hacerlos accesibles directamente en Lakehouse para los analistas de SQL.

Estos flujos se pueden actualizar de forma programada, activar mediante actualizaciones ascendentes, ejecutar bajo demanda o bien orquestar a través de tareas de SQL en Jobs.

Actualizaciones de solo adición

Las actualizaciones de solo adición (append-only) son el patrón estándar detrás de muchas tablas de streaming hoy en día; se utilizan para agregar de forma incremental nuevos registros desde un origen a una tabla de destino. Se suelen usar para cargas de trabajo de ingesta, como la carga de nuevos registros desde el almacenamiento de objetos en la nube con Auto Loader.

En lugar de escribir y programar una lógica de inserción repetitiva, los usuarios de SQL pueden definir un flujo APPEND simple que realiza un seguimiento automático de los datos nuevos frente a los procesados anteriormente en el origen. Databricks se encarga del seguimiento del estado y añade incrementalmente nuevos registros a medida que llegan, gestionando la canalización serverless subyacente de forma automática.

Esto ofrece a los usuarios de SQL una forma sencilla de poner en producción la ingesta de tipo adición sin tener que crear, programar o gestionar manualmente una canalización independiente.

Vea cómo definir flujos APPEND en Lakehouse.

Captura de datos de cambio

Las canalizaciones de CDC se encuentran entre los patrones más comunes (y complejos) en el ETL de SQL. Los equipos suelen utilizar MERGE INTO para procesar inserciones, actualizaciones y eliminaciones, pero los datos de CDC pueden llegar desordenados, lo que requiere una lógica adicional para evitar resultados incorrectos.

AUTO CDC permite a los usuarios de SQL definir la lógica de CDC con unas pocas líneas de código declarativo en Lakehouse. Con AUTO CDC, es fácil especificar claves, secuenciación, gestión de eliminaciones y si se deben almacenar los resultados como SCD Type 1 o SCD Type 2, sin tener que escribir a mano complejas canalizaciones de fusión.

“En bsport, SQL AUTO CDC nos ha proporcionado una forma mucho más sencilla y modular de gestionar la ingesta de datos en Databricks. Al desacoplar las cargas de tablas de una única canalización, hemos mejorado la disponibilidad y la frescura de los datos en toda nuestra plataforma. Nos permite procesar datos de terceros de forma independiente, lo que nos brinda una mejor gestión de fallos, reduce la complejidad de la orquestación y hace que la configuración general sea más fácil de operar y escalar. Para nuestro equipo, esto ha creado un flujo de trabajo basado en SQL más limpio y flexible, con una mayor confiabilidad en producción”.—Adrien Marteau, responsable de datos de bsport

Vea cómo crear flujos de AUTO CDC para SCD Type 1 y Type 2.

Sobreescrituras por lotes

Algunas cargas de trabajo de ETL por lotes solo necesitan actualizar un subconjunto específico de datos, como un rango de fechas, una partición o un segmento de negocio. Tradicionalmente, los equipos suelen gestionar esto con costosos recálculos completos o lógicas de sobreescritura personalizadas.

Los flujos REPLACE WHERE aportan a Lakehouse un patrón declarativo para el recálculo incremental por lotes focalizado. Los usuarios definen un predicado en la tabla de destino y Databricks actualiza esa región automáticamente. Con Enzyme, el motor de incrementalización automática de Databricks, Databricks puede identificar y procesar únicamente los datos que cambiaron dentro del predicado especificado siempre que sea posible, en lugar de volver a calcular toda la tabla de destino o sobreescribir toda la sección coincendente.

En las pruebas de rendimiento de Lakehouse, REPLACE WHERE impulsado por Enzyme se ejecutó 3.4 veces más rápido y fue 2.5 veces más económico que el REPLACE WHERE tradicional. Esto resulta útil para el reprocesamiento selectivo, la evolución del esquema, los backfills y la iteración en una pequeña ventana de datos antes de procesar un rango histórico más amplio.

Vea cómo utilizar los flujos REPLACE WHERE para actualizar un subconjunto específico de una tabla (y lea el blog de la comunidad aquí).

En resumen: por qué esto es importante para los profesionales de SQL

Modernizar su ETL no requiere una reescritura total ni un compromiso de todo o nada con marcos de trabajo de canalización complejos. Incorporar la semántica declarativa a sus operaciones SQL existentes en Lakehouse le permite combinar su código actual con SQL declarativo modernizado donde tenga más sentido.

Puede conservar sus consultas SQL procedimentales optimizadas para tareas personalizadas, al tiempo que integra sin problemas operaciones declarativas como la ingesta de solo adición, AUTO CDC o sobreescrituras por lotes focalizadas para patrones recurrentes que requieren mucho mantenimiento. Esto le ofrece lo mejor de ambos mundos: control total sobre su lógica SQL tradicional junto con la gestión automatizada del estado, el manejo de dependencias y la evolución del esquema donde lo desee, todo directamente dentro de Lakehouse.

De primitivas declarativas a canalizaciones declarativas completas

Combinar primitivas declarativas en sus flujos de trabajo de SQL diarios proporciona un punto de partida práctico y de baja fricción para gestionar tablas individuales y lógica incremental. A medida que su proyecto crezca en escala y complejidad, su flujo de trabajo de desarrollo podrá evolucionar de forma natural junto con él.

Para los equipos que gestionan múltiples transformaciones relacionadas, dependencias compartidas y flujos de trabajo de producción, el Lakeflow Pipelines Editor ofrece una experiencia de desarrollo más enriquecedora y orientada a proyectos para ETL declarativo, con soporte para desarrollo de múltiples archivos, gestión de dependencias, visualización de canalizaciones, validación integrada y despliegue en producción.

Esto es especialmente útil para los equipos que gestionan muchas transformaciones relacionadas en diferentes dominios, productos de datos o unidades de negocio. En lugar de mantener scripts desconectados o centralizar toda la lógica en un único gran proyecto, los equipos pueden organizar los flujos declarativos en canalizaciones gobernadas y propiedad del equipo en Databricks. Con Unity Catalog, cada equipo puede construir sobre activos de datos compartidos, gestionar permisos de manera consistente y comprender el linaje a lo largo de las canalizaciones y los consumidores descendentes.

Los profesionales de SQL pueden comenzar con flujos declarativos en el familiar editor de SQL y luego pasar al editor de canalizaciones (Pipelines Editor) cuando necesiten un entorno más estructurado para proyectos más grandes, una gestión de canalizaciones más profunda y un desarrollo basado en equipos.

Obtenga más información sobre la creación de flujos de trabajo de ETL declarativos con el Lakeflow Pipelines Editor.

Utilice Genie Code para comenzar más rápido

Genie Code hace que sea más fácil para los profesionales de SQL descubrir y aplicar estos patrones ETL declarativos en los flujos de trabajo que ya utilizan. En lugar de empezar desde una página en blanco o traducir manualmente el SQL existente a un patrón listo para producción, los usuarios pueden pedirle a Genie Code que los ayude a generar, explicar y perfeccionar flujos declarativos.

Por ejemplo, un usuario que trabaja con datos CDC puede pedirle a Genie Code que lo ayude a crear un flujo AUTO CDC, que incluya las claves adecuadas, la columna de secuencia, el manejo de eliminaciones y el comportamiento de SCD Tipo 1 o Tipo 2. Un usuario que trabaja con lógica de lotes recurrentes puede pedirle a Genie Code que lo ayude a convertir la lógica de sobrescritura existente en un flujo REPLACE WHERE incremental.

A medida que el ETL declarativo esté disponible en más experiencias de creación, Genie Code puede ayudar a guiar a los usuarios hacia el patrón declarativo adecuado para la tarea en cuestión.

Para comenzar, explore la documentación enlazada en cada sección anterior y utilice Genie Code en el Editor de SQL para identificar dónde los flujos APPEND, los flujos AUTO CDC o los flujos REPLACE WHERE pueden simplificar su lógica ETL existente.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original