淘寶分布式大數據及實時流數據技術架構淘寶分布式大數據1提綱? 背景? 目標? 傳統方案與業界進展? 設計理念(重點)? 技術架構? 要點? 例子? 系統邊界? 計劃提綱2背景? 應用背景–

數據量急劇增加–

Web

1.0

web

2.0,

publicego

net–

電子商務、移動互聯網、移動支付–

欺詐、風控對海量交易實時性–

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

由點到面?

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

S4、Storm等流計算框架CEP以及EDA模型Pregel等圖計算模型背景4傳統方案與業界進展? 傳統方案–

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

JobIProcess

Job傳統方案與業界進展? 傳統方案輸入輸入計算過程下載輸出獨立5Hadoop之于實時? 問題(hadoop本質是為全量而生)–

任務內串行–

重吞吐量，響應時間完全沒有保證–

中間結果不可見，不可共享–

單輸入單輸出，鏈式浪費嚴重–

鏈式MR不能并行–

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

圖計算不友好–

迭代計算不友好Hadoop之于實時? 問題(hadoop本質是為全量而生)6圖計算? MapReduce為什么不適合圖計算?–

迭代–

邊的量級遠大于節點? 圖計算特點–

適應于事件機制，規模大(邊)，但單條數據不大–

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

容錯性Google

Pregel?

本質上還是全量?

中間結果不可見超步過多(IProcess)圖計算? MapReduce為什么不適合圖計算?–迭代7Pregel

vs.

IProcess圖計算IProcess

亂序執行，避免了不必要的超步

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

結構固定? 本質Update? 方案–

傳統MR模型，hadoop效率太低HaloopIprocess0.4迭代計算? 特點9實時計算業界進展S4–

2010年底，Yahoo，0.3，windowtodo實時計算業界進展S410業界進展? Storm:2011.9，twitter，0.5.2業界進展? Storm:2011.9，twitter，0.511業界進展‐Storm業界進展‐Storm12系統邊界S4、Storm–

只能處理“獨立”的流數據–

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

不能很好的適用于大部分需要相關數據集執行計算和流數據保序的實時場景–

容錯性較差–

集群無法動態擴展系統邊界S4、Storm13業界進展? 其它StreamBaseBorealisStreamInsightPercolatorHbase

coprocessorPregeldremel–

…業界進展? 其它14設計理念負責任(Condition)–

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

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

通用計算框架，用戶組件只需關心業務邏輯。–

涉及到業務邏輯統統不做。設計理念負責任(Condition)15設計理念? 舉例–

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

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

觸發器模式–

完備事件驅動的架構，定制復雜完備事件條件–

支持相關集計算和Reduce時數據集生成(k‐mean)–

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

可擴展的編程模型? 提出并支持樹型實時MR和增量/定時MRIProcess? 通用的分布式流數據實時與持續計算平臺17IProcess? 通用的分布式流數據實時與持續計算平臺–

持續與AdHoc計算(endpoint)–

微內核+組件系統(系統級組件+用戶組件)–

多任務服務化，任務沙箱，優先級，任務調度–

兩級容錯：應用級和系統級，運算時動態擴容–

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

分布式系統的容錯，自動擴展，通訊，調度–

保序…IProcess? 通用的分布式流數據實時與持續計算平臺18IProcess? 基礎的運行系統–

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

引入數據集控制（用于機器學習），BI–

引入類SQL語言，DSL引擎–

引入圖計算模型IProcess? 基礎的運行系統19邏輯模型邏輯模型20淘寶分布式大數據及實時流數據技術架構21淘寶分布式大數據及實時流數據技術架構22持續計算Ad‐Hoc

Query–

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

SQL? 持續計算–

計算相對固定、可枚舉–

數據流動SQL、MR持續計算Ad‐HocQuery23

IProcess整體架構整體拓撲 IProcess整體架構整體拓撲24運行過程? 三個步驟–

簡單事件發射（分布式）–

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

分布式事務–

盡量避免（機制保證）–

強事務（MVCC）、邏輯事務、弱事務–

觸發下一個環節運行過程? 三個步驟25IProcess的存儲? 樹結構的存儲–

不同的一致性和事務模型? 區分實時數據與其它數據的存儲? 兩級容錯–

