Cómo crear un departamento de datos moderno

Tradicionalmente, los departamentos de datos o Business Intelligence empezaban desde el departamento de IT o con una Ingeniero de datos para construir la infraestructura. Era necesario generar los procesos de ETL (extracción, transformación y carga de datos) para consolidar los datos de diferentes fuentes en un almacén de datos (Data Warehouse) a menudo en servidores locales. Es importante notar que en este caso la transformación de los datos se ejecuta antes de la carga en el Data Warehouse. A partir de ese momento las tablas SQL se podían explotar desde una herramienta de Business Intelligence. Al principio, la modelización de datos en estas herramientas requería de unos ciertos conocimientos técnicos (estoy pensando por ejemplo en Microstrategy desde mi experiencia personal) y a menudo seguía perteneciendo a IT o a un ingeniero de datos. Sin embargo, empezaron a aparecer una nueva generación de herramientas de BI como Tableau, Qlik o PowerBI que aumentaron significativamente el poder de los analistas de datos y usuarios finales. Estas herramientas requerían menos conocimientos técnicos no solo para crear informes, sino también para transformar los datos en las proprias herramientas.

Desde este momento, el Analista de Datos empieza a involucrarse más en la capa de transformación lógica de los datos generando modelos y cálculos. Esto daba mucha flexibilidad comparado con las peticiones de modificar los datos en el proceso de ETL o en el Data Warehouse (DWH). Sin embargo, esta mayor flexibilidad se ha ganado a expensas de la misma robustez del sistema de BI. Por un lado, la lógica de los modelos de datos y transformaciones dependen de la herramienta de BI (con sus particularidades) generando quebraderos de cabeza a la hora de cambiar de herramienta. Por otro lado, la transformación de los datos en su fase final no es el entorno más adecuando para disponer de datos coherentes en los diferentes modelos de datos e informes. Dicho de otra manera, no es sencillo reutilizar las transformaciones y es necesario repetirlas con posibilidad de errores, o que diferentes analistas o usuarios creen transformaciones diferentes. Además, para complicar aún más el panorama, es posible conectar directamente herramientas como Power BI a las fuentes de datos, por lo que en el DWH no dispondremos de toda la información.

Mientras los analistas y usuarios empezaban a ganar cada vez más flexibilidad, asistimos también a otros cambios importantes en el mundo de las herramientas de datos:

• el desarrollo de DWH en la nube como Redshift, BigQuery, Snowflake: con estas herramientas es posible disponer de un data warehouse en minutos con una gran capacidad e procesamiento de datos y la posibilidad de escalarlo sobre la marcha en base a las necesidades.
• aparición de nuevas herramientas de extracción y cargas de datos como Fivetran o Stitch que permiten conectar con pocos clicks cientos de fuentes con nuestros almacenes de datos en la nube.

Estos dos cambios han revolucionado la parte de ETL y almacenamiento de datos dado que eso permite volcar datos brutos de las fuentes a un DWH con unos pocos clicks y de allí explotar las tablas con herramientas modernas de BI. Ya no hablamos entonces de un proceso de ETL sino más bien de ELT, dado que primero extraemos (E) y cargamos (L) los datos en nuestro data warehouse, y luego los transformamos.

Pero esto no ha solucionado el problema de las transformaciones en las herramientas de BI. Lo que nos podemos encontrar ahora es un entorno con DWH moderno en la nube donde coexisten tablas de datos brutos directamente desde las fuentes, tablas transformadas en un proceso de ETL, tablas y vistas creadas por queries programadas en el mismo DWH, y transformaciones adicionales en las herramientas de BI (no disponibles en el DWH). En estos tipos de entornos híbridos, se han popularizado otras herramientas de BI como Looker que permite una mayor centralización de las transformaciones por ejemplo generando Persistent Derived Tables (materialización de tablas de datos basadas en una cierta modelización y transformación de datos) que se guardan en el mismo DWH.

Hablando desde la experiencia personal, aunque Looker ofrece un gran potencial y flexibilidad a la hora de transformar y modelar los datos, seguimos teniendo el mismo problema de la dependencia de una herramienta de BI. Aunque se puedan guardar las tablas transformadas en el DWH esto sigue dependiendo de Looker (¿si un día tenemos que cambiar?) y el proceso de transformación puede ser complejo de visualizar, entender o modificar una vez completado. En un esfuerzo para disminuir la dependencia de Looker, he intentado mover parte de las transformaciones en BigQuery y Snowflake a través de la creación de vistas y tablas a través de queries programadas. Sin embargo, estos procesos no permiten un buen control y gestión, sobre todo si son necesarias varias transformaciones con una cierta complejidad. Y es ahí cuando descubrí DBT. DBT es una herramienta que se asocia al DWH y permite gestionar todas las transformaciones de datos con una serie de módulos reutilizables. No voy a entrar en los detalles, pero la ventaja es que esta herramienta permite gestionar casi todas las transformaciones de datos en el DWH y hacerlas disponibles a todos los usuarios del BI mejorando la coherencia de los datos y disminuyendo la dependencia de una herramienta concreta de BI.

Ahora que hemos visto como es un entorno de datos moderno podemos definir cómo tiene que ser un equipo de datos que trabaje en este entorno. Si antes el típico departamento de datos incluía un ingeniero y un analista de datos, ahora surge un rol más híbrido llamado Analytics Engineer. Si tuvieras que crear un equipo de datos desde cero hoy en día, empezarías por contratar a alguien que sepa gestionar todo nuevo entorno de datos. Esta persona puede configurar Stitch o Fivetran para iniciar la ingesta de datos, mantener ordenado un almacén de datos en la nube (BigQuery, Snowflake etc.), escribir transformaciones de datos complejas en SQL mediante dbt y crear informes sobre una capa de datos en Looker, Power BI, Qlik etc. Esta es la figura híbrida del Ingeniero de Analítica y por si sola permite a una empresa con recursos limitados avanzar mucho con un departamento de datos unipersonal. Sin embargo, para empresas que necesiten más recursos, la idea es ir buscando perfiles más especializados: Ingeniero de datos, Ingeniero de Analítica y Analista de datos. Aunque las tareas de estos perfiles puedan ser en buena parte compartidas, podemos diferenciarlos de la siguiente manera:

• Ingenieros de analítica: se centran en la transformación de datos brutos en datos transformados listos para el análisis con herramientas como DBT. Esta nueva función en el equipo de datos cambia las responsabilidades de los ingenieros de datos y los analistas de datos.
• Ingenieros de datos: pueden centrarse en una arquitectura de datos más amplia y en el EL en ELT, es decir que se centran más en la extracción y carga de datos, en particular para fuentes de datos que no se pueden conectar a través de herramientas como Fivetran o Stitch, o si se prefiere gestionar internamente el entorno de extracción y carga con herramientas como Airflow.
• Analistas de datos: pueden en la generación de cuadros de mandos, informes y análisis de datos avanzadas utilizando los datos transformados y actuar como intermediarios entre las necesidades del negocio y los ingenieros.