PAPER: SAP HANA DATABASE – An Architecture Overview

HECTOR JOHN MESA GARCIA

UNIVERSIDAD CATÓLICA DE ORIENTE

FACULTAD DE INGENIERIAS

INGENIERÍA DE SISTEMAS

03-10-2018
 2

Tabla de Contenido

Pág

1. Introducción ........................................................................................................................3

2. Objetivos……………………………………………………………………………....…..4

3. Desarrollo……………………….………………………………………………….……...5

4. Conclusiones……………………………………………………………………….…….15

5. Bibliografía………………………………………………………………………………19
 3

1. Introducción

El estudio de la ingeniería de sistemas y su enfoque principal es dar soluciones de alta calidad, lo

ideal es que las soluciones sean orientadas a problemas que impacten a una gran población en

general.

En la formación como ingenieros de sistemas y su posterior desarrollo como profesional obliga a

que el estudiante y profesional desarrolle un alto grado investigativo con el fin de aportar

soluciones innovadoras.

El presente Paper fue realizado para la “Conferencia Internacional sobre Ingeniería de datos”

En la actualidad las organizaciones se han vuelto más exigentes con relación a las aplicaciones

empresariales, requieren que los cálculos de los informes de datos transacciones se realicen en

menos tiempo o al mismo tiempo que muchos usuarios transaccionales puedan trabajar.

El objetivo de la base de datos Hana es la integración de la capa de trabajo Transaccional y

analítica dentro de un mismo sistema, esto es manejado por la computación en memoria.

Para lograr esto, un motor de columna explota el hardware moderno (núcleos de CPU múltiple,

gran capacidad de memoria principal, y cachés), la compresión de los contenidos de base de

datos, el máximo de paralelismo en el núcleo de la base de datos, y las extensiones de bases de

datos requeridas para las aplicaciones empresariales, por ejemplo, estructuras de datos

especializadas para jerarquías. En el presente trabajo se destacan los conceptos arquitectónicos

empleados en la base de datos de SAP HANA para poder operar en computación en memoria.
 4

2. Objetivo

2.1 Objetivo General

Adquirir los conocimientos y habilidades de investigación para aportar soluciones

innovadoras que impacten a la población en general aplicando los conocimientos

adquiridos en la ingeniería de software.

2.2 Objetivo Específico del Paper

El objetivo de este documento es comprender la arquitectura de la Base de datos de SAP

Hana habilitada para trabajar en computación en memoria.

 5

3. Desarrollo

Una visión integral de datos de la empresa se ha convertido en un activo fundamental

para todas las organizaciones. Los datos se introducen en lotes o por registro a través de

múltiples canales, tales como los sistemas de planificación de recursos empresariales (por

ejemplo, ERP SAP), sensores utilizados en entornos de producción, o interfaces basados

en web. Por ejemplo, en un proceso de venta, los pedidos se crean, se modifican y se

eliminan. Estas órdenes son la base para la planificación de la producción y la entrega.

Por lo tanto, durante el proceso de venta los registros se encuentran insertados y

actualizados. Este tipo de procesamiento de datos normalmente se conoce como

procesamiento de transacciones en línea (OLTP). OLTP ha sido la fortaleza de los

sistemas basados en disco y la base de datos por filas actuales.

Tras una inspección más de cerca, un proceso de ventas supuestamente sencillo exhibe

una cantidad significativa de procesamiento analítico complejo. Por ejemplo, comprobar

la disponibilidad de un producto para su entrega como parte de un proceso de ventas

requiere la agregación de las ventas esperadas, entrega prevista, y la terminación de los

lotes de producción, así como comparar el inventario resultante con la demanda de los

clientes. Del mismo modo, una organización de ventas estaría interesado en medidas

financieras y rentabilidad, esto para la planificación sobre la base de la mayoría de las

ventas recientes y la información de costos. Este tipo de carga de trabajo se considera

procesamiento analítico en línea (OLAP). tareas periódicas, tales como el cierre final del

trimestre o la segmentación de clientes, se ejecutan mediante la replicación de datos en un

