京東廣告計(jì)費(fèi)系統(tǒng)的架構(gòu)演進(jìn)

京東?告計(jì)費(fèi)系統(tǒng)的架構(gòu)演進(jìn)京東?告計(jì)費(fèi)系統(tǒng)的架構(gòu)演進(jìn)01背景介紹02 三個(gè)階段03 未來重??、背景介紹日志系統(tǒng)中間一環(huán)數(shù)據(jù)倉庫的建設(shè)IO密集計(jì)算任務(wù)事件驅(qū)動(dòng)型按C、M和A計(jì)費(fèi)系統(tǒng)本質(zhì)數(shù)據(jù)鏈路下游廣告物料的召回播放、報(bào)表的時(shí)效性廣告系統(tǒng)數(shù)據(jù)一致性要求高吞吐量高低延遲京東?告業(yè)務(wù)特點(diǎn)賬戶體系復(fù)雜各種模式下的子賬戶結(jié)構(gòu)各個(gè)層級(jí)下的?？顚Ｓ脿I銷模式多元導(dǎo)致的多種資金類型站內(nèi)廣告玩法豐富預(yù)算多種多樣，多種級(jí)別的預(yù)算控制。計(jì)劃和活動(dòng)等層級(jí)的預(yù)算玩法。起步較早幾乎伴隨著國內(nèi)的大數(shù)據(jù)浪潮而興起站外媒體模式多直投模式頭條及快手業(yè)務(wù)模式復(fù)雜GD/PD等模式對(duì)接騰訊廣告的深度結(jié)合如何衡量?告計(jì)費(fèi)系統(tǒng)？指標(biāo)單位受何影響穩(wěn)定篇應(yīng)用級(jí)一致性保障強(qiáng)/弱/最終網(wǎng)絡(luò)/宕機(jī)/系統(tǒng)設(shè)計(jì)等系統(tǒng)可用性百分比系統(tǒng)上下線/宕機(jī)等性能篇系統(tǒng)平均吞吐事件數(shù)每秒系統(tǒng)設(shè)計(jì)系統(tǒng)峰值吞吐事件數(shù)每秒同上事件平均延時(shí)毫秒同上事件延時(shí)TP99毫秒同上單賬戶最高吞吐事件數(shù)每秒單賬戶IO賬戶操作響應(yīng)時(shí)長TP99等同上青銅時(shí)代從零到?2014年-2017年?銀時(shí)代性能躍升2017年-2020年黃?時(shí)代?向?致2020年-?今?、京東?告系統(tǒng)演進(jìn)的三個(gè)階段青銅時(shí)代數(shù)據(jù)鏈路Stream

SystemCPC

BillingFinanceServerData

WarehouseB1B2EPost-anti

clickBilled

click

blockBilled

impression

blockPost-anti

refund

clickPost-antiimpressionIOinteractionDA1A2B1CDA1A2CPM

BillingRealtimeReportReport

EngineMySQLRedisHBaseBudgetDedupeCostStream

SystemB1A1A2CECData

Mining?結(jié)13快速搭建并交付了?套系統(tǒng)財(cái)務(wù)與統(tǒng)計(jì)完全分離。獨(dú)?的事件計(jì)費(fèi)處理，不容易互相影響基本滿?業(yè)務(wù)需求2白銀時(shí)代直?問題性能出現(xiàn)瓶頸任務(wù)不穩(wěn)定，經(jīng)常延時(shí)數(shù)據(jù)質(zhì)量較差問題摸排效率低性能提升反范式的設(shè)計(jì)基于樂觀鎖的計(jì)費(fèi)流式的設(shè)計(jì)財(cái)務(wù)扣費(fèi)數(shù)據(jù)保障應(yīng)??致性校驗(yàn)與保證完備的全鏈路監(jiān)控問題Problems方案Solution解決問題性能出現(xiàn)瓶頸任務(wù)不穩(wěn)定，經(jīng)常延時(shí)數(shù)據(jù)質(zhì)量較差問題摸排效率低性能提升數(shù)據(jù)鏈路上任務(wù)的整合反范式的設(shè)計(jì)基于樂觀鎖的計(jì)費(fèi)流式的設(shè)計(jì)財(cái)務(wù)扣費(fèi)數(shù)據(jù)保障應(yīng)??致性校驗(yàn)與保證完備的全鏈路監(jiān)控問題Problems方案Solution數(shù)據(jù)鏈路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樂觀式上鎖的扣費(fèi)AccountFinanceServiceBilling

SystemDeposit/Withdraw??Deduct??場(chǎng)景說明處理流程圖Lock

AccountDeduct

according

MapRead

to

Sync?<Account

Modified

?Rewind

the

accountLocal

Exists?Fetch

From

remote1<<CommitStartEnd1Fetch

and

update

Local保證最終?致性的統(tǒng)計(jì)系統(tǒng)Lambda架構(gòu)實(shí)時(shí)系統(tǒng)盡?寫庫，不保證準(zhǔn)確性批式系統(tǒng)按?調(diào)度，保證數(shù)據(jù)最終?致系統(tǒng)描述實(shí)時(shí)系統(tǒng)：以實(shí)時(shí)讀到的數(shù)據(jù)，追寫數(shù)據(jù)?DB批式系統(tǒng)：以HDFS數(shù)據(jù)為基準(zhǔn)，重新計(jì)算并覆寫數(shù)據(jù)?DB兩階段提交預(yù)寫階段：先寫數(shù)據(jù)?HDFS，再追寫?數(shù)據(jù)庫提交階段：寫HDFS成功即進(jìn)?提交階段，將offset提交?持久化存儲(chǔ)RealtimeReportReportIncr

