Resumiendo conceptos SAP HANA.

En un reciente webinar público, alguien de la competencia demostró que no entendía nada sobre SAP HANA y transmitió su limitado e inexacto conocimiento a analistas financieros y de la industria. En SAP no suelen responder este tipo de cosas; pero al ver cómo se desarrolló la escena que se había armado, nos pusimos a pensareeeee que: ¡debemos estar haciendo algo bien! Es decir, ¿es posible que uno de los líderes en el desarrollo de bases de datos desconozca en tal medida la próxima generación de tecnologías de bases de datos? ¿O acaso será que simplemente no está dispuesto a reconocer la realidad, y por eso recurre a diseminar información errónea?

El equipo HANA es un grupo apasionado por tres cosas en común: hacer que los clientes de HANA tengan éxito, divertirnos, y cuestionar el status quo. Con este propósito, de parte del equipo SAP HANA, me gustaría corregir la información inexacta de nuestra competencia, y de paso divertirme un poco.

La ventaja de SAP HANA

Quisiera empezar diciendo que (a) compararnos con enfoques tecnológicos del pasado no tiene sentido, (b) los clientes de HANA disfrutan de los excelentes beneficios de esta nueva tecnología sin cambios disruptivos, y (c) HANA representa una nueva generación de 'enterprise computing', particularmente en lo que concierne a bases de datos. Es una plataforma de datos moderna para aplicaciones y análisis de datos en tiempo real. Permite que una organización analice sus operaciones de negocios en base a una gran cantidad y variedad de datos detallados, en tiempo real, a medida que suceden, eliminando la latencia entre sistemas OLTP y OLAP para poder trabajar "realmente" en tiempo real. La ventaja de HANA reside en que es un sistema profundamente integrado con diferentes componentes que son completamente transaccionales y bien integrados al optimizador de sistema. Escalar vertical u horizontalmente es algo que funciona sin fricciones para todos los componentes, tales como OLTP, OLAP (tanto operacional como de warehouse), texto, planeamiento o puro desarrollo de aplicaciones. ¡Permite un deploy fácil, sin un zoo de servidores, ni replicación interna, ni vistas materializadas, ni un stack de motores!

En el análisis que comparto más abajo voy a tratar de ser preciso para comunicar todo esto, y voy a actualizar este blog periódicamente para brindar la verdad sobre SAP HANA continuamente. Aquí van algunas de las correcciones.

#1 Lo más importante del diseño futuro de bases de datos.

Incorrecto: "Los DBMS en memoria no remplazarán a muchos (o a todos) los DBMS relacionales".

Correcto: Los DBMS en memoria son una parte central del diseño futuro de bases de datos. Ya están remplazando grandes porciones del mercado de bases de datos, en particular las de analytics, planeamiento, simulaciones y aplicaciones en tiempo real (p. ej. el mercado de los juegos). Los nuevos DBMS en memoria se basan en investigación académica sólida y están diseñados para dar soporte a OLAP y OLTP. Ya son comunes en mercados donde la performance es clave, y van a transformar los mercados a nivel enterprise de la misma manera que el concepto de 'cloud' lo hizo con las aplicaciones transaccionales.

#2. El rol de la plataforma de base de datos.

Incorrecto: Una base de datos en memoria sólo puede hacer algunas cosas, tales como MOLAP, reportes operacionales, consultas y análisis, planeamiento y presupuesto, y descubrimiento de información no estructurada.

Correcto: SAP HANA es una plataforma de base de datos en memoria de propósito general, que puede obtener información reciente, capturar transacciones completamente ACID, analizarlas a medida que ocurren, hacer procesamiento en la base de datos (metiendo la lógica de negocios, de predicción y de planeamiento cada vez más en la base de datos), e incluso brindar a los clientes servicios como analytics o aplicaciones cloud y móviles. Se puede aplicar a los usos más comunes, mucho más allá de los casos de uso en los nichos enumerados para bases de datos en memoria. No hace falta agregar otras tecnologías y duplicar motores en un mismo servidor para distintos usos: p. ej. Endeca (texto), Essbase (planeamiento), TimesTen (caching, analytics).

#3. Escalar horizontalmente ante volúmenes crecientes de información. Soporte para NUMA.

Incorrecto: SAP HANA tiene soporte limitado para data marts y data warehouses, y no puede escalar horizontalmente.

Correcto: SAP HANA puede escalar horizontalmente a un número ilimitado de núcleos/nodos, y los precios del hardware siguen bajando. En nuestra conferencia SAPPHIRE NOW en mayo del año pasado, Hasso mostró 32 nodos / más de mil núcleos corriendo SAP HANA (a los 13,45 minutos de su presentación). A propósito, tenemos tres sistemas de más de mil núcleos corriendo en este momento en el mundo. Tenemos clientes activos de HANA con sistemas multi-nodo que escalan horizontalmente, y varios partners, incluidos IBM y HP, que ya están haciendo appliances capaces de escalar horizontalmente.

