Guía de estudio de Arquitectura de datos

El conjunto de decisiones, modelos, políticas y estándares que definen cómo se recogen, guardan, integran, procesan, gobiernan y consumen los datos en una organización, y los sistemas que los implementan.

Traduce las necesidades del negocio en estructuras y plataformas de datos: elige tecnologías y patrones, diseña modelos y flujos, define estándares de calidad, seguridad y gobierno, documenta las decisiones y orienta a los equipos para que los sistemas encajen y evolucionen sin rehacer todo constantemente.

Fuentes, ingesta (batch, CDC, streaming), almacenamiento (lake, warehouse, almacenes operativos), procesamiento y transformación, servicio (BI, APIs, features de ML, reverse ETL), y transversalmente orquestación, gobierno, seguridad, observabilidad y metadatos.

Tratar los datos como un producto con responsables; diseñar para el cambio (bajo acoplamiento, contratos); tener una única fuente de verdad por entidad; guardar los datos en bruto de forma inmutable y reprocesar cuando cambia la lógica; asegurar y gobernar por defecto; automatizarlo todo como código; optimizar para las preguntas que la gente hace; y preferir componentes simples y administrados cuando cumplen los requisitos.

Los modelos conceptuales muestran las entidades de negocio y sus relaciones para las partes interesadas; los lógicos añaden atributos, claves y normalización sin detalles tecnológicos; los físicos los implementan en una base concreta con tipos, índices, particiones y decisiones de almacenamiento.

Funcionales: qué datos, transformaciones, métricas y salidas se necesitan. No funcionales: latencia, frescura, volumen, escalabilidad, disponibilidad, durabilidad, seguridad, cumplimiento, costo y mantenibilidad, que a menudo determinan la elección de tecnologías.

Un documento corto que recoge una decisión importante: contexto, opciones consideradas, decisión, consecuencias y estado. Los ADR hacen visible el razonamiento y evitan que los equipos vuelvan a discutir lo ya decidido; se guardan junto al código.

Atajos que encarecen los cambios futuros: pipelines sin documentar, lógica duplicada, configuración escrita en el código, pruebas faltantes, tablas sin responsable, arreglos rápidos en producción. Se acumula en silencio y aparece como incidentes, entregas lentas y desconfianza en las cifras.

Elegir entre construir componentes propios (más control, más mantenimiento) y usar servicios administrados o proveedores (más rápido, menos control, costo recurrente, dependencia). La mayoría de los equipos compra las capacidades estándar (almacenamiento, warehouse, conectores) y construye lo que los diferencia.

Depender de los formatos o APIs propietarios de un proveedor, lo que encarece cambiar. Se limita con formatos abiertos (Parquet, Iceberg, Delta), SQL estándar, infraestructura como código, abstracciones donde sean baratas y planes de salida para los componentes críticos, aceptando cierta dependencia donde el valor es alto.

Gestionar los datasets como productos: un responsable claro, propósito y esquema documentados, garantías de calidad y SLA, facilidad para descubrirlos, versionado y retroalimentación de los consumidores. Es una idea central del data mesh, pero útil en cualquier arquitectura.

Las plataformas y equipos centralizados dan coherencia, economías de escala y un gobierno fuerte, pero se convierten en cuellos de botella. La propiedad descentralizada por dominio escala la entrega y acerca la experiencia a los datos, pero arriesga incoherencias y esfuerzo duplicado; el gobierno federado los equilibra.

La arquitectura de datos define el plano: estructuras, estándares, elección de tecnologías y cómo encajan los componentes. La ingeniería de datos construye y opera los pipelines y plataformas que lo implementan. En la práctica los roles se solapan, y los ingenieros sénior toman muchas decisiones de arquitectura.

Partiendo de los requisitos, comparando unas pocas opciones con criterios (encaje, rendimiento, costo, habilidades, ecosistema, soporte, seguridad, dependencia), haciendo una prueba de concepto con cargas reales, considerando el costo total de propiedad y el costo de salida, y registrando la decisión en un ADR.

El costo completo de una solución en el tiempo: licencias o consumo en la nube, infraestructura, personas para construirla y operarla, formación, migración, soporte y el costo de las caídas, no solo el precio por unidad de cómputo.

Diseñar los sistemas para que cambien de forma incremental con salvaguardas (fitness functions como pruebas sobre latencia, costo o acoplamiento), prefiriendo decisiones reversibles y pasos pequeños frente a grandes diseños iniciales.

Los datos en bruto inmutables permiten reprocesar el historial cuando cambian la lógica o se corrigen errores, auditar lo que enviaron las fuentes y reconstruir las capas posteriores; las modificaciones ocurren en las capas siguientes, lo que mantiene el sistema recuperable.

Cada pipeline o modelo debe tener un propósito claro (ingerir una fuente, homogeneizar una entidad, construir una métrica), lo que facilita probarlo, asignarle un responsable, reutilizarlo y cambiarlo sin efectos secundarios.

Relacionales (PostgreSQL, MySQL, Oracle), clave-valor (DynamoDB, Redis), documentales (MongoDB, Couchbase), de columnas anchas (Cassandra, HBase, Bigtable), de grafos (Neo4j, Neptune), de series de tiempo (TimescaleDB, InfluxDB), de búsqueda (Elasticsearch, OpenSearch), vectoriales (pgvector, Pinecone, vectores de OpenSearch) y almacenes analíticos columnares (warehouses, ClickHouse, Druid).

Cuando los datos son estructurados y tienen relaciones, necesitan transacciones ACID, consultas flexibles con joins y consistencia fuerte: pedidos, pagos, cuentas, inventarios. Es la opción por defecto de la mayoría de los sistemas operativos.

Cuando los registros son autocontenidos, anidados y con esquema flexible (catálogos de productos, contenidos, perfiles de usuario), se acceden sobre todo por clave o con consultas sencillas, y los equipos quieren hacer evolucionar el esquema rápido.

Para búsquedas muy rápidas por clave a gran escala (sesiones, cachés, preferencias de usuario, carritos de compra), con patrones de acceso simples y latencia predecible.

Para volúmenes de escritura masivos y conjuntos de datos grandes accedidos por clave de partición con patrones de consulta conocidos, como series de tiempo, IoT, mensajería y logs de eventos (Cassandra, Bigtable, HBase).

Cuando las relaciones son el objeto principal del análisis: redes de fraude, redes sociales, recomendaciones, topologías de red, grafos de conocimiento, con consultas que recorren muchos saltos.

Usar distintas tecnologías de almacenamiento para distintas necesidades dentro de un sistema (PostgreSQL para pedidos, Redis para sesiones, Elasticsearch para búsqueda, S3 para archivos), aceptando más complejidad operativa a cambio de ajustarse mejor a cada caso de uso.

