字节跳动埋点数据流建设与治理实践本文将介绍字节跳动在埋点数

文章图片
本文将介绍字节跳动在埋点数据流业务场景遇到的需求和挑战以及具体实践。
文|石伟来自字节跳动数据平台开发套件团队出品|字节跳动数据平台埋点数据流
埋点数据流在字节跳动
埋点数据流主要处理的数据是埋点，埋点也叫EventTracking ，是数据和业务之间的桥梁，也是数据分析、推荐、运营的基石。
用户在使用App、小程序、Web等各种线上应用时产生的用户行为数据主要通过埋点的形式进行采集上报，按不同的来源可以分为：
客户端埋点
Web端埋点
服务端埋点

文章图片
埋点通过埋点收集服务接收到MQ ，经过一系列的Flink实时ETL对埋点进行数据标准化、数据清洗、数据字段扩充、实时风控反作弊等处理，最终分发到不同的下游。下游主要包括推荐、广告、ABTest、行为分析系统、实时数仓、离线数仓等。因为埋点数据流处在整个数据处理链路的最上游，所以决定了“稳定性”是埋点数据流最为关注的一点。
字节跳动的埋点数据流规模
字节跳动埋点数据流的规模比较大，体现在以下几个方面：
接入的业务数量很多，包括抖音、今日头条、西瓜视频、番茄小说在内的多个App和服务，都接入了埋点数据流。
流量很大，当前字节跳动埋点数据流峰值流量超过1亿每秒，每天处理超过万亿量级埋点， PB级数据存储增量。
ETL任务规模体量较大，在多个机房部署了超过1000个Flink任务和超过1000个MQTopic ，使用了超过50万CoreCPU资源，单个任务最大超过12万CoreCPU ，单个MQTopic最大达到10000个partition 。
那么在这么巨大的流量和任务规模下，埋点数据流主要处理的是哪些问题呢？我们来看几个具体的业务场景。
业务场景
UserActionETL
在推荐场景中，由于埋点种类多、流量巨大，而推荐只关注其中部分埋点，因此需要通过UserActionETL对埋点流进行处理，对这个场景来说有两个需求点：
数据流的时效性
ETL规则动态更新

文章图片
为了提升下流推荐系统的处理效率，我们在数据流配置ETL规则对推荐关注的埋点进行过滤，并对字段进行删减、映射、标准化等清洗处理，将埋点打上不同的动作类型标识，处理之后的埋点内部一般称为UserAction 。 UserAction与服务端展现、Feature等数据会在推荐Joiner任务的分钟级窗口中进行拼接处理，产出instance训练样本。
举个例子：一个客户端的文章点赞埋点，描述了一个用户在某一个时间点对某一篇文章进行了点赞操作，这个埋点经过埋点收集服务进入ETL链路，通过UserActionETL处理后，实时地进入推荐Joiner任务中拼接生成样本，更新推荐模型，从而提升用户的使用体验。
如果产出UserAction数据的ETL链路出现比较大的延迟，就不能在拼接窗口内及时地完成训练样本的拼接，可能会导致用户体验的下降，因此对于推荐来说，数据流的时效性是比较强的需求。而推荐模型的迭代和产品埋点的变动都可能导致UserActionETL规则的变动，如果我们把这个ETL规则硬编码在代码中，每次修改都需要升级代码并重启相关的FlinkETL任务，这样会影响数据流的稳定性和数据的时效性，因此这个场景的另一个需求是ETL规则的动态更新。
数据分流
抖音的埋点Topic晚高峰超过一亿每秒，而下游电商、直播、短视频等不同业务关注的埋点都只是其中一部分。如果每个业务都分别使用一个Flink任务去消费抖音的全量埋点去过滤出自己关注的埋点，会消耗大量的计算资源，同时也会造成MQ集群带宽扇出非常严重，影响MQ集群的稳定性。