我們都知道，采集數(shù)據(jù)之后，得到數(shù)據(jù)是原始的和雜亂的，必須經(jīng)過專門的清洗、 關(guān)聯(lián)、規(guī)范化和精心的組織建模，而且要通過數(shù)據(jù)質(zhì)量檢測后才能進行后續(xù)的數(shù)據(jù)分析或用于提供數(shù)據(jù)服務(wù)，而這就是數(shù)據(jù)平臺構(gòu)建的關(guān)鍵環(huán)節(jié)-->數(shù)據(jù)存儲處理

而我們今天要聊的是大數(shù)據(jù)平臺是如何去存儲海量數(shù)據(jù)呢 ？

在之前，我們聊過，大數(shù)據(jù)的數(shù)據(jù)采集并存儲的數(shù)據(jù)流程，如下圖所示：

在整個大數(shù)據(jù)生態(tài)圈里，數(shù)據(jù)存儲可以分為兩大類：

1、是直接以文件形式存放在分布式文件系統(tǒng)上，處理工具可以直接讀寫 (Hive 和SparkSQL 都是這類)。

2、通過kafak存儲實時數(shù)據(jù)，經(jīng)過實時計算框架最后把指標數(shù)據(jù)利用NoSQL數(shù)據(jù)庫來存儲和管理數(shù)據(jù)(NOSQL數(shù)據(jù)庫Hbase之類)。

2.1 傳統(tǒng)數(shù)據(jù)存儲

互聯(lián)網(wǎng)時代各種存儲框架層出不窮，眼花繚亂，比如傳統(tǒng)的OLTP關(guān)系型數(shù)據(jù)庫Oracle、MySQL。

之前進行業(yè)務(wù)指標的統(tǒng)計分析都是基于傳統(tǒng)的事務(wù)型數(shù)據(jù)庫，傳統(tǒng)的事務(wù)型數(shù)據(jù)庫主要面對單一的業(yè)務(wù)系統(tǒng)，實現(xiàn)的是面向事務(wù)的增刪改查。

隨著業(yè)務(wù)的不斷發(fā)展，產(chǎn)生的海量數(shù)據(jù)，面對復雜的數(shù)據(jù)分析指標，單一的事務(wù)性數(shù)據(jù)庫已經(jīng)不能滿足數(shù)據(jù)分析的場景。

最根本的原因在于：數(shù)據(jù)分析通常需要訪問大量的數(shù)據(jù)，單條數(shù)據(jù)的分析沒有任何意義。它不僅需要訪問大量的數(shù)據(jù)，還要對其進行頻繁的統(tǒng)計和查詢。

1、大量訪問數(shù)據(jù)，這些請求占用了大量數(shù)據(jù)庫的資源，嚴重到影 響生產(chǎn)系統(tǒng)的性能。

2、大量的數(shù)據(jù)訪問通常需要全表掃描，頻繁而且通常又是并發(fā)地全表掃描會造成事務(wù)型數(shù)據(jù)庫響應(yīng)異常緩慢甚至宕機。

這促使數(shù)據(jù)倉庫概念的出現(xiàn)。

2.2 數(shù)據(jù)倉庫

在 1991 年出版的《Building the Data Warehouse》中，數(shù)據(jù)倉庫之父比爾·恩門（Bill Inmon）首次給出了數(shù)據(jù)倉庫的完整定義，他認為：

數(shù)據(jù)倉庫是在企業(yè)管理和決策中面向主題的、集成的、與時間相關(guān)的，不可修改的數(shù)據(jù)集合。

1、所謂主題：要把不同業(yè)務(wù)系統(tǒng)的數(shù)據(jù)同步到一個統(tǒng)一的數(shù)據(jù)倉庫中，然后按照主題域方式組織數(shù)據(jù)。主題可以把它理解為數(shù)據(jù)倉庫的一個目錄。

2、所謂集成：是指數(shù)據(jù)倉庫中的信息不是從各個業(yè)務(wù)系統(tǒng)中簡單抽取出來的，而是經(jīng)過一系列加工、整理和匯總的過程，因此數(shù)據(jù)倉庫中的信息是關(guān)于整個企業(yè)的一致的全局信息。

3、所謂隨時間變化：是指數(shù)據(jù)倉庫內(nèi)的信息并不只是反映企業(yè)當前的狀態(tài)，而是記錄了從過去某一時點到當前各個階段的信息。通過這些信息，可以對企業(yè)的發(fā)展歷程和未來趨勢做出定量分析和預測。

