概念與容器

為什么先說這個，其實很簡單：因為絕大多數人都把這兩個概念混為一談。然后就會出現各種各樣的問題：oracle不是數據庫么，怎么又是數據倉庫？Hive不是數據倉庫么？怎么又是數據庫？

數據倉庫、數據庫是一個概念，是一些技術的集合。類同于切菜刀法和雕刻刀法；

Oracel、DB2、MySQL、Hive是一個容器，是一種工具。類同于一把刀。

當我們在說數據倉庫的時候，我們在說什么？說的是你用的mysql還是oracle？用的是Hive還是Kylin？用的是druid還是doris？都不是！因為這些是實現數據倉庫的工具！

我們在說數據倉庫的時候，我們實際上說的是一種面向主題，沉淀歷史不可變信息，對明細數據進行匯總的，為決策提供在線分析服務的數據技術的集合。

我們在實現數據倉庫的時候，需要用到數據倉庫設計（數據庫設計工具）、數據存儲技術（數據庫工具）、數據處理技術（ETL工具、監控報警）、數據管理技術（元數據、數據地圖、血緣關系）等等技術。

而oracle、mysql、hadoop等都只是數據存儲技術中的一種而已。

數據倉庫發展歷史

1、數據倉庫概念誕生

數據倉庫概念公認最早的定義者，是數據倉庫之父比爾·恩門（Bill Inmon）在1991提出的。在此之前，所有的業務操作數據和分析數據都是存在一個數據庫中的，并沒有分開。

這個inmon就是inmon、kimball建倉方法論的inmon，是不是很熟悉？

如同絕大多數新概念一樣，剛誕生的數據倉庫同樣遭受到了巨大的失敗。inmon的建設理念是自上而下，這個上指的是數據的上游，不是數據分層的上層。

大家都是做數倉的，你肯定理解為什么一開始數據倉庫概念會慘敗。因為自上而下太難見效，得把所有的業務理清楚，把所有系統的數據理清楚，然后分主題分層一點點的設計，然后按照這個設計一層層的建。而且一旦其中有任何變動，整個設計全廢。所以第一批吃螃蟹的那些公司基本上都是小白鼠。

2、數據集市概念誕生

這個時候，有個英雄站出來了，這就是Kimball，他寫了一本書《The?DataWarehouse?Toolkit》，開啟了數據集市的狂潮，也開創了另一種數據倉庫建設的流派-Kimball的自下而上流派。這個上、下也是上下游的意思。Kimball建議，百鳥在林，不如一鳥在手。先搞一個銷售部門，摸清銷售部門的需求，等于把下游的需求先鎖死。然后再順藤摸瓜，把數倉的每一層設計好，最后再摸到業務系統（CRM+ERP+人力系統），找業務系統的數據，這樣就建立了一個銷售部門級的數據集市。

由于這種方法的需求少了，設計工作少，難度也就低了，對應的建設難度和工作量也少，建設速度就快，見效也就快啊，非常利于工作的開展。所以數據集市大行其道。

3、DWDM融合

兩派吵了很久很久，各自都有死忠，也都有對的理由，各自也都說服不了對方。雙方也明白了：“one size fits all”一碼通用是不可能的。終于在1998年， Inmon提出了新的BI架構CIF(CorporationInformation Factory,企業信息工廠)。

上面這張圖就是inmon老爺子畫的，看上去很亂對吧？其實按照咱現在的視角看就很清晰了：

這個架構是不是很熟悉？對！這個架構從1998年到現在，就沒變過！而且也是所有數據倉庫建設的框架性指南。

4、實時數倉

一直到最近兩年，實時處理技術的飛速發展，才將數據倉庫的架構往前又推了一步，出現了實時數倉。實時數倉又分為批數據+流數據、批流一體兩種架構。從這里開始，也就正式進入了大數據環境下的數據倉庫范疇。

大數據環境下的數據倉庫

1、離線數倉

剛轉到大數據環境中的哥們會很奇怪，為啥有一個數倉叫離線數倉？從來沒聽過啊！

其實離線數倉就是咱以前做的傳統數倉，數據以T+1的形式計算好放在那里，給前臺的各種分析應用提供算好的數據。這也被稱為“大數據的批處理”。只不過原本的單體環境工具（oracle、informatica等）基本都被替換成了大數據體系內（Hadoop、Hive、Sqoop、oozie等）的工具而已。

