Nuevas Perspectivas Serie de blogs: desafíos clave de 3 SAP HANA Embedded Analytics

Retos clave de 3 SAP HANA Embedded Analytics

Bienvenido a la serie de blogs Nuevas Perspectivas de TruQua. Esta serie de blogs proporciona una plataforma para que nuestros consultores compartan sus perspectivas, ideas y experiencias sobre tecnologías emergentes como SAP HANA y SAP Analytics Cloud.

Esta semana vamos a hablar con Laura Rossi. Laura es consultora en TruQua, y se especializa en el uso de las capacidades de análisis integrado de SAP HANA para proporcionar un enorme valor de planificación e informes en SAP S / 4HANA y SAP Analytics Cloud (SAC). Hoy Laura y yo discutiremos tres desafíos clave de SAP HANA que enfrentan los clientes y cómo superarlos.

Estos desafíos provienen de implementaciones maduras donde TruQua se involucró por primera vez después de la puesta en marcha para ayudar al cliente. Queremos cubrir no solo la solución, sino también la causa raíz de los problemas que se presentaron y cómo nos aseguramos de que los desafíos del cliente no volvieran.

Challenge 1: el enorme rendimiento de HANA

JS Irick: Sin hipérboles, HANA es la herramienta que muchos científicos de datos y analistas financieros han esperado durante toda su carrera. HANA maneja fácilmente el Universal Journal: miles de millones de registros con columnas 300 +, condensando cientos de tablas ERP en una sola estructura plana.

Con ese poder excepcional viene el riesgo: en el caso de un compromiso, descubrimos que una sola consulta requería 700 Gigabytes de memoria; en otro cliente, miles de millones de registros se pasaron a la capa SAP NetWeaver, amenazando repetidamente la estabilidad productiva.

Desde el punto de vista del desarrollo y las pruebas, ¿cómo recomienda a los clientes que aprovechen de manera efectiva las fortalezas de HANA?

Laura Rossi: Como mencionó, JS, HANA tiene la capacidad de procesar tablas masivas en cuestión de segundos, lo que permite a los usuarios crear vistas grandes y complejas de sus datos, agregar cálculos, filtrar, reformatear, etc. y almacenarlas como una sola estructura plana. Sin embargo, el hecho de que nosotros podría Crear consultas grandes y complejas no significa necesariamente que debamos aprovechar ese poder en todo momento. Las ineficiencias se agravan rápidamente, lo que lleva al tipo de demandas de memoria que sobrecargan y bloquean los sistemas, especialmente si estamos hablando de escenarios de pruebas o pruebas con asignaciones de memoria limitadas. En mi cliente más reciente, una sola consulta ineficiente logró ralentizar nuestro sistema de desarrollo de manera muy notable hasta que lo identificamos y lo rediseñamos. Un par de horas al rediseñar la consulta culpable convirtió una consulta muy lenta y a menudo chocante en un proceso que ahora se ejecuta en aproximadamente un minuto.

Ciertos requisitos de modelado requieren consultas grandes que consumen memoria, que HANA puede manejar. Lo importante es no combinar demandas innecesarias en torno a las demandas reales y necesarias. Nadie quiere esperar a 15 minutos para ejecutar una consulta que podría realizarse en 1.5.

Además, algunas optimizaciones son simples y se basan en los principios clásicos de diseño de bases de datos. Por ejemplo, en lugar de encadenar una serie de uniones externas para atribuir detalles dispersos, el mismo escenario se puede dividir en diferentes casos en función de cómo cambia la atribución, qué atributos se aplican, cuáles no y cómo se gestionan con las uniones internas y filtros Si un criterio de selección complejo requiere una unión o una transposición, vale la pena pasar algún tiempo para evaluar si otra forma de detalle o cálculo puede servir para el mismo propósito. De esa manera, cuando se necesita abordar un requisito que requiere una gran cantidad de memoria, estamos insertando esas demandas de memoria además del modelo más ágil y eficiente posible en lugar de agravar la ineficiencia.

JS Irick: Ha tocado un punto realmente interesante aquí, que es el conflicto fundamental entre "vistas con propósito" y una "vista como almacén de datos". El primero puede sobrevivir a un problema de filtrado o dos, pero el último requiere perfección en toda la pila. Además de las obvias ventajas semánticas del uso de las vistas del Servicio de datos básicos (CDS), el hecho de que ponen más barandillas y rigor en torno a las vistas de HANA las convierte en una opción muy atractiva para garantizar la estabilidad.

Desde una perspectiva pragmática, soy un gran defensor del volumen productivo (no de datos, sino de volumen) en el desarrollo. Para consultas complejas, debe poder ver realmente el impacto.