簡而言之，它綜合多個業(yè)務(wù)系統(tǒng)數(shù)據(jù)，主要用于歷史性、綜合性和深層次數(shù)據(jù)分析。

在了解數(shù)據(jù)倉庫之后，不得不提下經(jīng)典的兩個數(shù)倉建模技術(shù)。

比爾·恩門（Bill Inmon）和 金博爾（Kimball）

恩門提出的建模方法自頂向下（這里的頂是指數(shù)據(jù)的來源，在傳統(tǒng)數(shù)據(jù)倉庫中，就是各個業(yè)務(wù)數(shù)據(jù)庫），基于業(yè)務(wù)中各個實體以及實體之間的關(guān)系，構(gòu)建數(shù)據(jù)倉庫。

舉個例子：

在一個最簡單的買家購買商品的場景中，按照恩門建模的思維模式，首先你要理清這個業(yè)務(wù)過程中涉及哪些實體。買家、商品是一個實體，買家購買商品是一個關(guān)系。所以，模型設(shè)計應(yīng)該有買家表，商品表，和買家商品交易表三個模型。

金博爾建模與恩門正好相反，是一種自底向上的模型設(shè)計方法，從數(shù)據(jù)分析的需求出發(fā)，拆分維度和事實。那么用戶、商品就是維度，庫存、用戶賬戶余額是事實。

總結(jié)這兩種數(shù)倉建模技術(shù)：

這兩種方法各有優(yōu)劣，恩門建模因為是從數(shù)據(jù)源開始構(gòu)建，構(gòu)建成本比較高，適用于應(yīng)用場景比較固定的業(yè)務(wù)，比如金融領(lǐng)域，冗余數(shù)據(jù)少是它的優(yōu)勢。金博爾建模由于是從分析場景出發(fā)，適用于變化速度比較快的業(yè)務(wù)，比如互聯(lián)網(wǎng)業(yè)務(wù)。由于現(xiàn)在的業(yè)務(wù)變化都比較快，所以我更推薦金博爾的建模設(shè)計方法。

2.3 數(shù)據(jù)湖

傳統(tǒng)數(shù)據(jù)倉庫，第一次明確了數(shù)據(jù)分析的應(yīng)用場景應(yīng)該用單獨的解決方案去實現(xiàn)，不再依賴于業(yè)務(wù)的數(shù)據(jù)庫。

在模型設(shè)計上，提出了數(shù)據(jù)倉庫模型設(shè)計的方法論，為后來數(shù)據(jù)分析的大規(guī)模應(yīng)用奠定了基礎(chǔ)。

但是進入互聯(lián)網(wǎng)時代后，最為重要的兩個變化：

1、數(shù)據(jù)規(guī)模前所未有，傳統(tǒng)的數(shù)據(jù)倉庫難于擴展，根本無法承擔如此規(guī)模的海量數(shù)據(jù)。2、數(shù)據(jù)類型變得異構(gòu)化，不僅有結(jié)構(gòu)化數(shù)據(jù)，還有半結(jié)構(gòu)化，非結(jié)構(gòu)數(shù)據(jù)。而傳統(tǒng)的數(shù)據(jù)倉庫對數(shù)據(jù)模型有嚴格的要求，在數(shù)據(jù)導入到數(shù)據(jù)倉庫前，數(shù)據(jù)模型就必須事先定義好，數(shù)據(jù)必須按照模型設(shè)計存儲。

因總總的限制，導致傳統(tǒng)數(shù)據(jù)倉庫無法支撐互聯(lián)網(wǎng)時代的數(shù)據(jù)挖掘。

隨著大數(shù)據(jù)技術(shù)普及，數(shù)據(jù)湖概念被提出。

數(shù)據(jù)湖（Data Lake）是一個以原始格式存儲數(shù)據(jù)的存儲庫或系統(tǒng)。

其構(gòu)建組件基于Hadoop進行存儲。

簡而言之，數(shù)據(jù)湖原始數(shù)據(jù)統(tǒng)一存放在HDFS系統(tǒng)上，引擎以Hadoop和Spark,Flink開源生態(tài)為主，存儲和計算一體。

通俗總結(jié)：數(shù)據(jù)倉庫和數(shù)據(jù)湖

數(shù)據(jù)倉庫存儲結(jié)構(gòu)化數(shù)據(jù)(先處理后存儲)。

數(shù)據(jù)湖存儲原始數(shù)據(jù)(先存儲后處理)。

