Estimado lector:
Sí, admito que el título puede hacer que a
uno se le levante una ceja, pero déjenme explicar por qué llegué a titular este
post así.
En el entorno SAP contamos desde hace ya
varios años con SAP HANA y su aplicación dentro del ámbito de data warehousing,
bien porque se utiliza SAP BW o en un futuro BW4HANA, o bien porque se utiliza
SAP HANA como motor de BBDD para un data warehouse estilo “free-hand SQL”.
Ambos mundos no son contradictorios ni se excluyen mutuamente, como ya comentaba
Thomas Zurek de SAP en este post de hace ya casi un año. BW4HANA implementará este concepto de
forma más integrada en los próximos años, aunque a día de hoy ya se puede
trabajar en esta dirección de una forma más desligada.
Lo que sí tienen en común ambos estilos de Data
warehousing con SAP HANA es el crecimiento de datos al que se puede enfrentar
una plataforma de In-Memory basada en SAP HANA. Esto es quizás algo
impredecible hoy en día, por tener que ampliar el horizonte temporal de los
datos gestionados o por la amplitud del tipo de datos que se quieren ofrecer a
los usuarios finales. Factores limitadores pueden ser el valor de la unidad de
memoria (bits/EUR), pero también otro factores como la robustez de la
integración, SLA’s, o las normativas y procesos de desarrollo que puedan
obstaculizar la integración en un EDW central como lo percibimos hasta ahora.
Desde un punto de vista simplificado, podemos
dividir los datos relevantes para una memoria corporativa en dos tipos: Por un
lado (tipo 1) están los datos generados por transacciones empresariales y gestionados
en sistemas OLTP, como por ejemplo ERP, SCM y CRM. Estos datos suelen ser
relativamente de buena calidad, consistentes y completos. De momento quiero
llamarlos “(well) managed enterprise data”. Este tipo de dato bien estructurado
tiene a menudo un valor decreciente con el tiempo desde el punto de vista
informativo y por lo tanto en su importancia y su frecuencia de acceso (“la
temperatura del dato baja” - Concepto de Hot/Warm/Cold data, conocido en SAP BW
desde 7.0). Es obvio, que nos interesa disponer de opciones para mover los
datos de tipo 1, ya más fríos, a un repositorio de datos probablemente más
lento, pero considerablemente más económico que nuestra valiosa infraestructura
in-Memory de la que disponemos.
Por otro lado (tipo 2) están los datos cuyo
origen puede estar en otras fuentes de datos como por ejemplo data streaming en
sentido de IoT (sensor data, machine data, fleet data) y que tienen los
siguientes aspectos en común:
1. No
se necesitan con una calidad del 100%
2. No
tienen que ser necesariamente consistentes desde un punto de vista
transaccional
3. Para
muchas consultas analíticas es suficiente mirar aspectos detallados con poco horizonte temporal (HOT para un muy corto plazo)
4. Tienen
un gran volumen de detalle
5. En
un primer momento se desconoce si los datos tienen valor desde el punto de
vista de negocio
Raras veces los datos de tipo 2 serían
candidatos para ser incorporados en un repositorio de datos estilo EDW, por el
consumo de recursos de memoria, esfuerzo de integración, continuidad de operación
y aumento de complejidad (especialmente si las fuentes son inestables). Es
preferible canalizar estos datos a otro lugar, en el cual se puedan tratar de
forma más sencilla, económica y ágil. Aquí entran en juego las posibilidades
que ofrecen los componentes de “Big Data”, enfocados a trabajar con grandes
volúmenes de datos en entornos de hardware económicos y robustos, y que a día
de hoy, permiten ser consultados y analizados de diferentes maneras incluso de
forma online.
De este modo resulta lógico pensar en una
arquitectura común para acceder y gestionar estos dos tipos de datos debajo de
un paraguas unificador. Unificador a nivel de datos o sus agregados (“early join”) pero también a nivel de usuario (“late join”), algo ya muy factible según mi
opinión. SAP ha dado los pasos necesarios para poder construir un “hyper” data
warehouse con estas características. El HANADW con o sin BW4HANA (incluyendo
S4HANA hasta cierto punto, pag.36) ofrece, gracias a la infraestructura de integración de SAP
HANA, la posibilidad de construir algo de esta magnitud y que abarca los dos
mundos, permitiendo gestionar la temperatura de los datos y la
interoperabilidad con “lagos de datos” no gestionados dentro de la instancia
central de un sistema basado en SAP HANA.
El componente de acceso a los datos juega un
papel muy importante ya que actúa como “Gate Keeper” principal de los datos,
incluyendo la posibilidad de hacer transparente su ubicación técnica y
homogenizando su acceso (“data access channeling”). SAP dispone para este
componente de una solución con SAP BO BI platform y las herramientas de BO para
los usuarios finales. Sin embargo, aun así todavía puede ser necesario la
utilización de herramientas especializadas, no integradas, para aprovechar
todas las posibilidades de análisis y procesamiento almacenado en nuestro
“Hyper” Data Warehouse*. Esta sería uno de los puntos a analizar.
De momento quedan por supuesto retos por
solucionar, tales como aspectos de seguridad, la heterogeneidad de la
tecnología empleada, la gestión del “conjunto/cluster” integrado y también como
integrar los expertos de ambos mundos en un solo equipo.
En los próximos posts iré describiendo
nuestros avances en este apasionante área para una arquitectura estratégica y de análisis unificado. También
explicaré con más detalle qué son los componentes más importantes en este
setup. So, please stay tuned.
* El autor se reserva el derecho de cambiar
este nombre en cualquier momento sin previo aviso.