通俗易懂的大數據平臺概念和架構

前言

今天爲什麼來寫這個內容了，一是前些天有個非行業內的好朋友想了解下大數據相關概念的內容，搜了下網上平臺相關的介紹，對於業內和業外的感覺都不太完善和直觀。另外就是自己也想定時歸納下認知。所以今天特意描述下自己的拙見，也歡迎大家指點。

問題

在開始今天的描述前，這裏我先提一個問題。假設雙11馬總讓大家來計算下淘寶過去1小時購物車的點擊次數，你打算怎麼做了？我們一步步來看這個問題。

什麼是大數據

首先既然是要獲取購物車點擊次數，那麼我們首先得把用戶的點擊數據保存下來，對於淘寶來說雙11數億人1個小時數據，腦補下也是隻能用海量（Volume） 形容吧。當然實際存儲的肯定是更加多樣的（Variety） 數據，比如馬總又想單獨看國內用戶的點擊，是不是又得記錄用戶信息相關數據。
接下來當我們存好數據後，是不是隻要刷選出點擊標籤爲購物車的記錄彙總就行了。不過萬億級數據我們用一個臺計算機來做，就算它真的能處理，計算出結果也不知道是何年何月了。那如何快速（Velocity） 計算統計出這個有價值（Value） 的數據，這就正是我們從事大數據要考慮的事了，因爲老闆還在那裏等着了。
以上描述的4V也就是大數據的4大特徵。其中Value的產出正是大數據的價值體現。

爲什麼需要數據平臺

• 提供上述多樣化、海量數據的存儲能力，又提供強大、快速的計算能力。然後通過這兩個能力得到我們所想要的價值Value，這個價值可以是直觀的報表數據，可以網易雲音樂根據大家喜好生成的每日推薦，也可以是對股票未來趨勢預測等（如何你會的話記得聯繫我）。而這些能力真正的提供者，是多臺計算機（之後都稱節點）、多個應用組件共同的支持。
• 爲保證這些能力能夠正常施展，並在之後升級更強大的力量。就需要有個地方統一管理這些機器和組件。比如1000個節點組件需要修改一個配置，大家不能手動一個個修改吧，肯定是考慮通過一鍵配置的方式。平臺另一個重要作用就是對整個集羣進行監控管理，大家平時在網吧是不是偶爾聽人說死機、藍屏什麼的。同樣大規模集羣中節點出問題也是常有的事。就需要系統有監控、報警的機制才能方便管理。

數據平臺

整體模型

下圖描述了數據平臺簡單結構。我會結合自己的理解做一些說明和補充。接下來描述的內容會更側重技術範疇。

模塊分析

• 數據源
  如上圖所示最下面的部分。觀察仔細的話會發現它並沒有納入數據平臺中，是的，嚴格來說這些豐富的數據源並非數據平臺所管理的範疇。但這些底層數據確實是數據倉庫中很重要的一環，所以數據平臺雖然沒有直接管理，通常情況會通過一系列的組件和方式同步到數倉中。
  其中數據類型包括有RDBMS的結構化數據、JSON格式的半結構化數據、音頻文件的非結構化數據等。
• 數據集成
  上面我們提到數據要同步到數據倉庫中，那通過何種方式來進行，這就到了數據平臺所管轄的範疇了。常用的非實時接入有Sqoop、DataX等組件，側重實時處理的組件有JAVA NIO、消息隊列MQ、Flume等工具。這個環節也可以簡單理解爲數據傳輸。
  集成的過程，也是數據平臺開始收納數據的開始，這個過程實現了平臺和外部系統的解耦。至於數據內容可以是完全一致，也可以做初步的格式處理。比如同時多個系統數據流入，就可以通過簡單處理實現數據格式的歸一。
• 文件存儲
  數據平臺接收到多種類型的數據後，我們肯定就要考慮把他們安置好。那麼現在市面上主流的分佈式文件系統就有Hadoop的hdfs、新興的clickhouse、專注時序的Druid，也有少部分公司使用kudu等這些其他工具。（這裏我們提到的存儲介質限於元數據的接入、後續數據處理後會有更多不同特性工具）
  而這些文件系統主要爲我們做了什麼了。第一就是管理元數據，因爲我們海量數據肯定是要存在N臺計算機的吧，沒有管家我們怎麼高效查找、存儲數據了。第二個很重要的就是幫我們做數據的備份冗餘。我們前面提到節點一多，那麼集羣機器故障的概率也就大大提升了。數據只有同時存在多個節點、才能更好的保障數據的完整性。
• 數據計算
  這個過程也常被稱作Transform，也就是數據間的一些轉換，包括機器學習相關的一些算法處理。我們常把一次完整計算叫做一個任務job。目前常見的計算引擎有spark、presto、impala、flink-sql等，實時處理框架有flink、spark streaming、storm等，預計算框架kylin，存儲計算一體的clickhouse。這個階段也是數據開發來實現各種業務的主要層級之一。
• 結果落地
  上圖的數據分析層可以由結果落地和數據服務層來替代。通過上面計算出來的結果通常是我們可以直接或者間接使用的數據了，這類上層數據一般會要求有查詢低延遲特性，甚至有高併發的場景。所以我們會根據場景和數據類型選取合適的存儲介質，比如Hbase、Elasticsearch、Mysql、MongoDB、Redis等。爲後續的數據服務提供更好的支持。
• 數據服務
  通常數據服務可以是數據組的同學來負責，也可以是後臺的同事來支持。主要是搜索落地的數據，提供相關API給到外部系統。
• 統一資源調度
  這個模塊沒有在圖中畫出，理論上它是跨越數據集成至結果落地的。我們數據集成有些是實時、有些是離線。數據計算有些是5分鐘、有些是每天執行。而任務job之間也可能存在多種依賴，成千上萬個任務如果讓人手動維護肯定是不現實的。所以會專門的工具Azkaban、Oozie等來管理這些任務。這裏也能做一層數據權限控制。
• 可視化平臺
  可視化界面可以更方面的管理集羣、比如增刪節點和組件，統一修改配置等。另外也能更直觀監控集羣狀態，包括節點狀態、cpu、內存、網絡情況等。如下圖是Ambari的Dashborad。這塊也涵蓋了運維不少內容。
  
• 冰川之下
  上述提到的層級是我們能直觀感受到的鏈路，除此之外撐起數據平臺還有常被大家忽略的冰山之下的模塊。包括數據質量校驗、元數據管理、多用戶管理等。

主流平臺

• CDH
  

• HDP
  上述Ambari就是其產品。目前已和CDH合併、預計在2021年會推出CDP的新產品。