CEVIU News - CEVIU Dados - 29 de junho de 2026

O Flink 2.3 avança em direção a uma plataforma de dados de streaming declarativa. As tabelas materializadas agora podem evoluir por meio de alterações de DDL e de consultas, evitando o reprocessamento histórico desnecessário em muitos cenários comuns. Além disso, o SQL adiciona conversão de changelog, tratamento explícito de conflitos de upsert e suporte nativo ao S3 sem dependências do Hadoop.

O Pinterest desenvolveu um sistema de evolução de schema para CDC integrado ao Kafka, Flink, Spark e Iceberg, tratando o schema como um contrato. Os schemas de origem e os mapeamentos de destino geram artefatos do Flink, Spark e Iceberg de forma automatizada, enquanto verificações baseadas em push e pull detectam desvios (drift). As alterações são implantadas com auditabilidade via PR, recuperação baseada em SLAs e mecanismos de fallback para backfill.

O SmithDB constrói índices invertidos utilizando parsing de JSON eficiente, tokenização, string interning e radix sorting. O processo de interning aumentou a velocidade de construção em cerca de 2,2 vezes. Além disso, a compactação via streaming limita o uso de memória independentemente do tamanho do índice, enquanto blocos alinhados e a coalescência de requisições reduzem as operações de GET no armazenamento de objetos. Para garantir dados atualizados em menos de um segundo, as consultas realizam o merge dos índices armazenados em SSD local com os segmentos do armazenamento de objetos.

Para consolidar dados de transações dispersos em mais de 500 milhões de perfis de usuários, a Razorpay desenvolveu uma Customer Data Platform (CDP) interna capaz de gerar segmentos de público consultáveis em tempo real. A arquitetura utiliza DAGs do Airflow combinados com Spark para o processamento diário de segmentos, aplicando técnicas de reutilização e deduplicação de dados. Para garantir a ingestão confiável no DynamoDB, a equipe implementou fluxos de trabalho com o Temporal, permitindo o versionamento de dados sem tempo de indisponibilidade (zero-downtime). Além disso, a plataforma utiliza buscas com hashes para realizar consultas seguras e preservar a privacidade dos dados dos usuários.

O desempenho real das cargas de trabalho é mais importante do que benchmarks de destaque porque os sistemas em produção precisam lidar com dados reais, concorrência, latência, escala e custo. Alegações de performance devem ser avaliadas com base na correspondência com a sua carga de trabalho, se a configuração está pronta para produção, se os resultados se mantêm com o crescimento dos dados e se o produto está realmente disponível.

É possível criar uma aplicação auto-hospedada que simula a experiência do dbt Cloud combinando o dbt Core com uma interface em React e FastAPI, utilizando o Prefect para a orquestração. A principal lição desse desenvolvimento é priorizar o uso de APIs em vez de raspagem de CLI para garantir uma gestão confiável de jobs, logs, deploys e monitoramento de status de execução em tempo real.

O Hardwood 1.0 é um leitor de Parquet nativo para JVM pronto para produção, voltado para Java 21+, que elimina dependências obrigatórias e paraleliza a decodificação de páginas entre núcleos de CPU por padrão. O projeto oferece suporte a tipos físicos e lógicos do Parquet, projeções, predicate push-down, além de arquivos locais e em armazenamento de objetos, contando com APIs de linha e de lote de colunas. Benchmarks demonstram uma performance de 16,5 milhões de linhas por segundo e acelerações de aproximadamente 17 a 18 vezes com o uso de selective push-down.

Um problema notável de desempenho no Kafka Share Groups ocorre ao utilizar a configuração record_limit com menos consumidores do que partições, especialmente sob condições de desbalanceamento de partições (partition skew). Esse cenário causa esperas de busca patológicas, o que pode reduzir drasticamente a velocidade de consumo durante a limpeza de backlogs ou sob cargas de trabalho desbalanceadas. A mitigação mais simples para esse comportamento é garantir o uso de, pelo menos, o mesmo número de consumidores em relação ao número de partições ao executar o sistema com record_limit.

O Manticore reescreveu seu pipeline de embeddings no ONNX Runtime, reduzindo o desperdício de CPU e aumentando o throughput em até 14 vezes para buscas vetoriais de baixa latência. A nova arquitetura compartilha uma única sessão ONNX thread-safe, desativa o spinning intra-op e processa os documentos individualmente para evitar contenção de travas e o overhead de padding com comprimentos variáveis.

Uma avaliação com 250 execuções realizada pela Wix revelou que documentações otimizadas para agentes aumentaram a taxa de conclusão de tarefas de CLI de 67% para 87%, reduziram o consumo de tokens em 35% e superaram execuções baseadas apenas em skills quando estas estavam desatualizadas ou desalinhadas. Para tarefas de API, ambas as abordagens atingiram 80% de conclusão, mas as baseadas em documentação rodaram 31% mais rápido, enquanto as baseadas em skills consumiram 29% menos tokens. A recomendação é utilizar documentações otimizadas como base, adotando as skills como uma camada avaliada de caching.

O Dropbox utilizou o DSPy para converter avaliações de IA em melhorias concretas para o Dash Chat, combinando avaliações baseadas em LLM-as-judge, exemplos rotulados por humanos, replay offline e validação estatística. O resultado foi uma redução no número de respostas incompletas, melhor cobertura da intenção do usuário e menor consumo de tokens, sem comprometer a qualidade das respostas.

Novos gráficos de host e domínio oferecem mais de 6 bilhões de arestas para análise de links em larga escala sem a necessidade de rodar seu próprio crawler.

Um desafio de agentes de programação transformou-se em um laboratório colaborativo, no qual os agentes compartilham playbooks, compartilham cotas de uso, realizam debugging do trabalho uns dos outros e acumulam pequenas melhorias que resultam em grandes ganhos de desempenho.