安徽地税数据集中方案.docx

一、概述1.1背景安徽省地税在2006年全省上线运行了安徽征收管理系统ahtax2005，全省的信息化工作已经全面展开。但是系统是在各地市独立运行的，对于省地税来说，无法及时准确地了解全省的税收情况。另外，税务数据的省级集中也是一个大的趋势。为了执行国家税务总局要求税务数据全省集中，以及实际的需要，必须建设统一的数据中心，集合全省的数据。目前，安徽省全省共有17个地市，加上省属直接单位，共有18个业务数据库在运行，各地数据都在本地服务器存放，虽然全省已经实现17个地市的2M带宽的连接，但是要对全省的数据进行查询分析还是比较麻烦的。而且，由于各地税的数据是相对独立的，虽然应用的是同一套系统，但是由于各地的情况比较复杂，数据存在不一致的风险。因此，必须建立统一的数据模型，通过建立数据仓库整合数据，支撑全省查询分析的需要。1.2系统建设目标安徽地税数据中心的建设目标是：1、通过统一的数据存储平台，对数据进行标准化处理和规范化管理，实现数据透明和共享。目前各地市应用系统在线数据保存在不同的数据库中，各数据结构大致相同，但数据的一致性、统一性和规范性较差，数据共享十分困难。因此，通过数据中心构建安徽地税统一的数据服务平台，实现企业数据的统一规划、集中采集、集中处理和统一管理，形成地税数据的统一视图，实现数据透明和共享，充分发挥地税数据资源的价值。2、有效支撑统计分析及查询应用等功能。通过数据中心的建设，整合各地市、各业务系统等多种数据源，形成统一的业务数据视图，并采用统计分析、查询等方式满足各级专业和管理部门人员的不同要求。3、在完成前两步目标的基础上，进一步建设全省的数据仓库，支撑更多的业务查询、统计分析、数据挖掘功能，提升管理和整体决策能力。1.3系统建设原则系统建设遵循以下原则：Ø 整体规划，分步实施， 循序渐进，步步见效；Ø 有效控制项目风险；Ø 保护投资的长期有效性，资源能得到有效利用；Ø 为数据和应用大集中做好准备。二、技术方案数据仓库体系结构如下图所示：整个数据仓库系统是一个包含四个层次的体系结构：数据源：是数据仓库系统的基础，是整个系统的数据源泉。通常包括内部信息和外部信息。内部信息包括存放于关系数据库中的各种业务处理数据和各类文档数据，外部信息包括各类法律法规、经济统计信息等等。数据存储与管理：是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。其中，数据的存储与管理在数据仓库中通常按照三个层面进行存储和管理：操作数据存储区（ODS）、数据仓库（DW）、数据集市（DM）。在线分析服务器（OLAP）：对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：关系型在线分析（ROLAP）、多维在线分析（MOLAP）和混合在线分析（HOLAP）。ROLAP基本数据和聚合数据均存放在关系数据库之中；MOLAP基本数据和聚合数据均存放于多维数据库中；HOLAP基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。前端工具：主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。2.1操作数据存储区（ODS）2.1.1ODS的定位操作数据存储（ODS）是应用数据库与数据仓库之间的桥梁，在ODS中系统地进行数据整合使数据仓库系统的时效性不足得以弥补，提供统一完整的企业视图和准确的运营数据信息；通过集中简化的信息提取过程，提高业务运行效率；更有效地统计分析税务信息，为实现安徽地税内部自动化的信息和业务流程提供便利条件。ODS的建立实现对税务数据的清理整合，构筑一个统一的、完整的数据平台，确定数据所有者，建立数据同步机制，统一数据编码定义，建立数据访问机制，实现业务系统数据共享，完成应用与数据分离，实现数据从地市到省级的提升。ODS在安徽地税数据集中方案中可以发挥以下几个方面的作用：n 作为数据仓库的主要数据源ODS数据库对应用系统的数据进行了清洗、转换和整合，存储了较为详细和全面的业务运行数据，ODS数据库中的数据不仅具有较高的数据质量，而且比应用系统更有利于数据仓库对数据进行获取和进一步转换，是数据仓库的主要数据来源。n 提供报表和查询统计功能ODS从不同的应用系统中采集数据，整合各个应用系统的共享数据，形成企业级数据的整体视图，实现综合统计和报表查询功能。n 进一步引导需求通过ODS的建设及建立在其上的应用，进一步启发新的业务需求，为数据仓库的建设打下基础。2.1.2数据抽取、转换与加载（ETL）2.1.2.1 数据源安徽省地税数据中心需要采集的业务基本数据包括：n 税务登记n 核定管理n 申报征收n 发票管理n 票证管理n 行政执法n 税费检查n 会统管理这些数据主要从以下一些生产作业系统获得：n 安徽地税征收管理系统ahtax20052.1.2.1.1税务登记1、目标：获取纳税人信息等。纳税人基本登记信息，应缴税种信息，纳税人当前状况，证照信息等。2、信息交换方式：直接访问数据库。3、通信呼叫方式：纳税人新信息每日定时上传（访问）一次，若当日没有数据则不需要上传。4、数据文件名称与内容：1）税务登记信息：纳税人名称，经营地址，行业信息，开业时间，纳税人状态，所属税务机关，科室代码，注册类型代码，主营范围，兼营范围，经营方式，注册资本，工商登记等。2）纳税人缴税信息税种代码、税目代码、缴税频率（按月、季、半年、年等），限缴期限。3）纳税人状态信息停复业登记，注销登记、非正常户确认，纳税人迁移。4）证照信息证件打印，封存、缴销、作废、遗失。2.1.2.1.2核定管理1、目标：获取定期定额纳税人的税收信息。核定税款信息，核定社保费信息。2、信息交换方式：FTP访问数据库。3、通信呼叫方式：本地核定操作后，每月定时往数据中心系统ETL服务器传送本地网的所有核定信息；或通过各本地网接口服务器直接访问。4、数据文件名称与内容：1）核定税款信息核定时期，核定所属期，申报年月，核定的税种、税目，核定税额。2）社保费核定信息核定时期，核定所属期，申报年月，核定的税种、税目，核定费额。2.1.2.1.3申报征收1、目标：各地市的申报征收开票信息。2、信息交换方式：FTP访问、直接访问数据库。由于涉及较大的数据量，考虑到服务器的压力，建议通过FTP的方式间接访问数据局库。3、通信呼叫方式：每月定时传送（访问）二次。征收期过后一次，月末一次。4、数据文件名称与内容：1）申报信息企业编码，申报日期，申报税种、申报税目，申报日期，限期申报日期，申报所属期，申报类型，预算级次，预算科目，记税金额，申报税款，减免税款，是否零申报，金库编码2）开票信息企业编码，开票日期，入库日期，欠税属性编码，限缴日期，开票税金，减免税金，计征税金，税率、金库编码，预算级次，款项类别，税票号码，开户银行，银行账号3）减免税信息企业编码，减免税种、税目，减免类型，减免期限，减免比率或减免金额4）延期申报信息企业编码，延期税种、税目、税款所属期、延期缴纳时间、延期理由5）欠税信息 企业编码，税种编码、税目编码、税款所属期，欠税金额，欠税属性编码2.1.2.1.4发票管理1、目标：各地市发票计划、印制、库存等信息2、信息交换方式：直接访问数据库。3、通信呼叫方式：每日定时上传（访问）一次。4、数据文件名称与内容：1）发票计划信息发票名称，计划领购数量2）发票印制信息承印单位，发票代码，印制数量、印制价格。3）发票操作信息发票发出数量，发票入库数量，发票核销等。4）发票账务信息发票记账信息、结账信息。2.1.2.1.5票证管理1、目标：各地税票信息2、信息交换方式：直接访问数据库。3、通信呼叫方式：每月定时上传（访问）一次。4、数据文件名称与内容：1）票证领单票证编码，发出机关，领入机关，字轨，票号，数量。2）票证领据票证编码，发出机关，用票人编码，领用数量，字轨，票证号码范围，数量。3）票证结报票证编码，用票人，结报类型，结报数量，字轨，票证号码范围。4）票证上缴票证编码、用票人，上缴单位，数量、字轨，票证号码范围。2.1.2.1.6行政执法1、目标：各地行政处罚数据2、信息交换方式：FTP访问。3、通信呼叫方式：每日定时上传（访问）一次。4、数据文件名称与内容：1）处罚案件登记案件名称，纳税人编码，处罚原因，案件来源，处罚类型，处罚方式，违章原因。2）处罚案件情况表案件编码，处罚依据，处罚金额，处罚时间，处罚类型。2.1.2.1.7税费检查1、目标：各地稽查和税费检查情况数据：2、信息交换方式：直接访问数据库。3、通信呼叫方式：每日定时上传（访问）一次。4、数据文件名称与内容：1）案件情况表案件编号，企业编码，企业名称，行业编码，检（稽）查所属期，检（稽）查时间，案件检（稽）查单位，案件状态，结案时间，立卷时间，是否立案，是否大要案，检查人员，审理人员，执行人员。2）案件检查情况案件编号，查处税种，查处税目，查处期间，查处金额，税款类型，预算级次，款项类型，所属金库编码，处罚机关，征收机关编码。2.1.2.2 数据源分析数据源可以做如下分类：（1）按照数据类型：流水型数据记录增量产生，原记录不能修改的数据，该类数据通常按照一定的周期，根据时间戳传送特定的纪录。例如：系统的字典表和关键的辅助表：BM_SZ，BM_SM等。混合型数据记录既可以增量产生，原记录又可以修改的数据，该类数据通常按照一定的周期，对数据进行整表传送。税收数据大部分都是这种类型的数据。税收的大部分数据都是这种类型：比如登记信息表，征收表等。（2）按照数据量：大数据量数据量达到每天百万条记录以上。从全省的角度来讲，申报表和开票表接近这个数据量。中等数据量数据量为每天一万条记录以上。其他业务数据。小数据量数据量低于每天万条条记录。基本上比较少，如部分文书表等。（3）按照数据周期：实时、日周期、月周期、年周期、不定周期。2.1.2.3 数据抽取、转换、加载ETL即数据抽取、转换和加载，是数据中心实现过程中，将数据由数据源系统向数据中心加载的主要过程。从功能上看，整个ETL包括三个部分： 1. 数据抽取：从数据源系统抽取数据中心系统需要的数据；2. 数据转换：将从数据源获取的数据转换成数据中心要求的形式，对数据进行转换；3. 数据加载：将数据装入数据中心。ETL实现过程的流程图如下图所示：在ETL的整个过程中，还必须充分考虑异常情况的处理。2.1.2.3.1 数据抽取2.1.2.3.1.1 数据抽取接口1、直接访问接口直接访问方式是在对方数据库上建立接口表（或视图），本系统通过数据链接直接获取对方数据，然后进行处理的数据通信方法。该方法适用于双方数据库在同一台服务器上或在同一个局域网内。2、FTP方式在省中心配置ETL服务器，在ETL服务器上安装并启动FTP服务，外部系统需要发送给本系统的数据由相关外部系统定期或按需将需要传送的数据按要求组织成文本格式文件，通过FTP上传到本系统的ETL服务器。n FTP文件存放位置在省级ETL服务器中，统一建立针对外围不同系统存放文件的总目录，并以本地网为单位设置相应子目录，子目录名称为各本地网名称的全拼拼音字母，用来存放各本地网上传的文件；n FTP文件命名规则用文件扩展名区分数据文件类型，结构类型不同的数据文件其扩展名将不同。文件扩展名长两位，每位取值范围从0-9、A-Z；文件名前半部分分两种情况：u 对于每天生成的数据文件，取文件内数据发生的日期，具体文件格式：yyyy（年）mm（月）dd（日）.?。u 对于每月生成的数据文件，则取文件内数据所属的帐务月（或统计月），具体文件格式：yyyy（年）mm（月）.?。n FTP文件格式可以按照各系统和实际情况，灵活设置FTP文件的格式，如：文本文件的分隔符采用逗号方式，记录结束标识为换行/回车；或采用字段定长，记录定长的方式。n FTP文件传送完成确认方法由于数据文件可能很大，FTP传送可能是个漫长的过程，本系统接口处理程序不知道数据文件什么时候传送完毕。因此，在此要求每个数据文件传送完成之后，再传送一个数据文件传输完成的确认文件，该确认文件以要确认传送完毕的数据文件扩展名后加字符A，文件类容仅仅包含要确认传送完毕的数据文件名。一批传送多个数据文件时，每一个数据文件对应一个确认文件。例如：要上传一个20021024.A1的数据文件，确认文件名为20021024.A1A,确认文件内容为：20021024.A1。2.1.2.3.1.2 数据抽取策略数据的抽取必须能够充分满足数据中心的需要，又能保证不影响业务系统的性能，所以进行数据抽取时应制定相应的策略，包括抽取方式、抽取时机、抽取周期等内容。l 抽取方式：增量抽取、完全抽取等。l 抽取时机：尽可能避开业务系统的高峰时段，可选择在夜间业务系统比较闲时进行。l 抽取周期：对不同类型的数据源，应综合考虑业务需求和系统代价，制定合理的抽取周期。在制定抽取策略时，需要对以上各项因素综合考虑。通常情况下，流水型增长且数据量大的数据适合采用增量抽取的方式；变化更新的数据适合采用完全抽取的方式；对于两者结合的数据，如果能提取增量信息，则进行增量抽取，否则采用完全抽取的方式进行。此外，对于抽取周期要考虑实际业务的需求和抽取进行的系统代价，在可能的情况下，尽量缩短抽取周期。2.1.2.3.2 数据转换数据转换是指对从业务系统中抽取的源数据根据数据中心模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性，并按要求装入数据中心。2.1.2.3.2.1 数据转换的主要功能数据转换主要完成由于以下原因造成的数据不一致性问题：1 源数据系统同数据中心系统在模型上的差异性；2 源数据系统平台不一致：数据中心系统的数据源可能包括基于不同平台的数据库的数据，可能会存在大量的转码工作。；3 源数据结构的不一致：有些数据源由于历史的原因，导致同一个表在不同的时期数据结构不一致；4 源数据定义不规范导致错误数据；5 对数据的约束不严格，导致无意义数据；6 存在重复记录。2.1.2.3.2.2 数据转换技术和策略根据实际情况，数据转换工作一般会在以下几个环节中具体实现：1 在抽取过程中进行数据处理；2 使用异步数据加载，以文件的方式处理；3 在数据加载过程中进行数据处理；4 进入数据中心以后再进行数据处理。采用在数据抽取过程中进行数据转换时，必须考虑抽取的性能以及对业务系统性能的影响；采用异步数据加载需要以文件方式处理时，必须充分考虑中间磁盘的存储量以及ETL整个流程的协调性工作，以及大量的非SQL语句的编程；采用在数据加载过程中进行数据转换时，必须考虑加载性能；采用先将数据装载到数据中心后再处理时，必须考虑数据中心引擎的海量数据处理能力。2.1.2.3.3 数据加载2.1.2.3.3.1 数据加载主要功能数据加载就是将从数据源系统中抽取、转换后的数据加载到操作数据存储区或数据仓库系统中。要求数据加载工具必须具有高效的加载性能。2.1.2.3.3.2 数据加载技术及策略主要加载技术：1. 使用数据仓库引擎厂商提供的数据加载工具进行数据加载；2. 通过数据仓库引擎厂商提供的API编程进行数据加载。数据加载策略要考虑加载周期及数据追加策略两方面的内容。根据安徽地税业务数据的实际情况，加载周期要综合考虑业务分析需求和系统加载的代价，对不同业务系统的数据采用不同的加载周期，但必须保持同一时间业务数据的完整性。数据的追加策略根据数据的抽取策略以及业务规则确定，一般有以下三种类型：直接追加、全部覆盖、更新追加。l 直接追加：是指每次加载时直接将数据追加到目的表中。对于典型的流水数据，一般采用此方法；l 全部覆盖：对于抽取数据本身已包括了数据的当前和所有历史状况，对目标表采用全部覆盖方式。l 更新追加：对于需要连续记录业务的状态变化，用当前的最新状态同历史状态数据进行对比的情况采用更新追加的方式。具体采取何种方式，要综合考虑效率、业务实现等因素。2.1.2.4 数据审计每个数据加载周期中，如何保证数据中心中数据同业务系统中数据在业务意义上的一致性及数据的准确性极其重要。因此，必须引进数据审计功能。数据正确性的审计工作是在数据加载工作完成以后,一方面要从设计到实施的整个过程中确保算法的正确性，另一方面要通过事后的检验来检查ETL的正确性。理想的情况是，审计工作必须在数据抽取、转换、加载等所有的阶段都要进行，比如，如果采用异步数据抽取和加载，则在数据抽取传输完毕后，要从记录数、文件大小等角度检验抽取和传输的正确性。数据加载完毕后，一方面通过加载日志检验加载过程的正确性，另一方面要通过业务规则来校验数据的正确性。2.2数据仓库（DW）数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。根据数据仓库概念的含义，数据仓库拥有以下四个特点：1. 面向主题。操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。2. 集成的。面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。3. 相对稳定的。操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。4. 反映历史变化。操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。2.2.1主题数据库数据仓库里的数据都是按照业务主题进行组织的。主题数据库的基本特征如下：1面向业务主题(不是面向单个报表)。主题数据库是面向业务主题的数据组织存储，例如，对于安徽地税来讲，需要建立的典型的主题数据库包括：税务、申报、发票、票证、行政执法、税费等数据库的结构，是对有关税务、发票、税费的数据项进行分析整理而设计的，不是按税务、发票、税费的原样建立的。这些主题数据库与税务管理中要解决的主要问题相关联，而不是与通常的计算机应用项目相关联。2信息共享(不是信息私有或部门所有)。主题数据库是对各个应用系统“自建自用”的数据库的彻底否定，强调建立各个应用系统“共建共用”的共享数据库。不同的应用系统的计算机程序调用这些主题数据库。3一次一处输入系统(不是多次多处输入系统)。主题数据库要求调研分析各业务层次上的数据源，强调数据的就地采集、就地处理、使用和存储，以及必要的传输、汇总和集中存储。同一数据必须一次、一处进入系统，保证其准确性、及时性和完整性，经由网络-计算机-数据库系统，可以多次、多处使用。4由基本表组成。一个主题数据库的科学的数据结构，是由多个达到“基本表”(BaseTable)规范的数据实体构成的，这些基本表具有如下的特性：原子性基本表中的数据项是数据元素（即最小的、不能再分解的信息单元）；演绎性可由基本表中的数据生成全部输出数据（即这些基本表是精练的，经过计算处理可以产生全部企业管理所需要的数据）；规范性基本表中数据满足三范式(3-NF)要求，这是科学的、能满足演绎性要求、并能保证快捷存取的数据结构。在设计的同时，关键是要做好数据字典的维护工作，以使你对自己的数据库了如指掌。2.2.2数据存储数据仓库为安徽地税各级管理部门、分析人员的分析、决策操作提供统一、集成的基础数据，包括安徽地税各个业务部门当前及其历史的细节性业务数据，以及为了进行分析决策操作而生成的分析型数据，是一个统一、集成、稳定、基于历史数据的庞大数据集合，需要借助成熟的数据库技术对其进行存储管理，即利用改造过的关系数据库系统来组织和管理面向主题的数据仓库中的数据。2.2.2.1 整合业务数据的基础数据层数据仓库系统的基础数据是按照主题来组织的。基础数据层只考虑数据本身的来源与属性，按照业务本身的数据之间的相互关系来组织数据，而不考虑数据的应用，即“整合数据”，其目的在于减少数据的冗余，提高系统的灵活性，能快速的实现新增主题和功能。2.2.2.2 面向决策支持的分析数据层应用数据层与具体的应用需求紧密结合，按照应用的要求来组织基础数据层的数据。面向应用，其目的就是针对面向主题，面向具体的应用，提高访问、执行、查询的效率，即“面向决策支持”。2.2.2.3 数据仓库信息模型数据仓库信息主题，主要包括：税务登记、核定管理、申报征收、发票管理、票证管理、行政执法、税费检查、会统管理等，按照安徽地税信息的组成进行前瞻性的结构设计。2.2.3数据展现数据仓库系统应提供灵活多样的展现方式。目前常用的展现方式有：固定（预定义）报表、图表、即席查询（Ad-Hoc）、多维动态分析等。各主题分析的展现方式除了可以通过以上方式进行展现，对于异常的分析结果还可以通过短消息、E-mail或其他告警方式进行预警。表格和图表可以转换为Excel等格式，分析人员可以根据需要排序、分组数据并改变图表的类型（直方图、饼形图、折线图、堆积图等），可在任何维度上通过“钻取”和“切片”生成报表及图形。复合报表要“所见即所得”。2.2.4数据挖掘数据挖掘(Data Mining)是从大量的、不完全的、有噪声的、模糊的、随机的数据中提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。随着信息技术的高速发展，人们积累的数据量急剧增长，动辄以TB计，如何从海量的数据中提取有用的知识成为当务之急。数据挖掘就是为顺应这种需要应运而生发展起来的数据处理技术。是知识发现(Knowledge Discovery in Database)的关键步骤。数据挖掘步骤一般包括定义问题、数据准备、数据挖掘、结果分析和知识运用等步骤。1、定义问题：清晰地定义出业务问题，确定数据挖掘的目的。2、数据准备：包括：l 选择数据：在大型数据库和数据仓库目标中提取数据挖掘的目标数据集；l 数据预处理：进行数据再加工，包括检查数据的完整性及数据的一致性、去噪声，填补丢失的域，删除无效数据等。3、数据挖掘：根据数据功能的类型和和数据的特点选择相应的算法，在净化和转换过的数据集上进行数据挖掘。4、结果分析：对数据挖掘的结果进行解释和评价，转换成为能够最终被用户理解的知识。5、知识运用：将分析所得到的知识集成到业务信息系统的组织结构中去。2.3系统平台要求2.3.1 系统容量规划2.3.1.1 用户数据量的估算用户数据量的估算与用户数、业务量、系统中数据保存期限、业务系统中单个数据记录容量有关。设数据量为T，估算公式如下：T=U*N*R*Ti其中：U：为安徽省地市税务局的数量；N：为某个地市年业务量。对于不同的地市可取业务量最大值进行估算；R：为单个数据记录的容量；Ti：为数据存储期限。2.3.1.2 数据仓库磁盘容量估算数据仓库系统的存储主要由三部分构成，按照数据仓库系统功能结构，自上而下分别是：多维数据存储，数据仓库存储，接口文件存储。总的存储是这三部分的和。令T为系统的存储总量，Ta为多维数据存储所需的存储量，Td为数据仓库存储所需的存储量，Ti为接口文件存储所需的存储量，三者单位均为GB，则 TTa +Td +Ti（一）接口文件存储所需的存储量（Ti）接口文件存储区主要用于存放生产系统传送到数据仓库系统的数据文件和一些数据仓库系统从其他系统抽取的部分数据文档。估算时可取存储空间最大的接口文件，其它类型的文件数据量可以按该最大接口文件数据量的一定比例来计算。由此可得出如下公式：TiU*(1+Pi)*Ni *Nu 其中，U为最大接口文件数据量，单位为GB Pi为其他类型文件所占比例因子，通常可取0.05 Ni为接口文件在数据仓库系统中的保存天数 Nu为用户数量（二）数据仓库所需存储量（Td）计算数据仓库所需的存储量，主要考虑操作数据存储区、数据仓库层和数据集市层存储所需的磁盘空间，其中数据仓库层占用绝大部分。这里需要考虑承载数据的数据库系统、文件系统、RAID、数据冗余等对存储的影响。这些系统所占用的空间都将折合成所需存储的纯数据量的比例因子。这里的纯数据由两部分构成：用户详单数据和客户资料数据。其中用户详单数据量可以由用户数，存储时间和单用户每天数据量得到，单用户每天数据量的计算公式已经在上节得出。则有如下公式：TdU*Nu*Nd*（1+Pdb+Praid+Pfs+Predu）其中，U为单个地市数据量的平均值或最大值，Nu为地市局数量，Nd为存储时间，Pdb为数据库相关因子，Praid为RAID相关因子，Pfs为文件系统和软件相关因子，Predu为系统冗余因子。（三）多维数据存储所需存储量（Ta）这部分所占的存储空间和应用相关，主要是多维分析所需要的磁盘空间。空间的大小取决于分析的业务数量、维度数量和层次、分类等因素，还和具体采用的产品相关。凡是和时间相关的多维分析，其所占用的空间计算公式如下：Ta(Dmea+Ddim*Ndim)*Nserv*Nfact*(NserdimNlevNtype)*Ptdim*Nkp*Ncpr其中：Dmea为事实表中度量字段的平均数据量，单位为GBDdim为事实表中维度字段的平均数据量，单位为GBNdim为事实表中维度字段的平均个数Nserv为多维分析业务类型平均个数Nfact为每个业务类型分析的事实表平均个数Nserdim为事实表中除时间维外的维度个数，一般为Ndim-1Nlev为事实表中维度的平均层次数Ntype为事实表中每个维度层次的平均类型个数Ptdim为时间维因子，如果分析到日，则为365，到月为12Nkp 为数据保存周期，单位是年Ncpr为多维数据压缩因子，和具体的产品有关（四）数据库压缩技术某些数据仓库产品中引入了独特的数据压缩技术，用于数据存储。对于分区表，可以选择压缩全部或部分分区。压缩属性可以在表空间、表或分区上声明。如果在表空间上声明，则该表空间中建的所有表都被压缩存储。大型数据仓库的压缩比例通常为2:1到4:1，某些业务的数据有可能获得更高的压缩比，具体的压缩比与数据的类型和存储的顺序有关。2.3.2 配置要求2.3.2.1数据仓库系统主机服务器与存储设备假设安徽地税的数据仓库服务器和ETL服务器是分离的，并且不包括对固定报表的访问，因为这部分报表已经以静态数据的方式存放在WEB服务器上，对数据库不产生压力。则对数据仓库服务器的处理能力要求主要来自于对数据库的实时查询。假设：安徽地税数据仓库系统的用户数为Nu系统的最大并发数为用户总数的10每次查询平均调用100个指标每查询5个指标折合成1个标准交易系统在3秒中内完成处理则数据仓库主机所需要的TPMC为：（100/5）×Nu×10×60/32.3.2.2 ETL系统主机服务器与存储设备ETL服务器主要的处理工作包括以下方面：接收生产系统提供的源数据或从其他系统抽取数据。(我们将这个工作简称为W1)将接口文件包含的数据进行格式转换，进行数据清洗，重新整理，生成新格式的记录插入数据库中或形成文件，装载入数据仓库中，整个过程要求在一定的时间内完成。（我们将这个工作简称为W2）以上的工作流程为串行关系，数据仓库服务器的处理能力要求为：MAX（W1处理能力要求；W2处理能力要求）。（一）W1处理能力需求分析我们使用下列的条件对W1进行处理能力需求分析：所有工作每日要求在1小时内完成；平均抽取150条记录所需的事务数为1；考虑到处理过程中可能遇到的业务高峰期和用户数不可预料的增长情况，服务器的处理能力冗余30%。则，W1需要的TPMC为：TPMC（W1）每日抽取的记录数/（处理时间*60）*处理一条记录所需的事务数 * 30%（二）W2处理能力需求分析我们使用下列的条件对W2进行处理能力需求分析：所有工作每日要求在2小时内完成；平均处理6条记录所需的事务数为1。则，W2需要的TPMC为：TPMC（W2）记录数/（处理时间*60）*处理一条记录所需的事务数根据以上的分析，ETL服务器的处理能力要求为：MAX（W1处理能力要求；W2处理能力要求）同时我们需要考虑下列因素：增加服务器处理能力的20%，需运行数据仓库管理等应用；考虑到处理过程中可能遇到的高峰期和用户数不可预料的增长情况，服务器的处理能力冗余30%。根据实际系统经验，接口系统有时接口文件的生成时间会延迟，为了保证数据处理的及时性，以及未来业务的发展和系统扩展性的保证，建议TPMC实际考虑时适当扩大。2.3.2.3网络带宽网络带宽可以根据每分钟的业务量、每笔业务占多少流量、并发用户数来进行估算：网络带宽每分钟的业务量*每笔业务所占流量*并发用户数实际计算时考虑系统网络流量冗余30%。三、建议实施方案业务数据量估算（一年）：5G/地市*18地市90G3.1 只建设操作数据存储区（ODS）该方案只建设操作数据存储区（ODS），不建设数据仓库。此时，在数据仓库体系中的操作数据存储区实际上起着安徽地税数据中心的作用，负责将各地市业务数据集中到省局数据中心，并在此基础上提供基本的统计、查询功能。3.1.1硬件方案主机采用小型机，建议IBM P595或同等档次机型。数据存储存储2-3年的数据量：90G*3270G网络省局数据中心的网络环境，主干网带宽支持100M以上，省局数据中心同各地市之间的网络带宽支持10M以上，数据批量ETL占用2M网络连接。3.1.2工具平台数据库使用Sybase数据库。ETL工具建议自行开发。3.1.3软件方案固定报表：提供固定（预定义）报表及模板、图形展示、导入导出等功能。综合查询：提供自定义报表、图形展示、导入导出等功能。3.1.4工作量及费用估算工作量估算如下：建设内容工作量估算（人*月）ODS建设开发调研3ETL过程设计6数据库设计5软件开发30试点（1-2）地市数据抽取、加工3数据质量审核3软件功能完善10推广全省范围推广30培训和维护20合计110费用估算如下：110人月*2万/人月220万（RMB）3.1.5 进度计划初步计划项目启动时间为4月初，进度计划如下：3.2 同时建设操作数据存储区（ODS）和数据仓库（DW）该方案先建设操作数据存储区，将各地市业务数据集中到省局数据中心，并提供简单的统计和查询功能。同时，在此基础上建设数据仓库，以支持更丰富的业务查询、综合统计、多维分析、数据挖掘等功能。此方案中的操作数据存储区是实际意义上的数据仓库的一部分，其作为数据仓库与数据源之间的一个临时数据缓冲区，存储少量的、短期的数据，所有的数据最终都加载到数据仓库中。3.2.1硬件方案主机数据仓库采用小型机，建议IBM P595或同等档次机型。操作数据存储区（ODS）可以与数据仓库物理独立，也可以与数据仓库物理在一起。如果操作数据存储区与数据仓库物理独立，则操作数据存储区也可以采用PC服务器。数据存储操作数据存储区：存储1-3个月的数据量：90G/420G数据仓库：存储近5年的细节数据、汇总数据、多维数据、未来5年的数据量：90G*5+(90G+汇总数据+多维数据)*5=1500G网络省局数据中心的网络环境，主干网带宽支持100M以上，省局数据中心同各地市之间的网络带宽支持10M以上，数据批量ETL占用2M网络连接。3.2.2工具平台数据库使用Sybase数据仓库服务器。ETL工具建议自行开发。BI工具常用BI工具有：BO、Cognos、MSTR。市场参考价格约100万RMB。3.2.3软件方案固定报表：提供固定（预定义）报表及模板、图形展示、导入导出等功能。即席查询：提供自定义报表、图形展示、导入导出等功能。多维分析：提供多维动态分析（钻取、切块、切片）、复合报表等功能。数据挖掘：提供趋势分析、预测分析、关联分析、意外分析、原因和影响分析、What-If分析等功能。3.2.4工作量及费用估算工作量估算如下：建设内容工作量估算（人*月）ODS开发调研3ETL过程设计6数据库设计5软件开发30试点（1-2地市）数据抽取、加工3数据质量审核3软件功能完善10推广（其它地市）全省范围推广30数据仓库需求调研和分析5开发主题数据库设计30数据展现