JD.com constrói um lakestream com Apache Fluss e Apache Hudi para unificar streaming e batch

O caso do JD.com parte de uma escala grande: mais de 5.000 tabelas Hudi, mais de 700 PB migrados para o lakehouse e um Kafka com mais de 8.000 nós. Nesse volume, o custo de ler linha a linha pesa. No tópico de log de impressões, consumir tudo significa 195 GB/min, mas os jobs precisam de só 6 GB/min de colunas. Somando as duas pipelines paralelas (tempo real e batch) para os mesmos dados, o JD tinha armazenamento e computação duplicados e definições de métrica que divergiam.

A solução grava os dados uma vez no Fluss e faz o tiering contínuo para o Hudi. Jobs que precisam dos dois lados usam union reads, que tratam a tabela Hudi e os dados mais novos do Fluss como uma só. O ponto técnico central é a consistência. O writer do split 0 cria o instant do Hudi, marca como INFLIGHT e registra como pendente nos metadados de checkpoint. Os demais writers reutilizam esse instant, localizado pelo timestamp da rodada. O committer confere que todos os resultados são da mesma rodada, espera o instant ser concluído na timeline e só então envia ao Fluss Coordinator o snapshot com os offsets dos buckets. O instant time do Hudi vira o ID do snapshot no Fluss. Um commit por rodada torna as escritas visíveis de forma atômica.

Em 12 de outubro de 2026, o CEVIU noticiou "Apache Fluss Unifica Streaming e Lakehouse com Arquitetura Streamhouse", que apresentava a ideia de consolidar streaming, serviço e análise numa única tabela lógica. O caso do JD é a aplicação em produção desse conceito, agora com Hudi como destino do tiering. Em 4 de maio de 2026, a matéria "Engarrafando o Rio: Apache Fluss no EKS" citava tiering para Iceberg e Paimon. O trabalho do JD estende essa lista com um plugin para Hudi, que está sendo contribuído ao projeto como FIP-24.

Para quem opera pipelines de treino de modelos, o recado é que dá para cortar uma das duas pipelines sem abrir mão de dados frescos nem de backfill. Os números (mais de 80% menos custo de computação batch, mais de 50% menos armazenamento) vêm do próprio JD, num caso de ranking de recomendação, então vale validar no seu volume. O desenho de um commit Hudi por rodada, com offsets reportados só depois, é um padrão reaproveitável para quem precisa de consistência entre stream e lake.