发布于: Oct 30, 2022
德甲联赛的领导层、管理团队以及开发部门一直在采用云计算服务的过程中与 Amazon Web Services 专业服务团队通力配合，希望借助机器学习的力量增强观众体验。Amazon Web Services 数据科学顾问的任务，正是通过高效运用机器学习技术加速客户业务成果。客户需要首先参与初步评估，并从业务及技术两个方面认真研究希望达成的结果与相应可行性。Amazon Web Services 专业服务顾问则为客户的内部团队提供专业技能与行业经验、开发概念验证（POC）项目、打造最低可行性产品（MVP）并最终将机器学习解决方案投入生产。在此期间，我们还将持续推动学习与知识的转移，保证技术层面的尝试始终能够与明确的商业价值对应起来。
除了在德甲联赛下辖子公司 Sportec Solutions 中进行的内部实验与原型开发之外，我们也在全力建设独立的完善研究社区，致力于进一步提升 xGoals 计算的性能与准确率。将这一领域的知识与正确的技术栈上结合，再配合上最佳实践，我们将能够在保证卓越运营、安全性、可靠性、性能效率与成本优化的同时，更快推动大规模创新与实际执行。
足球比赛的历史数据无疑是基于机器学习技术的 xGoals 模型的训练基础。我们使用这些数据训练机器学习模型，根据赛场上的特定条件推理 xGoals 可能得出的结论。为了进行数据质量评估与初步实验，我们需要进行探索性数据分析、数据可视化、数据转换以及数据验证。这方面工作，可以通过 Amazon SageMaker notebook 等方案进行。下一步自然就是将机器学习工作负载从研究阶段转移至开发环境。这一部署流程需要使用跨学科工程方法，包括将数据工程、数据科学与软件开发结合起来。生产设置还需要配合错误处理、故障转移与恢复计划等多项举措。总体而言，机器学习系统的开发与运营（MLOps）涉及一系列复杂流程，包括代码重构、重新设计与优化、自动化、设置云基础设施基础、实施 DevOps 与安全模式、执行端到端测试、监控并保证使用正确的系统设计。我们的目标，始终是尽可能在更多系统组件中实现自动化，最大程度减少人工干预与手动维护需求。
在下一节中，我们将进一步探讨 Amazon Web Services 为德甲比赛 Match Facts 提供的底层技术栈，以及在将 xGoals 投入生产环境时的基本注意事项。
传统的 xGoals 机器学习模型单纯以事件数据为基础。这意味着评估进球几率时，模型只考虑球员的当前位置及其与球门之间的距离。但德甲方面将射门事件与以 25 Hz 帧频获取的高精度位置数据结合起来——虽然更高的数据采集精度会给数据流分析管道带来更高的数据清洗与数据预处理压力，但却能够带来更准确的预测结果，进而全面抵消额外工作量与复杂性产生的开销。通过持续跟踪皮球与球员的位置，该模型能够确定一系列附加特征，例如球员到球门间的距离、当前射门角度、球员的速度、对方防守球员数量以及对方门将的扑救范围等。
在 xGoals 当中，我们自 2017 年开始就使用 Amazon SageMaker XGBoot 算法使用德甲联赛超过 40000 次历史射门数据训练机器学习模型。训练工作可以使用默认的训练脚本（以 XGBoost 作为内置算法）执行，也可以通过以下方法进行模型扩展：添加预处理与后处理脚本（将 XGBoost 作为框架）。Amazon SageMaker Python SDK 使您能够轻松通过内置的规模伸缩功能以编程方式执行训练作业。它还抽象了 XGBoost 自动超参数优化中所涉及的资源部署与管理复杂性。我们建议大家先从一小部分可用数据起步，借此实现更快的实验启动速度，而后逐步发展并最终在完整的数据集上实现更加复杂的机器学习模型优化。
xGoals 训练作业中包含一项二进制分类任务，其中将 ROC 曲线下面积（AUC）作为目标指标，同时配合高度不平衡训练与射门验证数据集（无论是否实际进球）。
基于贝叶斯搜索的超参数优化作业提供多种机器学习模型选项，我们可以选择性能最强的机器学习模型并将其部署至 Amazon SageMaker 端点之上。由于不同模型在训练中有着不同的资源与生命周期要求，因此我们的模型训练与托管环境彼此分离。我们可以使用 API 实时推理从应用程序（例如 Amazon Lambda 函数）或者 Amazon SageMaker notebook 内部调用端点。
但是，单纯使用 Amazon SageMaker 训练机器学习模型还远远不够。其他基础设施组件对于完整云机器学习管道的建立同样至关重要，具体包括数据集成、数据清洗、数据预处理、特征工程以及机器学习模型的训练与部署等等。此外，我们还需要对其他特定应用程序云组件进行集成。
在设计应用程序架构之前，我们已经建立起持续集成与持续交付/部署（CI/CD）管道。根据 Amazon Web Services 良好架构框架白皮书中的说明，我们采用多账户设置方法建立起独立开发、分段与生产 CI/CD 管道。我们将其与基础设施即代码（IaC）方法配合起来，在交付环境之外为每一项代码变更提供可预测的部署支持。以此为基础，团队即可成功隔离不同环境、缩短发布周期，并促进代码的可测试性。开发者工具部署到位之后，我们开始为应用程序设计基本架构。下图所示，为这套架构的基本情况。
数据以两种相互独立的方式进行摄取：Amazon Fargate（面向容器的无服务器计算引擎）用于接收位置与事件数据流，而Amazon API Gateway 则用于接收其他元数据，例如球队名单与球员姓名。此输入数据将触发对应的 Lambda 函数，后者负责处理多项短暂的一次性任务——例如自动撤销闲置资源，数据预处理，简单的提取、转换与加载（ETL）作业，并在每次使用新的匹配数据时进行多轮数据质量测试。我们还使用 Lambda 调用 Amazon SageMaker 端点，以给定的一组输入特征为基础检索 xGoals 预测结果。
我们使用两套数据库以存储比赛状态：键值数据库 Amazon DynamoDB，以及文档数据库 Amazon DocumentDB（兼容MongoDB）。后者可帮助我们使用嵌套结构轻松查询及索引 JSON 格式的位置与事件数据。这套数据库特别适合匹配那些要求以灵活 schema 实现快速迭代的工作负载。对于官方比赛数据的集中存储，我们使用 Amazon Simple Storage Service (Amazon S3)。Amazon S3 负责存储所有比赛历史数据，用于迭代改进 xGoals 模型。Amazon S3 还将存储关于模型性能、模型监控以及安全指标的全部相关元数据。
为了监控应用程序的性能，我们使用 Amazon Amplify Web 应用程序。这样，运营团队与各相关方能够通过用户友好型仪表板查看系统运行状态、Match Facts 计算状态以及底层云基础设施的运行概述。这样的运营洞见能够帮助我们捕捉并建立赛后回顾分析，进而对当前系统进行持续改进。该仪表板还能帮助我们收集大量测量指标，衡量并评估业务目标的实现水平。最后，持续监控相关 KPI（包括总体系统负载与性能、端到端延迟以及其他非功能性要求）则能保证德甲联赛从业务及技术角度充分了解当前系统。
xGoals 架构完全以无服务器形式构建，旨在提高可扩展性与易用性。全托管服务消除了服务器及其他基础设施组件带来的繁重管理与维护工作。这样一套架构，使我们能够在比赛开始之后动态支持各类需求，并在比赛结束时自动释放资源——无需任何手动操作——显著降低应用程序成本与运营开销。
相关文章