Laura Rossi: Estoy de acuerdo. Una vez más, en mi último cliente, tuvimos la suerte de tener una muestra de datos de gran tamaño dentro de un sistema sandbox de memoria relativamente baja. Llamo a esto suerte porque permitió a nuestro equipo diseñar teniendo en cuenta la simplicidad y la eficiencia desde el primer día, en lugar de construir todo y luego optimizar. Lo que sucede con HANA es que es lo suficientemente potente como para ejecutar la consulta ineficiente. Pero de nuevo, eso no significa que deba hacerlo. Otra característica útil es la consola SQL de HANA que le permite analizar la demanda de memoria o el "costo de subárbol" de una vista y todos sus subcomponentes.

Challenge 2 - Falta de "HANA Gurus"

JS Irick: Durante casi 40 años, SAP era independiente de la base de datos, con las mejores prácticas para garantizar que los expertos de SAP permanecieran en la capa de aplicación.

Este firewall, que solo fue posible gracias a la excelente capa de integración entre NetWeaver y la base de datos, ha desaparecido. Ahora tenemos un entorno de desarrollo incomparable para datos financieros semánticamente enriquecidos. También tenemos equipos increíblemente talentosos, con un profundo conocimiento de los procesos y las necesidades de sus organizaciones, pero para quienes el desarrollo de la base de datos se ha bloqueado intencionalmente durante dos generaciones.

¿Qué fue fundamental para que te volvieras tan fuerte en el desarrollo de HANA y cómo trabajas con equipos de clientes experimentados para habilitarlos en este nuevo espacio?

Laura Rossi: Gran parte del panorama de SAP está evolucionando. SAC y S / 4HANA están remodelando cómo concebimos soluciones y qué clientes eligen priorizar. Entonces, diría que ahora es el mejor momento para comenzar a aprender y volver a aprender. Por supuesto, S / 4HANA se basa en HANA, pero incluso en un caso como SAC, conectarse a una base de datos de HANA es fácil y puede aumentar significativamente las capacidades de rendimiento de la solución de informes.

Y si bien es cierto que no podemos aprovechar la cantidad de experiencia disponible para otras soluciones SAP más antiguas, las mejores prácticas de análisis de datos aún se pueden adaptar y aprovechar en las mejores soluciones empresariales para modelar en HANA.

JS Irick: ¡Amo la positividad! La parte más gratificante de trabajar en consultoría es ver que los equipos de clientes con los que trabaja obtienen nuevas habilidades (y reconocimiento). "Ahora es el mejor momento para comenzar a aprender y volver a aprender", dice todo.

En términos de dónde comenzar, desde una perspectiva funcional, siempre recomiendo encontrar el siguiente paso. No busca reinventar FP&A, busca incorporar nuevas habilidades a su experiencia existente. Sigue construyendo sobre tus fortalezas. Desde una perspectiva técnica, recomiendo a los clientes que aprendan de la misma manera que nosotros aprendemos en TruQua. Debe poder aprovechar el plan-visualizador y comprender realmente cómo la plataforma está ejecutando sus consultas. Pequeños ajustes en el nivel de modelado pueden tener un impacto increíble, debe ser capaz de comprender dónde están los cuellos de botella para poder resolverlos.

Laura Rossi: Definitivamente de acuerdo con el visualizador del plan, es un gran lugar para comenzar a diagnosticar los aspectos de un rediseño que tendrá el impacto más productivo. Del mismo modo, comprender el linaje de sus datos y en qué etapa de una vista o modelo se realiza algún cálculo, y por qué, probablemente deberían ser los primeros pasos. Además de eso, siempre que tengamos en mente un diseño esbelto, me gusta argumentar que cuanto más simple, mejor, tanto desde el punto de vista de la resolución de problemas futuros como desde una perspectiva de escalabilidad.

Challenge 3 - Las complejidades de la transformación en tiempo real

JS Irick: No creo que sea difícil considerar la ruta desde la base de datos hasta un informe de un sistema cerrado. El proceso ETL (Extraer, Transformar, Cargar) y las muchas capas de agregación, enriquecimiento y conversión han desaparecido con el cambio a S / 4HANA y análisis integrados, pero la complejidad no ha desaparecido, todavía está presente en su CDS o Native HANA puntos de vista.

Las preguntas de informes estándar todavía existen, pero ahora se encuentran dentro de una vista única en lugar de un diagrama de arquitectura compleja:

  • ¿Cómo almacenamos datos en caché?
  • ¿Qué necesitamos para persistir?
  • ¿Cómo manejamos la configuración?
  • ¿Dónde están los puntos de extensibilidad para los nuevos requisitos?
  • ¿Cómo se manejan los cambios de datos maestros / jerarquía?

¿Cómo aborda estos desafíos con los clientes y cómo se asegura de que su solución sea de su propiedad y se expanda?

