A equipe de engenharia da Uber publicou um artigo sobre como sua plataforma de big data evoluiu de tarefas ETL tradicionais com bancos de dados relacionais para uma plataforma baseada no Hadoop e Spark. Um modelo de ingestão escalável, formato de transferência padrão, e uma biblioteca personalizada para atualizações incrementais são os principais componentes da plataforma.
Várias equipes da Uber usam big data para coisas como previsão de demanda por corridas, detecção de fraudes, computação geoespacial e endereçamento de gargalos no processo de cadastro de parceiros. Sua solução inicial, desenvolvida antes de 2014, foi baseada em MySQL e PostgreSQL. A quantidade relativamente pequena de dados que eles tinham até então - alguns TB - cabia nesses RDBMSs, e os usuários precisavam se descobrir por si próprios como consultar os bancos de dados. As equipes de operações da cidade, cientistas de dados, analistas e equipes de engenharia usam esses dados.
Um esforço de padronização levou à adoção do Vertica - uma plataforma analítica orientada a colunas - suportada por tarefas ad-hoc de extração, transformação e carga (ETL). Um serviço de consulta personalizada fornece acesso aos dados usando SQL. A quantidade de dados cresceu dezenas de TB, acompanhada por um crescimento no número de equipes e serviços que usaram esses dados. Os principais problemas enfrentados pelo Uber neste estágio foram a falta de escalabilidade horizontal, aumento de despesas e perda de dados devido à falta de um esquema formal entre produtores de dados e consumidores.
A equipe de engenharia adotou o Hadoop na fase seguinte para ingerir dados de vários armazenamentos sem transformá-lo. Apache Spark, Apache Hive, e Presto usados como mecanismo de consulta fazem parte da pilha. A Vertica foi rápida, mas não conseguiu escalar mais barato, enquanto a Hive teve o problema oposto (PDF). Armazenar o esquema e os dados juntos usando um serviço de esquema customizado resolveu os problemas enfrentados na fase anterior. A quantidade de dados cresceu dezenas de PBs e a infraestrutura de dados executou 100 mil tarefas por dia em 10.000 núcleos de CPU virtuais.
Apesar da escalabilidade horizontal estar em vigor, eles se depararam com gargalos no HDFS. Em um cluster HDFS, um NameNode mantém o controle de onde cada arquivo no cluster é mantido e mantém a árvore de diretórios. O HDFS é otimizado para acesso de streaming de arquivos grandes, e muitos arquivos pequenos tornam o acesso ineficiente. O Uber encontrou esse problema quando o volume de dados aumentou além de 10 PB. Eles contornaram os gargalos do HDFS ajustando o garbage collection do NameNode, limitando o número de arquivos pequenos e um serviço de gerenciamento de carga do HDFS. Além disso, os dados não estavam disponíveis com rapidez suficiente para os usuários finais. Reza Shiftehfar, gerente de engenharia da Uber, escreveu que:
Os negócios da Uber operam em tempo real e, como tal, os serviços exigem acesso a dados o mais recentes possível. Para agilizar a entrega dos dados, tivemos que redesenhar o pipeline para a ingestão incremental apenas de dados atualizados e novos.
Imagem - https://eng.uber.com/uber-big-data-platform/
O resultado foi uma biblioteca personalizada do Spark chamada Hudi (Hadoop Upserts anD Incrementals). Ele forma uma camada sobre o HDFS e o Parquet (um formato de armazenamento de arquivo) que permite atualizações e exclusões, atendendo assim à meta de que os trabalhos de ETL se tornem incrementais. O Hudi funciona permitindo que os usuários consultem o último carimbo de data / hora do seu ponto de verificação para buscar todos os dados que foram atualizados desde o ponto de verificação, sem a necessidade de executar uma verificação completa da tabela. Isso reduziu a latência de 24 horas para menos de uma hora para dados modelados e 30 minutos para dados brutos.
Junto com Hudi, a outra adição à fase mais recente da plataforma de big data do Uber é a ingestão de dados por meio do Apache Kafka com cabeçalhos de metadados anexados. Um componente chamado Marmaray pega as mudanças do Kafka e as envia para o Hadoop usando a biblioteca Hudi. Tudo isso é orquestrado usando o Apache Mesos e o YARN. Embora o Mesos seja bom para serviços de longa duração, o YARN é mais adequado para trabalhos em lote / Hadoop. O Uber usa seu próprio framework de agendamento personalizado, o Peloton, construído sobre o Mesos para gerenciar suas cargas de trabalho de computação.