在本世紀頭十年間，Google發表了三篇關於Google File System，Bigtable和MapReduce的論文，它們被認為是分散式系統領域最經典的文章之一。當時Google面臨的問題是，有太多的數據要存儲，但專用硬體對他們來說太貴了。於是Google的工程師們想要找到一種不同的方式儲存來自整個互聯網的數據。於是他們打算構建一個不同於Scale Up模式，而是通過Scale Out來保證數據存儲的可靠性，同事盡量將存儲數據和計算共置。於是Google的Google File System將數十萬臺機器組合在一起以提升處理能力和數據吞吐量，用市面上能買到的比較廉價的硬體就能實現，這也就意味著製造成本相對低廉。這個想法在那個時期有著革命性的意義。

由於Google的解決方案並沒有開源。開源社區的人在讀了這些論文之後，認為這些都是很好的想法，於是想要找到一些方法來實現這個計算和存儲的模型。Hadoop協議棧以及開源社區就這樣應運而生了。Hadoop作為工業界廣為接受的大數據的生態系統，忠實的再現了Google的這幾篇論文裏提出的將存儲和計算再次進行耦合的模型。

那麼發展到今天是什麼樣的狀況呢？如果找剛成立一兩年的創業公司談一下，就會發現其中大部分公司不再需要構建自己的內部基礎架構，而是直接在Amazon AWS，Google Cloud，或者Microsoft Azure上構建基礎架構。存儲服務主要由對象存儲系統提供。雲服務供應商正是以這樣更廉價，更具可擴展性和更靈活的方式，基於個性化的應用來提供多樣的存儲服務。這是一個極為重要的應用。如果想讓不同的機器運行應用程序，只需要將應用程序連接到這些對象存儲系統，這樣一來就再次實現了可擴展對象存儲系統和計算資源的去耦合。

以上就是數據架構的大致發展軌跡。我們可以從中看到一個循環：緊密耦合的架構 -> 去耦合的分散式存儲架構 -> 大數據規模下具有水平可擴展性的分散式文件系統耦合模型 -> 雲環境中的可擴展對象存儲和計算資源的去耦合。這是個非常有趣的循環發展過程。

大數據生態系統面臨的挑戰

大數據生態系統正變得越來越複雜，也帶來了很多挑戰。在工作中能夠擁有更多不同的選擇對用戶來說是件好事。然而，對於很多公司來說，後端基礎設施會變得越來越複雜，因為他們必須同時支持各種處理數據的方法，於是隻能在其系統中添加更多的新系統。

此外，對於用不同方法處理的常見數據，如何才能保證人們可以有效的共享不同框架呢？例如，在不同的Spark任務之間共享數據非常麻煩，因為每個Spark任務只會將自己的數據緩存到本身進程當中。所以必須找到一種巧妙的方法在像Spark這樣的同一個框架內進行數據共享。如果你想在Spark，Presto，Hadoop和TensorFlow之間實現高級的數據共享，難度就更大了。

另一個挑戰是，隨著許多數據應用的數據規模變得越來越龐大，很多用戶反映他們要用到數以萬計，甚至更多的機器。在這個規模之上，要實現管理集羣以及管理數據和獲得更高的處理能力，都需要很高的成本。

計算和存儲間的解決方案——數據編排層

如果想以更靈活、高效和低成本的方式搭建基礎框架，比如實現數據驅動應用中計算和存儲的獨立擴展，還要考慮以下幾個技術上的問題。

1）數據本地性。Hadoop MapReduce將計算移動到接近數據所在節點位置，具有良好的本地性。雲時代存儲與計算分開，節約了存儲空間的同時卻造成了計算效率下降。那麼如何能夠延續Hadoop的數據本地性？

2）數據抽象。如果使用混合雲解決方案，如何才能將多個不同類型的數據存儲系統混合到一個統一的抽象中，讓應用程序可以自如的處理數據而無需在意物理上的差異？

3）可訪問性。構建可以訪問一種類型的存儲的應用程序非常容易，但是如果有多個不同的存儲空間，如何保證開發人員依然能夠方便的訪問數據？

