Um Lakehouse Aberto em Tempo Real com Redpanda e Databricks

Todo lakehouse deve ser 'alimentado por fluxo' 

O conceito de 'open lakehouse' pioneiro da Databricks anos atrás tem sido mais amplamente realizado através da recente ascensão do Apache Iceberg™, impulsionado pelos investimentos dos principais fornecedores em integração de framework, ferramentas, suporte de catálogo e interoperabilidade de dados, comprometendo-se com o Iceberg como um substrato comum para um open lakehouse. Avanços como a capacidade de expor as tabelas do Delta Lake para o crescente ecossistema Iceberg através do UniForm, suporte do Unity Catalog para recursos avançados como otimização preditiva e Iceberg REST com tabelas Iceberg gerenciadas, e a recente unificação da camada de dados Delta/Iceberg no Iceberg V3 significam que as organizações agora podem adotar uma estratégia de dados 'Iceberg-forward' com confiança, e sem comprometer o uso dos ricos conjuntos de recursos de produtos maduros de lakehouse como o Databricks. 

Um dos principais elementos ausentes nesta história de acesso ubíquo a dados residentes na nuvem através da língua franca do Iceberg tem sido os fluxos, nomeadamente os tópicos Kafka. Hoje, qualquer dado estruturado em repouso pode ser facilmente aterrissado nativamente ou 'decorado' como Iceberg. Em contraste, dados de alto valor em movimento que fluem através de uma plataforma de streaming que alimenta aplicativos em tempo real ainda precisam ser 'ETLed' para o lakehouse alvo através de um trabalho de integração de dados ponto a ponto, por fluxo, ou executando uma infraestrutura de conector cara em seu próprio cluster. Ambas as abordagens utilizam um Kafka Consumer pesado, pressionando suas pipelines de entrega de dados em tempo real, e criam um componente de infraestrutura intermediário para escalar, gerenciar e observar com habilidades especializadas em Kafka. Ambas as abordagens equivalem a inserir um pedágio muito caro entre seus dados em tempo real e analíticos, um que realmente não precisa existir. 

À medida que o uso de armazenamentos de objetos na nuvem para suportar fluxos amadureceu (Redpanda liderou essa carga alguns anos atrás) e como os formatos de tabela abertos ganharam destaque nos lakehouses, esse casamento de fluxo para tabela é tanto conveniente quanto "destinado a ser". Databricks e Redpanda oferecem duas plataformas de dados de classe mundial que fazem essa abordagem brilhar intensamente e chamar a atenção. Juntos, eles criam um substrato de dados que abrange tomada de decisões em tempo real, análises e IA que é difícil de superar. Na prática, essa abordagem mescla fluxos com tabelas com a facilidade de uma bandeira de configuração. Ele age como uma barragem de várias câmaras, direcionando fluxos selecionáveis para um lago de dados unificado sob demanda, fornecendo insights atualizados e desbloqueando a mesma inclusão arbitrária de dados em novos pipelines de análise que a arquitetura do lakehouse nos deu para tabelas, e agora através da abertura ampliada que o ecossistema Iceberg oferece.  

Fundir perfeitamente a infraestrutura de dados em tempo real e analíticos para tornar um 'lakehouse alimentado por fluxo' um assunto de apertar um botão não só desbloqueia um valor massivo, mas também resolve um problema de engenharia difícil que exige uma abordagem cuidadosa para ser adequadamente abordado no caso geral. Como esperamos ilustrar abaixo, não cortamos cantos para apressar essa capacidade para o mercado. Trabalhando com dezenas de parceiros de design (e Databricks) por mais de um ano, estendemos o único código base do Redpanda de uma maneira que preserva as opções de implantação preferidas de nossos clientes (incluindo BYOC em várias nuvens), mantém a compatibilidade total com Kafka (não deixe nenhum workload para trás), e evita a duplicação de artefatos e etapas para os usuários sempre que possível. Esperamos que essa completude de visão seja evidente à medida que apresentamos os princípios orientadores para a construção de Tópicos Iceberg do Redpanda, que agora estão disponíveis com o Catálogo Unity da Databricks na AWS e GCP!

Execute sua plataforma de stream-para-lakehouse em qualquer lugar 

