XX学院数据治理平台建设项目采购需求.docx

《XX学院数据治理平台建设项目采购需求.docx》由会员分享，可在线阅读，更多相关《XX学院数据治理平台建设项目采购需求.docx（58页珍藏版）》请在课桌文档上搜索。

1、XX学院数据治理平台建设项目采购需求一、项目背景自建校以来，学校根据国家政策要求和学校发展需要，积极推进信息化建设,建成了覆盖全校的校园网络基础设施以及一批基于业务单元的应用系统（如教务系统、0A、财务系统、人事系统、科研系统等），并搭建了基础平台，包括统一身份认证平台、共享数据中心、数据清洗与整合平台和信息门户平台，解决了面向用户的门户使用，进行了数据的集中整合。在一定程度上,达到了预期的目标。根据学校信息化现状的分析与研究，目前学校在信息化建设方面虽已取得一定成效，但仍有许多问题亟待解决：1、已有数据标准，但标准不满足目前现状。学校数据标准及信息标准滞后，不符合目前学校行情及国家行业标准。

2、目前校级信息标准已不能指导目前数据中心的信息化建设，参考标准难取用，代码标准、接口标准、下行开放标准缺失，信息标准电子文档难维护、难使用，缺失关键数据管理细则、数据标准管理报告等问题突出。2、数据质量问题突出，缺乏数据治理能力前期共享数据中心建设主要解决了学校各部门数据孤岛问题，实现了基础数据集中管理、达到数据共享交换的目的。但是数据质量问题、数据同步、缺失问题还是很普遍，一方面以往关注点主要是在基础的主数据交换，另一方面数据质量的管理难度大，缺乏工具和标准，处于比较粗放的状态，对数据治理的重视程度也不够高，制度上也缺乏保障。加之在大数据背景下，各种应用系统产生的数据越来越多，越来越快，同时师

3、生服务、管理、决策、以及教学科研的各种活动对数据质量和可信度要求也越来越高。3、重复填报、统计过程繁琐从学校实际情况来看，每年各类业务填报没有数据支持，还在采用较为原始的纸质手段进行，使得数据项重复填报、业务系统数据无法提供支撑，已经沦为常态，同时，数据质量还面临巨大的考验，填报的准确性有待考量。二、建设目标本次项目总体建设目标是从学校当前的建设现状出发，实现学校信息化建设的现代化和智能化。通过开展以需求为导向、以互联共享为核心、以信息安全为保障的信息化建设，推进以数据共享为目标，整合学校多源头的数据资源，治理学校数据资产，帮助学校建立起一套合规的、可持续提升的数据规范体系，保证对于核心数据资

4、产的沉淀和积累，真正达到数据的准确性和权威性保障。主要包括以下几个方面：建设符合学校实际情况的校级数据字典和信息编码标准，包括各类信息子集标准、代码标准、数据交换标准、接口标准、数据模型标准等；编制学校各项数据管理规章制度；建立各信息系统与数据中心的数据交换机制，保证系统之间相关数据及时同步，打破信息孤岛；建设学校全量数据管理平台，对学校教务、人事、科研、财务、0A、一卡通等主要信息系统生产的数据进行全量采集、清洗整合、主题分类、分层管理，以师生数据全生命周期为主线，实现全校资源数据的有效存储与管理；建设全校数据质量监控体系，保证进入数据中心数据的规范性、完整性、一致性、准确性，定期发布数据质

5、量报告；建设数据填报平台，满足缺失数据、临时数据、报告报表数据的填报采集需要；具备信息标准、全量数据、数据交换使用可视化大屏分析展示平台。建设数据开放平台，让全校师生共享数据治理成果，并参与到学校的数据治理过程中，提高学校数据质量，建设学校自己的数字化的智慧的校园。三、建设内容序号建设内容数量单位备注1全量数据中心1套/2全量数据质量管理平1套包含12个业务系统的数据质量台检测3全量数据开放平台1套4一表通平台1套包含50个表单设计5系统集成10个包含10个新增业务系统的系统集成6数据大屏2个大屏最终内容以校方确认为准四、技术、功能指标序号技术、功能指标1全量数据中心1.1基础性框架软件1.1

