Um único caminho de gravação, múltiplas entradas: como a Rippling usa o Apache Iceberg™ gerenciado pelo Unity Catalog

Este é um post convidado de Tae Lee, Staff Engineer de Plataforma de Dados na Rippling

Na Rippling, o mecanismo que grava uma tabela nem sempre é o mesmo que a lê. Um job do Databricks pode gerar uma tabela, mas o consumidor downstream pode ser a camada de consulta baseada em Trino do Rippling Data Cloud, o Snowflake ou outro leitor de lakehouse. Isso faz com que a decisão do catálogo seja mais do que um detalhe de metadados: ela determina quem pode gravar na tabela, quem a mantém e como outros mecanismos a leem.

Isso significa que o objetivo não é forçar cada carga de trabalho a usar um único mecanismo ou catálogo. O objetivo é permitir que cada produtor use a plataforma onde executa melhor, sem deixar de publicar tabelas governadas que os sistemas downstream possam consumir sem duplicação.

Tabelas Iceberg gerenciadas pelo Unity Catalog são o padrão que usamos para a parte dessa arquitetura produzida pelo Databricks.

A propriedade do catálogo acompanha quem escreve

Nossa estratégia de catálogo começa com uma regra simples: o catálogo deve acompanhar quem escreve.

Para computação nativa da AWS, usamos o AWS Glue Data Catalog. Essa é a escolha natural para cargas de trabalho gravadas por mecanismos da AWS, como Glue, Athena, EMR ou infraestrutura relacionada.

Para cargas de trabalho produzidas pelo Databricks, usamos o Unity Catalog. Isso é especialmente importante para o Apache Iceberg™. O Databricks pode ler tabelas Iceberg externas por meio de federação, mas essas tabelas não são iguais às tabelas Iceberg gerenciadas pelo Unity Catalog. Se o Databricks precisar gravar na tabela, ou se a carga de trabalho depender muito do desempenho e da governança do Databricks, a tabela deve ser gerenciada pelo UC.

Para dados produzidos pelo Snowflake que precisam ser compartilhados entre plataformas, usamos o Snowflake Horizon Catalog com tabelas Iceberg gerenciadas pelo Snowflake. Essa é uma decisão de catálogo separada, orientada pelo Snowflake como produtor.

Esta é a distinção importante: o Iceberg nos oferece um formato de tabela aberto, mas o catálogo ainda é o proprietário dos commits de metadados, das permissões e do ciclo de vida da tabela. A portabilidade do formato e a propriedade do catálogo estão relacionadas, mas não são a mesma coisa.

Por que usar Iceberg gerenciado para cargas de trabalho do Databricks

Antes desse padrão, uma saída produzida pelo Databricks que precisava ser consumida em outro lugar geralmente exigia uma etapa extra: exportar uma segunda cópia após a gravação do Databricks ou gravar diretamente no sistema de consumo e lê-la de volta por meio de um conector ou caminho de federação quando o Databricks precisasse dela novamente. Ambas as abordagens funcionam, mas adicionam materialização duplicada, computação extra e limites específicos do conector. 

O Iceberg gerenciado pelo Unity Catalog nos oferece um limite mais claro.

O Databricks grava a tabela nativamente. O Unity Catalog detém os metadados, o modelo de acesso e o ciclo de vida da tabela. Os dados da tabela e os metadados do Iceberg são armazenados no armazenamento S3 de propriedade da Rippling. 

Mecanismos externos se conectam por meio da API REST Catalog do Iceberg ou de federação de catálogos. A distribuição de credenciais concede a esses mecanismos acesso delimitado ao armazenamento subjacente. Os mecanismos então leem os arquivos Parquet diretamente do S3 usando sua própria computação. 

Essa é a propriedade fundamental para nós. Um job do Databricks pode produzir a tabela uma vez, e um mecanismo downstream como Trino, Snowflake, Spark, Athena ou EMR pode consumir a mesma tabela por meio de padrões de acesso padrão do Iceberg. O consumidor não precisa fazer proxy de cada consulta por meio do dialeto SQL ou da camada de execução de outro mecanismo, o que reduz a dependência de tradução entre mecanismos, comportamento de pushdown, throttling e computação do lado do produtor para leituras downstream. 

Não se trata de uma exportação do Databricks. É uma tabela Iceberg aberta com um produtor nativo do Databricks.

De saídas de ML para o Data Cloud

O padrão é mais útil quando uma saída produzida pelo Databricks precisa se tornar parte de um produto mais amplo ou de uma superfície de análise (analytics).

