数仓的主题和主题域应该怎么划分呢？

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

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

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

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。

在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。

数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

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

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

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

数据域：面向业务分析，将业务过程或者维度进行抽象的集合，针对公共汇总层（DWS）进行数据域划分。

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

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

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

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

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

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

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

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

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

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

本文由 @白程序员的自习室 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。