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:
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).
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.
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.
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.
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:
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».
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.
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
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.