数仓与主题域

引

今日 Coding 之时，偶尔间发现，目前我们以业务流程划分各项主题的方式似乎有丝许不妥。因此陷入沉思，过去的经验里是怎么去划分主题域、数据域的？于是有了今天的文章

主题域

何以为主题域？窃以为，是由非常多个数据主题进行沟通。我们将这一系列具备一定相关性的主题划在一起，组成了我们所谓的主题域。这里我们用“拆解至最小单元”这个方法来对每个主题域拆分，于是可见，主题，是主题域的组成部份。那么，再向下拆，会是什么？什么是组成主题的基本单元？

网上有文也已经对这个问题进行了分析。按照其他作者的观点，“主体”是每个主题的最基本组成单元。举例来说，客户主题域我们客户划分为客户购买主题、客户下单主题、客户收获等主题。这里客户的主题域可以围绕客户的业务订单流转，来划分不同的主题。而在客户购买主题里，我们又可以细细拆分到一些主体，比如一定有的客户，购买状态主体等等。然后通过对主体、主题、主题域的划分，逐步确定好其业务模型，制定出对应的数据标准。

而主题域和主题域之间，也必然会有一定的联系。那么在制定模型的时候，也就可以在确定的模型层上进行相互连接，确保整体的模型能良好地描述我们一个行业或者一家公司的所有的业务开展。

这里，再摘录一些看到的主题域的划分方法。

按照业务过程划分

业务过程划分，就是按照业务的前后发生顺序，来将业务进行对应的主题域划分。例如我之前所在的在线教育，基本会是 营销广告 -> 名单线索 -> 电销 -> 签约 -> 上课， 这样的大致过程。因此我们可以其为例，划分营销域、线索域、销售域、合约域、课程域。当然这里只是举例，具体如何，还需要结合公司业务实际，来具体落地。

按照需求方划分

按照需求方的划分，则是以部门为基准点来做。例如，如果部门的划分有财务部、运营部、成本部，那么自然而然去划分财务域、运营域、成本域。而有一些公司会有类似合约部，则我们由会相应地设立合约域来统一处理该部门提出的数据需求。

这样一种主题域的组织方式，能够快速将一个组织下的需求归集在一起。而其弊端在于，公司企业的组织架构并不会是一成不变的，当组织架构变更的时候，主题域的变更势必会导致这样的一些问题。

按照系统划分

有一种划分方式，是一个应用系统，划分为一个主题域。这种形式，能够将一个系统内的所有表结构尽可能的内聚。但对于数仓而言，我认为其本身就应该是组合不同业务系统、解决数据孤岛的一种方案，将所有表都内聚在一起，似乎不是非常的方便。这是我的思路。

按照行业的惯例划分

这里就不细细展开了， 其实有很多的行业都有一些经典的主题域划分方案，比如说金融界的 FS-LDM，就将金融行业划成了十大金融主题模型。保险行业，国家的《保险基础数据模型》则将该行业划分了九个主题，也是值得参考的模型。

要制定出一个行业的主题标准、数据模型，并非易事。

结

再思考思考，如何制定出我们这个行业的基础数据模型标准。

于辛丑年冬至