数据仓库技术架构解决方案.docx

《数据仓库技术架构解决方案.docx》由会员分享，可在线阅读，更多相关《数据仓库技术架构解决方案.docx（25页珍藏版）》请在悟道方案网上搜索。

1、数据仓库 技术架构 解决方案  数据仓库技术架构解决方案  IT 基础设施 软硬件平台 系统管理和维护 安全、备份、灾难恢复 迭代开发 需求变更、功能增长、数据增加 国地税征收 系统 非税征收 管理系统 文 件 缓 冲 区 / i nb / a r c / l og / ou t 接口 文件区 / w r k 数据仓库 E T L M D R （元数据存储） 业务元数据、技术元数据 SSA （细节数据暂存） 用来准备 S O R S O R （ DW 细节数据） 数据结构 独立于各数据源 汇总数据 用来准备 C ub e 反馈数据 数据挖掘结果 数据集市 R O L A P

2、 关系型 多维立方体 M O LA P C ub e 多维立方体 E U L ( 最终用户层 ) 报表 / K P I 存储 元数据管理 交付件、建模工具 支出绩效 分析 收入统计 分析 资产管理 分析 源数据 应用转换操作型数据抽取、清理 多维数据 数据仓库装载 数据集市装载 C u b e 装载 预算执行 分析 农税征收 管理系统 人行国库 E 财预算 编制系统 预算管理系统 数据仓库 技术架构 解决方案  1.1 技术架构设计  成功地实施一个仓库项目，通常需要很长的时间。如果仅仅着眼于短期成果，缺乏 整体考虑，采用一种不健全的体系结构，不仅会增加系统开发和维护成本，

3、而且必将对 发挥数据仓库的作用造成不利的影响。因此一个综合，清晰的远景规划及技术实施蓝图 将在整个项目的实施过程中起到重要作用。  技术架构必须具有高度先进性和可扩展性，以满足业务需求的不断变化。一个完整 的数据仓库系统包括数据源、数据转换区、数据仓库、数据集市、和数据展现层，通过 数据仓库不同层次之间的加工过程，实现财政从数据资 产向信息资产的转化过程。在不 同层次之间的数据加工过程需要通过 ETL 技术实现，并对整个过程进行有效的元数据管 理。  基于对需求的理解，基于财政部的信息系统框架模型基础之上的财政决策支持系统 技术架构如下图所示：  如上图所示意，通

4、过搭建灵活的、可扩展技术架构，在保持数据集市稳定性的同时， IT 基础设施 软硬件平台 系统管理和维护 安全、备份、灾难恢复 迭代开发 需求变更、功能增长、数据增加 国地税征收 系统 非税征收 管理系统 文 件 缓 冲 区 / i nb / a r c / l og / ou t 接口 文件区 / w r k 数据仓库 E T L M D R （元数据存储） 业务元数据、技术元数据 SSA （细节数据暂存） 用来准备 S O R S O R （ DW 细节数据） 数据结构 独立于各数据源 汇总数据 用来准备 C ub e 反馈数据 数据挖掘结果 数据集市 R O L A P 关系型 多维立方体

5、 M O LA P C ub e 多维立方体 E U L ( 最终用户层 ) 报表 / K P I 存储 元数据管理 交付件、建模工具 支出绩效 分析 收入统计 分析 资产管理 分析 源数据 应用转换操作型数据抽取、清理 多维数据 数据仓库装载 数据集市装载 C u b e 装载 预算执行 分析 农税征收 管理系统 人行国库 E 财预算 编制系统 预算管理系统 数据仓库 技术架构 解决方案  可以不断增加数据源，增加应用数据 层、增加应用层，满足不断增加的业务分析应用需 求。  采用 DW+ODS的数据仓库体系结构，使用全新的 ETL模式对 ODS进程每日数据更新， 按周或

6、月周期对数据仓库执行 ETL 过程。使用 COGNOS BI 做为前端的查询分析和数据挖 掘工具，可满足各种日常数据处理操作，从即时简单报表查询到多维多级数据分析和挖 掘，都能够在统一 COGNOS BI 平台上完成。  1.1.1 数据源和数据接口  数据源指存储于财政各个业务系统的业务数据，以及未来的财政监管和外部数据。 数据仓库系统将整合来自于这些系统的数据，形成财政统一的、一致的基础数据集，并 提 供给不同的应用主题形成数据集市。各个系统在体系架构、开发平台、数据定义、接 口标准都会存在不同程度的差异；另外由于业务的不断变化，历史数据与当前数据之间 的含义也可能存在

