O que é um lakehouse aberto? Padrões de dados abertos explicados.

Um lakehouse aberto é um data lakehouse no qual cada camada (armazenamento, formato de tabela, mecanismo, catálogo e as ferramentas de ML e AI na parte superior) é construída em padrões abertos, de modo que nenhuma camada fique presa a um único fornecedor.

Um data lakehouse combina o armazenamento escalável e de baixo custo de um data lake com os recursos de gerenciamento e as garantias transacionais de um data warehouse. Um lakehouse aberto adiciona uma condição extra: cada camada da arquitetura é construída em padrões abertos. Os dados, os mecanismos que os processam, o catálogo que os gerencia e as ferramentas que criam modelos e aplicativos sobre eles são todos de código aberto, de modo que nenhum deles depende de um único fornecedor.

A palavra "aberto" é muito usada por aí, e nem sempre de forma honesta. É por isso que vale a pena defini-la claramente. Um formato pode ser chamado de aberto e ainda assim ser prático de usar por meio de apenas um mecanismo. Um catálogo pode ser chamado de aberto e ainda assim estar vinculado a apenas uma plataforma. O armazenamento permanece portátil até o momento em que as taxas de saída (egress) tornam sua movimentação cara. Um lakehouse aberto é o que você obtém quando essas restrições são removidas em todos os níveis. Mais recentemente, essa mesma abertura se estendeu às cargas de trabalho de AI e de agentes que agora estão sendo criadas com base nos dados.

Como um lakehouse aberto se diferencia de um data lake e de um data warehouse?

Um lakehouse aberto combina a confiabilidade de um data warehouse e o armazenamento de baixo custo de um data lake em uma única arquitetura, adicionando uma regra que falta aos outros dois: cada camada deve ser aberta e intercambiável. Um data warehouse armazena tabelas limpas e estruturadas para relatórios, com forte governança, mas com alto custo e pouco espaço para dados não estruturados. Um data lake armazena todo o resto, como arquivos brutos, logs e imagens, de forma barata e em escala, mas sem transações, garantias de esquema ou muita governança.

O lakehouse não surgiu do nada. Durante anos, as equipes mantiveram os dois sistemas lado a lado, copiando dados entre eles e reconciliando duas versões da verdade. O data lakehouse os unificou: gerenciamento e transações no estilo de data warehouse aplicados diretamente ao armazenamento de baixo custo do lake. O lakehouse aberto é o próximo passo dessa ideia. Ele mantém a arquitetura combinada e adiciona a regra acima, de modo que a confiabilidade de um warehouse e a economia de um lake sejam alcançadas sem vincular nenhuma camada a um único fornecedor.

Lakehouse aberto vs. proprietário: qual é a diferença?

A diferença entre um lakehouse aberto e um proprietário resume-se a uma pergunta: quem pode ler seus dados e quais mecanismos podem ser executados neles. Um lakehouse proprietário armazena dados em formatos que apenas um fornecedor pode ler, portanto, mudar de ferramenta pode exigir a reescrita ou a reexportação de todos os seus dados. Um lakehouse aberto armazena dados em formatos abertos que qualquer mecanismo compatível pode ler, permitindo que você adicione, troque ou remova um mecanismo de consulta sem precisar reescrever seus dados.

O que torna um lakehouse aberto?

Três coisas diferenciam um lakehouse aberto de um proprietário: formatos abertos, mecanismos abertos e governança unificada.

Comece com formatos abertos. Os dados residem em formatos de tabela abertos, Delta Lake e Apache Iceberg®, baseados em formatos de arquivo abertos como o Apache Parquet®. As especificações são públicas, de modo que qualquer mecanismo que as implemente pode ler e gravar os dados, e não apenas o ambiente de execução de um único fornecedor.

Em seguida, vêm os mecanismos abertos: os sistemas que realizam o processamento também são de código aberto. O Apache Spark® abrange lote, streaming, SQL e machine learning em um único ambiente de execução e, como as tabelas subjacentes são abertas, mecanismos como DuckDB, Trino ou PyIceberg podem trabalhar com os mesmos dados sem a necessidade de uma segunda cópia.

