| 出版日期：2005-01-10 总期号：644 本年期号：02 |
|
 |
六问税务数据整合
受访人 北京地税信息中心副主任 赵伟、清华同方应用系统本部项目经理 陈鲸飞 1什么样的契机？ 记者：北京地税的数据整合是在什么样的背景下实现的？其目的是什么？ 赵伟：北京地税的数据整合契机，缘于2002年开始的税务大集中建设。2002年之前，由于技术条件限制，北京地税的数据是分布存放在北京市地方税务局和下属各区县分局。分局每个月拿着磁带库把一些数据从分局转移到市局，以便市局做查询、分析、决策支持，市局、分局的系统之间基本上没有交互。 2002年之后，北京地税觉得必须要对系统进行大集中改造，如果不改造，一是服务空间无法进一步扩大，如分局之间不能实现跨区县的交互；不能打破地域限制，为纳税人提供网上申报方式；无法实现面向全北京市的税务稽查。二是难以承受巨大的运营维护成本，原来市局、分局都有设备，全体加起来仅PC就有5000多台，遇到故障，经常觉得人手不够。 记者：清华同方在税务大集中扮演了什么样的角色？在数据整合中做了些什么？ 陈鲸飞：清华同方承担了北京地税综合业务系统的建设，主要负责建设北京地税核心征管系统，纳税评估、综合查询系统（主要是一个数据仓库项目），数据交换系统（包括内部应用系统整合和与外部的数据交换，如政府间联网，以及与国库联网），以及新旧系统过渡工作。 其中，涉及数据整合内容主要是新旧系统的数据迁移，也就是把旧系统的数据整合到新系统中。 
图1 集中模式示意图 
图2 管理数据集中 2整合内容有哪些？ 记者：北京地税的数据整合具体包括哪些工作？从技术角度看，数据整合的实现方式有哪些？北京地税采用了哪种方式？ 陈鲸飞：北京地税数据整合的具体内容主要有两部分，一是新旧系统的数据迁移；二是基于应用系统整合下的数据交换。 赵伟：从技术角度看，数据整合可以通过多种方式实现，如传统的基于数据的整合，也就是把数据集中放置在一个数据库中，这种方式可能会影响到系统的灵活性。 还有基于应用的整合，数据可以不集中到一个数据库，但可以通过数据交换实现共享应用。在北京地税的大集中建设中，北京地税与银行、工商、交通等其他部门之间的联网应用，就采用了这种方式。 还有一种是业界讨论比较多的基于服务的整合。所谓基于服务的整合，也就是目前IT界提出的网格计算概念。它把分布在不同地理位置的高性能计算机、数据库等IT资源用高速网络连接在一起，同时研究开发相应的中间件，使这些资源看起来就像一台单一映像的虚拟机器，用户不需要知道后台的系统情况，就可以共享资源，共同合作开展有关应用。 前两种方式在北京地税都有不同程度地应用。 3分几步实施？ 记者：北京地税是如何推进数据整合的实施？具体分哪些步骤？ 陈鲸飞：大概分四个阶段：一是进行需求分析。具体是从2002年6月，大集中项目组成立时，就开始做数据方面的工作。清华同方投入5、6个人专门做数据工作。 二是迁移规则的制订。清华同方和北京地税信息中心一起制定了一本近300页厚的文档，其内容都是关于迁移规则的，而且还不断补充整理一些新的规则录入文档。 其中，大部分内容是关于数据标准的，如新旧系统的数据字段分别是如何规定的，还包括正常情况和异常情况下的数据迁移怎么做。 三是数据试迁移和验证工作。规则制订完后，先要试迁，并对数据一个个进行验证，如果符合要求，就正式迁移到新系统，如果不行，就要找出问题，并提出解决办法。 这些工作要和北京地税信息中心一起做。因为对数据的验证结果是否满意，要由用户说了算。如果验证出错，可能会影响到后续的数据的正确性，甚至会影响到最终纳税人。 四是实际迁移。当前面的三个步骤都做好之后，实际迁移会很快，可能1～2天就能完成。 2004年1月1日，大集中系统正式上线之前，大部分数据的迁移工作已经基本完成了。从2004年1月至今，做的都是一些零碎的数据处理工作。 整个数据迁移的过程比较长，主要原因是数据量太大，北京地税22个分局的数据库分布在22个区县，一个个迁移到市局数据库中，其难度可想而知。 4整合难点是什么？ 记者：在北京地税的数据整合过程中，数据迁移、数据交换的困难分别是什么？如何化解？ 赵伟：像北京地税这样大规模的综合业务系统，不可能以理想的方式顺序推进，而是要求多个项目齐头并进，多个公司一起合作，因此，要作好多个系统之间的数据整合不是一件容易的事。 北京地税内部的数据整合比较容易实现，因为一切都是可控制的，如接口规范、标准，项目质量控制等。难的是跨部门之间的数据交换、数据共享，如税务部门与银行、工商部门之间的数据共享。 要想实现跨部门的数据共享，难的不是技术问题，而是应用层面怎么以一种有效的利益机制推进整合。 陈鲸飞：在数据迁移过程中，最大的困难是数据质量问题，其中，数据清洗是保证数据质量的重要一步。由于22个数据库里的数据千奇百怪，什么样的数据都有，数据量也很大，因此清洗比较麻烦。 最麻烦的是处理数据的异常，如新系统要求必须填写的数据项，而旧系统中没有，这种问题比较多。为此，需要专门编写补入程序，重新填写。 再比如，遇到垃圾数据时，也就是某些数据可能是无效的，把日期写成1800年或3000年，这时，只能先把数据归类，提出解决问题的建议，再与信息中心一起讨论怎么办。 另外，有些业务环节的数据比较混乱，可能不在数据库中，处理起来不是一件简单的事，这需要信息中心先想好怎么处理，才能往下进行。 数据交换实现起来相对不难，关键是系统交换的接口标准要提前制订好。由于当前的IT系统都支持web service标准，因此，数据交换比较容易实现。 记者：在22个数据库的数据迁移过程中，优先迁移哪些库？依据的原则是什么？ 陈鲸飞：主要有两个原则，一个是根据北京地税局的业务需要，比如税务登记数据、申报数据优先迁移，因为登记数据、申报数据是纳税人的基础数据，是税务业务中最重要的数据。 二是从系统设计角度，也有迁移的重点。一次数据特别重要，要先迁移，二次数据可以采用不同办法，有的可以直接迁移；有的可以不迁，而是通过一次数据重新生成。 5哪些经验值得分享？ 记者：北京地税在数据迁移、数据交换中有哪些成功经验？ 赵伟：首先要有一个统一、完整的规划，包括业务层面的战略规划，系统建设的技术规划等。为此，北京地税提出了“规划要大，起步要小”的实施原则。 其次，无论从业务角度，还是技术角度考虑，要提前把数据接口预留好，并制定好接口的规范、标准，这样实现起来就比较容易。 还要有一个好的可适应性的技术框架，只有这样，才能适应各种业务变化需求。 陈鲸飞：从实施经验来看，首先，数据迁移一定要以用户为主。毕竟数据是用户的，怎么迁移都要由用户说了算；厂商只是提供技术支持的，这种主次关系一定要明确。 其次，从技术角度来看，一定要做好数据规划，因为后续的数据清洗、迁移，都是在此基础上一步一步执行的。 另外，要选择一个好的数据迁移工具，在北京地税数据迁移中，我们是按照ETL的选择标准来选择迁移工具的。ETL是数据仓库中的一个概念，指的是数据的抽取、转换、加载，一般处理从业务数据库到数据仓库的转换工作。对于数据迁移来说，它同样适用；而且对于数据从旧系统到新系统的映射、转换，它相对比较容易实现。 6数据如何共享应用？ 记者：整合之后，在数据利用方面，北京地税有些什么打算和具体实践？北京地税在国内率先与国库、交通、工商等部门实现了联网应用，是如何实现的？ 赵伟：在数据利用方面，北京地税正在开展数据挖掘。数据挖掘是基于数据仓库的应用，技术实现不是难题，难在业务规则、业务模型的建立上。它需要税务行业专家、业务部门共同研究制定。目前，北京地税正充分发挥各个分局的优势。具体来说，在数据大集中平台上，北京地税为各分局提供了一个可读的数据共享平台，各分局可以结合自己的管理特点、管理思路，把数据抓取到分局，进行分析、统计、预测工作，并结合具体工作实践，制定有关业务模型。 经过一年之后，北京地税打算再把有关业务模型收集起来，放在用于决策支持的知识库里面，建立一个统一的规则库，这样，慢慢就可以为数据挖掘、决策、预测提供支持。 北京地税率先与国库、交通、工商等部门实现了联网应用，这是北京地税大集中建设中比较大胆的一个尝试。它是由北京地税的高层领导一个个地和其他部门的高层领导谈下来的。数据共享的背后是利益共享，只有当不同部门达成一致共识的时候，才可能实现数据共享。 
北京地税数据整合结构图 链接 数据大集中的模式 当前数据大集中可供选择的模式有：机器设备集中、物理数据集中和应用处理集中。 机器设备集中模式是指简单地将原来多个信息处理中心的设备进行集中；物理数据集中模式是指部门内部数据集中到同一台主机或多台主机构成的集群系统中，实现数据的集中存储和管理；应用处理集中模式是指在部门软件体系架构中实现一体化设计，以覆盖所有业务。 机器设备集中模式是技术方面最低层次的集中，一般可以被其他两种集中模式所包含，只是在信息化的初级阶段经常出现。物理数据集中模式在实际应用中常常容易和应用处理集中模式混淆在一起，主要是物理数据集中模式下应用往往是分离的，而应用处理集中模式下物理数据往往是集中的（如图1）。 不论是国内还是国外，物理数据集中模式和应用处理集中模式都是目前采用最多的两种模式。应用处理集中模式是最高层次的“集中”，打破了以往业务系统的界限，对业务、流程和管理进行重整，以实现企业信息架构的再造。当然，根据业务规模及地域分布情况，在应用处理集中模式中，跨国或全国性部门一般都有多个数据中心，如工商银行的南北数据中心。 另外，针对数据分散情况，原有分散在各地或各部门的业务数据也可以通过网络方式，集中存储到同一个主机（主机群），以便于管理，这种集中模式与业务应用无关，在这个集中模式下可以相应地开发管理应用，可称之为管理数据集中（如图2）。 当然，不排除可能出现 “数据物理分布、逻辑集中”的模式。 （中国人民大学 谭荣华 谢波峰 范广琳） 链接 几种大集中模式的比较 几种集中模式各有优劣。如果是缺少成熟、稳定的数据管理方案，那么首先采用机器设备集中模式较为妥当，该模式虽然会产生一些硬件设备上的重复投资，但是可以避免由于盲目性而带来的数据信息支撑体系的混乱。 就我国大部分行业的信息化程度而言，目前适合物理数据集中和管理数据集中模式，具体模式的选择可依据内部业务的相关度和进行管理的实时性要求而定。物理数据集中模式可以统一各种业务数据，克服由于数据分散带来的弊端，又没有应用处理集中模式中对业务方案及技术实现的高要求，就目前应用水平而言，不失为一种好的选择。 应用处理集中模式在框架设计中蕴含了对整体业务的通盘考虑，当然是各模式中效率最高的一种，但由于信息化发展规律所制约，那些对业务的理解程度没有达到一定水平的行业，如果硬要强行上马该模式，可能会导致“消化不良”。 在实际应用中，国外的大银行目前基本上采用的是应用处理集中模式。譬如，花旗银行（City Bank）在全球共有三个数据中心，分别为CEEMEA中心（拉美部分地区、中/东欧、中东、非洲）和拉美中心、亚洲中心，在基于统一的数据中心的基础上，按照对公业务应用（corporate application）、客户应用（consumer application）和公共应用（common application）实现业务处理系统的整合，并通过规定路径提供给银行员工及客户使用。 与技术层面的集中相对应的，还有业务集中及管理集中的需求考虑。选择技术层面集中模式的决定因素是业务集中及管理集中提出的需求。这种需求因企业、行业、部门的规模不同、业务要求不同而不同。对于实时性要求高的行业，如银行，可能只有应用处理集中模式才能满足它们的要求；对于实时性要求不高的行业，如税务部门，可以选择的余地就比较大，既可选择应用处理集中模式，也可以选择管理数据集中模式，甚至后一种模式可能还有更高的投入产出比率。 （中国人民大学 谭荣华 谢波峰 范广琳） |
||||||||||||||||||||||
