优步的任务是提供“对每个人来说，在任何地方都可以获得像自来水一样可靠的出行服务”。为了履行这一承诺，优步依赖于在每个层面做出数据驱动的决策。大部分的决策都得益于更快的数据处理。例如，使用数据来理解一个地区以便于增加业务，或城市运营团队对新数据的访问来运营每个城市。不用说，数据处理系统的选择和必要的服务水平协议是数据团队与优步用户之间日常交互的主题。
在本文中，我想基于在优步建立数据基础设施的经验和经历，讨论准实时案例中数据处理系统的选择。在本文中，我认为通过增加新的增量处理原语到现有的Hadoop技术中，将能以更少的开销和统一的方式解决很多问题。在优步，我们正在构建相应的系统来解决这里总结的问题，并且以开放的态度，希望与对这一领域有兴趣的、志同道合的组织进行合作。
准实时案例
首先，让我们定义这类案例。在一些场景里，长达一小时的延迟是可容忍的，他们在大部分情况下都可以通过在MapReduce/Spark上用传统的批处理来执行，同时数据一般会向Hadoop/S3上增量添加。与之相反的另一个极端的案例是：需要小于一到两秒的延迟，通常涉及到将你的数据输送到一个可扩展的键值存储（已经在这个上工作）并且进行查询。诸如Storm、Spark流处理以及Flink之类的流式处理系统已经相当好地构建了实际可以支持约一到五分钟延迟的应用。流式系统对于像欺诈检测、异常检测或者系统监控这些需要机器快速响应做出的决策或者以盯着计算机屏幕为日常工作的人来说是非常有用的。
这两个极端之间给我们留下了一个大鸿沟，即从五分钟到一小时的端到端的处理延迟。在本文里我将这种情况称为准实时。大部分准实时案例商业仪表板，或是一些辅助人工决策的应用。下面是一些准实时可能的应用场景：
1.观察过去X分钟内仪表板上是否有任何异常;