都说数仓是面向主题建设的，那数仓的主题和主题域又应该怎么划分呢？

数据仓库之父 Bill Inmon 将数据仓库描述为一个面向主题的、集成的、稳定的、反应历史变化的数据集合，用于支持管理者的决策过程。

前言

从上面的引言里面，我们其实可以知道主题在数仓建设里面绝对是很重要的一环，这的确是的。数仓在建设过程中，对数据的组织管理上，不仅仅要进行横向的分层，也需要根据业务情况进行纵向的主题域划分。看到这里可能就有疑问了，上面明明说的是面向主题，怎么又突然说到主题域了，这里就延伸出主题和主题域的关系了。

下面我就围绕数仓主题、主题域以及两者之间关系、划分方式等，进行更详细的阐述。

数仓主题是什么，主题域又是什么呢？

数仓主题是什么？

数仓主题(Subject) 是在较高层次上将企业信息系统中某一分析对象（重点是分析的对象）的数据进行整合、归类并分析的一种范围，属于一个抽象概念，简单点说每一个主题对应一个宏观分析领域。

下面举例说明一下：对于一个 erp 系统而言，"销售分析"就是一个分析领域，这个"销售分析"所涉及到的分析对象有商品、供应商、顾客、仓库等，那么数仓主题就确定为商品主题、供应商主题、顾客主题、仓库主题，"销售分析"就可以作为一个主题域；

如果"产品分析"是一个分析领域，"产品分析"所涉及到的分析对象为商品、地域、时间、类别等，那么数仓的主题可以确定为商品主题、地域主题、时间主题、类别主题，"产品分析"可以作为一个主题域。

数仓主题域是什么呢？

主题域通常是联系较为紧密的数据主题的集合，可以根据业务的关注点，将这些数据主题划分到不同的主题域，这种划分个人感觉与 Kimball 思想更为相似，自下而上的方式，根据业务需求分析视角进行划分。

其实这里市面上，也有一些不同的描述，上面对主题域的描述被归于集合论，还有一种叫做是边界论，这里稍微扩展下：

边界论的论点是 “主题域是对某个主题进行分析后确定的主题的边界“，这点个人感觉和 Inmon 指导思想类似，理清主题之间的边界，由 ER 模型进行逻辑转化，对某一主题域的分析，需要先确定这个主题的关系边界，然后再进行逻辑建模。

我的话觉得两者并不矛盾，只是所站的视角不同，边界论是先从细微处也就是微观延伸到宏观，而集合论则是从宏观到微观的过程。

主题的划分

主题的划分和设计是对主题域进一步的分解，细化的过程。主题域下面可以有多个主题，主题还可以划分成更多的子主题，主题和主题之间的建设可能会有交叉现象，而实体则是不可划分的最小单位。

主题域、主题、实体的关系如下图所示：

可以显而易见的看出，主题域是一个更大的概念，主题是略次之，实体最小，这里的实体表示的是实体对象（对应企业中某一宏观分析领域所涉及的分析对象）,我的理解在维度建模的方法论上也可以说实体和维度某些概念是相似的。

主题域划分方法

在进行数据仓库设计时，一般是先基于一个主题或某部分主题进行优先建设，所以在大多数数据仓库的设计过程中都有一个主题域的选择过程，主题域的确定必须由最终用户和数据仓库的设计人员共同完成。

而在划分主题域时，大家的切入点不同可能会造成一些争论、重构等的现象，考虑的方法有下面一些：

按照所属系统划分：业务系统有几种，就划分几种

按照业务(功能模块/业务线)或业务过程划分

比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；

按照部门划分

比如公司里面的人力、财务、销售、运营等，运营域中可能会有工资支出分析、活动宣传效果分析等主题

按照行业案例分析

在某些行业，比如电信、金融都是最早建设数仓的行业，都有一些规范，比如 IBM 公司的 BDWM 九大金融主题模型,Teradata 公司的 FS-LDM 十大金融主题模型，都是行业应用比较广泛的标准，如果是这两个行业就可以参考构建自己的企业数据仓库模型规范

