, , , , , , , , ,

Clariba Big Data Series - Testeamos SAP HANA con varios Big Data Lakes. Nuestras conclusiones

, , , , , , , , ,

¿Tiene su empresa ya grandes cantidades de datos almacenados? ¿Quizás decenas o cientos de terabytes? ¿Utiliza SAP HANA para sus datos de explotación, pero quisiera poder combinarlos con sus repositorios de big data para extraer conocimiento? Veamos a continuación algunas de las opciones que tiene a su disposición. 

Necesidad empresarial de combinación de Big Data Lakes con SAP HANA


El volumen de datos de negocio crece continuamente, y los departamentos de IT se ven obligados a adoptar estrategias para gestionar este crecimiento, tratando de evitar disparar los costes de licencias de almacenamiento en memoria. El purgado de datos a menudo es una mala idea, ya que se pierden fuentes de información que aún pueden aportar valor a la actividad.

Este problema aparece recurrentemente en nuestras conversaciones con nuestros clientes de SAP HANA, y se ha convertido en una prioridad.
Mientras el volumen de datos y las necesidades de tiempo real van en aumento, paralelamente los datos históricos se van “comiendo” la capacidad disponible de memoria. En estas circunstancias, nuestros clientes con SAP HANA requieren que les ofrezcamos soluciones eficientes en coste que les permitan descargar parte de sus datos históricos en opciones menos costosas, manteniendo simultáneamente un acceso único a SAP HANA, de forma que el uso de varios repositorios resulte transparente para el usuario final.

En este artículo exploramos distintas opciones para extender SAP HANA con un repositorio big data (en otras palabras: un data lake) que permita tanto a usuarios finales como a data scientists consumir información combinando datos de SAP HANA y del data lake desde la misma interfaz de usuario de forma transparente y con un rendimiento aceptable.

Tratamos de asegurar que los datos críticos para el negocio (hot data) se encuentran siempre disponibles en memoria, mientras que los datos de acceso esporádico (cold data) son alojados en el data lake. Gracias a las capacidades de SAP HANA, ambos tipos de dato pueden ser combinados y entregados al usuario de forma transparente.

Definiciones de “Hot” y “Warm Data”

En Gestión de la Información Empresarial (EIM), podemos clasificar los datos en función del concepto de “temperatura”. Esta forma metafórica de clasificación categoriza los datos según su frecuencia de uso, de manera que hot data, los datos calientes, serán los datos de acceso más frecuente, mientras que los datos de acceso esporádico se etiquetan como cold data o “datos fríos”.

Basándonos en esta categorización de los datos, la información puede ser almacenada aplicando diferentes estrategias, buscando siempre el equilibrio entre coste y rendimiento 

Picture1.png

SAP HANA en una configuración multi-temperatura

SAP HANA es actualmente la mejor plataforma de base de datos para datos de alta frecuencia de uso o hot data. Ofrece la peculiaridad añadida de almacenar los datos y ejecutar las operaciones en memoria, lo que representa una velocidad de respuesta hasta 1000 veces superior que en tecnologías tradicionales. Sin embargo, el almacenamiento masivo de datos en SAP HANA puede convertirse en extremadamente costoso, especialmente cuando la mayor parte de los datos son de acceso esporádico. Es en estos casos cuando la opción de integrar un data lake conjuntamente con SAP HANA cobra todo el sentido.

SAP HANA ofrece distintas funciones para habilitar una configuración de almacenamiento basada en la temperatura:

Almacenamiento dinámico por niveles o Dynamic Tiering

Es una función estándar, que aprovecha una opción de almacenamiento por niveles personalizable, entre SAP HANA y un número limitado de opciones complementarias de almacenamiento, como SAP IQ, otro producto SAP que ofrece una base de datos relacional por columnas con un buen rendimiento, sin las costosas exigencias de hardware de SAP HANA (aunque sin agrupación en clúster), o la conocida Apache Hadoop. El almacenamiento dinámico por niveles mueve los datos entre SAP HANA y el repositorio elegido según su frecuencia de uso. 

Para casos en los que no es posible utilizar Dynamic Tiering debido al uso de otras tecnologías de data lake, siempre se pueden implementar soluciones de almacenamiento por niveles mediante el uso de procesos ETL que muevan los datos hacia arriba o hacia abajo según una lógica predefinida. Estos procesos ETL pueden implementarse con SAP Data Services o bien con el módulo Smart Data Integration de SAP HANA.
 

Acceso a datos inteligente o Smart Data Access

Esta funcionalidad permite la definición de fuentes externas de datos como tablas virtuales dentro de SAP HANA, de modo que pueden ejecutarse consultas en SAP HANA Calculation Views, e internamente SAP HANA extrae los datos tanto de su propio repositorio como de otra ubicación configurada previamente. Puede accederse a estas ubicaciones extrnas de datos mediante interfaces estándar ODBC o JDBC.

