Universo de informes de SAP



Hace aproximadamente 4 años, cambiamos nuestro sistema de informes de Oracle a SAP Hana. Hoy, almacena alrededor de 10,000 mesas, 38,000 personas lo usan y más de 5,000 procesos de descarga ocurren diariamente. Por el momento, nuestro complejo, en el que funciona el sistema, consta de 8 servidores con 14 TB de memoria. Todos los días, el sistema de informes procesa 1.5 pb de datos. Al mismo tiempo, Hana era aproximadamente 20 veces más productiva que Oracle, DB2 y MySQL. Y hoy quiero decir cómo, en el marco de la integración de M.Video y Eldorado, aumentamos adicionalmente el rendimiento del sistema de informes, qué optimizaciones hicimos.

Carga


Hoy, de varios miles de informes creados por el sistema, solo 10 generan el 70% de la carga total. El informe más pesado en la base de datos de Hana es la Revisión semanal de negocios. Funciona durante 30 minutos y consume 4 TB de memoria. El 90% de todos los informes son generados por el centro de contacto: creamos un servicio que, cuando un cliente llama por su número de teléfono, abre automáticamente un informe y muestra al operador el historial completo de las compras de la persona que llama y su interacción con la empresa.

Modelo de datos


El modelo de datos clave en el que se construye la mayor parte de los informes contiene 1.500 tablas. La mayoría de ellos son tablas de referencia. Con este modelo, puede analizar cualquier dirección de la empresa. Un ejemplo es la visualización de un modelo de datos creado con el diseñador de Universe. Es cierto que refleja solo una décima parte de nuestro sistema.



Rendimiento


En el momento de la fusión de M.Video y Eldorado, la cantidad de datos en los dos sistemas de informes era de aproximadamente 10 TB: 7 TB en el BW en HANA M.Video system, 2 TB en el BW en HANA Eldorado y 1 TB datos adicionales en HADOOP (datos históricos). Al combinar los sistemas, teníamos limitaciones de hardware: el complejo M. Video constaba de 6 nodos (2 TB cada uno), incluida una copia de seguridad. Este sistema podría expandirse a un máximo de 8 nodos, de los cuales un respaldo.

En preparación para la fusión, asumimos que la cantidad total de todos los datos alcanzaría 13 TB. Por lo tanto, según las recomendaciones de SAP, necesitábamos un sistema de 16 nodos de 2 TB cada uno, incluidos dos nodos de respaldo. Además, un nodo tenía que asignarse como un nodo maestro, que, con tal volumen de información, se haría cargo de las funciones de gestión. Es decir, para un funcionamiento correcto era necesario desplegar 13 nodos.

Como puede ver, los recursos disponibles son categóricamente insuficientes. Y ese fue el primer desafío.

La segunda dificultad principal antes de la fusión fue que la velocidad del sistema a menudo no satisfacía las necesidades del negocio. La razón principal fue la gran cantidad de llamadas simultáneas a la base de datos. Desde el punto de vista del sistema, parecía una bola de nieve, lo que podría conducir a la congelación e interrupción de parte de los procesos, o incluso a descargas globales de "falta de memoria" en los nodos.

Estaba claro que sin mejoras significativas, un aumento doble en la cantidad de datos en los informes (para dos marcas) conduciría a un empeoramiento aproximadamente doble de la situación.

Por lo tanto, decidimos optimizar el sistema en las siguientes áreas:

  • Informes Aceleración de los informes más críticos y más intensivos en recursos y revisión del modelo de datos.
  • Repositorio . Archivado y optimización de almacenamiento.
  • Descargas Agilice el procedimiento y cambie el horario de descarga.

El enfoque general para la optimización fue este:



Primero, realizamos un análisis en todas las direcciones, identificamos las causas de los problemas y luego analizamos las capacidades del sistema con los recursos necesarios. También intentamos de inmediato automatizar este proceso tanto como sea posible para que en el futuro podamos identificar rápidamente las causas de los problemas y restaurar rápidamente el rendimiento.

