数据仓库工作日记_记录（一）

在传统行业从事数据仓库好几年了（不敢贸然写多年），从ETL开发做到了架构师。由于行业因素的关系吧，像银行，电信这些单位（一些体制问题，就不细说了），会有自己的IT部门， 但IT部门的人员编制一般都不会太大，也就更不会招聘自己的项目团队，这也就养育了我天朝强大的外包事业，而我一直都是这外包大军中的一员。

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

项目介绍：一某地方性商业银行；系统的出版在N年前就上线了；系统的逻辑结构是进行了数仓常见的逻辑分层（ODS，DW等），以及下游系统。

ODS层：源系统的映射层，与源系统同构，只保留当期数据，当然这是一种保守的变种做法；ODS(Operational Data Store）,储存的是当前或接近当前的、不断变化的数据。这里要介绍的项目，仍旧采用的是，离线数据的方式，即不会实时同步变化。之所以设计ODS层，是为了将数据仓库系统与实时业务系统隔离开。在一些单位（朝九晚五从不加班办业务的单位）或类似的项目中，由于下班以后不再产生新的业务数据，因此数据仓库可以采取简单的形式，如oracle的dblink，在下班以后直接访问业务的OLTP数据。可是像银行，通信这一类的企业，都是24时有业务处理的，直接去大批量地查询核心业务系统的数据，不仅会影响对方的处理效率，同时也不能保证数据的准确，这里所说的数据准确，是由于业务系统一直在处理业务，我们不能准确的获取当天24小时内的数据。所以，会在ODS层保存一份截止性的快照数据，同时，也避免了各类分析需求对业务数据库的访问压力。

  DW层：轻度汇总层，按照主题汇总，保留历史数据。在ODS数据加载完成后，DW层开始调度任务。不过，这个项目中的DW层就稍稍有点惨不忍睹了，主题是划分了，但只是按照核心业务系统的表数据内容，大概的分了个类，与ODS的表结构基本一样，只是名字都换了，并不是数据仓库中真正意义上的划分主题。当然了，存在即有道理，这个DW层以拉链和当期快照还有全量的形式保存了历史数据。

  调度：有数据仓库就要有相关调度，这个项目中采用的是我国某中字开头公司的调度产品，这个产品，一个字烂，两个字恶心，三个字我艹了，但人家毕竟是产品！由java来做应用界面，底层功能由shell来实现，具体的分析会在后面的文章中进行刨析，因为我马上就要优化这玩意了。

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