搭建数据仓库第02篇：数据仓库技术架构解决方案

上一篇开了个头，从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