¿Qué es un lakehouse abierto? Explicación de los estándares de datos abiertos.

Un lakehouse abierto es un lakehouse de datos en el que cada capa (almacenamiento, formato de tabla, motor, catálogo y las herramientas de ML y AI en la parte superior) está construida sobre estándares abiertos, por lo que ninguna capa está vinculada a un único proveedor.

Un lakehouse de datos combina el almacenamiento escalable y de bajo costo de un data lake con las funciones de gestión y las garantías transaccionales de un data warehouse. Un lakehouse abierto añade una condición adicional: cada capa de la arquitectura está construida sobre estándares abiertos. Los datos, los motores que los procesan, el catálogo que los gobierna y las herramientas que crean modelos y aplicaciones sobre ellos son de código abierto, por lo que ninguno depende de un único proveedor.

La palabra "abierto" se utiliza mucho, y no siempre de manera honesta. Por eso vale la pena definirla con precisión. Un formato puede llamarse abierto y, aun así, ser práctico de usar solo a través de un único motor. Un catálogo puede llamarse abierto y seguir vinculado a una sola plataforma. El almacenamiento sigue siendo portable justo hasta que las tarifas de salida de datos hacen que moverlo sea costoso. Un lakehouse abierto es lo que se obtiene cuando se eliminan esas restricciones en cada nivel. Más recientemente, esa misma apertura se ha extendido a las cargas de trabajo de AI y de agentes que ahora se construyen sobre los datos.

¿En qué se diferencia un lakehouse abierto de un data lake y de un data warehouse?

Un lakehouse abierto combina la confiabilidad de un data warehouse y el almacenamiento de bajo costo de un data lake en una sola arquitectura, y luego añade una regla de la que carecen los otros dos: cada capa debe ser abierta e intercambiable. Un data warehouse contiene tablas limpias y estructuradas para la generación de informes, con un gobierno sólido pero a un costo elevado y con poco espacio para datos no estructurados. Un data lake almacena todo lo demás, como archivos sin procesar, registros (logs) e imágenes, de manera económica y a escala, pero sin transacciones, garantías de esquema ni mucho gobierno.

El lakehouse no apareció de la nada. Durante años, los equipos mantuvieron ambos sistemas de forma paralela, copiando datos entre ellos y conciliando dos versiones de la realidad. El lakehouse de datos los fusionó: gestión al estilo de un data warehouse y transacciones aplicadas directamente al almacenamiento de bajo costo del data lake. El lakehouse abierto es el siguiente paso de esa idea. Mantiene la arquitectura combinada y añade la regla anterior, de modo que la confiabilidad de un data warehouse y la rentabilidad de un data lake se obtienen sin vincular ninguna capa a un único proveedor.

Lakehouse abierto frente a propietario: ¿cuál es la diferencia?

La diferencia entre un lakehouse abierto y uno propietario se reduce a una pregunta: quién puede leer sus datos y qué motores pueden ejecutarse en ellos. Un lakehouse propietario almacena los datos en formatos que solo un proveedor puede leer, por lo que cambiar de herramienta puede requerir reescribir o volver a exportar todos sus datos. Un lakehouse abierto almacena los datos en formatos abiertos que cualquier motor compatible puede leer, de modo que puede añadir, cambiar o eliminar un motor de consultas sin tener que reescribir sus datos.

¿Qué hace que un lakehouse sea abierto?

Tres elementos diferencian a un lakehouse abierto de uno propietario: formatos abiertos, motores abiertos y un gobierno unificado.

Comencemos con los formatos abiertos. Los datos residen en formatos de tabla abiertos, Delta Lake y Apache Iceberg®, que se apoyan en formatos de archivo abiertos como Apache Parquet®. Las especificaciones son públicas, por lo que cualquier motor que las implemente puede leer y escribir los datos, no solo el entorno de ejecución de un único proveedor.

A continuación, los motores abiertos: los sistemas que realizan el procesamiento también son de código abierto. Apache Spark® abarca procesamiento por lotes, streaming, SQL y machine learning en un solo entorno de ejecución y, dado que las tablas subyacentes son abiertas, motores como DuckDB, Trino o PyIceberg pueden trabajar con los mismos datos sin necesidad de una segunda copia.

