Tabla de contenidos
Introducción
En los últimos años, hemos presenciado un enorme auge en la ingeniería analítica que ha transformado nuestra industria.
Desde el ámbito de las IT, donde el conocimiento sobre cómo fluyen los datos, dónde residen y para qué se utilizan puede ser fácilmente restringido a unos pocos, la ingeniería analítica ha permitido a las empresas (con «B» mayúscula) abrir las puertas a las bases de datos y comenzar a utilizar los datos de forma efectiva.
Al reducir las barreras de entrada para la escritura de pipelines de datos basados en SQL, los profesionales de IT han podido liberarse de la tediosa tarea de codificar la lógica empresarial con las mejores prácticas de ingeniería de software, lo que ha acelerado rápidamente la obtención de valor de los datos por parte de las empresas.
En gran medida, dbt Labs ha ayudado enormemente a la industria en este aspecto. dbt Cloud ofrece funciones increíblemente útiles para los profesionales de la analítica que se inician en el mundo de la ingeniería de software, lo que les ayuda a ponerse al día.
- Un IDE basado en navegador, diseñado específicamente para escribir modelos dbt con las mejores prácticas integradas.
- Un programador para ejecutar pipelines.
- Slim CI, para garantizar que los cambios se prueben antes de su lanzamiento a producción. Y, por supuesto,
- Los propios proyectos dbt y dbt-fusion.
Sin embargo, algo que hemos visto es que la ingeniería analítica no puede sobrevivir sin la ingeniería de datos. Si bien la transición de ETL a ELT puede haber abierto las puertas al almacén, las puertas a las demás áreas de la arquitectura empresarial permanecen firmemente cerradas.
Siempre he querido construir un mundo donde alguien con un nivel técnico moderado, curioso y con ganas de aprender pueda construir fácilmente canales de datos de extremo a extremo dentro de una arquitectura escalable.
Esto no es lo mismo que querer construir una plataforma como Talend, Informatica o alguna de esas plataformas tradicionales que te obligan a hacer las cosas de cierta manera. Hay dos resultados empíricos interesantes al trabajar con datos:
- Avanza rápidamente, por lo que es importante mantener la flexibilidad en la arquitectura.
- Los pipelines de datos son complejos, por lo que es importante mantener la modularidad, lo que también implica mantener la flexibilidad en la arquitectura.
Esto implica que necesitamos encontrar una manera de democratizar la creación de pipelines de datos de extremo a extremo más allá de DBT y el modelado de datos.
Por eso hemos invertido tanto en nuestras integraciones con DBT, y compartiré más sobre ellas a continuación.
Almacenes → Herramientas de datos
dbt ofrece a los equipos de datos una forma sencilla de conectarse a cualquier almacén de datos.
Sin embargo, los equipos de datos suelen usar solo un almacén, como Snowflake o Databricks.
¿Qué ocurre si tienes un flujo más complejo?
Supongamos que usas la clásica canalización de pila de datos moderna. Tienes algunas herramientas de ingesta a las que necesitas conectarte; una vez completadas las ingestas, quieres ejecutar dbt y, finalmente, quieres ejecutar algún tipo de panel de control.
Hoy en día, puedes reemplazar «panel de control» por «flujo de trabajo de IA», por supuesto.
dbt no ofrece una forma sencilla de conectar con todo esto, por lo que en Orchestra hemos creado más de cien integraciones para que puedas conectarte fácilmente a toda la pila sin tener que aprender ingeniería de datos de abajo a arriba ni crear todas estas integraciones internamente.
¿Es dbt un orquestador?
¡Sí! ¡dbt es un orquestador!
Con dbt puedes activar y supervisar los siguientes procesos:
- Enviar consultas SQL de ciertos tipos de forma síncrona a tu almacén de datos.
- Escribir código Python compilado en SQL que también se puede enviar a tu almacén de datos.
- Ejecutar solicitudes HTTP simples con sintaxis declarativa para, por ejemplo, activar actualizaciones de Power BI.
Actualmente, solemos ver que se añaden otras funciones a un «orquestador» (como se quiera definir).
- Capacidades de programación complejas (ver más abajo).
- Capacidad para ejecutar cualquier código.
- Integraciones con herramientas.
- Potencia para alertas granulares.
- Agregación de metadatos.
- Compatibilidad con flujos de trabajo basados en IA.
- Capacidades de observabilidad y monitorización.
- Permisos detallados y control de acceso basado en roles.
Esto significa que, por lo general, no se intenta usar dbt como orquestador para toda la empresa porque no fue diseñado para eso.
Por ejemplo, muchas empresas ejecutan scripts de Python, o simplemente scripts.
No se puede usar dbt para activar o supervisar un script arbitrario, a menos que, por supuesto, empiece con las letras dbt.
Programación cron → Cualquier programación
dbt funciona bien con un paradigma de programación cron, es decir, ejecuta las tareas con una cadencia determinada.
Sin embargo, cuando los equipos de datos escalan, existen muchos escenarios en los que esta programación necesita gestionar más casos de uso.
- Programación basada en eventos: al llegar ciertos datos, se activa una ejecución de DBT con parámetros específicos para materializar los datos recientes.
- Programación basada en sensores: cuando no sabemos cuándo llegarán los datos, creamos un «control» (o sensor) que se ejecuta y nos avisa, y lo usamos para iniciar una ejecución de DBT.
- Programación no lineal: un tipo de programación basada en sensores, donde necesitamos ejecutar modelos de DBT después de que otros procesos se hayan completado en momentos no especificados (nuestro proveedor nos enviará los datos hoy, en algún momento, pero desconocemos cuándo).
- Programación basada en calendario: en grandes empresas de sectores regulados, las consideraciones basadas en calendarios son fundamentales para tener en cuenta aspectos como los días festivos nacionales. Esto significa que es fundamental poder seleccionar o excluir fechas de un calendario, o tener una integración con una base de datos que contenga dicho calendario.
Para que los ingenieros analíticos y los analistas de datos obtengan esta funcionalidad, es necesario aprender a usar un programador empresarial como Tidal o un framework de orquestación tradicional como Airflow.
Es como si te dijeran que tienes que aprender cómo funciona un avión para poder tomar un vuelo. Totalmente innecesario, excesivo y una pérdida de tiempo.
En Orchestra, desarrollamos todos estos activadores personalizados de forma fácil de usar, para que cualquiera que cree pipelines tenga total flexibilidad en cómo se activan los procesos.
Sin condicionalidad ni ramificación → Ramificación
A veces, podrías querer cambiar tus acciones en función de lo que sucede en un flujo de datos.
Por ejemplo, supongamos que estás reentrenando un modelo de aprendizaje automático que calibra cuánto puedes invertir en una campaña de Google Ads según los datos más recientes.
Los datos de Google Ads son un poco erráticos. Esto significa que, a veces, los datos más recientes simplemente no están disponibles. Podrías detectar fácilmente esta prueba con una prueba DBT como:
select * from google_ads where date >= current_date
Si no se devuelven filas, la prueba falla.
Si la prueba falla, quizás no desee simplemente no realizar ninguna acción. Quizás prefiera implementar su modelo de aprendizaje automático de respaldo, que garantiza que su gasto no se dispare en la dirección incorrecta. Para ello, los analistas necesitan ramificación.
La ramificación o condicionalidad describe un patrón de orquestación donde decimos que el grafo tiene rutas contingentes. Las rutas dependen de que ocurran eventos específicos.
Presione Enter o haga clic para ver la imagen a tamaño completo.
En este ejemplo, si la prueba dbt tiene éxito, se elige la ruta superior. Si falla, se elige la ruta inferior.
dbt no admite ramificaciones ni condicionalidad, lo que significa que las empresas suelen recurrir a una herramienta de orquestación específica para obtener esta funcionalidad.
Hemos hablado con miles de ingenieros analíticos y estos son algunos de los casos de uso comunes que observamos para los analistas al ramificar el DAG:
Procesamiento con Control de Costos
- Cargas Incrementales vs. Cargas Completas: Ejecuta trabajos incrementales más pequeños solo durante las horas punta, reservando las actualizaciones completas para las horas valle.
- Organización de almacenes: Ramifica los trabajos para usar diferentes almacenes de cómputo según la urgencia (p. ej., XS para consultas ad hoc, L para ejecuciones de producción críticas).
- Opciones basadas en SLA: Prioriza las métricas empresariales críticas cuando los plazos sean ajustados, posponiendo las transformaciones no esenciales hasta que se liberen los recursos.
Resultados específicos para cada parte interesada
- Adaptación a la audiencia: Lógica de sucursal: Finanzas ve datos granulares a nivel de transacción, mientras que Marketing solo obtiene métricas agregadas de campaña.
- Control de frecuencia: Genera paneles diarios para la dirección, pero solo extractos semanales o mensuales para socios externos.
- Variaciones de formato: Integra los resultados en paneles de inteligencia empresarial para equipos internos y crea exportaciones CSV/Excel para partes interesadas con menos conocimientos técnicos.
Escenarios de fallo
- Pruebas seguras: Ejecuta pruebas si fallan los pipelines en lugar de materializar los resultados posteriores.
Calidad basada en costos → Pruebas fraccionarias
dbt es un excelente framework para escribir pruebas de calidad de datos. Con unas pocas líneas de .yml, puede evitar que sus clientes reciban datos erróneos.
version: 2
data_tests:
– name: assert_total_payment_amount_is_positive
description: >
Refunds have a negative amount, so the total amount should always be >= 0.
Therefore return records where total amount < 0 to make the test fail.
Sin embargo, este enfoque es costoso. Cada prueba que realizas envía consultas a tu almacén, lo que genera un mayor costo.
Recuerdo una conversación con alguien con quien trabajé que fue así.
Yo: “El valor único de la fila se deriva de la marca de tiempo y el ID; ¿por qué no podemos probar la columna gradualmente a medida que se introduce? Entonces, mientras sepamos que todas las pruebas anteriores y actuales pasan, cada fila de la tabla será única”.
Colega: “Así no funciona el algoritmo. No hay garantía de que la clave única sea única en los datos nuevos y existentes. Hay que escanear la tabla completamente cada vez”.
Realizar un análisis completo cada vez que se obtienen nuevos datos es costoso. Escribimos esta guía para pruebas de DBT que destaca algunos de los problemas asociados con ejecutar cada prueba de forma aleatoria en cada tabla. Es costoso y lento.
Otro aspecto interesante que descubrimos es que, a menudo, los errores de calidad de los datos no son realmente errores de calidad de los datos. Considera esto.
- Alguien modifica una columna en sentido ascendente.
- El trabajo de ingesta falla.
- Los trabajos de base de datos fallan; no hay datos nuevos.
- La prueba de calidad de datos alerta: no hay datos nuevos en una tabla importante.
- El analista de datos dedica una hora a la clasificación después de que el jefe de ventas indique que los datos parecen extraños, y finalmente los rastrea hasta el Sr. Alguien en el paso [1].
Todo este flujo podría haberse evitado si los analistas hubieran utilizado la herramienta de orquestación. Se habrían dado cuenta inmediatamente de que se modificó una columna y se produjo un error.
Por eso, con Orchestra, creamos un marco que nos ayuda a acercarnos al $1:
Presiona Enter o haga clic para ver la imagen a tamaño completo.
Con Orchestra, puedes:
- Identificar errores con anticipación: detiene los pipelines inmediatamente y los reinicia fácilmente desde el punto de fallo.
- Ejecutar pruebas de calidad de datos en tablas Iceberg: aprovechando nuestra integración con nuestro socio Bauplan. Esto significa que realizas pruebas desde la etapa de $1 y las capacidades de flecha de Bauplan hacen que las pruebas de calidad de datos se realicen en memoria, por lo que son gratuitas.
- Ejecutar detección de anomalías: identifica fácilmente trabajos y pruebas de larga duración para realizar pruebas proactivas de calidad de datos antes de que se produzcan errores.
- Ejecutar pruebas programadas fuera de dbt: aprender dbt puede ser complicado para quienes buscan ejecutar fácilmente pruebas de calidad de datos. En Orchestra, contamos con varias pruebas de calidad de datos que puedes ejecutar fuera de dbt, así como una integración de primera clase con dbt.
Esto convierte a Orchestra y dbt en la combinación perfecta para supervisar y prevenir proactivamente la calidad de los datos. Pasa de tener unas pocas pruebas básicas en dbt a un marco integral de calidad de datos empresarial.
Agregación de metadatos y linaje de extremo a extremo
Si bien dbt Cloud realiza tareas como aplanar artefactos y proporcionar linaje para proyectos dbt automáticamente, los equipos de datos a menudo dependen de otros metadatos importantes que se encuentran en diferentes ubicaciones.
Por ejemplo, tener un panel de observabilidad independiente es útil cuando se necesitan importar datos de registro de scripts ELT de ingesta o si varios equipos utilizan diferentes versiones de dbt.
Esto es fundamental para depurar las causas raíz de los fallos y garantizar que las temidas solicitudes de «Oye, los números no se ven bien» se mantengan al mínimo.
Con Orchestra, creamos una «capa de metadatos» propia para dbt y otros metadatos. Recopilamos automáticamente metadatos de toda la pila de datos y los limpiamos en un formato que funciona a la perfección con los datos dbt.
Presiona Enter o haz clic para ver la imagen a tamaño completo.
Código DBT → Cualquier código
Algo que nos encanta de DBT es que permite enviar consultas a tu almacén de forma estructurada.
Algo que nos habría ENCANTADO de DBT es que se pudiera escribir CUALQUIER SQL y, de hecho, CUALQUIER CÓDIGO.
Por eso, con Orchestra, mejoramos DBT para poder ejecutar cualquier código en Orchestrator. Paquetes como Airflow están escritos en Python y se ejecutan en servidores, lo que significa que prácticamente se puede ejecutar cualquier código (incluido DBT) en ellos.
Puedes hacer lo mismo en Orchestra, que permite combinar SQL (en DBT Core o en la nube), comandos de dialecto SQL específicos del almacén (por ejemplo, tareas de Snowflake o comandos de exportación de BigQuery) y Python, Bash, etc., en una sola vista.
Pulsa Intro o haz clic para ver la imagen a tamaño completo.
Conclusión: dbt es aún más potente con Orchestra
Todos recordamos nuestra primera experiencia con dbt. Fue el titular principal la primera vez que fui a Coalece y creo que la frase sigue vigente hoy en día.
A medida que más y más personas adoptan la ingeniería de datos en su conjunto, dbt Cloud es un excelente punto de partida para cualquiera que busque ejecutar dbt de la mejor manera.
Para los equipos de análisis avanzado, existe una clara necesidad de complementar dbt Cloud con herramientas como Orchestra para crear arquitecturas de datos escalables con canales de datos robustos que sean fáciles de depurar, fáciles de mantener y rápidos de construir.
En los últimos dos años, hemos tenido un éxito rotundo con diferentes empresas que utilizan este patrón de dbt Cloud para analistas/desarrollo de SQL y Orchestra para el plano de control general.
- Graniterock redujo drásticamente el tiempo de mantenimiento en un 50 %, duplicó la cantidad de productos de datos e identificó fácilmente las causas raíz con Orchestra y dbt Cloud.
- Hellmann desarrolló su conjunto de datos empresariales en tiempo récord utilizando Orchestra, dbt Cloud, Snowflake y AWS.
- Akebia redujo drásticamente los costos y el TCO en un 80 % al abandonar las herramientas tradicionales y optar por una combinación de Orchestra, dbt Cloud y Snowflake.
Nos entusiasma seguir ampliando los límites de la analítica y capacitando a analistas, ingenieros y a todos los niveles para que logren más con los datos y la IA.
Aprende más sobre Orchestra