wordpress 名站,建设个人网站的好处,seo厂家电话,湛江优化网站排名本文知识点提炼#xff1a; 1、端计算在移动设备上的应用探索 2、技术方案与核心模块设计 3、总结与展望
背景
传统的云计算#xff0c;使用的是端侧采集数据#xff0c;云端处理消费#xff0c;再反馈给端侧的模式。而伴随着数字化转型的浪潮、万物互联时代的到来…
本文知识点提炼 1、端计算在移动设备上的应用探索 2、技术方案与核心模块设计 3、总结与展望
背景
传统的云计算使用的是端侧采集数据云端处理消费再反馈给端侧的模式。而伴随着数字化转型的浪潮、万物互联时代的到来5G、大数据、人工智能等信息技术的快速发展云计算已经无法特定场景对低延迟的高要求。此时基于路由器、交换机、基站等计算节点的边缘计算因运而生其具有低延时、低成本、数据安全、数据丰富等特点。
而借鉴边缘计算的思想并融合手淘电商的业务场景我们在18年初提出并搭建了基于移动设备的第一代 端计算工程系统 DAI 。其基于 TensorFlow 的模型推理能力将计算、决策前置到移动终端获取最原始的数据实时在端侧进行数据分析与决策端到端的响应耗时可以做到百毫秒级别。同时将过滤后的数据传输上云与云端形成协同效应并减少服务端的带宽、运算成本。
18 年双十一期间端计算在部分场景小范围尝试和落地并在主会场的猜你喜欢详情页的看了又看等业务上取得了不错的效果。 端计算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架构图
整体设计上Walle 由端、云两部分组成。
端侧包括采集层、计算层、触达层三个模块。采集层对接了端侧不同的数据源进行数据存储与特征加工。计算层内置了 MNN、AliML 等。所有模型任务经过调度系统后会在计算容器中进行实时的决策。决策结果经由触达层的多种途径触达用户。
云侧分为运维平台、数据服务、触达服务三部分。运维平台负责日常的运维监控、数据服务为云端协同提供通道支撑、触达服务配合端上的触达层进行人群圈定和事件分发。
▐ 解决思路
更高效易用的计算容器
为了解决算法模型的迭代部署效率我们需要一套脚本语言环境来承载复杂控制与业务定制化逻辑。基于新版的计算容器大幅降低算法同学的认知与学习成本无缝衔接服务端算法应用流程极大提升部署与迭代效率。
同时我们使用自研的轻量级深度学习引擎 MNN 替代 TF 扩展了机器学习计算集 AliML 集成了高性能时序数据库 ProtoDB 为用户提供了一套低成本、高效、快速迭代的端侧模型预测与训练的执行环境。 计算容器
更夯实的稳定性保障措施
作为逐步大规模应用的端计算基础设施稳定性可谓重中之重。我们对端计算的开发、发布、运行时、监控、降级等全链路进行了详细梳理针对一些有风险的环节进行重点保障。
开发测试阶段
代码覆盖率。在SDK中内置了代码覆盖率与性能热点的采集与上报功能。配合Jarvis平台的真机验证系统可以在发布阶段更全面地度量真机验证的效果将风险暴露在上线前。
Mock系统。为了实现自动化测试能力我们开发了Mock系统。支持基于基线数据对端计算任务的入参、出参、异常逻辑进行Mock验证。
运行时
单机熔断。由于算法模型的迭代频率较高为了避免在日常的迭代过程中引入新问题我们在端侧引入了单机熔断的机制。既某个模型任务的执行耗时超过阈值或者执行线程卡死时我们会重启执行线程并对当前的模型任务进行一定时间段的熔断处理以免影响其他模型任务的正常执行。
高危模块移除。移除了So动态加载、JS等存在潜在风险的模块使用更优雅的方案替代。
疑难问题解决。端计算演进期间我们攻克了诸多内存 Abort 、 Crash 、 多线程锁等疑难问题整体Crash率有大幅降低。
监控
调试工具。支持验证版本的生效配置扫码拉取端侧日志对任务异常进行实时调试排查。
监控大盘。面向App运维同学可全局地观察整个端计算整体关键指标以及每个任务的资源消耗排名异常情况排名等。
任务报表。面向算法同学包含全链路多维度监控长尾报表等可直观地实时反馈任务上线后的运行情况。
Crash定向监控。为了更准确实时地定位线上Crash问题我们与Emas团队合作开发了模型Crash定向监控能力。在Emas平台上现在可以直观地看到所有模型任务的Crash分布情况以及Crash调用栈明细。
更体系化的数据能力
从共享端侧特征、降低重复计算与使用成本、提升特征查询效率等方面考虑我们建立了端侧基础特征服务DBFS。基于基础特征分层抽象出了统计特征、用户画像、情景计算等高维业务特征同时支持算法同学进行特征op的自定义扩展。DBFS目前提供100个基础特征op10中间层业务特征op涵盖电商场景最常用的点击、收藏、加购、下单等行为。 DBFS架构图
更丰富的场景覆盖能力
为了满足不同场景对端计算能力的诉求我们建设了端计算的触达中心其包含两部分能力
在端侧实现了一套简化的CEP复杂事件处理引擎支持根据预置的规则序列使用滑动窗口的模式匹配用户的操作行为进行实时的用户干预。对于一些轻量化场景可以直接使用CEP来定义行为而无需引入机器学习模型。同时在触达层面对接了奥格的人群系统支持针对特定人群进行CEP规则或者模型任务的投放。在行为命中后的业务响应环节我们统一扩展了Push、Poplayer、Broadcast、WalleTask、UT、NativeCallback等多种途径触达用户。触达中心
总结
今年双十一期间端计算首次在手淘大规模落地覆盖主搜、信息流推荐、云主题、会场、智能Push、红包雨、促升、直播等场景。双十一当日共执行了2235亿次运算在大幅提升GMV的同时也为用户带来了更好的交互体验。同时除了手淘外目前端计算也已在猫客、闲鱼、AE、CBU、零售通、优酷等App有成熟方案落地。
端计算的出现填补了云计算在网络延时、数据丰富、隐私安全、算力成本方面的不足。而端计算与云计算也会以共存与互补的姿态拥抱智能化浪潮。随着端计算体系的成熟以及基础设施的完善相信未来算法同学们会有越来越多的创新项目孵化与应用我们共同期待。
原文链接 本文为阿里云原创内容未经允许不得转载。
