數據倉庫之父 Bill Inmon 將數據倉庫描述為一個面向主題的、集成的、穩定的、反應歷史變化的數據集合，用于支持管理者的決策過程。

前言

從上面的引言里面，我們其實可以知道主題在數倉建設里面絕對是很重要的一環，這的確是的。數倉在建設過程中，對數據的組織管理上，不僅僅要進行橫向的分層，也需要根據業務情況進行縱向的主題域劃分。看到這里可能就有疑問了，上面明明說的是面向主題，怎么又突然說到主題域了，這里就延伸出主題和主題域的關系了。

下面我就圍繞數倉主題、主題域以及兩者之間關系、劃分方式等，進行更詳細的闡述。

數倉主題是什么？

數倉主題(Subject) 是在較高層次上將企業信息系統中某一分析對象（重點是分析的對象）的數據進行整合、歸類并分析的一種范圍，屬于一個抽象概念，簡單點說每一個主題對應一個宏觀分析領域。

下面舉例說明一下：對于一個erp系統而言，"銷售分析"就是一個分析領域，這個"銷售分析"所涉及到的分析對象有商品、供應商、顧客、倉庫等，那么數倉主題就確定為商品主題、供應商主題、顧客主題、倉庫主題，"銷售分析"就可以作為一個主題域；

如果"產品分析"是一個分析領域，"產品分析"所涉及到的分析對象為商品、地域、時間、類別等，那么數倉的主題可以確定為商品主題、地域主題、時間主題、類別主題，"產品分析"可以作為一個主題域。

數倉主題域是什么呢？

主題域通常是聯系較為緊密的數據主題的集合，可以根據業務的關注點，將這些數據主題劃分到不同的主題域，這種劃分個人感覺與Kimball思想更為相似，自下而上的方式，根據業務需求分析視角進行劃分。

其實這里市面上，也有一些不同的描述，上面對主題域的描述被歸于集合論，還有一種叫做是邊界論，這里稍微擴展下：

邊界論的論點是 “主題域是對某個主題進行分析后確定的主題的邊界“，這點個人感覺和 Inmon 指導思想類似，理清主題之間的邊界，由ER模型進行邏輯轉化，對某一主題域的分析，需要先確定這個主題的關系邊界，然后再進行邏輯建模。

我的話覺得兩者并不矛盾，只是所站的視角不同，邊界論是先從細微處也就是微觀延伸到宏觀，而集合論則是從宏觀到微觀的過程。

主題的劃分和設計

主題的劃分和設計是對主題域進一步的分解，細化的過程。主題域下面可以有多個主題，主題還可以劃分成更多的子主題，主題和主題之間的建設可能會有交叉現象，而實體則是不可劃分的最小單位。

主題域、主題、實體的關系如下圖所示：

可以顯而易見的看出，主題域是一個更大的概念，主題是略次之，實體最小，這里的實體表示的是實體對象（對應企業中某一宏觀分析領域所涉及的分析對象）,我的理解在維度建模的方法論上也可以說實體和維度某些概念是相似的。

在進行數據倉庫設計時，一般是先基于一個主題或某部分主題進行優先建設，所以在大多數數據倉庫的設計過程中都有一個主題域的選擇過程，主題域的確定必須由最終用戶和數據倉庫的設計人員共同完成。

而在劃分主題域時，大家的切入點不同可能會造成一些爭論、重構等的現象，考慮的方法有下面一些：

按照所屬系統劃分：業務系統有幾種，就劃分幾種

按照業務(功能模塊/業務線)或業務過程劃分

比如一個靠銷售廣告位置的門戶網站主題域可能會有廣告域，客戶域等，而廣告域可能就會有廣告的庫存，銷售分析、內部投放分析等主題；

按照部門劃分

比如公司里面的人力、財務、銷售、運營等，運營域中可能會有工資支出分析、活動宣傳效果分析等主題。

按照行業案例分析

在某些行業，比如電信、金融都是最早建設數倉的行業，都有一些規范，比如IBM 公司的 BDWM 九大金融主題模型,Teradata 公司的 FS-LDM 十大金融主題模型，都是行業應用比較廣泛的標準，如果是這兩個行業就可以參考構建自己的企業數據倉庫模型規范。

BDWMFS-LDM

