Ingesta de 10 TB de datos al día
Mantener una latencia de menos de un segundo de extremo a extremo
Mantenerse totalmente sin servidor, fiable y de nivel de producción
Este artículo detalla nuestra arquitectura, los retos a los que nos enfrentamos y cómo optimizamos el sistema para alcanzar los objetivos de rendimiento y rentabilidad.
Objetivos
Volumen de ingestión: 10 TB/día (~115 MB/seg sostenidos)
Objetivo de latencia: < 1 segundo desde la carga de datos hasta la visibilidad en BigQuery
Restricciones de diseño: Sin servidor, autoescalabilidad, operaciones mínimas
Servicios básicos: Cloud Functions, Pub/Sub, Dataflow (Apache Beam), BigQuery
Diseño y visión general de la arquitectura
[Productores de datos → Carga de GCS]
↓
(Evento de finalización de objeto) [Función en la nube desencadenada por GCS]
↓
[Tema Pub/Sub (Buffer)]
↓
[Trabajo de flujo de datos]
↓
[BigQuery (capa de análisis)
Función en la nube desencadenada por la carga de GCS
Nuestro pipeline de ingesta comienza cuando los archivos se suben a Google Cloud Storage. Una función de nube se activa automáticamente por los eventos de "objeto finalizado" de GCS.
Esta función
Analiza los metadatos GCS (bucket, nombre de archivo, marca de tiempo, fuente)
Añade etiquetas personalizadas o información de versión del esquema
Publica un mensaje en un tema Pub/Sub con metadatos
Optimizaciones
Asignación de memoria suficiente (~512 MB) para reducir los arranques en frío.
Reutilización de clientes de red para evitar la sobrecarga de sockets.
Posibilidad de 1000 ejecuciones simultáneas sin bloqueos por reintentos.
Pub/Sub: desacoplamiento y almacenamiento en búfer
Pub/Sub actuó como nuestro búfer de mensajes, permitiendo:
Escalado horizontal de consumidores descendentes
Capacidad de repetición en caso de fallo de los consumidores
Protección contra contrapresión mediante control de flujo
Cada mensaje contenía los metadatos que Dataflow necesitaba para cargar, transformar y enrutar los datos.
Flujo de datos: Motor de procesamiento de flujos
Utilizamos Dataflow (Apache Beam, Java SDK) en modo streaming para:
Obtener y analizar el contenido de archivos sin procesar de GCS
Aplicar transformaciones basadas en esquemas
gestionar la deduplicación mediante ventanas y marcas de agua
Escribir datos enriquecidos en BigQuery con un retraso de menos de un segundo
Optimizaciones de flujo de datos
Activación de Streaming Engine + Runner v2
Reequilibrio dinámico del trabajo y autoescalado (5-200 trabajadores)
División de archivos grandes en trozos más pequeños (ParDo + batching)
BigQuery: Capa de análisis en tiempo real
Los datos se transfirieron a una tabla de destino en BigQuery a través de la inserción de flujo. Un trabajo de transformación programado por separado particionó y agrupó los datos en tablas curadas.
Optimizaciones de BigQuery
Particionado por fecha de ingesta
Agrupados por source_id, event_type
Compactación de archivos diarios mediante consultas programadas
Utilización de métricas de búfer de flujo para detectar picos de retraso
Cuellos de botella y desafíos
Recuperación y observabilidad
Reintentos: Funciones en la nube y reintentos Pub/Sub + backoff
Colas de espera: Para eventos malformados o desajustes de esquema
Registro: Centralizado con Cloud Logging y etiquetas personalizadas
Métricas: Frescura de los datos, latencia, rendimiento y recuento de errores
Reprocesamiento: Reproducción manual o programada del flujo de datos desde GCS + Pub/Sub
Supervisión, optimización de costes y recuperación de fallos
No basta con crear una canalización ETL de alto rendimiento; también se necesita capacidad de observación y resistencia. He aquí cómo garantizamos la visibilidad, el control de costes y una sólida gestión de errores en nuestro canal ETL GCP de 10 TB/día.
Supervisión de la canalización
Aprovechamos Cloud Monitoring y Logging para realizar un seguimiento de cada componente en tiempo real:
Función de la nube:
Supervisión del recuento de invocaciones, la duración de la ejecución y las tasas de error mediante paneles de control de Cloud Monitoring.
Configuramos alertas para ejecuciones fallidas o picos anormales en la duración.
Pub/Sub:
Seguimiento de la acumulación de mensajes y el rendimiento mediante métricas Pub/Sub.
Se configuraron alertas para detectar el crecimiento de la acumulación de mensajes, lo que indica suscriptores lentos o que fallan.
Flujo de datos:
Supervisión del comportamiento del escalado automático, la utilización de la CPU, el uso de la memoria y el retraso del sistema.
Se configuraron alertas de retardo personalizadas para detectar retrasos en el procesamiento (por ejemplo, retardo en la ingestión de marcas de agua altas).
Utilización de los registros de trabajo de Dataflow para depurar errores de transformación, problemas de memoria o particiones sesgadas.
BigQuery:
Supervisión de los errores de inserción de secuencias y del rendimiento mediante los registros de auditoría de BigQuery.
Seguimiento del coste de las consultas, el uso de ranuras y la latencia para optimizar el rendimiento y el presupuesto.
Herramientas: Los paneles de control de la nube se personalizaron para nuestra canalización, con gráficos para:
Rendimiento (archivos/min, registros/seg)
Latencia (de extremo a extremo desde GCS a BQ)
Alertas de fallo de trabajos
Métricas de costes por servicio (almacenamiento/consulta en BQ, máquinas virtuales de flujo de datos, etc.)
Resultados
Escalado a una carga sostenida de 10 TB/día
Latencia media de extremo a extremo de ~600 ms.
Totalmente sin servidor y autoescalable con una sobrecarga operativa mínima
Las consultas en tiempo real y los análisis posteriores están disponibles en cuestión de segundos
Lecciones aprendidas
Cloud-native no significa que el compromiso de latencia por debajo del segundo sea alcanzable con los patrones adecuados.
Los desencadenadores basados en archivos de GCS son fiables si se diseñan para reintentos e idempotencia.
La clave del rendimiento es el preescalado, el ajuste por lotes y el desacoplamiento de etapas.
Conclusión
GCP proporciona una base sólida para crear canalizaciones ETL de alto rendimiento y baja latencia. Combinando desencadenadores basados en eventos, desacoplamiento Pub/Sub y flujos de datos en streaming, pudimos gestionar terabytes de datos al día con SLA en tiempo real.
Tanto si está modernizando un sistema por lotes como si está construyendo una arquitectura de streaming totalmente nueva, este diseño puede servirle de modelo. Póngase en contacto con nosotros para obtener más información o visite nuestra página de empleo para saber cómo formar parte del equipo Improving.
