Arquitectura de SAP HANA

Vista general de la arquitectura

SAP HANA es sistema complejo compuesto de múltiples procesos y servicios que trabajan coordinadamente. A diferencia de bases de datos tradicionales con arquitectura monolítica, HANA tiene arquitectura modular donde cada componente tiene responsabilidades específicas.

La arquitectura está diseñada desde cero para aprovechar características de hardware moderno: procesadores multi-core, memoria masiva, almacenamiento SSD rápido, y redes de alta velocidad. Cada decisión arquitectural optimiza para performance in-memory y procesamiento paralelo.

Componentes principales

El Index Server es el corazón de HANA. Gestiona el almacenamiento de datos en memoria, procesa queries SQL, ejecuta cálculos analíticos, y coordina acceso a datos. Casi todo el trabajo de procesamiento de datos ocurre en el index server.

El Name Server actúa como directorio de servicios y coordinador en topologías distribuidas. Mantiene información sobre qué nodos contienen qué datos, coordina distribución de carga, y gestiona cambios de topología cuando nodos se añaden o eliminan.

El Preprocessor Server maneja procesamiento de text analytics y text mining. Cuando aplicaciones necesitan extraer información de documentos no estructurados, analizar sentimiento, o categorizar textos, el preprocessor ejecuta estos algoritmos especializados.

El XS Engine (Extended Application Services) proporciona servidor de aplicaciones integrado. Permite ejecutar aplicaciones web completas directamente en HANA sin necesidad de servidor de aplicaciones externo, maximizando performance al co-ubicar aplicaciones con datos.

El Statistics Server recolecta métricas de performance y estado del sistema. Monitoriza utilización de memoria, CPU, I/O, tiempos de query, y otros aspectos operacionales. Estos datos alimentan herramientas de monitorización y alertas.

El Web Dispatcher distribuye carga HTTP entre múltiples instancias XS en configuraciones scale-out. Actúa como load balancer y reverse proxy para tráfico web entrante.

Index Server en detalle

El Index Server contiene múltiples engines especializados que procesan diferentes tipos de operaciones. Esta arquitectura multi-engine permite optimizaciones específicas para cada workload.

El SQL Processor interpreta y ejecuta queries SQL estándar. Parsea statements SQL, optimiza planes de ejecución, y coordina ejecución distribuyendo trabajo entre engines apropiados. El optimizer HANA es extremadamente sofisticado, considerando características de datos, estadísticas, y capacidades de hardware para generar planes óptimos.

El OLAP Engine ejecuta operaciones analíticas complejas: agregaciones, joins de múltiples tablas, cálculos de ventanas, operaciones de ranking. Aprovecha almacenamiento columnar para procesar eficientemente queries que leen subconjuntos de columnas sobre millones de filas.

El Join Engine optimiza joins entre tablas grandes. HANA utiliza algoritmos especializados (hash joins, merge joins) que aprovechan procesamiento paralelo y características de datos comprimidos para ejecutar joins órdenes de magnitud más rápido que bases de datos tradicionales.

El Calculation Engine ejecuta calculation views: vistas lógicas que definen transformaciones y agregaciones complejas. Las calculation views son fundamentales en aplicaciones analíticas HANA, permitiendo definir lógica de negocio compleja que se empuja al motor de base de datos.

El Planning Engine soporta aplicaciones de planning y simulación. Permite operaciones de write-back donde usuarios modifican datos agregados y los cambios se distribuyen a nivel de detalle, crítico para aplicaciones de budgeting y forecasting.

Gestión de memoria

La gestión de memoria es aspecto crítico de arquitectura HANA porque todos los datos operacionales residen en RAM. El memory manager coordina asignación de memoria entre diferentes componentes y pools.

El Global Allocation Limit define cuánta memoria total HANA puede alocar. Típicamente se configura como porcentaje de RAM física del servidor (por ejemplo, 90%) dejando memoria para sistema operativo y otros procesos.

Los memory pools separan memoria para diferentes propósitos: column store para datos columnares, row store para datos transitorios, result cache para resultados de queries, intermediate results para operaciones temporales.

