En este blog, me gustaría arrojar algo de luz sobre la dirección que SAP está tomando hacia una oferta unificada para construir un almacén de datos sobre HANA. El título de trabajo no oficial es el HANA DW. He dividido el blog en 3 secciones, cada una abordando las preguntas más urgentes que he recibido de los clientes que ya han visto algunas variantes de esto.

La visión para los almacenes de datos en HANA: el HANA DW

Como se describe en mi blog “Almacenes de datos en HANA: ¿Gestionados o libres? ¿BW o nativos?”, hay dos enfoques (preferencias) para construir un almacén de datos, no solo en HANA sino en general:

• Basado en SQL: Significa que los arquitectos de almacenes de datos utilizan SQL como el paradigma principal de construcción, lo que les da mucha libertad pero también conlleva el riesgo de que demasiada diversidad ponga en peligro el ciclo de vida del almacén de datos, ya que se vuelve cada vez más complejo gestionar las dependencias (por ejemplo, el impacto de los cambios) y la integración (por ejemplo, las mismas entidades, como productos, clientes, representadas de diferentes formas, utilizando diferentes tipos de datos, etc.).
• Gestionado a través de mejores prácticas: Aquí se utilizan bloques de construcción de alto valor (como flujos de datos, transformaciones, jerarquías, DSO de BW, solicitudes de datos de BW, pero también convenciones de nomenclatura) para construir y gestionar el almacén de datos. Este es un camino más rápido siempre y cuando los bloques de construcción satisfagan la necesidad. Se vuelve engorroso cuando hay un escenario que requiere desviarse del camino estándar ofrecido a través de los bloques de construcción.

En los últimos años, BW-on-HANA ha ofrecido el enfoque #2, que se ha extendido y combinado con el #1, el llamado escenario mixto. Un ejemplo tangible se describe aquí. Muchos clientes han adoptado este enfoque mixto; de hecho, se ha convertido en la corriente principal para BW-on-HANA. El HANA DW toma una dirección similar pero comienza con el #1 y se complementa con el #2, lo que al final produce el mismo resultado. Sigue la siguiente noción:

Comienza con una base de datos HANA desnuda que ofrece todas las capacidades de SQL que necesitas. Fundamentalmente, ahora puedes escribir tu código SQL en Notepad, Emacs, VI, etc., almacenar ese código SQL en archivos y ejecutarlos en HANA ya sea manualmente o a través de herramientas genéricas como cron. Ahora, escribir código SQL desde cero en un editor de texto es engorroso, incluso si hay algún tipo de resaltado de sintaxis o completado automático de sintaxis. La mayoría de las personas adquieren herramientas que les permiten modelar / diseñar / crear cosas gráficamente para generar las declaraciones SQL subyacentes. Cualquiera que sea el método que utilices para llegar a las declaraciones SQL, habrá necesidad de mantenerlas. Los escenarios se amplían o se ajustan. Esto se traduce en cambios a nivel de SQL. Para fines como auditoría o simplemente para tener la opción de volver a una configuración anterior, es una buena práctica rastrear la evolución (es decir, los cambios) y mantener las versiones de esos artefactos (SQL o de nivel superior). Esto no es más que en todo tipo de entornos de programación y se puede tomar infraestructura de allí, como GIT. Este último y los servicios relacionados con él se ofrecen (o se ofrecerán) en la plataforma HANA. Constituyen un repositorio. Hay dos tareas más que el repositorio debería admitir: gestionar las dependencias entre los objetos (por ejemplo, una transformación que utiliza ciertos procedimientos almacenados que, a su vez, utilizan ciertas tablas) y la gestión de versiones de esos artefactos (SQL o de nivel superior), por ejemplo, para permitir que se desarrollen y prueben en un sistema sin poner en peligro el sistema de producción. Finalmente, hay ciertos patrones recurrentes de SQL: cosas que necesitas hacer una y otra vez. Ejemplos son el seguimiento de datos entrantes (por ejemplo, a través de algo como la solicitud de datos en BW), cómo derivar cambios en los datos (como en un DSO), cómo almacenar jerarquías, etc. Tales “patrones” básicamente se traducen en artefactos de nivel superior (abstractos) que se crean y mantienen en el nivel de abstracción para luego traducirse en una serie de declaraciones SQL. El HANA DW admitirá este proceso de la siguiente manera; la figura 1 a continuación visualiza esto:

La base de datos HANA proporciona todas las funcionalidades de SQL que necesitas. La plataforma HANA proporcionará la infraestructura de desarrollo, especialmente para admitir un repositorio y servicios relacionados. Las herramientas superiores crearán artefactos directos de HANA SQL * o de nivel superior que se traducirán en HANA SQL *. Esas herramientas mantendrán sus artefactos en el repositorio de HANA, lo que permitirá admitir el ciclo de vida completo, incluida la auditoría, la versión y el análisis de dependencias (especialmente también entre artefactos mantenidos por diferentes herramientas). Las herramientas constituyen un valor añadido opcional que puedes utilizar pero que no tienes que utilizar. Considera BW-on-HANA como una de esas herramientas también. Se planea llevar los productos de SAP actualmente existentes relacionados con los almacenes de datos a esta configuración de HANA DW. Esto permitirá almacenes de datos basados en SQL (1.) enriquecidos a través de artefactos de nivel superior / de mayor propósito (2.). El segundo pilar en la figura 2 describe esa evolución. El tercer pilar indica que las herramientas evolucionarán, potencialmente en una serie de aplicaciones o servicios que también pueden gestionar un almacén de datos basado en la nube. Figura 1: La visión para el HANA DW. Figura 2: Evolución a corto, medio y largo plazo del HANA DW.

El papel de BW-on-HANA

A partir de lo anterior, debería haber quedado claro que BW-on-HANA formará una parte importante, pero opcional, del HANA DW. Si es conveniente para el propósito del almacén de datos, entonces debería ser utilizado o agregado a un HANA DW. Otro escenario potencial es que un BW-on-HANA existente evolucione gradualmente hacia un HANA DW a medida que se complemente con otras herramientas de la forma descrita anteriormente. La línea divisoria será difusa. En cualquier caso, BW-on-HANA ampliará y mejorará su funcionalidad existente, permitiendo cada vez más acceso directo a SQL + opciones y aprovechando / interactuando con el repositorio de HANA. Un sistema BW-on-HANA independiente, tal como existe hoy, se puede considerar como una instancia especial de un HANA DW. Seguirá existiendo, evolucionando, destacando. Cualquier persona que invierta en BW-on-HANA hoy está en un camino seguro.

El papel de HANA Vora y Hadoop: el HANA Big DW

Muchos clientes están buscando formas de complementar los almacenes de datos existentes con Hadoop. HANA Vora desempeñará un papel fundamental en la combinación de las plataformas HANA y Hadoop. Por lo tanto, HANA Vora permitirá ampliar el HANA DW a un HANA Big DW (título de trabajo actual). Ampliaremos sobre eso en una etapa posterior.

* Por favor, considera HANA SQL aquí como un marcador de posición que comprende todo tipo de lenguajes y extensiones más especializados como MDX, SQLscript, expresiones del motor de cálculo, etc. Puedes seguirme en Twitter a través de @tfxz.