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

主题域的划分

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

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

主题域和维度的迷惑

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

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

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

任务的组织方式

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

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

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

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