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

因此我们提供了数据分流服务，实现上是我们使用一个Flink任务去消费上游埋点Topic ，通过在任务中配置分流规则的方式，将各个业务关注的埋点分流到下游的小Topic中提供给各业务消费，减少不必要的资源开销，同时也降低了MQ集群出带宽。
分流需求大多对SLA有一定要求，断流和数据延迟可能会影响下流的推荐效果、广告收入以及数据报表更新等。另外随着业务的发展，实时数据需求日益增加，分流规则新增和修改变得非常频繁，如果每次规则变动都需要修改代码和重启任务会对下游造成较大影响，因此在数据分流这个场景，规则的动态更新也是比较强的需求。

文章图片
容灾降级
另一个场景是容灾降级。数据流容灾首先考虑的是防止单个机房级别的故障导致埋点数据流完全不可用，因此埋点数据流需要支持多机房的容灾部署。其次当出现机房级别的故障时，需要将故障机房的流量快速调度到可用机房实现服务的容灾恢复，因此需要埋点数据流具备机房间快速切流的能力。

文章图片
而数据流降级主要考虑的是埋点数据流容量不足以承载全部流量的场景，比如春晚活动、电商大促这类有较大突发流量的场景。为了保障链路的稳定性和可用性，需要服务具备主动或者被动的降级能力。
埋点数据流遇到挑战
【字节跳动埋点数据流建设与治理实践】挑战主要是流量大和业务多导致的。流量大服务规模就大，不仅会导致成本治理的问题，还会带来单机故障多、性能瓶颈等因素引发的稳定性问题。而下游业务多、需求变化频繁，推荐、广告、实时数仓等下游业务对稳定性和实时性都有比较高的要求。
在流量大、业务多这样的背景下，如何保障埋点数据流稳定性的同时降低成本、提高效率，是埋点数据流稳定性治理和成本治理面对的挑战。

文章图片
埋点数据流建设实践
上文我们了解了埋点数据流的业务场景和面对的挑战，接下来会介绍埋点数据流在ETL链路建设和容灾与降级能力上的一些实践。
ETL链路建设
发展历程
埋点数据流ETL链路发展到现在主要经历了三个阶段。

文章图片
第一个阶段是2018年以前，业务需求快速迭代的早期阶段。那时我们主要使用PyJStorm与基于Python的规则引擎构建主要的流式处理链路。特点是比较灵活，可以快速支持业务的各种需求，伴随着埋点量的快速上涨， PyJStorm暴露出很多稳定性和运维上的问题，性能也不足以支撑业务增长。 2018年内部开始大力推广Flink ，并且针对大量旧任务使用PyJStorm的情况提供了PyJStorm到PyFlink的兼容适配，流式任务托管平台的建设一定程度上也解决了流式任务运维管理问题，数据流ETL链路也在2018年全面迁移到了PyFlink ，进入到Flink流式计算的新时代。第二个阶段是2018年到2020年，随着流量的进一步上涨， PyFlink和kafka的性能瓶颈以及当时使用的JSON数据格式带来的性能和数据质量问题纷纷显现出来。与此同时，下流业务对数据延迟、数据质量的敏感程度与日俱增。我们不仅对一些痛点进行了针对性优化，还花费一年多的时间将整个ETL链路从PyFlink切换到JavaFlink ，使用基于Groovy的规则引擎替换了基于Python的规则引擎，使用Protobuf替代了JSON ，新链路相比旧链路性能提升了数倍。同时大数据开发平台和流量平台的建设提升了埋点数据流在任务开发、ETL规则管理、埋点管理、多机房容灾降级等多方面的能力。第三个阶段是从2021年开始至今，进一步提升数据流ETL链路的性能和稳定性，在满足流量增长和需求增长的同时，降低资源成本和运维成本是这一阶段的主要目标。我们主要从三个方面进行了优化。优化了引擎性能，随着流量和ETL规则的不断增加，我们基于Groovy的规则引擎使用的资源也在不断增加，所以基于Janino对规则引擎进行了重构，引擎的性能得到了十倍的提升。基于流量平台建设了一套比较完善的埋点治理体系，通过埋点下线、埋点管控、埋点采样等手段降低埋点成本。将链路进行了分级，不同的等级的链路保障不同的SLA ，在资源不足的情况下，优先保障高优链路。接下来是我们2018至2020年之间埋点数据流ETL链路建设的一些具体实践。基于规则引擎的FlinkETL