6、.1为学校搭建大数据平台和各种组件，包括但不限于以下内容：提供各种能够快速稳定运行的数据计算框架，如Spark；使用ApacheImpala做为对HDFSHBase的高性能SQL查询引擎；使用Hive数据仓库工具帮助用户分析数据；提供CM安装HBase分布式列式NoSQL数据库；包含原生的Hadoop搜索引擎以及ClouderaNavigatorOptimizer去对Hadoop上的计算任务进行一个可视化的协调优化，提高运行效率；提供的各种软件能让用户在一个可视化的Ul界面中方便地管理、配置和监控HadOOP以及其它所有相关组件，并有一定的容错容灾处理；提供基于角色的访问控制安全管理。1.1.

7、2l.l.Iw所提到的大数据分析的相关框架软件，其名称、版本不做强制要求，投标单位可以按自己的中台软件产品灵活进行软件系统架构设计，但其中台产品必须有明显的基于基础性框架软件进行设计、构建的相关描述及设计概要说明。1.2全量数据标准管理系统：信息标准的实施是数据治理的首要措施，是数据运用的基石，在数据中心架构设计的过程中，数据标准将一直影响和指导学校的业务发展，并提供权威参照依据，标准也会随着需求的变化而不断的更新。1.2.1技术性需求1.2.1.1平台需内置包括2012年部标【教育部-教育管理信息标准-高等学校管理信息(JY/T1006-2012)】、2013年国标【中华人民共和国国家标准G

8、B/T298082013】、2018年国标【中华人民共和国国家标准GB/T35298-2017以及行业经验标准等；内置的参考标准应支持任意取用、下载；支持自定义标准。1.2.1.2基于国家标准和教育部标准，在现有学校信息标准的基础上，建立完善学校数据标准体系，包括数据集标准与数据代码标准，并支持可视化管理。1.2.1.3平台需和全量元数据及关系管理系统可实现联动，支持四层标准草案的管理，包括原始层、主题层、统计层、应用层标准的在线配置、模板导入和批量取用。1.2.1.4要求提供所投产品适配国产数据库、国产操作系统和国产服务器的国产化软硬件认证证书复印件。1.2.2功能性要求1.2.2.1数据管

9、理员首页：系统应提供数据管理员首页统计展示，应支持对参照标准统计、全量数据中心采标率统计、标准草案统计。1.2.2.2参照数据标准管理1.2.2.2.1参照数据标准首页：应支持数据集、代码集的查看、下载，支持新增/编辑数据集，发布/停用数据集，下载和配置数据集。1.2.2.2.2参照数据标准配置页：系统应支持自定义数据集，内置数据集、内置代码集功能，应提供标准内容的导入/导出；新增目录/表/数据项，且必须支持批量新增；支持删除目录/表/数据项，且必须支持批量删除；提供批量取用已发布参照标准的功能。1.2.2.3标准草案管理：需管理学校自定义的标准草案，在成为执行标准前支持在此页面进行标准代码集

10、、数据集的单独管理、维护。需支持学校自定义标准草案时新增、修改、删除、配置等基本操作。1.2.2.3.1草案首页：应提供标准草案的拟定功能，包括数据集、代码集的新增/编辑/删除和发布。1.2.2.3.1.1新增标准草案：需支持新增草案，提供输入草案名和草案描述的功能。1.2.2.3.1.2信息标准发布：需支持学校自行编辑的信息标准，信息标准内容只有通过发布才会成为本校执行标准，提供给其他普通用户查看。1.2.2.3.1.3信息标准删除：需支持删除学校自行创建的信息标准。1.2.2.3.2草案配置页面：草案配置页面应支持取用参照标准、自定义标准草案、批量导入标准内容。1.2.2.3.2.1需支持

11、数据集的分层管理，支持每层标准内容的导入导出；应提供批量取用数据集标准（已发布参照标准、执行标准、元数据）；应支持批量新增目录/表/数据项，编辑目录/表/数据项，批量删除目录/表/数据项；需提供移动数据项功能。1.2.2.3.2.2需支持代码集管理，应提供标准内容的导入/导出；应提供批量取用代码集标准（已发布参照标准、执行标准、元数据）；应支持批量新增目录/表/数据项，编辑目录/表/数据项，批量删除目录/表/数据项；需提供移动代码项功能。1.2.2.4执行标准管理：需对经标准草案发布的标准（数据集和代码集）进行管理，能查看数据集、代码集，支持对各个历史发布版本进行统一管理。并能设置和取消各发布

