5 滴滴在流量链路检测架构设计及实践.docxVIP

滴滴在流量链路检测架构设计及实践 2021-08-15 以下文章来源于滴滴技术 ，作者滴滴技术团队 HYPERLINK 滴滴技术 . 滴滴出行官方技术号 桔妹导读：流量数据作为整个数据体系构建的基石之一，为公司的用户增长、产品优化、智能运营及科学决策等方面，供应了牢靠的业务分析及决策依据。业务层面对于流量数据也有较高的要求，比如全面性、精确?????性、准时性。经过几年时间的打磨，我们沉淀了一套掩盖全链路的检测体系，能够有效协助链路同学看清数据现状、定位数据问题。本文共享了流量链路检测在滴滴多业务线场景下的实践。? 1.? 背景 Omega是公司内部供应移动端用户行为采集、加工、存储、呈现和应用的全流程数据服务平台。整个平台以前端数据采集为源头，通过实时或者离线ETL加工出具有业务需求的目标结果，为滴滴的用户增长、产品优化、智能运营及科学决策等供应牢靠的流量数据支持。目前支持了公司内外部近1500+应用，掩盖公司大部分业务线。 业务层面对埋点提出了全面、精确?????、准时的高要求，而这也是整个数据体系构建的基石。经过过往几年的持续打磨，我们沉淀了一套掩盖全链路的检测体系，能够有效的协助链路同学看清数据现状，定位数据问题。下面我将与大家共享技术侧的架构设计。 2.? 数据链路 首先，先简约引见一下整个数据链路的架构，一共包含如下六个核心模块。 采集SDK：用于收集、组装、发送埋点数据，通过相关缓存策略，降低丢包率、反复率。同时接收服务端策略下发，定向采集。 数据接收：用于接收来自端上的埋点数据及配置下发，高吞吐轻量级web服务。 实时ETL：下游实时、离线数据的同源出口，担任比较重的数据处理规律，如格式转换、地理信息填充、白名单过滤等。 离线数仓：kafka数据到hive的清洗过程，包含通用ODS及面对Session、设备等主题的数仓建设。 实时分流：面对实时数仓及算法策略场景的分流服务。 行为分析：kafka2olap子链路，服务上层行为分析力量，如埋点细分、漏斗、路径分析等分析产品。 ? 整个链路相对较长，涉及各个大数据组件，链路的稳定性保障存在着难点，次要体现在以下几点： 1. 数据源品种多，需要多种采集SDK，且采集规律需要适配不同的生态。 2. 采集数据量大，强关联业务的使用场景，对数据的精确?????、准时性要求高。 3. 采集SDK宿主及各个采集组件在不断迭代，可能会消灭问题。 如何有效的评估并供应应下游一份可用的数据？这就是贯穿全流程的链路检测服务需要处理的问题，数据链路检测模块次要担当链路的接收率、反复率、丢包率的度量及预警等职责。? 3.? 数据链路检测 ▍3.1?设计思路 对采集数据实现完整性度量：采集的数据质量我们从两个方面进行度量：1）采集的精确度 2）采集的精确?????度。 精确是指每一次独立测量和真实值之间的差距（与理论值相符合的程度）； 精确?????则是要求试验有高度再现（多次试验或计算的结果全都），一个完整的度量必需符合精确和精确?????两个条件，才能算是精准，削减误判。 我们在度量的精准和精确?????两个方面进行了如下方面的努力。采集完整性度量方案不同于公司实时采集系统dquality接受的三方校验，Omega接受基于离线的小时级pv、uv联合校验保证度量采集完整性的精确度和精确?????度。 在采集精确度方面： 1）端上sdk层面，前端设备会以进程（android/ios，h5以页面）为基本单位，维护一个计数器，在app存活期间记录当前的埋点上报数据量，并且会记录后续的每次上报数据量。 2）通道数据加工层面，在端上实现类似trace系统的traceId，埋点每次上传会在端上生成独一的恳求Id，保证每次恳求的独一性，恳求Id会在数据流淌各个节点进行记录。在数据传输节点保证at last once语义的情况下，实现每一个埋点的独一性校验。 3）在小时级粒度下，以服务器接收时间处理接入层恳求日志和埋点日志切割的时间漂移问题。 在采集精确?????度方面： 检测需要的数据源以小时级离线表ods方式产出，在离线数据的基础上构建检测目标，保证数据源多次重新计算结果全都。 ▍3.2?方案设计 对于全链路的六大模块，我们进行了环环相比的检测方案，通过数据前后流淌两个节点pv比率(uv比率协助校验能否存在反复消费情况)推断每个节点生产消费能否正常，简化后的链路如下图五个节点： 链路检测有两个核心目标：丢失率和入库率，分别用来度量端上sdk、内部通道的采集质量。 丢失率是规律上度量端上sdk采集质量，丢失率分子为实际在接入层收集到恳求数，丢失率的分母是通过计数器实现预期的恳求数，丢失率通过对埋点恳求接收情况量化进而度量端上sdk的采集质量。 入库率是用来度量内部通道的采集质量，通过埋