Re: MapReduce (Re: [情報] 利用智慧型手機建構雲端

看板Cloud作者 (喲)時間13年前 (2010/08/24 04:09), 編輯推噓3(3030)
留言33則, 3人參與, 最新討論串4/6 (看更多)
: → hilorrk:@@ 兩位前輩請息怒... 08/24 00:16 這情況很正常. 在BBS或mailing-list常有這種嚴肅討論. 而我個人經驗,mailing-list遇到的討論對象,比較不會有刁蠻不承認自己犯錯的. : → hilorrk:就我所知 google的MapReduce並沒有送"資料"吧~ 08/24 00:16 : → hilorrk:而是master assign map/reduce task給worker 而worker再去 08/24 00:17 : → hilorrk:DFS取資料...所要傳輸的是程式的fork? 08/24 00:18 : → hilorrk:而且採取的是類似master去polling 而非worker主動要工作? 08/24 00:21 : → hilorrk:不知這樣理解對不對...改天要來好好研究一下了- -|| 08/24 00:21 你說的第一句話有一點錯.請以分散式的觀點思考系統環境, 環境中存在多少個map的instances,多少個reduce的instances? 最少,每個map都要知道它該讀哪個檔案分段,而根據map的規格, map並沒有自己包含了判斷它要讀哪個分段的程式碼. 包含了判讀正確檔案位置的程式,是舊世界的寫法. 可以Google尋找一些介紹 MapReduce的投影片,有一些會列出舊的平行程式寫法,和MapReduce平行程式寫法. 所以接下來你說對了,是master polling. (polling? 其實這個詞也不對啊!) Master必須要整理幾種資訊: 1. 要處理的資料有多少檔案. 2. 能使用的map worker有多少個. 基本上是把map fork在每個map worker沒錯. 但是把執行檔fork成一些程序就行了嗎? 當然不只,而是還要告訴每個程序要讀 哪個檔案或哪個分段位置(chunk index). Map worker會執行map,把檔案餵進map,然後map丟出一些key-value,是放在 local store; 線上的記憶體可能不足以處理這些突然拋出的key-value. 接下來,reduce會自動理解它要從哪個map讀結果嗎? 起碼也要看map worker和reduce worker是不是一對一對應. 通常不是. 那要怎麼做? 前面說 map 出來的東西是local store的. Reduce worker要拿到map的local store, 如果map worker和reduce worker各在不同的電腦,當然是一些類似檔案傳輸的動作. 根據key-value的規格,是 map(key0, value0) -> {(key,value)} [local store] -> grouping( {(key,value)} ) -> (key1,{value1}) [input to reduce] -> reduce(key1, {value1}) 中間grouping的客製彈性很大,有些是說map worker做一個map之後的處理, 有些是說把key-value送到一個集中位置處理,也有人說是map worker將key-value 分割,分別送到幾個固定的reduce worker那邊. 甚至一組工作的定義,可能要有個規格定義明白,哪個map之後要接哪個map/reduce, 哪個reduce要接哪個map/reduce. 並不是只有worker自己知道要從哪裡取資料而已. Worker哪有那麼聰明啊. 分散式系統重要的是訊息溝通. Map做完了要告訴master,然後master要通知reduce,reduce worker會向map worker 請求資料. 這些概念還蠻簡單. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.160.209.34

08/24 06:28, , 1F
我知道master必須informed其他worker location of data啦.
08/24 06:28, 1F

08/24 06:29, , 2F
用MapReduce當然就不可能像以前寫MPI還要在code裡切割分配
08/24 06:29, 2F

08/24 06:30, , 3F
我的意思是..由master傳輸process和location受限於master
08/24 06:30, 3F

08/24 06:31, , 4F
網路是沒辦法的吧?相較下來map task從DFS讀取大量data及運
08/24 06:31, 4F

08/24 06:33, , 5F
算才是真正的平行所在?(當然還包括reduce)
08/24 06:33, 5F

08/24 06:41, , 6F
至於map worker的grouping及reduce worker的merge要如何實
08/24 06:41, 6F

08/24 06:42, , 7F
現 這又是另一個問題了...確實有看到不少model就是了
08/24 06:42, 7F

08/24 06:58, , 8F
不知我的概念是否還有哪裡有需要指正的地方?
08/24 06:58, 8F

08/26 09:43, , 9F
哈哈, 別擔心, 你是對的, 對拒絕學習的人可以不用這麼認真
08/26 09:43, 9F

08/26 09:46, , 10F
MapReduce 只是雲端的一小部份, 如果像某些人想要又拿來傳
08/26 09:46, 10F

08/26 09:47, , 11F
資料, 又拿來解決 synchronization, 還真是浪費了 MapReduce
08/26 09:47, 11F

08/26 09:50, , 12F
message passing, voting, dynamic routing 等等
08/26 09:50, 12F

08/26 09:50, , 13F
這些 building block 沒概念, 抱著 MapReduce 一直玩, 還說
08/26 09:50, 13F

08/26 09:51, , 14F
別人不能承認錯誤 ? 噗哧 XD
08/26 09:51, 14F

08/26 20:01, , 15F
hilorrk,文章並沒有明確講由master傳一個process出去,事實上
08/26 20:01, 15F

08/26 20:01, , 16F
的確不這麼做,因為每一台電腦的Pid不一樣.
08/26 20:01, 16F

08/26 20:02, , 17F
ledia,我說你啊,你沒有指出我有什麼錯啊. 我在談的就是
08/26 20:02, 17F

08/26 20:03, , 18F
MapReduce的Framework,而不是特定工作. 是你自己一直把問題
08/26 20:03, 18F

08/26 20:03, , 19F
牽到map的層次而已. 你知道我講mapper是指map master嗎?
08/26 20:03, 19F

08/26 20:04, , 20F
而我的確指出你的錯誤,只是你還是要嘴硬不想回一句"抱歉錯了
08/26 20:04, 20F

08/26 20:04, , 21F
只能說,因為我還關心著MapReduce,所以目前文章還是反覆讀,
08/26 20:04, 21F

08/26 20:05, , 22F
實作也正在默默進行. 這些過程全都不干你的事.
08/26 20:05, 22F

08/26 20:06, , 23F
反正你有MQ server就滿意了.
08/26 20:06, 23F

08/26 20:12, , 24F
的確啦..我說傳送process不是很嚴謹 應該是從user的程式
08/26 20:12, 24F

08/26 20:12, , 25F
fork出一個process在worker上~不過也不能用每一台電腦的
08/26 20:12, 25F

08/26 20:13, , 26F
pid不一樣來說啦 畢竟一個worker上可能有多個task~
08/26 20:13, 26F

08/26 20:16, , 27F
我的重點在於 挺好奇y大所說的從master傳輸(assign?)task
08/26 20:16, 27F

08/26 20:16, , 28F
給map worker時如何作到您所意指的"分散式資源分配"
08/26 20:16, 28F

08/26 20:18, , 29F
就我認知當中 這點的確得依賴於master對外傳輸的速度@@
08/26 20:18, 29F

08/26 20:19, , 30F
還有請兩位息息怒..交流上難免會有意見不同處 我相信L大和
08/26 20:19, 30F

08/26 20:20, , 31F
Y大在資訊領域都有很深的見解 希望能就技術層面來討論就好
08/26 20:20, 31F

08/26 20:20, , 32F
不要傷了皇城之內的和氣啊XD(誤
08/26 20:20, 32F

08/26 20:29, , 33F
最後這不用管,反正該有的分寸我自己也會抓好. 養新板不容易
08/26 20:29, 33F
文章代碼(AID): #1CSjLzXr (Cloud)
討論串 (同標題文章)
文章代碼(AID): #1CSjLzXr (Cloud)