A Uber anunciou o lançamento do IngestionNext, uma plataforma de ingestão de dados com abordagem streaming-first para seu data lake, que representa um avanço significativo na redução da latência e do consumo de recursos computacionais. Desenvolvida para substituir os tradicionais jobs em batch, a nova arquitetura processa eventos em tempo real, diminuindo o atraso na disponibilidade dos dados de horas para minutos e otimizando o uso de infraestrutura em cerca de 25%.
Desafios da ingestão tradicional e motivação para a mudança
Historicamente, a Uber utilizava pipelines baseados em Apache Spark que executavam ingestões em batch programadas. Apesar da capacidade de processar grandes volumes, esse método introduzia atrasos consideráveis entre a geração dos dados e sua disponibilidade para análises, experimentos e modelos de machine learning. Essa latência impactava a agilidade das equipes e a qualidade dos insights gerados.
Segundo Kai Waehner, Global Field CTO, a mudança para um sistema streaming-first tem como objetivo tratar a frescura dos dados como uma dimensão crucial da qualidade da informação, permitindo decisões mais rápidas e precisas.
Arquitetura e componentes do IngestionNext
O IngestionNext foi construído sobre tecnologias consolidadas no ecossistema de dados em streaming:
- Apache Kafka: responsável pela ingestão contínua dos eventos;
- Apache Flink: processa os fluxos em tempo real, executando transformações e garantindo a consistência;
- Apache Hudi: gerencia o armazenamento dos dados no data lake, permitindo commits transacionais, rollbacks e suporte a time travel.
Essa combinação possibilita a ingestão de milhares de datasets com alto volume global, suportando dashboards analíticos, plataformas de experimentação e cargas de trabalho de machine learning com maior velocidade.
Além disso, um plano de controle automatiza o ciclo de vida dos jobs, configurações e monitoramento da saúde dos processos, enquanto estratégias de failover regional garantem continuidade e evitam perda de dados em situações de falha.
Principais desafios técnicos e soluções implementadas
Adotar um modelo streaming-first trouxe desafios relevantes:
- Granularidade dos arquivos: a geração de muitos arquivos pequenos no formato Parquet pode prejudicar o desempenho e a eficiência do armazenamento. Para mitigar isso, foram implementadas estratégias de mesclagem em nível de grupos de linhas e mecanismos de compactação contínua.
- Complexidade da evolução de esquema: o Apache Hudi foi aprimorado para suportar mesclagem de dados com esquemas diferentes usando técnicas de padding e masking, embora isso eleve a complexidade e o custo de manutenção.
- Gerenciamento de checkpoints e recuperação: o sistema rastreia offsets das streams upstream e coordena commits para assegurar a correção dos dados e permitir recuperação confiável em caso de falhas.
- Skew de partições: mecanismos específicos foram adotados para lidar com desequilíbrios na distribuição dos dados durante o processamento.
Impactos e resultados obtidos
A migração para o IngestionNext resultou em uma redução de latência de ingestão de dados de horas para poucos minutos, acelerando a disponibilidade para análises e experimentos. Além disso, a substituição de jobs batch por pipelines streaming contínuos permitiu uma redução de aproximadamente 25% no uso de recursos computacionais.
Suqiang Song, coautor do blog de engenharia da Uber, destacou que a nova plataforma habilitou uma pilha de dados em tempo real, do processo de ingestão à transformação e análise.
Limitações atuais e perspectivas futuras
Embora a frescura dos dados brutos tenha melhorado substancialmente, os engenheiros reconhecem que as transformações e pipelines analíticos downstream ainda podem introduzir latências adicionais. O foco futuro será estender as capacidades streaming para essas etapas subsequentes, garantindo que as melhorias na ingestão se propaguem por toda a cadeia de processamento e análise.
Links úteis
- Apache Hudi – Pull Request relevante
- Recursos gratuitos para aprendizado contínuo
- Contato InfoQ
- Fonte original no InfoQ
Frequently Asked Questions
Por que a transição de jobs em batch para streaming reduziu os custos computacionais da Uber?
Diferente dos jobs em batch do Apache Spark, que exigem picos de processamento massivos para tratar grandes volumes acumulados, o IngestionNext distribui a carga de forma contínua usando Apache Flink. Isso elimina a necessidade de superdimensionar a infraestrutura para picos de demanda, otimizando o uso de CPU e memória em 25%.
Como o IngestionNext resolve o problema de desempenho causado pela geração de múltiplos arquivos pequenos?
A ingestão contínua em tempo real naturalmente gera muitos arquivos pequenos no formato Parquet, o que degrada a performance do data lake. Para mitigar isso, a Uber implementou estratégias avançadas de mesclagem em nível de grupos de linhas e mecanismos de compactação contínua diretamente na camada de armazenamento do Apache Hudi.
De que forma a plataforma lida com a evolução de esquemas de dados sem interromper o fluxo de streaming?
O IngestionNext aprimorou o Apache Hudi para suportar a mesclagem de dados com esquemas diferentes de forma dinâmica. O sistema utiliza técnicas de padding (preenchimento) e masking (mascaramento) para garantir a compatibilidade dos dados em tempo real, embora isso aumente a complexidade de manutenção do pipeline.
O IngestionNext garante que todo o fluxo de análise da Uber ocorra em tempo real?
Não totalmente. Embora a plataforma garanta que os dados brutos cheguem ao data lake em minutos, as transformações e pipelines analíticos downstream (etapas posteriores) ainda podem introduzir latências adicionais. A Uber planeja estender as capacidades de streaming para essas fases subsequentes no futuro.
Como o sistema garante a consistência e evita a perda de dados em caso de falhas críticas?
A consistência é assegurada pelo Apache Hudi através de commits transacionais e suporte a rollbacks. Em caso de falhas, o sistema rastreia os offsets das streams do Apache Kafka para uma recuperação precisa, contando ainda com um plano de controle que executa estratégias de failover regional automatizado.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
