資料倉庫Data Warehouse，簡稱DW。數倉是資料庫的一種概念上的升級，它可以容納更多的資料、更加龐大的資料集。為企業中高層級別的決策制定提供所有型別資料支撐的戰略集合，主要是用於資料探勘和資料分析，以消滅資訊孤島和支援決策為目的而建立的。

數倉特性

1.面向主題：數倉首先是面對主題的，而每個主題是跨業務系統的，是企業系統資訊中的資料綜合、歸類並進行分析的一個抽象，對應企業中某一個宏觀分析領域所涉及的分析物件。例如說地產行業銷售主題，那麼這裡麵包含客戶、簽約、合同等綜合資料，對這些資料要進行歸類並分析，分析這個物件資料的完整性、一致性以及統一性。

2.資料整合：數倉是具有很強的資料整合性的，因為數倉中的資料均是從各個業務系統（包含線下資料）中來的，數倉中的資料一般來說是從業務系統獲取，但是進入數倉時需要進行資料的加工，所以數倉是具有很強的資料整合的。

3.歷史資料不可更新：進入數倉的資料的歷史資料一般是允許更新的，如果有一塊進行修改影響的將是整個歷史資料。以下是數倉構建的過程：

在如今的大資料時代，企業應該如何構建數倉呢？

數倉的特性決定了數倉建設不能採用同開發傳統的OLTP資料庫一樣的設計方法。數倉建設應該從一下幾個層面出發：

1.業務模型（主題）梳理：從企業的主營業務、集團組成架構、業務系統進行調研，來確定模型。首先分析業務系統有什麼、如何組成的、如何分佈的，然後考慮主題模型的設計，確定模型邊界。

2.邏輯模型設計：邏輯模型設計的主要工作包含粒度劃分、資料分割策略、表劃分、定義資料來源、主題劃分。資料倉庫邏輯設計中要解決的一個重要問題是決定資料倉庫的粒度劃分層次，粒度層次劃分適當與否直接影響到資料倉庫中的資料量和所適合的查詢型別，確定是採用單一粒度還是多重粒度，以及粒度劃分的層次。資料量的大小是決定是否進行資料分割和如何分割的主要因素；資料分析處理的要求是選擇資料分割標準的一個主要依據，因為資料分割是跟資料分析處理的物件緊密聯絡的；我們還要考慮到所選擇的資料分割標準應是自然的、易於實施的，同時也要考慮資料分割的標準與粒度劃分層次是適應的。

3.儲存設計及最佳化：確定資料的儲存結構、索引策略、存放位置以及儲存分配。一個數據庫管理系統往往都提供多種儲存結構供設計人員選用，不同的儲存結構有不同的實現方式，各有各的適用範圍和優缺點，設計人員在選擇合適的儲存結構時應該權衡三個方面的主要因素：存取時間、儲存空間利用率和維護代價。資料倉庫的資料量很大，因而需要對資料的存取路徑進行仔細的設計和選擇。由於資料倉庫的資料都是不常更新的，因而可以設計多種多樣的索引結構來提高資料存取效率。最後根據資料量分配儲存空間及存放位置。

4.資料維護：資料的維護主要包含資料的更新策略、指標維護等。在資料更新時往往會根據時間粒度進行更新資料，在更新資料時需要特別注意更新的時間、ETL/ESB的更新順序，避免因為上述問題而導致UI資料展示錯誤，影響企業高層運營決策。

老規矩，先看是什麼，再說怎麼做。

其實很多企業做資料倉庫的時候，都忽略了數倉與BI、資料庫的差異，只去搞底層資料，不去做資料服務和應用，其實就是把資料倉庫給狹義化了。

其實資料倉庫可以看成是BI的基礎版本、資料庫的升級版本，我們可以把公司裡的資料都想象成一個個資料夾，資料庫就是這一個個檔案櫃，這個檔案櫃存放著非常多的資料，無論這個資料是什麼、或者是如何組織的。而當我們的檔案非常多、種類非常複雜的時候，我們的就想要尋找某個資料夾的時候，如果每個檔案櫃每個檔案櫃的去找，實際上是非常耗費成本的，因此我們不妨建立一個檔案室，對不同的檔案櫃進行編號、歸類、分組，方便我們快速定位資料來源，這個檔案室就是資料倉庫。

