很多企业和政府部门做大数据项目,第一反应是"建个数据湖,把数据都汇进来"。结果汇进来之后才发现:同一个客户在不同系统里叫法不一样,同一台服务器在ERP和GIS系统里编号完全不同,报表数字对不上号,想共享数据给别的部门还要走一堆审批流程,最后数据是有了,但没人敢用、没人会用。
这份《行业大数据治理平台解决方案》讲的正是这个问题------数据治理不是"建平台"这一件事,而是标准、采集、加工、质量、安全、共享六个环节缠在一起的系统工程。方案面向ICT、能源、特种等行业用户,但核心方法论具有普适性,值得完整拆一遍。
一、先讲清楚一件事:数据凭什么算"资产"
方案开篇提出一个概念对比:"资源是资产"和"数据是资产",并对比了两种资产形态的差异:
- 物理资产:以物理形式存在,直接产生经济效益,会折旧、会退网
- 数据资产:以逻辑形式存在,间接或直接产生经济效益,不断增值、再利用
这个对比很关键,因为它说明了数据资产管理和传统固定资产管理的本质区别------物理资产用得越多越旧越贬值,数据资产用得越多、关联的越多反而越值钱。数据资产的价值链路是:通过多源多维海量数据"发现规律",通过统计比对"现状研判",基于规律和现状"科学预测",最终"综合服务"于社会各方面。
方案还列了具体的数据资产类型示例------交通应急数据、GIS地图数据、驾驶员基础数据、物流状态数据、视频监控数据、城市管理数据、个人出行数据、基础设施数据、交通路况数据、车辆基础数据------这些覆盖结构化和非结构化两大类,说明数据资产的边界远比传统IT系统里的"业务数据"更宽。
信息化建设范式的演变
方案指出信息系统建设方案经历了从"单一应用系统"到"应用系统+应用系统+应用系统"再到"应用+平台"的演变过程。这句话背后的意思是:过去每个业务需求对应建一套独立系统,现在要转向"底层平台统一支撑,上层应用灵活生长"的模式------这和很多企业中台建设的逻辑完全一致。
二、当前数据管理的四个老毛病
方案把当前数据管理面临的问题总结得很直接,几乎是所有传统烟囱式建设企业的通病:
1. 分散封闭:烟囱式建设的老账
传统的烟囱式建设模式造成系统林立,数据分散并且封闭。为了支撑各自的应用,相同的数据在不同系统之间重复存放,造成资源浪费。这一点方案里举的服务器编码案例特别形象------同一台服务器,在ERP系统里编号是87254、型号2CPU16G;在GIS系统里编号是I0954;在项目管理系统里编号是A0154。三个系统对同一个物理对象各说各话,想统一盘点资产根本无从下手。
2. 多样混乱:缺乏统一标准
缺乏统一的数据标准,无法有效避免数据混乱冲突,一数多源、多样多类的问题普遍存在。
3. 质量较差:缺乏评估和监管机制
数据整体质量不高,监管机制不健全,缺乏面向数据质量的评估机制和数据质量的服务体系。
4. 安全难控:缺乏有效管理机制
对敏感信息、隐私信息、保密信息的访问缺乏有效控制,数据共享困难,系统间接口繁多,实现复杂度高,且可靠性难以保证。
方案给出的应对思路也是针对性的四条:统一(避免重复存放)、集中共享(打破厂商垄断数据)、统一治理(建立数据质量体系)、安全管控(建立分级分类访问控制)。
三、数据资产管理是全生命周期的活儿,不是装个系统就完事
方案里有一句话讲得特别到位:"数据资产管理与政企单位IT信息化过程紧密相连,但对数据资产管理不仅仅是建设一套IT系统,更需要相应管理手段的跟进。"
这句话点破了很多项目失败的根本原因------单纯买软件、上系统,如果没有配套的管理制度、责任分工、流程规范,数据治理照样落不了地。
方案给出的全生命周期覆盖六个环节:
| 环节 | 核心内容 |
|---|---|
| 标准规范 | 数据标准化、资源建模、数据架构、场景定义、指标 |
| 数据采集 | 数据采集、数据录入、数据解析、数据汇总、数据存储 |
| 清洗加工 | 数据抽取、数据转换、数据校验、数据关联、数据脱敏 |
| 数据质量管理 | 准确性、完整性、及时性、安全性 |
| 应用 | 数据交换、数据共享、数据库模式、API接口模式、发布订阅模式 |
| 数据资产运营 | 指挥调度、统计分析、实时监测、流量预测、数据服务 |
这个顺序很重要------先定标准,再采集,再清洗,再管质量,最后才谈应用和运营。很多项目图快,跳过标准和质量管理环节直接上应用,结果就是应用建得越多,数据混乱程度越严重。
四、行业大数据治理平台:一句话讲清楚它是什么
方案对平台的定位很明确:"通过平台+服务的方式,支撑ICT、能源、特种等行业用户建立全面高效的数据资产管控环境,实现多源异构数据的集中、统一和共享交换。统一数据标准、进行数据整合与治理,保障数据安全,实现跨系统、跨部门、跨层级、跨地区的数据共享和开放。"
平台的核心构成包括数据湖(汇聚内部数据、外部数据、媒体数据、物联网/IOT数据)、数据资产管理、数据质量管理、数据标准管理、数据安全管理、元数据管理、交换共享服务、开放门户,支撑数据开发挖掘分析、应用开发、决策支撑等业务应用场景。
平台的产品价值可以用四组对比来概括:
- 分散封闭 → 集中共享:打破厂商垄断数据的局面,形成开放生态
- 多样混乱 → 统一标准:建立统一数据标准,实现主数据统一治理分发,保障一数一源
- 质量较差 → 综合治理:从数据质量管理系统和数据服务体系两方面保障全程质量
- 安全难控 → 安全管控:对数据分级分类、使用状况梳理、访问控制、脱敏加密以及定期稽核
方案总结平台的定位是"负责资源整合公开、协调、调度、管理与监控,凭借高效可靠的数据传输,以高安全、高可靠、高稳定的数据统一管理、共享交换能力,为各行各业的发展提供有力的支撑"。
五、数据汇聚:数据来源广、种类多,靠一条总线扛下来
方案讲了数据汇聚的核心架构------大数据资源汇聚总线。这一层要解决的问题是数据来源的多样性:数据来源覆盖部门内、部门间、政企单位、互联网;数据种类覆盖数据库、文件、消息数据、互联网、业务填报、离线导入、服务。
针对这些异构来源,汇聚总线设计了对应的适配层:互联网适配、非结构化适配、文件适配、消息数据适配、接口服务适配、数据库适配。汇聚过程本身要做数据消息路由、数据质量核检、数据清洗转换、数据预处理、数据格式处理,同时保证安全可靠传输。
存储架构方面提到了针对不同存储引擎的加速器------Hbase加速器、HDFS加速器、MPP加速器、Hive加速器,并强调整体设计要"扩展接口、模板服务、快速配置、灵活适配、安全可靠"。安全管控层面涉及数据加密、数据标准化、数据脱敏、数据加工,配合微内核SCA、OSGI/SOA集群管控等技术底座,以及汇聚编排和汇聚监控能力。
这套设计本质上是想解决一个现实问题:企业里的数据源五花八门,如果每接入一个新数据源就要单独开发一套接入逻辑,治理平台永远追不上业务系统的增长速度。用适配层+模板化配置的方式,能大幅降低新数据源接入的边际成本。
六、国家层面为什么要推这件事
方案专门用了几页篇幅讲政策背景,这一点值得单独说说,因为这类平台的建设很多时候不是企业自愿驱动,而是政策和监管要求推动的。
2017年12月9日,中共中央政治局第二次集体学习明确要求实施国家大数据战略、推动数据资源整合和开放共享,具体包括五个方向:推动大数据技术产业创新发展(坚持数据开放、市场主导)、构建以数据为关键要素的数字经济(深入发展工业互联网战略)、运用大数据提升国家治理现代化水平、运用大数据促进保障和改善民生、切实保障数据安全(制定数据资源确权、开放、流通和交易相关制度)。
配套的政策文件还包括:〔2015〕5号文《关于促进云计算创新发展培育信息产业新业态的意见》、〔2015〕50号文《促进大数据发展行动纲要》、〔2016〕23号文《推进"互联网+政务服务"开展信息惠民试点实施方案》、〔2016〕48号文《政府购买服务改革工作领导小组》、〔2017〕39号文《政务信息系统整合共享实施方案》。
方案还提到了具体的落地成效------制定了《政府数据标准规范》和《数据管理平台保障制度》两大类17项国家标准 ;建设的国家级平台已与山东、四川、福建、贵州、北京、江苏、浙江、广东、河南9个省份 和工信部、文化部、国家旅游局、工程院、中央编办5个部委 完成目录系统对接;帮助全国40余个省市 政府进行数据共享开放工作,其中山东省级政务信息资源共享交换平台已梳理了1.1亿条数据,省级排名全国第一。
这些具体数字说明,这套方法论不是纸上谈兵,而是在真实的国家级、省级平台建设中跑出来的经验总结。
七、数据共享交换平台:把"数据孤岛"变成"数据服务"
这是方案里的第一个核心功能模块。整体功能框架覆盖数据共享(数据共享管理、数据共享门户、共享工作台、内外数据互通)、数据资源目录、数据治理、数据前置交换、外部系统接入等能力。
1. 目录体系:先把数据"摸清楚"再谈共享
目录体系管理涵盖目录注册、目录发布、目录维护、目录查询、目录资源申请五个环节。这一步本质上是给数据资产做"户口登记"------没有目录,数据共享就是无源之水。
2. 数据交换管理:从任务配置到监控闭环
交换管理覆盖交换任务配置、交换作业配置、前置机配置、数据源配置,配合可视化的任务编排与监控(任务概览、任务监控、任务编排)。数据传输交换环节要处理数据加密、数据压缩、断点续传、交换路由等技术细节,数据处理环节涵盖数据抽取、数据清洗、数据转换、数据装载、数据集成,并支持图形化配置、发布订阅、流量控制、集群功能、日志管理。
3. 数据标准化:STG→ODM→DW→ADS 的分层建设
数据标准管理覆盖数据建模标准、数据接口标准、数据存储标准、数据标准指标标准、数据开发标准、标签标准,贯穿贴源层(STG)、操作数据层(ODM)、数据仓库层(DW)、应用数据层(ADS)四层架构。配套的标准管理流程包括标准推荐、标准变更流程、标准映射引用、标准增删改、标准遗漏分析、标准发布流程等。
4. 基于元数据的数据建模工具
这一块讲得比较细,建模的完整生命周期是"设计→审核→实施→验证"四步:
- 设计:根据业务需求进行模型设计,包含基本信息、分类、字段等
- 审核:由数据专家、模型专家对设计模型进行审核,通过后才能实际建立
- 实施:审核通过的模型根据设计在数据库中建立
- 验证:实现模型校验,校验通过后自动写入元数据库,校验方式分两种------一是设计库与实际数据库比对,二是通过业务应用进行验证
建模工具支持在线建立模型、模型变更、下线操作,支持批量模型导入(Excel、PDM),覆盖Hadoop(hive、spark、Impala)、MPP(vertica、gp、gbase、IQ)、RDB(Oracle、MySQL)等多种存储格式,还支持物理库与元数据库信息的一致性盘点核查,发现差异可直接确认同步。
5. 资源目录梳理:从"混乱现状"到"完整目录"的实操路径
方案给出了一套非常具体的资源目录梳理方法,总结了常见的数据问题------"各部门业务库不会提供数据"、"不知共享需求"、"多次跑腿"、"等待时间长"、"重复提交材料"。解决路径是:梳理更新数据开放目录→发现新目录→清理目录→建立数据开放目录→完整性确认→确定初步共享开放目录→依据现状政府业务模型相关单位确认→形成共享开放目录。
具体调研步骤覆盖信息系统基本情况调研、资源目录调研、资源模型调研三块,需要摸清楚的字段信息量很大------信息资源名称、代码、提供方、摘要、格式、共享属性、共享方式、开放属性、更新周期、数据存储总量、结构化信息记录总数、已共享数据量、已开放数据量等等,几十个字段都要逐一登记。这说明资源目录梳理不是拍脑袋分类,而是要按照标准化字段体系逐项调研核实。
6. 数据分级共享安全策略
方案给出了一个非常清晰的数据分级共享矩阵:把数据涉及的敏感维度(内部隐私、单位隐私、个人隐私、知识产权、法规禁止、其它禁止)和共享范围(部门内、部门间条件开放、部门间完全开放、社会条件共享、社会完全开放)交叉对应,形成"什么级别数据能共享到什么范围"的规则表。这套矩阵化的分级管理思路,比单纯靠人工判断"这份数据能不能给别人"要严谨得多。
7. 数据开放共享工具:一键发布,多种交付模式
支持一键式的数据资源对外发布为服务,交付模式覆盖数据API、数据集、数据报告、数据应用四种形式。共享管控采用"审批流程+策略控制"相结合的手段------审批流程包括服务注册审批、服务变更审批、服务注销审批、服务订阅审批;策略控制包括访问会话控制、访问队列控制、数据缓存控制。这种"先审批准入、再策略管控运行时"的双重把关方式,兼顾了共享前的合规性和共享中的稳定性。
八、主数据管理:一物一码,才能谈得上"数据是资产"
主数据管理是方案第二个核心模块,也是最贴近企业日常痛点的部分。
1. 主数据的核心特征
方案给出的定义是"描述客户、物料、供应商等的基础数据",特征包括高业务价值、跨业务重复使用、核心业务实体、变化相对缓慢、存在多系统中、需要交互共享、业务源头主体。
日常业务场景里的现实问题是------每个部门、分公司、业务系统拥有不同的信息,主数据分散存储在多个互不连接的系统里,同一份主数据在多个应用系统中被维护,导致集团总部没有对全局主数据信息及时、一致、真实、可靠的视图。
前面提到的服务器编码案例就是最典型的例证------同一个物理对象,在不同系统里的编号、属性描述完全不统一。
2. 主数据管理面临的五大挑战
方案总结得很精炼:数据共享不及时、数据定义不明确、责任部门不清晰、维护流程不统一、数据状态不可控。根源在于数据标准、流程、责任分工不明确(数据维护分散),数据清洗工作不到位(比如客户、供应商数据),系统功能不完善(缺少数据级联关系管理、维护流程定制、接口监控等定制化内容)。
3. 治理思路:以基础数据入手,自上而下
方案给出的治理路径是"以主数据入手即可完善数据管控的手段,以基础数据为主,步步为营自上而下",具体路径是:政企单位领导→建立数据标准→部门主管→建立规范化管理流程→业务专责→建立数据使用习惯→最终构建完整的数据管理环境。
这个"自上而下"的顺序很重要------如果没有领导层推动建立数据标准,底层的规范化流程和使用习惯很难自发形成。
4. 解决方案:产品能力+管理能力双轮驱动
方案强调解决方案需要"应用完善的数据管理产品能力结合政企单位管理能力的数据管理制度",产品能力覆盖元数据管理、主数据管理、质量管理、统一编码、数据分发、数据清洗等技术手段,管理能力体现在标准的贯彻和落实、流程管理、资源目录等方面。总体架构围绕政企单位服务总线(ESB),把主数据管理标准和流程贯穿人力系统、合同系统、财务系统、资产系统、票务系统、客流系统等各业务系统,最终实现的价值是"提升数据质量、提升数据整合能力、提升领导决策能力"。
5. 主数据管理咨询的五个步骤
方案给出了一套非常具体的实施方法:
- 资源调查:梳理各部门、各业务环节、已建信息系统的信息资源,细化完善目录
- 规划:准备构建主数据管理平台,制定数据标准规范、数据资源维护规范、数据交换共享规范等标准和管理制度,明确编制领导机构工作机制
- 主数据范围确定:按照主数据定义,确定本期项目主数据管理范围
- 主数据模型定义:按照元数据要求,编制生成主数据资源模型定义及编码
- 数据标准与规范规则:落地具体标准
方案还给出了一个非常实用的主数据来源系统对照表:
| 主数据类型 | 主数据来源系统 | 相关系统 | 建议主管部门 |
|---|---|---|---|
| 供应商主数据 | 物资管理系统 | 合同管理、财务管理、实物资产转资 | 运营公司 |
| 客户主数据 | 资源开发管理系统 | 物资管理、财务管理、电子商务 | 财务部 |
| 会计科目主数据 | 财务管理系统 | 合同管理、物资管理 | 财务部 |
| 固定资产主数据 | 财务管理系统 | 合同管理、物资管理、实物资产转资 | 财务部 |
| 设备主数据 | 实物资产转资管理系统 | 合同管理、物资管理、财务管理 | 运营公司 |
| 物资主数据 | 物资管理系统 | 合同管理、财务管理 | 运营公司 |
| 组织机构主数据 | 人力资源管理系统 | 统一用户管理提供给所有系统 | 人力资源部 |
| 员工主数据 | 人力资源管理系统 | 统一用户管理提供给所有系统 | 人力资源部 |
这张表的价值在于------它明确回答了"某类主数据到底谁说了算"这个企业里经常扯不清的问题。没有这张对照表,不同系统的数据维护人员往往各自为战,谁改的数据"更权威"根本说不清楚。
6. 主数据管理三类标准
方案把标准拆成三层:
- 数据标准:定来源(规定唯一出处)、定结构(规定属性、编码构成)、定规则(约定数据之间的关联关系)
- 服务标准:定接口规范(约定生产者、消费者、接口名称、参数)、定数据格式
- 管理标准:定流程(规范申请、变更、修改流程)、定职责(定义流程活动参与者职责)
7. 主数据管理的四大主要功能
方案把功能模块归纳为数据建模、数据整合、数据维护、数据服务四块:
数据建模 方面,资源分类功能能构造主资源目录,支持按组织机构、客户、物料、人员等维度层级划分,协助领导、业务专责或第三方厂商快速定位数据。主数据编码强调"一物一码"是核心内容------通过编码引擎实现系统内部统一数据编码,编码结构一般拆成一级分类码(类)、二级分类码(项)、三级分类码(目)、四级分类码(细目1)、五级分类码(细目2)、四位流水号,对内要建立编码库、支持编码自动校验、编码流程管理,对外要提供编码查询服务、统一编码服务、编码映射服务。实体建模则从PDM、ERP等多种业务系统中梳理汇编数据模型,进行标准化解决一数多源问题,支持模型注册、审核、发布、盘点。
数据整合方面,数据汇集合并提供数据采集与清洗能力,通过ETL、SQL、Excel等多种工具实现自动、手动或混合的采集清洗,结合数据质量检核解决数据的唯一性、权威性、一致性、完整性、合法性问题。
数据维护方面,提供主数据新增、修改、删除、审核、发布等生命周期管理,支持去重规则设置对多来源主数据进行去重。
数据服务方面,支持服务发布(针对分类进行发布)、数据权限管理(设定权限类型及具体属性)、查询服务(支持发起订阅审批流程)、分发服务(通过推送任务定制实现主数据推送)。
这套体系相当于给企业里散乱的主数据装上了一整套"户籍管理系统"------从怎么分类、怎么编码、怎么去重、怎么审核变更、到怎么对外提供服务,每个环节都有对应的机制。
九、数据质量管理:数据治理最容易被忽视,又最要命的一环
方案的数据质量管理部分,用了一个非常具体的行业案例(通信运营商的信令大数据)来说明质量问题到底有多复杂。
1. 数据质量问题遍布三层
方案总结,信令大数据的规模占比超过95% ,是性能管理现阶段数据质量的主要矛盾,而影响数据质量的问题遍及数据源层、数据平台层、上层应用层三层:
- 数据源层:大网调整与DPI割接不同步导致数据漏接(网元扩容、割接、地址变更)、业务量突增导致DPI带宽性能不足数据溢出(黄金周、春节返乡、重大活动)、原始XDR字段统计错误导致KQI计算不准、原始XDR关键信息回填失败(IMSI、MSISDN、IMEI、TAC、CELLID)、DPI特征库更新不及时导致业务识别异常、SDTP接口链路异常导致数据丢失
- 数据平台层:平台持续高负荷导致任务积压数据缺失(集群规划不合理、参数设置异常、程序未调优)、设备与网络故障影响全量数据运算(数据库宕机、采集清洗机故障)
- 上层应用层:指标算法统计错误导致KQI计算不准(用户数、流量、成功率)、基础数据异常影响业务运算准确性、共享接口链路故障导致应用汇总异常
这份清单虽然是通信行业的具体案例,但它揭示了一个通用规律:数据质量问题很少是单点故障,往往是从数据产生源头到最终应用消费的链路上,任何一环出问题都会传导放大。
2. 数据质量保障体系:标准+组织+工具+运维
方案给出了一套很完整的保障体系设计,分五个模块:
- 标准规范:制定数据标准规范、制定数据核查标准
- 组织与制度:构建多方专人保障组(局方、数据源厂家、数据共享平台厂家、数据应用厂家),制定管控制度(质量例会)
- 处理流程:明确数据处理问题闭环处理流程
- 质量核查工具:数据质量信息核查组件/探针、配置化数据质量核查功能、短信+告警结合的预警手段
- 运维保障:定制日常质量巡检作业、定期开展运维分析报告
组织与制度这一块讲得非常细,方案提到了"磐石行动 "、"部省接口"等专项行动的治理机制------每月/每季度确定专项重点保障范围,明确专项核查重点KPI及保障标准,实行闭环管理(专人每日巡检、每日汇报),定期总结(每周数据质量分析会、每月故障分析会、投诉及故障处理经验归档)。质量保障专项团队的组织形式是"局方专人管理+各厂家项目经理挂帅+各层厂家设置量问题专员",通过项目例会每两周对近两周数据质量问题进行总结分析原因、找隐患根源,最终总结经验、IT固化规则,提升自动化运维水平。
这里的关键启示是:数据质量不是技术部门单打独斗能解决的,必须建立跨方、跨层的协同机制,而且要有例会、督办这类"笨办法"来强制推进闭环。
3. 数据质量标准规范的颗粒度
方案给出的核查规则示例细到具体阈值------比如4G实时数据模型的准确性检查规则包括"http访问成功率<90%"、"http平均响应时延>3000ms"、"ATTACH成功率<90%"、"承载建立成功率<90%"、"TCP建立成功率<90%"等,及时性检查"文件生成时延>30分钟",完整性检查"有无标题行、文件数、记录数、列数"。字段规范方面也具体到字段类型、长度、取值范围(比如接口类型字段限定范围1-24,RAT字段限定范围1-6,IMSI字段限定为15位数字,手机号字段限定为11或13位数字)。
这种颗粒度说明,真正的数据质量核查不是"看起来数据完整就行",而是要下沉到每个字段的取值范围、每个业务动作的成功率阈值。
4. 数据质量管控工具:五个维度的全程监控
方案定义数据质量管控是"一个问题管理中心,遵循问题发现、分析、解决和评估的闭环管理方式,从完整性、及时性、有效性、一致性、准确性五个方面,对数据的运行环境、采集、处理、消费进行全程的监控评估"。
具体架构涵盖数据源监控、数据质量稽核信息采集、统一规则管理(规则库)、数据质量信息库和数据质量问题库(存储和追溯),支撑质量概览、血缘分析(影响性分析)、知识库检索、问题归档、报表服务等能力,并通过预警规则配置实现主动预警。
工具的核心价值可以概括为六点:统一的数据质量监控、灵活的规则设置、血统/影响分析帮助问题定位、质量规则的统一管理、知识库管理与查询、多方式质量问题分析。
5. 数据质量处理流程:三种典型场景的常态化机制
方案给出了三类场景下的常态化处理机制:
- 工程割接场景:专业室与网管提前共享割接计划,工程割接实施前提前告知DPI厂家制定升级方案,割接完毕后DPI升级同步开展
- DPI升级场景:基础信息例行更新(定期更新规则库、基础数据库、关联算法),数据模型与算法例行更新(根据下发的XDR数据规范定期自检更新模型、算法、合理性规则)
- 可视化监测预警:原始XDR监测覆盖数据完整性、及时性、准确性,监测周期分5分钟、15分钟档,预警手段包括PC端、短信、邮件
问题定位则依靠元数据血统分析、ETL/设备日志关联、经验检索多种手段协助;问题督办与闭环采用"摘挂牌"管理机制------对处理过程进行跟踪,频发、长期未解决的问题纳入摘挂牌管理,定期通报、评价与考核。
6. 共享统计数据质量稽核
方案提到对共享文件、上报文件的数据合规性、文件一致性进行实时稽核预警,核查内容覆盖及时性(文件生成时延)、完整性(文件数、文件大小、记录数、列数、是否有标题行)、准确性(成功率类、时延类、速率类、流量类指标)。
7. 接口数据补报与运维保障机制
方案提到了具体的资源数据合理性检查项------关键维度字段是否为空、重复账号数量占比、bandwidth为空占比、用户数、ONU总数、OLT总数、BRAS总数等;XDR数据合理性检查项包括关键字段为空占比、业务大类填充为空占比、上行/下行流量填充率等;性能指标合理性检查项包括ONU发光功率异常占比、OLT异常数据占比等。运维保障机制是"定期数据质量巡检任务+每周/每月数据质量专题报告"相结合。
这一整套质量管理体系告诉我们一个道理:数据质量不是一次性清洗就能解决的,而是需要标准、组织、工具、流程四位一体,持续运营才能维持住。
十、数据安全管控:从"数据在哪"到"数据去哪"
方案的数据安全部分,先讲了大的时代背景,再讲具体的治理方法论,逻辑很完整。
1. 大数据时代的数据安全命题
方案用四个问题概括了数据安全的核心难点:
- 数据在哪里产生:IOT to IOE(万物皆可产生数据)
- 数据在哪里存储:无所不在的端&云
- 数据在哪里使用:每一个生产环节,DT的价值发挥
- 数据在哪里"丢失":每一个生产环节的每一个组成要素,交换、共享、披露等外部环节
这四个问题合在一起说明:数据安全的边界已经从"守住数据库"扩展到了"守住数据的全生命周期",任何一个环节都可能是泄露点。
2. 国家层面的明确要求
方案引用了2017年6月1日起施行的《网络安全法》,列出了具体的技术性要求:对数据访问日志进行审计且留存不低于6个月(第21条)、对数据分类并区别化处理敏感数据与普通数据(第21条)、对重要数据进行备份容灾(第21、34条)、对重要数据进行加密(第21、31条)、对个人信息进行脱敏(第42条)。网络安全法涉及的数据保护对象分层------一般网络数据(第21条)、基础信息基础设施数据(第34条)、用户信息和个人信息(第42条)是重点保护对象。方案还提到当时已经预告将制定《数据安全法》。
3. 数据时代的数据安全威胁清单
方案按数据生命周期阶段列出了具体威胁:
- 数据采集:多源异构接入方式多样,造成采集源头安全隐患,数据溯源难
- 数据流通:数据不再局限于部门内使用,流通环节增大泄露隐患,需要对数据去向进行跟踪
- 数据使用:明文数据落地到数据库、加工使用、应用展现的过程中,权限滥用、误操作、缺乏审计等原因容易导致窃取或非法修改
延伸出来的具体风险点包括:数据分类分级、数据来源和流向溯源、数据驻留和资产地图、元数据管理、数据中间沉淀、权限漏洞、非法爬虫、数据滥用、信息泄露回溯、研发后门&模型和BI外包、云环境可信性、大数据综合风险。
4. 数据安全管理的四个难点
方案总结了四类管理难点:
- A:分类识别难------数量多、形式多、数据关系复杂,难以梳理;敏感与否由人主观判定,缺乏标准性和自动化技术手段
- B:分级保护难------缺乏分类分级安全策略,缺乏不同位置的风险评估视图;覆盖存储、传输、使用全过程的保护成本高
- C:全面覆盖难------无法明确某类敏感数据在组织的整体分布,数据类型多、形态多导致内容识别难度增加,缺乏处理漏报误报的技术手段,需要覆盖终端、网络、系统、数据库、存储等所有位置
- D:评价改进难------缺乏数据保护评价指标、方法和数据,无法客观评价管控措施有效性,缺乏评价导致无法有效改进
5. 数据安全治理总体思路:六步循环
方案给出的治理思路是一个持续改进的闭环:
- 组织保障:建立安全保障组织,构建安全管理机制
- 数据梳理:对数据资产进行梳理,评估所有者、用途、存储、分发、价值等属性,进行分类分级管控
- 制定防控方法:在分类分级基础上,分别制定安全防护策略和管控流程
- 技术防护:面向数据采集、加工处理、使用及流通全过程,采取加密、访问控制、脱敏、水印、监视等技术手段全方位防护
- 风险评估:监控敏感数据异常访问行为,进行风险评估,形成安全态势感知
- 改进措施:持续修正优化分类分级及相应管控策略和管理制度
这六步形成一个"组织→梳理→策略→防护→评估→改进"的持续循环,而不是一次性建设完就结束。
6. 数据安全治理功能架构:三大能力模块
方案把功能架构拆成三块:
分类分级管理:分类信息管理、分级信息管理、分类规则管理、数据修正、敏感数据地图。
安全策略管理:安全策略配置、加密密钥管理、脱敏算法管理、水印参数设置、用户权限配置,技术手段覆盖数据加密、数据脱敏、数据审计、数字水印、权限控制,适用对象覆盖结构化和非结构化数据、业务系统、管理系统、运维系统、第三方系统。
安全态势感知:风险规则管理、风险行为监控、风险行为分析、风险行为预警、安全态势评估。
7. 管理机制:三分管,七分治
方案有一句很朴素但很有分量的话:"数据安全,三分管,七分治"。这句话点出了一个常被忽视的事实------技术手段只占三分,更重要的七分是组织架构、责任分工和持续运营的管理机制。方案给出的组织架构包括部门层(数据安全经理、管理团队)、数据层(数据资源owner)、审计(集团统一、CRO控制点owner)、数据安全BU(可选生成方小组员工)。
8. 分类分级:AI+规则双引擎
分类分级支持多种数据识别技术------关键字、正则表达式、人工智能等,适应不同的分类分级规则制定需求。内置规则涵盖丰富的敏感数据识别规则(个人信息、银行及卡号信息等);自定义规则支持通配符、简单逻辑描述、简单关联、序列等;AI分类分级则利用自然语言处理、数据挖掘(聚类、分类)、机器学习(无监督、有监督)技术,分别针对结构化数据(数据模型)和非结构化数据(数据内容)进行智能分类分级。
9. 安全策略:六个维度的策略设计要素
方案给出的安全策略设计要素包括策略基本信息、应用用户对象、应用数据对象、数据操作环节、安全治理方式(数据加密、数据脱敏、添加水印、日志审计、金库审批、DLP防泄漏、接口令牌、权限控制)、后续处理流程。这套要素组合起来,基本上能回答"谁能对什么数据的哪个环节做什么操作,用什么方式治理,出了问题怎么处理"这一整套安全管控问题。
10. 技术防护:不同生命周期阶段配不同手段
方案把技术手段按数据生命周期阶段做了精细映射:
- 数据采集阶段:数据分类分级、权限控制
- 数据存储阶段:权限控制、数据库加密、数据库静态脱敏
- 数据加工阶段:数据动态加密、打标签、数据动态脱敏、差分隐私
- 数据使用阶段:数据动态加密、数字水印、数据库审计、数据动态脱敏、审计
- 数据传播阶段:数字水印、接口令牌、DLP防泄漏
这种"阶段化配置安全手段"的思路很关键------不是所有环节都上最重的防护,而是根据数据在不同阶段的暴露风险,配置对应强度的措施,兼顾安全性和使用效率。
11. 风险评估:三类行为模型
方案提到建立敏感数据异常访问模型、数据库访问行为模型、业务系统用户访问行为三类风险发现模型,通过监控用户行为及审计,根据风险模型发现问题,对高密级数据的异常访问进行风险预警,帮助直观感知安全态势,再根据风险问题改进安全策略及制度,形成持续改进闭环。
12. 方案亮点:四个具体技术手段
方案里点出了四个比较有代表性的技术亮点:
AI分类分级:通过机器学习(无监督和有监督)、自然语言处理、数据挖掘(聚类和分类)等AI技术,实现自动分类分级,提高效果和效率,避免漏判误判。
数据加密:用户可选择性对敏感字段加密,即使数据库文件被非法复制或存储文件丢失,也不会导致真实敏感数据泄露;基于主密钥、工作密钥等多级密钥方案,以及对称密钥和非对称密钥的混合密钥方案实现密钥管理。
动态脱敏 :针对需要共享的生产数据或时效性要求很高的测试培训场景,基于网关代理模式,达到实时模糊敏感数据的效果,可对业务系统数据库中的敏感数据进行透明、实时脱敏。方案给出了具体的技术实现方式------中途拦截SQL指令,根据用户权限对SQL进行改写 ,比如把select name from customer改写成select CONCAT(SUBSTRING(name,1,1),'O',SUBSTRING(name,3)) as name from customer,授权用户看到真实数据(如"张安全"),非授权用户看到脱敏后数据(如"张O全")。
静态脱敏:针对开发测试数据场景,通过采样、替换等方式生成脱敏后的准真实数据,脱敏后数据同时保留原有的关联关系,方便在培训环境、压力测试、开发环境、单元测试中使用。
数据水印:在数据外发环节加隐蔽标识水印,追踪数据扩散路径,支持可见水印(LOGO、文字、图片)和隐匿水印(版权、来源、出处),支持结构化数据表和非结构化数据水印,技术实现包括插入伪列、插入伪行等方式。
安全态势感知:通过库端审计和应用端审计,监控常见风险场景------频繁打开大量敏感数据、突然下载大量敏感数据、非正常时间访问敏感数据、短时间内删除大量数据或日志、大量数据出现位置移动,通过行为积累判断风险意图。
这几个技术亮点的共性是:都不是简单的"一刀切"防护,而是在保证业务可用性的前提下,精细化控制谁能看到什么样的数据。动态脱敏和静态脱敏的区分尤其体现了这种精细化思路------生产环境要保证数据实时可用又要防泄露,用动态脱敏;开发测试环境要保证数据可用于测试又不泄露真实信息,用静态脱敏,两种场景用两套不同的技术方案。
十一、适用行业:数据治理不是一个行业的事
方案最后提到了平台适用的五大行业场景,每个行业的数据安全痛点各有侧重:
- 政府:以信息共享、业务协同和数据开放为目标的电子政务发展,如何防止内部敏感数据、隐私信息泄漏是安全防护重点
- 特种行业:拥有大量涉及国防机密信息的数据,一旦发生数据安全问题涉及威胁国家安全,对数据安全可控有更高要求
- 制造业:智能制造发展引入更多业务系统,设计图纸/文档从研发到投产过程中数据流通更便利,同时带来安全隐患
- 运营商:核心业务积累大量客户信息、生产数据和运营信息,涉及国家政策、个人隐私、自身发展多方面,业务系统繁多交互复杂,数据安全问题多
- 交通、能源行业:信息化投入持续增大,信息生成流转传输变得快捷,伴随行业竞争激烈,数据安全问题愈发凸显
- 金融行业:数据量大、敏感度高、分散保存、参与应用人数众多,同时需要满足监管部门合规性要求,数据安全需求空前迫切
这份行业清单说明,这套治理方法论具备跨行业的普适性,只是不同行业需要根据自身数据特点调整分类分级规则和安全策略的具体参数。
十二、这份方案最值得学习的地方
1. 数据治理是全生命周期工程,不是单点建设
方案反复强调标准、采集、加工、质量、安全、共享这六个环节缺一不可,而且顺序很重要------没有标准就没法谈质量,没有分类分级就没法谈安全策略。
2. "一物一码"是主数据治理的核心抓手
服务器编码那个案例特别典型------同一个物理对象在三个系统里三种编号,这种混乱不解决,任何上层的数据分析和决策支撑都是建立在沙子上的。
3. 数据质量管理要有具体到字段级的核查规则
方案给出的字段规范细到取值范围、长度限制、成功率阈值,这种颗粒度才能真正发现问题,而不是停留在"数据看起来还行"的模糊判断上。
4. 数据安全要按生命周期阶段配置差异化手段
不是所有环节都上最重的加密,而是根据采集、存储、加工、使用、传播各阶段的风险特点,配置对应的技术手段,兼顾安全和效率。
5. "三分管,七分治"提醒我们组织机制比技术工具更重要
再好的平台工具,没有配套的组织架构、责任认定、考核机制,也很难真正落地运营下去。
十三、给正在规划数据治理项目的团队几点建议
1. 先做资源目录梳理,别急着上系统
方案里详细的资源目录调研字段体系值得参考------信息资源名称、代码、提供方、格式、共享属性、更新周期等等,先把这些摸清楚,再谈建平台的事。
2. 主数据管理范围要按业务实体逐一确认主管部门
参照方案里的主数据来源系统对照表思路,针对企业内的供应商、客户、会计科目、固定资产、设备、物资、组织机构、员工等核心实体,逐一明确来源系统和主管部门,消除"谁的数据说了算"的争议。
3. 数据质量保障要建立跨方协同的组织机制
不要指望单靠技术工具解决质量问题,要参考"专项小组+定期例会+专项汇报"的组织形式,让数据源方、平台方、应用方形成常态化协同。
4. 数据安全策略要先做分类分级,再谈具体防护手段
没有清晰的分类分级结果,任何加密脱敏策略都是无的放矢。可以借助AI+规则双引擎降低分类分级的人工成本。
5. 动态脱敏和静态脱敏要分场景选用
生产环境的实时共享场景用动态脱敏,开发测试环境用静态脱敏,不要用一套方案覆盖所有场景。
结语:数据治理的终点,是让数据真正可信、可用、可控
这份《行业大数据治理平台解决方案》讲的道理其实很朴素:数据要真正成为资产,必须经过标准化、质量保障和安全管控这三道关卡。没有统一标准,数据是混乱的;没有质量保障,数据是不可信的;没有安全管控,数据是危险的。三道关卡都过了,数据才能真正支撑决策、创造价值。
对任何正在推进数据治理项目的企业或政府部门来说,这份方案最值得借鉴的不是某个具体功能模块的清单,而是它贯穿始终的方法论------先摸清数据资产现状,再建统一标准和主数据体系,同步建立全程质量监控闭环,并按数据生命周期配置差异化安全防护,最后用组织机制而不仅是技术工具来保障长期运营。这套逻辑,比任何单一的技术组件选型都更值得深入理解和复制推广。
以下为方案部分截图:









































































































