Pipelines declarativos de Spark: por qué la ingeniería de datos necesita volverse declarativa de extremo a extremo

Los equipos de ingeniería de datos están bajo presión para entregar datos de mayor calidad más rápido, pero el trabajo de crear y operar pipelines se está volviendo más difícil, no más fácil. Entrevistamos a cientos de ingenieros de datos, estudiamos millones de cargas de trabajo del mundo real y descubrimos algo sorprendente: los ingenieros de datos pasan la mayor parte de su tiempo no escribiendo código, sino en la carga operativa generada por la integración de herramientas. La razón es simple: los marcos de ingeniería de datos existentes obligan a los ingenieros de datos a gestionar manualmente la orquestación, el procesamiento de datos incremental, la calidad de los datos y los backfills, todas tareas comunes para los pipelines de producción. A medida que crecen los volúmenes de datos y los casos de uso, esta carga operativa se agrava, lo que convierte a la ingeniería de datos en un cuello de botella para el negocio en lugar de un acelerador.

No es la primera vez que la industria se topa con este muro. El procesamiento de datos inicial requería escribir un programa nuevo para cada pregunta, lo cual no era escalable. SQL cambió eso al hacer que las consultas individuales fueran declarativas: especificas qué resultado quieres y el motor determina cómo calcularlo. Las bases de datos SQL ahora sustentan todos los negocios.

Pero la ingeniería de datos no se trata de ejecutar una sola consulta. Los pipelines actualizan repetidamente múltiples conjuntos de datos interdependientes a lo largo del tiempo. Debido a que los motores de SQL se detienen en el límite de la consulta, todo lo que está más allá (procesamiento incremental, gestión de dependencias, backfills, calidad de los datos, reintentos) aún debe ensamblarse manualmente. A gran escala, el razonamiento sobre el orden de ejecución, el paralelismo y los modos de falla se convierte rápidamente en la principal fuente de complejidad.

Lo que falta es una forma de declarar el pipeline en su conjunto. Spark Declarative Pipelines (SDP) amplían el procesamiento declarativo de datos de consultas individuales a pipelines completos, lo que permite a Apache Spark planificarlos y ejecutarlos de extremo a extremo. En lugar de mover datos manualmente entre pasos, usted declara qué conjuntos de datos quiere que existan y SDP se encarga de cómo mantenerlos correctos a lo largo del tiempo. Por ejemplo, en un pipeline que calcula las ventas semanales, SDP infiere las dependencias entre los conjuntos de datos, crea un único plan de ejecución y actualiza los resultados en el orden correcto. Procesa automáticamente solo los datos nuevos o modificados, expresa las reglas de calidad de los datos en línea y gestiona los backfills y los datos que llegan con retraso sin intervención manual. Como SDP entiende la semántica de las consultas, puede validar los pipelines por adelantado, ejecutar de forma segura en paralelo y recuperarse correctamente de las fallas, capacidades que requieren API declarativas de primera clase y compatibles con pipelines integradas directamente en Apache Spark.

La ingeniería de datos declarativa de extremo a extremo en SDP ofrece grandes beneficios:

• Mayor productividad: Los ingenieros de datos pueden centrarse en escribir la lógica de negocio en lugar de código de unión.
• Menores costos: El framework gestiona automáticamente la orquestación y el procesamiento incremental de datos, lo que lo hace más rentable que los pipelines escritos a mano.
• Menor carga operativa: Los casos de uso comunes, como los backfills, la calidad de los datos y los reintentos, están integrados y automatizados.

Para ilustrar los beneficios de la ingeniería de datos declarativa de extremo a extremo, comencemos con un pipeline de ventas semanal escrito en PySpark. Debido a que PySpark no es declarativo de extremo a extremo, debemos codificar manualmente el orden de ejecución, el procesamiento incremental y la lógica de calidad de los datos, y depender de un orquestador externo como Airflow para los reintentos, las alertas y el monitoreo (omitido aquí por brevedad).

Este pipeline, expresado como un proyecto dbt de SQL, sufre de muchas de las mismas limitaciones: aún debemos codificar manualmente el procesamiento de datos incremental, la calidad de los datos se maneja por separado y todavía tenemos que depender de un orquestador como Airflow para los reintentos y el manejo de fallas:

Reescribamos este pipeline en SDP para explorar sus beneficios. Primero, instalemos SDP y creemos un nuevo pipeline:

A continuación, define tu pipeline con el siguiente código. Ten en cuenta que comentamos la API de expectativa de calidad de los datos expect_or_drop, ya que estamos trabajando con la comunidad para que sea de código abierto:

Para ejecutar el pipeline, escribe el siguiente comando en tu terminal:

Incluso podemos validar nuestro pipeline por adelantado sin ejecutarlo primero con este comando; es útil para detectar errores de sintaxis y discrepancias de esquema:

Los backfills se vuelven mucho más simples: para hacer un backfill de la tabla raw_sales, ejecuta este comando:

El código es mucho más simple: solo 20 líneas que ofrecen todo lo que las versiones de PySpark y dbt requieren que proporcionen las herramientas externas. También obtenemos estos potentes beneficios:

• Procesamiento de datos incremental y automático. El framework realiza un seguimiento de los datos que se han procesado y solo lee los registros nuevos o modificados. No se necesitan consultas MAX, ni archivos de checkpoint, ni lógica condicional.
• Calidad de datos integrada. El decorador @dp.expect_or_drop pone en cuarentena los registros incorrectos automáticamente. En PySpark, dividimos y escribimos manualmente los registros buenos y malos en tablas separadas. En dbt, necesitábamos un modelo separado y un manejo manual.
• Seguimiento automático de dependencias. El framework detecta que weekly_sales depende de raw_sales y orquesta el orden de ejecución automáticamente. No se necesita un orquestador externo.
• Reintentos y monitoreo integrados. El framework maneja las fallas y proporciona observabilidad a través de una UI integrada. No se requieren herramientas externas.

SDP en Apache Spark 4.1 tiene las siguientes capacidades, que lo convierten en una excelente opción para los pipelines de datos:

• API de Python y SQL para definir datasets
• Soporte para consultas por lotes y de streaming
• Seguimiento automático de dependencias entre conjuntos de datos y actualizaciones paralelas eficientes
• CLI para estructurar, validar y ejecutar pipelines de forma local o en producción

Estamos entusiasmados con la hoja de ruta de SDP, que se está desarrollando de forma abierta con la comunidad de Spark. Las próximas versiones de Spark se basarán en estos cimientos con soporte para la ejecución continua y un procesamiento incremental más eficiente. También planeamos incorporar capacidades principales como la Captura de Datos de Cambios (CDC) en SDP, moldeadas por casos de uso del mundo real y los comentarios de la comunidad. Nuestro objetivo es hacer de SDP una base compartida y extensible para construir pipelines confiables de batch y streaming en todo el ecosistema de Spark.

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