【51CTO.com快译】敏捷编程是最常用的方法，它使开发团队能够将他们的软件发布到生产中，经常收集反馈并细化底层需求。为了让敏捷在实践中发挥作用，需要允许自动构建修改后的应用程序并将其发布到生产中的流程——通常称为持续集成/持续部署，或 CI/CD。CI/CD 通过定期让实际用户参与并反复整合他们的反馈，使软件团队能够构建复杂的应用程序，而不会冒错过初始需求的风险。
数据科学面临着类似的挑战。尽管数据科学团队错过初始要求的风险现在威胁较小（这将在未来十年发生变化），但将数据科学自动部署到生产中所固有的挑战使许多数据科学项目陷入停顿。首先，将任何东西放入生产系统时往往需要 IT 参与。其次，验证通常是一项未指定的手动任务（如果它存在的话）。第三，可靠地更新生产数据科学过程通常非常困难，它被视为一个全新的项目。
那数据科学可以从软件开发中学到什么？让我们先看看软件开发中 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 的组合）有何关系？提到这些术语的人往往会忽略两个关键事实：首先，数据预处理是生产过程的一部分（而不仅仅是投入生产的“模型”），其次，生产环境中的模型监控通常只是静态和非反应性。
目前，许多数据科学堆栈仅解决数据科学生命周期的一部分。不仅其他部分必须手动完成，而且在许多情况下，技术之间的差距需要重新编码，因此生产数据科学过程的全自动提取几乎是不可能的。在人们意识到真正生产化数据科学不仅仅是将一个包装精美的模型扔在墙上之前，每当组织试图可靠地使数据科学成为其运营不可或缺的一部分时，我们将继续看到失败。
数据科学过程还有很长的路要走，但 CI/CD 提供了很多可以借鉴的经验教训。但是，用于数据科学的 CI/CD 和用于软件开发的 CI/CD 之间存在两个根本区别。首先，集成过程中自动创建的“数据科学生产过程”与数据科学团队创建的不同。其次，生产中的监控可能会导致自动更新和重新部署。也就是说，部署周期可能由检查生产中数据科学流程的监控流程自动触发，只有当监控检测到重大变化时，我们才会回到战壕并重新启动整个流程。
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