A governança unificada é a parte que as equipes costumam subestimar. Um único catálogo gerencia o controle de acesso, a linhagem e a auditoria para cada formato e mecanismo, de modo que a governança se vincula aos próprios dados, em vez de ser recriada dentro de cada ferramenta que os acessa. O Unity Catalog desempenha esse papel aqui.

Junte tudo isso e o resultado é uma arquitetura aberta desde a camada de armazenamento até a camada de entrega (serving): armazenamento de objetos na base, um formato de tabela aberto acima dele, um mecanismo de processamento aberto, um catálogo aberto para governança e ferramentas abertas para análises, machine learning e aplicações de AI no topo.

"Aberto" é o mesmo que código aberto (open source)?

Não exatamente, e essa diferença importa. O código aberto (open source) descreve a licença do código de um projeto. Já o termo "aberto", no contexto do lakehouse, é mais amplo: abrange formatos abertos de arquivos e tabelas, APIs abertas e formas padronizadas de conexão para ferramentas, além de um ecossistema onde vários mecanismos trabalham com os mesmos dados. Uma plataforma pode ser construída a partir de projetos de código aberto e, ainda assim, prender seus dados, por exemplo, armazenando-os em um layout que apenas seu próprio mecanismo consegue ler bem. O teste real de abertura é simples: você pode ler seus dados com qualquer ferramenta compatível e migrar entre ferramentas sem precisar reescrevê-los.

Formato de tabela aberto vs. lakehouse aberto: qual é a diferença?

Esses dois termos costumam ser usados como sinônimos, mas não deveriam. Um formato de tabela aberto é apenas uma camada: ele adiciona recursos semelhantes aos de um banco de dados (atualizações confiáveis, alterações de esquema e histórico) sobre os arquivos no armazenamento de objetos. Um lakehouse aberto engloba tudo ao redor dessa camada: o armazenamento abaixo dela e o processamento, catálogo e governança acima. O formato de tabela é um componente. O lakehouse é a pilha completa.

Dois termos da tabela: ACID significa que as alterações de dados são concluídas de forma confiável sem corromper a tabela, e viagem no tempo (time travel) significa que você pode visualizar ou restaurar os dados como eles estavam em um momento anterior.

Quais padrões abertos alimentam um lakehouse aberto?

Esta arquitetura de referência é construída a partir de cinco padrões de código aberto, cada um gerenciado por uma fundação neutra (a Apache Software Foundation ou a Linux Foundation) e cada um responsável por uma camada diferente da pilha. Um lakehouse aberto é tão confiável quanto os projetos nos quais é baseado, e estes não são projetos de nicho: são padrões que grande parte do setor já utiliza, e a maioria deles foi criada na Databricks. Isso não é uma falsa modéstia, é um fato verificável: no início de 2026, o Apache Spark é usado por cerca de 80% das empresas da Fortune 500 e é o mecanismo mais amplamente adotado para processamento de dados em grande escala. O MLflow ultrapassa 30 milhões de downloads por mês. O Delta Lake e o Apache Iceberg juntos cobrem a grande maioria das tabelas de lakehouse em produção, com o Delta Lake possuindo a maior base instalada.

Juntos, isso representa mais de 90.000 estrelas no GitHub e dezenas de milhões de downloads por mês. Um panorama de onde cada projeto se encontra (estrelas no GitHub no início de 2026):

Apache Spark

O Apache Spark® é o mecanismo de processamento. Ele foi criado no AMPLab da UC Berkeley em 2009 pela equipe que posteriormente fundou a Databricks, e foi doado para a Apache Software Foundation, onde se tornou um dos mecanismos mais amplamente utilizados para processamento de dados em grande escala. Um único runtime do Spark lida com jobs em lote (batch), streaming, SQL e machine learning, e é por isso que uma equipe pode executar um único mecanismo em vez de manter um sistema diferente para cada tipo de carga de trabalho. No lakehouse, o Spark lê dados brutos, refina-os em etapas e grava os resultados de volta como tabelas abertas.

Delta Lake

O Delta Lake é um formato de tabela que faz com que o armazenamento de objetos se comporte como um banco de dados em vez de um monte de arquivos. Além dos arquivos Parquet comuns, ele adiciona transações ACID, imposição de esquema (schema enforcement) e viagem no tempo (time travel), de modo que jobs concorrentes não corrompam as gravações uns dos outros e uma tabela possa ser consultada como estava em um momento anterior. Uma biblioteca complementar, o Delta Kernel, empacota a lógica de leitura e gravação em um componente independente de mecanismo, o que torna mais simples para outros mecanismos além do Spark suportarem o formato. O Delta Lake foi criado na Databricks, que continua sendo sua principal contribuidora, e é gerenciado como um projeto da Linux Foundation.

Apache Iceberg

O Iceberg é um segundo formato de tabela, desenvolvido para tabelas analíticas muito grandes e para movimentação limpa entre mecanismos. Ele surgiu na Netflix, e não na Databricks, e agora é um projeto Apache amplamente adotado. A Databricks é uma grande contribuidora, incluindo a equipe fundadora do Iceberg que se juntou a nós por meio da aquisição da Tabular. Sua especificação de tabela e catálogo REST facilitam o compartilhamento das mesmas tabelas por vários mecanismos, e é por isso que ele aparece sempre que há mais de um mecanismo de consulta em jogo. O suporte tanto ao Delta Lake quanto ao Iceberg significa que uma equipe não precisa se comprometer com um único formato desde o primeiro dia e viver com essa escolha para sempre.

Unity Catalog

O Unity Catalog é a camada de governança. Ele mantém políticas de acesso, distribuição de credenciais e linhagem em um só lugar, e os mecanismos acessam os dados por meio dele, em vez de contorná-lo. Como as regras residem no catálogo e não dentro de um mecanismo específico, o controle de acesso e a linhagem permanecem consistentes, quer a consulta venha do Spark, do DuckDB ou de outro cliente. O Unity Catalog foi criado na Databricks e agora é um projeto de código aberto sob a LF AI & Data Foundation, com uma versão gerenciada disponível na Databricks. A versão de código aberto é mais recente do que o produto gerenciado, e alguns recursos de governança ainda estão amadurecendo nela, por isso vale a pena comparar o projeto aberto com os seus requisitos.

O Unity Catalog não é o único catálogo aberto. O Apache Polaris, o Project Nessie, o Hive Metastore e o AWS Glue cumprem a mesma função, e o catálogo REST do Iceberg está surgindo como uma interface compartilhada entre eles. Um lakehouse aberto pode usar qualquer um deles. Esta arquitetura de referência usa o Unity Catalog porque ele governa ativos de dados, ML e AI juntos sob um único modelo, mas a camada de catálogo é genuinamente intercambiável.

MLflow

O MLflow é a camada para machine learning e AI. Ele lida com rastreamento de experimentos, empacotamento de modelos, registro de modelos, avaliação e serviço de modelos (serving), e esse mesmo mecanismo agora alcança agentes de AI: rastreando o que um agente fez, pontuando sua saída em relação aos avaliadores e colocando um gateway com limites de orçamento e proteções (guardrails) na frente dele. Executar modelos e agentes na mesma plataforma aberta que governa os dados, em vez de em uma pilha separada e isolada, é grande parte do que torna esta versão do lakehouse diferente. O MLflow foi criado na Databricks, que continua sendo sua principal contribuidora, e é um projeto da Linux Foundation.

Como as camadas de um lakehouse aberto funcionam juntas?

As camadas se conectam por meio de interfaces abertas, de modo que se encaixam sem a necessidade de integrações proprietárias, e qualquer uma delas pode ser substituída sem afetar as outras. É isso que transforma cinco projetos em uma única arquitetura.

Comece com os dados. O Spark grava tabelas no armazenamento de objetos como Delta Lake ou Iceberg. Como esses formatos são abertos, e como o Delta Kernel e o catálogo REST do Iceberg os expõem de forma neutra, outros mecanismos leem os mesmos arquivos diretamente. Nada precisa ser copiado para um armazenamento proprietário primeiro, e não há etapa de exportação na saída.

A governança abrange tudo isso. Cada mecanismo acessa os dados por meio do Unity Catalog, de modo que uma política escrita uma única vez é aplicada em todos os lugares. Trazer um novo mecanismo de consulta para o cenário significa apontá-lo para o catálogo, e não recriar regras de acesso e linhagem do zero para ele.

