AI時代，還不瞭解大資料？
阿新 • • 發佈：2020-11-17
如果要問最近幾年，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：資料應用層，根據實際應用需求生成的各種資料表。 另外，各層的資料表都會採用統一的命名規則進行規範化管理，表名中會攜帶分層、主題域、業務過程以及分割槽資訊。比如，對於交易域下的一張曝光表，命名可以是這樣： 
# 寫在最後 上文對大資料的歷史、核心概念、通用架構、以及技術體系進行了系統性總結。如果大家想深入學習大資料技術，建議參考這篇文章，同時結合下面的學習指南展開。  後續會持續帶來大資料方向更深度的分享，如果感興趣，歡迎關注我。
作者簡介：985碩士，前亞馬遜工程師，現58轉轉技術總監 **歡迎關注我的個人公眾號：IT人的職場進階** 
## 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：資料應用層，根據實際應用需求生成的各種資料表。 另外，各層的資料表都會採用統一的命名規則進行規範化管理，表名中會攜帶分層、主題域、業務過程以及分割槽資訊。比如，對於交易域下的一張曝光表，命名可以是這樣： 
# 寫在最後 上文對大資料的歷史、核心概念、通用架構、以及技術體系進行了系統性總結。如果大家想深入學習大資料技術，建議參考這篇文章，同時結合下面的學習指南展開。  後續會持續帶來大資料方向更深度的分享，如果感興趣，歡迎關注我。
作者簡介：985碩士，前亞馬遜工程師，現58轉轉技術總監 **歡迎關注我的個人公眾號：IT人的職場進階** ![](https://img-blog.csdnimg.cn/202011072154329