数据仓库架构提前解决未来问题?

innovate511 20061207

今天MSN下了之后，happy兄给我的留言，就是说架构是否是解决需求变化和需求升级问题。

我想答案是肯定的，但还远远不够这些。那就是架构相当于提前解决了未来的问题，可能是5年，也可能是10年（当然10年之后不太好说，因为未来信息化变化太大，不敢肯定）。那么就包括了需求变化、新需求、数据源结构变化、数据源量和来源剧增、未来业务变化、未来BI需求的增加。

举例说明，某大型公司上EDW，刚开始的需求紧紧是看看销售和财务情况，分别是市场部、财务部和老总看，而BI需求仅仅是做报表，而该DW方案规划生命周期为8年。那么你可以仅仅靠以往经验搭建一个EDW，同时满足客户的报表需求，那没问题，数据量也能承受。

1年之后，客户要上OLAP，同时要看客户主题分析，数据源加入了客户中心和CRM系统，如果是DM式小架构，会感觉改变模型的吃力了......

2年后，要分析公司人力情况，比如销售人员业绩，还有多出多种产品主题分析，区域市场分析、公司投资主题分析，并加入数据挖掘。同时为了增加公司信息化，公司的销售人员和客服人员将使用到部分即席查询，数据源将更广泛，包括OA的非关系数据库，数据量激增，事实表开始很难ETL了，BI需求变"胖"后也越来越慢，快无法忍受了，需求变化和新需求开发不断，麻烦也不断。

可以想象，一般的"架构"维持3年就不错，8年就不要谈了。。。。就像happy兄说的，以前还可以跟客户解释，需求变化太多，系统承受不了。我想以后市场成熟后，这些理由客户是不会接受的，因为架构就是为了解决未来需求变化和新需求等新形势问题。

同时我感觉架构分为DW架构和BI架构，BI架构就是通常大家知道的行业解决方案，比如IBM的IIW保险解决方案，其实就是些主要BI模型，包括KPI。而DW架构是无形的，但在未来项目中的作用会越来越重要，因为项目生命周期要长，全靠DW架构，而BI的需求，BI的解决方案在每年的行业新形势下都会更新的，但DW架构要在现在考虑到未来5年甚至10年的BI需求，就没那么容易了。

goldenfish3 20061207

架构具备可扩展性，能够解决可预计的未来出现的问题。

从EDW架构的演变看，由点到点，演变到Hub&Spoke，再到中间的Hub扩充为DW，是需求在驱动，架构在适应。到目前，这种架构基本定型，已经验证了5－10年，未来5年似乎也不会有大变化。EDW架构的核心是让来源各异的数据在某个时间点上“对齐”以便使用，具体做法是把分散的数据Copy到一个集中的物理场点。这种架构受制于网络、机器性能，且仍因为对齐带来的时间延迟而不能完全满足用户实时访问的需求。未来如果EII技术、GRID计算等在基础网络、数据库、服务器等支持的情况下可以很方便的实现任意的、实时的数据集成，EDW这种物理集中于一点的架构也许会过时。

Qing 20061207

呵呵，架构能够满足多长时间的需求变化，我想确实得跟架构师的经验有关。如果客户提出一个架构要满足8年的需求变化，那他得确定能够找到这样的架构师啊。

想起若干年前，我第一次去架构一个数据仓库系统，很悲惨。首先对业务不甚了解的，可不知道他们会有什么变化，甚至是他们目前是什么样都搞不清楚。而对于数据仓库的技术，也大多是从书本上看到的理论，知其然不知其所以然。为了响应大师们的号召，即便不知其所以然，也是按图索骥。结果可想而知，那是一种不能贴合实际需要的架构，更不用谈能够满足未来的变化。

看吧，架构师要了解需求的变化，要了解技术的支撑手段。当然，这里的需求是泛指，不一定是指客户的业务需求，比如对于ETL架构师来说，他面临就是如何将数据从源整合到目标的需求，要快、要稳定、要自动、要高质量...

Innovate说，"一般的架构维持3年就不错，8年就不要谈了"，呵呵，如果让我来作架构，能够维持1年就不错了，因为俺只能看到1年的变化，能够看到8年的变化，那是不是神啊。就好像葛优说得，"我能看到这儿，泰勒能看到那儿，佛主能够看到......那边，这就是境界"。

innovate511 20061207

其实IBM CDW的架构宗旨就是为了满足未来需求的扩容，目前开始流行出现的什么并行数据仓库架构思想，其实这种思想在IBM 90年代提出的CDW就已经有这个意思了。至于是否能支撑8年的系统，我想我还是有发言权的，因为我曾经参加的那个项目是99年架构设计的，一直沿用到现在。当然也不是什么问题都没有，但是在这个架构的大环境下，数据源包容了尽量多的数据源，多种BI应用，多种部门和分公司的大量最终用户，给ETL带来了一定的挑战，所以对ETL开发和测试都有严密的要求。说个题外话，如果这么庞大的BI架构里，客户反复修改的需求和新需求很大程度依赖BI工具的话，这个系统早死了。

