我有自己的博客啦，歡迎各位客官前來哦！戳我進入！
什么是數倉
一、數倉是什么
數倉，全稱就是數據倉庫，是一個面向主題，集成的，相對穩定的，反映歷史變化的數據集合，通常用於支持管理決策。這里的主題指的是為了分析數據而創造產生的各種有助於決策的數據模型。
隨着互聯網的發展，數據源頭越來越豐富且分散的特點。除了企業中的業務庫之外，針對APP的埋點、Web的日志，IOT設備等非結構化的數據都在近幾年呈指數上升。因此，針對此類有着挖掘價值的數據進行分析是目前企業必須去做的事情，同樣也是數據倉庫越來越重要，越來越得到發展的原因。
不過需要注意的是，數據倉庫和實時數據庫在如今是兩個不一樣的概念，實時數據庫比如MySQL、Oracle、SQLite等，這些數據庫的存在是為了滿足低延時的業務需求，通常速度快，但能夠承載的數據量有限。而數據倉庫不需要滿足業務上的低延時，反而更加注重對數據的分析和挖掘 ，因此數據倉庫要求其數據量要大，數據維度要多。
數據倉庫，它不是數據的最終目的地，而是為數據最終的目的地做好准備，這些准備包括對數據的：清洗、轉義、分類、重組、合並、拆分、統計等工作。
二、數據倉庫的發展
從1990年 Inmon 提出數據倉庫概念到今天，數據架構經歷了最初的傳統數倉架構——離線數倉架構、Lambda 架構、Kappa 架構以及 Flink 的火熱帶出的流批一體架構，數據架構技術不斷演進，本質都是在往流批一體的方向發展，讓用戶能以最自然、最小的成本完成實時計算。
2.1 傳統數倉架構
早期，傳統的數據庫充當數據倉庫的角色，通過離線ETL定期加載離線數據，然后通過一定的分析模型對數據進行計算並產生結果的模式，大致的數倉架構如下：
2.2 離線數倉架構
隨着大數據技術的發展，傳統的數倉難以承受海量數據，因此業界開始采用大數據技術來承載存儲和計算任務，計算以及存儲都采用了基於大數據的框架。
從圖中，我們可以看到，離線的數倉的架構使用了集合采集、同步、消息隊列等技術，采用Flume監控日志文件的更新，采用Kafka對消息進行緩沖，使得后續框架能夠慢慢消費數據，采用Sqoop對保存在諸如MySQL等數據庫中的數據進行同步，使其存儲至HDFS中。之后，采用Hive對數據進行處理。
這里，將數據處理分成了五層，每層的處理分別如下：
| 層級名稱 | 解釋 | 要求 |
|---|---|---|
| ODS（Operation Data Store） | 原始數據層 | 存放原始數據，要求對數據不做任何處理，保持數據原貌。 |
| DWD（Data Warehouse Detail） | 明細數據層 | 對ODS層做數據清洗（去除空值、臟數據等），維度退化、脫敏等。粒度是一行信息代表一次行為，例如一次下單。 |
| DWS（Data Warehouse Service） | 服務數據層 | 以DWD為基礎，按天進行輕度匯總。粒度是一行信息代表一天的行為，比如一天內下單的次數。 |
| DWT（Data Warehouse Topic） | 數據主題層 | 以DWS為基礎，按主題進行匯總。粒度是一行信息代表累積的行為，例如用戶層注冊那天開始至今一共下了多少單。 |
| ADS（Application Data Store） | 數據應用層 | 為各種統計報表提供數據。 |
最后將處理好的分析數據同步至MySQL用於BI報表的展示。
2.3 Lambda架構
Lambda架構是由Storm的作者Nathan Marz提出的一個實時大數據處理框架。Marz在Twitter工作期間開發了著名的實時大數據處理框架Storm，Lambda架構是其根據多年進行分布式大數據系統的經驗總結提煉而成。
Lambda架構的目標是設計出一個能滿足實時大數據系統關鍵特性的架構，包括有：高容錯、低延時和可擴展等。Lambda架構整合離線計算和實時計算，融合不可變性（Immunability），讀寫分離和復雜性隔離等一系列架構原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各類大數據組件。
誠然，這個架構在一定程度上滿足了當下業界對實時性的部分要求，且Lambda架構經歷多年的發展，其優點是穩定，對於實時計算部分的計算成本可控，批量處理可以用晚上的時間來整體批量計算，這樣把實時計算和離線計算高峰分開，這種架構支撐了數據行業的早期發展，但是它也有一些致命缺點，並在大數據3.0時代越來越不適應數據分析業務的需求，原因有幾個，第一是實時和批量計算結果不一致會引起數據口徑的問題，第二是批量計算在一個單位的計算窗口時間內無法完成，第三是開發和維護兩個計算隊列成本過高，且邏輯復雜，第四是由於計算會產生大量中間結果表，對服務器的存儲壓力構成一定的威脅。
2.4 Kappa架構
2014 年 Jay Kreps 在一次研討會上指出了一些 Lambda 架構間的差異，大數據世界自此迎來了另一個備選架構，它的代碼量更少，特別適用於那些使用多層 Lambda 架構顯得有些奢侈的企業場景。Kappa 架構不能被簡單視作 Lambda 架構的替代品，相反，它是在離線層對滿足業務需求不是必須項時的一個備選項,該架構適合實時處理不同事件。
此架構解決了Lambda架構中的弊病，其在數據需要重新處理或數據變更時，通過Kafka框架保留歷史數據的機制，將歷史是數據重新處理來完成有關操作。這種方式有點在於將離線批處理層從架構中去除，能夠更加高效地進行計算。缺點在於缺少了離線層，可能導致數據處理或數據庫更新時發生錯誤，因此需要添加異常管理來調節矛盾，恢復數據，另外，流式重新處理歷史數據的吞吐能力低於離線批處理，這也是這個架構的缺點之一。
