Entre que los datos salen del origen y aterrizan limpios en BigQuery, alguien tiene que transformarlos. En Google Cloud, ese «alguien» suele ser Dataflow: el servicio gestionado que ejecuta pipelines escritos con Apache Beam sin que tengas que preocuparte de una sola máquina virtual.
Dataflow no es un motor propio, es un runner de Apache Beam
Apache Beam es un modelo de programación open source para definir pipelines de procesamiento de datos: lees de una fuente, aplicas transformaciones y escribes en un destino. Beam en sí mismo no ejecuta nada, necesita un runner que lo haga, y Dataflow es el runner gestionado de Google Cloud para esos pipelines. La ventaja de este desacoplamiento es la portabilidad: el mismo código Beam escrito en Java, Python o Go puede ejecutarse en Dataflow, y en teoría también en otros runners como Apache Flink o Spark, sin reescribir la lógica del pipeline.
Lo que aporta Dataflow encima de Beam es justo la parte que nadie quiere gestionar a mano: aprovisionar las VMs worker, coordinar el trabajo entre ellas, monitorizar el progreso y escalar los recursos según la carga real.
Un mismo modelo para batch y streaming
Una de las ideas centrales de Beam (y por tanto de Dataflow) es que el procesamiento por lotes (batch) y en tiempo real (streaming) usan el mismo modelo de programación. Un pipeline batch procesa un conjunto de datos acotado y termina; un pipeline streaming procesa un flujo continuo y sin fin, pensado para baja latencia e ingesta de volúmenes de datos que fluctúan en el tiempo.
Por defecto, Dataflow garantiza un procesamiento exactly-once (cada registro se procesa una sola vez), lo cual es importante en streaming para evitar duplicados en agregaciones o cargas incrementales. Para cargas que toleran algún duplicado ocasional a cambio de menor coste, existe también el modo at-least-once.
| Aspecto | Batch | Streaming |
|---|---|---|
| Naturaleza del dato | Conjunto acotado, con principio y fin | Flujo continuo, sin fin definido |
| Objetivo típico | Procesar un histórico o una carga diaria | Reaccionar a eventos casi en tiempo real |
| Duración del job | Termina al procesar todos los datos | Se mantiene en ejecución de forma continua |
Autoscaling: workers que suben y bajan solos
Dataflow puede autoescalar el número de VMs worker de forma horizontal: añade máquinas cuando detecta que el pipeline va con retraso o tiene más trabajo del que puede absorber, y las retira cuando ya no hacen falta. Además, optimiza dinámicamente cómo se reparte el trabajo entre las VMs activas, de forma que las tareas paralelas se completen de manera más eficiente sin esperar a que una sola máquina termine su porción.
En la práctica esto significa que no tienes que dimensionar el clúster pensando en el pico de carga del Black Friday particular de tu negocio: defines límites de mínimo y máximo de workers, y Dataflow ajusta el resto mientras el pipeline está en marcha.
Un patrón muy habitual en un pipeline de ingesta de datos es: Dataflow lee eventos en streaming (por ejemplo desde Pub/Sub), aplica una transformación ligera —parseo, filtrado, enriquecimiento— y escribe el resultado directamente en una tabla de BigQuery. Todo ese trabajo, desde el aprovisionamiento de recursos hasta el escalado, queda fuera de tu radar operativo: tu responsabilidad es el código del pipeline, no la infraestructura que lo ejecuta.
Qué contiene realmente un pipeline de Beam
A nivel de código, un pipeline de Beam se compone de un origen (PCollection de entrada), una serie de transformaciones encadenadas (ParDo, GroupByKey, ventanas de tiempo para agrupar eventos en streaming, etc.) y uno o varios destinos de escritura. Nada de esto menciona nunca cuántas máquinas lo van a ejecutar; esa decisión pertenece por completo al runner, en este caso Dataflow. Es justamente esa separación entre «qué transformar» y «cómo escalar la ejecución» la que hace que el mismo pipeline sirva igual para un archivo de prueba de un par de megas que para un flujo de eventos en producción.
Dataflow no sustituye a BigQuery ni a Cloud Storage, vive entre ambos: es la pieza que mueve y transforma los datos de un sitio a otro. Y cuando ese movimiento necesita ejecutarse en un orden concreto, coordinado con otros servicios, entra en juego un orquestador.
Si el destino final de tu pipeline de Dataflow es una tabla de BigQuery, te interesa diseñarla bien desde el principio: particionado y clustering marcan la diferencia en coste y rendimiento.
Leer sobre particionado y clustering en BigQuery