所以這時候我們需要更為龐大的資料倉庫，幫助我們去對多個數據源的資料庫資料進行抓取，而抓取資料來源的過程就可以理解為ETL的工作，這樣去理解一個企業的資料架構就會簡單很多。

因此資料倉庫的本質，其實就是整合多個數據源的歷史資料進行細粒度的、多維的分析，幫助高層管理者或者業務分析人員做出商業戰略決策或商業報表。

這裡面就涉及到了資料倉庫的架構，簡單來說資料倉庫分為四個層次，

ODS層：存放原始資料，直接載入原始日誌、資料，資料儲存原貌不做處理。DWD層：結構與粒度原始表保持一致，對ODS層資料進行清洗 DWS層：以DWD為基礎，進行輕度彙總ADS層：為各種統計報表提供資料

這裡要注意資料倉庫的架構當中，各個系統的元資料透過ETL同步到操作性資料倉庫ODS中，對ODS資料進行面向主題域建模形成DW（資料倉庫），DM是針對某一個業務領域建立模型，具體使用者（決策層）檢視DM生成的報表。也就是說，我們所看到的資料不是直接從資料底層抽取的，相當於我們訪問資料倉庫的時候，是讓圖書管理員幫你找一個檔案櫃，那麼怎麼更高效低去找，就是資料倉庫建設中很重要的一部分工作——資料建模，包括資料的儲存模型、邏輯模型、概念模型等等。

因此資料倉庫的建設流程大致上可以分為六個步驟：

一、模板調研：資訊調研是邏輯模型設計、物 理模型設計以及資料對映的基 礎，在模型設計階段貫穿始終決定了資料倉庫的質量。

這一步我們主要的工作是找出實際存在的業務問題，領導的KPI問題，現在沒有提出未來可能出現的問題，這是資料倉庫建立的核心所在。方法就是調研，包括業務人員、領導方不斷溝通，不斷調研，輸出問題清單。

二、主題域模型設計：主題域的界定、每個主題主實體的准入原 則、資料處理規範、核心的分類決定了數 據模型的主體框架，保持主體框架的穩定 性確保了倉庫的穩定性。

三、概念模型設計：詳細的實體屬性的設計，大量資料分析業務規則驗證的工作，模型設計的同時完成到邏輯 資料模型的簡要資料對映

四、邏輯模型資料設計：提供與生產一致版本的資料結構，準 確完善的資料字典，符合分析需求的 樣本資料；並能對樣本資料分析中的 問題進行及時準確的回覆跟蹤

五、物理儲存模型設計：協調倉庫資料的相關方達成共 識，既包容當前資料滿足現有 需求，又具備一定的前瞻性便 於擴充套件，還必須具備操作性

六、模型最佳化設計回顧：模型設計是多人協同的團隊工作，是一項持續不斷地擴充套件演化完善的 過程，遵循模型設計規範、沿用一致的模型客戶化方式是至關重要的。

我這文章不講如何構建企業的資料倉庫，因為我的文章裡面有，所以就沒有什麼說的必要，在這裡，我想講一個我個人的，有關資料倉庫的小故事。

2010年，我到上海的第一年。年底回老家的時候，在火車站碰到一位之前的老同事。閒聊之中，發現他在尋找新的機會，原單位是老企業，沒什麼活力，年輕人上升空間有限。他30+歲的年紀，上有老，下有小，也是逼急了沒辦法。要不，他的位置，是個輕鬆活兒。

我是當時唯一從無錫這家名企跳到上海外企的。在他眼裡，我比較另類，做了他不敢做的事情。相差5-6歲，卻拿著比他多3倍的工資，此時的他，眼裡充滿求知慾。請我喝了30多塊錢一杯的星巴克，在咖啡館談了1個都小時。我知道，其實他平常也就喝點超市裡賣的茶。

看在這麼有誠意的份兒上，我怎麼都要把自己知道的那些都傾囊相送，是不是！

事實上，事業單位裡的每個人，多多少少基本溝通之道是曉得的，只是不願意用。不像現在的小朋友，問我問題，麻煩我辦事，上來都是“我要怎麼怎麼樣”，好像我欠他的。對於這種沒禮貌的，我即使不拉黑，也選擇不予理會。

