机器学习（ML）被称为技术债的高息信用卡。针对具体的业务问题，使用合适的模型相对容易，但要让模型运行在可扩展的生产环境中，并能够处理不断变化的混乱数据语义和关系，并以可靠且可信赖的方式演化模式。自动化的方式，完全是另一回事。对于机器学习生产系统，只有5%的实际代码是模型本身。将一组机器学习解决方案转换为端到端机器学习平台是一种架构，它采用技术来加速建模、自动化部署并确保生产中的可扩展性和可靠性。作者之前讲过leanD/MLOps，数据和机器学习操作，因为没有数据的机器学习操作是没有意义的，所以需要整体搭建一个端到端的机器学习平台。CI/CD基金会已经启动了一个MLOps特别兴趣小组(SIG)。其端到端机器学习平台识别的步骤如下图所示；然而，一些不太重要的细节被掩盖了。例如，一项服务可能需要不同的技术，这取决于它是否实时完成。可扩展解决方案通常在负载均衡器后面的服务集群中的多台机器上的容器中运行模型。因此，上图中的单个框并不代表实际平台的单个步骤、容器或组件。这不是对图中步骤的批评，而是警告，看似简单的东西在实践中可能并不那么容易。图中没有模型（配置）管理。考虑版本控制、实验管理、运行时统计、训练、测试和验证数据集的数据沿袭跟踪、从头开始或从模型快照重新训练模型的能力、超参数值、准确性指标等。此外，图中缺少的另一个关键点是检查模型偏差的能力，例如，根据不同维度拆分模型的关键性能指标。许多公司还需要能够热插拔模型或并行运行多个模型。前者对于避免在后台更新模型时用户请求进入服务器时失败至关重要。后者对于A/B测试或模型验证也至关重要。我们可以从CI/CD中得出的另一点是对版本化数据和代码的需求，这一点经常被忽视。谷歌：TFX谷歌开发TensorFloweXtended(TFX)的主要动机是将机器学习模型的生产时间从几个月缩短到几周。谷歌工程师和科学家为此苦苦挣扎，因为“当机器学习需要应用于生产时，实际的工作流程变得更加复杂。TensorFlow和TFX都是免费使用的，但后者是2019年才发布的，比Google提供的ML基础设施晚了两年，远不如前者成熟。模型性能指标用于部署安全服务模型。因此，如果新机型性能不如现有机型，就无法投产。根据TFX的说法，该模型并不幸运。使用TFX，整个过程是自动化的。以下是开源TFX组件的基本概述：ExampleGen提取并拆分输入数据集。StatisticsGen计算数据集的统计数据。SchemaGen检查统计数据并创建数据模式。ExampleValidator查找数据集中的离群值和缺失值。Transform对数据集执行特征工程。Trainer使用TensorFlow训练模型。评估者分析培训结果。ModelValidator确保模型的高安全性。Pusher将模型部署到服务基础设施中。TensorFlowServing是一个为TensorFlowSavedModel文件提供服务的C++后端。为了最大限度地减少训练/服务偏差，TensorFlow转换“冻结”计算图，以便在服务中使用在训练期间找到的相同值。当训练在运行时是单个固定值时，DAG可能有多个操作。资料来源：unsplashUber：Michelangelo大约在2015年，Uber的ML工程师注意到机器学习系统中隐藏的技术债务。Uber构建了一个与ML模型集成的一次性定制系统，这在大型工程组织中可扩展性不是很好。用他们自己的话说，当时没有建立可靠、统一和可重复的管道来创建和管理大规模训练和预测数据的系统。这就是他们创造米开朗基罗的原因。它依赖于Uber的数据湖——交易和日志数据，支持离线（批量）和在线（流式）预测。对于离线预测，包含的Spark作业生成批量预测，而对于在线部署，模型在预测服务集群中提供服务，该集群通常由负载均衡器后面的数据集提供服务。由数百台机器组成，客户端将单个或批量预测请求作为RPC发送到集群。存储与每个实验的模型管理相关的元数据，例如训练器运行时统计信息、模型配置、沿袭、分布和特征的相对重要性、模型评估指标、标准评估图、学习参数值和摘要统计信息等。Michelangelo可以部署多个模型在同一个服务容器中，这允许从旧模型版本到新模型版本的安全转换，以及模型的并行A/B测试。Michelangelo的初始版本不支持在GPU上进行深度学习训练，但其开发团队解决了这一遗漏。当前平台使用Spark的ML管道序列化，但有一个额外的在线服务接口，添加了一个单例（在线）评分方法，既轻量又能够处理严格的SLA，例如用于欺诈检测和预防。它通过绕过SparkSQL的Catalyst优化器的开销来实现这一点。值得注意的是，Google和Uber都为其服务构建了内部协议缓冲区解析器和表示，从而避免了默认实现中存在的瓶颈。Airbnb：BigheadAirbnb出于类似原因在2016/2017年建立了自己的ML基础架构团队。首先，尽管他们只有几个模型在制作中，但每个模型都可能需要长达三个月的时间来构建。其次，模型之间没有一致性。三是线上线下预测差异较大。Bighead是其努力的结晶：数据管理由内部工具Zipline处理。Redspot是一个托管的、容器化的、多用户的JupyterNotebook服务。用于数据转换和管道提取的Bighead库为通用模型框架提供包装器。它通过转换保留元数据，因此可用于跟踪沿袭。DeepThought是一个用于在线预测的RESTAPI。Kubernetes精心优化服务。对于离线预测，Airbnb使用他们自己的自动化。Netflix也面临与上述公司类似的问题。他们的解决方案是使用Metaflow，这是一个面向数据科学家的Python库，可处理数据管理和模型训练，但不提供预测服务。因此，它不是机器学习的端到端平台，可能更适合公司内部用例而不是面向用户的用例。当然，它可以与由Kubernetes或AWSSageMaker提供支持的Seldon结合，变成一个成熟的解决方案。数据科学家将工作流编写为DAG步骤，就像数据工程师使用Airflow所做的那样。与Airflow一样，可以使用任何数据科学库，因为Metaflow仅执行Python代码。Metaflow在后台分发处理和训练。所有代码和数据都会自动快照到S3，以确保每个模型和实验的版本历史记录。Pickle是默认的模型序列化格式。开源版本还没有内置调度器。它鼓励用户“主要依靠垂直可扩展性”，尽管他们可以使用与AWS紧密耦合的AWSSageMaker实现水平可扩展性。Lyft：Flyte来源：unsplashLyft开源了其云原生平台Flyte，数据和机器学习操作在此融合。这与我的D/MLOps方法一致——数据(Ops)之于MLOps就像燃料之于火箭：没有它，它将是徒劳的。Flyte建立在Kubernetes之上。它由Lyft在内部使用，并且可以扩展到至少7,000个独特的工作流，每月执行超过100,000次、100万个任务和1000万个容器。Flyte中的所有实体都是不可变的，因此可以跟踪数据沿袭、重现实验并削减部署。重复性任务可以利用任务缓存来节省时间和金钱。当前支持的任务包括Python、Hive、Presto和Spark以及sidecars。从源码来看，好像是EKS。他们的数据目录也是Amundsen，很像Spotify的Lexikon。AWS、Azure、GCP和Co公共云领域的主要参与者都有自己的机器学习平台，但甲骨文除外，它们只为特定用例和行业提供封闭的基于机器学习的模型。AWSSageMaker是一个全堆栈机器学习解决方案，支持TensorFlow、Keras、PyTorch和MXNet。借助SageMakerNeo，可以将模型部署到云端和边缘。它具有通过AmazonMechanicalTurk标记存储在S3中的数据的内置功能。谷歌没有托管平台，但通过TFX、Kubeflow和AIPlatform，可以组合在CPU、GPU和TPU上运行的模型所需的组件，调整超参数，并自动部署到生产环境。Spotify甚至选择了TFX/Kubeflow-on-GCP选项。除了TensorFlow，还支持scikit-learn和XGBoost。自定义容器允许使用任何框架，例如PyTorch。SageMakerGroundTruth的标签服务目前处于测试阶段。Azure机器学习支持多种框架，例如scikit-learn、Keras、PyTorch、XGBoost、TensorFlow和MXNet。它有自己的D/MLOps套件，其中包含大量图形。那些喜欢模型开发的人可以使用拖放界面，它带有各种警告。正如预期的那样，模型和实验管理由Microsoft通过注册表完成。使用AzureKubernetes服务的生产部署也可以控制推出。IBMWatsonML提供点击式机器学习选项(SPSS)并支持通用框架组。作为两大主力之一，模型在CPU或GPU上训练，超参数调优也包含在盒子里。该平台没有很多关于数据和模型验证的细节，因为这些在其他IBM产品中可用。尽管阿里巴巴的AI机器学习平台标榜着两个流行语，但它并没有改进文档，而且关于最佳实践的部分写的是用例而不是建议。无论哪种方式，它都将精力放在拖放上，尤其是在数据管理和建模方面，这对于自动化的端到端ML平台可能没有多大帮助。该平台支持TensorFlow、MXNet、Caffe等框架，同时也支持大量传统算法。正如预期的那样，它还包括一个超参数调谐器。模型序列化是使用PMML、TensorFlow的SavedModel格式或Caffe格式完成的。请注意，采用PMML、ONNX或PFA文件的评分引擎可能支持快速部署，但它有引入训练/服务偏差的风险，因为所服务的模型是从不同格式加载的。其他平台H2O提供了一个使用POJO或MOJO进行数据操作、多种算法、交叉验证、用于超参数调整的网格搜索、特征排名和模型序列化的平台。valohai-芬兰语：lightshark，是一个托管机器学习平台，可以在私有、公共、混合或多云设置上运行。每个操作（或执行）针对DockerImage运行一个命令，类似于Kubeflow。两者的主要区别在于，Valohai直接管理Kubernetes部署集群，而Kubeflow则需要开发人员来执行此任务。然而，Kubeflow和TFX认为他们提供了一些与TensorFlow相关的工具。使用Valohai，您需要重用现有的DockerImage，或者推出自己的DockerImage，这意味着可以使用任何机器学习框架，但必须权衡自由度和可维护性方面的考虑。因此，培训可以通过Spark、Horovod、TensorFlow或任何适合个人需求和基础设施的方式进行分发，但这取决于个人。这也意味着负责确保数据转换兼容性以避免训练/服务偏差。请注意，它目前仅支持对象存储。Iguazio提到了在几秒钟内从笔记本或IDE进行部署的能力，尽管这似乎遗漏了最常见的场景：CI/CD管道，甚至包括TFX的Pusher组件的平台本身。它使用Kubeflow进行工作流编排。Iguazio确实有一个函数存储，为键值对和时间序列提供统一的API。虽然大多数大型科技公司都有专卖店，但许多可用的产品却没有。特征存储是核心，具有可在多个模型之间共享以加速模型开发的可重复使用的特征。它在企业范围内自动化特征工程。例如，可以从时间戳中提取许多特征：年、季节、月、周、时间、是否是当地节假日、自最近一次相关事件以来经过的时间、特定事件在固定窗口中发生的频率等等在。SwiftStackAI以NVIDIAGPU为目标，通过RAPIDS套件进行高吞吐量深度学习。RAPIDS提供了诸如cuML之类的库，这些库允许人们使用熟悉的scikit-learnAPI，但受益于GPU加速支持的算法，以及用于GPU驱动的图形分析的cuGraph。AI层是D/MLOps的API，内置支持多种数据源、编程语言和机器学习框架。MLflow由Databricks提供支持，这解释了与Spark的紧密集成。它提供一组有限的部署选项。例如，在PySpark中将模型导出为矢量化UDF的能力对于实时系统来说并不是最合理的，因为PythonUDF会带来Python运行时环境和JVM之间的通信开销。尽管开销不像使用标准PySparkUDF那样大，但由于在Python和JVM之间的传输中使用了ApacheArrow（一种内存中的柱状格式），所以开销并不小。如果您使用SparkStreaming作为默认的数据摄取解决方案，则可能很难使用Spark的微批处理模型实现亚秒级延迟。对日志记录的支持仍处于试验阶段，这对于D/MLOps非常重要。从文档中可以看出，MLflow并不专注于数据和模型验证，至少不是平台的标准部分。有一个托管版本的MLflow（在AWS和Azure上）提供了更多的功能。D2iQ的KubeflowKUDO是面向企业客户的基于Kubeflow的平台。与开源Kubeflow不同，它带有Spark和Horovod，以及针对TensorFlow、PyTorch和MXNet等主要框架的预构建和全面测试的CPU/GPU映像。数据科学家可以在不切换上下文的情况下在笔记本中部署表单。来源：unsplash默认支持多用??户使用。Istio和Dex集成在一起以提供额外的安全性和身份验证。Kubeflow的KUDO位于D2iQ的托管Kubernetes平台Konvoy之上。它可以在云端、本地、混合或边缘运行，也可以在气隙集群的端口上使用。在Kubernetes中，Kubeflow中的KUDO是使用KUDO定义的运算符的集合，KUDO是一个声明性工具包，用于使用YAML而不是Go创建Kubernetes运算符。KubernetesUnifiedDeclarationOperators（KUDOs）的Cassandra、Elastic、Flink、Kafka、Redis等都是开源的，可以和平台集成。