Además, nuestro benchmark reciente sobre 100TB en 16 nodos de servidores X5 de IBM, cada uno con medio TB de memoria, que procesan 100TB de información BW en 300-500ms para reportes operacionales y 800ms-2s para consultas analíticas ad-hoc. La información también se puede pasar a swap con mecanismos estándares de HANA, tales como un criterio de 'envejecimiento'. HANA tiene soporte para la arquitectura NUMA. Por el contrario, en la documentación pública se revela que Oracle Exalytics tiene un límite de 1 TB, y ya han dicho públicamente que una porción significativa de ese TB se usa en memoria de trabajo para todos los productos que juntaron (Essbase + Endeca + TimesTen).

#4: OLTP y OLAP.

Incorrecto: En SAP HANA hay una "limitada performance de escritura".

Correcto: SAP HANA es una base para OLTP+OLAP en una única pieza de hardware y un único sistema operativo; escala verticalmente y horizontalmente (desde una Mac Mini a más de mil núcleos distribuidos en varios nodos) y se ajusta dinámicamente según la carga de trabajo. Somos la única base de datos en memoria que hace inserts en una base de datos orientada a columnas con alta performance de escritura Y TAMBIÉN alta performance analítica. Ésta es la diferencia clave de SAP HANA.

#5: Almacenamiento: fila, columna y texto.

Incorrecto: SAP HANA no tiene "soporte para datos no estructurados" y no provee "compresión de filas y columnas".

Correcto: SAP HANA tiene almacenamiento orientado a filas, columnas y texto en una misma base de datos y tiene soporte nativo para información no estructurada. Además, todo está integrado, lo cual simplifica las operaciones transaccionales y analíticas en todas las formas de almacenamiento. De hecho, la base de SAP HANA fue originalmente la búsqueda no estructurada. Puede manejar búsquedas estándares y minería de texto tanto como búsquedas de texto en campos estructurados. Gracias a la tecnología Inxight, características lingüísticas tales como etiquetamiento, extracción de rasgos, extracción de entidades y análisis de sentimiento van a estar incluidas en SAP HANA. Inxight es el mejor software de análisis de texto en el mercado.

SAP HANA tiene soporte para compresión en almacenamiento orientado a columnas. La compresión fuerte no es un requerimiento para el almacenamiento orientado a filas, porque se lo usa únicamente como buffer para el orientado a columnas y para tablas donde la compresión es irrelevante. La ventaja de SAP HANA reside en una integración inteligente con el stack de aplicaciones, lo cual elimina la necesidad de compresión para el almacenamiento orientado a filas.

#6. Caching de información y optimización de consultas.

Incorrecto: SAP HANA y TimesTen hacen caching de información.

Correcto: La generación anterior de bases de datos usaba caching para mejorar la performance. HANA es una base de datos totalmente en memoria, basada en un nuevo paradigma de arquitectura. Dado que la base entera está en memoria, no hay cache de información en HANA. SAP HANA tiene un optimizador de primer nivel para consultas, que permite de manera nativa la ejecución de consultas de manera altamente paralela, incluso haciendo paralelismo inter- e intra-operador.

#7: Propiedades ACID e integridad transaccional.

Incorrecto: SAP HANA "no tiene verificación de la corrección/integridad transaccional, así como tampoco concurrencia multi-versión (MVCC)".

Correcto: SAP HANA cumple con ACID completamente, y usamos sistemas de almacenamiento permanente para backup y persistencia. Es totalmente MVCC con las capacidades estándares, tales como aislamiento a nivel de statement y de snapshot.

#8: Tablas agregadas y vistas materializadas.

Incorrecto: Hace falta tener vistas materializadas para tener alta performance con tablas agregadas.

Correcto: ¡Otro ja ja! Los autos eléctricos no necesitan bujías. Para datos detallados en memoria, calcular agregados en el momento tiene mucha mejor performance. Las tablas agregadas son una tecnología anticuada a esta altura, ya que se requiere mucho esfuerzo para crearlas, almacenarlas de manera redundante, y administrar sus cambios. SAP HANA no necesita índices para tener buena performance, como las bases tradicionales; la base entera en memoria, para todas las dimensiones del dataset, actúa de por sí como un índice.

#9: Clientes de Business Intelligence.

Incorrecto: SAP HANA brinda soporte limitado, para unos pocos clientes BI.

