数据仓库在税务系统的应用现状

昨天在网上看到了一个关于数据仓库在税务系统的应用现状的帖子，如获至宝，马上收之：

全国税务做数据仓库的比较少, 成功的应用更是少. :-(
我知道的情况是如下的:

项目 主要应用方面 开发商 进度
1.青岛国税 征管 Oracle Finish
2.南京地税 征管 Sybase Finish(好象做的不是很好)
3.武汉地税 征管 吉林某公司 Finish(近乎报表系统)
4.南京地税 金力四期, 征管, 行政等 TOP or Prient 起步
5.广东国税 征管 fenet finish
6.国税总局 fenet pending
7.北京国税 pending

这是我所知的, 运用好象不是很多, 而且主要的也是在征管方面.
南京地税将要开始的项目将是很大, 很全面的. good luck!

在税务行业进行数据仓库方面,特别是数据挖掘的应用探讨是非常有价值的,我最近就碰到这方面的问题,比如偷漏税预测等,希望大家能踊跃讨论一下.

税务的数据环境比较乱，业务直接受政策的影响。另外，征上来的税如何管理跟政策也非常紧密。恐怕在征管分析中，目前能分析并且需要分析的东西更多是集中在一些分类统计、偷税分析、税务结构分析等方面了。

其实税务数据仓库是一个非常有前景的领域：

1.税务数据量很大，而且相对比较整齐（比起统计系统、 公安系统等）
2.税务要做的分析很多，除了对征管行为进行分析为，对一些专题可以做很深入的分析，包括发票分析、稽查选案、两权监督等

另外税务系统也投入大量的财力进行税务信息化建设，金税工程三期要将全国的税务信息系统重新翻一变，能保留的保留，不能保留的就重新做，实现其“一个网络，一个平台，四大系统”的战略目标。其中很重要的一块就是数据仓库和决策支持系统。而且税务数据仓库系统有一个很重要的特性是其数据仓库系统与业务系统可以同时做，这与冲突的数据仓库建设有很大的差别，需要有新的系统架构方法和实施手段，其中很重要的部分就是实时数据仓库（RTDW，RealTime DW，）或称之为Active DW，这样把数据仓库的应用从战略决策扩展到战术决策，例如发票发售环节，原有业务系统有一定的监控，但是不能对该企业的发票历史情况作很多的分析，有了实时数据仓库后就能根据企业的历史状况做更深入的、更灵活的分析。有关实时数据仓库是一个很大的题目，我们可以另找时间仔细讨论。

但是税务数据仓库建设也是一个很具有难度的过程：

首先，税务业务很繁杂，而且随政策变化大
其次，表单证书很多，有兴趣的话看看征管规程，差不多有800多张业务的表单证书，其次还有很多会计、统计和分析的表，狂多，而且表格很繁杂，一般的前端工具很难实现。

因此，税务数据仓库只能用不断增长的方式，实现一部分功能后逐步扩展，很难在系统的初级阶段就规划很完整的企业级数据仓库架构。需要结合EDW架构、元数据管理和数据集市循环式增长的方式不断完善。

希望熟悉税务数据仓库以及对税务数据仓库感兴趣的人多多讨论

有几个问题请教一下，显然税务中的计算比较多而且复杂，你是否倾向于数据仓库中还是参考征管系统等原型设计，不作大量拆分、合并等？而把很多计算的工作放在前端工具来完成，只是针对一些效率低下的报表、查询等就事先生成好数据以达到优化的目的

另外一件事情，金税工程的网络带宽好像层次不齐，听说有的地方甚至要拨号上网，这种情况下如何进行realtime dw的数据上下传输？数据的实时上传可能还容易一点，但不可能下面每个地区直接联到上一级甚至上上一级的数据仓库进行分析吧？ 数据下传我觉得问题会更大一些

这得根据具体情况设计多个Layer，包括数据加载层、数据管理层、数据分析层等，而且每一个层还可以继续划分，如果需要的话，我不赞成把很多计算工作放在前端工具来完成。

金税数据的传输按目前的带宽在地市一级无法实现RTDW，但是在总局已经实现了全国金税数据的抽取和集中。

to cxgtommy

有一个问题请教一下：

Datastage可以利用远程的Agent实现广域网的数据抽取、传输、转换和加载吗？如果这么做，数据传输的效率、安全性是如何保证的呢。

目前的税务数据仓库多停留在数据查询和数据浏览、报表方面，因此对实时性要求较高。真正用于各种深层次的分析（至少在业务系统无法或难以进行的分析）好象还不多。不过还好，至少在数据 ETL 方面已有小成，积累了不少经验，再逐步完善分析主题即可。blueplum 提了不少家在做税务数据仓库，加上我知道的一些，不算少了，突然想到如果有一套税务数据仓库标准该多好啊，可以节省大量的重复工作，而且展望税务数据仓库之路：市级——省级——全国的建设会顺畅的多。

to blanc

首先，datastage没有agent。如果从远程抽取数据特别是网络情况不稳定的时候最实际的办法还是先把数据下载成文件，加上crc校验、压缩以及加密后，ftp到总部然后进行抽取。其中目前datastage 5.2版的话，有crc校验跟ftp的部分，压缩和加密这两部分需要跟外部工具集成，在下面要发布的datastage 6版会包含压缩和解压的功能，传输还是会推荐用第三方工具或者手写的程序。如果中间能采用像mq series这样的中间件产品，ftp、crc、压缩和加密都不需要了，这些可以通过mq来实现。我也看过informatica的传输部分，在税务的现有架构上传输数据也无法独立适应。如果说谁更适应这种情况的传输恐怕还要算是mq,tipco,webmethod等EAI的专业厂商，像datastage和informatica也都有跟这些产品集成的部分。

to y2000jh

其实做成功一个地方后，其他地方却是可以作为样板戏。但问题是税务系统各个地方政策相差挺大的，这些东西会让你提炼共性的时候很难受。 相对这点，银行和电信会好很多

to blueplum

听起来好像深深体验到项目的痛苦之处，能否道来听听？

做项目是训练大喜大悲承受能力的良药：）

应该是不以物喜不以己悲吧

to cxgtommy

我原来听一个客户说，他听DataStage可以用Agent进行远程的数据抽取和传输，我当时也比较怀疑，可能是他听岔了。对广域网的数据传输，Informatica提供了一个产品叫Informatica PowerChannel，其数据源接口可以是PowerMart，也可以是PowerChannel带的一个选项，负责从远程业务系统中抽取数据，PowerChannel负责传输、加密和压。PowerChannel也支持文本数据的抽取和传输。传到目的地后，可以转换为文本文件或由PowerMart/PowerCenter导入数据仓库中，可以说其解决方案是比较全面的。

另外的一种方法就是你提到用MQ或者Tibco、Webmethods、Vitia等MOM，但是这些MOM的传输效率比较低，MQ可能好些，以为它是用队列进行管理的，但是MQ的传输效率估计不到FTP的40%，而Tibco、Webmethods、Vitia等产品本身设计就不是用来传输大数据，效率有很大问题，就象用飞机来运钢铁一样。而税务的数据量很大，估计很难适应。

to y2000jh

除了bluePlum提到的那些，你还知道哪些税务局已经实施或者正要实施数据仓库阿。

北京地税在98年就开始数据仓库的建设了，还是非常早的。
集成商是联想系统集成公司，现在的神州数码。
ETL：自己写程序
OLAP Server： Oracle Express
当时DW的规划和建设是很好的，但Express嘛...好像很不好用，升级到6.3版本后可能稍微好了些。
还有一个问题是数据的质量。由于网上申报还没有全面铺开，大量的数据是聘用临时人员集中录入的，所以数据不是很准确，也影响了使用。

所以，数据仓库建设得是否成功，能否取得较高的投资回报，不仅仅取决于技术，而用户业务模式的合理性是至关重要的。

用 Oracle Express实施这么大的系统，呵呵，不过 Oracle Express的压缩技术还可以，几百万条记录的Cube，存储空间才几十MB。

不是吧，北京地税的大的cube都有将近1G呢，有时更新一夜都完不成，不知道6.3怎么样

已经实施数据仓库的还有：

山东地税
青岛地税

lazylion能介绍一下如何使用Express的压缩技术吗？这方面我一直想找人请教一下，如果几百万条纪录要能压到几十兆确实很诱人。

没做过，有什么好的经验不妨交流交流

其实我是个菜鸟，涉及BI才一个多月但是boss说要我搞国税的BI开发：）
上面的经验的确是个启发，神州数码的产品我昨天见他们安装，装了两个多小时还没有完成，不知道是不是他们系统太过庞杂的缘故，北京的那个好象使用的是DTS来实现ETL的：）

我现在使用的是 ORACLE数据库，其中的数据ETL该怎么做？还有是实时加载数据怎么做？他们说要一天更新一次数据。

现在越来越多的税务机关开始建立自己的数据仓库了，在以前我也是从来没有接触过这方面的工作，这是第一次，也刚刚做。现在在工作中遇到了很多的问题，希望大家能够多多指教呀！
我想知道一些ETL过程的具体实现与该如何去做？

Cube的大小还和维度的多少有很大的关系吧。

看不到下面的回复，只有先顶一下

etl->dw->olap->展现. 我一般将BI分为四个部分.你想咨询哪个环节的问题,能否说具体一些.

SPSS 与南京国税有过交流. 不知是否采用了.

河北地税的数据仓库已经上线了

国税总局的数据仓库项目是神州数码开发的，有两套版本，其中一套前端用了FENET的BI OFFICE，我怎么就不明白那么多人都说总局的数据仓库项目是FENET开发的呢，而且FENET也很乐意接受的样子。

补充：
1、狂多的表证单书和流程，相当一部分对于税务的数据分析来说没用，因为其中很多属于行政范畴。
2、税务是咱国计民生的饭碗，税务和其他行业的关系太密切了，例如GDP、财政、工商、海关、外汇管理局、地方经济特点，且国地分开，不像其他行业，在自己的业务圈子里就能做很多事情，这也是现在的税务数据仓库只能做表，不能做里的一个原因。
3、什么分析啊，挖掘啊，现在还是很难做的，因为业务模型还没建立起来。

数据仓库是面向主题的，这个主题就是说需要许多业务主题，那么对于税务来说真正的自己的业务主题数据却是十分的少，不象电信，当然，很难了。 分析是也是针对业务来研究的，这里的业务不是事务，业务是跟事务不一样，比如：移动上班接受处理工单这是事务，而市场推出GPRS上网这是业务。

我是亲自参与了南京地税数据仓库的，我觉得你需要你问问南京地税数据仓库当时他们要什么，需求是什么——用户方需要把他们在OLTP系统中的600多个无聊的查询抽出来整理出来就是他们的数据仓库需求，这个也他们组织一个所谓由南京大学某教授参与知道的需求分析组的需求分析。他们要的就是那些呀，你说能是叫税务数据仓库系统吗？上面的同志。。。还是去了解一下吧。。。知道内情的信息多着呢。。。。。

南京地税数据仓库系统一期工程
湖北省地税数据仓库系统一期工程
浙江地税数据集中分析系统
。。。。。

项目 主要应用方面 数据库厂商 （开发商）进度
1.青岛国税 征管 Oracle Finish
2.南京地税 征管 Sybase （SYBASE）Finish(好象做的不是很好)
3.武汉地税 征管 （SYBASE）开发商是北京中联而不是吉林某公司 Finish(近乎报表系统)
4.南京地税 金力四期, 征管, 行政等 TOP or Prient 起步（征管软件部分上线部分模块，DW部分还不没有动起来）

我接触很多税务所谓的数据仓库项目，其实基本上都是用一个多维的服务器，构建一些cube,然后把他们以前的查询，报表拿出来，形成所谓的需求，让大家做，把数据放入cube中，前端用一个什么报表工具，出一堆的报表。根据就没有数据模型，EDW等这一说。这就变成数据仓库，用户以及我们的公司都会非常开心的告诉别人，咋们又完成一个数据仓库项目。
我都不知道有十个还是九个这样的例子拉，悲还是喜？

税务行业也是如此，以上提到的税务行业居然没有提到中软的~~太不可思议了！！！广东地税大集中的项目是国内第一个基于J2EE的省级集中项目，正在全国推广，不过数据仓库还没有上，但是上海财税的数据仓库项目正进行中，现在的数据仓库系统多是用些国外BI软件，以报表和查询为中心建套系统而已，离真正的分析和挖掘查得很远，不知道有没有做得比较好的~~

据说这个项目做得有点糟糕,设计性能几个方面有点问题,听说用户最有意见的主要还是性能问题,上线的那几个月反映情况的贴子好象把地税的论坛都挤爆了,纳税人和基层都在骂,客户也是骑虎难下,好象都陷入官司了
不知道现在有没继续做数据仓库,好象是没

嗯，看来我要有些心理准备了，各位大大多指教些。两年前某个市级的税务局先是上了一套我们的报表系统，就是一些简单的报表查询统计了，那时主要就是抽取一些数据，难点在于灵活的报表格式设计，现在这个已经不是问题。但说到分析，就没那么简单了。说得零零碎碎，先做着先。

哈哈。。。曾几何时我也卷到税务这个圈圈来了
中软开发的广东地税大集中现在终于开始DW一期招标了，标底1200万/1500万（对类似NCR软硬捆绑的解决方案），看到标书很务实的做法，一期只建DW平台，少做应用，不过纳税评估肯定有得做，
对征收数据的抽取要求每半天抽一次，还没要求做到实时，不过实时DW看来是很多行业项目的趋势要求，IBM对实时数据的抽取的方案开始采用IBM Websphear II+Datastage，
杂七杂八说了一通，争取一有空就上来报道一下广东地税这个数据仓库项目

广东地税数据仓库项目招标结束了，东软中标，合同额近1000万。
广东地税的业务系统，数据相对比较全面，实行的是全省数据实时集中方式，为数据仓库的建设
提供了比较好的数据基础。

选用的产品有IBM的数据仓库产品、ETL产品，海波龙的OLAP，Bo的展现工具。

本人参与该系统，所以上网收集了一下这方面的帖子，希望能和感兴趣的人探讨。

希望能多在方法论、业务建模方面多探讨，选用产品的应用技巧，也欢迎多探讨