Nubank es una empresa basada en datos que tiene la Ciencia de Datos como uno de sus cuatro pilares, junto con la Tecnología, el Diseño y la Experiencia del Cliente. En la práctica, los modelos de ciencia de datos han estado tomando decisiones automatizadas desde los inicios de la empresa; La infraestructura y plataforma de datos de última generación permiten a cualquier Nubanker manipular datos. 

La creciente oferta de productos se tradujo en un aumento de los datos recopilados, lo que hizo que encontrar los datos correctos requiriera cada vez más tiempo. Entonces, además de un acceso fácil y seguro a los datos, los Nubankers necesitan datos seleccionados y listos para usar con control de calidad, para poder centrarse en el análisis y las aplicaciones de sus datos en lugar de buscar los datos correctos.

Tomemos un ejemplo sencillo. Supongamos que necesitas la cantidad de clientes para tu análisis. Podrías usar la cantidad de personas que se registraron, las que realizaron una primera transacción o transferencia, las que estuvieron activas el mes pasado, las que no abandonaron o no fueron bloqueadas por fraude, o las que no incumplieron.

¿Cómo conoces todas las opciones y cuáles puedes comparar con los análisis de otros?

Para abordar la calidad de los datos y, en última instancia, aumentar la eficiencia de los Nubankers para obtener datos y tomar las mejores decisiones basadas en datos, recientemente creamos una nueva capa de datos de calidad verificada en nuestro almacén de datos, con un nuevo equipo central para coordinar su adopción y sostenibilidad.

En este texto, vamos a: 

  1. dar algo de contexto sobre el enfoque previamente descentralizado de Nubank respecto de la calidad de los datos;
  2. explicar cómo condujo al desafío de lograr tanto eficiencia como calidad de los datos;
  3. presentar la capa y el marco de ″datos centrales″ que presentamos en enero de 2020 junto con un equipo central para aumentar tanto la eficiencia como la calidad.

Descubre las oportunidades

Parte 1: Nubank es una organización descentralizada, de ritmo rápido y basada en datos, con una plataforma de datos de autoservicio

Trabajamos en una empresa que ha experimentado un enorme crecimiento: Siete años después de su lanzamiento, Nubank cuenta con más de 25 millones de clientes, más que cualquier otra fintech del mundo, excluyendo Asia.

Ha logrado este impresionante crecimiento con una organización muy ágil, tanto en términos de organización de personas (unos 100 equipos autónomos) como de arquitectura de ingeniería (unos 500 microservicios). Esto significa equipos multifuncionales (escuadrones) centrados en un proyecto u objetivo específico de la empresa, junto con algunos equipos centrales horizontales.

El Equipo de Datos Horizontales se había centrado en democratizar el acceso a los datos mediante la implementación de una infraestructura de flujos de datos (ETL), la integración con herramientas de consulta / BI y el cumplimiento de la protección de la privacidad de los datos. Sin embargo, como a cada equipo se le dio libertad para crear sus propias tablas, análisis y modelos de ciencia de datos, la calidad de los datos variaba mucho.

Entonces, la ejecución del ETL (proceso Extract Transform Load, para transferir datos de nuestros microservicios de producción a nuestro Lago de Datos y Almacén de Datos) es responsabilidad del Equipo Horizontal; sin embargo, cualquier equipo puede agregar una nueva fuente de datos al ETL, o una nueva tabla, simplemente utilizando las herramientas de autoservicio desarrolladas internamente.

Con una fuerte mentalidad cuantitativa y de ingenieríaentre los analistas de negocios, la adopción de las herramientas de datos fue muy rápida y amplia. Una cosa impresionante en Nubank es que cientos de analistas saben cómo escribir SQL, Scala, usar git y escribir pruebas para sus transformaciones.

En muchas empresas, agregar una transformación al ETL automatizado es un proceso de cuello de botella, por lo que la cantidad de tablas que se ejecutan automáticamente es limitada. Sin embargo, en Nubank, este proceso se ha democratizado para que todos puedan contribuir con muy poca fricción.

Nuestras avanzadas herramientas de datos de autoservicio fueron ″víctimas de su propio éxito″: en pocos años, no solo teníamos miles de tablas sin procesar, sino también miles de tablas de datos transformadas – ¡y creciendo!

Parte 2: El análisis descentralizado generó desafíos para la coherencia de los datos y la productividad analítica

Controles de calidad vs. velocidad de ejecución

Todos los Nubankers pueden utilizar nuestra plataforma de datos de autoservicio para manipular datos, teniendo la responsabilidad de comprobar la calidad de los datos que utilizan y publican.

Sin embargo, comprobar la calidad de los datos requería cada vez más tiempo debido al aumento de tablas de datos sin procesar y transformados:

  • datos sin procesar (tablas de 20K) con la diversificación de nuestros productos financieros ofrecidos desde un producto de tarjeta de crédito hasta puntos de recompensa, cuentas de ahorro y préstamos;
  • tablas transformadas (10K) en nuestro entorno de análisis con un número creciente de contribuyentes (~500 entre los cuales ingenieros analíticos, analistas, ingenieros de datos y científicos de datos).