El gobierno unificado es la parte que los equipos suelen subestimar. Un único catálogo gestiona el control de acceso, el linaje y la auditoría para cada formato y cada motor, de modo que el gobierno se asocia a los propios datos en lugar de tener que reconstruirse dentro de cada herramienta que interactúa con ellos. Unity Catalog desempeña ese papel aquí.

Al combinar todo esto, el resultado es abierto desde la capa de almacenamiento hasta la capa de servicio: almacenamiento de objetos en la base, un formato de tabla abierto encima, un motor de procesamiento abierto, un catálogo abierto para el gobierno y herramientas abiertas para analítica, machine learning y aplicaciones de AI en la parte superior.

¿Es lo mismo "abierto" que código abierto (open source)?

No del todo, y la diferencia es importante. El código abierto (open source) describe la licencia del código de un proyecto. "Abierto", en el sentido del lakehouse, es más amplio: abarca formatos abiertos de archivos y tablas, APIs abiertas y formas estándar para que las herramientas se conecten, además de un ecosistema donde muchos motores trabajan con los mismos datos. Una plataforma puede estar construida a partir de proyectos de código abierto y, aun así, atrapar sus datos, por ejemplo, al almacenarlos en una estructura que solo su propio motor lee bien. La prueba de fuego de la apertura es sencilla: poder leer sus datos con cualquier herramienta compatible y moverse entre herramientas sin tener que reescribirlos.

Formato de tabla abierto frente a lakehouse abierto: ¿cuál es la diferencia?

Estos dos términos se suelen utilizar indistintamente, pero no debería ser así. Un formato de tabla abierto es una sola capa: añade características similares a las de una base de datos (actualizaciones confiables, cambios de esquema e historial) sobre los archivos en el almacenamiento de objetos. Un lakehouse abierto es todo lo que rodea a esa capa: el almacenamiento debajo de ella y el procesamiento (compute), el catálogo y el gobierno en la parte superior. El formato de tabla es un componente. El lakehouse es toda la pila (stack).

Dos términos de la tabla: ACID significa que los cambios en los datos se completan de manera confiable sin corromper la tabla, y viaje en el tiempo (time travel) significa que puede ver o restaurar los datos tal como se veían en un momento anterior.

¿Qué estándares abiertos impulsan un lakehouse abierto?

Esta arquitectura de referencia está construida a partir de cinco estándares de código abierto, cada uno gobernado por una fundación neutral (la Apache Software Foundation o the Linux Foundation) y cada uno propietario de una capa diferente de la pila (stack). Un lakehouse abierto es tan confiable como los proyectos a partir de los cuales se construye, y estos no son proyectos de nicho: son estándares sobre los que ya funciona gran parte de la industria, y la mayoría de ellos se crearon en Databricks. Esto no es falsa modestia, es algo comprobable: a principios de 2026, Apache Spark es utilizado por alrededor del 80% de las empresas de Fortune 500 y es el motor más adoptado para el procesamiento de datos a gran escala. MLflow supera los 30 millones de descargas al mes. Delta Lake y Apache Iceberg cubren juntos la gran mayoría de las tablas de lakehouse en producción, siendo Delta Lake el que cuenta con la mayor base instalada.

En conjunto, esto representa más de 90,000 estrellas de GitHub y decenas de millones de descargas al mes. Un resumen de la situación de cada proyecto (estrellas de GitHub a principios de 2026):

Apache Spark

Apache Spark® es el motor de procesamiento. Fue creado en el AMPLab de UC Berkeley en 2009 por el equipo que luego fundó Databricks, y fue donado a la Apache Software Foundation, donde se convirtió en uno de los motores más utilizados para el procesamiento de datos a gran escala. Un único entorno de ejecución de Spark maneja trabajos por lotes (batch), streaming, SQL y aprendizaje automático, por lo que un equipo puede ejecutar un solo motor en lugar de mantener un sistema diferente para cada tipo de carga de trabajo. En el lakehouse, Spark lee datos sin procesar, los depura por etapas y vuelve a escribir los resultados como tablas abiertas.

Delta Lake

