El glosario de datos, escrito para quien lo paga.

Decide cómo se debe construir la plataforma de datos, antes de que nadie la construya. Elige las tecnologías y los patrones de arquitectura, define cómo se almacena, procesa e integra el dato, y fija los estándares de escalabilidad, seguridad y gobierno que el equipo de ingeniería sigue después.

No es lo mismo que un ingeniero de datosUn arquitecto trabaja a nivel de plataforma y produce sobre todo decisiones y diseños. Un ingeniero trabaja a nivel de sistema y produce cosas que funcionan. En un proyecto pequeño la misma persona hace ambas cosas; en una plataforma corporativa, tratarlas como el mismo trabajo es como acabas con tres pipelines incompatibles.

Servicio de arquitectura de datos →

Construye y mantiene la infraestructura que mueve, transforma, almacena y procesa el dato. El trabajo consiste en sacar el dato de los sistemas donde vive — ERP, CRM, aplicaciones internas, bases de datos — y llevarlo al sitio donde de verdad se va a usar, de forma fiable y a tiempo.

Stack habitual: Python, SQL, Spark, Databricks, Kafka, Airflow, dbt, y una de las tres grandes nubes.

Servicio de ingeniería de datos →

Convierte el dato disponible en algo con lo que un negocio puede decidir: KPI, dashboards, informes, modelos de datos orientados a reporting. Es, de los tres perfiles, el que está más cerca del usuario de negocio — el trabajo no es construir la plataforma sino hacer que los números sean legibles y defendibles.

Stack habitual: Power BI, Tableau, Looker, SQL, Excel, Microsoft Fabric.

Servicio de Business Intelligence →

Una plataforma para procesar, trabajar y analizar grandes volúmenes de dato, construida alrededor de Apache Spark. Distintos perfiles — ingenieros, analistas, data scientists — trabajan en la misma plataforma para transformar dato, ejecutar jobs, entrenar modelos de machine learning y construir productos de datos.

No está atada a una sola nube: corre igual en Azure, AWS y Google Cloud.

No es lo mismo que SnowflakeDatabricks está más orientado a procesamiento e ingeniería; Snowflake está más orientado a almacenar y consultar dato estructurado para analítica. Compiten en el medio y muchas empresas usan los dos. Cualquiera que te diga que son intercambiables te está vendiendo uno de los dos.

Un warehouse de Databricks sobre datos de SAP →

El motor open-source de procesamiento distribuido de datos que hay debajo de buena parte del stack de datos moderno, Databricks incluido. Cuando un job es demasiado grande para una sola máquina, Spark lo reparte entre varias. PySpark es su interfaz de Python — la que la mayoría de ingenieros de datos escriben de verdad.

PySpark en un pipeline de telco en tiempo real →

Una plataforma cloud especializada en almacenar, procesar y consultar grandes cantidades de dato para analítica, reporting, BI y data science. Igual que Databricks, es independiente de cualquier nube concreta: corre sobre infraestructura de AWS, Azure o Google Cloud en vez de pertenecer a ninguna de ellas.

El data warehouse gestionado y la plataforma de analítica de Google Cloud. Almacena volúmenes de dato muy grandes y ejecuta consultas sobre ellos sin que tengas que gestionar servidores. Si una empresa ha elegido Google Cloud, BigQuery suele ser el centro de su analítica.

La plataforma de analítica y procesamiento de datos de Microsoft Azure, que combina almacenamiento, procesamiento y análisis. Durante años fue el centro del ecosistema de datos de Microsoft. Microsoft está impulsando ahora Microsoft Fabric, así que los proyectos nuevos en Azure cada vez mencionan más Fabric en su lugar.

Oír «Synapse» te dice la nube, no el productoEn la práctica, cuando sale Synapse en una conversación, lo más útil que te dice es que el proyecto vive en Microsoft Azure. Lo que el cliente necesita en realidad puede acabar siendo Fabric, Databricks o algo completamente distinto.

La plataforma de analítica unificada de Microsoft, que junta almacenamiento, ingeniería de datos, warehouse y reporting de Power BI en un solo producto. Es hacia donde Microsoft está dirigiendo los proyectos de datos nuevos en Azure, y cada vez más la respuesta por defecto dentro de organizaciones muy ligadas a Microsoft.

El data warehouse gestionado de AWS. Cumple el papel que BigQuery cumple en Google Cloud y que Synapse o Fabric cumplen en Azure: el sitio donde el dato estructurado se almacena y se consulta para analítica.

Un repositorio que guarda el dato tal como llega, con la forma que sea: ficheros, logs, exportaciones, imágenes, volcados en bruto. Barato y flexible, porque no hay que modelar nada antes de que aterrice. El coste es que un lake sin gobierno se convierte, sin que nadie se dé cuenta, en un sitio donde el dato va a que se olviden de él.

Un repositorio que guarda dato estructurado y modelado listo para analizar: ventas por cliente, facturación mensual, márgenes por región. El dato hay que limpiarlo y darle forma antes de que entre, lo que es más trabajo al principio y mucho menos trabajo cada vez que alguien hace una pregunta.

Una arquitectura que intenta mantener el almacenamiento barato y flexible de un lake y añadirle encima la estructura, la fiabilidad y el rendimiento de consulta de un warehouse. Es el patrón detrás de la mayoría de diseños de plataforma modernos, y el que Databricks usó como base de su producto.

El servicio de almacenamiento de objetos de AWS, y uno de los cimientos de la mayoría de arquitecturas de datos construidas sobre AWS: ficheros, datasets, logs, copias de seguridad, dato en bruto, salida de procesamiento. Muy a menudo es el data lake.

