El reporte de ventas dice una cosa. El ERP dice otra. El director comercial exporta a Excel para cuadrar los dos. Este ciclo —conocido y doloroso— no es un problema de herramientas: es un problema de arquitectura de datos.
Un pipeline de datos bien construido elimina ese ciclo. No es un producto que se instala; es una serie de piezas que trabajan en secuencia para mover tus datos del origen al destino de forma automatizada, confiable y auditable. Esta guía te explica cada pieza, en orden, sin tecnicismos innecesarios.
Qué hace un pipeline de datos (en lenguaje de negocio)
Un pipeline de datos toma información de distintas fuentes, la limpia y transforma según las reglas de tu negocio, y la deposita en el lugar donde tus equipos la consultan. Todo eso sin intervención manual.
El resultado es que tus dashboards se actualizan solos, tus reportes cuadran y tus decisiones se basan en la misma versión de los datos. Si hoy dependes de un analista que consolida archivos a mano cada semana, ese analista es tu pipeline actual —y el pipeline manual tiene fecha de caducidad.
Los cinco componentes del pipeline
La mayoría de los pipelines empresariales tiene la misma estructura básica, independientemente del tamaño de la empresa o el proveedor de nube.
[Fuentes] → [Ingestión] → [Almacenamiento bruto] → [Transformación] → [Destino]
ERP Conector Data lake / landing dbt / SQL DWH / Dashboard
1. Fuentes
Son todos los sistemas donde se genera información: ERP, CRM, plataforma de e-commerce, hojas de cálculo, APIs de proveedores o archivos de punto de venta. El primer trabajo del pipeline es saber exactamente dónde están los datos y en qué formato los entrega cada fuente.
Un error frecuente: asumir que todas las fuentes son accesibles. Antes de diseñar el pipeline, hay que mapear qué sistemas tienen API, cuáles solo exportan CSV y cuáles requieren un conector de base de datos. Eso define el costo y el tiempo.
2. Ingestión
La ingestión es el transporte: el mecanismo que conecta las fuentes con el almacenamiento del pipeline. Puede ser un conector nativo de una plataforma como Fivetran o Airbyte, un script Python programado, o un job de base de datos replicada.
Aquí se decide también la frecuencia: ¿los datos viajan una vez al día (batch), en tiempo casi real (micro-batch) o en el momento en que ocurren (streaming)? La respuesta no depende de la moda tecnológica, sino de qué decisiones necesitas tomar y con qué velocidad.
3. Almacenamiento en bruto
El primer destino de los datos ingeridos es un área de almacenamiento sin transformar, llamada landing zone o data lake. Los datos llegan tal como son, sin modificar. Esto sirve para dos cosas: tener un historial fidedigno ante cualquier auditoría, y poder re-transformar los datos si las reglas de negocio cambian en el futuro.
Saltarse este paso —escribir directamente al destino final— es la causa más común de pipelines que se rompen cuando algo cambia en la fuente.
4. Transformación
Aquí los datos se limpian, se enriquecen y se organizan según la lógica de tu negocio. Un "cliente" en el CRM puede llamarse distinto al "cliente" en el ERP. La transformación resuelve ese problema antes de que llegue al dashboard.
Las transformaciones se documentan como código (SQL, Python) para que cualquier analista pueda entender exactamente cómo se calculó cada métrica. Cuando alguien pregunta "¿de dónde sale este número?", la respuesta está en el repositorio, no en la memoria de quien lo construyó.
5. Destino
El destino es donde los datos transformados quedan disponibles para el consumo: un data warehouse como BigQuery, Redshift o Snowflake; un dashboard de BI como Looker o Power BI; o una API que alimenta otra aplicación.
El destino no es el último paso —es el primero que hay que diseñar. La pregunta correcta no es "¿dónde guardamos los datos?" sino "¿qué decisión necesito tomar y qué datos necesito para tomarla?". El resto del pipeline se construye hacia atrás desde ahí.
Batch vs. streaming: cuándo importa la diferencia
La mayoría de las empresas medianas no necesita datos en tiempo real. Necesitan datos correctos y actualizados una o varias veces al día. Optar por streaming antes de tiempo añade complejidad y costo sin resolver ningún problema concreto.
- Usa batch si tus decisiones se toman con reportes diarios, semanales o mensuales. Es más simple, más barato y más fácil de mantener.
- Considera streaming si operas alertas en tiempo real (fraude, inventario crítico, monitoreo de servicio) o si la latencia de horas afecta directamente el negocio.
Tres señales de que tu empresa necesita un pipeline
- Distintos equipos tienen distintas versiones del mismo número (ventas, finanzas y operaciones no cuadran).
- Hay una persona cuyo trabajo es consolidar reportes manualmente antes de cada junta directiva.
- Ningún sistema centraliza los datos de más de una fuente: cada área vive en su silo.
Si reconoces al menos dos de estas tres, el costo de seguir sin pipeline ya es mayor que el de construirlo.
Checklist antes de contratar o construir
- ¿Tienes un inventario de todas las fuentes de datos relevantes y sus formatos?
- ¿Sabes qué métricas necesitas calcular y cómo se definen en cada área?
- ¿El pipeline tendrá dueño técnico interno que lo opere o lo administrará un proveedor?
- ¿Existe documentación de las reglas de negocio actuales, o están en la cabeza de alguien?
- ¿Cuál es el SLA aceptable de latencia de datos (tiempo real, horario, diario)?
Un pipeline bien hecho tarda semanas, no meses, en tener las primeras transformaciones en producción. La velocidad depende en gran parte de qué tan clara tengas la respuesta a estas preguntas antes de empezar.
Preguntas frecuentes sobre pipelines de datos para empresas
¿Cuánto cuesta construir un pipeline de datos?
El costo depende del número de fuentes, la complejidad de las transformaciones y si se opta por plataformas gestionadas o infraestructura propia. No existen rangos universales aplicables a todos los casos: el primer paso es diagnosticar qué datos tienes y qué decisiones necesitas tomar con ellos.
¿Necesito un data warehouse antes de tener un pipeline?
El data warehouse es el destino del pipeline, así que se diseñan juntos. Lo que sí puedes tener antes es claridad sobre qué preguntas vas a responder con los datos, ya que eso define el modelo del warehouse.
¿Cuál es la diferencia entre ETL y ELT?
En ETL los datos se transforman antes de cargarse al destino; en ELT se cargan primero y se transforman dentro del warehouse. ELT es el estándar moderno porque los warehouses en nube tienen capacidad de cómputo para procesar grandes volúmenes, y permite mantener los datos brutos como respaldo histórico.
¿Mi empresa necesita un equipo de datos interno para operar el pipeline?
No necesariamente desde el inicio. Un proveedor técnico puede construir y operar el pipeline mientras el equipo interno aprende a consumirlo. Lo ideal es que con el tiempo alguien interno entienda la arquitectura para tomar decisiones de evolución, aunque no lo programe.
¿Cuánto tarda en verse el primer resultado?
Con un alcance acotado —dos o tres fuentes, un destino claro— los primeros datos en el warehouse pueden estar disponibles en semanas. El tiempo aumenta cuando las fuentes no están documentadas o las reglas de negocio son ambiguas.
