实时标签接入大概分为一个规范和三类 Flink 工具任务 。 规范指实时标签计算后写入指定 Kafka Topic 规范 。 三类 Flink 工具任务指 1. cuid->guid mapping 过程 。 2.根据标签类型进行数据分发 。 3.各标签数据独立写入到 StarRocks 表 。 注意全流程按照 cuid 做 kafka partition 分区保证顺序 。
（1）接入规范
标签计算类任务将标签结果统一输出为如下格式 ， 写入指定 kafka topic ， 并按照 cuid 分区 。
- {"header":{"type":"", "cuid":"cuid"}, "body":{"xxx":"xxx",...}}type 表是标签类型 ， 全局唯一 。 sys_offline_cuid、sys_cguid_mapping 为 type 保留字用补数和新映射数据输出 。
（2）mapping 过程
mapping 过程逻辑非常简单就是获取全局自增数值型 guid 和 cuid 形成一一映射关系 。 此过程大体存在如下几步 1.查 task LRU 堆外内存 2.内存不存在查 codis 3.codis 不存在通过发号器取新号 4.逐层缓存 mapping 信息 。
此过程稳定性是整个系统的关键 ， 结合作业帮已有的发号器和 codis 能力作为选型的主要参考 。 利用发号器产生全局唯一自增数值 id guid ， 利用 codis 存储 cuid 与 guid 关系 。 为保证一一映射关系将 mapping 过程设计为一个 flink 任务 。 思考如下：
业务实际情况：
cuid 总量十亿级 ， 日增百万高峰期每小时新增 20W 每秒 30+ 。 全量实时标签数据最高 10W qps
理论资源测算：
- 发号器：默认支持 3W qps ， 数据第一次初始化耗时十几个小时 ， 之后最高 qps 不需额外资源即可满足需求 。
- codis：十亿级 mapping 数据存储约 200G【未考虑 buffer 部分】 ， 12 个 pod 每个 pod 16G 内存大约可支持 50W qps 。
- flink 任务：
计算由近 N 个月活跃 cuid mapping 总内存占用除以每个 task 500M 到 1G 堆外内存得到数值 A ， 和上游 kafka 数据 10W qps 除以在确定内存命中率时单个 task 可处理的 qps 得到数值 B ， 然后可算出 flink 并行度 max(A, B) + 对业务预期发展给予一定 buffer 决定 。
上游 kafka topic 需按照 cuid 分区并且分区数最好为 flink 并行度的 3 倍以上【取决于后续新增标签数据量】 。
任务重启后对 codis 产生的最大 qps 小于 10W ， 如果 flink task LRU 缓存足够平时 codis qps 最高基本在万级别以内 ， 就目前 codis 资源配置已满足需求 。
任务本身只关注 cuid ， 除 cuid 以外数据可不做解析 。
潜在风险思考：
- 数据延迟：因使用场景更多用于触达 ， 一定程度的延迟可以接受 ， 较大延迟触发报警暂停触达 。
- cuid 脏数据 ， 当 guid 超过 Integer.MAX_VALUE 后 StarRocks bitmap 查询性能下降 。 增加 cuid 严格校验逻辑 ， 根据业务实际情况设置每天 cuid 增量监控 ， 超过后人工排查 ， 如果 cuid 脏数据不多时可不做处理 ， 因错误 cuid 并不会收到触达信息 。 如果 cuid 脏数据较多时需要重置发号器位置并恢复到某一时间点数据后重刷全部标签、人群包数据 。
特别声明：本站内容均来自网友提供或互联网，仅供参考，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，我们将在24小时内删除。