7、不同，因此数据整合必须充分考虑源系统在技术和数据方面存在的差 异。  数据仓库系统将采用文本文件的方式从源系统获取数据。每个源系统会就与数据仓 库之间就传输数据接口文件（ IFF）的格式和方法制定标准，称之为接口规范。  每个 数据源会首先通过各自的数据导出程序（ Extractor）生成接口文件存储在各自 的文件缓冲区内。这个 Extractor 负责各自范围内 导出数据的完备性和一致性，包括：  1） 依照各自的业务规则确定增量数据的导出方法  2） 保证导出文件的格式符合接口规范的要求  3） 保证导出文件的传输时间的及时性  

8、4） 保证接口文件的数据质量，不错数、不丢数、不多数  1.1.2 财政数据仓库  财政数据仓库（ EDW），存储和管理来自源数据系统的数据，按照数据模型分主题 数据仓库 技术架构 解决方案  进行组织和存放，包括当期的和较长时间的历史数据。数据仓库的核心是企业级数据模 型的规划和设计，是所有应用的基础。 接下来我们分别对 EDW 每个数据区域做详细介绍。  1） 接口文件区  接口文件区是存储和处理接口文件的区域，如前面章节所述，接口文件区在系 统下按照特定的目录结构组织起来。用一些系统命令和工具来管理。对每个目 录按照其特定的用途设定对不同

9、用户的访问权限，比如谁能读，谁能写，谁能 改等。  2） 细节数据暂存区 SSA（ SOR Staging Area）  SSA 的主要目的是支持把接口文件的装载到数据库，对其进行验证和处理，然 后把数据整合到 SOR 内。验证的方法主要是将新转载的数据与 SOR 内已有的数 据进行查找和比较。 SSA 内数据结构的设计原则是最大限度的利用接口文件的 数据结构，尽量降低实体的个数，同时很好的支持后续的 ETL 过程。  3） 细节数据 SOR（ System Of Record）  SOR 是基于模型开发的一套符合 3NF 范式规范的表结构。 SOR 存

10、储了数据仓 库内最细节层次的数据，按照不同的主题域进一步分分类组织。此模型是整个 数据仓库数据模型的核心，其设计为具有足够的灵 活性，以能够应对添加更多 的数据源，支持更多分析需求，同时也能够支持进一步升级和更新。  为了能够在数据仓库内记录数据的变化以支持历史趋势和变化分析， SOR 在一 些 关键的属性值上会跟踪变化（比如客户的信用度、状态等）。跟踪变化的常 见方法就是利用渐变维的 Type 2 方法来处理记录，在表内增加一条记录变化 数据的新记录。同时为了降低不必要的存储空间的浪费（相同数据的重复存储）， 我们可以把实体中动态变化的属性与静态不变或只需覆盖不需跟踪变化的属 性分

11、开。比如对用户，我们可以用一张表存放不变化的用户静态属性，用另一 张表存放 经常变化的用户行为属性，当跟踪用户行为的变化时我们只需在用户 行为表内添加记录就行了，没必要把没有发生变化的用户静态表内的数据也复 制一份。  4） 汇总数据区 Summary 汇总数据区是为了方便查询和后续多维数据的更新，创建一些常用的中间汇总 数据仓库 技术架构 解决方案  表，以提高性能和降低后续 ETL 工作的复杂性。  由于 SOR 是高度规范化的数据，因此要完成一个查询需要大量的关联操作； 同时数据集市中的数据粒度往往要比 SOR 高很多，对要成生数据集市所需数 据也需要大量的

12、汇总计算，因此如果我们把常用的数据预先关联和汇总好，并 让其尽量多在多个数据集市的计算 中共享，就能大幅度的提高整个 ETL 工作和 数据仓库查询的性能。  5） 反馈数据区（ Feedback Area）  反馈数据区主要记录的是数据仓库自身生成的结果。比如用户对营销活动的反 馈等。数据仓库的特性决定了用户在原则上不能直接修改数据仓库中的数据， 因此用户的修改数据和其它生成数据必须单独记录，以便于追踪历史和进行比 较。  6） 元数据存储 MDR（ Meta Data Repository）  元数据存储用来保存关于数据仓库中的过程、数据的信息（日志、

13、数据词典、 配置信息等）。由于各个工具和系统都会生成自己的元数据，同时我们还利用 元数据管理工 具把这些元数据尽可能的集中存储到数据仓库中的 MDR 内，因 此 MDR 总的来说只是一个共享元数据供用户集中访问的地方，真正元数据的 维护地还是在生成这些元数据的系统或工 具内。  1.1.3 数据集市  数据集市设计用途是要满足特定的目的，同时具有查询、多维分析、报表和数据挖 掘功能。这与企业数据仓库截然不同，设计时企业数据仓库在信息内容与结构方面尽可 能拥有开放性与灵活性。  数据集市有以下特征：   为特定用途而设计 数据集市设计的目的，是支持特定用户

