作者: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是腾讯通用的客户端用户行为事件(数据源)上报通道,带有本地缓存、失败重试,旁路监控等功能来保证日志安全可靠地上报至后端。
使用灯塔SDK上报日志,可以无缝使用灯塔敏捷分析、灯塔可视化DataTalk等功能,以及将数据接出至业务的系统进行消费,建立用户画像、建立标签、进行AB实验分析、智能推荐等。
支撑的业务
在数据治理的背景下,灯塔SDK是PCG全部业务客户端的标准统一数据上报通道,公司内外使用灯塔SDK的活跃的APP数量有数千个,目前的服务业务包括:
相关平台的关系
与灯塔SDK上下游相关的一些常用工具平台或SDK,如大同SDK、MTA上报、boss平台等,简单梳理他们之间的关系如下:
更多各平台间详细关系参考下图。
Logging、Metrics和Tracing
在开发过程中,很多同学是否偶尔也会搞混所谓的日志采集上报平台、监控采集上报分析平台和链路追踪平台,他们之间似乎都有很多相似性又有所区别,而这些系统之间似乎又耦合或者有和灯塔SDK类似的一部分能力。为了弄清楚这些系统间的关系,我们来看韦恩关系图:
很明显他们之间确实是有所部分重叠的功能,但这些系统关注的领域和特点是不一样的。
为什么使用灯塔SDK
可以解决哪些问题
业务线为什么要使用灯塔SDK?它可以解决哪些痛点?
相信在任何一款互联网产品上线前或者运营过程中,肯定都需要考虑怎么去度量产品上线后的运营情况,包括DAU、留存、收益等等情况,对于开发、产品、运营和数据的同学,可能都遇到如下类似的问题:
正所谓,数据的质量,决定了数据价值的上限!没有好的数据治理,无法保证好的数据质量!数据治理,需要统一的采集方案,统一的上报链路,灯塔SDK正是专注于解决这些问题的推出的统一上报通道方案。
支持的平台及能力
除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来说,衡量业务上报的事件流的质量,需要对每条事件进行唯一标识的标记,需要满足以下的特征:
基于上述特性,我们最先可以想到使用数据库本身的自增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之后迅速上升:
进一步分析,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问题。
建立质量看板、质量播报及异动告警
基于上述的监控能力,建立相关的看板及异动告警等,进一步及时感知问题。
建立线上问题诊断手段
atta线上单用户错误分析
结合业务的上报成功率,用户上报事件的日志详细流水及atta错误监控等,可以进行业务的线上问题定位。
线上单用户远程诊断日志捞取与分析
旧版本的灯塔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 架构浅析
高性能对象池实现
微信游戏推荐系统大揭秘
让我知道你在看