Que hemos hecho:

  • Cambió la configuración de los servidores de aplicaciones ABAP: la cantidad de instancias, el uso efectivo de la tecnología NUMA y la cantidad óptima de flujos de trabajo.
  • Aplicamos los parámetros óptimos de HANA y el sistema operativo Linux.
  • Analizamos la disminución en el consumo de CPU.
  • Analizamos el consumo de RAM en todo el intervalo de tiempo observado.
  • Analizamos la aparición de OOM en HANA.
  • Analizamos la aparición de bloqueos en el sistema y la disponibilidad de recursos del sistema para las operaciones de espera (espera).
  • Analizamos el equilibrio de datos teniendo en cuenta la redistribución y el reparto de datos para la solución SCALE-OUT HANA.
  • Analizamos las causas de los volcados de ABAP que afectan el funcionamiento de las cadenas críticas.

En función de los resultados, se compilaron informes de rendimiento, así como instrucciones para que en el futuro fuera posible determinar de forma independiente los cuellos de botella en el sistema y los intervalos de tiempo pico.

Qué resultados se lograron:









Varios informes optimizados SAP BO comenzaron a funcionar muchas veces más rápido y consumieron cientos de veces menos memoria .



Aquí hay algunos ejemplos sorprendentes de cómo el sistema cumple incorrectamente las condiciones de selección y cómo generar consultas correctamente en HANA.

Se revelaron problemas al filtrar por objetos no materializados, especialmente (!) Al usar los indicadores COUNT DISTINCT (se puede escribir un CD tanto a nivel del universo como en una función en CV).



Incluso si excluye el CD de la consulta, la primera opción seguirá funcionando 20 veces más lenta que la segunda, y con un CD, la velocidad es más de 500 veces mayor.



Un caso especial de uso de objetos no materializados en filtros: filtros compuestos de dos o más objetos, por ejemplo, pegar una semana y un año:



Las consultas con filtros pegados no funcionan tan lentamente como la conversión a una fecha, pero aún así ralentizan las consultas (aproximadamente 2-3 veces).



Para recopilar estadísticas sobre el funcionamiento del sistema de informes, los procesos de carga y las cadenas, desarrollamos el siguiente esquema:



Al mismo tiempo, agregamos un comentario especial a los informes con el nombre del informe. Por lo tanto, podemos comparar la carga de diferentes partes del sistema y comparar el período con el período.



Planes


Tenemos muchos planes para el desarrollo de la funcionalidad empresarial y una revisión sustancial de la herramienta de visualización de datos. La tendencia global en la que participamos activamente es integrar el sistema de informes en el paradigma de la transformación digital.

A que te refieres

Cuando nuestro sistema de informes era joven, los usuarios a menudo acudían a nosotros con solicitudes similares: "Automatice la construcción de un informe que muestre cuánto beneficio neto recibió esta o aquella tienda o toda la compañía".

Luego comenzaron a llegar a nosotros con solicitudes para elaborar un algoritmo que construiría un plan o pronóstico para una ganancia neta, dependiendo de factores específicos.

Y hoy hemos llegado a la conclusión de que los usuarios desean conocer el pronóstico exacto del beneficio neto. Tenemos todos los datos necesarios para el desarrollo de algoritmos de pronóstico, y hay especialistas en análisis de datos que pueden crear modelos de aprendizaje automático. Como saben, esto requiere grandes cantidades de datos, por lo que una de las principales tendencias en el desarrollo de nuestro sistema de informes es la transición al análisis y la creación de modelos basados ​​en grandes datos.

Unas palabras sobre nuestro equipo


Hoy en día, las grandes empresas están introduciendo cada vez más sistemas de pronóstico basados ​​en algoritmos de aprendizaje automático desarrollados por el propio sistema. Hace dos años, creamos un centro de competencias en el campo del análisis de datos del Centro de Ciencia de Datos Minoristas Digitales, y este año tenemos un grupo de ingenieros de datos. Estamos introduciendo un nuevo sistema para procesar y analizar big data. Y necesitamos personas en el equipo de los departamentos de soporte, desarrollo y análisis de datos aplicados.

Si estás interesado en estas áreas, si sientes la fuerza en ti mismo, ¡bienvenido! Encontrarás un trabajo interesante y difícil, a veces estresante, pero siempre creativo.

Source: https://habr.com/ru/post/462015/


All Articles