巨杉应用案例:大数据司法查询平台
1、前言 公检法机关因审理经济纠纷案件或经济犯罪案件需要向银行查询企业事业单位、机关、团体的银行存款或者查阅与案件有关的会计凭证、账册、报表等档案资料,银行应当积极配合。在查询或者查阅时,人民法院应当向银行出具正式公函,由银行行长(主任)指定具体的业务部门负责提供有关的情况和资料并派专人接待。查阅人对需要的资料可以抄录、复制或照相,但不能借走。人民法院对银行提供的资料应当保守秘密。 人民检察院侦查机关在办理职务犯罪案件时,尤其是贪污贿赂案件,到商业银行查询犯罪嫌疑人的账户相关交易流水和凭证是一个重要的获取线索和证据的途径,这也是商业银行的一项法定义务。然而在实际操作过程中,侦查机关到商业银行开展查询工作时却因为历史数据查询上的困难,导致查询工作效率低下。 对于历史数据而言,超过三至五年的数据,银行会采用离线存储的方式将数据归档至磁带库或光盘库。当侦查机关向银行提出司法查询请求时,银行工作人员需要将带库中的离线数据导出成在线数据,以供查询使用。带库数据的导出操作是非常耗时,耗力的过程,故导致司法查询进展缓慢。 2、面临的挑战 司法查询的数据是银行存储了几十年的历史数据,且会涉及多个业务系统,如核心系统、信用卡系统及网银系统等。故其数据有以下特点:数据量庞大、业务系统众多及新旧系统更替等。针对以上特点,解决方案需要解决以下几点需求: 离线数据在线化:整个解决方案的重点即在于消除司法查询中的离线数据导出工作,而最效有效的解决之道则在于把离线的数据进行在线化。离线数据在线化后,司法查询则只用将在线数据查询出来给到相应检查部门。因为司法查询不像核心交易查询如此频繁,所以也不可以使用大中型乃至小型机作为数据在线化的硬件存储平台。 各业务系统数据统一管理:因为司法查询涉及众多业务系统,所以进行司法查询时,需要到各业务系统平台进行数据查询。这种查询方式带来了极大的人力消耗成本。离线数据在线化需要将各业务系统数据进行统一管理,后续的司法查询只用在一个平台即可查询所有相关数据。 提供高效的数据查询:离线数据进行在线化的同时,也要保证数据查询的高效性。只有两者均达到,司法查询才能真正摆脱低效率查询的境地。 3、解决方案 3.1数据采集层 3.2数据存储加工层 存量数据存储:存量数据是指截止某时间点已经落盘存储的数据,主要作为各业务系统的初始化数据进行存储入库。因为司法查询的历史数据所存储的量比较庞大,所以存量数据在入库前会根据系统类别、数据类别(流水与非流水)及数据量等维度进行数据规划。SequoiaDB数据库的Domain可根据系统类别完成数据规划,如新旧核心使用Domain1,新旧信用卡使用Domain2。SequoiaDB的数据水平切分机制和时间序模型可根据数据类别及数据量等维度完成数据有序高效存储,如流水数据可根据客户交易日期采用时间序模型进行数据存储。数据规划完成后,操作员使用SequoiaDB Import工具将各系统数据导入SequoiaDB数据库。 数据模型去范式化:由于新旧系统的更替及旧系统设计的历史性,同一套系统的新旧系统数据表结构存在极大的差异,且旧系统数据在存储大量历史数据的情况下也不利用数据的查询。众所周知,历史数据查询的难度在于在数据量表的多表JOIN查询。为了实现新旧系统数据统一和高效快速的查询,存储加工层需要根据司法查询需求对存量数据进行加工处理。数据加工通过Spark分析框架将存储于SequoiaDB中的数据根据新旧系统结构的统一规划完成数据加工处理,如将所有数据打平成流水表及非流水表。 增量数据同步:增量数据指存量数据截止日期以后每日变更的数据,如新核心每天增加的客户及每天的交易流水数据等。SequoiaDB数据库存储的数据需要与在线交易系统(如新核心、新信用卡)保持T-2数据的一致。 3.3数据应用层 4、项目成果 业务系统数据统一平台管理:司法查询涉及多个业务系统,所以对多个业务系统数据的规划存储和统一管理则显得非常重要。SequoiaDB的Domain功能及元数据信息的有效管理很好的实现了多系统数据的统一存储及管理。 历史数据的实时查询:司法查询的数据存储在SequoiaDB分布式数据库之后,历史数据可以进行实时查询。SequoiaDB分布式存储+多索引机制达成一个司法查询请求任务秒级返回的结果。 SequoiaDB巨杉数据库2.6最新版下载 SequoiaDB巨杉数据库技术博客 SequoiaDB巨杉数据库社区 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |