当前位置:网站首页>一文读懂字节跳动“埋点验证平台”
一文读懂字节跳动“埋点验证平台”
2022-08-08 14:51:00 【InfoQ】
序言
埋点验证流程
- 埋点生命周期:4+6
- 4 个角色:PM、DA、RD、QA
- 6 个节点:提出需求、设计埋点、开发埋点、测试埋点、上报埋点、分析埋点
- 埋点验证流程:3+3+3
- 3 个角色:DA、RD、QA
- 3 个节点:设计埋点、测试埋点、验收埋点
- 3 个物料:埋点验证方案、埋点验证工具、埋点验证报告

技术架构
产品流程

- 附埋点验证工具图

技术架构图
- 埋点上报环节重点是丰富的 SDK(客户端、服务端、JS、Chrome 插件),要做到简单易用并且保证埋点实时上报。
- 埋点接收环节重点是数据接收服务(客户端-applog、Web 端-mcs、服务端-databus)、数据保存服务(消息队列),要保证服务稳定并且保证埋点不丢失。
- 埋点验证环节重点是埋点验证引擎,要确保服务高性能并且保证埋点验证结果的准确性。

规则生成器

- 按需求验证:即新建需求计划,针对某次需求验证、
- 按元数据验证:即按元数据验证,元数据是指所有需求的并集
- 埋点名称:video_play
- 参数信息
- (名称、类型、是否必填、值校验、是否是场景条件)
- enter_from,string,必传,固定值(login),是
- duration,integer,必传,值无限制,否
- type,integer,必传,枚举(1,2,3),否
{
"app_id":100,
"event":"click",
"params":{
"enter_from":"login",
"duration":1,
"type":3
}
}
{
"app_id":100,
"event_name":"video_play",
"logical_filter":{
"enter_from":"login"
},
"meta":{
"required_field":[
"duration",
"enter_from",
"type"
],
"scene":{
"condition":"enter_from=login",
"name":"登录页"
},
"validate_field":[
"duration",
"enter_from",
"type"
]
},
"physical_validation":"{\"$schema\":\"https://json-schema.org/draft/2019-09/schema\",\"type\":\"object\",\"properties\":{\"params\":{\"type\":\"object\",\"properties\":{\"duration\":{\"type\":\"integer\"},\"enter_from\":{\"type\":\"string\",\"enum\":[\"login\"]},\"type\":{\"type\":\"integer\",\"enum\":[1,2,3]}},\"required\":[\"duration\",\"enter_from\",\"type\"]}},\"required\":[\"params\"]}",
"source":"schema_scene"
}
- app_id:应用 id
- event_name:埋点名称
- logical_filter:用于“规则选择器”
- physical_validation:用于“埋点验证器”
- source:区分规则来源:按需求验证、按元数据验证
规则选择器
- 选择逻辑:具体数据参考“规则生成器”
- 根据“埋点数据”中 app_id 和 event 从“验证规则池”中筛选出“匹配的规则”
- 将“埋点数据”的 parms 字段和“匹配的规则”的 login_filter 规字段进行匹配,选择出最终的“埋点验证规则”

埋点验证器
- 基础验证规则:埋点是否登记;埋点是否禁用;是否是 debug 埋点;
- 埋点验证规则:参数是否丢失;参数类型是否正确;参数取值是否符合预期:枚举、范围、正则;
- 埋点验证结果:验证结果提供双语格式,用户可自行选择中文或者英文;

埋点推送器

技术挑战
- 易用性:快速接入埋点验证,快速开始埋点验证
- 准确性:埋点验证结果准确、用户可信
- 实时性:埋点数据实时可见
- 稳定性:埋点数据可靠不丢失
- 扩展性:快速接入新的埋点数据格式
易用性
SDK
- 快速接入埋点验证
- SDK 提供“埋点验证开关”,客户端集成 SDK 的时候,可根据不同环境来配置是否开启“埋点验证开关”
- SDK 层判断如果开启“埋点验证开关”,埋点数据会双发,此过程对业务是透明的
- 双发的原因或者为什么不从“线上埋点通道”取数?这里主要考虑两个原因:
- “线上埋点通道”数据量太大
- SDK 层线上上报逻辑是采用微批的形式,默认 1 分钟从客户端上报一次,而埋点验证要求实时性,所以采用单独的通道

扫码连接
- 快速开始埋点验证
- 连接流程
- 建立 WS 连接:服务端和验证平台建立长连接,用于通信
- ws_id:验证平台根据 ws_id 生成二维码
- 扫码:客户端扫描二维码
- 获取并打开验证开关:客户端获取设备信息并且打开埋点验证开关
- 上报 device_id:客户端将长连接信息和设备信息上报至服务端
- 下发 device_id:服务端将设备信息推送到验证平台
- 开始验证:埋点验证平台进入验证阶段
- 上报埋点:客户端开始上报埋点
- 推送埋点:服务端将埋点推送到验证平台
- 下发原理
- 客户端上报的埋点数据中含有设备信息
- 用户通过扫码在验证平台回填设备信息
- 服务端接收到埋点数据后,将埋点数据中的设备信息和验证平台的设备信息进行匹配,如果匹配则将埋点数据进行下发

