端计算Walle:2235亿次运算,为了无法计算的端智能价值

端计算Walle:2235亿次运算,为了无法计算的端智能价值

本文知识点提炼:

1、端计算在移动设备上的应用探索
2、技术方案与核心模块设计
3、总结与展望

背景

传统的云计算,使用的是端侧采集数据,云端处理消费,再反馈给端侧的模式。而伴随着数字化转型的浪潮、万物互联时代的到来,5G、大数据、人工智能等信息技术的快速发展,云计算已经无法特定场景对低延迟的高要求。此时基于路由器、交换机、基站等计算节点的边缘计算因运而生,其具有低延时、低成本、数据安全、数据丰富等特点。

而借鉴边缘计算的思想,并融合手淘电商的业务场景,我们在18年初提出并搭建了基于移动设备的第一代 端计算工程系统 DAI 。其基于 TensorFlow 的模型推理能力,将计算、决策前置到移动终端,获取最原始的数据,实时在端侧进行数据分析与决策,端到端的响应耗时可以做到百毫秒级别。同时将过滤后的数据传输上云,与云端形成协同效应,并减少服务端的带宽、运算成本。

18 年双十一期间,端计算在部分场景小范围尝试和落地,并在主会场的猜你喜欢,详情页的看了又看等业务上取得了不错的效果。

端计算Walle:2235亿次运算,为了无法计算的端智能价值

端计算DAI架构图

面临的挑战

今年我们加大投入,并联合了算法团队、搜索推荐工程团队、手淘基础链路团队,共建端计算的工程体系。随着端计算体系承载的业务数量与复杂度的快速增加,也对 DAI 等基础设施提出来了更多更严峻的挑战。

▐ 研发效率

初期的设计是算法同学通过控制台下发 TensorFlow 的 pb(protobuffer) 模型文件,所有的逻辑均在 pb 的网络结构中实现。这种模式下,存在如下一些不足的地方。

由于端侧集成的为精简版 TF Mobile ,算法同学编写的TF代码在端侧可能存在缺少算子而跑失败的情况。

新增或修改 Op 需要 Native 发版实现,周期长。

if、for 等流程控制在TF中难以处理。

TF 的端侧推理耗时较长,业务决策响应不及时。

▐ 稳定性

Android 出于包大小和动态性的考虑,采用了动态下发并加载动态库的模式。但是由于 Android 设备的碎片化,动态加载存在着诸多兼容性的问题,测试也不好验证。同时 JavaScriptCore 本身在 iOS 上是个黑盒,曾在 iOS9 上就出现过大量的 JavaScriptCore 的 Crash 问题。而端计算作为算法处理的基础设施,每日被调用的次数非常庞大。所以任何一个极小的不稳定因素,都有可能被放大。

并且端侧的故障,大部分是由于线上配置发布引起的。手淘对于线上变更有着严格的安全生产流程,涉及发布窗口、验证、灰度、观察等各个环节。而算法同学往往对端侧的指标不熟悉,一些潜在风险未必能及时发现。我们需要在各个环节加强完善设施能力,在风险发生前及时暴露,在发生中将影响减至最低。

▐ 任务治理

在年初的时候,我们进行了一次线上业务梳理。发现手淘环境中有5+的特征提取任务、4+的曝光任务。很多基础的数据特征,在不同的业务场景下都需要使用到,且对于同一特征的加工方式往往相识。若所有的特征均由各业务方自行进行加工,难免会造成开发成本及端上计算成本的浪费。而且无法高效地将已有能力复用到更多业务和App上。

▐ 场景覆盖

在端计算模式快速发展中,我们关注到部分业务域虽然不具备算法资源,但是希望借鉴端计算的思路,在一些输入因素相对比较固定的场景下,对用户特定的行为进行快速的响应与干预。同时初期 DAI 的触达能力比较单一,仅将执行结果以广播的方式通知到业务方,由业务方自行实现通知后的触达响应逻辑。而一些常规的触达途径,在大部分业务域都是相识的。比如Push、Poplayer(浮窗)、触发其他模型任务联动等。在这个环节需要有一套统一的多样的触达机制,满足不同场景不同定制。

端计算2.0 Walle

基于上述问题,我们对 DAI 进行了全面的升级,并改名为 Walle 。希望如电影 Walle 一样,将被遗忘在端上的数据汇集起来,成为挖掘金矿的工厂。

▐ 架构设计

端计算Walle:2235亿次运算,为了无法计算的端智能价值

Walle架构图

整体设计上,Walle 由端、云两部分组成。

端侧包括采集层、计算层、触达层三个模块。采集层对接了端侧不同的数据源,进行数据存储与特征加工。计算层内置了 MNN、AliML 等。所有模型任务经过调度系统后会在计算容器中进行实时的决策。决策结果经由触达层的多种途径触达用户。