Micro-BatchBatch

ReportStreaming

SystemABPost-anti

clickPost-anti

impressionABMeta

Data1:SUH–FRPPiW2:FRPPiWReport

Engine基于BloomFilter的?志去重slot管理模塊提交管理：每5k條日志提交一次P：誤判概率N：存儲(chǔ)數(shù)據(jù)條目位圖slot大小預(yù)估ln

????

=

???

ln

2

)

≈

??.

??MB整體思想多worker節(jié)點(diǎn)

+

哈希

+

bucket容量管理

+

slot提交管理每個(gè)slot對(duì)應(yīng)一個(gè)bloom-filter，且限制了每個(gè)slot容量的上限對(duì)桶內(nèi)slot遍歷探查并更新是否重復(fù)bucket容量管理模塊彈性擴(kuò)容管理：對(duì)slot容量探查，當(dāng)發(fā)現(xiàn)當(dāng)前slot容量已滿時(shí)，申請(qǐng)新的slot按每兩小時(shí)劃分slot過期管理：每個(gè)slot根據(jù)創(chuàng)建時(shí)間自動(dòng)過期基本面分析即不考慮彈性擴(kuò)容的前提下可行性分析每兩小時(shí)承載10億日志內(nèi)存分析單個(gè)worker約占用

660MB內(nèi)存性能分析多次哈希計(jì)算

+批量提交（30ms）Bucket

0Slot0Slot1……Bucket

1Slot0……Bucket

49Slot0Slot1hash(id)Slot1Slot

Pagename:WDVN,G

+EXFNHW,G+KRXU+QRBloom

bitmapBloom-Filter

bitmapCountCommit-tmDedup

WorkerDedupWorker

Dedup

WorkerKafka

Sourceshu?e(id)……全鏈路監(jiān)控AppsBillingRealtimeReportFinanceServerMQ……PipelineLogstashLogstashLogstash……ElasticClusterElasticsearchNode3VisualizeGrafanaElasticsearchNode2ElasticsearchNode1?結(jié)性能躍進(jìn)解決了性能上的問題，穩(wěn)定度過多個(gè)?促可用性提升模塊間職責(zé)更加清晰，也更加獨(dú)?，使得各個(gè)模塊更加穩(wěn)定鏈路延遲降低有效降低了數(shù)據(jù)鏈路延遲，度過了?促的考驗(yàn)鏈路監(jiān)控豐富的各項(xiàng)指標(biāo)，實(shí)時(shí)全盤掌握系統(tǒng)狀態(tài)01020304黃金時(shí)代直?問題復(fù)雜的站外模式帶來的技術(shù)對(duì)接鏈路上的數(shù)據(jù)丟失或重復(fù)問題機(jī)器宕機(jī)導(dǎo)致的數(shù)據(jù)丟失重放時(shí)導(dǎo)致的數(shù)據(jù)重復(fù)核?數(shù)據(jù)的?致性保證流式和批式計(jì)費(fèi)?持基于Flink流批?體化的API鏈路Exactly

Once的設(shè)計(jì)與實(shí)現(xiàn)Kafka事務(wù)?持兩階段提交持久化的KV存儲(chǔ)基于Raft協(xié)議的強(qiáng)?致實(shí)現(xiàn)問題Problems方案Solution解決問題復(fù)雜的站外模式帶來的技術(shù)對(duì)接鏈路上的數(shù)據(jù)丟失或重復(fù)問題機(jī)器宕機(jī)導(dǎo)致的數(shù)據(jù)丟失重放時(shí)導(dǎo)致的數(shù)據(jù)重復(fù)核?數(shù)據(jù)的?致性保證流式和批式計(jì)費(fèi)?持基于Flink流批?體化的API鏈路Exactly

Once的設(shè)計(jì)與實(shí)現(xiàn)Kafka事務(wù)?持兩階段提交持久化的KV存儲(chǔ)基于Raft協(xié)議的強(qiáng)?致實(shí)現(xiàn)問題Problems方案Solution流批?體的處理得益于Flink的流批?體處理接?，更?的可維護(hù)性統(tǒng)?的處理流程減少部分業(yè)務(wù)代碼的開發(fā)，提升業(yè)務(wù)迭代的效率Files%DWFKBilling

SystemFilesEventsEvents多制式計(jì)費(fèi)?持%DWFKStreamStreamConfFinBudDedupBal強(qiáng)?致的分布式KV系統(tǒng)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存儲(chǔ)兼容Redis協(xié)議，數(shù)據(jù)結(jié)構(gòu)靈活強(qiáng)?致的實(shí)現(xiàn)基于Raft協(xié)議的標(biāo)準(zhǔn)實(shí)現(xiàn)流量管理模塊的?致性實(shí)現(xiàn)Exactly

Once模式

+

Kafka事務(wù)提交KafkaSinkx1x2x3y1y2y3Checkpoint

Coordinator%1%1KafkaSinkCheckpoint

Coordinator%1%1KafkaSinkCheckpoint

Coordinator1RWiI\

%1TransactionCoordinator%HJiQTransactionCoordinatorZUiWHTransactionCoordinatorx1x2x3y1y2y3&RPPiW?結(jié)一致性打造了強(qiáng)?致的分布式系統(tǒng)，保證異常情況下重要數(shù)據(jù)的不丟失多制式實(shí)現(xiàn)了流批?體的計(jì)費(fèi)系統(tǒng)。減