My Blog

Thinking about the “Hyper” EDW*

No comments

Por Philipp Nell, Consultor en ConVista Spain

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.

Por Philipp Nell, Consultor en ConVista Spain

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.

La arquitectura se presentará así:

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.

ConVistaThinking about the “Hyper” EDW*

Related Posts

Deja un comentario

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