Almacenamiento de datos de forma incorrecta

Durante algún tiempo pareció obvio que, como industria, hemos estado tratando de meter herramientas cuadradas de almacenamiento de datos en agujeros redondos de aplicaciones basadas en datos. Pero no fue hasta que leí la excelente publicación del CEO de Decodeable, Eric Sammer, Estamos abusando del almacén de datos: RETL, ELT y otras cosas raras, que entendí por qué y qué daño estábamos causando en el proceso. Como escribe Sammer, "poner sistemas de bases de datos analíticos caros en el camino correcto introduce anti-patrones de pantalones en la cabeza para la compatibilidad y las operaciones".

En caso de que te lo estés preguntando, "los anti-patrones de pantalones en la cabeza" son en realidad un grito angustiado de "¡alguien por favor detenga esta locura!"

Complicando el problema de los datos

Pregunte a las empresas cómo se sienten acerca de sus almacenes de datos y un alto porcentaje (el 83 % en esta encuesta) expresa su insatisfacción. Luchan para cargar datos. Tienen datos no estructurados pero el almacén de datos no puede manejarlos, etc. Sin embargo, estos no son necesariamente problemas con el almacén de datos. Me arriesgaría a suponer que, por lo general, la insatisfacción surge al tratar de obligar al almacén de datos (o la base de datos analítica, si lo prefiere) a hacer algo para lo que no es adecuado.

Aquí hay una forma en que comienza el error, según Sammer:

A estas alturas, todo el mundo ha visto la tendencia rETL (ETL inverso): desea utilizar los datos de la aplicación n.º 1 (por ejemplo, Salesforce) para enriquecer los datos de la aplicación n.º 2 (Marketo, por ejemplo). Debido a que la mayoría de las tiendas ya están enviando datos desde la aplicación n.º 1 al almacén de datos con una herramienta ELT como Fivetran, muchas personas tomaron lo que creen que era un atajo, hicieron la transformación en el almacén de datos y luego usaron una herramienta rETL para sacar los datos del almacén y en la aplicación #2.

Las empresas de almacenes de datos y data lakes de alto precio, ELT y rETL estaban felices de ayudar a los usuarios a implementar lo que parecía una forma pragmática de unir aplicaciones, incluso a un costo y una complejidad considerables.

¿Y por qué no lo harían? “El almacén de datos en la nube es probablemente el ciclo de CPU más caro disponible”, dice Sammer. La topología del almacén de datos termina multiplicando los datos (creando problemas de gobernanza, entre otros), pero tiene la ventaja de ser conveniente. Los almacenes de datos son convenientes en el sentido de que se entienden bien. Mucha gente está capacitada para usarlos y ya están en uso.

Problema correcto, solución incorrecta

Sammer hace un convincente punto de "pantalones en la cabeza" de que son exactamente la forma incorrecta y más costosa de crear aplicaciones basadas en datos. ¿Por qué? Porque "colocar un almacén de datos entre dos aplicaciones de nivel 1 es una [mala] idea". Las empresas tienden a no tratar sus sistemas analíticos "como Tier 1 o componentes críticos para el negocio". Por lo tanto, “las empresas no replican herramientas y datos analíticos para una alta disponibilidad en todas las zonas de disponibilidad; no duplican procesos”. El resultado es un “coste y un riesgo enormes”. O, como concluye, "hemos diseñado accidentalmente la experiencia de nuestros clientes para que dependa de procesos ELT por lotes lentos".

Entonces, ¿cuál es la alternativa?

Para Sammer, se trata de transmitir datos, no de ELT (o reETL). Se trata de canalizaciones de datos en tiempo real basadas en la arquitectura Kappa. La arquitectura Kappa significa que tiene un "registro inmutable de solo agregar". Desde el registro, "los datos se transmiten a través de un sistema computacional y se alimentan a almacenes auxiliares para servir”, explica Milinda Pathirage, especialista en ingeniería de big data en KPMG. O, como escribió el CEO de Confluent, Jay Kreps, en 2014, cuando era líder de ingeniería en LinkedIn, argumentando en contra del tipo de enfoque de arquitectura Lambda "pegado con cinta adhesiva" que Sammers descarta, "¿por qué no se puede mejorar el sistema de procesamiento de flujo para manejar el problema completo establecido en su dominio de destino?-2.

Es decir, hacer que la transmisión sea el centro del universo de datos.

Los beneficios, sugiere Sammers, son varios: “Cuesta mucho menos, proporciona SLA de calidad de Nivel 1 sin el coste de duplicar datos, permite fallos fraccionarios en lugar de totales y saca su almacén de datos de la ruta crítica. En pocas palabras, Kappa significa extraer datos de la aplicación número 1 a medida que ocurren, enviarlos en fragmentos pequeños a una puerta de enlace de datos, transformarlos/enriquecerlos según sea necesario y luego enviarlos a todos los lugares que se necesitan en paralelo".

Incluso si no cree que el flujo reemplaza a la base de datos (yo personalmente no lo creo), es fácil aceptar la idea de que las canalizaciones/flujos de datos son más el futuro que intentar mover datos de un lado a otro entre bases de datos analíticas. Aunque Kappa y enfoques similares brindan datos en tiempo real, en realidad no se trata de eso. Según Sammer, se trata de poner fin a la “gran cantidad de deuda tecnológica que está acumulando rETL. Se trata de desentrañar el nido de dependencias críticas de las herramientas de análisis y hacer que el soporte sea sostenible”.

La próxima vez que construya una aplicación que tenga una tabla de clasificación o que necesite ser informada por datos (y ese es un porcentaje cada vez mayor de aplicaciones), pregúntese por qué su suposición de datos predeterminada es estasis: datos almacenados que luego debe impulsar de aplicación a aplicación, de sistema a sistema. Ya no vivimos en ese mundo orientado a lotes. Sammers parece tener razón: las secuencias deberían ser el valor predeterminado, no una excepción.