EDW架构.docx

数据仓库架构数据仓库架构，是IT架构的一个分支，随着数据在企业的核心作用的增强，数据仓库的架构日益重要。数据仓库架构由于其技术选择非常广泛，看上去复杂，不过背后有一套比较稳定的思路，这也是数据仓库架构设计的一个要点，稳定中蕴含变化，变化中蕴含稳定。总体来说，数据仓库架构分成两大块，一是硬件架构，二是软件架构。硬软架构又可以分成封闭式和开放式。封闭式硬件架构代表厂商有teradata，其硬件是专属的，必须使用特殊的硬件才能运行。开放式硬件架构的代表有oracle，可以运行在各种硬件上，不过开放和封闭之间的界限也逐步的融合，oracle也开始打包hp的专属硬件来推广其dw的方案，而teradata也开始用基于suse的os可运行的硬件上提供其dw产品。封闭式硬件好处是开箱即用，经过厂商的严格测试，保障性比较高，开放式硬件则需要企业具备很强大的技术实力，能够有一支具备硬件，存储，操作系统综合知识和能力的团队，在组合成一套可以运行dw软件的基础平台，并且在发现问题的时候要能很快速的定位问题的原因并解决。数据仓库的软件架构选择更加丰富。从数据库软件，etl软件，展现软件，数据挖掘软件，每一种类型里面都具备非常多的选择。这些软件的选择是架构设计的一部分，架构设计的重要核心一部分是综合这些软件的一套思路，在一套dw架构设计的思路下，软件可以很灵活的进行选择。1 出发点？需要解决哪些问题？所谓架构，好比大厦，好的设计大厦具备很好的抗震，抗自然灾害能力，框架式建筑能够重新打造内部结构。而数据仓库架构也是解决类似的问题，其实很多数据仓库在开始起步的时候是不谈架构的，本来就是小作坊，无须谈到架构这个高度。但是如果要考虑建设一个能支撑容纳5-10年业务的时候，架构的好坏就体现出来了。一个好的架构其实就是经验的沉淀物，架构是在理清楚数据仓库的基本的任务，并能让这些任务高效低成本的实现。举个简单的例子来理解一下，数据仓库中同步数据和汇总数据的依赖模块非常之多，如果其中若干模块出错，该如何处理？如果架构设计不好，就会陷入维护人员不断的寻找问题，清理现场，手工调度等问题出现，场面应该十分混乱。好的架构首先是模块化，模块内部具备自动清理现场功能，而模块间则具备自动断点重新启动功能，在模块常规出错的时候，能依靠系统自助解决问题，同时能把处理问题的过程记录下来供后续分析。这样的架构能够极大的提升维护的效率，减轻维护人员的维护量。整个dw系统也具备了抗异常能力。2 工具选择数据仓库的架构设计，有时候一个好的架构设计的出发点往往来源于当前系统的缺陷。如何面对当前系统的缺陷是架构能否持续发展的一个关键点之一。业界存在很多对商业，开源etl工具的评测，那么这些评测要点应该从哪些方面进行才能甄别出适合企业的工具呢？1) 成本：成本永远是企业关心的一个核心问题，特别在如今经济寒冬，更是如此。2) 效率：能否高效的处理海量的数据是一个基础要素，搞数据仓库的都知道，数据量永远是一个经常被拿出来讨论的话题。3) 线性扩展：能支持线性扩展的系统在计划支撑多年的系统中特别重要，可以非常方便的做出年度预算。4) 协同工作：解决多人协同开发问题。5) 调度：能否很方便的一目了然的看到整体调度，站在一个非常高的高度来管理各种数据流。6) 兼容性：能否兼容各种异构数据。7) 准确的监控系统。8) 高效的开发框架。3 物理架构数据仓库的物理架构，包含硬件物理架构和软件物理架构。硬件物理架构包含集中式和分布式中，在企业里面都有运用。集中式硬件物理架构偏向于使用非常power的小型机或者大型机，非常高端的海量存储，管理简单，在不计投入的情况下性能也能满足企业需求。分布式硬件物理架构目前非常流行，特征是采用价格低廉的中低端机器组成计算集群，不同的技术驱动下，在share nothing的架构下可以采用本机的硬盘， 在share everything的架构下偏向使用集中存储，分布式集群在网络上的要求比较高，扩展性比较好，配合好的软件可以达到线性扩展的要求。软件物理架构主要特征区别就是行存储和列存储。这个也是曾经很多厂商津津乐道的地方，根据需求的不同，2种方式可以灵活采用。大部分DB软件都是采用行存储，而列存储的特征在于高效的单列值压缩，在选择列比较少的时候需要IO要求很低，速度很快，不过行存储的DB目前在压缩效率上也在迅速提升，大部分需求还是选择行数据进行观察，行存储也更加便于表的按记录拆分进行并行化。4 模块BI系统（或者说数据仓库系统）也同样需要架构，它作为一种软件系统，是符合一般架构原则的。首先，我们来看看架构设计中包括那些内容。 架构的重点是描述系统的结构，以及它们之间的关联、交互接口。BI系统可以划分成业务模型、元数据、数据质量、接口平台、报表集市、指标库等若干模块。可以看出，在这里，这些模块的命名都是静态的名词，而不是动词（例如业务建模、数据质量管理等）。之所以如此，是因为这是在描述系统的结构而非功能。具体来讲，业务模型是存放业务数据的结构，可以再往下细分，并有不同的分层方法。例如可以分成ODS、EDW、DM等层，也有的会根据业务复杂度或数据量考虑，舍弃ODS层。业务模型是支撑业务分析需求的，例如报表、仪表盘、OLAP、专题应用等。元数据为整个系统数据的形态和数据流动的过程起到支撑作用，也就是说，数据从源头开始，到最终用户眼前，其来龙去脉，每个环节的状态都需要掌握。还有人将它比喻成模块之间的粘合剂，但我更愿意将它称作是“数据”之间的粘合剂，因为模块之间自有它们的交互接口规格来粘合。数据质量模块为衡量数据源质量、ETL 过程处理质量提供支撑。接口平台是处于源系统和数据仓库系统之间的玩意儿，作用在于可以更方便地明确界定双方职责。当然，通常有很多系统似乎并不大愿意将职责搞得过于明确了倒宁愿糊涂一些。糊涂一些的好处在于一开始省了好多事，但在以后扯皮的事情就少不了了。此外，报表集市为报表应用提供支持，指标库为绩效管理需求提供支持。其实，这两者还可以归入业务模型一类，因为它们都是服务于分析需求的。5 需求之所以分成若干模块，是为了让架构清晰，降低这些模块之间的耦合，这符合“分离变化”的原则。那么，这一结构到底是否合理呢？还得看这个架构面临的需求到底是什么。做好这一步，就需要把系统的用户分为两大类角色：一是系统运营角色，他们对系统的正常运行、维护负责；二是业务分析角色，他们需要从这个系统得到数据分析的功能。显然，第二种角色的分析数据来源都将来自业务模型模块，而第一种角色将从剩余模块中满足自己的需要，而不直接和业务模型这个模块打交道。在架构设计中，重点应该放在如何满足系统管理用户的需求上面。当然，只是重点，而非舍弃业务分析角色，毕竟在业务模型模块中，还需要根据业务、数据量、分析应用等方面的特点，来进一步细化。就笔者个人经验认为，架构设计应该是与具体业务关系不大的，这种架构应该是半通用的。之所以是半通用，是因为在系统功能上面，BI项目大同小异，而在业务需求上面，架构只需要对客户的业务、分析需求分成几个大类，例如按行业为业务模型分类，按OLAP、报表来为分析应用分类，不需要太过细致。下面，让我们来看看系统运营角色的需求：首先，我们可以把这类角色再细分成两类：一是开发设计及实施者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。二是系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等，当然都是系统管理员的分内之事。那么，对于开发实施人员，他需要进行系统部署、ETL的开发调试、质量的稽核；对于设计人员，则需要进行模型的变更、系统调优、系统一致性分析等；而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。这些用例就是架构设计的需求，如何满足他们，并且保持良好的体系和清晰的结构，能够易于维护且能够满足日后肯定会增加的业务需求等等，这些都是架构师们仔细斟酌的事情。最后，看一下分析人员的需求。举个例子来讲，某销售总监说：“我需要了解近半年来东区和西区的销售量、收入、成本对比”，这可以算是一个用例。对这个需求，架构师该如何做呢？正确做法是，在架构中不能考虑东区、西区这些业务概念，那样就太过于细致，而是应当将这种需求抽象成一种分析应用，例如 “即席查询”。如此，架构师所着重考虑的事情就是如何满足这一类需求，而非这一个需