El servicio de almacenamiento de objetos de Google Cloud, normalmente abreviado como GCS. Hace esencialmente el mismo trabajo que Amazon S3 dentro del ecosistema de Google Cloud.

El almacenamiento de objetos de Microsoft Azure. ADLS — Azure Data Lake Storage — es la variante construida para cargas de trabajo de analítica. Juntos son el equivalente en Azure de S3 o GCS.

El conjunto de pasos automatizados que llevan el dato desde donde se produce hasta donde se consume: extraerlo, limpiarlo, transformarlo, cargarlo, y volver a hacerlo mañana sin que nadie tenga que pulsar un botón. Cuando alguien dice que un proyecto de datos falló, normalmente quiere decir que el pipeline dejó de ser fiable.

ETL — extraer, transformar, cargar — limpia el dato antes de guardarlo. ELT — extraer, cargar, transformar — lo guarda en bruto primero y lo transforma dentro de la plataforma de destino, que es lo que los warehouses cloud modernos ya son lo bastante rápidos para permitir. Dos órdenes distintos de los mismos tres pasos.

La herramienta que organiza, programa y supervisa los procesos de datos. Piensa en un director de orquesta: a las 02:00 trae este dato, cuando termine ejecuta esta transformación, después refresca esta tabla, y lanza una alerta si algún paso falla. A ese trabajo se le llama orquestación de pipelines.

Airflow orquestando PySpark en el edge →

El servicio gestionado de Airflow de Google Cloud. Composer es Airflow, operado y mantenido por Google.

No es una tecnología distintaSi un cliente dice «estamos en GCP y usamos Composer», puedes leerlo como «usan Airflow dentro de Google Cloud». Un ingeniero que domina Airflow pasa a Composer con muy poca fricción — algo que importa cuando estás decidiendo si un desajuste de stack es real o solo cosmético.

El servicio de Microsoft Azure para integrar, mover y orquestar dato entre sistemas — ERP, SQL Server, ficheros, APIs, aplicaciones externas — y entregarlo en la plataforma de datos. Normalmente abreviado como ADF, y casi universal en empresas que corren sobre Azure.

Se solapa con Airflow, pero no es lo mismoLos dos pueden coordinar pipelines, así que salen en las mismas conversaciones. ADF es más fuerte conectando y moviendo dato entre sistemas; Airflow es más fuerte orquestando lógica arbitraria. Muchas plataformas en Azure usan los dos, cada uno para lo que se le da bien.

Jobs de ADF alimentando una plataforma de calidad →

Una herramienta para transformar y organizar dato usando sobre todo SQL. El dato normalmente ya ha aterrizado en un warehouse, y dbt lo convierte de tablas en bruto en conceptos de negocio estructurados, documentados y probados: ventas por cliente, facturación mensual, margen por región.

No sustituye a tu warehousedbt no es una alternativa a Databricks, Snowflake o BigQuery — corre encima de ellos. Snowflake + dbt y BigQuery + dbt son las dos combinaciones completamente normales.

Batch significa procesar el dato en bloques programados: cada noche procesamos las ventas del día. Streaming significa procesar eventos según ocurren: queremos ver cada venta en el momento en que sucede. El streaming es más caro de construir y de operar, y de verdad hace falta mucho menos a menudo de lo que se pide.

La tecnología más conocida para transportar grandes volúmenes de información de forma continua y casi en tiempo real: transacciones, eventos de aplicación, lecturas de sensores, actividad de usuario, logs. Si Kafka está en los requisitos, el proyecto suele ser un trabajo de ingeniería de datos bastante técnico.

Kafka moviendo datos edge en tiempo real →

El servicio gestionado de Google Cloud para enviar y recibir eventos o mensajes entre sistemas, usado en arquitecturas en tiempo real y dirigidas por eventos.

Conceptualmente cercano a Kafka, no idénticoKafka es una plataforma de streaming que puedes desplegar de muchas formas, en cualquier sitio. Pub/Sub es un servicio gestionado de Google Cloud. Los conceptos se trasladan bien de uno a otro; las realidades operativas no.

La herramienta de business intelligence y visualización de datos de Microsoft, y con diferencia la capa de reporting más habitual en las empresas medianas europeas. Se conecta a las fuentes de datos, modela el dato y produce los dashboards que lee un equipo directivo.

Datos contables de SAP expuestos en Power BI →

Un indicador clave de rendimiento: un único número que se supone que te dice si algo va bien. Lo difícil casi nunca es calcularlo — es ponerse de acuerdo en su definición entre departamentos para que finanzas y ventas no saquen dos cifras de ingresos distintas del mismo dato.

La capa que define qué significa cada concepto de negocio en la herramienta de reporting: qué cuenta como ingreso, qué cuenta como cliente activo, cómo se calcula un margen. Es donde una definición vive una sola vez en vez de reinventarse en cada dashboard.

Si el dato es lo bastante completo, correcto, consistente y actual como para poder usarse. Los problemas de calidad que solo se detectan en la capa de reporting ya te han costado la decisión que se tomó con ellos, por eso las comprobaciones van más arriba, en el pipeline.

Reglas de calidad e informes escritos con IA →

Composer es Airflow, gestionado por Google. Alguien que domina Airflow es productivo en Composer casi de inmediato.

La idea de almacenamiento de objetos se traslada intacta. Lo que hay que aprender son los detalles concretos de Google Cloud alrededor, no el modelo en sí.

Muchos conceptos se solapan y se trasladan bien. Siguen siendo productos distintos, con modelos de coste distintos y comportamiento operativo distinto, y cualquiera que los presente como idénticos se está saltando la parte que importa.