Data streams: la unidad de ingesta | Cleon

Un Data Stream es la unidad de ingesta en Data 360 (antes Data Cloud): la conexión configurada que trae datos de un origen y los aterriza como un Data Lake Object (DLO) — los API names terminan en __dll — más o menos en la forma en que el origen los entregó. Cada origen que metés es un stream, y cada stream produce un DLO. Si hacés bien esta capa, todo lo de abajo tiene material limpio con qué trabajar; si la hacés mal, el error se propaga por identidad, query y activación antes de que alguien lo note.

Esta página es la columna vertebral de la subcategoría Ingesta: qué es un stream, las tres cosas que configurás sobre él (origen, categoría, schedule), y dónde termina la ingesta y empieza el modelado. No cubre los orígenes individuales — eso es la página de connectors — ni cómo los DLOs se vuelven objetos con significado, que es trabajo de Arquitectura de datos y vive en mapping.

Qué es un Data Stream

Un Data Stream es una definición, no una importación de una sola vez. Nombra un origen, una forma de conectarse a él, y un schedule, y en cada corrida aterriza los registros del origen en un DLO. El DLO es el piso crudo: contiene los datos en la estructura del origen — sus campos, sus tipos, su grain — sin significado de negocio atado todavía.

Esa separación es deliberada y es el principio 2 en la práctica. El trabajo del stream es aterrizar datos con fidelidad; asignar qué significan los datos es un paso aparte. Un mismo origen puede producir más de un DLO, y el DLO de un stream es lo que lee cada paso posterior — así que la forma que aterrizás es la forma que hereda el resto de la org.

Origen            Data Stream              DLO (__dll)            DMO (__dlm)
(CRM, S3, SDK) ──[conectar + schedule]──▶  aterrizaje  ──map──▶  significado armonizado
                  ingesta                   crudo                Arquitectura de datos
                                            esta página

Las tres cosas que configurás

1. El origen

Cada stream se conecta a exactamente un origen a través de un connector o la Ingestion API — Salesforce CRM, Marketing Cloud, un bucket de cloud storage, el Web/Mobile SDK, y otros. Qué orígenes están disponibles depende de tu org y de tu licenciamiento, así que verificá la lista en vez de asumir que un connector específico existe. El catálogo completo de orígenes y para qué sirve cada uno vive en la página de connectors.

2. La categoría

Cuando creás un stream le asignás una categoría, y la categoría no es cosmética — le dice a Data 360 cómo se comportan los datos y constriñe qué podés hacer con ellos aguas abajo. Hay tres:

Profile — datos que describen a una persona o entidad: un cliente, una cuenta, un contact point. Un registro por sujeto, actualizado a lo largo del tiempo. Este es el material que la resolución de identidad unifica.
Engagement — datos de eventos de serie temporal: una apertura de email, una compra, una vista de página, un evento de app. Cada registro es algo que pasó en un momento, así que un stream Engagement requiere un campo de event-time — el timestamp que ubica el evento en una línea de tiempo. Sin él, los datos no son una serie temporal usable.
Other — datos de referencia o lookup que no son ni un perfil ni un evento: un catálogo de productos, una lista de tiendas, una tabla de categorías. Soporta a los otros dos sin ser ninguno.

Elegí la categoría equivocada y la restricción aparece después, no ahora. El error clásico es aterrizar datos de evento como un stream Profile: ingiere, se ve bien, y después la segmentación por ventana de tiempo y las métricas de engagement no tienen sobre qué pararse porque los datos nunca se modelaron como serie temporal. Elegir la categoría es la primera decisión de modelado que tomás, aunque pase en la ingesta — por eso ancla al principio 1: el modelo es un contrato que diseñás antes de que se conecte el primer stream.

3. El schedule de refresh

Un stream no es una carga única; refresca con una cadencia que configurás vos, y esa cadencia es una decisión real, no un default que aceptás. El schedule determina qué tan fresco está el DLO — y por lo tanto todo lo de abajo — en la práctica. Esto es el principio 6 hecho concreto: la frescura es un feature. Un stream que refresca a diario detrás de una decisión que necesita datos near-real-time es un bug de latencia esperando para sorprender a alguien; un stream que transmite en continuo para alimentar un batch de una vez al día es costo desperdiciado (principio 11).

Cómo un refresh aplica sus datos — reemplazar el set entero versus mergear por una key — es un eje aparte de cada cuánto corre, y carga el gotcha central de corrección de la ingesta. Eso pertenece a refresh modes; acá, el punto es solo que la cadencia es algo que elegís deliberadamente y anotás al lado del stream.

Dónde termina la ingesta y empieza el modelado

La responsabilidad de un Data Stream para en el DLO. El DLO es aterrizaje crudo; convertirlo en un Data Model Object (DMO) — los API names terminan en __dlm, los estándar en el namespace ssot__ — es el paso de modelado, y pertenece a Arquitectura de datos, no a la ingesta.

Este límite importa porque los dos son fáciles de confundir y caro confundirlos. Un DLO es lo que ingeriste; un DMO es lo que significa. Mapear un DLO uno-a-uno sobre un DMO y llamarlo modelado solo reubica el desorden del sistema de origen en la capa que lee cada segmento y cada agente. La decisión de mapping — qué campo del DLO carga qué significado de negocio, cuál es la key, cómo se relacionan los objetos — está documentada en mapping y Data Lake Objects. Esta página no la redefine. El handoff es lo que tenés que tener en la cabeza: la ingesta aterriza el DLO, Arquitectura de datos le da significado, y la calidad del stream pone el techo de todo lo que sigue.

Relacionado

Connectors — el catálogo de orígenes a los que un Data Stream se puede conectar, y para qué sirve cada uno
Refresh modes — full refresh vs upsert: cómo un stream aplica sus datos, y el gotcha de los deletes
Data Lake Objects — el objeto de aterrizaje crudo que crea un stream, y por qué lo mapeás en vez de construir sobre él
Principios de Data 360 — por qué el modelo bajo el stream es el producto (principios 1 y 6)

Referencia: