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

京东⼴告计费系统的架构演进京东⼴告计费系统的架构演进01背景介绍02 三个阶段03 未来重⼼⼀、背景介绍日志系统中间一环数据仓库的建设IO密集计算任务事件驱动型按C、M和A计费系统本质数据链路下游广告物料的召回播放、报表的时效性广告系统数据一致性要求高吞吐量高低延迟京东⼴告业务特点账户体系复杂各种模式下的子账户结构各个层级下的专款专用营销模式多元导致的多种资金类型站内广告玩法丰富预算多种多样，多种级别的预算控制。计划和活动等层级的预算玩法。起步较早几乎伴随着国内的大数据浪潮而兴起站外媒体模式多直投模式头条及快手业务模式复杂GD/PD等模式对接腾讯广告的深度结合如何衡量⼴告计费系统？指标单位受何影响稳定篇应用级一致性保障强/弱/最终网络/宕机/系统设计等系统可用性百分比系统上下线/宕机等性能篇系统平均吞吐事件数每秒系统设计系统峰值吞吐事件数每秒同上事件平均延时毫秒同上事件延时TP99毫秒同上单账户最高吞吐事件数每秒单账户IO账户操作响应时长TP99等同上青铜时代从零到⼀2014年-2017年⽩银时代性能跃升2017年-2020年黄⾦时代⾛向⼀致2020年-⾄今⼆、京东⼴告系统演进的三个阶段青铜时代数据链路Stream

SystemCPC

BillingFinanceServerData

WarehouseB1B2EPost-anti

clickBilled

click

blockBilled

impression

blockPost-anti

refund

clickPost-antiimpressionIOinteractionDA1A2B1CDA1A2CPM

BillingRealtimeReportReport

EngineMySQLRedisHBaseBudgetDedupeCostStream

SystemB1A1A2CECData

Mining⼩结13快速搭建并交付了⼀套系统财务与统计完全分离。独⽴的事件计费处理，不容易互相影响基本满⾜业务需求2白银时代直⾯问题性能出现瓶颈任务不稳定，经常延时数据质量较差问题摸排效率低性能提升反范式的设计基于乐观锁的计费流式的设计财务扣费数据保障应⽤⼀致性校验与保证完备的全链路监控问题Problems方案Solution解决问题性能出现瓶颈任务不稳定，经常延时数据质量较差问题摸排效率低性能提升数据链路上任务的整合反范式的设计基于乐观锁的计费流式的设计财务扣费数据保障应⽤⼀致性校验与保证完备的全链路监控问题Problems方案Solution数据链路Stream

SystemFinance

PlatformBillingFinance

Operation

ServiceFinanceServiceBilling

/

Finance

StatesBudFinDedupBalBatch

ReportBudgetServiceReport

Engine

/

JST

/

Various

Down-streamsFinance

Settle

ServiceJD

Settle

PlatformBudget

Operation

ServiceDelivery

PlatformB1B2B1B2Post-anti

clickPost-anti

refund

clickBilledclickCBilling

failed

clickPost-anti

impressionBilled

impressionBilling

failed

impressionDA3ConfA1A2A3CDA1A2CampaignOfflineAccountOffline乐观式上锁的扣费AccountFinanceServiceBilling

SystemDeposit/Withdraw֗᷇Deductṛ᷇场景说明处理流程图Lock

AccountDeduct

according

MapRead

to

Sync?<Account

Modified

?Rewind

the

accountLocal

Exists?Fetch

From

remote1<<CommitStartEnd1Fetch

and

update

Local保证最终⼀致性的统计系统Lambda架构实时系统尽⼒写库，不保证准确性批式系统按⽇调度，保证数据最终⼀致系统描述实时系统：以实时读到的数据，追写数据⾄DB批式系统：以HDFS数据为基准，重新计算并覆写数据⾄DB两阶段提交预写阶段：先写数据⾄HDFS，再追写⾄数据库提交阶段：写HDFS成功即进⼊提交阶段，将offset提交⾄持久化存储RealtimeReportReportIncr

