HANA – Página 10 – aníbal goicochea

SAP HANA Tailored Data Center Integration (SAP HANA TDI)

SAP HANA TDI (SAP HANA Tailored Data Center Integration) es la tercera vía para desplegar una plataforma SAP HANA, las otras alternativas son a través de un appliance certificado y la opción Cloud. El principal cuestionamiento que se le ha señalado a SAP HANA, desde sus inicios, es el costo elevado que puede llegar a alcanzar un appliance y la poca flexibilidad en la elección de la configuración de hardware que se debe utilizar (aquí listas de partners de hardware SAP HANA).

SAP HANA TDI (SAP HANA Tailored Data Center Integration) es la tercera vía para desplegar una plataforma SAP HANA, las otras alternativas son a través de un appliance certificado y la opción Cloud. El principal cuestionamiento que se le ha señalado a SAP HANA, desde sus inicios, es el costo elevado que puede llegar a alcanzar un appliance y la poca flexibilidad en la elección de la configuración de hardware que se debe utilizar (aquí listas de partners de hardware SAP HANA).

SAP HANA TDI es el concepto introducido por SAP a mediados del pasado año, el cual se base en la ampliación de las posibilidades de elección del hardware y configuración que se podría utilizar en una plataforma HANA. La mayor flexibilidad y seguro que menor coste, son los principales beneficios de esta nueva opción con respecto a un appliance, el cual tiene como ventajas el software pre-instalado y el hardware configurado.

Con respecto a un Appliance, SAP HANA TDI ofrece mayor facilidad para la ampliación del espacio de almacenamiento (denominado “Enterprise Storage” en la variante TDI). Para verificar que una plataforma SAP HANA TDI cumple las especificaciones de configuración HANA, se cuenta con una herramienta denominada SAP HANA hardware configuration check tool. SAP actualiza constantemente el listado de hardware compatible para SAP HANA (aquí).

SAP HANA Tailored DataCenter Integration es una alternativa que irá madurando en los próximos meses, y a la que auguramos un buen futuro. SAP HANA TDI, al brindar la posibilidad de utilizar las inversiones actuales de hardware que podría tener una organización, la convertirá en el principal mecanismo para que SAP HANA sea adoptada por más empresas, algunas veces, poco partidarias de realizar inversiones en hardware específicos que establece un fabricante de software, más propio de décadas pasadas.

Referencia: (aquí y aquí)

Información para virtualizar SAP HANA con VMware

Desde la actualización SPS05 un sistema SAP HANA puede ser virtualizado con VMware VSphere 5.1 (o versiones superiores) con la finalidad de facilitar la implementación de una política de entornos (p.e.: desarrollo, pruebas y producción). SAP HANA on VMware vSphere, no implica la asquisición de una licencia adicional, sólo es necesario contar con las versiones adecuadas de ambos sistemas, el cual sólo puede ser configurado, por el momento, sobre un appliance SAP HANA.

Desde la actualización SPS05 un sistema SAP HANA puede ser virtualizado con VMware VSphere 5.1 (o versiones superiores) con la finalidad de facilitar la implementación de una política de entornos (p.e.: desarrollo, pruebas y producción). SAP HANA on VMware vSphere, no implica la asquisición de una licencia adicional, sólo es necesario contar con las versiones adecuadas de ambos sistemas, el cual sólo puede ser configurado, por el momento, sobre un appliance SAP HANA.

Las diferencias de rendimiento entre un sistema HANA sobre un hardware certificado (“bare metal”) y un sistema virtualizado, dependiendo de los tipos de procesos que se ejecuten, pueden ser muy importantes, por lo que se establece que un entorno virtualizado debería tener cualquier uso, menos los propios de un entorno de Producción.

Adicionalmente, destacamos los siguientes aspectos:

Un entorno virtualizado SAP HANA sólo puede ser de un único nodo, por lo que configuraciones “scale out” o “multi-nodo” no son soportadas.
En cuanto a la configuración de CPU y memoria debe ser de acuerdo a las medidas estándar definidas para un appliance HANA (t-shirt sizing).
El soporte a los entorno virtualizados HANA puede ser brindando tanto por SAP como por VMware, según el tipo de incidencia, siempre y cuando no se trata de un entorno de Producción.
Absolutamente todas las aplicaciones que funcionan sobre un appliance SAP HANA funcionarán sobre un sistema virtual SAP HANA.
El modo de realizar las tareas de diseño o modelado de datos será exactamente igual en ambos tipos de instalación.
Estas características, posibilidades o limitaciones pueden variar en el tiempo por lo que se recomienda consultar la nota SAP de referencia.

Referencia: SAP Note 1788665

«Code pushdown» clave en el rendimineto SAP HANA

Los grandes beneficios de SAP HANA se encuentran en el procesamiento de grandes volúmenes de información, no tan sólo por tener los datos en memoria (además del almacenamiento físico en disco), sino también por la aplicación de técnicas, que en su conjunto, constituyen un nuevo paradigma en el concepto de base de datos.

Los grandes beneficios de SAP HANA se encuentran en el procesamiento de grandes volúmenes de información, no tan sólo por tener los datos en memoria (además del almacenamiento físico en disco), sino también por la aplicación de técnicas, que en su conjunto, constituyen un nuevo paradigma en el concepto de base de datos.

Uno de los cambios planteados por HANA es el procesamiento de datos en la capa de base de datos (code pushdown). Los sistemas tradicionales se basan en el principio denominado Data-to-code, el cual ejecuta todo el procesamiento de datos en la capa de aplicación, generando un tráfico de datos elevado que ocasiona bajos niveles de rendimiento e incremento de los tiempos de latencia o espera hasta ver los resultados.

Una aplicación diseñada o adaptada para una plataforma SAP HANA utiliza el principio Code-to-Data, el cual procesa los datos en la capa de base de datos, quedando la capa de aplicación sólo para controlar el flujo del procesamiento y tratar los datos procesados (Orchestration logic).

Reglas de oro para diseñadores SAP HANA

En SAP SCN encontramos un post que será muy útil para todos aquellos que estén comenzando a diseñar modelos de datos o a desarrollar aplicaciones en una plataforma SAP HANA. Por el momento se señalan seis “reglas de oro” que seguro se podrán ir ampliando en la medida que SAP HANA siga evolucionando al ritmo que lleva, presentando grandes cambios en cada actualización.

En SAP SCN encontramos un post que será muy útil para todos aquellos que estén comenzando a diseñar modelos de datos o a desarrollar aplicaciones en una plataforma SAP HANA. Por el momento se señalan seis “reglas de oro” que seguro se podrán ir ampliando en la medida que SAP HANA siga evolucionando al ritmo que lleva, presentando grandes cambios en cada actualización.