Es importante remarcar que las funciones de Dynamic Tiering y Near Line Storage (NLS) que ofrece SAP BW/4HANA sólo están disponibles cuando se utiliza SAP BW/4HANA como Data Warehouse. Más información en el siguiente enlace:  https://help.sap.com/doc/PRODUCTION/24b2b055b00143c5bb552edff7cc57c4/1.0.2/en-US/SAP_BW4HANA_en.pdf


El siguiente esquema nos muestra una simulación del ahorro potencial que puede suponer el uso de un data lake con SAP HANA. Partimos del ejemplo en que tenemos una instancia SAP HANA de 10TB y queremos reducir el uso de memoria de SAP HANA moviendo los datos fríos, de menor frecuencia de acceso, a un data lake
 

Picture2.png

Acceso transparente del usuario

Como hemos indicado, resulta crítico que los usuarios de negocio no se vean perjudicados por la implementación de este escenario. Asumiendo que partimos de una instalación existente SAP BusinessObjects BI Platform, veamos a continuación un ejemplo de cómo la información tanto de SAP HANA como del Data Lake sería consumida por las aplicaciones analíticas y de reporting:

 

Picture3.png

Potenciales retos

¿Cuáles son los principales retos para la implementación de un escenario SAP HANA + Data Lake con almacenamiento por niveles manual? 

  • Implementación y configuración de los procesos de almacenamiento por niveles. Los procesos de almacenamiento por niveles deben ser configurados para mover los datos de SAP HANA al data lake seleccionado (basados en una lógica, como el poseedor del dato). Asimismo, la información almacenada en el Data Lake, debe ser puesta a disposición del consumo por parte de la capa de reporting. Gracias a las funcionalidades Smart Data Access esto se puede conseguir de una manera transparente desde la perspectiva del usuario.
  • Rendimiento en la carga y consumo de datos fríos almacenados en el Data Lake. Como los datos del Data Lake no residen en la memoria, su almacenamiento no sera tan rápido como el que se realiza en SAP HANA. En consecuencia, el rendimiento esperado debe ser evaluado por el equipo de IT con los usuarios de negocio antes de la implementación.

Selección de escenarios Data Lake

Para una comparación inicial, en Clariba realizamos un proyecto interno con una muestra relativamente relevante de 80 millones de filas. Estas son las opciones evaluadas:

 

  • Sólo SAP HANA
  • SAP HANA con Dynamic Tiering
  • SAP HANA con VORA
  • SAP HANA con Hadoop
  • SAP HANA con Greenplum
  • SAP HANA con SAP IQ

 

Evaluándolas desde una perspectiva de costes, utilizar sólo SAP HANA resulta costoso, especialmente cuando no todos los datos se consideran “calientes” y vitales para su uso en la organización con disponibilidad en tiempo real. No tiene sentido por tanto evaluar en nuestro análisis el escenario puro SAP HANA, ya que claramente resultaría ganador desde un punto de vista de puro rendimiento.

Para nuestro análisis, nos centraremos por tanto en el resto de combinaciones con Data Lake. Para la selección de opciones, hemos tenido en consideración los siguientes factores:

  • Capacidad para tratar con cientos de Terabytes
  • Escalabilidad vertical y horizontal
  • Configuración distribuida para el almacenamiento de información
  • Facilidad de despliegue tanto en local como en configuración cloud (ej: AWS)

Teniendo en cuenta estas premisas, nos hemos centrado en los siguientes escenarios:

Picture5.png

SAP HANA + Hadoop data lake

Apache Hadoop es una de las soluciones big data más usadas y conocidas, basada en un entorno de software de código abierto que se ejecutan en agrupaciones de computadoras construidas con componentes de gran consumo. Apache Hadoop no es un sistema relacional RDBMS (Relational Database System); se basa en un componente de almacenamiento, el Hadoop Distributed File System (HDFS), y un sistema de procesado, el modelo de programación MapReduce. Apache Hadoop resulta ideal para el almacenamiento de datos no estructurados, pero no es la major opción para datos estructurados. Para poder utilizar Hadoop para almacenar datos estructurados con origen en HANA, necesitamos utilizar uno de los componentes de Hadoop, HBase, un componente que habilita una interfaz ACID/SQL sobre el Hadoop Distributed File System. Con el uso de Hadoop como Data Lake ganamos escalabilidad, flexibilidad y disponibilidad. Sin embargo, podemos experimentar tiempos de respuesta muy lentos.

Picture6.jpg

SAP HANA + Greenplum data lake

Greenplum es una base de datos relacional basada en PostgreSQL. Gracias a sus capacidades de agrupación (clustering) y de Procesado Masivo en Paralelo, sus implementaciones pueden crecer hasta una escala de petabyte entregando un buen rendimiento en consultas analíticas. 

HanaVora.png

SAP HANA + SAP Vora data lake