只有經歷過複雜需求，才能反覆錘鍊自己的技術。所以如果你要是愛好技術，千萬別讓自己閒下來，曲不離口，拳不離手，碼不離腦。多給自己提一些需求，利用不同手段去實現，你會發現自己技術前進飛快。

電子廠前道MES其實需求很複雜，基本2-3天就要改版一些功能。那個時候我也經常被壓得透不過氣來，2個禮拜寫套系統，是常有的事情。不過看到工廠上千人都在用自己寫的軟體，還是蠻有成就感的。直到有瓶頸突破不了。因為MIS軟體在不斷地增多，資料也不斷地湧進來，自然技術經理們對於報表的要求就提高。

於是，各類SQL效能問題也層出不窮。直到最後，一個黨支部書記要一份報表，憑我當時的SQL水平，報表每次都要跑個10來分鐘，才能搞定。他覺得這樣的系統體驗很不好，於是每次都給我壓力。逼得沒辦法了，我只有天天去逛論壇，看官方文件。

也不知道哪天運氣好，摸索到了微軟的BI官網，看懂了SQL SERVER 2000 DTS（2005 版本後稱為 SSAS） 服務。非常適合那位党支書的需求場景，利用空間換時間的策略，將查詢提高到了令人髮指的快速。不僅如此，配合 SSAS/SSRS 的設計，將各種柱狀圖整合到了MES的模組中。

一套組合打下來，這位党支書直接給我打了個當年優秀員工獎。我們IT部老大，也開始帶我一起出席各種技術研討會，嘗試把這些思想用在別的部門裡。這才認識了資訊中心這位老員工。

這位老員工，那時相當資深，在公司做了很多年，做到了經理級別，用粗話說，犯案無數。一代的MIS系統，他參加過不少，從 VB, VB.net 玩到 c#, 資料庫也是, SQL Server, Oracle 都玩過一遍了。但距我辭職以來1年都還不到，他的壓力就爆發了。

其實吧，我技術沒他厲害，我也知道。但我運氣好，比他先接觸到了資料倉庫這回事。當他仍舊在 OLTP 領域吃老本的時候，我已經著手玩 OLAP了。我深信，OLAP 會有一場轟轟烈烈的市場運動。當年 RDBMS 剛火的時候，市場反應也很強烈，甚至比其他行業有著10年從業經驗的老師傅的待遇都高。

但是行業火熱之後總會飽和的。丁磊一說養豬，大家都跑去養豬了；喬布斯打出觸控式螢幕，一幫人要出來做手機。市場就那麼大，技術密碼又那麼透明，老人被年輕人追上，只是遲早的事，除非你能夠快速切換賽道。

在我看來，資料倉庫在當時就是風口，做資料庫的人轉過來，易如反掌。錦上添花的事情，為什麼不去做呢？我把經典的三維模型，畫給這位老同事看，他一下子就明白了。

在這張巨寬的表上，整合所有的維度和度量，透過線性壓縮儲存，將快速提高聯機分析的速度。每種業務，都基於這個模型做抽象與變型。

如果讀者朋友們，如果你做了3-4年專案，還是在處理 OLTP 的系統，有時間可以做做 OLAP 的專案。真能學到不少。

一、什麼是資料庫？

1.資料庫(Database)是按照資料結構來組織、儲存和管理資料的建立在計算機儲存裝置上的倉庫

2.資料庫是長期儲存在計算機內、有組織的、可共享的資料集合。資料庫中的資料指的是以一定

   的資料模型組織、描述和儲存在一起、具有儘可能小的冗餘度、較高的資料獨立性和易擴充套件性

   的特點並可在一定範圍內為多個使用者共享

資料倉庫定義：

面向主題的，整合的，相對穩定的，反映歷史變化的資料集合，用於支援管理決策。二、資料倉庫的發展歷程

資料倉庫概念最早可追溯到20世紀70年代，希望提供一種架構將業務處理系統和分析處理分為不同

的層次

20世紀80年代，建立TA2(Technical Architecture2)規範，該明確定義了分析系統的四個組成部分：數

據獲取、資料訪問、目錄、使用者服務

1988年，IBM第一次提出資訊倉庫的概念：一個結構化的環境，能支援終端使用者管理其全部的業務，