12、版本的执行状态。同时支持一键同步标准数据表至全量数据中心元数据。1.2.2.4.1执行标准首页：应支持数据集标准管理，应支持下载执行标准数据集文档、基础信息展示、结构图谱展示、更多版本管理、执行标准同步至元数据。应支持灵活选择管理标准分层（原始层、主题层、统计层、应用层）一键同步至元数据。应支持代码集标准管理，提供下载执行标准代码集文档、基础信息展示、更多版本。1.2.2.4.2执行标准配置：需支持数据集分层管理，包括预览建表语句、批量导出建表语句、批量导出标准内容；应支持代码集的批量导出标准内容。1.2.2.5数据中心采标率：需支持查看数据中心采标率，需支持查看不同业务系统中表的历史变化情况

13、。1.2.2.6标准对比分析管理：通过不同标准之间、标准与元数据之间的对比，应支持通过图形化、数据表形式体现目标标准与对比标准的详细差异。1.2.2.7标准管理办法：协助学校根据实际情况制定出适合本校的数据管理办法，并支持管理办法的新增/编辑/删除/下载和在线预览。1.2.2.8提供数据标准管理的功能演示，要求演示标准草案的制定可以灵活取用参考标准的功能，实现对标准的在线制定；要求演示灵活选择管理标准分层（原始层、主题层、统计层、应用层）进行标准管理的功能，支持导出标准内容的功能；演示标准的结构图谱以及更多历史版本标准的查看功能。1.3全量元数据及关系管理系统：全量元数据及关系管理系统用于管理

14、全量数据中心的所有元数据的产生和迭代过程，记录元数据与数据中心结构的变化，客观反应数据业务属性、技术属性和管理属性，基于元数据的管理功能，有效解决元数据和数据标准之间的业务连续性问题，建设为实现教育业务系统间的数据资源共享与信息交换以及实现业务综合报表、决策知识挖掘、决策分析提供的基础支撑。1.3.1技术性需求1.3.1.1基础性技术要求1.3.1.1.1系统需采用开放、标准的数据库设计。平台需基于SOA思想，以XML为信息交换语言，需支持跨平台部署，对数据库中的表与数据项都提供中文备注。1.3.1.1.2数据来源需支持完全自定义模板配置，需支持可编程化查询语句有效兼容了所有业务数据查询方式，

15、需支持对外提供开放的数据访问服务接口，并实现对服务接口的管理，需支持对服务接口名称和描述的编辑，以及对接口的授权管理。1.3.1.1.3系统需遵循“谁产生、谁维护”的原则，所有的数据都有唯一的产生者和维护者。在管理上，需通过制定相应的应用规范要求数据生产者/维护者及时更新自己负责的数据，从而保证全量数据中心的数据按照学校信息标准更新。1.3.1.1.4系统需提供覆盖了全面的日志记录，需实现用户对系统标准的变更，元模型的变更，以及数据服务调用都是有详细的日志信息可以追溯。1.3.1.1.5要求提供所投产品适配国产数据库、国产操作系统和国产服务器的国产化软硬件认证证书复印件。1.3.1.2其他要求

16、1.3.1.2.1整体架构要求：整体架构需采用分层设计的方法，各层具有独立的功能含义和实施要求。需包含：原始数据层、主题明细层、汇总统计层以及应用数据层。详细如下：1.3.1.2.1.1原始数据层（原始层）：原始层数据结构与源业务系统最为贴近，设计功能要求与业务系统松耦合、源业务系统数据接入完整、数据的增量识别、短期的历史数据、高效的数据接入、中心库的数据来源、完整的源业务系统数据明细。1.3.1.2.1.2主题明细层（明细层）：设计功能要求：数据按主题存储、快速的数据查询结构、统一的业务编码、中长期历史数据、与行业标准结构贴近、完整的业务相关数据明细。1.3.1.2.1.3汇总统计层（统计层

17、）：设计功能要求：数据可以是汇总数据、可以是快照数据、不包含明细数据、可满足初级的统计要求；是数据分析常用的数据源。本层数据主要由应用层展现要求而反推出的汇总中间数据，一般不是最终结果数据，而是大粒度的半结果性数据，主要作用在于提高后期查询互动的性能。1.3.1.2.1.4应用数据层（应用层）：设计功能要求：数据根据实际数据需求生成，满足表格、图形等数据展示和应用；是数据计算的最终结果，无其他数据处理过程依赖此数据库。此层数据形式大都是简单视图方式，提供给各应用系统（如门户、综合校情分析、手机门户等）直接使用。其创建需求就是来自于各应用系统的数据接口需求。1.3.1.2.2数据流向要求：数据流