應用級和系統級? 運算時動態擴容? 保序Latency、throughput、可靠性–

動態tradeoffIProcess的存儲? 樹結構的存儲26IProcess的存儲MR模型的本質Reduce(key,valueList,context)實現STCacheStrategy接口QStore：持久化存儲。IProcess的存儲MR模型的本質Reduce(key,v27IProcess的存儲‐amber與MR容錯性的區別：應用級體現在amber，系統級體現在st與gtIProcess的存儲‐amber與MR容錯性的區別：應用級28IProcess的存儲‐

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

容量規劃–

剝離行事務Yahoo

OmidIProcess的存儲‐GlobalTableHbase維29IProcess要點回顧? 完備事件模型–

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

computing（實時pregel）SQL:HiveIProcess要點回顧? 完備事件模型L:Hive30IProcess要點回顧? 樹狀存儲? 事務模型–

邏輯事務–

弱事務–

強事務? 運行時擴容? 系統，應用量級容錯? 保序IProcess要點回顧? 樹狀存儲31應用場景特點? 響應時間:實時–

毫秒級別（子圖）–

秒級別–

分鐘級別? 圖復雜度–

節點簡單且重、圖復雜–

節點簡單但輕、圖復雜–

節點復雜但輕、圖簡單–

節點復雜且重、圖簡單應用場景特點? 響應時間:實時32應用場景特點? 語言C++、Java、ShellSQL–

規則DSL? 模型–

觸發器、簡單事件、實時MR、圖計算–

…應用場景特點? 語言33應用架構應用架構34How

to

use?? 使用IProcess需要準備什么？–

組件集–

配置(有向圖，事件)–

拓撲Howtouse?? 使用IProcess需要準備什么？35How

to

use?

A

demo? 簡化的資訊實時搜索Howtouse? Ademo? 簡化的資訊實時搜索36實時搜索實時搜索37用戶API簡介? 系統級（高級接口）STCacheStrategyLogicalConflictResolverLazyConflictResovlerIUserDefinedConditionISeedGeneratorIPartitioner用戶API簡介? 系統級（高級接口）38用戶API簡介? 應用級IProcess原生IProcessModule(JobContext)SparkEventProcessor(EventContext)Dumbo(實時Mapreduce)MapperPreparerReducerMerger–

使用MapperContext、

ReducerContext等用戶API簡介? 應用級39系統API簡介? 重要接口和類TableStrategyStorageStrategySegmentNameMappingSegment。SequencedSegmentTimedSegmentNameMappingRecord系統API簡介? 重要接口和類40Dumbo例子? 代碼直接復用，效果大不一樣? 例子(實時，中間結果可見)wordCount(與全量mapreduce區別在于：dumbo下

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

訪問記錄一次map、多次reduceSQL執行K‐mean聚類實時join? 代碼見下頁Dumbo例子? 代碼直接復用，效果大不一樣41Dumbo例子? 實時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代碼(join好一條輸出一條)42Dumbo例子?

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

相

同

joinkey

的

a

數

據

和

b

數

據

都ready(condition),系統才會實時調用reduce-大家可以比較在storm下實現實時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的結果record_b

=

iterator_b.next();}record_a

=

iterator_a.next();}}Dumbo例子?實時join代碼(reduce觸發的條件43觸發器模式例子? SNS推薦系統–

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

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

實時人立方(刪除關系)風控CEP–

離線風險控制–

在線風險控制觸發器模式例子? SNS推薦系統44系統邊界? 目前的問題– 跨語言– 吞吐量– 易用性– 服務化，云？? 邊界– 計算可枚舉– 計算可加– 依賴相關集較小? 建模介于BSP與DOT之間Runtime的executeplan優化系統邊界? 目前的問題45目標? 打造平臺–

實時計算–

持續計算–

Iprocess將專注于完備事件機制。? 只提供最基本的功能，提供高度可定制的接口，上層可定制出不同平臺（計算模型）和業務系統。? 構建技術生態體系–

合作開發容器類組件、通用組件–

協調可復用子圖(物化VIEW)、可復用系統–

Spark系統，Dumbo系統目標? 打造平臺46目標? 全面提升業務的實時處理能力–

落地各個業務線? 遠離業務的通用平臺的生命力不會強? 搜索，廣告，交易，結算，風控，圖算法，數據倉庫…–

針對業務的響應時間? 毫秒、秒級、分鐘級? 業界有影響力的技術產品–

具有原創技術并發表高質量有影響力論文? 目前已經準備OSDI2012。–

開源技術產品目標? 全面提升業務的實時處理能力–落地各個業務線47Iproces

RoadMapIProcess0.1：– 完備事件、圖模型IProcess0.2：– 樹存儲、完善事件、保序等? IProcess0.2.1、0.2.2：– 實時搜索、交易IProcess0.3：– 完備事件機制完善、吞吐量、可擴展模型IProcess0.3.x：易用性、落地、SQL規則引擎、完善分布式事務IProcess0.4：– 開放控制接口、調度、迭代計算、持續計算，組件計算遷移IProcess0.5：– 監控、服務化、IDE、DEBUG環境。– 基本功能完善IprocesRoadMapIProcess0.1：48淘寶分布式大數據及實時流數據技術架構淘寶分布式大數據49提綱? 背景? 目標? 傳統方案與業界進展? 設計理念(重點)? 技術架構? 要點? 例子? 系統邊界? 計劃提綱50背景? 應用背景–

數據量急劇增加–

Web

1.0

web

2.0,

publicego

net–

電子商務、移動互聯網、移動支付–

欺詐、風控對海量交易實時性–

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

由點到面?

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

S4、Storm等流計算框架CEP以及EDA模型Pregel等圖計算模型背景52傳統方案與業界進展? 傳統方案–

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

JobIProcess

Job傳統方案與業界進展? 傳統方案輸入輸入計算過程下載輸出獨立53Hadoop之于實時? 問題(hadoop本質是為全量而生)–

任務內串行–

重吞吐量，響應時間完全沒有保證–

中間結果不可見，不可共享–

單輸入單輸出，鏈式浪費嚴重–

鏈式MR不能并行–

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

圖計算不友好–

迭代計算不友好Hadoop之于實時? 問題(hadoop本質是為全量而生)54圖計算? MapReduce為什么不適合圖計算?–

迭代–

邊的量級遠大于節點? 圖計算特點–

適應于事件機制，規模大(邊)，但單條數據不大–

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

容錯性Google

Pregel?

本質上還是全量?

中間結果不可見超步過多(IProcess)圖計算? MapReduce為什么不適合圖計算?–迭代55Pregel

vs.

IProcess圖計算IProcess

亂序執行，避免了不必要的超步

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

結構固定? 本質Update? 方案–

傳統MR模型，hadoop效率太低HaloopIprocess0.4迭代計算? 特點57實時計算業界進展S4–

2010年底，Yahoo，0.3，windowtodo實時計算業界進展S458業界進展? Storm:2011.9，twitter，0.5.2業界進展? Storm:2011.9，twitter，0.559業界進展‐Storm業界進展‐Storm60系統邊界S4、Storm–

只能處理“獨立”的流數據–

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

不能很好的適用于大部分需要相關數據集執行計算和流數據保序的實時場景–

容錯性較差–

集群無法動態擴展系統邊界S4、Storm61業界進展? 其它StreamBaseBorealisStreamInsightPercolatorHbase

coprocessorPregeldremel–

…業界進展? 其它62設計理念負責任(Condition)–

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

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

通用計算框架，用戶組件只需關心業務邏輯。–

涉及到業務邏輯統統不做。設計理念負責任(Condition)63設計理念? 舉例–

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

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

觸發器模式–

完備事件驅動的架構，定制復雜完備事件條件–

支持相關集計算和Reduce時數據集生成(k‐mean)–

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

可擴展的編程模型? 提出并支持樹型實時MR和增量/定時MRIProcess? 通用的分布式流數據實時與持續計算平臺65IProcess? 通用的分布式流數據實時與持續計算平臺–

持續與AdHoc計算(endpoint)–

微內核+組件系統(系統級組件+用戶組件)–

多任務服務化，任務沙箱，優先級，任務調度–

兩級容錯：應用級和系統級，運算時動態擴容–

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

分布式系統的容錯，自動擴展，通訊，調度–

保序…IProcess? 通用的分布式流數據實時與持續計算平臺66IProcess? 基礎的運行系統–

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

引入數據集控制（用于機器學習），BI–

引入類SQL語言，DSL引擎–

引入圖計算模型IProcess? 基礎的運行系統67邏輯模型邏輯模型68淘寶分布式大數據及實時流數據技術架構69淘寶分布式大數據及實時流數據技術架構70持續計算Ad‐Hoc

Query–

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

SQL? 持續計算–

計算相對固定、可枚舉–

數據流動SQL、MR持續計算Ad‐HocQuery71

IProcess整體架構整體拓撲 IProcess整體架構整體拓撲72運行過程? 三個步驟–

簡單事件發射（分布式）–

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

分布式事務–

盡量避免（機制保證）–

強事務（MVCC）、邏輯事務、弱事務–

觸發下一個環節運行過程? 三個步驟73IProcess的存儲? 樹結構的存儲–

不同的一致性和事務模型? 區分實時數據與其它數據的存儲? 兩級容錯–

應用級和系統級? 運算時動態擴容? 保序Latency、throughput、可靠性–

動態tradeoffIProcess的存儲? 樹結構的存儲74IProcess的存儲MR模型的本質Reduce(key,valueList,context)實現STCacheStrategy接口QStore：持久化存儲。IProcess的存儲MR模型的本質Reduce(key,v75IProcess的存儲‐amber與MR容錯性的區別：應用級體現在amber，系統級體現在st與gtIProcess的存儲‐amber與MR容錯性的區別：應用級76IProcess的存儲‐

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

容量規劃–

剝離行事務Yahoo

OmidIProcess的存儲‐GlobalTableHbase維77IProcess要點回顧? 完備事件模型–

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

computing（實時pregel）SQL:HiveIProcess要點回顧? 完備事件模型L:Hive78IProcess要點回顧? 樹狀存儲? 事務模型–

邏輯事務–

弱事務–

強事務? 運行時擴容? 系統，應用量級容錯? 保序IProcess要點回顧? 樹狀存儲79應用場景特點? 響應時間:實時–

毫秒級別（子圖）–

秒級別–

分鐘級別? 圖復雜度–

節點簡單且重、圖復雜–

節點簡單但輕、圖復雜–

節點復雜但輕、圖簡單–

節點復雜且重、圖簡單應用場景特點? 響應時間:實時80應用場景特點? 語言C++、Java、ShellSQL–

規則DSL? 模型–

觸發器、簡單事件、實時MR、圖計算–

…應用場景特點? 語言81應用架構應用架構82How

to

use?? 使用IProcess需要準備什么？–

組件集–

配置(有向圖，事件)–

拓撲Howtouse?? 使用IProcess需要準備什么？83How

to

use?

A

demo? 簡化的資訊實時搜索Howtouse? Ademo? 簡化的資訊實時搜索84實時搜索實時搜索85用戶API簡介? 系統級（高級接口）STCacheStrategyLogicalConflictResolverLazyConflictResovlerIUserDefinedConditionISeedGeneratorIPartitioner用戶API簡介? 系統級（高級接口）86用戶API簡介? 應用級IProcess原生IProcessModule(JobContext)SparkEventProcessor(EventContext)Dumbo(實時Mapreduce)MapperPreparerReducerMerger–

使用MapperContext、

ReducerContext等用戶API簡介? 應用級87系統API簡介? 重要接口和類TableStrategyStorageStrategySegmentNameMappingSegment。SequencedSegmentTimedSegmentNameMappingRecord系統API簡介? 重要接口和類88Dumbo例子? 代碼直接復用，效果大不一樣? 例子(實時，中間結果可見)wordCount(與全量mapreduce區別在于：dumbo下

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

訪問記錄一次map、多次reduceSQL執行K‐mean聚類實時join? 代碼見下頁Dumbo例子? 代碼直接復用，效果大不一樣89Dumbo例子? 實時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代碼(join好一條輸出一條)90Dumbo例子?

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

相

同

joinkey

的

a

數

據

和

b

數

據

都ready(condition),系統才會實時調用reduce-大家可以比較在storm下實現實時join的代碼)int32_t

reduce(string

key,

map<string,

RecordIterator>

taged_value_iterator,

ReducerContext

context){string

tag_a

=

“member";

string

tag_b

=

“product";Record