almacén de datos optimizado de lectura.

 6

Además, las aplicaciones analíticas requieren lógica de procedimiento, que no puede ser

expresado con SQL normal, por ejemplo, el número de ventas de agrupamiento de los

diferentes productos o clasificar el comportamiento del cliente. El enfoque natural es

transferir todos los datos necesarios de la base de datos de la aplicación y procesarlo allí.

Por lo tanto, los datos optimizado las estructuras y los metadatos no pueden ser utilizados

y los resultados intermedios tienen que ser transferidos de nuevo a la base de datos si son

necesarios en los siguientes pasos del proceso de negocio.

Idealmente, una base de datos deberá ser capaz de procesar todas las cargas de trabajo

mencionadas anteriormente y la lógica de aplicación específica en un solo sistema

(H.Plattner).

Esta observación provocó el desarrollo de la base de datos de SAP HANA (SAP HANA

DB). Históricamente, el almacenamiento de columna en memoria de la SAP HANA DB

se basa en el motor de texto SAP TREX (Sanders) y la BI Accelerator SAP (SAP BIA) ,

que permite el procesamiento rápido de consultas OLAP. El alto rendimiento de fila-

almacén en memoria de la SAP HANA DB se deriva de P * Tiempo (Song)y

especialmente diseñado para hacer frente a la carga de trabajo OLTP. La persistencia de

la SAP HANA DB originó a partir de la tecnología probada del sistema de base de datos

de SAP MaxDB que proporciona el registro, la recuperación y el almacenamiento

duradero. A partir de hoy, el SAP HANA DB está disponible comercialmente como parte

del aparato de SAP HANA.

En la siguiente sección, se da una breve descripción acerca de los componentes

arquitectónicos de la SAP HANA DB. La sección 3.1 discute la capacidad de ejecutar la

 7

lógica de aplicación específica analítica. En la sección 3.2 se describe la forma del SAP

HANA DB acelera las cargas de trabajo tradicionales de almacenamiento de datos. Se

discute cómo abordamos los desafíos en las cargas de trabajo transaccionales en los

sistemas de planificación de recursos empresariales en la sección 3.3 y un resumen de

nuestro trabajo en el SAP HANA DB en la sección 3.4

3.1 SAP HANA DBA ARQUITECTURA

El objetivo general del SAP HANA DB es proporcionar una plataforma de gestión de

datos centrada en la memoria principal para apoyar SQL puro para aplicaciones
tradicionales, así como un modelo de interacción más expresivo especializada a las
necesidades de las aplicaciones de SAP (SAP, s.f.). Por otra parte, el sistema está
diseñado para proporcionar un comportamiento transaccional completo con el fin de dar
soporte a aplicaciones de negocios interactivos. Por último, el SAP HANADB está
diseñado con especial énfasis en la paralelización que van desde hilo y nivel básico hasta
configuraciones altamente distribuidos a través de múltiples máquinas.

La Figura 1 proporciona una visión general de la SAP en general la arquitectura HANA

DB.
 8

El corazón de la SAP HANA DB consiste en un conjunto de motores de procesamiento

