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

文章图片
相同SLA下的业务线，只要用了相同的source ，就可以把拓扑重构为新的模型。拓扑重构之后，用户侧无感知， SLA也没有打破，但是效率确实成倍提升，而且对于上游Kafka的压力小了许多。
实时动态处理引擎整体架构

文章图片
我们希望这个引擎是一个会变形的引擎。上游用户可以通过SQL、图形化/界面化配置，我们可以根据schema产生的catalog生成一个通用的自定义逻辑规则。之后用户还会对逻辑规则进行修改，比如进行校验或函数重构，我们再会转换成用户的物理规则(physicalrule) ，我们现在是使用Groovy进行转换。转换成物理规则之后，还有其他一些问题要处理。
首先是动态化，包括：
UDF动态化：我们期望UDF改变也不用重启，所以UDF需要进行动态化编译。拓扑重构动态化：重构之后拓扑改变，需要新的拓扑结构。 RPC动态化：可以加载动态的函数。
这些配置更新以后，经过Planbuilder生成JobGraph ，引擎再拉取配置。
这时也有一个问题：我们的规则非常多，不能因为一条规则的更改就更新所有规则。所以我们做的是增量更新，只对有需要的规则进行更新。
引擎拉取之后，会加载新的资源(RPC、Schema) ，并进行拓扑重构以及编译。因为之前给到的是一些Groovy的代码片段，用户可以将其热编译为物理规则。
此外我们还做了很多细致的工作，例如Objectcatch 。举个例子：大部分埋点上报的是String格式的Json数据，用户在进行数据清洗时就需要将String反序列化为Jsonobject ，如果用户在规则中多次用到该Jsonobject就会导致多次反序列化计算。因此，我们将反序列化后的object进行缓存，这样再次使用时就可以直接使用，避免重复反序列化成本。
Q&A
Q：新增埋点之后不用重启，那多久会生效，如何保证生效?
A：我们对用户承诺的SLA是2分钟生效。因为实时动态引擎是动态获取数据的过程，可以更高频地感知变化。在变化完成之后，我们是增量修改，修改的频率也更低。
如何能保证新增埋点生效?前面提到了重视SLA 。 SLA不一样，资源的利用率也就不一样。此外埋点也不可能无限加，当资源利用率达到一定的阈值之后，就需要扩容。资源不足的问题没有办法解决，只能重启。
Q：资源是先申请到位再重启吗?
A：在我们这边是的，资源申请到位后才会进行对应的重启。同时我们的开发套件会进行增量重启，也就是不会一次把所有服务节点全部重启，一次只会对有问题的部分(比如10%的服务节点)进行重启，把限度降到最低。但是在大数据量下，重启执行的运维成本依然很高。
Q：平台上的埋点开发代码模版可以复用吗?
A：一般不会复用。不同语言的模版肯定不同，不同产品的工程团队风格要求也不一样，也需要定制，所以模版几乎不会被复用。
Q：埋点的丢失和重复上报的问题是怎么处理的?
A：对于丢失数据的处理分两个方面：
端上日志：上报数据失败后会进行重试，并且端上有监控，可以了解当前客户端上报的情况。
服务端的丢失，我们也有对应的监控，这时候丢失有几种情况：
脏数据：没有通过判断校验逻辑的数据不会直接丢弃，而是分到一个dirty流，可以重新找回。特殊逻辑：比如风控逻辑。
重复上报的问题很少遇到，更多的是重启之后重新消费Kafka的offset不是那么精准。但我们的引擎是动态的，不需要重启，就避免了这个问题。