读数据自助服务实践指南：数据开放与洞察提效14持续集成服务
1.1. 通常，机器学习模型管道随着源模式的变化、特征逻辑、依赖数据集、数据处理配置、模型算法、模型特征和配置而不断演进
1.2. 在传统的软件工程中，代码是不断更新的，各团队每天都要进行多次修改
1.3. 机器学习管道的持续集成存在多个痛点
1.3.1. 需要全面跟踪涉及数据、代码和配置的机器学习管道实验
1.3.1.1. 这些实验可以视为特征分支，区别是绝大多数分支永远不会与主干集成
1.3.1.2. 现有的代码版本控制工具（如GitHub）只跟踪代码变化，既没有一个标准的地方来存储训练实验的结果，也没有一个简单的方法来比较一个实验和另一个实验
1.3.2. 为了验证变化，机器学习管道需要打包部署在测试环境中
1.3.3. 在开发或测试环境中运行单元和集成测试时，不能提供与生产环境类似的真实数据
1.4. 考虑到数据团队成员每天都要对机器学习管道进行数百次更改，集成耗时的增加影响了整体的洞察耗时
1.5. 理想情况下，持续集成服务会自动执行将更改可靠地集成到机器学习管道的过程
1.5.1. 该服务跟踪机器学习管道的更改，创建一个可复现的包以在不同的测试环境中部署，并简化管道测试的运行以检测问题
1.5.2. 通过自动化这些任务，该服务减少了集成耗时和在生产中泄露的问题的数量
1.5.3. 该服务允许数据用户之间进行协作开发
1.6. 作为测试管道更改正确性的一部分，将对机器学习模型进行训练和评估
1.7. 持续集成是一种软件工程实践，可以确保对代码的更改进行持续集成和测试，以主动发现问题
1.8. 通过在机器学习管道应用相同的原理，可以将实验视为主代码主干的分支
1.9. 持续集成服务的目标是跟踪、构建和测试实验，以找到最佳的机器学习管道
1.9.1. 在此步骤中丢弃了探索过程中的大部分次优实验，但它们对调试仍然很有价值，并且有助于设计未来的实验
2. 路线图2.1. 在机器学习管道上进行协作开发
2.1.1. 在构建阶段，数据科学家和工程师组成的团队一起协作以迭代并找到最佳模型
2.1.2. 特征管道代码与模型算法、模型参数和超参数并行开发
2.1.3. 团队交付机器学习管道的期限很紧，必须在确定要与主干集成以进行部署的管道之前，系统地进行大量实验
2.1.4. 如今，跟踪实验、构建可部署版本、验证管道、训练模型、评估模型质量以及跟踪最终结果都是以即席的方式完成的
2.2. 集成ETL更改
2.2.1. 特征管道被写成ETL代码，从不同的数据源读取数据并将它们转换为特征
2.2.2. ETL更改需要使用一套全面的单元、功能、回归和集成测试来验证其正确性
2.2.3. 作为集成过程的第一步，将运行单元测试和集成测试的黄金测试套件，这些也被称为冒烟测试
2.2.4. 如果特征用于生成业务指标仪表盘，则数据用户需要验证结果的正确性（这称为用户验收测试）
2.2.5. 现在的方法是即席的，验证通常使用不代表生产数据的小样本数据完成
2.3. 验证模式更改
2.3.1. 数据源所有者更改其源模式，通常不通知下游机器学习管道用户，这些问题通常在生产中检测到，并可能会产生重大影响
3. 最小化集成耗时3.1. 包括跟踪、打包和验证机器学习管道的正确性和生产准备所需的时间
3.2. 实验跟踪
3.2.1. 机器学习管道是数据集、代码和配置的组合
3.2.2. 跟踪实验需要创建一个单一的端到端视图，其中包括数据集版本、模型和管道的配置，以及与特征管道和模型相关联的代码
3.2.3. 实验也需要被跟踪，并将与测试和模型训练相关的结果记录下来
3.2.4. 跟踪实验很耗时，由于缺乏对数据集、代码、配置以及相应测试和模型训练结果的一致性跟踪，使得最终的模型选择过程非常烦琐
3.3. 可重复的部署
3.3.1. 在集成更改之前，需要验证更改的正确性
3.3.2. 需要在测试环境中构建和部署机器学习管道
3.4. 测试验证
3.4.1. 单元测试、功能测试、回归测试和集成测试
3.4.2. 挑战
3.4.2.1. 编写全面的测试来检测问题
3.4.2.1.1. 定义正确的测试结合了软件工程“卫生”（hygiene）和团队技能
3.4.2.1.2. 与传统软件相比，大多数组织不会对机器学习管道应用同样严格的代码覆盖率标准
3.4.2.2. 使用实际的生产数据
3.4.2.2.1. 大多数组织都有单独的QA、E2E和生产环境
3.4.2.2.2. 非生产的数据通常包含数据样本，不具有代表性
3.4.2.3. 运行测试需要大量的时间
3.4.2.3.1. 分配的测试资源通常有限，根据数据集的大小，测试可能会运行相当长的时间
4. 定义需求4.1. 实验跟踪模块
4.1.1. 实验跟踪是机器学习管道更改（与代码、配置和数据集相关）的E2E表现形式，并记录了相应的测试和模型训练结果
4.1.2. 目标是全面捕获影响机器学习管道的更改，以便将它们集成到构建-验证过程中
4.1.3. 配置参数
4.1.3.1. 特征管道和机器学习模型中使用的任何可配置参数
4.1.4. 代码版本
4.1.4.1. 库的版本、编程语言、依赖代码等
4.1.5. 数据集
4.1.5.1. 定义作为机器学习管道一部分使用的数据版本
4.2. 管道打包模块
4.2.1. 创建要在本地或云端部署的机器学习管道的可重复包
4.2.2. 云计算提供商，如Azure、AWS等
4.2.3. 容器编排框架，如Docker、Kubernetes等
4.2.4. 工件仓库，如Artifactory、Jenkins、S3等
4.2.5. CI框架，如Jenkins、CircleCI、Travis等
4.2.6. 密码管理，如AWS KMS、HashiCorp Vault等
4.2.7. 作为打包的一部分，澄清对数据集的版本处理非常重要
4.3. 测试自动化模块
4.3.1. 使用版本化生产数据编排最佳运行的测试
4.3.2. 测试数据的大小应该大到有意义或者小到能加快测试速度
4.3.3. 黄金测试套件通常与代码分开管理
4.3.3.1. 可以为这些测试定义对代码覆盖率和测试通过标准的要求
4.3.3.2. 其他考虑因素包括完成测试的时间和并行运行测试的必要性
5. 实现模式5.1. 可编程跟踪模式
5.1.1. 允许跟踪用户定义的指标以进行机器学习模型的实验
5.1.2. 作为机器学习管道实验的一部分，该服务跟踪与代码、配置和数据集有关的详细信息
5.1.3. 可编程跟踪模式让数据科学家能够添加任何指标作为实验跟踪的一部分
5.1.3.1. 训练作业的开始时间和结束时间
5.1.3.2. 谁训练了模型及业务细节
5.1.3.3. 每个特征的分布和相对重要性
5.1.3.4. 不同模型类型的特定准确度指标
5.1.3.5. 模型可视化统计汇总
5.1.4. 该模式通过集成用于数据处理的跟踪库和机器学习库（如Spark、Spark MLlib、Keras等）来实现
5.2. 可重复的项目模式
5.2.1. 将实验打包，使它能部署在任何环境中，以实现测试和模型训练
5.2.2. 目标是构建一个独立的、可重复的机器学习管道包，以便在测试或开发环境中进行部署
5.2.3. 适用于其他具有可重复性、可扩展性和实验性的用例
5.2.4. 该模式通过正确的依赖项自动创建部署环境，并提供标准化的CLI或API来运行项目
5.2.5. 管道组件的调用顺序
5.2.5.1. 这是组件需要被调用的顺序，通常用DAG表示
5.2.6. 代码版本
5.2.6.1. 这实际上是GitHub或其他版本控制仓库中的一个功能分支
5.2.6.2. 代码包括管道组件和模型算法
5.2.6.3. 通常，单元测试和黄金测试套件也包含在同一个项目包中
5.2.7. 管道组件的执行环境
5.2.7.1. 这包括库和其他依赖项的版本
5.2.7.2. 通常是一个Docker镜像
5.2.8. 数据版本
5.2.8.1. 是与管道一起使用的源数据集
5.2.9. MLflow Project
5.2.9.1. 它为打包可复用的数据科学代码提供了标准格式
5.2.10. 该模式的优势在于其标准化的方法可以跟踪机器学习管道的所有方面，确保实验结果的可重复性
5.2.11. 缺点是该模式没有考虑到生产部署所需的资源扩展需求
5.2.12. 该模式对于自动化机器学习管道的打包非常重要，并且允许在任何环境中进行灵活的再现
5.3. 测试验证模式
5.3.1. 以单元、组件和集成测试的形式进行测试