El almacenamiento de objetos inmutables en buckets accedidos por clave mediante HTTP (S3, ADLS, GCS): prácticamente ilimitado, muy durable, barato y desacoplado del cómputo. Los data lakes y lakehouses se construyen sobre él, y los formatos de tabla le añaden funciones de base de datos.

El de bloques da volúmenes en bruto para una máquina (EBS), ideal para bases de datos; el de archivos da sistemas de archivos jerárquicos compartidos (NFS, EFS); el de objetos da objetos planos accesibles por HTTP a enorme escala (S3), ideal para data lakes.

Clases de almacenamiento con distinto costo y velocidad de acceso (caliente, tibio, frío, archivo; S3 Standard, Infrequent Access, Glacier). Las políticas de ciclo de vida mueven los datos que envejecen a niveles más baratos.

Los formatos por filas (CSV, JSON, Avro) guardan los registros juntos, buenos para escribir y leer registros completos; los columnares (Parquet, ORC) guardan las columnas juntas con estadísticas, buenos para analítica que lee pocas columnas de muchas filas.

Especificaciones (Apache Iceberg, Delta Lake, Apache Hudi) que añaden una capa de metadatos transaccional sobre archivos Parquet en almacenamiento de objetos, con escrituras ACID, evolución del esquema, viaje en el tiempo, evolución de particiones y actualizaciones eficientes, legibles por muchos motores.

Delta es nativo de Databricks y muy usado en Spark; Iceberg tiene el soporte multimotor más amplio (Snowflake, Athena, Trino, Spark, Flink) y un catálogo REST abierto; Hudi se enfoca en los upserts de streaming y el procesamiento incremental. Elige según tus motores, tu catálogo y tu gobierno; las funciones de interoperabilidad (UniForm, XTable) reducen las diferencias.

Registra qué tablas existen, dónde están sus archivos, sus esquemas y permisos, para que los motores encuentren y gobiernen los datos: Hive Metastore, AWS Glue, Unity Catalog, Polaris y los catálogos REST de Iceberg.

OLTP maneja transacciones, OLAP maneja analítica, y los sistemas HTAP (procesamiento híbrido transaccional/analítico) (TiDB, SingleStore, AlloyDB, Unistore) intentan atender ambos sobre datos frescos, útiles para analítica operativa a escala limitada.

Considerando la unicidad entre sistemas, el orden para la localidad de los índices y la exposición: los enteros autoincrementales son compactos pero necesitan coordinación central; los UUIDv4 son únicos en el mundo pero aleatorios; los UUIDv7 y los ULID son únicos y ordenados en el tiempo; las claves naturales deben quedar como atributos.

Una estructura que acelera las búsquedas a costa de las escrituras y el almacenamiento: B-tree (rangos, igualdad), hash (igualdad), GIN/invertidos (texto completo, arreglos, JSON), BRIN (tablas enormes ordenadas naturalmente), bitmap (baja cardinalidad en warehouses) e índices vectoriales (HNSW, IVF) para búsqueda por similitud.

Para mediciones con marca de tiempo y alta ingesta (métricas, IoT, monitoreo) con consultas por rangos de tiempo, reducción de resolución y políticas de retención; comprimen las series de tiempo de forma eficiente y ofrecen funciones especializadas.

Para búsqueda de texto completo con relevancia, coincidencias aproximadas, facetas y analítica de logs, normalmente como índice secundario alimentado desde el sistema de registro y no como base de datos principal.

En un sistema distribuido que sufre una partición de red, hay que elegir entre consistencia (toda lectura ve la última escritura) y disponibilidad (toda solicitud recibe respuesta). Sin particiones ambas son posibles; CAP trata del comportamiento durante los fallos.

Una extensión de CAP: si hay una Partición, elige Disponibilidad o Consistencia; si no (Else, operación normal), elige Latencia o Consistencia. Explica por qué muchos sistemas sacrifican consistencia por menor latencia incluso sin fallos.

Atomicidad (todo o nada), Consistencia (se respetan las restricciones), Aislamiento (las transacciones concurrentes no interfieren) y Durabilidad (los datos confirmados sobreviven a los fallos): las garantías de las transacciones relacionales.

Basically Available, Soft state, Eventual consistency: un modelo preferido por algunos sistemas NoSQL distribuidos que priorizan la disponibilidad y la tolerancia a particiones, con datos que convergen a la consistencia con el tiempo.

Si no hay nuevas actualizaciones, todas las réplicas terminan devolviendo el mismo valor; mientras tanto, las lecturas pueden devolver datos desactualizados. Las aplicaciones deben tolerar diferencias temporales.

Leer tus propias escrituras (un cliente ve lo que escribió), lecturas monótonas (no se retrocede en el tiempo), consistencia causal (las operaciones relacionadas causalmente se ven en orden), obsolescencia acotada (lecturas con a lo sumo X segundos de retraso) y consistencia de sesión.

Repartir los datos entre nodos según una clave (hash o rango) para que el almacenamiento y la carga escalen horizontalmente. Una buena clave reparte los datos de forma pareja y mantiene juntos los datos relacionados; las malas claves causan hotspots.

Mantener copias de los datos en varios nodos para la disponibilidad y para escalar lecturas. La replicación síncrona espera a las réplicas (consistencia más fuerte, más latencia); la asíncrona responde antes de que confirmen (menos latencia, posible pérdida de datos en un failover). Las topologías incluyen líder-seguidor, multilíder y sin líder.

Un protocolo (Raft, Paxos, ZAB) que permite a nodos distribuidos ponerse de acuerdo sobre un valor o un líder pese a los fallos, usado para metadatos, coordinación y logs replicados en sistemas como Kafka (KRaft), etcd y ZooKeeper.

Una operación es idempotente si realizarla varias veces tiene el mismo efecto que una vez. Los reintentos son inevitables en los sistemas distribuidos, así que las escrituras idempotentes (upserts, sobrescritura por partición, claves de deduplicación) evitan duplicados y corrupción.

At-most-once (puede perder mensajes), at-least-once (puede duplicarlos) y exactly-once (el efecto de cada mensaje ocurre una vez). Exactly-once suele significar entrega at-least-once más procesamiento idempotente o transaccional.

Un mecanismo por el cual un consumidor más lento indica a los productores que bajen el ritmo (o los buffers absorben las ráfagas), evitando la sobrecarga y el agotamiento de memoria en los pipelines de streaming.

Escalar verticalmente añade recursos a una máquina (más simple, limitado); escalar horizontalmente añade máquinas (casi ilimitado, necesita particionado y coordinación). Las plataformas de datos dependen del escalado horizontal para el almacenamiento y el cómputo.

