京东广告计费架构演进之路

1.

2. 京东广告计费系统的架构演进

3. 哲学三问我是谁？刘军。对数据库内核开发、分布式系统及分布式计算有浓烈兴趣的人。我从哪里来？ 2016年加入京东商业提升事业部-广告数据部。现为京东-数据算法通道的一名高级工程师。负责并搭建过广告日志系统、广告计费系统、离线数据处理等。我要到哪里去……

4. 京东广告计费系统的架构演进 01 背景介绍 02 三个阶段 03 未来重心

5. 一、背景介绍系统本质 1. IO密集计算任务 2. 事件驱动型 3. 按C、M和A计费系统要求 1. 数据一致性要求高 2. 吞吐量高 3. 低延迟数据链路 1. 日志系统中间一环 2. 数据仓库的建设广告系统 1. 下游广告物料的召回 2. 播放、报表的时效性

6. 京东广告业务特点起步较早站内广告玩法丰富几乎伴随着国内的大数据浪潮预算多种多样，多种级别的预而兴起算控制。计划和活动等层级的预算玩法。站外媒体模式多账户体系复杂 1. 直投模式 1. 各种模式下的子账户结构 2. 头条及快手业务模式复杂 2. 各个层级下的专款专用 3. GD/PD等模式对接 3. 营销模式多元导致的多种资 4. 腾讯广告的深度结合金类型

7. 如何衡量广告计费系统？指标稳定篇性能篇单位受何影响应用级一致性保障强/弱/最终网络/宕机/系统设计等系统可用性百分比系统上下线/宕机等系统平均吞吐事件数每秒系统设计系统峰值吞吐事件数每秒同上事件平均延时毫秒同上事件延时TP99 毫秒同上单账户最高吞吐事件数每秒单账户IO 账户操作响应时长 TP99等同上

8. 二、京东广告系统演进的三个阶段青铜时代从零到一 2014年-2017年白银时代性能跃升 2017年-2020年黄金时代走向一致 2020年-至今

9. 青铜时代

10. 数据链路 Stream System Stream System B1 A1 A2 CPC Billing B1 C C A1 CPM Billing Realtime Report B2 D Finance Server Cost Budget Dedupe E MySQL A1 Post-anti click A2 Post-anti refund click B1 Post-anti impression C IO interaction D Billed click block E Billed impression block A2 Redis Data Warehouse Report Engine Data Mining HBase

11. 小结 2 1 快速搭建并交付了一套系统基本满足业务需求 3 财务与统计完全分离。独立的事件计费处理，不容易互相影响

12. 白银时代

13. 直面问题问题 Problems • 性能出现瓶颈方案 Solution • 性能提升 • 任务不稳定，经常延时 • 反范式的设计 • 数据质量较差 • 基于乐观锁的计费 • 问题摸排效率低 • 流式的设计 • 财务扣费数据保障 • • 应用一致性校验与保证完备的全链路监控

14. 解决问题问题 Problems • 性能出现瓶颈方案 Solution • 性能提升 • 任务不稳定，经常延时 • 数据链路上任务的整合 • 数据质量较差 • 反范式的设计 • 基于乐观锁的计费 • 问题摸排效率低 • 流式的设计 • 财务扣费数据保障 • • 应用一致性校验与保证完备的全链路监控

15. Delivery 数据链路 Stream System Budget Operation Service Budget Service A1 A2 B1 Billing / Finance States Bud Fin C Conf Dedup Bal D Billing A3 Finance Operation Service B2 Account Offline Finance Service Campaign Offline Finance Settle Service JD Settle Platform Batch Report A1 Post-anti click B1 Post-anti impression A2 Post-anti refund click B2 Billed impression A3 Billed click D Billing failed impression C Billing failed click Report Engine / JST / Various Down-streams

16. 乐观式上锁的扣费处理流程图场景说明 Fetch From remote Finance Service Start Local Exists? Deduct according Map Fetch and update Local Read to Sync? Rewind the account Lock Account Account Deduct Billing System Account Modified ? Commit End

17. 保证最终一致性的统计系统 Lambda架构 1. 2. B A Realtime Report Report Incr Micro- Batch A Post-anti click B Post-anti impression Batch Report Meta Data 实时系统尽力写库，不保证准确性批式系统按日调度，保证数据最终一致系统描述实时系统：以实时读到的数据，追写数据至DB 批式系统：以HDFS数据为基准，重新计算并覆写数据至DB 两阶段提交预写阶段：先写数据至HDFS，再追写至数据库提交阶段：写 HDFS成功即进入提交阶段，将 offset提交至持久化存储