El garbage collection libera memoria de objetos que ya no se necesitan. HANA utiliza garbage collection sofisticado que opera en background sin bloquear procesamiento de queries, minimizando impacto en performance.

La gestión de situaciones out-of-memory es crítica. Si HANA agota memoria disponible, debe manejar gracefully: rechazar nuevas operaciones, liberar caches, y en casos extremos unload datos menos usados a disco temporalmente.

Persistencia y durabilidad

Aunque HANA es base de datos in-memory, debe garantizar durabilidad: los datos no se pierden si hay crash del sistema. La arquitectura de persistencia equilibra performance con durabilidad.

El Data Volume almacena snapshots de datos en disco. Los datos en memoria se persisten periódicamente a archivos en disco. En caso de restart, HANA carga datos desde estos archivos recuperando estado consistente.

El Log Volume contiene redo logs que registran todas las modificaciones de datos. Los cambios se escriben a log inmediatamente (write-ahead logging) antes de modificar estructuras en memoria. Esto garantiza que en caso de crash, los cambios pueden recuperarse reproduciendo el log.

Los savepoints son checkpoints periódicos donde HANA escribe snapshot completo de datos en memoria a disco y trunca el log. Esto mantiene el log manejable y acelera recovery (no necesita reproducir log completo desde el inicio de los tiempos).

El delta merge combina cambios incrementales con datos persistidos. Las escrituras inicialmente van a estructuras delta en memoria. Periódicamente, el delta merge consolida estos cambios en estructuras principales columnares comprimidas.

Arquitecturas scale-up vs scale-out

Scale-up (también llamado single-node) ejecuta HANA en un servidor único con toda la memoria y CPU necesarias. Es arquitectura más simple, más fácil de administrar, y suficiente para muchos despliegues. Sistemas hasta varios TB de RAM pueden ejecutarse scale-up.

Las ventajas de scale-up incluyen simplicidad operacional (un servidor para gestionar, no coordinación distribuida), latencia mínima (no hay comunicación de red entre nodos), y menor coste para sistemas que caben en un servidor.

Scale-out distribuye la base de datos entre múltiples servidores conectados por red de alta velocidad. Las tablas grandes se particionan automáticamente entre nodos. Queries que acceden estas tablas ejecutan en paralelo distribuyendo trabajo entre todos los servidores.

Los beneficios de scale-out son capacidad de manejar bases de datos que no caben en un servidor (decenas de TB), mayor throughput al distribuir carga entre múltiples servidores, y mejor disponibilidad (fallo de un nodo no necesariamente tumba sistema completo).

La complejidad de scale-out incluye coordinación entre nodos, network overhead, particionamiento y re-particionamiento de tablas, gestión de joins distribuidos, y troubleshooting más complejo cuando problemas involucran múltiples nodos.

Topología scale-out

En configuración scale-out, un nodo actúa como master y los demás como workers. El master coordina operaciones, gestiona metadata del sistema, y distribuye trabajo. Los workers ejecutan procesamiento de datos.

El particionamiento de tablas distribuye datos entre nodos. Las tablas grandes se dividen automáticamente (típicamente por hash o range partitioning). HANA determina qué partición va a qué nodo basándose en distribución de datos y carga.

Los queries distribuidos ejecutan en paralelo: el optimizer descompone query en sub-queries que ejecutan localmente en nodos que contienen datos relevantes. Los resultados parciales se combinan en nodo coordinador.

La redistribución de datos ocurre cuando se añaden o eliminan nodos. HANA re-balancea particiones entre nodos disponibles para mantener distribución uniforme de datos y carga.

El failover en scale-out requiere configuración específica. Típicamente se configura standby node que puede tomar rol de nodo fallido. Los datos requeridos para failover deben estar disponibles (mediante replicación o storage compartido).

Tipos de tablas

Las Column Tables utilizan almacenamiento columnar comprimido. Son default para la mayoría de datos y óptimas para analytics. Los datos se comprimen agresivamente, se leen eficientemente para queries analíticas, y se benefician de procesamiento paralelo.

