Caso de éxito de Databricks: cómo Oportun simplificó la ingeniería de datos y el aprendizaje automático

En Oportun, los datos no son algo sobre lo que “generamos reportes” una vez que todo ha sucedido. Son un elemento de misión crítica y una parte fundamental de cómo operamos el negocio. Impulsan la forma en que entendemos a nuestros clientes, medimos el desempeño, gestionamos el riesgo, detectamos el fraude y llevamos el aprendizaje automático a los flujos de trabajo cotidianos. A medida que nuestra huella de datos creció y más equipos comenzaron a depender de los datos para tomar decisiones, una realidad se hizo evidente: el desafío a largo plazo no era si podíamos construir pipelines y modelos. Podíamos hacerlo. El verdadero desafío era hacerlo de manera confiable, rápida y segura a medida que la adopción aumentaba, sin multiplicar las herramientas, las transferencias entre equipos y la carga operativa.

Esa es la historia detrás de nuestra migración a Databricks. Hemos realizado la transición hacia una plataforma con un enfoque **Databricks-first**, que consolida la ingesta, la transformación, la analítica y el aprendizaje automático en un modelo operativo consistente. Igual de importante, fortalecimos nuestra estrategia de gobernanza al garantizar que todos nuestros datos estén gobernados mediante Unity Catalog. En la práctica, esto significa que los permisos, la auditoría, el linaje y las políticas de protección se aplican de forma centralizada y consistente, independientemente de si los datos se utilizan para analítica, reportes o machine learning.

Este recorrido representa un caso de éxito con Databricks porque simplificó nuestra plataforma y aceleró nuestra capacidad de entrega: los tiempos de ingesta de datos se redujeron de manera significativa, el desarrollo de modelos de ML se aceleró y los despliegues en producción se volvieron más predecibles, mientras que la gobernanza pasó de ser una consideración posterior a convertirse en la opción predeterminada.

Esto es lo que vamos a cubrir

• Dónde comenzamos: Spark ETL que interactuaba con múltiples sistemas
• El cambio que realizamos: una sola plataforma y un único modelo operativo
• Convertir los datos en productos: Bronze, Silver y Gold como un contrato compartido
• dbt como disciplina de modelado: haciendo que las transformaciones sean escalables y mantenibles
• Consumo alineado con conjuntos de datos curados y definiciones compartidas
• Gobernanza a escala: Unity Catalog, ABAC y enmascaramiento de PII
• Qué cambió de forma significativa: mejoras en los tiempos de ciclo para datos y ML
• Conclusión: lo que esto habilita para Oportun

Dónde comenzamos: Spark ETL que interactuaba con múltiples sistemas

Nuestro entorno anterior era sólido y evolucionó de manera orgánica con el tiempo. Los flujos de trabajo de ingeniería de datos crecieron hasta convertirse en código Spark que interactuaba con múltiples servicios e interfaces de AWS, incluidos EMR sobre EC2, S3, DynamoDB, Glue, Athena, Redshift (incluido Redshift Spectrum), además de herramientas de descubrimiento y catálogo de datos.

Ese ecosistema nos brindó flexibilidad, pero también incrementó lo que solemos llamar el “impuesto de integración”. Cada producto incorporaba sus propias consideraciones operativas: cómo se programaban los trabajos, cómo se gestionaban las fallas, cómo se administraban los cambios de esquema, cómo se descubrían los datos y cómo se aplicaban los controles de acceso. A medida que los pipelines se multiplicaron y más equipos comenzaron a contribuir, el sistema en su conjunto acumuló variabilidad de forma natural. Dos pipelines que resolvían problemas similares podían verse muy diferentes simplemente porque estaban implementados con herramientas, convenciones o patrones distintos.

El impacto de esa fragmentación no era abstracto. Se reflejaba en ciclos de incorporación más largos, una mayor carga de resolución de problemas y una iteración más lenta cuando era necesario realizar cambios. También incrementaba el riesgo de deriva lógica: situaciones en las que un mismo concepto o métrica se calcula de manera diferente según el lugar donde se utilice, lo que genera trabajo adicional de conciliación y reduce la confianza en los datos.

