【巨杉案例】:大数据司法查询平台

2023-10-08 13:20

本文主要是介绍【巨杉案例】:大数据司法查询平台,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1、前言

公检法机关因审理经济纠纷案件或经济犯罪案件需要向银行查询企业事业单位、机关、团体的银行存款或者查阅与案件有关的会计凭证、账册、报表等档案资料,银行应当积极配合。在查询或者查阅时,人民法院应当向银行出具正式公函,由银行行长(主任)指定具体的业务部门负责提供有关的情况和资料并派专人接待。查阅人对需要的资料可以抄录、复制或照相,但不能借走。人民法院对银行提供的资料应当保守秘密。

人民检察院侦查机关在办理职务犯罪案件时,尤其是贪污贿赂案件,到商业银行查询犯罪嫌疑人的账户相关交易流水和凭证是一个重要的获取线索和证据的途径,这也是商业银行的一项法定义务。然而在实际操作过程中,侦查机关到商业银行开展查询工作时却因为历史数据查询上的困难,导致查询工作效率低下。

对于历史数据而言,超过三至五年的数据,银行会采用离线存储的方式将数据归档至磁带库或光盘库。当侦查机关向银行提出司法查询请求时,银行工作人员需要将带库中的离线数据导出成在线数据,以供查询使用。带库数据的导出操作是非常耗时,耗力的过程,故导致司法查询进展缓慢。

2、面临的挑战

因为司法查询需要查看单位或个人银行账户的所有交易流水,所以银行需要提供所有历史数据用以查询。针对此类需求,银行均要安排相关系统工作人员导出离线数据以供查询使用。在此需求环境下,银行急需一种有效的解决方案将银行工作人员从繁重的导数作业中解放出来。

司法查询的数据是银行存储了几十年的历史数据,且会涉及多个业务系统,如核心系统、信用卡系统及网银系统等。故其数据有以下特点:数据量庞大、业务系统众多及新旧系统更替等。针对以上特点,解决方案需要解决以下几点需求:

离线数据在线化:整个解决方案的重点即在于消除司法查询中的离线数据导出工作,而最效有效的解决之道则在于把离线的数据进行在线化。离线数据在线化后,司法查询则只用将在线数据查询出来给到相应检查部门。因为司法查询不像核心交易查询如此频繁,所以也不可以使用大中型乃至小型机作为数据在线化的硬件存储平台。

各业务系统数据统一管理:因为司法查询涉及众多业务系统,所以进行司法查询时,需要到各业务系统平台进行数据查询。这种查询方式带来了极大的人力消耗成本。离线数据在线化需要将各业务系统数据进行统一管理,后续的司法查询只用在一个平台即可查询所有相关数据。

新旧系统数据整合银行的各系统在整个历史中进行了多次的升级改造,这就导致了新旧系统之间数据存储设计上存在着极大的差异。为了能提供高效、便捷的司法查询,新旧系统之间数据的整合也是必不可少。

提供高效的数据查询离线数据进行在线化的同时,也要保证数据查询的高效性。只有两者均达到,司法查询才能真正摆脱低效率查询的境地。

3、解决方案

司法查询平台由下到上可分为数据采集层、数据存储加工层和数据应用层。数据存储加工层是司法查询平台的核心,主要基于SequoiaDB分布式数据库和Spark内存分析框架构成。基于此架构,司法查询的离线数据实现在线化及实时查询。

 

3.1数据采集层

数据采集层的主要作用是为数据存储加工层提供司法查询所需的各业务系统数据。ODS取数平台通过将新旧核心、新旧信用卡及网银等业务系统准备的历史数据采集回来,将采集的数据统一格式,再通过SFTP、FTP和CD等网络传输方式提供给数据存储加工平台。


3.2数据存储加工层

数据存储加工层主要工作是完成司法查询数据的统一存储和加工处理。数据采集层传输至数据存储加工层的数据主要分为存量数据和增量数据。根据此两类数据,SequoiaDB+Spark构建的存储加工层完成数据的规划、入库以及加工处理。

存量数据存储存量数据是指截止某时间点已经落盘存储的数据,主要作为各业务系统的初始化数据进行存储入库。因为司法查询的历史数据所存储的量比较庞大,所以存量数据在入库前会根据系统类别、数据类别(流水与非流水)及数据量等维度进行数据规划。SequoiaDB数据库的Domain可根据系统类别完成数据规划,如新旧核心使用Domain1,新旧信用卡使用Domain2SequoiaDB的数据水平切分机制和时间序模型可根据数据类别及数据量等维度完成数据有序高效存储,如流水数据可根据客户交易日期采用时间序模型进行数据存储。数据规划完成后,操作员使用SequoiaDB Import工具将各系统数据导入SequoiaDB数据库。

数据模型去范式化由于新旧系统的更替及旧系统设计的历史性,同一套系统的新旧系统数据表结构存在极大的差异,且旧系统数据在存储大量历史数据的情况下也不利用数据的查询。众所周知,历史数据查询的难度在于在数据量表的多表JOIN查询。为了实现新旧系统数据统一和高效快速的查询,存储加工层需要根据司法查询需求对存量数据进行加工处理。数据加工通过Spark分析框架将存储于SequoiaDB中的数据根据新旧系统结构的统一规划完成数据加工处理,如将所有数据打平成流水表及非流水表。

增量数据同步增量数据指存量数据截止日期以后每日变更的数据,如新核心每天增加的客户及每天的交易流水数据等。SequoiaDB数据库存储的数据需要与在线交易系统(如新核心、新信用卡)保持T-2数据的一致。

3.3数据应用层

离线数据完成在线化之后,数据的应用并不局限于司法查询(即公检法查询),也可以用于历史数据定制查询和管理员查询等诸多用途。司法查询因为其低频率的查询使得在线数据在绝大部分时间里均未被使用。在不影响司法查询的前提下,在线存储数据的价值应该被发挥出来,如银行网点对历史数据的查询和银行管理员查询等。数据应用层使用SequoiaDB API、SequoiaDB SQL和SparkSQL等方式从数据存储加工层获取数据,并将获取的数据在WEB前端页面进行数据展示。

4、项目成果

离线数据低成本在线存储SequoiaDB数据库采用分布式架构,只需要普通X86 PC Server即可完成海量数据的高效存储。由于司法查询使用的业务数据存在离线化、海量化、分散性及查询低频性等特点,所以廉价的在线存储架构使离线数据实现在线化成为可能。


业务系统数据统一平台管理司法查询涉及多个业务系统,所以对多个业务系统数据的规划存储和统一管理则显得非常重要。SequoiaDB的Domain功能及元数据信息的有效管理很好的实现了多系统数据的统一存储及管理。


历史数据的实时查询:司法查询的数据存储在SequoiaDB分布式数据库之后,历史数据可以进行实时查询。SequoiaDB分布式存储+多索引机制达成一个司法查询请求任务秒级返回的结果。








产品特性
解决方案与案例 
数据库下载 
技术文档 

微信客服:
sequoiadb111



%$(LAXO}X%1H2{JOLG640GP.jpg



这篇关于【巨杉案例】:大数据司法查询平台的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/165567

相关文章

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因?

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台,是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力,在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术,能够处理多种视频流格式,并以多种格式(RTMP、RTSP、HTTP-FLV、WebS

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于