aníbal goicochea

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

Tradicional: Sólo para fines analíticos, no transaccionales.
SAP HANA: Es posible combinar tanto aplicaciones OLAP como OLTP.

Referencia: ISBN 978-1-78217-762-3

CPUs de un sistema SAP HANA a la máxima frecuencia

Puede suceder que después de reiniciar un sistema SAP HANA o realizar una actualización del sistema, se observe que los CPUs no estén trabajando a la máxima frecuencia disponible. Existe la posibilidad de monitorizar esta información a través de la vista M_HOST_INFORMATION la cual sólo se actualiza al iniciar el sistema.

Las diferencias entre las frecuencias del “CPU model” y el “CPU clock” se podrían deber a la parametrización del denominado “CPU governor”, parámetro a nivel del sistema operativo (SUSE Linux), que para el caso de un sistema SAP HANA, en el que se espera un sistema de alto rendimiento y un sistema de bases de datos con procesamiento paralelo, no debe tener asignado ningún valor equivalente a ahorro de energía (“ondemand” o similar), el valor recomendado es “performance”. En los enlaces de referencia se explica el procedimiento para ajustar este parámetro.

Referencia: SAP Note 1890444 y OpenSuse.org

Preguntas claves para valorar la utilidad de una visualización

Las representaciones gráficas que en ocasiones utilizamos, tales como los gráficos de columnas o el de líneas, se remontan al siglo dieciocho y no es hasta mediados del siglo pasado que estos se perfeccionan a través de la formalización de técnicas que se aplican a las actuales herramientas informáticas que se utilizan para crearlos.

Es innegable la importancia de transformar los datos en representaciones gráficas o visualizaciones, la alternativa más inmediata y fácil para comunicar y comprender los grandes volúmenes de información que nos pueden llegar a rodear. A partir de esta necesidad, han surgido una amplia gama de soluciones con posibilidades gráficas de dudosa utilidad para el análisis, pero de innegable impacto visual.

How is life - OECD URL

Una representación gráfica o visualización, que para comprenderla requiere una compleja explicación, va en contra los principios básicos de esta disciplina: claridad e inmediatez. Para saber si un gráfico será útil, plantéese las siguientes cuestiones:

¿Claramente indica la naturaleza de la relación de los valores representados?
¿Representa las cantidades con exactitud?
¿Facilita comparar las cantidades?
¿Es más fácil ver el orden o clasificación de los valores?
¿Resulta evidente cómo se debe utilizar la información?

Referencia: Interaction Design Foundation

Los “5 por qué” para minimizar los “fallos técnicos”

En el mundo informático nos podemos encontrar con incidencias de todo tipo, pero las que mayor frustración pueden causar son las que se catalogan como “fallo técnico”. Si al solicitar una explicación de la causa de un incidente recibimos como respuesta que se trata de un “problema técnico» o similar, pareciera que nos enfrentásemos a un “expediente X”, porque no hay explicación razonable, ninguna certeza que se solucionará y por consiguiente, no habrá garantías de que no volverá a ocurrir.

En el mundo informático nos podemos encontrar con incidencias de todo tipo, pero las que mayor frustración pueden causar son las que se catalogan como “fallo técnico”. Si al solicitar una explicación de la causa de un incidente recibimos como respuesta que se trata de un “problema técnico» o similar, pareciera que nos enfrentásemos a un “expediente X”, porque no hay explicación razonable, ninguna certeza que se solucionará y por consiguiente, no habrá garantías de que no volverá a ocurrir.

Inspirado en el sistema de producción Toyota, el autor de referencia, sugiere el uso de la técnica de los 5 por qué, para buscar la verdadera causa de los problemas que se originan en las organizaciones. Se trata de indagar de manera consecutiva, al menos cinco veces, la ocurrencia de la causa de un problema, para llegar a la causa u origen real del mismo, el cual casi siempre deriva en una carencia en la gestión de los procesos de negocio. Por ejemplo:

Problema técnico inicial: En el nuevo producto hay una característica que no funciona

¿Por qué? Porque ha fallado un servidor
¿Por qué ha fallado el servidor? Porque un subsistema se utilizó de forma inadecuada.
¿Por qué se utilizó de forma inadecuada? Porque el ingeniero responsable no sabía utilizarlo.
¿Por qué no sabía utilizarlo? Porque nunca lo formaron
¿Por qué nunca lo formaron? Porque su director no consideraba necesario enseñar a los nuevos ingenieros y porque él y todo el equipo estaban “demasiado ocupados”.

Referencia: El Método Lean Startup (Eric Ries)

Utilidad de las «funciones de proyección» de IDT (SAP BusinessObjects BI)

Cuando utilizamos Information Design Tool (IDT), componente de SAP BusinessObjects BI 4.*, para crear universos, y definimos objetos de tipo indicador (measure) debemos señalar la función de agregación a nivel de base de datos, pero adicionalmente, debemos seleccionar la función de proyección (Projection Function).

Cuando utilizamos Information Design Tool (IDT), componente de SAP BusinessObjects BI 4.*, para crear universos, y definimos objetos de tipo indicador (measure) debemos señalar la función de agregación a nivel de base de datos, pero adicionalmente, debemos seleccionar la función de proyección (Projection Function).

Podríamos señalar que la función de proyección es exclusiva para Web Intelligence. El resultado de una consulta WebI es almacenado localmente (local report cache), este almacenamiento temporal es conocido como microcubo y es utilizado para calcular los valores de los indicadores en los informes, según como se organicen los objetos en tablas y gráficos. Si en una tabla de un informe WebI, se utilizan menos dimensiones de los devueltos por la consulta, con la función de proyección, WebI sabrá calcularlos los valores de los indicadores.

Para universos con fuentes de datos relacionales se recomienda utilizar, como funciones de proyección, las siguientes: SUM, MIN, MAX, COUNT y AVG. Para universos multidimensionales se recomienda escoger la opción DELEGATED, a menos que se conozca, con exactitud, la función de agregación.