14、对数据子集的特 定范围的查询。它以用户所要求的方式提供企业数据仓库的细节 汇总。   优化 数据集市为了支持特定工具的访问而优化。根据工具、根据企业数据 数据仓库 技术架构 解决方案  仓库提供的信息子集来设计数据集市，而不是让用户直接访问企业数据仓库中 的大型数据库，这可以改善数据集市的性能。   虚拟或物理数据集市 数据集市可以是物理的实现，也可以是企业数据仓库 表的各种视图。使用视图（虚拟数据集市）可以避免存储数据的多个副本，简 化了数据管理。  数据集市，即 Data Mart，指面向专项应用领域的分析主题。 Data Mart 即是通过 OLA

15、P 技术或者数据挖掘技术，利用数据仓库的数据根据用户需求建立的数据集市模型， 大大提 高了前端查询访问的效率，用户能方便地实现灵活、动态、快速、多角度、多层 次地分析企业数据。同时，也可以通过定制灵活的 OLTP 查询来了解明细数据。  1.1.4 数据的抽取、转换、加载（ ETL）  数据仓库的数据来源于业务处理系统，但是数据仓库的数据并不是对源系统数据的 简单叠加，它需要按照数据仓库的逻辑模型和物理模型，在源系统数据分析的基础上， 按照源系统数据和数据仓库数据之间的映射关系，经过数据的抽取 (Extraction)、转换  (Transformation)和加

16、载 (Loading)等环节方可进入数据仓库，这个过程简称为 ETL 处 理。  数据经过数据抽取、转换和加载处理进入数据仓库的整个过程可以简称为 ETL 过程。 ETL 是搭建数据仓库数据平台的基础，也是保证数据仓库的数据质量的具体实现。根据 基于数据仓库项目开发的经验，在大多数据仓库的实施过程当中， ETL 都是一个非常复 杂、耗时的过程，其工作量约占整个数据仓库项目的 40-50%，占数据仓库设计阶段工 作量的 70-80%，有许多原因影响这一阶段的时间和进度。比如对原有业务系统和旧的 操作环境的了 解有限，原系统文档不全等。因为这些原因，使 ETL 任务花了许多时间在 了解旧

17、的业务应用以及如何抽取数据上。 ETL 实施困难另一个原因是原有的系统平台没 有足够的容量 /系统资源来支持数据抽取处理，系统资源不足可能表现为： CPU、磁盘空 间、 I/O 带宽或没有一个有效的窗口去运行抽取、转换程序。  ETL 过程不仅工作量大，而且还受到很多时间窗口的限制，它不仅需要在不同的特 定（非确定）的时间抽取数据，而且还必须要在特定的时间范围内把数据加载到数据仓 库。由于 ETL 过程是数据仓库应用系统每天都要进行的工作， ETL 设计的科学性和效 数据仓库 技术架构 解决方案  率性是非常重要的，关系到数据仓库项目的成败。  ETL 遵循如下设

18、计原则：   灵活性：不同的时间段中能够进行数据获取、转换、装载。   可重复性：支持失败的 ETL 任务行数据重新装载。   模块化： ETL 过程分步实施，每个过程通过不同的模块组件来完成。并尽可能 复用这些组件；从而提高 ETL 实施效率，增加数据仓库的可维护性。   迭代方法：满足当前的业务需求，尽可能搭建满足未来的业务需求的平台上不 断开发实施。   ETL 逻辑顺序：依赖业务系统数据处理方式，来定义 ETL 处理流程控制。例 如：在银行的 ETL 过程中，交易记录信息的数据装载应该 在账户信息进入数据 仓库之后进行。  1

19、.1.4.1 第一步：数据抽取  在源系统上启动数据抽取控制程序，完成以下工作：  1、数据采集  考虑到数据来源的多样性和复杂性，数据采集主要包括：   对业务系统的数据采集：在日终结后，当日数据自动、增量地转储到数据 备份机上，作为数据仓库的数据源并成为数据备份策略的一部分。   对于税收计划、外部数据、纳税人财务报表的数据采集。可根据实际需要， 采用多种途径。  2、数据发送  在数据采集完成后，各系统上的抽取控制程序将数据文件和校验文件通过局域 网发送到数据转换区。  1.1.4.2 第二步：数据装入 转换

