2022年2022年集中式系统的分布式通用查询框架设计 .pdf

《2022年2022年集中式系统的分布式通用查询框架设计 .pdf》由会员分享，可在线阅读，更多相关《2022年2022年集中式系统的分布式通用查询框架设计 .pdf（3页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、71集中式系统的分布式通用查询框架设计白剑斐，叶绿宽，杨文钧，丁宁(广东省国家税务局信息中心，广州 510080) 摘要：针对集中式系统的查询功能存在设计复杂、查询速度慢、时效性差等问题，提出一种建立在分布式数据源基础上的通用解决方案，将大量数据进行分发，并采用反向的数据访问方式，以提高查询效率，增强扩展性，降低程序复杂度。实现一种可继承的组件装配式查询方案，可以简化开发部署工作，对不断变化的各种形式的业务需求做出快速响应。关键词： 集中式系统；通用查询框架；依赖注入；模板化设计Design of Distributed General Query Framework in Centraliz

2、ed System BAI Jian-fei, YE Lv-kuan, YANG Wen-jun, DING Ning (Information Center of Guangdong Provincial Office SAT, Guangzhou 510080, China) 【Abstract 】The query function for a centralized system is usually hard to design and costs a large number of server resources. A solution based on distributed

3、data source is discussed to solve these problems, which uses an inverse data access method to improve querying efficiency and reduce programming complexity. It also contains an inheritable module-assembling query scenario to simplify the process of development and deployment, in order to meet the co

4、mplexity of business requirement. 【Key words 】centralized system; general query framework; dependency injection; template design计算机工程Computer Engineering第 36卷第 20 期Vol.36 No.202010 年 10 月October 2010 软件技术与数据库文章编号：10003428(2010)20 007103文献标识码：A 中图分类号：TP311.521 概述随着计算机硬件性能的提高和业务模式的成熟，越来越多的组织选择建设大集中式业务

5、系统。这种模式将业务系统集中部署在总部高性能的应用服务器和数据库上，各地分支机构用户通过浏览器远程访问进行业务操作。相比以前分支机构自己搭设业务系统的做法，这种模式提升了业务规范性，保证了数据安全，并大大降低了系统维护的成本和风险。广东国 税 2006 年 上 线 全国 统 一 的中 国 税收 征 管 信息 系 统(CTAIS)后，征管水平得到了大幅提升1。由于集中式业务系统的数据存放在统一的数据库中，随着业务的持续开展，该模式在查询功能和数据应用方面的弊端逐步显现出来，主要体现在以下 3 个方面：(1)查询速度越来越慢。部分核心表的记录数快速增长，甚至达到千万乃至亿级，导致基于这些表的查询速

6、度无法忍受。为了解决这一问题，往往需要投入大量资金不断升级硬件，并大量采取索引、 表分区等数据库优化技术以及加工表、数据仓库等 BI(商业智能 )技术。这大大增加了系统的复杂性，却只能将查询时间控制在分钟级2。(2)查询时效性差。由于查询功能大量采用加工表、数据仓库等技术，生成加工数据需要大量占用系统资源和时间，因此数据加工往往在晚上和周末进行，生成的数据可能滞后一天、一周甚至一月，这经常造成用户苦等数据的状况，不利于缩短业务反应时间。(3)数据的生产者拿不到第一手的数据。基层是数据的生产者，集中式系统上线后，出于安全考虑，基层用户往往无法直接访问数据库，只能使用系统提供的查询功能。这些功能往

7、往无法满足批量统计等各种个性化查询需求，用户需要从分散的功能模块中获取数据并手工进行计算，大大增加了工作量。新的查询需求从需求分析、设计、测试到最终部署，需要一个非常长的周期。为了解决这些问题，广东国税在征管辅助系统二期设计开发的过程中， 对查询模块进行攻关，设计出了一套分布式、方案化的通用查询框架。该框架的主要设计目标是：(1)高性能。实现全局统计到明细数据的多用户并发查询，并将查询时间缩短到秒级。(2)通用性。能够满足各种查询类型的需求，为用户提供丰富的交互手段。(3)快速开发部署。开发者可以通过拖拽和配置的方式短时间内开发出新的查询功能，并上传至服务器完成部署，无须进行编译和服务器重新配

