前言

数据仓库、数据集市的主题和主题域是什么？这个问题答案很多，而相关的开发人员对这些答案也历来莫衷一是。这个问题很复杂吗？很复杂，很难讲，看的资料越多越难讲，不信的话你尝试向邻居八十岁的奶奶讲一下什么是“元宇宙”。你可能说我是一位年方十八青春年少英俊潇洒聪明睿智的靓仔，又不是八十岁的老人家，你给我讲主题和主题域，我理解能力超强，根本不怕你讲得多晦涩。咱们试试：

圣经

孩子没娘，说来话长，事情得从 *** 开天辟地说起，啊，讲岔了，得从三十年多前说起。美国数据科学家比尔·恩门（Bill Inmon）于1990年首先提出数据仓库的概念，并在次年出版大名鼎鼎的《Building the Data Warehouse》----中文译名《数据仓库》。从此Inmon被称为数据仓库之父，他的这部著作被狂热的粉丝奉为数据仓库领域的《圣经》。

《圣经》里说数据仓库是面向主题的，并未就主题是什么做进一步阐释，而是举了一个栗子，又一个栗子，一筐栗子。我看了一堆栗子也没能把栗子看成核桃，看成主题，不过倒是隐约知道了他表达的意思，主题就是实体对象，主题域就是主题相关的表。例如：顾客就是一个主题，主题域就是顾客相关的表，顾客主表、顾客附属表等等。有兴趣的同学自行去读一下《圣经》，在此我不在赘述。

新约

上面说了数仓之父关于数仓主题的思想，现在说另一个数仓大神----Kimball。这位大神同样是美国人，他在1996年出版了一部著作《数据仓库工具箱：维度建模指南》，同样是一书封神。在数据开发人员眼中，这本书同样是《圣经》，我个人觉得呢，这本书更像是《圣经 新约》，数仓之父的那边呢更像是《圣经 旧约》。什么，你不了解《旧约》《新约》？没关系，你把《圣经》当做《易筋洗髓经》，《旧约》当做是《易筋经》，《新约》则当做是《洗髓经》，肿么样？

《新约》的维度建模基本思想类似于现在我们平时所说的宽表，并且根本没提主题这回事，自然也没啥主题域喽。虽然《新约》没提主题这回事，但是不妨有好事者给补充或者说脑补点内容，他们把一个个宽表认做是一个主题，客户的宽表(包括基本信息、消费、业务等信息)是客户主题，商品的宽表(包括销量、产地、价格等)是商品主题，总之是这种意思吧，这样的理解未必全错，但这是分明是藐视《圣经》啊！

金融领域

在金融领域，Teradata公司定义了大名鼎鼎的FS-LDM(Financial Services Logcial Data Model)数据模型，里面有十大主题；IBM公司定义了BDWM (Banking Date Warehouse Model)里面有九大主题，这两套模型基本是按照《旧约》规范来定义的，不过这两套模型中的主题往往又分为若干子主题甚至孙主题。这九、十大主题和子主题、孙主题的其实就是把业务实体分成了九大类十大类乃至更多的子类。

阿里巴巴

阿里巴巴官方文档有这样的定义：“数据仓库是面向主题（数据综合、归类并进行分析利用）的应用...数据域是联系较为紧密的数据主题的 *** ，是业务对象高度概括的概念，目的是便于管理和应用数据。”这个定义明显跟《旧约》《新约》都不同了，这里的主题成了分析方向或者数据归类，例如：贸易公司数仓里贸易公司财务分析、银行数仓里银行零售类等都可以作为一个主题。主题域也变了，跟财务主题沾边的数据都在财务域，跟银行零售主题沾边的数据也都在这个主题域。在这种情况下，不同主题域的实体是有重叠的。

阿里给的这个定义我个人是比较信服的，自然不因为他是大厂，而是这确实是目前相当主流的一种观点。

其他

有一种思想认为单独的数据集市就是一个主题，这种思想貌似也没错，其他各种表述在这里不再一一赘述，毕竟这只是一篇游戏之作。

综上所述，先有《旧约》，后有《新约》，又有人藐视《旧约*新约》，再后来干脆造《圣经》的反。阿里巴巴对主题的一种描述分明比数仓之父说的更抽象、数据范围更大，而后面的一种主题描述又比阿里巴巴描述的更甚。哇，这么乱，还有没有规矩、还有没有王法！在《圣经》的叙述中：“上帝说，要有光！于是便有了光。”规矩，不就是让人遵守的吗？不！规矩，也可以是用来打破的。要是人人都遵守某条规矩，从不触犯，那这条规矩差不多也该废除了。

