优步在Hadoop上做增量处理的案例

编者注：想了解更多关于优步是如何使用Hadoop和Spark的信息，请查阅Vinoth Chandar在2016年纽约Strata + Hadoop 世界大会上的演讲“Big data processing with Hadoop and Spark, the Uber way”。

优步的任务是提供“对每个人来说，在任何地方都可以获得像自来水一样可靠的出行服务”。为了履行这一承诺，优步依赖于在每个层面做出数据驱动的决策。大部分的决策都得益于更快的数据处理。例如，使用数据来理解一个地区以便于增加业务，或城市运营团队对新数据的访问来运营每个城市。不用说，数据处理系统的选择和必要的服务水平协议是数据团队与优步用户之间日常交互的主题。

在本文中，我想基于在优步建立数据基础设施的经验和经历，讨论准实时案例中数据处理系统的选择。在本文中，我认为通过增加新的增量处理原语到现有的Hadoop技术中，将能以更少的开销和统一的方式解决很多问题。在优步，我们正在构建相应的系统来解决这里总结的问题，并且以开放的态度，希望与对这一领域有兴趣的、志同道合的组织进行合作。

准实时案例

首先，让我们定义这类案例。在一些场景里，长达一小时的延迟是可容忍的，他们在大部分情况下都可以通过在MapReduce/Spark上用传统的批处理来执行，同时数据一般会向Hadoop/S3上增量添加。与之相反的另一个极端的案例是：需要小于一到两秒的延迟，通常涉及到将你的数据输送到一个可扩展的键值存储（已经在这个上工作）并且进行查询。诸如Storm、Spark流处理以及Flink之类的流式处理系统已经相当好地构建了实际可以支持约一到五分钟延迟的应用。流式系统对于像欺诈检测、异常检测或者系统监控这些需要机器快速响应做出的决策或者以盯着计算机屏幕为日常工作的人来说是非常有用的。

这两个极端之间给我们留下了一个大鸿沟，即从五分钟到一小时的端到端的处理延迟。在本文里我将这种情况称为准实时。大部分准实时案例商业仪表板，或是一些辅助人工决策的应用。下面是一些准实时可能的应用场景：

1.观察过去X分钟内仪表板上是否有任何异常;

2.测量过去X分钟内在网站上执行的试验进行的如何；

3.商业指标在X分钟间隔内的更新；

4.对一个机器学习管道在过去X分钟内进行特征抽取；

图一：处理延迟的不同着色图以及相关的典型技术。由Vinoth Chandar提供

通过“迷你”批次进行增量处理

解决准实时案例的选择是相当开放的。流式处理能够提供低延迟，并有较为基本的SQL支持能力，但是需要预先定义查询来达到较好的效果。专有的数据仓库有许多特性（例如，事务、索引），并且能支持随机和预定义的查询，但是这种专有数据仓库在规模上有限制而且价格昂贵。批处理可以解决大规模数据的场景，并通过Spark SQL/Hive提供成熟的SQL支持。但是这种处理的方式通常会有比较高的延迟。由于各有利弊，最后用户通常基于可用的硬件和他们组织内部的运维支持的方式来做出选择。我们将在本文的结论处在回头来看这些挑战。

下面我会介绍通过使用Spark/MapReduce而不是运行流式处理任务，以每X分钟执行迷你批任务的方式来解决准实时场景的一些技术优点。类似于Spark流处理中的微批次（以秒粒度执行操作），迷你批次以分钟粒度来运行。在本文中，我将通篇使用“增量处理”这一术语来指代这种处理方式。