Una partición o nodo que recibe una carga desproporcionada por una clave sesgada (un usuario muy popular, una marca de tiempo que siempre crece). Se evita con mejores claves, salting, hashing o dividiendo las claves calientes.

Un protocolo en el que un coordinador pide a todos los participantes que se preparen y luego que confirmen, garantizando la atomicidad entre sistemas. Se evita a escala porque se bloquea ante fallos, añade latencia y acopla la disponibilidad de todos los participantes; se prefieren las sagas y el outbox.

El número mínimo de nodos que deben confirmar una lectura o escritura para que tenga éxito (por ejemplo una mayoría). Si el quórum de lectura más el de escritura supera el número de réplicas, las lecturas ven la última escritura.

Los relojes de distintas máquinas no coinciden, así que no se puede confiar en las marcas de tiempo de distintos sistemas para un orden exacto. Para ordenar los cambios usa relojes lógicos, números de secuencia o posiciones del log del sistema de origen.

La latencia es cuánto tarda una operación; el rendimiento es cuántas operaciones terminan por unidad de tiempo. Los sistemas batch optimizan el rendimiento; los interactivos y de streaming se preocupan por la latencia; mejorar uno puede empeorar el otro.

Modelos normalizados (3FN) para la integración y el OLTP, dimensionales (Kimball) para la analítica, Data Vault para capas de integración auditables, tablas anchas desnormalizadas (one big table) para consumos concretos, y modelos anchor o ensemble en casos de nicho.

Un nivel de normalización en el que cada atributo no clave depende solo de la clave, evitando redundancia y anomalías de actualización. Sirve para los sistemas transaccionales y las capas de integración al estilo Inmon.

La Corporate Information Factory de Bill Inmon: un data warehouse empresarial en 3FN como versión única, integrada y orientada a temas de la verdad, que alimenta data marts dependientes para los departamentos. De arriba hacia abajo, primero la integración.

La bus architecture de Ralph Kimball: data marts dimensionales por proceso de negocio, integrados mediante dimensiones conformadas y la bus matrix, construidos de forma incremental. De abajo hacia arriba, primero el valor de negocio.

Una metodología para la capa de integración con hubs (claves de negocio únicas), links (relaciones) y satellites (atributos descriptivos en el tiempo), más claves hash para la carga en paralelo, historial de solo inserción y estándares para el business vault y los information marts. Pensada para la agilidad y la auditabilidad con muchas fuentes cambiantes.

Los hubs guardan las claves de negocio (número de cliente) con metadatos de carga; los links guardan las relaciones entre hubs (cliente-pedido); los satellites guardan los atributos y su historial para un hub o un link, separados por fuente o por velocidad de cambio.

En empresas con muchas fuentes que cambian a menudo, requisitos fuertes de auditoría (finanzas, seguros, sectores regulados) y la necesidad de cargar en paralelo y conservar todo el historial. Es excesivo para plataformas pequeñas o de una sola fuente.

Una sola tabla ancha y desnormalizada por caso de uso con todo lo necesario, rápida en los motores columnares y fácil para las herramientas, a costa de lógica y almacenamiento duplicados entre tablas. Suele construirse encima de modelos dimensionales.

Una organización moderna común: aterrizaje en bruto, una capa de integración (normalizada o Data Vault) que historiza e integra las fuentes, y esquemas en estrella de Kimball u OBT para el consumo, a menudo correspondientes a bronze, silver y gold.

El esquema al escribir valida y estructura los datos al cargarlos (warehouses), detectando los errores pronto. El esquema al leer guarda los datos en bruto y aplica la estructura al consultar (lakes), lo que es flexible pero traslada los problemas a los consumidores. Los lakehouses combinan ambos según la capa.

Una representación compartida e independiente de las aplicaciones de las entidades y eventos principales, usada para integrar sistemas, de modo que cada sistema se mapea al modelo canónico y no a todos los demás sistemas.

Una técnica muy normalizada (6FN) en la que cada atributo se guarda en su propia tabla con historial, lo que permite evolucionar el esquema sin destruir nada; es rara en la práctica pero influyó en ideas de Data Vault.

Aterrizándolos en bruto (JSON, VARIANT, columnas struct), extrayendo en las capas siguientes los campos estables y muy usados a columnas tipadas, dejando el resto anidado para conservar la flexibilidad y documentando los esquemas con contratos o un registro.

Definiciones compartidas de claves y entidades (cliente, producto, fecha) que usan los productos de datos de todos los dominios, para que el análisis entre dominios funcione; en un mesh suelen publicarse como productos de datos de referencia.

A partir de las preguntas de los consumidores y de los eventos atómicos del origen: elige el grano más atómico que sea estable y útil, documéntalo de forma explícita y ofrece los agregados como productos aparte.

Un repositorio centralizado en almacenamiento de objetos que guarda datos en bruto y procesados de cualquier formato y a cualquier escala, con almacenamiento barato y esquema al leer, usado para analítica, ciencia de datos y como fuente de los warehouses.

Un data lake que se volvió inutilizable: datos sin documentar, sin gobierno, duplicados, de calidad y propiedad desconocidas. Los catálogos, los responsables, los controles de calidad, las zonas y las políticas de ciclo de vida lo evitan.

Aterrizaje/raw (tal como llega), limpia/estandarizada (validada, tipada, deduplicada), curada/de consumo (datasets listos para el negocio), además de zonas sandbox para explorar y zonas de archivo para los datos fríos.

Una arquitectura que lleva las funciones del warehouse (transacciones ACID, control de esquema, gobierno, rendimiento) al almacenamiento del lake mediante formatos de tabla abiertos y catálogos, para que una sola copia de los datos sirva a BI, ML e ingeniería de datos con varios motores.

Un patrón de capas del lakehouse: bronze guarda los datos en bruto tal como se ingieren (solo inserción, con metadatos), silver guarda los datos limpios, homogeneizados, deduplicados e historizados, y gold guarda agregados de negocio y modelos dimensionales listos para consumir.

Responsabilidades claras por capa, la posibilidad de reprocesar desde los datos en bruto, una mejora incremental de la calidad, una depuración más fácil (se inspecciona cada capa) y un lugar natural para los controles de calidad entre capas.

Tratar las capas como copias obligatorias aunque no aporten nada, meter lógica de negocio en bronze, dejar que los consumidores lean bronze o silver directamente, contratos poco claros entre capas, y copiar datos entre capas sin procesamiento incremental (costo).

Son complementarios: medallion describe capas de refinamiento; Data Vault puede ser la técnica de modelado en silver; los esquemas en estrella de Kimball son típicos en gold. Medallion es una convención de capas, no un método de modelado.

