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

举个例子：上游Topic有200个Partition ，我们在一站式开发平台上去配置Flink拆分任务时只需要指定每个子任务的流量比例，每个子任务就能自动计算出它需要消费的topicpartition区间，其余参数也支持按流量比例自动调整。
拆分任务的应用使得数据流除了规则粒度的灰度发布能力之外，还具备了Job粒度的灰度发布能力，升级扩容的时候不会发生断流，上线的风险更可控。同时由于拆分任务的各子任务是独立的，因此单个子任务出现反压、Failover对下游的影响更小。另一个优点是，单个子任务的资源使用量更小，资源可以同时在多个队列进行灵活的部署。
容灾与降级能力建设
说到ETL链路建设，埋点数据流在容灾与降级能力建设方面也进行了一些实践。

文章图片
首先是容灾能力的建设，埋点数据流在Flink、MQ、Yarn、HDFS等组件支持多机房容灾的基础上完成了多机房容灾部署，并准备了多种流量调度的预案。正常情况下流量会均匀打到多个机房， MQ在多个机房间同步， FlinkETLJob默认从本地MQ进行消费，如果某个机房出现故障，我们根据情况可以选择通过配置下发的方式从客户端将流量调度到其他非受灾机房，也可以在CDN侧将流量调度到其他非受灾机房。埋点数据流ETL链路可以分钟级地进入容灾模式，迅速将故障机房的FlinkJob切换到可用的机房。其次是服务降级能力的建设，主要包含服务端降级策略和客户端降级策略。服务端降级策略主要通过LB限流、客户端进行退避重试的机制来实现，客户端降级策略通过配置下发可以降低埋点的上报频率。举个例子：在春晚活动中参与的用户很多，口播期间更是有着非常巨大的流量洪峰， 2021年春晚活动期间为了应对口播期间的流量洪峰，埋点数据流开启了客户端的降级策略，动态降低了一定比例用户的埋点上报频率，在口播期间不上报，口播结束后迅速恢复上报。在降级场景下，下游的指标计算是通过消费未降级用户上报的埋点去估算整体指标。目前我们在此基础上进行了优化，客户端目前的降级策略可以更近一步的根据埋点的分级信息去保障高优的埋点不降级，这样可以在活动场景下保障活动相关的埋点不降级的上报，支持下游指标的准确计算。埋点数据流治理实践
介绍完埋点数据流建设的实践，接下来给大家分享的是埋点数据流治理方面的一些实践。埋点数据流治理包含多个治理领域，比如稳定性、成本、埋点质量等，每个治理领域下面又有很多具体的治理项目。

文章图片
比如在稳定性治理中我们通过优化减少了由于单机问题、MQ性能问题和混布问题等导致的各种稳定性问题；成本治理方面，我们通过组件选型、性能优化、埋点治理等方式取得了显著降本增效的成果；埋点质量治理方面，我们对脏数据问题、埋点字段类型错误问题和埋点数据的丢失重复问题进行了监控和治理。这次我们主要选取了其中部分治理项目和大家分享。单机问题优化
FlinkBacklogRescale
Yarn单机问题导致Flink任务Failover、反压、消费能力下降是比较常见的case 。

文章图片
单机问题的类型有很多：队列负载不均、单机load高或者其他进程导致CPU负载高，以及一些硬件故障都可能导致Yarn单机问题。针对Yarn单机问题，我们从Flink和Yarn两个层面分别进行了优化，最终使单机load高导致的数据延迟减少了80%以上。