La coherencia de las definiciones de conceptos y métricas en toda la empresa también se convirtió en un desafío, ya que la cantidad de equipos creció a cien y necesitaban coordinarse y colaborar de la mejor manera.

Para cada uso de datos, era necesario repetir las tareas de control de calidad: asegurarse de que los datos consumidos se comprendan (legibilidad), sean correctos (precisión) y coherentes (consistencia). En última instancia, la velocidad de entrega (productividad) del análisis de datos se vio afectada.

Había que hacer un equilibrio entre la velocidad de entrega y la calidad de los datos según el caso de uso. Priorizar la calidad para informes regulatorios, modelos de ciencia de datos de alta exposición o decisiones estratégicas, al mismo tiempo que se prioriza la velocidad para análisis ad hoc o informes solo internos.

Aunque habíamos revisado las tablas minuciosamente, no era obvio distinguirlas entre otras. Además, los datos cuya calidad se controla pueden volverse obsoletos con el tiempo si no se mantienen, y algunas tablas de calidad pueden no ser coherentes con el resto en términos de convenciones de nomenclatura.

Identificar ganancias de calidad y eficiencia

Se hizo más claro que había enormes oportunidades de ganar eficiencia, ya que muchas de esas tareas repetidas de control de calidad en cientos de equipos podían realizarse una vez de forma centralizada, dejando más tiempo para que los analistas y científicos de datos se concentren en los análisis y los modelos que en la búsqueda de los datos correctos.

Cuando nos dimos cuenta de que podíamos aumentar significativamente la eficiencia, la coherencia, la precisión y la comprensibilidad del análisis de datos coordinando la calidad de los datos en un equipo central, en enero de 2020 se creó el equipo de Productividad de Análisis en Nubank.

Nuestro objetivo era lograr esta eficiencia manteniendo al mismo tiempo la libertad analítica de los analistas de toda la empresa. Si bien los objetivos autónomos de cientos de equipos deberían ser coherentes con los objetivos generales de la empresa, imaginamos que las métricas, los modelos y los informes deberían ser coherentes en toda la empresa a pesar de haber sido generados por cientos de microservicios independientes.

Parte 3: Introducción de una capa de “datos centrales” para toda la empresa con un equipo central para coordinar su lanzamiento y sostenibilidad

A medida que el nuevo equipo de Productividad Analítica se hizo cargo de la calidad de los datos de la empresa, abordó la organización del almacén de datos junto con un conjunto de reglas (convenciones de nomenclatura, requisitos de documentación), procesos (contribución y mantenimiento) e iniciativas de comunicación.

Nuestros componentes de implementación de gobernanza de calidad de datos en Nubank

Una nueva capa ″núcleo″ en el almacén de datos con algunos principios

El equipo creó una carpeta ″central″ (es decir, capa, esquema, contenedor o espacio de nombres) para diferenciar claramente las tablas con control de calidad de las otras carpetas de acceso abierto (lectura y escritura).

Aplicamos reglas más estrictas únicamente a la ″carpeta principal″, mientras manteníamos el resto del almacén de datos en un entorno de lectura y escritura de autoservicio y bajas restricciones. Esto fue fundamental para que los equipos mantuvieran la libertad de uso de datos que ha sido un catalizador para el crecimiento de Nubank.

Además, reconocemos que es necesario que coexistan diferentes capas de datos, ya que no todas las tablas están destinadas a usarse para más de un caso de uso o equipo. Nuestro objetivo es que las tablas de datos centrales sean la fuente de datos reutilizables con calidad comprobada para capas más específicas de aplicaciones comerciales.

Los principios fundamentales de la capa ″núcleo″ son:

  1. Los datos deben ser precisos (o lo más precisos posible) y mantenerse para seguir siendo precisos.
  2. Las métricas deben tener definiciones y convenciones de nomenclatura coherentes y consistentes en todas las tablas de esa capa.
  3. Cualquier Nubanker debe encontrar y utilizar datos “maestros” y fuentes veraces para los principales objetos y procesos comerciales.
  4. Las tablas se calcularían en función de datos sin procesar u otros conjuntos de datos básicos para garantizar que se mantenga la precisión.
  5. Siempre hay una documentación actualizada con cada tabla para garantizar que sus consumidores comprendan el contenido rápidamente.

Una representación simple de nuestra implementación: una capa central de datos de calidad controlada en nuestro almacén de datos.

Normas y procesos para hacerlo una realidad sostenible

Para asegurarnos de que se siguieran los principios, definimos reglas y las aplicamos técnicamente: para agregar, modificar o eliminar un conjunto de datos en la capa central, solo puedes hacerlo desde una carpeta específica en nuestro repositorio de código con reglas de contribución más estrictas.

Luego, tenemos procesos de mantenimiento que monitorean problemas potenciales en las tablas de esa carpeta principal, con un propietario responsable para solucionarlo.

Comunicación para involucrar a toda la empresa