形象点讲，它的最大特点，就是EDW是面向数据的，整合数据后，由被称为CDW的启到了管道的作用，由它来细分业务层次和多维模型层次，同时达到统一的一致的，面向业务的Kimball式数据仓库，也就是理论上讲，无论你多大的EDW，都可以通过CDW来建设新的数据集市或者维度模型扩容。同时并行的数据仓库也解决了效率问题。前面有人提到过，两重DW架构是否会导致性能下降。我想这和对实际系统的理解有关系，因为以前我提到过，一是两种数据仓库功能分明，不能重复其功能，这里的多维数据仓库其实不是真正意义的数据仓库，因为它不保留太多历史数据，轻装上阵。而多维数据仓库中事实表除了按粒度分层次外，也按周期分层，同时按照功能也分层，减少单个ETL的负担。同时这种大型架构，一般不建议ETL大量采用存储过程等直接在数据库完成ETL的方案，而是用工具或者自行开发ETL严格按照把数据先抽取，再转换到文件，然后再加载到目标表，尽可能给数据库更多性能空间。

在项目启动后，每次新的需求升级的开发需要严格在测试环境处理好数据质量、效率等问题后再加载到正式环境，确保每次需求升级顺利进行，架构能延续其生命。

土包子 20061210

其实我一直不太明白架构到底是什么意思！
是数据存储的问题吗？业务数据的增长导致数据库存储的压力和性能的下降，如果是这样的问题需要通过数据库调优的方式来解决。
是业务需求的变动问题吗？业务需求的变动导致系统结构的不稳定，不停地对数据模型的修改，这个要靠项目启动前的需求范围来明确。
是ETL结构的问题吗？这个需要明确数据仓库的结构，ODS层，聚合层，集市层等等。
还是所有以上的问题。

innovate511 20061211

可以参考我的新主题，数据仓库和建筑业比较带来的思考。

数据仓库的架构设计是解决项目的整体问题，并不是解决业务需求问题，其中包括了对数据的整合思考，对业务的分解思考，还有数据效率的思考，还有对需求变化的思考。

很形象的比喻一下，一个建筑如果设计不合理，哪怕危险建筑，照样可以装修很豪华，解决客户的需求。但比如一个体育场能容纳4万人，但设计不合理。刚开始只有1万人的时候，建筑没问题，等有4万人的时候，可能过几个月就踏了。再比如，现在大城市流行多功能办公、休闲和家住的建筑，为什么能多功能？因为他的架构设计能满足各种功能的使用和扩充。

同理，我们的数据仓库架构搞好了，随便你BI怎么变化，客户数量的增加，只要在我预期范围内我都能很好地支持你。当然数据仓库和建筑业也不能同等对比，比如我们的系统过几年跑不动了，如果是因为数据量过大的话，你可以增加服务器，但建筑一旦设计好后，你就不能随便加什么东西来支撑了。

数据仓库架构并不是想象中把数据按照传说中的基础的ODS层，聚合层，集市层设计好就行了。比如以前经常讨论的，多维模型到底在哪里设计才行？从数据源到多维模型到底需不需要先整合数据，到底要多少中间层，到底模型设计中事实表和维表的设计是否要足够丰富，如何去丰富，到底把新需求带来的更多数据转换问题在后台处理了还是直接在BI工具处理，ETL架构也是一个单独的架构，BI架构也是一个单独的架构。

目前信息化发达的企业里，分成几层的架构。第一次是整体IT架构，设计者要考虑包括各个业务系统、IT管理/监控系统以及数据仓库系统的整体运作和网络、硬件构架；第二层是数据仓库架构；第三层是并行的业务架构、ETL架构、BI架构，第四层才是最接近项目实际的架构，就是具体某一个业务层、某一个逻辑层架构、某一个BI需求架构（如报表架构）。我想一般我们之所以感觉架构概念太空，因为我们都直接面向客户的需求，如何去满足客户当前的需求，而不是先考虑整体，再考虑如何细节地满足客户需求，而且一般都是把DW的模型、ETL、BI凑合在一起形成一种相对单纯的架构，而没觉得每个部分都可以细分设计，他们可以局部对立而又相互合作成为整体，最终成为一个系统的整体架构。所以多数设计者的整体设计思想都还停留在第四层设计思想上的。当然，老美被大公司聘请为做第一层架构设计者的，都是IT行业摸爬20年以上的设计精英，能设计第二层的一般也是工作10多年以上的人。所以也不能和他们比，我们工程经验还是太欠缺，但是可以考虑加快脚步追赶了。