Un warehouse (Snowflake, BigQuery, Redshift) es lo más sencillo para BI centrado en SQL con datos estructurados. Un lakehouse encaja cuando necesitas formatos abiertos, varios motores, grandes volúmenes semiestructurados o no estructurados, ML y streaming sobre los mismos datos, o evitar copias. Muchas organizaciones combinan ambos, y la frontera se está difuminando.

Es el plano de control: registro de tablas, esquemas, permisos, linaje, etiquetas y descubrimiento entre motores (Unity Catalog, Glue con Lake Formation, Polaris), que convierte archivos en tablas gobernadas.

La zona de aterrizaje guarda los archivos exactamente como se entregaron (CSV, JSON, exportaciones) para la trazabilidad; bronze es la primera representación en tabla de esos datos con cambios mínimos más los metadatos de ingesta, consultable y gobernada.

Tantas como aporten un valor claro: típicamente raw/bronze, limpia/silver y de consumo/gold, a veces una zona de aterrizaje antes y una capa de servicio o semántica después. Las capas extra sin contratos propios solo añaden costo.

Reescribir muchos archivos pequeños en menos archivos más grandes (y fusionar los archivos de borrado), lo que mantiene rápidas las lecturas y pequeños los metadatos. El streaming y los upserts frecuentes la hacen necesaria; se puede programar o ser automática.

Permitiendo automáticamente los cambios aditivos (columnas nuevas que admiten nulos) en bronze, revisando y aplicando a propósito los cambios en silver y gold con las funciones del formato de tabla (añadir, renombrar, ampliar) y usando contratos y alertas para los cambios que rompen.

Para reproducir reportes a una fecha, auditar, depurar qué cambió, recuperarse de escrituras malas y comparar versiones, siempre que las políticas de retención conserven suficiente historial.

El batch procesa conjuntos de datos acotados a intervalos (cada hora, cada día) con mucho rendimiento y lógica más simple; el streaming maneja flujos de eventos sin fin de forma continua con baja latencia, y requiere gestión de estado, manejo del tiempo del evento y tolerancia a fallos.

La arquitectura de Nathan Marz con una capa batch (recalcula vistas exactas a partir de todo el historial), una capa de velocidad (procesa los datos recientes en tiempo real) y una capa de servicio que combina ambas. Da exactitud y baja latencia, pero duplica la lógica en dos caminos de código.

La simplificación de Jay Kreps: un único camino de procesamiento en streaming donde todo es un flujo; el reprocesamiento se hace reproduciendo el log (Kafka) con una nueva versión del job. Elimina la lógica duplicada, pero necesita un log durable y reproducible y un streaming robusto.

La Lambda pura es rara porque mantener dos bases de código es costoso. Las plataformas modernas usan motores unificados (Spark Structured Streaming, Flink, Beam) y formatos de tabla que admiten batch y streaming sobre las mismas tablas, más cerca de Kappa, con backfills batch cuando hace falta.

El tiempo del evento es cuándo ocurrió algo en el origen; el de procesamiento es cuándo lo procesa el sistema. La analítica correcta suele necesitar el tiempo del evento, porque los eventos llegan tarde y desordenados.

Agrupaciones de eventos en el tiempo para agregarlos: tumbling (fijas, sin solapamiento), sliding o hopping (solapadas) y ventanas de sesión (los periodos de inactividad definen las sesiones).

Un umbral de tiempo del evento hasta el cual el sistema asume que ya vio todos los eventos, lo que permite cerrar ventanas y limpiar el estado; los eventos más tardíos que la watermark se descartan o se tratan aparte.

Un log de eventos distribuido, durable y reproducible: desacopla productores de consumidores, absorbe ráfagas, permite que varios consumidores lean los mismos datos a su ritmo y sirve de columna vertebral para el streaming, el CDC y los sistemas orientados a eventos.

Un topic es un flujo de registros con nombre; se divide en particiones (logs ordenados y replicados) para el paralelismo; un grupo de consumidores reparte las particiones entre sus miembros, de modo que cada partición la lee un solo consumidor del grupo, lo que da un consumo escalable con orden por partición.

Solo dentro de una partición. Los registros con la misma clave van a la misma partición, así que se conserva el orden por clave; el orden global entre particiones no está garantizado.

Un servicio que guarda esquemas versionados (Avro, Protobuf, JSON Schema) de los topics y aplica reglas de compatibilidad, para que los productores no publiquen cambios que rompan y los consumidores deserialicen de forma confiable.

Apache Flink (baja latencia, con estado, por tiempo del evento), Spark Structured Streaming (micro-lotes y continuo, integrado con Spark), Kafka Streams y ksqlDB (librería y SQL sobre Kafka), Apache Beam (modelo portable, corre en Dataflow) y servicios administrados (Kinesis Data Analytics/Managed Flink, Confluent, Databricks).

Cuando las decisiones o acciones pierden valor en segundos o minutos: detección de fraude, alertas operativas, personalización, monitoreo de IoT, precios dinámicos. Muchos dashboards no lo necesitan; el batch o los micro-lotes son más baratos y simples.

Sistemas hechos para ingerir flujos y servir consultas analíticas de baja latencia sobre datos frescos (Apache Druid, Apache Pinot, ClickHouse, Materialize, RisingWave), usados para analítica de cara al usuario y dashboards operativos.

Procesar un flujo como una secuencia de lotes pequeños (de segundos a minutos), como hace por defecto Spark Structured Streaming. Simplifica la tolerancia a fallos y reutiliza la lógica batch, con algo más de latencia que el procesamiento evento por evento.

Un procesamiento que conserva información entre eventos (conteos por ventana, estado de sesión, joins entre flujos, deduplicación), que requiere almacenes de estado tolerantes a fallos y checkpoints; Flink y Spark administran el estado con snapshots.

Difundiendo (broadcast) los datos de referencia que cambian poco a los procesadores de streaming y refrescándolos periódicamente, uniendo con un flujo de cambios (tablas temporales o versionadas), o consultando un almacén rápido (Redis, DynamoDB) con caché.

Productores idempotentes más transacciones que escriben de forma atómica los registros de salida y confirman los offsets del consumidor, para que los efectos de un ciclo leer-procesar-escribir ocurran una sola vez aun con reintentos, dentro de pipelines de Kafka a Kafka.

Reproduciendo desde el log (retención o almacenamiento por niveles de Kafka) con una nueva versión del job que escribe en tablas nuevas, validando y luego cambiando a los consumidores; o haciendo backfill desde las tablas del lakehouse con un job batch que use la misma lógica.

Descargar los segmentos de log más viejos en almacenamiento de objetos, para que los topics conserven historiales largos de forma barata, lo que permite reproducciones y reprocesamientos al estilo Kappa sin discos enormes en los brokers.

Cada servicio es dueño de sus datos y de su base (una base por servicio) y se comunica mediante APIs y eventos en lugar de tablas compartidas. Esto mejora la autonomía y el escalado, pero dispersa los datos y exige patrones de integración para la analítica y las consultas entre servicios.