18、向要求数据能够从各个系统的接口出发，通过ETL工具将数据抽取到原始层，然后再根据主题数据标准的映射规则将原始层数据通过已有数据清洗与整合工具进行清洗、转换并装载到主题层，再根据分析需求，将主题层的数据做相应的计算并装载到统计层。最后，将门户需要展示的数据视图、报表中心需要的数据视图、个人中心的数据视图以及数据中心对外的接口表或者视图写到应用层进行统一管理，实现对数据全生命周期的管理。1.3.2功能性需求1.3.2.1数据管理员首页：系统应提供数据管理员首页统计展示，应支持数据中心总存储空间统计、数据中心表总数统计、数据中心数据项总数统计、数据中心数据总条数统计、参与数据交换系统（平台）总数统计

19、、流入数据总条数统计和流出数据总条数统计；并可查看今日数据中心数据流向一览。1.3.2.2元数据管理1.3.2.2.1数据集元数据：基于数据中心四层架构模型，通过数据集元数据进行每一层元数据的管理，需提供个性化的配置方式支持在线配置数据集。支持界面增删改等基本操作，也包括手动/自动全量同步元数据至全量数据中心、反向同步至元数据，并可立即检测源表对比情况。系统需支持每一层的统计信息展示，原始层元数据需展示机构/平台的统计，集成的业务系统统计，表/视图个数/数据项统计系统应支持批量导出数据集、批量导出SQL、批量导入数据集；支持对目录/表/数据项的新增、编辑、删除；需具有更新待同步表至全量数据中心

20、的功能，更新变化表至元数据、移动数据项排序。系统应支持自动识别原始层的表是否存在转换（有原始层映射关系则代表有转换），若不存在转换则支持“在线生成转换”。是否配置转换的更新频率应与自动提取映射关系强相关。系统在线生成转换的转换需符合命名规范：上行业务系统名称.表中文名称。1.3.2.2.2提供元数据中数据集源表采集以及在线自动生成转换作业的功能演示，演示对业务系统所有权限范围内表的源表采集，并演示同步至全量数据中心；演示在线的对表进行转换作业的自动生成功能。1.3.2.2.3数据集元数据结构图谱：系统需支持图形化展示各层数据集元数据机构，展开/收缩子集分支。1.3.2.2.4代码集元数据：需管

21、理全量数据中心代码表表结构，提供个性化的配置方式在线配置数据集。支持界面增删改等基本操作，包括手动/自动反向同步至元数据。系统需支持每一层的统计信息展示，包括代码集、代码表的统计。系统应支持批量导入代码集、批量导出代码集、支持对目录/表/代码项的新增、编辑、删除；更新变化表至元数据。1.3.2.2.5代码映射关系管理：需支持代码映射关系管理，分别记录原代码目录、原代码表表名、原代码表数量、映射表表名、代码映射关系数、预警映射关系数，应支持编辑、删除操作。需支持新增代码表映射关系、立即检测代码关系、导出文件等功能。1.3.2.2.6数据集监测日志管理：应支持数据集变更日志统计，分别记录数据集和代

22、码集数据项变更的情况，展示全量数据中心元数据正向/反向同步元数据表的更新记录，包括数据集元数据和代码集元数据。方便追踪数据中心元数据的变化情况。1.3.2.2.7代码集监测日志管理：应支持代码集变更日志统计，分别记录数据集和代码集数据项变更的情况，展示全量数据中心元数据正向/反向同步元数据表的更新记录，包括数据集元数据和代码集元数据。方便追踪数据中心元数据的变化情况。1.3.2.2.8UC矩阵预览：系统需支持UC矩阵预览（包括数据表和字段级的预览），原始层的表结合映射关系通过系统自动识别表的使用者，快速生成UC矩阵。1.3.2.2.9映射关系管理：需实现数据之间的字段级的映射关系管理。1.3.

23、2.2.9.1原始层映射关系：系统需支持实时读取数据清洗与整合平台作业数据表解析，需提供新增映射关系，查看/编辑映射关系详情，查看映射关系，删除映射关系。1.3.2.2.9.2主题层/统计层映射关系：系统需支持实时读取数据清洗与整合平台作业数据表解析，需提供新增映射关系，查看/编辑映射关系详情，在线配置映射关系详情，预览映射关系，删除映射关系。1.3.2.2.9.3应用层映射关系：系统需支持实时读取数据清洗与整合平台作业解析视图，需提供新增映射关系，查看/编辑映射关系详情，在线配置映射关系详情，预览映射关系，删除映射关系。1.3.2.2.9.4提供全量数据中心元数据管理功能演示，应至少包含数据

