作者董霖,个推高级技术总监。
前言:近期,智能大数据服务商“个推”推出了应用统计产品“个数”,今天我们就和大家来谈一谈个数实时统计与AI数据智能平台整合架构设计。
很多人可能好奇,拥有数百亿SDK的个推,专注消息推送服务多年,现在为什么要做应用统计?毕竟市面上已经有非常多的类似产品了。我认为答案是“天时地利人和”。
首先是天时。目前,互联网行业已发展到了所谓的“下半场”甚至是“加时赛”,运营工作走向精细化,DAU和效果被放到第一位,从业者们也逐步认识到数据优化及使用良好的模型的重要性。
其二是地利。个推经过多年的积累,拥有了坚实的数据基础;另外,个推基础架构也非常成熟,并在诸多垂直领域实实在在提供了很多数据服务。
第三是人和。内部的研发人员在实战中积累了丰富的经验,公司与外部应用开发者和合作伙伴建立了长期紧密的联系。
正是在这样的背景下,我们推出了这一款应用统计产品“个数”。
前段时间流行的词汇是“growth hacker”,而现阶段,单纯的用户增长已经无法满足发展,公司及产品的思考点都在于“效果”。相比于其他统计产品,个数产品的灵魂是运营,即围绕着核心KPI,保持应用的活跃度,提高整体的收益。
安全、准确、灵活的数据能够保证运营工作的有效开展;而承载数据的平台则需做到高并发、高可用、高实时;SDK作为基础,其核心在于包的体积足够小,并且集成方便,能够快速运行。这样一个从上到下的金字塔,构建起了个数产品。
四大核心能力,打造智能化统计
首先,实时的多维统计是整个应用统计的基础功能。其中,稳定与实时是两大关键;在颗粒度方面,页面级统计最适合运营者。
第二部分是数据整合。利用个推的大数据能力,我们能够提供独特的第三方视角,帮助应用认清自身,并找到它在行业内的地位。
第三部分是自动建模预测。这是个数非常独特的功能点。我们希望通过一整套解决方案,帮助应用开发者真正体验到模型的价值,并通过实际数据反馈,不断优化改进产品。
第四部分是精准推送。个推最广为人知的能力就是推送服务,而将应用内的统计数据与推送系统有效整合,能够辅助更加精细化的运营。
技术架构:业务域+数据域
个数的整体架构分为业务域与数据域。其中,数据域分为三个层面:数据网关层、数据业务层和数据平台层。
数据网关层主要做业务层与数据层之间的承载,包括Kafka集群与API网关,使得上下数据互通。数据业务层部分主要基于特定业务的研发工作,由于这部分工作不在平台间通用,因而是独立的一层。在这一层下,产品根据功能的不同配置了若干个独立的Hadoop集群,同时把核心能力包装成公共服务,提供给业务研发人员使用。
业务域部分包括了传统的微服务及相应的存储模块。
第一,这两层之间的数据防火墙非常重要,二级数据防火墙可确保系统内部数据的有效隔离。
第二,数据域的分层。对此,个数架构上设立的三层对应三个不同的职能团队,数据网管层—数据运维,数据业务层—业务线的研发团队,数据平台层—数据部门,这样的职能划分可以有效提升业务线产品研发效率。
第三,集群资源的隔离。业务线的开放集群需要通过资源划分的方式,实现资源的隔离。此外,隔离GPU计算集群资源也是非常有必要的。
第四,实时与离线的兼顾。在开发时,无论是何种产品,我们始终需要把实时和离线两种情况考虑在内。
最后,数据储存。业务线、数据层、平台层都要有相应的数据储存。此外,应通过合理的规划,确保每一类数据存放在合适的位置。
实时多维统计架构解析
Mobile API从SDK收集到上报的数据,以文件形式Log保存下来,通过Flume进入到Kafka,接下来通过实时与离线两条路进行处理,最后通过数据API封装提供给上层的业务系统使用。
在离线统计方面,个数可支持到小时级别。同时,我们会全流程监控数据的流转情况,当出现数据丢失或者延迟等情况时,确保第一时间监测到。
在这里需要补充几个关键的、需要解决的点:用户去重、页面的唯一性标识、多维度统计的处理策略,以及保证数据在各个环节中不丢失。
数据整合,提供多维指标
个推拥有强大的大数据能力,可以为应用统计产品提供丰富的数据维度。
首先,设备指纹。目前移动设备存在兼容性混乱等问题,个推则通过为应用打上唯一的设备ID标识来解决这个问题。
第二,以第三方视角提供应用留存、安装、卸载,活跃等中立的分析数据。
第三,用户画像。无论是性别、年龄段等静态标签,还是兴趣爱好等标签,都可通过个推的大数据平台获得。
自动建模预测&模型评估
一个标准化的建模工作大体包含以下几个步骤:首先选取一批正负样本用户;然后对其进行特征补全,把无关特征进行降维操作;之后,选择合适的模型进行训练,这也是一个非常消耗CPU的过程;接下来是目标预测,我们需要整理或补齐目标用户的所有特征,再将数据投入模型中,获得预测结果;最后是模型评估。模型评估之后,再进行下一个迭代调整,循环往复。
在建模环节,实时性是需要考虑的重要因素之一。最传统的离线训练是很常规的建模方式。预测可以选择高性能的离线方式,但它的缺点是反馈太慢,有可能导致结果出来之前没有其他的机会实施运营方案,因而我们需要提供更实时的预测功能。比如用户新安装或完成某个操作之后,系统实时获得预测结果,并立即进行运营干预。
最后是实时训练,从我个人的角度来看,这是未来发展的一个方向。
对于整个建模的基础架构,毫无疑问我们选择了tensorflow,目前主流的模型都可以在tensorflow下实现。它拥有诸多优点:支持分布式部署,可并发、集成扩展,可支撑集群Serving,能够以API形式提供模型服务……因而它非常适合预测服务的技术架构。
离线建模过程如下:数据落到HDFS之后,先通过Azkaban进行任务调度,数据清洗后把应用内的统计数据收集汇总,接下来将个推拥有的大数据能力与之进行整合,形成整体的数据Cube输入到TF集群,TF集群会根据预测事件的配置,综合进行模型训练,最后输出结果。
目标预测实现方案相对简单,只需要把模型导入到tensorflow的Serving集群即可。预测结果再通过DAPI封装出来,给到上层业务层调用。
目标预测首先要进行特征补全。这项工作极富挑战,需要针对每一个新用户的要求尽快预测并完美地补全特征。
第二部分是预测结果。预测最终得到的是概率值,我们需要去评估概率值是否处在合理范围内,概率分布是否符合我们的预期。如果不达标,我们就需要重新评估这个模型,或者认为预测是失效的。
第三部分是tensorflow集群。通过容器化部署,可以将预测服务部署到独立的Pod上。根据不同的实时性要求,个数可通过API的形式提供对外服务,也可以提供实时回调。
模型评估是预测的关键步骤,评价体系不完备可能直接导致最后的结果不可用。
精准率与召回率,这两个与预测准确度相关的基础指标是需要重点关注的。由于精确度与阈值相关,我们也支持开发者自主调整。
Lift也是一项重要指标,它反映了我们的预测能够产生多大的效果提升。显而易见,筛选的人群比例越大,提升的比例会逐渐递减。具体应用的时候,我们需要根据场景或需求来选择一个合理的值。
ROC与AOC,这两个指标作为模型整体评估指标,用于评估在不同阈值下模型的表现。为提升模型的区分能力,我们势必会追求AOC最大化。AOC值是一个定量的指标,适合做模型的持续监控。此外,对模型做每日评估也是必要的,如果AOC值不能够达到预期,我们可以及时选择其他模型。
在监控方面,首先要确保测试用户的选择足够随机。我们每天会选择一批测试用户来验证模型的效果,然后评估准确率、召回率以及AOC。除了内部校验,我们也会把这个指标提供给开发者。同时,缓存预测结果的历史数据,可以辅助每天的效果评估。
精准推送集成,增能实际场景
应用内埋点数据和预测结果可以通过个数传递到推送系统,方便开发者在推送环节直接以人群包的形式选择目标用户,或者下载这个人群包,上传到广点通等平台做广告投放。
个数Roadmap
个数产品在5月份已经正式对外开放,大家可以在http://www.getui.com/cn/geshu.html 自由注册并使用。模型预测功能目前处于测试阶段,我们希望到Q4时,能够正式把能力对外开放出来,帮助大家认识模型、使用模型,并享受模型带来的价值。
转载于:https://blog.51cto.com/13031991/2129820