教學部落格
http://www.wretch.cc/blog/trendnop09
其實我放這個並沒有啥意思，我已經不可能有參賽資格了
但實際上從這個比賽的規劃看起來確實跟以往有所不同
此外竟然還有教學
我只有一個感想，「要比什麼？」
比演算法？比效能？
比應用？比服務設計？
比文件撰寫？比夢想與遠景？
說起來現在很多包裝化，公式化的東西可能在我的眼裡都會解讀成不同的看法。
我還是想要說，學習一個新技術，該學的是這個技術的精髓，本質。
「取之有道」
雲端運算在做啥？想做個Amazon雲端平台該怎麼做？
可是其實培育並不是照本宣科，如果真的十年後要賭在雲端計算上，我想應該深入地討論基本的知識。
而這些知識必須建築在業界的普遍狀況，不然就別做了。
- 為何你需要Map Reduce，話句話說你可能不太需要？
- 高效能計算理論，程式如何平行化？為啥會加速？
- Divide and Conquer 與 Map Reduce 適用的題型
- 要做一個可以平行擴充的系統需要什麼？如何在Cost / Scale之間取得平衡？
- 如何有效地管理好硬體或軟體上可能發生的錯誤？
- 為啥我不能讓用戶來分享我的計算負載，成為真正的雲？
如何將電腦更有效地組合起來變成更好的服務，如何在組合的時候讓電腦去配合你的服務規劃，才是重要的。
不光只是做，而是要思考其本質後，再運用其本質來設計。
##CONTINUE##
所以最近思考過後，上述問題的答案是這樣的方向
1. 為何需要Map Reduce？
我認為，其實並不是所有人都需要用到這個。Map Reduce最典型的兩個誤用是，1. 把Map Reduce當作是另一種Grid，或是聽信Google的廣告台詞以為這是取之不盡用之不竭。2. 把Map Reduce當作是可以解決所有平行化的問題（甚至是資訊問題）的工具。
Map Reduce被設計成依賴在高效能的檔案系統上，在去進行資料分析，轉換，處理的Framework。也就是說，一個很好的鍋子，也需要配上一個不錯的蓋子。如果鍋子不好，蓋子在怎樣好也沒用。如果你確定你的問題是要做大量的資料處理，資料分析，甚至資料探勘，Map Reduce這個蓋子才對你有用。對此我認為現在應該進展到資料處理階段，也就是資料處理語言，這樣才能讓比較低階的Map Reduce能跟前端實做高階資料探勘的人員接上。
但問題是，你願意把錢砸在鍋子上嗎？
2. 為啥需要平行化？
對於控制成本的Project Manager而言，如果說有個東西可以花一定數量的金錢就有等效的成長，那誰不願意呢？例如說，從2核心到4核心，如果更快的話，那我當然買4核心。甚至換個想法，我可不可以要用的時候才加核心呢？
那麼，你就需要讓你的平台擁有平行化的觀念。
平行化的平台擁有的優點，就像是你的電話系統可以同時允許多條線路電話打進來，你可以每一線雇用一個客服人員，或是當你覺得客服品質不好，需要更多客服人員，可以在去加線路，或者雇用人。在平行化的同時，更要允許既有資源的共用。如果這些客服人員都用同一套客服系統，並且定期地彙整資料給高層主管評估績效，那更好了。
如果配置得當，那從一個角度就像是你的系統能夠加速或是擴大。如果客服人員的績效能有個評估的單位叫做「通/小時」而你發現增加當增加硬體的數量，能夠線性地增加這個數字，那表示成本是有效地轉換到績效上。而這個數字的斜率是多少，那還是得看工作的性質了。
對於運算也是如此，大家都是希望能用最少的成本，做到最多的事情。
3. Map Reduce為啥適用這些特定的題型？
Map Reduce能解的問題是一般的Device and Conqure問題，表示如果你的問題能拆解成獨立的小問題，那Map Reduce就能解。所以凡舉字串操作(包括binary)，數值運算(不包括矩陣)都可以。如果你的資料探勘是建築在字串形式的資料上，那就沒問題。
如果你想把未知的問題拿來實做看看，也要確定你的問題不是任何形式的遞迴問題。
此外MapReduce在架構上繼承自Functional programming的性質，mapper與reducer可以管線化，但這個就是視架構上的需求而調整的。
4. 一個可以平行擴充的系統需要什麼硬體條件？
可以想像的是，跟Google當初的初衷一樣，每樣東西要小，簡單，便宜。然後以非常大的數量作螞蟻雄兵。
記得在Google的Paper裡提到，要能夠達到這種計算量，電力是一個大問題。需要多少監控及機房管理的人員又是一個問題。所以有些中小企業，為了「趕快」解決問題，往往會被硬體廠商「晃點」，說他們的東西都不用人管，都可以自動化。
決策者往往弄不清楚自己在面對的是什麼，等到東西買下去才開始頭痛。
所有格網計算或雲端計算的硬體問題，都是「這麼多機器要怎麼管」，因為你的機器只會變多不會變少。當客戶數量成長時，需要更多機器，帶來麻煩的往往是越大台越複雜的機器。到時候管理的成本還是逃避不了。
硬體調整不好，雲端絕對快不了。
這些硬體就包括了管理人員以及電力，網路。
5. 如何有效地管理或防止軟硬體錯誤？
我認為這個問題的解答是在專案管理，以及開發的過程中有沒有在各個環節上符合軟體工程的「精神」。
還沒通過完整測試的東西？何以能上線？
如何將測試自動化？
而硬體錯誤是無法防止的，只能夠說任何Centralized failure point都應該要有備品，連人也是。
6. 我想讓我的使用者也加入雲端計算...
這個大概是最後的問題了，我想一旦成功的話，就是肥了這些廠商吧？
對於使用者來說，原本要花上千塊的軟體，因為他肯加入運算行列，他打了對折(應該要採取使用者越多降價越多的噱頭)，太便宜了。
對於廠商來說，電力機房都省了，他賺得更多。
難度在於：
- Active resource pre-allocated scheduling：這個已經有實做
- Resource classfication：如何確保這些遠端的運算資源用的是最少的IO？
我想一開始如果就將這些想法加入雲端或傳統的格網計算的話，或許有一天真的能走向大家都能貢獻自己的CPU的路吧。
沒有留言 :
張貼留言