Modelos e agentes utilizam os mesmos dados governados. Um modelo treinado no MLflow lê as tabelas Gold que o Spark produziu. Um agente que responde a uma pergunta faz consultas por meio do Unity Catalog sob as mesmas políticas que um analista humano faria. A linhagem que conecta a entrada bruta a um modelo implantado ou à resposta de um agente é registrada ao longo do caminho. A camada de AI não é apenas acoplada no final; ela lê e grava por meio da mesma superfície governada que todo o resto.

O retorno prático é a independência entre as camadas. Uma equipe pode alterar os mecanismos de processamento, adicionar um mecanismo de consulta, adotar um segundo formato de tabela ou trocar por um framework de modelo diferente sem precisar refazer a plataforma das camadas acima ou abaixo, porque cada camada depende apenas da interface aberta da camada vizinha.

Quais são os benefícios de um lakehouse aberto?

O principal benefício de um lakehouse aberto é a flexibilidade de escolha: as equipes mantêm suas opções abertas à medida que as necessidades de dados e AI crescem, pois nenhuma camada individual fica presa a um fornecedor (lock-in). Os benefícios específicos são:

• Sem dependência de fornecedor (lock-in): formatos abertos permitem que as equipes mudem de ferramenta sem migrar ou regravar dados.
• Custo mais baixo: uma única cópia dos dados em um armazenamento de baixo custo evita a duplicação entre sistemas.
• Múltiplos mecanismos: vários mecanismos podem ser executados nos mesmos dados para BI, SQL e machine learning.
• Governança unificada: um único catálogo aplica controles de acesso e linhagem consistentes.
• Pronto para AI: dados confiáveis e unificados oferecem suporte ao treinamento de modelos, feature stores e agentes de AI.
• Liberdade de nuvem: as cargas de trabalho podem ser executadas em várias nuvens sem a necessidade de reconstrução.

Como um lakehouse aberto escala à medida que você cresce?

Um lakehouse aberto escala adicionando camadas, não mudando de plataforma: você ativa mais camadas conforme o trabalho exige, e as camadas iniciais permanecem no lugar à medida que as novas chegam. O mesmo modelo atende a uma equipe de duas pessoas e a uma empresa distribuída por várias regiões; a diferença é apenas a quantidade de camadas ativadas.

• ETL básico. Armazenamento de objetos, tabelas Delta e Spark. Os dados brutos chegam na camada Bronze, são limpos na Silver e disponibilizados na Gold. Essa configuração de medalhão é, por si só, uma pilha aberta completa.
• Streaming e lote (batch) juntos. Quando os dados precisam ser processados conforme chegam, o Spark Structured Streaming e o Real-Time Mode executam streaming ao lado do lote no mesmo mecanismo, com o Spark Declarative Pipelines descrevendo as transformações. Um segundo sistema de streaming não é necessário.
• Um catálogo compartilhado e os primeiros agentes. Quando analistas, aplicativos, dashboards e machine learning precisam dos mesmos dados, o Unity Catalog se torna a camada de governança comum pela qual eles fazem a leitura. Geralmente, é aqui também que os primeiros agentes aparecem, monitorando a qualidade dos dados, criando rascunhos de pipelines e explorando a linhagem, tudo governado pelo catálogo como qualquer outro consumidor.
• Escala empresarial. Em diferentes regiões e nuvens, o Unity Catalog adiciona fornecimento de credenciais, políticas refinadas, Lakehouse Federation e Delta Sharing, e o Spark é executado como uma frota gerenciada no Kubernetes. A base é a mesma; há apenas mais governança e mais computação.

Como a AI se encaixa em um lakehouse aberto?

Em um lakehouse aberto, os aplicativos e agentes de AI são cargas de trabalho de primeira classe governadas exatamente como qualquer outro consumidor de dados, e não um sistema separado adicionado posteriormente. A maioria das explicações sobre lakehouse para no business intelligence e no machine learning, o que hoje em dia parece um diagrama de 2021 com uma caixa de AI grampeada ao lado. Tratar os agentes como consumidores governados dos mesmos dados é o que realmente torna essa versão atual.

