Cloudflare abre o Town Lake e revela que 53% das consultas ao seu lakehouse vêm de billing — e o que isso ensina sobre agentes de dados

Resumo: A Cloudflare abriu a caixa-preta do Town Lake, a plataforma de dados interna que reúne bilhões de eventos operacionais, financeiros e de segurança sob um único lakehouse. O detalhe que chamou atenção do mercado: 53% de todas as consultas ao sistema vêm da área de billing, o que reordena a discussão sobre onde nasce, de fato, o valor de um agente de dados em produção. Em cima do Town Lake, a empresa colocou um agente conversacional próprio chamado Skipper, capaz de traduzir perguntas em linguagem natural em consultas validadas contra o catálogo. Para times de dados e de plataforma no Brasil, é um estudo de caso raro e concreto sobre como uma empresa hyperscale une lakehouse aberto, catálogo semântico e agente de IA em um só produto interno.

O que a Cloudflare acabou de contar

Em um post técnico detalhado, a Cloudflare descreveu como consolidou dados operacionais, de bilhetagem, segurança e negócio em uma única plataforma chamada Town Lake. A arquitetura combina três peças de código aberto que viraram consenso no ecossistema moderno de dados: Apache Iceberg como formato de tabela, Apache Trino como engine de consultas distribuídas e DataHub como catálogo. O storage roda no próprio R2, o serviço S3-compatível da Cloudflare, o que simplifica governança, custo e latência dentro da rede da companhia.

Por cima, foi construído o Skipper, um agente de análise que aceita perguntas em português corporativo (“qual foi o maior cliente por consumo de Workers no último trimestre?”) e produz SQL validado, executa, devolve o resultado e explica o raciocínio. O agente usa metadados, definições de esquema, linhagem de transformações e documentação para reduzir alucinações, e ainda faz runtime inspection — olha para o resultado parcial antes de confiar nele.

Por que 53% de billing é o número que importa

No período medido pela Cloudflare, o Town Lake processou 91.760 consultas de billing feitas por 324 funcionários. Isso inclui análise financeira, investigação de suporte e relatórios operacionais. O dado é interessante porque contraria o discurso corrente de que agentes de IA em plataformas de dados servirão primariamente para BI executivo ou data science: o valor imediato aparece em atividades pouco glamurosas — reconciliar cobrança, entender consumo por cliente, responder chamados. É onde erro humano custa dinheiro e onde a linguagem natural corta minutos de cada consulta.

Por que importa (e o status no Brasil)

Para o mercado brasileiro, três leituras são úteis. Primeiro, valida um stack aberto que muitos times daqui já vinham adotando de forma isolada (Iceberg + Trino + catálogo). Não é preciso pagar licenças de data warehouse proprietário para chegar a uma plataforma capaz de responder a uma agente de IA. Segundo, mostra que a “killer app” de agentes de dados internos não é o dashboard bonito — é o time de finance ops, cobrança e atendimento operacional. Isso muda a priorização de PoCs em bancos, telecoms e varejo. Terceiro, o desenho separa claramente três camadas: contrato semântico (catálogo), execução (engine) e experiência (agente). Times brasileiros que tentam “colocar um LLM em cima do banco” costumam falhar exatamente porque ignoram a camada de contrato semântico.

Riscos e limitações

O caso da Cloudflare tem particularidades que precisam ser lidas com cuidado. A empresa já operava com forte cultura de plataforma, com times de site reliability maduros e catálogo alimentado por engenheiros — pré-requisitos que a maioria das corporações não tem. Além disso, a plataforma foi construída internamente por anos; não é um produto plug-and-play. Times que copiarem o desenho sem investir no catálogo e na governança de metadados vão colher um agente que responde rápido, mas com erros silenciosos — o pior tipo em billing. Há também o ponto óbvio de privacidade: agentes que acessam dados financeiros exigem trilha de auditoria, controle de acesso baseado em atributos e mascaramento sob demanda. Não é opcional.

Cenário: o que vem em seguida

O padrão “lakehouse aberto + catálogo semântico + agente conversacional” está virando o desenho de referência para quem quer self-service analytics real dentro de empresas. Nos próximos meses é razoável esperar duas coisas. Uma, mais fornecedores mainstream (Databricks, Snowflake, Google, AWS) vão empacotar o desenho como produto. Duas, comunidades open-source como Iceberg, Trino, DuckDB e DataHub devem receber contribuições para tornar o contrato semântico mais formal, com data contracts, políticas declarativas e métricas versionadas. Empresas que começarem agora a organizar o catálogo — mesmo antes de decidir qual LLM usar — chegam na frente.

Análise SWOT econômica

Conclusão prática

Se você lidera dados em uma empresa brasileira de médio ou grande porte, o recado é claro. Antes de escolher o LLM, priorize catálogo, linhagem e política de acesso. Escolha um caso de uso operacional (billing, suporte, reconciliação) onde a resposta certa vale dinheiro imediato. Adote um lakehouse aberto para não ficar preso a um fornecedor. E, quando ligar o agente, exija runtime inspection e guardrails auditáveis — porque o custo de um número errado em cobrança é maior do que o do agente. O caso Cloudflare é um manual, não uma cópia: use as ideias, não a réplica.

Fonte original: InfoQ — Cloudflare Details Unified Data Platform Where Billing Workloads Account for 53% of Queries. Cobertura técnica original em blog.cloudflare.com.