Las Row Tables almacenan datos en formato tradicional row-based. Útiles para datos transitorios, tablas temporales, o casos donde performance de escritura de registros individuales es crítica. Generalmente menor compresión y menos eficientes para analytics que column tables.

Las History Tables en column store mantienen historial de cambios con información temporal. Permiten time-travel queries: consultar estado de datos en cualquier punto del pasado. Útiles para auditoría, compliance, y análisis histórico.

Las Global Temporary Tables existen solo durante sesión de usuario. Útiles para resultados intermedios de procesamiento complejo. Los datos no persisten entre sesiones y no se replican en configuraciones de alta disponibilidad.

Procesamiento de queries

El query processing en HANA es altamente paralelo y optimizado para arquitectura columnar e in-memory. Cuando llega un query, múltiples fases lo procesan antes de retornar resultados.

El parsing verifica sintaxis SQL y construye árbol de sintaxis abstracta. Esta fase es rápida en HANA; el overhead de parsing es negligible comparado con tiempo de ejecución incluso para queries complejas.

La optimización genera plan de ejecución óptimo. El optimizer considera: estadísticas de datos, índices disponibles, tamaño de tablas, predicados de filtro, y topología del sistema. El cost-based optimizer estima coste de planes alternativos y selecciona el más eficiente.

La ejecución distribuye trabajo entre threads paralelos. Para tablas columnares grandes, el procesamiento se divide entre múltiples cores. En scale-out, trabajo se distribuye entre nodos. La paralelización es automática y transparente.

Los operadores de query (scan, filter, join, aggregate) están optimizados para procesamiento vectorizado: operan en bloques de datos en lugar de registro por registro, aprovechando instrucciones SIMD de CPUs modernas.

Caching y buffering

El Result Cache almacena resultados de queries frecuentemente ejecutadas. Si query idéntica se ejecuta nuevamente con datos sin cambios, HANA retorna resultado cached instantáneamente sin re-ejecutar query.

El Data Cache mantiene en memoria datos recientemente accedidos. Aunque idealmente toda la base de datos está en memoria, en sistemas muy grandes ciertos datos pueden estar en disco. El cache acelera acceso a datos accedidos frecuentemente.

El Metadata Cache almacena definiciones de tablas, vistas, y objetos de base de datos. Acceder metadata es operación frecuente; cachearla evita lecturas repetidas de estructuras de sistema.

La invalidación de cache ocurre cuando datos subyacentes cambian. HANA rastrea dependencias entre queries cached y datos. Cuando datos se modifican, caches dependientes se invalidan automáticamente garantizando que queries siempre retornan resultados actuales.

Procesamiento transaccional

El control de concurrencia gestiona accesos simultáneos a datos por múltiples transacciones. HANA utiliza optimistic concurrency control con MVCC (Multi-Version Concurrency Control): lectores nunca bloquean escritores, escritores nunca bloquean lectores.

Las versiones de datos permiten que lectores vean snapshot consistente de datos sin bloquear escrituras concurrentes. Cada transacción ve versión de datos correspondiente a su timestamp de inicio, incluso si datos se modifican por otras transacciones.

El transaction commit es proceso de dos fases: primero se escriben cambios al log (garantizando durabilidad), después se aplican cambios en estructuras en memoria. Solo tras completar ambas fases, la transacción se considera committed.

El rollback de transacciones abortadas deshace cambios mediante versiones previas de datos mantenidas por MVCC. Los rollbacks son rápidos porque no requieren aplicar operaciones inversas; simplemente se descarta versión modificada.

Compresión de datos

La compresión es fundamental para arquitectura HANA. Permite almacenar más datos en memoria disponible y acelera procesamiento reduciendo volumen de datos a procesar.

El Dictionary Encoding reemplaza valores repetidos con códigos cortos. Una columna "país" con millones de filas pero solo 200 valores únicos se comprime dramáticamente: almacena diccionario de 200 países y para cada fila almacena código corto en lugar de nombre completo.