20、区  1. 检查数据是否到位  数据仓库 技术架构 解决方案  根据校验文件，检查源系统数据是否到位、是否存在传输错误等异常情况。如 果数据不全或传输出现错误，如果出错，将出错结果写入错误日志，重新执行 第一步。  2. 将外部数据文件装入数据库  把来自外部源数据源的格式化数据转化成数据库、表结构。  3. 修改系统状态：  待该步骤工作完成后，将系统状态改为抽取工作完成。  注：若直接从业务系统数据库中抽取数据，则无须数据转换区步骤。  1.1.4.3 第三步： 数据质量 检查和出错处理  

21、1. 状态检查：  查询参数表，如果数据抽取工作已经完成，开始执行该步骤工作。  2. 数据质量检查 ：  根据检查规则，数据质量检查程序扫描源数据数据表，根据规则检查数据是否 合法，给出检查报告和最终的数据质量报告并写入数据库，数据质量检查结果 写入质量检查报告。  3. 出错处理：  如果出现严重出错，停止 ETL 工作，需要系统维护人员现场做出相应的处理， 修改正确后，重新执行该步骤工作；对于警告级出错，继续进行下述步骤。  4. 修改系统状态：  待该步骤工作完成后，将系统状态改为数据质量检查工作完成。  

22、1.1.4.4 第四步：数据转换  1、状态检查  查询参数表，如果数据质量检查工作已经完成，开始执行该步工作。  2、数据转换  根据数据 仓库要求的数据源格式在 Staging Area 中进行并行转换处 理，并 数据仓库 技术架构 解决方案  将转换的结果数据存放在待装载数据存放区。  3、生成转换报告  记录数据转换情况，并写入数据库转换日志中。  4、修改系统状态：  待该步骤工作完成后，将系统状态改为数据转换工作完成。  1.1.4.5 第五步：数据加载  1、状态检查 &

23、nbsp;查询参数表，如果数据质量检查工作已经完成，开始执行该步骤工作。  2、数据装入数据仓库  采用非依赖数据并行加载的策略，将待装载数据区的数据装入中心数据仓库， 如果标准代码表发生变化，数据装载程序将标准代码的变化情况增量加载到数 据仓库代码表中。  3、数据加载情况报告  记录数据加载情况，并写入数据仓库数据库的参数表中。  4、修改系统状态：  待该步骤工作完成后，将系统状态改为数据转换工作完成。  1.1.4.6 第六步： 加载 时间维  1. 状态检查  查询参数表，如果数据加载工作已经完

24、成，开始执行该步骤工作。  2. 加载时间维  根据当前的时间，依据数据集市多维模型，完成时间维的加载工作。  3. 修改系统状态：  待该步骤工作完成后，将系统状态改为时间维加载工作完成。  数据仓库 技术架构 解决方案  1.1.4.7 第七步：加载 事实 表  1. 状态检查  查询参数表，如果时间维加载工作已经完成，开始执行该步骤工作。  2. 加载事实表  以数据仓库数据为数据源，依据数据集市多维模型，完成事实表的加载工作。  3. 修改系统状态：  待该步骤工作完

25、成后，将系统状态改为事实表加载工作完成。  1.1.4.8 第八步：加载聚合表  1. 状态检查  查询参数表，如果事实表加载工作已经完成，开始执行该步骤工作。  2. 加载聚合表  以事实表为数据源，依据数据集市多维模型，完成聚合表的加载工作。  3. 修改系统状态：  待该步骤工作完成后，将系统状态改为 ETL 工作结束。  1.1.5 数据展现  数据访问及展现是通过信息门户， 将各类数据集市应用通过统一的平台展现给 财政 各类 用户 。同时提供数据分析结果的表达、共享与传递的功能，是信息服务的主要

26、界面， 主要包括信息展现与人机交互、信息发布等。  本次的展现选择 *的报表分析平台，详细功能见附件一。  数据仓库 技术架构 解决方案  1.2 数据架构设计  数据仓库的体系结构包括 4 个层次的数据：数据源、数据仓库层和数据集市层。  1） 数据源（业务系统）包含面向操作应用的原始数据以及外部录入数据，主要 服务于高性能的 事务处理。  2） 数据仓库层（包括 ODS 和 DW）存储企业的历史数据，其数据是规范的、 稳定的。  i. 数据仓库包含当前数据、综合数据、历史数据的组织和整理。通过数据抽 取平台获取的各业务数

27、据，从逻辑上和业务上是独立的、分散的，要实现 一体化的查询功能，必须对分散的业务数据进行抽取和整合。如将分散的 单位基础信息、预算数据、支出数据通过一定的策略，整理形成一套编码 数据仓库 技术架构 解决方案  统一、业务连贯的数据体系，这是一体化查询系统成功的关键。  3） 数据集市层（包括 Relational Data Mart 和 Star-Schema Data Mart 和 OLAP）是面向部门的、满足最终用户需求的数据，数据集市中的数据是反 规范的、汇总的。  数据整理平台基于各业务数据，可以根据不同的用户查询需求，定制数 据整理策略。根据查询角度的不