這里可以用一個做菜的場景做一個類比。以前數(shù)據(jù)倉庫的時候，好比把原材料都加工好了，比如土豆清洗，去皮，切片，這樣炒土豆片的時候直接炒就可以了。數(shù)據(jù)湖的時候呢，直接把土豆存儲進來，這樣以后想炒土豆片就切片，想炒土豆絲就切絲。增加了靈活性的同時，省去了前期頭都處理的費用。

3.1 HDFS分布式文件系統(tǒng)

Hadoop Distributed File System，簡稱HDFS，是一個分布式文件系統(tǒng)。它是谷歌的Google File System ( GFS）提出之后， Doug Cutting 受Google 啟發(fā)而開發(fā)的一種類GFS 文件系統(tǒng)。

它有一定高度的容錯性，而且提供了高吞吐量的數(shù)據(jù)訪問，非常適合大規(guī)模數(shù)據(jù) 集上的應(yīng)用。

HDFS提供了一個高容錯性和高吞吐量的海量數(shù)據(jù)存儲解決方案。

在Hadoop 的整個架構(gòu)中， HDFS在MapReduce 任務(wù)處理過程中提供了對文件操作和存儲等的支持， MapReduce 在HDFS基礎(chǔ)上實現(xiàn)了任務(wù)的分發(fā)、跟蹤和執(zhí)行等工作，并收集結(jié)果，兩者相互作用，共同完成了Hadoop 分布式集群的主要任務(wù)。

HDFS分布式文件架構(gòu)如下所示：

離線數(shù)據(jù)一般基于HDFS分布式文件系統(tǒng)作為數(shù)據(jù)倉庫。

實時處理的數(shù)據(jù)為無界流數(shù)據(jù)，因此分為原數(shù)據(jù)存儲和數(shù)據(jù)處理后的存儲。

4.1 原數(shù)據(jù)存儲

實時數(shù)據(jù)處理通常還會有從某歷史時間點重啟以及多個實時任務(wù)都要使用同一源頭數(shù)據(jù)的需求，因此通常還會引人消息中間件Kafka來作為緩沖，從而達到實時數(shù)據(jù)采集和處理的適配。

Kafka是最初由Linkedin公司開發(fā)，是一個分布式、可分區(qū)、多副本，基于zookeeper協(xié)調(diào)的分布式消息系統(tǒng)。

場景：在實時數(shù)倉中，以 Kafka 為支撐，將所有需要實時處理的相關(guān)數(shù)據(jù)放到 Kafka隊列中來實現(xiàn)貼源數(shù)據(jù)層(ODS)。

4.2 ?實時處理之后的數(shù)據(jù)存儲

1、HBase的NOSQL數(shù)據(jù)庫

HBase 是一種構(gòu)建在HDFS 之上的分布式、面向列族的存儲系統(tǒng)。在需要實時讀寫并隨機訪問超大規(guī)模數(shù)據(jù)集等場景下， HBase 目前是市場上主流的技術(shù)選擇。HBase 技術(shù)來源于Google 論文《Bigtable ：一個結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)》。

如同Bigtable 利用了Google File System 提供的分布式數(shù)據(jù)存儲方式一樣， HBase 在HDFS 之上提供了類似于Bigtable 的能力。

HBase解決了傳統(tǒng)數(shù)據(jù)庫的單點性能極限。

實際上，傳統(tǒng)的數(shù)據(jù)庫解決方案，尤其是關(guān)系型數(shù)據(jù)庫也可以通過復制和分區(qū)的方法來提高單點性能極限，但這些都是后知后覺的，安裝和維護都非常復雜。而HBase從另一個角度處理伸縮性問題， 即通過線性方式從下到上增加節(jié)點來進行擴展。

場景： 對于數(shù)據(jù)在線服務(wù)（即數(shù)據(jù)使用方傳入某個業(yè)務(wù)ID，然后獲取到所有此ID 的相關(guān)字段），通常放在HBase內(nèi)。

2、關(guān)系型數(shù)據(jù)庫

實時數(shù)據(jù)經(jīng)過實時計算引擎Flink、Spark處理后，可以存儲于Mysql或者Oracle等關(guān)系型數(shù)據(jù)庫。

場景：對于實時數(shù)據(jù)大屏，通常放在某種關(guān)系數(shù)據(jù)庫（如MySQL）內(nèi)。

3、 緩存數(shù)據(jù)庫

經(jīng)過實時計算引擎Flink、Spark處理后的數(shù)據(jù)，同時也可以存儲在Redis里，作為緩存數(shù)據(jù)。

場景：為了提高性能并減輕對底層數(shù)據(jù)庫的壓力，還會使用緩存數(shù)據(jù)庫（如Redis）等。