面對各種挑戰，結合在伯克利AMPLab的經驗，並與數據生態系統中的不同用戶溝通之後，我們認為應該在計算和存儲種插入一個新的「數據編排層（Data Orchestration Layer）」作為解決方案，相應的一個開源實現方案就是開源項目Alluxio。我們認為，現在工業界已經正在引入這一解決方案來應對挑戰了。這種架構的創新之處在於構建了一層統一的數據抽象，讓不同的潛在後端存儲系統都可以被訪問，而且能夠將數據轉移到需要的地方。

案例研究

下面我想通過一些實際案例來說明為什麼需要添加一個新的層，在面臨這一新的挑戰時會遇到哪些問題以及應該如何解決。

1. 彈性模型訓練（Elastic Model Training）- Two Sigma

第一個實例是彈性模型訓練。我們的一個用戶是Two Sigma，華爾街頂級對沖基金。時效性對他們至關重要。他們在訓練機器學習模型時發現，彈性地利用雲上的機器資源進行模型訓練的效果非常好。因為這樣一來，可以顯著降低維護自有的計算機集羣的成本，而且工作任務可以更好的在上百臺機器中間進行分配。

但是這存在一個問題，對於這樣一家華爾街公司，數據是重中之重。他們只願意將數據存儲在公司內部的基礎設施中， 但將數據一次次移動到雲端會導致高昂的成本，並且機器學習模型訓練可能變得異常複雜。於是，他們將這個新的數據層與他們的機器學習工具，比如Spark部署在一起，一旦數據移動到Alluxio層，就可以進行緩存處理和數據管理，以避免機器學習訓練的過程中反覆從他們的數據源讀取數據。這種方式可以讓他們的開發機器學習模型的效率提高十倍，獲得非常好的投資回報。

2. 準實時數據處理流水線（Near Real-time Data Pipeline） - 唯品會

還有一個很有意思的例子是電子商務公司唯品會的準實時數據流水線。這些關鍵的流水線可以提供推薦和分析銷售原因等任務，能夠幫助數據科學家們理解為什麼有人會去他們的網站購買商品，比如是因為平臺正在搞促銷活動，還是因為他們剛好有優惠券，或者是在哪裡看到了廣告推介。因此，他們利用Spark將相關數據結合一些統計演算法來推斷當前的購買決定是否源於之前的某些特定行為。關鍵在於，人們不會一直在網上購物，多數人只會停留十幾分鐘到幾十分鐘。因此這些統計推斷必須在用戶離開前對行為數據進行實時分析以獲得有意義的結果，並及時根據反饋進行調整。

在通常情況下， 常規的架構可能也可以滿足要求。但是到了像「雙11」這樣的熱門購物促銷日，網路流量就變得異常龐大。在這種情況下，應用程序與其數據之間的網路流量數據就不那麼可靠了。於是，唯品會的工程師們為這些流水線提供了「另一層數據」，能夠幫助他們獲得非常穩定的數據訪問量。例如，他們可以使用Alluxio並把內存（memory）作為數據存儲設備，其提供的高帶寬可以滿足Spark的數據消費任務的需求。在這種情況下，數據處理流水線變得更加穩定，及時的推薦和銷售歸因可以提升網站的訪問 - 購買轉化率，數據科學家的工作也變得更加得心應手。

3. 提高數據科學家的工作效率 - 美國電信公司

我想分享的最後一個例子是如何讓數據科學家的生活更輕鬆。機器學習應用程序可以通過一個新的智能數據層來訪問數據。有一家歷史悠久的美國頂級電信公司，擁有許多不同的傳統基礎設施，繁雜的部門也衍生出了非常分散的數據源。每當他們的數據科學家們想要用稍微高級一點的方式使用某些數據時都會覺得舉步維艱。他們必須進行無數次的ETL操作（Extract, Transform and Load），這將直接影響他們完成機器學習模型的效率。

最後，他們發現可以在不同的分散式文件系統或不同數據源上使用一層數據將這種差異隱藏起來。只要他們能夠理解一個統一的數據邏輯視圖，就可以高枕無憂，等待數據層幫他們進行數據轉移和管理。這樣一來，他們就能夠以很高的工作效率，非常輕鬆地進行模型開發。（完）

訪問Robin.ly觀看完整英文技術分享視頻。關注我們的微信訂閱號（Robinly）及時獲得更多科技訪談和活動信息。

推薦閱讀：