E210 - Intro a Dataform

Descargar video (720p, 318 MB)

Resumen

El episodio presenta una introducción a Dataform, la herramienta de Google (integrada con BigQuery y GCP) que se enfoca en la "T" de ELT. Se plantea que en sistemas productivos conviene evitar SQL puro, que se rompe, no escala y se vuelve difícil de mantener. Existen alternativas: Python con f-strings, dplyr en R, dbt o Dataform. Se explican los archivos SQLX (SQL más un bloque de configuración en JavaScript), las referencias `ref`, el grafo de dependencias, las assertions (estándar y custom), las tablas incrementales con `self`, la reutilización con funciones y listas en JavaScript, y los tags para ejecutar flujos parciales. Se comparan Dataform, dbt, Python y Great Expectations, y se recorre un repo de ejemplo con Terraform. Conclusión principal: Dataform conviene si el equipo ya lo usa o si se trabaja en GCP con flujos relativamente simples. dbt o Python son mejores para casos más complejos o fuera de GCP. Para exploración no hace falta nada de esto.

Capítulos

• 00:00
  IntroSe presenta el episodio sobre Dataform, una herramienta que el presentador estudió durante el fin de semana porque deberá usarla en su trabajo. La presenta como una alternativa a SQL.
• 00:29
  Por qué no SQL puroDataform es una forma más estructurada de usar scripts SQL. El presentador no ocupa SQL puro hace unos 8 años y opina que lo importante es saber extraer información, sea con SQL o con herramientas que lo generan por debajo.
• 01:15
  Alternativas Python y RUna alternativa es escribir la query como cadena en Python y parametrizarla con f-strings. En R basta usar dbplyr (select, group by, etc.), que se transforma a SQL. También menciona dbt como herramienta similar.
• 02:44
  Dataform vs dbt en GCPEl presentador solo ha leído proyectos en dbt, sin crearlos, y entiende que dbt es más general. Dataform interesa porque Google lo compró y lo integró con BigQuery y GCP, lo que facilita montar el ambiente. Anuncia teoría primero y demo después, con un repo abierto en GitHub.
• 04:06
  Caso demo e-commerceSe simula una tienda online con órdenes, ítems, clientes, productos y eventos, con ventas en muchos países y canales, y marketing con embudos de conversión y click through rate. El punto de partida son scripts SQL separados por tema.
• 05:19
  Problemas en producciónLos scripts copiados y pegados se rompen en producción: scripts ejecutados fuera de orden, datasets renombrados, duplicados que rompen el sistema sin verificarse explícitamente. También cuesta saber de dónde sale una columna, y los comentarios se desactualizan. Aclara que esto aplica a producción y no a la exploración de una query.
• 07:30
  Qué es Dataform y ELTDataform se enfoca en la T de ELT. En ETL se transforma localmente antes de cargar; en ELT se carga primero (por ejemplo a BigQuery) y se transforma en la nube. Dataform transforma, verifica la información y ordena la ejecución.
• 10:17
  SQLX y metadatosLos archivos SQLX son casi 100% SQL, con un encabezado de metadatos escrito en JavaScript. Se usa la CLI de Dataform, y el flujo completo incluye extracción, carga a BigQuery, Dataform y validaciones posteriores. Integra un repositorio git, lo que el presentador ve como buena práctica obligatoria más que como diferenciador.
• 13:17
  Dependencias y grafoEl compilador genera los archivos SQL que se ejecutan en BigQuery, que puede dispararse por eventos o manualmente. Las referencias evitan depender de nombres fijos, y Dataform detecta dependencias, calcula el orden de ejecución, permite el paralelismo cuando no hay dependencias y detecta dependencias circulares. El grafo se puede visualizar.
• 14:29
  Assertions y testsLas assertions verifican condiciones, por ejemplo que una columna no tenga nulos. Un SQLX tiene un bloque de configuración (tipo, tags, esquema, descripción, assertions) y luego el SQL. Hay assertions estándar como llave única en customer ID y campos no nulos en customer ID y email.
• 16:23
  Referencias ref y portabilidadEn el `from` se usa una referencia en vez del nombre completo de la tabla. Al compilar, Dataform la reemplaza por proyecto, dataset y tabla, lo que facilita trasladar el proyecto y hace innecesario actualizar referencias a mano. El presentador insiste en que existen otras herramientas y en no usar SQL puro para algo robusto.
• 21:09
  Particiones y configuraciónLa configuración define si es tabla, vista o incremental, y cómo particionar en BigQuery. `partition by` sirve para baja cardinalidad (por ejemplo fechas) y `cluster` para alta cardinalidad (país, canal, ID de cliente). Un comentarista que migra un modelo de datos bancarios opina que no ve milagros; el presentador responde que no es nada mágico.