Delta Lake es un formato de tabla que hace que el almacenamiento de objetos se comporte como una base de datos en lugar de un cúmulo de archivos. Sobre los archivos Parquet ordinarios, añade transacciones ACID, cumplimiento de esquemas y viaje en el tiempo, de modo que los trabajos simultáneos no corrompen las escrituras de los demás y se puede consultar una tabla tal como se veía en un momento anterior. Una biblioteca complementaria, Delta Kernel, empaqueta la lógica de lectura y escritura en un componente independiente del motor, lo que facilita que otros motores distintos de Spark admitan el formato. Delta Lake se creó en Databricks, que sigue siendo su principal colaborador, y se gestiona como un proyecto de la Linux Foundation.

Apache Iceberg

Iceberg es un segundo formato de tabla, diseñado para tablas analíticas muy grandes y para moverse de manera fluida entre motores. Surgió de Netflix en lugar de Databricks, y ahora es un proyecto de Apache ampliamente adoptado. Databricks es un colaborador importante, incluido el equipo fundador de Iceberg que se unió a través de la adquisición de Tabular. Su especificación de tabla y su catálogo REST facilitan que varios motores compartan las mismas tablas, razón por la cual aparece siempre que hay más de un motor de consultas en juego. Admitir tanto Delta Lake como Iceberg significa que un equipo no tiene que comprometerse con un solo formato desde el primer día y vivir con esa elección para siempre.

Unity Catalog

Unity Catalog es la capa de gobernanza. Mantiene las políticas de acceso, la entrega de credenciales y el linaje en un solo lugar, y los motores acceden a los datos a través de él en lugar de esquivarlo. Debido a que las reglas residen en el catálogo en lugar de dentro de un motor específico, el control de acceso y el linaje se mantienen consistentes ya sea que la consulta provenga de Spark, DuckDB u otro cliente. Unity Catalog se creó en Databricks y ahora es un proyecto de código abierto bajo la LF AI & Data Foundation, con una versión administrada disponible en Databricks. La versión de código abierto es más reciente que el producto administrado, y algunas características de gobernanza aún se están consolidando en ella, por lo que vale la pena contrastar el proyecto abierto con sus requisitos.

Unity Catalog no es el único catálogo abierto. Apache Polaris, Project Nessie, Hive Metastore y AWS Glue cumplen la misma función, y el catálogo REST de Iceberg está emergiendo como una interfaz compartida entre ellos. Un lakehouse abierto puede usar cualquiera de ellos. Esta arquitectura de referencia utiliza Unity Catalog porque gobierna los activos de datos, ML y AI de manera conjunta bajo un solo modelo, pero la capa de catálogo es verdaderamente intercambiable.

MLflow

MLflow es la capa para el aprendizaje automático y la AI. Se encarga del seguimiento de experimentos, el empaquetado de modelos, el registro de modelos, la evaluación y el servicio de modelos (serving), y esa misma maquinaria ahora llega a los agentes de AI: rastreando lo que hizo un agente, puntuando sus resultados frente a evaluadores y colocando una pasarela (gateway) con límites de presupuesto y medidas de protección frente a él. Ejecutar modelos y agentes en la misma plataforma abierta que gobierna los datos, en lugar de en un entorno separado e independiente, es en gran parte lo que hace diferente a esta versión del lakehouse. MLflow se creó en Databricks, que sigue siendo su principal colaborador, y es un proyecto de la Linux Foundation.

¿Cómo funcionan juntas las capas de un lakehouse abierto?

Las capas se conectan a través de interfaces abiertas, por lo que encajan sin necesidad de un nexo propietario y cualquiera de ellas se puede cambiar sin alterar las demás. Eso es lo que convierte cinco proyectos en una sola arquitectura.

Comienza con los datos. Spark escribe tablas en el almacenamiento de objetos como Delta Lake o Iceberg. Debido a que esos formatos son abiertos, y a que Delta Kernel y el catálogo REST de Iceberg los exponen de manera neutral, otros motores leen los mismos archivos directamente. No es necesario copiar nada primero en un almacenamiento propietario, y no hay ningún paso de exportación al final.

La gobernanza abarca todo esto. Cada motor accede a los datos a través de Unity Catalog, por lo que una política escrita una sola vez se aplica en todas partes. Incorporar un nuevo motor de consultas significa apuntarlo al catálogo, no volver a crear las reglas de acceso y el linaje desde cero.

