Configurar los destinos de reubicación (NSE e ILM) durante la construcción en proyectos de utilities SAP S/4HANA

Esta es la cuarta pieza de la secuencia de 6 guías técnicas de AGT sobre Archiving y Huella HANA en utilities, y abre el bloque “durante el proyecto”. El bloque anterior (piezas 1-3) dejó resuelto por qué crece el dato, qué hacer con los históricos del legado, y qué prerequisitos deben estar activos antes de construir. Esta pieza muestra dónde y cómo se reubican en la práctica los datos del flujo Meter-to-Cash una vez que esos prerequisitos están activos. La siguiente pieza de la secuencia profundiza en la mecánica técnica concreta de particionamiento y ejecución (Data Aging Run) que se apoya sobre esta configuración.

Fundamento conceptual

El Data Lifecycle Manager permite configurar destinos de almacenamiento para reubicar datos desde SAP HANA hacia otras capas del stack: SAP HANA dynamic tiering para datos tibios, o Apache Hadoop (vía el SAP HANA Spark Controller) para datos fríos. La configuración se realiza definiendo perfiles y reglas de reubicación por cada destino de almacenamiento, que luego se validan mediante una simulación antes de activarse: el sistema muestra cuántos registros o particiones se moverán a cada destino sin ejecutar todavía el movimiento real. Solo después de guardar y activar la regla, el sistema queda listo para programar la reubicación efectiva de datos [1]. Esta mecánica del Data Lifecycle Manager (DLM) aplica a aplicaciones nativas de HANA y a escenarios BW; para objetos de negocio de SAP S/4HANA y SAP Business Suite —como los tres tipos de objeto de Meter-to-Cash que siguen— la reubicación en frío no pasa por el DLM sino por el framework de SAP Information Lifecycle Management (ILM), tal como se precisa a continuación.

Es importante precisar algo que no siempre queda claro en la literatura general de tiering de HANA: para sistemas SAP S/4HANA y SAP Business Suite on HANA —que es exactamente el caso de una utility—, la guía técnica actual recomienda usar Native Storage Extension (NSE) como la opción específica para gestionar datos tibios, mientras que dynamic tiering y extension node quedan reservados principalmente para aplicaciones nativas de HANA o escenarios de BW [2]. NSE es un almacén de datos tibios integrado en HANA que permite gestionar datos de acceso poco frecuente sin cargarlos completamente en memoria, marcando tablas, particiones o columnas como “page loadable” en lugar de “column loadable” — de forma que solo se cargan en memoria las páginas efectivamente consultadas, mientras el resto permanece en disco [3]. Para el verdadero dato frío que ya no requiere consulta analítica frecuente, SAP IQ sigue siendo la opción adecuada [2]: en aplicaciones nativas de HANA se accede vía el mismo Data Lifecycle Manager, pero en objetos de negocio de S/4HANA y Business Suite —el caso de los tres objetos M2C de esta pieza— el camino es el framework de archivado SAP ILM (objetos de archivado ejecutados vía transacción SARA), que apunta a SAP IQ como store de archivo.

Aplicación práctica

Esta distinción entre NSE (tibio, dentro de HANA) y SAP IQ vía SAP ILM (frío, fuera de HANA) es exactamente lo que hay que resolver durante la construcción para cada uno de los tres tipos de objetos de datos del flujo Meter-to-Cash:

Documentos FI-CA de facturación, pago y morosidad que ya fueron compensados pero siguen dentro del período de residencia definido en la pieza anterior de esta secuencia son candidatos naturales a NSE: se consultan ocasionalmente —por ejemplo, ante una disputa de facturación o una auditoría interna—, pero no con la frecuencia de un documento del ciclo actual. Marcarlos como “page loadable” mediante NSE reduce su costo de memoria sin perder la capacidad de consultarlos con SQL estándar.

Documentos de lectura de medidor, tanto periódicos como fuera de ciclo, siguen el mismo patrón: una vez procesados en la facturación, su consulta cae drásticamente pero no desaparece —el área de atención al cliente y el área de detección de pérdidas no técnicas siguen necesitando acceso a lecturas históricas para resolver reclamos o investigar anomalías de consumo. NSE es, de nuevo, la opción consistente con esta necesidad de acceso ocasional pero real.

