Cómo me convertí en Data Engineer sin tener experiencia en el área

Recuerdo que la primera vez que vi el término de Data Scientist me encontraba navegando en Facebook. Una publicación llamó tanto mi atención que no pude evitar checarla: “Data Scientist: The Sexiest Job of the 21st Century”.

Quizás ya has leído ese texto si ya te dedicas a los datos, pero si aún no ingresas a ese mundo, lo llamativo del título seguro hará que lo quieras leer en este momento. Una se pregunta: ¿por qué es el trabajo del siglo XXI y de qué me estoy perdiendo? Finalizada mi lectura en su momento, quedó el gusanito de la curiosidad de aprender más de esta área y encontrar una oportunidad en una profesión con un futuro prometedor.

Empecemos por mencionar que un data scientist es aquella persona que utiliza su conocimiento en materias básicas como cálculo, álgebra lineal, probabilidad y estadística para la detección patrones en los datos, con los cuales prediga algún comportamiento. Junto a estos conocimientos, se hace uso de otras habilidades técnicas como lenguajes de programación (Python,R u otros), bases de datos, librerías especializadas en machine learning, procesamiento de datos, herramientas para la visualización y comunicación efectiva de resultados.

Dicho lo anterior, es bastante común que quienes desean incursionar en el mundillo de los datos se vean rebasadas y asustadas por la enorme cantidad de información necesaria para “the sexiest job”. Y si bien hoy día tener acceso a una formación autodidacta suele encontrarse al alcance de un clic, en algunos casos el acompañamiento cercano de personas con mayor experiencia en el área nos permite seguir motivados. Es por ello que la oferta de bootcamps en data science es de las más populares y atractivas de cursar.

Si bien por mi formación universitaria muchas de estas materias y habilidades las conocía a nivel escolar, el uso de éstas en proyectos con aplicación real eran totalmente ajenas para mí. Así que me inscribí a un bootcamp para aprender, de la mano de expertos, herramientas usadas por la industria. Aunque era un curso introductorio a la ciencia de datos, la barrera de entrada era alta, ya que el conocimiento requerido en programación, probabilidad, estadística y álgebra lineal, usualmente es adquirido en las ciencias duras. Durante esas exhaustivas ocho semanas,  uno de los instructores nos presentó un panorama general sobre el área de datos y que no todo era data scientist, ya que de acuerdo con nuestra experiencia e intereses podemos alinearnos mejor con otros perfiles.

https://www.analyticsvidhya.com/blog/2015/10/job-comparison-data-scientist-data-engineer-statistician/

