【公开招标】DZC20181678大庆市政府采购中心关于大庆市公安局(科信处)数据分析研判平台开发项目A招标公告
【公开招标】DZC20181678大庆市政府采购中心关于大庆市公安局(科信处)数据分析研判平台开发项目A招标公告
大庆市政府采购中心关于大庆市公安局(科信处)数据分析研判平台开发项目A招标公告
黑龙江省大庆市政府采购中心对大庆市公安局(科信处)数据分析研判平台开发项目A进行采购,本项目面向各类型企业进行采购,欢迎有能力的国内供应商参加。
一、项目编号:DZC********
二、项目名称:大庆市公安局(科信处)数据分析研判平台开发项目A
三、采购方式:公开招标
本项目要求以电子标书参与投标,不接受纸质投标文件(除《原件(样品)检验登记表》要求提供的资料外),否则投标无效。具体制作文件的步骤请参考http://ggzyjyzx.daqing.gov.cn/bsznTbr/20199.htm?pa=2221
咨询电话:****-*******
四、技术需求及数量:大庆市公安局(科信处)数据分析研判平台开发项目A,本项目共分1个标段,预算:2,060,000.00元,控制价为1,980,000.00元:参与投标供应商投标最终报价超出控制价的投标无效。详细需求见大庆市公共资源交易中心网(http://ggzyjyzx.daqing.gov.cn/)《招标公告》。
五、供应商资格条件:除符合《中华人民共和国政府采购法》中有关供应商申请取得政府采购资格的相关条件外,还应符合下述资格条件:
1、提供参与本项目竞争供应商有效的营业执照副本或事业单位法人证书副本。
2、参与本项目供应商产品中大数据产品必须通过国家标准<信息技术.大数据通用规范>检测,并提供有效的测试证书。
3、本项目不接受联合体投标 。
六、本项目面向各类型企业进行采购。本项目执行政府采购扶持中小企业的相关政策。详见《政府采购促进中小企业发展暂行办法》。
参与本项目供应商如属于小、微企业,则须提供“小微企业声明函”,格式详见招标文件第七部分。
根据相关政策,参与本项目供应商为小型或微型企业的,且所投大庆市公安局(科信处)研判平台采购项目是由参与本项目供应商直接提供服务的,则所投大庆市公安局(科信处)研判平台采购项目的价格给予6%的扣除,用扣除后的价格参与评审。参与本项目供应商需提供本企业的小微企业声明函(须按规定格式填写声明函),不提供声明函的不享受相关扶持政策。
注:以上“用扣除后的价格参与评审”是指开标现场,依据供应商所投大庆市公安局(科信处)研判平台采购项目投标报价进行6%的扣除。
七、获取文件须知
1、获取文件时间:公告之日起至2018年10月24日17时0分截止。
注:请参与本项目投标的供应商在2018年10月24日17时0分前自助下载文件,逾期则无法下载文件,由此造成的后果由供应商自行承担。
2、该项目采取供应商网上自助的方式。
在大庆市政府采购网或黑龙江省政府采购网注册的供应商且供应商注册信息审核状态达到“有效”或“入库”或“合格”状态,可网上自助下载文件。未注册的供应商请注册后,按照网站中“办事指南”中的说明网上下载文件。
3、咨询电话:****-*******
八、申请退出投标程序及注意事项:
1、参与本项目投标的供应商应严格遵守《诚信竞争承诺书》,如果供应商已下载文件后因自身原因需要退出投标,必须在投标截止时间72小时前,在大庆市电子政府采购交易管理平台提出退标申请,并说明合理退标理由。否则,计入不良行为记录名单一次。
供应商已下载文件后无故未参与投标或未按规定程序申请退出投标的,将被计入不良行为记录名单。12个月内:供应商被计入不良行为记录1次的,我中心将限制其1个月内参与大庆市政府采购竞争;供应商被计入不良行为记录累计2次的,我中心将限制其3个月内参与大庆市政府采购投标;供应商被计入不良行为记录累计3次的,我中心将限制其6个月内参与大庆市政府采购投标。同时1年内不能被推荐为诚信供应商。
2、通过大庆市电子政府采购交易管理平台提出退标申请,并经我中心受理备案的,可在大庆市电子政府采购交易管理平台办理退还保证金事宜。
3、未按规定程序申请退出投标的,无权向大庆市政府采购中心申请退还投标保证金。
4、未按规定程序申请退出投标的,我中心将视情况作出相应处理。
5、已经在大庆市电子政府采购交易管理平台提出退出申请的供应商或擅自不参加本项目投标的供应商,不得再参与该项目后期的采购活动。
九、投标保证金
(具体交纳方式见http://ggzyjyzx.daqing.gov.cn/downcenter/38287.htm?pa=3551)
1、参与本项目投标的供应商,须按相关规定向大庆市公共资源交易中心账户预交谈判保证金:20,000.00元,投标保证金必须由参与本项目投标的供应商以本单位对公账户名义,且以转帐方式交纳,不接受企业或个人以现金方式交纳投标保证金(包括直接将现金存到大庆市公共资源交易中心账户上的行为),不得以其他单位或以个人名义代交。投标保证金缴纳证明须扫描上传到大庆市公共资源交易管理平台投标文件中,否则,投标无效。
2、以担保保函方式提交投标保证金的,应提交经财政部认定的中国投资担保有限公司或经黑龙江省财政厅认定的黑龙江省鑫正担保集团有限公司或大庆市财政局认定的大庆市工商业担保有限公司、大庆市国盛融资担保有限公司出具的投标保函,或对公账户开户银行出具的投标保函及对公账户开户许可证。投标保函应按招标文件中规定的“政府采购投标保函”样式出具,不按招标文件规定的“政府采购投标保函”样式出具的投标保函,大庆市政府采购中心不予接受。同时应将投标保函原件带到开标现场,并提供投标保函复印件一份。否则,投标无效。
对投标担保保函咨询请与中国投资担保有限公司、黑龙江省鑫正担保集团有限公司、大庆市工商业担保有限公司、大庆市国盛融资担保有限公司联系,联系电话:
中国投资担保有限公司:***-********
黑龙江省鑫正担保集团有限公司:****-********/********
大庆市工商业担保有限公司:****-*******
大庆市国盛融资担保有限公司:****-*******
3、大庆市公共资源交易中心账户信息:
户 名:大庆市公共资源交易中心
开户银行:中国建设银行股份有限公司大庆市直支行
行号:********0553
注:填写汇款单时,需要标注项目编号或订单编号。
4、投标保证金不允许串项目使用,交纳其他项目的保证金不能用作本项目。
5、使用保证金年卡的供应商须将保证金年卡扫描上传到大庆市公共资源交易管理平台招标文件中,保证扫描内容清晰可查,否则投标无效。建议参与政府采购活动频率高的供应商办理保证金年卡,年卡可在投标(履约)保证金上限内重复使用,超出部分补差即可。保证金年卡可同时用作投标和履约保证金。
6、中标方的投标保证金可转为履约保证金(多退少补)。
7、投标保证金的退还:投标保证金一律采取转账方式无息退还至原汇款账户。未中标供应商请在中标通知书(成交公告)发出后主动在大庆市公共资源交易管理平台提出保证金退款申请,5个工作日内退还。中标供应商如未将投标保证金转为履约保证金的,请在合同签订后的平台内提出退款申请,5个工作日内退还。退款申请详细内容:未中标供应商全称、开户行、账号、金额、项目编号、联系人、联系电话。否则,投标保证金滞留的责任由供应商自行承担。
8、办理交纳或退还保证金事宜,如有疑问请与我中心办公室财务人员联系。
电话:0459—*******,传真:****-*******。
9、发生下列情况之一,投标保证金将不予退还:
⑴投标开始后在投标有效期间,供应商撤回其投标资料。
⑵中标方不按本文件及成交通知书规定签订合同协议。
⑶将中标项目转让给他人,或者在投标文件中未说明,且未经大庆市政府采购中心同意,将中标项目分包给他人的。
⑷拒绝履行合同义务的。
十、招标文件售价:免费。
十一、预计投标截止时间及开标时间:2018年11月2日9时30分,具体时间以招标文件为准。
十二、注意事项:
1、供应商请主动到大庆市公共资源交易中心网(http://ggzyjyzx.daqing.gov.cn/)《交易信息》栏目下载招标文件及后续发布的与本项目相关的各类文件(如:预备会纪要、变更通知、有关问题答复、质疑答复等相关文件)。
关于下载招标文件及相关文件事宜,采购中心不另行通知,均以发布的文件为准。由于供应商未及时下载与本项目相关的各类文件而影响供应商正常参与投标以及产生的其他问题和后果的,责任由供应商自行承担。
2、供应商应详细阅读本公告,符合条件即可参与。本项目要求的供应商资格证明文件报名时不需提供,参标供应商将所有资格证明文件提供到开标会上,由评标委员会审查,经评审不符合条件者投标无效。
3、未在大庆市政府采购网或黑龙江政府采购网注册的供应商,无法网上下载文件。未在大庆市政府采购网或黑龙江省政府采购网进行供应商注册的企业,请到www.hljcg.gov.cn,点击进入“大庆”登记注册。
4、获取文件截止时未在大庆市政府采购网或黑龙江政府采购网注册的供应商,本项目无法下载文件;在开标前供应商注册信息审核状态未达到“有效”或“入库”或“合格”状态,则投标无效。
未通过黑龙江省政府采购网注册审查的供应商,请联系政府采购网所属区县的采购管理办公室。市级入网审核咨询电话: ****-*******/*******。萨尔图区入网审核咨询电话:****-*******。让胡路区入网审核咨询电话:****-*******。龙凤区入网审核咨询电话:0459-6237315。高新区入网审核咨询电话:0459-8106016 。红岗区入网审核咨询电话:0459-4192221。大同区入网审核咨询电话:0459-6165923。具体要求请查阅http://www.dqgpc.gov.cn/《办事指南》栏目——供应商参与投标指南。流程第1条。
5、本项目开标过程全程音视频监控,如参与本项目投标企业或个人对开标过程有疑义,可以书面形式提出,由政府采购监督部门视情况调阅监控录像进行审查。因此,所有参与本项目投标企业和个人不得对开标过程进行录音、录像、摄影,或者通过发送邮件、博客、微博客等方式传播开标过程,一经发现,投标无效,造成损失和影响的,将追究法律责任(经允许的除外)。
6、单位负责人为同一人或者存在直接控股、管理关系的不同供应商,不得参加同一合同项下的政府采购活动。
集中采购机构:大庆市政府采购中心
集中采购机构地址:大庆市萨尔图区东风新村纬二路2号(大庆市行政服务中心三楼)
网址:http://ggzyjyzx.daqing.gov.cn/
集中采购机构联系人:李维
集中采购机构联系电话:****-*******
采购单位:大庆市公安局
采购单位地址:大庆市东风新村纬二路19号
采购单位联系人:高英杰
采购单位联系方式:0459-6065051
邮编:163311
日期:2018年10月17日
项目需求
项目概述根据实战需求,运用云计算、大数据、机器学习等新技术,开发建设数据整合、存储、管理、安全、服务、分析挖掘、可视化应用、预知预警等功能于一体的综合应用平台,建设内容主要包括以下:
1、大数据平台
建立与公安内部、社会单位业务系统的数据对接机制,按需采集数据,并借助云计算、大数据计算处理框架实现对数据的抽取、加工、整合及数据治理及资源服务功能,确保数据质量,为后续研判分析、建模挖掘、预警预测应用提供良好的数据支撑能力。
2、数据库资源池
在数据整合治理的基础上,构建数据汇聚库、专题库、战法模型资源库以及知识图谱库,打造可满足各警种业务部门业务需要的数据资源池。
3、基于大数据的预测、预警及研判应用
基于数据库资源池,利用大数据计算、可视化交互及分析挖掘等技术,建立服务全警种业务部门的预测、预警及研判应用实战应用,以及业务服务集、研判工具箱等研判分析工具,充分发挥工作的预知、预警和制导效用。
4、建设大数据运维管理系统
本平台运用了很多大数据计算体系相关的软件、组件,为便于平台后续的日常管理和运维,运维管理平台提供集群设备管理、系统容错、统一门户、一键运维、实时运维、设备状态检测、报警管理、报修管理、配置管理、监控报警、日志管理、安全管理等管理功能。
5、建设数据安全管控系统
本平台汇集融合公安内外各类数据资源,为确保数据应用层面的安全,安全管控系统提供了数据存储的安全、数据传输过程中的安全,数据的一致性、数据访问安全等管理功能。
建设需求标方在投标文件中,根据公安业务及以往项目建设经验,需详细描述各功能模块设计,能够满足实际公安业务需求,作为项目实施及验收的依据。
第1章
第2章
2.1 总体设计
总体架构
基于大数据技术构建,通过借助智能文本分析引擎实现异构存储,引入了Nosql数据库、关系数据库、图数据库、内存计算等引擎技术,并利用关系计算、特征计算、相似度计算、云计算的方式,实现实时、准实时、批量计算,为实战应用提供实时、高效、批量运算的技术保障。
应用层充分利用系统丰富的信息资源,通过调用引擎层的支撑功能,构建各类基于大数据技术、图数据技术的实战应用,由专题人智能管控、重大事件预警、警情态势分析、多元布控应用、图深度挖掘应用以及丰富的研判工具箱和业务服务集等功能组成。
2.2 平台性能设计
2.2.1 用户数
支持在线用户数≥3000;
支持用户并发数≥200;
2.2.2 稳定性指标
系统有效工作时间≥99.9%;
系统故障平均间隔时间≥90天;
2.2.3 应用系统技术指标
业务数据量在亿行级简单检索查询类响应时间≤1秒,复杂类检索查询响应时间≤5秒
非业务数据查询类页面响应时间≤1秒
2.2.4 数据加工分析技术指标
数据加载≥ 130M/秒
实时分析,在 100亿级别的数据连接分析,返回时间≤ 10秒
离线分析,在 1000 亿级别的数据连接分析,返回时间≤ 30分钟
2.3 大数据平台
大数据处理框架采用Hadoop发行版,优势在于极强的横向扩展能力以及对非结构化数据的良好支持,其中包含所有的全量数据,并且一些运算量大的处理,如战法构建等会在Hadoop集群上以分布式的方式运行。
2.3.1 大数据逻辑架构
面对数据资源海量化、异构化及应用需求多样化,复杂化等带来的挑战,针对不同应用场景,灵活地选择合适的数据技术解决业务问题是必然的。因此,针对业务场景的多样性,DAAS层的逻辑架构设计如下所示:
大数据资源池提供的能力具体包括:
分布式数据存储:
提供分布式文件系统HDFS,KV存储HBASE,分布式图数据库Titan,MPP DB能力,同时提供搜索引擎(Solr)能力, 满足存储各种类型海量数据的能力, 具备对数据进行快速查询和检索能力。
分析处理能力:
提供批处理(MapReduce)、内存迭代计算(Spark)和流处理框架(Storm)多种计算引擎;同时面向领域的分析语言(DSL),包括面向数仓的Hive,面向数据挖掘的SpakrSQL和 面向流处理的CQL(Continuous Query Language), 具备对结构化、半结构化和非结构化数据的进行多层次处理的能力,具备离线计算、流式计算、实时分析、机器学习等能力。
2.3.2 数据存储管理
大数据平台提供分布式数据存储,包括分布式文件系统HDFS,NoSQL存储HBase和分布式关系型数据库Elk的能力,同时提供全文索引(Solr)搜索能力,满足存储各种结构化、半结构化、非结构化等多种类型海量数据的能力,具备对数据进行快速查询检索、分析挖掘等能力。
根据数据生命周期的各个阶段,分别从数据接入、预处理、数据融合、数据管理等阶段提供统一的存储和管理能力。
2.3.2.1数据接入/预处理
数据接入/预处理作为大数据平台能力的基础,承担的是按统一标准对数据进行归一化处理的任务。面对来自不同网络、不同来源的互联网、电信、社会基础等数据,数据产生周期各异,需要一个统一的功能模块对这些数据的接入和结构化、半结构化和非结构化数据进行预处理操作。
数据接入和预处理技术架构和数据流如下图所示:
数据接入数据源主要包括各业务系统数据、其他系统数据、外部临时数据和其他数据等数据源管理。
按类型分,支持以下三种主要类型的数据源:
1) 关系型数据库:支持关系型数据库JDBC/ODBC接口,包括Oracle、MySql、SqlServer等主流数据库的调用接口。
2) 流式数据源:流式数据源有两种,一种是本来就是流式数据,比如电信网络的监控数据等;还有一种是本来是有格式文件数据,比如某些系统的日志输出等,输出的日志文件通过日志收集工具。
3) 文件数据源:支持包括SFTP/FTP等方式的文件批量采集方式。
? 数据接入
对于采用数据库接口提供的数据源,可采用开源Sqoop来实现,但考虑到软件稳定性和安全性,方案采用增强数据整合工具来实现对关系数据库数据的批量采集并通过分布式集群导入到大数据平台上。
对于采用文件接口提供的数据源,可采用增强数据整合工具方便的通过FTP/SFTP方式批量采集文件,并将文件数据通过分布式架构导入到大数据平台,对于超大文本文件支持以分块模式(分块大小和并行度可自定义)分布式接入大数据平台。
? 数据预处理
对于结构化数据预处理,在数据接入过程中通过接入工具实现对结构化数据进行基本的ETL处理,开展清洗和转换等归一化处理,利用大数据服务的高性能处理能力,结合大数据善于处理高吞吐业务特性,对数据进行并行预处理,实现结构化数据的快速入库,同时提供API接口,支持其他第三方平台和工具基于Loader的二次开发和集成。
对于半结构化数据预处理,需要对文本类数据开展翻译、摘要、分类等处理,提取元数据和特征信息,可以利用组件对文件的并行处理能力,将半结构化数据先导入大数据服务的分布式存储,再通过分布式计算框架MapReduce或Spark结合全文索引Solr,实现对半结构化数据预处理。
对于非结构化数据预处理,由于这类数据一般数据量非常大,在接入过程中进行处理会影响接入性能,将非结构化数据先行导入大数据服务的分布式存储,再通过对非结构化数据进行批处理,利用大数据计算框架MapReduce或Spark,提取元数据和特征信息实现非结构化数据的快速入库。
? 统一调度
整个数据接入和预处理过程通过Oozie实现可视化的管理和提供对相关接入/预处理作业的任务调度与协调;并提供对各作业任务的查看和监控功能。
2.3.2.2数据融合
数据融合是数据处理的核心组成部分,以原始数据库为基础,经过数据萃取和数据特征工程计算形成主题库,通过对比、筛选和分类等业务分析,形成业务专题库,原始数据库、主题库和业务专题库共同构成数据资源池。
原始数据资源通过数据接入/预处理阶段对数据完成初步处理形成原始数据库,以原始数据库为基础,配合用户和应用开发商开展数据规划、组织等建设工作,按照不同维度进行数据萃取融合和数据特征工程计算,结合业务主题建仓。
1) 属性融合:以人、地、事、时间等为维度,开展数据融合,建立属性归一化模型和标签体系;
2) 主题融合:为不同业务关注点进行主题信息融合,建立主题内人与事关系、人与人关系、行为规律等信息的刻画;
3) 知识融合:收集涉及社会各方面的基础知识,建立知识库,将定义、编码、名词、称谓、分类、描述等信息进行融合;
4) 业务融合:根据业务工作特色对主题库的信息进行重新组织,整理出国别类和领域类业务专题数据库。
2.3.2.3数据存储
提供对多源异构海量数据的存储,支持对原始数据文件的分布式存储,支持文本、键值对、对象等多种数据特征的存储,最终满足业务系统复杂数据源类型的存储需求。根据项目建设的需求,需要提供如下包括分布式文件存储HDFS,NoSQL数据库HBase,分布式关系型数据库,分布式全文索引等多种结构、不同需求场景的数据存储方案。
(一) 分布式文件系统
HDFS分布式文件存储采用可扩展的系统结构,提供了海量数据的分布式存储。对于以文件方式存储的数据,比较适合该类存储方式。但采集的数据存在着不同大小文件并存的情况,按大小可大致划分为小文件(1MB以下)、中文件(1MB到500MB)、大文件(500MB以上),且文件数量非常多,为保证存储这些文件的同时能够提供快速读取的能力,分布式存储要能够满足该目标而提供相应小文件、中文件和大文件的存储检索方案,对外能提供统一接口进行访问,客户端在访问分布式存储时不需了解底层存储方式,由分布式存储统一调配相应优化方式实现文件快速存储和检索。分布式文件系统要支持6亿以上文件存储能力。
HDFS支持数据分级存储,根据数据的不同访问热度的数据存储于不同性能的存储介质(如:SSD/SAS/SATA),以达到最高性价比。
分布式文件存储能够提供FTP/SFTP接口,以便传统应用可以不修改代码访问HDFS。
分析型DB存储格式/引擎:
在HDFS分布式存储之上,分析数据存储格式可以采用ORCFile或者Parquet,同时提供了结构化存储引擎Hive,可以把存储于HDFS分布式文件系统中的文件、目录映射为表。Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具,可以用来进行数据提取转化加载(ETL),这是一种可以存储、查询和分析存储在 Hadoop中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言,称为 HQL,允许熟悉 SQL 的用户查询数据。同时,这个语言也允许熟悉 MapReduce 开发者的开发自定义的mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。
本次项目需求如下:
? 能提供高吞吐量的数据访问,适合大规模数据应用。通过聚合多台服务器的本地文件系统的吞吐能力,能提供同时对超大数据文件的访问能力。
? 大数据平台支持不停机动态添加和删除节点,实现热扩展能力。
? 本期项目集群内的所有节点都需要部署统一的分布式文件系统,其存储的数据资源需要实现统一检索、编目和增删等管理操作,在此基础上,需要根据数据的使用热度等实现数据分级存储。
? 能够将各种类型、各种格式和大文件根据指定的分块大小参数进行文件分割,分块大小参数可修改配置;对每一个文件分块实现多副存储;文件分块随机、分布存储与管理于集群中的服务器。
? 支持将海量小文件打包为一个大文件集中存储。
? 提供对文件读写、删除操作记录的审计日志。
? 支持元数据的备份、恢复和水平扩展功能,实现文件系统的容量提升和集群规模扩展。
? 支持创建目录某个时间点的系统快照,可用系统快照将系统快速恢复到快照时间点。
? 对外接口:能提供基于Apache开源社区标准接口进行数据读写。
? 支持FTP/SFTP:能够提供FTP/SFTP接口,以便传统应用可以不修改代码访问HDFS。
? 支持小文件和大文件存储:能够同时提供对小文件(1MB以下)、中文件(1MB到500MB)、大文件(500MB以上)的存储和快速读取。
? 存储配额:支持基于目录的存储空间和文件数量的配额控制。
? 数据分级存储:HDFS应支持数据分级存储, 把不同热度的数据存储于不同的介质(SSD/SAS/SATA)。
? 节点标签存储:支持基于节点标签存储策略,指定文件只存储在只包含预配置的指定标签的节点上。
(二) NoSQL数据库
以HBase为代表的NoSQL数据库适合于存储较简单的数据模型,并且可以不受模式的约束。因而其可存储管理的数据类型更丰富;大数据技术同时适合进行一致性与事务性要求不高的计算(主要是指NoSQL的查询操作),以及对超大规模海量数据的、批量的分布式并行计算。NoSQL数据库由于摆脱了繁琐的SQL体系约束,其查询与插入的效率比传统关系型数据库要更高。
NoSQL数据存储一般采用面向列的存储方式,其存储结构保证了数据表的列可扩展性和读写I/O的高吞吐性。Key-Value方式存储。同时也可以通过对HBase增强来满足用户对文档数据的存储和管理。
本次项目需求如下:
? NoSQL数据库能够实现水平扩展。
? 支持主流NoSQL数据库,主要包括:支持将数据以键值对形式进行存储的键值型数据库,实现多级索引提高查询性能。支持将数据以列式存储的列存数据库,实现多表间的快速关联查询,并能够将多个具有类似功能或存在关联的业务表存储在一个大表中、支持面向文档的海量存储需求和访问的文档数据库。
? 支持分布式的图数据库,实现单节点、多节点多层关系查询,实现最短路径、最优路径遍历搜索等基本图计算。实现拓扑关系的可视化及搜索,具备可视化界面以关联图的方式显示对象和它们之间的关联关系。
? 实现NoSQL数据库的高可靠性,支持构建在分布文件系统之上,能支撑大数据在线查询需求。
? 一个集群能够支持部署多个数据库服务实例,不同业务和部门可以使用不能的服务实例来达到资源的隔离。
? Bulkload功能:在使用BulkLoad的方式将文件导入HBase时,需要支持自定义rowkey,自定义字段,数据基础清洗过滤,字段热冷存储等功能。
? Region动态分割:需要支持Region动态分割功能,即把空的Region预先分割成多个Region,避免Region因为空间不足,出现Region分割导致性能下降的现象。
? 容灾:需支持HBase表数据跨数据中心灾备。
? 权限管理:支持基于表、列族和列的用户权限管理,能够支持的操作权限有读、写、创建以及管理员权限。
? 数据加密:支持按照用户需要对NoSQL数据库中的数据进行列加密。即可以按照用户需要,对所有数据进行加密,也可以只对部分关键数据进行加密。
分布式图数据库:
图数据库使用图来存储数据,图数据库每个对象是一个节点,之间的关系是一条边。相对于关系数据库来说,图形数据库善于处理大量复杂、互连接、低结构化的数据,这些数据变化迅速,需要频繁的查询——在传统关系数据库中,由于这些查询会导致大量的表连接,从而导致性能问题,而且在设计使用上也不方便。
在安全类业务中,使用图数据库存放关系类数据,比起传统关系数据库存放方式更加简洁、直观。
(三) 分布式关系型数据库
关系型数据库Elk基于Shared-nothing架构,面向开放X86平台,数据跨所有节点均匀分布,所有节点以并行方式工作,提供标准SQL接口,支持SQL92,99,2003标准,支持JDBC/ODBC标准接口,具备高性能,高扩展性,高可用等特性。
本次项目需求如下:
? 分布式关系型数据库集群能够实现水平扩展。
? 支持SQL99、SQL2003标准,支持JDBC/ODBC标准访问接口。
? 一个集群能够支持部署多个数据库服务实例,不能业务和部门可以使用不能的服务实例来达到资源的隔离。
? 支持ACID强事务一致性,提供分布式事务机制;支持数据库存储过程。
? 支持多节点并行批量加载文件方式入库,支持CSV/TEXT两种文件格式导入,支持多分隔符文件;支持多节点实时流方式入库。
? 支持行列混存,支持表按行或列格式组织存储,支持行列转换。
? 支持索引,行存支持B-tree,hash,Gin,Gist;列存支持psort索引。
? 支持逻辑分区:分区合并、分区交换、分区切割、分区聚簇、分区Truncate、分区索引。
? 支持组网全冗余部署,任何网络节点故障,自动故障检测切换业务不中断。
(四) 分布式全文索引引擎
Solr是一个高性能,基于Lucene的全文检索服务器。Solr对Lucene进行了扩展,提供了比Lucene更为丰富的查询语言,同时实现了可配置、可扩展,并对查询性能进行了优化,并且提供了一个完善的功能管理界面,是一款非常优秀的全文检索引擎。SolrCloud是从Solr4.0版本开始开发出的具有开创意义的分布式索引和搜索方案,基于Solr和Zookeeper进行开发的;Solr可以以多种方式部署,例如单机方式,多机Master-Slaver方式,但这些方式部署的Solr不具有SolrCloud的特色功能:
利用ZooKeeper作为协同服务,启动时可以指定把Solr的相关配置文件上传Zookeeper,多机器共用。这些Zookeeper中的配置不会再拿到本地缓存,Solr直接读取Zookeeper中的配置信息。配置文件的变动,所有机器都可以感知到。
自动容错,SolrCloud对索引(collection)进行分片(shard),并对每个分片创建多个Replica。每个Replica都可以独立对外提供服务。一个Replica挂掉不会影响整个索引搜索服务;更强大的是,它还能自动的在其它机器上把失败机器上的索引Replica重建并投入使用。
索引和查询时的自动负载均衡,SolrCloud索引(collection)的多个Replica可以分布在多台机器上,均衡索引和查询压力。如果索引和查询压力大,可以通过扩展机器,增加Replica来减缓压力。因此,下面的介绍主要是围绕SolrCloud展开描述的。
Solr索引数据存放到本地磁盘,提供了更加快速的索引和查询速度;SolrCloud可以多实例部署,可以实现并发写与读,提高索引与查询性能。
1) 实现HA与浮动IP的机制,提高Solr服务的可靠性。
2) 增加了kerberos认证,保障了索引数据的安全性。
2.3.2.4数据管理
? 概述
数据治理的目的在于充分有效地发挥数据的作用,是对数据资产行使权力和控制的活动集合,主要通过数据标准管理、元数据管理、数据质量管理、数据资产管理、数据安全管理确保数据一致、安全、有效的运行和运营。数据治理是在高层次上执行数据管理制度。
? 数据标准管理:在组织推动和指导下,遵循一致的数据标准规范,提供数据统一的业务标准定义和技术标准算法,借助标准化管控流程得以实施数据标准化的整个过程。
? 元数据管理:元数据的整合、控制以及提供元数据。元数据分为技术元数据和业务元数据,业务元数据是数据标准的体现, 技术元数据是数据库实现层面的元数据。技术元数据需要映射为业务元数据对最终客户有价值,技术元数据对开发人员有意义,但并不能满足整体数据治理的需要。
? 数据质量管理:根据数据标准对数据进行质量管理和控制,即对监控对象的名称、说明、元数据和数据标准属性进行监控,通过闭环的管理过程实现对数据质量的提升。
? 数据资产管理:对企业及组织拥有或控制,能给企业及组织带来未来经济利益的数据资源进行行之有效的管理。目前本项目数据资产几乎涉及所有的信息资源类型,既包括各部门、各专业警种业务部门等业务系统数据,也包括各种社会资源信息和部省资源,既涵盖各种结构化数据,还包括视频、图片、音频、文档、互联网数据、电子笔录等半结构化、非结构化数据。因此,需要从满足实际应用的角度,综合考虑数据资产的管理。
? 数据安全管理:确保隐私、保密性和适当的访问权限等。
? 角色职责
必须通过明确角色职责才可以让各方对数据治理工作有清晰的分工界面,让数据治理工作融入数据相关的日常工作中,从而达到数据治理的目标。
数据管理决策者:牵头数据治理工作,负责制定数据治理的政策、标准、规则、流程,协调认责冲突。对数据事实治理,保证数据的质量和隐私。并在数据出现质量问题时负责仲裁工作。
数据管理执行者:对数据负责,提供数据的业务需求,解释数据的业务规则和含义。负责对影响数据质量的业务规则、业务规范等元数据的刚性落地,并汇总提供各类技术元数据。确保数据质量,对影响数据质量的问题进行分析、反馈和解决,是数据出现质量问题时的主要责任者。
数据平台运营者:负责数据治理平台中整体数据的管控流程制定和平台功能系统支撑的实施,并负责整体平台的运营、组织、协调。
数据开发者:负责数据及相关系统的开发,有责任执行数据标准和数据质量内容,负责从技术角度解决数据质量问题。是数据出现质量问题时的主要责任者。
数据提供者:需要制定相关数据标准、数据制度和规则,遵守和执行数据管控相关的流程,根据数据的相关要求提供数据。是数据出现质量问题时的次要责任者。
数据消费者:作为数据治理平台数据管控流程的最后参与使用者,是数据资产价值的获益人,同时也可作为数据治理平台数据闭环流程的发起人。
? 系统边界
数据治理平台与其他各系统平台之间存在数据交互、功能支撑、管控流程穿插和运维统一等关联。
? 数据治理平台搭建在大数据平台之上,符合大数据平台对接要求。
? 数据治理提供数据模型和接口的标准体系要求,并对进入大数据平台的接口数据进行元数据采集、数据质量管理和数据资产的统一治理。
? 数据治理平台提供稽核管控后的数据作为资产供应用支撑服务进行数据开放能力发布共享,是应用支撑服务后端数据的支撑系统。
? 数据治理平台支撑大数据平台的数据管控流程,并与数据运维管理平台交互协调,共同支撑大数据平台整体的安全运维、数据运维和管理运维。
? 数据字段级管理的意义
基于本项目特殊的工作性质,在实际业务工作的开展过程中,会大批量的对数据进行分析和处理,通过对数据的分析和处理间接或直接的支撑实际业务的工作开展。在对数据进行分析和处理的过程中,所利用到的数据是多样化的,包括来源多样化、样式多样化、表现形式多样化以及存储形式多样化。这些数据往往并不能够直接应用到具体的数据分析和处理过程中,这个时候就需要通过大数据的方式实现对多样化、大批量的数据进行抽取和整理,通过抽取和整理把需要的关键性数据形成“数据资产”应用到实际业务的开展过程中。在抽取的过程中、往往是对多源异构数据中的某个字段级的数据进行抽取,后期通过多种技术手段实现对抽取来的字段级数据进行归类和再处理,例如在实际的人口信息分析和研判过程中,具体人口信息的相关数据来源包含已掌握和存储的数据、其它政府单位的人口信息管理数据、公共场所(酒店、网吧、火车站等)实时反馈汇总的人口信息数据,部门通过抽取各来源数据中的关键性字段、通过汇总归类的方式形成符合业务实际需求的人口信息数据。
综上所述,基于行业的特殊性,数据管理必须管理到字段一级,才能最终发挥数据最大的利用价值。数据管理包括数据生命周期管理、权限控制、数据血缘管理。
2.3.3 数据分析挖掘
数据分析挖掘通过提供主流高性能分布式分析引擎和数据挖掘算法,实现对多源异构数据的离线、实时分析挖掘处理。
分析计算框架主要支持离线处理计算、内存迭代计算和流式计算等;支持多种编程模式,如Java,Python,R等。
同时,数据挖掘平台实现了对主流统计分析和机器学习分布式算法的集成和管理;
支持可定制的数据挖掘工具,具备拖拉拽式的界面操作,对各类数据源进行数据探索、抽取特征进行建模分析。
2.3.3.1分析计算框架
(一) 离线批处理计算
? MapReduce计算框架
MapReduce是Hadoop的核心,用于大规模数据集的并行运算。“Map(映射)”和“Reduce(化简)”概念及其主要思想,都是从函数式编程语言借来的,还有从矢量编程语言借来的特性。当前的软件实现是指定一个Map(映射)函数,用来把一组键值对映射成一组新的键值对,指定并发的Reduce(化简)函数,用来保证所有映射的键值对中的每一个共享相同的键组。
? Hive
Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具,可以用来进行数据提取转化加载(ETL),这是一种可以存储、查询和分析存储在 Hadoop中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言,称为 HQL,它允许熟悉 SQL 的用户查询数据。同时,这个语言也允许熟悉 MapReduce 开发者的开发自定义的mapper 和 reducer 来处理内建的 mapper 和 reducer 无法完成的复杂的分析工作。
(二) 内存迭代计算
Apache Spark是一个开源的,通用的分布式集群计算引擎。Spark具有如下特点:
1) 快速:数据处理能力,比MapReduce快10-100倍。
2) 易用:可以通过Java,Scala,Python,R,简单快速的编写并行的应用处理大数据量,Spark提供了超过80种高层的操作符来帮助用户组件并行程序。
3) 普遍性:Spark提供了众多高层的工具,例如Spark SQL,MLib,GraphX,Spark Stream,可以在一个应用中,方便的将这些工具进行组合。
4) 与Hadoop集成:Spark能够直接运行于Hadoop 2.0的集群,并且能够直接读取现存的Hadoop数据。
Spark提供了一个快速的计算,写入,以及交互式查询的框架。相比于Hadoop,Spark拥有明显的性能优势。Spark使用in-memory的计算方式,通过这种方式来避免一个MapReduce工作流中的多个任务对同一个数据集进行计算时的IO瓶颈。Spark利用Scala语言实现,Scala能够使得处理分布式数据集时,能够像处理本地化数据一样。
除了交互式的数据分析,Spark还能够支持交互式的数据挖掘,由于Spark是基于内存的计算,很方便处理迭代计算,而数据挖掘的问题通常都是对同一份数据进行迭代计算。除此之外,Spark能够运行于安装Hadoop2.0 Yarn的集群。之所以Spark能够在保留MapReduce容错性,数据本地化,可扩展性等特性的同时,能够保证性能的高效,并且避免繁忙的磁盘IO。
(三) 流式计算能力
利用流式计算框架的高性能处理特性对实时数据进行分析、处理,实现事件的分类、过滤以及复杂事件匹配操作。通过实时事件触发特定业务行为等应用,使系统满足对事件实时性、目标人员筛查精准性要求。Stream组件是大数据平台基于开源Storm平台进行产品化、功能增强、性能调优、安全和可靠性增强后形成的一个实时流处理系统,为用户提供事件驱动的事件过滤、转换、合并、拆分、窗口聚合计算、事件关联等功能,支持基于CQL和Storm原生API的二次开发。
a) 安全特性:为Storm提供用户级别的访问控制功能。使用Kerberos、LDAP机制提供统一的用户认证,并提供用户级别针对Topology的创建、浏览、中止、激活、去激活等操作,并对用户级别操作记录审计日志。安全特性使得对于重要业务Topology,仅有创建者才能查看和操作,避免非安全操作。
b) 高可用性:Nimbus HA机制,避免了Storm集群中Nimbus成为单点问题,从而导致集群无法提供Topology的新增及修改。增强了集群可用性。
2.3.3.2分析算法
可通过调用接口,自主完成数据处理、模型训练、评估、离线预测全链路流程开发调测,也可使用数据挖掘工具Miner,在图形界面上完成如基本统计、拆分、随机采样、归一化、全表统计、直方图、百分位等常规数据分析业务开发。
算法库提供的算法如下:
? Mahout
Apache Mahout是基于MapReduce计算框架的机器学习和数据掘框架,主要实现了推荐(Recommendation)、聚类(Clustering)、分类(Classification)三大类算法。
? MLlib
MLlib是基于Spark计算环境的机器学习和数据挖掘算法库,支持广泛的算法,包括:二元分类、线性回归、聚类、协同过滤、梯度下降等。
实现数据挖掘计算框架的有机统一。无论是图计算还是机器学习底层均基于统一抽象的高性能矩阵运算库,有利于性能优化,降低维护工作量。
不依赖于底层计算框架。基于HIMO运算库进行编程,而不依赖于Spark计算框架,这为未来运行到更为高效的并行计算框架提供了可能。
2.3.3.3可视化数据挖掘工具
提供一站式可视化大数据挖掘工作台,包括数据探索、特征工程、分析建模三个核心功能模块,方便数据挖掘工作者从大数据中创建准确高效的预测分析模型。基于Apache Spark进行分析和建模,可以充分利用大数据中高维度信息,构建更加精准的预测模型。
1) 端到端分析工作台
基于Hadoop生态,提供大数据平台上的一站式数据挖掘工作台,支撑从各类数据中探索业务规律和数据特点,并根据探索的结果构建分析预测模型,包括对原始数据的清洗、预处理、特征提取、建模、评估、预测、优化。
2) 高性能并行化建模算法
HiGraph算法库在Spark上封装和实现了矩阵和向量运算库(HIMO:Hybrid Iterative Matrix Operation)。
3) 支持百万维特征处理和管理
提供日志、交易数据中提取特征的套件,充分利用日志、交易数据中的丰富信息,提取出高维特征数据,并通过特征工程管理方便特征的共享和复用,提供专门优化的Logistic Regression算法来对高维特征数据进行建模分析,支持在百万维特征的稀疏数据集上构建模型。
4) 开放性
系统提供丰富API接口,包括Scala、R、Python、Java接口,提供可定制的数据分析挖掘能力,用户可以使用基于API接口编写自定义算子,来扩展系统的能力,并将自定义的算子作为系统的能力,在后续可以重复使用,也可以发布出去供更多的人来使用,基于Miner的规范,贵单位和应用ISV可以自行开发和贡献算法和算子、数据源连接器,嵌入到Miner运行时架构中,实现无缝集成。
5) 模型管理
支持评估、导入、导出、对比、分享或编辑分析模型。
系统支持从HDFS导入导出Model,支持InforModel和PMML两种格式。
通过Compare可以比较两个或两个以上同类模型信息,方便用户选出优秀模型。
用户对于自己满意的模型,可以通过share分享给所有使用平台的人。
针对已有的Model,用户可以通过编辑Model功能更新Model的名称。
用户可以根据实际情况,删除无用Model。
模型发布支持从探索环境到生产环境一键式发布,模型应用的输出是可在生产环境运行的程序,通过任务的方式调度模型。
模型管理对指定数据源进行预测,对模型质量进行监控,模型重新训练和更新能力。
2.3.4 应用支撑服务
应用支撑服务在数据统一存储和管理的基础上,通过服务接口向上层应用提供统一的,高效的数据和应用服务,支撑上层业务应用快速开发,构建基于云计算技术的服务支撑平台。实现应用和服务松耦合,同时服务可进行积木式叠加,满足业务应用开发的灵活需求。
为了提升开发人员使用大数据分析平台进行业务实现的便利性,可以将基础通用的大数据分析业务抽象到应用支撑服务中,提供标准的服务模型和访问接口,使得业务开发者能够快速的构建应用,获取大数据分析的处理能力。
2.3.4.1数据访问服务
所有数据形成数据资源目录,以总线服务方式对外提供数据访问共享应用
(一) 数据访问接口
数据访问服务主要提供对各类数据的标准化访问接口,共分三类接口:
1) 大数据平台各个存储层提供的标准开源社区原生访问API接口
2) 基于标准Restful接口的数据访问Web API接口
3) 基于服务管理和开发框架实现定制的Restful API接口
对于以上三类数据访问接口,应根据数据访问者和数据所有者的关系选择数据访问服务模式,如果数据访问者和数据所有者相同(即数据所有者访问自身数据),则直接调用数据管理和分析层组件(Elk,HBase,Hive,SparkSQL)的原始数据访问接口即1类接口进行访问,如果数据访问者和数据所有者不同,则需要采用标准服务化模式对数据进行访问,屏蔽数据组织结构,内容调整对数据访问者带来的不便。对于标准通用的对平台数据访问需求,可通过2类接口提供的标准Restful接口的数据访问服务,如果标准Restful接口不满足业务需求,可以基于服务管理和开发框架(Farmer)进行定制开发Restful接口即3类接口,实现跨部门和组织数据访问透明、高效、便捷。
(二) 接口扩展能力
数据访问服务提供的三类接口:
1) 大数据平台各个存储层提供的标准开源社区原生访问API接口
2) 基于标准Restful接口的数据访问Web API接口
3) 基于服务管理和开发框架实现定制的Restful API接口
(三) 日志审计和权限管理
数据访问服务提供日志审计和权限管理功能。
2.3.4.2应用开发服务
(一) 数据集成开发环境
提供应用开发服务的数据集成开发环境,包括数据管理、MR作业和任务监控、工作流编排和调度、数据搜索、交互式数据分析、分析结果评估与预测的可视化操作界面功能。
可以在界面针对组件进行以下操作:
HDFS:创建文件/目录,修改文件/目录权限,上传、下载文件,查看、修改文件等操作。
MapReduce:查看集群中正在执行和已经完成的MR任务,包括它们的状态,起始结束时间、运行日志等。
Hive:支持Hive SQL的编辑、执行,元数据联想功能可以简化用户编写SQL,另外通过metastore对数据库及表和视图进行增删改查等操作。
Oozie:工作流程编排、调度、监控,支持HDFS、Hive、Loader、SSH、Shell,Mapreduce、Java等Action。
Solr:支持基于Solr进行搜索的应用,并提供可视化的数据视图,管理员可以对搜索界面进行制定编排。
Zookeeper:提供Zookeeper节点可视化界面。
(二) 数据服务管理
提供业务逻辑开发框架,开发人员能够快速编写RESTful服务。系统管理员在获取到业务开发人员开发的应用后,将编译过的程序包通过图形化的操作界面,可以方便、快速地将其部署到Farmer提供的Tomcat集群中,并能实现服务实例自动分发。系统管理员可以通过图形化界面完成对BLU进行部署、启动、停止、删除等操作,服务上线部署可在15分钟内完成。
完成应用部署后,提供对服务进行治理的能力,包括服务的访问控制,负载均衡策略控制,服务的灰度发布等。同时能够对服务的调用时延、TPS指标进行监控。
利用服务灰度发布功能可以对版本策略进行灵活控制,服务升级时可实现新旧版本共存,在特定范围尝试新版本后,通过不断放量扩大升级范围来替换旧版本,实现平滑升级,保证系统的稳定工作。
2.3.4.3数据可视化服务
系统需具备以下服务:
? 提供图形化的模型探索环境,通过工作流编排即可完成数据挖掘应用的开发。
? 集成预设应用,用于特定业务分析和预测,通过这些预设应用,降低行业用户使用数据挖掘系统的门槛。
? 定时动态保持数据源更新,保持数据新鲜性。
? 平台支持多人协作,特征可多次复用,提升数据分析团队效率。
2.3.4.4数据交换服务
数据交换服务支持点对点和广播订阅两种数据交换服务模式,通过平台提供数据交换,同时根据消费者组的概念支持广播订阅和点对点两种模式,一个消息可以被多个消费者组消费,但是只能被一个消费者组里的一个消费者消费,这样当只有一个消费者组时就等同于点对点模式,当存在多个消费者组时就是广播订阅模式。
系统需具有如下特点:
消息可靠性
收到消息后,会持久化到磁盘,同时,Topic的每个Partition有自己的Replica(备份),每个Replica分布在不同的Broker节点上,以保证当某一节点失效时,可以自动故障转移到可用消息节点。
高吞吐量
通过以下方式提供系统高吞吐量:
数据磁盘持久化:消息不在内存中cache,直接写入到磁盘,充分利用磁盘的顺序读写性能。
zero-copy:减少IO操作步骤。
数据批量发送:提高网络利用率。
Topic划分为多个partition,提高并发度,可以由多个Producer、Consumer数目之间的关系并发来读、写消息。Producer根据用户指定的算法,将消息发送到指定的Partition。
消息订阅-通知机制
消费者对感兴趣的主题进行订阅,并采取pull的方式消费数据,使得消费者可以根据其消费能力自主地控制消息拉取速度,同时,可以根据自身情况自主选择消费模式,例如批量、重复消费,从尾端开始消费等;另外,需要消费者自己负责维护其自身消息的消费记录。
可扩展性
当在集群中可通过增加Broker节点以提供更大容量时。新增的Broker会向ZooKeeper注册,而Producer及Consumer会及时从ZooKeeper感知到这些变化,并及时作出调整。
作为一个分布式数据交换系统,为整个大数据平台多个子系统之间数据的传递提供了高速数据流转方式。可以实时接受来自外部的消息,并提供给在线以及离线业务进行处理。
2.3.5 大数据平台性能和功能需求
2.3.5.1规格及性能需求
组件版本需求:
产品 | 组件 | 版本要求 |
商用发行版大数据平台 | Zookeeper | 3.5.1 |
Hadoop | 2.7.2 | |
HBase | 1.0.2 | |
Hive | 1.2.1 | |
Spark | 1.5.1 | |
Spark2x | 2.1.0 | |
Solr | 6.2.0 | |
Flume | 1.6.0 | |
Kafka | 0.10.0.0 | |
Oozie | 4.2.0 | |
Loader(Sqoop) | 1.99.3 | |
Streaming(Storm) | 0.10.0 | |
Storm | 1.0.2 | |
Redis | 3.0.5 | |
Hue | 3.11.0 | |
Phoenix | 4.4.0 | |
Flink | 1.3.0 |
系统配置规格需求:
1.大数据平台系统规格 | |||
指标项 | 指标项 | 指标项描述 | 规格 |
大数据平台 | 单集群节点数(个) | 1.Manager管理的节点数 | 5,000 |
单集群最大存储容量(PB) | 230 | ||
单集群HBase Region Server数量(个) | 512 | ||
单Storm集群节点数(个) | 128 | ||
单Kafka集群最大Broker数(个) | 256 | ||
单Redis集群实例数(个) | 512 | ||
Redis集群数(个) | 512 | ||
单Solr集群实例数(个) | 500 | ||
Kerberos中KDC最大实例个数 | 2 | ||
LDAP服务最大实例数 | 2 | ||
Zookeeper最大实例数 | 5 | ||
单集群Flume最大实例数 | 128 | ||
租户数量(个) | 512 | ||
多集群互信最大对端集群数(个) | 每个集群支持与其它集群配置互信的个数。 | 16 | |
2.大数据平台配置规格 | |||
组件 | 指标项 | 指标项描述 | 规格 |
HDFS | NameService数量 | 一对主备NameNode组成一个NameService,系统最大支持的NameNode对数 | 10 |
单NameService支持最大文件数量(千万个) | 一个NameService在 256GB内存下支持的最大文件数量(按照平均每文件1个Block计) | 15 | |
单NameService支持RPC操作吞吐量(操作数/秒) | 按照读写操作7:1的情况,RPC操作数每秒; | 10,000 | |
Datanode Block数管理上限(百万) | 按照Datanode管理12个物理磁盘目录(dfs.datanode.data.dir);每个目录管理Block数上限为100万;不管对应多少个NameService; | 12 | |
SmallFS | SmallFS最大文件数量(千万个) | SmallFS文件系统最大支持文件数量 | 60 |
FtpServer | 系统支持FtpServer实例个数(个) | 集群中支持配置FtpServer角色实例最大数量 | 8 |
单FtpServer最大并发连接数(个) | 客户端到单个ftpServer的并发连接数量 | 249 | |
Hive | 系统Hive服务实例个数(个) | 集中支持Hive服务实例数量 | 5 |
单Hive服务HiveServer角色实例个数(个) | 一个Hive服务实例中HiveServer角色实例的个数 | 10 | |
单HS2最大并发回话数(个) | 单HS2允许的最大连接数,如果连接数达到这个值,则会拒绝额外的连接请求 | 500 | |
单HS2单用户最大并发回话数(个) | 单HS2对一个用户允许的最大连接数,如果用户的连接数达到这个值,则会拒绝额外的连接请求 | 500 | |
单HS2单位时间内最大SQL请求数(个/分钟) | 单HS2在单位时间内,最大处理的SQL请求数 | 500 | |
单Database下支持Table数量 | 5,000 | ||
数据库下总缺省路径partition数量 | 1,000,000 | ||
数据库下总指定路径的partition数量 | 5,000 | ||
单表最大partition数量 | 100,000 | ||
HBase | 系统HBase服务实例个数(个) | 集中支持HBase服务实例数量 | 5 |
单RegionServer上最大的Region数(个) | 2,000 | ||
单表最大Region数(个) | 1,024,000 | ||
Spark | 系统Spark服务实例个数(个) | 集中支持Spark服务实例数量 | 5 |
单应用最大的Executor数(个) | 2,000 | ||
单Job最大的运行任务数(个) | 8,000 | ||
单Job最大Task数(个) | 100,000 | ||
广播变量最大大小(MB) | 10 | ||
JDBCServer最大Session数(个/JDBCServer实例) | 500 | ||
单表最大分区数 | 10,000 | ||
单表最大文件数 | 100,000 | ||
最大历史任务保留数(个) | Spark JobHistory上保留任务数 | 30,000 | |
主备倒换时间(分钟) | 15 | ||
历史任务数(个) | 20,000 | ||
MR | 单应用最大running Task数 | 16,000 | |
最大历史任务保留时间(天) | MR HistoryServer上保留任务数 | 15 | |
Hue | 通过我的文档打开的文件数 | 打开单个文件夹下的文件数 | 100 |
Zookeeper | 最大连接数(个/节点) | 20,000 | |
Maximum number of wathers | Maximum number of wathers | 10,000 | |
最大存储内容(G) | 2 | ||
Flink | 单集群TaskManager节点数(个) | 1,000 | |
单节点的吞吐量 | 655Mbps | ||
集群业务时延 | <600ms | ||
系统支持的最大静态配置表最大记录数 | 5亿 | ||
系统支持的最大静态配置表最大文件大小 | 50GB | ||
Kafka | 单Broker支持的分区数 | 100 | |
大数据平台性能需求:
大数据平台性能规格 | ||
组件 | 指标项 | 要求 |
MapReduce | WordCount平均处理性能(GB/min/Node) | 8 |
Terasort平均处理性能(GB/min/Node) | 6 | |
K-means平均处理性能(MB/min/Node) | 650 | |
Bayesian平均处理性能(MB/min/Node) | 15 | |
Spark | WordCount平均处理性能(GB/min/Node) | 20 |
Terasort平均处理性能(GB/min/Node) | 6 | |
K-means平均处理性能(MB/min/Node) | 3800 | |
Bayesian平均处理性能(MB/min/Node) | 420 | |
Spark2 | WordCount平均处理性能(GB/min/Node) | 20 |
Terasort平均处理性能(GB/min/Node) | 6 | |
K-means平均处理性能(MB/min/Node) | 3800 | |
Bayesian平均处理性能(MB/min/Node) | 420 | |
Hive | 处理能力-HiveAggregation:平均每节点处理能力(GB/分钟) | 8 |
处理能力-HiveAggregation:平均每节点处理能力(GB/分钟) | 0.7 | |
处理能力-HiveJoin:平均每节点处理能力(GB/分钟) | 2 | |
处理能力-HiveJoin:平均每节点处理能力(GB/分钟) | 0.02 | |
Hbase | 100%随机读:平均每节点每秒读取记录条数(每条记录1KB),响应时间小于50MS | 10000 |
100%随机写:平均每节点每秒写入记录条数(每条记录1KB),响应时间小于50MS | 30000 | |
顺序扫描:平均每节点每秒scan记录条数(每条记录1KB),响应时间小于50MS | 300000 | |
Bulkload(MB/Node/Sec) | 30 | |
rowkey实时查询时延(ms) | 16 | |
Secondary Index实时查询时延(ms) | 25 | |
HDFS | 读吞吐量(MB/Node/Sec) | 640 |
写吞吐量(MB/Node/Sec) | 300 | |
读文件(次/秒/NN) | 100000 | |
写文件(次/秒/NN) | 10000 | |
Zookeeper | 读次数(次/Node/sec) | 12000 |
写次数(次/sec) | 10000 | |
Loader | nfs/ftp->HDFS(MB/Node/Sec) | 100 |
nfs/ftp->HBase(MB/Node/Sec) | 30 | |
HDFS->nfs/ftp(MB/Node/Sec) | 100 | |
HBase->nfs/ftp(MB/Node/Sec) | 30 | |
SOL吞吐量(K TPS/Node/Sec) | 400 | |
Random Message Spout消息处理端到端平均时延(ms) | 55 | |
Kafka | Comsumer读吞吐量(MB/Sec/Node) | 350 |
Producer写吞吐量(MB/Sec/Node) | 70 | |
Redis | 读写吞吐量(K TPS/Node) | 540 |
Flume | spool-file-hdfs (MB/Sec/Node) | 150 |
spool-file-hbase (MB/Sec/Node) | 70 | |
spool-file-kafaka (MB/Sec/Node) | 150 | |
spool-mem-hdfs (MB/Sec/Node) | 200 | |
spool-mem-kafaka (MB/Sec/Node) | 200 | |
spool-mem-hbase (MB/Sec/Node) | 70 | |
FtpServer | 读吞吐量(MB/Sec/Node) | 300 |
写吞吐量(MB/Sec/Node) | 300 | |
Solr | 建索引性能:(MB/Sec/Node) | 7 |
查询性能(s): | 8 | |
建索引性能(MB/Sec/Node) | 1.3 | |
查询性能(s): | 24 | |
批量建索引性能(MB/Sec/Node) | 2 |
系统可靠性需求:
指标名称 | 指标描述 | 指标值 |
MTTF | 平均无故障时间(小时) | 17000 |
MTTR | 平均故障恢复时间(小时) | 1 |
MTBF | 平均故障间隔时间(小时) | 17000 |
指标名称 | 指标描述 | 指标值 |
故障检测时间 | 从故障发生到系统检测到故障,产生告警的时间(秒) | 30 |
倒换时间 | 从发生故障到完成主备倒换的时间(秒) | 60 |
故障倒换业务中断时间 | 倒换过程中的业务中断时间 | 0 |
分布式数据库系统指标需求:
描述 | 指标 |
数据容量 | |
数据容量 | 4PB |
单表大小 | 1PB |
单行数据大小 | 1.6TB |
每个字段大小 | 1GB |
单表最大记录数 | 3000B Row |
单表最大列数 | 1600 |
单表最大索引个数 | 无限制 |
单索引最大包含列数 | 32 |
单表最大约束个数 | 无限制 |
扩展能力 | |
扩展能力(逻辑节点) | 2048 |
扩展能力(物理节点) | 256 |
线性扩展性 | 0.7 |
并发能力 | |
并发连接数 | 600 |
分布式数据库性能规格需求:
组件 | 指标项 | 指标项描述 | 指标 |
MPPDB | TPC-DS 1000X | TPC-DS标准测试集, scale=1000 | 列存:2304.28 |
行存:5480.62 | |||
TPC-H 1000X | TPC-H标准测试集, scale=1000 | 列存:567.06 | |
行存:2875.4 |
分布式数据库可靠性规格需求:
指标名称 | 指标描述 | 指标值 |
故障检测时间 | 从故障发生到系统检测到故障,产生告警的时间(秒) | 25 |
倒换时间 | 从发生故障到完成主备倒换的时间(秒) | 50 |
故障倒换业务中断时间 | 倒换过程中的业务中断时间(秒) | 50 |
分布式数据库接口规格需求:
子系统 | 描述 | 指标 |
JDBC | ||
JDBC4.0 | Y | |
ODBC | ||
ODBC 3.5 | Y |
分布式数据库压缩规格需求:
子系统 | 描述 | 规格说明 | 指标 |
行压缩 | |||
压缩比 | 平均2:1 | Y | |
压缩级别 | 无,不支持级别指定 | Y | |
列压缩 | |||
压缩比 | 平均7:1 | Y | |
压缩级别 | 三种: 低中高 | Y |
分布式数据库并行导入导出规格需求:
子系统 | 描述 | 规格说明 | 指标 |
并行导入 | |||
支持数据格式 | TEXT/CSV/FIXED | Y | |
支持数据导入模式 | NORMAL/SHARED/PRIVATE | Y | |
支持多线程导入 | 最大支持导入线程32个 | Y | |
导入兼容性 | 导入支持非法字符 | Y | |
导入支持日期/时间格式 | Y | ||
并行导出 | |||
支持导出数据格式 | TEXT/CSV/FIXED | Y | |
支持多线程导出 | 最大支持导出线程32个 | Y |
分布式数据库扩容规格需求:
子系统 | 描述 | 指标 | |
集群扩容 | 支持新增集群节点 | Y | |
数据重分布 | 支持将数据均匀分布到新增节点 | Y | |
大集群列存多分区场景,重分布元信息交换阶段节点间串行性能慢 | Y | ||
支持重分布过程中对表做导入超载 | Y |
2.3.5.2功能需求
大数据平台软件功能需求:
1) 大数据平台包括管理应用在内的所有业务组件的管理节点均可实现双机HA,业务无单点故障
2) 大数据平台支持对集群内服务器硬盘故障自动容错处理,支持硬盘热插拔,故障硬盘的业务恢复时间<2分钟
3) 大数据平台支持在系统整体掉电恢复后,能够正常恢复业务
4) 大数据平台支持业务平面与管理平面隔离组网, 保证业务、管理各自网络平面的独立性与安全性
5) 大数据平台支持基于角色的用户权限管理和基于WebUI的统一的用户管理界面
6) 大数据平台相关组件要能够紧跟开源社区版本,厂家能够持续跟踪开源社区新版本和新技术,能够对大数据平台软件进行持续的更新
7) 大数据平台集成有数据集成工具,用于大数据平台与关系型数据库、文件系统间交换数据与文件的能力,需要支持在HDFS/Hbase与关系型数据库、文件服务器间进行双向数据导入或者导出,同时在数据导入导出过程中,支持对文件进行合并、过滤、编解码格式转换等功能
8) 大数据平台应支持在SFTP、FTP与HDFS、HBase之间导入导出数据
9) 大数据平台应支持根据业务优先级进行MapReduce任务调度的功能,对于高优先级的业务,将优先保证业务资源,确保高优先级任务能够按时完成
10) 大数据平台应支持MapReduce容器重用,避免了容器重新分配以及初始化动作,大大减少了容器启动与回收时间,从而提升Job执行效率
11) 大数据平台的Spark组件,应支持DAG打印能力,帮助开发人员可以较快的分析出Job的执行流程是否合理,从而快速进行优化
12) 大数据平台的Spark SQL兼容部分Hive语法(以Hive-Test-benchmark测试集上的64个SQL语句为准)和标准SQL语法(以tpc-ds测试集上的99个SQL语句为准)。
13) 大数据平台的Spark组件,支持支持用户调用Spark Core、Spark Streaming、MLLib的接口来编写和提交应用。
14) 大数据平台的Spark组件,支持shuffle从计算框架中剥离,减少计算框架负担,支持Yarn模式下动态资源调度。
15) 大数据平台能够提供专用的数据导入导出工具,可以方便的导出集群中的数据,并支持在原集群、新集群、异构集群(节点个数不同的集群)进行数据恢复。
16) 大数据平台支持多租户管理,提供大数据统一租户管理平台,实现租户资源的动态配置和管理,资源隔离,资源使用统计等功能
17) 大数据平台易于安装,能够基于易用的图形化页面实现组件的安装、卸载、健康巡检以及服务器节点的增加、卸载等功能。
18) 大数据平台的管理模块应提供可视化、便捷的监控告警功能。用户可以快速获取集群关键性能指标,并评测集群健康状态,同时提供性能指标的定制化显示功能及指标转换告警方法。可监控所有组件的运行情况并实时上报告警,界面帮助提供性能指标和告警恢复的详细方法,帮助用户快速解决故障。
19) 大数据平台应为用户提供界面化的系统运行环境自动检查服务,帮助用户实现一键式系统运行健康度巡检和审计,保障系统的正常运行,降低系统运维成本。用户查看检查结果后,还可导出检查报告用于存档及问题分析
20) 大数据平台能够支持按照用户需要对HBase和Hive中的数据进行列加密。即可对所有数据进行加密,也可只对部分关键数据进行加密。
21) 提供机架组感知的副本放置策略,支持指定数据中心存储数据。当部分数据中心故障,存在可靠的数据中心保障系统的高可用性
22) 支持Hive的数据与其他关系型数据库数据进行跨库Join的功能,通过指定格式的建表语句可在Hive创建关联关系型数据库的外表,这张表可执行Hive的查询功能。
23) 提供统一的API同时访问HBase数据和Solr数据的能力,并将Solr的索引数据应用到HBase的查询中,加速HBase数据的查询。提供了更方便的SQL接口访问HBase数据,自动解析SQL的Where条件使用Solr的索引以HBase数据进行过滤加速。支持敏感词过滤。每个索引集可以关联对应的敏感词集合,在查询的过程中,Solr服务可以对返回结果进行处理,过滤掉其中的敏感词。
分布式数据库平台参数:
非OEM产品拥有自主知识产权,产品核心代码安全可控。
系统架构:支持通用x86服务器架构,支持本地盘部署模式,服务器节点角色平等。支持Shared Nothing的MPP架构,支持全分布式并行执行。采用基于全对称分布式的Active-Active多节点集群架构,系统设计无单点故障。
支持ACID强事务一致性,提供分布式事务机制。
支持TPCDS,TPCH;完整支持不修改语句
支持SQL92、SQL2003标准,支持JDBC、ODBC标准访问接口;
支持灵活选择建立行存表、列存表。
支持完善的全文检索:支持内置(中/英文)全文搜索引擎(支持按词索引、按字索引、字词混合索引的创建)。
支持完善的SQL on Hadoop能力:支持HDFS ORC增删改查,支持索引。
故障恢复:集群管理软件实时监控服务状态、故障实例自动拉起、自动主备切换。支持服务器节点故障或磁盘故障,某个服务器节点或磁盘发生故障时,系统自动故障检测切换,业务不中断
支持支持数据库审计:提供用户登录注销审计、数据库启停审计、用户锁定解锁审计、数据库对象增删改审计等。
可扩展性:支持PB级按需扩展。支持集群内硬件设备跨代兼容(支持不同配置的设备,可均衡利用资源)。
支持完善的分区管理功能,分区drop、add、truncate、merge、split、exchange、cluster、alter index unusable。
支持单表和多表并发IUD(Insert、Update、Delete)。
支持作业重跑,在网络异常、锁冲突等情况下能够保证作业自动重试。
支持图形化安装部署、升级、扩容
2.3.6 大数据平台开放性
大数据平台基于开放社区Apache Hadoop,不使用任何私有架构和组件,支持的组件,如:HDFS、MapReduce、Hive、HBase、Flink、Zookeeper、Oozie等对外提供的接口都遵从开源社区,任何应用开放商(ISV)均可以通过业界标准Hadoop接口实现与大数据平台的对接和开发,同时可以保证未来如果替换此大数据平台,应用开放商的重新开发工作几乎很少。在与现有统一网管系统对接时,大数据平台可以提供Syslog、SNMP标准接口对接。
以下提供组件名需支持的接口类型:
组件名 | 安全模式支持的接口类型 | 普通模式支持的接口类型 |
HBase | CLI、JAVA、Sqlline、JDBC | CLI、JAVA、Sqlline、JDBC |
HDFS | CLI、JAVA、REST | CLI、JAVA、REST |
Mapreduce | CLI、JAVA、REST | CLI、JAVA、REST |
Hive | CLI、JDBC、ODBC、Python、REST(仅限WebHCat) | CLI、JDBC、Python、REST(仅限WebHCat) |
Spark | CLI、JAVA、Scala、Python、JDBC | CLI、JAVA、Scala、Python、JDBC |
Solr | CLI、JAVA、REST | CLI、JAVA、REST |
Oozie | CLI、JAVA、REST | CLI、JAVA、REST |
Yarn | CLI、JAVA、REST | CLI、JAVA、REST |
Flume | JAVA | JAVA |
Loader | REST、CLI | REST、CLI |
ZooKeeper | JAVA、CLI | JAVA、CLI |
Kafka | JAVA、CLI | JAVA、CLI、Scala |
Manager | SNMP、Syslog、REST、CLI | SNMP、Syslog、REST、CLI |
Storm | JAVA、CLI | JAVA、CLI |
Redis | JAVA、CLI | JAVA、CLI |
2.4 数据治理
数据治理是指从使用零散数据变为使用统一主数据,从具有很少或没有组织和流程治理,到全业务范围内的综合数据治理,从尝试处理主数据混乱状况到主数据井井有条的一个过程。
传统数据治理模式,是从海量数据的清洗做起。在形成大数据集后,逐步通过业务与数据理解,形成数据应用。基于传统关系性数据库技术特性,数据汇聚与数据清洗工作量是巨大的。在数据汇聚清洗入库过程中,虽然保证了大量异构数据入库数据的正确性和一致性,但同时也有很多的缺陷:包括了数据损伤、数据模型定义灵活性差、数据入库实时性等一系列问题。
摈弃传统ETL数据汇聚的工作模式,从公安的大数据本质入手创新数据治理工作的方法,通过建立一种多规范、融合型的数据模型定义公安大数据库,面向结构化、半结构化、非结构化的各类数据,通过多规融合的数据模型定义,在数据同步入库的同时,完成数据的规范清洗,同时又能保持其有一定的数据冗余,用于对数据质量进行进一步的跟踪与提升。
2.4.1 数据处理引擎
对公安机关大量收集的文本等非结构化数据、视频类数据进行统一的再结构化处理,为机器深度学习提供良好的基础数据条件。
包括结构化数据处理、文本类数据处理、视频类数据处理、SQL引擎等。
2.4.2 数据标准
以实际工作出发,参考大量相关公安标准规范建立数据整合规范,解决数据标准、数据质量、共享方式等问题,用资源描述的主体类型对数据资源进行的分类建库,为上层各个应用提供数据支持。
用资源描述的主体类型对数据资源进行的分类建库,建库标准参照但不限于:
代码 | 名称 | 说明 |
1 | 人 | 以自然人为主体进行描述的数据资源。 |
2 | 物 | 以特定的物为主体进行描述的数据资源,针对不同情况涵盖不同的内容,包括物品、物证、微小痕迹、尸体或法律文书等,如:法医→昆虫;森警→动物;警务→犬;治安→犬等。 |
3 | 组织 | 以法人、单位、特定人群组织结构(如:户)为主体进行描述的数据资源。 |
4 | 虚拟标识 | 特指仅有虚拟服务标识、无法具体判断是否为个人或组织的数据资源。 |
5 | 时空 | 以时间、地点为主体进行描述的数据资源。 |
2.4.3 标准数据治理
提供的数据治理包括标准治理和深度治理,其中标准治理对应的就是传统数据治理的范畴,将来自不同客户那里,杂乱无章的数据(如:空值、缺失值、非法值、缺失记录、重复记录、数据类型多样等)进行清洗,整理成有处理价值的信息。
包括新建数据元、转换规则库、数据字典维护、自动化匹配与检测等功能。
2.4.4 深度数据治理
针对公安领域的多源异构数据,基于融合技术,进行属性识别以及非结构化数据的自动结构化,从而实现割裂在不同信息孤岛上的多源异构数据的自动融合,使得数据治理过程能实现有限范围的自动计算匹配,并采用数据标准化工具公安部数据元标准的进行映射对照,减轻数据治理的工作量。
包括字段对标、批量对标、深度去重计算。
2.4.5 可视化关系分析构建
将数据抽象成实体、关系、事件三大类,用来实现知识图谱的构建,让平淡的数据活起来,将知识网络搭建起来。
基于实体-对象二维理论,将现实中的人、案、物抽象为实体表示为图标,实体之间的关系抽象为链接表示为连线,将数据直观的展现在关系可视化研判系统中,并找出数据背后的关联。根据行业和业务特点来针对性的建立实体库,并可以随时调整和优化实体库来满足客户的需求。从业务角度讲,所有的关系都可以被系统构筑并管理,所有的关系包括但不限于:人与人之间的通讯关系、社交关系、家庭、户籍、资金往来、住宿出行等关系,人与事件、建筑、车辆、IP的关系。
2.4.6 数据治理清洗任务
项目承建方负责对用户的数据,按照项目需求、专题数据建立需求、用户业务需求等,进行相关的数据清洗治理工作。需要打破原数据类别之分,按照要素、关系等需求对数据进行清洗组合,满足平台数据分析、碰撞需要。项目初期数据清洗量不少于900余类500亿条,200TB,包含结构化、半结构化、非结构化数据处理,按照平台需求,完成图数据、专题数据整理。并根据项目数据汇聚情况,负责汇聚数据的治理清洗任务,并按需形成专题数据,满足平台项目应用需求。
2.5 数据库资源池
2.5.1 数据汇聚库
建立数据汇集库,将各类原始数据、历史数据、各类来源副本数据进行存储,具有数据管理功能,可以作为原始数据依据使用。
2.5.2 基础数据库
将抽取过来的各类业务信息,利用数据整合处理对各种来源数据进行数据抽取整合处理,按公安专门业务信息的主要信息要素—人员、案事件、地址、机构、物品为主题进行整理和组织,并建立内部和相互间的有机联系,形成基础数据库。
2.5.3 关联库
依据建立“五要素”索引层的需求,统一控制人员、案(事)件、地址、组织、物品公共项采集源头。
基础数据库包括人员信息、物品信息、案件信息、地址信息,以及组织信息和服务标签等内容。
2.5.4 专题库系统
按照业务、专题等要素,形成数据专题,包含但不限于常见各类数据专题等,在项目进行中与维护期内,根据用户所掌握数据和专题分析需求,建立相关的数据专题数据库,进行相关数据专题分析应用支撑。
★投标方须详细设计描述出数据专题构建,不少于5类。
2.5.5 战法模型资源库
战法模型是将日常核心业务用到的战法功能抽取成服务,并进行优化、完善和扩展,为业务部门的不同业务工作提供服务支撑。
将常用的分析战法进行固化、封装,并发布到系统中通过设置功能权限的方式开放给不同的用户使用基于现有的数据情况,
本期项目主要提供但不限于以上战法来满足业务的分析需求,并可根据用户数据情况与需求,进行相关战法的固话,封装。
★投标方须详细设计描述出战法构建,不少于10类。
2.5.6 公安知识图谱库
平台基于机器学习和实体识别技术,从基础数据库和专题数据库中提取各类实体,基于图数据库技术将实体之间的关联关系以知识图谱的形式保存下来,可用于支撑各类可视化的研判场景。包括技术选型、图数据导入、图建模、图查询等。
2.6 全景检索应用
全景检索是基于严格治理后的大数据资源提供的一种分布式全文检索,通过建立分层、分类索引,确保可以从多个维度检索、发现隐藏的数据关联,提供基于实体、关系和事件的全文检索功能。从而对数据做到真正的三位一体、全方位的了解和掌控。
支持通过碎片化、离散化的文本信息输入,输入身份证、号码、姓名、案件关键字等内容,实现海量数据的全要素一键式检索,智能检索提供带有复杂查询条件的关键词检索,如:逻辑组合检索(与、或、非)、通配检索、同义词查询、渐进检索、词根检索、关键词检索、分类检索、二次检索(渐进检索或在结果中检索)、时间段检索、年龄检索、姓名拼音检索等多种专业检索方式。支持跨库分类检索、字段精确/模糊检索、拓展检索、全网检索等多种智能检索方式。
系统后台实现对业务系统数据进行不同维度分类管理,如按五要素分类、资源库分类、业务分类等,在检索页面上支持选择某一具体分类进行检索,检索结果按照选择的分类进行展示,如选择五要素(人员、案(事)件、物品、组织机构、地点)中的某一个要素进行检索。
2.6.1 关键词检索
通过输入身份证、号码、姓名、案件关键字等内容,实现海量数据的全要素检索,系统将依据用户权限情况进行查询结果明细数据的列表展示。
★投标方须详细设计描述出关键词检索功能。
2.6.2 跨库分类检索
系统后台实现对业务系统数据进行不同维度分类管理,如按五要素分类、资源库分类、业务分类等,在检索页面上支持选择某一具体分类进行检索,检索结果按照选择的分类进行展示,如选择五要素(人员、案(事)件、物品、组织机构、地点)中的某一个要素进行检索。
★投标方须详细设计描述出跨库分类检索功能。
2.6.3 字段精确/模糊检索
支持用户可以选择某一具体数据表的单个或多个字段,形成查询表单,字段内的内容进行精确匹配或者模糊检索。利用搜索引擎架构,继承全文检索的优点,实现类似传统的数据库精确查询。
★投标方须详细设计描述出字段精确/模糊检索功能。
2.7 全息电子档案应用
提供基于全息档案研判的电子档案应用模式,全息研判是指借助可视化手段,将电子档案中的各类信息串连起来,为人工研判提供交互友好、直观的信息展现。为提供一线公安业务干警可以通过这些经过整理、标签化的数据基础上,掌握精准、全面的信息。
2.7.1 人员电子档案
人员全息电子档案通过对人员各类背景资料进行汇集,实现数据汇聚时实时动态更新,展示人员基本信息和各类关联信息。
★投标方须详细设计描述出人员电子档案功能。
2.7.2 车辆电子档案
建立起统一、全面的车辆电子档案。包括基本信息、年检信息、违章信息、等一系列可能信息。通过对接车辆关系分析系统和其它系统(如地图),车辆档案还支持关系分析、时间轴展示、地图轨迹分析等功能。
★投标方须详细设计描述出车辆电子档案功能。
2.7.3 案事件电子档案
案事件全息电子档案通过对发生的关注案事件以及围绕该事件的各类背景信息进行汇集构成案事件全息电子档案。
★投标方须详细设计描述出案事电子档案功能。
2.7.4 虚拟标识档案
根据用户数据与实战应用需求,对虚拟标识等信息进行组合,以电子档案形式进行组织,展现、应用等。
★投标方须详细设计描述出虚拟标识电子档案功能。
2.7.5 其他电子档案
根据用户数据与业务应用需求,对相关数据进行组合,以电子档案形式进行组织,展现、应用等。
2.8 可视化研判应用
使用图数据库做为分析基础,分析结果进行可视化展示,操作方便快捷,可视化程度高。人员通过图标颜色进行展示,专题人员和前科关注人员也通过特定颜色进行醒目展示,颜色可自定义。超级图谱可以通过页面级接口在其他功能模块中调用展示。
★投标方须详细设计描述出可视化应用类功能。
1、可视化图形操作
平台基于图数据库,最大亮点是可视化分析,分析结果以图谱聚类展现,所有功能图形化集成,操作方便快捷,可视化程度高。
2、无限层级基础关系网络分析
3、亲密度分析
4、两两分析
5、多人同时分析
6、全局分析
7、群体分析
★投标方须详细设计描述出关系分析构建。
2.8.1 关系推演
关系推演服务支持人到人、人到物、物到物和人到案等各种实体之间的关系发现,允许根据复杂过滤条件,围绕人、物,不断发现与其相关的其他关系人、关系物;同时,也支持关系路径查找,能够自动查找多个人、物在一定步数内的关系路径,并形成关系子网;此外,当扩展实体不能直接找到有价值线索时,还应支持显示某些实体扩展的事件,。而且在基于单个实体实时动态扩展与其有实体关系的基础上,还要能提供在两个或两个以上实体基础上进行直接推演或条件推演的服务,最终得到与选中实体相关联的新实体及其相应关系。
2.8.2 关系发现
提供证号批量输入(以分号间隔)或模板导入的简易接口,方便业务人员将研判群体快捷导入系统,系统自动将导入的对象显示在画布上,业务人员可使用关系自动推演功能,系统自动计算相关对象之间的显性或隐性关系,并将与存在关联关系的其他人从社会关系网络中检索出来,从而勾勒出社会关系网络,为研判提供有力支撑。
2.8.3 多元轨迹时空可视化
结合轨迹分析算法以及部分关系战法,支持对数据基于时间-空间的实体/事件/轨迹进行关联分析,时间分析有时间轴和动态时间卷轴,以及对接警用GIS系统或主流开源地图,结合其地理信息数据提供多元多维度分析。可将具有坐标元素的所有数据内容与警用GIS系统结合,进行数据地图展现,进行时空、区域、轨迹展现分析、研判应用。
基于各类专题数据和警用地理数据图层,实现数据检索功能。可实现基于时间序列进行时间轴排列可视化展示。
可根据海量的轨迹数据进行多类时空专题分析。
与预警模块、比对模块及热点数据分析模块对接,可实现布控信息、预警信息、各类信息数据GIS地图上实时显示,展示数据信息及位置,数据分布、热力展现等。
★投标方须详细设计描述出多元轨迹时空可视化功能。
2.8.4 社会网络分析
★投标方须详细设计描述出社会网络分析功能。
2.9 模型超市
模型超市以数据分析、面向业务建模、数学算法等处理挖掘技术,融合大数据平台的高速检索、可视化、数据挖掘、多维分析等高新技术,在数据研判工作信息化、高效化的基础上提升数据研判的有效性、专业性,为优质产品的生成打下坚实基础。
研判服务集主要包括两大部分,即基础研判服务集、业务服务集。支持可视化自助拖拽自建模型,可进行模型的共享、发布,可共享给其他业务用户共享使用,并进行二次自定义。
2.9.1 模型超市搜索
模型搜索:根据关键字或模型归类标签快速查找所需模型。
模型推荐:即搜索关键词推荐,给用户以明确的查找关键词,便于准确查找所需模型。
2.9.2 模型分级管理
根据用户权限不同实行模型分级管理。
2.9.3 业务分类
根据业务分类,按业务部门、其他业务单位使用。
2.9.3.1模型创建单位分类
可以根据创建模型单位所属分局进行分类,其他单位和业务部门也可以使用。
2.9.3.2模型应用类型
每一个模型在上传到应用市场前都需要打上相应的分类标签,一个模型可以同时具有多个标签,上传后系统自动将模型归为相应的类别,用户可以按照分类快速进行模型查找。
2.9.3.3最近更新模型
最近更新模型展示为系统管理员根据业务诉求及实践检验发布的新模型或者迭代模型,按发布时间排列。
2.9.3.4热门模型推荐
系统提供模型智能推荐功能,智能推荐根据不同用户的浏览和下载行为以及不同模型之间的关联关系为用户自动推荐其关注的模型。可以按照周、月、季、年等时间维度进行过滤筛选。
2.9.4 模型档案
为便于更直观展示功能应用,让操作人员了解模型用途,快速选定自己需要使用的模型,系统为每一个模型都建立了一个独立的档案,档案以类似个人页面的方式展现,包括对模型的描述、模型的快照、模型使用的数据源、模型的应用场景、模型的创建人、创建时间、模型更新时间、历史版本、下载量、好评量等。
2.9.5 模型来源
模型的需求发起人,模型的创建人,模型审核人,模型所属单位、模型创建时间。便于模型需求方在查看模型介绍时,了解模型来源,与模型提供者直接立沟通和联系,研究模型完善方向,让模型更具生命力。
2.9.6 模型应用中心
2.9.6.1我的应用
每位用户都拥有个人专属的模型应用页面,里面包含了该用户关注的所有模型,用户可以自定义筛选条件,即时查看模型结果。
2.9.6.2模型推荐
当用户进入我的应用或者要去下载某一个模型时,系统就会自动为其推荐相关模型。
2.9.6.3模型查看
用于模型的查看。
2.9.6.4用户使用监测
系统通过内置评价标准可以对使用人员和建模人员进行评价,提高模型使用人员和建模人员的积极性。
使用人员评价
通过分析使用人员的登录次数、使用模型数量、使用模型频次、需求提交量、需求拒绝量、需求通过量、点赞量、评论量、战果申报量等指标加权计算进行评价。
建模人员评价
通过分析建模人员或单位的建模数量、所建模型下载次数、所建模型使用次数、所建模型点赞数量、所建模型评论好坏、建模速度等指标加权计算进行评价。
2.9.6.5模型效果评价
使用人员对每一个模型都可以进行点赞、评论、打分,所以通过分析下载次数、下载频率、点赞个数、评论内容、打分分数、更新频度等因素,可以对每一个模型进行定量评价,积极推广优秀模型,淘汰落后模型.
2.9.7 基础研判服务集
基础研判服务集将研判业务中使用到的基础功能抽取成服务,为研判业务模块提供基础的功能实现。研判业务模块可以直接调用基础研判服务集中的服务接口实现其功能。基础研判服务包括轨迹服务、轨迹分析算法和战法服务。
2.9.7.1轨迹服务
基于各类专题数据和警用地理数据图层,实现与PGIS地理平台系统的功能接口,将PGIS地理平台系统提供的各类地图计算和展示功能嵌入到页面中使用,实现数据检索功能。
时空分析基于海量的各类轨迹数据,对轨迹分析,制定多模板的轨迹分析。
以图形化关联分析为基础,通过灵活的配置工具,提供易于理解的查询分析功能和分析结果,挖掘时空关系,关联关系,并利用实名动态信息,为挖掘案件线索提供强大的支撑。
招标
|
大庆市政府采购中心 关注我们可获得更多采购需求 |
关注 |
最近搜索
无
热门搜索
无