淘寶分布式大數(shù)據(jù)及實時流數(shù)據(jù)技術(shù)架構(gòu)

淘寶分布式大數(shù)據(jù)及實時流數(shù)據(jù)技術(shù)架構(gòu)提綱? 背景? 目標(biāo)? 傳統(tǒng)方案與業(yè)界進(jìn)展? 設(shè)計理念(重點)? 技術(shù)架構(gòu)? 要點? 例子? 系統(tǒng)邊界? 計劃背景? 應(yīng)用背景–

數(shù)據(jù)量急劇增加–

Web

1.0

web

2.0,

publicego

net–

電子商務(wù)、移動互聯(lián)網(wǎng)、移動支付–

欺詐、風(fēng)控對海量交易實時性–

用戶體驗的個性化和實時性–

由點到面?

實時搜索、個人實時信息服務(wù)、SNS等背景? 技術(shù)背景MapReduce、Dryad等全量/增量計算平臺–

S4、Storm等流計算框架CEP以及EDA模型Pregel等圖計算模型傳統(tǒng)方案與業(yè)界進(jìn)展? 傳統(tǒng)方案–

MAPREDUCE：HDFS加載，存儲LOCALITY(容錯性)，順序IO，存儲HDFS， 單輸入，單輸出獨立數(shù)據(jù)Di Latency(i)輸入輸入計算過程下載Mapshuffle輸出獨立數(shù)據(jù)DnlatencyLatency(n)reduceMapreduce

JobIProcess

JobHadoop之于實時? 問題(hadoop本質(zhì)是為全量而生)–

任務(wù)內(nèi)串行–

重吞吐量，響應(yīng)時間完全沒有保證–

中間結(jié)果不可見，不可共享–

單輸入單輸出，鏈?zhǔn)嚼速M嚴(yán)重–

鏈?zhǔn)組R不能并行–

粗粒度容錯，可能會造成陷阱–

圖計算不友好–

迭代計算不友好圖計算? MapReduce為什么不適合圖計算?–

迭代–

邊的量級遠(yuǎn)大于節(jié)點? 圖計算特點–

適應(yīng)于事件機(jī)制，規(guī)模大(邊)，但單條數(shù)據(jù)不大–

很難分布式(locality、partition，一直都是難點)–

容錯性Google

Pregel?

本質(zhì)上還是全量?

中間結(jié)果不可見超步過多(IProcess)Pregel

vs.

IProcess圖計算IProcess

亂序執(zhí)行，避免了不必要的超步

實時圖計算，圖計算注定慢，但是效果的可以漸顯。迭代計算? 特點–

結(jié)構(gòu)固定? 本質(zhì)Update? 方案–

傳統(tǒng)MR模型，hadoop效率太低HaloopIprocess0.4實時計算業(yè)界進(jìn)展S4–

2010年底，Yahoo，0.3，windowtodo業(yè)界進(jìn)展? Storm:2011.9，twitter，0.5.2業(yè)界進(jìn)展‐Storm系統(tǒng)邊界S4、Storm–

只能處理“獨立”的流數(shù)據(jù)–

無法處理“復(fù)雜”事件(condition)，需要用戶handle復(fù)雜的條件–

不能很好的適用于大部分需要相關(guān)數(shù)據(jù)集執(zhí)行計算和流數(shù)據(jù)保序的實時場景–

容錯性較差–

集群無法動態(tài)擴(kuò)展業(yè)界進(jìn)展? 其它StreamBaseBorealisStreamInsightPercolatorHbase

coprocessorPregeldremel–

…設(shè)計理念負(fù)責(zé)任(Condition)–

MapReduce本質(zhì)上保證了Reduce觸發(fā)的條件，即所有map都結(jié)束（但這點很容易被忽視）。–

實時計算Condition很容易被忽略。很多只是考慮了streaming，而沒有考慮Condition。實時(Streaming)成本(Throughput)? 有所為有所不為–

通用計算框架，用戶組件只需關(guān)心業(yè)務(wù)邏輯。–

涉及到業(yè)務(wù)邏輯統(tǒng)統(tǒng)不做。設(shè)計理念? 舉例–