Nunca utilices tablas con almacenamiento basado en filas. SAP HANA está preparado para trabajar con los dos tipos de almacenamiento de tablas (basado en filas y en columnas), el sistema ya cuenta con mecanismos necesarios para optimizar la grabación de datos en tablas con almacenamiento columnar. Una de las claves de éxito de HANA es el almacenamiento en columnas, son muy pocos los casos en que se recomienda las tablas con almacenamiento en filas, especialmente la tablas de parámetros o configuración.
No crear índices. El almacenamiento columnar, equivale a tener un índice por cada columna, por lo que crear índices secundarios, tal como se estila hacer en un sistema de base de datos relacional tradicional, no ayuda a reducir los tiempos de acceso a los datos. Sólo podría ser útil en el caso de tener una tabla muy grande sobre la que se realiza una selección muy pequeña de un conjunto de datos.
Utilizar la Perspectiva Development de SAP HANA Studio. SAP HANA Studio es la herramienta que facilita todas las tareas de administración y desarrollo en la plataforma HANA. Las capacidades que ofrece SAP HANA Studio están divididas en Perspectivas (véase como paneles o ventanas), dependiendo de las necesidades y autorizaciones disponibles se podrán habilitar las perspectivas. Para los desarrolladores se ofrecen varias perspectivas entre ellas System, Modeler y Debug, se sugiere el uso de la perspectiva Development, debidamente configurada se puede contar con todos los recursos necesarios en una única perspectiva.
No utilizar SQLScript, a menos que sea necesario. SAP HANA ofrece una implementación SQL, la cual se denomina SQLScript, este lenguaje puede ser muy útil en determinadas circunstancias, pero en muchos casos lo que se realice con este lenguaje se podría hacer con vistas de información (de atributos, analíticas y de cálculos) las cuales son más eficientes dado que SQLScript no paraleliza la ejecución de procesos (hasta la reciente actualización SPS07 este es el comportamiento de SQLScript, quizás más adelante se ofrezca una actualización que mejore este comportamiento).
Si utiliza SQLScript, no utilice cursores o SQL dinámico. El uso de estas sentencias ocasiona pérdida de rendimiento, especialmente el uso de SQL dinámico para referirse a nombres de columnas en sentencias INSERT o SELECT, hay otras alternativas disponibles, como las vistas de información (para los SELECTs) o el uso del lenguaje Python (para cargar datos).
Evitar Joins en grandes volúmenes de datos. Unir tablas con más de cien mil filas resultará ineficiente, en su lugar se sugiere normalizar vía el uso de vistas analíticas, para luego unir vía una vista calculada.

Referencia: SAP SCN

SAP HANA versus cualquier otra propuesta de Data Warehouse tradicional

TTeniendo presente que SAP HANA no debe ser valorado sólo como una base de datos, sino como una plataforma por todas las posibilidades que nos ofrece, compartimos esta comparativa entre SAP HANA visto solamente como un repositorio de datos contra cualquier otra propuesta de Data Warehouse de enfoque tradicional:

Teniendo presente que SAP HANA no debe ser valorado sólo como una base de datos, sino como una plataforma por todas las posibilidades que nos ofrece, compartimos esta comparativa entre SAP HANA visto solamente como un repositorio de datos contra cualquier otra propuesta de Data Warehouse de enfoque tradicional:

Volumen de datos

Enfoque tradicional: Almacenamiento basado en filas. Compresión en disco. Duplicación de datos a través del uso de agregados, almacenamiento en caché y uso elevado de índices.
Enfoque SAP HANA: Almacenamiento basado en columnas. Compresión en memoria. Uso intensivo de la memoria para mantener los datos que se requieren.

Latencia de información

Tradicional: ETL a través de procesos en lote que podría requerir generación de agregados (o técnicas similares) que en conjunto generaría retrasos en la disponibilidad de la información.
SAP HANA: Dirigido a través de servidor de replicación y al no requerirse agregados, se logra mejor rendimiento y considerables menores tiempos.

Velocidad de cálculo

Tradicional: Dirigido a través de almacenamiento de datos en filas y el caché en memoria.
SAP HANA: Guiado a través del almacenamiento basado en columnas y el conjunto de datos en memoria. Los cálculos se realizan en memoria, en la capa de base de datos en lugar de la capa de aplicación (enfoque tradicional).

Flexibilidad y robustez

Tradicional: Soluciones basada en disco proveen limitada flexibilidad para cambios en los modelos de datos o ajustes en las jerarquías de datos, los cuales derivan en cambios en agregados, cachés y otros elementos.
SAP HANA: Permite realizar los cambio en cualquier momento y no están limitados por la persistencia en disco.

Data governance

Tradicional: Duplicación de versiones de datos implica costosas o laboriosas actividades de conciliación.
SAP HANA: Es la auténtica “versión única de la verdad”

Aplicaciones