Los datos de intervalo de medición inteligente son el caso más exigente de los tres, porque su volumen crece de forma continua —una lectura cada 15 a 30 minutos, o menos, por punto de suministro— y buena parte de ese volumen, pasado cierto tiempo, ya no tiene valor operativo diario sino solo analítico o regulatorio. Este es el tipo de dato donde la reubicación hacia SAP IQ vía SAP ILM (el framework de archivado de S/4HANA; el DLM queda reservado a aplicaciones nativas de HANA) cobra más sentido: una vez que el dato de intervalo cumplió su ciclo de uso en la facturación y el análisis de consumo reciente, moverlo fuera de HANA por completo —sin perder accesibilidad, solo con una latencia mayor— es lo que evita que el crecimiento estructural de la medición inteligente siga presionando la memoria contratada bajo el RISE with SAP descrito en la pieza anterior.

Un recurso operativo específico para utilities es el análisis de Data Volume Management (DVM): permite proyectar cómo va a crecer el volumen de datos a futuro y planificar la estrategia de tiering en consecuencia, apoyándose en herramientas como el DBA Cockpit para identificar qué tablas concentran más consumo de memoria [4]. Nota de vigencia: la app DVM históricamente disponible en SAP for Me fue retirada el 31 de diciembre de 2025; el análisis equivalente se accede hoy a través del RISE with SAP Methodology Dashboard en SAP Cloud ALM. Correr este análisis durante la construcción —no después del go-live— es lo que permite decidir, con datos reales del propio sistema en migración, qué volumen de cada uno de los tres tipos de objeto de M2C conviene mandar a NSE y cuál a SAP IQ vía SAP ILM, en lugar de aplicar una regla genérica sin validar contra el comportamiento real de esa utility en particular.

Mejores prácticas y consideraciones

• No tratar “tiering” como una decisión única y genérica. Documentos FI-CA, lecturas de medidor y datos de intervalo tienen patrones de acceso distintos y merecen reglas de reubicación separadas — no una única política aplicada por igual a todo el sistema.
• Usar NSE como destino por defecto para dato tibio en S/4HANA, no dynamic tiering ni extension node. La guía técnica vigente reserva estas dos últimas opciones principalmente para aplicaciones nativas de HANA o escenarios BW; para el core transaccional de una utility en S/4HANA, NSE es la opción consistente con la arquitectura del sistema.
• Correr el análisis de Data Volume Management durante la construcción, con datos reales del sistema en migración. Decidir los umbrales de reubicación sin este análisis es una apuesta; decidirlos con él es una configuración basada en el comportamiento real de esa utility.
• Validar siempre con una simulación antes de activar cualquier regla de reubicación. En HANA nativa esto lo hace el Data Lifecycle Manager; en el archivado ILM de objetos S/4HANA, el modo de prueba (test run) de SARA cumple ese mismo rol — omitir este paso, en cualquiera de los dos frameworks, es la forma más común de descubrir después un volumen de reubicación distinto al esperado.
• Anti-patrón a evitar: postergar la configuración de destinos hasta después del go-live “para no atrasar el proyecto”. Cada mes de operación sin reglas de reubicación activas es un mes de crecimiento acumulado en memoria caliente que, como mostró la pieza anterior de esta secuencia, se traduce directamente en presión sobre la memoria contratada del RISE with SAP.

Con los destinos de reubicación configurados, la siguiente pieza de esta secuencia baja al detalle técnico de cómo se mueven realmente los datos entre particiones y qué dispara ese movimiento: la mecánica de particionamiento por temperatura y la ejecución del Data Aging Run.

Referencias

1. Data Aging in SAP S/4HANA
2. Managing SAP HANA data footprint for balancing cost and performance | Microsoft Learn — https://learn.microsoft.com/en-us/azure/sap/workloads/hana-tiering-guidance
3. SAP HANA Native Storage Extension: Storage option for warm data — https://www.ibsolution.com/academy/blog_en/data-and-analytics/sap-hana-native-storage-extension-storage-option-for-warm-data
4. HANA NSE (Native Storage Extension) Data Tiering Options for Utilities - SAP Community — https://community.sap.com/t5/technology-blog-posts-by-members/hana-nse-native-storage-extension-data-tiering-options-for-utilities/ba-p/13531609
5. Cold Data Tiering Options for SAP HANA (SAP ILM with SAP IQ vs. Data Lifecycle Manager) — AWS SAP Workloads Documentation — https://docs.aws.amazon.com/sap/latest/sap-hana/cold-data-tiering-options.html