Análisis de herramientas para pipelines de datos escalables
in Posts
Con este análisis de soluciones modernas de datos se pretenden cubrir todos los componentes de un pipeline de datos.
El stack moderno de datos es la evolución desde un sistema viejo basado en herramientas frágiles que necesitaban constante mantenimiento a un conjunto de herramientas que automatizan, simplifican y aceleran las decisiones de negocio centralizando todos los datos en un único lugar accesible donde poder crear modelos de datos unificados con la capacidad de sincronizarse con herramientas que usan los comerciales.
En el cambiante entorno comercial actual, las empresas deben moverse más rápido en todo lo que hacen. Habilitar una arquitectura de datos moderna puede ayudar a cualquier empresa a ser más competitiva y podría suponer la diferencia con el resto. Trabajar en la nube tiene también sus retos relacionados con la seguridad, la interoperabilidad entre nubes, la eficiencia y el rendimiento de las soluciones.
El stack moderno está centrado en los almacenes de datos basados en la nube. Los datos son directamente cargados en los almacenes y se usa una capa de transformación para convertir los datos en bruto en conjuntos de datos confiables. Las mejores soluciones BI están diseñadas para habilitar el uso de estos conjuntos de datos para que todos los empleados en una organización sean capaces de encontrar las respuestas a sus preguntas. El stack moderno de datos es la evolución desde un sistema viejo basado en herramientas frágiles que necesitaban constante mantenimiento a un conjunto de herramientas que automatizan, simplifican y aceleran las decisiones de negocio centralizando todos los datos en un único lugar accesible donde poder crear modelos de datos unificados con la capacidad de sincronizarse con herramientas que usan los comerciales. Con este análisis de soluciones modernas de datos se pretenden cubrir todos los componentes de un pipeline de datos:
Recopilación y enrutamiento de los datos de los usuarios
Cuando un usuario navega por un sitio web, esa sesión del navegador genera eventos que necesitan ser registrados, validados, enriquecidos y almacenados. Las plataformas de recopilación de datos sirven precisamente para almacenar estos eventos y la analítica que generan estos usuarios. Estos datos de usuarios requieren un stack completo de herramientas. El lado del cliente recopila los datos, el middleware transporta esos datos y el lado del servidor almacena y carga los datos en los almacenes y otras aplicaciones destino. Los eventos de los usuarios son las acciones y actividades que los usuarios hacen cuando interactúan con el producto. Los datos de los usuarios son usados para múltiples tareas dentro del negocio como construir y ejecutar un roadmap de producto de forma eficiente, la tabla de precios o el diseño de la experiencia del usuario. La empresa más conocida en esta categoría es Segment, pero últimamente han entrado a competir otras soluciones como RudderStack o Snowplow que pueden ser alojadas en los propios servidores proporcionando mayor flexibilidad. Se analiza a bajo nivel a continuación estas tres soluciones para recopilar y enrutar estos eventos de usuarios directamente al almacén de datos, resaltando al final las diferencias entre ellas.
Segment
Para entender lo que los usuarios hacen y cómo servirlos mejor, se necesita enviar datos de usuarios a múltiples servicios y aplicaciones de terceros. Para simplificar este proceso y permitir también acceder a los usuarios menos técnicos, Segment ofrece una interfaz sencilla en su plataforma para capturar los datos de usuarios de primera parte, transformarlos y enrutarlos a las aplicaciones destino que la empresa necesite de manera consistente. Segment ofrece tres productos nucleares para simplificar este proceso de recopilación de eventos: el primero de ellos es Connections que proporciona un conjunto de librerías y una API para recopilar datos de usuarios de primera parte de cualquier punto de contacto con las interfaces (búsquedas en el sitio web, interacciones con elementos, visitas a páginas clave, etc) y permite enviarlos a una o varias de las más de 300 aplicaciones disponibles en su catálogo. La ventaja de Segment es que la API está muy orientada desde el principio tanto a la gobernanza de datos de usuarios como a la administración de esos datos mediante herramientas como el debugger que permite ver en tiempo real la secuencia de los eventos fluyendo de la web/app a la API de Segment. Connections también permite reproducir los datos existentes para probar nuevos destinos de datos. Esta herramienta interna se llama Replay, y es unna capa que permite limitar el envío de datos a las aplicaciones destino para testing, correr herramientas en paralelo para verificar el formato de los datos o la precisión en la salida (output) o reenviar datos en caso de que la aplicación destino no acepte temporalmente los datos entrantes. También en este paquete cuenta con una propiedad de observabilidad para identificar y resolver los errores en la entrega de los datos. Segment dispone también de un pipeline para datos de aplicaciones en la nube, algo fundamental para que se pueda combinar con los datos de comportamiento en el almacén. A nivel de integrar Segment con el almacén, Segment no es tan flexible como lo puede ser RudderStack. Es un área en la que están trabajando pero no tienen pulida aún y podría traer problemas si los datos no se alinean con la estructura de los datos del almacén. Segment está más orientada como empresa a enviar datos a aplicaciones de negocio como Salesforce (CRM), Zendesk (atención al cliente) o Amplitude (analítica de producto) aunque también ofrece la integración con almacenes de datos como Amazon Redshift. En Segment, consideran los almacenes de datos como una aplicación destino especial. En lugar de secuenciar los datos al DWH todo el tiempo, lo hacen en intervalos regulares actualizando eventos y objetos, automáticamente ajustando su esquema para ajustar los datos enviados a Segment. Connections también ofrece Functions que sirve para personalizar el código y así adaptarlo a la realidad del negocio. Además de Connections, Segment ha creado otros dos productos interesantes: Protocols que proporciona reglas que se pueden usar para especificar adónde deberían enviarse y cómo deberían verse los eventos en la aplicación destino. La estandarización de eventos y la limpieza de datos automatizada son dos características integrales de este producto, que permite limitar los eventos que se envían a la aplicación destino identificando proactivamente los errores en minutos. Con protocols se podría crear un plan de medición detallando las propiedades de cada evento para que sean consistentes entre web, apps y servidores, lo que supone un salto de calidad si se compara con el proceso de calidad de datos actual en una empresa donde el cambio es manual y tiene que pasar por múltiples departamentos hasta ser implementado y correctamente desplegado en producción. Protocols persigue cuatro objetivos: alinear a toda la organización con un diccionario de datos compartido, diagnosticar los errores en calidad de datos con informes y alertas accionables, cambiar en la raíz los datos bloqueantes sin código y resolver esos errores transformándolos en la fuente por destino o limitando eventos no planeados que no se deberían enviar al almacén o aplicaciones destino. El último producto es personas que está particularmente orientado para los equipos de marketing y permite crear perfiles de usuario unificados entre plataformas directamente en Segment para poder llevar esa audiencia a otras herramientas de outbound marketing o servicios de email. Personas cuenta con tres componentes principales: cómputo en tiempo real para entender el comportamiento de cada usuario a escala, creación de modelos de datos enviando datos a las herramientas de marketing, y un explorador de perfiles que contiene todo el historial de eventos. Las audiencias de este producto permiten configurar un perfil de cliente en base a criterios. Por ejemplo: carrito abandonado con los criterios producto añadido al menos 1 vez, orden completada 0 veces y propensión a comprar del 75% en los próximos 14 días.
Segment tiene una configuración por defecto que viene incorporada en sus librerías pero recomienda a los usuarios ser deliberados y explícitos al valorar lo que se va a medir en cuanto a métricas, eventos y embudo. Algo interesante de Segment es que para ciertos casos de uso como sitios web que corran en WordPress tienen un conjunto de eventos preconfigurados pero es algo que ya funciona en la industria y no específico para una empresa. Segment se enfoca en recopilar dos campos con cada llamada que hacen: el id anónimo (anonymous id) que es aleatorio y generado en JavaScript o en las librerías para apps móviles y el id de usuario (user id), que se puede configurar a través de la API de Segment. El flujo de eventos de Segment con las aplicaciones destino depende de cómo la aplicación destino esté diseñada. Segment usa el lenguaje Go y sus servicios con APIs que proporcionan seguridad al escribir todos sus datos en disco, sin depender de cualquier problema con su infraestructura. Al mismo tiempo, Segment hace un uso extenso de los servicios (clusters, workers, etc) de Kafka que actúa como el lugar principal para recopilar los datos y tener de esta manera réplicas que permitan trabajar con una hipotética nueva versión del código de la plataforma. Segment tiene en su pipeline una serie de pasos para filtrar datos relativos a GDPR y CCPA dentro de su producto Connections para evitar procesar datos en los sistemas sujetos a estos consentimientos. Con esta gestión por parte de Segment se pueden eliminar o editar los registros en función de las necesidades de los clientes. Segment ha mejorado mucho la forma en la que envían datos a las aplicaciones destino. Al principio, funcionaban con los workers de Kafka mediante una cola de sincronización. Luego pasaron a particionar una cola para cada destino de los datos, para evitar que un cambio en una API del destino afectara al resto de eventos. No solo eso, sino que al descubrir que podría haber casos de que un solo cliente pudiera hacer un uso fuerte de una cola, decidieron crear una cola por cliente y por destino. Esto no escaló y decidieron crear su propio sistema interno llamado Centrifuge que permite reordenar los datos en función del volumen y prioridad manipulando errores y mejorando la entrega de los datos a través las colas. Por último, Segment cuenta con una ventaja como producto al tener el sistema ctlstore (Control Store), cuya arquitectura permite a una sola instancia servir a muchos clientes.
RudderStack
RudderStack ayuda a las empresas a recopilar datos de primera parte de cualquier interacción de los usuarios en los distintos puntos de contacto con la empresa (aplicaciones, web, chats de mensajería o backend), tanto datos cuantitativos como cualitativos. Recopila todos estos puntos de contacto y actividades de los usuarios con el objetivo de enviarlos a las aplicaciones que los necesiten. Por ejemplo, la empresa podría querer enviar datos a una herramienta de analítica del producto como Amplitude o a un servicio de email marketing como MailChimp para disparar campañas de emails basadas en actividades de los usuarios. No se podría enviar una campaña, por ejemplo, que se basa en un cupón de descuento desde este servicio de email si no se dispone de ese evento en MailChimp. El problema con estas integraciones en el pasado era integrar todos los diferentes SDKs de estas herramientas de negocio (Facebook, MailChimp, etc) y crear una infraestructura de backend para recopilar todos estos eventos y enviarlos al almacén. Cada actualización de un SDK suponía cambiar la semántica de los eventos y la carga de ingeniería era importante. Precisamente RudderStack resuelve este problema de arquitectura simplificando todo el proceso: en lugar de integrar múltiples SDKs de herramientas, simplemente se envía todo a RudderStack y éste se encarga de la distribución. Para añadir un nuevo destino de los datos, solo se necesita activar el destino en un dashboard de la herramienta.
RudderStack pone a disposición de sus clientes diferentes SDKs (conjunto de paquetes o librerías) para que se puedan llevar al sistema (web, móvil o backend) y permite generar los eventos que a la empresa le importan. Se instrumenta el código de manera que genere todos los eventos que nos importan y luego se envían esos eventos a través del SDK a RudderStack. A partir de ahí se puede decidir a cuál aplicación destino se quiere enviar cada tipo de eventos. Con RudderStack, al igual que con Segment, se puede definir la semántica de los eventos o la estructura del evento que se quiere generar. Esta definición permite saber el tipo de evento que se puede generar y las propiedades que deberían ser parte de un evento. RudderStack también se encarga del mapeo de la estructura del evento que la aplicación destino puede consumir. RudderStack cuenta con dos componentes nucleares: el control plane que permite administrar la configuración de las fuentes y las aplicaciones destino; el data plane, responsable de recibir y almacenar datos de los eventos en memoria de manera temporal, transformar los eventos en el formato requerido para la aplicación destino y encargado de comunicarlos con la aplicación destino.
RudderStack cuenta con una funcionalidad de transformaciones con la que se puede configurar el formato para que la aplicación destino lo entienda y ahorrar coste (separación de nombre y apellido, por ejemplo) y otra de flujo de eventos que se encarga de la manipulación de errores, el orden y la estructura de los eventos, además del dashboard para configurar fuentes, destinos de datos y APIs. El número de eventos que puede manejar RudderStack por segundo dependerá de las aplicaciones destino. Para desplegar la versión de RudderStack en los propios servidores se usan instancias de AWS. RudderStack almacena los eventos en su backend para evitar enviar eventos individuales al almacén por lo que pueda suponer de coste. No hace falta entonces un proceso ETL para gestionar esta fase. Las transformaciones mencionadas anteriormente suceden en el lado del backend de RudderStack. El cliente envía los eventos al backend y entonces se llama a la función de transformación para cambiar la estructura de un evento. Por ejemplo, si una empresa decidiera crear una app móvil, no tendría que subir una nueva versión cada vez que decida cambiar la estructura de un evento, la transformación se encarga de cambiar el evento en su backend. RudderStack ofrece, en definitiva, unas funcionalidades muy adecuadas para la ingesta de los datos de eventos hacia el almacén de datos (transformaciones, multinodos, manipulación de errores, etc).
Snowplow
Snowplow es una herramienta especialmente orientada a la analítica interna, de hecho, empezó siendo parte de la categoría de analítica web con Google Analytics como competidor. Pero ahora es más una plataforma completa para recopilar datos y activarlos en el almacén o crear pipelines de aprendizaje automático con ellos. De hecho, sus clientes usan ambos productos en paralelo. Son complementarios porque Snowplow puede recibir datos de Google Analytics en bruto y definir una estructura y lógica limpia, al igual que es complementario con las herramientas ETL para unir datos de comportamiento con transaccionales. Comparte con RudderStack la flexibilidad de ser de código abierto y la posibilidad de poder instalarse en los propios servidores. Tiene los mismos pilares que las otras dos herramientas: enrutamiento de eventos a los destinos de manera confiable garantizando calidad de datos, transformación de eventos en tiempo real permitiendo definir estructuras de datos propias y lógica según necesidad en el modelo de datos, almacenamiento de los eventos en el almacén y foco en privacidad. Snowplow es más complejo de configurar y requiere una estructura de datos estática. En Snowplow, los módulos llamados trackers envían datos a los collectors y estos datos pueden ser validados y enriquecidos antes de llevarlos al almacén a través de trabajos ETL. Snowplow cuenta con su conjunto de SDKs para que sus clientes puedan generar los eventos. Su variedad de productos no es tan amplia como las otras dos alternativas, siendo Snowplow Insights y Snowplow Open Source sus principales apuestas. Por un lado, con Snowplow Insights podríamos entender qué es lo que más engancha de la web y tener información y datos granulares sobre las señales de comportamiento. El beneficio con el que cuenta Snowplow es que pone a disposición de sus clientes un arquitecto de soluciones para diseñar un modelo de datos inicial en SQL atendiendo a los requerimientos puntuales de cada negocio y ofrece atención al cliente 24/7 con un equipo dedicado de ingeniería para resolver bugs que podrían ocurrir. Trabajan de cerca con los clientes asesorando sobre reserva de instancias, tamaño del pipeline para patrones particulares de tráfico, etc. Desde la consola de Snowplow Insights se puede medir la calidad de datos, explorando eventos fallidos, editando las estructuras de datos o cambiando la configuración del pipeline, todo desde un mismo lugar. Snowplow se considera un pipeline unidireccional porque los datos van en una sola dirección a partir de la cual se validan, enriquecen, procesan, etc. Funcionan de esta manera: los eventos generados en los SDKs son dirigidos a un servidor que recopila los eventos en bruto y los enruta a una cola para después llegar a una fase que realiza dos tareas importantes: hace la validación del evento y hace el enriquecimiento propiamente. Son las dos partes nucleares del producto. Por un lado, la parte de validación se enfoca en la estructura y la definición que el evento debería seguir (cambia si es analítica web o móvil). Cuentan con un componente llamado Iglu que actúa como un registro para las estructuras de datos. Por otro lado, tienen la parte de enriquecimiento del evento que se podría personalizar a partir de JavaScript. La manera en la que Snowplow maneja la alta frecuencia de eventos es a través de servicios que escalan horizontalmente y son bastante robustos. JSON es el esquema por defecto que soporta Snowplow y permite flexibilidad en las definiciones de los eventos y fácil instrumentación en el código para el desarrollador. Tener JSON libera a los analistas y científicos de datos que no se tienen que preocupar tanto por el tipo de datos sino por estructurar los datos en el pipeline de tal manera que sea un flujo de calidad. Snowplow deja que el usuario final modele los datos directamente en el almacén. Respecto a GDPR y CCPA, Snowplow también está adaptando su infraestructura añadiendo funcionalidad extra alrededor del consentimiento de los usuarios. Snowplow collector proporciona alta disponibilidad garantizando 100% uptime ante alto volumen de tráfico. Snowplow está todavía manteniendo procesamiento en batch pero quieren moverse a ser una arquitectura basada 100% en procesamiento en streaming para ser más eficientes en coste, y para tener mayor robustez y estabilidad en la plataforma.
Almacén de datos
El almacén de datos es la “pieza central” del stack de datos. Una de las prioridades es configurar un lugar centralizado a partir del cual los datos puedan ser analizados y usados con objetivos de reporting por los departamentos. En otras palabras, sin importar la fuente u origen de los datos, el almacén debería ser la fuente de la verdad de todos los datos de clientes. Pero más allá de ser el centro, también es una parte fundamental en el entorno completo de datos que se está construyendo y permitirá casos de uso como visualizar los cohortes de usuarios (por ejemplo, usuarios que han visitado la página de admisiones pero no han solicitado entrevista) y tomar acciones en función de la analítica (envío de emails con descuentos a esos usuarios). Estos casos de uso requieren una interfaz sofisticada para la consulta. La escalabilidad y el coste son otros puntos importantes a considerar. En este sentido, se analizan a continuación tres proveedores en la nube: Snowflake, BigQuery, y Redshift. De todos los componentes del sistema BI mencionados en este proyecto, los almacenes de datos son los que más mejoras significativas han experimentado en los últimos años. Su alta escalabilidad, su capacidad para administrar Terabytes de datos con SQL y su independencia de los servidores locales ha supuesto un avance considerable. Otras ventajas son los precios bajo demanda que los hace más accesibles y su fácil configuración con una completa documentación detrás. Las implicaciones de estas mejoras en la arquitectura de una empresa son las siguientes:
▸ Recibir información de muchas fuentes de datos. ▸ Unificar la información para ayudar a la analítica de la empresa. ▸ Disponibilidad, rendimiento y seguridad de los datos de usuarios. ▸ Permitir usar procesos de ETL (extract, transform, load). ▸ La empresa no se tiene que preocupar de los costes que supone almacenar los datos. ▸ La mayoría de las tareas de preparación y transformación de datos pueden delegarse en el almacén de datos, usando SQL. ▸ Las herramientas de BI pueden servirse del almacén de datos en tiempo real.
Se busca una plataforma que cuente con todas las ventajas de la nube (como el pago por uso) a las que se sumen funciones relacionadas con el rendimiento intensivo, interoperabilidad y eficiencia. Los almacenes de datos guardan grandes cantidades de datos de manera histórica, tienen una gran transaccionalidad y sirven, sobre todo, para realizar consultas sobre ella. Tener un buen almacén de datos nos permitirá tener este histórico de datos para poder analizarlo más adelante en sistemas BI por los comerciales. Debe servir, finalmente, para guardar datos por un largo periodo de tiempo y estos datos se deben poder usar para poder encontrar cuestiones interesantes para el negocio. Las tres soluciones que se presentan a continuación son actualmente las más interesantes por su bajo coste por almacenamiento, su alta velocidad de procesamiento y su tabla de precios. Se detallan características, funcionalidades y arquitectura de cada una de ellas:
Snowflake
Snowflake es una plataforma de datos basada en la nube. Su almacén de datos como servicio permite cargar y analizar grandes volúmenes de datos con altas velocidades, aprovechando las ventajas de estar construidos sobre arquitecturas nativas en la nube. Snowflake nació bajo el concepto de arquitectura de datos multiclúster, que separa el poder de cómputo del almacenamiento, lo que permite escalar de manera elástica y controlar la concurrencia en las consultas durante picos y horas bajas. Este desacoplamiento permite crear clústeres independientes escalando hasta un nivel casi infinito a nivel de usuarios y procesos que pueden estar corriendo. Cuando el sistema opera con normalidad con cientos de consultas corriendo contra la misma tabla el rendimiento no se reduce porque Snowflake usa los servidores de Amazon para replicar los datos. Al mismo tiempo, garantiza más disponibilidad de los recursos, es decir, los backups no deberían interferir con flujos de trabajo o disminuir el rendimiento. Esta es la principal baza de Snowflake que se apoya en no basarse en arquitecturas previas de disco compartido sino que se sitúa bajo escalabilidad dinámica proporcionando control de los costes al cliente. Otra de las características fuertes de Snowflake es la parte de administración como es el backup o la recuperación. No creen en el rol tradicional del administrador de bases de datos para manejar temas de distribución o llaves porque la propia plataforma se encarga dejando al administrador otras partes como la salud de la base de datos. Otro de los atributos interesantes de Snowflake son los datos de tipo variant que permiten cargar datos semiestructurados en una columna de una tabla para luego acceder de forma nativa en SQL con una extensión. Esto evita algunos procesos ETL y transforma la estructura de los datos en algo que el analista de negocio puede entender. Snowflake es también agnóstico en cuanto al esquema para ser flexible a cualquier técnica de modelado o despliegue. De esta manera, clientes que lleguen desde arquitecturas legadas o entornos on-premise no tienen que necesariamente cambiar su enfoque de modelado para poder trabajar con el almacén. Al mismo tiempo, con la funcionalidad de Snowflake de replicación entre nubes, se podría correr Snowflake en AWS y replicarlo en Azure como mecanismo. En algunos casos, esta replicación es necesaria para evitar desastres en recuperación o garantizar la continuidad del negocio. En otros casos, es por razones de latencia o de negocio porque el conjunto de datos tiene que vivir en un entorno particular. En el almacén virtual de Snowflake existen dos funcionalidades que se pagan según demanda y sirven para tener un mayor control del coste: auto-suspend donde el cliente configura la suspensión del almacén en caso de no actividad y auto-resume donde el cliente puede configurar el recomienzo del almacén cuando se necesite. Snowflake trabaja un ecosistema amplio de conectores, como uno nativo de Python, uno optimizado de Spark, uno de ODBC y otro de JDBC. Permiten conectarse a servicios tradicionales como Talend o Informatica, así como otros más modernos como Fivetran. Otras funcionalidades interesantes son: UNDROP TABLE, que permite la recuperación instantánea desde una tabla hasta un esquema completo; Time Travel, que permite consultar los datos en un punto pasado en el tiempo con una ventana del tiempo configurable; resultset caching que permite volver a una query pasada a través de la UI porque se guarda en chaché por 24 horas sin tener que ejecutar de nuevo esa consulta; organizations que permite tener una organización con múltiples cuentas de Snowflake conectadas entre ellas para garantizar que siempre exista un centro de datos disponible si otro se cae; soporte por datos geoespaciales, incluyendo geo JSON; enmascaramiento de datos como funciones; capacidades ELT dentro del motor de Snowflake o funciones SQL estándares para transformaciones y cálculos.
En la parte de almacenamiento, Snowflake usa los contenedores de Azure blob storage nativo a cada nube y escribe estructuras de archivos en ese almacenamiento como cliente o usuario de Snowflake. En la parte de cómputo, usan los nodos de cómputo. En el caso de Amazon, Snowflake usa dos nodos, con su disco duro de estado sólido (SSD), en la que se basa su memoria dinámica, compartiendo con el número de hilos en su clúster de cómputo que alguien pueda asignar. La fusión de estas dos capas (cómputo y almacenamiento) se convierte en la capa global de servicios de Snowflake, que es el motor de este almacén, donde sucede la concurrencia, la seguridad, la administración de accesos a cada recurso del cómputo y la parte transaccional. Tal como se ingestan datos en Snowflake, los datos son encriptados en el lado del cliente. La parte de seguridad es prioridad y se han asegurado de que el esquema de encriptación sea lo suficientemente robusto y seguro con llaves rotatorias. Por supuesto, se adaptan tanto a HIPAA como a PCI, así como al resto de regulaciones vigentes. Snowflake cuenta con muchos metadatos que le permiten acceder directamente a los archivos donde se encuentran los datos almacenados. Snowflake particiona los datos en archivos muy pequeños, llamados microparticionados, y son capaces de mantener los metadatos en cada columna de cada uno de esos archivos. Snowflake no soporta indexaciones. El único concepto que se puede especificar en una tabla de Snowflake se llama clustering key que son columnas que especifican el orden físico de las tablas en disco. Si el sistema no funciona, la única otra elección que se tiene que tomar es si se crece el tamaño del clúster, que se puede hacer de forma dinámica y con unos segundos de latencia. Snowflake es un sistema completamente transaccional en el que se puede decidir los datos que van a consumir el resto de los sistemas cuando se ejecuta la transacción o en caso de que algo salga mal poder hacer rollback. Snowflake usa como sistema de almacenamiento S3 de Amazon y también trabaja con Azure. Todos los datos se transfieren a disco persistente o al almacenamiento remoto. A medida que las queries en Snowflake toman datos del almacenamiento, hacen cache de esto en los nodos locales que están en SSDs. En Snowflake se pueden tener uno o más clusters y especificar los tamaños. Los clusters van desde 1 nodo hasta el más grande que tiene 128 nodos. La baja latencia se alcanza en Snowflake a través de interfaces que están secuenciando los datos continuamente en pequeños lotes desde la herramienta que sea. En Snowflake tienen la funcionalidad de Snowpipe que básicamente permite manejar datos de colas. Snowpipe identifica estos archivos cuando están en estado disponible y los selecciona cargándolos en Snowflake para hacerlos accesibles para las consultas. En términos de latencia, se demora entre uno o dos minutos desde que los datos llegan a S3 hasta que están disponibles en Snowflake. Otra de las características interesantes de Snowflake es el procesamiento masivo en paralelo (estilo MPP), usando el cómputo de los nodos (almacenes virtuales ilimitados), permitiendo que cada departamento de la empresa opere independientemente sin riesgo de contención. En el lado del almacenamiento, también han implementado un algoritmo de compresión columnar avanzado obteniendo más espacio en memoria comprimido en el almacenamiento, algo que resulta diferenciador en coste con los demás proveedores. El modelo de precios en Snowflake es por segundo por nodo. Snowflake solo cobra por tiempo de cómputo mientras el servidor virtual está operando y se aplica por segundo después de los primeros 60 segundos. El almacenamiento se cobra por separado, bajo el proveedor AWS, y sale por $23 por terabyte por mes. Snowflake tiene la ventaja que aplica compresión columnar en los datos por lo que saldrá más barato que S3, por ejemplo. Data Exchange ya está disponible en una de sus regiones y permite disponer los datos al público o de manera privada para enriquecer conjuntos de datos o dar acceso a una porción del almacén a un externo, sirviendo como proceso bidireccional de datos compartido mediante un contenedor en la capa de almacenamiento. Snowflake no maneja datos no estructurados como imágenes y sonido. Por último, Snowflake cuenta con un sistema de código abierto llamado SnowAlert para apoyar a las empresas que necesitan hacer analítica de seguridad encima de Snowflake, al mismo tiempo que apoyan otros verticales como analítica de marketing o empresas relacionadas con el mundo de la salud.
Google BigQuery
BigQuery es un motor de bases de datos columnar que accede principalmente a la información que tenemos almacenada en tablas organizadas en base a columnas. Esta característica provee una gran facilidad en cuanto al acceso a información y en tiempos de respuesta (fracciones de segundo). El caso de uso principal de BigQuery es generar un almacén de datos en la nube con algunas características importantes siendo un servicio totalmente administrado por Google. El usuario no tiene que preocuparse por configuraciones, capacidades, espacios en disco o actualizaciones de software porque es completamente administrado por Google. BigQuery provee análisis en tiempo real de grandes volúmenes de datos porque cuenta con un sistema de almacenamiento estructurado capaz de escalas a petabytes. Como Snowflake, está basado en el lenguaje SQL estándar de acceso a bases de datos. BigQuery tiene un motor internamente que distribuye nuestra consulta en cientos o miles de nodos en paralelo con la intención de separar el procesamiento y obtener una respuesta en fracciones de segundo. BigQuery maneja una arquitectura donde el poder de cómputo y la capacidad de almacenamiento se gestionan de forma independiente. Como en Snowflake, no se necesita mantener una relación entre los nodos de cómputo y el espacio de la información que se pretende administrar. Esto implica que se puedan tener procesamientos masivos con poca cantidad de información o se pueda llegar a grandes cantidades de información pero con un procesamiento muy avanzado, dependiendo de la consulta, se balancearán estas dos capas. BigQuery, como la mayoría de componentes de GCP, se cobra por dos métricas: el espacio estático de información que se tiene subida a las tablas y por el procesamiento que se utilice dentro de las consultas que se lanzan. Esto supone un ahorro de costes de procesamiento si no se realizan consultas en un periodo de tiempo. A nivel de funcionamiento interno, BigQuery cuenta con tablas lógicas que podemos manejar, un motor de ejecución de consultas llamado Dremel que se encarga de recibir la sentencia SQL, separarla o dividirla entre la cantidad de nodos que considere necesarios, nodos donde está el almacenamiento masivo que contiene la información. Dremel toma la consulta, va dividiendo en subconsultas o haciendo la segmentación que considere lanzando estas consultas a cada uno de los nodos. En una fracción de segundo se podrían obtener las respuestas de cada uno de los nodos. Dremel funciona bajo el principio de tenencia múltiple donde una sola instancia se ejecuta en el servidor, pero sirviendo a múltiples clientes. Independientemente de quién haga un uso alto, Dremel se encarga de servir a cada usuario el poder de cómputo necesario. BigQuery es capaz de hacer compresión de los datos por lo que tienen que hacer menos lectura de ellos y se puede ir más rápido. El modelo columnar ayuda a eliminar redundancia porque un modelo basado en filas tiene más información compartida por fila (usuario, clienteID, ordenID, etc) y, por tanto, mayor redundancia. Otra de las partes interesantes de la arquitectura de BigQuery es Colossus, sucesor del sistema de archivos de Google (GFS). Colossus maneja la replicación de los clústeres, la recuperación y la distribución. Es un sistema global de almacenamiento optimizado para leer grandes cantidades de datos. Cuando BigQuery escribe datos a Colossus, para garantizar alta disponibilidad, BigQuery inicia la georeplicación de los datos entre los centros de datos. Capacitor es el formato del almacenamiento en columnas y es un concepto importante en BigQuery porque permite directamente operar sobre los datos comprimidos. Otros dos servicios importantes dentro de la arquitectura de BigQuery son la red Jupiter para comunicar cómputo y almacenamiento, y Borg, precursor de Kubernetes, para asignar recursos de hardware.
La información de BigQuery puede ser consultada desde la interfaz donde se puede ejecutar una sentencia SQL, se puede ejecutar desde línea de comandos o desde la API para lanzar la creación de tablas, creación de conjunto de datos, subida o bajada de datos, o acceder a través de mecanismos estándares de consumo de información como JDBC o DBC. Con estos mecanismos, BigQuery a través de su secuencia de datos habilita a cualquier aplicación a conectarse a BigQuery para hacer las consultas necesarias. Existen en el mercado herramientas de BI muy utilizadas por usuarios de negocio como Qlikview o Tableau que ya tienen el conector con BigQuery implementado. En BigQuery, el motor de consultas se traduce en múltiples servidores en paralelo con multitenencia que seleccionan la consulta, la envían a shards individuales o cada uno de esos shards opera con fragmentos pequeños de datos, y luego se dan una serie de pasos de agregaciones dependiendo de lo compleja que sea la consulta.
Un servicio muy relacionado a BigQuery es Pub/Sub que es una solución de mensajería asíncrona que permite múltiples conexiones tanto de origen como destino. La manera de conectar con Pub/Sub es por medio de suscripciones a tópicos mediante push/pull, es decir, se puede tener un componente que genere un evento lo que significaría una suscripción de tipo push o se podría tener una serie de notificaciones de que se acaba de depositar un nuevo archivo en Pub/Sub para importarlo luego en una tabla de BigQuery, esto sería una suscripción de tipo pull. Una parte importante es que Pub/Sub puede manejar tantos datos en batch o en modo streaming o tiempo real para que se dispare instantáneamente por pull. Alrededor de Pub/Sub se pueden tener todos los componentes adicionales de GCP que puedan disparar eventos, llamadas de eventos, procesos de Dataflow, archivos que se depositen en Cloud Storage o tareas que se ejecuten en el motor de computación y que puedan disparar eventos de push. Otros componentes que se podrían suscribir a pull: eventos de red (cloud networking), provisionar máquinas virtuales (compute engine), escenarios de transformación dentro de Dataflow, disprar acceso a una app creada en App Engine o monitorización con Stackdriver (cloud monitoring).
Amazon Redshift
Amazon Redshift es una base de datos columnar enfocada en el procesamiento de grandes volúmenes de datos de la manera más eficiente posible. Redshift es muy potente en análisis de datos y también se basa en procesamiento masivo en paralelo (MPP), es decir, la parte de computación está dividida en diferentes nodos con lo cual puede paralelizar muchos de los procesos y no tiene problemas para escalar a un número ilimitado de consultas. Redshift soporta todo tipo de funciones complejas como matemáticas, de ventana o geoespaciales. Redshift está integrado con S3 y con las consultas federadas (federated queries), Redshift puede hacer consultas contra bases de datos operacionales como RDS o Aurora de tal forma que Redshift pasa una parte de la ejecución a la base de datos operacional para maximizar la parte de computación en los dos lados. Las bases de datos orientadas a columnas como Redshift se enfocan en el procesamiento de consultas complejas de grandes lotes con un fin analítico. En Redshift los registros se guardan columna a columna en bloques de datos, es decir, guarda en cada uno de los bloques de datos los datos de su columna única. Esta arquitectura de guardado en columnas hacen que sirvan excelentes para aplicaciones de analítica. En Redshift, cada columna se almacena en bloques de 1MB, es decir, en un solo bloque de datos se puede tener más filas agrupadas de una única columna, lo que supone una optimización importante del espacio. Por ejemplo, si al analista de una empresa solo le interesara consultar de una tabla de 10 columnas solo 2 de ellas, solo haría falta ir a esos dos bloques de datos que representan esas dos columnas, la consulta de datos ni siquiera tendrá en cuenta esos 8 bloques de datos y eso se traduce en tiempos más bajos de respuesta. La desventaja de las bases de datos columnares como Redshift viene cuando se trata de modificar o eliminar registros mal creados por el proceso ETL. En Redshift no se tiene disponible la llave que da la entrada al bloque de datos en específico para cambiar ese dato sino que el cambio en la columna se tiene que hacer entrando por otra columna.
A nivel de arquitectura, una empresa no tendría que instalar Redshift en un servidor, sino en un clúster, que es un arreglo de varios servidores conectados. Estos servidores son los nodos de datos. De esta manera, Redshift se puede conectar a cualquier cliente de SQL mediante una conexión ODBC o JDBC, que son drivers de conexión a la base de datos muy usados en desarrollo. Amazon recomienda descargar y utilizar los drivers específicos de Redshift, aunque se pueden utilizar los drivers de PostgreSQL. Estos drivers los conectamos a un clúster, específicamente a un nodo principal, que se encarga de esta gestión de conexiones y también de coordinar los nodos de computación y el procesamiento en paralelo. Cuando recibe la consulta, parsea el código SQL, genera el plan de ejecución y genera código compilado (más eficiente) que envía los nodos de computación relevantes para esa consulta. Los nodos de computación ejecutan este código compilado en su porción de datos almacenados y devuelven los resultados intermedios al nodo principal. El nodo principal realiza las operaciones finales de agregación y ordenación y envía el resultado final de vuelta a la aplicación cliente. Cada nodo de computación es un servidor con su propia memoria RAM, su propio espacio en disco, su propio procesador y están hechos para procesar muchos datos.
Además del paralelismo de los nodos de computación, cada uno de estos nodos está dividido en segmentos que son porciones de la memoria y disco de un nodo proporcionando mayor paralelismo. Un nodo puede tener 2, 4 u 8 segmentos, de manera que los datos que se le asignen a un nodo va a ser repartida en ese número de segmentos o servidores virtuales para que sean trabajado también en paralelo. Es importante entender este número de segmentos del clúster porque es el factor de paralelismo óptimo en operaciones como la carga de datos. De esta manera, cargando datos desde un número de archivos igual o múltiplo del número de segmentos del clúster estaremos maximizando el rendimiento. Redshift utiliza S3 para las copias de seguridad como capturas automáticas pero también se pueden hacer capturas manuales o, incluso, programarlas. Aunque Redshift permite cargar y descargar datos desde y hacia S3 no hace falta necesariamente mover datos para poder utilizarlos en las consultas en Redshift porque Redshift dispone de una capa llamada Spectrum, que se aprovisiona dinámicamente y permite Redshift ejecutar consultas que utilizan datos que están en S3. Esto permite ampliar las consultas con datos externos sin necesidad de procesos de ETL. Con esta herramienta, se pueden ejecutar consultas que combinan datos actuales o calientes que se encuentran almacenados en el clúster de Redshift con datos más fríos que están almacenados en un lago de datos en S3, lo que permite mantener, por ejemplo, en el clúster de Redshift los datos de acceso frecuente y en S3, los datos de acceso poco frecuente.
La arquitectura 8.0.2 de PostgreSQL funciona como base para la creación de Amazon Redshift aunque cubren casos de uso completamente diferentes. Hay tareas como el uso de disparadores, índices o procedimientos almacenados que no se pueden llevar a Redshift y sí se pueden ejecutar en PostgreSQL. Lo cierto es que no se necesitan porque PostgreSQL se utiliza para llevar integridad y velocidad en las transacciones pero no se busca eso con Redshift sino procesamiento analítico (OLAP o BI). Algo importante relacionado con los bloques de datos es que Redshift guarda el valor mínimo y máximo de ese bloque de datos, lo que permite hacer consultas más rápidas si se tiene un filtro condicional como WHERE u ORDER BY porque ya se sabe a qué bloque de datos ir y a qué columna ir. Redshift maneja los datos de manera distribuida, lo que significa que cada segmento y nodo sean proporcionados, es decir, tengan la misma cantidad de información porque esto apoya el procesamiento en paralelo de Redshift. Redshift puede escalar hasta 128 nodos computacionales u 8.2 petabytes de almacenamiento. Otra característica de su arquitectura es la capa de procesamiento distribuida y acelerada por hardware AQUA (advanced query accelerator) que se sitúa entre los clústeres RA3 y el almacenamiento en S3. AQUA utiliza chips nitro de AWS para la encriptación y compresión, así como procesadores específicos para analítica implementados en FPGAs. En caso de ser necesario ajustar el clúster, Redshift ofrece, por un lado, un reajuste elástico (elastic resize) donde la operación se completa en cuestión de minutos (10-15) en la que el clúster hace una captura, pausa las consultas/conexiones y migra los metadatos del clúster. Durante esta fase el clúster no está disponible. Una vez finalizada, el clúster reestablece las conexiones, retoma las consultas y, en segundo plano, redistribuye los datos en los nuevos segmentos de los nodos. Por otro lado, en caso de que este reajuste elástico no esté disponible para la configuración que necesite una empresa, se podría utilizar el reajuste clásico (classic resize), mediante el cual se crea un nuevo clúster y se copian los datos. La operación tarda más tiempo (entre 2 horas y 2 días), dependiendo del volumen de datos y volumen de nodos. Durante ambas operaciones, el clúster se encuentra en modalidad de solo lectura. No siempre hace falta ajustar el clúster para soportar más carga en Redshift. Hay algunas funcionalidades de Redshift que permiten a los clústeres escalar sin necesidad de cambiar la configuración como con la funcionalidad concurrency scaling. Otra característica interesante para mejorar el rendimiento es que en Redshift las consultas se ejecutan en colas. Workload Management (WLM) permite crear diferentes colas añadidas y definir cómo las consultas se envían a estas diferentes colas. Con WLM, se puede configurar la concurrencia y la memoria asignada a cada cola manualmente o también se puede habilitar la función Auto WLM para que lo haga Redshift automáticamente. De esta manera, Redshift utiliza aprendizaje automático para gestionar dinámicamente la memoria y la concurrencia de las colas de forma que se maximice el rendimiento. Con esta función de Auto WLM se puede especificar la prioridad de las colas de forma que las consultas de alta prioridad tengan un tratamiento preferencial y un rendimiento constante, mientras que las de baja prioridad siguen progresando y no se quedan paradas. Otras funcionalidades que se pueden utilizar dentro de WLM son SQA (Short Query Accelerator) que da prioridad a consultas de corta duración y las ejecuta en un espacio dedicado para mejorar la experiencia del usuario, y QMR (Query Monitoring Rules) que son reglas de monitorizado de las consultas que permiten definir límites de rendimiento basados en métricas y especificar las acciones que se ejecutan cuando una consulta sobrepasa dichos límites. Data Lake Export es la funcionalidad que es ideal para la integración con lagos de datos en S3 porque permite exportar datos de Redshift a S3 directamente en el formato Parquet. Parquet es su formato de almacenamiento columnar y comprimido diseñado para consultas sobre grandes volúmenes de datos. Se pueden exportar datos del lago de datos directamente con el comando UNLOAD. Cuando se especifica Parquet como formato Redshift se encarga del formato, del particionamiento y del movimiento de los datos a S3 proporcionando gran flexibilidad.
La seguridad es otra de las prioridades más grandes en AWS. Redshift cifra los datos y los mantiene protegidos tanto en tránsito como en reposo y esto incluye tanto la conexión de los clientes al clúster como la comunicación con otros servicios como S3 durante la carga y descarga de datos con LOAD y UNLOAD. También proporciona integración con IAM y con proveedores de identidad compatibles con SAML para el inicio de sesión único (SSO), así como soporta autenticación multifactor (MFA). Redshift permite aislar los clústers en un VPC y, por tanto, definir un grupo de seguridad para el clúster con reglas de acceso del tráfico específicas. Utiliza un modelo de seguridad de bases de datos que también permite implementar controles de acceso, incluso a nivel columnar. Para la parte de logs (registro) y monitorización, Redshift proporciona integración con alarmas de CloudWatch y con logs de CloudTrail, además de proporcionar diferentes logs para monitorizar las conexiones así como la actividad de los usuarios. La seguridad de Redshift está evaluada por auditores externos con un parte de varios programas de conformidad de AWS, incluyendo SOC, PCI, FedRAMP e HIPAA.
Transformación
Los datos deben ser usables para poder ser consultados. Cuando los datos se cargan en el almacén están en bruto y sin procesar. El almacén tiene como propósito ofrecer baja latencia para volúmenes altos de datos. Este almacén se encuentra dentro de un pipeline, que mueve datos a través de las diferentes áreas de la infraestructura para crear modelos de aprendizaje automático, dashboards o informes. Esta fase se centra en la transformación de datos en unos que sean limpios, descriptivos, confiables y fácil de consultar.
En esta capa de transformación se convierten los datos en bruto a conjuntos de datos usables para la analítica. Este proceso requiere ciertas habilidades y unas reglas de transformación que van a ir cambiando con el tiempo porque siempre hay datos en movimiento por lo que los conjuntos de datos necesitan actualizarse y refrescarse continuamente. Históricamente, las empresas confiaban esta actividad a los equipos de ingeniería para establecer buenas prácticas en sus transformaciones como las pruebas, los controles de versiones, las revisiones de código o las alertas. Los principios de la ingeniería del software como las versiones de control o las pruebas están construidos directamente dentro del producto, asegurando fiabilidad y pipelines de datos confiables. Hay dos soluciones que ofrecen un entorno completo de desarrollo construido sobre esta compleja capa de transformación: dbt y Dataform.
dbt
DBT es un sistema para el modelado de datos que permite al usuario cliente escribir consultas escritas con una combinación de SQL y un lenguaje comúnmente usado en el ecosistema de Python llamado Jinja. Jinja permite al analista combinar el código imperativo con el lenguaje declarativo SQL, literalmente compilar una consulta SQL que se ejecuta contra el almacén. Con dbt, los ingenieros de datos no necesitan escribir y mantener transformaciones, los analistas pueden mantener sus propios pipelines en SQL y la empresa al completo tiene mejor documentación para explorar los datos. DBT es una herramienta de línea de comandos que habla el lenguaje preferido por los analistas – SQL. Con dbt, los analistas se empoderan del flujo de ingeniería de datos, desde escribir la transformación de los datos, hasta el despliegue o la documentación. DBT maneja las dependencias entre los archivos .SQL y permite crear relaciones con la base de datos. DBT ofrece una capa construida en Rails para que los analistas puedan expresar su lógica con el correcto nivel de abstracción. La unión del lenguaje imperativo y declarativo tiene una ventaja sobre la operación. Los lenguajes imperativos basan su funcionamiento en un conjunto de instrucciones secuenciales, las cuales, al ejecutarse, van alterando las regiones de memoria donde residen todos los valores de las variables involucradas en el problema que se plantea resolver. En el paradigma declarativo, más que el ¿cómo? desarrollar paso a paso un proceso, interesa el ¿qué? se desea obtener a través del programa. Quizás el lenguaje declarativo es más familiar es SQL, el cual es utilizado para interactuar con la información de bases de datos, concentrándose sólo en los resultados que van a ser obtenidos, dejándole al traductor la tarea de cómo llegar a ellos y de presentación. Usando DBT, se puede expresar la lógica como una llamada a una función y pasarla en una lista de tablas que se quieran unir. DBT después instrospecciona el esquema de todas las tablas y construye una sentencia de unión en menos líneas de código. La diferencia de trabajar con SQL en bruto a hacerlo con SQL en DBT es significativa porque SQL por sí mismo no proporciona herramientas para crear funciones, variables o algún tipo de reusabilidad. DBT ayuda con la definición de las consultas, pero también con la parte de mantenimiento de esas consultas porque si hay un cambio en SQL estándar hay que modificar diferentes consultas en donde se encuentra ubicado el error, antes de mandar un pull request con cientos o miles de líneas de código difícil de examinar. DBT es mayormente usado para crear y probar modelos de datos. Un ejemplo de estas pruebas podría ser identificar en una columna email si todos los registros tienen símbolo @, dbt alertaría si se reciben nuevos datos que no encajan con la función hash, que depende de un tamaño concreto. Este modelo de DBT consiste en una consulta SQL que define una transformación. Es la principal unidad de trabajo en DBT. DBT puede materializar esos modelos de datos de cuatro maneras: se puede crear una tabla que se recrea desde cero cada vez que se ejecuta DBT, se puede crear una tabla que se crea a sí misma incrementalmente, se puede crear una vista o un modelo efímero, que es código expresado como tablas de expresión común y se define como una pieza de código que se puede probar sin tener que dejar huella dentro del almacén. DBT crea un DAG por sí mismo, un grafo acíclico dirigido, es decir, un grafo en el que no existen ciclos. La estructura de grafo acíclico es más flexible que la de un simple árbol, pero bastante más compleja. Todo el procesamiento de datos en DBT está creado alrededor de un DAG. Ese DAG dispone de dos nodos: el primero es una fuente de datos que DBT entiende, se configura en un archivo YAML donde se encuentra la fuente de datos, que puede estar transferida de herramientas ETL como Stitch o Fivetran y luego se crean modelos de datos encima. DBT es capaz–usando llamadas a su función ref() – de crear este DAG a partir de esos nodos y de pintar una representación visual de ese DAG de manera que se pueda inspeccionar cada nodo para ver qué está pasando. DBT está basado en dos estándares o capas: capa staging y capa mart. La capa staging consiste en una versión de los datos que están todavía al mismo nivel de granularidad de los datos origen, pero con un considerable trabajo de limpieza como manejo de llaves o duplicados. Por otro lado, la capa mart es donde se hace toda la lógica de negocio para la transformación que permite mapear los conjuntos de datos eventuales en el proceso de negocio. La mentalidad dentro del equipo que hace dbt siempre ha sido poner al mismo nivel al analista de datos y al ingeniero de software. La habilidad de compartir código o conjuntos de datos estandarizados entre proyectos es parte de la filosofía de que otros puedan beneficarse de ese trabajo. Solo con el proceso ETL los datos que vengan de APIs como Stripe se van a ver iguales en el almacén. Usar DBT permite precisamente establecer buenas prácticas entre equipos respecto a las transformaciones de datos que manejan. DBT cuenta con una funcionalidad que es el manejador de paquetes (package manager) que permite referenciar el paquete dentro de un proyecto en DBT, es decir, una herramienta como Stripe transfiere un archivo JSON por cada transacción y esta funcionalidad te permite tomar una parte de esos campos JSON y materializarlos en una tabla SQL. A veces esta funcionalidad ya la tienen incorporada las herramientas ETL pero DBT permite realizar un grupo de transformaciones específicas para resolver preguntas críticas para el negocio. DBT está dividido en dos productos: DBT Core y DBT Cloud. Core está basado en la licencia de código abierto Apache 2 y ofrece las funcionalidades núcleo como son la interaz de línea de comandos, un servidor para responder a las peticiones o conexiones con bases de datos para ejecutar SQL. DBT Cloud ofrece una capa de administración completa (entorno de desarrollo, orquestador de trabajos, etc) y una interfaz de usuario encima de Core que permite al analista interactuar con el software. DBT no almacena nada, todas las consultas de los usuarios viven en sus repositorios. De la misma manera que una herramienta como CircleCI se conecta a un repositorio de GIT y ejecuta código como parte de su trabajo. DBT Cloud hace lo mismo. DBT ha creado una arquitectura amigable con plugins que no solo se conectan a los almacenes de datos más conocidos sino que el sistema también soporta plugins externos que se conectan a Presto, Spark, Athena y más, algunos mantenidos por ellos y otros por su comunidad.
Dataform
Dataform comparte la característica con dbt de ser una plataforma que permite aplicar los principios de la ingeniería del software a las transformaciones de los datos y a la definición de las tablas, incluyendo fragmentos de pruebas unitarias en SQL, definición de pipelines repetitivos, y añadir metadatos al almacén para mejorar la operativa diaria. Dataform permite mantener un modelo de datos común y único para toda la empresa y permite además controlar el flujo completo de desarrollo de este modelo desde una sola herramienta. Dataform, en cambio, tiene un punto de partida diferente al de dbt. Mientras que dbt está pensado bajo las prácticas de versión de control y pruebas, Dataform quiere hacer placentera la experiencia en un entorno web con una interfaz parecida al del editor de código donde escribes las consultas y directamente la prueba contra el almacén. Ofrece múltiples funciones para crear dependencias entre las diferentes acciones. Dataform permite ejecutar porciones del pipeline en esquemas aislados de desarrollo para que no se sobrescriba lo que está en producción. Se trabaja como en un entorno de desarrollo: ramas, commits, entrega continua, etc. Cada proyecto en Dataform es un repositorio con una colección de archivos de configuración JSON, archivos SQLX y, a veces, archivos JS. Un proyecto en Dataform contiene tres tipos de archivos: archivos de configuración que permiten configurar el proyecto, definiciones que es donde se añaden los archivos SQLX que definen las nuevas tablas, vistas y pruebas de calidad, y includes que es donde se podrían añadir los archivos de JavaScript en caso de que se definan variables o funciones. Dataform divide su proceso en varias etapas: la primera es la etapa de compilado donde producen el grafo en JSON. La segunda etapa se llama build y consiste en tomar ese grafo y combinarlo con información del almacén de datos como las tablas, columnas en esas tablas. Usan luego esta información para generar el grafo de ejecución, que es lo último para poder ejecutar lisitas de cada operación en SQL. El objetivo del diseño de Dataform es rendir lo más rápido posible (compilación en tiempo real en menos de un segundo) y lo hacen posible gracias a que la salida de un proyecto de Dataform consiste en un objeto JSON con sentencias SQL. SQLX es SQL puro pero con la particularidad de que permite añadir bloques en JavaScript o JSON, una lógica que mejora la configuración y hace el proyecto más modular. La razón por la que usan este lenguaje es porque SQL es limitado: no se puede reutilizar fácilmente, no hay manera de escribir pruebas de calidad, manejo de dependencias es complejo porque requiere sistemas separados y no facilita la tarea de documentación. Con Dataform se solucionarían los anteriores problemas y se podría generar una plantilla con un bucle que automáticamente elimine aquellos usuarios afectados por la GDPR, por ejemplo. Dataform compila el proyecto en tiempo real, sin importar el número de tablas definidas. Durante este paso, todo el código SQLX se convierte a SQL puro, que es el dialecto del almacén.
Una de sus funcionalidades nucleares es la habilidad de escribir pruebas y pruebas de calidad sobre los datos. Pero también aporta una para describir toda la documentación sobre los conjuntos de datos como pueden ser tablas o columnas o una para configurar el esquema de los datos. Los cambios se disparan directamente desde la interfaz web o la línea de comandos a producción. La manera que tiene Dataform para acelerar la ejecución de los pipelines de datos es comprobar dependencias circulares. Dataform crea una vista en el almacén que contiene la consulta que el analista escribe. El beneficio que tiene Dataform es que si el error se da en producción, y el analista quiere saber a qué tabla exactamente ir, puede hacerlo. Después de la ejecución, se pueden consultar los registros para ver otros aspectos como tablas creadas o tiempo de cada acción. Por la manera en la que Dataform compila, no sería una buena opción si tuviera que ejecutar también el código del usuario llamando a una API de terceros. Otro escenario poco recomendable para trabajar con Dataform es streaming en tiempo real porque se necesita latencia extremadamente baja que no puede garantizar.
ETL Tradicional
ETL es el proceso de extraer datos de la base de datos origen, transformarlos en una forma más apropiada para la consultas analíticas y cargarlos en un almacén de datos o un sistema de procesamiento batch. Bajo este paradigma, los datos se extraen primero de las bases de datos y las fuentes de terceros (herramientas SaaS mayormente), se transforman para cumplir las necesidades de los analistas y científicos de datos, y finalmente se cargan en el almacén de datos en la nube. En este proceso, la transformación consume particularmente recursos lo que termina impactando significativamente el tiempo que toma extraer y cargar los datos. Sin embargo, debido a los avances en las tecnologías y ecosistema de warehousing, ETL está siendo reemplazado por ELT que es más rápido y flexible. Stitch y Fivetran son los dos jugadores principales en esta categoría de herramientas, aunque han surgido otras como Matillion. A continuación, se evalúan sus diferencias y tradeoffs.
Stitch
Stitch es un servicio de ETL basado en la nube que permite mover datos desde donde vivan hasta el almacén. Stitch permite tomar el control sobre los datos sincronizándolos desde bases de datos y herramientas SaaS como Salesforce hacia almacenes de datos como Redshift, Snowflake o BigQuery. Es particularmente poderoso para quien use arquitectura basada en microservicios, que es una forma de romper el monolítico pasando de una sola cápsula a lazos de aplicaciones desacopladas que se llaman entre ellas. Stitch comprende varios microservicios y los usan para consolidar sus propios datos en un almacén. Stitch no hace transformaciones arbitrarias y es intencional. Su objetivo es llevar los datos de la fuente al destino en un formato bruto y lo más parecido a la representación original como sea posible. No hacen transformaciones intencionalmente porque el uso de esos datos en bruto depende de las necesidades de cada empresa. Ellos como empresa animan a añadir una capa de transformación encima de esta capa de datos en bruto. Una capa capaz de limpiar los datos o normalizar ciertos valores. De hecho, con sus propios datos, aplican la lógica de transformación en SQL usando la herramienta dbt. La arquitectura de Stitch se basa en una API que básicamente acepta archivos JSON. Tienen procesos que son scripts de ETL que llaman a esta API que jala los datos en función de una configuración que el usuario realiza en la configuración de la replicación y esa API (gate) organiza en lotes los datos y los enruta en una cola de Apache Kafka. Después de esa cola, Stitch dispone de una capa llamada streamery que escribe los datos en S3 y divide los datos de clientes en múltiples conjuntos preparados para ser cargados. Una vez pasan por streamery los almacenan en S3 que tiene procesos que miran si hay datos de S3 para cargar en el almacén. Stitch creará un esquema (o conjunto de datos, o carpeta, dependiendo del destino) y cargará la integración en ese esquema. Los llamados Loaders se encargan de realizar las transformaciones necesarias convirtiendo los tipos de datos para acomodarlos al destino. El disco es usado temporalmente como búfer, pero los datos están encriptados cuando son escritos y eliminados cuando se cargan. Las tres prioridades principales para Stitch de cara al usuario son durabilidad, disponibilidad y escalabilidad. Una de las ventajas de Stitch es Stitch platform, la solución para integrar cualquiera de las soluciones SaaS del mercado a través de integraciones. Esta plataforma tiene una serie de requisitos: necesitan poder ejecutar fragmentos de código (scripts) de manera programática, scripts escritos en cualquier lenguaje de programación, desarrollar y hacer pruebas locales para empaquetarlo luego en la plataforma, entorno aislado para cada instancia del script, ofrecen una arquitectura completamente administrativa que pueda alojar automáticamente y balancear la carga de los trabajos y escalar la parte de hardware de manera automática. El modelo de precios de Stitch escala en función del tamaño de la empresa. Todos los nuevos usuarios tienen una prueba gratuita de 14 dñias. Los planes estándares van desde $100 a $1.250 al mes dependiendo de la escala, con descuentos por pagar anualmente. Los planes para empresas pueden incluir funcionalidades personalizadas, así como volúmenes de datos o niveles de servicio diferentes. Estas características añadidas se cobran individualmente. El uso de Stitch se calcula en base a volumen. El uso de cada celda y la replicación en cada una de ellas dependerá de gran variedad de factores, incluyendo el destino elegido o el número de integraciones. El proceso de replicación consiste en tres fases: en primer lugar, Stitch extrae los datos a partir de las fuentes de datos que se transportan por el pipeline a través de la API llamada import. No hay transformación luego, pero se asegura la compatibilidad con el destino haciendo esos datos en bruto útiles y finalmente se carga en la aplicación destino. La ocurrencia individual de cada una de estas fases se llama trabajo de replicación. Cuando se configura una integración en Stitch, se define la replicación en la configuración incluyendo la frecuencia de la extracción, qué datos deberían ser extraídos o cómo se extraen los datos. La replicación no se hace en tiempo real, sino que esta velocidad dependerá de los recursos disponibles en las fuentes y destinos. Stitch no borra nunca los datos de destino, aunque esos registros hayan sido eliminados de la fuente. En la fase de transformación, Stitch convierte los tipos de datos solo cuando sea necesario para asegurar que la aplicación destino los acepte. Con algunas excepciones, cuando se cambia el tipo de datos o un campo tiene múltiples tipos de datos en la fuente, Stitch crea una columna adicional en el destino para acomodar este nuevo tipo de dato. El destino determina cómo Stitch maneja las estructuras JSON como son los arreglos y objetos.
Fivetran
Fivetran es una herramienta ELT, es decir, no transforma datos antes de cargarlos, sino que confían en otras herramientas como dbt para modelarlo. Fivetran deja la responsabilidad al usuario final de escribir consultas SQL que transformen y modelen los datos para mantener el esquema ajustado a las necesidades del negocio. Fivetran tiene una serie de conectores automatizados que se conectan a las fuentes de datos, reciben datos de ellas y escriben a la aplicación destino. Cada conector de Fivetran crea y maneja su propio esquema de datos, es decir, un conjunto de tablas. Dependiendo del tipo de conector, Fivetran recopila datos que la fuente envía o se envía una solicitud a la fuente que jala los datos que la fuente envía como respuesta. Por ejemplo, en el caso de Salesforce lo primero que hacen es llamar a la API de metadatos y preguntar a Salesforce qué objetos y campos están disponibles en la cuenta de Salesforce. Luego escriben una solicitud contra la API de Salesforce dinámicamente para obtener todos los datos de esta fuente. El paso siguiente es ingestar los datos a través de un proceso automatizado en el destino como puede ser un almacén. Fivetran ofrece más de 100 fuentes de datos, soportando más de una docena de almacenes como destino pero no dispone de lagos de datos como destino. Estos conectores alivian de mucho trabajo por parte de ingeniería de tener que escribir una cantidad inmanejable de scripts. Los clientes pueden solicitar nuevas fuentes de datos, pero nadie de fuera puede crear nuevas fuentes o mejorar las fuentes existentes. A nivel de arquitectura, cada fuente de datos se conecta a Fivetran a través del conector que opera como un proceso independiente que persiste por la duración de una actualización. El conector recibe los datos de la fuente usando una conexión encriptada, luego Fivetran Core normaliza, limpia y escribe los datos a un almacén encriptado. Los archivos de los datos se eliminan automáticamente después de 24 horas. Fivetran writer carga datos de manera incremental a la aplicación destino usando una conexión encriptada. El concepto de conectores es fundamental en Fivetran porque se usan para conectarse a las fuentes de datos. Hay de dos tipos: push y pull. Los conectores de tipo pull activamente jalan datos de la fuente. La descarga de datos desde el sistema fuente tiene una frecuencia fija. Se usa una conexión SSL encriptada para recuperar datos de usando varios métodos: conexiones a través de ODBC/JDBC, o API REST. Los conectores de tipo push reciben los datos que la fuente envía hacia ellos en forma de eventos. Tal como los eventos llegan, Fivetran los almacena en JSON en un bucket de archivos en un servicio de almacenamiento en la nube. De manera periódica, el proceso jala los nuevos eventos de ese bucket para después seguir los mismos pasos que el conector pull. Una vez el conector ingesta los datos, Fivetran se encarga de normalizarlos, limpiarlos, ordenarlos y eliminar duplicados. El propósito de la normalización es limpiar y formatear los datos para dejarlos en un formato óptimo para la aplicación destino. La salida de Fivetran es almacenar los registros finalizados en un archivo dentro de un sistema de archivos. El archivo está encriptado con una llave efímera que es conocida solo para el proceso encargado de la escritura. Este archivo temporal se elimina automáticamente después de 24 horas. El servicio de almacenamiento (bucket service) es dependiente de la aplicación destino. Fivetran copia el archivo en un esquema en el destino. En el proceso, la llave de encriptado efímera para el archivo es enviada al destino de tal manera que pueda desencriptar los datos cuando lleguen. Las actualización en ese esquema se realizan en la tabla destino. La actualización se completa y el proceso del conector finaliza su trabajo. Se puede programar la reanudación del proceso para la siguiente actualización. Fivetran no usa sistemas de streaming como Kafka porque no resuelven el problema en su caso donde todas las fuentes de datos y destinos son batch. Si persiste un error, se puede volver atrás y volver a intentarlo. Fivetran ofrece una prueba gratuita de 14 días en la que se pueden probar los conectores para ver si cumplen los requerimientos que el negocio necesita. Durante esta prueba, se pueden realizar sincronizaciones, comprobar el rendimiento de las actualizaciones periódicas de datos, analizar datos y probar otras funcionalidades de Fivetran. Fivetran tiene como objetivo de ingeniería expandir la calidad de sus conectores y el alcance que puedan tener para cubrir más casos de uso. Una manera de expandir esta calidad es ofrecer por defecto plantillas con el SQL necesario para transformar y normalizar los esquemas de algunas de las herramientas más populares para ahorrar tiempo a los equipos de analítica.
Matillion
La interfaz gráfica de Matillion permite modelar una cadena de eventos que naturalmente ocurren durante el modelado de datos. Se puede configurar el orden de esos eventos. Esto significa que no es necesario conocimiento de SQL, aunque sí ayuda entenderlo. Matillion también incluye una variada gama de integraciones para la ingesta de datos de terceros (unos 70 conectores). Se puede escribir código customizado con los componentes de SQL y Python que tiene. Matillion siporta transformaciones después de la carga de datos a través de los componentes de transformación. Los usuarios pueden crear estos componentes a través de interfaces de point & click o escribiendo directamente en SQL. Matillion es capaz de integrarse con unas 60 fuentes de datos en 7 categorías: CRM y marketing, ERP, finanzas, redes sociales, bases de datos, formatos de documento y archivo, y recursos de internet. Al igual que Fivetran, los clientes también pueden solicitar nuevas fuentes de datos, pero nadie de fuera puede crear nuevas o mejorar las existentes. Soporta Redshift, BigQuery y Snowflake como destinos. Matillion ofrece dos productos actualmente: Matillion ETL y Matillion Data Loader. Matillion ETL está pensado para la nube y se integra a las fuentes de datos a través de múltiples conectores habilitando fácilmente la extracción y carga en almacenes y lagos de datos. Esta lista de conectores incluyen bases de datos on-premise, bases de datos en la nube, aplicaciones SaaS, documentos y fuentes NoSQL. Se puede usar la REST API para crear un conector propio. Tiene soporte nativo con Snowflake, Amazon Redshift, BigQuery, Synapse y Delta Lake (Databricks). Matillion dispone de una interfaz gráfica que no requiere SQL y visualmente se pueden orquestar flujos de datos. A través de esta interfaz gráfica drag-and-drop se pueden combinar componentes para resolver la lógica de negocio como filtros, uniones, agregados, etc. La arquitectura de Matillion funciona como un ETL tradicional: extrae los datos con su lista extensa de conectores, carga estos datos en los entornos de la nube y realiza las transformaciones necesarias para acomodar los datos y hacerlos consumibles por herramientas analíticas como Looker, Tableau o Power BI. Por su lado, Matillion Data Loader simplifica el proceso de migrar los datos hacia el almacén. Matillion Data Loader es una plataforma SaaS basada en la nube con herramientas que permiten configurar pipelines de datos sin preocuparse por el código o la infraestructura. Matillion tiene integraciones nativas con Salesforce o Google analytics, pero también con bases de datos on-premise.
Reverse ETL
Una vez la empresa tiene configurado su proceso ETL, la siguiente pregunta que se debe estar haciendo es sobre cómo enviar esos datos de el almacén a las herramientas de negocio y marketing. El espacio de Reverse ETL viene a solucionar el problema de hacer accionables los datos que están almacenados en el almacén de datos desde el lado operativo. Normalmente la transformación nuclear vive en el almacén antes de este proceso, pero las herramientas en esta categoría también tienen una capa mínima de transformación para ajustar los datos a la estructura de datos del sistema externo. Este proceso desbloquea el problema entre los comerciales y los profesionales de datos sin tener que recurrir a un conector tipo Zapier ni escribir segmentos de código. Esta categoría es clave en la arquitectura de la solución junto al almacén de datos, que es la única fuente de la verdad de los datos, porque sincroniza la información de los contactos con plataformas de terceros como Salesforce potenciando los casos de uso más operacionales y de negocio del día a día. En el caso de la escuela de negocios, no se necesita usar este proceso para casos de uso analíticos porque para ello ya se usará la solución de BI, sino que el enfoque está puesto en los casos de uso operacionales. El envío de datos en tiempo real a estas aplicaciones desde el almacén (única fuente re la verdad) permite obtener una vista consistente del cliente en todos los sistemas usados por negocio. A continuación, se analizan las soluciones que pueden ayudar a implementar este proceso sin la necesidad de implementar conectores a través de APIs que pueden traer problemas y consumir grandes recursos de ingeniería.
Hightouch
Hightouch es una herramienta SaaS dentro de la categoría reverse ETL que vive sobre un almacén de datos y permite a las empresas enviar datos a plataformas SaaS como Salesforce o Marketo, sin importar desde dónde entran esos datos en el almacén. Se seleccionan todos los datos que se quieran propagar a otros sistemas de negocio a través de una sentencia SQL, y en la definición es cuando se especifica cómo se quieren ver esos datos en un CRM como Salesforce. El proceso en el que se basa Hightouch sigue cinco pasos: consulta los datos según necesidad usando los modelos transformados por dbt existentes en el almacén u otros creados con Hightouch, dispara un webhook cada vez que los datos cambian, entrega datos personalizados según departamento en las herramientas de negocio, usa un sistema de colas para automáticamente rechazar los registros problemáticos que causan errores y graba los registros de cada una de las filas con el debugger en tiempo real. Se eliminan flujos innecesarios a través de una interfaz sencilla donde esencialmente se incorpora una sentencia SQL en Hightouch y se indica cómo esos datos deberían aparecer en las herramientas que negocio usa como Salesforce. Hightouch también puede resolver el problema de incrustar múltiples scripts en el código fuente de los sistemas para solo conectar un sistema con otro y hace estas integraciones de lado a lado conectando las herramientas de negocio con el almacén. Cualquiera que pueda escribir SQL podría automatizar una consulta para un caso concreto sin recurrir a los ingenieros. Hightouch no se centra ni en coleccionar o cargar datos (ETL tradicional) ni en transformarlos (dbt, dataform), sino en activarlos para propósitos de negocio. Este enfoque permite que la única fuente de la verdad (almacén) sirva para enviar definiciones encima de esos datos en bruto para volverlos datos operacionales. Un caso interesante sería la creación de listas dinámicas en función de campos y parámetros en el almacén para que los equipos de marketing puedan usarlas para sus emails, anuncios en Facebook Ads o Google Ads. No se requiere que los datos estén en un formato en particular pero sí tiene que haber una transformación anterior para tener los datos en el formato correcto. El usuario que manipule Hightouch tiene que tener esto en cuenta para adaptar la consulta a sus necesidades. Hightouch ejecuta la sentencia SQL contra el almacén o a través de flujos conectados a dbt o Airflow. Antes de enviarlo a estas herramientas de negocio, Hightouch compara la consulta con otras que se han cargado desde el almacén para comprobar los cambios, los datos eliminados y los nuevos antes de sincronizar. Esto último ayuda a eliminar preocupaciones que aparecen en torno a límites de que pueden tener estas soluciones. El debugger en tiempo real ayuda a identificar duplicados y otros errores que podrían ocurrir. Para tener Hightouch la empresa necesita tener primero los datos en el almacén. Igualmente, Hightouch precisa de que alguien en el equipo pueda escribir SQL, pero no necesita recursos de ingeniería. Con Hightouch los equipos no solo pueden confiar en tener una vista unificada del usuario sino que se pueden definir reglas granulares sobre cómo se quieren propagar esas métricas clave en cada sistema de negocio. Algunos ejemplos son: el equipo de crecimiento quiere datos de interacción con emails en herramientas de analítica de producto, ventas quiere ver el scoring de un contacto en estado prospect en Salesforce, el equipo de soporte al cliente necesita datos de uso de producto en Intercom, el equipo de marketing necesita una lista de usuarios muy activos para impactarles con anuncios o el equipo de cuentas necesita atributos de clientes sincronizados con el ERP. A diferencia de las CDPs, Hightouch no tiene la limitación de que los datos tienen que matchear a nivel de usuario o cuenta sino que envían los datos al destino por campos u objetos. Hightouch no almacena nada de los datos por lo que la empresa podría tener control total sobre los datos. Hightouch ofrece actualizaciones bidireccionales, es decir, actualizaciones en un commit actualizan también Hightouch. Se conectan a servicios que son de uso común como GitHub o BitBucket. Sus funcionalidades no se limitan al aspecto de sincronización sino que también ofrecen flujos automatizados como convertir un contacto a un lead en Salesforce, crear una tarea en Asana o notificaciones de cambios o errores en los datos directamente en Slack. Además, cuenta con una función para actualizar bases de datos en producción como Postgres con una especie de proceso ETL interno con el almacén. Hightouch reemplaza el proceso manual donde el analista es el cuello de botella para la persona de marketing permitiendo a la persona de marketing responder a las solicitudes de datos a través de la interfaz de Hightouch que vive sobre el almacén de tal manera que puedan manejar el proceso de principio a fin. El modelo de precios de Hightouch se basa en registros activos mensuales de usuarios únicos, cuentas únicas y objetos personalizados únicos. Solo se paga cuando se actualiza un registro. No se cobra por usuarios activos mensuales o usuarios medibles. Con Hightouch las definiciones nucleares de la empresa pasan de vivir solo en el almacén a hacerlo en las herramientas de negocio.
Census
Census simplifica la sincronización de los datos entre almacén de datos en la nube y las aplicaciones de negocio. Funciona sobre la infraestructura de la empresa y permite seleccionar las aplicaciones de destino de los datos al usuario final, mapear los datos y mantener actualizadas las métricas de negocio. El motivo por el que los datos se mantienen seguros es porque Census corre dentro del almacén y nunca almacena los datos de la empresa en sus propios servidores. Census trabaja en la misma línea que Hightouch empujando los datos de vuelta a las aplicaciones de negocio. Los usuarios generan modelos sobre usuarios, clientes, entidades de negocio y quieren usar esos modelos para cambiar la manera en la que opera su empresa. Por ejemplo, un caso de uso podría ser con Zendesk para manejar tickets de los clientes. Los analistas de datos podrían computar cuántos ingresos están generando como compañía y combinarlo con el tamaño de esa compañía y la actividad del usuario con el producto para determinar si puede ser categorizado como cliente VIP. Usando Census, el equipo de soporte puede priorizar sus tickets cuando estén respondiendo a los clientes en base a esta información. Otro caso de uso de Census con una empresa B2B podría ser convertir a usuarios en un plan pro a un plan de empresa. Para identificar estas señales externas e internas, se podría usar Census no solo para sincronizar los datos, sino para crear los objetos en el CRM para que ventas pueda tener la información relevante de a quién llamar en un solo lugar. Para que este proceso funcione correctamente, los modelos de datos tienen que estar transformados y unificados para crear el flujo de trabajo con Census. La mayor parte del tiempo se pasa diseñando y programando estos modelos antes de desplegar estos resultados usando Census que monitorea cómo se están sincronizando y mapeando. Census en sí mismo es como un sistema de despliegue continuo e integración continua. La alternativa sería crear pipelines completos de ingeniería de datos que no son triviales por los cambios en los APIs o acceder directamente a los sistemas pero no es incremental porque, por ejemplo, pueden existir errores de duplicados. La manera en la que funciona Census es la siguiente: se conectan al almacén con una credencial, esa credencial ejecuta una consulta, hace una comparación con la última consulta lanzada y mira qué ha podido cambiar para no volvler a sincronizar lo mismo que la última vez. El próximo paso consiste en cargar los datos en el CRM o aplicación destino con un proceso batch. En este proceso tienen en cuenta las diferencias entre APIs y ratios de limitación de estos productos SaaS para determinar qué puede entrar y qué no o qué registros están duplicados a través de una funcionalidad de validación. Census es un sistema basado en estados no en eventos, es decir, lo que se apunta hacia Census son los modelos de datos, por lo que no realiza ninguna transformación de los datos, ni puede solucionar los errores que se produzcan. No haría falta pensar en la lógica de reproducción de eventos (event replay) sino solo en cómo se quiere que los datos lleguen al destino y Census se encarga de la operación. A nivel de funcionalidades, Census automáticamente navega los errores en la API y los notifica, solo hace actualizaciones incrementales sincronizando solo los nuevos valores y registros, permite customizar la frecuencia de la sincronización, ofrece recuperación automática, hace optimización de las llamadas de API, tiene soporte para dbt nativo, y automáticamente convierten tipos de datos.
BI: Visualización en dashboards y queries (consultas)
Ahora que ya están los datos trasladados al almacén, testeados, transformados en tablas usables, es momento para abrir el entorno a los usuarios de negocio a través de una capa de visualización. La inteligencia de negocio es el conjunto de metodologías, aplicaciones, prácticas y capacidades enfocadas a la creación y administración de información, que permite tomar mejores decisiones a los usuarios de una empresa. Business Intelligence también es un término usado normalmente para describir las herramientas que sirven para el análisis de los datos que se concretan en reportes o diferentes tipos de gráficos. Los datos se han convertido en el “motor” de la toma de decisiones en las empresas modernas. Si realmente las empresas quieren ser orientadas a los datos, las soluciones de BI no pueden recaer en unos informes realizados a mano por los comerciales porque sencillamente no es escalable. El proceso de transformar los datos en conjuntos de datos entendibles y fáciles de manipular solo es el primer paso pero, después, las empresas necesitan soluciones de BI para habilitar a todos el consumo de estos datos. Los trabajadores deben saber dónde encontrar los datos que necesitan y acceder a ellos de manera rápida, además de poder confiar en esos datos. Es una parte importante de la arquitectura de datos porque nos sirve como punto final de la cadena en la que estamos recopilando datos, almacenándolos, transformándolos y, finalmente, necesitamos hacer todo eso con un propósito: que todos tengan los elementos para tomar decisiones adecuadas en la organización. Tratar de proveer a todos con los datos e información correcta tiene una representación concreta y entran variables de escalabilidad, facilidad de uso y coste. En esta disciplina no solo es suficiente con tener clara la parte técnica clara, sino que es necesario, a diferencia de las otras técnicas, que se tenga sensibilidad por entender el negocio, las necesidades de los departamentos y entender qué información se necesita para tomar decisiones.
A continuación aparecen algunas soluciones BI en el mercado que se valen de las técnicas anteriores descritas para presentar los datos mediante tablas de datos, dashboards o gráficas que sirvan para tener la información a la mano de un vistazo y hacer algo que tenga coherencia y signifique algo para el departamento comercial.
Looker
Looker es una plataforma de analítica de datos que actúa como el frontend de los datos las empresas que lo usan para dar un self-service a toda la organización. Ha sido de las primeras empresas modernas en promover las ideas sólidas detrás de la generación actual de capas de modelado de datos para realizar transformaciones de los datos en bruto. Looker hace posible acceder a dónde viven los datos (almacén) y darles sentido respondiendo a preguntas sofisticadas. El almacén se conecta a Looker y este genera un modelo de LookML, un lenguaje declarativo con formato YAML muy legible que permite modelar el almacén subyacente directamente sin salir de Looker. LookML es la característica nuclear en Looker porque brinda el poder del desarrollo de software (control de versiones, entornos sandbox o pruebas unitarias) al modelado de datos. LookML ofrece esta capa de abstracción de la base de datos con SQL como lenguaje de consulta que simplifica y modula las agrupaciones, los agregados y los joins en tiempo de ejecución para darle forma a los datos según la empresa los necesite. LookML evita que exista caos en los datos precisamente porque no hace falta repetir un modelo ya creado o reusar un snippet de código, simplemente existe un modelo de datos que está gobernado, controlado por versiones y con un entorno por etapas para la personalización y realización de pruebas sin que los cambios afecten a la organización de producción o sus usuarios. Looker es una alternativa a Sisense, antes Periscope Data, que muchas compañías de base tecnológica están usando, muchas en conjunción con Redshift.
A nivel de funcionalidades de LookML: la dimensión duration permite crear un grupo de dimensión que especifica diferentes unidades de medida. Este tipo de dimensión puede devolver la diferencia entre los valores start y end con los intervalos que se especifiquen. Otra funcionalidad es que permite restringir el acceso en base a valores de los atributos del usuario dentro de un field, view, join y explore. Un ejemplo de esto sería dentro de la dimensión salario solo se quiere dar acceso a ciertos departamentos. El access_grant es un parámetro que define en una view qué user attribute que es igual a departamento tiene los valores específicos en el atributo del usuario de ese departamento. Se puede asociar la vista con una dimensión en LookML usando el parámetro required_access_grants para dar acceso solo a los que pertenecen a un departamento y a una dimensión en concreto.
LookML también ofrece una jerarquía para estructurar el código. La unidad más elevada de análisis en LookML es el proyecto, que sirve de contenedor para los modelos, las vistas y los dashboards. Los proyectos se usan para organizar proyectos y manejar permisos y conexiones con la base de datos. Al mismo tiempo, los proyectos están conectados a los repositorios de Git. Por defecto, a cada implementador que use Looker en el modo desarrollador se le asigna una rama para cada proyecto. Esto hace que LookML pueda usarse colaborativamente mediante control de versiones. Por su lado, los modelos tienen la función de organizar los análisis por necesidades de negocio. Normalmente personas de diferentes departamentos usarán diferentes modelos. Los modelos están compuestos por explores, que permiten trabajar con las join views. Estas views están construidas con tablas de la base de datos a las que Looker está conectado, o también está formada por tablas derivadas compuestas por valores unidos a partir de diferentes tablas. Como casi todos los análisis tienen que ver con agregados, cada view contiene dimensiones que representan columnas en las que sentencias de SQL como GROUP BY se pueden aplicar. Por su lado, las medidas representan funciones agregadas. También existen field sets que funcionan como vectores o matrices de las dimensiones y de las medidas. Por otro lado, los drill fields son parámetros que te permiten filtrar por dimensiones o visualizar los registros de una medida. Para terminar de ver el mapa de la taxonomía de LoomML, están disponibles los dashboards que son colecciones de visualizaciones, y pueden ser numéricas o gráficas, para que los usuarios finales de la empresa consultan a diario. Cuando se creas una visualización, se tendrá que seleccionar un explore en el que basarse. Looker también ofrece REST APIs que significa que todas las funciones de la interfaz de Looker están disponibles mediante programación: se pueden crear o guardar reports; agendar reports; descargas de dashboards, etc. En definitiva, LookML sirve como capta de abstracción entre el reporting y la base de datos lo que permite a los implementadores programar tan simple o complejo como lo requiera la situación. Realmente es una capa de abstracción de la base de datos donde se pueden describir relacionees, modificar columnas, crear agregaciones, etc. Looker genera SQL a partir de esas definiciones. Es decir, es flexible porque teniendo a LookML como lenguaje para modelar permite estandarización, repetibilidad, escalabilidad y la lista continúa y creo que es un gran catalizador para Looker porque le ayuda a diferenciarse de las aplicaciones de visualización en muchos aspectos sin perder competitividad. Además de LookML, Looker ofrece la posibilidad de crear dashboards interactivos para obtener conocimiento más granular, integraciones como Slack para recibir alertas condicionales, se integra con la suite de Google Marketing Analytics, acceso en móvil de forma rápida o un proceso de modelado del código muy intuitivo. Además, Looker dispone de un Marketplace que es un lugar centralizado para encontrar, desplegar y manejar contenidos y plug-in para enriquecer la experiencia en Looker, y un buscador que sirve como diccionario para buscar metadatos.
Metabase
Metabase es una capa de visualización de código abierto agnóstica a bases de datos bien apoyada por útiles funcionalidades y extensa documentación que permite unir tablas usando su interfaz de usuario flexible, potenciada por un generador SQL, ingesta de datos en gran escala, o potentes características de visualización para crear dashboards o para compartir conjuntos de datos. Este componente democratiza el acceso a los usuarios de negocio que no conocen el lenguaje SQL. Cuando Metabase está configurado, ofrece funcionalidades interesantes como: una terminal nativa de SQL accesible por usuarios de todos los niveles de conocimiento con una interfaz limpia que autocompleta las consultas, una interfaz sencilla para consultas que permite seleccionar fuentes de datos, filtrar, y agrupar (GROUP BY) para que los usuarios puedan producir lo más ágil posible unos gráficos a partir de un conjunto de datos dado o alertas inteligentes. Metabase se integra con Slack y/o el proveedor de email que tenga la empresa para que sea más fácil compartir los hallazgos. Metabase permite programar informes entregados en email o slack a nivel de consultas, no de dashboards completos. También ofrece alertas más avanzadas. A nivel de funcionamiento, Metabase se conecta a la base de datos de preferencia (MariaDB, SQLite, DW, etc) y empieza a escanear los datos. Entiende qué representan las columnas y tablas y crea un sistema de metadatos encima de la base de datos y a partir de ahí se pueden empezar a generar dashboards, hacer diferentes agregaciones o configurar alertas. Metabase ofrece flexibilidad con o sin conocimientos de SQL porque en caso de que no, tiene una interfaz gráfica en la que se puede explorar mediante clicks, algo que resulta muy útil para usuarios no técnicos. Otra funcionalidad interesante de Metabase es el modo multiusuario que permite explorar colaborativamente sobre los datos. En general, lo que define Metabase es que es muy flexible en cuanto al proceso de crear consultas ad hoc o compartir links de informes en aplicaciones internas como Slack. El sistema de carpetas ayuda también a esta colaboración interna. Al mismo tiempo también tiene diferentes niveles de complejidad aplicada a sus consultas. La más compleja es cuando es necesario usar las plantillas SQL para crear consultas muy detalladas para otros porque interpela al backend. También se puede usar el concepto de X-rays que consiste en una exploración automática de datos para entender lo que hay en cierto gráfico o tabla. Metabase tiene diferentes tipos de tablas y columnas con tipos de metadatos. Para una tabla dada, Metabase ofrece diferentes formas de explorarla. Hay un lenguaje de tipo YAML que describe las definiciones de X-rays para tipos específicos de datos y trata de esclarecer qué dimensiones son las interesantes. Se puede usar X-rays para tablas, segmentos de tablas o una celda específica en la consulta. Esto sirve para crear luego un dashboard basado en estas métricas y dimensiones. Metabase clasifica estas métricas y dimensiones con funciones y escoge las más interesantes para desplegar. El ciclo de vida de una consulta en Metabase es el siguiente: el usuario se sitúa en el query builder como punto de partida, selecciona el conjunto de datos que le interesa para consultar como la base de datos, selecciona la tabla, Metabase referencia esas tablas usando metadatos para tener un ID, se construyen cláusulas de agregación, filtros y otros cálculos de columnas. Después, esa consulta viaja al backend de Metabase, se inyectan los metadatos y en ese momento la consulta se convierte en el lenguaje de consultas para Metabase, MBQL. Esa consulta se envía al procesador de consultas de Metabase, se comprueba la base de datos a la que se dirige, se transpila pasando de MBQL al dialecto de la base de datos y finalmente se ejecuta en la base de datos y se muestra en la vista del cliente. Internamente, se realiza una monitorización para detectar posibles errores en esta transpilación. Para hacer la traducción del lenguaje de consultas de Metabase a cual sea el de la base de datos usan conectores, que son transpiladores efectivos. Usan este enfoque porque quieren hacerle la vida más fácil al usuario final no técnico que no quiere o puede escribir sus propias consultas. Metabase ofrece una automatización que es Pulse, una funcionalidad para crear informes sobre un área en específico de la base de datos con posibilidad de programarlo en el tiempo y enviarlo a través de email o Slack. Metabase no funciona si la organización necesita una monitorización en tiempo real (milisegundos) sino que la granularidad en el tiempo está más pensada para cadencias diarias. La mayorían usan Metabase en sus propios servidores por la naturaleza de código abierto propia de Metabase pero desde 2020 ofrecen la versión SaaS (Metabase Cloud). En el caso de que se opere con Metabase como una instancia en los propios servidores, los datos no quedan almacenados en los servidores de Metabase.
Conclusión
Reunir el stack de datos perfecto es una tarea que nunca se da por terminada. Los stacks más valiosos permiten a las organizaciones moverse lo suficientemente rápido para adoptar tecnologías cambiantes, añadiendo soluciones y analizando datos sin que eso suponga una inversión ridícula de tiempo y dinero. Sin embargo, todavía hay organizaciones que se resisten a la transformación y se basan en soluciones monolíticas o aplicaciones con código heredado sin soporte técnico ni nadie que las mantenga (en las aplicaciones monolíticas todo el código y la estructura se desarrolla en un mismo sitio). El stack moderno de datos que se plantea en este post está compuesto de aplicaciones y herramientas que funcionan de manera integrada con el fin de entregar valor a todos los equipos.
Cada componente de los que se presentan es suficientemente flexible, por un lado, para ser independiente de los demás, y robusto, por otro, para responder preguntas de negocio complejas, con la capacidad de mejorar continuamente. La correcta combinación de soluciones varía por empresa, pero los conceptos fundamentales son los mismos: crear un entorno que empodere a toda la organización respondiendo más rápido a las preguntas, creando mejores programas y moviendo la estrategia de datos a un nuevo nivel de madurez. La proliferación de microservicios y la comunicación entre el backend y el frontend realizada con REST APIs (un tipo de API basada en hacer una petición desde el frontend y el servidor responde con una serie de datos para que el frontend lo interprete) ha cambiado la manera en que las compañías enfocan la arquitectura de los datos. El stack moderno ha de ser modular que es lo mismo que decir escalable. Al mismo tiempo, modular significa flexible. En lugar de tener un solo servicio que cubra las funciones de recogida de datos, transformación y análisis, se propone una solución para cada caso lo que supone mayor especialización sin preocuparse por el bloqueo del stack completo si un sistema central no dispone de una funcionalidad.
Los stacks modulares permiten a los equipos moverse más rápido. Algunas herramientas están especializadas en procesos ETL o en transformación y cuentan con conectores e integraciones que permiten conectar componentes sin mucha complejidad. Se han considerado varios factores para la elección de las mejores soluciones: en qué lenguaje se siente más cómodo el analista, qué preguntas estamos tratando de responder o qué tipo de stakeholder está preguntando por los insights. Los stacks modernos no limitan a los analistas. Incluyen herramientas que permiten trabajar en diversos lenguajes de programación, visualizar los datos de diversas maneras, y customizar los dashboards e informes para enfocarse en las métricas más importantes por departamento. Al contrario que las soluciones monolíticas que normalmente prescriben flujos de trabajo a sus usuarios, los stacks modulares están hechos de componentes flexibles que permiten a los usuarios dictar sus propios flujos para cumplir sus objetivos. La inflexibilidad de las soluciones monolíticas también incluye problemas de gobernanza de datos cuando llega el momento de cambiar de herramientas. Si la gobernanza de los datos vive dentro de una sola aplicación como Salesforce, se tendrá que implementar desde cero una nueva plataforma. Se puede hacer la transformación de datos antes de cargarlo a una solución con una herramienta como dbt que asegura calidad de datos.
