SAP amplía sus estrategias alrededor de HANA

Durante gran parte de los últimos cuatro años SAP concentró sus esfuerzos en la creación de su plataforma in-memory, HANA. Mientras avanzaba en dirección a mejores prestaciones analíticas, tiempo real y OLTP para sus aplicaciones, se mostró algo rezagada en lo que respecta a Big Data.

Y Big data es una tendencia estructural que necesariamente debe ser atendida por una empresa como SAP, que maneja enormes masas de datos en las grandes empresas del planeta.

Sin embargo, en los últimos meses varias acciones de SAP mostraron que está comenzando a poner las cosas en orden. La compañía anunció que la tecnología Smart Data Access de consulta de datos federada y adquirida con la compra de Sybase por parte de SAP, se extenderá desde Sybase a la plataforma HANA. Por otra parte, concretó acuerdos OEM con dos importantes proveedores de las plataformas Hadoop, Hortonworks e Intel.

En lo que hace a la tecnología Smart Data Access de Sybase, recién estamos frente al primer release para HANA y Hadoop. Si bien el concepto de consulta federada es trabajado por otros proveedores, su extensión a HANA muestra a una SAP más activa en lo que hace a estrategias de administración de datos.

HANA y su misión

Hasta hace poco tiempo, el papel de HANA parecía ser el de una plataforma capaz de facilitar la performance de aplicaciones analíticas y de procesamiento de transacciones. Este posicionamiento no es equivocado ya que el poner la mira en función de plataforma analítica y de OLTP (Online Transaction Processing) responde a la gran demanda existente. Las empresas necesitan que sus aplicaciones tengan más procesamiento en tiempo real y también poder atender a necesidades puntuales que requieren esas capacidades.

Como al hablar de HANA estamos hablando de una plataforma in-memory, conviene que nos detengamos en este punto: no todas las aplicaciones necesitan tener todos sus datos en memoria todo el tiempo. De hecho, se trata de pocas aplicaciones y funciones. Los casos de uso que vemos en las empresas nos muestran que sigue siendo conveniente tener un almacenamiento estratificado o “tiered.” Las opciones disponibles, que van desde los discos convencionales a los SSD (Solid State Drives) y a las memorias DRAM, permiten realizar una arquitectura de almacenamiento de datos muy flexible. HANA ganó factibilidad con el descenso de los precios de la memoria DRAM, pero esa forma de almacenamiento todavía tiene un sobreprecio o costo adicional importante si se las compara con SSD, por ejemplo. Numerosos observadores y analistas del mercado ven como adecuada una estrategia que incluya a los diversos medios de almacenamiento como DRAM, SSD Flash, Discos o Librerías de Cintas y los aplique según el grado de utilización de los datos que alojan.

Si bien HANA es una plataforma que desde su primer versión ha tenido la capacidad de almacenar los datos “fríos” o menos utilizados en discos, la comunicación comercial de SAP no lo recalcó demasiado. Ahora, con la integración de Smart Data Access, la utilidad de consulta federada que desarrolló Sybase, SAP entra en una estrategia de tiering de datos para HANA.

Smart Data Access permite que los datos residentes en sistemas remotos aparezcan como tablas virtuales en HANA. La carga de procesamiento, mientras tanto, es puesta sobre los sistemas donde se originan esos datos. Al presente, Smart Data Access soporta a Sybase IQ, la base de datos analítica columnar, a Sybase ASE, a Teradata y a las últimas versiones de Hadoop que incluyen a Hive 0.12, la versión de alta performance de Hortonworks en su proyecto Stinger. Respecto al futuro, en SAP se habla de planes para soportar sistemas fuente como los de Oracle o Microsoft SQL Server.

