一、 前言
我們都知道，采集資料之後，得到資料是原始的和雜亂的，必須經過專門的清洗、 關聯、規範化和精心的組織模組化，而且要通過資料品質檢測後才能進行後續的資料分析或用于提供資料服務，而這就是資料平台建構的關鍵環節-->資料存儲處理
而我們今天要聊的是大資料平台是如何去存儲海量資料呢 ？
在之前，我們聊過，大資料的資料采集并存儲的資料流程，如下圖所示：
在整個大資料生态圈裡，資料存儲可以分為兩大類：
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）等。