Correcto: SAP Business Objects está optimizado para correr en SAP HANA. Además de numerosos clientes de terceros que ya están disponibles (p. ej. Tableau, Tibco Spotfire), continuaremos siendo completamente abiertos a clientes BI de terceros para SAP HANA.

#10: Aplicaciones de planeamiento y funciones analíticas.

Incorrecto: SAP HANA tiene soporte limitado para aplicaciones de planeamiento y presupuesto.

Correcto: SAP HANA brinda un soporte completo para aplicaciones de planeamiento. Muchas aplicaciones de SAP Enterprise Performance Management corren sobre SAP HANA. SAP HANA tiene soporte nativo para planeamiento dentro de la base de datos, en el motor de planeamiento. Operadores como desagregación, copia y otros son parte del álgebra relacional dentro de SAP HANA. Además, tenemos soporte para el lenguaje de planeamiento FOX en SAP, dentro de la base de datos.

El planeamiento es un argumento muy importante a favor de SAP HANA, no a la inversa. SAP HANA no necesita las operaciones típicas de un cubo, porque podemos calcular en el momento. SAP HANA incluye en su biblioteca las principales funciones analíticas y de negocios, tales como funciones matemáticas, de conversión de monedas y unidades, de agregación excepcional, de análisis de series temporales, de manejo jerárquico y de predicción. Tiene además un amplio soporte para otras bibliotecas. Con SAP BW sobre HANA no tenemos capas; metemos los cálculos de planeamiento en HANA DB para obtener alta performance. SAP HANA tendrá soporte para toda aplicación transaccional, warehouse de negocios, o aplicación cloud y BI de SAP. También tenemos partners que están haciendo aplicaciones de planeamiento, desarrolladas nativamente en SAP HANA.

#11. Reporte operacional y fuentes de datos.

Incorrecto: SAP tiene capacidades limitadas para reportes operacionales debido a "fuentes de datos limitadas", porque copian tecnologías ETL.

Correcto: SAP tiene una solución extremadamente completa para reportes operacionales en tiempo real a partir de múltiples fuentes de datos (p. ej. SAP CO-PA Accelerator). Muchas de ellos son fuentes de datos de aplicaciones no SAP. SAP Data Services y SAP Sybase Replication Server son líderes de mercado en tecnologías ETL y de replicación, y traen datos de fuentes tanto SAP como no SAP. HANA tiene una velocidad extremadamente alta de insert para bulk inserts, debido a su alto paralelismo. Tiene soporte para todas las fuentes de datos y es un sistema que ha sido testeado con más de 2TB por hora de movimiento de datos hacia SAP HANA.

#12. Esquema de precios.

Incorrecto: "SAP HANA es entre 5 y 50 veces más caro que Exalytics." el hardware para 1 TB HANA cuesta $362K, y el software SAP HANA cuesta $3.75M

Correcto: Para 1 TB calculamos que el hardware cuesta $40-$60K (no $362K) y el software será mucho más barato que en el enunciado anterior. Además, SAP HANA está disponible a distintos precios para diferentes segmentos del mercado.

Las posibilidades van desde HANA Edge para pequeñas empresas, con precios adecuados (p. ej. $12K por un nodo hardware + $2K por HANA para SAP B1 Analytics sobre HANA), hasta escenarios con más de 100TB de memoria. Los clientes también pueden comprar SAP HANA para una aplicación (BW, BPC, CO-PA, Smart Meter Analytics, etc.) o para data marts y data warehousing. BW sobre HANA para un data warehouse de 40TB está a muy buen precio. Además, el esquema de precios HANA incluye todo lo que los clientes necesitan: testing, desarrollo, ambientes de QA y soporte. No hace falta comprar más software para cargar o mover información, acelerar el almacenamiento (p. ej. Exadata), etc. Si se toma en consideración todo esto, para una configuración de 512GB de uso, el costo total de SAP HANA es aproximadamente el 50% del costo de los productos de la competencia.

#13: Estándares y apertura.

Incorrecto: "HANA sólo funciona con las herramientas SAP, y tiene un SQL limitado o no estándar"

Correcto: Un porcentaje significativo de los clientes usa HANA para información no SAP. Hay casos de uso tanto para aplicaciones SAP como no SAP. Funciona con SQL y MDX estándares, y tiene interfaces estándares para cualquier aplicación. Es abierto en todas sus capas:

• Opción libre de proveedor de hardware, para traer al mercado innovaciones a nivel del chip antes que la competencia
• Opción libre de cliente BI
• Abierto a todas las aplicaciones y plataformas
• Hay cientos de aplicaciones personalizadas (no SAP) en desarrollo sobre SAP HANA

p. ej. las aplicaciones Oracle y Oracle BI corren sin cambios sobre SAP HANA. Los stored procedures existentes en Oracle se traducen a SQLscript por razones de propiedad intelectual, lo cual muestra la completa apertura de SAP HANA.

