1.1 技术架构设计
成功地实施一个仓库项目，通常需要很长的时间。如果仅仅着眼于短期成果，缺乏整体考虑，采用一种不健全的体系结构，不仅会增加系统开发和维护成本，而且必将对发挥数据仓库的作用造成不利的影响。因此一个综合，清晰的远景规划及技术实施蓝图将在整个项目的实施过程中起到重要作用。
技术架构必须具有高度先进性和可扩展性，以满足业务需求的不断变化。一个完整的数据仓库系统包括数据源、数据转换区、数据仓库、数据集市、和数据展现层，通过数据仓库不同层次之间的加工过程，实现财政从数据资产向信息资产的转化过程。在不同层次之间的数据加工过程需要通过ETL技术实现，并对整个过程进行有效的元数据管理。
基于对需求的理解，基于财政部的信息系统框架模型基础之上的财政决策支持系统技术架构如下图所示：
元数据管理－交付件、建模工具源数据抽取、清理操作型数据ETL转换多维数据应用国地税征收系统非税征收管理系统农税征收管理系统人行国库E财预算编制系统预算管理系统数据仓库装载数据集市装载Cube装载预算执行分析接口文件区文件缓冲区/inb/arc/log/wrk/outMDR（元数据存储）业务元数据、技术元数据用来准备SOR数据结构独立于各数据源反馈数据数据挖掘结果MOLAPCube多维立方体数据仓库汇总数据SSASOR用来准备Cube（细节数据暂存）（DW细节数据）数据集市ROLAP关系型多维立方体支出绩效分析收入统计分析EUL(最终用户层)报表/KPI存储资产管理分析……迭代开发－需求变更、功能增长、数据增加系统管理和维护－安全、备份、灾难恢复IT基础设施－软硬件平台 如上图所示意，通过搭建灵活的、可扩展技术架构，在保持数据集市稳定性的同时，可以不断增加数据源，增加应用数据层、增加应用层，满足不断增加的业务分析应用需
求。
采用DW+ODS的数据仓库体系结构，使用全新的ETL模式对ODS进程每日数据更新，按周或月周期对数据仓库执行ETL过程。使用COGNOS BI做为前端的查询分析和数据挖掘工具，可满足各种日常数据处理操作，从即时简单报表查询到多维多级数据分析和挖掘，都能够在统一COGNOS BI平台上完成。
1.1.1 数据源和数据接口
数据源指存储于财政各个业务系统的业务数据，以及未来的财政监管和外部数据。数据仓库系统将整合来自于这些系统的数据，形成财政统一的、一致的基础数据集，并提供给不同的应用主题形成数据集市。各个系统在体系架构、开发平台、数据定义、接口标准都会存在不同程度的差异；另外由于业务的不断变化，历史数据与当前数据之间的含义也可能存在不同，因此数据整合必须充分考虑源系统在技术和数据方面存在的差异。
数据仓库系统将采用文本文件的方式从源系统获取数据。每个源系统会就与数据仓库之间就传输数据接口文件（IFF）的格式和方法制定标准，称之为接口规范。
每个数据源会首先通过各自的数据导出程序（Extractor）生成接口文件存储在各自的文件缓冲区内。这个Extractor负责各自范围内导出数据的完备性和一致性，包括：
1） 依照各自的业务规则确定增量数据的导出方法 2） 保证导出文件的格式符合接口规范的要求 3） 保证导出文件的传输时间的及时性
4） 保证接口文件的数据质量，不错数、不丢数、不多数
1.1.2 财政数据仓库
财政数据仓库（EDW），存储和管理来自源数据系统的数据，按照数据模型分主题进行组织和存放，包括当期的和较长时间的历史数据。数据仓库的核心是企业级数据模
型的规划和设计，是所有应用的基础。接下来我们分别对EDW每个数据区域做详细介绍。
1） 接口文件区
接口文件区是存储和处理接口文件的区域，如前面章节所述，接口文件区在系统下按照特定的目录结构组织起来。用一些系统命令和工具来管理。对每个目录按照其特定的用途设定对不同用户的访问权限，比如谁能读，谁能写，谁能改等。
2） 细节数据暂存区SSA（SOR Staging Area）
SSA的主要目的是支持把接口文件的装载到数据库，对其进行验证和处理，然后把数据整合到SOR内。验证的方法主要是将新转载的数据与SOR内已有的数据进行查找和比较。SSA内数据结构的设计原则是最大限度的利用接口文件的数据结构，尽量降低实体的个数，同时很好的支持后续的ETL过程。 3） 细节数据SOR（System Of Record）
SOR是基于模型开发的一套符合3NF范式规范的表结构。SOR存储了数据仓库内最细节层次的数据，按照不同的主题域进一步分分类组织。此模型是整个数据仓库数据模型的核心，其设计为具有足够的灵活性，以能够应对添加更多的数据源，支持更多分析需求，同时也能够支持进一步升级和更新。 为了能够在数据仓库内记录数据的变化以支持历史趋势和变化分析，SOR在一些 关键的属性值上会跟踪变化（比如客户的信用度、状态等）。跟踪变化的常见方法就是利用渐变维的Type 2方法来处理记录，在表内增加一条记录变化数据的新记录。同时为了降低不必要的存储空间的浪费（相同数据的重复存储），我们可以把实体中动态变化的属性与静态不变或只需覆盖不需跟踪变化的属性分开。比如对用户，我们可以用一张表存放不变化的用户静态属性，用另一张表存放经常变化的用户行为属性，当跟踪用户行为的变化时我们只需在用户行为表内添加记录就行了，没必要把没有发生变化的用户静态表内的数据也复制一份。 4） 汇总数据区Summary
汇总数据区是为了方便查询和后续多维数据的更新，创建一些常用的中间汇总表，以提高性能和降低后续ETL工作的复杂性。
由于SOR是高度规范化的数据，因此要完成一个查询需要大量的关联操作；同时数据集市中的数据粒度往往要比SOR高很多，对要成生数据集市所需数据也需要大量的汇总计算，因此如果我们把常用的数据预先关联和汇总好，并让其尽量多在多个数据集市的计算中共享，就能大幅度的提高整个ETL工作和数据仓库查询的性能。 5） 反馈数据区（Feedback Area）
反馈数据区主要记录的是数据仓库自身生成的结果。比如用户对营销活动的反馈等。数据仓库的特性决定了用户在原则上不能直接修改数据仓库中的数据，因此用户的修改数据和其它生成数据必须单独记录，以便于追踪历史和进行比较。
6） 元数据存储MDR（Meta Data Repository）
元数据存储用来保存关于数据仓库中的过程、数据的信息（日志、数据词典、配置信息等）。由于各个工具和系统都会生成自己的元数据，同时我们还利用元数据管理工具把这些元数据尽可能的集中存储到数据仓库中的MDR内，因此MDR总的来说只是一个共享元数据供用户集中访问的地方，真正元数据的维护地还是在生成这些元数据的系统或工具内。
1.1.3 数据集市
数据集市设计用途是要满足特定的目的，同时具有查询、多维分析、报表和数据挖掘功能。这与企业数据仓库截然不同，设计时企业数据仓库在信息内容与结构方面尽可能拥有开放性与灵活性。
数据集市有以下特征：
? 为特定用途而设计——数据集市设计的目的，是支持特定用户对数据子集的特
定范围的查询。它以用户所要求的方式提供企业数据仓库的细节汇总。 ? 优化——数据集市为了支持特定工具的访问而优化。根据工具、根据企业数据
仓库提供的信息子集来设计数据集市，而不是让用户直接访问企业数据仓库中
的大型数据库，这可以改善数据集市的性能。
? 虚拟或物理数据集市——数据集市可以是物理的实现，也可以是企业数据仓库
表的各种视图。使用视图（虚拟数据集市）可以避免存储数据的多个副本，简化了数据管理。
数据集市，即Data Mart，指面向专项应用领域的分析主题。Data Mart即是通过OLAP技术或者数据挖掘技术，利用数据仓库的数据根据用户需求建立的数据集市模型，大大提高了前端查询访问的效率，用户能方便地实现灵活、动态、快速、多角度、多层次地分析企业数据。同时，也可以通过定制灵活的OLTP查询来了解明细数据。
1.1.4 数据的抽取、转换、加载（ETL）
数据仓库的数据来源于业务处理系统，但是数据仓库的数据并不是对源系统数据的简单叠加，它需要按照数据仓库的逻辑模型和物理模型，在源系统数据分析的基础上，按照源系统数据和数据仓库数据之间的映射关系，经过数据的抽取(Extraction)、转换 (Transformation)和加载(Loading)等环节方可进入数据仓库，这个过程简称为ETL处理。
数据经过数据抽取、转换和加载处理进入数据仓库的整个过程可以简称为ETL过程。ETL是搭建数据仓库数据平台的基础，也是保证数据仓库的数据质量的具体实现。根据基于数据仓库项目开发的经验，在大多数据仓库的实施过程当中，ETL都是一个非常复杂、耗时的过程，其工作量约占整个数据仓库项目的40-50%，占数据仓库设计阶段工作量的70-80%，有许多原因影响这一阶段的时间和进度。比如对原有业务系统和旧的操作环境的了解有限，原系统文档不全等。因为这些原因，使ETL任务花了许多时间在了解旧的业务应用以及如何抽取数据上。ETL实施困难另一个原因是原有的系统平台没有足够的容量/系统资源来支持数据抽取处理，系统资源不足可能表现为：CPU、磁盘空间、I/O带宽或没有一个有效的窗口去运行抽取、转换程序。
ETL过程不仅工作量大，而且还受到很多时间窗口的限制，它不仅需要在不同的特定（非确定）的时间抽取数据，而且还必须要在特定的时间范围内把数据加载到数据仓库。由于ETL过程是数据仓库应用系统每天都要进行的工作， ETL设计的科学性和效率性是非常重要的，关系到数据仓库项目的成败。