Historia contemporánea del SQL y su papel en el mundo del Big Data
SELECT * FROM sql_history WHERE date > 2000
Advertencia: El presente artículo contiene comentarios y opiniones que incluye el autor para dramatizar lo que fue trabajar durante esta etapa de la historia como ingeniero de datos. La idea es reflejar el lado humano, destacando las diversas motivaciones que uno puede tener para actuar de una determinada manera. Quizás te identifiques con algunas de estas situaciones. Si no, considérate afortunado.
Contenido
- El Protoingeniero de Datos
- El Ingeniero de Big Data
- La Relación entre Data Practitioners y Developers
- El Surgimiento de las Herramientas Low-Code/No-Code
- Pero que no todos los ingenieros de datos manejan SQL…
- Palabras Finales
El Protoingeniero de Datos
Hubo una época en la que la ingeniería de datos estaba más ligada a cargar tablas en una base de datos y a calcular indicadores de negocio. En el habla hispana, a estos héroes se les conocía como “eteleros” dado a que construían las ETLs (Extract, Transform, Load) y su campo de acción eran los proyectos de integración como los Data Warehouses, Data Marts y la Inteligencia de Negocios.
Para realizar las ETLs se utilizaban herramientas de integración licenciadas (💲📈). Algunas de las más populares:
- IBM Data Stage
- Informatica Power Center
- SQL Server Integration Services (SSIS)
Para ciertos escenarios se recurría a los llamados procedimientos almacenados para realizar cálculos dentro de la base de datos destino. Dicha base de datos debía tener un fierro suficientemente potente. Aquí se recurría a proveedores de Data Warehouse licenciados (💲📈). Algunos de los más populares:
- Teradata
- IBM Netezza
- Oracle Exadata
- Vertica
Ese era el stack de estos profesionales. Aprender estas herramientas era complicado, no porque fuese cosa dificil, sino porque la barrera de entrada era muy alta. No se tenía tanta documentación como hoy en día. Y por si fuera poco, muchos de los arrogantes consultores eran celosos con sus conocimientos. “Invítale el almuerzo para que te enseñe” — era algo que era común escuchar en los pasillos o a veces de tu propio jefe.
En ese entonces no se pensaba en hacer proyectos caseros a manera de portafolio debido a dos factores:
- Se debía estar dentro de las instalaciones de la empresa para poder echar mano a estas sofisticadas herramientas.
- En la empresa se tenían datos de la empresa — oh sorpresa — y no es buena idea andar filtrando esa información así nada más.
Algunos optaban por quedarse luego de las horas de trabajo con la excusa de avanzar más rápido con el proyecto pero en realidad lo que hacían era practicar.
El Ingeniero de Big Data
Años más tarde, Google publica un paper sobre el Google File System (GFS) el cual inspira a la creación del HDFS (Hadoop Distributed File System) por parte de la Apache Software Foundation. Esta tecnología forma parte del ecosistema Hadoop y es clave para trabajar con una técnica llamada Map Reduce, la cual fue inventada por Jeffery Dean and Sanjay Ghemawat dentro de Google. Map Reduce se usa para el procesamiento de grandes volúmenes de datos en paralelo. Con esto en manos de la comunidad open source se dio inicio a la era del Big Data. De pronto, cada empresa, grande o pequeña, podía apoyarse en Apache Hadoop para procesar su información y lograr su independencia de los proveedores de herramientas licenciadas (💲📉).
Cabe resaltar que Apache Hadoop no era perfecto y que la curva de aprendizaje era alta. Es por eso que años más tarde nace otro proyecto open source llamado Apache Hive el cual permitía consultar la data almacenada en HDFS mediante sentencias SQL. ¡Magnífico! En este punto ya tenemos cómo hacer Big Data con menos barreras de entrada.
– 😡 Me estás diciendo que mis años arrastrando y soltando cajitas en un lienzo de pronto ya no son relevantes?
– 💁♂️ Qué quieres que te diga.
Para muchos de los que no soportaban estar rogando al compañero para que le enseñe los trucos con la herramienta ETL, este era el momento de dejar ese ambiente.
Para otros que ya estaban cansados de la monotonía, tener nuevas herramientas con las que jugar era atractivo. Muchos buscaron reinventarse como ingenieros de Big Data.
Sepan que los grandes frameworks de la era Big Data se habían construido sobre Java o Scala. Pero luego vino la ola de hacer todo con Python, porque Python es super popular y no es tan molesto como los otros lenguajes. No hay ciclos de programa, compila, ejecuta y corrige. Aquí solo ejecutas y ves los resultados rapidamente. ¿Pero saben que es más fácil que Python? SQL. Más adelante cuento por qué la comparación.
Quiero detenerme en este momento de la historia. En este punto, se sentía algo elitista ser ingeniero de datos. Recibías ofertas de trabajo para machacar datos mediante SQL y las ignorabas simplemente porque no había nada desafiante en ello. No lo tomes a mal, estimado lector, depende de la personalidad de cada uno. Para algunos, permanecer en la zona de comfort está bien, pero para otros, lo desconocido es lo que les atrae. Hay quienes gustan de la simpleza y hay quienes gustan complicarse la vida.
Además, quienes reciben los aplausos son los que meten los goles, no los que pasan la pelota.
La verdad es que ser ingeniero de datos se siente así, como que eres el que pasa el balón a los demás integrantes del equipo para que ellos sean quienes se lleven los laureles y salgan en las portadas de los diarios.
Si así va a ser el trato que reciben estos profesionales, al menos hay que asignarles cosas más interesantes que hacer o darles un aumento. La idea es retenerlos para que no se vayan con la competencia.
La Relación entre Data Practitioners y Developers
Muchos consultores buscaron ir más allá y tomaron proyectos donde haya que implementar Big Data o que al menos haya que construir plataformas de datos desde cero, no necesariamente Big Data. Se sentía “cool” estar involucrado en proyectos de esta magnitud.
En el caso de la construcción de plataformas de datos, este tipo de proyectos parecía tarea de un ingeniero de software o un backend engineer debido a que requiere de profundos conocimientos de programación.
– ¿En qué consiste una plataforma de datos?
– Es una solución que consta de los siguientes módulos:
- Automatización de procesos
- Scheduling
- Monitoreo
- Logging
- Calidad de datos
- Observabilidad de datos
- Orquestación de datos
- La ETL como tal
- Entre otras características de acuerdo a la industria y/o caso de uso.
Como verán, hay muchos frentes que atacar aquí, de modo que se justifica que la parte de ETLs y las reglas de negocio pasen a ser responsabilidad de otro tipo de profesionales. Algunos candidatos:
- Analistas de datos
- Ingenieros de datos que estén especializados en consultas SQL
– ¿Entonces puede darse el caso de que en una empresa se tengan 2 tipos de ingenieros de datos?
– Sí. Incluso se daban casos donde el encargado de la plataforma lo miraba mal al que hacía las ETLs, como si este último no fuese merecedor del título de ingeniero de datos. Y esto es algo curioso ya que el que construye la plataforma de datos más parece developer que otra cosa.
El Surgimiento de las Herramientas Low-Code/No-Code
Lo malo de participar en la construcción de una plataforma de datos es que se requiere de patrocinio y comprensión por parte de los altos ejecutivos dado que este tipo de proyectos no llegan a producción en unas cuantas amanecidas, pero una vez conseguido, se ahorra bastante esfuerzo y tiempo dado que configurar nuevas fuentes de datos y transformaciones es casi trivial y ya no requiere de talentosos ingenieros de datos para hacerlo (alerta de despido inminente).
El tiempo pasó y no faltaron empresas que vieron la necesidad de desarrollar la plataforma de datos definitiva y revenderla para combatir la construcción in-house de las plataformas de datos. Durante este periodo, el movimiento Low-Code y No-Code, liderado por empresas como Fivetran, Stitch o Airbyte venía tomando fuerza, de modo que ya no era necesario invertir meses construyendo una plataforma para mover datos (alerta de “ya no existe esa necesidad”). Era el retorno del arrastra y suelta, de las herramientas ETL o EL (no todos quisieron meterse a hacer la T de transformación).
– 😁 ¿Me estás diciendo que mis años arrastrando y soltando cajitas en un lienzo nuevamente son relevantes?
– 💁♂️ Qué quieres que te diga.
Para los profesionales que miran con desconfianza los movimientos Low-Code y No-Code, les encantará saber que SQL está de vuelta. Sucede que después de Apache Hive vinieron otros motores de consultas como Presto y Apache Drill que también permiten al usuario escribir sentencias SQL para manipular la data almacenada en una variedad de fuentes de datos.
– ¿Qué hay de Apache Spark?
– Oh, sí. Luego de que le tocara a Apache Spark hacer su aparición, dando soporte primero al lenguaje Scala y luego al lenguaje Python mediante la librería pyspark, hoy por hoy Spark SQL es el favorito de las masas, no cabe duda.
Hoy en día la tendencia va por ahí dado que muchas de las plataformas más populares — y/o poderosas — tienen una interface que permite a los data practitioners, mover datos utilizando sentencias SQL. Me refiero a Databricks, Snowflake, Apache Beam, Apache Kafka, Apache Flink, dbt.
SQL es el rey. Saber SQL es fundamental, no solo para los analistas o científicos de datos, sino también para los ingenieros de datos que antes miraban con desprecio a este lenguaje.
– 😡 Me estás diciendo que mis años arrastrando y soltando cajitas en un lienzo de pronto ya no son relevantes?
– 💁♂️ Qué quieres que te diga.
Pero que no todos los ingenieros de datos manejan SQL…
Tal como lo lees. Existen dos antepasados del ingeniero de datos:
- El que trabajó en proyectos de integración como los descritos al inicio de este artículo, de modo que su nivel de SQL es superior a la de los demás.
- El que fue backend engineer (developer) en una vida pasada y evolucionó a ingeniero de datos — por la paga o porque los datos son lo que está de moda — de modo que su manejo de SQL es más que nada para sistemas transaccionales. Ponlos a trabajan en sistemas analíticos y vas a ver cómo es que les cuesta y desmotiva tener que esperar a que sus consultas resuelvan.
– ¿Y qué hay del NoSQL?
– Esa es otra historia que te la contaré en otro post.
– ¡Ay caramba!
Moraleja
- Si ves a algún consultor haciendo horas extra, poniéndose la camiseta supuestamente por la empresa, es probable que esa persona esté pensando en irse porque la paga es mejor en otro lado o porque el clima laboral es muy rancio.
- Tienes todo para hacer tu propio portafolio de proyectos de ingeniería de datos. ¿Qué te detiene?
- Despreciado por unos y amado por otros, la relación entre los ingenieros de datos con el lenguaje SQL ha sido una relación de amor/odio. Antes para llevar tu carrera hacia nuevas alturas tenías que aprender nuevas tecnologías y profundizar en los lenguajes de programación como Java, Scala o Python. Actualmente, con solo saber SQL — como parte de algún framework de procesamiento de datos — puedes llevar tu carrera bien lejos.
- Ya no se habla más de Big Data… pero sí de SQL.
- Hubo una época en la que la ingeniería de datos estaba más ligada a cargar tablas en una base de datos y a calcular indicadores de negocio. Seguimos en esa época, lo que han cambiado las herramientas.
¡Gracias por leer! ¿Qué tal otro artículo?
¿Quieres más?
Si presionas 50 veces el botón de 👏 algo maravilloso sucederá.
- Versión del post en inglés aquí.
- Sígueme (David Regalado) para más contenido.
- Sigue a Data Engineering Latam (Dataengineering Latam) para más contenido sobre Ingeniería de Datos, Ciencia de Datos y Gestión de los Datos.
