搭建数据仓库：数据仓库开发的生命周期

虽然一直在做数据仓库开发，但是还没有从0开始搭建过数据仓库，所以就想通过学习和思考来搭建一个还不错的数据仓库。比较经典的当属Kimball生命周期方法，它为我们在数据仓库开发过程中提供了路标的作用，生命周期方法的总体结构的核心内容有

• 定义业务需求
• 技术路径
  • 技术架构设计
  • 产品的选择和安装
    
• 数据路径
  • 维度建模
  • 物理设计
  • ETL设计和开发
    
• BI应用路径
  • BI应用设计
  • BI应用开发
    
  
  

后续会按照这个顺序依次做些总结和思考。其中第一部分定义业务需求是后面的三种路径的前提，但是跟数据路径更加紧密一些，所以就在数据路径中作总结了。

上一篇开了个头，从Kimball数据仓库生命周期方法角度，列出了数据仓库搭建的核心步骤，从这一篇开始将讲述技术路径：技术架构设计和产品选择和安装。

首先先以某公司的数据仓库的总体架构图的视角，了解整个数据仓库搭建起来后结构大体的样子。

   

• 最底层是数据源，一般是在线的数据库或者是文件系统。对于在线数据库，一般是操作型数据库，比如mysql,Oracle等，一般是存在主库和从库，从库用来做备份，主库出现问题时切换到从库，从而尽可能的避免影响线上的应用，从库的数据是从主库使用工具同步过来的，比如oracle的shareplex等，所以从库有一定的延迟。文件系统一般使用的格式是csv或者txt。不推荐excle格式的文件，容易出现格式问题。
• 数据仓库层包含ODS,EDW,DM,接口数据，归档数据以及调度监控，元数据管理，主数据管理和数据质量监控
  • ODS层是从数据源抽取（E），经过格式的转换（T），最后加载（L）到数据仓库中的。
    • ETL过程中数据的粒度不会变化，一般除了简单的格式变化，跟线上的数据库的表基本一致。
    • 抽取是对从库的表的数据进行抽取，抽取的时候需要对主从库是否存在延迟进行监测。
    • 有的时候是加载操作在转换操作之前，也就是ELT，这取决于转换操作在数据仓库中是否更加容易操作，在一般的TB、PB的数据仓库中，数据的转换函数并不是很丰富，即便是有，有时候性能也不是很好，所以都是在抽取数据到文件之后，对文件进行转换操作处理。
    • 抽取的时候一般可以选择增量抽取还是全量抽取，增量抽取一般需要根据时间戳，全量抽取的时候可以通过ROW NUM字段进行批量式的抽取。
    • 加载的目标表可以是临时表staging table，全量ODS表，分区ODS表。加载到临时表一般是针对增量抽取而言的，通过将增量数据全部load到临时表之后，通过merge操作更新ODS表。加载到全量ODS表，如果是增量抽取，那么就用新增数据merge历史全量数据，此时确保没有应删除操作；如果是全量抽取，那么直接用新抽取的数据覆盖历史数据。 分区ODS表分为增量分区（每个分区是增量数据）和全量分区（每个分区是历史全量数据），增量分区表可以选择增量抽取，全量分区，在没有硬删除的时候可以采用增量抽取，然后merge前一个分区的数据生成最新的分区，有硬删除的情况下只能采用全量抽取，然后直接生成最新的分区。
      
  • EDW层是将ODS层的数据按照主题来生成基础数据。EDW之上的是DM层。针对特殊的APP应用或者部门等，可以通过EDW的数据生成接口数据，专门服务于应用软件等。
  • 任务调度，从数据源—>ODS—>EDW—>DM/接口层的数据流的计算都需要使用工具或者编写脚本来执行，执行的过程需要调度系统来安排，过程中需要管理任务的执行频率，优先级，任务的依赖，以及任务运行时的监控（失败或者延迟）等等。
  • 元数据和主数据的管理，这一块是比较难于管理的部分。
  • 数据质量监控
    
• 数据应用层主要是数据的分析、挖掘和展示。
  

系统角度上，影响建设数据仓库的解决方案的因素

• 操作出现的频率，即业务部门每隔多长时间做一次查询分析。
• 在系统中需要保存多久的数据，是一年、两年还是五年、十年。
• 用户查询数据的主要方式，如在时间维度上是按照自然年，还是财政年。
• 用户所能接受的响应时间是多长、是几秒钟，还是几小时。
  

产品选择角度上，影响建设数据仓库的解决方案的因素