Micro-BatchBatch

ReportStreaming

SystemABPost-anti

clickPost-anti

impressionABMeta

Data1:SUH–FRPPiW2:FRPPiWReport

Engine基于BloomFilter的⽇志去重slot管理模块提交管理：每5k条日志提交一次P：误判概率N：存储数据条目位图slot大小预估ln

𝑃𝒎

=

−𝑛

ln

2

)

≈

𝟏.

𝟏MB整体思想多worker节点

+

哈希

+

bucket容量管理

+

slot提交管理每个slot对应一个bloom-filter，且限制了每个slot容量的上限对桶内slot遍历探查并更新是否重复bucket容量管理模块弹性扩容管理：对slot容量探查，当发现当前slot容量已满时，申请新的slot按每两小时划分slot过期管理：每个slot根据创建时间自动过期基本面分析即不考虑弹性扩容的前提下可行性分析每两小时承载10亿日志内存分析单个worker约占用

660MB内存性能分析多次哈希计算

+批量提交（30ms）Bucket

0Slot0Slot1……Bucket

1Slot0……Bucket

49Slot0Slot1hash(id)Slot1Slot

Pagename:WDVN,G

+EXFNHW,G+KRXU+QRBloom

bitmapBloom-Filter

bitmapCountCommit-tmDedup

WorkerDedupWorker

Dedup

WorkerKafka

Sourceshuffle(id)……全链路监控AppsBillingRealtimeReportFinanceServerMQ……PipelineLogstashLogstashLogstash……ElasticClusterElasticsearchNode3VisualizeGrafanaElasticsearchNode2ElasticsearchNode1⼩结性能跃进解决了性能上的问题，稳定度过多个⼤促可用性提升模块间职责更加清晰，也更加独⽴，使得各个模块更加稳定链路延迟降低有效降低了数据链路延迟，度过了⼤促的考验链路监控丰富的各项指标，实时全盘掌握系统状态01020304黄金时代直⾯问题复杂的站外模式带来的技术对接链路上的数据丢失或重复问题机器宕机导致的数据丢失重放时导致的数据重复核⼼数据的⼀致性保证流式和批式计费⽀持基于Flink流批⼀体化的API链路Exactly

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

Once的设计与实现Kafka事务⽀持两阶段提交持久化的KV存储基于Raft协议的强⼀致实现问题Problems方案Solution流批⼀体的处理得益于Flink的流批⼀体处理接⼜，更⾼的可维护性统⼀的处理流程减少部分业务代码的开发，提升业务迭代的效率Files%DWFKBilling

SystemFilesEventsEvents多制式计费⽀持%DWFKStreamStreamConfFinBudDedupBal强⼀致的分布式KV系统ClientMasterz=3State

MachineConsensusModule1:]=37:VXFFHVVSlavex=1y=2z=3State

MachineConsensusModuleSlavez=3State

MachineConsensusModuleBinlogBinlogBinlog2:]=33:]=33:]=3x=1y=2z=3x=1y=2z=35:DFN4:]=34:]=35:DFN6:flXVK

]=38:flXVK

]=38:flXVK

]=3基于Pika的分布式KV存储兼容Redis协议，数据结构灵活强⼀致的实现基于Raft协议的标准实现流量管理模块的⼀致性实现Exactly

Once模式

+

Kafka事务提交KafkaSinkx1x2x3y1y2y3Checkpoint

Coordinator%1%1KafkaSinkCheckpoint

Coordinator%1%1KafkaSinkCheckpoint

Coordinator1RWiI\

%1TransactionCoordinator%HJiQTransactionCoordinatorZUiWHTransactionCoordinatorx1x2x3y1y2y3&RPPiW⼩结一致性打造了强⼀致的分布式系统，保证异常情况下重要数据的不丢失多制式实现了流批⼀体的计费系统。减