MLOps｜为什么构建实时的 data pipelines 的难度很高
如果你正在阅读有关机器学习工具的文章，你会发现大多数文章都会告诉你实时的机器学习非常困难，并且大多数机器学习项目都失败了。然而，解释实时的机器学习（ML）为何如此困难的文章却相对较少！这是因为构建ML工具的人有时会想当然地认为，每个做ML的人都经历过这种困难。
实时机器学习最困难的部分是构建实时的数据pipeline。在本博客中，我将重点讨论：
- 为什么机器学习项目构建实时的数据pipeline如此困难；
- 在尝试时会出现什么问题；
- 如何从一开始就避免这些困难。
为什么在机器学习中构建实时数据pipeline如此具有挑战性？
在我们面对构建实时数据pipeline的挑战之前，我们应该先探索大多数团队在实时机器学习过程中所经历的数据旅程。对于大多数项目，一般从批量特征工程开始：
值得注意的是，批量特征工程并不是那么难！由于过去几十年来在构建数据仓库解决方案方面取得的进步，有许多工具可基于历史数据用于构建特征，比如：
- 用于集中访问数据的数据仓库（如Snowflake和Databricks）
- 表示特征逻辑的数据建模工具（如DBT）
- 用于协调特征计算的调度器（如Airflow）
- 用于查询特征和训练模型的工具（如Snowflake和Databricks）
Batch ML的好处在于，生成训练数据的工作通常在模型训练和模型推理之间进行。如果您使用现代工具构建训练数据，您应该能够重用这些代码来提取数据进行批量推理。
值得注意的是，许多团队在创建和生成训练数据的做法和实践方面仍然没有达成一致。在脆弱的Python笔记本中，您仍然经常听到关于特征工程的故事——在生产过程中，解开和重构这些代码仍然可能是一个长达数周的缓慢过程。
构建Batch ML的数据pipeline有很好的解决方案，但尚未被广泛采用。
第一个挑战：在线推理
一旦需要实时进行预测，数据世界就开始发生变化——瞬时，机器学习模型需要快速获得特征数据。
如果机器学习模型位于应用程序的关键路径中，则通常用于推理的服务等级协定（SLA）约为100毫秒。这意味着您只有不到100毫秒的时间来检索数据！否则刹那间，您编写的从数据仓库读取特征的代码就不起作用了。
为了解决这个问题，您通常从预计算特性并将它们存储在快速数据库中开始着手。
我看到的解决这个问题最常见的做法是采用Redis（Remote Dictionary Server，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value的数据库，并提供多种语言的API）。
要使这一切工作正常，您需要在已计划的特征提取任务中添加一个步骤，以便将数据加载到Redis中。
一个合理的方法是将新计算的特性卸载到对象存储中，然后编写一个Lamba函数，在新数据出现时触发，将数据加载到Redis中。
这一变化带来的主要挑战是，现在您需要维护固定的基础设施！以前，您的所有工作（在数据仓库之外）都是无状态的，通常对时间不敏感。如果出现故障，可以手动调试并重试任务。然而，如果Redis失败，您的应用程序将面临停机！
实际上，这带来了重大的新负担：
- 您需要对在线仓库实施监控，以检测问题；
- 您需要实现一个随叫随到的工程轮换，以支持您的特征服务基础设施。
这些变化代表着巨大的工程负担和成本，维护基础设施的工作将开始拖累您创建新ML模型的时间。
通过在线推理，您已经进入了维护固定数据基础设施的世界，这大大增加了工程团队的负担。
最大的挑战：机器学习的新特征
一旦您的模型需要新特征，您的机器学习产品的复杂性就开始爆炸。大多数实时ML模型从新数据中获益匪浅（例如，欺诈模型需要处理关于最近交易的信息、推荐系统关心最近的用户行为、保险报价模型依赖于来自第三方API的信息等）。
因此，现在您需要解决从许多不同来源收集特征的问题。
第一个挑战是简单地找出新数据的来源！我看到的一些常见来源：
- 流数据（如Kafka）
- 第三方API（如Plaid）
- 事务型数据库（如Postgres）
- 其他团队管理的内部API
- 应用程序上下文
简单地查找所有这些数据源（以匹配数据仓库中可用的数据）可能是一个重大挑战。更糟糕的是，您通常需要一组独特的工具来查询并将这些数据源转换为功能！
这些应用中的每一个都有与之相关的工程挑战。例如，构建高效的流处理代码非常具有挑战性。
您的整个技术栈中现在有很多移动部件：
新特征会导致复杂性的爆炸
还有更多的固定基础设施需要监控：微服务、流处理任务、事务型数据库。这意味着要构建更多的监控和更多的随叫随到的负担。您需要投入大量时间来维护现有系统，最终可能需要一个专门的团队。
在处理在线流量时，还需要对解决方案的可伸缩性进行重要考虑。现代数据仓库比大多数在线数据基础设施更无缝地处理扩展！您需要设计一个解决方案来处理您现在的峰值负载（或是您明年的峰值负载）。在最大规模上，这些生产系统中的每一个都非常复杂，难以扩展和管理。
机器学习模型中的训练/推理倾斜
最终，您将完成维护具有新特征的生产ML模型所需的所有工程工作，但挑战才刚刚开始。
如果您像大多数组织一样，使用两种不同的数据模型在两个不同的地方构建了特征。在两个地方编写逻辑几乎总是导致特征分布的微小但重要的差异！
这种方法（几乎无一例外）会导致训练/推理偏差——用于训练模型的特征与进行预测时使用的特征看起来略有不同。你会注意到这一点，因为你花了那么多时间构建的模型在现实世界中的表现不如你预期的那么好。
对大多数团队来说，诊断和解决训练/推理偏差是一项非常困难的任务。您可能需要使用某种数据质量监控和漂移检测（一种复杂的监控形式）来改进在线和离线特征的计算。调试这些差异可能需要额外几周的工程时间。
解决方案：构建特征平台以管理机器学习实时数据pipeline的复杂性
构建机器学习数据pipeline的现代解决方案是特征平台。特征平台为团队提供了集中构建和管理机器学习模型所需的所有不同数据pipeline的工具。
这里概述了如何构建一个特征仓库（https://www.tecton.ai/blog/how-to-build-a-feature-store/），它将引导您完成您需要构建的组件，以解决本博客中列出的问题。目前已经有相应的企业服务工具，比如Tecton。
Tecton可以
- 帮助您构建统一的在线/离线pipeline，以避免出现训练/推理偏差；
- 支持处理来自每个公共新数据源的数据（这意味着您不需要为每个源构建自己的工具和服务）；
- 是一种具有保证SLA的托管服务，减少了支持生产ML系统所需的随叫随到的负担；
- 是按比例构建的，因此在应用程序增长时不需要重新架构。
本文翻译自MLOps community
原文链接为：https://mlops.community/why-real-time-data-pipelines-are-so-hard/
欢迎关注公众号，获取最新的MLOps信息
