移動計算比移動數據更划算 - 大數據技術源起

傳統的軟體計算處理模型，都是「輸入->計算->輸出」模型。也就是說，一個程序給它傳入一些數據也好，它自己從某個地方讀取一些數據也好，總是先獲得一些輸入數據，然後對這些數據進行計算處理，最後得到輸出結果。

但是在互聯網大數據時代，需要計算處理的數據量急速膨脹。一則因為互聯網用戶數遠遠超過傳統企業的用戶，相應產生大量的數據；二則很多以往被忽視的數據重新被發掘利用，比如用戶在一個頁面的停留時長都會被記錄下來進行分析。在稍微大一點的互聯網企業，需要計算處理的數據量常常以P計（ byte）。

正因為如此，傳統的計算處理模型不能適用於大數據時代的計算要求。難以想像，一個程序讀取P級的數據進行計算是怎樣一個場景，一個程序所能調度的網路帶寬（通常數百M）、內存容量（通常幾十G）、磁碟大小(通常數T)、CPU運算速度是不可能滿足這種計算要求的。

這個問題的解決思路跟大型網站的分散式架構思路是一樣的，那就是採用分散式集群的解決方案（詳情參考《大型網站技術架構：核心原理與案例分析》），用數千台（甚至上萬台）計算機構建一個大數據計算處理集群，利用更多的網路帶寬、內存空間、磁碟容量、CPU核心數去進行計算處理。

但是大數據計算處理的場景跟網站的實時請求處理場景又有很大不同，網站實時處理通常針對單個用戶的請求操作，雖然大型網站面臨大量的高並發請求（比如天貓的雙十一活動），但是每個用戶之間的請求是獨立的，只要網站的分散式系統能將不同用戶的不同業務請求分配到不同的伺服器上，只要這些分散式的伺服器之間耦合關係足夠小，那麼就可以通過添加更多的伺服器去處理更多的用戶請求及由此產生的用戶數據。這也正是網站系統架構的核心原理。

但是大數據計算處理通常針對的是網站的存量數據，也就是剛才提到的用戶請求產生的數據，這些數據之間是有大量關聯的，比如購買同一個商品的用戶之間的關係（協同過濾），同一件商品的歷史銷量走勢（統計分析）。網站大數據系統要做的就是將這些統計規律和關聯關係計算出來，並由此進一步改善網站的用戶體驗和運營決策。

為了解決這種計算場景的問題，大型網站設計了一套相應的技術架構方案。最早的時候由Google實現並通過論文的方式發布出來，隨後根據這些論文，開源社區開發出對應的開源產品，並得到業界的普遍支持和應用。

這套方案的核心思路是，既然數據是龐大的，將數據輸入給程序是不划算的，那麼就反其道而行之，將程序分發到數據所在的地方進行計算，也就是所謂的移動計算比移動數據更划算。整套方案包括大數據存儲，大數據計算、大規模計算資源調度、大數據倉庫引擎、大數據挖掘計算框架等一系列產品。

這就是鼎鼎大名的Hadoop及其生態體系。