隨著大數據行業的發展，大數據生態圈中相關的技術也在一直迭代進步，作者有幸親身經歷了國內大數據行業從零到一的發展歷程，通過本文希望能夠幫助大家快速構建大數據生態圈完整知識體系。

目前大數據生態圈中的核心技術總結下來如圖1所示，分為以下9類，下面分別介紹。

一、數據采集技術框架

數據采集也被稱為數據同步。隨著互聯網、移動互聯網、物聯網等技術的興起，產生了海量數據。這些數據散落在各個地方，我們需要將這些數據融合到一起，然后從這些海量數據中計算出一些有價值的內容。此時第一步需要做的是把數據采集過來。數據采集是大數據的基礎，沒有數據采集，何談大數據！

數據采集技術框架包括以下幾種：

Flume、Logstash和FileBeat常用于日志數據實時監控采集，它們之間的細節區別見表1： Sqoop和Datax常用于關系型數據庫離線數據采集，它們之間的細節區別見表2： Cannal和Maxwell常用于關系型數據庫實時數據采集，它們之間的細節區別見表3：

Flume、Logstash和FileBeat的技術選型如圖2所示：

Sqoop和Datax之間的技術選型如圖3所示：

Cannal和Maxwell之間的技術選型如圖4所示：

二、數據存儲技術框架

數據的快速增長推動了技術的發展，涌現出了一批優秀的、支持分布式的存儲系統。

數據存儲技術框架包括HDFS、HBase、Kudu、Kafka等。

HDFS它可以解決海量數據存儲的問題，但是其最大的缺點是不支持單條數據的修改操作，因為它畢竟不是數據庫。

HBase是一個基于HDFS的分布式NoSQL數據庫。這意味著，HBase可以利用HDFS的海量數據存儲能力，并支持修改操作。但HBase并不是關系型數據庫，所以它無法支持傳統的SQL語法。

Kudu是介于HDFS和HBase之間的技術組件，既支持數據修改，也支持基于SQL的數據分析功能；目前Kudu的定位比較尷尬，屬于一個折中的方案，在實際工作中應用有限。

Kafka常用于海量數據的臨時緩沖存儲，對外提供高吞吐量的讀寫能力。

三、分布式資源管理框架

在傳統的IT領域中，企業的服務器資源（內存、CPU等）是有限的，也是固定的。但是，服務器的應用場景卻是靈活多變的。例如，今天臨時上線了一個系統，需要占用幾臺服務器；過了幾天，需要把這個系統下線，把這幾臺服務器清理出來。

在大數據時代到來之前，服務器資源的變更對應的是系統的上線和下線，這些變動是有限的。隨著大數據時代的到來，臨時任務的需求量大增，這些任務往往需要大量的服務器資源。如果此時還依賴運維人員人工對接服務器資源的變更，顯然是不現實的。因此，分布式資源管理系統應運而生，常見的包括YARN、Kubernetes和Mesos，它們的典型應用領域如圖5所示。

四、數據計算技術框架

數據計算分為離線數據計算和實時數據計算。

1. 離線數據計算

大數據中的離線數據計算引擎經過十幾年的發展，到目前為止主要發生了3次大的變更。

MapReduce可以稱得上是大數據行業的第一代離線數據計算引擎，主要用于解決大規模數據集的分布式并行計算。MapReduce計算引擎的核心思想是，將計算邏輯抽象成Map和Reduce兩個階段進行處理。

Tez計算引擎在大數據技術生態圈中的存在感較弱，實際工作中很少會單獨使用Tez去開發計算程序。

Spark最大的特點就是內存計算：任務執行階段的中間結果全部被放在內存中，不需要讀寫磁盤，極大地提高了數據的計算性能。Spark提供了大量高階函數（也可以稱之為算子），可以實現各種復雜邏輯的迭代計算，非常適合應用在海量數據的快速且復雜計算需求中。

2. 實時數據計算

業內最典型的實時數據計算場景是天貓“雙十一”的數據大屏。數據大屏中展現的成交總金額、訂單總量等數據指標，都是實時計算出來的。用戶購買商品后，商品的金額就會被實時增加到數據大屏中的成交總金額中。

Storm主要用于實現實時數據分布式計算。

Flink屬于新一代實時數據分布式計算引擎，其計算性能和生態圈都優于Storm。

Spark中的SparkStreaming組件也可以提供基于秒級別的實時數據分布式計算功能。

他和Storm、Flink之間的區別見表4。

