大数据环境下数据仓库的实践（四）—— 主题域的划分及任务和工作流的组织方式

主题域的划分

由于数据仓库跨部门，所以必然存在某些数据关系密切，而某些数据相互比较独立。于是相关的一组数据往往被划成一个个主题域。主题域是为了更好地组织数据仓库。

我们以一个普通的买卖为例，这里的主题域可以划分为：卖家（商家）、买家（客户）、商品、交易、营销等。每个域下面还可以根据业务的复杂程度设置自己的子域，例如交易域下还可以设置正向交易、逆向交易（退款）。

主题域和维度的迷惑

主题域和维度经常容易被混淆。一个主题域只会在它的主题范围内获得所需要的数据，而不会从其他域中获取。

举个例子，当我们要考察某个商品的销售数量时，它需要从交易域获取数据。因此商品销量并不属于商品域，而是交易域的数据。

商品是一个 维度，那么商品域的数据长什么样呢？例如，在售商品数是属于商品域的，它不需要考察交易的情况。

任务的组织方式

任务是组成工作流的最小单位，也是完成一次 数据流转 的最小开发单位，同时也是调度任务进行失败重试的最小单位。

熟悉Informatica的小伙伴可以把它看成mapping。一个表的导入是一个任务，一段带insert操作的Hive SQL也是一个任务。

应当尽可能做到一个任务只操作一张表。反之，一张表也只由一个任务进行写操作。也就是任务和表一一对应。多个任务操作一张表容易造成写入顺序不清晰，追加和覆盖不清晰，重跑任务易漏等风险。一个任务操作多张表则在并行度上就已经显示出劣势了，同时还存在耦合度高、失败重跑成本高等一系列问题。

单个任务的运行时间可以从几分钟到几百分钟不等，但基于失败重试的成本考虑，应当尽可能将单个任务的运行时间控制在1小时之内，30分钟之内是比较理想的单任务运行时间。

最后，在任务的命名上，强烈建议任务名中包含所操作的表名。

工作流的组织方式

工作流是指具有相关性，并且组织在一起调度的一组任务。有了主题域，那么将同一主题同一调度周期的任务组织成一个工作流就显得很自然了。工作流可以类比为Informatica中的workflow。

一个值得考虑的问题是：在同一主题同一调度周期的情况下，落地层的导表任务和依赖它的ETL任务是否应该分工作流组织？我们的建议是分工作流组织。首先，这会让数据仓库的分层更清晰；其次，正如前面所提到的，大数据平台下的数据仓库已经不仅仅是为了BI分析所使用。那么如果我们有大量的导表任务，且并不一定会在后续的ETL中被使用的话，不拆分工作流将会使整个ETL工作流变得臃肿。

工作流的命名可以分为三类：导表类、后续ETL类和各粒度聚合类。同一类工作流除了表示主题域的关键字不同以外，应当有相同的命名格式。

例如导表类工作流叫xxx_loading_stg或者stg_xxx，ETL类工作流叫dws_xxx，聚合类工作流叫dwa_xxx等等。