• 24:14
  Assertions custom ejemploLas assertions se pueden separar en archivos propios y existen custom con reglas de negocio. Una assertion es una query que busca problemas, y si devuelve filas el proceso se corta. El ejemplo compara los customer ID entre órdenes y clientes. Se ejecutan durante el flujo, lo que permite fallar rápido y evitar datos corruptos.
• 28:20
  Dataform vs Python y GESe discute cuándo elegir Dataform, dbt o Python. Dataform conviene para flujos estándar en GCP, dbt es más genérico y tiene mayor comunidad, y Python sirve para casos muy custom. En general conviene adaptarse a la herramienta que ya usa el equipo. Great Expectations se considera complementario, para validar a posteriori tablas en producción o feature stores. Los datos deben estar ya cargados en la nube.
• 35:58
  Incrementales y selfLas tablas incrementales agregan solo los registros que faltan en vez de reescribir todo, lo que permite procesar en batch. `self` referencia la misma tabla, y la condición solo agrega datos con fecha mayor al máximo ya existente. El DDL queda guardado y versionado en un archivo.
• 39:10
  Reutilización y loops JSSe define en JavaScript una lista de pasos del embudo (page view, add to cart, begin checkout, purchase), exportada, y una función en `helpers` que devuelve un `count distinct if` para cada paso. La misma lógica se reutiliza sin copiar y pegar.
• 41:03
  Leer JavaScript sin saberloNo hace falta dominar JavaScript, basta con entender la lógica y poder pedírsela a una IA. Quien sabe programar en un lenguaje puede leer los demás.
• 41:45
  Helpers y referencias en DataformSe muestra cómo se aplica la función de `helpers.js` sobre la lista de `constants`. Los participantes se confunden y el presentador aclara que antes solo se mostraban definiciones y ahora se aplican.
• 43:48
  Iteraciones y columnas dinámicasLa iteración genera varias columnas de forma implícita, y agregar otra solo requiere añadirla a la lista. Si cambia la lógica, se cambia la función. Evita el olvido humano al actualizar varios lugares.
• 46:16
  Por qué esto importa en producciónEl presentador reitera que no es para queries exploratorias, sino para productos de datos, como una tabla de clientes con probabilidad de no pago. En producción un fallo puede significar pérdidas de dinero o cobros erróneos. Aun así, conviene entender estas herramientas para leer los sistemas productivos.
• 47:52
  Iterar queries y usar tagsSe pueden generar queries enteras con la misma estructura variando el tipo de evento. Con tags se ejecuta solo un subconjunto del flujo (ventas, no pago, etc.) con sus dependencias. Existen pre y post operations, por ejemplo un `alter table`, y la sincronización con git en la rama main dispara compilación y ejecución.
• 51:27
  Qué es Dataform realmenteSe describe como SQL con metadatos que indican al sistema en la nube cómo tratar cada query. Se compila primero a las queries reales y luego se envían a BigQuery. Los logs de la plataforma muestran las ejecuciones, su orden y las queries ejecutadas.
• 53:50
  Costos, CI/CD y robustezNo se necesita infraestructura on premise. El servicio de Dataform es gratis y solo se paga BigQuery, con integración nativa con IAM, BigQuery y Terraform. La curva de aprendizaje es suave, el grafo se calcula solo, las assertions corren antes de las queries, y se fuerza el uso de Git y CI/CD. Se discute si el dry run permite validar la sintaxis.
• 56:22
  Contras y cuándo usarloContras: muy orientado a Google, comunidad y ecosistema más chicos que dbt, hay que saber leer JavaScript, el desarrollo local es limitado porque se ejecuta en BigQuery, la orquestación puede depender de otros sistemas y la documentación es menos extensa. Conviene si el equipo ya lo usa o se trabaja en GCP con casos simples; si no, dbt, Python o R.
• 58:07
  Tour del repo y Terraform labSe muestra el repo con una carpeta Terraform para crear el laboratorio en GCP (con unos 300 de crédito por 90 días). Detalla variables, el README con prerrequisitos (Google Cloud CLI, Terraform, Python, git, Node.js), Make para simplificar comandos, el token de acceso al repositorio para Dataform, `terraform init/plan/apply` y `destroy`, y scripts de Python que generan datos aleatorios y permiten romper las queries a propósito.
• 01:05:24
  Estructura SQLX y sourcesLos SQL base con malas prácticas están en la carpeta SQL y las versiones mejoradas en SQLX. Se definen las fuentes (datos raw ya cargados en BigQuery), las tablas y sus columnas, y las queries se encadenan por referencias (facts, order items). Se comenta que un data scientist debe entender Terraform aunque no lo configure, y que Ansible configura recursos ya creados mientras Terraform los crea.
• 01:09:13
  CierreSe comenta la rifa de una suscripción a Claude, el contexto laboral del presentador como data scientist y el costo del lab (un par de dólares). Se anuncia un próximo episodio sobre skills de Claude y se insiste en entender el flujo de datos de principio a fin y en revisar el código generado por IA antes de producción.

Palabras clave