24、集元数据、数据集元数据结构图谱、代码集元数据、数据集监测日志管理、代码集监测日志管理。其中数据集元数据包含主题数据层、统计数据层、应用数据层，并且每一层中的数据子类详细信息需至少包含中文名称、数据项名、长度、值空间、主键、解释举例等内容；同时数据集进行整体支持导入、导出和SQL语句导出功能，并且可以针对某一数据自行进行新增和批量操作。1.3.2.2.10元数据关系分析：系统需利用元数据可视化展现映射关系的定义，描述元数据之间复杂的映射关系；应支持通过多对多的映射形成元数据之间的完整拓扑，形成全量数据中心四层架构数据表之间复杂的关系图谱。元数据关系分析分为UC矩阵分析，全链分析，血缘分析，影响分

25、析等多种分析页面，需根据我校不同业务场景支持查看不同的分析页面。1.3.2.2.10.1UC矩阵分析：应支持UC矩阵分析关系图谱，按照数据维护分布图和数据使用图分别反应各业务系统维护、使用表的整体情况。关系粒度要细化到表中字段级别。1.3.2.2.10.2全链分析：应支持全链路展示并分析全量数据中心四层架构间各表的关联关系。关系粒度要细化到表中字段级别。1.3.2.2.10.3血缘分析（该功能需提供清晰截图证明并加盖单位公章）：应支持对某数据表向上分析查找该表的祖父表至原生业务系统，快速定位数据问题。需提供图形说明、血缘图谱展示、关联映射关系。关系粒度要细化到表中字段级别。1.3.2.2.10

26、.4影响分析：对某数据表向下分析查找该表的使用对象至业务系统，需提前预测修改某字段属性给下游系统或部门带来的影响。需提供图形说明、影响分析图谱展示、影响表统计、关联映射关系。关系粒度要细化到表中字段级别。1.3.2.2.10.5数据地图（该功能需提供清晰截图证明并加盖单位公章）：需以三维立体地图的方式反映各个部门之间数据的流向，包括数据流入、流出的动态模型展示。1.3.2.2.10.6提供元数据关系分析管理演示，要求演示U/C矩阵分析、全链分析、血缘分析、影响分析、数据地图。要求演示进入全链分析可以以图形的方式展示四层架构的数据关系，要求演示向上追溯系统，找数据如何产生，向下可以找到数据的影响

27、分析，找到数据的使用方向。1.3.2.3历史拉链管理：历史数据拉链管理对主数据非常重要，后续分析也会经常要使用到历史数据，问题出现也会去查询数据的历史拉链。因此，系统需在原始层提供历史数据拉链的管理功能，对原始层元数据进行数据拉链的设置，然后进行数据历史拉链的查看，并提供数据变更对比分析功能，分析某张表在不同时间的历史数据以及数据更新情况。1.3.2.3.1配置历史拉链：需支持批量设置历史拉链和批量取消历史拉链，支持单个表是否设置历史拉链。1.3.2.3.2查看历史拉链：应支持历史拉链的查看、历史拉链分析（按日期）。1.3.2.4数据服务管理1.3.2.4.1数据查询分析工具：需通过数据垂直搜

28、索的方式提供可视化、自定义SQL等个性化方式查询全量数据中心数据表中的数据。通过自定义SQL查询支持保存查询模板、导出数据。通过可视化查询支持保存查询模板。1.3.2.4.2应用系统管理：应支持对接入的业务系统实现统一管理的功能，支持查看应用系统的名称、所属机构、系统类型、全量数据中心参与角色、服务授权数、授权IP地址、授权序列号；支持对业务系统编辑/服务授权，编辑内容包括输入授权IP地址及刷新授权序列号；支持查看已授权列表并可对已授权服务进行删除和批量删除操作，支持查看未授权列表并可进行授权和批量授权的操作。1.3.2.4.3数据服务管理：管理全量数据中心上行、下行数据的服务，需提供服务新增

29、、编辑等基础功能；界面上同时支持统计服务的调用信息，包括服务的调用情况以及调用日志。新增数据服务，并对服务进行命名、设定调用频率并对其进行描述；支持对服务进行授权，经过授权的应用系统才有权限调用该服务；应提供对服务的停用、发布、删除、测试。1.4全量主数据管理系统：系统以主数据管理和共享为核心，提供全生命周期管控的主数据治理功能，协助我校实现主数据的标准化管理、统一数据表和全局共享，打通各信息系统之间的数据集成和业务协同，发挥主数据业务价值，促进学校降本增效。1.4.1技术性需求1.4.1.1要求采用B/S架构实现主数据可视化管理，并实现前台页面与服务器后台的实时通信，提高系统性能。1.4.1