总结一下，在主题和主题域的概念上有很多中说法，有的表述相近但是不尽相同，有些表述差别较大。一般大公司做数仓，多采用金融主题类似的主题提取和主题域划分方法；而做数据集市则采用阿里巴巴这类思想，这两种思想也并不是完全相悖。

上面所述的关于主题和主题域的这么多，我讲清楚了吗？我没讲清楚，你没看懂也没关系，反正我是不会承认错误的。看懂了，当然你就是玉树临风、英明睿智、青春年少永远十八岁的骚年，看不懂仍然也是。

为什么分主题

这几种关于主题和主题域的说法那种对呢？

......小孩才分对错，大人只看利弊。

我们不如从头捋一下，反问一句根本的问题：数仓为什么要提取主题，划分主题域呢？还有这个问题的兄弟，问题二：数仓为啥什么分层，分几层，根据什么来分层？试着回答一下，不忘初心嘛！

数仓本质上就是一个数据加工厂。

你脑海中可以浮现一个生产轿车、卡车、拖拉机的车辆厂。

假如我们要建设一个数仓，一共涉及十张表，需要用这十张表简单关联一下做2张台账。这样的数仓我们需要分层吗？需要提取主题吗？

答案自然是不需要！

那新建一个数仓，数仓分层到底该遵循什么原则呢？ 看数据加工的复杂度！如果给你一堆xml、html、json、照片，最后让你出一堆复杂的报表，这样的加工过程可能很复杂，涉及步骤比较多，这样可以适当多分几层，反之则少分几层。车辆厂接收的原料是钢铁、橡胶这类原始材料做汽车势必很麻烦，如果接收的原料是轮胎、发动机、车灯这样的材料加工过程会简单很多。

如果每一层表数量比较多，则适当分域。我们在甲方客户现场同一办公区域，这个办公区域有四个项目组，一百多人，每个项目组的相关开发人员都坐在一起，而不是这四个项目组一百多个同事混坐。为什么？ 好管理、好沟通啊。数仓划分域也是一样，同一层有很多表，根据这些表的业务相关性把他们划分为不同的组，好管理，好应用。百来平的房子有卧室、厕所、厨房、客厅是为啥? 为啥不做成整个一室？车辆厂为啥做成许多不同的车间，而不是组装拖拉机的车间和组装轿车的车间并成一个大车间？家里来了客人，吃饭要添一副碗筷，我就去厨房取，业务系统从数仓提取零售客户信息，我就去当事人域找，都是一样的道理。

数仓分层、分域(主题域) 都是为了方便数据管理和使用。分层主要取决于数据加工的复杂度，一般分层有2、3、4、5层，再多就不建议了，那数仓得复杂成啥鬼样。这里我们要注意区分数仓和数据集市，在大型企业数仓一般处于数据基础层次，会提供对多个数据集市的数据支撑，它理论上包含企业全部的数据，它的服务是面向整个企业的，一般不直接面向用户；而数据集市一般是专门面对某个部门或某几个部门、某一个特定业务或某几个特定业务的需求，是面向特定需求的，是直接面向用户应用的。关于数仓的主题域，如果行业有成熟的主题模型，金融、电信等行业建议直接拿来用，他们都是经过实践验证的，不用做选择。例如我们在银行做数仓，TD公司的十大主题或者IBM公司的九大主题，直接拿过来用就行，业务系统向数仓提需求一般都是要各种明细表，数仓管理者通过主题可以很方便查找和提取数据。如果是做数据集市，则要重新考虑我们的数据组织方式或者叫归类方式。当前在甲方做的一个资产质量集市，其中的主题划分则分为公贷、零售、票据、信用卡、非信贷等，相关的表按照这个来归类，这个归类也是为了方便用户和系统管理者。数仓和集市的每一层跟每一层的表归类方式也不一定要相同，便于数据使用和数据管理是永远的真理。

补充一点，咱们做的项目中，未必只有数仓和数据集市才把数据归类，其他日间业务系统也同样做数据归类，这个在我们所有项目中基本都是这么做的，只不过归类是否合理，是否按规则是另外的问题了。你的项目生产环境中是否存在大量临时表、备份表？这些表是如何处理的？如何归置的？

最后归纳：数仓分层看数据加工复杂度，根据复杂度设置合理分层；数仓提取主题域根据每层表的多寡以及合适的归类方式，合适的归类方式就是便于数据管理和数据使用的归类方式，可以设置多个类别及子类别。主题提取主题域划分只有这一招，这一招也是无数招，可以根据这一招在不同的仓库、集市中划分出无数种主题域。

还没讲透？仍然不要紧，项目组也不是人人都擅长前端、后台、数据开发及设计，让擅长的人来做。^_^