28、同，按决策的主题要求形成当前的基本数据 层，按综合决策的要求构成综合数据层，随着时问的推移，由时间控制机制 将当前基本数据层转为历史数据层。  4） 数据展现层（前端展现）是面向业务用户的需求展现，包括使用报表、多维 分析、即席查询等基本功能，提供告警、统计算法等高级功能。  第二章  基于基础资料系统的数据模型设计  2.1 基本纬度数据模型设计  “金财工程”一体化需以系统统一的数据字典和统一的编码体系为基础，以统一的 应用支撑平台作保障，通过本级财政业务流程的整合，实现对任一笔资金的跟踪和回溯。  为了实现对数据的集中使用，就要

29、从需求出发，在充分考虑到数据的可共享性、系 统未来的可扩展性等因素，定义一套标准数据格式，为系统的建设打下一个良好的基础。 它包括各种涉及的基础编码表：如预算科目表、经济科目表、预算单位编码表、企业登 记表、税种表、预算级次表等。  数据字典是财政业务系统间需要统一维护管理、支持同步和共享的数据元、基础代 码集、基础配置数据和相关命名规范 的统称。其中数据元又称数据类型，包括定义、标 识、表示以及允许值等一系列属性描述的数据单元。通常所说的业务要素就是财政业务 系统中构成业务数据的比较重要的数据元，该类数据元均有相应的基础代码集。  数据字典中主要包括的内容：财政业务管理涉

30、及到的所有的数据元及共享的基础代 码集；共用的用户列表；相关配置数据及系统开发需遵循的命名规范。  数据仓库 技术架构 解决方案  我们将按照省厅建设的基础数据资料库来进行基本纬度模型的建设。  2.2 基础资料系统维护功能  模块 功能模块 功能说明  框架 单点登录 多系统实现单点登录  权限控制 统一的功能权限控制机制  日志 统一的系统级、功能级、数据级操作日志  选择年度 选择所需要操作的年度和帐套，设置默认的年度；  修改密码 修改当前用户的登录系统密码；  注销 注销当前用户，退出

31、系统，返回到登录页面；  帮助   隐藏 隐藏和显示页面上方软件标题栏和左方菜单栏；  基础资料    创建新年度    系统设置 应用设置 设置应用的名称以及一些基础信息；  选项表设置 设置选项表以及下拉菜单信息；  参数设置  设置各个应用的所在服务器的 IP 值以及一些其他的固 定的参数；  应用权限设置  设置数据授权中的用户和单位对应用中的要素的权限 是否公有；  用户对账本年度  设置用户与账本年度对应关系，也即用户访问账本年度 的权限； &

32、nbsp;缓存管理 刷新缓存的功能；  要素维护 预算单位 设置预算单位名称以及基本信息；  功能科目 设置功能科目名称以及基本信息；  会计科目 设置会计科目名称以及基本信息；  经济科目 设置经济科目名称以及基本信息；  预算项目 设置预算项目名称以及基本信息；  收费项目 设置收费项目名称以及基本信息；  资金来源 设置资金来源名称以及基本信息；  指标类型 设置指标类型名称以及基本信息；  资金性质 设置资金性质名称以及基本信息；  数据仓库 技术架构 解决方案  财政归口部门

33、 设置财政归口部门名称以及基本信息；  数据授权 用户对预算单位 设置用户与预算单位对应关系；  用户对会计科目 设置用户与会计科目对应关系；  用户对功能科目 设置用户与功能科目对应关系；  用户对经济科目 设置用户与经济科目对应关系；  用户对预算项目 设置用户与预算项目对应关系；  用户对收费项目 设置用户与收费项目对应关系；  用户对指标类型 设置用户与指标类型对应关系；  用户对资金来源 设置用户与资金来源对应关系；  单位对会计科目 设置预算单位与会计科目对应关系；  单位对功能科目

34、 设置预算单位与功能科目对应关系；  单位对经济科目 设置预算单位与经济科目对应关系；  单位对预算项目 设置预算单位与预算项目对应关系；  处室对单位 设置财政归口部门与预算单位之间的对应关系；  用户对归口 设置用户与财政归口部门之间的对应关系；  功能授权 用户  设置用户的基本信息以及用户与财政归口部门和预算 单位之间的对应关系；  岗位 设置岗位的基本信息；  功能  设置功能（也即各个应用的菜单和按钮）的基本信息和 链接地址等；  功能转授 把当前用户的功能转授给其他用户的设置； &

