机器学习, 以下简称为ML, 该算法以及架构所存在的意义, 于一个叫做MLOps的框架场景之中, 所关乎的工程项目的实践情况, 是此文全力介绍的目标。当从业者具备了足够丰富的知识储备时就可以开始尝试ML了。通常情况下ML实践会涉及研究和生产两个主要环境。下面举个例子, 这个例子什么情况, 仅在研究环境里进行数据分析, 或者进行建模, 就能满足需求, 也就是在文章标题当中, 找到跟比较高的点击率相关联的关键词。数据分析师的交付方式是什么样的, 是把探索出来的规律以及结论, 报告给一个运营团队, 如此一来, 运营人员能够在新的标题里, 尝试运用探索出来的规律以及结论, 以此提高点击率。再去举例说这样一种情形, 就是数据分析以及建模得要在研究环境当中来予以完成, 然而建模造就的结果却要在生产环境里展开发布 , 就如同在电商网站之上运行的推荐模型这种情况。会有这样的状况出现, 那便是在生产环境里运行的模型会牵扯到后续的管理以及运维方面 , 一旦在运行期间碰上异常或模型出现衰退之时, 就得借助监控机制去发出预警信号。对从业者而言, 这两类环境所提出的要求存在着极大差异。在众多初级ML图书当中, 多数所阐述的是研究环境里的ML, 而涉及生产环境中ML的情况则极为少见。常理上讲, 一个完整的ML项目工作流程是这样的, 首先会于研究环境当中去探索以及开发ML模型, 进而制作出一个ML应用程序的原型, 接着, 呈现预期表现的模型会被推送至生产环境, 开展自动化部署以及监控的相关工作。开发一款专为生产环境打造的ML应用程序的工作比分析、探索阶段的工作相比要复杂得许多, 得将在研究环境里运行的ML作业转变为可在生产环境内进行自动运行的作业, 我们通常将这一进程称作ML的生产化或者工程化。机器学习工程及生产化模块回想之前ML的定义, 宽泛来讲, ML属于一门借助算法以及统计模型从数据当中学习知识的学科, ML工程按照字面意思就是打造基于ML的应用程序的计算实践。ML工程这一技术是建立于ML的工作根基之上的, 它要把在研究环境里所开发出的ML模型运用到生产环境当中, ML工程跟ML存在区别, 其侧重点并不一样, ML更在意于算法的优化以及模型的训练, 而ML工程则更关注从形形色色的业务系统去采集数据, 再训练出一个可同时兼顾模型性能与计算性能的模型, 从而让这个模型能够在生产环境之中安稳运行, 进而确保模型具备可监控、可维护、可更新以及可被业务系统使用的特性, 从而为模型生产化给予工程方面的保障。ML工程涵盖了诸多阶段, 有从数据收集开始的阶段, 有进行特征工程的阶段, 有开展模型训练的阶段, 还有实现模型投入应用、管理以及运维的阶段。这个过程跟高中时期考试的不同阶段相类似, 其中ML开发过程差不多类似平时的模考情况, 它所关心的是各知识点的消化以及总结, 而ML工程就如同高考一般, 在兼顾平时模考所习得的知识点的情形下, 还得综合考量实考环境中的心理压力、时间分配以及考题内容等诸多因素。实际上呢, 数据科学团队常常致力于去钻研新颖的算法, 或者训练高精准的模型然而跟实际 ML 项目里所需要进行的全流程, 像是特征工程、部署、监控等等相比较而言, ML 算法仅仅只是 ML 项目中特别小的一个部分, 一个实实在在要被投入生产的 ML 项目通常是需要大量的工程工作以及基础设施的相互配合, 从而达成 ML 模型在生产环境里能够顺利地运行。2015年, 谷歌发布论文表明, 为躲避永无休止之“技术债”缠身, 需着重考量将“把视作一种学科的存在加以重视于当下ML技术主要潮流范畴内无疑为此趋势之势”, 依托强化工程技术给予供应达成ML生产化。如图1所示, ML模型生产化具多个构成部分, 于真实状况里要求在这些结构间构筑关联体系来协同开展ML模型生产化历程, 以推进其生产化的达成。 这样通过多方面举措以顺利达成ML生产化的进程, 使其得以逐步实现生产化的转变, 从而避免受困于无休止增长的“技术债”, 这都在谷歌2015年发布的论文所阐述的范畴之内, 且在实际应用场景中, 各相关部分的协同配合至关重要, 其模块之间的沟通机制建立对于ML模型生产化的最终实现不可或缺。图1 ML生产化模块机器学习工程模块的设计原则关注点分离, 也就是SoC, 乃是一个可行的设计原则。它所指的是在计算机科学里面, 对应用程序、代码块以及其他对象系统进行划分的此种方式。针对其中关注点被“分离”的程度, 会因为系统的不同而有所差异。比如说, 要是有一个存在相互依存关系的系统, 通常来讲它就是关注点的弱分离了, 我们把它简称为弱分离, 对。然而要是有一个能够完全独立去负责自身工作的系统或者模块, 一般情况下会被当作是关注点的强分离, 也就是简称为强分离。对于 ML 工程模块而言, 设计层面存在着不同选择, 既能够采用弱分离这一设计原则, 与此同时又可以运用强分离这种设计原则。当中, 在弱分离的设计原则情形之下, 训练以及预测这两项操作必须于同一台服务器之上开展运行, 并且训练步骤和预测步骤被捆绑于一个相同的模块之中。举例来说, 在键入数据之时对一个名为 train 的函数予以调用, 此函数会返回一个模型, 这个产出的模型复又会成为函数的输入内容, 在实际运行期间会按照先后排列顺序依次径直去执行 train 以及函数。然而, 在强分离的设计原则条件下, 训练以及预测能够在两个彼此不同的服务器或者进程里进行运行。处于这种情形下, 训练是独立发生的, 预测也是独立发生的, 训练步骤归属于不同的模块, 预测步骤同样归属于不同的模块。通常来讲, 那种面向服务的架构也就是SOA, 是契合强分离设计原则的, 我们觉得, 于生产场景范畴之内, 运用SOA去开展设计以及开发ML系统, 这事是具备可行性的。除此之外, 不管是去设计MLOps平台, 还是设计传统的ML系统, 在设计期间都建议要考虑下面这几项关键原则。进行机器学习工程的模块设计时需要注意的细节应将满足业务需求以及公司远为长远之目标视为设计架构与模块时的出发点。于开启运用最新技术展开设计之前, 要针对现有条件之限制、预期会创造出怎样的价值以及是在为谁创造该价值等等予以知悉, 同时得考虑当下公司的业务场景以及未来有可能会新增的场景。举例而言, 于现有的业务场景当中是否具有实行实时预测的必要? 倘若有实行实时预测的需求, 那么业务侧所准许的延迟究竟系毫秒级别的还是秒级别的, 抑或是仅仅在接收输入的数据之后的30分钟或者一天之内交付预测结果便可以达致需求。具体地以下几个细节值得考虑。一经团队针对这些基础问题开展了评估, 随即能够基于此去思索 ML 系统的某些高级体系结构选项, 举例而言, 构建独立的模型训练系统、模型服务系统, 又或者全流程的 MLOps 平台。需要多加留意的是, 为了防止从业的人员在运用方面把“系统”跟“平台”弄混淆, 在这里针对二者的定义予以说明。某个具体的软件, 一般会被称作系统, 而平台呢, 乃是指开展某项工作所必不可少的信息化环境或者那些必要条件, 同时, 它又是一个相对抽象的生态环境。系统着重强调的那一方面是功能, 平台集中关注侧重于场景。系统拥有明确的输入、还有处理过程以及输出环节, 而平台本质上的依据是基于同一套的规则以及体系的, 它是一个经由多个不同的主体共同参与而构成的生态圈, 并且这套规则和体系实际上常常是源于系统所组成的。编码环境与模型探索要是数据科学家于研究环境里运用的编程语言跟生产环境的相符, 那么整个工作流程的处理会较为轻松些, 这里所涉及的编程语言一般而言是那种含有丰富有关数据科学还有数据处理的开源代码以及包的语, 一种尽管有诸多办法可助其进一步优化运行速度, 但假使其被作为考虑的选项时却或许并不能行得通的语。基于性能方面的考量, 何时开展语言的转换这件事变得极其重要, 原因在于研究团队跟生产团队之间的那额外的沟通成本将会变成一个相当大的负担。当然咯, 要是你周边所有的数据科学家都对 Scala、Java 或者 C语言十分精通, 那么这个问题就变轻松好多了。当然了, 不一样的角色, 有可能会运用不一样的工具, 又或者运用不一样的编程语言, 没有哪一个工具能够把所有的任务都涵盖起来, 更为关键的是, 单独的一个任务, 通常来讲需要通过多个角色以及多个工具的互相协作, 这样子才能够达成其实现。拿分析工程师、数据科学家以及数据工程师来说, 就如同图2所展示的那样, 数据工程师有可能运用其中的Scala去创建涵盖数亿个事件的数据集的聚合, 分析工程师或许会于有关业务的分析报告里运用SQL对该聚合展开分析以及可视化操作, 而数据科学家说不定会使用手段处理该聚合, 并且参照分析工程师的分析结果来构建线上营销模型。图2 工具和编程语言偏好因角色而异的示例看似初看时, 这三种角色的工作流程好像不一样, 然而实际上, 他们工作内容常常互补, 不同角色负责的工作流程里任务还有重叠, 为推进团队间协作进一步, 我们期盼尽量缩减平台需支持工具的数量, 于这些工具乃至语言的上层增添一层抽象, 目的是提供跨工具以及编程语言的通用模式, 这也是MLOps的理念。还好, 存在一个开源项目, 这个开源项目属于当前数据科学家最常运用的开源项目中的一个, 它的设计达成了这一要点。当下市场上诸多专门钻研MLOps领域的公司都借助它来供给建模或者分析的环境, 像是cnvrg.io、Data Lab等。其中那家公司旗下的平台起初是从提供线上建模环境起步的之后才渐渐增添了模型部署以及管理等功能, 并且一步步拓展成为MLOps平台。为此提供了一种标准的消息传递API协议, 运用此协议与充当计算引擎的内核实施通信, 这一协议开启了一种可组合的架构设定, 能实现编写代码具体内容的位置与执行位置的互相间隔, 其中编写在UI位置, 而执行为内核位置, 将运行时与UI界面实施分隔, 实际上如MLOps此部分设计中确实有和其相仿类似思路存在一样, 可以超越多种并不相同的编程语言范围, 其同时也持有方式上保持灵活可变的执行环境配置特性, 并能确保灵活可变特性持续存在永不改变。具体而言, 鉴于新的ML开发框架持续兴起且替代传统工具这般情况, 对MLOps平台所支持的语言以及框架拟订受限的标准这种做法并不被提倡。MLOps平台开展设计时应当具备充分的灵活性, 同时要做到模块化, 旨在能够为新框架的添加予以支持举例来说, 要达成随意去加载所需的、诸如-Learn这类数据科学家必不可少这样标准的工具或者框架之事。处于MLOps框架建造环境之际, 有一点需留意, 得依据用户或者项目生成起隔离空间, 举例一下, 要把新增加的服务建置于所存在的虚拟环境当中, 或者借助容器予以创建, 这是鉴于不同的项目或者不同的用户也许会运用不一样版本的ML工具或者框架。在我们打算着手去开发一个有可能会在生产环境里运转的ML原型之际, 我们偏好去运用一些具备可视化特性的开发工具, 比如说。从事相关工作的人员能够一边去编写代码, 而与此同时还能撰写有关模型的说明以及数据探索的结论。同运用开发工具, 或者老式的文本编辑器以及Shell终端相比较而言, 其关键优势在于, 它具备数据可视化的功能, 能够在线呈现分析图, 能为待打印的数据框架给予良好的显示格式, 就如同图3所展示的那样。这使得开发者于撰写脚本之际, 能够较为轻易地检查中间结果, 这种方式相较于把输出内容打印至终端, 或者在断点处检查变量, 显得更为直观、高效。图3 中数据帧的基础可视化首个具体的、手动的步骤, 是任何 ML 项目里的数据探索, 通常这也是从业者最为熟悉的步骤。然而当把一个 ML 项目推进至产品化阶段的时候, 往往会出现认知偏差, 原因在于这两个阶段所需的工具以及思维方式有所不同。模型的存在依赖于数据, 因而数据探索理应先于模型探索, 这是很自然的。数据探索旨在理解数据, 人们常见地收集用以准备数据的初始数据, 是以表格形态留存的, 此时直接探索数据是不可行的因为包含百万行数据量的表格, 并非人类理解数据的理想介质。人类倾向于借助形状、尺寸以及颜色等去领会事物, 为了明晰单个变量属性以及多个变量间的关联, 人们借助工具辅助解析。数据经特征工程手段在转换与处理期间使之达到更高层阶特征成为该步骤最终的产出结果, 此结果在模型探索环节中对接下来的流程走向起到了决定性的作用, 当我们尝试去理解数据时便可通过这样的方式来进行。模型探索虽能够跟数据探索重叠, 然而也能够被视作是单独的一步。进入到模型探索步骤时, 数据科学家会针对不同模型的可行性展开分析与评估, 像是评估运用回归、决策树或者随机森林等算法于现有数据之上的表现。在技术方面, 模型探索相较于数据探索有着更高的要求, 模型探索时经常会被使用 数据探索一般能够在本地环境里达成, 然而模型探索过程通常存在更高的计算需要用一组参数跟数据去测试一个模型的表现, 有时候耗时几个钟头, 甚至数天, 一个可自动扩展的云环境或许会成为合理的选择, 模型探索不但要耗费时间还要花费金钱, 因而版本控制以及可重复性对于所有的探索实验来讲都是必要的。此外, 因 ML 项目日益增多, 写模型文档成了数据科学家开发模型时不可缺少的部分, MLOps 平台嵌入后, 数据科学家能用相关功能做模型训练与部署, 无需过问底层资源管理且能在其中轻快写好数据探索跟模型建模经过, 做成知识库, 从而能在整个团队里面共享。完成数据探索与模型探索后, 若要把模型或分析结果进行生产化, 那便还有诸多工作需梳理以及实现。比如说, 生产里的数据处于何处? 怎样在现实场景中运用模型的结果? 需不需要把模型部署至分布式的机器上以便扩大规模模型服务的预测延迟是否足够低? 如何去更新模型? 怎样知晓模型是否存有问题? 怎样处理边缘案例, 像数据缺失以及异常值的情形?特征存储在ML项目里头, 常常得处理好多各式各类的数据源, 为啥, 是由于压根就不存在哪种数据源能适配全部应用。数据库存储海量数据特别方便, 然而返回结果那时相对较慢, 为啥, 是因为它们是从磁盘读取数据的, 并且读取时间或者磁盘的I/O通常会对网络应用性能造成限制。有些对延迟时间有要求的应用或许得找办法解决这个瓶颈难题, 一种常用办法是运用缓存, 也就是把常用数据存起来, 让它们留在内存里且随时能用, 而非从磁盘“分页”去提取。具体来讲, 数据存储的办法存在着多样, 像是具备海量原始数据存储能力的数据湖, 用于集中存储企业数据的数据仓库, 面向特定部门或业务线的数据集市, 以及在近些年机器学习领域颇受关注而兴起的特征存储等。这些分别呈现出不同等级的数据管理模式的区分。作为好比数据科学这般的数据仓库的特征存储, 其主要目标在于让数据科学家能够去缩短从数据摄取开始一直到ML模型训练以及推理的时间, 它填补了MLOps生命周期里的一个重要空白, 嗯。在特征存储模式之时, 收集数据, 还有将其转化成特征的那个进程, 是一次性达成的, 而且能够被重复运用。特征存储, 它是把特征工程的进程与特征的消费进程去进行解耦, 这里说的对特征的消费, 比如提到在模型的开发或者在线推理的时候去运用在特征存储当中, 特征于模型训练以及在线推理服务之间的消费, 同样使用不一样的技术来予以分离, 藉由一个通用的SDK去维持这两种消费模式的一致性喔。这种共享方式, 使得ML的工作进程得以加快, 原因在于, 数据工程师无需像传统方式那般, 每次在建模之际, 都去重新收集数据, 以及开展相应的转换, 毕竟重复性的工作, 不但会造成浪费情形, 还对特征的充分利用颇为不利, 更有碍于其管理。另外, 借助特征存储, 能够挑选历史沉淀下来的特征, 以此快速生成训练数据, 用以训练不同的模型。特征存储有着双重作用, 它本是对特征工程创建的特征予以存储的设施, 同时又是能让开发者实现特征复用的的贮藏设备。从本质而言, 特征存储当属众人共享、注释、发现及使用已处理数据的场所之处。具体的说, 它牵扯到两种不同的储存方式, 其一是低迟延的在线存储, 一般以Redis缓存的形态为模型服务供应最新且实时的特征其二是成本得以优化的离线存储, 用以存放支撑模型训练所需之过往数据。存在于当前市场之上深受欢迎的特征存储包括, Uber这个, Feast这般其中有Gojek还有, 以及。实验管理和模型管理实验管理, 于 ML 模型关键之处, 像迭代、版本化以及评估等类事件, 紧密相连, 模型管理, 同样与之紧密相关, 同时, 要保证有可重复性, 还得提供针对模型以及结果的可视化管理界面。存在对模型训练期间所产生的特定信息的管理工作, 这些特定信息包含变量, 包含特征, 包含属性, 包含评分, 包含性能指标, 包含历史版本, 还包含位置信息, 而这样的管理工作属于实验管理的范畴。与之相对的是, 对于训练这一活动, 以及创建这一行为, 还有部署这一举措, 再加上重新评估这一过程, 又再有重新训练这一操作, 另外发布到生产环境这一行动, 以及模型版本、标签和描述这类事件的管理之事, 通通都归属于模型管理的范畴之内。这些事件所具有的标签能够是注释, 像是项目, 还有用户, 并且包含时间戳, 以及有关原始值与更新值的详细信息。通常而言, 实验管理和模型管理的达成, 往往得把跟数据科学家工作流程有关联的那些元数据, 予以记录以及保存。这里面的记录和保存, 能够借助API的封装来达成。除了借助API与元数据集开展编程交互以外, 还得拥有前端界面的功能, 以此来达成可视化管理, 而在前端界面上开展操作产生以及检索的数据, 同样是借助上述API完成与后端数据库交互的。服务存在于一个更大系统里的独立单元是服务, 它能提出一些特定的功能。可将服务当作是构成一个系统的黑盒子。比如说, 一个在后端部位的大型媒体网站系统, 有可能是靠着若干一同给媒体网站使用者供应文章推荐的服务来构成的。在此其中, 给到一组关于一篇文章的统计内容, 被视作一个服务, 而另一个服务, 也许会启动被称作 ML—推荐服务的 ML 训练作业, 还会把训练好的模型给到一个对 ML 这种结果开展后处理的服务, 最终网站前端经由借助推荐服务获得针对推荐的结果。这些工作一般被称作服务, 每一个单独的服务都是很强烈地相互分离的。尽管不同企业所定义的服务标准是各不相同的, 然而依旧是存在共性的, 像下面所讲述的这样。服务应当是能够被复用的, 这对于MLOps平台而言格外有用, 举例来说, 特征存储的在线服务是能够被复用的, 它能够满足各异团队以及各异模型的使用需求。模型服务规模化于生产环境里, 在模型服务化阶段, 此阶段自服务化后所生成的服务称作模型推理服务或者预测服务, 其对应的API常常要应对大量的请求负载, 好多情况下单机难以满足需求, 存在诸多方法能够去扩展一个生产系统。第一种方法是垂直扩展, 该扩展指的是那种增加网络里单个节点容量的过程。若是那种模型服务早已在多个节点上面运行的情况, 它指的则是增加一部分网络, 或者整个网络的容量。垂直扩展有着一个主要的问题, 就是随着单个节点容量慢慢增加, 跟增加第二个类似那种规格的节点比起来, 它的成本会呈现非线性地去增加。垂直扩展通常属于首选的方法。一般而言, 通过这种方法进行扩展的时候, 是不需要去修改代码的。第二种办法是进行水平扩展, 也就是往网络里增加更多的节点, 在节点之间去分配容量。这种办法通常得引入负载均衡器, 这个负载均衡器会把一个给定的请求分流到一个有可能当下不忙的节点。同样, 这种办法在扩展之际也无需改变应用程序的代码。不过, 和垂直扩展相比较, 它会带来更多的复杂性, 原因在于要引入负载均衡器以及增大网络规模。还有其他多种方式可优化生产系统性能, 并非仅这两种扩展方式。常见方式为, 优化应用程序代码自身性能, 像找寻使代码片段处理更快的办法, 分批开展数据库调用, 规避不必要循环与嵌套, 以及将网络调用设为异步等。有时, 要在低延迟与准确性间寻得折中方案。运用这些方法调整模型服务后, 模型服务的响应会变快。还有, 为了对模型服务组成部分中的构件成本予以优化, 托管技术的挑选相当关键, 比方讲, 在容纳仪器当中使多个模型运行起来能够最大程度地将资源也就是中央处理器或者图形处理单元的内存加以运用, 进而处理推理方面的请求。那模型服务构件自身应当具备控制模型从产生到消亡整个过程的管理职能, 以便帮助版本推出运行下去也起到助力效用, 自动扩展属于应用机器学习基础建构及实现运营范畴当中一项关键的特质, 是用来满足高峰时间段需求以及削减非高峰时间段成本的。就好比啊, 针对长时间没接收到流量的模型, 能够灵活地减少对这个模型服务所需资源的分配比例。模型监控生产环境里头的模型, 能够在正常运维涵盖的范围之内运行, 借助监控组件的可视化指标予以观察, 当模型的运行表现出现变化之际, 要有持续训练机制被引入, 用以解决模型的漂移问题。之前讨论过, ML管道涵盖传入数据验证, 该验证是管道中一个独立任务, 还有模型评估, 这也是管道里单独的任务, 以及推理请求监控, 同样是管道中的独立部分, 另外还有日志管理亦是管道中的独立任务。管道里每个如此独立的组件所产生的结果, 都得存储于中央存储之中, 目的在于保障模型生命周期实现可观察性。开发环境中经过验证以及评估的模型, 在被推送到生产环境之后, 其实时性能得由专门的监察模块予以跟踪, 用来保证对业务的影响朝着正向发展, 能够借助多种办法去监控运行中的模型服务以及预测行为, 理想的办法是, 记录模型服务被请求之际所做出的预测, 接着把它们跟后续业务系统运行进程里所观测到的用户反馈结果融合到一块, 最终评估运行中的模型性能是不是契合预期。
机器学习, 以下简称为ML, 该算法以及架构所存在的意义, 于一个叫做MLOps的框架场景之中, 所关乎的工程项目的实践情况, 是此文全力介绍的目标。当从业者具备了足够丰富的知识储备时就可以开始尝试ML了。通常情况下ML实践会涉及研究和生产两个主要环境。下面举个例子, 这个例子什么情况, 仅在研究环境里进行数据分析, 或者进行建模, 就能满足需求, 也就是在文章标题当中, 找到跟比较高的点击率相关联的关键词。数据分析师的交付方式是什么样的, 是把探索出来的规律以及结论, 报告给一个运营团队, 如此一来, 运营人员能够在新的标题里, 尝试运用探索出来的规律以及结论, 以此提高点击率。再去举例说这样一种情形, 就是数据分析以及建模得要在研究环境当中来予以完成, 然而建模造就的结果却要在生产环境里展开发布 , 就如同在电商网站之上运行的推荐模型这种情况。会有这样的状况出现, 那便是在生产环境里运行的模型会牵扯到后续的管理以及运维方面 , 一旦在运行期间碰上异常或模型出现衰退之时, 就得借助监控机制去发出预警信号。对从业者而言, 这两类环境所提出的要求存在着极大差异。在众多初级ML图书当中, 多数所阐述的是研究环境里的ML, 而涉及生产环境中ML的情况则极为少见。常理上讲, 一个完整的ML项目工作流程是这样的, 首先会于研究环境当中去探索以及开发ML模型, 进而制作出一个ML应用程序的原型, 接着, 呈现预期表现的模型会被推送至生产环境, 开展自动化部署以及监控的相关工作。开发一款专为生产环境打造的ML应用程序的工作比分析、探索阶段的工作相比要复杂得许多, 得将在研究环境里运行的ML作业转变为可在生产环境内进行自动运行的作业, 我们通常将这一进程称作ML的生产化或者工程化。机器学习工程及生产化模块回想之前ML的定义, 宽泛来讲, ML属于一门借助算法以及统计模型从数据当中学习知识的学科, ML工程按照字面意思就是打造基于ML的应用程序的计算实践。ML工程这一技术是建立于ML的工作根基之上的, 它要把在研究环境里所开发出的ML模型运用到生产环境当中, ML工程跟ML存在区别, 其侧重点并不一样, ML更在意于算法的优化以及模型的训练, 而ML工程则更关注从形形色色的业务系统去采集数据, 再训练出一个可同时兼顾模型性能与计算性能的模型, 从而让这个模型能够在生产环境之中安稳运行, 进而确保模型具备可监控、可维护、可更新以及可被业务系统使用的特性, 从而为模型生产化给予工程方面的保障。ML工程涵盖了诸多阶段, 有从数据收集开始的阶段, 有进行特征工程的阶段, 有开展模型训练的阶段, 还有实现模型投入应用、管理以及运维的阶段。这个过程跟高中时期考试的不同阶段相类似, 其中ML开发过程差不多类似平时的模考情况, 它所关心的是各知识点的消化以及总结, 而ML工程就如同高考一般, 在兼顾平时模考所习得的知识点的情形下, 还得综合考量实考环境中的心理压力、时间分配以及考题内容等诸多因素。实际上呢, 数据科学团队常常致力于去钻研新颖的算法, 或者训练高精准的模型然而跟实际 ML 项目里所需要进行的全流程, 像是特征工程、部署、监控等等相比较而言, ML 算法仅仅只是 ML 项目中特别小的一个部分, 一个实实在在要被投入生产的 ML 项目通常是需要大量的工程工作以及基础设施的相互配合, 从而达成 ML 模型在生产环境里能够顺利地运行。2015年, 谷歌发布论文表明, 为躲避永无休止之“技术债”缠身, 需着重考量将“把视作一种学科的存在加以重视于当下ML技术主要潮流范畴内无疑为此趋势之势”, 依托强化工程技术给予供应达成ML生产化。如图1所示, ML模型生产化具多个构成部分, 于真实状况里要求在这些结构间构筑关联体系来协同开展ML模型生产化历程, 以推进其生产化的达成。 这样通过多方面举措以顺利达成ML生产化的进程, 使其得以逐步实现生产化的转变, 从而避免受困于无休止增长的“技术债”, 这都在谷歌2015年发布的论文所阐述的范畴之内, 且在实际应用场景中, 各相关部分的协同配合至关重要, 其模块之间的沟通机制建立对于ML模型生产化的最终实现不可或缺。图1 ML生产化模块机器学习工程模块的设计原则关注点分离, 也就是SoC, 乃是一个可行的设计原则。它所指的是在计算机科学里面, 对应用程序、代码块以及其他对象系统进行划分的此种方式。针对其中关注点被“分离”的程度, 会因为系统的不同而有所差异。比如说, 要是有一个存在相互依存关系的系统, 通常来讲它就是关注点的弱分离了, 我们把它简称为弱分离, 对。然而要是有一个能够完全独立去负责自身工作的系统或者模块, 一般情况下会被当作是关注点的强分离, 也就是简称为强分离。对于 ML 工程模块而言, 设计层面存在着不同选择, 既能够采用弱分离这一设计原则, 与此同时又可以运用强分离这种设计原则。当中, 在弱分离的设计原则情形之下, 训练以及预测这两项操作必须于同一台服务器之上开展运行, 并且训练步骤和预测步骤被捆绑于一个相同的模块之中。举例来说, 在键入数据之时对一个名为 train 的函数予以调用, 此函数会返回一个模型, 这个产出的模型复又会成为函数的输入内容, 在实际运行期间会按照先后排列顺序依次径直去执行 train 以及函数。然而, 在强分离的设计原则条件下, 训练以及预测能够在两个彼此不同的服务器或者进程里进行运行。处于这种情形下, 训练是独立发生的, 预测也是独立发生的, 训练步骤归属于不同的模块, 预测步骤同样归属于不同的模块。通常来讲, 那种面向服务的架构也就是SOA, 是契合强分离设计原则的, 我们觉得, 于生产场景范畴之内, 运用SOA去开展设计以及开发ML系统, 这事是具备可行性的。除此之外, 不管是去设计MLOps平台, 还是设计传统的ML系统, 在设计期间都建议要考虑下面这几项关键原则。进行机器学习工程的模块设计时需要注意的细节应将满足业务需求以及公司远为长远之目标视为设计架构与模块时的出发点。于开启运用最新技术展开设计之前, 要针对现有条件之限制、预期会创造出怎样的价值以及是在为谁创造该价值等等予以知悉, 同时得考虑当下公司的业务场景以及未来有可能会新增的场景。举例而言, 于现有的业务场景当中是否具有实行实时预测的必要? 倘若有实行实时预测的需求, 那么业务侧所准许的延迟究竟系毫秒级别的还是秒级别的, 抑或是仅仅在接收输入的数据之后的30分钟或者一天之内交付预测结果便可以达致需求。具体地以下几个细节值得考虑。一经团队针对这些基础问题开展了评估, 随即能够基于此去思索 ML 系统的某些高级体系结构选项, 举例而言, 构建独立的模型训练系统、模型服务系统, 又或者全流程的 MLOps 平台。需要多加留意的是, 为了防止从业的人员在运用方面把“系统”跟“平台”弄混淆, 在这里针对二者的定义予以说明。某个具体的软件, 一般会被称作系统, 而平台呢, 乃是指开展某项工作所必不可少的信息化环境或者那些必要条件, 同时, 它又是一个相对抽象的生态环境。系统着重强调的那一方面是功能, 平台集中关注侧重于场景。系统拥有明确的输入、还有处理过程以及输出环节, 而平台本质上的依据是基于同一套的规则以及体系的, 它是一个经由多个不同的主体共同参与而构成的生态圈, 并且这套规则和体系实际上常常是源于系统所组成的。编码环境与模型探索要是数据科学家于研究环境里运用的编程语言跟生产环境的相符, 那么整个工作流程的处理会较为轻松些, 这里所涉及的编程语言一般而言是那种含有丰富有关数据科学还有数据处理的开源代码以及包的语, 一种尽管有诸多办法可助其进一步优化运行速度, 但假使其被作为考虑的选项时却或许并不能行得通的语。基于性能方面的考量, 何时开展语言的转换这件事变得极其重要, 原因在于研究团队跟生产团队之间的那额外的沟通成本将会变成一个相当大的负担。当然咯, 要是你周边所有的数据科学家都对 Scala、Java 或者 C语言十分精通, 那么这个问题就变轻松好多了。当然了, 不一样的角色, 有可能会运用不一样的工具, 又或者运用不一样的编程语言, 没有哪一个工具能够把所有的任务都涵盖起来, 更为关键的是, 单独的一个任务, 通常来讲需要通过多个角色以及多个工具的互相协作, 这样子才能够达成其实现。拿分析工程师、数据科学家以及数据工程师来说, 就如同图2所展示的那样, 数据工程师有可能运用其中的Scala去创建涵盖数亿个事件的数据集的聚合, 分析工程师或许会于有关业务的分析报告里运用SQL对该聚合展开分析以及可视化操作, 而数据科学家说不定会使用手段处理该聚合, 并且参照分析工程师的分析结果来构建线上营销模型。图2 工具和编程语言偏好因角色而异的示例看似初看时, 这三种角色的工作流程好像不一样, 然而实际上, 他们工作内容常常互补, 不同角色负责的工作流程里任务还有重叠, 为推进团队间协作进一步, 我们期盼尽量缩减平台需支持工具的数量, 于这些工具乃至语言的上层增添一层抽象, 目的是提供跨工具以及编程语言的通用模式, 这也是MLOps的理念。还好, 存在一个开源项目, 这个开源项目属于当前数据科学家最常运用的开源项目中的一个, 它的设计达成了这一要点。当下市场上诸多专门钻研MLOps领域的公司都借助它来供给建模或者分析的环境, 像是cnvrg.io、Data Lab等。其中那家公司旗下的平台起初是从提供线上建模环境起步的之后才渐渐增添了模型部署以及管理等功能, 并且一步步拓展成为MLOps平台。为此提供了一种标准的消息传递API协议, 运用此协议与充当计算引擎的内核实施通信, 这一协议开启了一种可组合的架构设定, 能实现编写代码具体内容的位置与执行位置的互相间隔, 其中编写在UI位置, 而执行为内核位置, 将运行时与UI界面实施分隔, 实际上如MLOps此部分设计中确实有和其相仿类似思路存在一样, 可以超越多种并不相同的编程语言范围, 其同时也持有方式上保持灵活可变的执行环境配置特性, 并能确保灵活可变特性持续存在永不改变。具体而言, 鉴于新的ML开发框架持续兴起且替代传统工具这般情况, 对MLOps平台所支持的语言以及框架拟订受限的标准这种做法并不被提倡。MLOps平台开展设计时应当具备充分的灵活性, 同时要做到模块化, 旨在能够为新框架的添加予以支持举例来说, 要达成随意去加载所需的、诸如-Learn这类数据科学家必不可少这样标准的工具或者框架之事。处于MLOps框架建造环境之际, 有一点需留意, 得依据用户或者项目生成起隔离空间, 举例一下, 要把新增加的服务建置于所存在的虚拟环境当中, 或者借助容器予以创建, 这是鉴于不同的项目或者不同的用户也许会运用不一样版本的ML工具或者框架。在我们打算着手去开发一个有可能会在生产环境里运转的ML原型之际, 我们偏好去运用一些具备可视化特性的开发工具, 比如说。从事相关工作的人员能够一边去编写代码, 而与此同时还能撰写有关模型的说明以及数据探索的结论。同运用开发工具, 或者老式的文本编辑器以及Shell终端相比较而言, 其关键优势在于, 它具备数据可视化的功能, 能够在线呈现分析图, 能为待打印的数据框架给予良好的显示格式, 就如同图3所展示的那样。这使得开发者于撰写脚本之际, 能够较为轻易地检查中间结果, 这种方式相较于把输出内容打印至终端, 或者在断点处检查变量, 显得更为直观、高效。图3 中数据帧的基础可视化首个具体的、手动的步骤, 是任何 ML 项目里的数据探索, 通常这也是从业者最为熟悉的步骤。然而当把一个 ML 项目推进至产品化阶段的时候, 往往会出现认知偏差, 原因在于这两个阶段所需的工具以及思维方式有所不同。模型的存在依赖于数据, 因而数据探索理应先于模型探索, 这是很自然的。数据探索旨在理解数据, 人们常见地收集用以准备数据的初始数据, 是以表格形态留存的, 此时直接探索数据是不可行的因为包含百万行数据量的表格, 并非人类理解数据的理想介质。人类倾向于借助形状、尺寸以及颜色等去领会事物, 为了明晰单个变量属性以及多个变量间的关联, 人们借助工具辅助解析。数据经特征工程手段在转换与处理期间使之达到更高层阶特征成为该步骤最终的产出结果, 此结果在模型探索环节中对接下来的流程走向起到了决定性的作用, 当我们尝试去理解数据时便可通过这样的方式来进行。模型探索虽能够跟数据探索重叠, 然而也能够被视作是单独的一步。进入到模型探索步骤时, 数据科学家会针对不同模型的可行性展开分析与评估, 像是评估运用回归、决策树或者随机森林等算法于现有数据之上的表现。在技术方面, 模型探索相较于数据探索有着更高的要求, 模型探索时经常会被使用 数据探索一般能够在本地环境里达成, 然而模型探索过程通常存在更高的计算需要用一组参数跟数据去测试一个模型的表现, 有时候耗时几个钟头, 甚至数天, 一个可自动扩展的云环境或许会成为合理的选择, 模型探索不但要耗费时间还要花费金钱, 因而版本控制以及可重复性对于所有的探索实验来讲都是必要的。此外, 因 ML 项目日益增多, 写模型文档成了数据科学家开发模型时不可缺少的部分, MLOps 平台嵌入后, 数据科学家能用相关功能做模型训练与部署, 无需过问底层资源管理且能在其中轻快写好数据探索跟模型建模经过, 做成知识库, 从而能在整个团队里面共享。完成数据探索与模型探索后, 若要把模型或分析结果进行生产化, 那便还有诸多工作需梳理以及实现。比如说, 生产里的数据处于何处? 怎样在现实场景中运用模型的结果? 需不需要把模型部署至分布式的机器上以便扩大规模模型服务的预测延迟是否足够低? 如何去更新模型? 怎样知晓模型是否存有问题? 怎样处理边缘案例, 像数据缺失以及异常值的情形?特征存储在ML项目里头, 常常得处理好多各式各类的数据源, 为啥, 是由于压根就不存在哪种数据源能适配全部应用。数据库存储海量数据特别方便, 然而返回结果那时相对较慢, 为啥, 是因为它们是从磁盘读取数据的, 并且读取时间或者磁盘的I/O通常会对网络应用性能造成限制。有些对延迟时间有要求的应用或许得找办法解决这个瓶颈难题, 一种常用办法是运用缓存, 也就是把常用数据存起来, 让它们留在内存里且随时能用, 而非从磁盘“分页”去提取。具体来讲, 数据存储的办法存在着多样, 像是具备海量原始数据存储能力的数据湖, 用于集中存储企业数据的数据仓库, 面向特定部门或业务线的数据集市, 以及在近些年机器学习领域颇受关注而兴起的特征存储等。这些分别呈现出不同等级的数据管理模式的区分。作为好比数据科学这般的数据仓库的特征存储, 其主要目标在于让数据科学家能够去缩短从数据摄取开始一直到ML模型训练以及推理的时间, 它填补了MLOps生命周期里的一个重要空白, 嗯。在特征存储模式之时, 收集数据, 还有将其转化成特征的那个进程, 是一次性达成的, 而且能够被重复运用。特征存储, 它是把特征工程的进程与特征的消费进程去进行解耦, 这里说的对特征的消费, 比如提到在模型的开发或者在线推理的时候去运用在特征存储当中, 特征于模型训练以及在线推理服务之间的消费, 同样使用不一样的技术来予以分离, 藉由一个通用的SDK去维持这两种消费模式的一致性喔。这种共享方式, 使得ML的工作进程得以加快, 原因在于, 数据工程师无需像传统方式那般, 每次在建模之际, 都去重新收集数据, 以及开展相应的转换, 毕竟重复性的工作, 不但会造成浪费情形, 还对特征的充分利用颇为不利, 更有碍于其管理。另外, 借助特征存储, 能够挑选历史沉淀下来的特征, 以此快速生成训练数据, 用以训练不同的模型。特征存储有着双重作用, 它本是对特征工程创建的特征予以存储的设施, 同时又是能让开发者实现特征复用的的贮藏设备。从本质而言, 特征存储当属众人共享、注释、发现及使用已处理数据的场所之处。具体的说, 它牵扯到两种不同的储存方式, 其一是低迟延的在线存储, 一般以Redis缓存的形态为模型服务供应最新且实时的特征其二是成本得以优化的离线存储, 用以存放支撑模型训练所需之过往数据。存在于当前市场之上深受欢迎的特征存储包括, Uber这个, Feast这般其中有Gojek还有, 以及。实验管理和模型管理实验管理, 于 ML 模型关键之处, 像迭代、版本化以及评估等类事件, 紧密相连, 模型管理, 同样与之紧密相关, 同时, 要保证有可重复性, 还得提供针对模型以及结果的可视化管理界面。存在对模型训练期间所产生的特定信息的管理工作, 这些特定信息包含变量, 包含特征, 包含属性, 包含评分, 包含性能指标, 包含历史版本, 还包含位置信息, 而这样的管理工作属于实验管理的范畴。与之相对的是, 对于训练这一活动, 以及创建这一行为, 还有部署这一举措, 再加上重新评估这一过程, 又再有重新训练这一操作, 另外发布到生产环境这一行动, 以及模型版本、标签和描述这类事件的管理之事, 通通都归属于模型管理的范畴之内。这些事件所具有的标签能够是注释, 像是项目, 还有用户, 并且包含时间戳, 以及有关原始值与更新值的详细信息。通常而言, 实验管理和模型管理的达成, 往往得把跟数据科学家工作流程有关联的那些元数据, 予以记录以及保存。这里面的记录和保存, 能够借助API的封装来达成。除了借助API与元数据集开展编程交互以外, 还得拥有前端界面的功能, 以此来达成可视化管理, 而在前端界面上开展操作产生以及检索的数据, 同样是借助上述API完成与后端数据库交互的。服务存在于一个更大系统里的独立单元是服务, 它能提出一些特定的功能。可将服务当作是构成一个系统的黑盒子。比如说, 一个在后端部位的大型媒体网站系统, 有可能是靠着若干一同给媒体网站使用者供应文章推荐的服务来构成的。在此其中, 给到一组关于一篇文章的统计内容, 被视作一个服务, 而另一个服务, 也许会启动被称作 ML—推荐服务的 ML 训练作业, 还会把训练好的模型给到一个对 ML 这种结果开展后处理的服务, 最终网站前端经由借助推荐服务获得针对推荐的结果。这些工作一般被称作服务, 每一个单独的服务都是很强烈地相互分离的。尽管不同企业所定义的服务标准是各不相同的, 然而依旧是存在共性的, 像下面所讲述的这样。服务应当是能够被复用的, 这对于MLOps平台而言格外有用, 举例来说, 特征存储的在线服务是能够被复用的, 它能够满足各异团队以及各异模型的使用需求。模型服务规模化于生产环境里, 在模型服务化阶段, 此阶段自服务化后所生成的服务称作模型推理服务或者预测服务, 其对应的API常常要应对大量的请求负载, 好多情况下单机难以满足需求, 存在诸多方法能够去扩展一个生产系统。第一种方法是垂直扩展, 该扩展指的是那种增加网络里单个节点容量的过程。若是那种模型服务早已在多个节点上面运行的情况, 它指的则是增加一部分网络, 或者整个网络的容量。垂直扩展有着一个主要的问题, 就是随着单个节点容量慢慢增加, 跟增加第二个类似那种规格的节点比起来, 它的成本会呈现非线性地去增加。垂直扩展通常属于首选的方法。一般而言, 通过这种方法进行扩展的时候, 是不需要去修改代码的。第二种办法是进行水平扩展, 也就是往网络里增加更多的节点, 在节点之间去分配容量。这种办法通常得引入负载均衡器, 这个负载均衡器会把一个给定的请求分流到一个有可能当下不忙的节点。同样, 这种办法在扩展之际也无需改变应用程序的代码。不过, 和垂直扩展相比较, 它会带来更多的复杂性, 原因在于要引入负载均衡器以及增大网络规模。还有其他多种方式可优化生产系统性能, 并非仅这两种扩展方式。常见方式为, 优化应用程序代码自身性能, 像找寻使代码片段处理更快的办法, 分批开展数据库调用, 规避不必要循环与嵌套, 以及将网络调用设为异步等。有时, 要在低延迟与准确性间寻得折中方案。运用这些方法调整模型服务后, 模型服务的响应会变快。还有, 为了对模型服务组成部分中的构件成本予以优化, 托管技术的挑选相当关键, 比方讲, 在容纳仪器当中使多个模型运行起来能够最大程度地将资源也就是中央处理器或者图形处理单元的内存加以运用, 进而处理推理方面的请求。那模型服务构件自身应当具备控制模型从产生到消亡整个过程的管理职能, 以便帮助版本推出运行下去也起到助力效用, 自动扩展属于应用机器学习基础建构及实现运营范畴当中一项关键的特质, 是用来满足高峰时间段需求以及削减非高峰时间段成本的。就好比啊, 针对长时间没接收到流量的模型, 能够灵活地减少对这个模型服务所需资源的分配比例。模型监控生产环境里头的模型, 能够在正常运维涵盖的范围之内运行, 借助监控组件的可视化指标予以观察, 当模型的运行表现出现变化之际, 要有持续训练机制被引入, 用以解决模型的漂移问题。之前讨论过, ML管道涵盖传入数据验证, 该验证是管道中一个独立任务, 还有模型评估, 这也是管道里单独的任务, 以及推理请求监控, 同样是管道中的独立部分, 另外还有日志管理亦是管道中的独立任务。管道里每个如此独立的组件所产生的结果, 都得存储于中央存储之中, 目的在于保障模型生命周期实现可观察性。开发环境中经过验证以及评估的模型, 在被推送到生产环境之后, 其实时性能得由专门的监察模块予以跟踪, 用来保证对业务的影响朝着正向发展, 能够借助多种办法去监控运行中的模型服务以及预测行为, 理想的办法是, 记录模型服务被请求之际所做出的预测, 接着把它们跟后续业务系统运行进程里所观测到的用户反馈结果融合到一块, 最终评估运行中的模型性能是不是契合预期。
![可白嫖源码---课程设计--毕业设计--springboot高校学科竞赛管理系统[编号：project18952]（案例分析）](http://pic.xiahunao.cn/yaotu/可白嫖源码---课程设计--毕业设计--springboot高校学科竞赛管理系统[编号：project18952]（案例分析）)