云侧分为运维平台、数据服务、触达服务三部分。运维平台负责日常的运维监控、数据服务为云端协同提供通道支撑、触达服务配合端上的触达层,进行人群圈定和事件分发。

▐ 解决思路

更高效易用的计算容器

为了解决算法模型的迭代部署效率,我们需要一套脚本语言环境来承载复杂控制与业务定制化逻辑。基于新版的计算容器,大幅降低算法同学的认知与学习成本,无缝衔接服务端算法应用流程,极大提升部署与迭代效率。

同时我们使用自研的轻量级深度学习引擎 MNN 替代 TF ,扩展了机器学习计算集 AliML ,集成了高性能时序数据库 ProtoDB ,为用户提供了一套低成本、高效、快速迭代的端侧模型预测与训练的执行环境。

端计算Walle:2235亿次运算,为了无法计算的端智能价值

计算容器

更夯实的稳定性保障措施

作为逐步大规模应用的端计算基础设施,稳定性可谓重中之重。我们对端计算的开发、发布、运行时、监控、降级等全链路进行了详细梳理,针对一些有风险的环节进行重点保障。

  • 开发测试阶段

代码覆盖率。在SDK中内置了代码覆盖率与性能热点的采集与上报功能。配合Jarvis平台的真机验证系统,可以在发布阶段更全面地度量真机验证的效果,将风险暴露在上线前。

Mock系统。为了实现自动化测试能力,我们开发了Mock系统。支持基于基线数据,对端计算任务的入参、出参、异常逻辑进行Mock验证。

  • 运行时

单机熔断。由于算法模型的迭代频率较高,为了避免在日常的迭代过程中引入新问题,我们在端侧引入了单机熔断的机制。既某个模型任务的执行耗时超过阈值或者执行线程卡死时,我们会重启执行线程,并对当前的模型任务进行一定时间段的熔断处理,以免影响其他模型任务的正常执行。

高危模块移除。移除了So动态加载、JS等存在潜在风险的模块,使用更优雅的方案替代。

疑难问题解决。端计算演进期间,我们攻克了诸多内存 Abort 、 Crash 、 多线程锁等疑难问题,整体Crash率有大幅降低。

  • 监控

调试工具。支持验证版本的生效配置,扫码拉取端侧日志,对任务异常进行实时调试排查。

监控大盘。面向App运维同学,可全局地观察整个端计算整体关键指标,以及每个任务的资源消耗排名,异常情况排名等。

任务报表。面向算法同学,包含全链路多维度监控,长尾报表等,可直观地实时反馈任务上线后的运行情况。

Crash定向监控。为了更准确实时地定位线上Crash问题,我们与Emas团队合作开发了模型Crash定向监控能力。在Emas平台上,现在可以直观地看到所有模型任务的Crash分布情况,以及Crash调用栈明细。

更体系化的数据能力

从共享端侧特征、降低重复计算与使用成本、提升特征查询效率等方面考虑,我们建立了端侧基础特征服务DBFS。基于基础特征分层抽象出了统计特征、用户画像、情景计算等高维业务特征,同时支持算法同学进行特征op的自定义扩展。DBFS目前提供100+个基础特征op,10+中间层业务特征op,涵盖电商场景最常用的点击、收藏、加购、下单等行为。

端计算Walle:2235亿次运算,为了无法计算的端智能价值

DBFS架构图

更丰富的场景覆盖能力

为了满足不同场景对端计算能力的诉求,我们建设了端计算的触达中心,其包含两部分能力:

  • 在端侧实现了一套简化的CEP(复杂事件处理)引擎,支持根据预置的规则序列,使用滑动窗口的模式匹配用户的操作行为,进行实时的用户干预。对于一些轻量化场景,可以直接使用CEP来定义行为,而无需引入机器学习模型。
  • 同时在触达层面,对接了奥格的人群系统,支持针对特定人群进行CEP规则或者模型任务的投放。在行为命中后的业务响应环节,我们统一扩展了Push、Poplayer、Broadcast、WalleTask、UT、NativeCallback等多种途径触达用户。

端计算Walle:2235亿次运算,为了无法计算的端智能价值

触达中心

总结

今年双十一期间,端计算首次在手淘大规模落地,覆盖主搜、信息流推荐、云主题、会场、智能Push、红包雨、促升、直播等场景。双十一当日共执行了2235亿次运算,在大幅提升GMV的同时,也为用户带来了更好的交互体验。同时除了手淘外,目前端计算也已在猫客、闲鱼、AE、CBU、零售通、优酷等App有成熟方案落地。

端计算的出现,填补了云计算在网络延时、数据丰富、隐私安全、算力成本方面的不足。而端计算与云计算也会以共存与互补的姿态,拥抱智能化浪潮。随着端计算体系的成熟以及基础设施的完善,相信未来算法同学们会有越来越多的创新项目孵化与应用,我们共同期待。

作者:李杰(兵长)

本文为阿里云原创内容,未经允许不得转载。