发布于: Nov 30, 2022
【概要】本文介绍了 Amazon Web Services 专业服务团队与 F1 共同使用这些数据，并配合机器学习与分析技术帮助粉丝们获取洞见、更好地理解赛场形势。
在设计云计算系统架构时，我们也需要满足多种要求，而且不少要求乍看起来似乎相互矛盾。通过使用云原生 Amazon Web Services 服务，我们得以专注于真正重要的工作，降低维护开销并最终实现业务目标。最后，按实际资源使用量计费的机制也让我们能够始终保持相对较低的运营成本。
在赛道上捕捉到信号之后，数据会首先通过 F1 主办方基础设施进行传递，而后可通过 HTTP 从 Amazon Web Services 云处调用。其中 Amazon API Gateway 充当应用程序入口点，而应用程序则以函数形式托管在 Lambda 之内，并由函数负责实现竞赛逻辑。当函数接收到传入消息时，它会更新存储在 Amazon DynamoDB 中的竞赛状态（例如各位车手的位置变动）。更新完成之后，函数会评估是否需要触发预测。如果需要，则使用 Amazon SageMaker 中训练完成的模型执行预测。预测结果将以响应形式被传回至 F1 主办方基础设施，并最后进入广播中心以供赛事主办方使用。最重要的是，我们要求整个过程要在 500 毫秒以内完成。
我们面临的第一个挑战在于，我们事先并不知道哪种方法真正具有可行性，特别是在对延迟时长提出严苛要求的前提之下。我们需要选择一套工具，保证我们能够快速完成原型设计、验证与试验，并让我们得以从概念验证阶段迅速过渡至可用于生产的应用程序。在这方面，我们使用到 Amazon Web Services 提供的多种无服务器产品，包括 Lambda, API Gateway, DynamoDB, Amazon CloudWatch 以及 S3。我们在 Lambda 上托管一套原型，其运营成本为零；当我们对结果感到满意时，则可使用一套简单脚本将应用程序转入生产环境。整个过程不需要分神于基础设施配置，因为 Lambda 会根据请求率自动对资源进行规模伸缩。在比赛结束之后，无需手动操作，多余的资源即会被释放。由于预测以实时方式进行，因此基础设施必须拥有极高的可用性。从传统角度看，构建这样一套基础设施往往需要一整个由专业系统工程师组成的高水平团队。但现在，Lambda 接管了一切，能够为任意应用程序提供高可用性基础设施。
在应用程序从赛场上接收到消息时，单一消息的内容永远不会直接触发预测。例如，一位驾驶员的位置变化并不能充分体现赛道的整体情况。预测需要更为综合的信息，包括赛道之前以及当下的全面情况，因此我们需要使用数据库来存储并管理比赛状态。DynamoDB 是一款关键工具，我们用它存储比赛状态、计算数据、当前正在监控的策略以及机器学习模型。无论表中的行数如何，DynamoDB 都能提供以毫秒为单位的性能，且不会带来任何运营开销。我们不必花时间精简及管理数据库集群，也无需分神于保证正常运行时间等运营任务。
为了实现从原型设计到生产的自动化迭代，我们使用了 CI/CD 工具（包括 Amazon CodePipeline 与 Amazon CodeBuild）以隔离环境，并在代码准备就绪后再将其转移至生产环境。我们使用 Amazon CloudFormation 实现了所谓基础设施即代码（IaC）方案，借此置备环境并建立起可预测的部署体系。
我们只在现场比赛或测试期间大量使用资源，借此控制实际使用的资源量。为了避免为冗余的预留空间支付太多成本，我们以往还需要手动启动及停止各类组件。但现在，我们使用的服务提供按实际使用量付费的模式，账单中只涉及我们使用的确切存储容量，并通过调用次数确定计算资源费用。而这一切，都被托管在 Lambda 之上，从而替代了以往将模型托管在 SageMaker 上的方法。关于在 Lambda 上托管模型的更多详细信息，请参阅本篇博文。
在运行机器学习模型方面，我们要求其具备与预期相符的准确率与运行时性能。为了保证准确率，我们需要使用能够实现快速测试、实验与迭代的工具。而在模型训练方面，我们选择了 Amazon SageMaker，其内置 XGBoost 算法属于梯度提升树算法的一种流行、高效开源实现方案。我们认真分析了赛车数据与模型预测，以提取出赛车数据中的可用特征。在完成模型与输入特征的优化设计之后，我们使用 Amazon SageMaker 中的训练作业通过历史赛事数据进行模型训练。在这套体系当中，资源的供应与撤销能够自动进行，保证数据科学家只需要专注于模型优化工作。此外，SageMaker 还允许用户控制实例类型以及用于训练的实例数量，为涉及大型数据集的训练场景提供有力支持。
算法的训练时长相对较为宽松，而推理过程则往往要求实时完成。F1 为全球数亿观众提供直播节目，而对于这样一种以毫秒为单位的运动项目，即使是几秒前的数据也可能无法反映赛场上的当前状况。为了满足响应时间需求，我们将在 Amazon SageMaker 中训练完成的模型加载至 Lambda 托管的应用程序当中，并通过函数代码执行推理。由于模型始终保持加载状态且毗邻正在运行的代码，所以我们可以将调用开销降至最低。我们还使用内置的 XGBoost 开源算法训练模型，同时配合附带的开源软件包将模型转换为更小、性能更高的格式，从而提高推理速度并缩小部署规模。由于我们将应用程序与模型托管在 Lambda 当中，因此能够灵活地扩展基础设施，并在无需操作干预的前提下轻松适应赛事期间不断变化的预测需求。
工具与服务的实际选择，对于项目能否成功至关重要。Amazon Web Services 提供的服务选项兼顾广度与深度，能够帮助我们结合实际需求及运营模式选择最合适的工具。无服务器技术则把我们从基础设施维护工作中解放出来，让我们专注于执行其他更为重要的任务。
入站策略洞见项目于 2019 年 3 月 17 日在 2019 F1 赛季澳大利亚大奖赛上首次亮相。为了充分展现入站策略洞见项目提供的视觉效果，我们又在 3 月 31 日将其引入巴林大奖赛。此轮比赛是 2019 赛季最激动人心的比赛之一，同时也让梅赛德斯车队的 undercut 策略拥有了闪亮的展示舞台。以下短片为汉密尔顿在提前一圈进站之后，利用新的轮胎快速追赶维特尔，并尝试在维特尔第十四圈进站时将其超越的片段。
通过视频，我们可以清楚看到汉密尔顿如何成功执行 undercut 策略。屏幕上的图形给观众们留下深深悬念，同时也帮助粉丝们深刻了解赛场上正在发生的一切。这款应用程序成功凭借通过历史数据训练出的机器学习模型，在 500 毫秒之内对追车时间间隔与成功超车概率做出实时预测。
F1 赛事在技术创新方面拥有悠久历史，但在海量数据的收集方面，如今我们才刚刚踏出第一步。当前，每辆赛车中的 300 多个传感器每秒可产生 110 万个数据点。本文介绍了 Amazon Web Services 专业服务团队与 F1 共同使用这些数据，并配合机器学习与分析技术帮助粉丝们获取洞见、更好地理解赛场形势。多支团队就此建立起共识，并通过反推需求以明确最终目标。这样顺畅和谐的并行工作体系，最终极大加快了项目进度并消除了种种瓶颈。
与其他企业一样，F1 主办方也希望在混乱中理清脉络，而我们使用的高级服务与应用的基本原理也将适用于各个行业。您可以使用 Lambda 进行应用程序托管，使用 DynamoDB 存储数据，并使用 Amazon SageMaker 进行模型训练，保证开发人员与数据科学家能够专注于更重要的工作。您不必耗费时间建立并维护基础设施，也不必担心正常运行时间与成本。相反，您将真正把精力集中在如何把业务知识转换为应用逻辑，并进行实验与快速迭代方面。
无论是有意推出个性化产品的网站开发商、希望高效运行的工厂、还是希望努力提高产量的农场，通过对来自业务中的数据进行收集与分析，您都将对下一步发展与扩张方向建立起更明晰的认知。Amazon Web Services 专业服务将随时为您的团队提供专业技能与经验指导，帮助您顺利达成业务愿景 。
相关文章