並支援資訊科技部門保證資料質量；抽象出基本元件：資料抽取、轉換、有效性驗證、載入、cube

開發等，基本明確了資料倉庫的基本原理、框架結構，以及分析系統的主要原則

1991年，Bill Inmon出版《 Building the Data Warehouse 》提出了更具體的資料倉庫原則：

1.資料倉庫是面向主題的

2.整合的

3.包含歷史的

4.不可更新的

5.面向決策支援的

6.面向全企業的

7.最明細的資料儲存

8.資料快照式的資料獲取

儘管有些理論目前仍有爭議，但憑藉此書獲得“資料倉庫之父”的殊榮

Bill Inmon主張自上而下的建設企業資料倉庫，認為資料倉庫是一個整體的商業智慧系統的一部分。兩種思路和觀點在實際的操作中都很難成功的完成專案交付，直至最終Bill Inmon提出了新的BI架構CIF(Corporation information factory),把資料集市包含了進來。CIF的核心是將數倉架構劃分為不同的層次以滿足不同場景的需求，比如常見的ODS、DW、DM等，每層根據實際場景採用不同的建設方案，改思路也是目前資料倉庫建設的架構指南，但自上而下還是自下而上的進行資料倉庫建設，並未統一。

基於大資料數倉構建特點

隨著我們從IT時代步入DT時代，資料從積累量也與日俱增，同時伴隨著網際網路的發展，越來越多的應用場景產生，傳統的資料處理、儲存方式已經不能滿足日益增長的需求。而網際網路行業相比傳統行業對新生事物的接受度更高、應用場景更復雜，因此基於大資料構建的資料倉庫最先在網際網路行業得到了嘗試。

大資料是我的主要研究方向之一，目前也在帶相關方向的研究生，所以我來回答一下這個問題。

首先，資料倉庫對於企業來說是比較傳統的資料管理方案，具有一定規模的企業透過建立資料倉庫能夠解決一定的“資料孤島”問題，從而能夠讓企業的資料有一個更加合理的利用，同時也能夠讓多個系統透過資料倉庫完成互聯互通。

但是在大資料時代，企業的資料倉庫無論從規模、資料型別、響應速度還是部署架構上來看，都將面臨較大的調整，這些調整主要體現在以下幾個方面：

第一：資料倉庫將以雲計算為基礎進行構建。雲計算的出現從某種程度上來說改變了整個IT行業對於技術資源和儲存資源使用的理解，雲計算彈性的服務模式和廉價的使用策略讓更多的企業願意採用雲計算服務，同時雲計算也能夠提供一站式解決方案，為企業進行資訊化升級降低了門檻。把資料倉庫搭建在雲計算平臺上，是目前雲計算能夠解決的一個重要問題之一。

第二：資料倉庫的儲存結構由Sql向NoSql轉換。雖然目前大量企業的資料倉庫依然以結構化資料為主，但是隨著物聯網的發展，未來資料倉庫中必然會出現大量的非結構化資料和半結構化資料，在這種情況下，資料倉庫必然要跟著進行調整，資料庫型別必將從Sql型資料庫向NoSql型資料庫轉換，未來將出現Sql資料庫和NoSql資料庫並行的情況。

第三：資料倉庫管理智慧化。在雲計算平臺的支撐下，未來企業資料倉庫的管理必然向智慧化方向發展，基於PaaS將更容易構建出智慧化的管理方案，從而提升資料倉庫的價值。

最後，這一系列的改變自然離不開人才結構的升級。

我以我曾經做過的一個大資料專案來舉例吧。

我們建立了一個數據中心，這個資料中心每天會彙總所有有關銷售、財務、客服、使用者的各種資料，然後定期的輸出各種維度的結果，為銷售人員的提成核算、財務的系統所需要的各種資料、客服反饋的進度處理情況，使用者對於系統的使用情況，行為作出全程的分析處理。

為了保證資料系統的健康和強健，那麼我們自然不能什麼資料都往裡面塞，因此，我們需要對資料倉庫進行分級。

首先，不同的前端應用程式，我們需要設定一個3級資料倉，或者說是前置資料倉庫，用於存放這些系統傳遞過來的原始資料。

然後，我們透過對資料探勘和分析，進行建模，將多維度的資料綜合處理後，存放到2級資料倉中，當2級資料倉中的資料出現一些問題時，可以進行人工的干預。

