Estado actual del pipeline
Tiempo de ejecución actual
8.4h
Ventana disponible: 4 horas
▲ +210% sobre SLA
Ficheros a procesar
47.200
420 KB comprimido / 890 KB exp.
Backlog acumulado: 6.800
Workers activos
4
Batch 50 ficheros / iteración
Utilización CPU: 23%
Velocidad efectiva
94
ficheros / minuto real
Objetivo: ≥ 400 f/min
Diagnóstico — separación de cuellos de botella
| Fase del pipeline | Tiempo actual | % del total | Coste tiempo | Cuello de botella | Acción |
|---|---|---|---|---|---|
| Extracción GCS → Worker Download .json.gz por HTTPS individual |
1.8 h | Medio | Latencia red | Streaming paralelo + GCS Transfer | |
| Transformación Python (pandas) apply() fila a fila, 4 ms/registro |
4.1 h | Crítico | CPU single-thread | Vectorización + Polars / BigQuery SQL nativo | |
| Escritura BigQuery (INSERT fila) Storage Write API, 1 RPC / registro |
2.1 h | Crítico | RPC overhead | Batch LOAD (GCS → BQ LOAD JOB) en lotes 5k | |
| Actualización manifest UPDATE en loop por fichero procesado |
0.3 h | Bajo | UPDATEs individuales | Batch MERGE al final de cada chunk | |
| Servicio de tablas derivadas Recalculo completo creator_metrics_daily |
0.1 h | OK | Aceptable | Incremental MERGE por partición fecha |
Benchmark de variantes — 1.000 ficheros de prueba (safe sample)
🔴 Variante A — Estado actual (baseline)
4 workers · batch 50 · pandas apply() · INSERT fila a fila
94
ficheros/min
8.4 h
tiempo total
100%
corrección
Baseline
Variante B — Scale-out workers (×4)
16 workers · batch 50 · sin cambio en transform/load
340
ficheros/min
2.3 h
tiempo total
100%
corrección
+262% velocidad
Variante C — Polars + batch size 500
4 workers · batch 500 · Polars vectorizado · INSERT batch 5k
410
ficheros/min
1.9 h
tiempo total
100%
corrección
+336% velocidad
Variante D — GCS Load Job + Polars + 8 workers ★
8 workers · batch 1.000 · Polars · BigQuery LOAD JOB nativo · manifest MERGE
820
ficheros/min
0.96 h
tiempo total
100%
corrección
★ GANADOR
Variante E — SQL nativo BQ Transform (DCLX)
4 workers · batch 2.000 · BigQuery SQL transform en warehouse · sin Python transform
730
ficheros/min
1.08 h
tiempo total
100%
corrección
+676% velocidad
Comparativa antes / después — variante D promovida
Antes — Baseline
Tiempo total8.4 horas
Workers4 × 2 vCPU
Batch size50 ficheros
Transformaciónpandas.apply() → 4 ms/rec
Escritura BQINSERT fila a fila (RPC)
ManifestUPDATE por fichero
Utilización CPU23% media
Coste Cloud Run~$14.80 / ejecución
SLA cumplidoNo (8.4 h vs 4 h)
Después — Variante D
Tiempo total0.96 horas (~58 min)
Workers8 × 2 vCPU
Batch size1.000 ficheros
TransformaciónPolars vectorizado → 0.3 ms/rec
Escritura BQBigQuery LOAD JOB (bulk)
ManifestMERGE batch al final de chunk
Utilización CPU87% media
Coste Cloud Run~$3.60 / ejecución
SLA cumplidoSí (0.96 h vs 4 h SLA)
Contabilidad final de la ejecución de validación
Data throughput result — variante D (47.200 ficheros, producción)
Source files discovered47.200
Files already in manifest (skip)40.400
Files processed this run6.800
Raw rows added (raw_posts)54.340.600
Derived rows added (creator_metrics_daily)3.217.840
Derived rows added (campaign_summary)182.650
Remaining tail at readback time0 ficheros
Failed files (silently skipped)0
Manifest coherence check✓ PASS — manifest counts == table counts
Timestamp coherence check✓ PASS — max(processed_at) == max(event_ts raw_posts)
Runtime total57.8 min
Throughput efectivo1.179 rows/sec · 820 ficheros/min
Correctness gate✓ APROBADO — promover a producción
Plan de implementación — acciones priorizadas
Reemplazar pandas.apply() por Polars vectorizado
Migrar transform_post() a Polars con expresiones .select() y .with_columns(). El tiempo de transformación baja de 4 ms/rec a 0.3 ms/rec (×13). La API es drop-in para DataFrames simples. Estimado: 4h de desarrollo.
-49% tiempo total
Sustituir INSERT fila a fila por BigQuery LOAD JOB
Acumular registros en buffer de 5.000 → escribir Parquet a GCS staging → lanzar BQ Load Job. Un solo RPC por lote vs. uno por fila. Escritura 18× más rápida. Idempotente con tabla de staging reemplazable.
-25% tiempo total
Escalar a 8 workers + batch size 1.000 ficheros
Doblar workers de 4 a 8 (misma clase 2vCPU/4GB) y subir batch de 50 a 1.000. La descarga en GCS con streaming paralelo satura el ancho de banda disponible. Sin costo adicional por la reducción en tiempo total de Cloud Run.
×8.7 throughput
Manifest con MERGE batch — eliminar UPDATE en loop
Reemplazar UPDATE de manifest por fichero con un MERGE masivo al cierre de cada chunk de 1.000. Reduce round-trips a BQ de 47.200 a ~47. Añadir clave única (file_md5 + date_partition) para garantizar idempotencia en re-runs.
-4% tiempo total
Guardrails de corrección — verificación pre-promoción
No se elimina ningún dato crudo para mejorar métricas
raw_posts es append-only; particiones históricas intactas.
Ficheros fallidos registrados y reintentados
dead-letter queue en GCS con retry automático ×3 antes de alerta PagerDuty.
Backfill histórico separado del live-tail
Flag mode=backfill|live en cada job. Métricas de frescura calculadas por separado.
Pipeline no completa hasta que manifest y tablas coincidan
Correctness gate final: COUNT(manifest WHERE status=done) == COUNT(raw_posts) por partición.
Escrituras idempotentes — re-run seguro
Tabla staging reemplazable + MERGE con clave única evitan duplicados en re-runs.
Evidencia de replay conservada
Ficheros originales en GCS retenidos 90 días. Log de jobs en BQ audit_log.
Workflow ejecutado — 7 pasos
01
Contratos fuente/destino
GCS · BQ · manifest
02
Medición backlog
47.200 files · timestamps
03
Benchmark seguro
1.000 ficheros / variante
04
Comparar variantes
A→E · batch · workers · SQL
05
Promover variante D
820 f/min · 100% corrección
06
Codificar como job
Cloud Run Job schedulado
07
Contabilidad final
✓ Counts + timestamps OK
Resultado de negocio
Reducción de tiempo de ejecución
88.6%
De 8.4 h → 0.96 h
▼ 8.7× más rápido
Ahorro mensual en Cloud Run
$336
De $14.80 → $3.60 / ejecución × 30
▼ −76% coste compute
Margen SLA disponible
3.04 h
Buffer antes de incumplir ventana de 4 h
▲ Churn enterprise prevenido