应用统计平台架构设计：智能预测APP统计数据

前言：近期，智能大数据服务商“个推”推出了应用统计产品“个数”，今天咱们就和你们来谈一谈个数实时统计与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时，可以正式把能力对外开放出来，帮助你们认识模型、使用模型，并享受模型带来的价值。