DATA 360 / INGESTA
Ingesta
Meter la data: Data Streams, connectors (CRM, Marketing Cloud, S3, SDK web/mobile), la Ingestion API, y los refresh modes — full vs incremental y cuándo te muerde cada uno.
Fundamento · 2
Nota de producción
Gotchas de ingesta: las fallas silenciosas al frente del pipeline
Las fallas de ingesta que no lanzan un error. Un upsert conserva registros borrados en el origen porque nada le avisó que se fueron; un full refresh sobre un origen enorme factura como una decisión de costo que nadie tomó; una clave no única sobrescribe un registro; una cadencia diaria queda detrás de una decisión en tiempo real; datos de evento aterrizan como stream Profile y la serie temporal nunca existe; un DLO se infla porque nadie reconcilia lo que ingiere contra lo que usa; un conector pierde la autenticación en silencio y parece un origen sin datos. Siete gotchas, cada uno como el instinto, lo que pasa de verdad en producción, y el arreglo.
Marco de decisión
Ingesta en Data 360: Style Guide
Las reglas opinadas que Cleon aplica a cada decisión de ingesta en Data 360 — la decisión streaming-vs-batch-programado decidida por la decisión downstream más fresca, la decisión full-refresh-vs-upsert decidida por una key nombrada y una historia de deletes explícita, la disciplina de cadencia y costo, los patrones a preferir y los a rechazar, más un checklist de pre-ship para cualquier Data Stream nuevo. El documento de disciplina que ata la subcategoría de Ingesta.
Referencia · 5
Referencia
Data streams: la unidad de ingesta
Qué es un Data Stream: la conexión configurada de origen a Data 360 que aterriza un DLO. La categoría del stream — Profile, Engagement u Other — y qué constriñe aguas abajo, el schedule de refresh, y dónde termina la ingesta y empieza el modelado.
Referencia
Connectors: desde dónde ingiere Data 360
Las fuentes desde las que ingiere un Data Stream y para qué sirve cada una — Salesforce CRM, Marketing Cloud, Amazon S3, Google Cloud Storage y Microsoft Azure Storage, el Web/Mobile SDK, la Ingestion API, MuleSoft, y zero-copy sobre Snowflake, BigQuery y Databricks. La naturaleza batch-versus-streaming de cada una, y por qué el set disponible es algo que verificás en la org, no que memorizás de una página.
Referencia
La Ingestion API: streaming vs bulk
Ingesta programática para cuando ningún conector empaquetado encaja: los dos patrones de la Ingestion API — Streaming (payloads chicos, near-real-time, asincrónicos) y Bulk (cargas de archivos/CSV grandes) — cuándo encaja cada uno, cuándo agarrar la API en vez de un conector, y el requisito previo de que haya una fuente y un schema definidos antes de mandar un solo registro.
Referencia
Modos de refresh: full refresh vs upsert
El modo de refresh de un Data Stream decide cómo cada corrida reconcilia contra lo que ya aterrizó. El full refresh reemplaza el dataset entero en cada corrida y captura las bajas por ausencia; el upsert inserta-o-actualiza con una primary key — más liviano e incremental, pero una key equivocada o no única duplica o sobrescribe en silencio, y no elimina los registros borrados en el origen salvo que mandes las bajas explícitamente.
Referencia
La ingesta y el ciclo de vida: lo que hereda cada capa de abajo
La ingesta es el frente del ciclo de vida de Data 360, y cada capa posterior hereda lo que aterrizaste. El handoff de DLO a DMO, y cómo la frescura y la corrección de la ingesta alimentan la resolución de identidad, query, segmentación y agent-readiness — una ingesta vieja o mal-keyeada aparece como un bug aguas abajo a tres capas de distancia.