網址: http://xumingming.sinaapp.com/756/twitter-storm-drpc/
本文翻譯自:https://github.com/nathanmarz/storm/wiki/Distributed-RPC。
Storm裏面引入DRPC主要是利用storm的實時計算能力來並行化CPU intensive的計算。DRPC的storm topology以函數的參數流作爲輸入,而把這些函數調用的返回值作爲topology的輸出流。
DRPC其實不能算是storm本身的一個特性, 它是通過組合storm的原語spout,bolt, topology而成的一種模式(pattern)。本來應該把DRPC單獨打成一個包的, 但是DRPC實在是太有用了,所以我們我們把它和storm捆綁在一起。
概覽
Distributed RPC是由一個”DPRC Server”協調的(storm自帶了一個實現)。DRPC服務器協調1) 接收一個RPC請求。2) 發送請求到storm topology 3) 從storm topology接收結果。4) 把結果發回給等待的客戶端。從客戶端的角度來看一個DRPC調用跟一個普通的RPC調用沒有任何區別。比如下面是客戶端如何調用RPC: reach方法的,方法的參數是: http://twitter.com。
1
2
3
|
DRPCClient client =
new DRPCClient( "drpc-host" ,
3772 ); String result = client.execute( "reach" , |
DRPC的工作流大致是這樣的:
客戶端給DRPC服務器發送要執行的方法的名字,以及這個方法的參數。實現了這個函數的topology使用DRPCSpout
從DRPC服務器接收函數調用流。每個函數調用被DRPC服務器標記了一個唯一的id。 這個topology然後計算結果,在topology的最後一個叫做ReturnResults
的bolt會連接到DRPC服務器,並且把這個調用的結果發送給DRPC服務器(通過那個唯一的id標識)。DRPC服務器用那個唯一id來跟等待的客戶端匹配上,喚醒這個客戶端並且把結果發送給它。
LinearDRPCTopologyBuilder
Storm自帶了一個稱作LinearDRPCTopologyBuilder的topology builder, 它把實現DRPC的幾乎所有步驟都自動化了。這些步驟包括:
- 設置spout
- 把結果返回給DRPC服務器
- 給bolt提供有限聚合幾組tuples的能力
讓我們看一個簡單的例子。下面是一個把輸入參數後面添加一個”!”的DRPC topology的實現:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
public
static class ExclaimBolt
implements IBasicBolt { public
void prepare(Map conf, TopologyContext context) { } public
void execute(Tuple tuple, BasicOutputCollector collector) { String input = tuple.getString( 1 ); collector.emit( new
Values(tuple.getValue( 0 ), input +
"!" )); } public
void cleanup() { } public
void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare( new
Fields( "id" ,
"result" )); } } public
static void main(String[] args)
throws Exception { LinearDRPCTopologyBuilder builder =
new LinearDRPCTopologyBuilder( "exclamation" ); builder.addBolt( new
ExclaimBolt(), 3 ); // ... } |
可以看出來, 我們需要做的事情非常的少。創建LinearDRPCTopologyBuilder
的時候,你需要告訴它你要實現的DRPC函數的名字。一個DRPC服務器可以協調很多函數,函數與函數之間靠函數名字來區分。你聲明的第一個bolt會接收兩維tuple,tuple的第一個field是request-id,第二個field是這個請求的參數。LinearDRPCTopologyBuilder
同時要求我們topology的最後一個bolt發射一個二維tuple:
第一個field是request-id, 第二個field是這個函數的結果。最後所有中間tuple的第一個field必須是request-id。
在這裏例子裏面ExclaimBolt
簡單地在輸入tuple的第二個field後面再添加一個”!”,其餘的事情都由LinearDRPCTopologyBuilder
幫我們搞定:鏈接到DRPC服務器,並且把結果發回。
本地模式DRPC
DRPC可以以本地模式運行。下面就是以本地模式運行上面例子的代碼:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
LocalDRPC drpc =
new LocalDRPC(); LocalCluster cluster =
new LocalCluster(); cluster.submitTopology( "drpc-demo" , conf, builder.createLocalTopology(drpc) ); System.out.println( "Results for 'hello':" + drpc.execute( "exclamation" ,
"hello" )); cluster.shutdown(); drpc.shutdown(); |
首先你創建一個LocalDRPC
對象。 這個對象在進程內模擬一個DRPC服務器,跟LocalClusterLinearTopologyBuilder
有單獨的方法來創建本地的topology和遠程的topology。在本地模式裏面LocalDRPC
對象不和任何端口綁定,所以我們的topology對象需要知道和誰交互。這就是爲什麼createLocalTopology
方法接受一個LocalDRPC
對象作爲輸入的原因。
把topology啓動了之後,你就可以通過調用LocalDRPC
對象的execute
來調用RPC方法了。
遠程模式DRPC
在一個真是集羣上面DRPC也是非常簡單的,有三個步驟:
- 啓動DRPC服務器
- 配置DRPC服務器的地址
- 提交DRPC topology到storm集羣裏面去。
我們可以通過下面的storm
腳本命令來啓動DRPC服務器:
1
|
bin /storm
drpc |
接着, 你需要讓你的storm集羣知道你的DRPC服務器在哪裏。DRPCSpout
需要這個地址從而可以從DRPC服務器來接收函數調用。這個可以配置在storm.yaml
或者通過代碼的方式配置在topology裏面。通過storm.yaml
配置是這樣的:
1
2
3
|
drpc.servers: - "drpc1.foo.com" - "drpc2.foo.com" |
最後,你通過StormSubmitter
對象來提交DRPC topology — 跟你提交其它topology沒有區別。如果要以遠程的方式運行上面的例子,用下面的代碼:
1
2
3
4
5
|
StormSubmitter.submitTopology( "exclamation-drpc" , conf, builder.createRemoteTopology() ); |
我們用createRemoteTopology
方法來創建運行在真實集羣上的DRPC topology。
一個更復雜的例子
上面的DRPC例子只是爲了介紹DRPC概念的一個簡單的例子。下面讓我們看一個複雜的、確實需要storm的並行計算能力的例子, 這個例子計算twitter上面一個url的reach值。
首先介紹一下什麼是reach值,要計算一個URL的reach值,我們需要:
- 獲取所有微薄裏面包含這個URL的人
- 獲取這些人的粉絲
- 把這些粉絲去重
- 獲取這些去重之後的粉絲個數 — 這就是reach
一個簡單的reach計算可能會有成千上萬個數據庫調用,並且可能設計到百萬數量級的微薄用戶。這個確實可以說是CPU intensive的計算了。你會看到的是,在storm上面來實現這個是非常非常的簡單。在單臺機器上面, 一個reach計算可能需要花費幾分鐘。而在一個storm集羣裏面,即時是最男的URL, 也只需要幾秒。
一個reach topolgoy的例子可以在這裏找到(storm-starter)。reach topology是這樣定義的:
1
2
3
4
5
6
7
8
9
|
LinearDRPCTopologyBuilder builder =
new LinearDRPCTopologyBuilder( "reach" ); builder.addBolt( new
GetTweeters(), 3 ); builder.addBolt( new
GetFollowers(), 12 ) .shuffleGrouping(); builder.addBolt( new
PartialUniquer(), 6 ) .fieldsGrouping( new
Fields( "id" ,
"follower" )); builder.addBolt( new
CountAggregator(), 2 ) .fieldsGrouping( new
Fields( "id" )); |
這個topology分四步執行:
GetTweeters
獲取所發微薄裏面包含制定URL的所有用戶。它接收輸入流:[id, url]
, 它輸出:[id, tweeter]
. 沒一個URL tuple會對應到很多tweeter
tuple。GetFollowers
獲取這些tweeter的粉絲。它接收輸入流:[id, tweeter]
, 它輸出:[id, follower]
PartialUniquer
通過粉絲的id來group粉絲。這使得相同的分析會被引導到統一個task。因此不同的task接收到的粉絲是不同的 — 從而起到去重的作用。它的輸出流:[id, count]
即輸出這個task上統計的粉絲個數。- 最後,
CountAggregator
接收到所有的局部數量, 把它們加起來就算出了我們要的reach值。
我們來看一下PartialUniquer
的實現:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
public
static class PartialUniquer implements
IRichBolt, FinishedCallback { OutputCollector _collector; Map<Object, Set<String>> _sets =
new HashMap<Object, Set<String>>(); public
void prepare(Map conf, TopologyContext context, OutputCollector collector) { _collector = collector; } public
void execute(Tuple tuple) { Object id = tuple.getValue( 0 ); Set<String> curr = _sets.get(id); if (curr== null ) { curr =
new HashSet<String>(); _sets.put(id, curr); } curr.add(tuple.getString( 1 )); _collector.ack(tuple); } public
void cleanup() { } public
void finishedId(Object id) { Set<String> curr = _sets.remove(id); int
count; if (curr!= null ) { count = curr.size(); }
else { count =
0 ; } _collector.emit( new
Values(id, count)); } public
void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare( new
Fields( "id" ,
"partial-count" )); } } |
當PartialUniquer
在execute
方法裏面接收到一個粉絲tuple
的時候, 它把這個tuple添加到當前request-id對應的Set
裏面去。
PartialUniquer
同時也實現了FinishedCallback
接口, 實現這個接口是告訴
LinearDRPCTopologyBuilder
它想在接收到某個request-id的所有tuple之後得到通知,回調函數則是,code>finishedId方法。在這個回調函數裏面PartialUniquer
發射當前這個request-id在這個task上的粉絲數量。
在這個簡單接口的背後,我們是使用CoordinatedBolt
來檢測什麼時候一個bolt接收到某個request的所有的tuple的。CoordinatedBolt
是利用direct stream來實現這種協調的。
這個topology的其餘部分就非常的明瞭了。我們可以看到的是reach計算的每個步驟都是並行計算出來的,而且實現這個DRPC的topology是那麼的簡單。
非線性DRPC Topology
LinearDRPCTopologyBuilder
只能搞定"線性"的DRPC topology。所謂的線性就是說你的計算過程是一步接着一步, 串聯。我們不難想象還有其它的可能 -- 並聯(回想一下初中物理裏面學的並聯電路吧), 現在你如果想解決這種這種並聯的case的話, 那麼你需要自己去使用CoordinatedBolt
來處理所有的事情了。如果真的有這種use case的話, 在mailing list上大家討論一下吧。
LinearDRPCTopologyBuilder的工作原理
- DRPCSpout發射tuple:
[args, return-info]
。return-info
包含DRPC服務器的主機地址,端口以及當前請求的request-id - DRPC Topology包含以下元素:
- DRPCSpout
- PrepareRequest(生成request-id, return info以及args)
- CoordinatedBolt
- JoinResult -- 組合結果和return info
- ReturnResult -- 連接到DRPC服務器並且返回結果
- LinearDRPCTopologyBuilder是利用storm的原語來構建高層抽象的很好的例子。
高級特性
- 如何利用KeyedFairBolt來同時處理多個請求
- 如何直接使用CoordinatedBolt