SAP Datasphere y asociaciones – Databricks

Juntos con SAP DatasphereSAP lanzó nuevas asociaciones para completar el panorama de la gestión de datos analíticos y la idea de Business Data Fabric.

Fig. 1: SAP Datasphere & Partnerships – Fuente: SAP, 2023 (ligeramente adaptado)

Ya di una impresión de los nuevos socios en mi blog “SAP Datasphere: preguntas y respuestas y asociaciones“. Como quiero enfocarme aquí en Databricks, repito lo que he escrito:

Ladrillos de datos

Databricks fue fundado por los creadores de Apache Spark y construyen un ecosistema completo alrededor, entregando el Lago de datos basado en una estrategia multinube similar a SAP. En términos simples, se puede entender que Data Lakehouse reúne formatos de archivo modernos (parquet apache (ladrillos de datos), Apache ORCO, apache avro) con formatos de tabla abiertos (lago delta (ladrillos de datos), iceberg apache, apache hudi) con un potente motor de consultas distribuidas para procesar datos (Fotón para ladrillos de datos).

La ventaja de un Data Lakehouse es tener todo tipo de datos (estructurados, semiestructurados, no estructurados) en un nivel y servir todos sus roles de datos como ingeniero de datos, analista de datos, científicos de datos, modelador de BI, etc., desde este nivel. .

Databricks acuñó el término «Data Lakehouse» y es el principal socio en esta área, incluso si otros también ofrecen tecnologías de Data Lakehouse.

Recientemente entré en algunas discusiones sobre lo que significan los Databricks para los expertos de SAP Data Warehouse y especialmente para SAP Datasphere. ¿Se convertirán ahora los Databricks en el nuevo enfoque de SAP Data Warehouse? ¿No hace Databricks lo mismo que SAP Datasphere? ¿Debería aprender más sobre Databricks y mejorar?

Así que aquí están mis pensamientos sobre estas preguntas.

Conocer los patrones de arquitectura de datos

Primero tenemos que diferenciar entre los patrones de arquitectura que vemos aquí.

SAP Datasphere era anteriormente SAP Data Warehouse Cloud, disponible desde finales de 2019. Entonces, básicamente, sigue siendo un servicio basado en la nube. Almacén de datos basado en la tecnología SAP HANA Cloud incl. Data Lake, Machine Learning y Data and Business Layer que soportan el caso de uso de Data Warehouse y diferentes tipos de grupos de usuarios.

SAP Datasphere ahora está evolucionando hacia un Business Data Fabric. Tejido de datos es un enfoque para unificar el acceso y la gestión de todos los datos dentro de una empresa (en el mejor de los casos) y hacerlos más disponibles. Por lo tanto, Data Fabric puede verse como un enfoque para la democratización de los datos y la ruptura de los silos de datos. SAP entregó nuevas capacidades como el catálogo (de datos), la tarea de replicación y pronosticó nuevas capacidades semánticas. Ver aquí para las nuevas capacidades.

Por otro lado, Databricks ofrece un enfoque de Data Lakeouse, una evolución de los enfoques combinados de Data Lake/Data Warehouse habilitados dentro de un solo nivel técnico. Una vez ya analicé el enfoque de SAP en mi blog “Arquitectura de datos con SAP – Data Lake” y llegué a la conclusión de que SAP no está allí en este momento, pero tiene un enfoque útil propio dentro de la oferta de SAP HANA Cloud Data Lake.

Qué significa Data Lakehouse

En general, hay mucho movimiento en el mercado de gestión de datos en la nube y todas las ofertas actualmente evolucionan en la dirección de convertirse en una especie de Data Lakehouse, que proviene de diferentes direcciones y trata de encontrar allí la diferenciación:

Fig. 2: Posicionamiento y tendencia de las ofertas populares de plataformas de datos en la nube

Podemos entrar un poco en detalle para entender las diferentes posiciones.

Soluciones como Databricks Data Lakehouse y también Google BigQuery nacen en la nube. Desde el principio, hacen uso de las capacidades de la nube, como la separación del almacenamiento y la computación para una mejor escalabilidad, con una arquitectura de almacenamiento compartido y procesamiento paralelo distribuido. Estas soluciones siguen el enfoque de lectura de esquema, que es muy popular en el campo de la ciencia de datos, ya que brinda libertad para modelar los datos y se sirve en el almacenamiento de objetos para que cualquier tipo de datos, como textos, documentos, imágenes, videos o sonido no estructurados. se puede almacenar fácilmente.

Usan motores de procesamiento paralelo como Apache Spark y una red interna altamente optimizada para mover y procesar datos muy rápido.

