Uber的工程团队撰写一篇文章，介绍了他们的大数据平台如何从传统的基于关系型数据库的ETL作业演变为基于Hadoop和Spark的平台。可扩展的摄取模型、标准传输格式和用于增量更新的自定义库是这个平台的关键组件。

Uber的各个团队使用大数据来预测乘客需求、欺诈检测、地理空间计算以及解决乘客注册流程的瓶颈问题。他们在2014年之前开发的初始解决方案基于MySQL和PostgreSQL。那个时候，他们的数据相对较少——几TB——可以放在这些RDBMS中，用户必须知道如何进行跨数据库查询。城市运营团队、数据科学家和分析师以及工程团队在使用这些数据。在进行工程标准化后，他们开始采用Vertica——一个面向列的分析平台——由Extract-Transform-Load（ETL）作业提供支持。自定义查询服务通过SQL提供对数据的访问。数据量开始增长到数十TB，同时使用这些数据的团队和服务数量也在增长。Uber在这个阶段面临的主要问题是缺乏水平可扩展性，由于数据生产者和消费者之间缺乏正式模式，导致成本增加和数据丢失。

工程团队在下一阶段采用了Hadoop，从多个数据存储提取数据而不对数据进行转换。Apache Spark、Apache Hive和Presto作为查询引擎，是整个技术栈的组成部分。Vertica速度很快，但扩展成本很高，而Hive存在的问题恰好相反。使用自定义模式服务将模式和数据存储在一起解决了前一阶段所面临的问题。数据量增长到数十PB，数据基础设施每天在10000个虚拟CPU核心上运行10万个作业。

尽管具备了水平可扩展性，但仍然遇到了HDFS瓶颈。在HDFS集群中，NameNode负责跟踪集群中每个文件的保存位置，并维护目录树。HDFS针对大型文件的流式访问进行了优化，太多的小文件导致访问效率低下。当他们的数据量超过10 PB时，这个问题就出现了。他们通过调整NameNode垃圾回收、限制小文件数量和HDFS负载管理服务来缓解HDFS瓶颈问题。此外，数据无法以最快的速度提供给最终用户。Uber工程经理Reza Shiftehfar写道：

Uber的业务是实时运行的，因此，我们的服务需要访问尽可能新鲜的数据。为了加速数据交付，我们不得不重新构建我们的管道，以便只提取增量的更新过的和新的数据。

图片来源

结果出来的是一个叫作Hudi（Hadoop Upserts anD Incrementals）的自定义Spark库。它在HDFS和Parquet（存储文件格式）之上构建了一个层，允许更新和删除，从而可以进行增量的ETL作业。Hudi的原理是让用户使用上一个检查点时间戳进行查询，以获取自检查点以来已更新的所有数据，不需要进行全表扫描。这使得模型化数据的延迟从24小时缩短到不到一个小时，原始数据的延迟缩短到30分钟。

除了Hudi，Uber大数据平台最新阶段的另一个组件是通过Apache Kafka摄取数据。一个叫作Marmaray的组件从Kafka获取数据变更，并使用Hudi库将它们推送到Hadoop。所有这些都是使用Apache Mesos和YARN编排的。Mesos适合长期运行的服务，YARN适合批处理和Hadoop作业。Uber使用了基于Mesos构建的自定义调度程序框架Peloton来管理计算工作负载。

查看英文原文：The Evolution of Uber’s 100+ Petabyte Big Data Platform

创作场景

Uber：100 PB 大数据平台演化简史