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.
Un connector es lo que está del otro lado de un Data Stream — el sistema de origen, y la mecánica para meter sus datos en Data 360 (antes Data Cloud). Elegí un connector, apuntalo a una fuente, y el stream aterriza esos datos como un Data Lake Object (__dll). Esta página es el mapa de desde qué podés ingerir y para qué sirve cada fuente; el stream en sí — categorías, schedule, el DLO que produce — es la página anterior, y el camino programático es la Ingestion API.
La regla que le gana a todo lo demás acá: el set de connectors disponible evoluciona, así que verificá la lista actual de connectors de la org antes de diseñar alrededor de uno solo. Salesforce agrega connectors y cambia sus capacidades release tras release. Todo lo de abajo describe la forma común y durable de cada categoría de fuente; tratá un connector específico como presente solo después de haberlo visto en el setup de la org, no porque una página lo dijo.
Las dos cosas que decide cada connector
Antes de las fuentes individuales, las dos propiedades que de verdad moldean un diseño:
- Batch o streaming. La mayoría de los connectors aterrizan datos en un schedule — corren, tiran un batch, y lo aterrizan (un file drop, un sync de CRM). Unos pocos son streaming — los eventos llegan de forma continua, en near-real-time. Esto no es un ranking de calidad; es una decisión de freshness. El freshness es un feature (principio 6): hacé que la cadencia de la fuente matchee la decisión más fresca que los datos alimentan, nunca el "más fresco es mejor". Un batch diario detrás de una activación en tiempo real es un bug de latencia; hacer streaming de una fuente que un batch nocturno serviría es costo desperdiciado (principio 11).
- Copia o zero-copy. La mayoría de los connectors copian datos al lake de Data 360. Zero-copy deja los datos en el warehouse de origen y los consulta ahí mismo — sin una segunda copia que mantener fresca. Esa diferencia es lo bastante grande como para tener su propia sección abajo.
Fuentes nativas de Salesforce
- Salesforce CRM. El connector para Sales Cloud, Service Cloud, y el resto de la plataforma core — objetos como Account, Contact y Lead, más tus objetos custom. Ingesta batch programada; es el primer stream más común en casi cualquier build, porque el CRM suele ser el sistema de registro de quién es el cliente.
- Marketing Cloud. Datos de engagement y de subscribers desde Marketing Cloud Engagement — los sends, opens y clicks que un practicante de Marketing Cloud conoce como las System Data Views, ahora ingeridos como un stream en vez de consultados en el lugar. Batch programado. Este es el connector que hace que el loop Data-360-alimenta-Marketing-Cloud (principio 8) sea de dos direcciones: el engagement de MC entra, un segmento resuelto activa de vuelta hacia afuera.
Almacenamiento de archivos en la nube
Estos ingieren archivos (típicamente CSV) que otro sistema deja caer en un bucket con una cadencia. Batch programado por naturaleza — Data 360 lee el archivo en su schedule, no recibe un push.
- Amazon S3 — leer archivos de un bucket de S3.
- Google Cloud Storage y Microsoft Azure Storage — los equivalentes para las otras dos nubes mayores.
El almacenamiento de archivos es el catch-all pragmático: cuando un sistema de origen no tiene connector directo pero sí puede exportar un archivo, un drop programado en un bucket es el camino. El costo es que vos sos dueño de la exportación — su schedule, su schema y su correctitud — y un archivo que silenciosamente deja de aterrizar se ve, aguas abajo, exactamente igual que una fuente sin datos nuevos.
Engagement desde tus propias propiedades: el Web/Mobile SDK
El Web/Mobile SDK captura eventos de comportamiento — page views, screen views, interacciones — desde tu sitio web y tus apps móviles, y los streamea hacia Data 360 como datos de engagement. Esta es la fuente streaming, near-real-time: los eventos llegan a medida que pasan, no en una corrida nocturna. Alimenta la categoría de stream Engagement (time-series, con event-time) que describe la página de data-streams, y es cómo metés señal de comportamiento first-party en el perfil unificado sin esperar a un batch.
Ingesta programática: la Ingestion API
Cuando ningún connector encaja con la fuente — una aplicación custom, un sistema que puede hacer push en vez de ser tirado — la Ingestion API es el camino programático. Tiene dos patrones: uno Streaming para payloads chicos en near-real-time y uno Bulk para subidas de archivos grandes. El detalle (qué patrón, la definición de schema por adelantado, los trade-offs) es su propia página — ver la Ingestion API. Acá alcanza con saber que existe como la salida de emergencia cuando la fuente no es un connector empaquetado.
Integración a escala: MuleSoft
Para fuentes que necesitan trabajo de integración real antes de ser ingeribles — sistemas legacy, APIs que requieren orquestación, transformación al vuelo — MuleSoft es el camino al que apunta Salesforce. Se ubica aguas arriba del stream: MuleSoft hace la integración, y el resultado aterriza en Data 360. Agarralo cuando la brecha entre la fuente y un ingest limpio es un problema de integración, no solo de conexión.
Zero-copy: consultá el warehouse sin copiarlo
Zero-copy es el que rompe la suposición de que "ingerir significa copiar". Con una conexión zero-copy a un data warehouse — Snowflake, Google BigQuery o Databricks — los datos se quedan en el warehouse y Data 360 los consulta donde viven. No hay una segunda copia física en el lake que mantener en sync, lo que significa ninguna copia que quede stale y ningún almacenamiento duplicado.
Verificá la lista de la org — no diseñes contra un nombre de una página
Como el catálogo de connectors se mueve con cada release, la postura de ingeniería honesta es confirmar qué tiene la org realmente antes de comprometer un diseño a eso. Si no estás seguro de si un connector específico existe o soporta la fuente que necesitás, tratá la categoría de fuente de forma genérica — "necesitamos ingesta de archivos programada", "necesitamos un feed de comportamiento en streaming" — y resolvela a un connector concreto contra el setup real de la org, no contra una suposición. Un diseño que nombra un connector que la org no puede habilitar es un rebuild que descubrís tarde.
Relacionado
- Data streams — el stream que alimenta un connector: de la fuente al DLO, la categoría y el schedule
- La Ingestion API — la fuente programática cuando ningún connector encaja: Streaming versus Bulk
- Refresh modes — full refresh versus upsert, la decisión de correctitud que hereda el stream de cada connector
- Gotchas de ingesta — fallas de auth y de límites de connectors que se ven como "no hay datos", y otras silenciosas
- Principios de Data 360 — el freshness es un feature (6), el costo escala con lo que procesás (11)
Referencia: