Data Warehousing，
最近和Bill讨论了很多关于构建数据仓库中的一些设计问题，主要是基于对已有系统的不足来进行回顾与剖析。
一、ODS的必要性
我是完全支持ODS的。一个健全的数据仓库，最为关键的是数据，在对数据模型不是很理解、逻辑模型不是很确定、需求易变，然而对项目时间有限制的数据仓库建设，首推的是先建设ODS，对源系统进行一一对应的拷贝。
这样做的好处有：
1. 先把数据抓进数据仓库中，因为有的源系统可能有删除数据的特性，尽早把数据抓入数据仓库就更能保证数据的完全性。
2. 易于查明数据缺失情况。对比没有ODS的数据仓库，要分析数据仓库中是否缺失了数据，与源系统进行比较是一件痛苦的事情，因为最终数据仓库里的数据模型和格式已经是完全转换过的（fully transformed）。如果仅仅查作为源数据的一份COPY的ODS，那是非常容易的事情。
3. 数据重现。如果目标数据表的转换逻辑变化，那么可以通过ODS重新进行数据清洗。理论上说，无论逻辑如何变化，总能满足易于重构的需求。
4. 与源系统解耦。检查数据质量是否有问题。对比没有ODS的数据仓库，数据质量问题分析往往要复原到源系统的数据格式然后和源系统进行比较。但是如果能保证ODS和源系统是一致的情况，很多数据质量分析工作很容易地在一个环境下（即数据仓库中）用SQL来进行分析比较，尤其是对细节数据discrepancy的查原因上。如果在两个系统中（指源系统和数据仓库），那么比较细节数据将是一件让人望而生畏、、繁复而又愚蠢的工作。
5. 当某一个源系统发生问题，无法抓到数据时，不会影响到其他系统，其他系统的数据可以继续转换加载到仓库中。
二、旧系统迁移
由于旧系统在性能上（比如MySQL数据）无法支撑大数据量，可能要把源系统迁移到新环境下（如ORACLE、Teradata）。那么，有三种方案，第一种是原封不动地迁移过来，保留所有的模式，但这样很难，因为新系统可能不支持一些原有系统的特性。第二种，如果新环境是一个崭新的空白的系统，很多时候就不仅仅是把原有的数据模式原封不动地复制到新环境上，我们很多人可能就直接进行数据仓库重构——这种情况往往发生在原有系统和新环境的开发和支持人员是不同的两批人员，这是很有意思的一件事情。第三种，如果新环境里已经有一套成熟的模式，那么迁移的工作在于把原有系统的数据模式集成到已有新系统中的模式上。
我所接触到的是第三种。
且不论新环境已有系统模式的合理性。任何旧系统往一个新系统中集成，必定会出现不兼容的情况，毕竟新系统的已有模式不是为目前待迁移的旧系统量身定制的。在这种不兼容的情况下，如果硬是要把数据集成起来，可能会很别扭，尤其是现有DW模式中的列的业务定义可能与待迁移的系统的列的定义完全不同，那么硬是把这个列集成进来可能不是很合理。目前我也没有什么好的方法来解决这个问题。
我想说的更进一步的问题，如何保证原有老系统上的分析服务在新系统上运转成功和顺畅。方法很简单，按老系统的分析服务模式复制生成一份在新系统上一模一样的模式，比如老系统上有3个分析的汇总表，那么在新系统上构建相同的3张表，这3张表的数据从新系统中来，这样首先保证了新系统上能够完全支持原有系统的分析服务。在能保证这个基本需求的前提下，再进行其他适合新系统的分析服务开发。这种方法还有一个好处就是当做数据测试，看看我们底层基本表的数据是否正确。在完成对已有系统分析服务的复制生成后，很有原有老系统上的报表可以在新系统上进行运行了，然后再切换到新系统的分析服务模式上。如果直接让用户切换到新系统的服务上的话，这里有很多数据差异分析的工作要开展，而且这种工作不是一件容易的事情。
三、数据仓库的定义
1、数据仓库是面向主题的
我们的仓库就是按照subject area来划分的。
2、数据仓库是集成的，数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，进行加工与集成，统一与综合之后才能进入数据仓库
不错，我们的表集成了很多源系统的数据。
3、数据仓库是非易失的
针对应用用户而言，所涉及的操作主要是数据的查询；
4、数据仓库是时变的
数据仓库中的数据通常包含历史信息，每次加载业务源系统的快照到数据仓库中。系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
第三、四点的典型应用就是缓慢变化维。所以，缓慢变化维是很重要的一个模型层。
四、回顾我们当前的数据仓库
参照数据仓库的定义，我们目前的数据库严格意义上来说就是个ODS，只是这个ODS是有具备第一点和第二点的ODS。只是我们的ODS是集成了很多源系统的ODS，具有存储海量历史数据（主要得益于Teradata强大的数据处理能力）的ODS，所谓的历史数据也就是那些状态（列值）永远不会变化的数据，这些数据呈现的是最终的运营数据状态，这些数据最终的形式就是静止的死状态。至于这些死数据活着时候的每个快照，完全没有。这是个悲哀。
但是，我们必须意识到，并非所有的数据都需要各个历史快照，这取决于业务分析的需求，有的分析就只希望看最终状态。这就是业务驱动。何况，保留所有快照是不现实的，因为磁盘存储消耗太大。
但是没有缓慢变化维度的数据仓库我个人认为这绝对不是一个数据仓库。
五、关于增量抽取
不错，我们可以基于源系统的last modified date进行增量抽取，这也要求我们的源数据系统必须要带上last modified date这个列，任何其他列的数据变化，必须更新last modified date的值，这样我们才能捕捉到数据的变化。
但是事实上，很多业务源系统可能都不带last modified date，那么对于这些没有last modified date的系统，如何进行增量抽取呢？
很简单，把所有的时间column都放在抽取的条件中，并且派生出一个虚拟的last modified date。比如：
select *
case when create_date between F_DATE and T_DATE then create_date
when update_date between F_DATE and T_DATE then update_date
end as last_moidified_date
from source_table
where create_date between F_DATE and T_DATE
or update_date between F_DATE and T_DATE;
这个虚拟的last modified date是非常重要的时间列，它标志了该行数据进入数据仓库的时间，业务意义上表示该行快照的一个时间戳，代表了该快照的历史时间点。
六、关于分层的架构和数据集市
数据集市可以作为展示层的一个模型集合。在展示层，数据理论上应当是维度化的建模，汇总表和支持报表的展现数据表应该是非规范化的、可以冗余的。很多lookup值应当用易读易理解的文本简写存储，而不是存放ID值，减少join的复杂性。这种表的作用就是给用户看的，好用，方便。如果让用户自己join的话，肯能会得到不正确的统计值，因为join是有陷阱的。
作为细节数据层的数据表才是真正的数据仓库，这些表的模型是高度规范化的3NF集合。这些表结构很复杂，不易于阅读和理解。很多lookupvalue是ID值。
作为ODS的数据表就是源系统的一份拷贝，存放当前状态的快照。
七、关于数据仓库重构
仓库重构包括小改和大改。
小改即为持续重构，针对已经上线的表，如果发现其模型和物理实施不合理，应当尽早进行重构并修改相应的ETL流程。我个人极度支持持续重构。
大改就是推翻已有的数据模型，用新的技术和概念把整个数据仓库进行重构。这个需要很大的工作量。比如，已有系统拥有100张表，现在要重新定义关键表的PI，这些关键表被绝大多数的表引用外键，所以修改PI和PK讲涉及到其他很多表的重构，还包括其他表的ETL流程的改变。那么，我推荐重构过程作为一个项目来实施，在数据仓库里再开一个相同容量的数据库，分批地重构表到新的空数据库中直至所有表被重构完成。在此之前，老数据仓库继续运行着，然后试着让新数据仓库运行起来，进行QA工作后，把老系统的数据进行转换插入到新系统里（historical load）。然后新老系统同时运行一段时间，比如半年后，retire老系统。