举个例子:一个客户端的文章点赞埋点,描述了一个用户在某一个时间点对某一篇文章进行了点
赞操作,这个埋点经过埋点收集服务进入 ETL 链路,通过 UserAction ETL 处理后,实时地进入推
荐 Joiner 任务中拼接生成样本,更新推荐模型,从而提升用户的使用体验。
如果产出 UserAction 数据的 ETL 链路出现比较大的延迟,就不能在拼接窗口内及时地完成训练样
本的拼接,可能会导致用户体验下降。因此,对于推荐来说,数据流的时效性是比较强的需求。
而推荐模型的迭代和产品埋点的变动都可能导致 UserAction ETL 规则 的变动,如果我们把这个
ETL 规则硬编码在代码中,每次修改都需要升级代码并重启相关的 Flink ETL 任务,这样会影响数
据流的稳定性和数据的时效性,因此这个场景的另一个需求是 ETL 规则的动态更新。
4. 业务场景 -数据分流
抖音的埋点 Topic 晚高峰超过一亿每秒,而下游电商、直播、短视频等不同业务关注的埋点都只
是其中一部分。如果每个业务都分别使用一个 Flink 任务去消费抖音的全量埋点去过滤出自己关注
的埋点,会消耗大量的计算资源,同时也会造成 MQ 集群带宽扇出非常严重,影响 MQ 集群的稳
定性。
因此我们提供了数据分流服务。如何实现?我们使用一个 Flink 任务去消费上游埋点 Topic,通过
在任务中配置分流规则的方式,将各个业务关注的埋点分流到下游的小 Topic 中提供给各业务消
费,减少不必要的资源开销,同时也降低了 MQ 集群出带宽。
分流需求大多对 SLA 有一定要求,断流和数据延迟可能会影响下流的推荐效果、广告收入以及数
据报表更新等。另外随着业务的发展,实时数据需求日益增加,分流规则新增和修改变得非常频
繁,如果每次规则变动都需要修改代码和重启任务会对下游造成较大影响,因此在数据分流这个
场景,规则的动态更新也是比较强的需求。
5. 业务场景 -容灾降级
另一个场景是容灾降级。数据流容灾首先考虑的是防止单个机房级别的故障导致埋点数据流完全
不可用,因此埋点数据流需要支持多机房的容灾部署。其次当出现机房级别的故障时,需要将故
障机房的流量快速调度到可用机房实现服务的容灾恢复,因此需要埋点数据流具备机房间快速切
流的能力。
评论0
最新资源