例如：我們的銷售資料和電子合同分別在兩個系統中儲存，而收款進度情況又和財務系統有關，我們想要知道這個月應該給銷售人員多少的佣金時，就可以彙總銷售資料和合同資料，再加上匯款的資料，得出結果。而這個結果的原始資料，就放在2級資料倉裡面。

最終的1級資料倉，其實是用來做最終結果的輸出的，我們的資料加工後，可能沒有對時間維度、人員維度、專案維度等等多維度進行加工。

而我們的管理人員可能會關心一些業務方面的環比資料、同步資料，那麼，我們就可以根據需要，再次對資料進行加工，然後放到1級的資料倉裡面，配合資料中心的系統，想其他應用系統輸出，或者直接作為結果進行展示。

當然，這裡的資料庫可以是關係型資料庫，也可以是非關係型資料庫，資料加工的工具也有很多，我們根據需求進行選用就是了。

大資料時代，如何構建企業資料倉庫？個人認為，目前資料倉庫型別主要分為兩種，一種是離線資料倉庫，一種是實時資料倉庫，這兩種資料倉庫的主要區別在於業務對於資料計算延遲的敏感度。離線資料倉庫一般計算的資料是 T-1天，既今天只能看到昨天的計算資料，適合對資料產出時間不是那麼敏感的業務，比如你現在看到的一些網站對你文章閱讀量的統計資訊。實時數倉在於對資料的實時性計算，業務同學可以實時監測到業務指標的變化，從而及時的做出相應決策來應對業務的調整。這兩種數倉雖然從技術實現上有一定差異，但是整體模型構建上，卻有很多的相似點。

離線資料倉庫設計

離線資料倉庫的設計，主要分為三層結構，ODS層(原始資料層),DWD層(公共明細層)和DWS(公共彙總層)，APP層(業務資料應用層)。一般ODS層的資料是直接來源於線上業務，沒有經過任何的加工處理，所以你在進行模型構建的時候，第一步需要對ODS層的資料進行處理轉換，加工出你所需要的資料。

開發同學在進行模型構建時，要儘可能保證自己開發出的資料模型的公用性，這樣你開發出來的資料更好的具有統一性，保證計算邏輯的統一，其次別的同學也可以使用你的資料，進一步降低口徑不一致所帶來的問題，同時也便於你維護你所開發出來的資料。所以DWD層和DWS層所做的事情就是維護資料的統一，同時，也進一步降低了任務計算的成本，因為計算量較大的任務都做成公共層，每天只計算一次，而不是每個同學都去計算。

APP層是對DWD層或者DWS層的資料的應用，一般如果有業務方或者BI同學找你要資料時，可以讓他們的資料任務直接從DWD或者DWS層取出相關的指標資料，指標具體怎麼拼接，怎麼使用，交給業務方來具體使用，你只需要提供公共資料就可以了。

實時資料倉庫設計

實時資料倉庫的設計和離線資料倉庫的整體架構很類似，不過實時資料倉庫使用訊息中介軟體來進行資料的傳輸。實時資料倉庫一般需要使用實時計算引擎(比如Flink)、訊息中間儲存(Kakfa訊息中介軟體)、計算結果儲存(HBase,HDFS等等)。整體上實時資料倉庫也可以分為三層，ODS、DWD和DWS層、APP層。線上業務資料直接到Kafka或者其他的訊息儲存系統，使用Flink實時消費資料計算，然後計算的中間結果儲存到HBase或者繼續使用Kafka來進行儲存，最後使用統一的介面服務層(比如 OneService) 為業務使用方提供Dubbo介面獲取指標資料，前段在進行展示。資料同學在開發實時任務時，也應該考慮到資料任務通用性、可維護性、降低計算資源成本，一次開發，都可以使用，畢竟實時計算任務消耗的叢集資源還是很大的。

總結

實時數倉和離線數倉從整體架構設計上很類似，雖然在底層實現所用到的技術有很大差異，但是思想都是不變的。資料倉庫最終的目的是為業務服務，更好的指導業務的運營和發展，所以在開發資料任務的同時，也要考慮到業務方使用是否方便、資料準確等。

首先大家都知道資料倉庫建設的目的，解決了什麼樣的問題，為什麼用它，如果連這個都還不清楚，那麼就是在瞎搞。

