Uber工程技术栈（三）:看曾经的独角兽背后用了哪些技术

异常检测

Argos是我们的内部异常检测工具，负责分析进来的度量指标，并基于历史数据，将它们与预测模型进行比对，从而确定当前数据是不是在预期范围内。

我们将通过异常检测算法每小时生成的动态阈值（红色和黄色）与进入的数据流进行比对。我们添加了实际的每一分钟的数据，以作参考（蓝色），这当然是事先未知的。阈值密切遵循实际度量指标的模式。

针对度量指标采取行动

Uber的μMonitor工具让工程师能够查看这些信息和阈值（无论是静态信息，还是Argos的智能阈值），并采取相应行动。如果数据流超出界限――比如说出行减少到某个城市的某个阈值以下，该信息就会传送到通用操作网关（Common Action Gateway）。这是我们的自动响应系统。不是说有问题就通知工程师，它会采取针对性措施，缩短问题的持续时间。如果部署带来了某个问题，就会自动回滚。

我们的观测工具大多数保留在Uber里面，因为它们是专门针对我们的基础设施，不过我们希望很快能够选取并开源通用组件。

创造性地使用数据

地图和试验团队依赖数据可视化，将数据转换为清楚、合理的信息。城市运营团队可以在地图上查看所在城市中实时移动的司机，而不是靠枯燥乏味的SQL查询获取洞察力。Storm和Spark将数据流处理成有用的业务度量指标。我们的数据可视化团队创建可重复使用的框架和应用程序，以使用可视化数据。

（表和置信区间可视化为我们的A/B测试平台Morpheus添加了功能）

我们使用JavaScript（ES5和ES6）以及React来构建数据产品，作为我们的核心工具。我们还在可视化组件中使用所有的图形Web标准：SVG、Canvas 2D和WebGL。我们开发的许多库是开源库，比如react-map-gl，我们依赖它们用于地图可视化：

可视化展示了react-map-gl的功能，这是由Uber数据可视化团队为MapboxGL-JS开发的一个包装器。

我们还开发了可视化框架，那样R、Shiny和Python等其他技术可以使用这些框架用于我们的图表组件。我们想要高数据密度的可视化，可以在浏览器中顺畅地执行。为了同时实现这两个目标，我们开发了基于WebGL的开源可视化工具。

这张Uber热图显示了载客车辆的密度。然后，我们从百分位分布上去除了高百分位（top percentile），看看基本概况。

地图

Uber的地图团队格外重视数据集、算法和地图数据、显示和路由等方面的工具，以及用于收集和推荐地址及位置的系统。地图服务（Map Service）在主要基于Java的堆栈上运行。

这方面容量最高的服务是Gurafu（https://eng.uber.com/engineering-an-efficient-route/），它提供了一组实用工具，可用于处理道路地图数据，通过提供更复杂的路由选项，提高效率和精度。Gurafu的前端是μETA，它在原始ETA（比如试验群组分段等）上增添了业务逻辑层。Gurafu和μETA都是建立在DropWizard框架基础上的Web服务。

我们的业务和客户依赖高度精确的ETA，所以地图服务工程师花费了大量和时间，提高这些系统的准确性。我们执行了ETA误差分析，以识别和修复故障来源。除了准确性外，问题的规模值得关注：每一秒，整个公司的系统都使用ETA信息来做出数量众多的决策。由于那些请求的延迟时间必须在5毫秒左右，算法效率就成了个大问题。我们不得不关注分配内存、执行并行计算，以及请求慢速资源（比如系统磁盘或数据中心网络）的方式。

地图服务还支持乘客和司机应用程序中的搜索框后面的所有后端技术。这些技术包括自动填写地址的搜索引擎、预测引擎和反向地理编码服务。自动填写地址的搜索引擎可以对地方和地址进行高速、偏向本地的偏置位置搜索。我们的预测引擎使用机器学习，基于结合的用户历史及其他信号，预测乘客目的地。预测占了输入目的地的50%左右。反向地理编码根据GPS来确定用户位置，另外我们根据总体出行历史记录，为建议的Uber载客地点提供了额外信息。