2019年3月9日Robin.ly線上技術交流活動特邀Alluxio公司創始成員、開源專案PMC成員範斌博士，與Robin.ly社群成員分享資料架構在過去幾十年的演變過程，以及他多年來從事分散式系統研究的經歷和體會。
範斌(右)與Robin.ly主持人Julia(左)在矽谷線上分享並與社群互動
1 職業經歷
範斌在矽谷Robin.ly線上分享並與社群互動
2 資料架構的演變
Garth Gibson是RAID系統的發明者，也是我的博士答辯委員會成員。在八十年代的初期，人們還對需要多個硬碟儲存資料這個想法嗤之以鼻，而他們在試圖解釋這一概念的好處：這是一種用於分配儲存的新演算法，能夠實現更大的資料吞吐量，更好的佈局，更優的計算效能。
而當時一個磁碟就已經造價不菲，使得人們沒有任何動力去追求更多的硬碟。而現在，它的體積已經變得很小，在任何一個桌上型電腦和膝上型電腦中都已經可以裝得下多個不同的硬碟，還能連線一些外部儲存器。
在上世紀90年代起，人們意識到這是大勢所趨，於是開始嘗試打造多硬碟驅動系統並將不同的應用程式連線到儲存系統。那個時候，功能的構建包含兩個部分：一部分重點關注如何低成本高效率的儲存和提供位元組；另一部分是如何構建更高效的CPU和伺服器，已實現快速有效的處理其他部件所提供的位元組。
在本世紀頭十年間，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上構建基礎架構。儲存服務主要由物件儲存系統提供。雲服務供應商正是以這樣更廉價，更具可擴充套件性和更靈活的方式，基於個性化的應用來提供多樣的儲存服務。這是一個極為重要的應用。如果想讓不同的機器執行應用程式，只需要將應用程式連線到這些物件儲存系統，這樣一來就再次實現了可擴充套件物件儲存系統和計算資源的去耦合。
以上就是資料架構的大致發展軌跡。我們可以從中看到一個迴圈：緊密耦合的架構 -> 去耦合的分散式儲存架構 -> 大資料規模下具有水平可擴充套件性的分散式檔案系統耦合模型 -> 雲環境中的可擴充套件物件儲存和計算資源的去耦合。這是個非常有趣的迴圈發展過程。
3 大資料生態系統面臨的挑戰
大資料生態系統正變得越來越複雜，也帶來了很多挑戰。在工作中能夠擁有更多不同的選擇對使用者來說是件好事。然而，對於很多公司來說，後端基礎設施會變得越來越複雜，因為他們必須同時支援各種處理資料的方法，於是只能在其系統中新增更多的新系統。
此外，對於用不同方法處理的常見資料，如何才能保證人們可以有效的共享不同框架呢？例如，在不同的Spark任務之間共享資料非常麻煩，因為每個Spark任務只會將自己的資料快取到本身程式當中。所以必須找到一種巧妙的方法在像Spark這樣的同一個框架內進行資料共享。如果你想在Spark，Presto，Hadoop和TensorFlow之間實現高階的資料共享，難度就更大了。
另一個挑戰是，隨著許多資料應用的資料規模變得越來越龐大，很多使用者反映他們要用到數以萬計，甚至更多的機器。在這個規模之上，要實現管理叢集以及管理資料和獲得更高的處理能力，都需要很高的成本。
4 計算和儲存間的解決方案—資料編排層
1）資料本地性。Hadoop MapReduce將計算移動到接近資料所在節點位置，具有良好的本地性。雲時代儲存與計算分開，節約了儲存空間的同時卻造成了計算效率下降。那麼如何能夠延續Hadoop的資料本地性？
2）資料抽象。如果使用混合雲解決方案，如何才能將多個不同型別的資料儲存系統混合到一個統一的抽象中，讓應用程式可以自如的處理資料而無需在意物理上的差異？
3）可訪問性。構建可以訪問一種型別的儲存的應用程式非常容易，但是如果有多個不同的儲存空間，如何保證開發人員依然能夠方便的訪問資料？
面對各種挑戰，結合在伯克利AMPLab的經驗，並與資料生態系統中的不同使用者溝通之後，我們認為應該在計算和儲存種插入一個新的“資料編排層（Data Orchestration Layer）”作為解決方案，相應的一個開源實現方案就是開源專案Alluxio。我們認為，現在工業界已經正在引入這一解決方案來應對挑戰了。這種架構的創新之處在於構建了一層統一的資料抽象，讓不同的潛在後端儲存系統都可以被訪問，而且能夠將資料轉移到需要的地方。
5 案例研究
下面我想通過一些實際案例來說明為什麼需要新增一個新的層，在面臨這一新的挑戰時會遇到哪些問題以及應該如何解決。
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），這將直接影響他們完成機器學習模型的效率。
最後，他們發現可以在不同的分散式檔案系統或不同資料來源上使用一層資料將這種差異隱藏起來。只要他們能夠理解一個統一的資料邏輯檢視，就可以高枕無憂，等待資料層幫他們進行資料轉移和管理。這樣一來，他們就能夠以很高的工作效率，非常輕鬆地進行模型開發。