說白了資料倉庫要解決的問題就是減少資料查詢的重複性操作，更具體點就是提高查詢效率。

要知道如果沒有數倉，那麼那些bi產品展示的指標就沒法得到嗎？不是，完全可以得到，換句話說，業務資料的聚合操作完全可以在常規資料庫如mysql裡做關聯查詢，但是我們都知道這麼做的話效率非常低，甚至mySQL是出不來資料的。所以為了提高查詢效能才有了資料倉庫，提前做聚合，把一些指標在數倉裡面跑完，然後給應用層做展示。當然數倉的另一個目的是把零散的資料彙總起來做個關聯，然後查詢出有用的資料做展示，也就是打通資料，讓以前孤立的資料關聯起來，產生有用的價值。那麼究竟怎麼建立呢？

簡單的說，首先要知道資料的來源，因為不同的來源資料處理方式是不一樣的。比如你的資料是從業務來源也就是mysql這樣的常規資料庫，還是來源於日誌。然後資料同步到數倉的第1層也就是ods，這一層就是將原始的資料匯入到資料倉庫中，當然匯入的方式根據資料分flume或者是sqoop，這一層本身對資料不做任何處理，只是將資料匯入到數倉，以及做一些簡單的etl。

然後是dwd層，在dwd層當中要對上游的每一張表做具體的處理，注意這裡面只是對有關聯的主題的相關表做處理，跨主題的表不會做關聯。比如訂單表和訂單明細表，這就是兩張表要各自處理各自的，然後在各自表中做聚合操作的是降維處理，也就是維度表才會做關聯的處理，本身dwd層的目的就是以事實表為中心，周圍鼓曲關聯維度表，那麼維度表比較多的話，才會將相關的維度表做聚合，也就是降維形成一張維度表和事實表的關係。

接下來是dws，在這一層才會根據具體的指標做聚合的查詢，生成有目的性的聚合表，但是這個聚合表也不是最終的結果，是根據一些大的範圍提前做一些聚合的查詢。最後才是ads，也就是結果表示根據業務方的需求，他們有什麼樣的指標，根據他們提出的指標去生成相應的結果，最後求出的結果匯入es或者是mysql，給應用層做展示用。

以上只是一個大概的流程，具體一些細節要根據業務的不同去做相應的分析和處理，比如說同步策略不同表有不同的同步策略，還要根據業務的需求進行相應的同步，哪些表需要全量同步，哪些表需要新增和變化的同步，哪些表還要刷歷史資料，這些都要根據業務的不同做具體的分析，所以一定要熟悉業務，業務才是建立良好資料倉庫的關鍵，否則一套通用的資料倉庫存在的話，那麼各個行業就不必要建立自己的資料倉庫了，拿來直接套用就行，但是要說的是，這樣的資料倉庫是不存在的，各自企業的業務內容不一樣，主要根據自己的業務去建立屬於自己的資料倉庫。

好了，這就是我想說的。。。

目前最火熱的資料倉庫莫非clickhouse莫屬了，其叢集輕鬆支援億級別資料。

其搭建可參考：億級資料秒級查詢資料倉庫clickhouse安裝，

其基本操作可參考：億級資料秒查資料倉庫clickhouse基本操作及其叢集表。

當然這只是資料倉庫的儲存和查詢，而且clickhouse非常擅長根據group by進行資料彙總，它是列式資料庫。當然clickhouse只是整個企業資料倉庫構建的最核心的一部分。一般資料倉庫的全套系統會結合Hadoop大資料系列，Hadoop平臺可以使用CDH來進行搭建，其免費版就已經滿足大部分的大資料分析的需求了。可以使用flume來抽取資料寫入到kafka，對於詳情資料可以透過kafka直接寫入到clickhouse，對於一些彙總資料可以結合spark叢集來進行計算將最終結果彙總寫入到clickhouse

clickhouse的操作是使用sql，大部分SQL基本都是通用的，因此操作上手很快。springboot+mybatis-plus 可以對clickhouse資料進行分析，具體的資料分析就是結合企業自身的業務需求了。最終展示一般使用表格或者echarts來展示企業分析資料。

首推上述方案

除此還有：es的方案，kudu+impala+druid方案