一張圖解釋清楚大數據技術架構，堪稱阿里

我們先來看看這張圖，這是某公司使用的大數據平臺架構圖，大部分公司應該都差不多：

從這張大數據的整體架構圖上看來，大數據的核心層應該是：數據採集層、數據存儲與分析層、數據共享層、數據應用層，可能叫法有所不同，本質上的角色都大同小異。

所以我下面就按這張架構圖上的線索，慢慢來剖析一下，大數據的核心技術都包括什麼。

一、數據採集

數據採集的任務就是把數據從各種數據源中採集和存儲到數據存儲上，期間有可能會做一些簡單的清洗。

數據源的種類比較多：

網站日誌：

作爲互聯網行業，網站日誌佔的份額最大，網站日誌存儲在多臺網站日誌服務器上，

一般是在每臺網站日誌服務器上部署 flume agent，實時的收集網站日誌並存儲到 HDFS 上；

業務數據庫：

業務數據庫的種類也是多種多樣，有 Mysql、Oracle、SqlServer 等，這時候，我們迫切的需要一種能從各種數據庫中將數據同步到 HDFS 上的工具，Sqoop 是一種，但是 Sqoop 太過繁重，而且不管數據量大小，都需要啓動 MapReduce 來執行，而且需要 Hadoop 集羣的每臺機器都能訪問業務數據庫；應對此場景，淘寶開源的 DataX，是一個很好的解決方案，有資源的話，可以基於 DataX 之上做二次開發，就能非常好的解決。

當然，Flume 通過配置與開發，也可以實時的從數據庫中同步數據到 HDFS。

來自於 Ftp/Http 的數據源：

有可能一些合作伙伴提供的數據，需要通過 Ftp/Http 等定時獲取，DataX 也可以滿足該需求；

其他數據源：

比如一些手工錄入的數據，只需要提供一個接口或小程序，即可完成；

二、數據存儲與分析

毋庸置疑，HDFS 是大數據環境下數據倉庫 / 數據平臺最完美的數據存儲解決方案。

離線數據分析與計算，也就是對實時性要求不高的部分，在筆者看來，Hive 還是首當其衝的選擇，豐富的數據類型、內置函數；壓縮比非常高的 ORC 文件存儲格式；非常方便的 SQL 支持，使得 Hive 在基於結構化數據上的統計分析遠遠比 MapReduce 要高效的多，一句 SQL 可以完成的需求，開發 MR 可能需要上百行代碼；

當然，使用 Hadoop 框架自然而然也提供了 MapReduce 接口，如果真的很樂意開發 Java，或者對 SQL 不熟，那麼也可以使用 MapReduce 來做分析與計算；

Spark 是這兩年非常火的，經過實踐，它的性能的確比 MapReduce 要好很多，而且和 Hive、Yarn 結合的越來越好，因此，必須支持使用 Spark 和 SparkSQL 來做分析和計算。因爲已經有 Hadoop Yarn，使用 Spark 其實是非常容易的，不用單獨部署 Spark 集羣。

三、數據共享

這裏的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關係型數據庫和 NOSQL 數據庫；

前面使用 Hive、MR、Spark、SparkSQL 分析和計算的結果，還是在 HDFS 上，但大多業務和應用不可能直接從 HDFS 上獲取數據，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據；和數據採集層到 HDFS 剛好相反，這裏需要一個從 HDFS 將數據同步至其他目標數據源的工具，同樣，DataX 也可以滿足。

另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。

四、數據應用

業務產品（CRM、ERP 等）

業務產品所使用的數據，已經存在於數據共享層，直接從數據共享層訪問即可；

報表（FineReport、業務報表）

同業務產品，報表所使用的數據，一般也是已經統計彙總好的，存放於數據共享層；

即席查詢

即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求；

這種即席查詢通常是現有的報表和數據共享層的數據並不能滿足他們的需求，需要從數據存儲層直接查詢。

即席查詢一般是通過 SQL 完成，最大的難度在於響應速度上，使用 Hive 有點慢，可以用 SparkSQL，它的響應速度較 Hive 快很多，而且能很好的與 Hive 兼容。

當然，你也可以使用 Impala，如果不在乎平臺中再多一個框架的話。

OLAP

目前，很多的 OLAP 工具不能很好的支持從 HDFS 上直接獲取數據，都是通過將需要的數據同步到關係型數據庫中做 OLAP，但如果數據量巨大的話，關係型數據庫顯然不行；

這時候，需要做相應的開發，從 HDFS 或者 HBase 中獲取數據，完成 OLAP 的功能；比如：根據用戶在界面上選擇的不定的維度和指標，通過開發接口，從 HBase 中獲取數據來展示。

其它數據接口

這種接口有通用的，有定製的。比如：一個從 Redis 中獲取用戶屬性的接口是通用的，所有的業務都可以調用這個接口來獲取用戶屬性。

五、實時計算

現在業務對數據倉庫實時性的需求越來越多，比如：實時的瞭解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統數據庫和傳統實現方法基本完成不了，需要的是一種分佈式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm 在這塊是比較成熟了，但我選擇 Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming 比 Storm 延時性高那麼一點點，那對於我們的需要可以忽略。

我們目前使用 Spark Streaming 實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。

做法也很簡單，由 Flume 在前端日誌服務器上收集網站日誌和廣告日誌，實時的發送給 Spark Streaming，由 Spark Streaming 完成統計，將數據存儲至 Redis，業務通過訪問 Redis 實時獲取。

六、任務調度與監控

在數據倉庫 / 數據平臺中，有各種各樣非常多的程序和任務，比如：數據採集任務、數據同步任務、數據分析任務等；

這些任務除了定時調度，還存在非常複雜的任務依賴關係，比如：數據分析任務必須等相應的數據採集任務完成後才能開始；數據同步任務需要等數據分析任務完成後才能開始；

這就需要一個非常完善的任務調度與監控系統，它作爲數據倉庫 / 數據平臺的中樞，負責調度和監控所有任務的分配與運行。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/uXsCDGjlW4dhQ8ax5pW9LA