Na Rippling, as cargas de trabalho de ML e AI ainda escolhem o destino que melhor se adapta ao caso de uso: tabelas Delta, bancos de dados vetoriais, OpenSearch ou outros destinos criados para fins específicos. O Iceberg gerenciado é um padrão de publicação selecionado, não o destino padrão para cada saída de ML.

Onde o Iceberg gerenciado realmente importa é na transição (handoff). Para saídas selecionadas, um job do Databricks pode publicar uma tabela Iceberg gerenciada pelo Unity Catalog uma única vez. O Rippling Data Cloud pode então consumir essa mesma tabela por meio de sua camada de consulta, incluindo padrões de acesso baseados em Trino, e usá-la em transformações downstream, dashboards e recursos de produtos baseados em AI.

A arquitetura é assim:

Isso nos dá uma tabela governada e um caminho de gravação. Os consumidores downstream não precisam de uma cópia física duplicada, e os Lakeflow Jobs não precisam gravar separadamente em cada sistema de consumo.

As operações importam tanto quanto a abertura

Formatos de tabela abertos são apenas parte da história. As tabelas Iceberg ainda precisam de manutenção: compactação de arquivos, expiração de snapshots, limpeza de órfãos e estatísticas.

Para tabelas Iceberg catalogadas no Glue, essa manutenção pertence ao caminho da plataforma nativa da AWS. O Glue possui recursos de otimização de tabelas, mas ainda é um modelo operacional separado: precisamos decidir onde habilitar esses recursos, como monitorá-los e como validar o comportamento das cargas de trabalho que usam o Glue.

Para o Iceberg gerenciado pelo Unity Catalog, o Databricks lida com mais partes desse ciclo de vida por meio de Predictive Optimization, incluindo manutenção automática de tabelas, otimização e compactação de arquivos, coleta de estatísticas e otimização do layout de dados para tabelas gerenciadas. Isso é útil porque a mesma plataforma que grava a tabela também gerencia grande parte da manutenção necessária para mantê-la com alto desempenho.

Esse é um dos motivos pelos quais não vemos o Iceberg gerenciado pelo UC apenas como um recurso de interoperabilidade. É também um modelo operacional. Para tabelas produzidas pelo Databricks, o caminho de manutenção importa tanto quanto o caminho de leitura.

Sendo precisos sobre o lock-in

Essa arquitetura reduz o lock-in de dados, mas não elimina todas as dependências.

O lock-in de dados é baixo. A tabela é Iceberg sobre Parquet no armazenamento S3 de propriedade da Rippling.

Os mecanismos downstream podem ler os dados diretamente por meio de padrões abertos do Iceberg.

A dependência de catálogo e governança é real. O Unity Catalog continua sendo o plano de controle para metadados, permissões, linhagem e comportamento de tabelas gerenciadas. Se deixássemos de usar o Databricks, os dados seriam portáveis, mas precisaríamos substituir o catálogo e o sistema de manutenção.

Esse é um trade-off aceitável para essa classe de tabelas. O UC conquista seu espaço quando o Databricks é o produtor e a tabela precisa ser governada, mantida e legível por outros mecanismos.

O resultado prático

O valor do Iceberg gerenciado pelo Unity Catalog não é nos dar um único catálogo para cada tabela. Ele não faz isso, e esse não é o nosso objetivo.

O valor é que ele nos dá um único caminho de gravação para tabelas produzidas pelo Databricks que precisam de consumo downstream aberto. O Databricks obtém o caminho nativo de gravação e otimização. Os sistemas downstream obtêm acesso direto a dados abertos no S3. 

Os mecanismos que acessam a tabela por meio do catálogo REST passam pela mesma camada de metadados e acesso, em vez de ignorar a governança

por meio de caminhos de armazenamento brutos. Esse é o resultado prático:

"O Unity Catalog e o Iceberg gerenciado nos dão o melhor dos dois mundos: desempenho nativo para nossos pipelines de AI e ML e interoperabilidade aberta para cada consumidor downstream. Um caminho de gravação, zero duplicação e uma camada de governança que todo mecanismo respeita, incluindo os produtos baseados em AI que estamos criando para o Data Cloud da Rippling."

Para a Rippling, interoperabilidade não significa tornar todos os mecanismos intercambiáveis. Trata-se de permitir que cada mecanismo faça o trabalho no qual é bom, mantendo a tabela publicada portável, governada e utilizável pelos sistemas que precisam dela.

Para saber mais sobre o Unity Catalog e o suporte ao Iceberg, visite a página do produto do Unity Catalog. 

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