35、nbsp;用户对岗位 设置用户与岗位的对应关系；  岗位对功能 设置岗位与功能的对应关系；  权限转授 用户对会计科目 把当前用户会计科目的数据权限转授给其他用户；  用户对经济科目 把当前用户经济科目的数据权限转授给其他用户；  用户对指标类型 把当前用户指标类型的数据权限转授给其他用户；  用户对收费项目 把当前用户收费项目的数据权限转授给其他用户；  用户对预算项目 把当前用户预算项目的数据权限转授给其他用户；  用户对资金来源 把当前用户资金来源的数据权限转授给其他用户；  数据仓库 技术架构 解决方案 &

36、nbsp;2.3 数据逻辑建模  逻辑建模是数据仓库实施中的重要一环 , 因为它能直接反映出决策者管理者的需 求 , 同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的 第三范式 (3NF, 即 Third Normal Form)和星型模式 (Star-Schema)， 3NF 是数据库设 计的基础理论，这里不再展开。  星型模式是一种多维的数据关系 ,它由一个事实表 (Fact Table)和一组维表 (Dimension Table)组成。每个维表都有一个维作为主键，所有这些维的主键组合成事 实表的主键。事实表的非主键属性称为事实 (Fact),

37、它们一般都是数值或其他可以进行 计算的数据 ; 而维大都是文字、时间等类型的数据，按这种方式组织好数据我们就可以 按照不同的维 (事实表的主键的部分或全部 )来对这些事实数据进行求和 (summary)、求 平均 (average)、计数 (count)、百分比 (percent)的聚集计算，甚至可以做 20-80 分析。 这样就可以从不同的角度数字来分析业务主题的情况，下面给出一个直观的例子。  图 8-3 预算执行情况星型模型  图三是一个典型的财政预算执行情况分析的模型设计，其中加边框的为主关键字 (PK, Primary Key)，其中预算执行情况分析表是一个事实表

38、，其中的指标金额，计划 金额，支付金额是需要从各角度观察的数据 (事实 )，而观察的角度是有功能分类、业务 功能分类维  功能分类标准码  类  款  项    业务处室维  业务处室编码  业务处室名称    时间维  时间代码  年  季度  月    单位维  单位编码  一级单位编码  一级单位名称  二级单位编码    预算执行情况分析  功能分类标准码 &

39、nbsp;业务处室编码  时间代码  单位编码  指标金额  计划金额  支付金额    数据仓库 技术架构 解决方案  处室、时间和单位这四个方面组合进行，这些分析角度的有机组合，可以对指标金额、 计划金额和支付金额进行多种组合的数据统计分析，以此实现对预算执行情况的多角度 (维 )多层次 (数据不同的汇总程度 )的分析，预算执行情况分析人员既可以宏观地看到 财 政业务的整体情况，又可以微观地观察到具体某预算单位某天支出的细节信息。多维分 析的时候，维度选择越多数据越细节 (划分得更细了 )，维度选择越少数据越汇

40、总越宏观。  这样一个中间一个大表形成主表，周围一组小表与主表相关联的结构，形态上呈星 星和雪花的形状，星型模型是数据仓库的数据模型与其他数据库应用相区分的一个重要 特征。  数据仓库典型的逻辑模型形状  第三章  数据抽取平台建设  数据转换平台是将分布式物理存储的源数据，转换到统一存储的数据仓库中。从分 布式源数据库中获取对财政一体化查询系统用户有用的数据、过滤掉不需要的内容、验 证数据的质量、数据清理、数据融合、到最后数据装载入数据仓库中。数据抽取是数据 进入仓库的入口，财政一体化查询系统涉及多个分布式数据源，需要通过抽取过程将数 据从联

41、机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。根据源 数据的不同性质，应选用不同的数据抽取方法。本系统中，对于 Oracle、 sybase 等关 系数据库中的数据，我们通过交易日志的方法进行数据抽 取，而对于其它半结构化或非 星型 雪花  数据仓库 技术架构 解决方案  结构化数据，我们选用静态数据、时间标记、文件比较等方法实现数据抽取。  3.1 设计原则   高数据质量原则：  保证进入数据仓库数据的质量，将垃圾数据排除在数据仓库之外。   自动化原则：  ETL 过程应尽量自动完成，减少人为干预程度

42、。   可追溯原则：  ETL 的相关工作结果，应留有痕迹，给出相应的报告，以便跟踪和分析。   参数化设计原则：  采用参数化的设计思想，减少编程的工作量，增强系统的灵活性和可维护性。   效率性原则：  采用并行处理等设计方法，减少 ETL 时间，提高 ETL 效率。   源系统不修改原则：  尽量不对源系统进行修改，将对源系统的影响降低到最低程度。   方便性原则。  设计应充分考虑系统运行后管理和维护的方便性和易用性。  3.2 ETL抽取过程设计  ETL 工具采用