總而言之，切入的出發點邏輯不一樣，就可以存在不同的劃分邏輯。在建設過程中可采用迭代方式，不糾結于一次完成所有主題的抽象，可先從明確定義的主題開始，后續逐步歸納總結成自身行業的標準模型。

在很多文檔上都有說數據域，反而沒有主題域的概念，那數據域到底是什么，又和主題域什么關系呢？

我自己在網上也搜索了很多，也沒查到對兩者的來源和區別說明讓我滿意的，但是我在看《阿里大數據之路》和 阿里的官方相關文檔 介紹上，看到了這個詞，下面可以看下引用的阿里對數據域的介紹：

數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。為保障整個體系的生命力，數據域需要抽象提煉，并長期維護更新。在劃分數據域時，既能涵蓋當前所有的業務需求，又能讓新業務在進入時可以被包含進已有的數據域或擴展新的數據域。數據域的劃分工作可以在業務調研之后進行，需要分析各個業務模塊中有哪些業務活動。

我個人理解其實主題域和數據域差異不大，在實際過程中可以把主題域和數據域都當做一種域來處理了，不必糾結。

當我我也查到網上，有人總結的一段話，是將兩者描述為一種包含關系，姑且可以看下：

主題域

面向業務過程，將業務活動事件進行抽象的集合，如下單、支付、退款都是業務過程，針對公共明細層（DWD）進行主題劃分。數據域：面向業務分析，將業務過程或者維度進行抽象的集合，針對公共匯總層（DWS）進行數據域劃分。

為保證整個數倉體系的生命力，數據域需要抽象提煉，長期維護及更新，但不要輕易變動，在劃分數據域時，既能涵蓋當前所有的業務需求，又能在新業務接入時無影響的包含進已有的數據域中或者擴展出新的數據域，這是劃分的一個準則。

特別說明的是，主題域是無法一次劃分完整的，在大多數數據倉庫的設計過程中都有一個主題域的選擇過程。業務一直發展的，設計之初就想著一次把所有主題全部劃分完整，是不太可能，也不太適用的，我們可以遵循上面說的劃分主題域的準則，以不斷迭代的方式進行。

馬蜂窩數倉主題、主題域劃分案例

以馬蜂窩訂單交易模型的建設為例，基于業務生產總線的設計是常見的模式，首先調研訂單交易的完整過程，定位過程中的關鍵節點，確認各節點上發生的核心事實信息。

馬蜂窩數據模型網易云音樂數倉主題、主題域劃分案例

網易云音樂將一級主題域劃分為參與者、服務及產品，版權及協議、公共、事實這5個大的主題域，二級細節分類按照業務過程抽象獲得。

之前在一家互聯網醫療公司工作，主題域的劃分是按照部門bu進行劃分的，這種方式適合較大的集團公司，各個事業部或者業務交叉不大的，不同的bu使用不同的數據域，這種架構它是一種小型的、部門級數據倉庫，企業的不同部門有不同的 “主題域”，因而就有不同的獨立性數據集市。

實際操作是按照部門劃分了獨立的數據集市，也就是主題域之后，再利用業務過程抽象出細分的主題。。

獨立型數據集市的實質，是為了滿足企業內各部門的分析需求而建立的微型數據倉庫。有些企業在實施數據倉庫項目時，為了節省投資，盡快見效，針對不同部門的需要，分步建立起這類數據集市，以解決一些較為迫切的問題。

但是，當多個獨立的數據集市增長到一定規模后，由于沒有統一的數據倉庫協調，企業只會又增長出一些新的信息孤島，仍然不能以整個企業的視角來分析數據，所以就延伸出另外一種企業級的數據倉庫架構，后面有時間再單獨分析這塊。

結合我參與過的數倉項目建設經驗和踩過的坑，對于數倉主題、主題域劃分個人比較推薦按照業務系統劃分或者bu部門來劃分主題域（一級主題），這樣的話邊界較為清晰，數據倉庫開發過程也不會因為模型主題的歸屬引發扯皮和不同意見，然后根據各個系統中的業務過程抽象整合出主題（叫二級主題域也可以）。

數倉建設是一整套方法論，但方法論不一定是真理，每個公司都有自己的業務場景及需求，方法論或別人的方案不一定適用自己的公司，我們需要學習利用這些方法論，然后結合自己公司實際的業務場景來制定自己的主題及主題域劃分規范。