Como o MLflow é executado na plataforma que governa os dados, um agente está sujeito às mesmas regras que todos os outros. Ele faz a leitura por meio do Unity Catalog, portanto, vê apenas o que suas permissões permitem. Sua atividade é rastreada e suas respostas são avaliadas por avaliadores no MLflow, da mesma forma que a qualidade de um modelo é monitorada, e o gateway à sua frente pode limitar os gastos e aplicar proteções. Nada disso exige uma pilha de AI separada com sua própria cópia dos dados e sua própria governança mais fraca, que costuma ser a alternativa comum.

Na prática:

• Atribuição: um agente é executado com sua própria identidade, de modo que cada ação é rastreada até um principal, em vez de ficar oculta atrás de uma conta compartilhada.
• Credenciais com escopo definido: o catálogo fornece credenciais temporárias e restritas em vez de chaves de longa duração, de modo que o acesso de um agente pode ser limitado e revogado como o de qualquer outra pessoa.
• Linhagem: as leituras e gravações de um agente são registradas, de modo que o caminho desde os dados de origem, passando pela recuperação, até a resposta possa ser reconstruído para uma auditoria.
• Gastos e proteções: os limites de orçamento e os controles de conteúdo ficam no gateway, fora do próprio código do agente.
• Modo de falha: como o acesso passa pelo catálogo, o que acontece quando o catálogo está indisponível é uma escolha de design explícita, como negar o acesso em vez de recorrer a leituras diretas e não governadas.

A identidade de um agente pode ser seu próprio service principal ou uma delegação do usuário que o invocou (um modelo em nome de outrem), e essa escolha determina como suas ações aparecem no log de auditoria. E o caminho autônomo do MLflow descrito mais adiante oferece rastreamento e avaliação sem a necessidade de um lakehouse, mas o controle de acesso imposto pelo catálogo mencionado acima se aplica apenas quando o Unity Catalog estiver implementado.

Na prática, isso é concreto. Um agente solicita uma coluna para a qual não recebeu permissão; o Unity Catalog nega a leitura, e o log de auditoria registra a identidade do agente, a tabela e a coluna solicitadas, o horário e a decisão de negação. Para as consultas permitidas, a linhagem vincula a resposta de volta às tabelas Gold específicas que ele lê.

O objetivo não é que os agentes substituam o restante da arquitetura. É que eles se encaixem nela. Um agente é mais um consumidor de dados governados, criado e monitorado com as mesmas ferramentas abertas que os pipelines e modelos ao seu redor.

Você realmente precisa de um lakehouse aberto?

Nem sempre: um lakehouse aberto é a escolha certa quando a abertura e a escala mostram seu valor, e um exagero quando não mostram. É uma excelente opção quando você tem muitos tipos de dados, várias equipes ou mecanismos compartilhando os mesmos dados, requisitos multicloud ou um objetivo claro de evitar a dependência de fornecedor (lock-in). Pode ser um exagero para uma carga de trabalho pequena, de ferramenta única, com dados simples e estruturados, sem necessidade de alternar entre ferramentas.

Uma abordagem prática é começar com um piloto de escopo limitado vinculado a um requisito real, por exemplo, federar uma fonte existente ou mover um pipeline, antes de se comprometer com uma migração completa. A arquitetura foi projetada para ser adotada uma camada de cada vez, de modo que a escolha não é entre tudo ou nada.

É possível migrar para um lakehouse aberto de forma incremental?

Sim. Um lakehouse aberto foi projetado para se integrar ao que você já executa, uma camada de cada vez, em vez de exigir que você desmonte sua pilha existente primeiro. Poucas equipes começam do zero; a maioria já executa um data warehouse em nuvem, ou EMR, ou um catálogo de dados, ou uma migração do Iceberg pela metade.

• Em um data warehouse em nuvem existente: federe-o por meio do Unity Catalog para que a governança e a linhagem o alcancem, e deixe os dados onde estão.
• No EMR Spark: mova apenas a camada de criação de pipeline para o Spark Declarative Pipelines e mantenha os clusters que você já executa.
• Em um catálogo separado: faça com que o Unity Catalog emita eventos de linhagem abertos que seu catálogo existente ingira, para que os dois funcionem lado a lado.
• No meio do caminho para o Iceberg: coloque o Unity Catalog sobre o catálogo que você já configurou e não altere mais nada.

