写在前面
互联发展近几年，所有火热的产品都会增加上算法赋能。怎么猜中客户心理，成为了产品用户增长必不可少的一环。那怎么为自家的算法业务赋能。就是这篇文章想探究的内容。「本文旨在讨论算法工程化共性的部分，无特指任何框架平台」
做好算法工程化意味着，建设一个AlgorithmComb平台。「自己瞎取的名字，如有雷同，纯属巧合，请不要代入任何框架与平台」
旨在提供一站式的服务，覆盖算力管理、算法模型策略配置、特征样例生成、特征样例回放、算法部署、压测诊断、AB实验、监控指标告警、算法效果评估的全流程，降低了算法工程师的使用门槛，帮助他们脱离繁琐的工程化开发，把有限的精力聚焦于业务和算法逻辑的迭代优化。
算法模型接入AlgorithmComb平台能有效解决算法迭代周期，预测算法迭代效果，通过平台赋能，整体提升算法迭代效率。
刀耕火种的烟囱模式
在算法云业务发展初期，为了支撑业务的快速发展，快速支持算法上线、快速试错，就简单的提供一些列的RESTFUL接口来调用算法任务，也就是我们所熟知的“烟囱模式”。此种模式各自为战，非常灵活，能够快速支持业务的个性化需求。但随着业务规模的逐渐扩大，这种“烟囱模式”的缺点就凸显了出来，主要表现在以下三个方面：
- 重复造轮子：特征模型数据获取和预处理、算法容器化冗余、AB实验等都是各自研发，从零做起。
- 平台化能力缺失：缺乏对特征数据、模型迭代上线的完整生命周期的平台化运维、管理、监控和追踪能力，研发效率低下。
- 算法与工程耦合严重：算法与工程边界模糊，耦合严重，相互制约，算法迭代效率低下。
“烟囱模式”在算法云业务发展早期做出了不可磨灭的贡献，但随着算法业务体量的增长，这种方式的边际收益逐渐降低到了不可忍受的程度，亟需一个统一的在线服务框架来进行改变。
刀耕火种的云算法平台（AlgorithmComb 1.0）如下图所示：
为了解决上述问题，为优化算法的迭代效率提供易用的算法平台，AlgorithmComb平台建设了统一的算法部署框架，通过整合模型计算和预处理/后处理等模块，弱约束出一系列抽象能力，免去了与算法与工程化之间复杂的交互。
工程化平台模式
针对AlgorithmComb 1.0 时代对算法、工程和平台三方高耦合的痛点，架构了新的AlgorithmComb 2.0框架，目标是解决算法、工程、AlgorithmComb平台三者耦合的问题，让算法迭代无需依赖工程发版，AlgorithmComb平台新功能上线无需影响工程化功能，进一步提升算法迭代效率和工程开发效率。
围绕解耦算法、工程和AlgorithmComb平台的目标，在AlgorithmComb 2.0框架中，设计了四个模块化平台用于实现工程化能力的闭环。包括：
AI算力平台：实现了对CPU/GPU等资源的统一调度和管理；提供显存隔离、算力隔离、异构资源支持等功能。
算法模型与发布平台：实现算法的策略高效调整，支持算法自主化迭代上线，同时提供错误特征数据回放、标准可用性测试、性能压测等能力的算法发布与验证平台。
模型数据管理平台：在算法计算的过程中会产生很多重要数据（算法策略、模型、特征、参数和数据通道等相关数据），这些数据不仅有助于快速排查定位系统问题，也为AB实验报告、错误回放和性能压测等模块提供了重要的数据基础，为了更好地自动记录、存储和使用这些数据，就有了模型数据管理平台。 算法任务运营平台：实现线上算法任务的运营，提供算法任务回放、日志、模型健康检测、性能压测以及算法线上效果报告等功能。
AlgorithmComb 2.0平台解耦了算法、工程和平台，实现了算法与工程迭代的各自闭环。大部分算法迭代的整个流程无需工程研发人员、测试工程师的参与，算法工程师在小时级即可完成算法策略的迭代上线；通过AlgorithmComb 2.0的赋能，算法的研发迭代效率得到了大幅提升。
AI算力平台
具体功能特性如下：
- 显存/算力中心化：可配置每个算法任务的显存/算力比，使得每个算法任务运行得更高效。
- 算法容器混合部署：算法结果无需上传，直接当前节点nas处理，为编发的算法提供更高效的环境。
- 异构资源支持：系统能同时使用多种GPU/CPU，这些系统通过增加不同的协处理器提高整体的性能或者资源的利用率。
- 算法与节点亲和度：可配置每个算法与GPU节点的亲和度，使得优先级高的算法任务更容易占领资源。
- 容器节点弹性伸缩：通过Prometheus Adapter适配Prometheus采集到的GPU指标，再利用Custom Metrics API来对HPA的指标进行扩展，从而根据GPU利用率、显存等指标进行弹性伸缩。
算法模型与发布平台
具体功能特性如下：
- 算法镜像化部署：封装默认算法模型alpine，算法模型一键生成docker镜像部署。
- 算法多版本参数：为了提供算法 模型不同版本的测试效率，提供自定义算法任务对应的模型版本。
- 标准可用性测试：为了验证迭代的算法正确性，提供线上标准样例进行回归测试，提高业务的稳定性。
- 错误特征样例回放：为了验证算法迭代的优化效率，提供标记的错误样例回放，提前对算法优化效果进行上线前评测。
- 算法编排：把具有独立输入输出的算法模型抽象为一个算子，通过串行或者并行的方式组合为一个有向无环图（DAG），形成了算子编排，为算法业务功能的多样性进一步赋能。
模型数据管理平台
具体功能特性如下：
- 特征数据抽取：算法计算过程中会有OOM等一系列的系统超限的数据，需要将此类数据进行特征抽取，提供给算法优化的能力。
- 错误数据标记：对于没有明确错误而失败的算法进行错误标记，提供算法优化回放功能埋点。
- 聚合收集存储：一次请求可能对应多次算法模型计算，会产生大量的中间或者结果态的数据，所以需要具备聚合收集存储能力，建议采取ES和HBase结合存储回放数据，其中ES存储关键索引字段，HBase存储完整数据记录，充分发挥二者的优势，同时满足了快速查询搜索和海量数据存储的要求。
- 算法性能统计：线上实时评估和校验困难，算法策略和算法模型的线上性能和效果评估困难，故引入此功能，通过错误码收集以及线上实时的es整理绘制图表。
- 算法数据通道：异构资源部署时，不同算法计算引擎互相调用或者算法计算引擎调用模型计算引擎，算法数据通道是实现算子编排的一种具体通信功能，类似golang的channel。
任务运营平台
具体功能特性如下：
- 算法模型效果分析：为了更好的统计算法一定时间内的效果，对于算法模型效果会以报告的形式在运营平台输出并赋能算法工程师迭代算法。
- 算法任务回放：对于线上 任务无法通过日志定位的问题，可以通过标记的算法任务输入数据进行测试环境回放，还原事故现场的功能。
- 算法任务日志聚合与持久化：为了方便分析算法效果及异常时排查问题，我们需要把算法任务计算过程中的输出日志记录下来，以便任务运行的pod异常退出都能快速高效的定位对应任务的运行状态以及问题。
- 算法模型健康检查：对于线上算法模型以及对应的算法策略
- 算法模型性能压测：压测功能实施的过程中记录算法在不同QPS场景下的性能表现，主要包括CPU和内存等应用指标，TP时延和超时率等响应耗时数据，并与线上真实性能、历史压测数据和服务承诺的SLA进行对比分析给出压测报告及优化指南，存在明显性能问题时将阻断算法包的上线流程。
工程化平台 AlgorithmComb 2.0建设成果
算法研发流程
通过AlgorithmComb 2.0的算法功能化平台能力，我们解耦了算法、工程，实现了算法与工程迭代的各自闭环，提升了研发效率，算法迭代上线周期大幅缩短：
- 当模型迭代、特征变更及算法策略迭代时，算法工程师可以自主完成全链路的开发测试，无需工程研发人员和测试工程师的介入；同时算法包可独立部署，无需任何服务上线，上线后周知到工程侧及产品方关注相关指标变化即可。
- 当新业务场景和新算法策略接入时，还需要算法和工程共同开发，定义好Protobuf接口之后，算法工程师和工程研发人员可以各自独立开发代码，各自上线。
通过使用AlgorithmComb 2.0的提供的「常规数据回放、优化样例回放、错误样例回放、性能压测诊断能力」等自动化能力工具，算法策略迭代的效率进一步提升，算法迭代上线周期大幅缩短，由天级别提升至小时级别。算法工程师自主开发，然后部署AlgorithmComb 2.0进行自测调试，部署进行「AB引流测试、灰度启用」等，通过模型管理平台评估效果性能，最后自主部署上线，整个流程无需工程研发人员的参与，达到自动运维的目标；同时通过各种手段保证算法策略的执行性能及AlgorithmComb 2.0的运行稳定性。
AlgorithmComb 2.0算法研发流程如下图所示：
总结及未来展望
当然，肯定没有完美的算法平台及算法工程化框架，AlgorithmComb 2.0还有很大的进步空间。随着对算法模型的持续探索，会有越来越多的应用场景需要AlgorithmComb 2.0支持，未来可以会在以下方面持续进行建设：
- 进一步抽象AlgorithmComb 2.0 平台化的能力，将「运算结果压缩、CDN部署输出」等平台业务通用能力抽象。
- 建设AlgorithmComb 2.0自动化运维工具和自动化测试工具，支持算法半自动化开发，进一步降低平台接入成本和运维成本。
- 推进AlgorithmComb 2.0全图化引擎的建设，通过抽象算法业务的通用组件，提供图形化流程编排工具和图执行引擎，为业务上线和算法迭代进一步赋能，进一步提升迭代效率。