43、 Cognos 产品本身的 ETL 工具  3.2.1 ETL 过程概述  ETL 流程是指源系统数据经过数据抽取、转换和加载处理进入数据仓库的整个过程。 ETL 流程主要包括以下主要步骤：  1. 数据抽取：  数据抽取就是将数据仓库需要的业务数据抽取到数据转换区的过程。（这里的数 数据仓库 技术架构 解决方案  据转换区也可以仅仅是一个逻辑的概念，即数据的抽取到转换采取数据不落地的方式完 成）  2. 数据检查和出错处理：  在数据转换区中，对源系统数据质量进行检查，形成检查报告，并进行相应的出 错处理，对于严重错误，需

44、要系统维护人员现场做出相应的处理。  3. 数据转换：  数据转换包括对源系统数据进行整理、剔除、合并、验证等一系列转换工作，最 后形成数据仓库物理数据结构所需的数据，存放在转换区的数据表中。  4. 数据加载：  数据加载将数据转换的结果数据加载到数据仓库，并形成数据加载情况的报告。  3.2.2 ETL 过程详述  本期项目 ETL的过程具体描述如下：  第一步： 数据抽取  在源系统上启动数据抽取控制程序，完成以下工作：  1、 数据采集  考虑到数据来源的多样性和复杂性，数据采集主要包括

45、：   对业务系统的数据采集：在日终结后，当日数据自动、增量地转储到数据备份机上，作为数 据仓库的数据源并成为数据备份策略的一部分。   对于税收计划、外部数据、纳税人财务报表的数据采集。可根据实际需要，采用多种途径。  2、 数据发送  在数据采集完成后，各系统上的抽取控制程序将数据文件和校验文件通过局域网发送到数据 转换区。  第二步：数据装入转换区  1. 检查数据是否到位  根据校验文件，检查源系统数据是否到位、是否存在传输错误等异常情况。如果数据不全或 传输出现错误，如果出错，将出错结果写入错误日志，重新执行第一步

46、。  2. 将外部数据文件装入 oracle 数据库  把来自外部源数据源的格式化数据转化成 oracle数据库、表结构。  3. 修改系统状态：  数据仓库 技术架构 解决方案  待该步骤工作完成后，将系统状态改为抽取工作完成。  注：若直接从业务系统数据库中抽取数据，则无须数据转换区步骤。  第三步：数据质量检查和出错处理  1. 状态检查：  查询参数表，如果数据抽取工作已经完成，开始执行该步骤工作。  2. 数据质量检查：  根据检查规则， 数据质量检查程序扫描源数据数据表，根

47、据规则检查数据是否合法，给出检查报 告和最终的数据质量报告并写入数据库，数据质量检查结果写入质量检查报告。  3. 出错处理：  如果出现严重出错，停止 ETL工作，需要系统维护人员现场做出相应的处理，修改正确后，重新执 行该步骤工作；对于警告级出错，继续进行下述步骤。  4. 修改系统状态：  待该步骤工作完成后，将系统状态改为数据质量检查工作完成。  第四步：数据转换  1、 状态检查  查询参数表，如果数据质量检查工作已经完成，开始执行该步工作。  2、 数据转换  根据数据仓库要求的数据源格式在

48、Staging Area中进行并行转换处理，并将转换的结果数据存放 在待装载数据存放区。  3、 生成转换报告  记录数据转换情况，并写入数据库转换日志中。  4、 修改系统状态：  待该步骤工作完成后，将系统状态改为数据转换工作完成。  第五步：数据加载   状态检查  查询参数表，如果数据质量检查工作已经完成，开始执行该步骤工作。   数据装入数据仓库  采用非依赖数据并行加载的策略，将待装载数据区的数据装入中心数据仓库，如果标准代码表发 生变化，数据装载程序将标准代码的变化情况增量加载到数据仓库代码

49、表中。   数据加载情况报告  记录数据加载情况，并写入数据 仓库数据库的参数表中。   修改系统状态：  待该步骤工作完成后，将系统状态改为数据转换工作完成。  第六步：加载时间维  1. 状态检查  查询参数表，如果数据加载工作已经完成，开始执行该步骤工作。  数据仓库 技术架构 解决方案  2. 加载时间维  根据当前的时间，依据数据集市多维模型，完成时间维的加载工作。  3. 修改系统状态：  待该步骤工作完成后，将系统状态改为时间维加载工作完成。  第七步