大數據環境中工具清單：

• 數據采集：flume/logstash+kafka，替代傳統數倉的FTP；
• 批量數據同步：Sqoop、Kettle，跟傳統數倉一樣用Kettle，部分商用ETL工具也開始支持大數據集群;
• 大數據存儲：Hadoop HDFS/Hive、TiDB、GP等MPP，替代傳統數倉的Oracle、MySQL、MS SQL、DB2等；
• 大數據計算引擎：MapReduce、Spark、Tez，替代傳統數倉的數據庫執行引擎；
• OLAP引擎：Kylin/druid，（Molap，需預計算）、Presto/Impala，（Rolap，無需預計算），替代BO、Brio、MSTR等各種BI工具。

2、實時計算

就是因為有實時數據處理，所以才會有離線數據處理。相對應的也就有實時數倉和離線數倉。實時數倉最開始是在日志數據分析業務中被廣泛使用，后來在各種實時戰報大屏的推動，實時數倉開始應用。

與離線計算相比，實時計算這邊減少了數據落地，替換了數據計算引擎，目前純流式數據處理基本上就只有Spark Streaming了。Storm會丟數據，Flink是批流一體的。實時數據計算好結果后，可以落地到各種數據庫中，也可以直接對接到大屏進行展示。

大數據環境下的數據倉庫架構

1、Lambda 架構

Lambda架構核心就三個：批數據處理層、流數據處理層和服務層。批數據處理層應對歷史長時間數據計算，流數據處理層應對短時間實時數據計算。如果一個需求要歷史到當前所有數據的累加結果，那就在服務層將兩部分數據進行累加就好了。

Lambda架構需要維護兩套計算引擎，如果需要歷史到現在實時數據的累加，則需要在兩邊同時做相同的計算，然后還得加總一下，非常麻煩。因此就有了最近非常火熱的Kappa架構。

2、Kappa 架構

Kappa架構的設計很有意思。Lambda架構反正還是分離線和實時兩部分的，所以可以從離線庫和實時消息隊列取數，分別計算后，在服務層加總就可以了。

Kappa的設計理念是：干脆不要離線了，全部都進行流式計算。流式計算的數據來源是消息隊列，那我把所有需要計算的數據放在消息隊列里就好了，然后讓流計算引擎計算所有數據不就好了？

因為所有數據都存在Kafka，上面接Flink批流一體數據處理引擎將kafka的數據計算好存在服務層的table n中。如果需求有變化了，就講kafka的offset調整一下，Flink則重啟一個任務重新計算，存在table N+1中，當N+1的數據進度趕上table n了，就停掉table n的任務。

3、Kappa 架構+查詢+分析展示

Kappa架構只到數據服務層，Flink本身只是一個計算引擎，因此還需要一個提供快速查詢的工具和一個展示的工具。所以現在的架構就變成了這樣：

總結

綜上所述，傳統數倉和大數據環境下的數倉還是有很多區別的：

• 數倉設計的工具都是一樣的，這個不會變；
• 由于大數據集群中，表關聯的代價比較大，因此數倉建模會更多的使用寬表，所以這里會有一些變化；
• 數據處理和調度工具用kettle基本都OK，沒啥太大變化，但是需要了解一下Flume、Kafka等工具；
• 數據存儲這邊需要深入了解一下，這是單體數據庫和集群數據庫的差別，會有分布式一致性的各種亂七八糟的問題；
• 數據計算引擎也有變化，也是單體數據庫和集群數據庫的差別。分布式計算會有數據傾斜、join代價高等問題，所以優化的方法和方向也不一樣；
• 數據總體架構設計的時候也會有所變化，傳統數倉整個BI套件就ok了，大數據環境下可能要面對更多的各種復雜需求，所需的大數據組件就變多了，需要系統學習。

建議傳統數據倉庫工程師的轉型路線：

傳統數倉-離線數倉（批數據處理）-實時數據處理（流數據處理）-lambda架構-kappa架構（批流一體）。

來源網絡侵刪

總結

以上是生活随笔為你收集整理的数据查询和业务流分开_传统数仓和大数据数仓的区别是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。