30、.2系统整体框架需采用可扩展性框架进行搭建，便于后期扩展。1.4.1.3要求系统灵活性高、可扩展，能够适应不断发展的需求。1.4.1.4要求提供所投产品适配国产数据库、国产操作系统和国产服务器的国产化软硬件认证证书复印件。1.4.2功能性要求1.4.2.1机构分类管理：应支持机构的新增/编辑/删除功能。1.4.2.2组织机构管理：应支持组织机构的新增/编辑/删除/搜索功能，并支持组织机构的批量导入/导出。可新增机构号、机构名称、机构简称、机构简拼、所属校区码，选择机构分类，对组织机构进行描述。1.4.2.3专业信息管理：系统应提供对专业的新增/编辑/删除/搜索功能，并支持专业的批量导入/导出。

31、可新增专业号、专业名称、所属机构，并选择相应学制。1.4.2.4班级信息管理：应提供班级信息管理功能，支持班级信息的新增/编辑/删除/搜索功能，并支持班级信息的批量导入/导出。可新增班号、班级名称，并选择所属专业。1.4.2.5系统厂商管理：应提供厂商管理功能，支持系统厂商的新增/编辑/删除功能。可新增厂商名称，对系统厂商进行描述。1.4.2.6业务系统管理：应支持业务系统的新增/编辑/删除/搜索功能；应支持业务系统的批量导入/导出。可新增业务系统名称、系统简拼、访问地址，选择所属机构/厂商名称/系统类型,支持图形显示状态（显示或隐藏）以及参与全量数据中心角色的设定（包括数据使用者、数据提供者

32、和未参与）。1.4.2.7学生基本信息管理：应支持学生基本信息的新增/编辑/删除/搜索功能，并支持学生基本信息的批量导入/导出O可新增学号、姓名、联系电话、邮箱，选择性别、年级、所属班级和是否在校，并可上传头像。1.4.2.8教职工基本信息管理：应支持教职工基本信息管理功能，支持对教职工基本信息的新增/编辑/删除/搜索功能，并支持教职工基本信息的批量导入/导出。可新增教工号、姓名、联系电话、邮箱、职务，选择性别、学历、所属机构信息、政治面貌和是否在职，并可上传头像。1.4.2.9信息主题管理：应支持业务系统的新增/编辑/删除功能；应支持通过主体名称或简拼快速检索；应支持业务系统的批量导入/导出

33、。可新增主题名称、主题简拼，对主题进行描述。2全量数据质量管理平台：为实现学校数据质量提升，需建设数据质量管理平台来自动检测数据的质量。数据质量管理平台的目标是监控数据状态，并对数据在任何程度上满足期望提供一定程度上的保证，用来检测可能指出一个数据质量问题的数据变化或在数据生成中的其他变化。2.1技术性需求2.1.1基础性技术需求2.1.1.1要求登录时间最长不超过8秒，检索时间不超过10秒，页面跳转不超过8秒，并发数60以上。2.1.1.2要求平台可以全天候24*7天运行，不会因为程序错误导致影响失败或者系统崩溃。2.1.1.3需支持同时兼容符合HTML5标准的主流浏览器，例如IE9及以上，

34、ChrOme浏览器等。2.1.1.4需基于教育数据质量联机评估框架，数据质量检测元规则从五个方面，即完备性、及时性、有效性、一致性和完整性评价数据质量。2.1.1.5为支持在不同业务系统中重用规则，数据质量监控系统中每一个规则都需由规则描述语言RDL来表达。RDL由系统生产，并由规则执行引擎解析执行，不需要用户对其进行编辑。2.1.1.6数据质量监控系统，需提供在快速评估中进行列剖析，在数据质量监控模块中，通过创建相应的质量监控规则实现连接分析和键值分析。（需提供截图证明）2.1.1.7数据质量监控系统需利用相似重复数据检测算法，快速比对数据，自动发现相似重复数据。2.1,1.8数据质量监控系

35、统需要基于内存数据库操作，从而提升数据质量检测效率。2.1.1.9系统需具备灵活的业务检测规则的设计功能，无需使用SQL代码即可实现。2.1.1.10需提供“脏数据库”管理，为数据质量治理留下记录。并且对满足数据质量阈值的“脏数据”，根据报告形成周期，向数据质量负责人定期通报数据状况以及改进建议。2.1.1.11要求提供所投产品适配国产数据库、国产操作系统和国产服务器的国产化软硬件认证证书复印件。2.1.2其他需求2.1.2.1需要数据质量监控工作能够支持分布式多线程运算，提高运算能力。2.1.2.2需支持集群部署，保证系统高可用。2.1.2.3系统必须支持自动负载均衡，提高系统运行稳定性以及

