作者：jackhuali 腾讯PCG工程师
|导语 灯塔SDK当前的日活终端设备数超过10亿，日事件上报量超过万亿条，灯塔SDK是什么，灯塔SDK做了哪些工作来支撑如此大业务需求的呢？灯塔SDK是怎么保障业务客户端事件数据上报的准确性的呢？带着问题我们接下来一步步进行拆解。
灯塔SDK从2011年左右诞生至今，并随着PCG数据治理地持续推进，灯塔SDK逐步被各个业务线所深度使用，灯塔SDK逐渐收敛其余上报通道，成为了公司级统一的数据上报通道。
以下总结了大家日常对灯塔SDK集成、测试、数据验证等使用过程中的一些问题，主要是这三类：
1、what，是什么，灯塔SDK是什么，在数据治理中扮演什么角色。
2、why，为什么，为什么业务线需要使用灯塔SDK，灯塔SDK可以解决哪些问题。
3、how，怎么做，灯塔SDK做了什么，核心功能、架构和流程是什么，如何进行数据治理。
本文将围绕灯塔SDK是什么、为什么、怎么做这三大类问题，对灯塔SDK进行偏向于技术方向的整体介绍。
灯塔SDK是什么
简介
数据在互联网业务的重要性至关重要，经典的数据生成到消费流程如下：
数据的上报，是整个大数据链路中，介于数据采集和后台数据存储分析的桥梁，完整高效的数据采集和上报是至关重要的环节，规范的采集和及时且不丢失的数据上报是保证数据质量的前提，而灯塔SDK所做的事情就是将业务客户端埋点采集的数据高效不丢失地上报至后台。
基于PCG数据治理的背景下，目前PCG的数据采集上报及消费建立了统一的规范和工具，规范的业务客户端数据采集及上报流向如下：
- 通过大同SDK采集的规范事件，直接自动默认通过灯塔SDK上报到灯塔日志接收后台；业务自定义上报的事件也通过灯塔sdk上报到灯塔日志接收后台；
- 灯塔日志接收后台调用阿塔API将数据转换成AttaID通过阿塔系统传输；
- 阿塔将数据分发到灯塔的敏捷分析平台，在灯塔上可以配置和查看数据分析报表；
- 如果数据需要在tdw上使用，阿塔可以将数据分发到tdbank，由tdbank入库到tdw上使用；
- 如果业务需要接出数据到自己的业务系统，也可以通过阿塔、CDMQ接出消费。
我们可以从上述流程，并结合腾讯在大数据各个链路的现有系统上，理解灯塔SDK在整个大数据链路的位置。
从数据流向的角度看，
从整个大数据系统架构的角度看，
可以看到，灯塔SDK是大数据链路中的基础，直接集成在业务客户端的作为数据上报的入口，
- 业务客户端负责基于代码埋点、可视化埋点或者无埋点方案采集业务需求的数据；
- 然后将数据透传给集成的灯塔SDK；
- 灯塔SDK会将数据保证不丢失地情况下，快速地上报给灯塔后台的日志接收服务。
基于上述流程定义，灯塔SDK是腾讯通用的客户端用户行为事件（数据源）上报通道，带有本地缓存、失败重试，旁路监控等功能来保证日志安全可靠地上报至后端。
使用灯塔SDK上报日志，可以无缝使用灯塔敏捷分析、灯塔可视化DataTalk等功能，以及将数据接出至业务的系统进行消费，建立用户画像、建立标签、进行AB实验分析、智能推荐等。
支撑的业务
在数据治理的背景下，灯塔SDK是PCG全部业务客户端的标准统一数据上报通道，公司内外使用灯塔SDK的活跃的APP数量有数千个，目前的服务业务包括：
- PCG内部业务，手Q、微视、看点、QQ浏览器、腾讯视频、腾讯新闻、腾讯动漫等PCG绝大部分业务；
- 公司内兄弟BG，IEG、TME、WXG和CSIG等，如企业微信、QQ邮箱、王者荣耀、王者营地、QQ音乐、全名K歌、开心鼠英语、腾讯会议等业务；
- 兄弟公司或者其他公司业务，如斗鱼直播、阅文等等。
相关平台的关系
与灯塔SDK上下游相关的一些常用工具平台或SDK，如大同SDK、MTA上报、boss平台等，简单梳理他们之间的关系如下：
- Mta上报：teg数据平台部提供，已经准备下线，建议使用灯塔sdk代替；
- BOSS平台：从上报角度看，主要指boss的蜂巢系统，目前已经整合到阿塔系统，所有数据的使用传输管理等都在阿塔系统，boss的上报功能建议使用灯塔SDK代替；
- 大同SDK：是PCG数据治理产生的采集规范产品，用于做数据采集的规范治理，目的在统一采集能力，包括自动化采集、数据采集规范等，采集后的数据通过灯塔SDK上报；
- 阿塔atta平台：整合了原BOSS蜂巢、罗盘DC、消息通道等三个数据上报通道系统，是一个数据上报、传输、分发的数据通道系统，其中上报功能可以使用灯塔SDK替代；
- Aegis、TAM、007：主要是致力于业务客户端相关的监控上报及多维监控分析系统，一站式发现问题，定位问题，分析问题;
- Athena：一站式用户行为分析平台，包括SDK无埋点采集、上传及后台分析系统，主要聚焦提供界用户操作轨迹、界面热力图、界面漏斗流等用户行为分析服务。
更多各平台间详细关系参考下图。
Logging、Metrics和Tracing
在开发过程中，很多同学是否偶尔也会搞混所谓的日志采集上报平台、监控采集上报分析平台和链路追踪平台，他们之间似乎都有很多相似性又有所区别，而这些系统之间似乎又耦合或者有和灯塔SDK类似的一部分能力。为了弄清楚这些系统间的关系，我们来看韦恩关系图：
很明显他们之间确实是有所部分重叠的功能，但这些系统关注的领域和特点是不一样的。
- 日志系统，是对我们应用或者系统事件做一个记录，这些记录是我们问题排查，取证的一些依据；公司内的如鹰眼日志系统、腾讯云日志服务CLS和智研日志系统；
- 度量系统，是对某些我们关注事件的聚合，当达到一定指标我们会设置告警，会设置自适应机制，会有容灾等等；公司内如007监控、Aegis、TAM等系统都属于这个范畴；
- 追踪系统，更关注请求的质量和服务可行性，是我们优化系统，排查问题的高阶方法，在当前火热的微服务架构中是必不可少的基础组件；公司内如天机阁；
- 灯塔SDK的上报，更专注于APP客户端的业务事件和用户行为事件的上报，将事件上报至后台并存储、分发，进一步运用在业务分析、智能运营和推荐等。本质上，灯塔SDK结合灯塔分析平台，是有作为日志logging系统和Metric监控系统使用的简单能力，但这不是灯塔SDK专注和推荐的。
为什么使用灯塔SDK
可以解决哪些问题
业务线为什么要使用灯塔SDK？它可以解决哪些痛点？
相信在任何一款互联网产品上线前或者运营过程中，肯定都需要考虑怎么去度量产品上线后的运营情况，包括DAU、留存、收益等等情况，对于开发、产品、运营和数据的同学，可能都遇到如下类似的问题：
- 埋点的数据不准确，突然某个版本上线之后，数据少了、多了、慢了，无法追踪原因；数据上报缺乏专门的策略调优和错误监控，难以保证上报数据的质量；
- 线上的网络、用户行为、业务间相互影响等情况复杂，业务自己上报数据可能会导致数据丢失或者及时性低，也无法衡量埋点数据的准确性，无法自我验证数据的可靠性；
- 埋点错埋、漏埋、多埋，开发埋点的数据无法进行实时校验；
- 一个APP里面包含的业务非常多，希望将各个业务的数据进行隔离，业务自己上报的话，管理复杂；
- 业务有多个端的APP，包括Android、iOS、小程序、flutter、H5、PC端等，如果自己去上报数据，各端实现成本高且难以统一标准；
- 监管越来越严格的情况下，没有可以使用的统一设备ID，导致数据间的串联分析、广告追踪等出现短路；
- 推过一些规范，没有专人维护和质量监控，过一段时间又回到原始状态；
- 基于错误的数据得出错误的结论，基于错误的结论做了错误的行动。
正所谓，数据的质量，决定了数据价值的上限！没有好的数据治理，无法保证好的数据质量！数据治理，需要统一的采集方案，统一的上报链路，灯塔SDK正是专注于解决这些问题的推出的统一上报通道方案。
支持的平台及能力
- 支持各个平台的事件上报功能，并且在一个业务客户端里支持不同的业务使用不同的appkey进行上报，Android和iOS平台支持事件的立即上报，对于高实时的场景如推荐应用的事件可以采用立即上报的功能；
- 支持大部分平台的事件统计机制，可以准确衡量事件上报的丢失情况，事件上报的延迟情况等；支持灯塔SDK自我数据置信度的监控验证，可以验证自我上报率和及时率等数据的可靠性；
- 自带设备ID插件能力、稽核插件能力和AB使用插件能力；
- Android、iOS和Mac平台支持海外业务上报事件数据到海外的服务器；
- 支持远程配置服务，可以进行策略及开关能力的远程下发，如远程关闭某些敏感信息的采集或者调整上报的策略等；
- 建立了专门的实时联调验证平台，提供给业务进行数据上报是否成功及准确性的验证，支持各个平台的事件数据上报后进行实时联调，开发测试同学可以实时验证数据上报的准确性，实时联调平台；
- 支持SDK运行过程中自身的错误监控，可以实时监控线上SDK运行的情况，结合灯塔分析平台，可以分析错误的趋势，错误的详细日志，捞取错误的用户的在线日志，捞取异常用户的日志流水分析等等手段；
- 支持开发调试过程中设置严苛模式下，可以自检SDK使用过程中的一些致命错误，如参数设置错误，未初始化SDK等；
- 支持对线上运行的SDK，捞取线上出现bug用户的第一现场运行日志，进行bug归因分析；
除SDK上述自身的能力，还可以结合灯塔分析平台，捞取线上低上报率的用户分析，进一步针对低上报率的用户拉取其日志明细分析等。灯塔SDK在开发和推广过程中，已经积累和具备了较为完善的业务功能及监控运维可能。
灯塔SDK做了什么
灯塔SDK当前的日活终端设备数超过10亿，日事件上报量超过万亿条，在终端高并发（对于终端设备来说，秒级数十条甚至百级别的事件产生频率，是属于比较高并发的场景）及复杂的网络环境下，要如何将如此高频率的事件集快速地传输至后台是需要解决的最主要问题。
了解灯塔SDK的基本情况之后，我们是否好奇，灯塔SDK是如何做到支撑如此巨大业务需求的呢？灯塔SDK是怎么保障业务客户端事件数据上报的准确性的呢？带着问题我们接下来一步步进行拆解。
模块架构
灯塔SDK在4.0版本开始对整个技术架构做了重构，以模块化的方式分层拆分了各个模块，在代码层面和监控运维层面提升了SDK的稳定性和增加线上问题排查的手段。
可以看到，灯塔SDK团队在架构的设计层面，按照一个APP的基本标准进行设计，完善了SDK从开发到监控运营层面的基础能力。并且灯塔SDK在架构设计层面，保留了充分的扩展性支持，收敛了旧SDK无法弹性扩展新能力的接口设计，充分抽象了灯塔SDK需要关注的主体“事件”这个对象模型，为后续的新事件类型、新上报策略和新上报需求预留了自由扩展的空间。
灯塔SDK怎么提升上报成功率
对于客户端事件采集后上报到后台的通道，上报的成功率是SDK关注的北极星指标，为了提升指标的成功率，我们首先来看下业界都有哪些方案。
大体来说，都是先入库再发送，先保证上报率再保证及时率，每个SDK的发送策略有些区别。相对于业界的SDK，灯塔SDK增加了更多的数据可靠性验证和保证的策略，增加了更多精细化的上报策略及错误监控，提供更加精细化的事件类型区分和专门的上报策略控制等。
精细化上报策略
先来看下图灯塔SDK的基本上报策略逻辑，大致的逻辑以保证事件不丢失为基本目标，并在此基础上优先保证上报的成功率，其次是上报的及时率。所以SDK采用的基本策略是，除需立即上报进行即刻消费的事件外，其余事件均是优先入db存储，并使用各自的轮询定时器进行累加地多线程并发上报。
当然，灯塔SDK内部包含了更多的精细化的处理策略，比如对于数据存取db的并发队列控制和上报并发队列的控制，以在在性能和上报及时率上找到均衡点；为了保证上报成功率统计准确性，对事件在db的存取进行后入先出的策略控制；对轮询定时器的间隔在server端的接收能力、客户端的网络带宽占用和内存、CPU性能等间保证均衡最优等。
建立指标度量体系
有了策略之后，灯塔SDK在业务侧集成上线之后，究竟怎么去衡量灯塔SDK的上报质量呢，业界的很多SDK会默认信任上报发送的准确性，不去衡量丢失和发送失败的统计，这对于很多精细化运营的业务以及需要准备数据质量的后续数据链路来说，这样的数据源是不可靠的。灯塔SDK为此，专门建立了相关的度量指标。
事件唯一标识LogID
对于灯塔SDK来说，衡量业务上报的事件流的质量，需要对每条事件进行唯一标识的标记，需要满足以下的特征：
- 唯一性：最基本的要求，需要满足单设备下APP级别里区分业务维度的ID唯一性，不能出现重复的ID号，便于业务间统计问题隔离和上报质量的区分；
- 整形离散化：为便于对基于时间递增的事件流的统计拆分，需要数学意义上的整形进行离散化，基于此容易对事件进行统计和缺失事件的分析；
- 单调递增：需满足统计过程中衡量事件流的连续性及单调性，为便于常规统计，保证下一个ID一定大于上一个ID；
基于上述特性，我们最先可以想到使用数据库本身的自增ID，但是显然对于有分库分表、业务隔离和增删改查后的连续自增均不满足，更重要的是需要对入库前的数据质量做统计时，等到入库再进行ID标记，在时序上已无法满足要求。
分析上述的ID特性要求，虽然事件流上报到后台是可以理解为分布式的上报，但是我们统计上报质量，是基于统计每个设备的每个业务的上报质量之后，再统一汇聚全部设备的质量计算出某业务的上报质量，所以可以发现此ID不需要进行联网分布式生成，可以基于设备维度在本地生成，并进行业务间隔离计算并存储即可，灯塔SDK将此ID称为事件的LogID序号。
灯塔SDK在实际计算生成LogID时，会区分灯塔SDK的版本进行统计，当SDK版本升级时会重置LogID。
上报成功率
上报成功率，通过计算在某个时间区间内，实际后台接收到的事件与需要上报的事件的比例，是衡量灯塔SDK事件上报成功质量最关键的指标。
由上述LogID的原理，上报的每条事件都会有一个独立的上报序号，称为LogID，这个ID在同设备、同app、同进程下、同业务下，会连续自增。
在灯塔后台，会对LogID做一个统计，对于同设备、同app、同进程、同业务的日志，计算如下：
因为SDK上报日志时，LogID是连续自增的，因此，丢失的事件会在count(distinct LogID)里体现出来，举例某一天某台设备的日志上报情况分析如下，
从全局的角度计算某个业务的上报成功率，为了消除不同设备上报的事件数量不一样引起的加权不一样，则不能将单个的设备上报成功率直接求和取平均，而是需要计算全部实际设备接收的事件量之和与全部设备实际应该上报的事件量的比例，计算如下：
在统计的时间细粒度上，除了经典的T+1天的粒度，可以按照分/时/天等粒度灵活计算上报的成功率，以反映不同粒度的上报成功率。
上报及时率
上报及时率，是通过计算距离事件产生到上报成功的某个时间区间内，成功上报的事件被与需要上报的事件的比例，衡量的是事件从产生到被灯塔SDK上报至后台需要的时间，反映的是事件上报的及时性。例如事件在00：00只00：05的5s事件内产生的数量是100条，实际上报到后台的是99条，则1s内的及时率就是99%。
从另外的角度近似地统计，也可以计算某个事件区间内，后台接收的事件里，其事件的产生时间也在这个时间区间的事件的占比。
上报重复率
上报重复率，是指同一条事件被灯塔SDK上报至后台两次甚至多次，计算的是在某个时间区间内，有重复的事件占总事件量的比例。
SDK Crash率
为提升灯塔SDK的质量，灯塔SDK基于以下两个指标，亦提供了严格的crash SLA保障。
日Crash率，灯塔客户端SDK当天产生的crash的数量DTCrashCount，业务方APP当天的日活用户ActiveUserCount，DTCrashCount / ActiveUserCount即为灯塔SDK的日crash率
占业务方Crash率的比例，即灯塔SDK的Crash率占业务方APP Crash率的比率。
建立监控体系
对于线上系统，可观测性是非常重要的指标，对于问题的感知和排查来说，监控是非常重要的一环，灯塔SDK为此从SDK运行错误，LogID统计置信度（可信度）和crash异常方面均做了非常细致的监控。
因为灯塔SDK自身作为一个上报通道，也可以作为监控上报的通道，但是为了监控灯塔SDK ，灯塔SDK使用腾讯的atta系统作为监控旁路，对灯塔SDK做监控上报，并将监控数据接入灯塔分析平台进行统计和分析。
错误监控与性能监控
错误监控是针对灯塔SDK运行过程中一些可能出现的错误进行的监控上报，灯塔SDK针对这些监控项按模块化区分，并使用atta旁路通道上报监控，相关错误监控模块有：
- 前置检验监控
- 数据库增删改查相关监控
- 序列化、加解密、加压缩相关监控
- 上报及后台错误监控
- 网络监控等
除了错误监控模块外，灯塔SDK还有相关的性能、耗时、置信度等监控亦是通过atta通道进行上报。
例如如下线上的错误监控，
6**错误是DB相关的错误，在15号上线4.1.22之后迅速上升：
- 未升级前4.0.17版本，603错误码db插入约60w+；升级后4.1.22版本，603约350w，增长6倍
- 未升级前4.0.17版本，604错误码db查询约25w+；升级后4.1.22版本，604约150w，增长6倍
进一步分析，601错误码打开/创建db/表错误 并结合错误信息，是db创建失败，导致上面的数据增删改查失败，事件量下跌。
LogID置信度监控
在业务使用灯塔SDK上报数据后，在查看和分析线上的数据时，如分析APP的DAU或者使用时长等关键指标时，往往会怀疑其某个新活动的DAU应该会更高，此时我们会给出灯塔SDK的上报率情况等给业务看，但是业务可能会怀疑我们的上报率统计就可能存在bug或者质疑上报率的可信度，所以灯塔SDK需要更进一步针对自身的LogID统计的上报成功率等指标做置信度的验证。
基于灯塔SDK前面已经建设的atta旁路监控通道，可以复用来进一步做LogID的监控统计，通过独立于灯塔上报通道的atta通道验证自身上报成功率的置信度，具体的置信度的监控上报逻辑如下：
异常crash监控
当前业界的crash监控均是基于APP维度的，尚未有较为完善的基于SDK维度的crash监控，灯塔SDK在此结合了各业务APP自己的crash监控能力和RDM的crash监控能力，基于RDM后台的crash监控能力，针对灯塔SDK的监控标识字段，将各个业务的灯塔SDK的crash情况单独拉取并建立灯塔SDK的crash质量看板，基于此可以不需要等业务的反馈，较业务更及时地感知灯塔SDK的线上crash情况。
基于此，灯塔SDK提供了日crash率十万分之一的SLA，在线上业务中，如果有高于十万分之一的线上crash率，则灯塔SDK会优先解决crash问题。
建立质量看板、质量播报及异动告警
基于上述的监控能力，建立相关的看板及异动告警等，进一步及时感知问题。
- 上报率、及时率等看板、crash等大盘
- 企业微信群播报
- 异动告警
建立线上问题诊断手段
atta线上单用户错误分析
结合业务的上报成功率，用户上报事件的日志详细流水及atta错误监控等，可以进行业务的线上问题定位。
- 基于业务上报成功率，对于有异常上报成功率的业务，可以针对性地将上报成功率低于80% 的用户查询出来
- 将第一步的用户详细日志查询出来, 用LogID分析用户上报率偏低的原因
- 如果第二步得到初步结果, 则修复可能出现问题的点，如果无法找到问题，那么就可以使用atta 上报的错误监控来单独深度分析用户错误上报,，来确定导致上报率偏低的问题
线上单用户远程诊断日志捞取与分析
旧版本的灯塔SDK对线上问题定位，主要依赖业务集成方：
- 需要集成方重新打包集成、打开日志、在开发环境本地运行复现、IDE里copy获取日志、日志返回给灯塔开发同学定位问题
- 像IEG的msdk等二次封装了灯塔SDK的业务，定位问题的流程更为漫长，甚至重新打包等无法支持，缺乏定位问题的主动权
- 其次，对于在分析平台捞取到的低上报率的线上用户，缺乏获取上报率低的第一现场日志的手段
SDK迫切需要自我定位线上问题的能力建设，可以在线获取问题现场的第一手运行日志。 新版本的灯塔SDK更进一步地建立了在线诊断日志捞取能力。
如果基于atta单用户线上错误分析仍无法找到异常原因，还可以结合灯塔SDK建设的在线诊断日志捞取能力，基于atta上报的错误，通过设备ID可以定位用户低上报率影响大的那批用户，以配置下发的方式，捞取线上用户的灯塔SDK记录的关键操作行为和详细错误日志进行分析定位。
效果收益
基于灯塔SDK建立的指标体系、监控体系和线上问题诊断手段，灯塔SDK针对性地根据指标数据分析及线上的监控问题进行修复和优化。目前灯塔SDK在上报成功率、及时率、重复率和crash率方面均达到比较不错的效果。
其中上报成功率基本上较之前旧版本95%至99%的不稳定上报率，目前均稳定在99.5%以上，大部分业务可以达到99.8%甚至99.99%；上报的及时率可以达到98%以上，重复率在千分之三以下，针对需要低重复率的业务事件，灯塔SDK还可以进一步后台去重，将重复率降低到千分之一以下；灯塔SDK的crash率也已稳定在十万分之一以下。
近期热文
Nginx 架构浅析
高性能对象池实现
微信游戏推荐系统大揭秘
让我知道你在看
腾讯云开发者
