本文整理自火山引擎开发者社区 Meetup 第四期演讲|字节跳动大规模埋点数据治理优秀实践( 三 )

离线处理：通过SQL解析，计算埋点与离线表的血缘;实时处理：利用埋点链路优势，掌握实时分流血缘关系;即时分析：与行为分析、SQL临时查询系统打通;推荐系统：利用数据清洗链路优势，解耦推荐血缘。
在埋点分级上，我们以性能埋点为突破口，给予匹配的SLA和TTL配置。
埋点链路解决方案
下面着重介绍一下我们的埋点链路解决方案。首先我们还是来看下埋点链路用户的需求是什么。对于非技术的运营、分析师同学，他们需要清楚自己：
需要什么样的数据：是埋点数据还是展现数据?需要哪些数据：最好能对不同来源不同时效性的数据进行可视化过滤、清洗。需要在哪里用这些数据：是实时报表，还是行为分析，还是推荐?埋点链路的挑战
在埋点链路设计上我们也遇到了一些挑战：
大数据量下的稳定性：埋点数据在字节跳动是核心数据，其稳定性非常重要。低延迟实时处理：尤其对于推荐，实时性要求非常高。
分级构建+下线。这里分几块内容：
数据接入：我们提供全栈SDK接入，还在SDK内置了管控的机制，利用各个APP内终端计算的能力，大大节省成本;而且根据合规要求不能上报的埋点就可以直接在SDK端丢弃掉;数据收集：数据收集一般是提供HTTP接口，将上报的数据存到消息队列。而埋点数据量特别大，于是我们进行了埋点聚合，将埋点的Event数据聚合成Applog数据一起上报。数据进入到Applog后通过自研的实时数据处理平台来解析。实时动态处理引擎

文章图片
上图是我们自研的实时数据平台架构，该平台主要解决两方面的问题：
实时处理：快速处理大量数据;动态化：字节跳动服务规模巨大，重启时间过长会导致下游断流，因此我们的实时领域里不接受重启。此外，逻辑有任何修改都要重启，在大量的业务和逻辑下这是不可能实现的。所以该平台一定要做到动态化。
动态实时处理引擎在收到实时数据的Applog后将其解析成真正的埋点数据。再通过数据加工，可以转换为其他的(甚至自定义的)数据格式，最后通过数据订阅推送到各应用。
第二种模式是分级。在埋点数据被解析以后，我们会打上标记，然后dump到hdfs不同的路径下。后续Hive进行构建的时候可以区分优先级，优先级高的进入高优队列。 Hive的数据也是分区的，分区的数据可以制定不同的TTL 。这样，数据的TTL和SLA就都能分级了。
第三是强保证。在埋点数据下线前，先将要下线的数据分流到pre-discardHive表中暂存30天。如果在这段时间里没有问题， 30天之后就可以直接下线。
现在，该引擎的处理逻辑、拓扑、函数以及RPC都可以做到动态化。用户对于上游而言，一般是写SQL或者进行界面化操作。因为用户不懂如何处理，我们就需要特定的模型让用户进行适配。于是我们用声明式表达建立统一的逻辑模型让用户直接适配。在引擎上我们还能以插件化的形式支持Flink、Pyjstorm、TCE等多种运行时平台，业务方基于视图表达可以定制化支持业务场景。
Map计算模型
下面介绍下该引擎的逻辑动态性。我们使用的是简单的map模型。

文章图片
数据进来后判断是否是需要的，过滤清洗之后需要的数据进入下游，不需要的数据就丢弃掉。基于Groovy语言的热加载，将语言转换成可执行的逻辑。
拓扑重构
字节跳动的业务新增速度很快，我们希望新增业务下游后也不需要重启。对于业务方来说，用户只关心业务逻辑，运维关心底层稳定性和Job执行效率。但是在实际处理中，一个大的困境在数据源。我们以Kafka为例，每多一个消费者就多一份网络消耗和数据反序列化的计算成本，对Kafka的压力就越大。我们应对的方法原理其实很简单，即基于源数据集来进行重构。