8、置。本文查询框架在J2EE 平台上实现，采用分层式设计思想，涉及 Spring、Groovy、Ajax 等主流服务器和客户端技术。2 分布式数据源为了从根本上解决数据查询的效率问题，需要建立一组分布式数据源。 应用服务器在将数据写入生产数据库的同时，将同样的数据异步写入主查询数据库。主查询数据库定期通过 ETL 的方式将数据按生产者的区域进行增量分发3。由于每次分发时传输的数据量较小，因此可以每半天甚至每小时同步一次，大大提升了数据时效性。查询服务器维护到查询作者简介：白剑斐 (1985)，男，工程师、硕士，主研方向：大数据量核心业务系统设计，B/S 系统的用户体验优化；叶绿宽、杨文钧、丁宁，

9、工程师收稿日期：2010-04-20 E-mail ：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 3 页 - - - - - - - - - 71集中式系统的分布式通用查询框架设计白剑斐，叶绿宽，杨文钧，丁宁(广东省国家税务局信息中心，广州 510080) 摘要：针对集中式系统的查询功能存在设计复杂、查询速度慢、时效性差等问题，提出一种建立在分布式数据源基础上的通用解决方案，将大量数据进行分发，并采用反向的数据访问方式，以提高查询效率，增强扩展性，降低程序复杂度。实现

10、一种可继承的组件装配式查询方案，可以简化开发部署工作，对不断变化的各种形式的业务需求做出快速响应。关键词： 集中式系统；通用查询框架；依赖注入；模板化设计Design of Distributed General Query Framework in Centralized System BAI Jian-fei, YE Lv-kuan, YANG Wen-jun, DING Ning (Information Center of Guangdong Provincial Office SAT, Guangzhou 510080, China) 【Abstract 】The query fun

11、ction for a centralized system is usually hard to design and costs a large number of server resources. A solution based on distributed data source is discussed to solve these problems, which uses an inverse data access method to improve querying efficiency and reduce programming complexity. It also

12、contains an inheritable module-assembling query scenario to simplify the process of development and deployment, in order to meet the complexity of business requirement. 【Key words 】centralized system; general query framework; dependency injection; template design计算机工程Computer Engineering第 36卷第 20 期V

13、ol.36 No.202010 年 10 月October 2010 软件技术与数据库文章编号：10003428(2010)20 007103文献标识码：A 中图分类号：TP311.521 概述随着计算机硬件性能的提高和业务模式的成熟，越来越多的组织选择建设大集中式业务系统。这种模式将业务系统集中部署在总部高性能的应用服务器和数据库上，各地分支机构用户通过浏览器远程访问进行业务操作。相比以前分支机构自己搭设业务系统的做法，这种模式提升了业务规范性，保证了数据安全，并大大降低了系统维护的成本和风险。广东国 税 2006 年 上 线 全国 统 一 的中 国 税收 征 管 信息 系 统(CTAIS)

14、后，征管水平得到了大幅提升1。由于集中式业务系统的数据存放在统一的数据库中，随着业务的持续开展，该模式在查询功能和数据应用方面的弊端逐步显现出来，主要体现在以下 3 个方面：(1)查询速度越来越慢。部分核心表的记录数快速增长，甚至达到千万乃至亿级，导致基于这些表的查询速度无法忍受。为了解决这一问题，往往需要投入大量资金不断升级硬件，并大量采取索引、 表分区等数据库优化技术以及加工表、数据仓库等 BI(商业智能 )技术。这大大增加了系统的复杂性，却只能将查询时间控制在分钟级2。(2)查询时效性差。由于查询功能大量采用加工表、数据仓库等技术，生成加工数据需要大量占用系统资源和时间，因此数据加工往往