18. 基于BloomFilter的日志去重整体思想 Bucket 0 Slot0 Kafka Source hash(id) 多worker节点 + 哈希 + bucket容量管理 + slot提交管理 2. 每个slot对应一个bloom-filter，且限制了每个slot容量的上限 3. 对桶内slot遍历探查并更新是否重复 Slot1 …… shuﬄe(id) 1. bucket容量管理模块弹性扩容管理：对slot容量探查，当发现当前slot容量已满时，申请新的slot 按每两小时划分slot Dedup Worker Dedup Worker Dedup Worker Bucket 1 Slot0 …… …… Slot Page name: slot管理模块基本面分析提交管理：每5k条日志提交一次即不考虑弹性扩容的前提下 P：误判概率可行性分析 N：存储数据条目每两小时承载10亿日志内存分析 Bucket 49 Bloom Bloom-Filter bitmap bitmap 过期管理：每个slot根据创建时间自动过期位图slot大小预估 Slot0 Count Slot1 Commit-tm Slot1 𝒎 = −𝑛 ln 𝑃 ≈ 𝟏. 𝟏MB ln 2 ) 单个worker约占用 660MB内存性能分析多次哈希计算 +批量提交（30ms）

19. 全链路监控 Apps Pipeline Billing Logstash ElasticCluster Elasticsearch Node1 Finance Server MQ Logstash …… …… Realtime Report Logstash Elasticsearch Node2 Elasticsearch Node3 Visualize Grafana

20. 小结 01 02 03 04 性能跃进解决了性能上的问题，稳定度过多个大促可用性提升模块间职责更加清晰，也更加独立，使得各个模块更加稳定链路延迟降低有效降低了数据链路延迟，度过了大促的考验链路监控丰富的各项指标，实时全盘掌握系统状态

21. 黄金时代

22. 直面问题问题 Problems • 复杂的站外模式带来的技术对接方案 Solution • • 链路上的数据丢失或重复问题 • 机器宕机导致的数据丢失 • 重放时导致的数据重复流式和批式计费支持 • • • 核心数据的一致性保证 • 基于Flink流批一体化的API 链路Exactly Once的设计与实现 • Kafka事务支持 • 两阶段提交持久化的KV存储 • 基于Raft协议的强一致实现

23. 解决问题问题 Problems • 复杂的站外模式带来的技术对接方案 Solution • • 链路上的数据丢失或重复问题 • 机器宕机导致的数据丢失 • 重放时导致的数据重复流式和批式计费支持 • • • 核心数据的一致性保证 • 基于Flink流批一体化的API 链路Exactly Once的设计与实现 • Kafka事务支持 • 两阶段提交持久化的KV存储 • 基于Raft协议的强一致实现

24. 多制式计费支持 Stream Events Files 流批一体的处理得益于Flink的流批一体处理接又，更高的可维护性 Bud Fin Billing System Conf Dedup 统一的处理流程 Bal 减少部分业务代码的开发，提升业务迭代的效率 Files Events Stream

25. 强一致的分布式KV系统 Master State Machine 基于Pika的分布式KV存储 Client Binlog 兼容Redis协议，数据结构灵活 Consensus Module x=1 y=2 z=3 Slave 强一致的实现基于Raft协议的标准实现 Consensus Module x=1 y=2 z=3 Slave Consensus Module Binlog State Machine x=1 y=2 Binlog State Machine z=3

26. 流量管理模块的一致性实现 Exactly Once模式 + Kafka事务提交 Checkpoint Coordinator Checkpoint Coordinator x2 y3 x3 y1 y2 y3 Checkpoint Coordinator Transaction Coordinator x1 KafkaSink y2 x2 Transaction Coordinator Transaction Coordinator x3 x1 y1 KafkaSink KafkaSink

27. 小结一致性多制式端到端打造了强一致的实现了流批一体结合Flink的两阶段分布式系统，保的计费系统。减提交以及事务特性，证异常情况下重小业务迭代的开部分实现了端到端要数据的不丢失发量的一致性

28. 未来重心 • 彻底解决端到端的一致性 • 日志的跨机房容灾等 • 更低的数据链路延迟 • 持续的系统优化，提高整体吞吐

29. 个人感悟 1. 渐进式的架构演进 2. 每个系统都有自己独特的特性 u 如同CAP理论、蒙代尔不可能三角。不要想实现一个大而完美的系统 u 比认识应用什么最重要的更关键的是系统什么特性是可以牺牲的 3. 好的系统应该是高内聚、低耦合的 4. 对系统特性的抽象描述应谨慎，尽量避免太过泛化的抽象 u 什么都能做的系统，通常什么都做不好

30. Q & A

31.

32. 流量管理模块的一致性实现去重部分实现 v0 1. 2. 3. 4. X1 v0 X2 X3 v0 v0 x1 x2 X3 Remote Dedup State 流式处理每个事件对于每个事件进行Fetch&Write操作记录每个事件ID时记录当前全局版本号当Fetch出的版本号高于当前的全局版本号