BDWM

FS-LDM

总而言之，切入的出发点逻辑不一样，就可以存在不同的划分逻辑。在建设过程中可采用迭代方式，不纠结于一次完成所有主题的抽象，可先从明确定义的主题开始，后续逐步归纳总结成自身行业的标准模型。

数据域是什么，和主题域之间的关系

在很多文档上都有说数据域，反而没有主题域的概念，那数据域到底是什么，又和主题域什么关系呢？

我自己在网上也搜索了很多，也没查到对两者的来源和区别说明让我满意的，但是我在看《阿里大数据之路》和 阿里的官方相关文档 介绍上，看到了这个词，下面可以看下引用的阿里对数据域的介绍：

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

我个人理解其实主题域和数据域差异不大，在实际过程中可以把主题域和数据域都当做一种域来处理了，不必纠结。

当我我也查到网上，有人总结的一段话，是将两者描述为一种包含关系，姑且可以看下：

主题域：面向业务过程，将业务活动事件进行抽象的集合，如下单、支付、退款都是业务过程，针对公共明细层（DWD）进行主题划分。数据域：面向业务分析，将业务过程或者维度进行抽象的集合，针对公共汇总层（DWS）进行数据域划分。

主题域及主题划分的准则

为保证整个数仓体系的生命力，数据域需要抽象提炼，长期维护及更新，但不要轻易变动，在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务接入时无影响的包含进已有的数据域中或者扩展出新的数据域，这是划分的一个准则。

特别说明的是，主题域是无法一次划分完整的，在大多数数据仓库的设计过程中都有一个主题域的选择过程。业务一直发展的，设计之初就想着一次把所有主题全部划分完整，是不太可能，也不太适用的，我们可以遵循上面说的划分主题域的准则，以不断迭代的方式进行。

案例介绍

马蜂窝数仓主题、主题域划分案例

以马蜂窝订单交易模型的建设为例，基于业务生产总线的设计是常见的模式，首先调研订单交易的完整过程，定位过程中的关键节点，确认各节点上发生的核心事实信息。

马蜂窝数据模型

网易云音乐数仓主题、主题域划分案例

网易云音乐将一级主题域划分为参与者、服务及产品，版权及协议、公共、事实这 5 个大的主题域，二级细节分类按照业务过程抽象获得。

个人工作中的案例介绍

之前在一家互联网医疗公司工作，主题域的划分是按照部门 bu 进行划分的，这种方式适合较大的集团公司，各个事业部或者业务交叉不大的，不同的 bu 使用不同的数据域，这种架构它是一种小型的、部门级数据仓库，企业的不同部门有不同的 “主题域”，因而就有不同的独立性数据集市。

实际操作是按照部门划分了独立的数据集市，也就是主题域之后，再利用业务过程抽象出细分的主题。。

扩展下独立性数据集市的概念

独立型数据集市的实质，是为了满足企业内各部门的分析需求而建立的微型数据仓库。有些企业在实施数据仓库项目时，为了节省投资，尽快见效，针对不同部门的需要，分步建立起这类数据集市，以解决一些较为迫切的问题。

但是，当多个独立的数据集市增长到一定规模后，由于没有统一的数据仓库协调，企业只会又增长出一些新的信息孤岛，仍然不能以整个企业的视角来分析数据，所以就延伸出另外一种企业级的数据仓库架构，后面有时间再单独分析这块。

我的一些建议

结合我参与过的数仓项目建设经验和踩过的坑，对于数仓主题、主题域划分个人比较推荐按照业务系统划分或者 bu 部门来划分主题域（一级主题），这样的话边界较为清晰，数据仓库开发过程也不会因为模型主题的归属引发扯皮和不同意见，然后根据各个系统中的业务过程抽象整合出主题（叫二级主题域也可以）。

总结

数仓建设是一整套方法论，但方法论不一定是真理，每个公司都有自己的业务场景及需求，方法论或别人的方案不一定适用自己的公司，我们需要学习利用这些方法论，然后结合自己公司实际的业务场景来制定自己的主题及主题域划分规范。