Desde hace mucho tiempo, los formatos de archivo están disponibles para almacenar datos estructurados basados ​​en columnas y comprimidos (como lo hace HANA) para un mejor rendimiento de lectura. El paso a Data Lakehouse vino con formatos de tablas abiertas como Delta Lake para Databricks, que trajo capacidades esenciales de Data Warehouse como ÁCIDO o seguridad de nivel de fila al lago de datos.

Ya iniciado con el desarrollo de Apache Hive en 2010 surgió la idea de utilizar Big Data (Hadoop) para casos de uso de Data Warehouse pudiendo realizar consultas tipo SQL. Hoy en día, los potentes motores de consultas paralelas como Photon para Databricks habilitan la parte de almacenamiento de datos para Data Lakehouse.

Por otro lado, tenemos soluciones que evolucionan desde sistemas de administración de bases de datos relacionales (RDMS) locales, como Azure Synapse Analytics, Amazon Redshift o SAP HANA Cloud como base de SAP Datasphere, como hoy (típicamente) Massively Parallel Processing (MPP) Cloud Data Almacenes con inicialmente una arquitectura compartida como Hadoop, que combina almacenamiento y computación. Para la mayoría de las soluciones, hemos visto un desacoplamiento a lo largo del tiempo para hacer uso de la escalabilidad y la elasticidad de la nube. SAP HANA está actualmente en camino de dar pasos aquí, lo que es un gran paso, ya que la gran diferencia es aquí una base de datos basada en memoria. A través de la pirámide de datos de SAP (HANA Cloud, HANA Relational Data Lake y HANA Data Lake Files), ya vemos una especie de separación y la forma en que SAP maneja esta evolución con su propia tecnología.

También me di cuenta de que las soluciones que venían de esta dirección también trasladaron el almacenamiento al lago de datos y habilitaron en gran medida formatos de tabla como Apache Hudi o Apache Iceberg que habilitan capacidades de almacenamiento de datos en el lago de datos. Actualmente, esto no está disponible para SAP HANA Cloud. Pero con su arquitectura basada en memoria, la tecnología SAP IQ como una capa intermedia y SQL en archivos para consultar el lago de datos, SAP quizás tenga un enfoque alternativo, pero hoy no he visto mucho uso práctico en el mercado aquí. .

Hasta ahora, la pregunta es si Databricks y SAP Datasphere están haciendo lo mismo o no. Lo hacen en algunas partes y no como SAP tienen aspectos, mercados y clientes propios.

Conclusión

Si bien ahora Databricks evoluciona cada vez más su plataforma de datos, abordando nuevos casos de uso, el enfoque es administrar físicamente todo tipo de datos, especialmente big data y cargas de trabajo de aprendizaje automático. El Data Warehouse es posible y aún más, ya que nos trae el Data Lakehouse.

Por otro lado, SAP Datasphere está optimizado para SAP, ofrece contenido, una sólida perspectiva comercial y, con el enfoque de Data Fabric, no se trata de tener todos los datos integrados para el procesamiento, sino de dirigir el acceso y la organización de los datos empresariales independientemente de qué datos del sistema. está almacenado.

A medida que las empresas se basan cada vez más en los datos, SAP ya no es la única solución para la gestión de datos analíticos. Aceptar eso y dar el siguiente paso para ser la única cara del usuario final en lo que respecta a los datos es un movimiento estratégico, ya que SAP ya lo es con frecuencia en el mundo de los sistemas comerciales transaccionales.

Actualmente entendíamos qué es SAP Data Warehouse Cloud y ahora tenemos una visión de lo que se convertirá SAP Datasphere. SAP tiene que entregar para qué, cómo lo formularía el DSAG alemán, es un «trabajo en progreso».

Asociarse con jugadores fuertes del mercado como Databricks tiene sentido, ya que todos sabemos que implementar una visión formulada con SAP Datasphere es difícil y es un camino a seguir. Adoptar socios fuertes, habilitar la integración con un amplio ecosistema que no sea de SAP, pero también confiar en las propias fortalezas, es el camino correcto desde mi perspectiva.

SAP no debe esperar que suceda simplemente con nuevas funcionalidades. El «Lanzamiento de la metodología de asesoramiento de datos y análisis de SAP” es un movimiento inteligente, ya que se vuelve más importante comprender los casos de uso estratégico, pero también pintar una imagen holística de datos y análisis para que el cliente encuentre el lugar adecuado para SAP dentro de esta imagen. Espero que veamos más casos de uso de socios y arquitecturas de referencia de socios la próxima vez.

Esta es solo mi opinión y perspectiva actual. Me alegra saber de usted cómo ve estas nuevas asociaciones en el contexto de SAP Datasphere.