SAP Vora es una solución de big data ofrecida por SAP y basada en el componente Spark. SAP Vora permite manipulaciones de datos distribuidas y consultas analíticas de alta velocidad. SAP Vora proporciona una interfaz de usuario avanzada: SAP HANA Vora tolos, para el modelado de datos. Está integrada asimismo con Apache Zeppelin, que proporciona una mejor visualización y control de los datos en el data lake. SAP Vora viene además con Apache Spark, otro de los frameworks de big data más utilizados, considerado aún más potente que Apache Hadoop.

SAP-IQ-Sybase.jpeg

SAP HANA + SAP IQ

SAP IQ ofrece una base de datos en columnas, como SAP HANA, sin requerir un hardware tan potente. Aprovecha además las capacidades de Dynamic Tiering, que automatiza la mayoría de procesos de almacenamiento por niveles. Requiere el pago de licencias, en contraste con las soluciones mencionadas anteriormente. Aunque sea quizás una de las mejores opciones par implementar un Data Lake con SAP HANA, SAP IQ no es una solución distribuída ni ofrece las posibilidades de clustering disponibles en otras opciones ccomo SAP Vora, Greenplum o Apache Hadoop. Por este motive, no consideraremos esta opción para nuestro análisis.
 

Comparación de los diferentes escenarios Data Lake

Veamos en la tabla siguiente un detalle del análisis realizado por Clariba:

Table.PNG

Cuál es el rendimiento alcanzado?

Tras implementar los diferentes escenarios, integramos los diferentes Data Lakes en SAP HANA y habilitamos el consumo de datos desde las vistas de cálculo SAP HANA. Utilizamos un conjunto de datos de 80 millones de filas para evaluar el rendimiento en grandes conjuntos de datos, y cómo estos son extraídos por SAP HANA (SDA). Finalmente, medimos el rendimiento de algunas consultas, con los siguientes resultados:

Picture8.png

Claramente, el rendimiento de Apache Hadoop resulta pobre cuando se usa para propósitos de analítica y reporting. Tanto SAP Vora como Greenplum se muestran como opciones válidas para el almacenamiento de grandes cantidades de datos para la analítica en conjunción con SAP HANA, pues muestran un rendimiento aceptable.

Resumen y conclusiones

Si usted es un cliente SAP con un data warehouse SAP HANA en memoria, tiene varis opciones a considerar para avanzar hacia un escenario de big data. LA selección de la tecnología adecuada dependerá de los casos de uso que pretenda cubrir. Aunque descartemos desde un punto de vista puro de costs las opciones de una instalación pura SAP HANA, así como complementda con SAP IQ, estas opciones deberán ser incluídas en el proceso de selección, para asegurarse de que todos los escenarios son comparados adecuadamente. Algunos puntos finales a destacar serían:

  • Almacenamiento dinámico por niveles o Dynamic Tiering tendrá siempre un coste adicional de licencias, y estará disponible solo en casos con SAP IQ. LA descartaríamos entonces en escenarios con grandes data lakes distribuídos., aunque será una opción muy válida para el resto de casos.
  • Apache Hadoop no es la mejor opción para su uso en escenarios conjuntos con SAP HANA con propósitos de reporting y analítica, debido a su pobre rendimiento. Hay varias otras opciones con capacidades de clustering igualmente eficientes en costes y que ofrecen un rendimiento muy superior. Recomendaríamos Apache Hadoop para escenarios de “datos fríos” en los que no es necesario ejecutar consultas analíticas.
  • SAP Vora resulta una solución prometedora dentro del portfolio SAP. Nos encontramos con algunos retos durante nuestra evaluación, en los que el motor fallaba durante largas ingestiones de ficheros CSV. Necesita aún algunas versiones para alcanzar un nivel sólido de madurez, pero promete convertirse en una potente solución de futuro. Usado en combinación con SAP HANA facilita el reporting analítico y ofrece herramientas de modelado ausentes en el resto de soluciones. Creemos firmemente que a medio plazo se convertirá en una clara alternativa debido a su fuerte integración con el resto de productos del portfolio, que está en constante mejora. Además, es muy probable que en un futuro próximo SAP ofrezca soluciones para automatizar el almacenamiento por niveles entre SAP HANA y SAP Vora.
  • Greenplum es una solución de big data muy sólida y madura. Ofrece un rendimiento excepcional y es capaz de manejar virtualmente cualquier volumen de datos. Carece sin embargo de las habituales herramientas de modelado de datos y almacenamiento por niveles que permitirían una experiencia más integrada. Aunque estas funcionalidades deban ser implementadas manualmente, pensamos que en combinación con SAP HANA, ambas soluciones trabajan perfectamente, y esta combinación es definitivamente una de las más válidas a considerar.

Como corolario final, para clientes SAP HANA que deseen implementar escenarios big data, hay varias opciones disponibles. Dependiendo del caso de uso, recomendamos analizar las necesidades exactas, ya sean la mejor combinación entre rendimiento y coste, el flujo de datos ente fuentes, el almacenamiento de grandes volúmenes a bajo coste, o una combinación de todas, para decidir en consecuencia la mejor opción disponible. 

Permanezcan atentos a los futuros posts de la serie Clariba Big Data!

Referencias
 

EspañolEnglish