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

在埋点数据流这种大流量场景下使用Kafka ，会经常遇到Broker或者磁盘负载不均、磁盘坏掉等情况导致的稳定性问题，以及Kafka扩容、Broker替换等运维操作也会影响集群任务正常的读写性能，除此之外Kafka还有controller性能瓶颈、多机房容灾部署成本高等缺点。

文章图片
为了优化这些问题， BMQ这款字节跳动自研的存储计算分离的MQ应运而生。 BMQ的数据存储使用了HDFS分布式存储，每个Partition的数据切分为多个segment ，每个segment对应一个HDFS文件， Proxy和Broker都是无状态的，因此可以支持快速的扩缩容，并且由于没有数据拷贝所以扩缩容操作也不会影响读写性能。
受益于HDFS已经建设得比较完善的多机房容灾能力， BMQ多机房容灾部署就变的非常简单，数据同时写入所有容灾机房后再返回成功即可保障多机房容灾。数据消费是在每个机房读取本地的HDFS进行消费，减少了跨机房带宽。除此之外，由于基于多机房HDFS存储比Kafka集群多机房部署所需的副本更少，所以最终实现了单GB流量成本对比Kafka下降了50%的资源收益。
成本治理-埋点治理
在埋点治理方面，通过对流量平台的建设，提供了从埋点设计、埋点注册、埋点验证、埋点上报、埋点采样、流式ETL处理，再到埋点下线的埋点全生命周期的管理能力。

文章图片
埋点管控
目前字节跳动所有的产品都开启了埋点管控。所有的埋点都需要在我们的流量平台上注册埋点元数据之后才能上报。而我们的埋点数据流ETL也只会处理已经注册的埋点，这是从埋点接入流程上进行的管控。

文章图片
在埋点上报环节，通过在流量平台配置埋点的采样率对指定的埋点进行采样上报，在一些不需要统计全量埋点的场景能显著地降低埋点的上报量。
对于已经上报的埋点，通过埋点血缘统计出已经没有在使用的埋点，自动通知埋点负责人在流量平台进行自助下线。埋点下线流程完成后会通过服务端动态下发配置到埋点SDK以及埋点数据流ETL任务中，确保未注册的埋点在上报或者ETL环节被丢弃掉。还支持通过埋点黑名单的方式对一些异常的埋点进行动态的封禁。
埋点分级

文章图片
埋点分级主要是针对离线存储成本进行优化，首先在流量平台上对埋点进行分级，埋点数据流ETL任务会将分级信息写入到埋点数据中。埋点数据在从MQDump到HDFS这个阶段根据这些分级的信息将埋点数据写入不同的HDFS分区路径下。然后通过不同的Spark任务消费不同分级分区的HDFS数据写入HiveTable 。不同等级的分区可以优先保障高优埋点的产出，另外不同分区也可以配置不同的TTL ，通过缩减低优数据的TTL节省了大量的存储资源。
未来规划
目前Flink能做到计算层面的流批一体，但计算和存储的流批一体还在探索阶段，接下来我们也会继续关注社区的进展。另外我们会尝试探索一些云原生的实时数据处理框架，尝试解决资源动态rescale的问题，以此来提升资源利用率。最后是在一些高优链路上，我们希望保障更高的SLA ，比如端到端的exactly-once语义。

文章图片