15、在晚上和周末进行，生成的数据可能滞后一天、一周甚至一月，这经常造成用户苦等数据的状况，不利于缩短业务反应时间。(3)数据的生产者拿不到第一手的数据。基层是数据的生产者，集中式系统上线后，出于安全考虑，基层用户往往无法直接访问数据库，只能使用系统提供的查询功能。这些功能往往无法满足批量统计等各种个性化查询需求，用户需要从分散的功能模块中获取数据并手工进行计算，大大增加了工作量。新的查询需求从需求分析、设计、测试到最终部署，需要一个非常长的周期。为了解决这些问题，广东国税在征管辅助系统二期设计开发的过程中， 对查询模块进行攻关，设计出了一套分布式、方案化的通用查询框架。该框架的主要设计目标是：(1

16、)高性能。实现全局统计到明细数据的多用户并发查询，并将查询时间缩短到秒级。(2)通用性。能够满足各种查询类型的需求，为用户提供丰富的交互手段。(3)快速开发部署。开发者可以通过拖拽和配置的方式短时间内开发出新的查询功能，并上传至服务器完成部署，无须进行编译和服务器重新配置。本文查询框架在J2EE 平台上实现，采用分层式设计思想，涉及 Spring、Groovy、Ajax 等主流服务器和客户端技术。2 分布式数据源为了从根本上解决数据查询的效率问题，需要建立一组分布式数据源。 应用服务器在将数据写入生产数据库的同时，将同样的数据异步写入主查询数据库。主查询数据库定期通过 ETL 的方式将数据按生

17、产者的区域进行增量分发3。由于每次分发时传输的数据量较小，因此可以每半天甚至每小时同步一次，大大提升了数据时效性。查询服务器维护到查询作者简介：白剑斐 (1985)，男，工程师、硕士，主研方向：大数据量核心业务系统设计，B/S 系统的用户体验优化；叶绿宽、杨文钧、丁宁，工程师收稿日期：2010-04-20 E-mail ：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 3 页 - - - - - - - - - 73查询方案可以存储在文件系统或数据库中，当用户请求一个 新

18、的 查 询功 能 页面 时， 方 案解 析 器才 读入 查 询方 案XML ，这样在部署和修改查询配置时，不会对服务器造成任何影响 (如图 3 中的 1)，无需停机进行。对于经常被访问的功能，查询框架会自动将它们缓存起来以提升性能。方案解析引擎将查询方案解析为HTML 文件，在解析过程中，监听器上的动态语言脚本被执行，Dataset 和控件被翻译成HTML片段和 JavaScript 代码。解析完成后，服务器将HTML 文档发送到客户端，方案解析引擎的实例被销毁(如图 3 中的 2)。客户端浏览器根据接收到的HTML 文件中的代码， 创建查询方案中定义的Dataset和控件对象 (如图 3 中

19、的 3)。数据展现控件绑定在Dataset 上，当控件值被改变时，Dataset 的参数相应改变，而 Dataset返回数据时，控件的值也随之改变，这样大 大简 化 了客 户 端业 务 逻辑 ，无 须 编写 任 何代 码。 当Dataset中的元数据被提交，服务器端Dataset 创立后 (如图 3中的 4)，查询框架根据Dataset 的标示符，向方案解析引擎查询数据访问方式， 并将其注入到Dataset中(如图 3 中的 5)。Dataset 从分布式数据源获取数据(如图 3 中的 6)，发送到客户端(如图 3 中的 7)。客户端 Dataset接收到查询结果后，刷新与之绑定的控件 (如图

20、 3 中的 8)，将结果展现出来。图 3 查询方案解析过程查询结果展现时往往需要将其中的代码转换为文字。为了简化开发过程的工作量，进一步提升系统性能，本次项目没有采用在编写SQL 查询语句时连接代码表的方法，而是在系 统 主 界 面 上 定 义 了 一 组 用 于 查 询 代 码 表 的 被 动 加 载Dataset。当查询结果字段在展现前需要进行转码时，对应的代码 Dataset被加载，并通过哈希连接的方式快速匹配。由于代码 Dataset 加载时可以根据用户的权限和功能模块等信息只加载一小部分代码表内容，因此在涉及到机构、人员等数据的代码转换时，这种匹配往往比在数据库中进行连接操作更省时。

