推 Azarc:interesting 08/17 11:22
→ bartschen:沒有去看文章內容，所以偷懶用問的，這種mobile cluster 08/17 12:13
→ bartschen:有什麼特別的好處或用途嗎？感謝~ 08/17 12:13
將load balance、fault tolerance等系統層面的任務交由framework處理
在智慧手機(其實也包含sensor等embedded sys.)上編寫分散式程式時
更能專注於應用而不被其他因素干擾
此外通常交由framework完整的機制來處理比自己處理效益更高
(其實就是把MapReduce的好處搬到mobile(ubi) sys.上啦)
應用的話paper有提到老人居家看護及醫院(或其他地方)的緊急疏散兩點
可以參考看看
※ 編輯: hilorrk 來自: 114.24.195.24 (08/17 14:03)
推 ledia:hand held device 就應該拿來當 hand held device 來用 08/17 16:57
→ ledia:要計算還是 data center 專職專用, 不然你的電池馬上就空了 08/17 16:57
→ ledia:用主機算好再讓手機來用, 會有效率得多 08/17 16:58
→ ledia:個人淺見 08/17 17:00
mobile device當然不可能用來取代data center的巨量計算密集工作啦
但可利用mobile device即時取得週邊embedded sys.的資訊(如老人看護的例子)
而且wireless remote傳輸所耗的能量/時間也不全能忽略的
或許能在區域計算與遠端集中計算的取捨衡量中找到此技術的甜蜜點
我覺得有點像智慧型手機<->平板電腦<->小筆電<->一般筆電之間的關係啦
(雖然舉這個例子自己想想都覺得頗爛)
不過這一切都還算是空談...畢竟它能發展到什麼程度現在也是未知數~
以上也為一點個人淺見XDD||
※ 編輯: hilorrk 來自: 114.24.195.24 (08/17 17:39)
推 ledia:你真的知道自己在說什麼嗎 @@ 08/17 18:39
→ ledia:該用什麼 device 就做什麼 device, 如果是收集資訊, 可以另 08/17 18:40
→ ledia:外發展更有效率的 device, 沒必要什麼都放到手機上算 08/17 18:41
→ ledia:畢竟像看護有其特性, 比如說他的 device 不需要 mobility 08/17 18:41
→ ledia:雲端的某些設計哲學, 就是在於不要讓 client 做太多事 08/17 18:42
→ ledia:如此 client 能精簡短小, 好用不容易壞, 難的事讓專業的來 08/17 18:43
您有沒有看過那篇paper@@?
第一：
文中指的老人看護並非躺在病床上的那種...
我翻譯其中一段給您看：
手機提供多種重要的感應能力，例如：位置、影像、移動(加速度)與聲響。
這些能被用於偵測一些潛在的問題，像是早上躺在床上的時間超時、
夜晚過度的於房屋週遭行走、穿著拖鞋抖動(XD?)、語音通話(?!)等。
...
不正常的行為如長期在夜晚行動或過度行走、不正常的噪音等
可被mapped到特殊的monitor node作更進一步的處理並於合適地點發出警報。
...
這種應用能利用我們的系統輕鬆的修改及分散處理；
修改events偵測可以設定適當的map function，警報情況能實作於reduce function。
第二：
MapReduce這種framework主要是為了簡化一般寫程式所需要的流程，
在此受益的client端指的即是寫程式的工程師而非end-user。
(當然，高品質及更適合的產品對使用者總是好的)
使用此framework的client端(程式設計師)只需管應用層面的問題化簡為MapReduce，
而不必親自去管理各種系統層面的東西(資源虛擬化)。
第三：
您提到額外開發device更具優勢，這點是產品發展策略的問題。
事實上此framework應該不是只能應用在手機上。
而使用手機也有其好處，像是配合現在手機具有的功能(像是與social network溝通)。
以上是我對這件事的一點看法與回覆，如有錯誤也請L大與各位前輩繼續指正@@
※ 編輯: hilorrk 來自: 114.24.195.24 (08/17 20:20)
推 larrywhy:專業文推~可以繼續討論嗎? 好想要多瞭解一些 !! 08/17 20:46
推 ledia:你對 MapReduce 的認知不太對, 不要什麼東西都想套用 08/17 22:08
→ ledia:那只是用來解決 large scale computation problem 的模型 08/17 22:08
→ ledia:如果今天你用 web cam + motion detection 甚至做一些動作的 08/17 22:09
→ ledia:偵測, 會不會比用手機好用呢 ? 手機還有充電的問題, 還不如 08/17 22:10
→ ledia:插著電的 IP camera 好用吧 ? 08/17 22:10
推 ledia:btw, 有些東西做成 chip 會比用 cpu 算得要死來得有效率 08/17 22:36
Google的MapReduce(此處不論Lisp)的確是用來解決large scale computation的，
因此才會有load balance和Locality的問題。
但是此處的"large scale"也許有議論的空間；
在google的paper當中都是以tera等級在計算的，
但是現今MapReduce也被拿來實作成multi-core及shared-memory的框架(也就是單機版XD)，
相信單一電腦的計算能力難以處理tera等級的問題吧？
可是也不能完全抹滅MapReduce在其上的功效。(但確實不比在large cluster上來得有用)
此處由mobile device組成的cluster用來處理偵測到的data set
利用MapReduce是否能夠達到更好的效能及更便利的使用？
當然現在不得而之，因為與一般cluster的諸多相異，整個系統目前還是初生兒的狀態。
不過這也不外乎是一種可能性，至少對我來說也是一種新的啟發。
就現在來看要做到非常智慧型的ubi-computing的確很難，
但未來processor的計算能力越來越強，
未來不論是用什麼device若能配合這種框架，也許能產生令人驚奇的應用。
當然，多數mobile device都有電量問題，
現在無線充電無法做到隨地充電，(不過至少一直有進展，Qi前陣子不就定了部份無線充電規格了嗎?)
電池技術長久以來也沒有突破性的發展。
Misco現階段只是實驗性的產品，並不一定要期待他能帶來多大商業價值。
但我相信持續的觀察，能從其中得到不少東西...
不才只是一個剛踏入此領域的學生，無法與L大在資訊領域的見識相比。
但希望能透過表達自己想法讓大家來評論及糾正，使我對雲端有更深刻的瞭解。
希望L大與其它前輩對我的想法再提出一些意見^^
※ 編輯: hilorrk 來自: 114.24.195.24 (08/17 23:13)
推 ledia:又想到一點, 我是用 industry view 來看的, 如果只是想做一 08/17 23:02
→ ledia:些學術研究, 我覺得可以有創意一點, 不用考慮經濟性 08/17 23:02
→ ledia:但是 MapReduce 是拿來做啥的要弄清楚, 不要誤用了 08/17 23:02
→ hilorrk:上面那段回覆是在L大推文前寫的 與L大推文不謀而合XD 08/17 23:18
PS.
剛剛突然發現"MapReduce這種framework主要是為了簡化一般寫程式所需要的流程"
這句話可能讓L大誤解了，
其實就像我前面說到的，它簡化的是"在分散式系統中的平行處理"程式寫作流程。
若是這樣補充，不知在MapReduce的理解方面是否還有錯誤的地方?
※ 編輯: hilorrk 來自: 114.24.195.24 (08/17 23:24)
推 ledia:我以為 large scale computation 是用來解決 peta scale 的 08/17 23:32
→ ledia:你說的 google 的 paper 是哪一年的 ? ;) 08/17 23:33
→ ledia:我是覺得 processor 計算能力強, 耗電就是會大, 你還是會回 08/17 23:33
→ ledia:到到底是要用 hand held, 還是 ipad 還是 laptop 的迴圈裡 08/17 23:34
→ hilorrk:就是2004年那篇囉 因為小弟剛接觸 平常也沒那麼大的資料 08/17 23:41
→ hilorrk:量啦...資訊爆炸的速度確實很恐怖:P 08/17 23:42
→ hilorrk:的確目前看來是如此...只能希望未來能有更好的技術/架構囉 08/17 23:46
→ hilorrk:感謝L大提供那麼多實際的意見 讓我有另一方面的省思^^ 08/17 23:46
→ yauhh:這篇Misco highlight的是行動監護的應用,然而主體確實是在講 08/18 00:05
→ yauhh:smart-phone做worker處理map和reduce工作. 雖然電力供給可能 08/18 00:06
→ yauhh:不夠,但這網路恰好符合所謂ubiquitious network計算環境. 08/18 00:07
※ 編輯: hilorrk 來自: 114.36.168.54 (08/19 01:06)