CI/CD对数据科学有什么不同

将数据科学转移到生产中，与部署应用程序有很多相似之处。但也有一些关键的区别是你不应该忽视的。

敏捷编程是最常用的方法，它使开发团队能够将他们的软件发布到生产中，经常收集反馈并完善基础需求。然而，为了使敏捷在实践中发挥作用，需要有一些流程，使修改后的应用程序能够自动构建并发布到生产中--一般被称为持续集成/持续部署，或CI/CD。CI/CD使软件团队能够通过定期让实际用户参与并迭代纳入他们的反馈来构建复杂的应用程序，而不会有错过最初需求的风险。

数据科学也面临着类似的挑战。尽管数据科学团队错过初始需求的风险现在还不是很严重（这在未来十年内会发生变化），但将数据科学自动部署到生产中的固有挑战使许多数据科学项目陷入停滞。首先，IT部门往往需要参与进来，才能将任何东西放入生产系统。其次，验证通常是一项没有明确规定的手工任务（如果它存在的话）。第三，可靠地更新一个生产数据科学流程往往是如此困难，它被当作一个全新的项目。

[也在InfoWorld上。什么是CI/CD？持续集成和持续交付的解释］。

数据科学能从软件开发中学到什么？让我们先看看软件开发中CI/CD的主要方面，然后再深入了解事情的相似之处和数据科学家需要采取的不同方式。

软件开发中的CI/CD

软件开发的可重复生产过程已经存在了一段时间，而持续集成/连续部署是当今事实上的标准。大规模的软件开发通常遵循一种高度模块化的方法。团队在代码库的一部分工作，并独立测试这些模块（通常使用这些模块的高度自动化测试案例）。

在CI/CD的持续集成阶段，代码库的不同部分被插在一起，并再次自动进行整体测试。这种集成工作最好是经常进行（因此是 "连续的"），这样就可以立即发现那些不影响单个模块但破坏整个应用程序的副作用。在一个理想的情况下，当我们有完整的测试覆盖率时，我们可以确保任何一个模块的变化所引起的问题几乎可以立即被发现。在现实中，没有测试设置是完整的，完整的集成测试可能每晚只运行一次。但我们可以尝试接近。

CI/CD的第二部分，持续部署，指的是将新构建的应用程序转移到生产中。每分钟更新数以万计的桌面应用程序几乎是不可行的（而且部署过程更加复杂）。但是对于基于服务器的应用程序，通过越来越多的基于云的工具，我们可以更频繁地推出变化和完成更新；如果我们最终推出了有问题的东西，我们也可以快速恢复。然后，部署的应用程序将需要持续监测可能出现的故障，但如果测试做得好，这往往不是一个问题。

数据科学中的CI/CD

数据科学流程往往不是由不同的团队独立完成的，而是由不同的专家合作完成的：数据工程师、机器学习专家和可视化专家。极为重要的一点是，数据科学的创建并不关注ML算法的开发--这是软件工程，而是关注ML算法在数据中的应用。算法开发和算法使用之间的这种差异经常引起混淆。

数据科学中的 "整合 "也是指将基础部分拉到一起。在数据科学中，这种整合意味着确保特定工具包的正确库与我们最终的数据科学过程捆绑在一起，如果我们的数据科学创建工具允许抽象，则确保这些模块的正确版本也被捆绑在一起。

然而，在整合阶段，软件开发和数据科学之间有一个很大的区别。在软件开发中，我们所构建的是正在部署的应用程序。也许在集成过程中会删除一些调试代码，但最终的产品是在开发过程中构建的东西。在数据科学中，情况并非如此。

在数据科学创建阶段，已经建立了一个复杂的流程，优化了数据的组合和转换方式以及哪些数据。这个数据科学创建过程经常在不同类型和参数的模型上进行迭代，甚至有可能在每次运行时以不同方式组合其中的一些模型。在整合过程中发生的事情是，这些优化步骤的结果被结合到数据科学生产过程中。换句话说，在开发过程中，我们生成特征并训练模型；在整合过程中，我们将优化后的特征生成过程和训练后的模型结合起来。而这种整合包括生产过程。

那么，什么是数据科学的 "持续部署"？正如已经强调的那样，生产过程--即需要部署的集成结果--与数据科学创建过程不同。那么实际的部署就类似于软件部署。我们希望自动替换现有的应用程序或API服务，最好是有所有通常的好处，如适当的版本和如果我们在生产过程中捕捉到问题，能够回滚到以前的版本。

数据科学生产流程的一个有趣的额外要求是需要持续监测模型的性能--因为现实往往是变化的变化检测对于数据科学流程至关重要。我们需要建立机制来识别我们生产过程的性能何时恶化。然后，我们要么自动重新训练和重新部署模型，要么提醒我们的数据科学团队注意这个问题，以便他们可以创建一个新的数据科学流程，重新触发数据科学CI/CD流程。

因此，虽然监控软件应用往往不会导致自动改变代码和重新部署，但这些是数据科学中非常典型的要求。这种自动集成和部署如何涉及原始验证和测试设置的（部分），取决于这些自动变化的复杂性。在数据科学中，测试和监控都是过程本身的更多组成部分。我们较少关注测试我们的创建过程（尽管我们确实想对我们的解决方案的路径进行归档/转换），我们更关注对生产过程的持续测试。这里的测试用例也是 "输入-结果 "对，但更可能是由数据点而不是测试用例组成。

这种监测的差异也影响到部署前的验证。在软件部署中，我们要确保我们的应用程序通过其测试。对于数据科学的生产过程，我们可能需要测试以确保标准数据点仍然被预测为属于同一类别（例如，"好 "客户继续获得高信用排名），并且已知的异常情况仍然被捕获（例如，已知的产品故障继续被归为 "故障"）。我们也可能想确保我们的数据科学过程仍然拒绝处理完全荒谬的模式（臭名昭著的 "男性和怀孕 "的病人）。简而言之，我们要确保提及典型或异常数据点或简单异常值的测试用例继续被当作预期处理。

MLOps、ModelOps和XOps

所有这些与MLOps、ModelOps或XOps（Gartner称之为DataOps、ModelOps和DevOps的组合）有什么关系？提到这些术语的人往往忽略了两个关键事实。首先，数据预处理是生产过程的一部分（而不仅仅是投入生产的 "模型"），其次，生产环境中的模型监控往往只是静态的、非反应的。

现在，许多数据科学堆栈只解决了数据科学生命周期的一部分。不仅其他部分必须手动完成，而且在许多情况下，技术之间的差距需要重新编码，所以完全自动提取生产数据科学过程是完全不可能的。在人们意识到真正的数据科学生产化不仅仅是把一个包装好的模型扔到墙上之前，每当组织试图可靠地把数据科学作为其运营的一个组成部分时，我们将继续看到失败。

[也在InfoWorld上。开始使用CI/CD：用CI/CD管道自动化你的应用交付] 。

数据科学流程仍有很长的路要走，但CI/CD提供了不少可以借鉴的经验。然而，用于数据科学的CI/CD和用于软件开发的CI/CD之间有两个根本的区别。首先，在整合过程中自动创建的 "数据科学生产流程 "与数据科学团队所创建的流程不同。其次，生产中的监控可能会导致自动更新和重新部署。也就是说，有可能部署周期是由检查生产中的数据科学流程的监测过程自动触发的，只有当该监测检测到严重的变化时，我们才会回到战壕，重新启动整个流程。