准确性
埋点方案
- 埋点名称:video_play
- 参数信息
- (名称、类型、是否必填、值校验、是否是场景条件)
- enter_from,string,必传,固定值(login),是
- duration,integer,必传,值无限制,否
- type,integer,必传,枚举(1,2,3),否
埋点规则
{
"$schema":"https://json-schema.org/draft/2019-09/schema",
"type":"object",
"properties":{
"params":{
"type":"object",
"properties":{
"duration":{
"type":"integer"
},
"enter_from":{
"type":"string",
"enum":[
"login"
]
},
"type":{
"type":"integer",
"enum":[
1,
2,
3
]
}
},
"required":[
"duration",
"enter_from",
"type"
]
}
},
"required":[
"params"
]
}
埋点数据
{
"app_id":100,
"event":"click",
"params":{
"enter_from":"login",
"duration":1,
"type":3
}
}
验证结果


- 测试地址:https://www.jsonschemavalidator.net/
实时性
Push 服务目标
- 基于 WebSocket 实现一套通用长连接通讯协议,能实现同一个客户端上的不同业务共享同一个长连接通道,并实现可靠的心跳机制。
- 客户端和服务端基于通用长连接通讯协议实现一个稳定可靠的全双工通道。
- 客户端实现一个通用的 SDK,服务端实现一个通用接入层。
- 客户端 SDK,服务端接入层,都要很方便后续 service 接入。
- Push 服务定期做打点监控,同时开放 http 的 Admin 接口,方便系统的监控和查看服务状态
Push 服务优势
- 连接稳定性:Push 服务分为两个组件 Push 和 Backone,实现了业务和推送解耦。push 面向客户端连接,设计尽可能简单,需保持大量客户端活跃连接,避免了业务服务更新时不影响客户端连接
- 服务隔离性:不同的业务服务接入 push 服务,会根据接入信息做集群隔离,避免业务之间互相影响
- 横向扩展性:当业务服务不断增多时,只需对 push 服务做横向扩容即可支持
Push 服务流程

稳定性
SLA
- 定义:服务级别协议 (service-level agreement,即 SLA) 是服务提供方与客户之间的正式承诺,用来量化服务水平(质量、可用性、责任)
- 埋点验证服务:服务的特征是实时,所以衡量埋点验证不可用的手段是“数据延迟”,即埋点从“上报”->“验证平台”的 p99 超过 3s 即视为不可用,日常 p99 在 1s
措施
- 为了保证“SLA”,我们做了一系列的保护措施
- 日志转换器:客户端、服务端、web 端上报的是原始日志格式,需要转换为埋点验证日志格式后进行验证

扩展性
- 提供可插拔的“日志转换器插件”,服务高内聚,可支持各种日志格式快速接入、验证

展望
- 回归验证(自动化验证):伴随每次发版,核心埋点都需要进行回归验证,目前我们通过内部其他团队的合作实现了自动化验证功能来支撑回归验证,当前已有一部分业务正在使用,极大地降低了验证核心埋点的成本
- 事后验证:经过事前验证、回归验证,埋点质量基本能得到很好的保障。但为了更好的保障我们也在探索事后验证的场景和落地:
- 质量大盘:通过“规则引擎”,结合“质量模型”对埋点数据进行质量评估,得出各个维度的“质量评分”,然后针对质量问题进行专项修复,进一步提高埋点质量。
- 质量工具:提供监控计划,业务可以针对自己关注的埋点配置监控报警,当线上出现质量问题,会发送质量报告给业务,及时止损。
- 全链路埋点质量保障:事前验证、回归验证、事后验证贯穿埋点的生命周期,打通这三个流程,从而形成埋点质量保障全链路,彻底解决埋点质量问题。
边栏推荐
猜你喜欢
小白大白读论文-关于EfficientNetV2论文的 疑问 与 总结
761. 特殊的二进制序列 : 经典构造题
JS-BOM-名字转换器-输入名字位置颠倒
2022-08-07 第五小组 顾祥全 学习笔记 day31-集合-Map集合
Tungsten Fabric SDN — OpenStack 与 Kubernetes 异构集群统一 SDN 方案
JS Adder (DOM)
我凭借这份pdf成功拿到了阿里,腾讯,京东等六家大厂offer
Elegantly detect and update web applications in real time
[内部资源] 想拿年薪30W的软件测试人员,这份资料必须领取
本机Redis Desktop Manager连不上vmware的redis
随机推荐
EasyExcel导入校验必填项不能为空
零基础入门华为云数据库RDS【华为云至简致远】
让您知道华为云服务器的强大【华为云至简致远】
什么是幂等性
基于接口而非实现编程
软考 --- 软件工程(6)软项目管理
Is it safe to open an account online now?Which securities to choose for securities account opening?
P8352-[SDOI/SXOI2022]小N的独立集【dp套dp】
JS-BOM-for,if(字符串转大小写)
PHP —— 用 ThinkPHP5.0 实现微信小程序登陆
本机Redis Desktop Manager连不上vmware的redis
并发请求如何优雅地处理重复请求
Common regularization methods in deep learning (Regularization) and detailed explanation of WeightDecay parameters in optimizers
更改默认打开应用程序设置
AT2382-[AGC015D]A or...or B Problem
[Small Coder Study Room] [NOI Online 2020-2 Beginner Group] Finished: Abominable precision will make you burnt
2022-08-07 The fifth group Gu Xiangquan study notes day31-collection-Map collection
【LeetCode】761. Special binary sequence
bandanas Kerchief头巾是何含义?
【小码匠自习室】叛逆的小孩,打死也不改