#14: SAP HANA en disco.

Incorrecto: SAP HANA no tiene soporte para información almacenada en disco.

Correcto: SAP HANA tiene soporte para información almacenada en disco a través de técnicas de asignación de prioridad tales como Least Recently Used (LRU). SAP HANA puede mantener la información relevante en memoria, y la información en disco se carga a pedido.

#15: Velocidad de consulta.

Incorrecto: SAP HANA no ejecuta consultas más rápidamente que otras bases de datos.

Correcto: SAP HANA mantiene toda la información en almacenamiento orientado a columnas, en formato entero, optimizado para aprovechar las más recientes innovaciones de Intel, tales como mejoras en CPU para operaciones con vectores. La arquitectura de avanzada de SAP HANA y sus innovaciones a nivel de chip hacen que su desempeño sea más rápido que el de las demás bases de datos del mercado. Por ejemplo, tenemos cuatro clientes que han superado mejoras de 100.000 veces en sus procesos de negocios con SAP HANA. El líder del grupo es MKI, que comprobó mejoras de 408.000 veces en el análisis de datos sobre ventas y logística.

#16: SAP HANA es más lento que Exadata y Exalytics.

Incorrecto: "SAP HANA no corre más rápidamente que Exadata, así que mucho menos va a mejorar a Exalytics".

Correcto: En un ejemplo en la infraestructura de un cliente, SAP HANA resultó ser 15.000 veces más rápido que Oracle Exadata en correr el proceso de verificación de crédito y límites de crédito sobre la misma información y la misma consulta. Compárese esta performance en tiempo real con la de una arquitectura basada en muchos servidores redundantes transaccionales, analíticos, con aceleración en memoria y procesamiento de texto, que ya tienen latencia inherente. Vemos esta misma experiencia en varios clientes, sólo mencionamos aquí un ejemplo.

El enfoque actual en el mercado.

El nuevo enfoque de SAP HANA.

#17: Instalación y experiencia en implementación.

Incorrecto: SAP HANA requiere de días para instalar y de meses o años para implementar.

Correcto: SAP HANA se instala en un datacenter en un tiempo que va de unos minutos a una hora. De hecho, pronto se podrá dar de alta en algún cloud de nuestros partners. Provimi entró en funcionamiento, haciendo análisis de rentabilidad, en tres semanas.

#18: Viaje en el tiempo.

Incorrecto: Es difícil para estas bases de datos hacer reportes basados en series temporales sin un overhead importante.

Correcto: Con SAP HANA se pueden recorrer los reportes en el tiempo (p. ej. para comparar predicciones de precios con los precios reales). También permite desplazarse a lo largo del eje temporal y ver cómo los reportes se construyen en el momento, sin necesidad de almacenarlos previamente en vistas o índices.

Resumen

Presenté los hechos y sólo pido que se entienda la verdad detrás de SAP HANA. La performance de SAP HANA es un cambio enorme y revolucionario en el mercado tradicional de bases de datos. Es una base única para OLTP+OLAP sobre una pieza de hardware y un sistema operativo, y corre en equipos que van desde una Mac Mini hasta un cluster de servidores con más de mil núcleos.

Aquí van las especificaciones técnicas de los atributos que realmente nos importan:

• Volúmenes de información con gran crecimiento (sí, SAP HANA escala a medida que crezcan, y funciona con almacenamiento basado en disco)
• Información multi-estructurada (sí, incluye texto e información de máquina)
• Análisis en tiempo real de información reciente (sí, tiempo real _real_)
• Alta velocidad de interacción (sí, a la velocidad del pensamiento humano)
• No requiere esfuerzo para tunear la base de datos (sí, es más simple y más barato)

Estas características brindan mejoras de performance de varios órdenes de magnitud. SAP HANA crea enormes ventajas competitivas y de negocios para compañías al revolucionar la manera en que éstas interactúan con sus clientes, así como su performance financiera y de cadena de suministros. Clientes como Nongfu Spring (mejora de 22k sobre Oracle DB) ya están abandonando Oracle.

También estamos explorando nuevas fronteras en el ámbito del cuidado de la salud, por ejemplo, revolucionando el análisis del genoma; acercamos el comercio y la operación bancaria en tiempo real a cientos de millones de usuarios en todo el mundo; y vemos más posibilidades en los grandes desafíos de nuestra época. Llegó la hora de que todos persigamos estos nuevos horizontes, y dejemos de pensar en el mundo en términos de mejoras incrementales sobre el pasado. Debemos pensar en el mundo como algo fascinante que todavía está por crear, basándonos en lo que creemos posible. La vida es demasiado corta como para que nos quedemos atrás por falta de información.