• 厂商的背景和支持能力，能否提供全方位的技术支持和咨询服务。
• 数据库对大数据量（TB级）的支持能力。
• 数据库是否支持并行操作。
• 能否提供数据仓库的建模工具，是否支持对元数据的管理。
• 能否提供支持大数据量的数据加载、转换、传输工具（ETT）。
• 能否提供完整的决策支持工具集，满足数据仓库中各类用户的需要。
  

在了解了整个数据仓库自上而下的框架之后，数据的同步，数据的存储计算，数据的计算，数据的分析，数据的展现，这些阶段上建设数据仓库有什么样的解决方案呢？

• 首先是数据同步（数据源-ODS层）：ETL工具的选择
  • 主流的ETL工具有Informatica，Datastage，Kettle
    
  
  

(借此吐槽一下博客园表格的使用太不和谐了，做好的表格，整篇文章格式全乱了! 只能做好截个图)

• • 其他的ETL工具有ODI，Beenload，cognos等等
    
• 其次是数据的存储计算（EDW-DM）:数据仓库
  • 数据仓库主流有Teradata，Exadata，GreenPlum，SybaseIQ，Hive
    
  
  

• 数据的分析和报表展示：OLAP
  • 5大主流BI工具
    • 参考http://www.cnblogs.com/cold/archive/2011/10/18/2216272.html
      
    
    
  
  

目录

• 前言
• 业务建模
• 概念模型
• 小结
  

---

前言

上一篇在数据仓库在技术架构设计和产品选择方面进行了一些总结。从这一篇将开始数据路径上的学习和思考吧。数据仓库作为一种产品，在不同的公司或者部门设计出来是不一样的。但是设计的思想是相通的。按照层次关系划分，数据路径上包括业务建模，概念模型设计，逻辑模型设计和物理模型设计。

• 业务建模是针对公司或者部门级的业务进行全方面的梳理和分解。
• 概念建模是对业务模型进行抽象出来实体以及实体与实体之间的关系。
• 逻辑模型是对概念模型进行具体的设计，实体的属性，主键，外键等等。
• 物理模型是将逻辑模型具体实施，考虑各种具体的技术实现因素，进行数据仓库体系结构设计，真正实现数据在数据仓库中的存放。
  

这一篇我们将优先思考业务建模和概念模型两个方面。

业务建模

数据仓库的构建离不开业务场景，构建数据仓库的第一步就需要通过与业务部门的充分交流，了解建立数据仓库所要解决的问题的真正含义，并确定各个主题下的查询分析要求。业务建模就是一种理解公司业务的很好的方式。通过业务建模可以深入了解各个业务部门的内具体业务流程，界定数据仓库建模的范围。

业务建模也是按照层级逐层展开的，依次是顶层模型，业务域，业务流程，业务环节。

• 顶层模型，是从公司整体业务的角度，划分业务模块，以及各个业务模块之间的交互关系。比如公司有交易，财务，营销模块，财务模块跟营销之间的关系有营销活动发起之前要申请预算，采取需要统计营销活动的成本。交易可以配置营销活动。
• 业务域，是把划分的模块逐一进行分解到业务用例。比如营销活动模块可分解为，运营人员配置活动信息，用户购买产品使用优惠等等。
• 业务流程，是将业务用例做具体的流程分解，具体到每一步操作是怎么样，以及操作之间的次序和依赖关系。
• 业务环节，就是写SOP，把一个环节的作业内容再标准化，实际上就是作业标准化的过程。主要涉及流程中每一步的正常情况，异常情况的结果是怎样的等等。
  

概念模型

概念模型是把业务建模的各个业务流程过程抽象出实体和关系（ER）。概念模型关注的是实体和实体之间的关系，对于实体的属性没有做过多的考虑。概念模型的设计结果将直接指导接下来的逻辑模型和物理模型设计，可以说概念模型是在整个模型设计过程中最重要的一环。

概念模型的设计可以一定的参考ER模型设计，当然也有很多成熟的方法论，比如DWER等等。具体的没有深入了解。笔者自己的理解，概念模型主要是有以下几个方面：

• 针对关键业务环节部分，抽象出实体。
• 确定实体之间的关系，1对1,1对多，还是多对多。
• 不断的迭代所有的业务环节。
• 将所有抽象出来的实体和关系进行总结，统一的实体汇集在一起，将所有相关的实体关联起来。
  

小结

业务建模和概念建模都是比较抽象的，不同的人抽象出来的结果也不尽相同，抽象出来的更合理的模型会对后续的数据建模打了更好的基础。

业务建模的主要工作在于

• 划分整个单位的业务，理清各业务部门之间的关系，界定建模的范围。
• 深入了解各个业务部门的内具体业务流程。
  

概念模型的主要工作在于

• 将关键业务流程抽象出实体和实体之间的关系。
• 将所有抽象出来的实体和关系，进行汇集，相同的实体关联在一起。