Laura Rossi: En cierto sentido, creo que todas las preguntas que abordamos hoy se reducen a los mismos principios de un diseño eficiente y esbelto. Tener muy claros los requisitos, lo que puede o no cambiar, lo que ha cambiado históricamente y dónde reside todo es clave, por lo que en ese sentido uno debe comenzar por lo básico: echar un buen vistazo a lo que se requiere y a cómo se ven los datos. para datos reales actuales, planificación y datos históricos.

Después de esto, desglosar el modelado de vistas en “capas” basadas en casos de uso o escenarios ayuda tanto desde el punto de vista de la trazabilidad como de la resolución de problemas simples, al tiempo que mantiene baja la complejidad. En otras palabras, recomendaría crear vistas múltiples para diferentes aspectos del uso comercial y luego una vista de "nodo superior" que combine el resultado de estas capas más pequeñas. Una vista simple y eficiente con un caso de uso claro es más fácil de construir y expandir que una vista grande y compleja que combina múltiples escenarios de casos de uso.

JS Irick: Realmente me gusta que hayas presentado una arquitectura en capas desde una perspectiva funcional. (también que hiciste un guiño astuto al desarrollo ágil / delgado).

Un desarrollador necesita comprender realmente el caso de uso del cliente, ser capaz de comunicarse con el usuario y desarrollar la necesidad, no el requisito. Luego, para ir más allá, debe comprender cómo las necesidades del negocio pueden cambiar con el tiempo, o le quedará una solución frágil.

Hay tantos lugares para dejar ganchos para la extensión y la configuración: interfaz web, XSA, a través de la capa BW, etc. Dudaría en hacer una regla rápida y dura sobre dónde deberían estar estos puntos. La gestión del cambio desde una perspectiva técnica rara vez tiene brillo, pero realmente vale la pena mantener tanto como sea posible "en el idioma del cliente", por así decirlo.

Laura Rossi: Estoy de acuerdo. Personalmente, creo que comprender el caso de negocios y el "lenguaje de negocios" para todo lo que he construido ha sido un área en la que he tenido que aprender más mientras trabajaba con TruQua, y realmente ha valido la pena. La mejor solución solo puede brillar si los usuarios lo entienden y lo necesitan. Y, por supuesto, tener una idea completa del caso de uso desde el principio le ahorra mucho trabajo en preguntas y respuestas. En definitiva, la solución debería funcionar para el cliente.

Conclusión

JS Irick: Muchas gracias por compartir tu perspectiva hoy, Laura. Las tecnologías emergentes en el panorama de SAP, incluidas HANA, SAP Analytics Cloud, Leonardo y S / 4HANA están brindando una oportunidad para que los consultores de carrera temprana ofrezcan un valor enorme. Me alegra que hoy tengamos un poco de tiempo para analizar cómo está ayudando a los clientes a superar sus mayores desafíos. ¡Gracias por compartir sus ideas, y espero volver a hablar pronto!

Laura Rossi: ¡Gracias por la oportunidad de compartir! Este es definitivamente un momento emocionante para estar en el ecosistema de SAP y las conversaciones como esta crean grandes oportunidades para el crecimiento y el intercambio de ideas. Definitivamente he aprendido mucho de todos los demás en TruQua, así que es genial unirse a la conversación.

Sobre nuestros colaboradores:

JS Irick tiene el mejor trabajo del mundo; trabajando con un equipo talentoso para resolver los desafíos comerciales más difíciles. JS es un orador reconocido internacionalmente en los temas de Aprendizaje automático, Planificación de SAP, SAP S / 4HANA y Desarrollo de software. Como Director de Ciencia de Datos e Inteligencia Artificial en TruQua, JS ha desarrollado las mejores prácticas para implementaciones de SAP en las áreas de informes SAP HANA, SAP S / 4HANA y personalización de SAP S / 4HANA.

Laura Rossi es consultora de SAP en TruQua y se especializa en la aplicación de la ciencia de datos a la planificación y análisis financieros. Laura es altamente experta en el desarrollo de aplicaciones de bases de datos nativas para resolver no solo los desafíos actuales del cliente, sino también para anticiparse y adaptarse a sus objetivos futuros. El trabajo de Laura en la "pila de planificación moderna" de SAP HANA, SAP S / 4HANA y SAP Analytics Cloud ayuda a proporcionar una base para la planificación empresarial colaborativa.

Gracias por leer nuestra primera entrega en nuestro Nuevas perspectivas serie de blogs Estén atentos para nuestra próxima publicación que contará con Andrew Xue, Consultor de SAP y sus ideas sobre la Planificación Empresarial Colaborativa.

Para obtener más información sobre los servicios y ofertas de TruQua, visítenos en línea en www.truqua.com. Para recibir notificaciones de futuras publicaciones en el blog e incluirse en nuestra lista de correo electrónico, complete el siguiente formulario.

Descubra cómo TruQua puede llevarlo más lejos, más rápido, juntos.

Servicios

Descubra cómo TruQua puede llevarlo más lejos, más rápido, juntos.

info@truqua.com
312.525.8787