El Run-Length Encoding comprime secuencias de valores idénticos. Si columna "estado_pedido" tiene miles de filas consecutivas con valor "completado", RLE almacena "completado x 5000" en lugar de repetir valor 5000 veces.

El Cluster Encoding agrupa valores similares. Columnas con datos que tienen patterns predecibles (fechas, números secuenciales) se comprimen eficientemente identificando clusters y almacenando offsets en lugar de valores completos.

El Sparse Encoding optimiza columnas con muchos valores NULL o default. En lugar de almacenar explícitamente cada NULL, almacena solo valores no-NULL con sus posiciones.

Servicios de sistema

El Daemon Manager (sapstartsrv) controla inicio y parada de servicios HANA. Es el primer proceso que arranca y el último que para. Monitoriza salud de servicios y puede reiniciar automáticamente servicios que crashed.

El Host Agent proporciona interfaz para herramientas de gestión externas. Permite a SAP Solution Manager y otras herramientas monitorizar y gestionar instancias HANA remotamente.

El License Manager gestiona licencias HANA. Verifica que licencia válida está instalada, rastrea uso (para licencias basadas en memoria o usuarios), y bloquea sistema si licencia expira o es inválida.

El Audit Log Service registra eventos de seguridad y auditoría. Rastrea logons, accesos a datos sensibles, cambios de configuración, y otras actividades críticas para compliance y forensics.

Comunicación y networking

El SQL Interface es punto de entrada estándar para aplicaciones. Aplicaciones SAP y externas conectan mediante SQL estándar sobre protocolo JDBC/ODBC. HANA implementa amplio subconjunto de SQL:2016 más extensiones propietarias.

Los Internal Communication Channels conectan servicios dentro de HANA. Index server, name server, y otros componentes se comunican mediante protocolos internos optimizados de baja latencia.

El MDC (Multi-tenant Database Containers) permite múltiples bases de datos lógicas en una instancia HANA física. Cada tenant database es aislado pero comparte infraestructura física, optimizando utilización de recursos.

El System Replication Protocol replica cambios entre sistemas primario y secundario para alta disponibilidad. Opera a nivel de redo log, transmitiendo cambios continuamente con latencia mínima.

Seguridad arquitectural

La autenticación soporta múltiples mecanismos: passwords almacenados en HANA, Kerberos, SAML, JWT tokens, y certificados X.509. La autenticación flexible permite integración con sistemas corporativos de identity management.

El cifrado de datos en reposo protege data volumes y log volumes en disco. El cifrado es transparente para aplicaciones; HANA gestiona claves y cifrado/descifrado automáticamente.

El cifrado de red (SSL/TLS) protege comunicaciones entre clientes y HANA. Todas las conexiones SQL pueden cifrarse garantizando que datos sensibles no viajan en claro.

El role-based access control gestiona autorizaciones. Los privilegios se asignan a roles, roles a usuarios. Separación clara entre privilegios de sistema (administración), de objeto (acceso a datos), y de procedimiento (ejecutar lógica específica).

Extensibilidad

El Application Function Library (AFL) permite registrar funciones custom implementadas en C++ directamente en HANA. Estas funciones ejecutan in-process con performance nativo, útil para algoritmos especializados no disponibles en SQL estándar.

Los Stored Procedures en SQLScript permiten implementar lógica compleja que ejecuta en servidor de base de datos. SQLScript es lenguaje procedural optimizado para operaciones set-based sobre datos HANA.

Las External Machine Learning Libraries integran frameworks como TensorFlow, PyTorch. Los modelos entrenados externamente pueden desplegarse en HANA para scoring in-database, eliminando necesidad de mover datos.

Temas relacionados

Para profundizar en la arquitectura HANA, consulta:

Introducción a SAP HANA para contexto y conceptos fundamentales.

Memoria, persistencia y almacenamiento para detalles de gestión de memoria y disco.

Column Store vs Row Store para profundizar en almacenamiento columnar.

Performance y tuning para optimización de arquitectura para workloads específicos.

Monitorización para vigilar salud y performance de componentes arquitecturales.

Replicación para alta disponibilidad y disaster recovery.