Los modelos y agentes se basan en los mismos datos gobernados. Un modelo entrenado en MLflow lee las tablas Gold que produjo Spark. Un agente que responde a una pregunta realiza consultas a través de Unity Catalog bajo las mismas políticas que lo haría un analista humano. El linaje que conecta la entrada de datos sin procesar con un modelo implementado o la respuesta de un agente se registra a lo largo del camino. La capa de AI no está acoplada a la fuerza al final; lee y escribe a través de la misma superficie gobernada que todo lo demás.

La recompensa práctica es la independencia entre las capas. Un equipo puede cambiar los motores de procesamiento, agregar un motor de consultas, adoptar un segundo formato de tabla o incorporar un marco de trabajo (framework) de modelos diferente sin tener que migrar de plataforma las capas superiores o inferiores, porque cada capa depende únicamente de la interfaz abierta de su vecina.

¿Cuáles son los beneficios de un lakehouse abierto?

El principal beneficio de un lakehouse abierto es la opcionalidad: los equipos mantienen abiertas sus opciones a medida que crecen las necesidades de datos y AI, porque ninguna capa de la plataforma está vinculada a un proveedor. Los beneficios específicos son:

• Sin dependencia de proveedores: los formatos abiertos permiten a los equipos cambiar de herramientas sin migrar ni volver a escribir los datos.
• Menor costo: una sola copia de los datos en un almacenamiento económico evita duplicarlos en varios sistemas.
• Multimotor: muchos motores pueden ejecutarse sobre los mismos datos para BI, SQL y aprendizaje automático.
• Gobernanza unificada: un único catálogo aplica controles de acceso y linaje consistentes.
• Listo para la AI: los datos unificados y confiables respaldan el entrenamiento de modelos, los almacenes de características (feature stores) y los agentes de AI.
• Libertad de nube: las cargas de trabajo se pueden ejecutar en múltiples nubes sin necesidad de reconstruirlas.

¿Cómo escala un lakehouse abierto a medida que crece?

Un lakehouse abierto escala agregando capas, no cambiando de plataforma: se activan más capas a medida que el trabajo lo requiere, y las primeras capas permanecen en su lugar a medida que llegan las posteriores. El mismo esquema se adapta a un equipo de dos personas y a una empresa distribuida en varias regiones; la diferencia es simplemente cuántas capas están activadas.

• ETL básico. Almacenamiento de objetos, tablas Delta y Spark. Los datos sin procesar llegan a Bronze, se depuran en Silver y se sirven desde Gold. Esa configuración de medallón es una pila abierta completa por sí sola.
• Streaming y procesamiento por lotes (batch) juntos. Cuando los datos deben procesarse a medida que llegan, Spark Structured Streaming y el Real-Time Mode ejecutan streaming junto con el procesamiento por lotes en el mismo motor, con Spark Declarative Pipelines describiendo las transformaciones. No se requiere un segundo sistema de streaming.
• Un catálogo compartido y los primeros agentes. Una vez que los analistas, las aplicaciones, los dashboards y el machine learning necesitan los mismos datos, Unity Catalog se convierte en la capa de gobernanza común a través de la cual leen. Aquí es también donde suelen aparecer los primeros agentes, que monitorean la calidad de los datos, diseñan pipelines y exploran el linaje, todo gobernado a través del catálogo como cualquier otro consumidor.
• Escala empresarial. A través de regiones y nubes, Unity Catalog añade la entrega de credenciales (credential vending), políticas detalladas, Lakehouse Federation y Delta Sharing, y Spark se ejecuta como una flota gestionada en Kubernetes. La base es la misma; solo hay más gobernanza y más capacidad de cómputo.

¿Cómo encaja la AI en un lakehouse abierto?

En un lakehouse abierto, las aplicaciones y los agentes de AI son cargas de trabajo de primera clase gobernadas exactamente como cualquier otro consumidor de datos, no un sistema separado añadido a posteriori. La mayoría de las explicaciones sobre lakehouse se quedan en business intelligence y machine learning, lo que a estas alturas parece un diagrama de 2021 con una caja de AI pegada a un lado. Tratar a los agentes como consumidores gobernados de los mismos datos es lo que realmente hace que esta versión esté actualizada.

Dado que MLflow se ejecuta en la plataforma que gobierna los datos, un agente está sujeto a las mismas reglas que todos los demás. Lee a través de Unity Catalog, por lo que solo ve lo que permiten sus permisos. Su actividad se rastrea y sus respuestas son evaluadas por evaluadores en MLflow, de la misma manera que se realiza el seguimiento de la calidad de un modelo, y la pasarela (gateway) que tiene delante puede limitar el gasto y aplicar medidas de seguridad (guardrails). Nada de eso requiere un entorno de AI separado con su propia copia de los datos y su propia gobernanza más débil, que suele ser la alternativa habitual.

