""
,

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.

It is worth mentioning that standard Dynamic Tiering or Near Line Storage (NLS) features offered by the SAP BW/4HANA product are only available when using SAP BW/4HANA as Data Warehouse. More info here: 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? 

  • Implementation and configuration of the Data Tiering processes. The data tiering processes must be setup to move the data from the SAP HANA to the selected Data Lake (based on a logic, such as the data tenure). Moreover, information stored in the Data Lake should be made accessible for consumption in the reporting layer. Thanks to Smart Data Access features this can be achieved in a transparent way from business user’s perspective

  • Performance on loading and consuming cold data stored in the Data Lake. Since the Data Lake data will not be held in-memory it will not be as fast as storing the data in SAP HANA. Therefore, the expected performance should be assessed by IT and the business users before implementing the scenario.

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 is a big data solution released by SAP and based on the Spark component. SAP Vora enables distributed high speed data manipulations and analytical queries. SAP Vora provides an advanced graphical user interface, the SAP HANA Vora tools for data modelling purposes. It is also integrated with Apache Zeppelin which enables a better visualization and control of the data within the data lake. SAP Vora also comes with Apache Spark, another of the most used big data frameworks which is considered more powerful than 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 options do have an additional licensing cost and are only available today with SAP IQ. The dynamic tiering option we therefore discarded for a large distributed big data lake scenario; albeit a very valid option in many cases.

  • Apache Hadoop is not the best option for reporting/analytical scenarios together with SAP HANA because of its performance. There are other big data / clustering solutions which are equally cost effective and offer much better performance. However, we recommend Apache Hadoop for cold data scenarios, where running analytical queries is not required.

  • SAP Vora is a promising solution in the SAP portfolio. We did find a few challenges during our assessment where the engine crashed with large CSV uploads. It still needs a few more releases to reach a solid level of maturity, but it promises to be a very powerful solution. In combination with SAP HANA it facilitates analytical reporting and offers modelling tools not present in any of the other solutions. We strongly believe that in the long term, when looking for SAP HANA based Data Lake options, it will be a very strong option given the integration with the SAP analytics product portfolio which is continuously improving. Further, sooner than later, SAP will offer solutions to automate the data tiering between SAP HANA and SAP Vora

  • Greenplum is a very solid and mature big data solution. It offers outstanding performance and is virtually able to manage any amount of data. However, it lacks the typical analytical modelling tools and data tiering processes that would allow a more integrated experience. While these must be manually implemented, we found that they work together very well and this combination is definitely a strong one to consider.

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