Stripe使用机器学习来响应用户复杂的现实问题。机器学习使雷达能够阻止欺诈，并通过计费重试网络上的失败收费。Stripe为全球数百万企业提供服务，我们的机器学习基础设施在许多机器学习模型中获得数亿次预测。这些模型由数十亿个数据点驱动，每天都有数百个新模型接受训练。随着时间的推移，随着我们模型性能的不断提高，数据量、数据质量和信号数量都有了极大的增长。以这种规模运行基础设施带来了一个非常实际的数据科学和ML问题：我们如何为每个团队提供训练模型所需的工具，而不要求他们操作自己的基础设施？我们的团队还需要一个稳定和快速的ML管道，以便在应对快速变化的世界时不断更新和培训新模型。为了解决这个问题，我们构建了Railyard，一个API和作业管理器，用于以可伸缩和可维护的方式培训这些模型。它的动力来自Kubernetes，这是一个我们从2017年底开始合作的平台。Railyard使我们的团队能够通过集中管理的ML服务每天独立培训他们的模型。在许多方面，我们建立Railyard是为了向Stripe用户反映我们的产品开发方法：我们希望团队专注于核心工作培训，开发机器学习模型，而不是操作基础设施。在这篇文章中，我们将讨论Railyard和操作机器学习基础设施的最佳实践，我们在构建这个系统时发现了这一点。为组织提供有效的机器学习基础设施我们已经在生产中运行Railyard一年半了，我们的ML团队已经将它作为他们共同的培训环境。在这段时间里，我们对成千上万的模型进行了这种架构的培训，下面是我们最大的收获：构建一个通用的API，而不是绑定到任何一个机器学习框架。我们没有预料到车队会扩展到铁路站。我们首先关注的是分类器，但后来团队将该系统应用于时间序列预测和word2vec风格的嵌入。完全管理的Kubernetes集群减少了整个组织的运营负担。Railyard直接与kubernetesapi交互（与更高层次的抽象相反），但是集群完全由另一个团队操作。我们能够从他们的领域知识中学习保持集群可靠运行，这样我们就可以专注于ML基础设施。我们的Kubernetes集群为我们提供了扩展和扩展的极大灵活性。当我们需要训练更多的模型时，我们可以轻松地扩展集群的容量，或者在需要额外的计算资源时快速添加新的实例类型。集中跟踪和调试模型允许我们轻松地跟踪和调试模型。我们不再问"你把你的工作成果保存在任何地方让我们可以看吗？""你的工作ID是什么？我们观察总体指标并跟踪集群内培训工作的总体绩效。构建一个用于模型训练的API使我们能够在任何地方使用它。团队可以从任何服务、调度器或任务运行器调用我们的API。我们现在使用Railyard来训练模型，使用气流任务定义作为更大数据作业图的一部分。铁路站建筑在Stripe的早期模型培训中，工程师或数据科学家将SSH连接到EC2实例中，并手动启动Python进程来训练模型。这在当时满足了Stripe的需求，但随着公司的发展，我们的机器学习基础设施团队需要解决许多挑战和未决问题：我们如何将模型培训从共享EC2实例上的即席Python进程扩展到每天自动培训数百个模型？我们如何构建一个通用的接口来支持多个培训库、框架和范例，同时又保持表达力和简洁性？我们希望为每个模型运行跟踪哪些度量和元数据？培训工作应该在哪里执行？我们如何为不同的模型类型调整不同的计算资源需求（CPU、GPU、内存）？我们设计这个系统的目的是让我们的数据科学家少考虑他们的机器学习工作是如何在我们的基础设施上运行的，而是专注于他们的核心研究。机器学习工作流通常涉及多个步骤，包括加载数据、训练模型、序列化模型和持久化评估数据。因为Stripe在云中运行其基础设施，所以我们可以在API后面管理这些流程：这减少了我们数据科学和工程团队的认知负担，并将本地流程转移到协作、共享的环境中。经过一年半的迭代和与Stripe团队的协作，我们已经在Railyard的以下系统架构上取得了一致。下面是一个高层次的概述：Railyard运行在Kubernetes集群上，并将作业与正确的实例类型配对。Railyard提供了一个jsonapi，是一个Scala服务，用于管理Postgres数据库中的作业历史、状态和出处。作业是使用kubernetesapi执行和协调的，并且我们的Kubernetes集群提供具有不同计算资源的多个实例类型。集群可以将作业与正确的实例类型配对：例如，大多数作业默认为我们的高CPU实例，数据密集型作业在高内存实例上运行，而像深度学习这样的专门培训作业在GPU实例上运行。我们使用Subpar将Python代码打包用于模型训练，Subpar是一个Google库，它创建一个独立的可执行文件，将所有依赖项都包含在一个包中。它包含在Docker容器中，部署到AWS弹性容器注册中心，并作为Kubernetes作业执行。当Railyard收到API请求时，它将运行匹配的培训作业，并将日志流式传输到S3进行检查。一个给定的作业将经历多个步骤，包括获取培训和保留数据、训练模型以及将训练的模型和评估数据序列化到S3。这些培训结果保存在Postgres中，并在Railyard API中公开。铁路站API设计Railyard API允许您指定训练机器学习模型所需的一切，包括数据源和模型参数。在设计这个API时，我们需要回答以下问题：我们如何为多个培训框架提供一个通用接口，同时为用户保持表达和简洁？为了理解每个用例，我们对多个内部客户的一些设计进行了迭代。有些团队只需要特别的模型培训，可以简单地使用SQL来获取特性，而其他团队则需要使用存储在S3中的特性，每天以编程方式调用API数百次。我们探索了许多不同的API概念，在设计范围的两端达到了两个极端。一方面，我们研究了如何设计一个定制的DSL，通过直接在API中编码scikit-learn组件来指定整个培训工作。用户可以在API规范中包含scikit-learn管道组件，而不需要自己编写任何Python代码。另一方面，我们回顾了设计，允许用户使用定义清晰的输入和输出接口为他们的培训代码编写自己的Python类。我们的库将负责训练模型的必要输入（获取、过滤和分割训练和测试数据）和训练管道的输出（序列化模型，编写评估和标记数据）。否则，用户将负责编写所有训练逻辑。最终，任何基于DSL的方法最终都过于僵化：它要么将我们绑定到给定的机器学习框架，要么要求我们不断更新API以跟上不断变化的框架或库。我们集中在以下几个方面：我们的API公开了用于更改数据源、数据过滤器、特性名称、标签和培训参数的字段，但是给定培训作业的核心逻辑完全在Python中。下面是一个向Railyard服务发出的API请求的示例：{//这个模型是做什么的？"model_description"："预测欺诈的模型"，//这个模型叫什么？"model_name"："欺诈预测_模型"，//哪个团队拥有这个模型？"owner"："机器学习基础设施"，//这个模型用于什么项目？"project"："railyard api博客帖子"，//哪个团队成员在训练这个模型？"trainer"："机器人故事"，"数据"：{"特点"：[{//从Hadoop Parquet文件获取的列"names"：创建时间为"，"计费类型"，"计费金额"，"指控国家"，"是否有欺诈纠纷"]，//我们的数据源是S3"source"："s3"，//我们拼花地板数据的路径"path"："s3://path/to/parquet/fraud"_数据.parq"}],//数据集中的规范日期列"date_column"："创建时间为"，//数据可以过滤多次"过滤器"：[//过滤掉2018-01-01之前的数据{"feature_name"："创建时间为"，"predicate"："GtEq"，"特征值"：{"string_val"："2018-01-01"}},//过滤出2019-01-01之后的数据{"feature_name"："创建时间为"，"predicate"："LtEq"，"特征值"：{"string_val"："2019-01-01"}},//超过$10.00的费用过滤{"feature_name"："充值金额"，"predicate"："Gt"，"特征值"：{"浮动值"：10.00}},//过滤美国或加拿大的费用{"feature_name"："收费国家"，"predicate"："IsIn"，"特征值"：{"字符串"：US，"CA"]}}],//我们可以指定如何处理保留数据"保持采样"：{"sampling_function"："日期范围"，//2018年10月1日至2019年0月期间的拆分维持数据