50、：加载事实表  1. 状态检查  查询参数表，如果时间维加载工作已经完成，开始执行该步骤工作。  2. 加载事实表  以数据仓库数据为数据源，依据数据集市多维模型，完成事实表的加载工作。  3. 修改系统状态：  待该步骤工作完成后，将系统状态改为事实表加载工作完成。  第八步：加载聚合表  1. 状态检查  查询参数表，如果事实表加载工作已经完成，开始执行该步骤工作。  2. 加载聚合表  以事实表为数据源，依据数据集市多维模型，完成聚合表的加载工作。  3. 修改系统状态

51、：  待该步骤工作完成后，将系统状态改为 ETL工作结束。  3.2.3 ETL 时间约束  数据抽取的范围涉及财政核心业务系统数据，主要是五大块内容：税收收入数据、 非税收入数据、部门预算、支出数据、专项支出数据、其他系统数据。其中：其他系统 数据包含固定资产、统发工资等相关财政业务系统数据。平台在数据抽取时根据用户对 数据的查询需求，可以实时、按天、按月取数。  是指对在每天的特定时间必须要完成的事件进行严格的控制。对时间的限制建议可以表示为下 图：  数据仓库 技术架构 解决方案  8: 00 加载 数据 集市 E T L 转换

52、 抽取 6: 005: 004: 003: 002: 001: 000: 0 0 图 4-2： ETL时间阶段示意图  从上图可以看出，为了保证每天业务人员及时使用数据仓库系统，对 ETL时间通常有如下要求：   3:30 之前完成数据从源系统到数据转换区的数据抽取工作。   5:00 之前完成数据转换区内的数据转换工作。   6:00 之前完成转换后数据到数据仓库的数据加载工作。   8:00 之前完成数据仓库到数据集市多维数据库的 ETL 工作。  ETL的时间窗口通常在 4-6小时，考虑到将来系统数据的增长， ETL工具的处理效

53、率和扩展性是关键。  3.3 后台对应规则的设置  平台中的数据由于来自不同的业务系统，各数据的编码可能不一致，系统能与后台 设置各编码的进行对应关系管理；  用户对预算单位 设置用户与预算单位对应关系；  用户对会计科目 设置用户与会计科目对应关系；  用户对功能科目 设置用户与功能科目对应关系；  用户对经济科目 设置用户与经济科目对应关系；  用户对预算项目 设置用户与预算项目对应关系；  用户对收费项目 设置用户与收费项目对应关系；  用户对指标类型 设置用户与指标类型对应关系；  用户

54、对资金来源 设置用户与资金来源对应关系；  单位对会计科目 设置预算单位与会计科目对应关系；  数据仓库 技术架构 解决方案  单位对功能科目 设置预算单位与功能科目对应关系；  单位对经济科目 设置预算单位与经济科目对应关系；  单位对预算项目 设置预算单位与预算项目对应关系；  处室对单位 设置财政归口部门与预算单位之间的对应关系；  用户对归口 设置用户与财政归口部门之间的对应关系；  预算项目对执行项目 设置预算项目与执行项目之间的对应关系    3.3.1 数据抽取程序的设计原则 &n

55、bsp;数据仓库需要的数据存在于不同种类、不同技术平台的业务系统中，数据抽取就是 从这些不同的数据源中抽取数据作为数据仓库的原材料。本项目数据抽取设计时，采用 以下方法：  1. 直接从源业务系统抽取最原始的数据，不抽取派生数据。  2. 只抽取源系统中本期项目需要的数据库表。  3.3.2 数据抽取方式  1. 初始抽取  数据初始抽取指按照需求设计要求，把数据仓库要求的各业务系统的数据源一次性抽取并加载到数 据仓库，本项目初始抽取的数据范围为源业务系统当天日终后的数据。  初次加载时间可定为投入运行的当月业务系统处理结束后进行。

56、 2. 增量抽取  在数据仓库系统投入运行后，只抽取业务系统的增量数据到数据仓库，增量数据包括业务系统新增 数据和变化数据两部分，采用增量抽取的方法确保每次最小的数据子集加载到数据仓库里。  第四章  数据整理平台建设  数据整理平台实现数据仓库中当前数据、综合数 据、历史数据的组织和整理。通过 数据抽取平台获取的各业务数据，从逻辑上和业务上是独立的、分散的，要实现一体化 的查询功能，必须对分散的业务数据进行抽取和整合。如将分散的单位基础信息、预算 数据仓库 技术架构 解决方案  数据、支出数据通过一定的策略，整理形成一套编码统一、业务连贯的数据体系，这是 一体化查询系统成功的关键。  数据整理平台基于各业务数据，可以根据不同的用户查询需求，定制数据整理策略。 根据查询