边缘计算:在客户端实现的推荐系统

边缘计算是一种分散式运算的架构,将应用程序、数据资料与服务的运算,由网络中心节点移往网络逻辑上的边缘节点来处理。边缘计算将原来完全由数据中心节点处理大型服务加以分解,切割成更小更容易管理的部分,分散到边缘节点去处理。边缘节点更接近于用户端设备,可以加快数据的处理和传输速度,减少延迟,提升效率。总得来说就是将计算任务在接近数据源的计算资源上运行,将运行的结果(或中间结果)再向中心节点传输。

本文介绍的这个案例发生在2012年,那时还没有边缘计算的概念(2016年)甚至 Hadoop 还没有火起来,严格意义上讲在项目初期并不是一个真正的边缘计算项目,在后来在大数据技术应用和发展的过程中,才真正构建成一个边缘计算模型。

作者当时所在的公司是一家房地产信息门户网站,因为所在部门比较闲,于是联系了老领导,希望能调动工作。老领导当时正负责管理公司整个后台,同意了我的调动申请,让我交接完工作下周一办理手续,具体工作另行安排。周一早上9点,找老领导签字时,他说目前正好有一件事找不到人,因为我之前做过几年搜索和数据中心的工作,希望我能负责。竞争对手上周二刚上线了一个“猜你喜欢”功能,就是推荐用户可能感兴趣的房源,希望我们也能快速上线一个类似的功能,让我出一个方案。一个小时后,办完了手续,还没安排好工位,正好又碰到老领导,随口来了一句:“方案有了吗?下午上班我们碰一下。” 当时我的心中是超级崩溃的,领导呀,我电脑还没开好吧。离下午1点钟还有两个小时,查资料也来不急了,做 PPT 也来不急了,甚至思考也来不急了,你又不能跟领导说我还没想好,这不是辜负领导的一片信任嘛,领导也有压力好吧。

如何快速实现一个推荐系统?因为做过几年数据,行业内的情况还有些了解,比如国外的 DoubleClick,国内的百分点,他们都是将用户的信息收集的服务器端,然后进行汇总计算后分析出用户可能的偏好再推荐给用户合适的商品。我打电话问领导,能给我几台服务器,领导回复说一台没有,只能将功能运行在业务系统上。我的内心又崩溃一次。

我已经忘了两个小时我是怎么过的,反正中午饭是肯定吃了,下午1点钟碰头时,我在白板上画出了我的方案。

方案有了,找开发,问领导,能给几个人呀,领导回答:你不就是开发吗?我....

开发过程还算顺利,因为主要涉及 Javascript 开发的数据存取处理,工作量不算大,3天后测试,周五下午正式上线。效果还不错,当用户搜索和浏览的房源越多时,推荐的房源越接近实际需求。冷启动(当用户第一次访问时)策略也比较简单,推荐用户关注度最高的那些房源即可。

这个方案本质上还不能称为“边缘计算”,因为它不会向云端发送计算完成的数据,只是在客户端保存数据并进行计算。这个推荐系统还有很多问题,如不能关联推荐,即其他用户的行为不能与当前用户行为进行关联;再如由于存储空间受限,不能存储太多的数据等。

下面再说一下之后的升级过程。

第一次升级。因为客户端 Cookie 数量和存储空间的限制,特别是对旧浏览器,全域 Cookie 限制20个,空间限制为4K,于是开始寻找更好的客户端存储方案。Flash ShareObject 进入我们的考虑范围,ShareObject 最大存储空间为100K。测试部门给出的数据是90%的用户浏览器均支持 Flash,所以这次升级计划就是将数据存储到 ShareObject 中。又问了一圈,没人会 ActionScript 3,还得自己上...

第二阶段,尝试将用户行为收集到服务器端。通过让 Javascript 访问一个静态网址,网址上附加各种用户行为参数,再通过 Nginx 收集这个网址的访问记录。然后再通过解析程序进行处理,将行为数据保存在数据库进行分析。但是没有实现与客户端进行交互。

第三阶段,尝试将客户端和服务器端收集的行为进行同步,一是为了数据更精准,二是即使用户清除了客户端数据,也能在服务器端找到用户的偏好。不出所料,这个系统没上线就崩了,即使加了一层 Redis,也没有通过压力测试。用户量大太了,每天百万级的独立用户,上万级的峰值并发,不是一台机器能承受得住的。

第四阶段,由于这个推荐系统要扩展到其他的业务,用户标签越来越多,必须找到更好的数据存储方式,Flash ShareObject已经不能满足需求。得益于 Html 5 的普及,特别是移动设备的浏览器已经几乎全部支持 Html 5,PC 端也有80%以上的用户浏览器支持。LocalStorage 最大能存储5M的数据,所有我们选择了 LocalStorage 作为推荐系统的存储技术。LocalStorage 彻底解决了客户端的数据存储问题,升级的同时,移动端WAP也上线了推荐产品。

第五阶段,已经到了2013年,发现数据库中已经存了十亿级别的用户行为汇总数据(还不是明细),查询分析已经变得非常困难,这时我们发现了 Hadoop。Hadoop 解决了大数据量下的存储和计算难题。用户行为分析项目独立成立团队,用户行为数据也为将来公司各种大数据的应用打下了基础。

第六阶段,公司的移动端 APP 用户行为数据开始收集,同时 APP 中也上线了推荐产品,点击率还不低。数据同样也先在 APP 端存储并计算,推荐时也不经过服务器端计算。由于 APP 端数据存储不受浏览器的限制,我们使用了 SQLite 为存储和汇总用户行为数据。

第七阶段,网页端、移动 WAP 和 移动 APP 三端打通,用户在任意一端访问的数据都可以在其他端同步并应用,推荐结果也更精准。

第八阶段,尝试分析用户的群体偏好,即群体行为也会影响推荐结果,如看了这个房源的用户还看了哪些房源。但由于这时实时计算还没有普及,群体行为只能每天计算一次,相对会滞后一些。

第九阶段,2016 年,实时计算技术已开始普及,Storm 技术应用到项目中,完全实现了整个推荐系统的实时化,延时基本可以控制在3秒以内。客户端进行数据计算,再实时将结果反馈给服务器端,服务器端综合用户的历史行为和群体行为偏好,实时推荐给用户合适的房源或其他产品。

到 2016 年末,推荐系统已经在公司网站和 APP 上占据了非常多的位置,公司把项目称为“千人千面”,即每个用户看到的内容都是不同的。

2020 年末的今天,回忆起当年设计开发推荐系统的经历,在当年有限的资源条件下,需要完成公司交待的任务,只能另辟蹊径,把计算和存储都放在客户端。在条件允许后,客户端计算并没有移除,而是先在客户端进行汇总和计算,只将计算结果发送给服务器端。这个项目可以说得上是一个边缘计算的应用案例。时代在发展,现在物联网终端设备性能越来越强,计算能力也越来越大,已经可以将很多计算在终端设置上执行,只与云端交互计算的结果,从而减轻云端的压力。


微信公众号
码农老吴  |  星源工作室  |  开发月志  |  问题反馈
联系我们:wu@qross.io     手机/微信:18618171102
京 ICP 备 20027445 号
$(h1)!