實時JOIN(后面有具體代碼)在storm（不考慮Condition）框架下，實現(xiàn)join，需要用戶代碼自己hold條件，判斷條件，進(jìn)而觸發(fā)join后的邏輯處理。但在我們的設(shè)計理念下，這些condition完全可以抽象為復(fù)雜完備事件模型，所以作為通用系統(tǒng)應(yīng)該提供condition的通用功能，用戶只需進(jìn)行配置而不是編碼就可以完成condition，那么實時join在iprocess體系下，用戶無需編碼處理condition，而只需處理join后的邏輯。IProcess? 通用的分布式流數(shù)據(jù)實時與持續(xù)計算平臺–

有向圖模型? 節(jié)點為用戶編寫的組件、邊為事件–

觸發(fā)器模式–

完備事件驅(qū)動的架構(gòu)，定制復(fù)雜完備事件條件–

支持相關(guān)集計算和Reduce時數(shù)據(jù)集生成(k‐mean)–

樹存儲模型，支持不同級別定制不同一致性模型和事務(wù)模型–

可擴(kuò)展的編程模型? 提出并支持樹型實時MR和增量/定時MRIProcess? 通用的分布式流數(shù)據(jù)實時與持續(xù)計算平臺–

持續(xù)與AdHoc計算(endpoint)–

微內(nèi)核+組件系統(tǒng)(系統(tǒng)級組件+用戶組件)–

多任務(wù)服務(wù)化，任務(wù)沙箱，優(yōu)先級，任務(wù)調(diào)度–

兩級容錯：應(yīng)用級和系統(tǒng)級，運算時動態(tài)擴(kuò)容–

系統(tǒng)級組件系統(tǒng)：實時join、二級索引、倒排表、物化視圖、counter…–

分布式系統(tǒng)的容錯，自動擴(kuò)展，通訊，調(diào)度–

保序…IProcess? 基礎(chǔ)的運行系統(tǒng)–

引入CEP規(guī)則引擎模塊（RPM），類似hive與MR–

引入數(shù)據(jù)集控制（用于機(jī)器學(xué)習(xí)），BI–

引入類SQL語言，DSL引擎–

引入圖計算模型邏輯模型持續(xù)計算Ad‐Hoc

Query–

不可枚舉用戶搜索(online)，DB

SQL? 持續(xù)計算–

計算相對固定、可枚舉–

數(shù)據(jù)流動SQL、MR

IProcess整體架構(gòu)整體拓?fù)溥\行過程? 三個步驟–

簡單事件發(fā)射（分布式）–

復(fù)雜事件完備性判斷（集中式、分布式）?

分布式事務(wù)–

盡量避免（機(jī)制保證）–

強(qiáng)事務(wù)（MVCC）、邏輯事務(wù)、弱事務(wù)–

觸發(fā)下一個環(huán)節(jié)IProcess的存儲? 樹結(jié)構(gòu)的存儲–

不同的一致性和事務(wù)模型? 區(qū)分實時數(shù)據(jù)與其它數(shù)據(jù)的存儲? 兩級容錯–

應(yīng)用級和系統(tǒng)級? 運算時動態(tài)擴(kuò)容? 保序Latency、throughput、可靠性–

動態(tài)tradeoffIProcess的存儲MR模型的本質(zhì)Reduce(key,valueList,context)實現(xiàn)STCacheStrategy接口QStore：持久化存儲。IProcess的存儲‐amber與MR容錯性的區(qū)別：應(yīng)用級體現(xiàn)在amber，系統(tǒng)級體現(xiàn)在st與gtIProcess的存儲‐

GlobalTableHbase維護(hù)分支Segment分裂策略Coprocessor沙箱類Redis接口–

容量規(guī)劃–

剝離行事務(wù)Yahoo

OmidIProcess要點回顧? 完備事件模型–

基礎(chǔ)模型：觸發(fā)器模式? 可擴(kuò)展的編程模型(類似于HIVE與hadoop的關(guān)系)Spark（類似storm，完全的流處理，無condition）Dumbo（實時MapReduce框架）Graph