En ese momento, fue la primera vez que escuché del término de Data Engineer. De acuerdo con Glassdoor, “un data engineer se encarga principalmente de transformar los datos en un formato que se pueda analizar fácilmente. Para ello, desarrollan, mantienen y prueban infraestructuras para la generación de datos. Como data engineer, colabora con los y las data scientist para diseñar soluciones que los mismos utilizarán al realizar su trabajo.” [1 https://www.glassdoor.com/Job-Descriptions/Data-Engineer.htm ]

Aunque el perfil se alineaba más con mi experiencia profesional como Backend Engineer, la descripción del trabajo sonaba poco retadora. Si en esta profesión la responsabilidad únicamente es pasar datos de A a B, entonces ¿qué desafío puede tener eso si ya lo he hecho como backend developer? Así que me cerré a la oportunidad de investigar más sobre  esta área y solo me enfoqué en aprender más para trabajar cómo científica de datos.

Una vez finalizado este bootcamp, me sentí poco calificada y con nula experiencia profesional para aceptar retos de aplicar modelos y explicar los resultados para una toma de decisiones, por lo que durante años continué como web developer y backend engineer, esperando en algún momento la oportunidad de abrirme camino en el área de datos.

Fue hasta hace un año, que un excolega de carrera que conocía mis habilidades en la programación y sabía de mi interés por machine learning, me invitó a postularme a una vacante con su empleador, ya que buscaban data engineer. Debido a esta llamada, empecé a comprender una frase muy común:

Hay una verdad muy arraigada que dice que el 80% del tiempo que se dedica a la analítica de datos se emplea en limpiar y reunir los datos, y sólo el 20% en analizarlos realmente.

Y adivinen: ¿quién hace esa limpieza? Exacto, un data engineer. Acepté  sin pensarlo dos veces  mi hambre por adquirir experiencia profesional en el área de datos era mayor a lo “sexy” que fuera el rol.

El siguiente paso fue prepararme para una entrevista técnica. Había conceptos que desconocía y que son básicos de un data engineer, así que investigué con más detalle sobre:

• Proceso de ETL (extract-transform-load)
• Orquestador de procesos ETL: Airflow
• Datalake y data warehouse
• Python, pandas y pyspark
• AWS para Big Data: Glue Jobs y crawlers, Kinesis, Lambda Functions, Athena
• Bases de datos: Presto, MongoDB, Hive
• Formatos óptimos para almacenar información: parquet
• Arquitectura de procesamiento de datos
• Aplicaciones de la ingeniería de datos y machine learning en la industria
  

Durante la entrevista, conté mi experiencia en Python y pandas, cómo resolví algunos problemas de datos, cómo generé reportes de usuarios, crear sistemas de recomendación a la medida y basados en filtros colaborativos y generar RESTful-APIs usando AWS Lambda Functions. También hablé sobre mi participación en proyectos personales al crear un chat-bot desde cero, así como de mis destrezas al estar a cargo de un equipo técnico. En ese momento, me dediqué a presentar las habilidades que poseía para enfrentarme a un área que desconocía, pero la cual estaba dispuesta a enfrentar.

Una vez concluida esa entrevista, comenzó la verdadera prueba técnica. Aquí el reto fue un problema práctico dónde se debía plantear un solución arquitectónica escalable:

Se requiere generar y enviar un reporte mensual de las transacciones realizadas por los usuarios. Este debe ser entregado a más tardar el día 5 de cada mes. ¿Qué tipo de arquitectura propondrías que escale sin importar que sean 2, 5, 10 o 100 millones de usuarios?

La verdad, era la primera vez que me enfrentaba a un problema de tal magnitud, debido a que los datos que manejé como backend engineer nunca rebasaron los 500 mil registros. Como no recuerdo exactamente mi respuesta, intentaré describirla lo más cercana a cómo fue:

Mi propuesta fue  con el procesamiento tan pronto éste llegara al data lake, tener dos funciones lambda tal vez con Golang o Python, una encargada de generar el reporte y otra encargada del envío del reporte. Al preguntar más a mi entrevistador, despejó mis dudas para dar una solución. Algunas eran con respecto a restricciones de dinero, el lenguaje a utilizar, si ya existían herramientas en el equipo y el proceso actual de generar el reporte, entre otras. Esa fue mi solución final. Sin embargo, admití que para tener una respuesta más certera aconsejaría a mi cliente que en lugar de implementar inmediatamente esta solución, se investigaran papers relacionados con generación de reportes dinámicos para evaluar si esa solución tiene una mejor escalabilidad. Con tal comparación, se tendría un mayor nivel de certeza a la hora de seleccionar la arquitectura final. En ese momento, el entrevistador me comentó que a eso se le llama prueba de concepto (Proof of Concept, PoC), y que es una práctica válida y bastante común en proyectos de big data.

Un par de procesos más y, días después, la empresa me presentó una propuesta formal para unirme al equipo. Lo bueno estaba por venir. Una vez dentro, reafirmé que:

En esta área se transforman los datos en bruto en formas más útiles. Y lo que es más importante, se automatiza el proceso de esta transformación, creando un flujo repetible y consistente de datos de alta calidad listos para ser refinados.

Dentro de mi día a día en el equipo de datos, realicé actividades como:

Coding

• Desarrollo de pipelines de datos
• Mantenimiento de la infraestructura
• Depuración de código: corrección de bugs, hotfixes, reworks
• Mejoras en el código (añadir o eliminar código)
• Documentación
• Dato curioso: Múltiples estudios tienden a mostrar que un ingeniero de software pasa del 30 al 40% codificando diariamente.
  

Arquitectura

Antes de comenzar a desarrollar pipelines es necesario generar la arquitectura de la solución para que las personas con mayor experiencia puedan aconsejarnos sobre si la solución es ideal, además de ver otros temas como: ¿Es la solución planteada escalable? ¿Cuál es el costo y tiempo del recurso de cómputo utilizado? ¿Qué tanto se verá afectada la base de datos productiva si se ejecuta un proceso que actualice 5 millones de datos en tiempo real?

Project Management

Estas actividades se dividen principalmente en dos tipos:

• Redacción: preparación de entradas, hoja de ruta, etc.
• Reuniones: standup, planificación de sprints, etc.
  

Evangelización de los datos

La persona profesionista en el área de data engineer, está la mayor parte del tiempo sentada entre el martillo (consumidores de datos, es decir, analistas de datos/científicos de datos/negocios/microservicios) y el yunque (productores de datos, como back-end y front-end).

Si algo va mal para el consumidor de datos, el primer en culparse es al data engineer. En esa situación, hay que establecer las reglas y difundir la cultura de los datos.

Code Review

Nada como aprender del código de tus colegas de equipo para impregnarse del proyecto y retos enfrentados.

Memes y descanso

El descanso es parte del trabajo y permite que, al alejarnos por un problema, liberemos la mente un momento para descansar y pensar en una perspectiva diferente.

Aprender nuevos detalles

Es necesario seguir aprendiendo para mejorar nuestro expertis, por lo que conocer más sobre big data y data engineer es necesario para crecer más en esta área y soluciones retos tan grandes que requieran el procesamiento, en un tiempo aceptable, de millones de datos.

Con todo lo anterior, fue una sorpresa grata conocer los grandes retos a los que se enfrenta un data engineer y que, en muchas ocasiones, es poco visto su aporte debido a que se asume que los datos estarán disponibles para su uso. Fue un largo camino para llegar a un área donde pocos profesionistas tienen la oportunidad de enfrentar esta clase de retos, principalmente por las barreras mentales autoimpuestas.

Finalmente, si te encuentras en una situación similar y buscas un cambio similar en tu carrera, te invito a que des ese paso y apliques en empresas que buscan estos profesionales. Usualmente, tenemos habilidades útiles para el departamento de datos que descartamos por una miopía a solo apuntar a la ciencia de datos.