Cada microservicio tiene una base privada a la que solo él accede; los demás servicios usan su API o sus eventos. Evita el acoplamiento fuerte a través de esquemas compartidos.

Los servicios quedan acoplados por el esquema: el cambio de un equipo rompe a otros, los despliegues deben coordinarse y la propiedad es confusa, con lo que se pierde el principal beneficio de los microservicios.

Capturando los datos de cada servicio (CDC de su base o sus eventos de dominio) en un lake o un warehouse, modelándolos de forma central o por dominio, y sirviendo la analítica desde allí, en lugar de consultar directamente las bases de los servicios.

Sistemas que se comunican produciendo eventos y reaccionando a ellos (hechos sobre algo que ocurrió: OrderPlaced, PaymentFailed) a través de un broker, en lugar de llamadas síncronas, lo que da bajo acoplamiento, escalabilidad y registros de auditoría naturales.

Un comando pide a alguien que haga algo (ShipOrder) y puede rechazarse; un evento indica que algo ocurrió (OrderShipped) y es inmutable; mensaje es el envoltorio genérico que transporta cualquiera de los dos.

Guardar el estado de una entidad como la secuencia de eventos que lo modificaron, en lugar del estado actual; el estado actual se reconstruye reproduciendo los eventos. Da un log de auditoría completo y viaje en el tiempo, pero complica las consultas y la evolución del esquema.

Command Query Responsibility Segregation: separar el modelo de escritura (comandos, validación) de los modelos de lectura (vistas optimizadas para consultas), a menudo actualizados de forma asíncrona a partir de eventos. Escala lecturas y escrituras de forma independiente y encaja con event sourcing.

Un servicio escribe su cambio de negocio y un registro de evento en una tabla outbox en la misma transacción de base de datos; un proceso aparte (a menudo CDC) publica los registros del outbox en el broker. Evita el problema de la doble escritura de actualizar la base y publicar un evento por separado.

Cuando un servicio escribe en su base y publica un evento como dos operaciones separadas, una puede tener éxito y la otra fallar, dejando los sistemas incoherentes. El outbox o la publicación basada en CDC lo resuelven.

Una forma de ejecutar transacciones de negocio que abarcan varios servicios como una secuencia de transacciones locales con acciones compensatorias ante fallos, coordinadas por coreografía (eventos) u orquestación (un coordinador), en lugar de commits distribuidos en dos fases.

El CDC lee el log de la base de cada servicio y publica los cambios como eventos sin modificar los servicios, alimentando la analítica y otros servicios; es más simple que añadir eventos a código heredado, pero expone los esquemas internos salvo que se use un outbox o un contrato.

Los eventos de dominio son internos al modelo de un servicio; los de integración son contratos publicados para otros servicios y la analítica, estables y versionados, desacoplados a propósito de los esquemas internos.

Un punto de entrada único para las solicitudes de los clientes que enruta a los servicios y se encarga de la autenticación, los límites de solicitudes y la agregación. Para los productos de datos, las APIs o capas GraphQL exponen datos curados a las aplicaciones.

Nombrados en pasado, con un esquema claro, un ID de evento, marcas de tiempo (del evento y de publicación), la clave de la entidad, una versión y suficientes datos para los consumidores (eventos gruesos) o una referencia para buscar los detalles (eventos delgados), evolucionando de forma compatible.

Los eventos delgados solo llevan identificadores y el tipo de cambio, así que los consumidores deben consultar los detalles (acoplamiento, carga sobre el productor); los gruesos (event-carried state transfer) llevan todo el estado necesario, lo que permite consumidores autónomos a costa de mensajes más grandes y de cuidar el esquema.

Con un schema registry con reglas de compatibilidad, añadiendo campos opcionales en lugar de cambiar significados, introduciendo tipos o versiones de evento nuevos para los cambios que rompen y conservando las versiones viejas hasta que migren todos los consumidores.

En la coreografía, los servicios reaccionan a los eventos de los demás sin un coordinador central (bajo acoplamiento, más difícil ver el flujo completo); en la orquestación, un coordinador les dice a los servicios qué hacer (flujo claro, dependencia central). Los pipelines de datos suelen usar orquestación (Airflow); las sagas de microservicios usan cualquiera de las dos.

El enfoque sociotécnico de Zhamak Dehghani con cuatro principios: propiedad de los datos orientada al dominio, datos como producto, una plataforma de datos de autoservicio y gobierno computacional federado. Descentraliza la propiedad de los datos hacia los dominios que los conocen.

Que los equipos de datos centrales se conviertan en cuellos de botella entre muchos dominios de origen y muchos consumidores, perdiendo el contexto del dominio y escalando mal a medida que crece la organización.

Un dataset de un dominio expuesto para su consumo, con un responsable, una interfaz (tablas, APIs, eventos), documentación, garantías de calidad y SLA, facilidad de descubrimiento, seguridad y versionado, construido sobre la plataforma compartida.

Un gobierno en el que los estándares globales (interoperabilidad, seguridad, privacidad, métricas de calidad) los acuerda una federación de representantes de los dominios y la plataforma, y la plataforma los aplica automáticamente (políticas como código), mientras los dominios deciden localmente dentro de esas reglas.

Proveer infraestructura de autoservicio (almacenamiento, cómputo, pipelines, catálogo, control de acceso, observabilidad, plantillas) para que los equipos de dominio construyan productos de datos sin ser expertos en la plataforma.

En organizaciones pequeñas, con pocos dominios, baja madurez de datos o sin capacidad en los dominios para hacerse cargo de productos de datos. Sin inversión en la plataforma y en el gobierno, el mesh se convierte en datos fragmentados e incoherentes.

Una arquitectura que usa metadatos, grafos de conocimiento, automatización y virtualización para integrar datos de fuentes distribuidas y presentar una capa de acceso unificada y gobernada, poniendo el énfasis en la tecnología (metadatos activos) más que en la organización.

El data mesh es sobre todo organizacional (quién es dueño de los datos, pensamiento de producto), con descentralización; el data fabric es sobre todo tecnológico (integración mediante metadatos y automatización), a menudo centralizado. Se pueden combinar.

Eligiendo uno o dos dominios motivados con consumidores claros, construyendo una plataforma de autoservicio mínima (plantillas, catálogo, control de acceso, calidad), definiendo unos pocos estándares globales, entregando productos de datos de punta a punta, midiendo la adopción y luego ampliando.

Mediante estándares globales: identificadores y datos de referencia compartidos, convenciones de nombres y metadatos, formatos y métodos de acceso comunes, métricas de calidad y un catálogo central para el descubrimiento.