en memoria. Los datos relacionales residen en las tablas de la columna o el diseño fila en
el motor de la columna y la fila combinado, y puede ser convertida de una disposición a
la otra para permitir que las expresiones de consulta con mesas en ambos diseños, datos
de gráficos y datos de texto residen en el motor gráfico y el motor de texto
respectivamente; más motores son posibles debido a la arquitectura extensible (SAP, s.f.).
Todos los motores mantienen todos los datos en la memoria principal, siempre y cuando
haya suficiente espacio disponible. Como uno de los principales rasgos distintivos, todas
las estructuras de datos están optimizados para la eficiencia de la caché en lugar de estar
optimizada para la organización de disco tradicional por
bloques. Además, los motores de comprimir los datos usando una variedad de esquemas
de compresión.
Cuando se alcanza el límite de la memoria principal disponible, los objetos de datos
enteros, por ejemplo, mesas o particiones, se descargan de la memoria principal bajo
control de la aplicación semántica y vuelve a cargar en la memoria principal cuando se
requiere de nuevo.
Desde una perspectiva de la aplicación, el SAP HANA DB proporciona múltiples
interfaces, tales como SQL estándar para funcionalidad genérica de gestión de datos o los
idiomas más especializados como SQLScript (véase la sección 3.2) y MDX. consultas
SQL se traducen en un plan de ejecución por el generador, que luego se optimiza y
ejecutado por el motor de ejecución. Las consultas de otras interfaces son eventualmente
transformados en el mismo tipo de plan de ejecución y ejecutados en el mismo motor,
pero primero descritos por un abstracto de datos más expresivo de flujo modelo en el
motor de cálculo. Independientemente de la interfaz externa, el motor de ejecución puede
utilizar todos los motores de procesamiento y se ocupa de la distribución de la ejecución
durante varios nodos.
Al igual que en los sistemas de bases de datos tradicionales, el SAP HANA DB tiene
componentes para gestionar la ejecución de consultas. El gestor de sesiones controla las
conexiones individuales entre la capa de base de datos y la capa de aplicación, mientras
que el gestor de autorización gobierna los permisos del usuario. El administrador de
 9

transacciones implementa el aislamiento de instantánea o los niveles de aislamiento más

débiles incluso en un entorno distribuido. El gestor de metadatos es un repositorio de
datos que describen las tablas y otras estructuras de datos, y, como el administrador de
transacciones, se compone de una parte global en caso de distribución local.
Aunque prácticamente todos los datos se mantienen en la memoria principal por los
motores de procesamiento por motivos de rendimiento, los datos también tienen que ser
almacenado por la capa de persistencia para backup y recuperación en caso de un reinicio
del sistema después de un cierre explícito o un fracaso. Las actualizaciones se registran
como necesario para la recuperación al último estado comprometido de la base de datos y
objetos de datos enteras se conservan en el almacenamiento de datos de forma periódica.

3.2 SOPORTE PARA APLICACIONES ANALITICAS

Una ventaja clave de la SAP HANA DB es su capacidad para ejecutar negocios y lógica
de la aplicación en el interior del núcleo de la base de datos. Para ello, el motor de cálculo
proporciona una abstracción de los planes de ejecución lógicos, llamados modelos de
cálculo.
Por ejemplo SQLScript, un lenguaje declarativo y optimizable para expresar la lógica de
aplicación como datos de flujos o usando la lógica de procedimiento, se compila en
modelos de cálculo. Siguiendo esta ruta, múltiples idiomas de dominio específico pueden
ser apoyados tan alto como un compilador genera la representación intermedia modelo de
cálculo.
Las primitivas de un modelo de cálculo constituyen un plan de ejecución lógica que
consiste en un conjunto de datos acíclicos la gráfica con nodos que representan los
operadores (operaciones plan) y bordes reflejando los datos de flujo (datos de plan). Una
clase de operadores implementa los operadores relacionales estándar como unirse y
selección.
Además, el SAP HANA DB es compatible con una gran variedad de operadores
particulares de aplicación de los componentes de aplicaciones específicas en el núcleo de
la base de datos. Casi todos estos operadores sólo son capaces de acelerar el
 10

procesamiento de datos, ya que se aprovechan de la disposición de los datos en columnas.

