DW架构.doc

浅析数据仓库架构作者：Jerome来源：/blog/user1/lastwood/index.html点击数： 2016时间：2008-2-29【摘要】目前来说， 数据仓库架构比较成熟并已经形成理论的主要有两个，一个是Corporate Information Factory，简称CIF，中文一般翻译为企业信息工厂，代表人物是Bill Inmon。另一个是Mutildimensional Architecture，简称MD，中文一般翻译为多维体系结目前来说， 数据仓库架构比较成熟并已经形成理论的主要有两个，一个是Corporate Information Factory，简称CIF，中文一般翻译为企业信息工厂，代表人物是Bill Inmon。另一个是Mutildimensional Architecture，简称MD，中文一般翻译为多维体系结构，代表人物是Ralph Kimball。企业信息工厂主要包括集成转换层（Integrated and Transformation Layer）、操作数据存储（Operational Data Store）、数据仓库（Enterprise Data Warehouse）、数据集市（Data Mart）、探索仓库（Exploration Warehouse）等部件。多维体系结构分为后台（Back Room）和前台（Front Room）两部分。后台主要负责数据准备工作，称为数据准备区（Staging Area），前台主要负责数据展示工作，称为数据集市（Data Mart）。而数据仓库是一个虚拟的部件，它指的是全部数据集市的集合。两个数据仓库架构各有优缺点，一种比较流行的做法是合用两种架构，即建立CIF的数据仓库和MD的数据集市。浅析企业信息工厂数据仓库领域里，有一种构建数据仓库的架构，叫Corporate Information Factory，中文一般翻译为“企业信息工厂”。企业信息工厂的创始人是数据仓库之父Inmon。企业信息工厂主要包括集成转换层（I&T）、操作数据存储（ODS）、数据仓库（EDW）、数据集市（DM）、探索仓库（EW）等部件。这些部件有机的结合在一起，为企业提供信息服务。集成转换层的目的是将来自操作型源系统的数据集成转换到数据仓库中，它通常由一组程序组成，而其它部件如数据仓库和数据集市等则主要由数据组成。 当业务数据来源多，业务复杂时，集成转换层会建立一些临时表，为数据处理提供方便。这时，集成转换层包括程序和数据，也称数据准备区（Data Staging Area）。通常中等规模及以上的数据仓库系统都会建立数据准备区。操作数据存储（ODS）是建立在数据准备区和数据仓库之间的一个部件。用来满足企业集成的、综合的操作型处理需要。例如，出尽可能实时的集成的操作报表等需求。一般，也称操作数据存储是用来满足企业战术决策的需要。操作数据存储是个可选的部件。数据仓库是企业信息工厂的核心部件，用来保存整个企业的数据。一般，也称数据仓库是用来满足企业战略决策的需要。数据仓库的数据来自数据准备区和操作数据存储。数据集市是为了满足企业特定部门的分析需求而专门建立的数据的集合。数据集市的数据来源是数据仓库。企业信息工厂中的数据集市一般来说是非规范化的、定制的和汇总的。而多维体系架构中的数据集市分为两种，分别是原子数据集市和聚集数据集市。一般来说，企业信息工厂中的数据集市相当于多维体系架构中的聚集数据集市。探索仓库或 数据挖掘仓库的建立主要是为了解决大型查询，提高数据仓库的效率。当有探索或挖掘需求时，会从数据仓库导出一部分数据提供给他们操作。企业信息工厂中的数据流向一般是从源系统到数据准备区到操作数据存储到数据仓库到数据集市。当分析人员在数据仓库或数据集市中得出分析结论后，会有信息的回流。这种信息回流有可能是物理数据的回流，也可能是直接改变业务部门的策略，总之，要将分析的结果应用起来。通过这种信息的回流，企业信息工厂的不同部件可以不断的相互调整，最终找到一种平衡。这也是称为企业信息工厂的原因。浅析多维体系结构数据仓库领域里，有一种构建数据仓库的架构，叫Multidimensional Architecture（MD），中文一般翻译为“多维体系结构”，也称为“总线架构”（Bus Architecture）。多维体系结构的创始人是数据仓库领域中最有实践经验的Kimball博士。多维体系结构主要包括后台（Back Room）和前台（Front Room）两部分。后台也称为数据准备区（Staging Area），是MD架构的最为核心的部件。在后台，是一致性维度的产生、保存和分发的场所。同时，代理键也在后台产生。前台是MD架构对外的接口，包括两种主要的数据集市，一种是原子数据集市，另一种是聚集数据集市。原子数据集市保存着最低粒度的细节数据，数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。在多维体系结构中，所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中，也可以分散在不同的机器上，而所有这些数据集市的集合组成的分布式的数据仓库。浅谈数据中心的数据存储区域划分来源：机房360 作者：林小村 更新时间：2010/11/14 1:22:44 摘要：根据数据中心数据库规划，数据中心的数据存储由交换数据临时存储区、操作型数据存储区、数据仓库、数据集市4个区域构成。 根据数据中心数据库规划，数据中心的数据存储由交换数据临时存储区、操作型数据存储区、数据仓库、数据集市4个区域构成，具体建设的时候需要根据它们各自的特点分别进行设计，数据中心数据存储区域结构如图6.18所示。 1 交换数据临时存储区 交换数据临时存储区（ExchangeDataStore，EDS）是用来保证数据交换过程中安全隔离和临时存储的存储区，其数据结构应与接入的应用系统保持一致。 2 操作型数据存储区 操作型数据存储区（OperationalDataStore，ODS）存放集成的、可更新的、近实时的业务数据。ODS主要用于异构业务数据源的明细数据整合后、进入数据仓库前的存储，并提供企业面向业务的、近实时的统一数据视图，支持企业全局业务数据的近实时查询与分析。 ODS是业务系统间公共和共享数据的存储区，是业务系统与数据仓库间的数据迁移的缓存区，是支持数据中心应用中实时查询数据的存储区，是日常业务决策支持的数据存储区。ODS数据模型依据数据模型构建，基于主题域组织，其主题域划分和核心数据实体与企业数据模型相同。 3 数据仓库 数据仓库（DataWarehouse,DW）存放面向主题的、集成的、相对稳定的、反应历史变化的数据。数据仓库统一存放与管理经整合后、具体分析价值的企业历史数据，支持基于大量历史数据的企业决策分析。 数据仓库中存储从业务系统中到处的用于决策和挖掘的企业数据，也到处操作型数据的轻度汇总数据。数据仓库的数据一部分通过ODS导入，一部分通过业务系统直接导入。数据仓库的数据模型按照主题组织，主题域划分与数据模型相同，数据模型依据数据模型构建。 4 数据集市 数据集市（DataMarkets，DM）是以数据仓库数据为唯一数据源、面向特定分析应用、俺一定方式重新组织的数据集合，是数据仓库的子集。 数据集市基于数据仓库创建，用于不同业务部门的需求和不同分析应用的分析数据的存储，数据集市的数据模型与企业数据模型一直，用于描述企业业务部门、企业综合分析以及高级管理人员分析所需的数据。数据集市模型也按主题组织，但其主题域划分与数据模型不同，数据集市的主题是基于企业的不同部门、不同人员的分析需求而组织的。 5 数据交换流程 数据中心内的数据交换实现方式如下： （1） 从EDS到ODS通过数据复制或者ETL工具实现。 （2） 从ODS到数据仓库通过ETL工具实现。 （3） 从数据仓库到数据集市通过ETL工具实现。 6 区域功能特点 ODS、数据仓库和数据集市3个区域的业务功能、数据规模、数据源、主题范围、时效性、更新频率、集中度、用途、使用者等功能特点见表6.5。 责任编辑：kellyODS与数据仓库的区别 2011-08-03 17:42 8人阅读 评论(0) 收藏 举报 数据仓库是面向主题的、集成的、随时间变化的、非易失的、用于进行战略型决策的数据集合。 ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。操作型数据存储（Operational Data Store，ODS）用于战术型决策，而数据仓库支持战略型决策。操作型数据存储在某些方面具有类似于数据仓库的特点，但在另一些方面又显著不同于数据仓库：l 像数据仓库那样，是面向主题的。l 像数据仓库那样，其数据是完全集成的。l 数据是当前的或其数据处理技术允许这样，这与数据仓库存储历史数据的性质显著不同。ODS具有最少的历史数据，而尽可能接近实时地展示实体的状态。l 数据是易失的和可更新的，这是与静态数据仓库的一个很大的区别。ODS就如同一个事务处理系统，当新的数据流进ODS时，受其影响的字段被新信息覆盖或更新。除审计数据外，不保留其他的历史内容。l 数据几乎完全是细节数据，仅具有少量的动态聚集或汇总数据。通常将ODS设计成包含事务级的数据，即包含该主题域最低级别的数据。l 在数据仓库中，几乎没有针对其本身的报表（报表均放到数据集市中完成）；与此不同，在ODS中，业务用户频繁地直接访问ODS。数据仓库架构设计 收藏数据仓库架构，是IT架构的一个分支，随着数据在企业的核心作用的增强，数据仓库的架构日益重要。数据仓库架构由于其技术选择非常广泛，看上去复杂，不过背后有一套比较稳定的思路，这也是数据仓库架构设计的一个要点，稳定中蕴含变化，变化中蕴含稳定。总体来说，数据仓库架构分成两大块，一是硬件架构，二是软件架构。硬软架构又可以分成封闭式和开放式。封闭式硬件架构代表厂商有teradata，其硬件是专属的，必须使用特殊的硬件才能运行。开放式硬件架构的代表有oracle，可以运行在各种硬件上，不过开放和封闭之间的界限也逐步的融合，oracle也开始打包hp的专属硬件来推广其dw的方案，而teradata也开始用基于suse的os可运行的硬件上提供其dw产品。封闭式硬件好处是开箱即用，经过厂商的严格测试，保障性比较高，开放式硬件则需要企业具备很强大的技术实力，能够有一支具备硬件，存储，操作系统综合知识和能力的团队，在组合成一套可以运行dw软件的基础平台，并且在发现问题的时候要能很快速的定位问题的原因并解决。数据仓库的软件架构选择更加丰富。从数据库软件，etl软件，展现软件，数据挖掘软件，每一种类型里面都具备非常多的选择。这些软件的选择是架构设计的一部分，架构设计的重要核心一部分是综合这些软件的一套思路，在一套dw架构设计的思路下，软件可以很灵活的进行选择。数据仓库架构设计的出发点是什么？需要解决哪些问题？所谓架构，好比大厦，好的设计大厦具备很好的抗震，抗自然灾害能力，框架式建筑能够重新打造内部结构。而数据仓库架构也是解决类似的问题，其实很多数据仓库在开始起步的时候是不谈架构的，本来就是小作坊，无须谈到架构这个高度。但是如果要考虑建设一个能支撑容纳5-10年业务的时候，架构的好坏就体现出来了。一个好的架构其实就是经验的沉淀物，架构是在理清楚数据仓库的基本的任务，并能让这些任务高效低成本的实现。举个简单的例子来理解一下，数据仓库中同步数据和汇总数据的依赖模块非常之多，如果其中若干模块出错，该如何处理？如果架构设计不好，就会陷入维护人员不断的寻找问题，清理现场，手工调度等问题出现，场面应该十分混乱。好的架构首先是模块化，模块内部具备自动清理现场功能，而模块间则具备自动断点重新启动功能，在模块常规出错的时候，能依靠系统自助解决问题，同时能把处理问题的过程记录下来供后续分析。这样的架构能够极大的提升维护的效率，减轻维护人员的维护量。整个dw系统也具备了抗异常能力。数据仓库的架构设计，有时候一个好的架构设计的出发点往往来源于当前系统的缺陷。如何面对当前系统的缺陷是架构能否持续发展的一个关键点之一。业界存在很多对商业，开源etl工具的评测，那么这些评测要点应该从哪些方面进行才能甄别出适合企业的工具呢？1.成本。成本永远是企业关心的一个核心问题，特别在如今经济寒冬，更是如此。2.效率。能否高效的处理海量的数据是一个基础要素，搞数据仓库的都知道，数据量永远是一个经常被拿出来讨论的话题。3.线性扩展。能支持线性扩展的系统在计划支撑多年的系统中特别重要，可以非常方便的做出年度预算。4.协同工作。解决多人协同开发问题。5.调度。能否很方便的一目了然的看到整体调度，站在一个非常高的高度来管理各种数据流。6.兼容性。能否兼容各种异构数据。7.准确的监控系统。8.高效的开发框架。数据仓库的物理架构，包含硬件物理架构和软件物理架构。硬件物理架构包含集中式和分布式2中，在企业里面都有运用。集中式硬件物理架构偏向于使用非常power的小型机或者大型机，非常高端的海量存储，管理简单，在不计投入的情况下性能也能满足企业需求。分布式硬件物理架构目前非常流行，特征是采用价格低廉的中低端机器组成计算集群，不同的技术驱动下，在share nothing的架构下可以采用本机的硬盘， 在share everything的架构下偏向使用集中存储，分布式集群在网络上的要求比较高，扩展性比较好，配合好的软件可以达到线性扩展的要求。软件物理架构主要特征区别就是行存储和列存储。这个也是曾经很多厂商津津乐道的地方，根据需求的不同，2种方式可以灵活采用。大部分db软件都是采用行存储，而列存储的特征在于高效的单列值压缩，在选择列比较少的时候需要io要求很低，速度很快，不过行存储的db目前在压缩效率上也在迅速提升，大部分需求还是选择行数据进行观察，行存储也更加便于表的按记录拆分进行并行化。数据仓库架构设计系统（四）2 comments一月 20th, 2009 | by 云铮 in dw架构 , 所有数据仓库的物理架构，包含硬件物理架构和软件物理架构。硬件物理架构包含集中式和分布式2中，在企业里面都有运用。集中式硬件物理架构偏向于使用非常power的小型机或者大型机，非常高端的海量存储，管理简单，在不计投入的情况下性能也能满足企业需求。分布式硬件物理架构目前非常流行，特征是采用价格低廉的中低端机器组成计算集群，不同的技术驱动下，在share nothing的架构下可以采用本机的硬盘， 在share everything的架构下偏向使用集中存储，分布式集群在网络上的要求比较高，扩展性比较好，配合好的软件可以达到线性扩展的要求。软件物理架构主要特征区别就是行存储和列存储。这个也是曾经很多厂商津津乐道的地方，根据需求的不同，2种方式可以灵活采用。大部分db软件都是采用行存储，而列存储的特征在于高效的单列值压缩，在选择列比较少的时候需要io要求很低，速度很快，不过行存储的db目前在压缩效率上也在迅速提升，大部分需求还是选择行数据进行观察，行存储也更加便于表的按记录拆分进行并行化。思维DW架构设计中的数据流架构规划 博客分类：技术文章 数据仓库的架构看起来天马行空。其中定义的集中架构模式已被无数人无数项目验证n次。数据仓库中心数据流部分或者也称之为数据架构将是把DW结构与项目的实时，企业的运作规则紧紧地绑定到了一起。细想DW的数据方向可以从数据流架构、数据管理架构、企业的业务数据架构、数据安全、数据质量架构来分别阐述DW中数据流的表现。我们来看第一个部分数据流的架构，从设计上来看应该是设计数据流需要多少个层次，每个层次的数据含义或数据流向要有适合自己的特性、以后的扩展性。拆分DW架构，其中的ODS是否只是为数据仓库做数据准备？还是是否按照业务主线穿起支持统一视图，或是否为了方便屏蔽Source 源的异构性，或为某个企业统一维度、是否按照主题划分、或考虑是为考虑到超大交易数据量进行阶梯预先处理。拿集中式的架构方式中的EDW(EDS)是否需要保持最小粒度或是否计划和条件的去建设范式模式(3nf/准3nf或只做到2nf）、是否采用多个数据集市、多个的数据集市是否全部需要统一维度建模需要。数据集市到底要解答哪些问题或满足那些BI功能。每部分的不同问题都决定了数据流架构需要如何设计，同时也决定一个企业上数据仓库的演进步骤等因素。看到数据这个词首先会想到存了多少数据，换句话说考虑历史存储方式，需要根据数据的价值和使用频率。这里倒是可以参考DW2.0理论定义。 数据是要保存的粒度，可以当成是存储方式的角度、从粒度上讲有维度模型的DW需要最小粒度。比较独立的时间维度在数据集市上到底是需要多大的粒度。从应用维度表与事实表的联系密度是多少。需要多少的维度信息放到事实表中。是否为了牺牲存储来形成大的宽表，方便报表或数据挖掘。数据仓库架构提前解决未来问题?innovate511 20061207 v,O&UrZ 今天MSN下了之后，happy兄给我的留言，就是说架构是否是解决需求变化和需求升级问题。jZgnt 我想答案是肯定的，但还远远不够这些。那就是架构相当于提前解决了未来的问题，可能是5年，也可能是10年（当然10年之后不太好说，因为未来信息化变化太大，不敢肯定）。那么就包括了需求变化、新需求、数据源结构变化、数据源量和来源剧增、未来业务变化、未来BI需求的增加。Xv;ZAa 举例说明，某大型公司上EDW，刚开始的需求紧紧是看看销售和财务情况，分别是市场部、财务部和老总看，而BI需求仅仅是做报表，而该DW方案规划生命周期为8年。那么你可以仅仅靠以往经验搭建一个EDW，同时满足客户的报表需求，那没问题，数据量也能承受。xo/k 1年之后，客户要上OLAP，同时要看客户主题分析，数据源加入了客户中心和CRM系统，如果是DM式小架构，会感觉改变模型的吃力了./t2 nr Qing 20061207 3B+e 呵呵，架构能够满足多长时间的需求变化，我想确实得跟架构师的经验有关。如果客户提出一个架构要满足8年的需求变化，那他得确定能够找到这样的架构师啊。LWR &(p.% 想起若干年前，我第一次去架构一个数据仓库系统，很悲惨。首先对业务不甚了解的，可不知道他们会有什么变化，甚至是他们目前是什么样都搞不清楚。而对于数据仓库的技术，也大多是从书本上看到的理论，知其然不知其所以然。为了响应大师们的号召，即便不知其所以然，也是按图索骥。结果可想而知，那是一种不能贴合实际需要的架构，更不用谈能够满足未来的变化。K:trV; 看吧，架构师要了解需求的变化，要了解技术的支撑手段。当然，这里的需求是泛指，不一定是指客户的业务需求，比如对于ETL架构师来说，他面临就是如何将数据从源整合到目标的需求，要快、要稳定、要自动、要高质量.m,tdVo. innovate511 20061207 .sN?5y 其实IBM CDW的架构宗旨就是为了满足未来需求的扩容，目前开始流行出现的什么并行数据仓库架构思想，其实这种思想在IBM 90年代提出的CDW就已经有这个意思了。至于是否能支撑8年的系统，我想我还是有发言权的，因为我曾经参加的那个项目是99年架构设计的，一直沿用到现在。当然也不是什么问题都没有，但是在这个架构的大环境下，数据源包容了尽量多的数据源，多种BI应用，多种部门和分公司的大量最终用户，给ETL带来了一定的挑战，所以对ETL开发和测试都有严密的要求。说个题外话，如果这么庞大的BI架构里，客户反复修改的需求和新需求很大程度依赖BI工具的话，这个系统早死了。:9Q/8! 在项目启动后，每次新的需求升级的开发需要严格在测试环境处理好数据质量、效率等问题后再加载到正式环境，确保每次需求升级顺利进行，架构能延续其生命。 $CVp/En 0q ) 土包子 20061210 + dIs 其实我一直不太明白架构到底是什么意思！ ; i q 是数据存储的问题吗？业务数据的增长导致数据库存储的压力和性能的下降，如果是这样的问题需要通过数据库调优的方式来解决。 Z-V%lRQ=b 是业务需求的变动问题吗？业务需求的变动导致系统结构的不稳定，不停地对数据模型的修改，这个要靠项目启动前的需求范围来明确。 lt*y.%b 是ETL结构的问题吗？这个需要明确数据仓库的结构，ODS层，聚合层，集市层等等。 +u)$o 还是所有以上的问题。jv L4 可以参考我的新主题，数据仓库和建筑业比较带来的思考。BGj Ta.& 数据仓库的架构设计是解决项目的整体问题，并不是解决业务需求问题，其中包括了对数据的整合思考，对业务的分解思考，还有数据效率的思考，还有对需求变化的思考。N* - Z Jv 很形象的比喻一下，一个建筑如果设计不合理，哪怕危险建筑，照样可以装修很豪华，解决客户的需求。但比如一个体育场能容纳4万人，但设计不合理。刚开始只有 1万人的时候，建筑没问题，等有4万人的时候，可能过几个月就踏了。再比如，现在大城市流行多功能办公、休闲和家住的建筑，为什么能多功能？因为他的架构设计能满足各种功能的使用和扩充。c W%O- 同理，我们的数据仓库架构搞好了，随便你BI 怎么变化，客户数量的增加，只要在我预期范围内我都能很好地支持你。当然数据仓库和建筑业也不能同等对比，比如我们的系统过几年跑不动了，如果是因为数据量过大的话，你可以增加服务器，但建筑一旦设计好后，你就不能随便加什么东西来支撑了。e-RJ! 数据仓库架构并不是想象中把数据按照传说中的基础的ODS层，聚合层，集市层设计好就行了。比如以前经常讨论的，多维模型到底在哪里设计才行？从数据源到多维模型到底需不需要先整合数据，到底要多少中间层，到底模型设计中事实表和维表的设计是否要足够丰富，如何去丰富，到底把新需求带来的更多数据转换问题在后台处理了还是直接在BI工具处理，ETL架构也是一个单独的架构，BI架构也是一个单独的架构。qa?y lRkA 目前信息化发达的企业里，分成几层的架构。第一次是整体IT架构，设计者要考虑包括各个业务系统、IT管理/监控系统以及数据仓库系统的整体运作和网络、硬件构架；第二层是数据仓库架构；第三层是并行的业务架构、ETL架构、BI架构，第四层才是最接近项目实际的架构，就是具体某一个业务层、某一个逻辑层架构、某一个BI需求架构（如报表架构）。我想一般我们之所以感觉架构概念太空，因为我们都直接面向客户的需求，如何去满足客户当前的需求，而不是先考虑整体，再考虑如何细节地满足客户需求，而且一般都是把DW的模型、ETL、BI凑合在一起形成一种相对单纯的架构，而没觉得每个部分都可以细分设计，他们可以局部对立而又相互合作成为整体，最终成为一个系统的整体架构。所以多数设计者的整体设计思想都还停留在第四层设计思想上的。当然，老美被大公司聘请为做第一层架构设计者的，都是IT行业摸爬20年以上的设计精英，能设计第二层的一般也是工作10多年以上的人。所以也不能和他们比，我们工程经验还是太欠缺，但是可以考虑加快脚步追赶了。什么是架构？为什么要架构？怎样去架构？ 2010-04-09 15:20:20| 分类： 默认分类 | 标签：|字号大中小 订阅 the development of a Technology Architecture/architecture/togaf8-doc/arch/chap10.html 何谓技术架构？ 1。首先，基于网络平台的技术应用，应该是大架构师。 应该如何应用，如何部署，是技术架构的大架子。 2。其次，基于操作系统的技术平台，是架构的第二层功能。 采用什么的操作系统，建立什么样的安全机制，是技术架构的小身体。 3。第三，基于开发工具技术的选择，是技术架构的第三层职能。 是基于J2EE，还是基于。NET，是获得技术支持和技术研究、发展的方向。 4。第四，开发什么的组件，组件构架是技术架构的第四层职能。 应用软件，除了USE-CASE之外，还要公用component设计。 要设计良好的架构，必须做到关注点分离，这样可以产生高内聚、低耦合的系统，这是美丽架构的终极原则。 每个人可能都有自己对架构的定义。我比较喜欢的定义是：“架构是系统的组成部件及其之间的相互关系。”根据观察者的视角不同，架构又可以分为业务架构和技术架构。一般来说， 功能性需求会对业务架构产生影响， 而非功能性需求会对技术架构产生影响。例如：“注册用户可以向自己的相册上传图片，并与好友分享”。这是一项功能性需求。它告诉了我们在系统的业务架构中，会出现“注册用户”“相册”、“图片”、“好友”等组成部件，它们之间存在着相互关系。而“系统可以支持10万并发用户，并在需要时可以方便地伸缩，扩展到支持100万到1000万的并发用户”，则是一项非功能性需求。它告诉了我们系统在性能、负载、吞吐量、可伸缩性方面的特性，目标系统的架构必须对这些特性提供支持。架构体现的是对复杂系统的分解设计。而如何进行分解，则是软件设计领域永恒的话题。实际上，架构体现的是关注点分离的原则和方法。经典的三层架构，由展现层、业务逻辑层和持久层构成；其中体现了我们对用户界面、业务逻辑和数据持久的关注点分离。这种架构从命令行时代的软件就开始有了，直到最新的AJAX 加RESTful的Web 应用架构中仍然可以看到它，因为这种关注点的分离在这些应用中是必要的。我们可以在Web 应用中不采用三层架构，也就是不进行这种分离。我们可以在JSP/ASP/PHP中混合用户界面、业务逻辑和数据持久层。但是这样的代码是难以维护的，难以适应大规模项目开发，难以适应将来的变化。关注点不分离的代码为阅读和理解制造了更多的障碍。用户界面、业务逻辑和数据持久三者的分离，让它们能够相对独立地进行变化，比如实现新的用户界面方式、改变业务逻辑和采用新的数据持久机制。依赖注入的架构方式因Spring、Guice 等框架而被广大Java 程序员所熟悉，进而扩展到.NET等其他语言和平台，它也体现了关注点的分离。首先，依赖注入体现了“做什么”和“怎么做”的关注点分离。学过C语言的程序员都知道，这种关注点的分离有着悠久的历史，它表现为.h文件和.c文件，一个规定函数原型，一个规定函数实现。这种关注点分离后来还在面向对象的设计中表现为“针对接口设计”，于是我们在依赖注入的架构方式中，看到了许多的接口，以及接口的不同实现。组件的使用者关注组件做什么，组件的实现者关注组件怎么做。其次，依赖注入体现了对实例生命周期（特别是实例创建）和组件装配的关注点分离。我们可以集中指定对象创建的方式，方便灵活地改变系统的装配方式。通过这样的关注点分离，依赖注入的架构让系统变得更灵活，让组件的实例化和组装方式集中在系统的一个局部来确定，而不是分散在系统各处。彩色UML建模一书中提出了4种领域无关的架构型，体现了业务流程、业务事件、参与者角色、具体参与者、分类分组的关注点分离。它研究的是业务架构，告诉我们如何设计一些组件来体现业务逻辑。以ATM机取款为例，它包含一个业务流程，由身份认证、取款、打印凭据等事件组成。单独来看取款这个事件，彩色UML方法会在模型中体现出“取款（时刻/ 时段）”、“账户（物品）”、“信用卡（物品）”、“ATM机/ 取款柜台（地点）”等组件。这样的关注点分离，使得这一组取款组件可以从业务流程中独立出来，所以它也可以参与其他业务流程，如柜台取款。REST是一种Web应用架构风格，它的主要特点包括： 资源是由URI来指定。 对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。 通过操作资源的表形来操作资源。 可以通过内容协商机制来取得同一资源的不同物理表现形式，可以是XML、HTML、JSON或其他格式，这取决于请求者是机器还是人，是消费eb服务的客户软件还是Web浏览器。在REST架构风格中，体现了对资源命名、请求处理和资源物理表现形式的关注点分离。由于实现了这些关注点分离，REST有下面这些好处： 可以利用缓存Cache来提高响应速度。 通讯本身的无状态性可以让不同服务器处理一系列请求中的不同请求，提高服务器的扩展性。 浏览器即可作为客户端，简化软件需求。 相对与其他叠加在HTTP协议之上的机制，REST的软件依赖性更小。 不需要额外的资源发现机制。 在软件技术演进中的长期的兼容性更好。AOP（面向方面编程）也是关注点分离思想的一种体现。记日志是说明AOP 思想的一个常用例子。当我们在业务代码中嵌入很多日志代码时，业务代码的可读性就下降了，因为业务逻辑和日志是两个不同的关注点。通过AOP技术来分离这两个关注点，就提高了代码的可读性和可维护性。Ivar Jacobson在他的Aspect-Oriented Software Developmentwith Use Case一书中， 提出了AOP思想与用例技术结合的方法。例如，在“用户利用电话系统通话”和“对用户的通话计费”这两个用例中，我们的关注点是不同的。但是如果不采用AOP的方法，实现代码中必然将这两个关注点的代码编织在一起。如果对一个业务过程有许多不同的关注点，代码就变得复杂而难读了。于是Ivar提出，分离两个关注点， 再利用AOP的技术将它们最终编织在一起。这样，我们就能单独面对一个方面的关注点。AOP技术用一种特别的方式实现了关注点分离，它的好处是明显的，但也有一些不足。比如对于编织后的系统除错，会因为执行流的跳转而变得比较复杂。这时候，我们需要通过一些其他技术来弥补，例如回归测试。我们在实现了“用户利用电话系统通话”后，写一个回归测试将工作成果确定下来。在我们实现之后的业务关注点时，经常跑这个回归测试，确保不会因为新的编织而在系统中引入缺陷。EJB技术虽然在早期受到了一些诟病，但是它的架构设计总体上仍然是非常漂亮的。EJB体现了分布式计算、持久、实例化、缓冲、事务、安全性等关注点的分离。Google提出的MapReduce技术是一种新的集群计算思想， 它体现了分布式并行计算的关注点分离。Apache