El tiempo para entregar nuevos productos de datos, el número de productos con consumidores activos, el cumplimiento de los SLO de calidad, la reducción de las solicitudes al equipo central, la reutilización entre dominios y la satisfacción de los consumidores.

Metadatos que disparan automatizaciones en lugar de solo documentar: etiquetas que aplican enmascaramiento, linaje que lanza alertas ante cambios en el origen, estadísticas de uso que sugieren retirar datasets, métricas de calidad que bloquean la publicación.

ETL/ELT batch, captura de cambios (CDC), streaming de eventos, integración por APIs, virtualización/federación de datos, transferencia de archivos y reverse ETL para devolver datos curados a las herramientas operativas.

Cargar primero los datos en bruto en almacenamiento en la nube o en warehouses escalables y transformarlos allí con SQL (a menudo con dbt). El almacenamiento barato y el cómputo elástico lo hicieron más simple y flexible que transformar antes de cargar.

Consultar los datos donde están mediante una capa lógica (Denodo, Trino, consultas federadas) sin copiarlos. Es rápida de montar y evita duplicados, pero el rendimiento, el historial y la carga sobre las fuentes son limitaciones.

Sincronizar datos modelados del warehouse hacia sistemas operativos (CRM, marketing, herramientas de soporte) para que los equipos de negocio actúen sobre la analítica, cerrando el ciclo entre análisis y operación.

La autenticación, la paginación, los límites de solicitudes y los reintentos con espera, la extracción incremental (cursores, updated-since), la deriva del esquema, la idempotencia, guardar las respuestas en bruto para reprocesar y monitorear los cambios silenciosos de la API.

Un acuerdo explícito y versionado sobre el esquema, la semántica, la calidad y los SLA de un dataset o un evento entre el productor y los consumidores, validado en CI y en ejecución, que hace visibles los cambios que rompen antes de que rompan los pipelines.

Usando las marcas de tiempo del evento, permitiendo ventanas de retraso, diseñando upserts y escrituras idempotentes, reprocesando las particiones recientes y midiendo la completitud de los datos para que los consumidores sepan cuándo un periodo es definitivo.

CDC para bases que no puedes cambiar y de las que necesitas todos los cambios con baja latencia y poco impacto; extracciones batch para datos pequeños o que cambian poco y fuentes sin acceso al log; eventos cuando controlas la aplicación y quieres semántica de negocio.

Servicios como Fivetran, Airbyte Cloud, Lakeflow Connect o AppFlow que extraen de aplicaciones SaaS y bases de datos con conectores mantenidos y manejo del esquema. Ahorran tiempo de ingeniería en las fuentes estándar a un costo por volumen; el código propio tiene sentido para fuentes inusuales o volúmenes enormes.

Con pipelines guiados por metadatos: un componente de ingesta genérico y probado, configurado por fuente (conexión, tablas, claves, programación) desde una tabla o archivos de configuración, en lugar de un pipeline escrito a mano para cada fuente.

Un acuerdo sobre los formatos de archivo, los nombres, el calendario de entrega, las señales de completitud (manifiestos o archivos _SUCCESS), la codificación, el aviso de cambios de esquema y el manejo de errores, que evita la mayoría de los incidentes de ingesta de archivos.

El marco de roles, políticas, estándares y procesos que garantiza que los datos sean exactos, seguros, conformes, comprensibles y se usen de forma apropiada, incluidos la propiedad, la custodia (stewardship), la clasificación, el acceso, la calidad y el ciclo de vida.

Los data owners responden por un dominio de datos (decisiones sobre acceso, definiciones, metas de calidad); los data stewards manejan en el día a día las definiciones, los problemas de calidad y los metadatos, junto con los ingenieros que implementan los controles.

Recoger y administrar metadatos técnicos, de negocio y operativos (esquemas, definiciones, linaje, calidad, uso) para facilitar el descubrimiento, el análisis de impacto, el gobierno y la automatización; los "metadatos activos" los usan para disparar acciones.

El flujo de los datos desde las fuentes, a través de las transformaciones, hasta los consumidores. Se captura analizando el SQL y los jobs (dbt, Unity Catalog, eventos OpenLineage de Airflow y Spark) y se muestra a nivel de tabla y de columna para el análisis de impacto y las auditorías.

Un estándar abierto para los eventos de linaje que emiten los orquestadores y motores (Airflow, Spark, dbt, Flink), que describen los jobs, las ejecuciones y los datasets de entrada y salida, y que recogen backends como Marquez o los catálogos.

Etiquetar los datos por sensibilidad (público, interno, confidencial, restringido) y tipo (datos personales, financieros, de salud), a menudo de forma automática con escáneres, para guiar las políticas de acceso, el enmascaramiento, la retención y el cumplimiento.

Crear un registro único y confiable de las entidades centrales (cliente, producto, proveedor) entre sistemas mediante reglas de emparejamiento, fusión y supervivencia, distribuido a los sistemas operativos y analíticos.

Conjuntos de códigos y clasificaciones relativamente estáticos usados por muchos sistemas (códigos de país, monedas, códigos de actividad económica, valores de estado); administrarlos de forma central evita códigos inconsistentes.

Definiendo dimensiones de calidad y SLA por producto de datos, validando en la ingesta (esquemas, contratos), probando las transformaciones (unicidad, integridad, reglas de negocio), bloqueando la publicación ante fallos, monitoreando anomalías y frescura, poniendo en cuarentena los registros malos y asignando responsables para resolver los problemas.

Por la cobertura de responsables, las definiciones documentadas, la clasificación de los datos sensibles, las políticas de acceso como código, el linaje, los SLO de calidad, los procesos de incidentes y la frecuencia con que los consumidores encuentran datos y confían en ellos sin tener que preguntar.

Una lista curada de términos de negocio con sus definiciones acordadas (cliente activo, ingreso neto, churn), vinculados a datasets y métricas en el catálogo, que alinea a los equipos sobre el significado.

Haciendo descubribles los datasets existentes (catálogo, búsqueda), certificando los autorizados, exigiendo un responsable y una revisión para los nuevos datasets publicados, monitoreando el uso y retirando las copias.

La gestión de identidades y accesos (autenticación, autorización de mínimo privilegio), el aislamiento de red, el cifrado en reposo y en tránsito, la gestión de claves, el enmascaramiento y la tokenización, la seguridad a nivel de fila y columna, la auditoría y el monitoreo, y las prácticas de desarrollo seguro.

El control de acceso basado en roles concede permisos a roles asignados a usuarios; el basado en atributos evalúa en las políticas atributos de los usuarios, los recursos y el contexto (departamento, clasificación de los datos, ubicación), lo que escala mejor para reglas detalladas (por ejemplo, políticas por etiquetas).

