一、 ?前言

我們都知道，采集數據之后，得到數據是原始的和雜亂的，必須經過專門的清洗、 關聯、規范化和精心的組織建模，而且要通過數據質量檢測后才能進行后續的數據分析或用于提供數據服務，而這就是數據平臺構建的關鍵環節-->數據存儲處理

我們今天要聊的是大數據平臺是如何去存儲海量數據呢 ？

大數據的數據采集并存儲的數據流程，如下圖所示：

在整個大數據生態圈里，數據存儲可以分為兩大類：

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

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

二、數據存儲的發展?

2.1 傳統數據存儲

互聯網時代各種存儲框架層出不窮，眼花繚亂，比如傳統的OLTP關系型數據庫Oracle、MySQL。

之前進行業務指標的統計分析都是基于傳統的事務型數據庫，傳統的事務型數據庫主要面對單一的業務系統，實現的是面向事務的增刪改查。

隨著業務的不斷發展，產生的海量數據，面對復雜的數據分析指標，單一的事務性數據庫已經不能滿足數據分析的場景。

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

1、大量訪問數據，這些請求占用了大量數據庫的資源，嚴重到影 響生產系統的性能。

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

這促使數據倉庫概念的出現。

2.2 數據倉庫

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

數據倉庫是在企業管理和決策中面向主題的、集成的、與時間相關的，不可修改的數據集合。

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

2、所謂集成：是指數據倉庫中的信息不是從各個業務系統中簡單抽取出來的，而是經過一系列加工、整理和匯總的過程，因此數據倉庫中的信息是關于整個企業的一致的全局信息。

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

簡而言之，它綜合多個業務系統數據，主要用于歷史性、綜合性和深層次數據分析。

在了解數據倉庫之后，不得不提下經典的兩個數倉建模技術。

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

恩門提出的建模方法自頂向下（這里的頂是指數據的來源，在傳統數據倉庫中，就是各個業務數據庫），基于業務中各個實體以及實體之間的關系，構建數據倉庫。

舉個例子：

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

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

總結這兩種數倉建模技術：

這兩種方法各有優劣，恩門建模因為是從數據源開始構建，構建成本比較高，適用于應用場景比較固定的業務，比如金融領域，冗余數據少是它的優勢。金博爾建模由于是從分析場景出發，適用于變化速度比較快的業務，比如互聯網業務。由于現在的業務變化都比較快，所以我更推薦金博爾的建模設計方法。

2.3 數據湖

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

在模型設計上，提出了數據倉庫模型設計的方法論，為后來數據分析的大規模應用奠定了基礎。

但是進入互聯網時代后，最為重要的兩個變化：

1、數據規模前所未有，傳統的數據倉庫難于擴展，根本無法承擔如此規模的海量數據。

2、數據類型變得異構化，不僅有結構化數據，還有半結構化，非結構數據。而傳統的數據倉庫對數據模型有嚴格的要求，在數據導入到數據倉庫前，數據模型就必須事先定義好，數據必須按照模型設計存儲。

因總總的限制，導致傳統數據倉庫無法支撐互聯網時代的數據挖掘。

隨著大數據技術普及，數據湖概念被提出。

數據湖（Data Lake）是一個以原始格式存儲數據的存儲庫或系統。

其構建組件基于Hadoop進行存儲。

簡而言之，數據湖原始數據統一存放在HDFS系統上，引擎以Hadoop和Spark,Flink開源生態為主，存儲和計算一體。

通俗總結：數據倉庫和數據湖

數據倉庫存儲結構化數據(先處理后存儲)。

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

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

三、 批處理的數據存儲?

3.1 HDFS分布式文件系統

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

它有一定高度的容錯性，而且提供了高吞吐量的數據訪問，非常適合大規模數據 集上的應用。

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

在Hadoop 的整個架構中， HDFS在MapReduce 任務處理過程中提供了對文件操作和存儲等的支持， MapReduce 在HDFS基礎上實現了任務的分發、跟蹤和執行等工作，并收集結果，兩者相互作用，共同完成了Hadoop 分布式集群的主要任務。

HDFS分布式文件架構如下所示：

離線數據一般基于HDFS分布式文件系統作為數據倉庫。

四、實時處理的數據存儲

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

4.1 原數據存儲

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

Kafka是最初由Linkedin公司開發，是一個分布式、可分區、多副本，基于zookeeper協調的分布式消息系統。

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

4.2 ?實時處理之后的數據存儲

1、HBase的NOSQL數據庫

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

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

HBase解決了傳統數據庫的單點性能極限。

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

場景： 對于數據在線服務（即數據使用方傳入某個業務ID，然后獲取到所有此ID 的相關字段），通常放在HBase內。

2、關系型數據庫

實時數據經過實時計算引擎Flink、Spark處理后，可以存儲于Mysql或者Oracle等關系型數據庫。

場景：對于實時數據大屏，通常放在某種關系數據庫（如MySQL）內。

3、 緩存數據庫

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

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