2010的雲端回顧及未來展望

為了能讓大家對雲端的發展有所瞭解，這篇文章將從幾個不同的觀點來剖析今年度的雲端技術發展。我會先從國際間的狀況與台灣產業的發展來分析，之後才是實際的雲端技術及Web技術的總和介紹。當然這些都是我個人在2010這一整年的觀察，所以想說整理一下在網路上與大家來討論。

闕志克與貨櫃型電腦介紹 / 文茜的世界財經週報 2010.01.10

花了些時間看完這整段影片，以下是我的一些感想

第一段：



第一段大概介紹了工研院在雲端上的方向，簡單來說就是闕主任提到的「如果能夠有雲端的OS整合台灣現有的硬體」，那就會是完成體了XD

從不同的角度看雲端運算

這年頭真是有趣，到哪裡都會有不同領域的人問「什麼是雲端運算？」
看樣子廣大媒體的效力真的非常之厲害，但從個人而群聚出的媒體似乎也形成一種效力(Stand Alone Complex)，所以我還是想在這發揮一下個人的效力。

有人說它是「Google」或是「Amazon」。

也有人說它是「MapReduce」或是「Hadoop」。

更有人說它只不過就是「Grid」或是「Cluster」。


或許我的部落格該改成「Kiwi雲端運算開發站」？
Stallman大叔還說雲端運算是蠢事...
(http://www.zdnet.com.tw/news/software/0,2000085678,20132147,00.htm)

觀察一些文章，可以非常清楚大家都是從幾個固定的角度去看他。而並沒有人從發展的角度去看。這些文章有褒有譴，不過多半並沒有全面性地去介紹這個名詞。但是不管是什麼時候的什麼新名詞，大家最關切的是「有沒有發展價值？」

趨勢2009騰雲駕霧 程式競賽

http://www.trend.org/contest

教學部落格

http://www.wretch.cc/blog/trendnop09

其實我放這個並沒有啥意思，我已經不可能有參賽資格了
但實際上從這個比賽的規劃看起來確實跟以往有所不同
此外竟然還有教學

我只有一個感想，「要比什麼？」
比演算法？比效能？
比應用？比服務設計？
比文件撰寫？比夢想與遠景？

說起來現在很多包裝化，公式化的東西可能在我的眼裡都會解讀成不同的看法。
我還是想要說，學習一個新技術，該學的是這個技術的精髓，本質。
「取之有道」

雲端運算在做啥？想做個Amazon雲端平台該怎麼做？

可是其實培育並不是照本宣科，如果真的十年後要賭在雲端計算上，我想應該深入地討論基本的知識。
而這些知識必須建築在業界的普遍狀況，不然就別做了。

1. 為何你需要Map Reduce，話句話說你可能不太需要？


2. 高效能計算理論，程式如何平行化？為啥會加速？


3. Divide and Conquer 與 Map Reduce 適用的題型


4. 要做一個可以平行擴充的系統需要什麼？如何在Cost / Scale之間取得平衡？


5. 如何有效地管理好硬體或軟體上可能發生的錯誤？


6. 為啥我不能讓用戶來分享我的計算負載，成為真正的雲？

如何將電腦更有效地組合起來變成更好的服務，如何在組合的時候讓電腦去配合你的服務規劃，才是重要的。
不光只是做，而是要思考其本質後，再運用其本質來設計。

Google App Engine, MapReduce與資料處理

去年夏天的時候，Google大肆炒熱AppEngine的平台，讓使用者能夠撰寫自己的程式，並且放在Google的雲端計算環境上執行。

Google AppEngine的好處我們都曉得，尤其對於應用的角度來說，無非就是可以讓很多有想法的網路創業族群能夠以極少的成本自行開發軟體並且供人使用。但從學術角度及高效能計算的觀點，Google的運算資源極為龐大，如果只是單拿來跑應用程式，有點可惜。

於是有了這個HTTPMR。

雲端運算、格網運算與P2P運算

在6月的Google Developer's Day活動前後，媒體報導了有關雲端運算的事情。有些也冠上了滿誇大的標題，說雲端運算是Google的武器...或是IT的明日之星...等等的。但其實這也和「Web2.0」這個名詞的出現一樣，多半有廠商在後面的推廣，舊酒新瓶裝。但實際上，各位也是從以前到現在就都在「雲」上，只是Google將自己的三個核心技術，與網路的使用者們，一起包裝成新的名詞叫做雲端運算。

9月10號凌晨3點的時候，CERN的大型強子對撞機(LHC)投入了第一個質子束，一個月後就要進行第一次對撞。LHC一年能夠產生15PB(15,000,000GB)的資料量，如果以一張DVD9來算的話，那就是166萬張了。但要怎樣能夠將這些偵測器得到的原始資料進行龐大的運算？這個時候就要靠著分散式運算來得到結果。而其中一種分散式運算的技術，我們稱做格網計算。

我希望透過這篇文章，讓大家了解電腦的運算歷史，以及未來每個人手上的電腦，又會被放在世界的哪裡。

MapReduce是開技術倒車？

http://glinden.blogspot.com/2008/01/mapreduce-step-backwards.html

http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html

MapReduce是開技術倒車？實際上這像是當初SQL推出的時候，很多人也認為以語言來描述資料的處理是多餘的事情一樣。而ORM盛行的時候，也有人質疑SQL已經很直觀了，為啥又要轉成物件。

"Ronn Brashear said:
...
A good engineer understands the specific problem space, examines the potential solutions, and picks the right tool for the job. "

所以說，Vertica DB發表這一篇也只是商業競爭而已，其實他們並不如Google能夠理解Column-based DBMS的好處，並經其原理應用在BigTable上，其中一個回應也說的對，根據paper裡所說的結構，BigTable是有index(還有vertica做不到的timestamp based query)。這些教授對RDBMS很熟，可是卻完全不瞭解parallel data processing是怎樣回事，因此誤用，並拿來對照。

當然我在上次的書報討論中，也將這幾個paradigm拿來比，是不太對的。不過當然就是想說先讓同學們瞭解一下觀念。

不管怎樣，在此重新釐清一次觀念。

Google File System(GFS)是一種Global File System，目的是以出力(throughput)為主，並不具備任何的檔案分割能力。他與Redhat推出的GFS功能上相似，但實測的檔案大小及效能差異極為懸殊。GFS本身不具備任何的DLM(Distributed Lock Manager)機制，而是以另一套服務稱為Chubby來提供，這也是跟Redhat GFS不同。簡單地說，把他想像能夠高速傳輸上10TB大小檔案的NFS即可。

MapRedurce是一個parallel data processing framework，根據程式設計師撰寫的Mapper/Reducer Function，搭配合併於framework內的checkpoint技術，而進行平行化的資料分析及處理。首先利用GFS的特性，使得大容量(如上述的10TB)並且為單一檔案的資料，能夠分散在適當的節點群組裡。接著Framework的主程序就會自動地散佈開發好的程式，進行呼叫Map,Reduce兩個函式，最後將結果寫回GFS去。也就是說，就某種角度，他比較像Condor，而跟資料庫一點都扯不上關係。至於說他是不是能夠用在Computation上，paper的說法是「有機會」，但我認為除非你將問題切割成資料處理，不然是很難有機會的。

BigTable是一個利用上述Framework所撰寫成的巨大資料集儲存系統，這裡指的是「資料集」，而表示這些資料彼此之間可能不具有任何的「關連」。因此將關連式資料庫能夠有的功能如transcation，拿來比較是不合適的。換句話說，你應該不會經常拿許多份Excel，將其內容合併(join)後才取出資料(select)進行你的工作(真的已經這樣就會去用DB而不是excel了)，而你也不會將資料庫系統裡就建一個表格，然後把所有欄位都放在同一個資料表裡(坦白說我還是有看過人這樣做@@|||)。BigTable如其名，就是一個巨大的表格，就像Excel一樣，而並不是DBMS。儘管在paper裡也提過他擁有一些與DBMS相同的功能，不過這也不代表他是被定義為DBMS。更何況，在這樣大的系統內，要堅持使用特定的觀念去解決事情是一件很不合理的事。

看完了，大部分人可能也還是無法從定義去對應到腦袋裡可以想像的模樣，而不免心裡會有疑問，這些東西搭在一起又能幹嘛？就未來來說，我們有機會擁有下一代平行資料庫的雛形，也有可能就真的只是一輩子被用在Google的應用服務中了。但就現階段而言，請不要忘記這世界上已經有多少人無時無刻地在使用Google的軟體了。