Storm、Spark、Flink 之間的技術選型如圖6所示。

目前企業中離線計算主要使用Spark，實時計算主要使用Flink。

五、數據分析技術框架

數據分析技術框架包括Hive、Impala、Kylin、Clickhouse、Druid、Drois等，它們的典型應用場景如圖7所示。

Hive、Impala和Kylin屬于典型的離線OLAP數據分析引擎，主要應用在離線數據分析領域，它們之間的區別見表5。

表5

Hive的執行效率一般，但是穩定性極高；

Impala基于內存可以提供優秀的執行效率，但是穩定性一般；

Kylin通過預計算可以提供PB級別數據毫秒級響應。

Clickhouse、Druid和Drois屬于典型的實時OLAP數據分析引擎，主要應用在實時數據分析領域，它們之間的區別見表6。

Druid和Doris是可以支持高并發的，ClickHouse的并發能力有限；Druid中的SQL支持是有限的，ClickHouse支持非標準SQL，Doris支持標準SQL，對SQL支持比較好。

目前Druid和ClickHouse的成熟程度相對比較高，Doris處于快速發展階段。

六、任務調度技術框架

包括Azkaban、Ooize、DolphinScheduler等。它們適用于普通定時執行的例行化任務，以及包含復雜依賴關系的多級任務進行調度，支持分布式，保證調度系統的性能和穩定性，它們之間的區別見表7。

它們之前的技術選型如圖8所示。

七、大數據底層基礎技術框架

大數據底層基礎技術框架主要是指Zookeeper。Zookeepe主要提供常用的基礎功能（例如：命名空間、配置服務等），大數據生態圈中的Hadoop（HA）、HBase、Kafka等技術組件的運行都會用到Zookeeper。

八、數據檢索技術框架

隨著企業中數據的逐步積累，針對海量數據的統計分析需求會變得越來越多樣化：不僅要進行分析，還要實現多條件快速復雜查詢。例如，電商網站中的商品搜索功能，以及各種搜索引擎中的信息檢索功能，這些功能都屬于多條件快速復雜查詢的范疇。

在選擇全文檢索引擎工具時，可以從易用性、擴展性、穩定性、集群運維難度、項目集成程度、社區活躍度這幾個方面進行對比。Lucene、Solr和Elasticsearch的對比見表8。

九、大數據集群安裝管理框架

企業如果想從傳統的數據處理轉型到大數據處理，首先要做就是搭建一個穩定可靠的大數據平臺。

一個完整的大數據平臺需要包含數據采集、數據存儲、數據計算、數據分析、集群監控等功能，這就意味著其中需要包含Flume、Kafka、Haodop、Hive、HBase、Spark、Flink等組件，這些組件需要部署到上百臺甚至上千臺機器中。

如果依靠運維人員單獨安裝每一個組件，則工作量比較大，而且需要考慮版本之間的匹配問題及各種沖突問題，并且后期集群維護工作也會給運維人員造成很大的壓力。

于是，國外一些廠商就對大數據中的組件進行了封裝，提供了一體化的大數據平臺，利用它可以快速安裝大數據組件。目前業內最常見的是包括CDH、HDP、CDP等。

HDP：全稱是 Hortonworks Data Platform。它由 Hortonworks 公司基于 Apache Hadoop 進行了封裝，借助于 Ambari 工具提供界面化安裝和管理，并且集成了大數據中的常見組件， 可以提供一站式集群管理。HDP 屬于開源版免費大數據平臺，沒有提供商業化服務；

CDH：全稱是 Cloudera Distribution Including Apache Hadoop。它由 Cloudera 公司基于 Apache Hadoop 進行了商業化，借助于 Cloudera Manager 工具提供界面化安裝和管理，并且集成了大數據中的常見組件，可以提供一站式集群管理。CDH 屬于商業化收費大 數據平臺，默認可以試用 30 天。之后，如果想繼續使用高級功能及商業化服務，則需要付費購買授權，如果只使用基礎功能，則可以繼續免費使用；

CDP：Cloudera 公司在 2018 年 10 月份收購了 Hortonworks，之后推出了新一代的大數據平臺產品 CDP（Cloudera Data Center）。CDP 的版本號延續了之前 CDH 的版本號。從 7.0 版本開始， CDP 支持 Private Cloud（私有云）和 Hybrid Cloud（混合云）。CDP 將 HDP 和 CDH 中比較優秀的組件進行了整合，并且增加了一些新的組件。

三者的關系如圖9所示。