大數據技術體系（轉）

原文：https://mp.weixin.qq.com/s/ky-a4Me6wHvT9zvFFVLWnA

作者：武哥漫談IT（微信公眾號）

如果要問最近幾年，IT行業哪個技術方向最火？一定屬於ABC，即AI + Big Data + Cloud，也就是人工智能、大數據和雲計算。

這幾年，隨着互聯網大潮走向低谷，同時傳統企業紛紛進行數字化轉型，基本各個公司都在考慮如何進一步挖掘數據價值，提高企業的運營效率。在這種趨勢下，大數據技術越來越重要。所以，AI時代，還不了解大數據就真的OUT了！

相比較AI和雲計算，大數據的技術門檻更低一些，而且跟業務的相關性更大。我個人感覺再過幾年，大數據技術將會像當前的分布式技術一樣，變成一項基本的技能要求。

前幾天，我在團隊內進行了一次大數據的技術分享，重點是對大數據知識做一次掃盲，同時提供一份學習指南。這篇文章，我基於分享的內容再做一次系統性整理，希望對大數據方向感興趣的同學有所幫助，內容分成以下5個部分：

1、大數據的發展歷史 

2、大數據的核心概念 

3、大數據平台的通用架構和技術體系

4、大數據的通用處理流程 

5、大數據下的數倉體系架構

01 大數據的發展歷史

在解釋「大數據」這個概念之前，先帶大家了解下大數據將近30年的發展歷史，共經歷了5個階段。那在每個階段中，大數據的歷史定位是怎樣的？又遇到了哪些痛點呢？

  

1.1 啟蒙階段：數據倉庫的出現

20世紀90年代，商業智能（也就是我們熟悉的BI系統）誕生，它將企業已有的業務數據轉化成為知識，幫助老板們進行經營決策。比如零售場景中：需要分析商品的銷售數據和庫存信息，以便制定合理的采購計划。

顯然，商業智能離不開數據分析，它需要聚合多個業務系統的數據（比如交易系統、倉儲系統），再進行大數據量的范圍查詢。而傳統數據庫都是面向單一業務的增刪改查，無法滿足此需求，這樣就促使了數據倉庫概念的出現。

傳統的數據倉庫，第一次明確了數據分析的應用場景，並采用單獨的解決方案去實現，不依賴業務數據庫。

1.2 技術變革：Hadoop誕生

2000年左右，PC互聯網時代來臨，同時帶來了海量信息，很典型的兩個特征：

• 數據規模變大：Google、雅虎等互聯網巨頭一天可以產生上億條行為數據。

• 數據類型多樣化：除了結構化的業務數據，還有海量的用戶行為數據，以圖像、視頻為代表的多媒體數據。

很顯然，傳統數據倉庫無法支撐起互聯網時代的商業智能。2003年，Google公布了3篇鼻祖型論文（俗稱「谷歌3駕馬車」），包括：分布式處理技術MapReduce，列式存儲BigTable，分布式文件系統GFS。這3篇論文奠定了現代大數據技術的理論基礎。

苦於Google並沒有開源這3個產品的源代碼，而只是發布了詳細設計論文。2005年，Yahoo資助Hadoop按照這3篇論文進行了開源實現，這一技術變革正式拉開了大數據時代的序幕。

Hadoop相對於傳統數據倉庫，有以下優勢：

• 完全分布式，可以采用廉價機器搭建集群，完全可以滿足海量數據的存儲需求。

• 弱化數據格式，數據模型和數據存儲分離，可以滿足對異構數據的分析需求。

隨着Hadoop技術的成熟，2010年的Hadoop世界大會上，提出了「數據湖」的概念。

數據湖是一個以原始格式存儲數據的系統。

企業可以基於Hadoop構建數據湖，將數據作為企業的核心資產。由此，數據湖拉開了Hadoop商業化的大幕。

1.3 數據工廠時代：大數據平台興起

商用Hadoop包含上十種技術，整個數據研發流程非常復雜。為了完成一個數據需求開發，涉及到數據抽取、數據存儲、數據處理、構建數據倉庫、多維分析、數據可視化等一整套流程。這種高技術門檻顯然會制約大數據技術的普及。