Mediante la implementación de los operadores especiales en el motor de cálculo, varios
dominios de aplicación pueden ser soportados.
Los algoritmos estadísticos pueden estar unido a modelos de cálculo para realizar
cálculos estadísticos complejos minimizando un tiempo de ejecución R asociado. Esto
incluye diferentes métodos estadísticos, como los modelos lineales y no lineales, pruebas
estadísticas, análisis de series de tiempo, clasificación, y la agrupación. Al mismo tiempo,
el modelo de cálculo permite aprovechar las capacidades de pre y post-proceso de datos
de gran tamaño en el núcleo base de datos y de este modo se entretejen los algoritmos
estadísticos con operaciones de base de datos (SAP, s.f.)
Planificación proporciona un conjunto de funciones de planificación genéricos
comúnmente utilizados y que permiten modelar y ejecutar escenarios complejos de
planificación directamente en la base de datos. la lógica de planificación se expresa
utilizando los datos de flujo de los operadores del motor de cálculo. Además, los
operadores especiales realizar la planificación de algoritmos ficas tales como
desagregación y personalizados fórmulas.
Otros operadores especiales proporcionado dentro del motor de cálculo incluyen la lógica
de negocio que requiere como peraciones complejas que son difíciles de implementar
eficiente el uso de SQL, por ejemplo, la conversión de moneda. Otro ejemplo son las
grandes jerarquías que describen, por ejemplo, las relaciones entre los empleados y la
información asociada en la gestión del capital humano de una empresa. Aquí, el SAP
HANA DB proporciona a los operadores de aplicaciones específicas para devolver
resultados de la consulta en estas jerarquías de forma casi instantánea que explotan las
estructuras internas de datos alternativos.
Un modelo específico cálculo fisico ejecución lógica plan de una vez sometido a SAP
HANA DB (por ejemplo, mediante el uso de SQLScript): se puede acceder de la misma
manera como una vista de base de datos, haciendo que el modelo de cálculo una especie
de vista parametrizada. Una consulta el consumo de una visión tan invoca la ejecución
del plan de la base de datos para procesar un plan de ejecución. Este plan se deriva de los
datos lógicos FL Descripción ow proporcionadas por el modelo de cálculo. Si el modelo
de cálculo contiene datos independientes fl ujo de caminos, el plan de ejecución derivada
 11

contiene implícitamente la ejecución en paralelo entre operadores. Esta es explorado por

SQLScript y los lenguajes C fi dominio especí compilado en modelos de cálculo.

3.3 PROCESAMIENTO DE CONSULTAS ANALITICAS:

Como generalmente acordados, columna-tiendas están bien adaptados para consultas

analíticas en cantidades masivas de datos [1]. Para un alto rendimiento de lectura

columna a guardar el de SAP HANA DB utiliza esquemas de compresión e fi ciente en

combinación con algoritmos de caché-conscientes y paralelas. Cada columna se

comprime con la ayuda de un diccionario ordenada, es decir, cada valor se asigna a un

valor entero (la valueID). Estos valueIDs son más bit-embalado y comprimido. Al

recurrir las filas de una tabla, la compresión más beneficioso (por ejemplo, la

codificación de longitud (RLE), codificación escasa, o clúster de codificación) para las

columnas de esta tabla se puede utilizar [11, 12]. La compresión de datos no sólo permite

mantener más datos en un solo nodo, sino que también permite un procesamiento más

rápido de consulta, por ejemplo, mediante la explotación del RLE para calcular los

agregados.

Ya que las actualizaciones individuales son caros en la disposición descrita, cada mesa

tiene un almacenamiento de Delta, que está diseñado para equilibrar entre las altas tasas

de actualización y buen rendimiento de lectura. Diccionario de compresión se utiliza aquí

también, pero el diccionario se almacena en una memoria caché Sensible árbol B +

(MMS + -Árbol). El almacenamiento delta se fusionó periódicamente en el

almacenamiento de datos principal. Para reducir al mínimo el período de tiempo donde

 12

las mesas están bloqueadas, las operaciones de escritura son redirigidos a un nuevo

almacenamiento delta cuando el proceso de fusión delta comienza. Hasta que esté

terminado, lea las operaciones de acceso nuevo y viejo de almacenamiento delta, así

como la antigua memoria principal [9].

ejecución de la consulta explota el creciente número de hilos de ejecución disponibles

dentro de un nodo mediante el uso de intraoperador paralelismo. Por ejemplo, las

operaciones de agrupación escala casi linealmente con el número de hilos hasta que se

saturó la CPU. Además, el SAP HANA DB también explota el paralelismo dentro de un

plan de ejecución de la consulta y en muchos núcleos y nodos. tablas de gran tamaño se

pueden dividir en función de criterios de partición. Estas piezas o tablas completas

pueden entonces ser asignados a diferentes nodos en el paisaje [10]. Los operadores

