De los lagos de datos a HTAP: 3 alternativas a los almacenes de datos OLAP

Ya sea que ya tenga un almacén de datos o simplemente esté buscando soluciones, probablemente esté al tanto de los dolores de cabeza que los almacenes de datos pueden crear tanto para los analistas de negocios como para TI.

(Si no, echa un vistazo a parte uno de esta serie de dos partes, que explica algunas de las limitaciones de los almacenes de datos tradicionales diseñados para admitir herramientas de procesamiento analítico en línea (OLAP).

Con la evolución de la computación en memoria, las herramientas de visualización interactiva de datos y nuevos tipos de sistemas de administración de bases de datos (DBMS), el mercado de inteligencia comercial (BI) ahora está saturado con alternativas al almacén de datos OLAP.

Aquí analizamos algunas de las soluciones más sencillas para realizar un análisis histórico sin un almacén de datos completo. Estas soluciones alternativas pueden ser especialmente útiles para las pequeñas empresas que carecen de los recursos de TI o del presupuesto para implementar un almacén de datos en primer lugar.

También discutiremos soluciones avanzadas como Data Lakes y HTAP que prometen eliminar por completo la necesidad de almacenamiento de datos.

Esto es lo que cubriremos:

(Haga clic en un enlace a continuación para saltar a esa sección).

Alternativa #1: lagos de datos
Alternativa #2: HTAP/DBMS en memoria
Alternativa n.º 3: análisis de estilo OLAP con herramientas de autoservicio
Avanzar

Alternativa #1: lagos de datos

Los lagos de datos son esencialmente almacenes de datos que están mucho menos estructurados que los almacenes de datos.

Los almacenes de datos tradicionales se basan en tecnologías de sistemas de gestión de bases de datos relacionales (DBMS) que almacenan datos en tablas, siendo el ejemplo más conocido las bases de datos SQL.

A diferencia de las tablas utilizadas en las bases de datos relacionales, los cubos de datos multidimensionales presentes en estos DBMS son no relacional almacenes de datos porque los datos se cargan en una matriz cúbica en lugar de tablas.

Sin embargo, el almacén de datos normalmente contiene más datos que el propio cubo de datos para permitir que los analistas consulten por debajo de las dimensiones más granulares del cubo.

Por lo general, los datos que son demasiado granulares o no estructurados para cargarlos en un cubo OLAP se almacenan mediante una base de datos relacional para complementar el análisis multidimensional en el cubo. En otras palabras, los DBMS tradicionales para OLAP admiten el almacenamiento de datos tanto relacionales como no relacionales.

Por lo general, las relaciones entre tablas en un almacén de datos se definen mediante una estrella planque organiza los datos en tablas de hechos y tablas de dimensiones para que sea más fácil unir tablas a través de consultas:

Esquema de estrella típico para registros de ventas

El esquema en estrella consta de dos tipos de tablas: tablas de hechos y tablas de dimensiones.

  • Tablas de hechos contener medidas, es decir, valores numéricos para cantidades de ventas, unidades vendidas, etc. llaves que son idénticas a las claves principales que se encuentran en las tablas de dimensiones.
  • Tablas de dimensiones contienen claves primarias así como atributos de la dimensión, por ejemplo, «DayOfWeek» es aquí un atributo de la dimensión «Time». Las dimensiones y los atributos que se encuentran en las tablas de dimensiones proporcionan las rutas de exploración que guían el análisis OLAP.

Al vincular claves externas a claves primarias, los esquemas en estrella asocian los mismos hechos en múltiples dimensiones, lo que permite el análisis multidimensional en un cubo de datos.

Por el contrario, los datos en un lago de datos están mucho menos estructurados y esquematizados. En muchos casos, los datos aún se preprocesan antes del almacenamiento, pero sin utilizar estructuras rígidas (como el esquema en estrella) que normalmente se utilizan para el almacenamiento de datos.

Con un almacén de datos, la información se estructura mediante esquemas cuando se carga en el almacén, un enfoque conocido como diagrama por escrito (ya que los datos se esquematizan cuando se escriben en la memoria).

Con un lago de datos, el esquema se define cuando los datos se consultan a través de una API o SQL, un enfoque conocido como esquema en lecturalo que requiere un modelado inicial de datos mucho menos rígido.

En cambio, la complejidad de definir esquemas se traslada a la consulta misma. Es por eso que los lagos de datos son ideales para analistas y científicos de datos que tienen habilidades de consulta avanzadas y cuentan con el respaldo de un departamento de TI ágil.

Esquema de escritura frente a esquema de lectura
El enfoque de esquema para la lectura permite que los lagos de datos almacenen muchos conjuntos de datos altamente heterogéneos. Los registros de ventas y las fuentes transaccionales de los dispositivos móviles se pueden almacenar junto con enormes conjuntos de datos extraídos de las redes sociales para el análisis de sentimientos.

Los lagos de datos superan los desafíos técnicos del uso de almacenes de datos para almacenar grandes conjuntos de datos. Además, eliminan la necesidad de un extenso modelado inicial, ya que con un almacén de datos típico, el esquema debe definirse cuando se cargan los datos.

Esto significa que los lagos de datos son ideales para casos de uso en los que inicialmente no está seguro de cómo desea analizar exactamente sus conjuntos de datos.

Por lo general, busca información comercial transformadora del lago de datos (nuevos segmentos de mercado, nuevas formas de involucrar a los clientes, etc.), en lugar de realizar diagnósticos sobre problemas de rendimiento (por ejemplo, determinar por qué los ingresos cayeron en el tercer trimestre).

Sin embargo, los lagos de datos son notoriamente difíciles de administrar y los analistas de negocios pueden carecer de las habilidades y herramientas para extraer información de ellos.

La línea de fondo: Los lagos de datos son ideales para las empresas que necesitan administrar grandes cantidades de datos, como los generados por el web scraping, las redes sociales y las interacciones de los clientes con la web y las aplicaciones móviles.

Además, los lagos de datos son lo suficientemente profundos para manejar conjuntos de datos a escala de terabytes y petabytes generados por implementaciones masivas de sensores en proyectos industriales o de Internet de las cosas centrados en el consumidor. Sin embargo, probablemente necesitará un científico de datos o al menos un analista altamente capacitado en su equipo para obtener información útil de ellos.

Una palabra de advertencia

Actualmente, los lagos de datos, así como los análisis en los lagos de datos, son compatibles principalmente con marcos de código abierto como apache hadoop y Colmena.

Hadoop es «gratuito», pero las iniciativas de Hadoop son notoriamente complejas y costosas para comenzar. Diseñar una solución desde cero requerirá importantes recursos técnicos y presupuestarios, y puede ser un fracaso costoso.

En su lugar, considere mirar las distribuciones empaquetadas de Hadoop de proveedores como Cloudera y hortonworksya que estos proveedores ofrecen aplicaciones empaquetadas y soporte.

Dennis Duckworth, director de marketing de productos de Volt DB (un sistema operativo de administración de bases de datos en memoria que analizaremos en la siguiente sección de este informe), observa:

“Tenemos muchos clientes en Cloudera, Hortonworks y MapR. Es cierto que Hadoop no reemplaza todos los almacenes de datos, pero muchas empresas están implementando lagos de datos como repositorios a largo plazo. para datos y sandboxes para que los científicos de datos jueguen.

Dennis Duckworth, director de marketing de productos de VoltDB

Algunos proveedores de sistemas de administración de bases de datos (DBMS) que tradicionalmente se especializan en almacenamiento de datos también ofrecen productos para crear y administrar lagos de datos, como Teradata.

Alternativa #2: HTAP/DBMS en memoria

La computación en memoria ofrece otra alternativa al almacén de datos al permitir la consolidación de bases de datos analíticas y transaccionales en una sola base de datos que puede soportar tanto el procesamiento de transacciones en línea (OLTP) como OLAP.

Esto se llama procesamiento transaccional analítico híbrido o HTAP. Se diferencia del almacenamiento de datos porque en esta estrategia las bases de datos OLTP alimentan la base de datos OLAP, mientras que con HTAP se elimina el paso de cargar datos en un almacén para el análisis histórico:

Relación entre OLAP, HTAP y OLTP

Uno de los principales desafíos para pasar a una verdadera solución HTAP es operar de manera confiable las bases de datos transaccionales en memoria (es decir, almacenar datos en RAM en lugar de escribirlos en el disco), pero las soluciones ya están llegando al mercado. Actualmente, sus mejores opciones son las bases de datos transaccionales o analíticas in-memory, como soluciones que completamente El soporte HTAP aún no ha aparecido.

VoltDB es un buen ejemplo de un DBMS que se está moviendo hacia el soporte HTAP. Peter Vescuso, director de marketing de VoltDB, describe la solución como una «base de datos operativa en memoria o base de datos OLTP».

VoltDB también se puede describir como una base de datos NewSQL, lo que significa que ha realizado cambios significativos en la arquitectura de la base de datos relacional tradicional para escalar con el rendimiento.

Si bien las soluciones de NewSQL son relacionales, Vescuso señala que distribuyen datos a través de múltiples nodos en un clúster de servidores, lo que permite a las organizaciones usar hardware básico de bajo costo en lugar de depender de computadoras individuales más grandes (y más costosas) que los RDBMS tradicionales solían escalar.

La arquitectura en memoria de VoltDB reduce significativamente la sobrecarga de procesamiento, dice Vescuso: «90-95% del trabajo con bases de datos tradicionales no tenía nada que ver con el procesamiento de datos y todo que ver con la estructura basada en disco».

Supervisión del rendimiento del servidor en VoltDB Management Center

Las soluciones OLTP en memoria como VoltDB ya admiten análisis sofisticados, pero tienden a ser en tiempo real e integrados en procesos automatizados, en lugar de los complejos análisis históricos realizados por analistas de negocios.

En otras palabras, la aplicación generalmente toma una decisión o recomendación en función de los análisis, en lugar de un ser humano. La arquitectura en memoria permite que esta decisión se tome lo más rápido posible para aplicaciones sensibles al tiempo.

Como explica Vescuso:

“Hay dos lados de los datos: big data, o datos históricos en reposo, y datos rápidos, o datos operativos en vivo antes de que se conviertan en big data. El análisis de datos de transmisión en vivo a menudo está destinado a las interacciones frontales con los consumidores, pero también se puede usar para interactuar con una aplicación orientada a la red para automatizar operaciones como la aplicación de políticas, crédito de detección de fraude de tarjetas de crédito, etc.

Peter Vescuso, director de marketing de VoltDB

Las aplicaciones móviles ofrecen numerosos casos de uso para este tipo de análisis. Vescuso da un ejemplo de interacción automatizada con una aplicación móvil a través de análisis en tiempo real:

«Podríamos ver a un cliente transmitiendo medios en su teléfono inteligente y el saldo de la cuenta cayendo rápidamente, presentarle al cliente una oferta, ver que el cliente ha aceptado la oferta y dejar que la transmisión continúe».

En última instancia, las soluciones HTAP admitirán análisis históricos y en tiempo real, lo que permitirá que los datos históricos y transaccionales residan en el mismo DBMS.

Sin embargo, Duckworth de VoltDB observa que el verdadero HTAP aún no es técnicamente factible: «Si observa soluciones HTAP como SAP Hana, siempre escuchamos que son mucho mejores en el lado OLAP que en el lado transaccional. Siempre tienen problemas y las soluciones son caras.

“Hay otras soluciones NewSQL que afirman ser HTAP”, dice, “pero lo que hemos encontrado al hablar con los clientes es que tienden a ser más fuertes de un lado o del otro. Hacemos PAH, pero somos más fuertes en el lado transaccional, porque creemos que es más difícil de hacer y más crítico hacerlo bien.

HTAP parece la forma más lógica de admitir operaciones y análisis con uso intensivo de datos. Por lo tanto, si desea obtener una ventaja inicial, puede considerar experimentar con bases de datos en memoria, especialmente para OLTP.

De hecho, Duckworth señala que el análisis en tiempo real proporcionado por soluciones como VoltDB puede complementar el análisis histórico: «Somos totalmente compatibles con SQL y admitimos la conectividad JDBC, por lo que las personas pueden escribir los informes y aprovechar los datos en una base de datos VoltDB, y a menudo lo hacen para mira y mira lo que está pasando allí.

La línea de fondo: HTAP no es una tecnología madura y debe tratar los reclamos de los proveedores para respaldarlo con cierto escepticismo. Sin embargo, al explorar la memoria, las soluciones NewSQL para OLTP pueden ayudar a su organización a desarrollar habilidades avanzadas con las nuevas arquitecturas DBMS y habilitar la funcionalidad HTAP limitada a corto plazo.

Por otro lado, incluso pasar a «HTAP-lite» requerirá una revisión radical de sus bases de datos operativas críticas y requerirá una aceptación considerable de las partes interesadas de toda la organización. Es posible que su negocio no esté listo para dar el paso en este momento.

Por lo general, también necesitará un caso de uso operativo para el análisis en tiempo real que es fundamental para las soluciones OLTP de NewSQL, por ejemplo, el análisis de red en tiempo real en apoyo de procesos automatizados, como la detección o el consumo de fraudes. frente a aplicaciones móviles y web que dependen de interacciones en tiempo real.

Alternativa n.º 3: análisis de estilo OLAP con herramientas de autoservicio

Las herramientas de BI de autoservicio utilizan una tecnología diferente a las herramientas OLAP tradicionales compatibles con los almacenes de datos. En particular, las herramientas de autoservicio utilizan cachés de datos de almacenamiento de columnas en lugar de cubos de datos OLAP.

Se accede a estos cachés de datos en la memoria en lugar de leerlos o escribirlos en el disco. Esto permite consultas mucho más rápidas que las que pueden admitir los almacenes de datos OLAP.

Las herramientas de autoservicio también están diseñadas para el análisis a través de una interfaz visual, eliminando los requisitos de conocimiento técnico por parte del usuario comercial y la necesidad de soporte de TI. Además, no requieren modelado de datos previo y se pueden usar con una multitud de tipos de fuentes de datos, incluidas fuentes de datos grandes.

El análisis de autoservicio ofrece el mismo tipo de interacciones multidimensionales con conjuntos de datos que originalmente requerían el uso de cubos OLAP, aunque los usuarios definen sus propias rutas de exploración en lugar de seguir las que se estructuraron en un cubo de datos durante el modelado de datos.

Uso de medidas y dimensiones para generar visualizaciones en SAP Lumina

La línea de fondo: Las herramientas de autoservicio son una excelente manera de ampliar las capacidades de análisis a los usuarios comerciales, eludir la rigidez de cubos de datos y permite a los usuarios empresariales explorar una amplia gama de conjuntos de datos. Sin embargo, no pueden servir como una «única fuente de verdad» altamente gobernada como un almacén de datos.

Considere los siguientes proveedores de BI de autoservicio:

Ver el perfil
Ver el perfil
Ver el perfil
Ver el perfil

Avanzar

Dos de las estrategias que hemos considerado aquí, lagos de datos y soluciones HTAP, requerirán un enfoque arquitectónico radicalmente nuevo para almacenar datos históricos. HTAP también requiere una revisión completa de cómo almacena los datos transaccionales.

Si aún no tiene un almacén de datos en su lugardeberías considerar:

  • La cantidad de datos que necesita almacenar
  • El grado en que sus datos están estructurados y comparten patrones comunes
  • Casos de uso para análisis en tiempo real en su organización
  • Fuentes de datos más allá de los datos transaccionales que desea analizar

Para organizaciones que almacenan principalmente datos transaccionales para análisis históricos, un almacén de datos todavía tiene sentido. Nuestro sitio ofrece reseñas, precios y demostraciones para proveedores que ofrecen Plataformas de BI de extremo a extremo que admiten almacenamiento de datos.

Si planea yuxtaponer datos transaccionales con conjuntos de big data o de escala webun lago de datos tendrá más sentido.

Si está manejando grandes cantidades de datos operativos continuos que deben procesarse a través de análisis en tiempo realluego, comenzar el viaje a HTAP a través de un DBMS OLTP en memoria puede proporcionar ventajas competitivas significativas tanto en términos de rendimiento como de nuevas formas de análisis.

Si aún no está seguro de si necesita un almacén de datos en primer lugarentonces considera soluciones de autoservicio enfocadas en la visualización de datos por el momento. Estas herramientas brindan casi toda la funcionalidad de las herramientas OLAP tradicionales compatibles con los almacenes de datos.

Deja un comentario

Tu dirección de correo electrónico no será publicada.