21、当用户翻页或访问包含此字段的其他功能时，由于代码 Dataset已经被加载过， 可以直接进行匹配， 进一步提高了性能。5 继承式方案设计装配式查询方案提供了灵活强大的可定制性，因此开发者需要为各个控件设置属性和事件处理代码，开发量较大，且容易造成不同的查询功能间操作方式和界面的差异。为了解决这一问题，将开发者从机械重复劳动中解放出来，本项目参照面向对象的思想，为查询方案设计了继承的特性。这种继承是单向的、基于通配符匹配的、覆盖式的。首先，设计基方案，其中定义以“*”号命名的查询条件表单、数据展现表格、弹出式子窗口等控件，设置了其大小样式等信息。 接着，为每种不同的展现形式设计了样式方案，如部门

22、统计、人员清册等，它继承了基方案，并包含一系列以前缀或后缀加“ * ”号命名的控件，如用于展现部门统计信息的表格 *_BM等，其中定义了多个名称包含通配符的列，如部门 BM、金额*_JE、比例*_BL 等，列的宽度、对齐方式、代码转换等属性在其中被设置。然后，为相似的功能模块设计了功能方案，它继承了样式方案，并包含与业务相关的属性和事件处理代码，如在表格统计区显示汇总数、单击机构列表可进行下钻等。以上方案为抽象方案，不能被方案解析引擎解析，只能用于继承。最后，当设计实际查询方案时，只需指定继承于一个功能方案，并将控件按方案中的控件名称命名，方案解析时就可以自动获得继承链上所有抽象方案中的属性和

23、事件处理代码。方案继承示例如图4 所示。图 4 方案继承示例通过继承的方式，查询方案的开发变得非常简单。如需要添加一个数据展现表格时，只需要指定标示符和需要绑定的 Dataset，并根据绑定的Dataset 中的字段自动创建列即可。表格会根据被继承的抽象方案中的样式恰当地展现出来，并按照方案中设置的事件处理方式响应交互。查询方案可以覆盖抽象方案中控件的属性和事件处理代码，以满足个性化的需求。另一方面，当抽象方案中的属性和事件处理代码被修改时，所有继承于该方案的实际查询方案随之改变，降低了代码维护量。通过继承式的设计方法， 利用可视化编辑器带来的便利，开发者几分钟就可以设计出一个新的查询方案，这

24、大大提高了对业务需求的响应能力，解放了开发人员的生产力。熟悉数据结构的业务人员经过简单培训后，就可以自行设计并对本级和下级发布查询方案，提升了整个机构的数据应用水平。6 性能测试选择正常纳税人查询这一具有代表性的业务需求进行测试，在同一分局、行业、税收管理员的查询条件下，查询耗时如表 1 所示。表 1 查询性能对比s省局市局区局分局方式统计前 20 条统计前 20 条 统计前 20 条 统计 前 20 条原始数据124.65112.1421.31 18.75 4.53 4.37 0.500.33 预生成统计数0.060.04 0.03 0.03从表 1 可以看到，直接查询省局原始数据时间过长，用户难以接受，将数据分发到区县局，可以有效地缩短查询时间，大大提升用户体验。使用查询框架可以将省、市局的预(下转第 77 页) 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 3 页 - - - - - - - - -