共计 3270 个字符，预计需要花费 9 分钟才能阅读完成。
编者按：随着大数据和 AI 的关注重点转向工程化和能效，DataOps 和 MLOps 逐步衰亡。DataOps 侧重于进步数据分析品质、缩短数据交付周期，MLOps 侧重于疾速交付 AI 模型。
数据是 AI 开发生产的重要元素，在数据驱动的 AI 时代，割裂的 DataOps 和 MLOps 是否仍然能满足企业数据挖掘和 AI 利用的需要?
带着这个疑难，IDP 和大家一起追随资深 AI 从业者 Debmalya Biswas 的实际分享，一探“如何将 DataOps 嵌入到 MLOps 中”。
以下是译文，Enjoy!
作者 | Debmalya Biswas
翻译 | 王旭博
依据我作为数据分析和 AI/ML 从业者的教训来看，数据分析和 AI/ML 这两个畛域目前依然很是脱节。
当我第一次理解到，DataOps(Data operations，数据运维) 和 MLOps(Machine Learning Operations，机器学习运维) 这两个框架都反对 Data 和 ML 管道时就产生了疑难：那咱们为什么还须要两个独立的框架？尤其在这个以数据为核心的 AI 时代，数据是 AI/ML 的要害因素（至多对于进行监督学习的 ML 是这样，现在，该类模型约占企业级 AI 的 80%）。
以数据为核心的 AI 从新将 AI/ML 从算法 / 建模局部聚焦到底层数据局部。这基于这样一个假如：一个好的算法或模型可能从训练数据集中提取出的“了解量（understanding）”是无限的。所以本文举荐的进步模型准确性的办法是专一于训练数据集：收集更多数据、增加合成（内部）数据、进步数据品质、尝试新的数据转换等办法。
咱们仍未解决为什么要离开应用 DataOps 和 MLOps 两套框架的问题，或者，咱们能够将 DataOps 嵌入到 MLOps 中，将前者作为后者的一部分？那就让咱们开始吧，心愿新框架最终的名字不会是 DataMLOps——还请举荐一个更好、更风行的名字，毕竟天知道咱们的框架什么时候会忽然闻名。
整合 BI 和 ML
现实的解决方案应该想下图这样：
图 1. 对立的 BI 和 AI/ML 管道（图片来自作者）
结构化和非结构化的数据都会被提取到青铜层；这些数据在青铜层被荡涤和标注后，进入白银层；再通过进一步的建模和转换后，这些数据进入到黄金层。
此时，这些数据曾经能够被 BI-Reporting 工具（BI -Reporting 工具用于从公司的数据源、本地或云中读取数据，来辨认销售、支出、库存等数据，并利用日期、洽购订单或客户信息等维度来创立剖析报表）和 ML 管道（ML pipeline，用于主动将数据输出 ML 模型）应用。
然而，实际上，咱们看到的这些被整顿过的数据挪动到了另一个地位，例如云存储空间或者是另一个数据湖。在那里，这些数据被进一步用于 ML 的训练和部署。
因而，相比于图 1，企业环境中的架构更像图 2（下图 )。
图 2. DataOps 和 MLOps 管道中的数据处理
MLOps 的数据（预）解决局部侧重于将数据从数据源挪动到 ML 模型，而不用包含模型如何解决数据。该局部通常包含一系列用于反对学习算法的变换（transformation），例如，数据科学家为将数据传输给 ML 模型，可能抉择构建线性回归 pipeline 或探索性因子分析 pipeline。
ML 训练所须要执行的性能比传统 ETL 工具所提供的性能更加简单。这种景象经常出现在简单的数据处理、聚合和回归中。本文举荐的办法是应用有向无环图（Directed Acyclic Graph，简称 DAG）流来欠缺数据处理策略。
相比于 BI 中更线性的数据流，DAG 流可用于数据路由（所谓路由，就是指将数据送一个中央传送到另一个中央的行为）、统计转换和零碎逻辑的可扩大有向图。Apache Airflow 等很多工具可用于与 DAG 流相干的创作、治理和保护，咱们能够通过编程来将这些工具与 ETL 管道集成在一起。
不用说，这会导致 DataOps 和 MLOps 的管道过多及其碎片化。偏心地说，现在，DataOps 更多地与 BI/ 结构化分析相干，而由 MLOps 提供嵌入了数据（预）解决的残缺 ML 管道。
工具 / 平台提供商曾经开始致力解决这个问题，咱们也曾经能看到一些初期解决方案。近期，Snowflake 带来了 Snowpark Python API，通过调用该 API，数据科学家能够在 Snowflake 中应用 Python（而非应用 SQL）训练和部署 ML 模型。
Google Cloud Platform（GCP）提供了一种可在 GCP 数据仓库环境中只应用 SQL 来训练 ML 模型的工具，名为 BigQuery ML。同样，AWS Redshift Data API 使任何用 Python 编写的应用程序都能够轻松的与 Redshift 交互。这让 SageMaker notebook 能够连贯到 RedShift 集群，并应用 Python 调用 Data API。就地剖析（in-place analysis）提供了一种间接将数据从 AWS 的 DWH（data warehouse，数据仓库）提取到 notebook 的办法。
将机器学习推理数据作为新数据源
与 MLOps 管道相连的 ML 模型会产生新数据，而咱们在本节中将会钻研 MLOps 短少的“数据（data）”方面——将 ML 模型产生的新数据作为源数据。
让咱们思考一个 Compositional AI(组合 AI) 场景（图 3）。
图 3. Compositional AI 组合 AI 场景（图片来自作者 )
生产电子供应商为用户提供（在线）维修服务，该服务包含一个计算机视觉（Computer Vision，简称 CV）模型，该模型可能依据受损产品的快照（snapshot，用于保留受损产品在某一时刻的状态，能够了解为照片）评估所需的维修服务。如果用户对报价感到称心，则将解决流程转移给聊天机器人，该聊天机器人通过与用户交谈，来获取订购维修服务所需的其余详细信息，例如损坏细节、用户姓名、联系方式等。
未来，当供应商想要开发产品举荐服务时，能够参考维修服务。维修服务收集的数据——用户领有的产品状态（由 CV 评估模型收集）、用户们的个人信息（由聊天机器人收集）——额定为举荐服务提供了有标记的训练数据。
进一步，供应商心愿开发反对计算机视觉的制作缺点检测服务（用于供应商在发售产品前测验产品质量）。维修服务曾经标记了损坏产品的图像，因而，这些数据也能够用于训练新 CV 模型。另外，这些被标记的图像也能够作为反馈循（feedback loop）环提供给维修服务，用来改良其根底 CV 模型。
总而言之，已被部署 ML 模型所做的推断能够作为反馈循环，来扩充已部署模型的现有训练数据集，或者作为新模型的训练数据集。于是，就产生了已被部署的 ML 模型产生新数据，而这些新数据又能够供 DataOps 管道应用的情景。
图 4（下图）显示了扩大的 MLOps 管道，其中（已被部署的）ML 模型的推理被集成为一个（新）数据源。合成数据，即经合成（基于生成神经网络）产生的、与原始训练数据集十分类似的数据，也能够被视为与原数据类似的附加数据源。
图 4. (已部署的) ML 模型推理后果作为附加数据源（图片由作者提供）
参考资料
以数据为核心的 AI https://datacentricai.org/
DataOps 的重要性：为什么重要以及如何开始？https://www.wipro.com/analyti…
D.Scully 等 机器学习中暗藏的技术债权 https://proceedings.neurips.c…
现场演示：应用 Snowpark for Python 构建数据迷信的将来 https://www.snowflake.com/web…
什么是 BigQuery ML？https://cloud.google.com/bigq…
应用 Amazon Redshift Data API https://docs.aws.amazon.com/r…
DataKitchen 公司 为什有这么多 *Ops 术语？https://datakitchen.io/why-ar…
D. Biswas 组合式 AI：企业 AI 的将来 https://towardsdatascience.co…