A mudança é sempre a mesma: substitua uma camada por uma versão aberta e não mexa no restante até que haja um motivo para isso.

O que é realmente difícil em um lakehouse aberto?

Um lakehouse aberto tem seus desafios reais, e um relato honesto deve mencioná-los. Os formatos de tabela abertos acumulam arquivos pequenos e precisam de compactação e manutenção regulares. Gravar nas mesmas tabelas a partir de vários mecanismos ao mesmo tempo ainda é um processo menos maduro do que ler a partir delas, portanto, as gravações multimecanismo exigem cuidado. As versões de código aberto de alguns componentes ficam atrás de suas versões gerenciadas em alguns recursos. E hospedar toda a pilha por conta própria exige um trabalho operacional real. A abertura nas camadas de formato e catálogo também não elimina todas as formas de lock-in. Runtimes gerenciados, aceleradores de consulta proprietários e preços de computação são onde as plataformas ainda prendem você, e vale a pena avaliá-los separadamente das camadas abertas. Nada disso vai contra a arquitetura. É o custo real de possuir cada camada.

Como você mesmo pode executar um lakehouse aberto?

Como cada camada é de código aberto, você pode executar tudo sozinho. Existe uma implementação de referência aberta que configura as camadas juntas:

Isso inicia o Apache Spark, o Apache Kafka®, o Apache Airflow®, o Apache Iceberg, o Delta Lake, o Unity Catalog e o MLflow localmente no Docker, com configurações para implantação na nuvem. Se tudo o que você precisa no início for a camada de AI, poderá começar apenas com o MLflow: um pip install e algumas linhas em um aplicativo existente são suficientes, e você poderá adicionar o restante mais tarde.

Por exemplo, você pode apontar o MLflow para um agente existente sem nenhum lakehouse por baixo:

Seu agente LangGraph ou OpenAI é executado sem alterações, e seus traces, prompts e chamadas de ferramentas aparecem no MLflow. Seu Postgres, banco de dados vetorial e provedor de modelos permanecem onde estão. Você adiciona o lakehouse governado por baixo apenas quando seus agentes precisarem de dados corporativos governados.

O repositório de referência é licenciado sob a licença Apache 2.0 e mantido pela equipe de relações com desenvolvedores da Databricks. Não se trata de uma tecnologia nova: são os cinco projetos comprovados acima, conectados com o Docker para quando você deseja toda a pilha em um só lugar. Cada camada também funciona de forma independente; o pacote é uma conveniência, não uma dependência. Executar um lakehouse aberto por conta própria é viável, mas exige um trabalho real, e o repositório trata isso dessa forma: ele oferece padrões de alta disponibilidade, configurações de implantação e observabilidade para que a hospedagem própria seja um caminho suportado, e não apenas uma promessa.

O que um lakehouse aberto muda na sua função?

• Se você escreve SQL ou dbt: o Spark Declarative Pipelines oferece a mesma criação declarativa e focada em SQL que você conhece do dbt, e adiciona streaming junto com lote e suporte completo a SQL e Python em um único mecanismo, tudo em tabelas abertas governadas que você ainda pode consultar a partir da sua ferramenta de BI existente.
• Se você cria pipelines de dados: você os desenvolve uma vez, por exemplo, com o Spark Declarative Pipelines, e executa lote e streaming em um único mecanismo.
• Se você cria modelos ou agentes: você os cria, avalia e serve no MLflow com os mesmos dados governados, sob as mesmas regras de acesso de todos os outros.
• Se você gerencia a plataforma: você adiciona camadas conforme a empresa cresce e pode substituir qualquer uma delas sem precisar refazer a plataforma inteira.

Quais plataformas oferecem suporte a lakehouses abertos?

Diversas plataformas agora implementam os princípios de lakehouse aberto. Databricks, Snowflake, Google Cloud, Microsoft Fabric, Cloudera, Dremio, Starburst e Qlik oferecem produtos nessa área. Esses produtos são desenvolvidos com base em ideias de lakehouse aberto, e não na arquitetura em si, e variam no nível de abertura de cada camada.