Nosso primeiro princípio foi manter a escolha e encontrar os usuários onde eles estão. Redpanda já tem maturidade multi-nuvem SaaS, BYOC e auto-gerenciadas ofertas, opções de rede soberanas privadas como BYOVPC, e geralmente nunca força seus clientes a mover nuvens, redes, armazenamentos de objetos, IdPs, ou qualquer outra coisa que possa impedir a adoção ou impedir os proprietários da plataforma de posicionar sua implantação de plataforma de streaming (incluindo ambos planos de dados e controle, onde faz mais sentido para eles. Independentemente dessa escolha, os usuários obtêm todos os recursos da plataforma e uma UX consistente para desenvolvedores e administradores. Esta estratégia de produto de plataforma única é o que nos permite anunciar que Tópicos Iceberg para Databricks estão geralmente disponíveis nas nuvens AWS, GCP e Azure hoje, e que as organizações podem implantar com a confiança de saber que se e quando elas mudarem de nuvem ou mudarem para novos formatos, elas estão implantando o mesmo produto com o mesmo motor subjacente, compatibilidade com Kafka, modelo de segurança, características de desempenho e ferramentas de gerenciamento. Esta amplitude de flexibilidade e consistência contrasta fortemente com outras opções no mercado.

Catálogo Unity, conheça a plataforma de streaming mais unificada

Em segundo lugar, estávamos determinados a construir isso como um único sistema, e um que realmente se pareça com isso. Simplesmente não se pode fundir dois conceitos bem juntando duas arquiteturas de software completamente diferentes.  Você pode encobrir algumas coisas com uma camada de SaaS, mas arquiteturas inchadas vazam nos modelos de preços, desempenho e TCO no mínimo, e nos piores casos na experiência do usuário. Fizemos o nosso melhor para evitar isso.

Para os desenvolvedores, a 'sensação' de um único sistema significa um único ciclo de vida CRUD e uma UX consistente para tópicos como tabelas, e para as coisas que eles exigem para funcionar (ou seja, esquemas). Com os Tópicos Iceberg, você nunca copia entradas ou confusões, nem os cria duas vezes usando uma UI separada. Você gerencia uma entidade como a fonte da verdade para dados e esquema, sempre usando as mesmas ferramentas. Para nós, isso significa que você CRUD através das ferramentas que já usa: qualquer ferramenta do ecossistema Kafka, nosso rpk CLI, Cloud REST APIs ou qualquer ferramenta de automação de implantação Redpanda como nossos K8s CRs ou provedor Terraform. Para esquemas, é nosso integrado Registro de Esquema com seu padrão amplamente aceito API, que define o esquema da tabela Iceberg implicitamente, ou explicitamente, como você preferir. Tudo é orientado à configuração e amigável para DevOps. E com as novas tabelas Iceberg gerenciadas do Unity Catalog, todos os seus fluxos são descobertos através das ferramentas Databricks como tabelas Iceberg e Delta Lake por padrão.

Um único sistema também preocupa o operador da plataforma, que não deveria precisar se preocupar em gerenciar vários buckets ou catálogos, ajustar os tamanhos dos arquivos Parquet, tabelas atrasando fluxos quando os clusters estão com recursos limitados, ou falhas de nós comprometendo a entrega exatamente uma vez.  Com os Tópicos Iceberg da Redpanda, tudo isso é autônomo. Os operadores se beneficiam de gravações em lote dinâmicas de parquet e commits transacionais do Iceberg que se ajustam às suas SLAs de chegada de dados, monitoramento automático de atraso que gera contrapressão do Produtor Kafka quando necessário, e entrega exata uma vez via marcação de snapshot do Iceberg (evitando lacunas ou duplicatas após falhas de infraestrutura). 

A Redpanda gerencia todos os seus dados em um único bucket/container, usa um único catálogo Iceberg no Unity Catalog (que a Redpanda monitora para recuperação graciosa), e torna as tabelas facilmente descobertas expondo o endpoint REST Iceberg do Unity Catalog diretamente na UI da Redpanda Cloud. E agora, com as Tabelas Iceberg Gerenciadas do Unity Catalog, operações de manutenção de tabela como compactação, expiração de dados e Otimização Preditiva são integradas e executadas automaticamente pelo Unity Catalog em segundo plano, enquanto a Redpanda assume as operações de manutenção mínimas apropriadas para seu papel, (atualmente limpeza de snapshot Iceberg e criação/exclusão de tabela). Os administradores do Databricks podem então proteger e governar essas tabelas usando todos os normais privilégios do Unity Catalog privileges.  

Um cluster para governar todos eles

Acima de tudo, graças ao nosso R1 motor de streaming multi-modelo que usa uma arquitetura thread-per-core e possui recursos como cache de escrita e balanceamento de dados e carga de trabalho em vários níveis, os administradores podem executar esta ingestão Iceberg de alta capacidade no mesmo cluster, e com os mesmos tópicos que alimentam as cargas de trabalho Kafka de baixa latência com SLAs abaixo de 10ms.  Usando operações assíncronas e encadeadas bloqueadas nos mesmos núcleos de CPU que lidam com solicitações de produção/consumo, lidamos com ambas as cargas de trabalho com a máxima eficiência em um único processo. Mais importante ainda, os Tópicos Iceberg podem aproveitar o conjunto completo de semânticas Kafka, incluindo transações Kafka e tópicos compactados, onde a camada Iceberg recebe apenas registros de transações confirmadas. Esta combinação de uma arquitetura fundamentalmente eficiente que resolve os problemas difíceis de semânticas sofisticadas rende enormes dividendos na redução de seus custos operacionais porque, bem, um cluster para governar todos eles.  Sem produtos adicionais. Sem clusters separados. Sem supervisão de pipelines. Implemente em qualquer lugar.  Mantenha a calma e continue, administradores de plataforma de streaming.

Simplifique

Nosso terceiro princípio foi fazer algumas escolhas opinativas sobre comportamentos padrão, permitindo que os usuários aprendam o sistema gradualmente com a configuração mais inteligente possível sem intervenção manual que funciona para a maioria dos casos de uso.  Isso significa particionamento de tabela por hora integrado (totalmente divorciado dos esquemas de partição de tópicos Kafka), sempre ligado filas de letras mortas como tabelas para capturar qualquer dado inválido, e convenções simples e canônicas como 'última versão' ou 'Estratégia de Nome de Tópico' para inferência de esquema facilitam a adoção. Também trazemos metadados Kafka como partições de mensagens, offsets e chaves junto para a viagem como um Struct Iceberg, para que os desenvolvedores tenham toda a proveniência para validar rapidamente a correção de seus pipelines de streaming no Iceberg SQL.  

O simples deve ser simples, claro, mas o sofisticado também deve ser direto. Então, definir a particionamento personalizado hierárquico com o conjunto completo de transformações de partição Iceberg ou puxar um tipo específico de mensagem Protobuf de dentro de um assunto para se tornar o esquema de sua tabela Iceberg são, novamente, apenas propriedades de tópico declarativas de uma única linha. Os esquemas podem evoluir graciosamente à medida que a Redpanda aplica evolução de tabela no local. E se precisar, execute um SMT simples em sua linguagem favorita que distribui mensagens complexas de um tópico bruto em tabelas de fatos Iceberg mais simples usando Transformações de Dados a bordo alimentadas por WebAssembly. O objetivo final é aterrissar pronto para análise em uma única passagem. Boom, olá camada Bronze.

O pano de fundo para toda essa inovação é, claro, o projeto e as especificações do Apache Iceberg em rápida evolução, e o compromisso do Redpanda mais geralmente com os padrões abertos. Esse compromisso começou com seu suporte inicial ao protocolo Kafka, registro de esquema e APIs de proxy HTTP, e até outros detalhes como a configuração padrão do tópico que permite às organizações migrar um conjunto inteiro de aplicações Kafka sem alterações. No reino Iceberg, Redpanda se destacou como um pioneiro comprometido na comunidade, implementando um cliente Iceberg C++ completo do zero (algo não disponível em código aberto). Este cliente suporta a especificação completa da tabela Iceberg V2, todas as regras de evolução de esquema, e transformações de partição. No lado do catálogo Iceberg, Redpanda tanto envia um catálogo baseado em arquivo quanto fala Iceberg REST para operações como criar, commitar, atualizar e deletar em catálogos remotos como o Catálogo Unity, e suporta autenticação OIDC, manuseando suas credenciais do Catálogo Unity judiciosamente como um segredo que é transparentemente criptografado no gerenciador de segredos do seu provedor de nuvem. Redpanda também trabalhou de perto com Databricks e outros líderes do Iceberg para explorar como a especificação pode ser estendida para suportar dados de fluxo semi-estruturados através do tipo Variant, e para tornar a gestão do RBAC da tabela mais fácil sincronizando políticas entre as duas plataformas. Esta padronização e sempre implementando a especificação também significa um mínimo de bloqueio de fornecedor. As organizações estão sempre livres para trocar qualquer peça do sistema se encontrarem uma opção melhor: a plataforma de streaming, o catálogo Iceberg ou o lakehouse consultando/processando as tabelas. 

Se você chegou até aqui, esperamos sinceramente que você tenha tido uma noção do rigor cuidadoso na abordagem da Redpanda para esta oportunidade de mercado em alta, que vem de uma forte cultura de engenharia e paixão por construir produtos sólidos.  Como tecnólogos de coração com sólidos históricos, e com nosso foco no formato BYOC em particular, Redpanda e Databricks estão perfeitamente alinhados para entregar duas plataformas líderes de mercado que agem e se sentem como uma, e uma que, para você, resolve bem o problema de vapor para a mesa.

Experimente os Tópicos Iceberg com o Unity Catalog usando a oferta única da Redpanda de Traga-Seu-Próprio-Cloud hoje.  Ou, comece com uma avaliação gratuita de nosso sabor auto-gerenciado, Redpanda Enterprise!: https://cloud.redpanda.com/try-enterprise.

(This blog post has been translated using AI-powered tools) Original Post