La seudonimización reemplaza los identificadores por tokens o hashes que se pueden volver a vincular con información adicional (siguen siendo datos personales según el RGPD); la anonimización impide de forma irreversible la identificación (dejan de ser datos personales), algo difícil de lograr en la práctica.

Reemplazar valores sensibles (números de tarjeta, documentos de identidad) por tokens no sensibles, guardando la correspondencia en una bóveda segura, para que la mayoría de los sistemas nunca maneje los valores reales.

Exigen una base legal y limitación de la finalidad, minimización de los datos, límites de retención, seguridad, registros del tratamiento y atender los derechos de los titulares (acceso, rectificación, supresión), lo que implica saber dónde están los datos personales (linaje, catálogo) y poder borrarlos de todas las capas. En Colombia, la Ley 1581 de 2012 de habeas data plantea obligaciones similares.

Rastreando dónde están los datos de cada persona, usando formatos de tabla que admiten borrados (Delta, Iceberg), borrando en todas las capas, haciendo vacuum de los archivos viejos tras la retención, evitando copiar ampliamente los identificadores en bruto (seudonimizar pronto) y documentando el proceso y sus plazos.

Requisitos que obligan a guardar y procesar ciertos datos en jurisdicciones concretas, lo que afecta la elección de regiones, la replicación, la ubicación de los respaldos y los servicios que se pueden usar.

No confiar nunca por la ubicación en la red: todo acceso se autentica, se autoriza con el mínimo privilegio y se audita, con credenciales de corta duración, identidades de carga de trabajo y verificación continua.

Guardándolos en un gestor de secretos (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, secret scopes de Databricks), prefiriendo las identidades de carga de trabajo y las credenciales de corta duración a las claves estáticas, rotándolos automáticamente y sin subirlos nunca a Git.

Herramientas y políticas que detectan y bloquean la salida de datos sensibles fuera de los límites aprobados (correos, exportaciones, buckets públicos), a menudo buscando patrones como números de tarjeta o de documentos de identidad.

Compartiendo datasets curados y mínimos con mecanismos gobernados (Delta Sharing, shares de Snowflake, acceso prefirmado con vencimiento) en lugar de volcados de archivos, aplicando restricciones de filas y columnas, definiendo el uso por contrato y auditando el acceso.

Los SLI son indicadores medidos (frescura, completitud, tasa de éxito de los pipelines); los SLO son metas para ellos (datos listos a las 7 a. m. el 99 % de los días); los SLA son compromisos con los consumidores con consecuencias. Hacen medible la confiabilidad de los datos.

Monitorear la frescura, el volumen, el esquema, la distribución y el linaje de los datos (no solo el estado de los jobs) para detectar rápido los incidentes y encontrar su causa raíz, a menudo con detección automática de anomalías.

Suponiendo que habrá fallos: pasos idempotentes y reiniciables, reintentos con espera para los errores transitorios, checkpoints para los streams, colas dead-letter para los registros malos, alertas con runbooks y la capacidad de hacer backfill de periodos concretos.

Un lugar al que se envían, con la información del error, los mensajes o registros que no se pueden procesar (formato inválido, validación fallida), para que el pipeline continúe y los fallos se puedan revisar y reproducir después.

Recovery point objective: cuánta pérdida de datos es aceptable (tiempo entre el último estado recuperable y el fallo). Recovery time objective: cuánto puede tardar la recuperación. Determinan la frecuencia de los respaldos, la replicación y el diseño de la recuperación ante desastres.

La práctica de gestionar en colaboración los costos de los datos en la nube: visibilidad (etiquetas, costo por pipeline y equipo), optimización (dimensionamiento, auto-suspend, niveles de almacenamiento, ajuste de consultas, procesamiento incremental) y gobierno (presupuestos, alertas, rendición de cuentas).

El cómputo de las transformaciones y las consultas (sobre todo clusters siempre encendidos y recálculos completos), las consultas ineficientes sobre muchos datos, la duplicación de datos entre capas y herramientas, la salida de datos y la transferencia entre regiones, y los datos sin uso guardados para siempre.

Con procesamiento incremental, particionado y clustering para el pruning, cómputo serverless o con autoescalado y auto-suspend, almacenamiento por niveles y retención, evitando copias innecesarias, eligiendo la latencia adecuada a la necesidad de negocio y haciendo visibles los costos por equipo.

Definir las plataformas (almacenamiento, cómputo, permisos, catálogos, jobs) de forma declarativa en código (Terraform, CloudFormation, Bicep, bundles) para que los entornos sean reproducibles, revisados y auditables, y se pueda detectar la deriva.

Cualquier evento en el que los datos están mal, llegan tarde o no están disponibles para los consumidores. Se gestiona como un incidente de software: detectar, evaluar el impacto, comunicar a los consumidores, mitigar (pausar la publicación, revertir), corregir la causa raíz y escribir un postmortem sin culpables con acciones.

Prever el crecimiento del volumen de datos, de los usuarios y de las cargas para que el almacenamiento, el cómputo y la concurrencia sigan siendo suficientes y los presupuestos estén preparados, usando las tendencias del monitoreo y los planes de negocio.

Clasificando los datasets según las necesidades legales y de negocio, definiendo la retención por capa (el raw puede guardarse más tiempo para reprocesar, o menos por privacidad), implementándola con reglas de ciclo de vida, borrado de particiones y la retención del formato de tabla, y documentando las excepciones.

Datos de entrenamiento confiables y versionados, features correctas en el tiempo (point-in-time), reutilización de las features entre entrenamiento y servicio, linaje de los datos a los modelos, seguimiento de experimentos, registro de modelos y monitoreo de la deriva de los datos y de las predicciones.

Un sistema que guarda, documenta y sirve features de ML de forma coherente para el entrenamiento (offline, histórico, correcto en el tiempo) y la inferencia (online, baja latencia), evitando el desfase entre entrenamiento y servicio y la ingeniería de features duplicada.

Al construir los datos de entrenamiento, las features solo deben usar la información disponible en el momento del evento de cada etiqueta, evitando filtrar datos del futuro; los feature stores unen las features a la fecha de cada evento.

Diferencias en cómo se calculan las features para el entrenamiento y para la inferencia (distinto código, fuentes o momento), que degradan el rendimiento del modelo en producción. Las definiciones de features compartidas y los feature stores lo reducen.

Un almacén optimizado para búsquedas por similitud sobre embeddings (pgvector, OpenSearch, Pinecone, Weaviate, Databricks Vector Search), usado para búsqueda semántica, recomendaciones y generación aumentada por recuperación.

Ingerir documentos, dividirlos en fragmentos, calcular embeddings, guardarlos con metadatos en un índice vectorial, recuperar los fragmentos relevantes al consultar (a menudo combinando búsqueda por palabras clave y filtros por permisos) y pasarlos a un LLM, con pipelines que mantengan el índice fresco y gobernado.

