回调逻辑拆分
2021-11-08 17:13:36 56 举报
回调逻辑拆分
作者其他创作
大纲/内容
firstday - event_time 超过 1 天,小于180天
判断1
firstday
是
event_time 和 firstday 时间差在 1 天以内
判断0
否
1d
关联渠道优先级
Flink 归因任务
180d
自然流量
client_app_attribute_callbacked
判断2
client_app_attribute
当前渠道优先级更高
判断3
查 user_base 表
方案说明: Flink 处理回调数据存在问题: 1. Flink 内所有逻辑均不能存在异常,出现异常 Flink 会重新处理,直到全部算子执行成功。有时可能会因为外部原因导致的运行时异常而持续反复地处理同一批数据,造成后续数据堆积。 2. Flink 的高可用主要通过容错机制和自动重启任务的方式,面向数据处理保证数据不丢失。但很难做到任务的多实例部署。万一任务在初始化阶段卡住且没有及时处理就会导致数据堆积,不适合回调这类无法容忍数据延迟的业务需求。 改进方案: 将原本放在 Flink 内部的归因判断逻辑分离出来,使回调和入库两个步骤解耦,并且当归因逻辑因外部因素无法执行时(查询的 Kudu 表不可用),通过全量回调保证回调的数量和及时性,再通过后续的 Flink 任务来保证数据库中归因结果的正确性。 技术选型: 1. java 编写: 优势:客户端框架成熟,不依赖系统环境,归因逻辑可通过公共库统一维护。 缺点:与其他业务代码语言不统一。 2. python 编写: 优势:与其他业务代码语言统一。 缺点:kudu 查询依赖操作系统环境,业务变动需要两人维护。
event_time - firstday超过180天
发送 callback
查到数据
0 条评论
回复 删除
下一页