此時，大數據平台（平台即服務的思想，PaaS）應運而生，它是面向研發場景的全鏈路解決方案，能夠大大提高數據的研發效率，讓數據像在流水線上一樣快速完成加工，原始數據變成指標，出現在各個報表或者數據產品中。

1.4 數據價值時代：阿里提出數據中台

2016年左右，已經屬於移動互聯網時代了，隨着大數據平台的普及，也催生了很多大數據的應用場景。

此時開始暴露出一些新問題：為了快速實現業務需求，煙囪式開發模式導致了不同業務線的數據是完全割裂的，這樣造成了大量數據指標的重復開發，不僅研發效率低、同時還浪費了存儲和計算資源，使得大數據的應用成本越來越高。

極富遠見的馬雲爸爸此時喊出了「數據中台」的概念，「One Data，One Service」的口號開始響徹大數據界。數據中台的核心思想是：避免數據的重復計算，通過數據服務化，提高數據的共享能力，賦能業務。

02 大數據的核心概念

了解了大數據的發展歷史后，再解釋下大數據的幾個核心概念。

2.1 究竟什么是大數據？

大數據是一種海量的、高增長率的、多樣化的信息資產，它需要新的存儲和計算模式才能具有更強的決策力、流程優化能力。

 

下面是大數據的4個典型特征：

• Volume：海量的數據規模，數據體量達到PB甚至EB級別。

• Variety：異構的數據類型，不僅僅包含結構化的數據、還包括半結構化和非結構化數據，比如日志文件、圖像、音視頻等。
• Velocity：快速的數據流轉，數據的產生和處理速度非常快。

• Value：價值密度低，有價值的數據占比很小，需要用到人工智能等方法去挖掘新知識。

2.2 什么又是數據倉庫？

數據倉庫是面向主題的、集成的、隨着時間變化的、相對穩定的數據集合。

 

簡單理解，數據倉庫是大數據的一種組織形式，有利於對海量數據的維護和進一步分析。

• 面向主題的：表示按照主題或者業務場景組織數據。

• 集成的：從多個異構數據源采集數據，進行抽取、加工、集成。
• 隨時間變化的：關鍵數據需要標記時間屬性。

• 相對穩定的：極少進行數據刪除和修改，而只是進行數據新增。

2.3 傳統數據倉庫 vs 新一代數據倉庫隨着大數據時代的到來，傳統數據倉庫和新一代數據倉庫必然有很多不同，下面從多維度對比下兩代數據倉庫的異同。

 

03 大數據平台的通用架構

前面談到大數據相關的技術有幾十種，下面通過大數據平台的通用架構來了解下整個技術體系。

 

 

3.1 數據傳輸層

• Sqoop：支持RDBMS和HDFS之間的雙向數據遷移，通常用於抽取業務數據庫（比如MySQL、SQLServer、Oracle）的數據到HDFS.

• Cannal：阿里開源的數據同步工具，通過監聽MySQL binlog，實現增量數據訂閱和近實時同步。
• Flume：用於海量日志采集、聚合和傳輸，將產生的數據保存到HDFS或者HBase中。
• Flume + Kafka：滿足實時流式日志的處理，后面再通過Spark Streaming等流式處理技術，可完成日志的實時解析和應用。

3.2 數據存儲層

• HDFS：分布式文件系統，它是分布式計算中數據存儲管理的基礎，是Google GFS的開源實現，可部署在廉價商用機器上，具備高容錯、高吞吐和高擴展性。

• HBase：分布式的、面向列的NoSQL KV數據庫， 它是Google BigTable的開源實現，利用HDFS作為其文件存儲系統，適合大數據的實時查詢（比如：IM場景）。
• Kudu：折中了HDFS和HBase的分布式數據庫，既支持隨機讀寫、又支持OLAP分析的大數據存儲引擎（解決HBase不適合批量分析的痛點）。

3.3 資源管理層

• Yarn：Hadoop的資源管理器，負責Hadoop集群資源的統一管理和調度，為運算程序（MR任務）提供服務器運算資源（CPU、內存），能支持MR、Spark、Flink等多種框架。

• Kubernates：由Google開源，一種雲平台的容器化編排引擎，提供應用的容器化管理，可在不同雲、不同版本操作系統之間進行遷移。目前，Spark、Storm已經支持K8S。