A medida que abordamos una necesidad creciente de nuestros consumidores de datos, esperamos que utilicen nuestros conjuntos de datos principales. También esperamos que los equipos ayuden a contribuir cuando sea su dominio de experiencia o cuando posean tablas que ya cumplan con nuestros criterios y puedan transferirse a la carpeta principal; mientras que el equipo central coordina que se cumplan los principios de contribución.

Con comunicación y capacitaciones, buscamos impulsar la contribución y el consumo en toda la empresa, además de asegurarnos de estar cerca de las necesidades de nuestros consumidores de datos.

El equipo

Comenzamos el equipo con Ingenieros Analíticos (AEs) y Analistas de Negocios (BAs).

Los AEs se centraron más en la implementación, aprovechando los conceptos de modelado dimensional para diseñar una arquitectura y herramientas sólidas, el rendimiento de la ejecución, el monitoreo y la aplicación de reglas técnicas en nuestro repositorio. También fueron clave para aclarar algunos cálculos complejos y garantizar rigurosamente que fueran correctos.

Los BAs se centraron más en estar más cerca de las necesidades comerciales y comprender qué datos agregar primero, ayudar a alinear las definiciones de métricas cuando no había un consenso claro y documentar nuestros procesos que generan estos datos.

Además, también integraron este concepto central de datos con nuestra herramienta de visualización de datos, no solo en la forma en que se organizaron los datos en ella, sino también proporcionando algunos paneles e información basada en esas métricas de toda la empresa, en las que la considerable tracción dio visibilidad a nuestro proyecto.

De arriba a abajo, de izquierda a derecha: Logotipo del equipo, Renan Critelli (BA), Amanda Onaga (AE), Pepijn Looije (AE), Vitor Julio (AE), Joao Pedro Micena (AE), Flavio Akira (AE), Marcel Rubner (BA), Talisson Souza (BA) y Ariane Hoffenberg (AE, jefa de equipo).

Midiendo el éxito

El principal impacto está relacionado con la productividad de obtener datos y usarlos. Sin embargo, medir el aumento de la productividad es un desafío en sí mismo, ya que medir el tiempo exacto para buscar cambios en los datos es imposible. Nuestro enfoque hasta ahora es tener un proxy con encuestas para los consumidores de datos.

Un segundo impacto es que toda la empresa acepte métricas y definiciones como “fuente de verdad”. Lo medimos observando cuántos equipos utilizan nuestras tablas principales y cuántas consultas se ejecutan en nuestras tablas principales frente a los ″competidores″, por ejemplo, tablas similares que no están verificadas.

Finalmente, también medimos el rendimiento de nuestras tablas, tanto en términos de rendimiento de ejecución (tiempo de carga) como en términos de problemas que tuvieron que solucionarse de forma reactiva.

Conclusión

¿Recuerdas el ejemplo al principio de esta publicación? Queríamos obtener el número de clientes. Uno de los conjuntos de datos principales que creamos es una tabla sobre el grano de un cliente, con una instantánea de la información más reciente sobre él. Tiene una columna para cada opción más común para obtener este valor y una documentación que explica qué es exactamente lo que cada opción tiene en cuenta.

Puedes comparar fácilmente con otros informes que usan la misma columna, y si vas a utilizar esos datos para un informe regular que necesitas enviar, puedes confiar en esos datos ya que serán monitoreados y mantenidos. 

Ahora esto es mucho más sencillo y rápido de lo que hubiera sido antes, donde primero habría preguntado a las personas o habría intentado comparar varios cálculos diferentes de otros informes.

Como ocurre con toda plataforma que permite a los usuarios consumir y contribuir con las menores limitaciones posibles, el éxito genera cantidades y variedad de contenido tan grandes que seleccionar este contenido se convierte en un desafío clave a abordar para mantener la plataforma lo más relevante y fácil de usar posible.

El marco de datos central es una forma de separar una categoría de tablas que siguen un conjunto estricto de reglas e implementar procesos para garantizar que se mantengan en el tiempo y que la contribución mantenga un ritmo que siga nuestras nuevas necesidades de datos. La comunicación también es clave en toda la empresa para garantizar que la iniciativa se comprenda y se conozca.

Algunos de los desafíos que tuvimos durante la implementación fueron: 

  • ¿Cuáles son los pasos para llegar a una carpeta completa de “datos básicos”? ¿Cómo elegimos y priorizamos las tablas para agregar a la carpeta? ¿Cuál es la masa crítica de mesas que debería ser un hito?
  • ¿Cómo lanzamos y definimos propietarios de mantenimiento para cada tabla agregada a esa carpeta? ¿Cómo podemos detectar nuevos problemas en un conjunto de datos central?
  • ¿Cómo definimos cuáles son las columnas que se comparten en toda la empresa?
  • ¿Cuáles son los KPIs que monitoreamos? ¿Qué implica eso en las herramientas de visualización de datos?

¡Esperamos compartir nuestras respuestas a algunas de esas preguntas en algunos artículos próximos!

Descubre las oportunidades