horarios motor de ejecución en paralelo si se pueden procesar de forma independiente y,

si ellos posible-ejecuta en el nodo que contiene los datos. En caso de cambio de carga de

trabajo, el esquema de particiones y la asignación de tablas de nodos se pueden adaptar,

mientras que la base de datos está disponible para consultas y actualizaciones.

3.4 PROCESAMIENTO DE CONSULTAS TRANSACCIONAL:

Si bien es claro que la columna-tiendas funcionan bien para las cargas de trabajo OLAP,

también sostienen que hay varias razones para considerar la columna-almacén para las

cargas de trabajo OLTP, especialmente en sistemas ERP (SAP, s.f.):

1.) escenarios OLTP pueden en gran medida se benefician de los esquemas de

compresión disponibles en la columna de Tiendas-: En un sistema altamente

 13

personalizable como SAP ERP, no se utilizan muchas columnas, y por lo tanto sólo

contienen valores por defecto o no hay valores en absoluto. Del mismo modo, algunas

columnas suelen tener un pequeño dominio, por ejemplo, la eficiencia del estado AGS.

En ambos casos, la compresión es muy eficiente, lo cual puede ser una ventaja decisiva

para OLTP escenarios: Al reducir el consumo de memoria, el tamaño necesario se hace

más pequeño, por lo que se requiere número pequeños nodos. Además, la compresión

también conduce a una menor utilización de ancho de banda de memoria.

2) las cargas de trabajo transaccionales del mundo real tienen grandes porciones de las

operaciones de lectura que los puntos de referencia estándar como TPC-C lo define. Por

lo tanto, la disposición de almacenamiento orientado columna optimizada-lectura puede

ser más apropiado para cargas de trabajo OLTP que el sugerido por los puntos de

referencia.

3) Columna-tiendas por lo general siguen el esquema simple “solo-agregar”: Cuando se

actualiza una fila existente, la versión actual es invalidada y una nueva versión se añade.

Este esquema es más simple que las actualizaciones en-sitio, ya que no requiere ni

reordenamiento codificación de los valores.

4) Columna-tiendas reducen en gran medida la necesidad de índices: Como cuestión de

hecho, el alto rendimiento de exploración de la columna-tiendas en el hardware moderno

nos permite tener índices única para las claves principales, columnas con restricciones

únicas y columnas de combinación frecuentes. En todos los demás casos, el rendimiento

del análisis es lo suficientemente bueno, sin índices, especialmente en pequeñas mesas o

pequeñas particiones de hasta unos cientos de miles filas. Las ventajas son un diseño de

base de datos física significativamente simple, menor consumo de memoria principal, y el

 14

esfuerzo eliminado en el mantenimiento de índices, que a su vez la velocidad hasta el

rendimiento general de la consulta.

Además de estas ventajas intrínsecas de la columna-tiendas para OLTP, hay varios retos

que hemos descubierto en este contexto. Un desafío surge directamente de la disposición

de los datos de la columna. A pesar de que permite una definición de patrón de acceso de

datos más de grano fino, que puede resultar en una sobrecarga de rendimiento

significativo para asignar la memoria por columnas para manejar un gran número de

columnas, por ejemplo en la construcción de una sola fila de resultado que consta de 100

columnas o más. A partir de ahora, el SAP HANA DB combina las asignaciones de

memoria para múltiples columnas en una sola, cada vez que ayuda a reducir la sobrecarga

de rendimiento.

Como un reto importante, vemos que en las aplicaciones ERP, un número considerable de

cambios se realiza simultáneamente. En contraste con los almacenes de datos, donde las

actualizaciones se ejecutan en lotes, las actualizaciones frecuentes de los registros

individuales se suman constantemente nuevas entidades en el almacenamiento de Delta,

lo que implica fusiones frecuentes desde el delta en el almacenamiento de datos principal.

Como la operación de fusión es una operación intensiva de CPU y la memoria, el reto es

reducir al mínimo su impacto en las peticiones que se procesan simultáneamente. El SAP