computing（實時pregel）SQL:HiveIProcess要點回顧? 樹狀存儲? 事務(wù)模型–

邏輯事務(wù)–

弱事務(wù)–

強(qiáng)事務(wù)? 運行時擴(kuò)容? 系統(tǒng)，應(yīng)用量級容錯? 保序應(yīng)用場景特點? 響應(yīng)時間:實時–

毫秒級別（子圖）–

秒級別–

分鐘級別? 圖復(fù)雜度–

節(jié)點簡單且重、圖復(fù)雜–

節(jié)點簡單但輕、圖復(fù)雜–

節(jié)點復(fù)雜但輕、圖簡單–

節(jié)點復(fù)雜且重、圖簡單應(yīng)用場景特點? 語言C++、Java、ShellSQL–

規(guī)則DSL? 模型–

觸發(fā)器、簡單事件、實時MR、圖計算–

…應(yīng)用架構(gòu)How

to

use?? 使用IProcess需要準(zhǔn)備什么？–

組件集–

配置(有向圖，事件)–

拓?fù)銱ow

to

use?

A

demo? 簡化的資訊實時搜索實時搜索用戶API簡介? 系統(tǒng)級（高級接口）STCacheStrategyLogicalConflictResolverLazyConflictResovlerIUserDefinedConditionISeedGeneratorIPartitioner用戶API簡介? 應(yīng)用級IProcess原生IProcessModule(JobContext)SparkEventProcessor(EventContext)Dumbo(實時Mapreduce)MapperPreparerReducerMerger–

使用MapperContext、

ReducerContext等系統(tǒng)API簡介? 重要接口和類TableStrategyStorageStrategySegmentNameMappingSegment。SequencedSegmentTimedSegmentNameMappingRecordDumbo例子? 代碼直接復(fù)用，效果大不一樣? 例子(實時，中間結(jié)果可見)wordCount(與全量mapreduce區(qū)別在于：dumbo下

的wordcount，實時reduce結(jié)果是可見的，即整個計算結(jié)果中間可被用戶訪問)–

訪問記錄一次map、多次reduceSQL執(zhí)行K‐mean聚類實時join? 代碼見下頁Dumbo例子? 實時join代碼(join好一條輸出一條)classMemberMapper

:public

Mapper{public:void

map(const

string&

key,

const

RecordPtr

value,

MapperContextPtr

context){context‐>add(value‐>get_field("member_id").toString(),value,"member");}}classProductMapper

:

public

Mapper{public:void

map(const

string&

key,

const

RecordPtr

value,

MapperContextPtr

context){context‐>

add

(value‐>get_field("member_id").toString(),

value,

"product");}}Dumbo例子?

實時join代碼(reduce觸發(fā)的條件在配置文件中，即

相

同

joinkey

的

a

數(shù)

據(jù)

和

b

數(shù)

據(jù)

都ready(condition),系統(tǒng)才會實時調(diào)用reduce-大家可以比較在storm下實現(xiàn)實時join的代碼)int32_t

reduce(string

key,

map<string,

RecordIterator>

taged_value_iterator,

ReducerContext

context){string

tag_a

=

“member";

string

tag_b

=

“product";RecordIterator

iterator_a

=

taged_value_iterator.find("A")‐>second;

RecordIterator

iterator_b

=

taged_value_iterator.find("B")‐>second;

RecordPtr

record_a

=iterator_a.begin();while(record_a){RecordPtr

record_b

=iterator_b.begin();

while(record_b){Recordresult

=

record_a‐>join(record_b);

context‐>add(result);//生成join的結(jié)果record_b

=

iterator_b.next();}record_a

=

iterator_a.next();}}觸發(fā)器模式例子? SNS推薦系統(tǒng)–

用戶將公司名修改，引發(fā)推薦的實時變化–

某用戶增加一個好友會引發(fā)對自己和對別人的推薦變化–

實時人立方(刪除關(guān)系)風(fēng)控CEP–

離線風(fēng)險控制–

在線風(fēng)險控制系統(tǒng)邊界? 目前的問題– 跨語言– 吞吐量– 易用性– 服務(wù)化，云？? 邊界– 計算可枚舉– 計算可加– 依