駕馭雲端龐大計算規模的基本認知

雲端計算平臺的建構，除了能把開發者將應用程式放置到網路上提供服務需要付出的代價，盡可能降到最低之外，也衍生出另一個重要的作用，那就是更大規模的計算能力及資料處理能力。

雲端計算平臺的背後，是以分散式計算的理論及技術做為後盾，只不過，盡可能將各種細節予以封裝，使得應用程式的開發者可以在不理會這些技術細節的情況下，透過十分高階又抽象的方式，來開發運作於雲端平臺上的應用程式。而憑藉著分散式計算技術所打造出來的雲端計算平臺，擁有分散式計算本質上具備的能力。而基於雲端計算平臺開發應用程式的程式設計者，便有機會利用平臺本身的基礎設施，便利地進行大規模的計算及資料處理。

為什麼雲端利用分散式計算？
我們都知道，兩部機器同時進行運算，肯定比一部機器快。而若有成千上萬的機器同時在運算，那計算的速度更是天差地遠。既然如此，為什麼當我們遇上需要解決大量計算量問題的時候，我們不利用多一點的機器來處理計算就好呢？

對開發者而言，這中間存在一些問題。

第一，一般的個人開發者或團體，並沒有大量的機器可供執行解決運算問題的程式。

第二，即使有大量的機器可供運用，分散式計算需要建立計算基礎設施，這樣的基礎設施得提供一些機制，像是將程式自動分散到多部機器上、允許這些程式之間相互溝通，並且在某些執行程式的機器上發生錯誤時，能夠進行錯誤狀態的修復或者是容忍。

第三，程式設計者必須有能力設計出能被分散計算的程式。這是在說，倘若你要解決的運算問題其運算量很大，而你又希望透過多部機器來分散這計算量，那麼你就必須要能夠將你的問題本身拆解成若干個子問題，才能將這多個子問題丟到多部機器上去計算，當各個機器的計算完成後，也必須要透過某種方式，將各個計算結果合併、彙整、甚至再進行一些額外的計算，才能得到最後的結果。

要明白分散式計算可以加快計算速度這一點，在觀念上是很容易，但對大多數的程式設計者而言，既要擁有大量的硬體資源、又得建構出必要的基礎設施、還要發展出解題的模型，這中間存在的障礙實在不小，也因此，讓分散式計算一直被認為不是一種很親民的計算方式。

不過，發展雲端計算的過程中，其相關的產物降低了一般程式設計者接近分散式計算的門檻。一來，雲端計算平臺先天就提供了大量的硬體資源可供運用，解決了開發者自行準備硬體的成本難題。二來，雲端計算平臺背後本來就是以分散式計算的技術搭建而成，相關設施已一應俱全。當這兩個條件都已具備的時候，那麼問題就剩下最後一個了，也就是如何讓程式設計者能夠輕易設計出能被分散計算、處理的程式。

採用不同的程式設計模型
其實，發展這些雲端計算平臺的單位，在他們對大眾公布他們的雲端平臺服務之前，老早就思考這樣的問題，因為，他們之所以會發展出他們的雲端平臺，最原先的出發點，往往一開始並不是為了要提供對外的服務，而是為了要解決他們自己本身的問題，著名的Google便是一例。

Google在開發他們的搜尋引擎時，本來就發展出一套串連大量小型計算機器的機制，大規模的分散式計算，本來就是他們的看家本領。發展出一種便利的將工作分散到多部機器上進行計算的程式設計模型，對Google來說，自然是一個重要的議題。

在2004年，Google發表了名為MapReduce的程式設計模型，在這個程式設計模型中，很巧妙地運用了函數程式設計中map和reduce的觀念，這樣的觀念，在我們需要將資料分散到多部機器上處理時，可以發揮很大的作用。
基本上，它是依循著所謂「分而治之（divide and conquer）」的精神，將問題拆解成互不相干的若干個子問題，然後將問題拆解到最小的層次之後，在這個最小的層次上解決最小的子問題，接著再一一將各個子問題的答案給合併，最終求得原始問題的答案。因為在這過程中，問題會被拆解成若干個子問題，而這些子問題，便可以分別丟到不同的機器上去執行，因而達到分散平行運算的目的，也得到了分散平行運算的好處。

關於MapReduce的細節，在這邊並不打算多談，我想表示的是，雲端計算平臺提供的是一個可分散式平行運算的環境，而想要善用這個環境，有一個重要的關鍵，便是掌握其程式設計模型，而MapReduce便是現今一個重要的程式設計模型，你必須先能掌握這程式設計模型，了解你的問題是否適用於使用MapReduce來解決，以及該如何運用它來解決。

當你想要分散平行的運算能力時，所採取的程式設計方式、解題的方法、計算的模型，肯定和傳統上你所習慣的方式不同，這是登上雲端從事進行計算時，所必須要有的心理準備。

沿用既有做法，已無法因應專屬的資料存取方式
類似的情況，有些雲端平臺為了提供更大規模的資料處理能力，在資料處理上，也可能提供有別於你所習慣的方式，例如關聯式資料庫。

同樣的，我們再以Google為例。為了處理巨量的結構性資料，Google設計出一個名為BigTable的分散式儲存系統。當然，有很多Google自身的服務都使用BigTable來儲存資料。當然，你可以說它是個資料庫系統，但是，它不具備關聯式的特性，所以使用這類的資料庫的方式，便和傳統上你使用SQL去存取關聯式資料庫的方式大異其趣。它甚至不是以資料列（row）為導向，而是以資料欄（column）為導向。但無疑的，它具備了極高的性能。

不可諱言，關聯式資料庫有其應用的領域，但對於非常大量的資料處理需求、卻又不需要關聯式特性的應用程式來說，關聯式資料庫便有先天特質上的限制。這當然也是Google最後發出BigTable這類型產物的原因。

當你在提供特定資料存取模型的雲端平臺上開發應用程式時，你多半沒有熟悉的關聯式資料庫可供運用，你能使用的，便是這種專門的資料存取系統，因此，也必須讓自己適應、熟悉不同的資料存取模型，才能在此類的平臺上達到目的。

不同的資料存取模型，便會影響到你規畫資料的設計方式，進一步影響到資料的運用。對程式設計者的影響也實在不小。不過，憑藉著這種專屬的分散式資料庫系統，對於想要存取大規模資料的你來說，可以說是一把鋒利的寶劍，雖然它或許沒有關聯式資料庫來得通用，但存取的效能將會十分的高。

當我們撰寫運作於雲端平臺的機器時，除了可以享用到雲端平臺所提供的硬體資源，以及計算的基礎設施之外，程式設計者本身也會需要改變程式設計的方式。倘若想要運用分散平行計算的資源，那麼，就得善用雲端平臺所提供的分散平行計算模型以及機制；如果想要提高資料存取的效能，那麼同樣的得好好運用雲端平臺所提供的資料存取模型及系統。不論是計算模型或資料存取模型，都有可能會因為登上了雲端而有所不同。