Concretamente:

• Atribución: un agente se ejecuta con su propia identidad, por lo que cada acción se rastrea hasta una entidad principal en lugar de ocultarse detrás de una cuenta compartida.
• Credenciales de alcance limitado: el catálogo emite credenciales de corta duración y alcance limitado en lugar de claves de larga duración, por lo que el acceso de un agente se puede limitar y revocar como el de cualquier otro.
• Linaje: las lecturas y escrituras de un agente se registran, por lo que la ruta desde los datos de origen, pasando por la recuperación, hasta una respuesta se puede reconstruir para una auditoría.
• Gasto y guardrails: los límites de presupuesto y los controles de contenido residen en el gateway, fuera del propio código del agente.
• Modo de fallo: debido a que el acceso se realiza a través del catálogo, lo que sucede cuando el catálogo no está disponible es una decisión de diseño explícita, como denegar el acceso en lugar de recurrir a lecturas directas y no gobernadas.

La identidad de un agente puede ser su propia entidad principal de servicio (service principal) o una delegación del usuario que lo invocó (un modelo en nombre de otro), y esa elección decide cómo aparecen sus acciones en el registro de auditoría. Y la ruta independiente de MLflow que se describe más adelante le ofrece rastreo y evaluación sin necesidad de un lakehouse, pero el control de acceso impuesto por el catálogo mencionado anteriormente solo se aplica una vez que Unity Catalog está implementado.

En la práctica, esto es concreto. Un agente solicita una columna para la que no tiene permisos; Unity Catalog deniega la lectura y el registro de auditoría registra la identidad del agente, la tabla y la columna que solicitó, la hora y la decisión de denegación. Para las consultas que tiene permitidas, el linaje vincula su respuesta con las tablas Gold específicas que lee.

El objetivo no es que los agentes reemplacen el resto de la arquitectura, sino que se integren en ella. Un agente es un consumidor más de datos gobernados, creado y supervisado con las mismas herramientas abiertas que los pipelines y modelos que lo rodean.

¿Realmente necesita un lakehouse abierto?

No siempre: un lakehouse abierto es la opción correcta cuando la apertura y la escala demuestran su valor, y una exageración cuando no lo hacen. Es una excelente opción cuando tiene muchos tipos de datos, múltiples equipos o motores que comparten los mismos datos, requisitos multinube o un objetivo claro de evitar la dependencia de un proveedor (lock-in). Puede ser excesivo para una carga de trabajo pequeña con una sola herramienta, con datos simples y estructurados, y sin necesidad de moverse entre herramientas.

Un enfoque práctico es comenzar con un piloto de alcance limitado vinculado a un requisito real, por ejemplo, federar una fuente existente o mover un pipeline, antes de comprometerse con una migración completa. La arquitectura está diseñada para adoptarse una capa a la vez, por lo que la elección no es entre todo o nada.

¿Se puede migrar a un lakehouse abierto de forma incremental?

Sí. Un lakehouse abierto está diseñado para adaptarse junto a lo que ya ejecuta, una capa a la vez, en lugar de pedirle que desmantele primero su infraestructura actual. Pocos equipos empiezan de cero; la mayoría ya ejecuta un data warehouse en la nube, o EMR, o un catálogo de datos, o una migración a Iceberg a medio terminar.

• En un data warehouse en la nube existente: fedérelo a través de Unity Catalog para que la gobernanza y el linaje lleguen a él, y deje los datos donde están.
• En EMR Spark: mueva solo la capa de creación de pipelines a Spark Declarative Pipelines y conserve los clusters que ya ejecuta.
• En un catálogo independiente: haga que Unity Catalog emita eventos de linaje abiertos que su catálogo existente ingiera, para que ambos funcionen en paralelo.
• A mitad de camino en la migración a Iceberg: coloque Unity Catalog sobre el catálogo que ya ha configurado y no cambie nada más.

El proceso es el mismo cada vez: reemplace una capa con una versión abierta y deje el resto como está hasta que haya una razón para cambiarlo.