Al mismo tiempo, nuestro enfoque de machine learning centrado en notebooks facilitaba la experimentación rápida, pero el camino desde un “notebook exitoso” hasta un modelo confiable en producción no siempre era consistente. La lógica de las características (features) solía requerir estandarización, las dependencias debían fortalecerse, los flujos de despliegue necesitaban formalizarse y los controles de acceso tenían que validarse repetidamente. Este es un punto de inflexión común: la experimentación escala con notebooks, pero el ML en producción escala con componentes de plataforma reutilizables y una gobernanza consistente.

El impuesto de integración se hace evidente cuando sistemas capaces se vuelven más difíciles de operar de forma consistente a medida que crece su adopción.

El cambio que realizamos: una sola plataforma y un único modelo operativo

Adoptamos un enfoque **Databricks-first** para simplificar la forma en que desarrollamos y operamos las cargas de trabajo de datos y machine learning. Databricks ahora proporciona un único entorno donde la ingesta, las transformaciones, la analítica y el aprendizaje automático pueden desarrollarse y ejecutarse siguiendo patrones consistentes. Esta consolidación redujo la variabilidad operativa y clarificó la asignación de responsabilidades, ya que el trabajo dejó de estar distribuido entre múltiples plataformas con modelos operativos diferentes.

Igualmente importante, incorporamos la gobernanza como parte de los cimientos de la plataforma. Unity Catalog gobierna todos nuestros datos, proporcionando una capa centralizada para permisos y controles de acceso, auditoría, linaje y aplicación consistente de políticas. Esto es fundamental a escala porque la gobernanza no puede depender de dónde resida un conjunto de datos o de qué herramienta lo haya creado. Ya sea que el consumidor sea un analista, un dashboard o un pipeline de modelos, la gobernanza se aplica de manera uniforme en la capa de plataforma.

Esta es la diferencia fundamental entre una colección de herramientas y un modelo operativo: ya no estamos integrando manualmente el comportamiento de distintas plataformas. Lo estamos estandarizando.

Convirtiendo los datos en productos: Bronze, Silver y Gold como un contrato compartido

Uno de los mayores beneficios de nuestro enfoque **Databricks-first** ha sido estandarizar la forma en que los datos sin procesar se convierten en productos de datos confiables y reutilizables. Organizamos los datos mediante una progresión explícita que va desde la ingesta de datos brutos hasta conjuntos de datos validados y, finalmente, activos curados listos para el consumo.

Los datos sin procesar se conservan para mantener la trazabilidad y permitir su reprocesamiento cuando sea necesario. Las capas validadas y conformadas aplican controles de calidad y reglas de negocio, generando conjuntos de datos estandarizados y reutilizables. Posteriormente, los conjuntos de datos Gold se organizan en torno a dominios y KPI para que los equipos puedan utilizarlos con confianza tanto para analítica como para casos de uso posteriores.

Esta estructura beneficia tanto a perfiles técnicos como no técnicos. Para los equipos técnicos, aclara dónde deben realizarse las transformaciones y cómo se garantiza la calidad. Para los usuarios de negocio, establece un contrato claro: los conjuntos de datos Gold representan información curada y lista para la toma de decisiones, no extracciones de datos en bruto con supuestos ocultos. Además, ayuda a mantener la lógica de negocio centralizada en la plataforma, en lugar de dispersarla entre pipelines ad hoc o capas de cálculo posteriores.

dbt como disciplina de modelado: haciendo que las transformaciones sean escalables y mantenibles

Para mantener la consistencia del modelado a medida que más equipos contribuyen, utilizamos dbt como nuestra capa de modelado de datos. dbt proporciona un flujo de trabajo repetible para desarrollar transformaciones como modelos modulares, con pruebas estandarizadas y documentación integrada. Esto mejora la mantenibilidad y reduce la duplicación, ya que los equipos pueden construir sobre modelos compartidos y patrones acordados en lugar de volver a implementar la lógica de manera aislada.

Desde una perspectiva operativa, dbt nos ayuda a escalar la colaboración. La lógica de transformación pasa a estar versionada, puede revisarse fácilmente y resulta más sencillo evolucionarla de manera segura. El resultado no es simplemente un código más limpio, sino un sistema más predecible y escalable para producir conjuntos de datos confiables.