Permíteme dar un poco de contexto. Antes de mi rol actual y antes de graduarme de Cal en mayo del ‘21, planeaba encontrar un rol en Ciencia de Datos. Esperaba que fuera relativamente simple dado que tenía varios roles e internados en Ciencia de Datos. Desafortunadamente, no solo el mercado no era muy favorable para personas buscando roles de nivel inicial en Ciencia de Datos con solo una licenciatura, sino que, más importante aún, no comencé mi búsqueda de trabajo hasta unas semanas antes de graduarme. Ni siquiera intensifiqué mi búsqueda de trabajo hasta después de graduarme, así que para ese momento, la gran mayoría de las empresas que contratarían Científicos de Datos recién graduados ya habían encontrado a sus candidatos. En ese momento, me interesé por la Ingeniería de Datos y tomé un par de cursos en DataCamp. Coincidentemente, y afortunadamente para mí, mi empresa actual, Entidad, encontró mi perfil en Diversify Tech y estaban en busca de un Ingeniero de Datos. Así que, me sumergí de lleno.

Lo Que No Esperaba

En mi mente, había algún software de código abierto que todas las empresas usaban para canalizar datos de un área a otra. Pensaba que absolutamente todo se hacía en Airflow y Spark. Te diré ahora, aparte de un breve período con Airflow, no uso ninguna de estas herramientas hoy en día. Resulta que el espacio de la Ingeniería de Datos es vibrante y tiene una cantidad increíble de ofertas de herramientas. Puede ser tan complejo como una canalización hecha desde cero en Python ejecutándose en EC2 hasta tan simple como una canalización de Fivetran configurada en menos de 5 minutos. La amplia gama de ofertas significa que casi siempre hay una herramienta que es perfecta para una canalización, sin importar el tamaño, origen o destino. Y cuando no hay una pieza de lego perfecta para tu canalización, la mayoría de las herramientas permiten construir conectores personalizados para tu caso específico.

Tampoco esperaba la popularidad de SQL en el espacio. Antes de este rol, solo había usado SQL para consultar datos. En lo que a mí respectaba, eso era todo para lo que servía, obtener los datos que necesitaba. Por supuesto, era consciente de que puedes hacer análisis más profundos usando SQL, pero siempre preferí consultar usando SQL y luego hacer todo lo demás en Pandas/Python. Sin embargo, con el auge de herramientas como dbt, SQL ha seguido volviéndose aún más poderoso. En lugar de ser una herramienta en sus últimos años como pensaba tontamente, continuará creciendo durante décadas.

Otra herramienta que uso, aunque no tan crítica, es cron. Aunque no tengo la estructura memorizada, dependo de crontab guru, encuentro la simplicidad de los asteriscos, signos de interrogación y horas del día muy visualmente atractiva. Claro que es útil para programar, pero me gusta más por la estética que por la funcionalidad.

Lo Que Llegué a Apreciar

“Datos como Producto” es una frase que había leído mucho al aprender sobre Ingeniería de Datos, pero no algo que realmente entendiera. Entendía cómo una aplicación podía ser un producto, pero no podía comprender cómo los datos podían ser un producto. Al menos pensé que no. Lo que no me di cuenta fue que ya había estado expuesto a uno de mis productos de datos más comunes: las APIs. Las APIs están en todas partes, son críticas y se usan en prácticamente todos los productos, aunque algunas APIs solo se usen internamente en las empresas.

Mi siguiente obstáculo fue entender “Ser dueño de conjuntos de datos”. Claro, si cada conjunto de datos fuera solo el backend de una API, entonces tal vez habría tenido sentido inmediatamente para mí, pero no todos lo son. No entendía qué tenía de especial las tablas. ¿La razón? Daba por sentado los conjuntos de datos limpios. Lo que pensaba que eran datos sucios, datos que podrías encontrar en Kaggle o incluso extraídos de sitios web, era solo un nivel de datos sucios. He aprendido que los datos pueden venir en tantas formas, formatos y niveles de granularidad. Habiendo ganado ahora algo de propiedad sobre una parte de la infraestructura de datos, ahora entiendo que convertirse en el dueño de un conjunto de datos o tabla significa obtener los datos correctos en un formato que los haga favorables para el análisis, documentar cualquier peculiaridad con los datos y responder cualquier pregunta que los interesados puedan tener sobre ellos.

En mi caso, donde ocasionalmente actúo como Ingeniero de Datos y Analista de Datos, eso a veces significa que tengo que hacerme estas preguntas a mí mismo, pero afortunadamente también puedo molestar al resto del equipo de ingeniería.

Otra herramienta que llegué a apreciar fueron herramientas como Fivetran. Al principio, no era fan de la herramienta, y seré honesto, fue por mi ego. Pensaba que usar Fivetran, o cualquier herramienta similar, me hacía un ingeniero menor. Pero, lo que he llegado a darme cuenta, es que este tipo de herramientas me permiten acelerar mi trabajo y llegar a las partes que disfruto más, como realizar análisis o limpiar los datos. En este caso, me importa más el destino que el viaje. Además, al final del día, usar herramientas como Fivetran permite a los ingenieros proporcionar más valor comercial en la misma cantidad de tiempo de lo que podrían hacerlo de otra manera.

El Amor de Mi Vida - La Nube

La parte más importante de mi trabajo esencialmente abarca todo, la nube. Mi proveedor de nube preferido es AWS. Siempre que había algún tipo de nueva tarea que parecía requerir una arquitectura diferente, mi movimiento inmediato era buscar cualquier servicio de AWS que pudiera hacer la solución más simple de alcanzar. Como resultado, estuve expuesto a todo tipo de ofertas de AWS como Lambda, SQS, SNS, Step Functions, Eventbridge, EC2, etc., etc., y la lista continúa. AWS y todos los demás proveedores de nube tendrán más ofertas de las que necesitaría, lo que para mí ha significado que siempre hay una herramienta para hacer mi trabajo más simple o rápido.

Mientras estamos en el tema, me enamoré de las canalizaciones micro ETL. Cada vez que la gente piensa en datos, y sus canalizaciones asociadas, siempre piensan en terabytes o incluso petabytes. Sin embargo, la mayoría de las empresas no son empresas Fortune 500. Puedo garantizarte que el 99% de las empresas en mi ciudad no tienen ni siquiera 100Gb de datos en total. Así como no tendría sentido construir una autopista de 20 carriles para 2 autos, no tiene sentido construir una canalización de nivel big-tech para una pequeña empresa. Las canalizaciones micro ETL son fáciles de construir y más fáciles de mantener, y no creo que se estén aprovechando bien. Si mi ciudad es alguna indicación, la revolución de datos aún no ha llegado a las pequeñas empresas, pero creo que podemos llegar allí una canalización micro ETL a la vez.

En Fin

Estoy agradecido por lo que he aprendido hasta ahora. Estoy aún más agradecido por todos los Ingenieros de Datos, habiéndolos dado por sentado durante mi tiempo en roles de Ciencia de Datos. Que tus datos se mantengan limpios y tus canalizaciones no envíen alertas los fines de semana. Gracias por leer.