¿Qué es lo realmente difícil de un lakehouse abierto?

Un lakehouse abierto tiene desafíos reales, y un análisis honesto debe mencionarlos. Los formatos de tabla abiertos acumulan archivos pequeños y necesitan compactación y mantenimiento regulares. Escribir en las mismas tablas desde varios motores a la vez es todavía menos maduro que leer de ellas, por lo que las escrituras multimotor requieren cuidado. Las versiones de código abierto de algunos componentes van por detrás de sus versiones gestionadas en algunas características. Y alojar por cuenta propia (self-hosting) toda la infraestructura es un trabajo operativo real. La apertura en las capas de formato y catálogo tampoco elimina todas las formas de dependencia del proveedor (lock-in). Los entornos de ejecución (runtimes) gestionados, los aceleradores de consultas propietarios y los precios de cómputo son los aspectos donde las plataformas aún lo retienen, y vale la pena evaluarlos por separado de las capas abiertas. Nada de esto va en contra de la arquitectura. Es el costo honesto de ser dueño de cada capa.

¿Cómo puede ejecutar usted mismo un lakehouse abierto?

Dado que cada capa es de código abierto, puede ejecutar todo usted mismo. Existe una implementación de referencia abierta que configura las capas de forma conjunta:

Eso inicia Apache Spark, Apache Kafka®, Apache Airflow®, Apache Iceberg, Delta Lake, Unity Catalog y MLflow localmente bajo Docker, con configuraciones para implementarlo en la nube. Si al principio todo lo que necesita es la capa de AI, puede comenzar con MLflow por su cuenta: un pip install y unas pocas líneas en una aplicación existente son suficientes, y puede agregar el resto más tarde.

Por ejemplo, puede apuntar MLflow a un agente existente sin ningún lakehouse debajo:

Su agente de LangGraph o OpenAI se ejecuta sin cambios, y sus trazas (traces), prompts y llamadas a herramientas (tool calls) aparecen en MLflow. Su Postgres, base de datos vectorial (vector store) y proveedor de modelos se quedan donde están. Solo agregará el lakehouse gobernado debajo cuando sus agentes necesiten datos empresariales gobernados.

El repositorio de referencia tiene licencia Apache 2.0 y es mantenido por el equipo de relaciones con desarrolladores de Databricks. No es tecnología nueva: son los cinco proyectos probados mencionados anteriormente, conectados entre sí con Docker para cuando desee tener toda la infraestructura en un solo lugar. Cada capa también funciona de forma independiente; el paquete es una comodidad, no una dependencia. Ejecutar un lakehouse abierto por su cuenta es realista, pero requiere un trabajo real, y el repositorio lo trata de esa manera: incluye patrones de alta disponibilidad, configuraciones de implementación y observabilidad para que el alojamiento por cuenta propia (self-hosting) sea una opción admitida y no solo una promesa.

¿Qué cambia un lakehouse abierto para su rol?

• Si escribe SQL o dbt: Spark Declarative Pipelines le ofrece la misma creación declarativa y orientada a SQL que conoce de dbt, y añade streaming junto con procesamiento por lotes (batch) y soporte completo de SQL y Python en un solo motor, todo ello frente a tablas abiertas gobernadas que aún puede consultar desde su herramienta de BI existente.
• Si crea pipelines de datos: los diseña una vez, por ejemplo con Spark Declarative Pipelines, y ejecuta procesamiento por lotes (batch) y streaming en un solo motor.
• Si crea modelos o agentes: los crea, evalúa y sirve en MLflow con los mismos datos gobernados, bajo las mismas reglas de acceso que todos los demás.
• Si ejecutas la plataforma: añades capas a medida que el negocio crece y puedes sustituir cualquiera de ellas sin tener que migrar el resto a una nueva plataforma.

¿Qué plataformas admiten lakehouses abiertos?

Actualmente, varias plataformas implementan los principios de lakehouse abierto. Databricks, Snowflake, Google Cloud, Microsoft Fabric, Cloudera, Dremio, Starburst y Qlik ofrecen productos en este ámbito. Se trata de productos creados sobre la base de las ideas de lakehouse abierto, no de la arquitectura en sí, y difieren en el nivel de apertura real de cada capa.

