需求-[2019]1723黑龙江省应急管理厅_省应急管理综合应用平台（一期）数据治理系统采购项目

商品信息：
序号商品名称目录名称数量/单位单价(元))总价(元))
1省应急管理综合应用平台（一期）数据治理系统其他网络控制设备1/项--
资格要求：
序号状态评审内容投标要求
1新增资格评审1、符合《中华人民共和国政府采购法》第二十二条的规定。 2、经检察机关查询近三年内无行贿犯罪记录。 3、具有同类项目的经营资质和服务能力。 4、拟参加本项目投标的潜在投标人须在黑龙江省政府采购网上注册登记并备案。 5、在黑龙江省设有办事处或分支机构并提供办事处或分支机构的有效证明材料。 6、投标单位本次必须独立投标，不得联合投标。 7、中标单位不得转包给其他第三方。 8、必须是具有软件开发类（包括技术开发、基础软件服务、应用软件服务等）经营范围的企业法人。
商务要求：
序号状态分值招标文件商务要求评审标准评审选项
1新增30文件编制 开发团队 企业业绩 本地化服务 质保要求 驻场人员 通用管理能力文件编制 开发团队 企业业绩 本地化服务 质保要求 驻场人员投标文件编制质量3分，投标文件编制完整、有目录（目录对应页码）、总体编排有序，格式规范、装订整齐、页码连续清晰，得3分；每有一项不符合扣1分，最多扣3分；投标文件有关内容前后矛盾，与招标文件不一致，该项不得分。(3分)?
开发团队不少于4人具有高级职称（或同等级别），得5分，不少于4人具有中级职称（或同等级别），得2分，不满足得0分。提供团队人员社保缴纳证明。(5分)?
投标人最近三年内成功实施的同类项目的业绩：每提供一个同类项目单个合同金额不小于本项目金额的，得5分，满分10分；投标人提供的同类项目多个合同累计金额大于本项目金额的，得3分；投标人提供的同类项目累计合同金额未达到本项目金额的，得1分；没有项目业绩的不得分；(须提供合同复印件及相应的验收合格和资金结算证明,原件备查)(10分)?
（1）投标人提供“ISO 9001”质量管理体系认证证书的，得0.5分；(2分)?
投标人在黑龙江省内设有办事处或分支机构，且成立时间不晚于2019年1月1日的，机构人员规模不少于10人（含10人）得 4 分，少于10大于5人（含5人）人得2分，少于5人得0分。 （注：提供有效的营业执照复印件和不少于3个月的人员社保缴纳证明文件并加盖投标人公章）(5分)?
承诺质保期至少5年，并提供系统功能需求定制修改服务，额外增加1年得1分，最多得2分。未承诺或未满足要求不得分。(满分2分)；(2分)?
要求在应急管理厅有驻场工程师4名，需提供近六个月社保证明，证明函和社保证明均提供得3分，提供一份得1分。(3分)?
技术要求 ：
品目序号状态配置招标文件技术参数要求加减分标准评审选项
省应急管理综合应用平台（一期）数据治理系统1新增5.1 信息资源规划 地方应急管理部门应在应急管理部编制的信息资源目录的基础上，补充梳理本省应急管理信息资源，并按照相关规范要求进行编目，为应急管理业务系统和政务服务提供数据资源清单，并定期与部级数据治理系统的资源目录实现同步，为数据接入、数据汇聚、数据存储、、数据交换、数据应用提供技术约束，确保数据治理工作规范、统一、有据。 5.1.1 信息资源 应急管理数据治理系统建设是一项长期的工作，数据资源池中存储和接入的信息资源类型不断丰富、数据量不断增长数据来源单位范围逐步扩大。本期信息资源的采集范围主要包括以下单位：应急管理各转录部门以及林业、交通运输、国土资源、地震、城管、消防、民政、气象等单位。采集数据类型主要包括： 1、各单位应急相关基础数据，危险源、防护目标数据等，地理信息等。 2、各单位应急资源数据，包括救援队伍信息、应急专家、应急救援物资装备信息等。 3、各单位实时监测监控数据，如气象信息、舆情信息等。 4、各单位应急相关业务数据，包括预案、案例、法律法规信息、安全生产监管的相关信息等。 5、各单位专业预测信息，如气象预测信息、地震预测预警信息等。 5.1.2 信息要素规划 根据应急管理业务的数据特征，以相关要素为基础，将应急管理业务中可以进行信息化处理的数据进行分类。 5.1.3 信息资源目录编制 本项目将依照《政务信息资源目录编制指南（试行）》、GB/T21063.1-2007及GB/T21063.3-2007等相关指南和标准的要求，结合应急管理部的管理需要，梳理应急管理信息资源，规划应急管理元数据范围，编制完成标准《应急管理信息资源资源目录》。 基于应急管理信息要素，将应急管理信息资源进行汇总融合，可形成包括最小的一级分类。基于一级分类，将关联于同一信息要素的不同职能或不同对象进行子类划分，形成信息资源二级分类。对二级分类下的业务流程或业务处理对象进行信息资源再划分，形成信息资源三级分类。 5.1.4 分类管理 按类别管理。 5.1.5 综合查询 综合查询。 5.1.6 定期更新 形成完备的更新机制。 5.1.7 绩效考核 根据资源规划情况进行考核。 5.2 数据接入 数据接入主要提供统一的数据汇聚功能，将纷繁复杂、格式各样的外部关联部门业务系统、应急管理内部业务系统、互联网业务系统的数据接入到数据治理平台中，方便和外部系统进行数据交换，为上层大数据应用支撑平台的业务分析工作提供数据源。 5.2.1 数据接入方式 从数据来源分布来看，本次项目建设接入数据包括外部关联部门数据、应急管理厅内部业务部门数据、互联网公开数据、感知数据等。针对不同来源数据采用不同的数据接入方式。 5.2.1.1 外部关联部门数据接入方式 对于林业、交通运输、国土资源、地震、城管、消防、民政、气象等外部相关部门业务系统数据可通过数据交换平台获取，引接方式遵从平台规定方式进行，目前主要提供库表交换、服务接口调用、文件上传方式。 5.2.1.2 应急管理厅内部业务部门数据接入方式 对于黑龙江应急管理厅等应急管理厅内部业务部门的数据，可通过前置系统采用数据抽取、接口调用、消息服务的方式进行数据接入。 5.2.1.3 互联网公开数据接入方式 对于来自互联网以及社会企业的舆情数据可通过互联网单向传输设备接入到数据资源池。 5.2.1.4 感知数据接入方式 对于来源于GPS与北斗定位及速度、方向等实时定位设备、各单位实时监测监控数据，可通过接口实时接入或定点接收的方式实现数据接入。 5.2.1.5 其他数据 对于没有IT系统支撑的业务数据，还可采用人工填报，XLS表格导入的方式实现数据接入。 5.2.2 系统功能 数据接入子系统提供数据探查、数据读取、数据对账等功能模块。 5.2.2.1 数据探查 数据探查是指通过对来源数据存储位置、提供方式、总量和更新情况、业务含义、字段格式语义和取值分布、数据结构、数据质量等进行多维度探查，以达到认识数据的目的，为数据定义提供依据。 5.2.2.2 数据读取 数据读取是指从源系统抽取数据或从指定位置读取数据，检查数据是否与数据定义一致：不一致的停止接入，并重新进行数据的探查和定义；一致的执行进一步接入，对数据进行必要的解密、解压操作，生成作用于数据全生命周期的记录ID，并对数据进行字符集转换等，将其转成符合数据处理要求的格式。 5.2.2.3 数据对账 数据对账是针对数据接入环节，对数据提供方和数据接入方在某一对账节点的完整性、一致性、正确性进行核对和检验的过程。如果在某一对账时间点数据提供方和数据接入方分别对应的数据条数不一致，说明对账出现异常，记录异常，在必要时需告警。 5.2.2.4 断点续传 系统应该提供基于消息的数据传输服务，从一个应用系统传输数据实体和数据格式到另一个应用系统，每个传输服务可以运行多个传输实体。另外系统也提供断点处理功能，用户可以通过流程诊断工具查看流程发生错误的断点，用户可以只修改发生错误的断点处的消息，然后把该消息重新发送，而不是回退和重新发送整个流程。 5.2.2.5 任务管理 主要实现对数据接入任务的管理，支持数据接入任务的创建、查询、删除等功能，并可指定接入任务所使用的抽取方法、转换规则和加载方式，并根据指定类型进行任务的调度执行。 5.2.2.6 数据分发 将预处理后的数据按需分发到资源库、主题库、业务库，更新维护原始库，以及向请求方反馈数据。 5.3 数据处理 数据处理主要是针对数据接入系统汇聚的结构化数据记录、半结构化文本等具体数据内容建立标准化的数据处理模式，经过处理后的数据存储在应急管理数据资源池中。数据处理子系统提供数据探查、提取、清洗、转换、关联、比对、标识、融合等功能模块。 5.3.1 数据处理场景 5.3.1.1 从前置库到原始库 数据处理系统通过数据接入系统接入到前置库中的数据，这些数据包括各业务系统中的结构化数据和非结构化数据，通过数据探查和数据提取等手段，对前置库的数据进行探查分析，提取出数据源信息，并将非结构化数据的关键文字信息如森林草原林火视频监控数据中的时间等提取出来，整个数据处理过程处理后的数据会落入原始库中。 5.3.1.2 从原始库到资源库 原始库的数据经过数据比对、数据提取、数据关联、数据转换、数据清洗等处理过程，将数据加工成符合标准规范的数据。例如人员伤亡表的数据处理工作，经过比对人员伤亡表中的各个字段和标准数据元的差异，将标准数据元与原始表进行关联，如身份证号，然后进行转换和清洗。 5.3.1.3 从资源库到主题库 资源库的数据经过数据比对、数据关联、数据融合、数据标识的处理过程，将资源库的数据映射到灾害事故、管理对象、应急环境、救援资源、动态感知五大信息分类中，并详细对应到各信息分类中与森林防火相关的二级、三级主题库中。例如“地”主题中的关键基础设施主题，需要比对关键基础设施表与资源库中表的数据结构差异，选择有效的字段关联、融合数据到关键基础设施主题中。 5.3.1.4 从主题库到专题库 主题库的数据经过数据比对、数据关联、数据融合、数据表示的处理过程，将灾害事故、管理对象、应急环境、救援资源、动态感知五大信息分类中的数据提取出来，按照森林防火专题库所需要的方式进行组织。 5.3.2 系统功能 5.3.2.1 数据探查 数据探查功能组件主要对业务缓冲库和原始库中的数据进行探查分析，以便对待汇聚整合的数据有一个清晰的了解，进而提取出数据源头的元数据信息，为后续的数据处理过程提供管理、业务、技术等方面的支撑。 数据探查组件功能框图 业务探查：对来源表的业务含义进行探查，以便能准确地理解和描述数据。 接入方式探查：对来源表的存储位置、提供方式进行探查，为数据接入规则定义和数据处理、组织提供依据。 字段探查：对具体字段的数据内容进行探查，识别其代表的含义和统计分布情况。具体的功能主要包括： 空值率探查：统计字段空值占比情况，一方面可重点关注空值率高的重要字段，另一方面可通过与历史情况比较及时发现数据质量的动态变化。 值域及分布探查：对字段的值域范围以及分布情况进行探查。 命名实体探查：根据数据内容识别人名、地名、机构名、手机号等命名实体，帮助理解字段语义。 数据元探查：根据字段名字及内容，探查字段的确切语义，并与数据元标准进行映射。 类型及格式探查：探查字段的类型及格式是否符合规范。 数据集探查：对来源数据集表名、引用数据元等进行探查，确定数据集是否是标准数据集。探查数据总量、增量及更新情况，为数据接入、处理和组织提供依据。 问题数据探查：探查字段中不符合规范的数据，为后续数据清洗规则的制定提供依据。 数据推送：把数据探查的结果信息推送到数据清洗组件、数据转换组件以及元数据库中，为相关组件的规则制定，流程分发等提供必要的信息。 5.3.2.2 数据提取 数据提取是原始数据进行规范化处理的过程，主要针对半结构化数据，通过数据提取过程，从这些半结构化数据中提取出人员、机构、应急物资、事件等相关信息，并将提取的信息以结构化形式进行存储。 5.3.2.2.1 半结构化文件内容提取 主要针对存在于原始库中的半结构化数据，根据文件中的内容，提取出业务需要的数据内容。常见的半结构化数据类型包括：XML、CSV、TXT、Word、Excel等文件。 数据缓存：对XML、CSV、TXT、Word、Excel文件解析出来的结构化信息缓存的功能。 数据封装：对解析出来的数据进行数据封装，形成标准化的数据结构。 数据推送：推送封装好的结构化数据到资源库、主题库。 源数据索引：需实现对原始半结构化数据的索引能力，便于对提取后的结果进行溯源追踪。 5.3.2.2.2 非结构化文件内容提取 多媒体信息提取：从图片、语音、视频等多媒体数据中提取文字、图片等信息。如从相关图片中提取文本信息，从视频信息中提取关键帧信息，对图片中出现的二维码进行解析识别，提取包含的文字信息、链接信息等。 生物特征提取：从海量图像、视频、音频信息中提取人脸、人声等信息，为应急救援提供数据支撑。如从人事管理系统中的人员照片信息提取人脸特征信息、从各类视频信息中提取人脸信息，识别出涉及的领导人员信息等。 全文信息提取：主要是从海量文本数据中提取姓名、身份证号、电话号码、车牌号码、社会统一信用代码、企业名称、地址、时间等信息。如从安全生产诚信管理系统的黑白红名单中提取企业名称、社会统一信用代码等企业组织要素信息，从评估报告信息中提取灾害事故的发生时间、地点、伤亡情况等结构化要素信息。如从业务信息系统中对接的Word格式的文献文件内容中提取单位名称、姓名等要素信息。 5.3.2.3 数据清洗 数据清洗是对业务数据中不符合标准规范或者无效的数据进行相关操作。在进行数据整合之前先定义数据的清洗规则，并对符合清洗规则的数据设置数据的错误级别。当进行数据整合过程中遇到符合清洗规则的数据时，系统将把这些业务数据置为问题数据，并根据错误的严重程度进行归类。对出现的问题数据进行标记后存入问题数据库中，经确认后再决定是通过清洗转换后入库，还是直接放弃，抑或其他方式处理。对于清洗前后的数据还需进行一致性检查，以保证清洗结果集的质量。 数据清洗流程 5.3.2.4 数据转换 本次数据治理项目涉及多个部门、多个业务系统中的数据。不同系统有不同的数据结构定义，数据汇聚在一起后就会产生数据格式不规范统一、数据命名不规范统一、数据编码不规范统一、数据标识不规范统一。这样的数据是无法支撑业务应用需要的，因此需要对汇集的数据进行数据格式规范统一、数据命名规范统一、数据编码规范统一、数据标识不规范统一等数据转换处理。具体数据转换组件包括一下功能： 数据转换流程示意 数据命名转换：通过比对标准数据元和实际数据表中的数据项，如果比对结果一致，则不需要转换处理，如果比对结果不一致，要按照标准数据元中规定的命名进行转换。 数据类型转换：通过比对标准数据元和实际数据表中的数据项，如果比对结果一致，则不需要转换处理，如果比对结果不一致，要按照标准数据元中规定的数据类型进行转换。按照标准规范将不同来源、不同格式的数据转换成统一的标准化数据格式。平台将建立一系列的数据标准，进入平台的数据都必须遵循这些标准，只有这样才能保证平台上层应用的调用数据的通用性和应用之间充分的信息共享。需要做的格式统一有以下几种：全角转半角、电话号码转换、URL形式转换、身份证件号码转换、社会统一信用代码转换、时间格式转换、经纬度等数据标准化类型。身份证号码和社会统一信用代码标准化是将身份证位数统一为18位半角字符，字母字符转为大写字符，电话号码标准化主要是保留源数据的数字字符部分，去除加减号、空格等特殊字符，仅保留有效的数字字符内容。特定字段全角转半角（URL、账号等信息）。时间标准化即将“yyyy-MM-dd HH:mm:ss”、“yyyyMMddHHmmss”等各种时间格式值，这些格式也统一转成平台定义的标准时间格式。经纬度标准化主要将各种经纬度坐标系统一转换为2000国家大地坐标系，经纬度数值统一为十进制数值格式。所有数据格式标准化后的字段单独存储，原字段予以保留。 数据编码转换：比对标准数据元和实际数据表中的数据项，如果比对结果一致，则不需要转换处理，如果比对结果不一致，需要按照标准数据元中规定的标准编码进行转换。将来源于不同系统的不同数据字典转化为标准数据字典。 视频转码：由于应急管理数据治理工程中的视频信息来源于不同终端设备，且多经由异构通信网络进行传输，因此需要进行视频转码，将已经压缩编码的视频码流转换成另一个视频码流，以适应不同的网络带宽、不同的终端处理能力和不同的用户需求，并保证服务质量。 数据标识转换：通过数据元和数据表字段的关联，根据关联关系自动生成可执行的转换规则，进行数据标识的转换。 标准地址转换：对地址要素不完整、文字表达不一致的地址信息进行标准化处理。依托民政的标准化地址库及互联网公开的POI地址信息库，形成应急相关的地址标准基础库，对应急采集的地址信息进行标准化处理。 为保障数据转换处理过程不会造成数据丢失，数据转换模块需要支持断点功能。 5.3.2.5 数据关联 数据关联组件需要完成在不同数据集之间的关联，实现在不同数据集的联动，为数据治理、业务应用的需求提供支撑。根据数据处理流程设计的要求，数据关联组件的功能包括：标准关联、字典关联、半结构化关联、关联回填。 标准关联：在资源库中设计了标准的数据元体系，作为数据资源中心的数据规范基础。数据元是最小的数据单位。在数据关联系统中，需要通过手工或更智能的方式实现各种不同编码的原始数据和标准数据元的关联。 数据字典、属性及相关含义的关联：如灾害等级与灾害类别关联、自然灾害和灾害地点关联、单位代码和单位名称关联、救援物资与物资类别关联等。 半结构化与结构化的关联：对半结构化数据进行提取结构化信息后，按照关键字（如灾害地点相同、灾害时间相同、灾害诱因相同）等进行关联，构建数据关联关系。如从业务信息系统中对接的Word格式的文献文件，通过提取出的文献内容，通过事件的时间、地点查询相应火灾灾情库中的灾情信息进行关联。 关联回填：两个或两个以上数据集之间通过某种信息建立关联关系之后，根据实际业务的需要，可以对这两个数据集中的数据进行相互补充。 5.3.2.6 数据比对 通过数据比对功能实现对两个数据集中的数据内容、数据格式的比较核查，找出相同的数据或不同的数据。在业务应用场景上主要实现以下数据比对功能。 数据项与标准数据元比对：实现原始数据表中的数据与标准数据元数据的比对，比对的内容包括数据命名、数据标识、数据格式、数据值域、数据编码、数据类型等数据的比对，数据比对的结果为一致或不一致。 不同数据项集比对：实现两个数据项集的交集、补集，以满足数据检索的需求。 5.3.2.7 数据标识 数据标识模块依托标签引擎结合应急业务知识库、标签规则库对数据进行标识。标签规则库提供标签的定义、内容、版本、关联等，通过读取标签规则库的内容，对数据进行映射，通过人工或智能的方式实现对数据打标，以便提升数据的价值密度，并为上层应用提供支撑。 根据标签规则库提供的规则接口，数据标识过程分为以下三类： 基础标签标识：根据基础标签定义的规则，对数据进行规则筛选，符合规则的数据增添一列基础标签。 业务标签标识：按照业务数据模型管理数据，根据标签规则库提供的标签元数据信息，在资源库中找到标签所需的相关联的数据，根据规则进行合并、汇总等工作，得到的数据按照标签定义增加一列内容到目标数据中。 智能标签标识：据标签规则库提供的模型接口，将相应的数据输入模型进行计算，将计算后的结果按照标签规则库定义的标签内容增加一列业务标签到目标数据中。 5.3.2.8 数据融合 标准化去噪后的数据需要采取必要的数据融合手段，按照应急管理的主题库、专题库以及数据应用需要的方式组织，以支撑应急管理单位的数据需求。在数据融合的过程中，应该以合理的方式设计数据结构，保障数据应用对数据高效分析查询的同时，尽可能的减少冗余。数据融合处理过程贯穿主题库、专题库和数据应用的建设过程，详细如下： 数据融合的关键功能模块包括模型加工和汇总加工。各功能模块的详细描述如下： 数据融合功能模块示意 模型加工：主要包含数据合并、数据覆盖、数据切分功能，其中数据合并需要通过函数、分组或转列的方式完成数据的表合并和列合并。数据覆盖功能需要依赖数据比对的结果，将新增和修改的记录覆盖到目标表中。数据切分需要通过行筛选、列提取或表提取等方式将相同数据对象的结果表进行切分合并。 汇总加工：按照公共汇总的原则，明确哪些数据需要汇总合后，采用聚合函数或窗口函数等方式，完成对跨数据域且需要被频繁公用的数据的汇总。 5.3.2.9 数据去重 对重复数据合并处理。 5.3.2.10 数据补全 对一条数据各个字段的缺失，通过技术手段进行补全，例如：黑龙江省，需要补充机构代码23。 5.4 数据资源池 按照数据使用目的分级分类建库的要求，统一规划资源，通过对数据资源进行标准统一、流程规范的组织与挖掘，形成包含原始库、资源库、主题库、专题库等的应急管理数据资源池，以满足应急管理内部各单位业务专题数据落地建库需求，为综合展示、数据服务、领导决策提供数据支持。 5.4.1 应急管理数据库 5.4.1.1 原始库 大数据资源中心的原始库应该包含应急管理单位内部、外部所有需要组织的数据。在数据来源上，包括外部委数据（如公共安全数据、交通运输数据等），应急管理单位内部数据（如省市重大安全风险监测预警数据、部级安全生产行政执法数据等），社会及互联网数据（如微信、微博及其他舆情数据等）。在数据类型上，包括结构化数据、半结构化数据和非结构化数据。 原始库的合理设计可以在业务系统和数据资源中心之间形成一个良好的过渡，既保障了数据资源中心数据的稳定性，不会受源业务系统数据频繁变化的影响，又可减轻前置系统被反复抽取的压力，数据资源中心的数据需求统一由原始库为基础来抽取和分发。 由于数据来源多、种类丰富，原始库的数据应该采取清晰、合理的方式去组织。对于不同来源的数据，应该按照其数据来源进行清晰的标识，包括表名标识、表元数据标识等。对于不同种类的数据，应该采取不同的存储机制进行存取。存储域分为结构化域、半结构化域和非结构化域，其中半结构化域和非结构化域的数据应该采用相应的数据提取手段提取关键信息保存至结构化域，便于数据的溯源和使用。 原始库的数据结构设计原则上和业务生产库的表结构一致，并在业务生产库基础上增添数据接入过程中的操作字段，表示数据的更新和删除等状态。以此向大数据资源中心提供原始、准确的数据，便于后续的分析和使用。 原始库中的数据是大数据资源中心最基础的数据，需要对数据设置不同的生命周期和质量监控标准，从而保障数据的鲜活性和准确性。 原始库的结构按数据的类别分为结构化数据域、半结构化数据域和非结构化数据域三个逻辑的数据域。 （1）结构化数据域用于保存由各业务系统抽取的关系型数据，如火灾档案表等，这部分数据需基于云计算平台所提供的关系型数据库组件来组织。 （2）半结构化数据域用于保存从各业务系统或各部门抽取的半结构化数据，如互联网舆情数据等XML格式、XLS格式数据或文件，该类型数据需基于云计算平台所提供的NoSQL数据库组件来组织。 （3）非结构化数据域用于保存从各业务系统或各部门抽取的非结构化数据，包括图片、音视频、文本等类型数据，如卫星遥感数据、火灾图传录像、救援总结报告等，该类型数据需基于云计算平台所提供的分布式文件系统进行存储。 非结构化数据和半结构化数据需在原始库中建立索引表来记录该数据的来源和存储路径等。索引表主要以关系型数据形式存储在结构化数据域中。 5.4.1.2 资源库 资源库的数据是由原始库的数据经过清洗、转换、关联、比对等数据处理过程后形成的标准数据。 资源库的设计包括数据结构设计、数据表结构设计和加工过程设计。在资源库的数据结构设计上，以原始库数据结构为基础，补充必要的数据字段。在数据表设计上，将相同表结构的数据表进行适当的合并，并保留原始库的表名以方便进行溯源。数据加工过程设计是资源库设计中最核心的部分，这部分要进行数据标准、数据元的设计，以及原始数据和标准数据元的关联设计，从而将资源库的数据处理成符合标准的数据。 5.4.1.3 主题库 主题库是按照应急管理信息要素将应急数据按灾害事故、救援物资与装备、组织机构、危险源等进行分类，为数据应用和产品提供公共数据服务，降低用户理解和获取数据的难度，降低数据加工的深度和复杂度，提升数据应用和产品获取数据的效率，保持系统内各个软件模块和应用服务间数据的一致性。 主题库的设计需遵循下述规则： 1、提供统一的数据出口 主题库中包含了主题相关的实体表和实体间的关联表，以及实体表的来源表信息。通过关联表以及来源表信息，用户能快速清晰地了解实体的数据来源，减少了去数据库中寻找实体相关表的时间，并且由于各个用户统一从主题库获取数据，数据口径的一致性得到了有效保障。 2、保证实体的一致性 主题库包含主题库是按照应急管理单位信息要素将应急数据按灾害事故、救援物资与装备、组织机构、危险源等进行分类，为数据应用和产品提供公共数据服务，降低用户理解和获取数据的难度，降低数据加工的深度和复杂度，提升数据应用和产品获取数据的效率，保持系统内各个软件模块和应用服务间数据的一致性。 主题库的设计需遵循下述规则： 1、提供统一的数据出口 主题库中包含了主题相关的实体表和实体间的关联表，以及实体表的来源表信息。通过关联表以及来源表信息，用户能快速清晰地了解实体的数据来源，减少了去数据库中寻找实体相关表的时间，并且由于各个用户统一从主题库获取数据，数据口径的一致性得到了有效保障。 2、保证实体的一致性 主题库包含灾害事故、救援物资与装备、组织机构、危险源等实体，每个实体都会在主题库中有唯一的ID，通过这个唯一的ID，可以获取实体在主题库中的所有信息，从而保证了实体的一致性。 3、提供汇总的业务数据，满足查询、统计、分析等多类应用产品的数据需求 主题库会根据业务类别，将数据从各个业务表中汇聚起来变成汇总后的实体表和关联表，并且在实体表和关联表中还会包含常用的业务字段，使得用户可以方便得从较少的表中获取所需数据，降低了数据获取成本。 主题库在数据治理体系中位于DWD明细数据层（资源库）和DM专题层（专题库）中间，对上游的明细数据打散重构形成主题表，对下游的专题层提供了标准化、一致性的数据。上游的明细数据里面包含了不同系统、不同部门的数据，数据之间存在关联，但是由于没有进行一致性处理，无法达到数据准确的互通，因此主题库将不同系统间的数据通过信息要素等实体进行有效的关联，打通了不同系统间的数据。主题层完成后，专题层就能根据特定应用需求，快速选取有效数据形成专题数据。 主题库逻辑模型的设计应采用自顶而下的方法，首先将需求涉及范围内的业务对象从高度概括的信息要素概念层次归类，即划分主题域，再针对各个主题设计实体关系图。 5.4.1.4 专题库 专题库是主题库的数据按照专题应用的需要重新整合形成的数据库。专题库的建库按照专题应用业务模型，通过二次抽取装载的方法重新组织数据，建立形成满足应急管理专题业务应用需要的数据库。 根据应急管理业务需求，专题库包括包括预案、案例、应急资源、专家等数据的收集、整理、清洗、入库。 预案主要包括突发事件总体应急预案、专项预案、部门预案、下级政府应急预案、大型活动应急预案和企事业单位应急预案等。应急预案按内容和形式分为两种：文本预案和数字预案。文本预案主要以文本方式组织存储各级政府或机构编制好的应急预案。数字预案是对文本预案中的救援组织、救援队伍、程序步骤、措施、职责、协调等内容进行结构化处理后形成的可程序化执行的预案，包括预案手册中所记录的所有信息。 案例库主要存储处置突发事件的历史案例数据、各部门收集的与其专业领域相关的专业案例数据及国内外突发事件典型案例等相关信息。包括案例基本信息和案例要素。案例包括自然灾害、事故灾难、公共卫生、社会安全四大类。 应急资源库主要存储应急救援物资储备场所、数量、内容及应急救援物资生产企业，以及救援队伍数据等数据。应急资源数据实体包括应急物资储备库、应急物资、应急装备、应急物资生产企业、救援队伍等。应急物资储备库数据描述应急物资储备库的基本情况，包括名称、类型、级别、地址、负责人、联系人、周边交通状况、储备物资等信息。应急物资数据描述应急物资的基本情况，包括名称、类型、级别、存放地点、数量、保质期等信息。应急装备包括个人防护装备、通信设备、探测设备、洗消设备、医疗设备、能源设备、应急运输工具等。应急装备数据描述各类应急装备的基本情况，包括名称、类型、级别、负责人、联系人、装备数量、运输方式等。应急物资生产企业数据描述应急物资生产企业的基本情况，包括名称、类型、级别、地址、负责人、联系人、生产物资、生产能力等信息。救援队伍数据库存储全市综合性、专业性应急救援机构、队伍信息，主要包括：本市区县级以上人民政府建立或确定的综合性应急救援队伍信息。各市级部门、各专业领域建立的专业应急救援队伍信息。应急志愿者队伍信息。。 专家库存储市政府和市有关单位、区县、企业的各类应急管理专家信息。包括自然灾害专家、公共卫生专家、事故灾难专家、社会安全专家、综合类专家。专家组数据描述专家组（库）的基本情况，包括专家组名称、类型、负责人、联系人、组建单位、人数、专家组介绍等。专家数据描述专家的基本情况，包括姓名、专家类型、性别、出生日期、工作单位、专业特长、应急工作经历等信息。 5.4.2 应急管理配置库 5.4.2.1 标签规则库 标签规则库是按照标签目录进行组织的标签规则集合，每一个标签规则由标签名称、标签加工源数据信息、转换规则信息、统计周期等信息组成。根据规则的定义方式，标签规则库可分为基础规则库、业务规则库、智能标签规则库。 5.4.2.1.1 基础标签规则库 基础标签规则是对数据的某一属性字段信息进行计算的处理规则，主要用于生成刻画灾害事故、管理对象、应急环境、救援资源等应急管理要素的基础特征的标签。 5.4.2.1.2 业务标签规则库 业务标签规则是基于应急管理人员的业务经验，对基础标签规则进行模型关联和逻辑计算，形成的固化知识标签生成规则。 5.4.2.1.3 智能标签库 智能标签规则库是基于特征工程、机器学习算法，建立的智能标签模型集合。智能标签模型可用于从互联网信息、文档等大量信息中提取可直观展现对业务主观认识的标签。 5.4.2.2 知识库 知识库是结构化、易操作、易利用、全面的、有组织的、互相联系的知识集合，是相关部门在应急管理过程中与该领域相关的基本概念、理论知识、事实数据，以及所获得的规律、常识性认识、启发式规则和经验教训的集合。 本项目针对常用森林火灾、地震、危险化学品泄漏、台风暴雨等事故灾害现场救援必须掌握的知识，整合森林消防、减灾中心等部门的应急管理知识，构建应急管理知识库，为应急指挥中的前期处置、物资调用提供支撑。知识库建设内容包括应急基本信息、应急速查手册、应急处置流程、应急案例信息、应急专家信息与应急法规政策信息。 5.4.2.2.1 应急基本信息 应急基本信息包括应急资源、场景、情况定义和详细描述，不同要素的分类，等级和标准。 5.4.2.2.2 应急速查手册 应急速查手册包括灾害事故的名称及详细描述、应急救援过程中应急指挥和处置人员应特别注意的问题、危险性类别、作业人应采取的防护措施以及应采取的紧急措施等。 5.4.2.2.3 应急处置流程 应急处置流程信息包括处置的基本原则、应急处置流程图、处置的基本流程及详细描述和各类事故处置的详细流程。 5.4.2.2.4 应急案例信息 应急案例信息主要包括处置突发事件的历史案例数据、各部门收集的与应急专业领域相关的专业案例数据及国内外突发事件典型案例等相关信息。包括案例基本信息和案例要素。 5.4.2.2.5 应急专家信息 应急专家信息应急管理单位以及有关单位、区县、企业的各类事件响应处置专家信息，包括自然灾害专家、事故灾难专家、综合类专家。专家信息又分为专家组与专家个人数据。其中，专家组数据描述专家组（库）的基本情况，包括专家组名称、类型、负责人、联系人、组建单位、人数、专家组介绍等。专家数据描述专家的基本情况，包括姓名、专家类型、性别、出生日期、工作单位、专业特长、城市联动指挥工作经历等信息。 5.4.2.2.6 应急法规政策 汇集国内外应对突发事件制定的法规、政策、应对措施等规范性文件。可以全方位的了解世界上各个国家、地区，国内各级政府为应对突发事件所采取的措施。 5.4.2.3 索引库 为应用查询、业务搭建提供数据索引。 5.4.2.4 日志库 软件全流程、全方位日志记录。 5.5 数据支撑 基于Hadoop架构采用分布式数据处理技术，对外提供海量数据的存储、分析查询和实时流式数据处理分析能力。提供数据集成、数据存储、数据计算、数据安全管理以及统一资源调度能力，用于承载数据资源池建设，包括原始库、资源库、主题库、专题库、配置库、共享库等。 安全 架构安全：大数据支撑平台基于开源组件实现功能增强，保持100%的开放性，不使用私有架构和组件。 认证安全：基于用户和角色的认证统一体系，遵从帐户/角色RBAC（Role-Based Access Control）模型，实现通过角色进行权限管理，对用户进行批量授权管理。提供单点登录，统一了Manager系统用户和组件用户的管理及认证。对登录管理平台的用户进行审计。 文件系统层加密：Hive、HBase可以对表、字段加密，集群内部用户信息禁止明文存储。加密灵活：加密算法插件化，可进行扩充，亦可自行开发。非敏感数据可不加密，不影响性能（加密约有5%性能开销）。业务透明：上层业务只需指定敏感数据（Hive表级、HBase列族级加密），加解密过程业务完全不感知。 可靠 NameNode、Hive Server、HMaster、Resources Manager等所有管理节点组件均实现HA（High Availability）部署，确保数据的可靠性、一致性。 数据备份恢复，支持表级别全量备份、增量备份，数据恢复（对本地存储的业务数据进行完整性校验，在发现数据遭破坏或丢失时进行自恢复）。 易用 统一运维管理，提供界面化的统一安装、告警、监控和集群管理。 易集成，提供北向接口，实现与企业现有网管系统集成；当前支持Syslog接口，接口消息可通过配置适配现有系统；整个集群采用统一的集中管理，未来北向接口可根据需求灵活扩展。 易开发，提供自动化的二次开发助手和开发样例，帮助软件开发人员快速上手。 5.5.1 数据集成 数据集成服务是一个以设计、调度、监控和管理ETL过程为核心功能的服务。提供同构/异构数据源之间批量数据迁移服务，帮助客户实现数据自由流动。支持客户各种类型数据源之间的数据迁移，支持的类型包括：文件系统，关系数据库，数据仓库，NoSQL，大数据服务等数据源。 平台提供批量的结构化和非结构化数据、流式数据的集成能力，具备接入和迁移各种类型海量数据的能力。数据接入来源多样，既有内部数据也有其他部门数据，还有互联网数据，各数据来源的数据格式也不一致，在收集的过程中需对数据进行规范化处理，以便于管理使用。 大数据基础平台软件要完成从传统数据库到大数据平台的数据采集，包含批量采集和基于流处理的实时采集，主要提供如下组件能力： 支持从传统数据库到大数据平台的双向数据传输，可以将一个关系型数据库（例如：MySQL ,Oracle ,SQLServer等）中的数据导入到大数据分布式文件系统中，也可以将分布式文件系统的数据导进到关系型数据库中。 提供高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。 提供实时的、分布式以及具备高容错的流处理系统，能够与实时消息系统交互，完成实时数据的采集。 提供高吞吐量的分布式发布订阅消息系统，通过消息的封装完成实时数据的传递。 5.5.1.1 批量数据集成 实现大数据平台与关系型数据库、文件系统之间交换“数据”、“文件”，既可以将数据从关系型数据库或者文件服务器导入到HDFS/HBase中，同时也支持反过来从HDFS/HBase导出到关系型数据库或者文件服务器中。Loader是在开源Sqoop组件的基础上进行了一些扩展，实现大数据平台与关系型数据库、文件系统之间交换“数据”、“文件”，既可以将数据从关系型数据库或者文件服务器导入到HDFS/HBase中，同时也支持反过来从HDFS/HBase导出到关系型数据库或者文件服务器中。 Loader功能包括： 1.通过MapReduce实现并行执行和容错 Loader通过MapReduce作业实现并行的导入或者导出作业任务，不同类型的导入导出作业可能只包含Map阶段或者同时Map和Reduce阶段。 Loader同时利用MapReduce实现容错，在作业任务执行失败时，可以重新调度。 2.数据导入到HBase 在MapReduce作业的Map阶段中从外部数据源抽取数据。在Reduce阶段中，按Region的个数启动同样个数的Reduce Task，Reduce Task从Map接收数据，然后按Region生成HFile，存放在HDFS临时目录中。在MapReduce作业的提交阶段，将HFile从临时目录迁移到HBase目录中。 3.数据导入HDFS 在MapReduce作业的Map阶段中从外部数据源抽取数据，并将数据输出到HDFS临时目录下。在MapReduce作业的提交阶段，将文件从临时目录迁移到输出目录中。 4.数据导出到关系型数据库 在MapReduce作业的Map阶段，从HDFS或者HBase中抽取数据，然后将数据通过JDBC接口插入到临时表（Staging Table）中。在MapReduce作业的提交阶段，将数据从临时表迁移到正式表中。 5.数据导出到文件系统 在MapReduce作业的Map阶段，从HDFS或者HBase中抽取数据，然后将数据写入到文件服务器临时目录中。在MapReduce作业的提交阶段，将文件从临时目录迁移到正式目录中。 5.5.1.2 实时数据集成 Apache Flume是一个广泛使用的大规模分布式数据收集工具，它可以监听特定的端口（UDP、RPC端口），从而获得流过端口的数据，并且支持多样化的插件体系，在收集端对数据进行过滤等处理，在汇聚端则允许将数据直接输入到大数据分布式存储HDFS。 Flume作为一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。其中Flume-NG是Flume 的一个分支，其目的是要明显简单，体积更小，更容易部署。 5.5.1.3 分布式消息队列 Kafka是一个分布式的、分区的、多副本的消息发布-订阅系统，它提供了类似于JMS的特性，但在设计上完全不同，它具有消息持久化、高吞吐、分布式、多客户端支持、实时等特性，适用于离线和在线的消息消费，如常规的消息收集、网站活性跟踪、聚合统计系统运营数据（监控数据）、日志收集等大量数据的互联网服务的数据收集场景。 5.5.2 数据存储 应急管理接入的数据类型包含数据库表等结构化数据、视频图片等非结构化数据，要求大数据基础平台采用分布式文件系统实现对汇聚的多类型海量数据的存储，要求提供如下组件及能力： 提供高度容错性的分布式文件系统，适合部署在廉价的机器上。它能提供高吞吐量的数据访问，适合大规模数据集上的应用。 提供高可靠性、高性能、面向列、可伸缩的分布式存储系统，以键值对的形式承载海量结构化、半结构化以及非结构化数据。 支持大数据计算与存储分离技术，解决应急数据治理系统中存储架构适配性，提供大数据多集群的统一数据存储底座，解决计算、存储非等比扩容需求，提高大数据存储资源利用率。CPU资源不足时，扩容计算型服务节点，存储资源不足时，扩容存储型服务节点。 5.5.2.1 分布式文件存储 HDFS是Hadoop的分布式文件系统，实现大规模数据可靠的分布式读写。HDFS针对的使用场景是数据读写具有“一次写，多次读”的特征，而数据“写”操作是顺序写，也就是在文件创建时的写入或者在现有文件之后的添加操作。HDFS保证一个文件在一个时刻只被一个调用者执行写操作，而可以被多个调用者执行读操作。 HDFS分布式文件存储采用可扩展的系统结构，提供了海量数据的分布式存储。对于以文件方式存储的数据，比较适合该类存储方式。但采集的数据存在着不同大小文件并存的情况，按大小可大致划分为小文件（1MB以下）、中文件（1MB到500MB）、大文件（500MB以上），且文件数量非常多，为保证存储这些文件的同时能够提供快速读取的能力，分布式存储要能够满足该目标而提供相应小文件、中文件和大文件的存储检索方案，对外能提供统一接口进行访问，客户端在访问分布式存储时不需了解底层存储方式，由分布式存储统一调配相应优化方式实现文件快速存储和检索。分布式文件系统要支持6亿以上文件存储能力。 HDFS支持数据分级存储，把不同热度的数据存储于不同的介质（SSD/SAS/SATA）。同时针对冷数据，可采用HDFS-EC通过Erasured Code机制来降低副本数量的同时确保HDFS数据的可用性没有下降。 分布式文件存储能够提供FTP/SFTP接口，以便传统应用可以不修改代码访问HDFS。 5.5.2.2 分布式列数据库 HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。 HBase适合于存储大表数据（表的规模可以达到数十亿行以及数百万列），并且对大表数据的读、写访问可以达到实时级别。利用Hadoop HDFS作为其文件存储系统，提供高可靠性、高性能、列存储、可伸缩、实时读写的数据库系统。 为Spark和Hadoop MapReduce提供海量数据实时处理能力。 以HBase为代表的NoSQL数据库适合于存储较简单的数据模型，并且可以不受模式的约束。因而其可存储管理的数据类型更丰富；大数据技术同时适合进行一致性与事务性要求不高的计算（主要是指NoSQL的查询操作），以及对超大规模海量数据的、批量的分布式并行计算。需要注意的是，NoSQL数据库由于摆脱了繁琐的SQL体系约束，其查询与插入的效率比传统关系型数据库要更高。 NoSQL数据存储一般采用面向列的存储方式，其存储结构保证了数据表的列可扩展性和读写I/O的高吞吐性。Key-Value方式存储，Rowkey用户自由定制，用户可根据应用的具体需要将相关的一些查询逻辑封装在Rowkey生成规则中，从而提高系统查询效率。 在大数据应用中，经常遇到结构化数据和非结构化数据共同组成一个完整的数据，并且两个数据加起来都不大的情况。比如银行办理业务时产生的交易数据和高拍仪拍摄的图像数据，交警卡口产生的过车识别结构化数据和车相关的视频关键帧数据等。伴随结构化数据的是一些大小为几百K字节、几兆字节大小的非结构化文件，也有少部分几十兆或者更大的文件。 HBase具有能够存储海量结构化数据的优势，HDFS具有存储海量大小的超大文件的优势，本次大数据中心建设将结合二者合，基于两个部件的接口封装，提供超混合存储HFS（HBase File Stream），封装后的接口允许应用能够自由的进行大小文件的读写，HFS将会自动的把结构化数据信息存储到HBase，将与之对应的非结构化文件进行打包，确保HDFS文件系统看到的是远大于单个块（Block）大小的大文件，降低对Name Nodede元数据容量冲击。 5.5.2.3 数据仓库 Hive是建立在Hadoop上的数据仓库框架，提供大数据平台批处理计算能力，能够对结构化/半结构化数据进行批量分析汇总完成数据计算。提供类似SQL的Hive Query Language语言操作结构化数据，其基本原理是将HQL语言自动转换成MapReduce任务，从而完成对Hadoop集群中存储的海量数据进行查询和分析。 Hive支持对表的某一列或者多列进行加密。在创建Hive表时，可以指定要加密的列和加密算法。当使用insert语句向表中插入数据时，即可将对应的列进行加密。 由于底层存储系统的原因， Hive并不能支持对单条表数据进行删除操作，但在Hive on HBase功能中，提供了对HBase表的单条数据的删除功能，通过特定的语法， Hive可以将自己的HBase表中符合条件的一条或者多条数据清除。 5.5.2.4 分布式关系型数据仓库 适合于存储关系复杂的数据模型，并且需要限制为基于二维表的关系模型；同时适合进行一致性与事务性要求高的计算，因此元数据、统计值等结构化数据存储在分布式关系数据库中。在查询时调度多节点并发执行提升响应性能，采用基于代价模型的查询优化能力，结合数据分布情况选择最优的查询和处理方案，支持复杂多维分析查询。同时，在数据库组织结构、访问接口（JDBC等）、SQL语法、存储过程、权限管理等多方面高度兼容关系型数据库。 支持通过开放标准SQL接口实现复杂查询。通过分布列散列算法和分区路由算法避免数据偏斜导致单节点计算或存储性能瓶颈，提供整集群近似线性扩展能力。 支持标准的SQL92/SQL2003规范，支持GBK和UTF-8字符集，支持SQL标准函数与分析函数，支持存储过程。支持表空间，支持在线扩容功能。提供组件管理和数据节点HA。支持数据库事务ACID特性（即原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durability），支持单节点故障恢复，支持负载均衡等。支持标准JDBC 4.0的特性和ODBC 3.5特性。 支持SSL安全网络连接、用户权限管理、密码管理、安全审计等功能，保证数据库在管理层、应用层、系统层和网络层的安全性。 基于海量数据查询统计分析能力与事务处理能力，行列混存技术同时满足联机事务处理OLTP（On-Line Transaction Processing）与联机分析处理OLAP（Online Analytical Processing）混合负载场景。 支持分布式x86架构、与ARM架构，客户硬件投资成本低。 支持标准的SQL92/SQL2003规范，支持客户应用系统平滑迁移。 支持集群最大可扩展至1000个节点，满足PB级大数据分析能力。 5.5.2.5 内存数据库 Redis是一个开源的，基于网络的，高性能的key-value数据库，弥补了memcached这类key-value存储的不足，在部分场合可以对关系数据库起到很好的补充作用，满足实时的高并发需求。 Redis跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。支持在服务器端计算集合的并、交和补集(difference)等，还支持多种排序功能。 支持一主一从模式的Redis集群，系统自动计算节点上可安装的Redis实例个数并分配主从关系。 当集群需要提供大规模的处理能力时，可以一键式扩容一对或多对主从实例。在此过程中，系统会自动完成数据迁移和数据平衡，用户无需关注。 出现扩容异常、部分实例掉线等异常场景时， Redis集群中的数据可能会分布不均匀，此时可以通过管理界面上提供的Balance功能，让系统自动对集群数据进行平衡，保证集群的健康运行。 系统提供Redis集群的性能监控功能，可以通过直观的曲线图方式，了解当前Redis集群、实例的TPS吞吐量情况。 系统为Redis集群提供了多种告警，例如集群下线告警、持久化失败告警、槽位分布不均告警、主备倒换事件、集群高可靠性受损告警等，甚至主从实例内存大小不一致都可以自动上报告警。丰富的告警帮助用户更加轻松的进行Redis集群的监控和管理。 5.5.2.6 全文检索库 ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。Elasticsearch通过API提供丰富访问接口，使用集群发现机制，支持脚本语言，支持丰富的插件。底层基于Lucene，保持Lucene绝对的独立性，通过本地文件、共享文件、 HDFS完成索引存储。 实现Elasticsearch实例的内存、 CPU和磁盘IO的监控，以及index、 shard状态监控和告警。 提供基于用户/角色划分的index权限控制功能。提供Kerberos认证，保障了索引数据的安全性。 Solr是一个高性能，基于Lucene的全文检索服务器。Solr对Lucene进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展，并对查询性能进行了优化，并且提供了一个完善的功能管理界面，是一款非常优秀的全文检索引擎。SolrCloud是从Solr 4.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可以多实例部署，可以实现并发写与读，提高索引与查询性能。 5.5.3 数据计算 大数据基础平台软件提供对海量数据汇总后的多种数据并行处理框架，大数据分析的处理速度、准确度对实战的及时性、高效性都有至关重要的影响。大数据资源池提供分布式计算、流式计算、内存计算多种数据计算引擎，能够针对不同的场景采用不同的计算模型，对数据进行大规模批量处理或者实时处理，大大提升大数据管理中心的实战能力。同时面向领域的分析语言（DSL），包括面向数仓的Hive，面向数据挖掘的SpakrSQL 和面向流处理的CQL（Continuous Query Language），具备对结构化、半结构化和非结构化数据的进行多层次处理的能力，具备离线计算、流式计算、实时分析、机器学习等能力。 计算框架本身，也是在快速的发展中，几年前MarpReduce是唯一，目前已经快速出现并开始广泛流行的是Spark/Storm，同时包括Tez、Flink等计算框架也在借助自己的优势在推动中。 不同计算框架具有各自独特的优势，选择时的考虑点如下： MapReduce具有超大数据量处理非常稳定的优势，其追求在稳定，Tez在性能方面有很大提升，同时借助支持Hive，构成了基于Hive运算的铁三角，对于大容量表的碰撞，可以考虑使用Hive（基于MapReduce或者Tez）的技术。 Spark由于专门针对大内容和迭代计算进行了优化，在进行机器学习等算法运行的时候具有优势，一些最新的机器学习库（Spark MLlib等）也构筑在Spark之上，所以进行机器学习时Spark是首选。同时目前行业中也在进行将Hive迁移到Spark的实践，希望在具有对应用接口不变（为Hive）的同时，获取到Spark的高性能优势，目前这块还在发展中，对于大容量数据集的计算（比如多个超大表的碰撞）有时还不够稳定。 Flink是一个批处理和流处理结合的统一计算框架，其核心是一个提供了数据分发以及并行化计算的流数据处理引擎。它的最大亮点是流处理，是业界最顶级的开源流处理引擎。Flink最适合的应用场景是低时延的数据处理（Data Processing）场景：高并发pipeline处理数据，时延毫秒级，且兼具可靠性。 综合以上讨论，建议计算引擎的选择考虑以下几个基本准则： 1.需要进行超大容量的多表碰撞的，选择Hive 2.需要进行机器学习等迭代计算为主要特征的，选择Spark 3.需要与传统的数据分析、展示系统对接，数据为结构化，要求高性能的数据，采用SQL引擎作为计算引擎（MPPDB） 4.实时流处理采用Flink 5.5.3.1 离线计算能力 离线处理，通常是指对海量数据进分析和处理，形成结果数据，供下一步数据应用使用的场景。离线处理对处理时间要求不高，但是所处理数据量较大，占用计算存储资源较多，通常通过MR或者Spark作业或者SQL作业实现。 离线处理场景的典型特点和核心能力是： 1.集群规模最大能力——数据量大，用户数据量最大超过5PB，大于1000节点 2.数据权限和资源隔离（多租户）——多种离线处理作业同时运行，需要不同的数据权限和资源调度，避免越权访问和抢占资源 3.接口与开源兼容——客户通常存在存量离线处理应用，需要迁移到数据治理系统 4.支持多数据源，多种数据加载方式——数据源存放在多种类型来源，存在多种类型数据，存在多种数据格式 5.滚动升级——离线处理是客户大数据系统的基础，停机升级无法忍受 6.支持作业调度管理——多种离线作业存在不同的优先级，不同的运行时间，需要多种调度策略管理，对异常、失败作业进行监控 7.支持异构设备——支持异构设备，客户扩容时支持配置升级的设备，并且支持新旧设备区分使用 8.支持冷热数据分级存储——用户数据热度不同，希望有分级存储策略，达到性能和成本的平衡 9. 支持与第三方软件对接（可视化、分析挖掘、报表、元数据等）——对接多种第三方工具，方便进行数据进一步的分析和管理 5.5.3.2 实时流处理能力 实时流处理，通常是指对实时数据源进行快速分析，迅速触发下一步动作的场景。实时数据对分析处理速度要求极高，数据处理规模巨大，对CPU和内存要求很高，但是通常数据不落地，对存储量要求不高。实时处理，通常通过Spark Streaming或者Flink任务实现。 实时流处理场景的典型特点和核心能力是： 1.处理速度快：端到端处理需要达到秒级，流处理平台负责的数据采集和数据处理要在1秒内完成。如风控项目要求单条数据处理时间达到秒级，单节点TPS大于2000。 2.吞吐量高：需在短时内接收并处理大量数据记录，吞吐量需要达到数十兆/秒/节点。 3.抗震性强：为应对数据源端业务数据产生速度会突然出现峰值的情形，需提供数据缓存机制。 4.可靠性高：网络、软件等故障发生时，需保证每条数据不丢失，数据处理不遗漏、不重复。 5.水平扩展：当系统处理能力出现瓶颈后，可通过节点的水平扩展提升处理性能。 6.多数据源支持：支持网络流、文件、数据库表、IOT等格式的数据源。对于文件数据源，可以处理增量数据的加载。 7.数据权限和资源隔离：消息处理、流处理需要有数据权限控制，不同的作业、用户可以访问、处理不同的消息和数据。多种流处理应用之间要进行资源控制和隔离，防止发生资源争抢。 8.第三方工具对接：支持与第三方规则引擎、决策系统、实时推荐系统等对接。 5.5.3.3 交互查询能力 交互查询平台主要承载对数据进行交互式的分析和查询，查询响应要求较高，能够实现人机之间交互，查询通常比较复杂。专题库的数据通常已经被预处理过，按照适合交互查询的数据模型进行组织。专题库数据量巨大，对CPU和内存要求很高，对于存储要求也很高。交互查询方式，以复杂SQL查询最为常见，也有简单的快读检索，多维Cube分析也比较常见。 5.5.3.4 实时检索能力 实时检索，通常是指数据实时写入，对海量数据基于索引主键实时查询，查询响应要求较高，查询条件相对比较简单。查询条件复杂的可以根据关键词在全域数据中通过索引搜索主键后，通过主键查询。全域数据既包含了结构化数据又包含了文本等非结构化数据。 实时检索处理场景的典型特点和核心能力是： 1.查询速度快：查询响应时间要求较高，通常要求在1秒内返回结果 2.高并发能力：需要同时支持多用户查询，如1秒千级并发查询 3. 数据量大：处理数据量巨大，通常在PB级别 4.能够同时处理结构化和非结构化的数据 5.支持全文检索功能 5.5.4 数据安全管理 应急数据涉采集面广，涉及政府单位涉密信息、企事业单位商业机密等，数据安全风险高。整体架构应遵循“零信任”的设计理念，建设数据安全防护系统，从数据的采集、交换、存储、使用、分享等几个方面进行防护，确保数据在整个生命周期中的安全性和保密性。 5.5.4.1 用户认证与角色授权 5.5.4.1.1 用户认证 大数据平台提供对外访问时，用户需通过安全认证，提供：pki身份认证、WebUI身份认证、CLI命令行身份认证、API身份认证等三种方式。 5.5.4.1.1.1 单点登录功能 用户在任意Web界页面登录后，组件客户端登录，访问其他各组件Web页面，无需再次输入用户口令进行认证。大数据平台需提供基于Kerberos的统一认证，客户端访问组件服务时，需要经过Kerberos机制认证，认证通过后才能访问组件服务。 5.5.4.1.1.2 应用组件API认证 大数据平台的应用组件提供对外的API，用户在使用这些API时，必须先进行Kerberos认证，认证通过后才能使用对应的API。 5.5.4.1.1.3 命令行方式访问 大数据平台的应用组件支持命令行操作，当用户登录到应用组件的节点上使用应用组件的命令之前，需要先进行Kerberos认证，认证通过后，才能使用应用组件提供的命令。 5.5.4.1.2 角色授权 大数据资源池提供可视化的多组件统一的集中用户权限管理，简单易用。同时提供基于角色的访问控制（RBAC），预定义权限集（角色）可重复使用，灵活。大数据资源池提供统一的用户管理界面。通过这个界面，管理员可以进行常规的添加、删除用户，以及重置密码等操作，并可以对用户访问权限进行设置。 支持对用户进行划分，为不同的用户赋予不同的访问权限。对每个用户群设定最大的访问权限，再对用户群中具体用户进行权限设置，实现细粒度划分，不允许任何用户超过为其设定的最大权限。依据数据敏感性规则，对数据查询、数据管理、决策系统等功能功能设置不同的用户角色，如数据查询、数据访问、数据调用、数据管理等。并根据部门提供的用户清单设置不同的角色，分配不同的用户权限。 5.5.4.2 数据加密 应急数据基于HBase、Hive、MPP等组件进行存储，为了保证数据存储的安全，数据应以密文的形式存储在硬盘上，不会因为硬盘泄露、或底层OS被攻破导致数据泄露。 大数据平台的HBase、Hive，以及MPPDB等组件均需支持透明加密。实现上层业务只需指定敏感数据，加解密过程业务完全不感知。同时大数据平台各组件支持本地数据目录访问权限设置，无权限用户禁止访问数据，同时所有集群内部用户信息禁止明文存储。 加密算法支持AES128、SM4。 密钥管理：密钥由独立部署、安全隔离的加密机生成，可通过角色和权限配置由专人管理，其他用户仅可使用；每种加密算法均有各自的密钥，所有密钥在数据库中均加密存储，读取的时候需要提供当前用户的登录密码；应支持密钥生命周期管理，且若密钥已被引用，则不允许修改、删除； 5.5.4.3 数据传输加密 5.5.4.3.1 大数据平台传输加密 大数据平台中的各个组件，如HDFS、Hive在进行数据传输的时候，应通过各种加密手段对通信协议进行保护。 HTTP：HDFS支持配置SSL，启用HTTPS加密通道。 RPC: 组件间的RPC交互使用SASL（Java Simple Authentication and Security Layer）来完成，SASL可配置对称密钥加密的方式来传输。 DTP：HDFS Client和DataNode之间的数据传输是通过Hadoop的DTP（Data Transfer ）来进行的。DTP支持3DES和RC4两种加密方式。 5.5.4.3.2 共享交换传输加密 共享交换平台负责从各参建部门采集信息（库表、文件、接口），通常采用发布订阅、点对点、路由转发等几种数据交换机制。通过在前置节点之间的通信应采用128位的SSL技术，或者在各部门之间建设VPN通道，在共享单位间进行可靠传输，确保连接的合法性、私有数据的保密性。 5.5.4.4 多租户隔离 大数据平台需提供可视化的多级租户管理，与单位组织结构和业务模式相匹配，简化系统资源分配与管理： 与单位组织结构相匹配的多级的租户模型，不同部门对应不同的租户，按需动态增删租户； 一站式管理租户资源管理：计算资源（CPU/内存/IO）、存储资源（HDFS）、服务资源（HBase…)； 基于linux cgroup容器机制的租户资源隔离，为租户SLA保驾护航； 租户资源使用情况实时监控。 5.5.4.5 安全审计 大数据平台支持记录审计日志，审计日志可用于安全事件中定位问题原因及划分事故责任，大数据资源池审计日志中记录了用户操作信息，可以快速定位系统是否遭受恶意的操作和攻击。 通过大数据审计系统，实现对大数据访问的日志记录与审计。 日志采集：在大数据资源池和数据库主机上安装代理，收集系统管理和数据访问、计算等环节的日志信息；过滤、聚合和标准化为标准格式。 日志管理：集中收集大数据平台各组件安全日志并高效长期储存，支持搜索、检索和报告；实现合规和监管要求。 事件关联与分析：自动分析安全日志以识别安全事件，威胁，违规行为和安全趋势。 报告与告警：提供安全报告，SQL行为、风险行为，政策性（等级保护）报表； 大数据审计系统功能如下： 全面审计：通过主机流量探针来捕获数据访问全流量； 业务关联：通过将数据访问行为和业务访问请求关联，将数据库访问行为定位到用户； 合规报表：数据访问行为、风险行为，政策性（等级保护）报表； 安全事件追责：应用层访问审计、大数据平台操作审计、业务关联匹配、事后分析追责； 大数据平台问题诊断：性能监控、资源监控、问题诊断； 5.5.5 统一调度管理 5.5.5.1 资源调度框架 分布式资源管理Yarn是离线计算能力、实时流处理能力提供支撑，尤其为计算能力提供计算资源并协调多种计算框架运行在一个物理集群中。 Yarn的主要功能是对集群中各类资源进行抽象，并根据各种应用程序或者服务的要求，按照一定的调度策略，将资源分配给它们使用，同时需采用一定的资源隔离机制防止应用程序或者服务之间因资源抢占而相互干扰。YARN调度器的ACL（访问控制列表）功能，控制了只有合法身法的租户，才能往响应队列提交计算任务的权利。 Yarn作为分布式资源调度引擎，是整个系统的调度核心，具体包括： 1）高性能的调度：采用容器重用以及专业的调度算法提升2倍以上的吞吐量 2）低时延的调度：采用异步通知和常驻会话等机制，把调度时延减低5倍以上 3）针对多样化硬件的出现，比如GPU计算设施，以及多样性软件的出现，包括MapReduce这种短生命周期应用，以及HBase、流处理这种超长生命周期应用如何共享资源调度，提供多维的调度算法 为了支持多部门共享大数据服务，在有充分安全保证的条件下，基于Yarn实现多租户架构。多租户架构允许按照组织架构来分配集群的各种资源，建立各部门独享的虚拟大数据集群，在虚拟集群管理员或者用户控制下，虚拟大数据集群间可以共享数据等集群资源。租户的数据既有隔离又有共享，相比于“一种计算框架一个集群”的模式，共享集群的模式存在多种好处： 资源利用率高 如果每个框架一个集群，则往往由于应用程序数量和资源需求的不均衡性，使得在某段时间内，有些计算框架的集群资源紧张，而另外一些集群资源空闲。共享集群模式则通过多种框架共享资源，使得集群中的资源得到更加充分的利用。 运维成本低 如果采用“一个框架一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本，而共享模式通常需要少数管理员即可完成多个框架的统一管理。 5.5.5.2 管理平台 系统管理平台提供可视化的运管工具，运行维护简便，用户经过简单培训应能自主完成日常运维和节点变更等操作。 系统管理平台通过为数据支撑平台的每一个部分提供细粒度的可视化以及管理控制，为Hadoop的企业级部署设定了标准，提高了服务质量并且减少了管理成本。 系统管理平台作为运维系统，为大数据资源池提供高可靠、安全、容错、易用的集群管理能力，可解决在开局、日常维护、故障处理、业务开发场景下的相关问题。 系统管理平台支持大规模集群的安装部署、监控、告警、用户管理、权限管理、审计、服务管理、健康检查、问题定位、升级和补丁等，提供如下功能： 一键式安装，单点登录，统一用户管理，维护操作审计，故障定位，统一监控告警，备份恢复，健康检查。 5.6 数据服务 通过提供标准化、模板化的应用服务接口来对外提供大数据资源的开放能力，主要包括数据基础服务、工具引擎服务以及业务应用服务。不同部门、不同单位可通过调用标准服务接口实现对数据资源、模型算法的数据服务访问，以满足实战应用和订制化开发的需要。数据共享服务可面向应急管理各级市大数据平台以及面向外部相关单位的服务，所有的服务都能够通过资源服务目录对服务进行注册、发布和使用。 5.6.1 数据基础访问服务 数据基础访问服务是最低层的服务，应能够通过数据存储访问中间件，实现对平台内的源数据、业务数据等进行底层访问，包括文件系统以及针对数据库的DDL和DML操作的表服务，并实现数据库表的创建、查询、插入、更新、删除等透明操作。 5.6.2 数据索引服务 提供数据资源的位置检索服务，通过统一的索引服务检索接口，根据所请求的要素值通过索引服务可以快速定位到资源的所在中心、所在省市、所在系统、所在库表信息等。 5.6.3 元数据访问服务 提供数据资源、服务资源的元数据查询访问能力，支持枚举数据资源、获取数据资源的元数据信息以及字段结构信息，包括对应的数据元信息等。 5.6.4 数据字典服务 提供数据字典的查询、翻译接口，返回字典类别、字典项值等相应所需结果，实现数据字典查询或翻译。 5.6.5 数据授权服务 为用户分配各类系统功能权限和数据资源访问权限。在实际授权过程中，通过动态授权、鉴权管理等验证角色是否拥有访问数据的权限。 支持对分级分类的数据，按照用户、角色进行授权；支持按照业务流程中的角色或者业务办理事项进行授权。 在不同库中，使用用户权限进行区分，对不同用户使用数据情况进行区分授权。 5.6.6 数据鉴权服务 对服务请求地向服务提供地发起各类服务请求时，服务提供地根据请求用户地市、角色对服务请求地进行身份鉴别、权限验证，对服务请求地用户发起的服务请求和用户（角色）权限进行验证。所有服务发起时须先进行鉴权。鉴权能力覆盖本地及跨地的全部数据访问行为。 5.6.7 数据接口服务 5.6.7.1 数据查询类服务 以预设或自定义的数据项为单一查询条件或组合查询条件，通过标准化的查询功能配置和服务接口调用，建立基于条件查询的分类分目查询功能和一键式查询功能，实现按要素分类查询或基于不确定关键字的一键式全网检索。查询类服务主要包含： 结构化查询服务：从数据库中查询出匹配的数据。 支持单表查询和父子表联查，支持前缀条件查询、关键字条件查询、完全匹配条件查询、多种查询条件组合查询等多种查询方式。 关联查询服务：关联查询服务提供多个数据资源项的关联查询，而对外表现为一个具有特定语义功能的查询服务。 全文关键词查询服务：根据关键词组合条件，查询符合关键词组合条件的全文数据。 全文相似文本查询服务：根据输入的文本块条件，查询与输入文本块相似的全文数据。 二进制文件查询服务：根据输入MD5（必填）和文件体长度（非必填），查询与输入文件相同的全文数据。 获取文体服务：根据输入的文件体路径，返回相应的文件体。 5.6.7.2 数据比对类服务 提供全量数据比对、增量数据比对等比对方式，实现比对时间和比对频次的自定义功能。如根据业务条件，对灾害事故影响范围内的关键基础设施、避难场所、救援物资等数据资源实现全量或增量的数据比对。 5.6.7.3 数据订阅/推送类服务 主动向外部系统推送加工好的数据或分析成果，以便应用于实战、体现大数据价值。如对灾害事故动态信息、应急知识、安全生产企业核查信息等提供数据订阅服务，实现精准推送。 5.6.7.4 数据分析类服务 依托平台数据分析类工具，提供包括历史事件分析、灾害事故发展态势模拟推演、事故风险分析等综合分析服务。 5.6.7.5 动态数据获取服务 协助用户在线调取实时气象、现场视频等智能感知数据。 5.6.8 数据可视化服务 数据可视化分析引擎借助于图形化分析手段，清晰有效地通过可视化方式表达数据分析逻辑，自助式构建数据治理可视化分析和业务预警可视化分析，满足数据治理分析简洁、高效、灵活及多元化的可视化展示要求。 5.6.8.1 可视化组件服务 多维透视图组件主要提供各种常用可视化图表组件，包括：标准柱状图、堆叠柱状图、多系列层叠图、标准条形图、圆点地图世界、路径地图世界、标准漏斗图、多漏斗图、矩形树图、树图、字符云、关系图等大屏可视化图表类型。对于每一个组件均可提供丰富的大屏可视化参数设置，包括维度数量、配色、对比、版集切换等。 5.6.8.2 数据治理可视化 数据治理可视化主要用于分析展示数据治理全周期运行情况，包括数据接入、数据处理、数据管控、资源库、数据应用等情况。通过联动、钻取，地理信息可视化、跳转、报告生成、多终端展示等分析功能及折线图、条形图、堆积图、饼形图、GIS地图、词云、表格、桑吉图、漏斗图、词云等可视化图形展现方式，展示数据治理的相关过程，并允许用户以图片、Excel、PDF、Word的形式将结果数据导出。包含但不限于以下内容。 5.6.8.2.1 数据治理概况 从宏观角度展示数据治理的成效与存在的问题，对数据治理总量、不同类型数据治理量、不同来源系统数据治理量、不同业务类型的数据治理量进行分析展示。 5.6.8.2.2 数据质量可视化 直观掌握当前数据的治理情况，对已接入数据总量、已完成治理数据量、未完成治理数据量、数据治理完成比、有问题数据数量、数据质量问题原因统计等。 5.6.8.2.3 数据接入可视化 通过统计接入数据、接入系统信息，分析展示信息包括接入数据总条数、当日数据增加条数、月度数据接入条数变化趋势、接入数据总量、当日数据增量、月度数据接入量变化趋势、接入数据类型统计、接入数据网络分布等，直观展示数据接入情况。 可按接入系统分类包分类展示各系统的各项指标。并通过环形图展示各类系统接入数据的占比，每类系统可以通过钻取查看细类数据指标，例如点击应急管理业务系统的接入总数据量，可以钻取查看各类系统的数据接入量等。 5.6.8.2.4 数据处理可视化 数据处理可视化分析主题统计已处理数据情况及数据处理的各个步骤情况，分析展示内容包括数据提取、数据清洗、数据关联、数据比对、数据融合、数据标识等处理概况，统计信息包括：处理数据总量、当日处理数据增量、处理数据量月度变化趋势、处理数据类型统计，数据提取总量、数据提取增量、数据清洗总量、数据清洗增量、数据关联总量、数据关联增量、数据比对总量、数据比对增量、数据融合总量、数据融合增量、数据标识总量、数据标识增量等。 5.6.8.2.5 数据管控可视化 数据管控可视化分析包括数据标准、元数据、数据资产、数据资源目录、数据运维等维度。 5.6.8.2.6 数据资源可视化 数据资源库可视化分析按照自然灾害、安全生产事故、综合防范类分类，包括地震灾害、森林火灾、草原火灾、火灾事故、非煤矿山事故、危化品事故、烟花爆竹事故、工商贸事故、煤矿事故、生产经营单位、重大基础设施、重大活动保障等小类，分析相关应急基础信息、应急装备、救援物资、救援队伍、事件信息、预案信息、经济损失等数据信息情况。 5.6.8.2.7 数据应用情况可视化 数据应用包括查询检索、数据获取、数据订阅、智能档案、智能标签等，数据应用情况可视化分析包括接口调用情况、应用封装情况、使用用户情况、实际应用效果等维度。 5.7 数据管控 数据管控主要是对数据资源进行全生命周期的过程控制和质量监督，通过规范化的数据管控，可实现数据资源的透明、可管、可控，厘清数据资产、提升数据质量、保障数据安全使用、促进数据流通。数据管控子系统提供数据标准管理、元数据管理、资源目录管理、数据鉴权管理、数据质量管理、数据运维管理、数据血缘管理和数据分级分类等功能模块。 5.7.1 数据标准管理 数据标准是为了消除相同属性信息因定义和描述不一致而导致信息理解和使用出现偏差，是各信息业务系统建设、业务数据交互的重要参考。数据标准管理提供一整套标准的维护、查询和落地功能，方便以最小的劳动成本管理数据标准。 数据标准管理工作需要明确专门的组织与人员。数据标准是对数据进行的统一定义，包括标准的业务属性、技术属性和管理属性三部分。所以数据标准的管理组织应该涵盖各业务部门和技术部门的相关人员，并逐条标准定义责任人。具体的角色、职责和建议的责任部门需要建设单位参与制订。 数据标准管理流程包括数据标准申请流程、数据标准制定审核流程、数据标准发布流程、数据标准推广流程和数据标准复审流程五部分，前三个流程组成数据标准制定与维护的全过程，后两个流程组成数据标准执行与验证的全过程，两大过程形成数据标准管理的闭环，实现数据标准的持续提升和落地实施模式。 数据标准管理平台负责维护用户统一的数据标准信息，是用户各信息业务系统建设、业务数据交互的重要参考。该系统应能够支持对基础主题数据标准、应用专题数据标准、数据基础指标口径的管理与维护，提供各项标准文件的查阅与修订功能，及时跟踪反映各项标准的执行情况。 （1）标准浏览 该功能主要基于标准梳理结果，对数据标准和标准落地进行全方位的信息展现，并可通过页面超链接的方式，对标准主题和公共代码之间的引用关系，以及标准到业务源系统落地情况进行灵活导航，方便用户快速地了解到标准间依赖关系、标准落地情况。 （2）基础主题标准维护 系统提供对已梳理基础主题数据标准的管理维护功能，包括修改、提交、审核、发布等基础维护功能 （3）指标标准维护 ①数据标准定义的维护：包含纳入指标数据标准定义范畴的数据标准项。 ②维度定义的维护：包含了“数据标准定义”中涉及的维度名称及定义描述。 ③维值代码定义的维护：包含了“维度定义”中所需解释的维值名称、代码取值及描述，是对维度的进一步描述。 ④公共统计规则的维护：包含了“数据标准定义”中所用到的适用统计规则。 5.7.2 元数据管理 按照数据整合的层次结构、主题域划分，需要实现各层的各种对象，如表、存储过程、索引、数据链、函数和包等的管理。清晰的表示各层次结构之间的数据流程、各对象之间的关系，以及向外提供的各类数据服务的信息。 5.7.2.1 元数据分类 按照元数据的定义分类，综合价值分析系统元数据管理分为业务元数据、技术元数据二类。其中： （1）业务元数据 使用者的业务术语所表达的数据模型、对象名和属性名。 访问数据的原则和数据来源。 系统所提供的分析方法及公式、报表信息。 对业务元数据来源的管理和差异性对比。 （2）技术元数据 系统结构的描述（各个主题的定义，星型模式或雪花型模式的描述定义等）。 整合数据层的机构单位的数据模型描述（以描述关系表及其关联关系为形式）。 对数据稽核规则的定义、汇总数据层模型描述与装载描述。 5.7.2.2 元数据管理 元数据管理包括元数据基础数据管理和元数据应用，由元数据自动获取、元数据检索、数据模型管理、元数据管理、血缘关系等功能组成等。 1）元数据自动获取 对元数据获取数据源以及这些数据源之间的关系进行集中登记管理，并形成自动获取数据源的全局视图，实现元数据自动获取数据信息。 要实现元数据的自动获取，需要在集成的元数据平台中配置自动获取策略和调度时间等，使元数据能够按预设的调度策略触发相应的元数据自动获取过程，满足元数据自动获取的时效性。 调度策略包括时间周期触发、事件触发两种方式。 2）元数据维护 包括元数据的定义、变更及版本管理，对主机信息、数据库信息、用户信息、数据对象信息、业务规则信息、加工逻辑等进行维护和管控。 3）元数据扫描 支持以手动或定时的方式扫描指定的数据库资源，并提取和解析相关的信息在比较扫描数据和原有数据的差异后自动将差异数据维护到指定的元数据目录。 4）元数据检索 在元数据管理首页用户通过输入关键字后，系统采用全文检索的方式迅速查找和关键字匹配的权限范围内的元数据信息，并将信息返回给用户。用户能够通过展示的路径信息快速定位到元数据组织树上的节点。 5）元数据地图 快速动态生成全局元数据地图，方便用户快速全面查阅所有元数据平台中各类信息，支持逐层钻取查看下级数据资产详情以及数据加工关系脉络。 6）元数据版本 版本管理分为元数据对象版本管理与基线版本管理两种类型。 元数据对象版本：对元数据的每次提交形成版本（上一版本形成历史版本），提供历史版本间，历史版本与当前版本对比功能。 基线版本，对某一阶段产生的元数据对象形成数据集，提供不同阶段产生的数据集的版本比较 7）权限管理及查询 统一实现数据库的访问和操作管控，对用户进行角色权限、对象权限、数据权限等方面的管控和查询。 8）元数据的导入/导出 在系统层面实现元数据的导入/导出功能，以保证数据模型、数据对象能够灵活的迁移，支持模型间的检查和比对，以便于数据模型的维护和扩展。 5.7.2.3 元数据分析 元数据分析算法包括以网状模式展示对象等血缘关系和以父子依赖关系展示对象等有向血缘关系。 影响性分析：包括血统分析和影响分析两类，以便于掌握和追溯对象变更时的缘由和影响关系。血缘分析是元数据分析中重要的分析应用，以图形方式清晰的展现出元数据（表、视图、字段、指标）每一步数据的来源情况，数据的来源情况包括该元数据的直接或间接使用到的其他元数据和加工该元数据所使用的加工规则。元数据对象和对象之间以连线方式表现出血缘分析的结果。 重要性分析：分析各元数据对象之间的关联密集度，分析数据仓库中各层次的包、表等对象的重要程度，指导数据仓库开发和维护团队对重点元数据进行重点关注和质量监控。 无关性分析：与重要性分析相反，随着数据仓库系统的规模不断扩大，业务需求的日益变化，会产生一定数量的无关数据、信息和报表，找出这些无关的内容，结合业务需求分析其产生的根源，从而为用户简化工作负载，降低项目总拥有成本，为用户提供可信赖的数据和分析能力。 5.7.3 资源目录管理 资源目录管理是按照统一的数据资源目录标准规范，对数据资源进行统一管理，实现数据资源科学、有序、安全使用。主要包括资源分类与编目、目录注册与注销、目录更新、目录同步、目录服务和可视化展现。 资源分类与编目：按照数据资源目录标准规范，对大数据平台存储的数据资源和通过接口方式提供大数据平台使用的数据资源进行梳理，并赋予唯一的目录标识符和编码。 目录注册与注销：由资源所属单位在本地大数据平台的数据资源目录管理模块中填写数据资源目录信息，审核、审批通过后完成注册。支持资源分级分类配置，支持批量模板导入。当数据资源暂时失效时，停用相关数据资源目录。当数据资源彻底失效时，注销相关数据资源目录。当数据资源恢复使用时，重新启用相关数据资源目录。 资源目录更新：当数据资源发生变化时，对资源目录进行更新。 资源目录同步：本地数据资源目录发生变化时，下级目录需向上级目录进行汇聚，上级目录需向下级目录分发。 资源目录服务：支持用户按照权限查看数据资源目录，支持根据数据资源目录相关属性和数据项进行数据资源的查询。支持目录注册、查询、核查和更新、同步服务接口。 5.7.4 数据鉴权管理 数据鉴权是基于数据的访问控制规则结合数据分级分类，实现数据的访问权限鉴别的过程。访问控制规则从内容敏感度、数据来源、数据种类、字段及字段关系分类四个维度进行资源权限的控制，资源鉴权通过用户的数据资源权限，使用数据鉴权服务实现对数据资源的访问控制。 服务请求方向服务提供地发起各类服务请求时，服务提供地根据请求用户地市、身份、角色，对其进行身份鉴别、权限验证，并对其服务请求和资源访问权限（权限细化到记录及字段）进行鉴别。鉴权能力覆盖本地的全部数据访问行为。鉴权服务不直接对用户提供服务，仅在鉴权服务外的其他服务中调用并进行权限验证。 5.7.5 数据质量管理 数据质量应当在整个数据仓库规划、设计、建设、维护中体现和实现。数据质量保证重点从数据质量组织机构、数据质量管理以及数据质量验证机制三个方面考虑，提供相应的管理流程支持。 为保证质量过程持续的改进，保证所有已知的错误在系统中不重复发生，建立完善的数据质量文档体系，整个系统内的数据质量活动都要求有完善的纪录，最终依次建立或完善质量考核体系。 数据质量管控由数据处理过程监控、数据稽核、问题管理、日志管理、质量报告、问题处理等环节组成。 1）数据处理过程监控 监控数据处理任务执行的情况，包括是否按时调度，是否成功等状态消息。监控数据装载和数据分发到数据缓存的采集流程和结果状态。监控业务数据源是否按要求及时准备数据、提供的数据是否符合约定和采集过程。 2）数据稽核 数据质量稽核是数据质量管控的核心，对ETL整个流程的数据质量进行稽核，主要分为数据来源环节和数据加工环节。 数据来源稽核：数据来源稽核主要包括接口的规范性、完整性、一致性稽核、及时性监控。 数据加工环节稽核：数据的加工环节重点要稽核各层之间数据的一致性以及数据的准确性。一致性包括数据在由数据源到整合层，中间层，应用层到数据封装服务接口的传递过程中，数据能否保持一致。在数据保证完整一致的基础上，根据业务情况对重点业务指标进行波动检查，准确及时地找到异常数据，需要参考以往合理月数据指标的环比变化，确定该指标变化的波峰，波谷，由此形成其正常变化范围。通过环比对照，若该数据在正常变化范围内，则说明该指标数据正常。若偏离正常变化范围之外，则说明该指标数据异常。 ETL功能在所有源数据处理的必须经过的环节，其保证了数据的可用性和准确性。 3）问题管理 为数据质量相关问题处理提供的IT化支撑功能，在发现问题、处理问题的过程中，可以通过问题报告的形式登记问题、指派处理人员，并提交问题处理情况，体现流程化的管理。提供质量问题的创建、发布，以及处理过程的跟踪，为数据校验提供解决、跟踪平台。 4）日志管理 包括规则运行日志、告警日志、过程执行日志，为用户提供规则运行的最终稽核状态和历史稽核状态日志，以及除数据本身的异常外的异常监控和各层过程的执行日志的监控。 5）质量报告 对稽核功能模块和问题管理模块做整体的统计分析，包括三类报告： 总量评估报告：对需要评估总量的数据质量检查/稽核报告（可配置），统计各类错误数，从总体上对数据质量的收敛度进行评估。 数据源的质量评估报告：比如各类错误统计、接口的稳定性、及时性指标，对各源系统的质量的收敛度进行评估。 专项数据质量问题评估报告：以报告模式对重点关注的质量专题，制定专题规则进行分析并对结果予以评估。 6）质量问题处理 问题分析：数据质量问题生成后，首先需要进行问题的分析与定位工作。 数据隔离：当发生重要或严重级别的问题时，可根据需要先采取数据处理流程挂起和问题隔离措施，将问题的影响范围控制在较小的区间内，防止问题扩大，便于问题的解决。 数据维护：对于大数据处理环节造成的数据质量问题，启动相应的数据质量维护流程，解决相应的数据质量问题。 过程总结：当问题处理环节结束后，需要对问题处理的全过程进行记录和总结。数据质量管理系统在对数据的质量进行监控的同时，也对数据提供者有了考核的依据。 5.7.6 数据运维管理 数据运维管理是通过采集数据接入、处理、组织和服务等各项任务的状态信息，对异常状态进行预警和处置，实现对各任务的实时监控和管理。 运维规则配置管理：对数据运维的实时监测、日志采集、日志统计分析、报表展示、日志输出、预警阈值、预警规则和信息、数据对账等相关规则进行配置管理。 数据实时状态采集：支持对来源数据以及接入、提取、清洗、关联、比对、标识、分发、入库等环节设置监控点，进行多维度信息的实时采集。 数据运行状态监控：包括对来源数据的监控（通道是否连通、数据是否更新等），数据接入及处理状态的监控、统计（运行是否正常、数据流量情况等），数据积压监测及统计，数据心跳图，数据入库异常统计、当日或指定时间周期内各类数据的增量及存量监控、数据服务接口监控等。 数据运维报表：支持对系统的数据资源总体情况、分类情况、上报下发情况等多种维度进行统计分析。支持对数据对账分析、数据有值率分析。支持数据标准化分析，形成数据运维报表并实现可视化展示。 数据预警管理：当出现实时流监控异常、运行状态异常、数据质量异常、数据备份异常等状况时，触发告警，告警结果可以通过消息、服务、邮件、短信等方式推送给运维系统或运维人员。 数据运维日志审计：针对所有数据运维工作的操作日志进行全方位、全流程安全性审计。 5.7.7 数据血缘管理 数据血缘是在数据产生、加工融合、流转流通到最终消亡等过程中形成的继承关系集合。通过对接入数据、原始库、资源库、主题库、专题库等各类数据资源间和数据项间的继承关系进行描述和管理，反映数据资源在各个环节间的继承关系。 血缘关系管理：记录上下游数据资源编码、数据项编码和数据资源转换规则等数据血缘信息，并实现动态更新。通过元数据模块以历史事实的方式记录每项数据的来源，处理过程，应用对接情况等，记录了数据表在治理过程中的全链血缘关系，基于这些血缘关系信息，可以轻松的进行影响分析，以数据流向为主线的血缘追溯等功能，从而提升报表信息的可信度，为数据的合规性提供验证手段，帮助业务部门实现信息共享、提升协调工作效率。 数据血缘关系分析：数据从源到目的地，经过大量的功能模块的处理和传递，呈现在业务用户面前，分析数据的来龙去脉。支持对数据资源进行数据流向分析、溯源和变更影响分析，并提供数据血缘关系的图形化展现。 血缘关系应用：支持基于数据血缘信息，进行相关的元数据应用分析如溯源分析、影响分析、重要程度分析和数据时效性分析等。支持按照数据类别、数据项和转换规则进行数据血缘查询，并向数据资源目录提供服务接口。 5.7.8 数据分级分类 为解决数据管理，特别是数据开放共享过程中缺乏数据敏感度衡量标准等问题，采用数据分级分类管控。主要内容包括：对数据进行分级分类，根据对外开放及敏感程度进行管控，制订不同级别的敏感数据在对外开放和内部管理中应遵循相应的管控实施要求，并提供原始数据及标签数据的模糊化等示例，利用数据分级分类对数据进行标识，配合数据授权、数据鉴权等，确保数据的安全使用。 数据分级分类是对数据资源访问级别进行限定的基础和依据。通过数据分级分类，对涉及敏感内容、隐私内容、定位信息等内容的记录和字段进行分级别的访问限制，防止敏感信息的扩散，杜绝手段滥用的风险。 1）数据分级 数据分级是通过对数据内容的敏感程度，对数据资源进行分级。数据分级包括数据分级管理、用户分级管理和系统分级管理三个方面。 数据分级管理：基于数据表设置安全级别，共分5个等级： 数据分级管理 级别名称说明 第Ⅰ级可公开数据可对部、省业务直属部门开放，可对外部社会组织开放。 第Ⅱ级业务数据可对全内部业务人员开放，不可以对外开放。 第Ⅲ级重要业务数据涉及部分安全隐私数据，业务部门研判分析使用 第Ⅳ级敏感数据涉及隐私数据，经过审批可以使用。 第Ⅴ级特别敏感数据绝密数据，由专业部门立案后审批使用。 用户分级管理：基于数据使用人员，共分4个等级： 用户分级管理 等级说明映射 第Ⅰ级全内部直属人员、部分外部共享人员查询数据的权限对应数据Ⅰ级 第Ⅱ级应急体系内部科室人员查询数据的权限对应数据Ⅱ级及以下 第Ⅲ级业务部门人员查询数据的权限对应数据Ⅲ级及以下 第Ⅳ级重点分析研判人员查询数据的权限对应数据Ⅳ级及以下 系统分级管理：系统安全共分3个等级： 系统分级管理 等级名称说明 第Ⅰ级普查系统（绿色）全部人员可用 第Ⅱ级 授权系统（黄色）内部授权可用（需要在界面上标明向谁申请） 第Ⅲ级专有系统（红色）提请调用的，需要经过流程审批后才能使用，比如针对某个灾害事件要访问其他系统，军事设施分布的系统 以通用搜索应用为例描述数据的权限控制。在数据共享时分别创建四级用户，通用搜索上的业务人员级别分别与数据共享的Ⅰ、Ⅱ、Ⅲ、Ⅳ级用户对应，并通过四级用户访问数据。 2）数据分类 数据分类是通过数据融合后的种类进行分类。应急数据融合之后将数据分为原始库、资源库、主题库、专题库。根据应用的需求，可以给访问不同类别的数据资源。 5.7.9 生产库管理 对上层应用所有数据库统一管理。 5.8 数据共享交换 按照黑龙江信息资源交换和共享标准规范，制定黑龙江应急管理数据交换平台的标准规范。充分整合现有的城市管理信息资源，基于应急云计算环境，建设应急管理统一的数据共享交换平台，提供统一的数据共享交换功能，满足当前及今后各种跨部门、跨区域的应急管理信息资源共享和业务协同要求，推进信息资源开发利用。 数据共享交换平台提供统一的数据共享交换功能。横向上实现与部署在各种网络上的黑龙江应急管理部门自建业务系统、相关部门所建业务系统、其他业务系统数据交换。纵向上实现向部委系统上报数据及向下级单位分发接收数据。支持WebService、Socket、消息队列等数据交换方式，并提供身份验证、加密传输、数据完整性、安全审计等数据共享交换安全机制。 5.8.1 服务共享管理 采用面向服务架构(SOA)的企业服务总线（ESB）成熟技术，采用组件式分层开发方式，支持任意源端到目标端的数据交换共享服务。 5.8.1.1 服务目录 建立适应应急业务特征的服务目录框架，根据业务特征，服务目录框架包括查询类服务、比对类服务、统计类服务及其他类服务。 5.8.1.2 服务注册 实现对后台已注入的服务注册/发布至服务中心，并可对服务中心里的服务进行查询、查看、修改注册信息、上线等操作功能。系统支持对单表资源通过前端配置自动发布成服务接口。 5.8.1.3 服务申请 平台用户可通过统一的服务资源目录查看并申请个人所需的服务。 5.8.1.4 服务发布 对审核通过的服务进行服务发布，对正式发布的服务可以提供使用者进行服务的查询。 5.8.1.5 服务订阅 对于暂未发布/不存在的服务，系统提供统一订阅申请的功能模块，为各服务申请单位提供统一服务订阅入口，统一管理。 5.8.1.6 服务审核 服务申请单提交后，具备审核权限的用户可通过工作台查看待审核的服务申请单，并进行相关的审核操作。管理员可通过服务台对系统所有的服务申请单进行维护。 5.8.1.7 通用服务接口 通用数据服务接口是给其他模块或者系统使用的一种约定或者规范，接口设计应遵循统一接口规范，保证接口性能良好。 共享交换管理 共享交换平台主要实现：数据交换管理、数据交换服务、共享资源配置、交换中间库建设。 5.8.2 数据交换管理 提供交换节点、交换服务和交换桥接的配置、调度和检测功能。提供交换服务和交换桥接的日志查询和统计功能。 5.8.2.1 数据交换服务 提供共享域内交换节点之间的数据共享交换服务，包括采集、分发、汇总和转发。提供交换节点与业务系统之间的交换桥接服务，实现数据提供和获取。提供跨域交换服务，实现共享域之间通过对接节点进行数据交换。 5.8.2.2 共享资源配置 对需要进行共享的数据资源进行配置，包括数据源、数据库链接、数据表配置、共享数据项目配置等，对共享资源的配置提供修改、查询和删除等日常管理功能。 5.8.2.3 交换中间库建设 数据采集过程中源端到目标端经交换平台产生的交换数据，包括数据交换目录及交换数据库。 5.8.3 数据对接服务 建立安全、稳定、高性能、跨平台、跨系统、跨应用、跨地区的信息交换平台，提供应急管理综合应用平台对外服务接口，实现新老系统之间、异构系统之间的信息的透明交换，各行业各部门的系统将统一通过这一平台进行信息交换，以达到整个应急管理综合应用平台资源共享互通的效果。 系统提供基于消息的数据传输服务。从一个应用系统传输数据实体和数据格式到另一个应用系统，每个传输服务可以运行多个传输实体。 交换服务提供了断点续传机制。在规划数据流程的过程中，数据从一个系统节点传送到另一个系统节点时，用户可以根据实际应用情况（网络状况、应用系统状况）选择两个系统之间的消息传送机制。断点续传机制就是其中的有效传送机制之一。断点续传跟踪检查是否每个目标应用节点收到了该消息，如果目的节点因为某个原因没有激活或者与发送节点之间的连接断开，系统在队列中保存这些要发送的消息一直到目的节点处于激活状态或连接畅通。当源节点和目标节点保持有效连接后，系统再把这个消息交付给目标节点。 另外系统也应该提供断点处理功能，用户可以通过流程诊断工具查看流程发生错误的断点，用户可以只修改发生错误的断点处的消息，然后把该消息重新发送，而不是回退和重新发送整个流程。 5.9 算法模型 5.9.1 算法工程 算法服务平台包含了各种各样的算法组件，包括基础算子、统计分析、数据预处理、特征工程、机器学习、文本分析、网络分析以及业务算法组件等。算法组件主要由各厂商提供，也可以采用外部购买的方式来持续完善整个算法平台的服务能力。 通过算法平台用户可以了解每个算法的使用方式，包括功能描述、提供厂商、使用API、开放方式（服务接口、SDK包、可执行计算包等），用户也可以将自己的算法包上传到算法平台之上，以免费或者付费的形式开放给其他用户使用。 通过在算法平台申请使用算法组件之后，用户可以将算法包嵌入到应用程序中运行，也可以通过服务接口访问的方式在应用程序中集成，另外算法组件也可以为模型服务以及可视化分析平台提供算法支撑服务。用户通过模型标准描述语言或者可视化的方式配置算法的输出、输出、执行顺序，以工作流的形式传到数据治理系统进行运算和操作，所有算法都是以plugin的形式存放在底层的计算引擎当中，用户在使用算法的时候只关心算法的调用即可，真正实现了算法和计算引擎的解耦。 5.9.1.1 算法管理 提供算法包注册、修改、删除、启动、停用、查询、评价等全生命周期管理，用户可以将算法名称、算法描述、支持运行的平台（内存计算，离线计算，图计算等）、算法类型（基础算子、机器学习算法、业务算法等）、算法执行包、算法参数集、开发语言、开发厂商、提交单位等信息注册到算法平台。提供对算法信息进行查询功能，支持查询算法列表信息和详细信息。还可依据算法使用次数、点击量、好评数等指标，通过赋予相应权重系数（可灵活设置）对各算法进行评价，评价结果以分值体现。 5.9.1.2 算法组件 提供包含了基础算子、统计分析、数据预处理、特征工程、机器学习、文本分析、网络分析等算法组件。用户可以通过java sdk或者模型描述语言以及通过可视化分析平台的方式使用算法平台提供的算法，按照算法平台提供的使用指南，设置算法运行参数，执行算法。每个算法之间包含了输入和输出，可以通过组合算法，形成一系列复杂的分析模型。 5.9.1.3 算法库 依托大量算法工程师对平台算法进行优化和设计，建设涵盖统计分析、特征工程、文本分析、机器学习、网络分析、深度学习等多个领域的算法库，为平台提供各类算法支撑。 此外，系统提供页面可视化创建自定义算法，支持Java、Scala、Python、R、C++语言进行算法自定义。并提供对应语言的语法接口和可调用库，方便用户创建和调用所需算法。 5.9.2 模型工程 模型工程是实现模型构建、模型研判、任务运行等功能的面向交互式大数据分析处理的基础性、支撑性工程。模型工程的主要目的是通过统一的模型框架应对大量个性化的建模需求，实现交互式、可配置的模型构建和研判，实现易于管理的自动化部署。支持数据、算法的灵活扩展，支持对结构化、半结构化和非结构化数据的融合分析建模，实现不同研发单位构建的模型能够兼容运行。 5.9.2.1 模型创建 用户通过多种建模方式创建基于应急管理模型标准的模型，部署到模型运行引擎上面配置模型参数，模型运行引擎会对模型运行的合法性进行验证，包括是否符合模型标准，数据资源是否有访问权限，算法参数是否合法，模型编排是否合理等。模型通过验证之后，会上传到测试平台上面，通过数据采样、构建测试集等多种方式检测模型执行的准确性。模型测试成功之后，进行模型上线部署。通过申请计算资源，将模型实例化成任务运行。 传统建模的数据来源和模型的使用一般在同一数据库当中，而应急管理大数据环境下，因为数据采集类型的多样性，和数据计算的多样性使得来源和使用分散在不同的计算存储资源当中。一个模型的运行可能需要涉及到图计算、离线计算、多维分析等多种方式的计算，因此模型需要能在多个存储和计算资源当中自由流转。 模型适配主要是解决了这种需要跨存储、跨计算资源的统一运行。通过对模型的输入、输出、算子进行识别，将需要涉及到的数据输入、输出资源调度到对应的数据接口服务中，通过统一的数据接口服务，降低了模型运行的复杂度。 通过将算子调度到合适的数据接口服务上面执行。每个算子的运行都会对应到一个计算框架上面，通过解析算子的执行顺序以及依赖关系，整个模型的运行过程会形成一幅有向无环图，形成有向无环图的过程中也会根据算子之间的依赖关系形成血缘，当某个算子计算错误的时候，只需要根据血缘重新计算相关的操作不必回滚整个模型。 5.9.2.2 模型分析 模型服务提供趋势分析、异常分析、相关性分析等元模型分析功能以及统计分析算法、聚类算法、分析算法等算法的运行分析。 专业用户可以基于可视化智能建模功能，对元模型、算法、数据服务结合数据资源进行动态编排，构建以“灾害事故”为核心，“救援资源”为重点的数据分析模型。 对外通过智能化建模编排完的模型，可以通过模型服务进行模型解析、模型适配，再通过模型工程中的模型运行引擎对模型里面的算子、服务、数据进行调度。 模型服务除了提供动态模型的建模调度能力之外，还应提供固化模型的调用分析服务。 5.9.2.3 模型管理 模型管理：提供模型的注册、修改、删除、查询、评价、分享、生命周期、质量、导入导出能功能。 模型任务管理：模型任务是对已编排好的模型进行实例化执行的过程。模型实例化主要包括：任务类型、输入参数实例化、执行周期实例化、输出结果实例化等。 模型数据集管理：模型数据集包含模型输入数据、模型输出数据、模型中间结果。模型数据集依照统一资源目录的标准进行定义和使用，覆盖数据存储空间管理、数据的存储生命周期等过程，并支持算子间、节点间的数据存储和交换。 模型资源管理：数据资源是面向使用者的，应能对模型使用的资源配额进行管理，用于对外共享交换，是实现对外共享交换的最大单元。数据资源管理实现数据地图呈现、数据目录管理和数据资源管理。 元模型管理：对元模型进行管理维护、并能能够进行物理模型创建。 5.10 工具引擎 5.10.1 通用工具 5.10.1.1 可视化工具 通过可视化方式对原始数据、标准化数据、资源库数据、专题库数据等进行多源数据组织分析，对可视化主题分析提供应用支撑，支持钻取分析、联动分析、跳转分析、多表关联、追加合并、聚合分析、SQL创建、字段编辑等功能。 5.10.1.2 智能查询工具 智能查询工具是将数据治理平台汇聚的各业务部门数据、外部门数据、基层单位数据、社会面数据和感知数据进行全局的综合查询检索。智能查询工具提供全文搜索、专题检索等功能。 1、资源搜索 通过指定搜索条件、指定搜索范围对数据进行搜索，以资源列表形式展示搜索结果，其中搜索条件、搜索范围包括数据来源、有效时间、数据表范围等。 如用户需要搜索以往某一时间段、某一森林范围发生过哪些火灾事件，可在筛选对话框内选择该时间段和该森林区域，系统将以列表形式展示搜索结果，包括火灾发生时间、名称、具体位置、持续时间、经济损失，点击某一具体火灾事件，可查询事故报告。 2、全文检索 全文检索提供针对系统的文件信息的数据检索功能。系统用户在“搜索”框中输入关键词作为查询条件，系统将依据用户权限情况进行查询结果的列表展示，其中涉密数据将进行脱敏展示。 3、专题搜索 专题搜索是指系统用户在某一专题下进行目标搜索，专题包括森林草原火灾专题库、地震专题、危化品事故专题，系统将依据用户权限情况进行查询结果的列表展示。支持逻辑运算组合检索、通配符检索、模糊音检索、时间段检索、地理区域段检索。 5.10.2 业务流程引擎 通用业务流程引擎是业务系统中的一个基础支撑模块，用于提供对应用中各类业务流程的管理，根据业务特点，针对监测预警、监督管理、指挥救援、决策支持、政务管理业务建立通用的业务管理模型，为各业务子系统提供基础的业务流程管理服务。 5.10.2.1 中间件 业务流程引擎中间件包括流程引擎、规则引擎和业务全引擎三个核心模块。 1、流程引擎 流程引擎负责对流程模型和数据模型进行管理，按照业务控制流的定义把流程节点从一个节点推向下一个节点，流程引擎负责这些节点的状态维护和监控并把业务数据按照节点的运行规则发送给不同的用户进行处理，当这些节点的状态或者数据发生改变时流程引擎负责把状态的变化通知规则引擎，规则引擎收到通知后会根据这些事件的类型和时间顺序来触发事先定义好的业务规则并把运行的结果反馈给流程引擎。 2、规则引擎 规则引擎是对整个业务流程节点及路由的控制规则及业务集成规则进行定义并解析和运行的智能引擎，规则引擎不仅可以接收由流程引擎发送过来的事件和通知来触发事件，还可以主动监控业务流程运行过程中的异常或者是数据流。通过对这些异常或者是业务数据的主动监控可以及早地预防事故的发生，使管理人员、业务负责人可以及时主动的发现问题。 3、业务全引擎 业务全引擎负责系统的权限及关键数据的监控和记录工作，当用户试图进行一个业务操作时业务全引擎首先会对用户的权限进行监控，如果没有权限则阻止用户操作并且记录日志和发出预警。当用户对系统中的关键数据进行编辑、删除、阅读时，业务全引擎都会记录用户身份信息、操作时间、IP地址、业务标识等信息，以方便管理员进行追查和分析。 5.10.2.2 基础服务组件 基础服务组件由流程管理工具、监控分析工具、抽象出来的业务流程模型以及内部和外部的服务接口组成，它们共同为业务应用提供基础的服务支撑。 1、工具集 工具集为业务流程引擎提供的一系列方便管理人员、业务人员以及开发人员进行流程模型定义、管理和分析的可视化工具。这些工具不但可以加快流程应用的开发还可以对流程引擎、规则引擎、业务全引擎等中间件的状态及实例进行监控和管理，使系统管理员可以更好的了解当前业务流程引擎的运行状态、业务量、各业务的处置情况、处置时间等。 工具层中提供功能丰富的可视化流程建模工具、规则建模工具、数据建模工具、分析报表工具等功能，通过这些工具开发人员和业务人员可以快速的根据系统的业务需求完成流程的定义。 2、业务流程模型 根据业务应用中的业务流转需求，利用流程建模工具、规则建模工具、数据建模工具对业务流程进行抽象定义，形成一个通用的业务流程模型，比如可以将政务管理中的行政许可审批定义成一个抽象的行政许可审批模型，对审批的步骤、用户、每一步的输入输出以及数据处理规则进行严格定义，而业务系统只要通过公开的服务接口引用该模型即可完成行政许可审批的业务流转。 5.10.3 工作流引擎 主要包括核心引擎、核心API、工作流等功能。工作流引擎结合云计算提供的微服务功能，通过API网关实现流程服务的开放，业务系统通过远程调用的方式获得流程服务。 5.10.4 搜索引擎 平台提供快捷的搜索引擎功能，通过搜索方式帮助用户快捷浏览需要的公文、知识、业务数据、政策法规、办事流程、政务、日常办公、项目资料、资金财务等各个方面的信息资源，并在搜索结果中显示关键词上下文，让用户快速准确的查找到公文。 全文检索组件支持对关系型数据库的全文检索功能，包括目前流行的Hadoop、Oracle、DB2、SQLServe、mysql、Sybase、达梦、南大通用、人大金仓、巨彬等，支持对站点内容的全文检索功能，支持对应用系统的全文检索功能。支持集中式的数据存储方式。 5.10.5 表单引擎 为满足应急管理综合应用平台业务表单的多样性，基础支撑平台建设提供强大的表单引擎，让用户自由定制各类业务流中的表单，确保流程完全符合应急管理综合应用平台系统的实际运行状况。让用户拥有完全的自由度，可以根据需要自定义表单样式以适应应急管理综合应用平台系统的业务调整，无需进行复杂的二次开发。 表单支持图形化设计，设计好的表单遵循国际标准规范，以xml格式进行存储，以实现表单模板和表单数据的分离。表单设计工具允许表单设计者以简单的拖拽方式，方便地重建与纸面表单外观保持高度一致的电子表单。利用“设计一次，发布多次”的优点，可以设计出适合多种输出格式的表单模板文件，增强表单复用性。 5.11 标签工程 标签工程应能够提供标签体系构建、标签分类、标签规则的定义与执行、标签构建流程管理、标签全生命周期的可视化管理等系统服务。 5.11.1 标签体系管理 支持标签主体管理；支持标签目录管理，支持以树状目录分类呈现等功能；支持标签管理，包括标签需求分析、标签专题数据预加工（归集、清洗、标准化、整合）、标签数据同步、标签创建和标签计算等功能。 支持标签主体的创建、编辑、删除。支持标签和标签目录创建、编辑、删除；支持标签血缘查看。 支持对象实例标示属性查看，展示对象实例标签信息、属性信息、支持批量创建、编辑、删除、支持添加、删除标签过滤条件。 5.11.1.1 标签主体管理 标签主体是基础，只有标签主体明确才能确定应急管理标签体系建立的方向和范围。应急行业标签主体将选取具有唯一标识的关键主数据，主数据是描述应急核心业务实体的数据，这些数据是应急管理的关键业务实体，它为应急管理的业务开展提供关联环境，而且它可能在应急业务开展过程中被反复引用，是可以共享的数据。它需要在业务管理范围内保持高度一致，记录业务活动，与波动较大的数据相比，主数据（也称基准数据）的变化频率应该是缓慢和稳定的。 针对应急管理领域，应急标签主体的选择将使用应急要素分类中的主数据，从这些应急要素中挑选出有唯一标识的，对应急管理有影响能力的主体。 以灾害事件为例，由于应急管理部门在事件分析研判、应急救援等活动中，都针对特定的灾害事故，比如地震、森林火灾、洪水、台风、生产事故等。围绕这些事件分析其周边危险源、防护目标、救援队伍等特征构建标签，进而可进行特征数据碰撞与关联分析，为了在更广的范围内进行特征碰撞分析，在设计标签主体时应避免选择具体某一类事件，比如地震、台风等事件作为标签主体，这样会陷入到数据面过于狭窄、难以广泛进行碰撞分析的情况当中。 确定标签主体后，需要明确标签唯一标识ID，而身份证作为中华人民共和国境内的13亿人口的唯一标识，是天然的索引，不会存在任何两个人的身份证号码相同的情况，因此身份证号码应作为实体人标签主体的唯一索引。在高级应用中，是否同时采用其他信息作为索引，可以结合实际业务需求而定。 综上所述，可选择以下标签主体及相应的唯一标识（主数据）纳入标签主体数据管理范畴： 标签主体数据 要素 标签主题唯一标识 人救援人员、专家、受灾人员身份证件号 事自然灾害事件、安全生产事故、重大事件事件编号、案件编号 组织组织机构组织机构编码、群体编号 物车辆、救援物资车辆号、物资编码 地关键基础设施、应急避难场所设施编码、场所地址 5.11.1.2 标签目录管理 提供配置和维护标签主题对象和标签分类目录功能。可创建任意的标签主题对象类型，如果主题对象已创建有标签，则不能删除。 以树型结构灵活配置标签分类目录，可增加和修改各细目录描述信息，随意调整目录结构，至少支持4级以上分类目录设置，以保障标签体系建设的灵活扩展。 标签目录体系是应急大数据治理平台标签应用开发和利用的基础设施，从标签目录体系可以快速构建和清晰标签的主要作用、使用对象、应用模式。也可以按类别协助开发利用已有标签资源，实现标签资源的共享。标签目录结构采用多层树状目录分类，标签目录体系的设计遵循业务性、通用性、可扩展性原则。 业务性：主要面向应急管理业务及应用，从使用者的业务逻辑视角出发，构建标签分类结构，便于分类体系好找好记。 通用性：根据不同业务部门用户对标签的通用性需求，逐层递进构建标签分类结构，在提供标签共享的同时，保障部门私有标签数据的安全。 可扩展性：根据业务和数据的变化，整个分类体系应可灵活的迭代、扩展，扩展的同时不影响现在分类的设计。 本项目标签规则库结构设计示例如下： 标签目录体系结构示意图 5.11.1.3 标签管理 标签管理提供标签需求分析、标签专题数据预加工（归集、清洗、标准化、整合）、标签数据同步、标签创建和标签计算等功能。 标签需求分析 根据汇总和提炼标签需求得到的标签预加工表，从业务源表中分析标签的取值来源，明确取值范围、清洗规则、过滤条件等，生成映射文档，辅助ETL开发人员开发加工脚本。 标签专题数据预加工 通过特征提取、清洗、整合等处理，从原始库、资源库中加工成标签专题数据（如体现事件基础特征、演化动态、关系特征、业务特征等的标签）。 标签数据同步 支持标签数据的全量同步或是增量同步，当选择增量同步时，需要选择增量字段或是增量条件，当选择全量同步时，系统会默认同步该标签的所有历史数据。 支持同步标签数据源的自定义筛选，可筛选特定时间段、特点类型的标签数据源进行同步，也可以通过自定义SQL语句的方式来设置同步条件。 标签创建和计算 在标签管理平台上创建标签，通过分布式计算对标签专题库中的原始数据进行标签计算，生成带标签的数据。 标签创建功能将基于已汇聚、标准化数据，经过对大数据进行主题对象整合，以及权威数据处理后，配置标签的基础信息、计算规则和刷新策略，后续将自动根据规则引擎生成标签结果数据。 标签基础信息配置内容包括标签名称、标签分类、标签类型（静态或动态标签）、标签共享方式（公共或私有）、标签说明等信息。其中标签类型中静态标签为没有时间周期概念的标签，一个主题对象仅有一个标签值，如：性别、民族、经济情况等标签；动态标签为有对应时间周期的标签，一个主题对象在不同的时间周期对应多个标签值，需求创建时指定标签时间周期的配置策略。 标签维护 标签维护是对已上线的标签进行修改，可修改内容包含：标签分类、设置可见权限、选择标签类型（公共或私有）、标签说明等信息。在标签维护之前必须进行标签停用操作。 标签删除 标签下线操作包括：标签正常下线、标签停用、标签强制停用。 1、标签正常下线：具有标签下线权限的用户（标签创建者和标签管理角色）通过手动下线标签来下线标签。若该标签被其他标签引用（如：组合标签中用到该标签）则需要发起影响审批给所有引用此标签的部门。标签下线审批通过之后，此标签将被下线，所有引用此标签的标签都被停用。 2、标签停用：在标签结果出错或某些紧急情况下，支持标签停用功能。具有标签停用权限的用户通过手动停用标签来停用标签。 3、标签强制停用：在紧急情况下，管理员可以强制停用标签，管理员强制停用标签时，停用此标签和所有引用此标签的其他标签也一并被停用。强制停用无需审批。 标签统计 支持标签数量统计，并可以图表形式直观展示统计结果。支持按标签数量数据进行排序。 5.11.2 标签分类管理 标签分类的目的是为了方便标签的使用和管理，使标签系统更富有层次性，表分类的标准从业务、管理、技术全方位描述标签，满足不同人员需求，使得业务人员、管理人员、技术人员更易于理解和采纳标签。 系统提供配置和维护标签主题对象和标签分类功能。从业务角度、管理和运营角度以及技术角度对标签进行分类管理。可创建任意的标签主题对象类型，如果主题对象已创建有标签，则不能删除。 可以树型结构灵活配置标签分类，可增加和修改各细分类描述信息，随意调整目录结构，至少支持7级以上分类目录设置，以保障标签体系建设的灵活扩展。 5.11.2.1 业务分类 标签体系规划建设的目标是为了支撑业务需要，因此标签目录应重点围绕业务分类进行设计，标签的分类应该是让用户易于理解，并且能够方便、快速地检索到所需标签。 以灾害事件主体为例，从业务分类来看，所有标签主体均能从基础特征、发展动态、关系特征和业务特征这四个维度进行细分。 其中业务特征又可再分为公共业务特征及各条线业务强关联业务特征，这样形成“4+N”分类。 针对应急事件的“4+N”标签目录分类，将有助于应急管理部门快速构建应急管理标签体系，且具有一定的扩展性和稳定性。在一级标签目录下，可以结合业务需求设计相应的子目录，为了避免目录层次过多导致难以检索，建议规划标签目录时不要超过三层，下面分别简要介绍这些标签目录分类。 基础特征主要包括事件名称、等级、事件描述、事件性质等基本信息，这些信息将以业务视角重新整合数据，构建完整的基础标签。 发展动态：描述标签主体的动态发展特征，是一个动态的特征，标签更新的频率较快，是从事件的发展动态研究方面出发，根据事件在不同时段的表现的发展态势所表现出来的发展特征，可包括变化趋势、影响范围、损失情况等。 关系特征：从事件的各种时空关系研究方面出发设计标签特征。例如相似事件、同地区事件、同时段事件等。 业务特征：从应急管理领域业务需求方面出发，根据事件在各个阶段表现的发展特点设计梳理标签。各条线业务特征是各业务部门面向具体应急管理实战分析挖掘应用而构建的特征标签，这些业务特征通常基于基础特征、发展动态、关系特征和公共业务特征来构建。 一般标签分类目录设计时可定义一级目录及部分二级目录，更详细的三级目录及部分二级目录应在梳理标签时结合标签情况而定。 5.11.2.2 管理分类 管理分类主要是面向标签的管理和运营，标识标签所属的组织、范围，实现标签共享和标签私有的统一管理，并能够辅助标签的运营。 管理分类：面向管理和运营，标识标签所属组织、范围，实现标签共享和私有的统一管理，并能够辅助标签目录的运营。例如，管理分类可以按照以下分类：1）按水平组织架构分类：如按照应急业务组织分类，可分为抗震标签、森林防火标签、水旱防治标签等。2）按标签权限分类：如按照标签使用权限，全局标签用于全部开放，适应于所有人员；私有标签适用于本部门、本业务所用。 例如，管理分类可以按照以下分类： 按水平组织架构分类：按照应急管理业务组织分类，如地震标签、安全生产监管标签、火灾防治标签等，快速应用于专题。 按标签权限分类：按照标签权限，如全局标签用于全部开放，适应于所有人员；私有标签适用于本部门、本业务业务部门所用。 除了上述组织及权限分类外，还可以按照标签热度分类，即按照标签使用的频率进行分类，可根据使用热度分为热门标签、未使用标签等。 5.11.2.3 技术分类 主要面向标签开发维护，从技术角度描述标签，方便标签进行规则定义和维护。技术分类可从标签值域、标签规则、标签生产方式、标签状态周期几个维度进行分类： 按标签值域分类； 有些标签只有是或否，例如是否特大安全生产事故；有些标签具有多个值，如火灾事故类别可以有一般火灾、较大火灾、重大火灾、特别重大火灾等多种取值。 按标签规则分类： 有些标签可以直接从数据库通过sql方式加工而成，有些标签可以通过其他标签采用不同的与或非等逻辑条件组合而成。 按标签生产方式分类： 标签可从统计得出，也可以从业务得出，根据标签生产方式可分为统计类标签、业务类标签等。 按标签状态周期分类： 根据标签更新频率，又可分为离线标签、在线标签，在线标签又可分为不同的周期，如按月或按天统计。 5.11.3 标签规则管理 标签规则主要是提供一种嵌入在应用程序的组件，实现了将数据标签的动态定义从应用程序代码中分离，并使用自定义表达式编写标签产生规则，同时接受数据的输入，通过规则动态解析，实现一个或者多个的数据标签输出。 通过构建标签引擎，实现对应急管理要素的快速分类与标识。支持标签元数据管理、标签规则管理、标签生命周期管理、标签计算、标签画像等功能。 5.11.3.1 标签元数据管理 标签元数据体系构建了标签的逻辑框架，体现标签的定义、统计、控制、意义、来源等。用户在使用标签数据时可以首先查看其元数据以便能够获取自己所需的信息，使标签的使用变得准确而高效。 通过将标签元数据可按照应急要素维度对标签进行定义，并按各维度要素的基础特征和业务场景进行标签分类，例如对灾害事故这个维度可按照事件类型和事件影响范围进行标签分类。 为了更好的与上层标签应用平台对接，系统还开放了标签元数据查询能力，元数据查询能力是上层标签应用基于标签画像平台开展业务的基础，支持查询的标签元数据包括： 业务类型：即标签主体，如人、企业、车辆等。 标签分类目录：即标签体系的树形目录，标签都按其属性归类与某个具体目录下，以便用户可以快速查找。 标签查询：查询某个标签目录下标签，或通过标签名称关键字模糊搜素标签，或查询指定标签的信息，返回的标签信息包括标签名称、标签ID、标签描述、标签生成周期、标签值类型、具备该标签的人员数量等。 标签值域查询：查询指定标签的取值列表。 画像配置查询：查询已配置的画像，及该画像包含的标签清单。 5.11.3.2 标签规则管理 标签规则是生成标签的依据，标签规则管理就是实现对标签规则的设计、创建与管理，对外提供统一的规则接口，对标签规则进行解析验证和加载执行。 标签规则设计 标签规则设计的核心是确定标签以及与标签相关的定义。标签规则设计应遵循业务需求，并结合数据对业务及流程进行深入了解，通过分析业务流程、理解业务需求、分析各个流程节点分析，最后梳理数据源的业务范围与数据完整度。在进行标签规则设计时主要考虑两个方面：一个方面是至上而下，看业务应用上需要什么标签；另一个方面是至下而上，看应急部内部相关系统存在哪些数据，根据这些数据可以提取出哪些标签，从这两个方面综合分析归纳出定义标签的规则。 在设计标签时，通常结合业务场景参考“5W2H”模型的思路，有效理清标签数据的属性，帮助标签的有效管理。 “5W2H”模型梳理标签方法思路如下： 1、WHAT：标签是什么？确定标签的名称、标签的值、以及该标签对应的维度，如时间、组织、区域等。 2、WHO：标签由谁控制？标签由哪些人员生产，由哪些人控制，可以给哪些人使用 3、WHY：为什么有该标签？标签的背景和意义是什么？ 4、WHERE：标签来自哪里？包括标签属于什么业务？标签属于哪个组织、来源于哪个数据源？ 5、WHEN：标签的失效期，有效期是多久？ 6、HOW TO DO：标签怎么统计？分别从业务口径和技术口径出发统计。业口径是从业务角度出发，可用于业务工作者的统计，例如跟标签用户有直接关系的消防人员，可以给消防装备打一个标签，比如“特种防护类装备”、“呼吸保护类装备”、“侦检器材”等；而技术口径可以是从技术角度出发，对于大数据算法师和技术工作者，标签可从数据技术操作层面进行处理，进行数据表字段级别的逻辑统计。 7、HOW MUCH：具备该标签特征的对象有多少？标签计算复杂度如何？对应的数据质量如何？ 通过上述梳理工作，明确项目中应实施的标签清单，然后按照标签的数据来源、标签值、标签类型、标签编码、创建类型、所需知识库、生成周期、刷新周期、标签值类型、计算表达式等维度来详细定义标签。 标签规则创建 标签规则配置支持基础标签、组合标签和智能标签的创建，并且可将外部标签导入到标签管理平台中进行统一存储和管理。其中基础标签的创建支持规则配置和SQL语句创建两种方式。规则配置是将已设置好的数据模型，拖、拽操作，设置多个属性的逻辑处理规则来创建标签。SQL语句创建是SQL方式配置的计算规则，主要用于复杂的数据处理规则定义。组合标签是基于多个已创建标签的逻辑规则组合方式来创建标签。智能标签是将在数据分析挖掘平台中配置好的模型工作流引入到标签管理平台中自动生成智能标签。 支持直接映射数据、条件匹配、公式计算等标签计算配置规则。 1）直接映射数据 支持通过自定义标签值、识别状态、事件状态、规则类型、对应的具体规则、匹配字段、特定转换函数、规则的有效时间和备注等信息来创建标签规则。 2）条件匹配 系统支持的条件匹配标签计算配置规则包括地理范围规则、数据范围规则、时间范围规则、库表比对规则等。 地理范围规则是通过在地图上绘制一系列多边形，实现地理范围内和地理范围外这两个规则，一旦事件的经纬度落入或者未落入规则定义的范围，则打上对应的标签。 数值范围规则是通过判断事件级别、事件伤亡人员或者损失量等是否落入该范围，来判断是否打上对应的标签。 时间范围规则是通过判断事件中的发生时间、入库时间等是否落入该事件范围内，一旦符合规则，则打上对应的标签。 库表比对规则是通过事件中的所涉及的应急要素，如危险源、救援人员、应急车辆或者安全生产企业，并基于平台的主题库或专题库，如应急资源库、救援人员库、应急车辆库或企业库进行比对，一旦这些要素属于这些数据库，则打上对应的标签。 3）公式计算 系统支持的公式计算标签计算配置规则包括逻辑表达式规则、符合标签规则等。 逻辑表达式规则是通过事件标题、内容是否符合规则所定义的逻辑表达式，来判断是否打上对应的标签。 复合标签规则是在基础的标签无法符合业务规则需求时，通过对多种标签进行逻辑计算形成标签的标签规则。 5.11.3.3 标签生命周期管理 主要实现标签整个生命周期全可视化管理。提供标签可视化编辑、标签创建任务执行策略设置、标签的注册审批等功能；支持对超过当前数据周期的标签数据进行更新操作；支持对标签使用情况进行统计，分析标签的使用频次。 5.11.3.4 标签计算 支持在线、离线标签计算，以便能够支持平台沉淀的大量历史数据的标签计算，也支持对实时流入的事件进行标签计算。 在线标签计算 在线标签计算主要是针对实时流数据进行标签标识； 离线标签计算 离线标签计算主要是针对已入库的数据进行离线计算，并进行标签识别。 5.11.3.5 标签画像 系统支持基于应急要素及其已有的标签构建该要素的画像，形成对要素的全方位、多角度、面向各业务场景的刻画与描述。并通过标签管理平台提供的对外服务接口提供标签画像的查询服务。 标签画像是多属性和标签组合，是针对某个应用场景设计的描述目标对象（人或事等）的重点关注的一系列特征标签，是该场景下对象的精确刻画，如：重点企业画像。通过画像特性可以协助应急管理领域针对不同应用场景而构建的定制化的对象画像，便于应用聚焦于其关注的特征标签或属性，从而节约时间和投资成本，同时也避免应用访问其他无关标签，防止数据无意泄露。 为了将标签作为一类资源服务提供给各业务部门，帮助应急管理业务人员挖掘出案事件所需要的潜在业务信息，对应急决策提供有价值的洞察和参考，为应急管理业务人员制定精准化决策提供支撑，标签画像平台将标签分析能力以API接口的形式开放给外部系统调用，实现标签画像平台与其他标签应用平台的对接。开放的标签画像分析能力包括： 标签碰撞分析 基于多标签为组合筛选条件，帮助应急管理业务人员快速定位符合特征条件的目标对象群体。标签筛选条件支持多标签的“与”、“或”、“非”的逻辑表达式判断。 统计分析 基于标签碰撞分析的目标对象群体，按指定标签维度统计该群体在不同标签值分类的数量。例如碰撞规则为“森林消防人员”，统计维度为“地区”时，平台将返回森林消防人员在不同地区分布的数量。该功能可用于对目标群体进行宏观态势分析。 画像查询 应用可以针对具体场景查询指定对象或群体的定制化画像，系统仅返回该场景下需要的标签信息，而不返回无关标签特征，使得应用可以聚焦于目标对象的重点特征而避免无意泄露其他特征信息。该功能可用于对目标对象进行进一步精细化研判。 5.11.4 标签地图 标签地图以树形结构展示标签分类目录，当选中某级目录时，显示目录下有查看权限的标签列表，再选中某标签时，可展示该标签的详细信息，包括：标签名称、标签创建者、标签创建部门、标签更新频次、标签使用说明、标签上线时间、标签星级、标签引用次数、查看次数、用户评论等信息 支持标签搜索功能，用户直接输入搜索字符即可，默认采用标签名称的搜索方式。 5.11.5 标签评论 用户对任意标签都可以发表评论，以及对任意标签都可以打分。分数在0－5分之间，以5分为满分。每个用户只能打分一次。 对标签的标签打分和评论、更新频次、标签引用次数、查看次数、用户评论进行展示。 5.11.6 智能标签服务 智能标签服务主要是利用标签工程引擎将标签的创建、查询、分析给服务化，是将标签作为一类资源服务提供给专业部门，帮助业务任务挖掘出事件所需要的潜在业务信息，对侦破分析提供有价值的洞察和参考，为应急管理人员制定精准化决策提供支撑。 标签服务将通过三种形式开放： 1)通用标签分析能力以API接口形式开放给外部系统调用，包含标签碰撞分析、画像查询、统计分析等。 2)开放自定义规则引擎供专业业务人员进行标签规则自定义，以生成个性化标签。提供可视化操作支撑服务，方便用户以拖拉拽的方式进行数据自助规则挖掘、规则建立、规则试跑、样本数据训练等操作。帮助用户进行个性化业务专题标签的建立。 3)标签元数据查询服务，支持查询的元数据包括标签名称、标签分类目录，标签编码等等。 5.12 知识图谱 知识图谱旨在通过建立数据之间的关联链接，将碎片化的数据有机的组织起来，让数据更加容易被人和机器理解和处理，并为搜索、挖掘、分析等提供便利，为人工智能的实现提供知识库基础。 5.12.1 知识图谱创建 知识图谱创建为构建知识图谱提供了基础支撑，提供事与事、事与人、事与组织等等之间的各种关系分析复现，提供深层次的研判洞察，为知识图谱构建提供了统一的入口，支撑用户构建自己的知识图谱。 系统提供元数据的统一视图，实现数据多源融合、关系排序、深度去重等深度治理。在数据深度治理基础上，对数据进行进一步加工，实现对象之间的关联关系构建、轨迹类数据构建，最终形成面向应急管理体系的知识图谱；知识图谱存储计算引擎采用分布式图数据库，可以支撑十亿级别的实体点和百亿级别关系边的关联分析。 知识图谱是将现实中的事物抽象成实体、关系、事件等三个基本的要素，用户可根据标准化的数据，对数据进行分析，分析出能够支撑知识图谱的实体，关系，事件。 系统提供本地标准化的数据模型的定制功能，用户可根据数据模型配置相应的数据处理逻辑，配置数据模型提供统一的图形化界面，然后统一调度数据转换程序。 处理后的数据，利用统一的调度工具，可统一加载到图数据库中。图谱数据的存储主要由上层业务应用、数据模型、数据体量、计算模型等因素决定，业务模型和数据模型适配选择图数据库、NoSQL数据库和索引数据库。 5.12.2 知识图谱库构建 知识图谱构建知识体系包括数据标准、数据元、标签、规则和业务模型等构建知识图谱所需的知识库。知识图谱的构建依赖于大数据资源中的主题库、专题库、知识库、知识图谱创建服务。 知识图谱库中内置搜索引擎，实现了基本的全文检索功能、高级检索、精确/模糊查询功能、字段归类组合查询功能、多维度表分类查询功能。主要为上层服务层提供基础服务和专题服务（隐性关系和事件）。如：人员基本信息，车辆基本信息，组织基本信息、人-事件关系、事件-资源关系，时空轨迹事件关系等。 5.12.3 知识图谱服务 知识图谱服务是基于知识图谱库构建的面向应用的基础服务，可提供完整的全文检索。主要为上层应用和外部系统提供关系查询、实体查询、事件查询等检索服务。 知识图谱服务利用友好的访问接口对图谱库的基本操作进行封装，可完成实体、关系、事件的在线查找、添加、更新、删除的能力。 5.12.3.1 知识图谱检索服务 知识图谱服务关系查询引擎在图谱库提供的快速图遍历功能基础上，支持从种子点出发的多跳关系查询、多点之间的关系推演（即关系路径查找：自动查找多个事件或物在一定步数内的关系路径，形成关系子网）、指定过滤条件的关系扩展等功能。关系推演能够实现事与事、事与人、事与组织等各种实体之间的关系发现。可以实现根据复杂过滤条件，围绕某事或某组织，不断发现联系的关系事件或关系组织的过程。 5.12.3.2 关联分析/图析服务 提供可视化数据关联分析，在数亿实体和数十亿的关系网中，实时进行关系挖掘、路径推演、事件比对、时空分析等，并通过可视化交互方式，有效发现和获取最有价值的数据。如基于图形化关系分析技术实现的机构图谱，为安全生产监管人员架起了与大数据交互的简便快捷手段。还可利用时间轴，从时间序列的维度对图谱进行分析，通过时间轴，直观展示关联关系网络及事件在时间维度的分布及统计情况，查看某特定时间段内后某时间上，某关系网络的发生情况以及其随时间变化的发展变化规律。 5.12.3.3 多维展示/全息档案服务 从应急管理指挥业务需求出发，基于应急管理数据资源池整合的各类数据资源，对各类人、事件、地、组织及其之间的关系背景资料建立完备的档案，如救援人员档案将人员及其所属组织作为整体进行综合呈现，主要包含人员基本信息、关系网络图、相关轨迹、地址信息及历史救援记录等。 5.12.3.4 地理展示和时空比对服务 结合轨迹分析算法以及部分关系战法，支持指挥人员对数据基于时间-空间的实体/事件/轨迹进行关联分析，时间分析有时间轴和动态时间卷轴，以及对接EGIS或主流开源地图，结合其地理信息数据提供多元多维度分析。 5.13 通用应用服务 5.13.1 统一机构管理 主要实现对单位内部组织机构和临时机构的统一管理，支持制定临时机构的编码规范。各分级管理员可在机构树里进行新增、修改、删除，同时支持机构合并功能。 5.13.2 统一用户管理 主要包括了应急管理用户管理、外部施工人员管理、个人信息管理，并提供用户数据批量导入功能。由管理员对应急管理用户、外部施工人员进行管理，个人信息管理由平台用户自己进行维护。支持按照用户的业务域管理机制。用户横向具有不同的业务域，纵向为用户的单位层级。不同业务域的管理员不能相互干涉。 5.13.3 统一权限管理 实现各业务系统的菜单资源和功能的使用权限统一在用户管理系统中设置，为各业务系统提供统一的权限授权管理，并能够对外提供权限信息服务接口。权限管理用于配置各应用系统的权限信息、应用接入，主要包括应用注册、应用资源同步、角色管理等功能。 5.13.4 统一身份认证 实现用户的统一身份认证，支持单点认证SSO（SingleSignOn）功能：即用户在一点登录后，在访问不同的业务应用时无需重复登录，做到一次登录，即可访问所有服务系统。平台门户接收用户的认证请求，将用户请求信息发送到统一认证平台，由统一认证平台为合法用户生成用户身份凭证，并将凭证反馈至平台门户，从而完成用户登录认证过程。 5.13.5 统一消息服务 提供统一的消息引擎，提供接口接收各应用推送的消息，通过消息队列的机制实现消息的生产及消费。需提供统一消息分类标准和统一消息接口规范。 统一消息服务为应急管理应用提供基础的消息服务，同时还可以在未来对其他新建应用提供强大的消息能力。统一消息服务利用多种消息渠道（短信、电话语音等）将各种通知、提醒内容及时的传达给用户，并对应用提供统一的消息发送接口。通过统一消息服务实现门户应用功能与消息发送功能的松散耦合，以实现更为全面的覆盖。 统一消息服务采用“服务集中、应用分散”的架构思路设计。服务核心应用放置在中心平台，供各本地应用系统调用。本平台融权限管理及各种通讯服务于一体，是一个包含信息查询、发布、通知、短信留言，工作人员状态查询等诸多功能的平台和应用系统。 统一消息服务包含以下功能： 信息多渠道发布：通过集成接口将其他应用系统的各种通知信息进行分类管理，便于管理人员通过指定渠道及时动态的使用。每一个应用系统都会有相关的信息需要按照不同的分类、以不同的形式、在不同的时刻通知到相关人员。 信息送达和反馈：根据多渠道通讯提示，可利用短信、平台操作等方式，确认信息已经收到，并对具体业务提供处理反馈信息。使用统一消息中心接收人可以直接回复手机短消息的提醒来确认接收到这些提醒信息，从而完成信息闭环确认的过程。 日志查询等服务：记录短信、语音等业务日志，方便查询明细，提供分类报表功能。 5.13.6 日志管理 日志管理是针对日志类数据的一站式服务，对用户登陆、退出、查询、新增、删除、修改等操作行为的日志进行详细记录，完成日志数据采集、消费、投递以及查询分析等功能，提升运维、运营效率及海量日志处理能力。 5.13.7 安全审计 安全审计将用户所有的操作日志集中记录管理和分析，不仅可以对用户行为进行监控，并且可以通过集中的审计数据进行分析，以便于事后的追责和认定。支持安全日志归档功能，管理员可以定期对日志文件按时段进行归档，在归档时生成归档文件。 5.13.8 数据治理门户 将所有数据治理的系统集成发布于门户中，实现单点登陆等便捷化操作，一键直达某一功能点，根据用户需求随时进行修改、调整内容。 5.14 资源目录 按照多维度、多渠道的服务建设模式，构建多点多活的统一服务资源目录，包括数据资源目录、服务接口资源目录、算法资源目录、模型资源目录、应用资源目录等，提供资源的查询、注册、申请、变更、停用、启用、同步等接口，用于实现资源共享与利用。 通过目录形式展示的方式，提供对平台现有资源成果的展示，使用户可以快速、直观地了解平台现有资源及成果，便于用户快速检索。 用户可以自定义地图目录结构，定义好目录结构后，可在地图浏览的图层控制中显示，从而实现个性化目录展示的功能。 5.14.1 元数据资源目录 对平台内的元数据和数据代码的进行统一的管理，提供注册、更新、启用、停用、注销等业务功能。 注册的数据项主要有元数据和数据代码的注册单位信息、应用范围、数据表示、名称、描述等信息，可以查询的字段信息、数据规模、数据更新情况等。 5.14.2 数据资源目录 构建数据资源目录，以原始库、资源库、主题库、专题库、配置库中的数据资源为管理对象，通过注册、更新、启用、停用、注销、查询等业务功能，形成标准的、规范的、统一的数据资源目录，促进数据资源科学、有序、安全的开放和共享。 5.14.3 标签资源目录 构建标签资源目录，通过标签资源目录实现对标签模板资源的共享开放与自定义。 注册的标签模板资源信息主要包括标签类别、标签编码、标签名称、标签资源摘要、标签输入数据项、所需知识库、计算表达式等信息。 通过统一资源管理模块提供标签资源的查询、注册、更新等功能。对于标签资源的汇聚分发除了标签本身模板信息外，还应该对这个标签所依赖的知识库进行汇聚分发。 5.14.4 算法资源目录 资源管理中心提供统计分析算法、聚类算法、分类算法、关系网络算法、文本分析算法、图像和音视频分析算法等通用算法。 同时资源管理中心可以通过算法资源目录，提供外部算法的注册功能，注册的信息包含算法基本信息、算法引用信息、算法描述信息、算法依赖环境信息、算法提供单位信息、算法运行包等。 5.14.5 模型资源目录 通过模型资源目录，提供自定义模型的注册，注册的信息包含模型基本信息、模型引用信息、模型描述信息、模型依赖环境信息、模型提供单位信息、XML模型标准描述等。通过统一资源管理模块提供模型模板资源的查询、注册、更新等功能。 5.14.6 服务接口资源目录 构建服务接口资源目录，包括平台的数据访问服务、业务服务。通过服务接口资源目录提供服务的注册、发现与使用。服务开发平台能够直接对接服务接口资源进行动态使用与查询调度。 注册的服务接口资源信息主要包括服务分类、服务提供方式、服务地址、服务版本、服务资源位置、服务系统名称、服务信息描述等。通过统一资源管理模块提供服务资源的查询、注册、更新等功能。 5.15 数据服务总线 建设数据服务总线，基于数据治理系统，将数据应用服务、数据支撑服务的注册、路由、适配等内容进行统一管理，实现应用开发、数据共享和业务协同的统一服务。互联网、电子政务外网、指挥信息网均需按域部署，与部署在各省的服务节点对接，用于部省联动。 5.15.1 服务注册 提供服务的集中注册功能。地方应急管理部门基于注册功能实现服务的创建和维护。 5.15.2 服务编排 提供服务的组合功能。地方应急管理部门基于服务编排功能，实现将已有的不同协议的服务进行组合，从而生成新的服务。 5.15.3 服务路由 提供服务的静态路由和智能路由功能。地方应急管理部门基于静态路由功能实现消息按预定的通道进行传输。地方应急管理部门基于动态路由功能实现消息传输时能够选择最优通道。 5.15.4 协议适配 提供协议适配功能。地方应急管理部门按照规定信息的格式和规则实现服务的适配接入。 5.15.5 事务管理 提供事务管理功能。地方应急管理部门基于事务管理实现事务的一致性和完整性。 5.15.6 服务监控 提供服务的监控功能。地方应急管理部门可以基于管理功能实现对系统运行情况和各种资源的状态信息进行监控，及时发现并定位系统中出现的异常情况。平台功能具体要求负偏离
负偏离? (-2分)?
基本满足要求
正偏离
2新增6.1 应用支撑技术指标 应用支撑应在服务能力、智能化、灵活性、可扩展性等方面达到以下要求： （1）满足业务系统整合与集成的能力需求； （2）提供WebService、Rest等通用协议服务，满足现有业务系统和新建业务系统的服务能力需求； （3）可兼容基于Java、Python等主流技术开发的引擎组件； （4）支撑第三方服务快速集成到应用支撑，实现服务能力传递共享； （5）支撑组件化、可插拔式的服务发布与管理； （6）充分利用大数据、人工智能等技术，实现组件引擎的智能化管理。 6.2 服务总线技术指标 服务总线应在服务能力范围、技术兼容性、灵活性等方面达到如下要求： （1）应用服务、数据服务等服务在服务总线进行统一管理； （2）应支持引入服务在本服务总线上进行注册和使用； （3）应支持Rest、SOAP、Hessian、FastInfoset等协议的服务注册； （4）应支持如报表、工作流、UI等工具的开发服务支撑； （5）应支持将应用组件、数据一键发布成服务的能力； （6）应能够展现各维度的服务使用情况。 6.3 数据治理门户技术指标 应在兼容性、可靠性、安全性、时效性等方面达到如下要求： （1）应全面支持业界的技术标准和技术规范，包括WSDL、SOAP、UDDI等； （2）应能够提供多种门户开放方式； （3）应能够具有完善的个性化服务； （4）应能够提供良好的通信机制； （5）统一门户应能满足用户访问应用的时效性要求，保证提供一致的、可预测的响应，在500并发数时平均延时应小于1秒。 6.4 身份管理系统技术指标 用户身份管理能力不少于10万条目、本地机构编码管理能力不少于1万条目、应用系统身份管理能力不少于150个、设备资源身份管理能力不少于2000台；双因素身份鉴别能力不低于300次/TPS（每秒事务处理能力）；日志存储不少于6个月。 6.5 密码管理系统技术指标 密码设备必须支持SM1/SM2/SM3/SM4密码算法。 6.6 数据治理系统技术指标 1.接入系统单台前置子系统结构化数据的接入性能不小于10MB每秒，非结构化小文件（小于1MB）接入性能不小于6MB每秒，非结构化大文件（大于1MB）的接入性能不小于30MB每秒。 2.单节点实时计算能力不低于5000条每秒，离线计算能力不低于30000条每秒，同时应满足1亿条数据计算的稳定性。 3.亿行级数据检索查询响应时间不大于3秒，支持最大在线用户数不少于300人，并发查询请求不小于30个。 4.单节点可满足500万次请求的稳定运行，单节点并发访问支持不小于50次每秒。技术指标负偏离
负偏离? (-2分)?
基本满足要求
正偏离
3新增投标人标前须到用户现场评估现有网络、系统、设备的情况，根据目前应急管理相关部门的实际情况，合理考虑系统的需求，对应用系统建设进行深化设计。在实施过程中所提供的软件如不能满足系统和业务的运行需求，投标人自行负责调整软件功能，满足业务需求。投标人需承担由此带来的一切费用。投标人投标时要一次性包含所有项目建设、迁移、实施和维护等费用。如果有任何附加的费用由中标人承担。投标人须提供承诺函加盖公章。 （1）自签订合同日起，2周内承建单位完成需求调研工作，形成需求文档（规格说明书或报告形式），并通过建设单位评审。 （2）自需求文档（规格说明书或报告形式）通过评审日起，2周内承建单位完成技术架构设计、应用原型设计，形成技术方案，并通过建设单位评审。 （3）自技术方案通过评审日起，1周内承建单位完成项目实施计划，并通过建设单位评审。 （4）自项目实施计划通过评审日起，45个自然天内承建单位完成所有项目开发。承建单位每周发布一版可工作软件版本到生产环境中供建设单位相关工作人员测试使用。 （5）承建单位每周提交一次项目报告，项目报告包括本周开发内容、下周开发计划、开发期间问题列表等内容；需要获得客户支持的事项形成问题报告及时与建设单位的项目主管部门或人员沟通，并将其进展记录在周报和月报中，汇报至建设单位的项目负责人及主管领导。 （6）在项目实施期内，承建单位派驻5名以上软件工程师驻建设单位现场开发；验收合格前，项目经理、需求经理不得更换，开发人员的更换不得超过2人次，并且如有人员变更必须提前1周告知建设单位，并将交接记录等内容交建设单位备案，经建设单位同意后变更人员方可离开。 （7）自项目功能验收完毕日起，1周内进入系统运维期,同时承建单位在1周内提供运维方案和计划。 （8）提供五年免费质保服务，自项目验收完毕日起，2年内保证原项目开发团队的3名以上软件工程师在现场进行系统维护和对所有需求变更进行免费开发和实施；项目经理和需求经理保持原有成员，不得更换；自项目验收完毕日起，第3至5年内提供驻本地的维护服务团队，提供所有组件及模块的二次开发与技术支持，免费开放接口，实现数据互通、业务协同；最少人数不能少于3人，原开发团队成员占维护服务团队的比例不能少于40%。 （9）执行过程中如无法达到实施要求，建设单位可随时终止合同，并追缴已支付所有款项。 （10）该要求最终解释权归建设单位。实施要求负偏离
负偏离? (-2分)?
基本满足要求
正偏离
4新增8.1服务质量要求 （1）软件平台提供7×24小时的连续运行，软件平均年故障时间小于2天，平均故障修复时间小于1小时。 （2）承建单位根据系统不同重要程度的维护等级保障，满足相应等级问题的响应时间。 系统重要程度定级表如下： ▲紧急事件：故障影响范围大，引起严重社会影响。 ▲高关注度事件：故障影响局限在所服务客户的本单位。对核心生产业务系统造成影响的，导致多数用户无法使用的问题。 ▲正常关注度事件：系统故障影响用户工作效率。 ▲低关注度事件：个别用户使用故障，使用不便或容易出现误操作。 不同级别问题响应时间如下： ▲紧急事件：响应时间0.5个小时，1小时内解决事件。 ▲高关注度事件：响应时间1个小时，6小时内解决事件。 ▲正常关注度事件：响应时间4个小时，1天内解决事件。 ▲低关注度事件：响应时间8个小时，2天内解决事件。 系统的定级等级由建设单位根据系统具体重要程度制定。 8.2 运维机构要求 承建单位应设有固定的运维机构，最少人数不能少于4人，且驻建设单位现场维护，其中运维经理至少1名、维护工程师至少3名。运维经理负责计划、统筹、协调整个系统的运维工作；运维工程师具有高级职称（或同等级别），负责具体解决日常工作中的各类运维问题；每天接听用户的各类咨询、故障报送电话。 运维机构应有相应系统的具体运维计划和运维记录。运维记录包括具体问题、解决方案、问题解决后的反馈情况。运维机构应能够随时提供运维记录以及相关运维问题统计表。 8.3 服务形式 （1）电话支持服务 应提供7×24小时电话技术支持服务。 （2）电子邮件回复服务 用户可以将遇到的问题随时通过电子邮件的方式提交给技术支持电子邮箱，并应于1个工作日内得到答复。 （3）远程诊断服务 应提供7×8小时的远程诊断服务。在征得用户同意的前提下，通过远程登录到用户系统环境，进行问题侦测和定位，提出解决方案，与用户交流并征得同意后，实施解决。 （4）现场支持服务 通过电话支持和远程诊断均无法解决时，维护服务中心应组织技术人员到用户现场解决。 8.4 服务期限 （1）承建单位需对影响系统稳定运行和应用效率的系统缺陷进行终身无偿修正。 （2）自项目验收完毕日起，2年内为所有业务需求的变动和新需求提供免费开发；5年内提供免费运维服务并为用户终端免费升级。 8.5 用户培训 （1）提供用户手册。 （2）提供系统运维手册及提供开发过程中的《需求规格说明书》、《项目计划》、《质量保证计划》、《概要设计》、《测试报告》，项目验收完毕后提供平台源代码及编译工具，源代码必须有注释。 （3）提供系统操作培训3次，培训费用由承建单位承担。 （4）系统维护培训1次，培训费用由承建单位承担。 （5）免费提供2人次以上（含2人次）系统维护所需基础技能培训。培训内容应包括系统的安装、使用、管理、性能维护、故障恢复等内容。 声明：如此部分内容与实施要求部分有不一致部分，以更利于建设单位的条款为准。服务要求负偏离
负偏离? (-2分)?
基本满足要求
正偏离
5新增1.提供对各单位的信息资源进行采集，包括：应急管理各转隶部门以及林业、交通运输、国土资源、地震、城管、消防、民政、气象等单位。 2.提供对各单位应急相关基础数据进行采集，危险源、防护目标数据等，地理信息等 3.提供对各单位应急资源数据进行采集，包括救援队伍信息、应急专家、应急救援物资装备信息等 4.提供对各单位实时监测监控数据进行采集，如气象信息、舆情信息等 5.提供对各单位应急相关业务数据进行采集，包括预案、案例、法律法规信息、安全生产监管的相关信息等 提供对各单位专业预测信息数据进行采集，如气象预测信息、地震预测预警信息等。信息资源规划-信息资源负偏离
负偏离? (-2分)?
基本满足要求
正偏离
6新增提供以要素为基础，将应急管理业务中可以进行信息化处理的数据进行分类，进行整理（按照应急管理部数据要素规范执行）。信息资源规划-信息要素规划负偏离
负偏离? (-2分)?
基本满足要求
正偏离
7新增根据应急管理厅的实际需要，梳理应急管理信息资源，规划应急管理元数据范围，编制完成标准《应急管理信息资源资源目录》信息资源规划-信息资源目录编制负偏离
负偏离? (-2分)?
基本满足要求
正偏离
8新增1.外部关联部门数据接入：提供对于林业、交通运输、国土资源、地震、城管、消防、民政、气象等外部相关部门业务系统数据可通过数据交换平台获取。 2.应急管理厅内部业务部门数据接入：提供对于黑龙江应急管理厅等应急管理厅内部业务部门的数据，可通过前置系统采用数据抽取、接口调用、消息服务的方式进行数据接入。 3.互联网公开数据接入：提供对于来自互联网以及社会企业的舆情数据可通过互联网单向传输设备接入到数据资源池 ★4.感知数据接入：提供对于来源于GPS与北斗定位及速度、方向等实时定位设备、各单位实时监测监控数据，可通过接口实时接入或定点接收的方式实现数据接入 5.其他数据接入：提供对于没有IT系统支撑的业务数据，还可采用人工填报，XLS表格导入的方式实现数据接入 6.数据探查：提供通过对来源数据存储位置、提供方式、总量和更新情况、业务含义、字段格式语义和取值分布、数据结构、数据质量等进行多维度探查，以达到认识数据的目的，为数据定义提供依据 #7.数据读取：提供从源系统抽取数据或从指定位置读取数据，检查数据是否与数据定义一致 8.数据对账：提供针对数据接入环节，对数据提供方和数据接入方在某一对账节点的完整性、一致性、正确性进行核对和检验的过程 #9.断点续传：提供基于消息的数据传输服务，从一个应用系统传输数据实体和数据格式到另一个应用系统，每个传输服务可以运行多个传输实体 #10.任务管理：提供对数据接入任务的管理，支持数据接入任务的创建、查询、删除等功能，并可指定接入任务所使用的抽取方法、转换规则和加载方式，并根据指定类型进行任务的调度执行 11.数据分发：提供将预处理后的数据按需分发到资源库、主题库、业务库，更新维护原始库，以及向请求方反馈数据数据接入负偏离
负偏离? (-2分)?
基本满足要求
正偏离
9新增★1.从前置库到原始库处理:提供通过数据接入系统接入到前置库中的数据，这些数据包括各业务系统中的结构化数据和非结构化数据，通过数据探查和数据提取等手段，对前置库的数据进行探查分析，提取出数据源信息，并将非结构化数据的关键文字信息如森林草原林火视频监控数据中的时间等提取出来，整个数据处理过程处理后的数据会落入原始库中 ★2.从原始库到资源库处理:原始库的数据经过数据比对、数据提取、数据关联、数据转换、数据清洗等处理过程，将数据加工成符合标准规范的数据。 ★3.从资源库到主题库处理:资源库的数据经过数据比对、数据关联、数据融合、数据标识的处理过程，将资源库的数据映射到灾害事故、管理对象、应急环境、救援资源、动态感知等信息分类中（按照应急管理部主题库组成得详细要求为标准），并详细对应到各信息分类中与森林防火相关的二级、三级主题库中 ★4从主题库到专题库处理:主题库的数据经过数据比对、数据关联、数据融合、数据表示的处理过程，将主题库中的数据提取出来，按照森林防火等应急管理工作专题库所需要的方式进行组织 5.数据探查-业务探查:对来源表的业务含义进行探查，以便能准确地理解和描述数据。 6.数据探查-接入方式探查:对来源表的存储位置、提供方式进行探查，为数据接入规则定义和数据处理、组织提供依据 7.数据探查-字段探查:对具体字段的数据内容进行探查，识别其代表的含义和统计分布情况 8.数据探查-数据元探查:根据字段名字及内容，探查字段的确切语义，并与数据元标准进行映射 9.数据探查-类型及格式探查:探查字段的类型及格式是否符合规范 10.数据探查-数据集探查:对来源数据集表名、引用数据元等进行探查，确定数据集是否是标准数据集 11.数据探查-问题数据探查:探查字段中不符合规范的数据，为后续数据清洗规则的制定提供依据 12.数据探查-数据推送:把数据探查的结果信息推送到数据清洗组件、数据转换组件以及元数据库中，为相关组件的规则制定，流程分发等提供必要的信息 13.数据提取-半结构化文件内容提取:主要针对存在于原始库中的半结构化数据，根据文件中的内容，提取出业务需要的数据内容。 14.数据提取-非结构化文件内容提取:主要针对存在于原始库中的非结构化数据，根据文件中的内容，提取出业务需要的数据内容。 ★15.数据清洗:提供对业务数据中不符合标准规范或者无效的数据进行相关操作 16.数据转换-数据命名转换:提供通过比对标准数据元和实际数据表中的数据项，如果比对结果一致，则不需要转换处理，如果比对结果不一致，要按照标准数据元中规定的命名进行转换 17.数据转换-数据类型转换:提供通过比对标准数据元和实际数据表中的数据项，如果比对结果一致，则不需要转换处理，如果比对结果不一致，要按照标准数据元中规定的数据类型进行转换 18.数据转换-数据编码转换:提供比对标准数据元和实际数据表中的数据项，如果比对结果一致，则不需要转换处理，如果比对结果不一致，需要按照标准数据元中规定的标准编码进行转换。 19.数据转换-数据标识转换:提供通过数据元和数据表字段的关联，根据关联关系自动生成可执行的转换规则，进行数据标识的转换 20.数据转换-标准地址转换:提供对地址要素不完整、文字表达不一致的地址信息进行标准化处理 21.数据关联-标准关联:提供在资源库中设计了标准的数据元体系，作为数据资源中心的数据规范基础 22.数据关联-数据字典、属性及相关含义的关联:提供如灾害等级与灾害类别关联、自然灾害和灾害地点关联、单位代码和单位名称关联、救援物资与物资类别关联等 23.数据关联-半结构化与结构化的关联:提供对半结构化数据进行提取结构化信息后，按照关键字（如灾害地点相同、灾害时间相同、灾害诱因相同）等进行关联，构建数据关联关系 #24.数据关联-关联回填:提供两个或两个以上数据集之间通过某种信息建立关联关系之后，根据实际业务的需要，可以对这两个数据集中的数据进行相互补充。 25.数据比对-数据项与标准数据元比对:实现原始数据表中的数据与标准数据元数据的比对，比对的内容包括数据命名、数据标识、数据格式、数据值域、数据编码、数据类型等数据的比对，数据比对的结果为一致或不一致。 26.数据比对-不同数据项集比对:提供实现两个数据项集的交集、补集，以满足数据检索的需求。 27.数据标识-基础标签标识:提供根据基础标签定义的规则，对数据进行规则筛选，符合规则的数据增添一列基础标签 28.数据标识-业务标签标识:提供按照业务数据模型管理数据，根据标签规则库提供的标签元数据信息，在资源库中找到标签所需的相关联的数据，根据规则进行合并、汇总等工作，得到的数据按照标签定义增加一列内容到目标数据中 29.数据标识-智能标签标识:提供根据标签规则库提供的模型接口，将相应的数据输入模型进行计算，将计算后的结果按照标签规则库定义的标签内容增加一列业务标签到目标数据中 30.数据融合-模型加工:主要包含数据合并、数据覆盖、数据切分功能，其中数据合并需要通过函数、分组或转列的方式完成数据的表合并和列合并。 31.数据融合-汇总加工:按照公共汇总的原则，明确哪些数据需要汇总合后，采用聚合函数或窗口函数等方式，完成对跨数据域且需要被频繁公用的数据的汇总。数据处理负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
10新增★1.应急管理数据库-原始库建设:提供包含应急管理单位内部、外部所有需要组织的数据 ★2.应急管理数据库-资源库建设:提供由原始库的数据经过清洗、转换、关联、比对等数据处理过程后形成的标准数据 ★3.应急管理数据库-主题库建设:提供按照应急管理信息要素将应急数据按灾害事故、救援物资与装备、组织机构、危险源等进行分类，为数据应用和产品提供公共数据服务 ★4.应急管理数据库-专题库建设:提供按照专题应用的需要重新整合形成的数据库。专题库的建库按照专题应用业务模型，通过二次抽取装载的方法重新组织数据，建立形成满足应急管理专题业务应用需要的数据库。 5,应急管理配置库-标签规则库建设-基础标签规则库:提供对数据的某一属性字段信息进行计算的处理规则，主要用于生成刻画灾害事故、管理对象、应急环境、救援资源等应急管理要素的基础特征的标签 6.应急管理配置库-标签规则库建设-业务标签规则库:提供基于应急管理人员的业务经验，对基础标签规则进行模型关联和逻辑计算，形成的固化知识标签生成规则 7.应急管理配置库-标签规则库建设-智能标签库:提供基于特征工程、机器学习算法，建立的智能标签模型集合。智能标签模型可用于从互联网信息、文档等大量信息中提取可直观展现对业务主观认识的标签。 8.应急管理配置库-知识库建设:主要包括：应急基本信息、应急速查手册、应急处置流程、应急案例信息、应急专家信息和应急法规政策等数据资源池负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
11新增1.数据基础访问服务:提供通过数据存储访问中间件，实现对平台内的源数据、业务数据等进行底层访问，包括文件系统以及针对数据库的DDL和DML操作的表服务，并实现数据库表的创建、查询、插入、更新、删除等透明操作 2.数据索引服务:提供数据资源的位置检索服务，通过统一的索引服务检索接口，根据所请求的要素值通过索引服务可以快速定位到资源的所在中心、所在省市、所在系统、所在库表信息等 #3.元数据访问服务:提供数据资源、服务资源的元数据查询访问能力，支持枚举数据资源、获取数据资源的元数据信息以及字段结构信息，包括对应的数据元信息等 ★4.数据字典服务:提供数据字典的查询、翻译接口，返回字典类别、字典项值等相应所需结果，实现数据字典查询或翻译 #5.数据授权服务:为用户分配各类系统功能权限和数据资源访问权限。在实际授权过程中，通过动态授权、鉴权管理等验证角色是否拥有访问数据的权限。 ★6.数据鉴权服务:对服务请求地向服务提供地发起各类服务请求时，服务提供地根据请求用户地市、角色对服务请求地进行身份鉴别、权限验证，对服务请求地用户发起的服务请求和用户（角色）权限进行验证。 ★7.数据接口服务-数据查询类服务:提供以预设或自定义的数据项为单一查询条件或组合查询条件，通过标准化的查询功能配置和服务接口调用，建立基于条件查询的分类分目查询功能和一键式查询功能，实现按要素分类查询或基于不确定关键字的一键式全网检索 ★8.数据接口服务-数据比对类服务:提供全量数据比对、增量数据比对等比对方式，实现比对时间和比对频次的自定义功能。 9.数据接口服务-数据订阅/推送类服务:提供主动向外部系统推送加工好的数据或分析成果，以便应用于实战、体现大数据价值。 10.数据接口服务-数据分析类服务:提供依托平台数据分析类工具，提供包括历史事件分析、灾害事故发展态势模拟推演、事故风险分析等综合分析服务 11.数据接口服务-动态数据获取服务:提供协助用户在线调取实时气象、现场视频等智能感知数据 12.数据可视化服务-可视化组件服务:提供多维透视图组件主要提供各种常用可视化图表组件 13.数据可视化服务-数据治理可视化-数据治理概况:提供从宏观角度展示数据治理的成效与存在的问题，对数据治理总量、不同类型数据治理量、不同来源系统数据治理量、不同业务类型的数据治理量进行分析展示 14.数据可视化服务-数据治理可视化-数据质量可视化:提供直观掌握当前数据的治理情况，对已接入数据总量、已完成治理数据量、未完成治理数据量、数据治理完成比、有问题数据数量、数据质量问题原因统计等 15.数据可视化服务-数据治理可视化-数据接入可视化:提供通过统计接入数据、接入系统信息，分析展示信息包括接入数据总条数、当日数据增加条数、月度数据接入条数变化趋势、接入数据总量、当日数据增量、月度数据接入量变化趋势、接入数据类型统计、接入数据网络分布等，直观展示数据接入情况 16.数据可视化服务-数据治理可视化-数据处理可视化:提供数据处理可视化分析主题统计已处理数据情况及数据处理的各个步骤情况，分析展示内容包括数据提取、数据清洗、数据关联、数据比对、数据融合、数据标识等处理概况 17.数据可视化服务-数据治理可视化-数据管控可视化:提供数据标准、元数据、数据资产、数据资源目录、数据运维等维度 18.数据可视化服务-数据治理可视化-数据资源可视化:提供对各类数据资源情况进行可视化分析 19.数据可视化服务-数据治理可视化-数据应用情况可视化:通过查询检索、数据获取、数据订阅、智能档案、智能标签等可视化分析 20、生产库：省厅所需所有生产库得全流程管理，为业务应用提供数据服务，及时为业务应用通过数据流进行指导。 21、所有工具为满足所有数据需要而进行服务，且所有针对数据的操作及处理等所有流程均包含于该项目中。不得额外收取费用。数据服务负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
12新增数据管控1.数据标准管理-标准浏览：提供基于标准梳理结果，对数据标准和标准落地进行全方位的信息展现，并可通过页面超链接的方式，对标准主题和公共代码之间的引用关系，以及标准到业务源系统落地情况进行灵活导航，方便用户快速地了解到标准间依赖关系、标准落地情况 2.数据标准管理-基础主题标准维护：提供对已梳理基础主题数据标准的管理维护功能，包括修改、提交、审核、发布等基础维护功能 3.数据标准管理-指标标准维护：提供数据标准定义的维护、维度定义的维护、维值代码定义的维护、公共统计规则的维护 4.元数据管理-元数据分类：提供按照元数据的定义分类，综合价值分析系统元数据管理分为业务元数据、技术元数据二类 5.元数据管理-元数据自动获取：提供对元数据获取数据源以及这些数据源之间的关系进行集中登记管理，并形成自动获取数据源的全局视图，实现元数据自动获取数据信息 ★6.元数据管理-元数据维护：提供元数据的定义、变更及版本管理，对主机信息、数据库信息、用户信息、数据对象信息、业务规则信息、加工逻辑等进行维护和管控 7.元数据管理-元数据扫描：提供以手动或定时的方式扫描指定的数据库资源，并提取和解析相关的信息在比较扫描数据和原有数据的差异后自动将差异数据维护到指定的元数据目录 8.元数据管理-元数据检索：提供全文检索的方式迅速查找和关键字匹配的权限范围内的元数据信息 9.元数据管理-元数据地图：提供快速动态生成全局元数据地图，方便用户快速全面查阅所有元数据平台中各类信息，支持逐层钻取查看下级数据资产详情以及数据加工关系脉络 10.元数据管理-元数据版本：主要包括元数据对象版本管理与基线版本管理两种类型 11.元数据管理-权限管理及查询：提供统一实现数据库的访问和操作管控，对用户进行角色权限、对象权限、数据权限等方面的管控和查询 #12.元数据管理-元数据的导入/导出：提供在系统层面实现元数据的导入/导出功能，以保证数据模型、数据对象能够灵活的迁移，支持模型间的检查和比对，以便于数据模型的维护和扩展 13.元数据分析-影响性分析：提供包括血统分析和影响分析两类，以便于掌握和追溯对象变更时的缘由和影响关系。 14.元数据分析-重要性分析：提供分析各元数据对象之间的关联密集度，分析数据仓库中各层次的包、表等对象的重要程度，指导数据仓库开发和维护团队对重点元数据进行重点关注和质量监控 15.元数据分析-无关性分析：提供对一定数量的无关数据、信息和报表进行分析 ★16.资源目录管理-资源分类与编目：按照数据资源目录标准规范，对大数据平台存储的数据资源和通过接口方式提供大数据平台使用的数据资源进行梳理，并赋予唯一的目录标识符和编码 17.资源目录管理-目录注册与注销：由资源所属单位在本地大数据平台的数据资源目录管理模块中填写数据资源目录信息，审核、审批通过后完成注册。支持资源分级分类配置，支持批量模板导入；当数据资源暂时失效时，停用相关数据资源目录 #18.资源目录管理-资源目录更新：提供当数据资源发生变化时，对资源目录进行更新 #19.资源目录管理-资源目录同步：提供当本地数据资源目录发生变化时，下级目录需向上级目录进行汇聚，上级目录需向下级目录分发 ★20.资源目录管理-资源目录服务：提供用户按照权限查看数据资源目录，支持根据数据资源目录相关属性和数据项进行数据资源的查询。 #21.数据鉴权管理：提供基于数据的访问控制规则结合数据分级分类，实现数据的访问权限鉴别的过程 22.数据质量管理-数据处理过程监控：提供监控数据处理任务执行的情况，包括是否按时调度，是否成功等状态消息。 23.数据质量管理-数据稽核：提供对ETL整个流程的数据质量进行稽核，主要分为数据来源环节和数据加工环节，包括：数据来源稽核、数据加工环节稽核 24.数据质量管理-问题管理：提供质量问题的创建、发布，以及处理过程的跟踪，为数据校验提供解决、跟踪平台。 25.数据质量管理-日志管理：包括规则运行日志、告警日志、过程执行日志，为用户提供规则运行的最终稽核状态和历史稽核状态日志，以及除数据本身的异常外的异常监控和各层过程的执行日志的监控 26.数据质量管理-质量报告：对稽核功能模块和问题管理模块做整体的统计分析，包括三类报告：总量评估报告、数据源的质量评估报告、专项数据质量问题评估报告 27.数据质量管理-质量问题处理：包括：问题分析、数据隔离、数据维护、过程总结 28.数据运维管理-运维规则配置管理：提供对数据运维的实时监测、日志采集、日志统计分析、报表展示、日志输出、预警阈值、预警规则和信息、数据对账等相关规则进行配置管理 29.数据运维管理-数据实时状态采集：提供对来源数据以及接入、提取、清洗、关联、比对、标识、分发、入库等环节设置监控点，进行多维度信息的实时采集。 30.数据运维管理-数据运行状态监控：提供对来源数据的监控（通道是否连通、数据是否更新等），数据接入及处理状态的监控、统计（运行是否正常、数据流量情况等），数据积压监测及统计，数据心跳图，数据入库异常统计、当日或指定时间周期内各类数据的增量及存量监控、数据服务接口监控等 31.数据运维管理-数据运维报表：提供对系统的数据资源总体情况、分类情况、上报下发情况等多种维度进行统计分析。 32.数据运维管理-数据预警管理：提供当出现实时流监控异常、运行状态异常、数据质量异常、数据备份异常等状况时，触发告警，告警结果可以通过消息、服务、邮件、短信等方式推送给运维系统或运维人员。 33.数据运维管理-数据运维日志审计：提供对所有数据运维工作的操作日志进行全方位、全流程安全性审计 34.数据血缘管理-血缘关系管理：记录上下游数据资源编码、数据项编码和数据资源转换规则等数据血缘信息，并实现动态更新。 35.数据血缘管理-数据血缘关系分析：数据从源到目的地，经过大量的功能模块的处理和传递，呈现在业务用户面前，分析数据的来龙去脉。 36.数据血缘管理-血缘关系应用：提供基于数据血缘信息，进行相关的元数据应用分析如溯源分析、影响分析、重要程度分析和数据时效性分析等。 #37.数据分级分类-数据分级：提供通过对数据内容的敏感程度，对数据资源进行分级。数据分级包括数据分级管理、用户分级管理和系统分级管理三个方面。 #38.数据分级分类-数据分类：提供通过数据融合后的种类进行分类。应急数据融合之后将数据分为原始库、资源库、主题库、专题库。数据管控负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
13新增数据共享交换★1.服务共享管理-服务目录:提供适应应急业务特征的服务目录框架，根据业务特征，服务目录框架包括查询类服务、比对类服务、统计类服务及其他类服务。 #2.服务共享管理-服务注册:提供对后台已注入的服务注册/发布至服务中心，并可对服务中心里的服务进行查询、查看、修改注册信息、上线等操作功能。 #3.服务共享管理-服务申请:提供通过统一的服务资源目录查看并申请个人所需的服务。 #4.服务共享管理-服务发布:提供对审核通过的服务进行服务发布，对正式发布的服务可以提供使用者进行服务的查询。 5.服务共享管理-服务订阅:提供对于暂未发布/不存在的服务，系统提供统一订阅申请的功能模块，为各服务申请单位提供统一服务订阅入口，统一管理。 #6.服务共享管理-服务审核:提供服务申请单提交后，具备审核权限的用户可通过工作台查看待审核的服务申请单，并进行相关的审核操作。 7.服务共享管理-通用服务接口:提供通用数据服务接口是给其他模块或者系统使用的一种约定或者规范，接口设计应遵循统一接口规范，保证接口性能良好。 8.共享交换管理-数据交换管理:主要实现：数据交换管理、数据交换服务、共享资源配置、交换中间库建设 9.共享交换管理-数据交换服务:提供共享域内交换节点之间的数据共享交换服务，包括采集、分发、汇总和转发。 10.共享交换管理-共享资源配置:提供对需要进行共享的数据资源进行配置，包括数据源、数据库链接、数据表配置、共享数据项目配置等，对共享资源的配置提供修改、查询和删除等日常管理功能。 ★11.共享交换管理-交换中间库建设:提供数据采集过程中源端到目标端经交换平台产生的交换数据，包括数据交换目录及交换数据库。 ★12.数据对接服务:提供基于消息的数据传输服务。从一个应用系统传输数据实体和数据格式到另一个应用系统，每个传输服务可以运行多个传输实体。数据共享交换负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
14新增算法模型★1.提供原厂售后服务承诺函盖章原件和授权书盖章原件。 ★2.算法工程-算法管理：提供算法包注册、修改、删除、启动、停用、查询、评价等全生命周期管理，用户可以将算法名称、算法描述、支持运行的平台（内存计算，离线计算，图计算等）、算法类型（基础算子、机器学习算法、业务算法等）、算法执行包、算法参数集、开发语言、开发厂商、提交单位等信息注册到算法平台。 #3.算法工程-算法组件：提供包含了基础算子、统计分析、数据预处理、特征工程、机器学习、文本分析、网络分析等算法组件。 ★4.算法工程-算法库：依托大量算法工程师对平台算法进行优化和设计，建设涵盖统计分析、特征工程、文本分析、机器学习、网络分析、深度学习等多个领域的算法库，为平台提供各类算法支撑。 #5.模型工程-模型创建：用户通过多种建模方式创建基于应急管理模型标准的模型，部署到模型运行引擎上面配置模型参数，模型运行引擎会对模型运行的合法性进行验证，包括是否符合模型标准，数据资源是否有访问权限，算法参数是否合法，模型编排是否合理等。 6.模型工程-模型分析：提供趋势分析、异常分析、相关性分析等元模型分析功能以及统计分析算法、聚类算法、分析算法等算法的运行分析。 7.模型工程-模型管理：提供模型的注册、修改、删除、查询、评价、分享、生命周期、质量、导入导出能功能。 8.模型管理-模型任务管理：模型任务是对已编排好的模型进行实例化执行的过程。模型实例化主要包括：任务类型、输入参数实例化、执行周期实例化、输出结果实例化等 9.模型管理-模型数据集管理：模型数据集包含模型输入数据、模型输出数据、模型中间结果。 10.模型管理-元模型管理：对元模型进行管理维护、并能能够进行物理模型创建。 11.模型管理-模型资源管理：数据资源是面向使用者的，应能对模型使用的资源配额进行管理，用于对外共享交换，是实现对外共享交换的最大单元。算法模型负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
15新增工具引擎★1.通用工具-可视化工具:通过可视化方式对原始数据、标准化数据、资源库数据、专题库数据等进行多源数据组织分析，对可视化主题分析提供应用支撑，支持钻取分析、联动分析、跳转分析、多表关联、追加合并、聚合分析、SQL创建、字段编辑等功能。 2.通用工具-智能查询工具-资源搜索:通过指定搜索条件、指定搜索范围对数据进行搜索，以资源列表形式展示搜索结果，其中搜索条件、搜索范围包括数据来源、有效时间、数据表范围等 #3.通用工具-智能查询工具-全文检索:提供针对系统的文件信息的数据检索功能。 4.通用工具-智能查询工具-专题搜索:提供用户在某一专题下进行目标搜索，支持逻辑运算组合检索、通配符检索、模糊音检索、时间段检索、地理区域段检索 #5.业务流程引擎-中间件-流程引擎:提供对流程模型和数据模型进行管理，按照业务控制流的定义进行执行 6.业务流程引擎-中间件-规则引擎:提供对整个业务流程节点及路由的控制规则及业务集成规则进行定义并解析和运行的智能引擎 7.业务流程引擎-中间件-业务全引擎:提供系统的权限及关键数据的监控和记录工作，当用户试图进行一个业务操作时业务全引擎首先会对用户的权限进行监控，如果没有权限则阻止用户操作并且记录日志和发出预警 8.业务流程引擎-基础服务组件-工具集:提供为业务流程引擎提供的一系列方便管理人员、业务人员以及开发人员进行流程模型定义、管理和分析的可视化工具。 9.业务流程引擎-基础服务组件-业务流程模型:提供根据业务应用中的业务流转需求，利用流程建模工具、规则建模工具、数据建模工具对业务流程进行抽象定义，形成一个通用的业务流程模型 #10.工作流引擎:主要包括核心引擎、核心API、工作流等功能。 #11.搜索引擎:提供快捷的搜索引擎功能，通过搜索方式帮助用户快捷浏览需要的公文、知识、业务数据、政策法规、办事流程、政务、日常办公、项目资料、资金财务等各个方面的信息资源，并在搜索结果中显示关键词上下文，让用户快速准确的查找到公文 #12.表单引擎:提供基础支撑平台建设提供强大的表单引擎，让用户自由定制各类业务流中的表单，确保流程完全符合应急管理综合应用平台系统的实际运行状况。工具引擎★1.通用工具-可视化工具:通过可视化方式对原始数据、标准化数据、资源库数据、专题库数据等进行多源数据组织分析，对可视化主题分析提供应用支撑，支持钻取分析、联动分析、跳转分析、多表关联、追加合并、聚合分析、SQL创建、字段编辑等功能。 2.通用工具-智能查询工具-资源搜索:通过指定搜索条件、指定搜索范围对数据进行搜索，以资源列表形式展示搜索结果，其中搜索条件、搜索范围包括数据来源、有效时间、数据表范围等 #3.通用工具-智能查询工具-全文检索:提供针对系统的文件信息的数据检索功能。 4.通用工具-智能查询工具-专题搜索:提供用户在某一专题下进行目标搜索，支持逻辑运算组合检索、通配符检索、模糊音检索、时间段检索、地理区域段检索 #5.业务流程引擎-中间件-流程引擎:提供对流程模型和数据模型进行管理，按照业务控制流的定义进行执行 6.业务流程引擎-中间件-规则引擎:提供对整个业务流程节点及路由的控制规则及业务集成规则进行定义并解析和运行的智能引擎 7.业务流程引擎-中间件-业务全引擎:提供系统的权限及关键数据的监控和记录工作，当用户试图进行一个业务操作时业务全引擎首先会对用户的权限进行监控，如果没有权限则阻止用户操作并且记录日志和发出预警 8.业务流程引擎-基础服务组件-工具集:提供为业务流程引擎提供的一系列方便管理人员、业务人员以及开发人员进行流程模型定义、管理和分析的可视化工具。 9.业务流程引擎-基础服务组件-业务流程模型:提供根据业务应用中的业务流转需求，利用流程建模工具、规则建模工具、数据建模工具对业务流程进行抽象定义，形成一个通用的业务流程模型 #10.工作流引擎:主要包括核心引擎、核心API、工作流等功能。 #11.搜索引擎:提供快捷的搜索引擎功能，通过搜索方式帮助用户快捷浏览需要的公文、知识、业务数据、政策法规、办事流程、政务、日常办公、项目资料、资金财务等各个方面的信息资源，并在搜索结果中显示关键词上下文，让用户快速准确的查找到公文 #12.表单引擎:提供基础支撑平台建设提供强大的表单引擎，让用户自由定制各类业务流中的表单，确保流程完全符合应急管理综合应用平台系统的实际运行状况。工具引擎负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
16新增标签工程★1.提供原厂售后服务承诺函盖章原件和授权书盖章原件。 2.标签体系管理-标签主体管理：针对应急管理领域，应急标签主体的选择将使用“人、地、事、物、组织”等应急要素分类中的主数据，从这些应急要素中挑选出有唯一标识的，对应急管理有影响能力的主体。 ★3.标签体系管理-标签目录管理：提供配置和维护标签主题对象和标签分类目录功能。可创建任意的标签主题对象类型，如：人、地、事、物、组织等，如果主题对象已创建有标签，则不能删除。 #4.标签体系管理-标签管理：提供标签需求分析、标签专题数据预加工（归集、清洗、标准化、整合）、标签数据同步、标签创建和标签计算等功能 #5.标签分类管理-业务分类：提供为了支撑业务需要，因此标签目录应重点围绕业务分类进行设计，标签的分类应该是让用户易于理解，并且能够方便、快速地检索到所需标签 6.标签分类管理-管理分类：提供面向标签的管理和运营，标识标签所属的组织、范围，实现标签共享和标签私有的统一管理，并能够辅助标签的运营。 7.标签分类管理-技术分类：提供面向标签开发维护，从技术角度描述标签，方便标签进行规则定义和维护。技术分类可从标签值域、标签规则、标签生产方式、标签状态周期几个维度进行分类 8.标签规则管理-标签元数据管理：标签元数据体系构建了标签的逻辑框架，体现标签的定义、统计、控制、意义、来源等。用户在使用标签数据时可以首先查看其元数据以便能够获取自己所需的信息，使标签的使用变得准确而高效。 #9.标签规则管理-标签规则管理：提供生成标签的依据，标签规则管理就是实现对标签规则的设计、创建与管理，对外提供统一的规则接口，对标签规则进行解析验证和加载执行。 10.标签规则管理-标签生命周期管理：提供标签可视化编辑、标签创建任务执行策略设置、标签的注册审批等功能；支持对超过当前数据周期的标签数据进行更新操作；支持对标签使用情况进行统计，分析标签的使用频次。 #11.标签规则管理-标签计算：提供在线、离线标签计算，以便能够支持平台沉淀的大量历史数据的标签计算，也支持对实时流入的事件进行标签计算 12.标签规则管理-标签画像:提供基于应急管理部规范的应急要素及其已有的标签构建该要素的画像，形成对要素的全方位、多角度、面向各业务场景的刻画与描述。 13.标签地图:提供以树形结构展示标签分类目录，当选中某级目录时，显示目录下有查看权限的标签列表，再选中某标签时，可展示该标签的详细信息 14.标签评论:提供对任意标签都可以发表评论，以及对任意标签都可以打分 15.智能标签服务:提供利用标签工程引擎将标签的创建、查询、分析给服务化，是将标签作为一类资源服务提供给专业部门，帮助业务任务挖掘出事件所需要的潜在业务信息，对侦破分析提供有价值的洞察和参考，为应急管理人员制定精准化决策提供支撑。标签工程负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
17新增知识图谱及通用服务★1.提供原厂售后服务承诺函盖章原件和授权书盖章原件。 ★2.知识图谱创建：提供为构建知识图谱提供了基础支撑，提供事与事、事与人、事与组织等等之间的各种关系分析复现，提供深层次的研判洞察，为知识图谱构建提供了统一的入口，支撑用户构建自己的知识图谱。 #3.知识图谱库构建：提供构建知识体系包括数据标准、数据元、标签、规则和业务模型等构建知识图谱所需的知识库。 4.知识图谱服务-知识图谱检索服务:提供知识图谱服务关系查询引擎在图谱库提供的快速图遍历功能基础上，支持从种子点出发的多跳关系查询、多点之间的关系推演（即关系路径查找 5.知识图谱服务-关联分析/图析服务:提供可视化数据关联分析，在数亿实体和数十亿的关系网中，实时进行关系挖掘、路径推演、事件比对、时空分析等，并通过可视化交互方式，有效发现和获取最有价值的数据。 6.知识图谱服务-多维展示/全息档案服务:提供基于应急管理数据资源池整合的各类数据资源，对各类应急管理部规范的各要素之间的关系背景资料建立完备的档案，如救援人员档案将人员及其所属组织作为整体进行综合呈现，主要包含人员基本信息、关系网络图、相关轨迹、地址信息及历史救援记录等 7.知识图谱服务-地理展示和时空比对服务:提供结合轨迹分析算法以及部分关系战法，支持指挥人员对数据基于时间-空间的实体/事件/轨迹进行关联分析，时间分析有时间轴和动态时间卷轴，以及对接EGIS或主流开源地图，结合其地理信息数据提供多元多维度分析 8.通用应用服务-统一机构管理:主要实现对单位内部组织机构和临时机构的统一管理，支持制定临时机构的编码规范。各分级管理员可在机构树里进行新增、修改、删除，同时支持机构合并功能。 9.通用应用服务-统一用户管理:主要包括了应急管理用户管理、外部施工人员管理、个人信息管理，并提供用户数据批量导入功能。由管理员对应急管理用户、外部施工人员进行管理，个人信息管理由平台用户自己进行维护。支持按照用户的业务域管理机制。用户横向具有不同的业务域，纵向为用户的单位层级。不同业务域的管理员不能相互干涉。 10.通用应用服务-统一权限管理:实现各业务系统的菜单资源和功能的使用权限统一在用户管理系统中设置，为各业务系统提供统一的权限授权管理，并能够对外提供权限信息服务接口。权限管理用于配置各应用系统的权限信息、应用接入，主要包括应用注册、应用资源同步、角色管理等功能。 11.通用应用服务-统一身份认证：实现用户的统一身份认证，支持单点认证功能：即用户在一点登录后，在访问不同的业务应用时无需重复登录，做到一次登录，即可访问所有服务系统。平台门户接收用户的认证请求，将用户请求信息发送到统一认证平台，由统一认证平台为合法用户生成用户身份凭证，并将凭证反馈至平台门户，从而完成用户登录认证过程。 12.通用应用服务-统一消息服务：提供统一的消息引擎，提供接口接收各应用推送的消息，通过消息队列的机制实现消息的生产及消费。 13.通用应用服务-日志管理：日志管理是针对日志类数据的一站式服务，对用户登陆、退出、查询、新增、删除、修改等操作行为的日志进行详细记录，完成日志数据采集、消费、投递以及查询分析等功能，提升运维、运营效率及海量日志处理能力。 14.通用应用服务-安全审计 ：安全审计将用户所有的操作日志集中记录管理和分析，不仅可以对用户行为进行监控，并且可以通过集中的审计数据进行分析，以便于事后的追责和认定。支持安全日志归档功能，管理员可以定期对日志文件按时段进行归档，在归档时生成归档文件。 15.通用应用服务-数据治理门户： 提供数据治理门户实现各数据治理业务的统一展示、登陆、管理、运维等全部内容，并按照用户需求进行界面修改及功能实现知识图谱及通用服务负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
18新增资源目录★1.元数据资源目录:对平台内的元数据和数据代码的进行统一的管理，提供注册、更新、启用、停用、注销等业务功能。 ★2.数据资源目录:构建数据资源目录，以原始库、资源库、主题库、专题库、配置库中的数据资源为管理对象，通过注册、更新、启用、停用、注销、查询等业务功能，形成标准的、规范的、统一的数据资源目录，促进数据资源科学、有序、安全的开放和共享。 3.标签资源目录:构建标签资源目录，通过标签资源目录实现对标签模板资源的共享开放与自定义。注册的标签模板资源信息主要包括标签类别、标签编码、标签名称、标签资源摘要、标签输入数据项、所需知识库、计算表达式等信息。 #4.算法资源目录:资源管理中心提供统计分析算法、聚类算法、分类算法、关系网络算法、文本分析算法、图像和音视频分析算法等通用算法。 #5.模型资源目录:通过模型资源目录，提供自定义模型的注册，注册的信息包含模型基本信息、模型引用信息、模型描述信息、模型依赖环境信息、模型提供单位信息、XML模型标准描述等。 ★6.服务接口资源目录 :构建服务接口资源目录，包括平台的数据访问服务、业务服务。通过服务接口资源目录提供服务的注册、发现与使用。资源目录负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
19新增服务总线★1.服务注册:提供服务的集中注册功能。地方应急管理部门基于注册功能实现服务的创建和维护。 2.服务编排:提供服务的组合功能。地方应急管理部门基于服务编排功能，实现将已有的不同协议的服务进行组合，从而生成新的服务。 3.服务路由:提供服务的静态路由和智能路由功能。地方应急管理部门基于静态路由功能实现消息按预定的通道进行传输。 4.协议适配:提供协议适配功能。地方应急管理部门按照规定信息的格式和规则实现服务的适配接入。 5.事务管理:提供事务管理功能。地方应急管理部门基于事务管理实现事务的一致性和完整性。 6.服务监控:提供服务的监控功能。地方应急管理部门可以基于管理功能实现对系统运行情况和各种资源的状态信息进行监控，及时发现并定位系统中出现的异常情况。服务总线负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
20新增大数据平台★1.提供原厂售后服务承诺函盖章原件和授权书盖章原件。 ★2.提供高级版许可以及5年软件订阅与保障年费所有节点 ★3.平台组件：sqoop,storm，hdfs,hbase,flume,elasticSearch,kafka,hive,spark,sparkStreaming,yarn,Mepreduce,Redis等所有Hadoop生态组件。 4.数据集成-批量数据集成：实现大数据平台与关系型数据库、文件系统之间交换“数据”、“文件”，既可以将数据从关系型数据库或者文件服务器导入到HDFS/HBase中，同时也支持反过来从HDFS/HBase导出到关系型数据库或者文件服务器中。 5.数据集成-实时集成：利用Apache Flume监听特定的端口（UDP、RPC端口），从而获得流过端口的数据，并且支持多样化的插件体系，在收集端对数据进行过滤等处理，在汇聚端则允许将数据直接输入到大数据分布式存储HDFS。 #6.数据集成-分布式消息队列：利用kafka进行常规的消息收集、网站活性跟踪、聚合统计系统运营数据（监控数据）、日志收集等大量数据的互联网服务的数据收集。 #7.数据存储-分布式文件存储：HDFS是Hadoop的分布式文件系统，实现大规模数据可靠的分布式读写。HDFS分布式文件存储采用可扩展的系统结构，提供了海量数据的分布式存储。 #8.数据存储-分布式数据库：HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。 HBase适合于存储大表数据（表的规模可以达到数十亿行以及数百万列），并且对大表数据的读、写访问可以达到实时级别。 #9.数据存储-分布式数据仓库：Hive是建立在Hadoop上的数据仓库框架，提供大数据平台批处理计算能力，能够对结构化/半结构化数据进行批量分析汇总完成数据计算。 10.数据存储-内存数据库：Redis是基于网络的，高性能的key-value数据库，弥补了memcached这类key-value存储的不足，在部分场合可以对关系数据库起到很好的补充作用，满足实时的高并发需求。 #11.数据存储-全文检索库：ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。 #12.数据计算-离线计算能力：离线处理，通常是指对海量数据进分析和处理，形成结果数据，供下一步数据应用使用的场景。离线处理对处理时间要求不高，但是所处理数据量较大，占用计算存储资源较多，通常通过MR或者Spark作业或者SQL作业实现。 #13.数据计算-流计算能力：实时流处理，通常是指对实时数据源进行快速分析，迅速触发下一步动作的场景。实时数据对分析处理速度要求极高，数据处理规模巨大，对CPU和内存要求很高，但是通常数据不落地，对存储量要求不高。实时处理，通常通过Spark Streaming任务实现。 14.数据计算-交互查询能力：交互查询平台主要承载对数据进行交互式的分析和查询，查询响应要求较高，能够实现人机之间交互，查询通常比较复杂。专题库的数据通常已经被预处理过，按照适合交互查询的数据模型进行组织。专题库数据量巨大，对CPU和内存要求很高，对于存储要求也很高。交互查询方式，以复杂SQL查询最为常见，也有简单的快读检索. 15.数据计算-实时检索能力：实时检索，通常是指数据实时写入，对海量数据基于索引主键实时查询，查询响应要求较高，查询条件相对比较简单。查询条件复杂的可以根据关键词在全域数据中通过索引搜索主键后，通过主键查询。全域数据既包含了结构化数据又包含了文本等非结构化数据。 16.数据安全管理-用户认证与角色授权：大数据平台提供对外访问时，用户需通过安全认证。可以提供：WebUI身份认证、CLI命令行身份认证、API身份认证等三种方式来对外生工角色授权和用户认知。 17.数据安全管理-数据加密：应急数据基于HBase、Hive、hdfs等组件进行存储，为了保证数据存储的安全，数据应以密文的形式存储在硬盘上，不会因为硬盘泄露、或底层OS被攻破导致数据泄露。 18.数据安全管理-多租户隔离：大数据平台需提供可视化的多级租户管理，与单位组织结构和业务模式相匹配，简化系统资源分配与管理 19.数据安全管理-安全审计：大数据平台支持记录审计日志，审计日志可用于安全事件中定位问题原因及划分事故责任，大数据资源池审计日志中记录了用户操作信息，可以快速定位系统是否遭受恶意的操作和攻击。大数据平台负偏离
负偏离? (-2分)无效投标?
基本满足要求
正偏离
共 20 条，当前 1/1 页
1
需求公示：
序号供应商提问时间提问内容回复内容