A Databricks criou a categoria de lakehouse e oferece desempenho de nível de data warehouse em uma base aberta, usando Delta Lake e Apache Iceberg para armazenamento e Unity Catalog para governança. A Plataforma Databricks oferece isso como um serviço gerenciado para equipes que preferem não gerenciar a infraestrutura por conta própria.

Perguntas frequentes

Um lakehouse aberto é o mesmo que um data lakehouse?

Um data lakehouse é a arquitetura: gerenciamento no estilo data warehouse em armazenamento de data lake. Um lakehouse aberto é um data lakehouse no qual cada camada (armazenamento, formato de tabela, mecanismo, catálogo e as ferramentas de ML e AI na camada superior) é de código aberto e intercambiável, de modo que nenhuma camada dependa de um único fornecedor.

Iceberg ou Delta Lake: qual devo usar?

Ambos são formatos de tabela abertos com transações ACID, evolução de esquema e viagem no tempo (time travel), e um lakehouse aberto pode usar um ou ambos. O Delta Lake se integra perfeitamente ao Spark e, por meio do Delta Kernel, é cada vez mais legível por outros mecanismos; o Iceberg foi desenvolvido para amplo acesso multimecanismo por meio de seu catálogo REST. O suporte a ambos significa que a escolha não precisa ser feita logo de início.

Preciso de todos os cinco projetos para ter um lakehouse aberto?

Não. A arquitetura foi feita para crescer. Um lakehouse aberto básico consiste apenas em armazenamento de objetos, um formato de tabela e Spark. O Unity Catalog e o MLflow são adicionados quando a governança entre vários consumidores e as cargas de trabalho de machine learning ou AI entram em cena.

Posso executar um lakehouse aberto sem a Databricks?

Sim. Cada camada é de código aberto e roda em sua própria infraestrutura. A implementação de referência inicia toda a pilha localmente com o Docker, e a camada de machine learning pode ser usada de forma independente com um único pip install. A Databricks oferece versões gerenciadas desses componentes abertos, mas a auto-hospedagem é um caminho suportado.

Onde os agentes de AI se encaixam em um lakehouse aberto?

Os agentes são tratados como consumidores de dados governados, e não como um sistema separado. Eles leem por meio do Unity Catalog sob as mesmas políticas que pessoas e outros mecanismos, e são criados, rastreados e avaliados no MLflow junto com os modelos, o que mantém a camada de AI dentro da mesma arquitetura aberta e governada, em vez de ser algo integrado à parte.

Quanto custa um lakehouse aberto?

Os componentes de código aberto são gratuitos para uso sob as licenças Apache 2.0 e Linux Foundation; seus custos serão o armazenamento de objetos, a computação que você executa e o esforço operacional para manter a pilha. Executá-lo por conta própria troca o custo de licenciamento pelo tempo de engenharia, enquanto uma plataforma gerenciada como a Databricks troca o tempo de engenharia por uma assinatura, sob a mesma base aberta.

Um lakehouse aberto está pronto para produção?

Sim. Os cinco projetos principais são padrões maduros que já rodam em produção em larga escala, por exemplo, o Apache Spark em cerca de 80% das empresas da Fortune 500 e o MLflow com mais de 30 milhões de downloads por mês. As principais considerações de produção são operacionais: manutenção e compactação de tabelas, cuidado com gravações multimecanismo e o trabalho de auto-hospedagem se você não usar um serviço gerenciado.

Apache, Apache Spark, Apache Iceberg, Apache Kafka, Apache Airflow, Apache Parquet e o logotipo Apache feather são marcas registradas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou em outros países. Delta Lake, MLflow e Unity Catalog são marcas comerciais da LF Projects, LLC. Todas as outras marcas são de propriedade de seus respectivos proprietários.

Para ver tudo funcionando, clone a arquitetura de referência e execute-a de ponta a ponta em github.com/open-lakehouse/open-lakehouse. Se você estiver começando pelo lado da AI, o MLflow por si só é um bom ponto de partida, e o restante da pilha estará lá quando seus modelos e agentes precisarem de dados governados por trás deles. Prefere um caminho totalmente gerenciado? A mesma base aberta alimenta a plataforma de lakehouse da Databricks.

Explore a arquitetura de referência

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original