在从事数据仓库几年传统产业（敢写了很多年），离etl发展做建筑师。

由于行业之间的关系的因素是。像银行，电信这些单位（一些*问题，没有详细说明），这将有自己的IT系。 但IT盛，也就更不会招聘自己的项目团队，这也就养育了我天朝强大的外包事业，而我一直都是这外包大军中的一员。

  准备把文章分成几个主题来写，这个主题是用来记如今刚启动项目的工作笔记的，工作中的一些奇闻轶事就放到其它主题了。

  项目介绍：背景-某地方性商业银行；上线时间-n年前。系统结构-ods，dw，下游系统。

  ods层：源系统的映射层。与源系统同构。仅仅保留当期数据。之所以设计ods层，是为了将数据仓库系统与实时业务系统隔离开。在一些事业单位（朝九晚五从不加班办业务的单位，大家懂的）或类似的项目中，因为下班以后不再产生新的业务。因此数据仓库能够採取简单的形式，如oracle的dblink。在下班以后直接将数据抽取过来。

但像银行，通信这一类的企业。都是24时有业务处理的。直接去大批量地查询核心业务系统的数据，不仅会影响对方的处理效率，同一时候也不能保证数据的准确，这里所说的数据准确，是因为业务系统一直在处理业务，我们不能准确的获取当天24小时内的数据。ods（Operational Data Store）的功能也就体现出来了。当然，这仅仅是ods的一部分功能了

  dw层：轻度汇总层，依照主题汇总，保留历史数据。

在ods数据载入完毕后，dw层開始调度任务。只是，这个项目中的dw层就稍稍有点慘不忍睹了，主题是划分了，但仅仅是依照核心业务系统的表数据内容，大概的分了个类，与ods的表结构基本一样。仅仅是名字都换了。并非数据仓库中真正意义上的划分主题。

当然了，存在即有道理，这个dw层以拉链和当期快照还有全量的形式保存了历史数据。

  调度：有数据仓库就要有相关调度，这个项目中採用的是我国某中字开头公司的调度产品，这个产品，一个字烂。两个字恶心。三个字我艹了，但人家毕竟是产品！

由java来做应用界面。底层功能由shell来实现，详细的分析会在后面的文章中进行刨析。由于我立即就要优化这玩意了。

  讲完背景，下一篇将说明要做的工作。