数据/机器学习平台的发展和支持复杂的MLOps实践
数据/机器学习一直是我们技术领域中最热门的话题。我想分享一下我对数据/机器学习平台的理解，以及这些平台如何从基础发展到复杂。最后，我尽力涵盖MLOps，这是一种用于管理机器学习项目的原则。
关于我的个人信息，你可以在我的领英页面找到。
旅程的开始：在线服务 + OLTP + OLAP
初始阶段，数据基础设施可能相当简单。分析查询可能会发送到在线OLTP数据库的读取副本，或者建立一个OLAP数据库作为数据仓库。
下图是基础设施的示意图：
只要满足业务需求，这些系统没有问题。满足我们业务需求的所有系统都是好系统。如果它们简单，那就更好了。
在这个阶段，有多种方法可以进行数据分析：
- 简单地将查询提交给OLTP数据库的副本节点（不推荐）。
- 启用OLTP数据库的CDC（Change Data Capture）并将这些数据注入到OLAP数据库中。选择CDC日志的摄取服务选项可根据您选择的OLAP数据库而定。例如，使用Flink数据流与CDC连接器是一种处理方法。许多企业服务都附带自己的建议解决方案，例如Snowflake的Snowpipe。还建议从副本节点加载数据，以保留主节点的CPU/IO带宽用于在线流量。
在这个阶段，机器学习的工作负载可能在您的本地环境中运行。您可以在本地设置一个Jupyter笔记本，并从OLAP数据库加载结构化数据，然后在本地训练您的机器学习模型。
这种架构的潜在挑战包括但不限于：
- 使用OLAP数据库难以管理非结构化或半结构化数据。
- 当处理大量数据时，OLAP可能会出现性能回滚（需要TB级别的数据进行单个ETL任务）。
- 缺乏对各种计算引擎的支持，例如Spark或Presto。大多数计算引擎确实支持通过JDBC端点连接到OLAP，但由于JDBC端点本身的IO瓶颈，并行处理将受到严重限制。
- 在OLAP数据库中存储大量数据的成本很高。
您可能已经知道如何解决这个问题了。建立一个数据湖！引入数据湖并不意味着您需要完全放弃OLAP数据库。公司常常同时存在两个系统以满足不同的用例。
数据湖：存储-计算分离 + 写时模式
数据湖允许您持久存储非结构化和半结构化数据，并进行写时模式。它通过使用专门的存储解决方案存储大数据量来降低成本，并根据需求启动计算集群。通过扩展计算集群，它进一步让您轻松管理TB/PB级别的数据集。
下图是您的架构示意图：
这其实是一个过于简化的图表。实际的数据湖实现可能要复杂得多。
现在，许多云服务提供商都有相当成熟的数据湖存储解决方案，例如AWS S3和Azure ADLS。但在这些存储解决方案之上还需要完成许多任务。例如，应该有一个Hive元存储来管理表元数据，以及一个Datahub来提供数据可见性。还有一些具有挑战性的问题，例如数据湖中的细粒度权限控制以及数据血统分析（例如spline）。
为了最大化您的数据湖的价值和效率，我们应该仔细选择每个层的文件格式和平均文件大小。
一般的建议是：
- 避免小文件：小文件是数据湖存储成本高和性能差的主要原因之一。
- 在延迟、压缩比和性能之间保持平衡：像 Hudi 这样的低延迟数据湖表可能无法给您最佳的压缩比，而具有高压缩比的大型 ORC 文件可能会给您带来性能噩梦。您可能需要根据表的使用模式、延迟要求和表大小来明智地选择文件格式。
有一些非常成熟的 SaaS/PaaS 提供商，例如 Databricks，提供了一个不错的数据湖（或LakeHouse）解决方案。您还可以探索 ByteHouse，以便统一体验大数据分析。
在机器学习方面，团队可能开始在远程环境中探索像 Tensenflow 和 Pytorch 这样的成熟的机器学习框架。此外，训练好的机器学习模型可以部署到生产环境进行在线模型推断。Tensorflow 和 Pytorch 都提供了模型服务解决方案，例如 TensorFlow Serving 和 Pytorch Serving。
然而，我们的旅程不会止步于此。现在我们可能面临以下挑战：
- 缺乏关键的在线机器学习模型服务的实时指标和特征管理。
- 缺乏模型性能监控。
让我们进一步提高我们的水平。
实时数据/机器学习基础设施：数据河流 + 数据流式处理 + 特征存储 + 指标服务器
建立实时数据基础设施通常需要公司的多个部门共同努力。构建数据河的初衷通常不是为了数据/机器学习系统，而是为了通过移除同步调用来使微服务进一步扩展。相反，微服务将通过与像 Kafka 这样的消息代理进行通信来提高效率（以降低一致性水平为代价）。
整体架构可能是这样的。
有了数据河中可用的数据（例如 Kafka），我们可以构建数据流式处理管道来处理实时数据。这些数据可以直接在在线特征存储中使用，或者同步到像 Pinot 这样的指标服务器。指标服务器可以进一步处理/聚合这些指标数据点，生成更有用的模型性能指标和业务指标。您还可以采用流式数据库，如 RisingWave，它可以通过 SQL 语法连接/聚合流式数据。
对于构建数据流处理本身而言，Flink 非常受欢迎。您也可以使用 Flink with CDC connector 从 OLTP 数据库提取数据并将其汇入消息代理和数据湖中。
应该有一个由键值数据库（如 ScyllaDB 或 AWS Dynamo DB）支持的在线特征存储。在线特征存储可以帮助您在发送到模型服务的请求中附加一个与某个引用 ID（用户 ID、产品 UUID）相关联的特征向量。它可以极大地解耦后端服务团队构建微服务和机器学习工程师团队构建机器学习模型之间的依赖关系。这样，当您更新特征向量时，您可以独立地推出新的机器学习特征和新的机器学习模型（您向微服务公开的模型服务 API 签名保持不变）。
在书中，《设计机器学习系统》中，它分享了有关模型堆叠（Jen Wadkin的VoAGI文章关于模型堆叠）的知识。人们在模型服务中普遍使用模型堆叠。当你想将异构模型（例如将PyTorch和TensorFlow模型堆叠在一起）时，需要使用协调者。当将请求路由到不同的模型时，您的协调器可以根据模型的表现动态分配权重，使其变得更加复杂。
现在我们有一个复杂的系统。它看起来很酷，但它也带来了新的挑战：
- 如果不加以管理，系统的负债将飙升。
- 对于机器学习工程师来说，认知负担很高。
这可能是您需要考虑MLOps如何帮助您的时候了。
MLOps：抽象、可观察性和可扩展性
MLOps从来不是一个具体的解决方案。它更像是一组管理机器学习系统的原则。与典型的软件项目不同，机器学习系统受到数据变动的极大影响，而数据依赖管理并不是一项容易的任务。论文《机器学习系统中的隐藏技术债务》详细描述了这些挑战。因此，一个以MLOps为驱动的机器学习平台必须能够实现以下功能：
- 监控数据变化和数据质量。
- 在离线和在线环境中管理机器学习特征。
- 可复现的机器学习流水线，实现实验-操作对称。
- 简洁的机器学习流水线配置，可以将基础设施细节抽象化。
本文《MLOps：机器学习中的持续交付和自动化流水线》强调了实验-操作对称的重要性。它还描述了从级别0、级别1到最终级别2的MLOps自动化水平。我确实喜欢这个文档中的图表，所以借用它来解释一下一级MLOps看起来像什么。
要在您的组织中推广这种MLOps实践，您需要提供简洁的机器学习流水线配置，以便为机器学习工程师抽象基础设施实现细节。通过这样做，平台工程师在升级机器学习平台时也可以灵活进行，而不会对平台用户造成太多的干扰。您可以考虑使用类似yaml的配置文件来描述机器学习流水线，并依赖于您的机器学习流水线控制器将其转换为实际工作负载。
因此，让我们用下面的图表重新组织实时数据/ML基础架构，以突出MLOps是如何塑造我们的平台的。
为了让您更好地了解机器学习流水线可能的样子，以下是每个阶段可能的抽象示例。下面的图表只是帮助您更好地了解配置可能的样子，不代表任何实际实现。它也没有涵盖所有所需的方面。
Kubernetes是一种流行的解决方案，用于编排机器学习工作负载（或者现在可能是所有工作负载）。您可以使用CRDs为用户和平台提供简洁的接口。在文章《我对Kubebuilder的思考》中，我分享了我在使用kubebuilder构建CRD时的一些想法。
当然，我没有涵盖许多重要的子主题，包括但不限于：
- 超参数优化
- 分布式训练架构
下一步计划
您可以看到MLOps为已知任务赋予一个合适的名称。这还远远不够。我分享的是一种实现ML Ops平台的有见地的策略。即使如此，创建高质量的ML产品的门槛仍然很高，收集、处理和挖掘数据的工作仍然很繁重。
除了这些挑战仍然存在外，我还想分享我观察到的ML领域的趋势。鉴于这个领域的发展速度，这当然不是一个完整的清单。
- 无服务器：我们已经太过于忽视了ML的价值，因为ML平台的基础通常是数据平台。就像在移动时代已经到来时，强迫用户购买计算机才能参与社交媒体平台一样。无服务器的数据服务和计算集群正在解决这个问题。许多服务提供商正在探索各自的无服务器解决方案，以降低采用的门槛，例如Databricks、Snowflake、Bytehouse。企业可以在启动数据仓库、数据湖或混合存储后开始构建其ML产品。
- AI驱动的特征工程：好吧，现在AI可以做任何事情了，是吧？
- MaaS趋势：更强大的Model-as-a-Service将会出现。公司可以直接利用ML的力量，而无需建立自己的ML服务，从而为他们的业务带来巨大的推动。
正如我们都已经注意到的，ML领域发展得非常迅速。在我打字的这一刻，这篇文章可能已经过时了。更多的想法已经涌现并转化为现实。请告诉我您对ML Ops的看法，或者我应该在哪里继续学习。让我们一起保持步伐！