Databricks creó la categoría de lakehouse y ofrece un rendimiento de nivel de data warehouse sobre una base abierta, utilizando Delta Lake y Apache Iceberg para el almacenamiento y Unity Catalog para el gobierno. La Plataforma de Databricks ofrece esto como un servicio gestionado para los equipos que prefieren no ejecutar la pila tecnológica por sí mismos.

Preguntas frecuentes

¿Es lo mismo un lakehouse abierto que un data lakehouse?

Un data lakehouse es la arquitectura: gestión de tipo data warehouse sobre almacenamiento de lago. Un lakehouse abierto es un data lakehouse en el que cada capa (almacenamiento, formato de tabla, motor, catálogo y las herramientas de ML y AI integradas) es de código abierto e intercambiable, por lo que ninguna capa depende de un único proveedor.

Iceberg o Delta Lake: ¿cuál debería usar?

Ambos son formatos de tabla abiertos con transacciones ACID, evolución de esquemas y viaje en el tiempo (time travel), y un lakehouse abierto puede usar cualquiera de los dos o ambos. Delta Lake se integra estrechamente con Spark y, a través de Delta Kernel, es cada vez más compatible con otros motores; Iceberg está diseñado para un amplio acceso multimotor a través de su catálogo REST. Admitir ambos significa que no es necesario tomar la decisión de antemano.

¿Necesito los cinco proyectos para tener un lakehouse abierto?

No. La arquitectura está diseñada para crecer. Un lakehouse abierto básico es simplemente almacenamiento de objetos, un formato de tabla y Spark. Unity Catalog y MLflow se añaden cuando el gobierno entre muchos consumidores y las cargas de trabajo de machine learning o AI entran en juego.

¿Puedo ejecutar un lakehouse abierto sin Databricks?

Sí. Cada capa es de código abierto y se ejecuta en tu propia infraestructura. La implementación de referencia inicia toda la pila de forma local con Docker, y la capa de machine learning se puede usar por sí sola con un simple pip install. Databricks ofrece versiones gestionadas de estos componentes abiertos, pero el alojamiento propio es una opción compatible.

¿Dónde encajan los agentes de AI en un lakehouse abierto?

Los agentes se tratan como consumidores gobernados de datos, no como un sistema independiente. Leen a través de Unity Catalog bajo las mismas políticas que las personas y otros motores, y se crean, rastrean y evalúan en MLflow junto con los modelos, lo que mantiene la capa de AI dentro de la misma arquitectura abierta y gobernada en lugar de ser un añadido externo.

¿Cuánto cuesta un lakehouse abierto?

Los componentes de código abierto son de uso gratuito bajo las licencias Apache 2.0 y Linux Foundation; tus costes serán el almacenamiento de objetos, el cómputo que ejecutes y el esfuerzo operativo para mantener la pila. Gestionarlo tú mismo cambia el coste de las licencias por tiempo de ingeniería, mientras que una plataforma gestionada como Databricks cambia el tiempo de ingeniería por una suscripción, sobre la misma base abierta.

¿Está un lakehouse abierto listo para producción?

Sí. Los cinco proyectos principales son estándares maduros que ya se ejecutan en producción a gran escala; por ejemplo, Apache Spark en aproximadamente el 80 % de las empresas de Fortune 500 y MLflow con más de 30 millones de descargas al mes. Las principales consideraciones para producción son operativas: el mantenimiento y la compactación de tablas, el cuidado con las escrituras multimotor y el trabajo de alojamiento propio si no utilizas un servicio gestionado.

Apache, Apache Spark, Apache Iceberg, Apache Kafka, Apache Airflow, Apache Parquet y el logotipo de Apache feather son marcas comerciales registradas o marcas comerciales de Apache Software Foundation en los Estados Unidos y/u otros países. Delta Lake, MLflow y Unity Catalog son marcas comerciales de LF Projects, LLC. Todas las demás marcas son propiedad de sus respectivos dueños.

Para ver todo en funcionamiento, clona la arquitectura de referencia y ejecútala de extremo a extremo en github.com/open-lakehouse/open-lakehouse. Si estás empezando desde el lado de la AI, MLflow por sí solo es un buen punto de partida, y el resto de la pila estará allí cuando tus modelos y agentes necesiten datos gobernados que los respalden. ¿Prefieres una opción totalmente gestionada? La misma base abierta impulsa la plataforma de lakehouse de Databricks.

Explora la arquitectura de referencia

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original