🛠️ El rol del Data Engineer | Data Engineering Notes #1
Una historia de invención (y reinvención)
Esta semana empezamos el bootcamp de Data Egineering. Y en esta primera cohorte bootcamp estaré ayudando a 7 ingenieros a aprender los fundamentos de Data Engineering y apoyándolos a afianzar los fundamentos técnicos de un buen data engineer.
Y en vez de lanzarnos directo a escribir código o construir pipelines, decidimos empezamos con la historia de data engineering—porque no puedes entender data engineering profundamente sin entender su historia.
El rol del data engineer es un rol relativamente nuevo que fue acuñado por allá en 2010 - 2011, cuando empresas como Facebook y LinkedIn empezaron a buscar los primeros data engineers.
Sin embargo, este rol ha existido prácticamente desde 1990! Simplemente con diferentes nombres a lo largo de la historia.
Los pre-cursores de los data engineers fueron los ETL developers y data warehouse engineers, y, luego, los big data engineers.
La evolución del rol está estrechamente relacionado con su historia, décadas de evolución tecnológica y soluciones que con el tiempo se volvieron obsoletas…. Cada innovación siempre abrió paso a la siguiente…
1. ¿Qué hace realmente un Data Engineer?
Pueso de manera simple, un Data Engineer construye sistemas para disponibilizar datos.
Es como la infraestructura que lleva el agua potable hasta tu casa. Si lo hace bien, nadie se da cuenta. Pero si algo falla… todo se desmorona.
El Data Engineer no solo mueve datos de un punto A a un punto B, si no que construye sistemas enteros…
2. Un rol que aún se está escribiendo
Lo más importante para entender el rol del Data Engineer es aceptar que no está completamente definido.
Es un rol en construcción.
En una empresa, el Data Engineer puede ser quien crea pipelines y mueve datos de A a B.
En otra, diseña toda la arquitectura de datos. O quizá en otra más, lidera la estrategia de plataforma y colabora con analistas, ML engineers y devs.
Y en muchas… hace todo eso al mismo tiempo.
Por eso, ser buen Data Engineer va mucho más allá de saber usar ciertas herramientas.
Requiere aprender a reconocer matices, navegar ambigüedades, y entender lo que el contexto necesita del rol.
El rol no vive en abstracto, se define en relación con el equipo, el producto y los vacíos que hay alrededor.
Si como Data Engineer te toca desplegar infraestructura, y “miras a los lados” y no hay nadie más que lo haga…
Entonces probablemente te toca a ti.
Ser Data Engineer también es aprender a leer entre líneas:
¿Qué necesita este equipo? ¿Dónde hay cuellos de botella? ¿Qué decisiones de datos aún no se han tomado?
Y asumir que, muchas veces, la descripción del rol no está escrita en ninguna parte. Te toca escribirla a ti…
3. La historia del Data Engineering
Esta semana recorrimos la evolución del rol desde sus raíces.
Aquí un resumen:
1970s | Bases de Datos Relacionales
En 1970 nacen las bases de datos relacionales. Con eso, por primera vez, se pudo digitalizar información estructurada de manera masiva.
Imaginen un supermercado en esa época.
Antes de las bases de datos, toda la información se guardaba en papel: inventarios escritos a mano, cuadernos con precios, hojas sueltas con horarios de empleados.
Cada vez que alguien quería responder una pregunta como:
“¿Cuáles fueron los productos más vendidos el mes pasado?”
…tenía que revisar recibos, contar a mano, sumar en calculadora, y cruzar datos de diferentes cuadernos. Semanas de trabajo.
Con las bases de datos, ese tipo de preguntas pasaron de ser tediosas y demandantes en tiempo… a ser consultas SQL.
Una pregunta que antes tardaba semanas, ahora podía resolverse en minutos.
Este fue el primer gran hito en la historia del Data Engineering: la digitalización de los datos.
Y con eso… empezó todo.
1990s | Data Warehouses y ETLs
Para los 90s, muchas empresas ya usaban bases de datos relacionales. Pero apareció un nuevo problema: los silos de datos.
Cada departamento tenía su propio sistema.
El equipo de ventas usaba una herramienta, finanzas otra, recursos humanos otra.
Los datos estaban por todas partes. No se hablaban entre sí y cruzar diferentes de datos era difícil…
Imagina intentar cruzar 3 archivos que están en 3 computadores diferentes. Si no los llevas a un lugar centralizado (o utilizas herramientas “sofisticadas”) es una tarea difícil.
Es por ello que la solución a los silos de datos fue centralizar todo en un solo lugar. Así es como nacen los Enterprise Data Warehouses (EDWs).
Con estos, también se crean procesos ETLs (Extract, Transform, Load) para mover los datos desde sus fuentes hacia un lugar común: el EDW.
Así es como nace también una nueva figura: el ETL Developer —el precursor del Data Engineer moderno.
Herramientas como Informatica, scripts en COBOL o Perl permitían crear estos procesos de extracción y carga.
Los EDW permitieron responder preguntas que antes tomaban semanas en cuestión de segundos o minutos. Por ejemplo, si querías saber cuánto se vendió en todas las tiendas del país durante un trimestre, ya no tenías que combinar reportes manualmente. Solo consultabas el DW.
Fue un cambio enorme. Pero también trajo nuevas limitaciones...
2000 - 2013 | Web 2.0 y Big Data
Con la llegada de la Web 2.0 (y empresas como Google, Amazon, Facebook…), la cantidad y variedad de datos se disparó.
Ya no solo se generaban datos tabulares. Ahora también logs, imágenes, videos, datos de sensores, geolocalización, y mucho más.
Los Data Warehouses tradicionales no estaban diseñados para almacenar ni procesar este tipo de datos a gran escala. Eran costosos, requerían hardware especializado, y estaban enfocados solo en datos estructurados.
Ahí es donde entra Hadoop…
Hadoop resolvió dos grandes desafíos:
Cómo almacenar grandes volúmenes de datos no estructurados de forma económica.
Cómo procesarlos de manera distribuida y tolerante a fallos.
Lo hizo con dos componentes clave:
HDFS (Hadoop Distributed File System): un sistema de archivos distribuido que almacenaba los datos en nodos “baratos,” con replicación automática para evitar pérdida de información.
MapReduce: un modelo de programación que permite procesar grandes volúmenes de datos en paralelo, directamente sobre esos archivos distribuidos.
Este nuevo enfoque dio origen a una arquitectura emergente: el Data Lake.
Un Data Lake es un repositorio donde puedes almacenar todo tipo de datos en su forma cruda, sin necesidad de definir un esquema al ingreso (schema-on-read).
A diferencia del Data Warehouse, que exige limpieza y estructura antes de cargar la data (schema-on-write), el Data Lake recibe todo tal como viene: CSVs, JSONs, logs, imágenes, audio, etc.
Esto era posible gracias al uso de sistemas distribuidos como HDFS, y luego Amazon S3, que ofrecían almacenamiento barato y escalable.
El concepto clave: almacena primero, estructura después. Por primera vez, las empresas podían capturar absolutamente todos sus datos aunque no supieran todavía cómo la iban a usar.
Era una arquitectura más compleja, sí. Pero abrió las puertas a una nueva forma de trabajar con datos a escala.
Y marcó un cambio de paradigma: de optimizar para el reporte… a optimizar para la exploración y el descubrimiento.
2013 - 2016 | Cloud DWs y Modern Data Stack
El siguiente gran salto vino con la nube.
Antes, implementar un Data Warehouse era costoso y complejo.
Había que comprar servidores, habilitar espacios físicos (racks, refrigeración, energía), y contar con equipos de infraestructura especializados para mantener todo funcionando.
Era una inversión millonaria. Y no todas las empresas podían permitírselo.
Con la llegada de Redshift, BigQuery y luego Snowflake, ese modelo cambió por completo.
Los Cloud Data Warehouses ofrecían tres ventajas clave:
Mayor accesibilidad: gracias al modelo pay-as-you-go (paga solo por lo que usas).
Escalabilidad bajo demanda: sin necesidad de predecir la capacidad de antemano.
Experiencia fully managed: la infraestructura desaparece del radar del equipo de datos.
Esto permitió que muchas startups y empresas medianas accedieran a capacidades analíticas avanzadas sin invertir millones en hardware o administración.
Al mismo tiempo, aparecieron herramientas que simplificaron el trabajo del Data Engineer:
Fivetran y Stitch automatizaron la extracción y carga de datos desde cientos de fuentes.
DBT permitió transformar datos directamente dentro del warehouse, usando SQL modular, versionado y testeable.
Todo esto dio origen al llamado Modern Data Stack: una arquitectura cloud-native, modular, centrada en el enfoque ELT —donde los datos se cargan primero y se transforman después directamente en el warehouse.
Para muchos, fue una revolución. Democratizó el acceso al análisis de datos. Redujo los costos operativos. Y aceleró el desarrollo de pipelines analíticos robustos y escalables.
2017 - 2020 | Open Table Formats y Lakehouses
Los Cloud Data Warehouses y el Modern Data Stack resolvieron muchos problemas, pero no todos.
Su arquitectura giraba en torno a los Cloud Data Warehouses, lo cual funcionaba bien para datos estructurados. Pero en muchos casos, esto implicaba costos elevados, rigidez en los esquemas, y una arquitectura fuertemente acoplada al warehouse como núcleo de todo.
Por otro lado, los Data Lakes prometían flexibilidad y bajo costo, especialmente para datos semiestructurados o no estructurados (como logs, JSONs, imágenes o datos de sensores). Pero al no exigir estructura al momento del ingreso (schema-on-read), muchos se convirtieron rápidamente en lo que hoy se conoce como data swamps.
¿Qué es un Data Swamp?
Es un Data Lake que ha perdido estructura, gobernabilidad y usabilidad.
En lugar de ser un repositorio útil, se vuelve un archivo caótico donde los datos están… pero no se pueden usar con confianza.
Esto sucede cuando:
Se cargan datos sin estandarización ni metadatos.
No hay control de versiones ni trazabilidad sobre transformaciones.
Faltan políticas de calidad, acceso o seguridad.
Y nadie sabe bien qué hay, cómo encontrarlo o si es confiable.
Paradójicamente, muchos Data Swamps contienen información valiosa. Pero es información enterrada bajo capas de desorden, duplicación y ambigüedad.
Frente a ese problema surgió una nueva propuesta: los Data Lakehouses.
Los Lakehouses combinan lo mejor de los Data Warehouses y los Data Lakes.
Ofrecen:
La escalabilidad y flexibilidad de un Data Lake (almacenamiento barato, soporte de múltiples formatos).
Con garantías operacionales: control de versiones, transacciones ACID, schema enforcement, time travel, y gobernabilidad.
Este salto fue posible gracias al surgimiento de los Open Table Formats:
Apache Hudi (Uber, 2017)
Apache Iceberg (Netflix, 2019)
Delta Lake (Databricks, 2019)
Estos formatos permiten trabajar sobre archivos en el Data Lake como si fueran tablas, con soporte de metadatos, control de cambios, y optimizaciones de lectura/escritura.
Gracias a estas innovaciones, muchas organizaciones comenzaron a migrar de arquitecturas tradicionales hacia ecosistemas híbridos que permiten:
Almacenar datos en formatos abiertos
Mantener gobernabilidad y calidad
Ejecutar queries analíticos sin mover los datos al warehouse
El Lakehouse no es una bala de plata, pero representa un esfuerzo importante por reconciliar dos mundos: la flexibilidad de los data lakes y la estructura de los data warehouses…
4. Recapitulando la historia de Data Engineering
A lo largo de las décadas, el rol del data engineer ha evolucionado en respuesta directa a los problemas técnicos del momento.
Los hitos más relevantes en la historia de data engineering son los siguientes:
1970s | Bases de datos relacionales. Digitalizaron los datos. Por primera vez se pudieron responder preguntas de negocio de forma rápida y programática.
1990s | EDWs (Enterprise Data Warehouses). Resolvieron los silos de información. Permitieron el análisis centralizado, pero a un alto costo económico y con poca flexibilidad.
2006 | Big Data. La Web 2.0 trajo una explosión de volumen y variedad de datos. Nace el almacenamiento distribuido (Hadoop + HDFS), junto con la necesidad de arquitecturas escalables y tolerantes a fallos.
2011–2015 | Cloud Data Warehouses & Data Lakes. Redshift populariza los DW en la nube. Paralelamente, surgen los Data Lakes como una evolución más flexible… aunque con serias limitaciones en gobernabilidad y rendimiento.
2016 | Modern Data Stack. Se adopta el enfoque ELT. Herramientas como Stitch, Fivetran y DBT hacen más accesible la construcción de pipelines analíticos.
2017–2020 | Open Table Formats & Lakehouses. Nacen Apache Iceberg, Delta Lake y Hudi. Se introduce una nueva arquitectura híbrida que combina lo mejor del Data Lake y el Data Warehouse: el Data Lakehouse.
Cada etapa trajo consigo nuevas herramientas, nuevos desafíos… y una redefinición del trabajo del Data Engineer.
5. El rol del Data Engineer también ha cambiado
Así como la tecnología cambió, también lo hizo el rol del Data Engineer.
En los 90s, era común encontrar perfiles como ETL Developers o Data Warehouse Engineers, enfocados en mover datos desde sistemas operacionales hacia un data warehouse. El trabajo era más lineal, y la complejidad vivía principalmente en las transformaciones.
En la era Big Data, el foco se volvió técnico: administrar clústeres, escribir jobs en MapReduce, y garantizar que todo funcionara a escala. Nació el Big Data Engineer, experto en infraestructura distribuida y procesamiento masivo.
Luego, con el advenimiento de los Cloud Data Warehouses el data engineer se enfocó en construir pipelines de datos apalancados en infraestructura y servicios de la nube. Pasó enfocarse más en la optimización de pipelines de datos—el data warehouse, el data lake y todo su alrededor se volvió su centro de trabajo.
El Modern Data Stack marcó un nuevo giro. El modelo ELT reemplazó al ETL tradicional. Herramientas como Fivetran y Airbyte automatizaron la ingesta desde múltiples fuentes. DBT trajo buenas prácticas de software al mundo SQL: modularidad, tests, documentación y versionado.
El foco pasó de mover datos… a modelarlos, organizarlos y disponibilizarlos para el negocio.
Y finalmente, en la era de los Lakehouses, el Data Engineer entra a un nuevo capítulo.
Uno donde se exige entender arquitecturas híbridas, formatos abiertos como Iceberg o Delta, y prácticas más sofisticadas de versionamiento, trazabilidad y control de calidad. Uno donde el almacenamiento vuelve a estar en el centro, pero bajo nuevas reglas…
Próximamente
La próxima semana entraremos más a fondo en Data Warehouses y modelado dimensional. Esto apenas comienza!
Y si te interesa seguir esta serie, asegúrate de suscribirte a The LATAM Engineer.
Durante la ejecución de mi bootcamp, cada semana compartiré los temas que vayamos discutiendo. Gracias por leer!
Hasta la próxima 🙏
Antony