36、方便灵活的任务调度管理功能。2.1.2.4系统需通过先进的技术解决方案，最大化利用现有硬件资源，以适应高校环境中大数据量的实际情况。2.2功能性需求：数据质量监控平台需包含：数据源管理、快速评估工具、数据质量监控、业务规则管理、数据质量报告、消息中心、正则表达式配置、引擎管理以及日志管理功能。2.2.1数据源管理2.2.1.1系统需具备数据源管理功能，主要用于管理数据库数据源连接信息以及监测数据源的可用性，为数据评估、数据质量检测提供基础。应支持各种国内外主流数据库等。2.2.1.2系统需具备设置元数据同步频率的功能，并支持对同步时间的设定，按照每天/每周/每月进行设定。2.2.1.3为适应高

37、校业务场景，系统需具备业务分类管理功能，业务分类是指按照一定主题聚集的数据表或者视图，比如教务业务系统为一种业务分类，由选课信息、成绩信息等数据表、视图构成，用于将数据源下的实体表进行分类管理。2.2.1.4业务分类功能需包含新增业务分类、修改业务分类、删除业务分类功能。并可设置业务分类的名称，从用户列表中选择数据负责人，可通过鼠标点击的方式选择业务分类中需要的数据表，支持待选数据表和己选数据表的查询功能。2.2.1.5系统需具备对数据源的定时检测功能，支持按照每天/每周/每月进行设置。2.2.1.6需支持配置数据质量大表&近十年数据分布功能，选择一个业务分类，需具备对表进行质量大表（是/否）

38、、近十年数据分布（是/否）的设置功能。配置成功的表需在数据质量报告中相应模块进行展示。2.2.2快速评估工具：为便于快速掌握数据质量概况，需具备快速评估功能，可对关键数据进行快速评估，得到评估结果，以图形化界面展示数据量，数据极值，数据分布，数据填充率等指标。2.2.2.1选择评估对象2.2.2.1.1需支持选择业务分类中一个表下的一个字段，并把该字段加入到评估队列里。因学校数据表及字段众多，需要支持按业务分类及数据表搜索功能。2.2.2.1.2为了能得到更有业务价值的快速评估结果，需要能够设置被检测数据字段类型转换的功能，可选择将文本型字段转换为数值型或日期型进行快速检测。2.2.2.2评估

39、进程管理：要求管理员可以查看队列中等待评估的字段列表，并可取消队列中的等待中的字段，便于管理员查看评估进度。2.2.2.3查看评估结果：要求管理员可以查看评估的结果（图表），便于管理员了解数据项的数据概况。评估结果内容需要包括数据源名称、业务分类名称、数据表名称、字段名称、字段类型、空数据占比图形、数据总数、空数据总数、对字符型字段需要显示字段最大长度和最小长度、对日期类型字段要显示按年度数据量分布，最早年度，最晚年度、对数值型字段需要显示最大值和最小值。2.2.3数据质量监控2.2.3.1应支持数据质量检测运行结果的大屏展不，展示运行的统计分析内容，包括监控表、监控字段、业务规则的总数等，还

40、应具有重复率、变化幅度、更新率、波动幅度、多列有效性等检测结果数据的占比展示。2.2.3.2需提供立即检测和检测回放功能。2.2.3.3需支持从该界面钻取到业务分类界面查看该业务的质量检测运行结果。2.2.4业务规则管理2.2.4.1数据质量监控规则设置2.2.4.1.1需要系统支持动态数据质量监控规则配置功能，采用图形化鼠标点击及参数设置等操作方式，让用户在无需编写SQL语句的前提下，方便快捷的根据业务需要，设置数据质量监控规则。2.2.4.1.2系统需支持数据质量规则的启停监测设置，便于管理数据质量监测状态。支持通过规则模板设置数据质量监控规则、禁用或启用数据质量监控规则，便于管理数据质量

41、的监测策略。2.2.4.1.3数据质量监控规则设置内容应包括规则名称、检测维度、被检测字段的逐级选择功能（通过数据源、业务分类、数据表、字段的逐级选择）、阈值、对评分影响的权重等。2.2.4.1.4为保证数据质量检测的全面性，数据质量检测应包含多种检测维度，至少应包含数据填充率、数据唯一性、跨表数据有父无子的父记录检测、跨表数据有子无父的子记录检查、数据表中信息在一段时间内变化及时性检查、数据表中字段值在一段时间内值范围变化幅度检查，以上检测内容在数据质量监控规则设置中必须做到仅通过鼠标点击即可完成，无需代码编写工作。2.2.4.1.5在数据治理过程中，存在缺失及遗漏、错误数据的情况，为避免此

