干货 | 一文读懂字节跳动“埋点验证平台”（下）

文 | 志荣  来自字节跳动数据平台开发套件团队

技术挑战

• 易用性：快速接入埋点验证，快速开始埋点验证

• 准确性：埋点验证结果准确、用户可信

• 实时性：埋点数据实时可见

• 稳定性：埋点数据可靠不丢失

• 扩展性：快速接入新的埋点数据格式

 SDK 

1. 快速接入埋点验证

2. SDK提供“埋点验证开关”，客户端集成SDK的时候，可根据不同环境来配置是否开启“埋点验证开关”

3. SDK层判断如果开启“埋点验证开关”，埋点数据会双发，此过程对业务是透明的
1. “线上埋点通道”数据量太大
2. SDK层线上上报逻辑是采用微批的形式，默认1分钟从客户端上报一次，而埋点验证要求实时性，所以采用单独的通道
3. 双发的原因或者为什么不从“线上埋点通道”取数？这里主要考虑两个原因：

1. 快速开始埋点验证

2. 连接流程
1. 建立WS连接：服务端和验证平台建立长连接，用于通信
2. ws_id：验证平台根据ws_id生成二维码
3. 扫码：客户端扫描二维码
4. 获取并打开验证开关：客户端获取设备信息并且打开埋点验证开关
5. 上报device_id：客户端将长连接信息和设备信息上报至服务端
6. 下发device_id：服务端将设备信息推送到验证平台
7. 开始验证：埋点验证平台进入验证阶段
8. 上报埋点：客户端开始上报埋点
9. 推送埋点：服务端将埋点推送到验证平台

3. 下发原理
1. 客户端上报的埋点数据中含有设备信息
2. 用户通过扫码在验证平台回填设备信息
3. 服务端接收到埋点数据后，将埋点数据中的设备信息和验证平台的设备信息进行匹配，如果匹配则将埋点数据进行下发

 埋点方案 

event:video_play

• 埋点名称：video_play
• 参数信息
• (名称、类型、是否必填、值校验、是否是场景条件)
• enter_from,string,必传,固定值(login),是
• duration,integer,必传,值无限制,否
• type,integer,必传,枚举(1,2,3),否

 埋点规则 

jsonSchema

{    "$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"    ]}

埋点数据 

event:video_play

{    "app_id":100,    "event":"click",    "params":{        "enter_from":"login",        "duration":1,        "type":3    }}

 验证结果 

event:video_play

• 测试地址：https://www.jsonschemavalidator.net/
  
  

1. 基于WebSocket实现一套通用长连接通讯协议，能实现同一个客户端上的不同业务共享同一个长连接通道，并实现可靠的心跳机制。

2. 客户端和服务端基于通用长连接通讯协议实现一个稳定可靠的全双工通道。

3. 客户端实现一个通用的SDK，服务端实现一个通用接入层。

4. 客户端SDK，服务端接入层，都要很方便后续service接入。

5. Push服务定期做打点监控，同时开放http的Admin接口，方便系统的监控和查看服务状态

1. 连接稳定性：Push服务分为两个组件Push和Backone，实现了业务和推送解耦。push面向客户端连接，设计尽可能简单，需保持大量客户端活跃连接，避免了业务服务更新时不影响客户端连接

2. 服务隔离性：不同的业务服务接入push服务，会根据接入信息做集群隔离，避免业务之间互相影响

3. 横向扩展性：当业务服务不断增多时，只需对push服务做横向扩容即可支持

SLA 

1. 定义：服务级别协议 (service-level agreement，即 SLA) 是服务提供方与客户之间的正式承诺，用来量化服务水平(质量、可用性、责任)
2. 埋点验证服务：服务的特征是实时，所以衡量埋点验证不可用的手段是“数据延迟”，即埋点从“上报”->“验证平台”的 p99 超过 3s 即视为不可用，日常 p99 在 1s

   
   

   可用性	双月故障时间	年故障时间
   99.9%	86.4m	8.64 h

 措施 

• 为了保证“SLA”，我们做了一系列的保护措施
• 日志转换器：客户端、服务端、web 端上报的是原始日志格式，需要转换为埋点验证日志格式后进行验证

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

展望

埋点验证是保障埋点质量的有效方式，此方式属于事前验证，适用于埋点频繁变化的业务场景，需要一定程度的人工介入，能够解决基本的埋点质量问题。但是对于核心埋点场景来说，这种方式的验证成本较高，需要重复的人力投入，为了解决核心埋点验证成本高的问题，我们正在探索落地其他方式：

• 回归验证(自动化验证)：伴随每次发版，核心埋点都需要进行回归验证，目前我们通过内部其他团队的合作实现了自动化验证功能来支撑回归验证，当前已有一部分业务正在使用，极大地降低了验证核心埋点的成本
• 事后验证：经过事前验证、回归验证，埋点质量基本能得到很好的保障。但为了更好的保障我们也在探索事后验证的场景和落地：
• 质量大盘：通过“规则引擎”，结合“质量模型”对埋点数据进行质量评估，得出各个维度的“质量评分”，然后针对质量问题进行专项修复，进一步提高埋点质量。
• 质量工具：提供监控计划，业务可以针对自己关注的埋点配置监控报警，当线上出现质量问题，会发送质量报告给业务，及时止损。
• 全链路埋点质量保障：事前验证、回归验证、事后验证贯穿埋点的生命周期，打通这三个流程，从而形成埋点质量保障全链路，彻底解决埋点质量问题。

点击阅读原文进入官网，了解DataLeap更多产品信息