雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
如果要問最近幾年，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：資料應用層，根據實際應用需求生成的各種資料表。
另外，各層的資料表都會采用統一的命名規則進行規範化管理，表名中會攜帶分層、主題域、業務過程以及分區資訊。比如，對于交易域下的一張曝光表，命名可以是這樣：
總結
上文對大資料的曆史、核心概念、通用架構、以及技術體系進行了系統性總結。如果大家想深入學習大資料技術，建議參考這篇文章，同時結合下面的學習指南展開。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-04-20
本文作者：駱俊武
本文來自：“
51CTO”，了解相關資訊可以關注“
”