42、类情况对数据质量的影响，要求提供通过关联关系在进行数据质量监测运算时对数据缺失自动补全的机制，以解决部分字段大面积数据遗漏错误的问题。2.2.4.1.6为保证项目中使用的任何技术、产品和服务（包括部分使用）时，不会产生因第三方提出侵犯其知识产权引起的法律和经济纠纷，需提供由国家政府部门颁布给投标产品原厂商的智能数据补全或基于数据间关联关系的遗漏数据填补方法相关的知识产权证书。2.2.4.2检测规则运行管理：需具备管理质量规则检测任务的功能。要求可以设置检测周期（每月/每周/每天/自定义时间间隔），具体检测的时间。2.2.4.3数据质量检测2.2.4.3.1根据已配置的数据质量监控规则对数据质量

43、进行检测，应支持数据质量评分功能，将数据质量结果进行量化，以分值的形式展示，便于管理人员理解，需要提供科学合理的评分计算规则。2.2.4.3.2在检测完成后应提供脏数据管理功能，需通过图形化的方式可视化的展示不同数据表以及字段的脏数据量的多少，可查看到具体脏数据记录内容，并应提供脏数据导出功能供数据治理工作人员进行数据问题的分析与处理。2.2.5数据质量报告2.2.5.1查看报告2.2.5.1.1为使数据质量工作得到校方非技术部门领导和工作人员的支持与理解，对数据质量检测的结果要形成数据质量报告，以更偏向业务化的语言来讲解数据质量分析的结果，需支持下载报告。2.2.5.1.2为提高工作效率与准

44、确性、规范性，需要提供数据质量报告自动生成功能，通过确定报告生成的内容与形式，以图形化结合文字描述的方式展示监控数据的状况，报告内容应包括对数据质量的总结，对通过测量发现的任何数据质量问题的回应，以及改进建议。2.2.5.1.3要求数据质量报告应分为全校整体报告和各部门主题独立报告两大部分。2.2.5.1.4全校整体报告汇总学校整体数据质量情况，需对全校数据质量进行评估，并形成量化分值以及各部门数据质量情况的概览。2.2.5.1.5各主题独立报告需要根据各个主题实际业务情况制定各主题专属的数据质量报告生成规则，包括评估情况、量化打分以及对特定测量类型指标检测出不满足数据质量阈值的“脏数据”，根

45、据报告形成周期向数据质量负责人定期通报数据状况以及改进建议。2.2.5.2检测记录2.2.5.2.1需支持对检测状态、业务分类的搜索查看，检测状态需支持检测中/已完成/异常三种状态。2.2.5.2.2需提供查看业务分类检测记录详情的功能以及规则结果的查看，支持规则结果导出，导出内容应包含业务分类，业务规则、得分、脏数据条数统计，同时能够直接定位脏数据，找到问题数据的出处。2.2.5.2.3需提供检测异常的业务规则列表，用于确定异常范围。2.2.5.3数据质量专题报告：系统除了提供常规质量报告以外，还需支持质量报告的深化补充，至少应包含模式聚类专题报告、分布波动专题报告、列关系专题报告。需提供质

46、量检测规则与生成数据质量专题报告之间的业务联动关系。2.2.6消息中心2.2.6.1消息中心应包括未读消息、己读消息、归档消息，并对消息的类型、内容、发送时间等进行查看，支持详情查看和定位到发生异常的记录。2.2.6.2消息主要来源应包括数据源连接失效、数据质量检测异常、数据评估异常等。2.2.6.3需支持消息订阅配置，根据个人喜好设置接收的消息内容和接收方式。2.2.7正则表达式配置：系统需支持配置相关有效性的正则表达式，在配置规则过程中使用，如对邮箱地址、身份证号等的校验，应内置部分正则表达式。2.2.8引擎管理：需支持引擎使用情况查看，包括CPU核数、物理内存、JVM内存、心跳等，可以对引擎进行启用/禁用。2.2.9日志管理：操作日志管理，要求可以实时展示账号、时间、IP、操作详情，以追踪用户情况方便查找异常情况。3全量数据开放平台：由业务系统分散带来的数据传播性和共享性受到很大限制，同时还存在数据不完整、数据不一致、数据不安全等问题