摘要：搭建这个平台最费时耗力的事莫过于对批、流作业的编排，作业组织治理以及任务调度了。然而这所有，用 DAYU 的数据开发性能几个工作可统统搞定。
大多数电商类企业都会搭建本人的个性化举荐零碎，利用本人领有的用户数据、商品数据、用户行为数据以及各种维度计算得来的标签画像计算用户偏好，举荐最佳商品给用户，最大化地促成交易。
一个典型的举荐零碎包含批处理计算、实时处理层、举荐利用 3 局部，是典型的 Lamda 架构。
搭建这个平台最费时耗力的事莫过于对批、流作业的编排，作业组织治理以及任务调度了。然而这所有，用 DAYU 的数据开发性能几个工作可统统搞定。当然，你可能会说，不是有专门的个性化举荐云服务吗，间接用它不香吗？这里咱们不较量举杠铃，如果企业还不具备利用各种举荐算法的能力，那间接花点钱买举荐服务是最佳抉择；然而你如果想最大化地、继续地优化举荐算法的成果，框架还是本人搭比拟靠谱。这里给一个例子，展现如何利用 DAYU 疾速实现一个简略的举荐零碎。除了 DAYU 的数据开发，还须要搭配华为云的 DLI、DIS、MRS-HBase。
首先介绍下 DAYU 开发的两种作业类型：
- 批作业
批作业只能被调度触发，工作执行一段时间必须完结，换句话说就是工作不能有限工夫继续运行。作业是多个算子（一个也能够）组成的 Pipeline，Pipeline 作为一个整体被调度。 - 实时作业
实时作业这个名字其实不精确，实际上它能够是一个流、批混合的作业，也能够是个纯实时流解决作业，也能够是个单纯的批作业。作业是由多个算子组成的 Pipeline，绝对批作业，实时作业中每个算子可独自被配置调度策略，而且算子启动的工作能够永不下线，这样就能够调度那些 always online 的 Flink、SparkStreaming 流解决作业。在实时作业里，带箭头的连线仅代表业务上的关系，而非工作执行流程，更不是数据流。
这个举荐零碎的后盾就应用实时作业来实现，一个流、批混合的作业，间接给个全景图：
这里涵盖了一个简略举荐零碎的次要计算流程。更多算法的工作流程这里没有齐全展现进去，例如基于模型的算法、基于深刻学习的举荐算法，也不蕴含各种举荐指标的计算过程，有趣味的同学能够百度学习。
整个工作中包含 9 组数据处理流程，6 个批作业流程，3 个实时作业：
批处理流程
从上到下，顺次计算：
1）基于个用户特色、标签计算举荐列表
周期：每天一次
计算：每天通过 CDM 从 RDS 抽取用户数据到 DLI，基于每个用户的根本信息，年龄、性别、职业、支出、地区等等各种属性信息，以及来自 360 度画像零碎的标签信息，生成举荐列表，保留到 HBase 中。
2）基于商品的相似性特色，计算举荐列表
周期：每天一次
计算：每天通过 CDM 从 RDS 抽取新增商品信息到 DLI，而后计算出来的基于商品类似特色的举荐列表，存入 HBase 中。
3）计算当天用户的偏好，生成日举荐列表
周期：每天一次
计算：通过 DIS dump 转储工作，把网站实时收集的用户行为信息转储到 OBS 中，通过一批 Spark 算法（批量的用户协同、商品协同、基于内容相似性、LR 等算法），基于一天的行为数据计算举荐列表。而后把列表推到 HBase 中。
4）计算本周用户的偏好，生成周举荐列表
周期：每天一次
计算：计算行为同上，区别是基于一周的行为数据计算举荐列表。
5）计算 3 个月内的偏好，生成长期偏好举荐列表
周期：每天一次
计算：计算行为同上，区别是基于 3 个月的行为数据计算举荐列表。
6）计算风行产品的列表
周期：每天或者数小时
计算：通过用户总体商品的点击、搜寻、评分等行为，基于 OBS 上用户的行为数据，按类别计算热门商品 Top50。这个列表也可作为补齐列表，当其余举荐列表还不足以填满网站的举荐位，能够用这个列表补齐。
实时流解决流程
1）实时计算用户偏好 –Item-Based 协同算法
计算：通过 Flink 工作对 DIS 用户行为通道的数据进行生产，先把用户行为日志转换为规范行为（Time,userid,ItemID,Score)，再通过流式 Item-Based 协同算法计算举荐列表，更新到 HBase 中。
2）实时计算用户偏好 –User-Based 协同算法
计算：同上，区别是应用流式 User-Based 协同算法计算举荐列表，更新到 HBase 中。
3）实时计算用户偏好 –Content-Based 算法
计算：同上，区别是应用流式 Content-Based 协同算法计算举荐列表，更新到 HBase 中。
以上一顿操作，在 HBase 中会有一堆以 UserID、Item 为 Key 的举荐列表，形如：
用户举荐列表后果：
userid_001:item100, item899, item 433, item 666,….
userid_002:item220, item334, item 720 item 666,….
userid_003:item728, item899, item 333, item 632,….
依据用户实时行为、历史行为不同周期，有若干组不同的举荐列表。
基于商品的举荐列表后果：
Item_0001: Item1000,Item333,time5213,…
Item_0002: Item1000,Item333,time5213,…
Item_0003: Item1000,Item333,time5213,…
另外，举荐零碎平台还须要一个提供 rest 接口的服务，供 web 网站举荐位调用。当用户关上网页时，主动向该服务申请以后用户的举荐列表，服务拜访 HBase，获取后面作业计算出来的多个举荐列表，并按肯定策略组合成一个举荐列表返回给网页，就此，实现了一个端到端的举荐业务流程。
一个残缺的举荐零碎要更简单一些，这里并没有探讨举荐零碎的专题内容。从例子能够看出 DAYU 具备弱小的编排和调度能力，单单一个工作就能够涵盖非常复杂的场景。实时上，大型的举荐零碎平台还是须要针对性的定制，因为波及到一些治理上的流程须要应答、闭环。不过基于华为云体系下各种平台、利用，有了 DAYU 这个助手，数据相干的方方面面的事务处理，将变得既简洁又高效。
本文分享自华为云社区《基于 DAYU 的实时作业开发，分分钟搭建企业个性化举荐平台》，原文作者：Loading…。
点击关注，第一工夫理解华为云陈腐技术~