3.4 數據計算層大數據計算引擎決定了計算效率，是大數據平台最核心的部分，它大致了經歷以下4代的發展，又可以分成離線計算框架和實時計算框架。

 

 

3.4.1 離線計算框架

• MapReduce：面向大數據並行處理的計算模型、框架和平台（將計算向數據靠攏、減少數據傳輸，這個設計思路非常巧妙）。
• Hive：一個數據倉庫工具，能管理HDFS存儲的數據，可以將結構化的數據文件映射為一張數據庫表，並提供完整的SQL查詢功能（實際運行時，是將Hive SQL翻譯成了MapReduce任務），適用離線非實時數據分析。
• Spark sql：引入RDD（彈性分布式數據集）這一特殊的數據結構，將SQL轉換成RDD的計算，並將計算的中間結果放在內存中，因此相對於Hive性能更高，適用實時性要求較高的數據分析場景。

3.4.2 實時計算框架

• Spark Streaming：實時流數據處理框架（按時間片分成小批次，s級延遲），可以接收Kafka、Flume、HDFS等數據源的實時輸入數據，經過處理后，將結果保存在HDFS、RDBMS、HBase、Redis、Dashboard等地方。
• Storm：實時流數據處理框架，真正的流式處理，每條數據都會觸發計算，低延遲（ms級延遲）。
• Flink：更高級的實時流數據處理框架，相比Storm，延遲比storm低，而且吞吐量更高，另外支持亂序和調整延遲時間。

3.5 多維分析層

• Kylin：分布式分析引擎，能在亞秒內查詢巨大的Hive表，通過預計算（用空間換時間）將多維組合計算好的結果保存成Cube存儲在HBase中，用戶執行SQL查詢時，將SQL轉換成對Cube查詢，具有快速查詢和高並發能力。
• Druid：適用於實時數據分析的高容錯、高性能開源分布式系統，可實現在秒級以內對十億行級別的表進行任意的聚合分析。 

04 大數據的通用處理流程

了解了大數據平台的通用架構和技術體系后，下面再看下針對離線數據和實時數據，是如何運用大數據技術進行處理的？

 

 

上圖是一個通用的大數據處理流程，主要包括以下幾個步驟：

• 數據采集：這是大數據處理的第一步，數據來源主要是兩類，第一類是各個業務系統的關系數據庫，通過Sqoop或者Cannal等工具進行定時抽取或者實時同步；第二類是各種埋點日志，通過Flume進行實時收集。
• 數據存儲：收集到數據后，下一步便是將這些數據存儲在HDFS中，實時日志流情況下則通過Kafka輸出給后面的流式計算引擎。
• 數據分析：這一步是數據處理最核心的環節，包括離線處理和流處理兩種方式，對應的計算引擎包括MapReduce、Spark、Flink等，處理完的結果會保存到已經提前設計好的數據倉庫中，或者HBase、Redis、RDBMS等各種存儲系統上。
• 數據應用：包括數據的可視化展現、業務決策、或者AI等各種數據應用場景。

05 大數據下的數倉體系架構

數據倉庫是從業務角度出發的一種數據組織形式，它是大數據應用和數據中台的基礎。數倉系統一般采用下圖所示的分層結構。

可以看到，數倉系統分成了4層：源數據層、數據倉庫層、數據集市層、數據應用層。采用這樣的分層結構，和軟件設計的分層思想類似，都是為了將復雜問題簡單化，每一層職責單一，提高了維護性和復用性。每一層的具體作用如下：

• ODS：源數據層，源表。
• DW：數據倉庫層，包含維度表和事實表，通過對源表進行清洗后形成的數據寬表，比如：城市表、商品類目表、后端埋點明細表、前端埋點明細表、用戶寬表、商品寬表。
• DM：數據集市層，對數據進行了輕粒度的匯總，由各業務方共建，比如：用戶群分析表、交易全鏈路表。
• ADS：數據應用層，根據實際應用需求生成的各種數據表。

另外，各層的數據表都會采用統一的命名規則進行規范化管理，表名中會攜帶分層、主題域、業務過程以及分區信息。比如，對於交易域下的一張曝光表，命名可以是這樣：

 

總結

上文對大數據的歷史、核心概念、通用架構、以及技術體系進行了系統性總結。如果大家想深入學習大數據技術，建議參考這篇文章，同時結合下面的學習指南展開。