Como permitir que diferentes plataformas utilizem os mesmos dados sem criar cópias e pipelines para mantê-las sincronizadas? Essa pergunta representa um dos desafios atuais das organizações que operam múltiplas plataformas de dados. Um caso da United Airlines publicado pela AWS em 15 de setembro de 2026 mostra como uma arquitetura de dados federada conecta Databricks e AWS sem duplicação.
Federação de dados entre Redshift e Databricks
A United Airlines processa bilhões de eventos diariamente em uma plataforma de dados que combina Amazon Redshift e Databricks. A companhia passou a permitir que usuários do Amazon Redshift consultem dados gerenciados no Databricks Unity Catalog por meio da federação do AWS Glue Data Catalog. Nessa arquitetura, as consultas chegam aos dados armazenados no Amazon S3 sem exigir duplicação no armazenamento gerenciado do Redshift.
A companhia já possui 30 tabelas federadas em produção e outras 70 em processo de implantação, com centenas adicionais previstas para os próximos meses. Segundo o relato técnico, cerca de 100 analistas passaram a acessar as tabelas de interação com usuários nessa primeira etapa, sem a criação de novos pipelines para replicar esses dados.
A configuração por trás da promessa
A arquitetura da United depende de uma cadeia de configuração específica: o Unity Catalog expõe as tabelas por uma API REST compatível com Iceberg; o AWS Glue cria um catálogo federado a partir dela; um resource link no catálogo padrão do Glue serve de ponte para que o Redshift consiga enxergar esse catálogo; e o AWS Lake Formation governa as permissões em cada etapa da cadeia. Para tabelas Delta, é preciso ainda habilitar o UniForm, que gera metadados compatíveis com Iceberg.
Nessa configuração, essas etapas são necessárias para que a consulta federada funcione corretamente. Sem o resource link corretamente apontado, sem as permissões do Lake Formation concedidas nas tabelas de destino e sem o UniForm ativo nas tabelas Delta, a consulta federada simplesmente não funciona. A “eliminação de pipelines” que a AWS descreve, nesse contexto, não significa ausência de mecanismos de integração, mas a substituição da replicação por uma arquitetura baseada em catálogos e permissões.
MLOps também é uma decisão de arquitetura
Nesse momento em que as empresas ampliam seus investimentos em Machine Learning, GenAI e agentes de IA, a movimentação dos dados passa a ser uma decisão arquitetural, e não uma consequência da integração. O caso da United mostra isso: diferentes tecnologias acessando os mesmos ativos de dados sem que cada integração obrigatoriamente gere uma nova cópia.
MLOps, nesse caso, não se resume ao deployment do modelo. Existe uma cadeia que envolve dados, features, experimentação, treinamento, inferência, observabilidade e atualização. Quando cada ambiente precisa manter sua própria versão dos dados, aumenta também o número de pipelines e sincronizações que precisam ser operados.
Menos movimento de dados, mais integração
E aqui não estamos falando somente sobre a integração da AWS com Databricks. A Databricks e o Google Cloud anunciaram também federação bidirecional de catálogos, permitindo que usuários do BigQuery e do Unity Catalog acessem dados compartilhados sem duplicação. Com a integração, o BigQuery lendo tabelas gerenciadas pelo Unity Catalog e, inversamente, o Databricks acessando tabelas Iceberg escritas a partir do BigQuery. É a mesma lógica da United aplicada a outro par de plataformas: operação com metadados abertos, no lugar de pipelines dedicados de replicação.
O número que não deve virar promessa
Segundo a AWS, a mudança eliminou pipelines de sincronização, reduziu armazenamento redundante e reduz em aproximadamente US$ 30 mil por mês em infraestrutura redundante de ETL. O número, porém, precisa ser interpretado dentro de seu contexto. Ele representa o resultado da arquitetura específica da United e não significa que produzirá automaticamente a mesma redução de custos em outras organizações.
FinOps multicloud: por que menos cópias significa menos desperdício
O que a AWS descreve como economia de infraestrutura é, sob outra lente, o tipo de gasto invisível que compõe a maior parte do desperdício multicloud: pipelines de ETL redundantes, armazenamento duplicado e sincronizações que ninguém lembra por que existem.
É aqui que arquitetura de dados e FinOps deixam de ser conversas paralelas. O OPT-3, plataforma de FinOps Multicloud da Jump, parte exatamente dessa premissa: reduzir o desperdício de nuvem por meio de visibilidade sobre quanto se gasta, onde e por qual motivo cada recurso continua ativo.
Interoperabilidade e conexão
A principal lição deste caso da United está em otimizar o uso dos dados sem a necessidade de criar uma cópia para cada workload. Parte do esforço antes dedicado à movimentação, replicação e sincronização passa para o desenho da interoperabilidade, conectividade e execução entre plataformas. Assim, a arquitetura mais eficiente passa a ser aquela capaz de escolher a abordagem adequada para cada workload.
