所谓的数据仓库架构，我也是第一次听说，改改一些概念，干脆一起来分享一下吧，没准还能成为行业标准，呵呵！该架构主要分为四层结构体系：
> ODS层
主要负责采集业务系统并保存一定期限内的相关业务数据。当然也可以满足用户对明细数据的查询要求，姑且也可以算作明细数据仓库。
> 数据仓库层
将ODS层经过质量检查、清洗、转换后，形成符合质量要求的公共数据中心。实际上与ODS层差别不大，都是建立以ER为中心的数据关系，方便以后的数据的聚合。
> 明细数据集市层即前面所说的事实层
按主题及KPI指标对数据仓库层数据进行进一步转换，将指标与维度组成数据集市。这是OLAP的数据基础。
> 聚合数据集市层即OLAP
在明细数据集市层的基础上，提供基于联机分析处理(OLAP)引擎的多维分析能力，解决联机分析功能和决策支持要求。
> 数据展现层
按照用户报表要求，提供用户报表界面及预警分发机制。
其中前3层都是属于ETL层的，问题是层次出来了我的疑问也出来了，都是属于那种别人不操心我瞎操心的事。毕竟算是搞数据库出身的(搞过一些索引和简单的SQL调优)，最关心的还是性能问题。数据仓库是企业级的数据中心，每天上G的数据的企业不在少数，那么多的层次，使用工具能抽的完数据吗？说实话我实在不信任ETL工具，总感觉他没我写的SQL语句效率高；即使抽的完数据，那么多的层次转换能处理的完吗；即使处理完，如果万一一个环节出现问题，能回退或重新处理吗；处理完后那OLAP该怎么调度啊；数据质量（清洗转换）到底在哪个环节处理；数据质量到底包括哪些东西(除了主外键缺失和NULL值)，兄弟比较愚笨，一直想不明白；不合质量要求的数据如何处理；入库的数据在业务库发生更改怎么办；业务数据没有时间戳怎么办；数据核对和校验工作如何进行；不管工具也好代码也好，到底有没有通用的处理流程(比如维度数据处理，原始业务数据抽取，事实表日结处理)数据库简单吗；还有就是到现在也没搞到合适的需求设计文档的模板(如果哪位兄弟有可以帮忙提供一下)。这一系列问题我是横竖想不明白的，反正我的问题总是比别人多，学东西总比别人慢，还是人年龄大了真的退化了。
关于数据仓库的逐步学习，发现不懂得越来越多了，希望大家多提点提点，数据挖掘我是一窍不通，高等数学没学好，算法自然也学不会，只怪我高中文科出身，信息管理系的文凭拿
的还是文学学士，简直没脸见人了；业务建模和需求分析也不是我擅长的，因此我只能关心纯技术的东西，可是ETL工具把人写代码的权力也剥夺了，因此我只能关心一些大的方面了，这难道就是所谓的架构吗？不知道，哎，学吧！