Wind Mobility 公司如何构建无服务器数据架构

Original URL：https://aws.amazon.com/cn/blogs/big-data/how-wind-mobility-built-a-serverless-data-architecture/

本文为Wind Mobility公司商务智能负责人Pablo Giner撰写的客座文章。

过去几年当中，城市内的短途出行已经成为一大热门议题。随着污染指数达到历史最高水平，世界各地的市政及企业在积极参与法规制定的同时，也在努力构建各类缓解性的应对方案。

Wind Mobility公司致力于将城市短途交通推广至全球范围，帮助通勤群体们享受更便捷、也更具可持续性的生活方式。

在Wind Mobility，我们以同步于用户需求的速度快速推动业务扩展，并以更经济、更具环境友好性的方式提供服务。我们优化了车辆分配，避免在已经过度拥挤的城市中部署超出实际需求数量的踏板车辆，同时尽可能在正确的时间将车辆摆放在用户们最需要的位置附近。

我们是怎么做到的？简单来说，就是最大限度优化我们的运营能力。为此，我们需要深入理解用户在不同条件下的行为，同时认清自身拥有的潜力。

快速增长的前提——可扩展性与灵活性

我们知道，在着手应对这一挑战之前，我们需要通过多种不同来源进行数据收集——包括用户与应用程序间的交互、用户需求、踏板车的物联网信号以及运营指标等等。为了对收集到的大规模数据集进行分析并提取具备可行性的洞见，我们需要建立一套数据湖。虽然宏观目标非常明确，但具体范围却仍然有待权衡。随着不断开拓新的市场，我们也在努力扩大经营规模。业务的快速增长与扩展，使我们很难预测需要消耗的具体数据量。我们还推出新的微服务以支持业务增长，这又进一步增加了业务体系内的数据源规模。为此，我们需要一套具备敏捷特性、易于上手，而且能够充分适应业务增长的架构方案。很明显，无服务器架构是最理想的选项，我们的100%无服务器基础架构设计也就此拉开帷幕。

第一项挑战就是从现场踏板车中获取并存储数据，通过移动应用端提取事件、运营指标以及合作伙伴API。我们使用AWS Lambda捕捉运营数据库与移动应用中的变更，并将事件推送至Amazon Kinesis Data Streams，借此建立起强大的实时响应能力。此外，我们还使用Amazon Kinesis Data Firehose将数据写入Amazon Simple Storage Service（Amazon S3）以供后续分析。

在使用Amazon S3并根据常见用例进行适当分区（按照日期、区域、业务范围以及数据源进行分区）之后，我们还需要找到一种数据查询方法，借此实现数据剖析（理解数据中的结构、内容与相互关系）与即席分析。为此，我们选择了AWS Glue爬取器进行数据分类，同时配合Amazon Athena从AWS Glue数据目录中读取并运行查询。但是，即席分析与数据剖析只在日常业务中占据极低比例，我们的大多数数据处理计算时长主要用于将多个数据源转换为数据仓库、合并原始数据、进行数据建模、添加新属性，最终挑选数据元素（这些元素在我们的分析与预测需求中占比达95%）。

这里正是负载强度最高的部分。我们需要解析持续生成的日均数百万个踏板车与用户事件（每秒超过300个事件）并从中提取可行洞见。我们选择AWS Glue执行这项任务。我们的主要ETL作业会从Amazon S3中读取新添加的原始事件数据，使用Apache Spark加以处理，并将结果写入至我们的Amazon Redshift数据仓库。AWS Glue同时也是我们按需扩展能力中的重要一环。经过全面的评估与测试，我们意识到AWS Glue ETL作业能够充分满足我们的所有需求，帮助我们摆脱因基础设施采购与管理带来的运营开销。

架构概述

下图所示为我们的当前数据架构，其中包含两条无服务器数据收集、处理与报告管道：

• 来自Amazon Relational Database Service（Amazon RDS）与MongoDB的运营数据库。
• 物联网与应用程序事件，接下来是用于数据剖析的Athena，最后是用于报告的Amazon Redshift。

每一天，我们都会使用运行在AWS Glue上的自动管道对数据进行多次处理与转换。以此为基础，我们的团队得以集中精力进行数据分析并构建机器学习（ML）应用程序。

我们选择Amazon QuickSight作为商务智能工具，用以帮助我们可视化并更好地理解当前的运营KPI。此外，我们还使用Amazon Elastic Container Registry (Amazon ECR)存储包含自定义ML算法的Docker镜像，并使用 Amazon Elastic Container Service (Amazon ECS)训练、评估并托管各类ML模型。我们每天会对模型进行多轮训练及评估。以关于踏板车的需求、用户切换以及行驶走向作为输入数据，我们运行的模型有助于在任意给定时间段内优化特定城市内的车队利用率。

下图所示，为我们如何将来自数据湖的数据整合至机器学习训练、测试与服务系统当中。首先，我们的开发人员会处理应用程序代码并提交变更，这些变更将经由我们的CI/CD管道被封装于新的Docker镜像当中，镜像又将进一步存储在Amazon ECR注册表内。我们将这些镜像推送至Amazon ECS中，通过DEV与UAT环境进行测试，而后再转移至RPOD（由Amazon ECS任务调度程序触发）。在执行期间，Amazon ECS任务（部分任务负责训练需求与使用量预测模型，部分任务负责发布每日及每小时预测结果，其余任务则负责根据预测结果优化车队分布）将从Amazon S3处读取配置与数据（由之前调度完成的各AWS Glue作业生成）。最后，结果将被存储回Amazon S3。这些管道的执行流程还受到MLFlow（运行在专门的Amazon EC2服务器内）的全程跟踪，而用于指示车队最终运营方式的结果则被放入Kapler map中供现场操作人员使用。

总结

在Wind Mobility公司，我们一直将数据视为运营体系的最前沿。为此，我们需要保证数据基础设施拥有充分的灵活性，能够切实满足行业中不断变化的实际需求——这也是我们选择无服务器架构的根本原因。过去一年以来，我们构建起一套数据湖、一套数据仓库、一款商务智能套件以及多种生产级数据科学应用程序。所有这一切，都出自一支小型技术团队之手。

此外，在过去12个月内，我们将多条数据管道的规模扩大了10倍，且没有造成任何速度减缓、也没有对架构进行任何重新设计。即使要在一周之内将车队规模扩大一倍，并将从踏板车处捕捉的数据总量提升十倍，无服务器数据架构都能够轻松完成同步扩展。这种强大的基础保障，使我们能够专注于简化日常运营、对变化做出快速反应并显著提高客户的满意度。

以下几项指标，也从多个维度证明了我们的成功：

• 速度 – 无服务器架构的部署与扩展速度更快，我们估计整体基础设施将功能发布速度提升了1倍。
• 可见性 – 我们对全球业务保持360度全方位可见性，业务体系可供各城市经理、财务团队以及管理委员会随时访问。
• 优化车队部署 – 我们很清楚在一天内的任意时段，客户在接下来几个小时中所需要的踏板车数量，并借此将客户投诉减少超过50%。

如果您也面对类似的挑战，我们的建议非常明确：请全面拥抱无服务器架构，并使用AWS提供的各类解决方案。

大家也可以在Facebook、Instagram 以及LinkedIn上关注我们，发现关于Wind Mobility的更多内容。

本篇作者