HANA se enfrenta a este problema mediante la planificación cuidadosa y la

paralelización ([10] T. Legler)

 15

3.5 CONCLUSIONES DEL PAPER

En este documento se resumen los principios que guían el diseño y la implementación del

SAP HANA DB. Nuestro análisis muestra que en la memoria de procesamiento

utilizando un motor de columna es el enfoque más prometedor para hacer frente a las

cargas de trabajo analíticas y transaccionales al mismo tiempo. El fuerte apoyo de los

requisitos de aplicaciones de negocios y los dos tipos de cargas de trabajo se diferencian

del SAP HANA DB de otras columnas-tiendas. Después de todo, la mayoría de las

operaciones OLAP y OLTP son operaciones, que se benefician de la compresión de la

columna. Además, un menor número de índices que se requieren que conduce a un

simple del diseño base de datos física y el consumo de memoria reducida. Para mantener

aún más la enorme cantidad de datos producidos por las aplicaciones empresariales de

hoy en día en la memoria, SAP HANA DB permite distribuir en un clúster de nodos.

Como resultado.

Sin embargo, una columna de almacenar en memoria apoyar la distribución plantea una

serie de desafíos, incluyendo la necesidad de partición, el apoyo a las transacciones

distribuidas y un proceso cuidadosamente diseñado para la fusión de las actualizaciones

en el diseño de almacenamiento optimizado de lectura. Sin embargo, estos desafíos son

sólo la punta del iceberg, ya que consideramos aplicaciones intensivas de datos en la

nube, los requisitos de elasticidad, multi-alquiler, o científico de computación son nuevos

retos que tienen que ser abordados.

 16

4. Conclusiones

 Desarrollar la habilidad de investigación nos ayuda a formarnos como

profesionales que pueden aportar soluciones en el contexto general.

 Conocer la importancia de la material de complejidad de algoritmos, ya que un

algoritmo mal diseñado puede impactar en el desempeño del programa y de la

máquina.

 Este trabajo sobre el paper abre la mente del estudiante y futuro profesional en

pensar diferente sobre todas las posibles ramas de la ingeniería que se puede

enfocar.
 17

5. Bibliografía

Trabajos citados
[1] DJ Abadi, S. M. (s.f.). Columna-Tiendas vs. fila Tiendas-: ¿Qué tan distintos son ellos De
Verdad? SIGMOD.
[10] T. Legler, W. L.-c.-7. (s.f.). La minería de datos con el acelerador de BI de SAP NetWeaver.
VLDB.
[10] T.Legler, W. a. (s.f.). DataMiningwiththeSAPNetWeaverBIAccelerator. VLDB.
[3] S. Chaudhuri, U. D. (s.f.). Una visión general de la tecnología de Business Intelligence.
MCCA.
American National Standards Institute. (Reaffirmed 9 December 2009 ). Estandares IEEE para
el Aseguramiento de la calidad del software.
EEEI. (s.f.). THE SAP HANA DATABASE - AN ACHITECTURE OVERVIEW.
H.Plattner, [. (s.f.). ACommonDatabaseApproachforOLTPandOLAPUsinganIn-
MemoryColumnDatabase. SIGMOD.
Pressman, R. S. (1998). Ingenieria de Software "Un enfoque Practico" . Madrid: Concepción
Fernández Madrid.
Roldos, E. X. (2012). http://calidadtes.blogspot.com. Obtenido de http://calidadtes.blogspot.com:
http://calidadtes.blogspot.com
Sanders, [. F. (s.f.). Engineering Basic Algorithms of an In-Memory Text Search Engine.
ACMTOIS.
SAP. (s.f.). https://support.sap.com. Obtenido de https://support.sap.com:
https://support.sap.com
significados.com. (s.f.). Obtenido de www.significados.com: www.significados.com
Song, [. S. (s.f.). TIEMPO: DBMS OLTP altamente escalable para administrar Stream-intensivo
de actualización Carga de trabajo. 1033-1034.
wikipedia. (s.f.). es.wikipedia.org. Obtenido de wikipedia: https://es.wikipedia.org