Qumulo y Databricks han completado una integración conjunta que permite a los almacenes de lago empresariales abarcar todo el patrimonio de datos de una organización. Dondequiera que vivan los datos, en las instalaciones, en el borde o en cualquier nube importante, Databricks puede ahora leerlos, escribirlos y gobernarlos a través del almacenamiento Qumulo.
El lakehouse se ha convertido en la base de la analítica de datos moderna al combinar la apertura de un lago de datos con la gobernanza y fiabilidad de un almacén de datos. Las organizaciones lo adoptan para escapar de la dependencia de un proveedor, reducir costes y unificar sus análisis e IA en una única plataforma. Pero hasta ahora, los lakehouses se han limitado en gran medida a un solo sitio o al almacenamiento de objetos de un proveedor de nube en una sola región. Esto ha servido bien a la industria, pero la mayoría de las empresas tienen sus datos brutos y de nivel de bronce en todas partes: sensores de fábrica, datos de sucursales, imágenes médicas, registros de aplicaciones, registros transaccionales, todos generados y retenidos a través de centros de datos, sitios de borde y múltiples nubes. IDC prevé que los datos empresariales no estructurados crezcan aproximadamente un 16% CAGR hasta 2028 a 10,5 ZB, impulsados por la proliferación de sensores, IoT y cargas de trabajo de IA. Llevar la casa del lago a todos de esos datos, vivan donde vivan, es el siguiente paso arquitectónico.
Qumulo es una plataforma de datos definida por software que se ejecuta en las instalaciones, el perímetro y la nube como un único espacio de nombres global. Junto con Databricks, permite que el lago se extienda a todo el conjunto de datos sin necesidad de copiarlos o consolidarlos en un cubo en la nube. Las mismas tablas gobernadas pueden ser consultadas por Databricks en una región, por un trabajo de formación en las instalaciones y por una herramienta de BI en otra nube, contra una fuente de verdad.
Este post presenta tres patrones de integración validados entre Databricks y Qumulo para permitir diferentes arquitecturas lakehouse: (1) ejecutar análisis e IA de Databricks directamente contra datos en Qumulo, sin necesidad de volver a crear plataformas o migrar; (2) poner las tablas residentes en Qumulo bajo el gobierno de Unity Catalog, para obtener una única vista gobernada independientemente de dónde vivan los datos; y (3) compartir datos de Qumulo, solo de lectura, con otros espacios de trabajo de Databricks, otras nubes y herramientas que no sean de Databricks a través de Delta Sharing abierto. Para una guía de despliegue paso a paso, consulte la página Nota de integración de Qumulo y Databricks.
Figura 1. Arquitectura de alto nivel de los patrones de integración Qumulo-Databricks Arquitectura de alto nivel de los patrones de integración Qumulo-Databricks
Ventajas para los equipos de Databricks
Estos patrones ofrecen tres resultados a las organizaciones que adoptan Databricks:
Resultados más rápidos. Los datos existentes en Qumulo de registros sin procesar, imágenes, telemetría, genómica y registros de aplicaciones son leídos por Databricks in situ, lo que elimina los costes y el tiempo de migración masiva y los cargos de API de S3 por solicitud. Bajo cargas de prueba de validación, Qumulo vio los costes de almacenamiento relacionados con la API reducidos en un 60% o más y el tiempo hasta el primer resultado comprimido en un 40% o más en comparación con los flujos de trabajo equivalentes que organizaban los datos primero a través del almacenamiento de objetos en la nube.
Un ejemplar, muchos consumidores. Los mismos datos son utilizados simultáneamente por Databricks en la nube, por tareas de formación en las instalaciones, por aplicaciones de borde y por otras herramientas de análisis e IA. Todo el mundo trabaja con una única fuente de verdad en lugar de versiones que se separan en distintos entornos.
Gobernanza unificada sin migración masiva. Las tablas en Qumulo se rigen a través de Unity Catalog, con permisos, auditoría y linaje aplicados de forma consistente a los analistas y equipos de BI a través de cuadernos y cuadros de mando.
Tres patrones validados
Cada patrón posiciona los datos y la gobernanza de forma diferente, y la mayoría de las implantaciones de producción los combinan. Cabe señalar que los clientes pueden desplegar una combinación de estas integraciones.
Patrón A. Qumulo contiene los datos brutos e históricos, Databricks contiene las tablas curadas. Databricks compute lee los datos de origen en Qumulo, aplica transformaciones Silver y Gold, y escribe las tablas Delta curadas en el almacenamiento gestionado Unity Catalog. Los almacenes SQL sin servidor consultan las tablas Gold para BI y análisis. Lo mejor cuando una organización está empezando con Databricks y quiere su primera capa curada gobernada nativamente por Unity Catalog.
Patrón B. Todos los niveles de medallón (Bronce, Plata, Oro) viven en Qumulo como tablas Delta. Las tablas se registran en un Hive Metastore que Databricks federa en Unity Catalog. All-Purpose Compute lee y escribe a través de esta ruta; Serverless SQL Warehouses consulta a través de Unity Catalog. Es la mejor opción cuando una organización desea que toda su base de datos permanezca en Qumulo sin dejar de beneficiarse del gobierno, el linaje y la auditoría de Unity Catalog.
Patrón C: Con Delta Sharing, Qumulo puede exponer tablas Delta de sólo lectura a Unity Catalog y otros consumidores. Los Databricks y otras herramientas obtienen un acceso efímero a través del protocolo Delta Sharing, sin que se copien datos al consumidor. Esto es lo mejor para compartir datos de Qumulo a través de múltiples consumidores (otros espacios de trabajo Databricks, Snowflake, herramientas BI) y a través de múltiples nubes.
Los procedimientos paso a paso para los tres patrones se encuentran en el Nota de integración de Qumulo y Databricks.