Hay que rastrear qué datos entrenaron qué modelos, respetar los permisos en la recuperación (los usuarios no deberían ver mediante un LLM documentos a los que no podrían acceder directamente), manejar los datos personales en los prompts y los datos de entrenamiento, y evaluar las respuestas; los catálogos gobiernan cada vez más los modelos y las features junto a las tablas.

Prácticas y herramientas para desarrollar, desplegar y operar modelos de ML de forma confiable: datos y código versionados, pipelines de entrenamiento reproducibles, registro de modelos, pruebas y despliegue automatizados, monitoreo del rendimiento y la deriva, y reentrenamiento.

La deriva de datos es un cambio en la distribución de los datos de entrada (cambian las edades de los clientes); la de concepto es un cambio en la relación entre las entradas y el objetivo (cambia lo que predice el churn). Ambas requieren monitoreo y posiblemente reentrenar.

Guardándolos en almacenamiento de objetos con metadatos en un catálogo (volúmenes), rastreando el linaje de los documentos a los fragmentos y embeddings, aplicando controles de acceso y clasificación, y construyendo pipelines que actualicen los índices cuando los documentos cambian o se borran.

Fuentes ingeridas con DMS, Kinesis/MSK, AppFlow o Glue hacia S3; Glue Data Catalog y Lake Formation para el gobierno; procesamiento con Glue, EMR o Databricks; tablas Iceberg o Delta; Athena y Redshift para SQL; QuickSight para BI; SageMaker para ML; Step Functions, MWAA o EventBridge para orquestar; todo definido con CloudFormation, CDK o Terraform.

Ingesta con Data Factory o pipelines de Fabric y Event Hubs hacia ADLS Gen2/OneLake; procesamiento con Databricks o Spark de Fabric; tablas Delta; warehouses de Synapse/Fabric o Databricks SQL; Power BI; Purview para el gobierno; Entra ID para la identidad.

Ingesta con Pub/Sub, Datastream (CDC) y Dataflow hacia Cloud Storage y BigQuery; procesamiento con Dataflow, Dataproc o SQL de BigQuery (a menudo con dbt o Dataform); Dataplex para el gobierno; Looker para BI; Vertex AI para ML.

Usar varios proveedores de nube. Puede reducir la dependencia, cumplir requisitos de clientes o regulatorios, o usar los mejores servicios de cada uno, pero multiplica las habilidades, las herramientas, la red y los costos de salida. La mayoría de las organizaciones gana más con una nube principal y formatos portables.

Combinar sistemas on-premises con servicios en la nube, común durante las migraciones o para datos regulados; necesita conectividad segura (VPN, Direct Connect, ExpressRoute), identidad y gobierno coherentes, y un movimiento de datos cuidadoso.

Rehost (lift and shift), replatform (pasar a equivalentes administrados con pocos cambios), refactor (rediseñar para servicios nativos de la nube y ELT), retirar los activos sin uso y retener lo que debe quedarse. Las migraciones de datos suelen combinarlas, avanzando por olas y por dominio con validación en paralelo.

Un entorno multicuenta (o multisuscripción) preconfigurado y seguro, con identidad, red, logs, barreras de seguridad y estructura de cuentas, sobre el que se despliegan de forma coherente las plataformas de datos.

Separando los entornos (dev, staging, prod) y a menudo los dominios en cuentas o proyectos distintos para aislar el impacto de los fallos, ver los costos y aplicar el mínimo privilegio, con los servicios compartidos (catálogo, red, logs) administrados de forma central.

Ingiero la base de pedidos con CDC, los eventos web con un stream (Kafka o Kinesis) y las herramientas SaaS (CRM, marketing) con conectores hacia almacenamiento de objetos; organizo capas medallion con tablas Iceberg o Delta en un catálogo; transformo con dbt o Spark hacia dimensiones conformadas y hechos; sirvo BI desde un warehouse o un motor SQL de lakehouse con una capa semántica; añado reverse ETL para los segmentos de marketing; orquesto con Airflow o jobs nativos; aplico gobierno, pruebas de calidad, observabilidad y etiquetas de costo; y lo defino todo como código con CI/CD.

Identificar los procesos de negocio y las métricas centrales, crear dimensiones conformadas y hechos certificados con equipos responsables, implementar una capa semántica para las definiciones de las métricas, establecer la propiedad y la custodia de los datos, retirar poco a poco la lógica duplicada y comunicar un catálogo de datasets certificados.

Transmito las transacciones desde el origen (CDC o eventos) hacia un broker, calculo las features con un procesador de streaming usando un feature store online (definiciones compartidas con el entrenamiento batch), llamo al modelo para puntuar en milisegundos, escribo las decisiones de vuelta como eventos y llevo todo al lakehouse para el análisis y el reentrenamiento.

Dejar de leer directamente las tablas internas: acordar contratos de datos, hacer que los servicios publiquen eventos de integración (mediante un outbox) o vistas de CDC curadas, validar los contratos en el CI de los servicios, versionar los cambios que rompen y dar a los dominios la propiedad de sus productos de datos publicados.

Inventario los datasets con su uso y sus responsables, defino zonas y estándares de nombres, registro los datos valiosos en un catálogo con descripciones y etiquetas, añado controles de calidad, convierto los datasets clave a formatos de tabla, archivo o borro los datos sin uso con políticas de ciclo de vida y hago obligatoria la propiedad de los datasets nuevos.

Es el plan urbanístico de los datos de la empresa: de dónde vienen, dónde se guardan, cómo circulan y se limpian, quién es responsable de ellos y las reglas que los mantienen seguros y confiables, para que los equipos construyan encima sin caos.

Mantenerla simple y administrada: un servicio de warehouse o lakehouse en la nube, conectores administrados para las fuentes SaaS, CDC o réplicas para la base del producto, dbt para las transformaciones con pruebas, un solo orquestador, una herramienta de BI con capa semántica, un gobierno básico y alertas de costo, todo como código. Añadir streaming, mesh o componentes propios solo cuando aparezca la necesidad.

Empiezo por las preguntas que necesita responder la dirección, mapeo las entidades y métricas clave, replico los datos necesarios en la plataforma principal con CDC o exportaciones (o los comparto con formatos abiertos), construyo dimensiones conformadas con emparejamiento de datos maestros, y planifico a más largo plazo la consolidación de las plataformas según costo y capacidades.

Pregunto qué decisiones cambian con datos más frescos y qué latencia necesita cada una, estimo los costos y la complejidad de cada nivel (segundos, minutos, horas), entrego tiempo real donde el valor de negocio lo justifica y mantengo el resto en batch o micro-lotes, que son más baratos.