共计 2806 个字符，预计需要花费 8 分钟才能阅读完成。
音讯推送作为用户促活的无效利器，具备低成本、高效率的显著劣势，已成为 App 经营中最重要的用户触达形式之一。为帮忙开发者有策略地晋升 音讯推送的成果，减少音讯的达到率和点击率，个推音讯推送 SDK 于今年初重磅上线了后效剖析性能，旨在为开发者和经营人员迷信调整推送策略提供无效撑持。
后效剖析性能上线后，咱们联合产品指标和用户倡议，进行了屡次迭代。本文就开发和迭代过程中积淀的教训与大家做分享，也欢送感兴趣的开发者们通过企业微信和咱们交换。
后效剖析性能的开发背景
音讯推送过程中，从服务端推送音讯、音讯达到客户端，到用户点击推送、关上利用的各阶段，都可能存在音讯折损的状况。
以往，音讯零碎通过简略比照下发、达到、展现、点击等四个维度的数据，来计算音讯的折损水平。但这样的音讯折损计算形式不够精确，经营人员较难深刻理解音讯的折损起因，也就无奈对推送参数、推送设置做出迷信无效的改良。此外，以往客户遇到音讯推送的问题时，会间接与技术支持人员分割解决，沟通和工夫老本较高。
因而，咱们须要设计出一种自动化形式，来帮忙开发者清晰理解推送音讯的各项后效数据，并可能自主、高效地找出音讯折损的起因。
后效剖析性能的开发思路
咱们的解决思路是：
1. 推出后效数据报表性能。通过将音讯在服务端下发过程中的折损状况以及客户端回执数据进行梳理、统计，造成各环节后效数据的清晰报表，以帮忙开发者和经营人员透过数据表象，疾速定位出音讯折损起因，找到晋升推送成果的关键环节。
2. 主动采集各推送模块日志并造成后效剖析报告。通过不同模块获取推送日志：以相似人工查问日志的形式，将一些含有起因标识的日志进行对立存储和梳理，从而梳理出某条工作下发时产生的所有异样和折损起因。这其中就蕴含“指标正处于黑名单”“申请受到频控（或流控）限度”等起因。与人工技术支持相比，这样不仅能进步后效剖析的效率，还能从一些以往可能被疏忽的折损中主动提炼出问题，帮忙用户自检并躲避一些使用不当的状况。
后效剖析性能的开发难点
在开发后效剖析性能的过程中，咱们也遇到了如下一些技术上的难点：
难点一：日志的聚合归类和后效起因提炼
在通过日志进行音讯折损起因排查和剖析的过程中，咱们首先须要从海量日志数据中筛选出无效的局部，并对该局部日志数据进行演绎，依据咱们事后设置的日志解析策略，对全链路的日志数据打上对应标记，以帮忙咱们剖析音讯在各阶段的折损起因。
为此，咱们对音讯推送的整个链路做了一次大梳理，从推送阶段动手，将推送模块辨别为入口层、解决层、下发层、客户端等四层，而后对各层可能存在的音讯折损起因进行了提炼：
✦在入口层，咱们次要关注服务端收到的申请内容是否通过格局校验，以及各类指标参数是否设置无误，比方“CID 是否无效”“鉴权信息是否异样”等。
✦在解决层，咱们关注指标客户端是否合乎下发条件，例如可能因为推送策略限度，导致服务端无奈给局部客户端进行后续推送。
✦在下发层，咱们关注客户端与服务端的网络连接是否失常，比方，在线通道是否无效等。
✦最终在客户端收到推送、用户点击音讯时，客户端也会将回执汇报到服务端模块。这一阶段的音讯折损起因可能是“告诉开关没有关上”等。
基于以上业务档次辨别，咱们能够更清晰地看到音讯推送的整体业务流程。咱们将各阶段可能存在的异样关注点提炼进去，以便于咱们梳理绝对应的日志模块。最终咱们将后效异样起因总结为 1 2 类，别离对应音讯推送各阶段中可能遇到的折损状况。
难点二：TB 级别日志数据的解决和精确计算
基于上述各场景，咱们筛选出相干日志，通过后期的标记来提炼音讯折损起因。
在一条音讯的下发过程中，服务端会产生大量日志，单个性能节点一天的日志量就能达到 TB 级别。如何对亿级别的日志进行过滤和计算，成为咱们进行后效数据分析的第一个难题。
咱们通过 Flume 传输日志，将日志数据写入到 HDFS，采纳 Spark 作为计算引擎，HDFS 存储原始日志数据和维度数据，最初的报表数据寄存在 ElasticSearch、Hbase 和 Mysql 中。
海量日志数据的荡涤和计算
依据对推送业务个性的理解，咱们总结出推送日志数据可能存在的问题如下：
✦ 日志反复。例如，用户一直地登录和登出服务，从而产生大量的反复日志。
✦ 申请反复。例如，用户屡次发动雷同申请，对某个客户端发送同一条音讯。客户端最终只会收到一次音讯并展现，但服务器会产生多条反复的客户端 / 音讯关联日志。
✦ 回执反复。上游回执中，因为客户端的网络环境简单，有时会呈现反复回执的状况，从而导致服务器反复打印回执日志
✦ 日志有余。比方，个别状况下，敞开告诉、设施沉闷等客户端信息，在推送流程中不会有日志产生，这就必须依赖相干数据作为补充，能力综合评估出客户端的状态信息。
针对以上问题，咱们提出的解决办法是“人群打标”。咱们依照推送流程对日志数据进行划分，将推送工作影响到的人群分为达到人群、下发人群、申请人群等三类。咱们依据音讯与客户端的关联状况，对客户端进行打标。例如当采集到“在线下发模块”日志时，如果其中蕴含某音讯与客户端的关联信息，那么咱们就会给该推送工作下的客户端打上胜利下发标记。每个标记只有 0 或 1，不同日志不会反复打标，如此就防止了日志反复统计的状况。
联合上述人群打标逻辑，咱们将四个维度的打标数据汇总，最终失去单个推送工作的原始数据。这份数据内，一个客户端会有多个标记，咱们只须要按过滤逻辑将这些标记整顿并演绎出最终状态，就可辨别该条音讯对这个客户端的下发流程最终到了哪一阶段，或是在哪一阶段因何种起因折损。
解决数据歪斜问题
在日志数据的计算过程中，咱们还遇到了数据歪斜的问题。
咱们依照音讯下发阶段将整个日志计算工作拆分成四个。依据推送漏斗，这四个工作之间存在上下游关系。在对指标维度进行聚合的时候，会呈现维度聚合体量差别过大导致数据歪斜的状况，甚至因为个别工作计算工夫过久拖慢整体的计算进度。
为了解决该问题，咱们须要在计算前和计算时对 Spark 工作进行解决，以缩小数据歪斜。
咱们采取的解决形式有：1. 将大文件宰割成小文件，或将小文件合并成大文件，以此保障每个工作解决的日志数据量平均；2. 优化分区策略，避免某个较大推送申请下的所有数据全副汇聚到同一节点，使节点计算压力更平衡；3. 优化工作的计算链路，保障以最优的计算链路实现数据处理。
至此，基于如上所述的日志数据处理和计算逻辑，咱们就能够在 HBase 中存储每条工作的后效数据，从而供业务层查问、调用。
总结
近期，咱们还引入了 Flink 流式计算引擎来晋升后效数据计算的实时性；咱们也联合了更多的音讯细则日志进一步欠缺数据，将后效数据报表降级，推出了音讯链路查问性能，借此来帮忙开发者更好地理解推送音讯下发状况，并依据对应倡议来疾速晋升音讯的整体达到率。
“码”上注册和登录个推开发者核心（https://dev.getui.com/），体验个推后效剖析性能和最新推出的音讯链路查问性能吧！