Existen otros proveedores que dan soporte al acceso federado a datos. Por ejemplo tenemos a Teradata, que tiene un enfoque similar en sus plataformas de almacenamiento relacional de datos. La diferencia que SAP tiene a su favor, sin embargo, es que puede alcanzar datos de Hadoop sin tener que migrarlo físicamente a un entorno SQL. Recordemos que la utilización de Business Intelligence sobre Hadoop, por ejemplo, requiere de conexión que principalmente pasa por integración SQL-Hadoop y va desde la necesidad de ejecutar procesos en lotes o batch, a la realización de consultas interactivas sobre los metadatos de Hive (con o sin procesamiento en HIve). También tenemos a la extracción, transformación y carga (ETL) desde Hadoop a warehouses de datos SQL; a la extracción de datos Hadoop a SQL en forma de una tabla externa y a la integración física de tablas SQL en HDFS (Hadoop Distributed File System) o HBase.

Smart Data Access no es una solución con todo lo que puede llegar a necesitarse. No soporta instancias de HANA cuando se opera en clusters, por ejemplo. Tampoco tiene soporte directo al manejo de tipos de datos que se encuentran en grandes objetos BLOB/CLOB que pueden encontrarse en Hadoop. Esto limita a Smart Data Access al manejo de datos que pueden encontrarse utilizando Hive, mientras que los datos más crudos, generalmente almacenados en grandes bloques en HDFS, están fuera de su alcance. Aquí SAP tiene la oportunidad de extender su potencia de query o consulta federada de datos.

Estrategias con Hadoop

A diferencia de competidores como Oracle, Microsoft y Teradata, que han elegido a un solo partner OEM para la plataforma Hadoop, SAP ha optado por tener a más de un socio. Hortonworks es su partner OEM en lo que hace a la plataforma Apache open source de Hadoop y por otro lado tiene a Intel. Intel, como lo informamos hace un año, es un proveedor que ha implementado Hadoop para la alta performance. Su distribución de esta plataforma open source gana potencia basándose en las instrucciones nativas que se han incorporado en el chipset de su procesador Xeon en cuanto a pre-procesamiento de datos en caché. También dispone de instrucciones especiales para operaciones de computación intensiva tales como encriptado y procesamiento gráfico. Cuando Intel dio a conocer esta plataforma, mostró una performance extraordinaria funcionando sobre almacenamiento SSD Flash.

Hortonworks e Intel tienen diferentes grados de madurez en el manejo de Hadoop. Diríamos que el primero de ellos tiene cierta ventaja en cuanto a experiencia y capacidad de implementación.

Pero además de estos acuerdos, SAP tiene certificaciones para Cloudera y MapR, situación que lo asemeja a Teradata, que también tiene una importante relación con Cloudera.

La elección de dos proveedores por parte de SAP posiblemente responda a una estrategia de sondeo. EMC Greenplum, hoy Pivotal, hizo lo propio con sus primeras estrategias para MapR (Map Reduce) en cuanto a Hadoop de alta performance. Finalmente se volcó a SQL-on-Hadoop Pivotal HD.

En el caso de SAP, posiblemente Intel tenga alguna ventaja debido a que ha ajustado a sus procesadores Xeon para que optimicen la plataforma HANA. Por el momento, en SAP manifestaron que no existen planes para avanzar en una mayor itnegración de HANA con la plataforma Hadoop de Intel. Recordemos que la plataforma Hadoop de Intel ha sido desarrollada con una opción de alta performance que incluye drives SSD Flash e interconexiones Ethernet de alta velocidad 10GbE.

La consultora británica Ovum, en cuyo informe se basa este artículo, entiende que las plataformas Hadoop basadas en discos componen la corriente central del mercado. Desarrollos con frameworks open source como Spark (para el manejo de datos intensivos a memoria DRAM y Shark, que opera Hive sobre Spark, componen interesantes oportunidades para que SAP pueda ofrecer una plataforma convergente Hadoop/HANA, capaz de integrar con facilidad a SAP Business Suite sobre HANA con analíticos Big Data.

Este es el extracto del artículo acerca del informe escrito por Tony Baer, de la consultora Ovum.