第11章 技术架构与数据治理

本章导读

第 04 至 10 章是逐域展开的业务场景，本章退到这些场景共同的底座：架构决定系统能走多远，数据决定结论能信几分。过去不少企业把 GIS 当作“电子地图”采购，验收时图层齐全、演示流畅，两三年后却陷入“图上看得到、业务用不上”的困境，问题很少出在软件功能，而出在架构分层缺失与数据治理缺位。

全章按“先骨架、再血肉、最后底线”推进：11.1 用五层架构（图11-1、表11-1）和标准规范、安全运维两条纵线回答变化如何被隔离；11.2 讨论统一时空基准与多模存储选型（表11-2）；11.3 至 11.5 依次处理标准与主数据（表11-3）、数据质量五维度（表11-4）、共享交换与开放（表11-5）；11.6 至 11.8 收在性能与高可用（表11-6）、安全合规（表11-7）、运维与总拥有成本（表11-8）这三条长期运行的底线。八张表不是并列的清单，而是一条判断链：架构分层决定服务边界，主数据决定系统之间能不能对上，质量规则决定数据敢不敢用，服务目录决定别人找不找得到，性能与合规决定上线后会不会被叫停，成本决定三年后还养不养得起。

学习目标

读完本章，你应当能够：

• 对照表11-1 说出五层架构各层的核心构成与关键交付物，并解释“层与层之间对不上”为何通常源于两条纵线缺失；
• 区分空间数据库、时序库、对象存储、图数据库的适用边界，为矢量管网、监测时序、遥感影像、关系图谱各选一种存储并说明理由；
• 复述数据标准的三层结构（要素分类与编码、属性字典、接口与交换格式），并按“一数一源”为四类主数据指定权威系统与责任部门；
• 用完整性、位置精度、拓扑连通性、属性一致性、时效性五个维度设计检查规则，说明发现矛盾后为什么应生成外业核查任务而不是直接改坐标；
• 对照表11-5 与表11-7 判断一次数据共享分别触发哪些合规事项，并说明个人信息与关键设施位置应如何脱敏；
• 用表11-6 与表11-8 为一个典型场景设定性能目标、估算并发，并说明全生命周期成本为什么要区分一次性投入与年度经常性支出。

地理信息系统（GIS）在水务行业的价值，最终取决于两件不太显眼的事：架构能否支撑业务长期演进，数据是否可信到可以据此决策。架构决定系统能走多远，数据决定结论能信几分。过去十余年，不少水务企业把 GIS 当作“电子地图”采购，验收时图层齐全、演示流畅，两三年后却陷入“图上看得到、业务用不上”的困境。问题很少出在软件功能，而出在架构分层缺失与数据治理缺位：感知数据进不来，主数据对不上，分析结果回不到工单。本章从五层架构与两条纵线出发，讨论时空数据底座、标准与主数据、质量治理、共享开放、性能与高可用、安全合规、运维与成本，给出可落地的判断标准与实施顺序，帮助管理者在立项、选型、验收与运营各阶段做出不失衡的决策。

11.1 总体架构

五层架构的价值不在于层次名称，而在于每一层都对应一个必须回答的问题。感知层回答现场正在发生什么：管网压力、瞬时流量、水质指标、泵站液位、积水深度、巡检轨迹、施工机械位置，以及遥感影像所反映的地表变化。数据层回答这些记录以什么形态保存、保存多久、由谁维护，涉及空间数据库、时序库、对象存储与元数据目录。平台层回答哪些能力可以被反复调用，包括地图服务、三维服务、空间分析、拓扑计算、模型接口与统一身份认证。应用层回答业务动作如何完成，例如关阀方案如何生成、工单如何派发、汛情如何会商。门户层回答不同角色如何获得信息，包括桌面端、移动端、指挥大屏与对外接口。层次划分的真正意义是把变化隔离开：感知设备五到八年更新一轮，应用需求两三年调整一次，而数据模型与服务接口应当保持十年以上稳定。

两条纵线常被当成验收材料，实际上是架构能否成立的前提。标准规范体系贯穿五层，规定要素分类、编码规则、属性字典、服务接口、地图符号与质量规则；安全运维体系同样贯穿五层，覆盖网络分区、身份认证、数据分级、审计留痕、备份恢复与应急演练。纵线缺失的典型症状是“每层都建成了，层与层之间却对不上”：感知层上报的测点编号在平台层找不到对应设施，应用层拿到的管线数据无法与营收系统的用户地址关联。把纵线写进概算、写进合同、写进验收清单，比在架构图上多画两个方框有效得多。

架构设计有三条经得起检验的原则。第一，以业务动作定义服务，而不是以软件模块划分系统，需要沉淀的是“关阀影响分析”“爆管影响范围推算”“积水点与管网节点匹配”这类可被多个应用调用的能力，而不是“管网模块”“调度模块”这样的菜单。第二，平台层只建设被三个以上应用复用的能力，复用不足的能力放在应用侧快速迭代，避免平台越做越重、版本越上越慢。第三，跨系统数据交换一律走统一通道，禁止应用直连他人数据库，否则数据血缘无法追踪，一处表结构变更就可能引发连锁故障。

实践中最常见的三种失衡值得警惕。其一是重感知、轻数据：大量安装智能表计与压力计，却没有设备台账、时间同步与坏点标识，数据进库即失真。其二是重三维、轻二维：预算集中投在实景三维与指挥大屏，二维管线仍靠手工维护，三维模型因此失去分析价值。其三是重建设、轻治理：验收时数据完整，交付两年后新增管线无人入库，系统逐渐退化为历史档案。三种失衡的根源相同，都是把 GIS 当作一次性工程，而不是需要持续运营的能力。

架构演进通常经历项目化、平台化、资产化三个阶段。项目化阶段以单个痛点为王，系统之间靠文件交换；平台化阶段建立统一数据底座与服务目录，应用按需调用；资产化阶段把空间数据纳入企业数据资产，明确责任、质量与价值。三个阶段无法跳跃，但可以缩短。可行的做法是在平台化初期建立架构评审机制，由信息化部门、业务部门与技术专家共同评审新建系统的数据模型、接口方案与复用说明。评审不必复杂，一张数据流图、一份接口清单、一份复用清单，往往就能避免后续数年的返工。

表11-1 五层架构的构成与关键交付物

【实践观察】架构评审如何拦下重复建设 这是水务信息化中反复出现的一类情形：管网、营业、工程等部门各自提出系统建设申请，方案中都包含管线地图与关阀分析，也都计划自建管段表。若在立项阶段引入架构评审，要求申请方提交数据流图与接口清单，重复建设往往能在纸面上被发现：三套编码、三份管段表、三个地图服务，后续的对接成本远高于当期节省。评审的结论通常是地图与关阀分析由平台层统一提供，业务部门只建设自身流程，管线数据由管网部门唯一维护。这一做法的价值不在审批本身，而在于强制各方把“我要什么”翻译成“数据从哪来、服务谁提供、责任归谁”。

图11-1 水务 GIS 总体技术架构

资料来源：本报告整理

11.2 时空数据底座

时空数据底座的第一项要求是统一时空基准。管线、监测点、影像、三维模型必须统一到 CGCS2000（2000 国家大地坐标系）与 1985 国家高程基准，并在数据字典中写明投影方式、坐标单位与高程校正关系。存量数据从西安 80 或地方独立坐标系转换时，必须保留转换参数、转换日期与精度评估记录，否则同一段管线在不同系统中的位置可能相差数米，关阀分析的空间范围随之失真。第二项要求是图属一体：几何与属性存放在同一条记录中，避免图形在计算机辅助设计图纸、属性在表格、关系在纸质台账的“三张皮”状态。

空间数据库承担管段、节点、附属设施、汇水区、服务范围等矢量数据的存储与空间计算。选型应评估五个维度：空间函数是否完备，能否支撑缓冲区、叠加、最近邻与网络连通分析；高并发下的查询性能；与现有数据库体系的一致性；许可与维保成本；国产化适配的成熟度。PostGIS 生态成熟、社区活跃，适合以开源路线为主的企业；Oracle Spatial 在已有 Oracle 体系的大型企业中运维经验充足；国产数据库的空间扩展进步明显，在信创要求明确的场景可以作为主选，但必须在项目前期用真实数据做压力测试，而不能只看兼容性清单。

时序库承担数据采集与监视控制系统（SCADA）与物联网数据的写入、压缩与聚合。以一个中等规模城市布设一万个压力与流量测点、每五分钟上报一次为例进行测算，日增记录约二百八十八万条，年增约十亿条；若保留五年原始数据，单表规模将超出关系型数据库的舒适区。合理的分层是热数据入时序库、温数据按小时或日聚合、冷数据归档到对象存储，并在数据字典中固定降采样规则。口径不清是常见隐患：调度部门用五分钟均值判断压力波动，营业部门用日累计值核对水量，两者若引自不同聚合结果，对账时必然出现无法解释的差额。

湖仓一体主要解决原始资料与分析成果并存的问题，并非所有水务企业都需要。遥感影像、无人机视频、计算机辅助设计（CAD）与建筑信息模型（BIM）原件、扫描档案、外业照片应放在对象存储中，以元数据目录建立检索与权限；清洗后的分析成果进入分析型数据库或数据仓库，供报表与模型调用。集团级企业、跨区域运营主体和承担省级监管平台建设的单位，才有必要引入开放表格式与统一元数据服务；市级水司若数据量有限，用对象存储加分析型数据库的组合即可，盲目上湖仓往往带来更高的运维复杂度。

图数据库适合处理多跳关系，但不应被当作管网拓扑的默认选择。十万到百万级管段的连通性分析，用关系型数据库配合递归查询或拓扑扩展即可满足；真正体现图数据库价值的是影响传播、水质溯源、权属关联与事件链路，例如从一处水质异常出发，沿供水路径反向追溯可能的二次供水设施与用户群体。选型前应先列出查询模式：需要几跳、每跳的过滤条件是什么、结果如何排序，再判断图数据库能否带来数量级改善。先买图库再找场景，是这类项目最常见的浪费。

瓦片金字塔是二维地图的性能基础，三维缓存则决定模型能否被业务使用。二维侧常用网络地图瓦片服务（WMTS）或 XYZ 瓦片，按层级预切，管线更新后对受影响范围重新切片并保留版本号；三维侧以 3D Tiles 组织倾斜摄影、点云与 BIM 模型，通过层级细节与视锥剔除控制单次加载的三角面数量。缓存应分四级设计：浏览器缓存、反向代理缓存、服务端瓦片缓存与数据库查询缓存，每级设置合理的过期策略。管线数据更新频繁而底图更新缓慢，二者必须分离缓存，否则每次管线变更都会触发全量重切，运维成本难以为继。

表11-2 多模数据存储选型对照

11.3 数据标准与主数据

数据标准分为三个层次，缺一层都会导致标准落不了地。第一层是要素分类与编码，解决“这是什么、叫什么”；第二层是属性字典，解决“记录哪些字段、取值范围是什么、单位与精度如何”；第三层是接口与交换格式，解决“以什么结构对外提供、如何版本管理”。分类分级要解决三件事：按专业划分一级类，按要素形态划分二级类，按管理粒度划分三级类；分级过粗无法支撑统计，过细则采集成本过高。很多企业只发布了第一层的分类代码表，就宣称建成了标准体系，结果各系统字段名不同、单位不同、枚举值不同，交换时仍需人工映射。

管线编码规则应同时满足唯一性、稳定性、可读性与可扩展性。唯一性要求全企业范围内不重复；稳定性要求资产生命周期内不因行政区调整、道路改名或权属变更而改码；可读性要求业务人员能从编码看出专业与要素类别；可扩展性要求为新增要素类型预留位置。一种可行结构是“专业代码＋行政区代码＋要素类代码＋顺序号”，例如给水专业以 GS 开头、排水以 PS 开头，后接行政区与要素类，最后是流水号。编码一旦启用不得修改，历史编码通过映射表保留，供旧工单与旧图纸回溯。

属性字典要回答四个问题：哪些字段必填、每个字段的取值范围、单位与精度、由谁在什么环节录入。以管段为例，管径、材质、敷设方式、埋深、建设年代、权属单位属于必填；材质枚举应统一为球墨铸铁、钢管、塑料管、混凝土管等有限取值，不能出现“铸铁”“球铁”“球墨”三种写法并存；埋深需注明是管顶埋深还是管中埋深；建设年代精确到年即可，精确到日反而制造虚假精度。字典由数据责任部门维护，任何新增枚举值需经审批并同步到所有采集端。

元数据是数据可信度的凭证，至少应记录来源、生产方式、坐标系、高程基准、精度等级、生产日期、更新日期、质检结论、责任人与使用限制。外业探测数据与竣工测量数据的精度不同，设计图与实测图的可靠性不同，这些差异必须通过元数据传递给使用者，而不是让分析人员凭经验猜测。元数据还应支持血缘追踪：一份爆管分析报告使用了哪些管段、哪些测点、哪个版本的数据，出现争议时可以复现。

主数据管理的核心是“一数一源”。水务企业至少有四类主数据需要跨系统对齐：管网设施（管段、节点、阀门、泵站、水厂）、用户与表具、组织与人员、监测设备。营收系统里的用户地址、GIS 里的建筑点位、工单系统里的报修地址，若不基于同一套地址库与设施编码，坐席只能靠人工判断，派单错误率居高不下。可行路径是先确定每类主数据的权威系统与责任部门，其他系统只读引用；新建系统不得自建同类主数据，只能申请接入。

数据模型是把业务对象翻译成数据库结构的规则。水务空间数据模型通常围绕设施、事件与用户三类对象组织：设施包括水厂、泵站、管段、阀门、检查井与排放口，事件包括爆管、积水、投诉与工单，用户包括居民、企业与重点保障对象。三者通过设施编码、事件编号与用户编号建立关联，形成“谁在什么位置、发生了什么、影响了谁”的基本结构。模型设计应预留扩展位，避免每增加一类设施就改一次表结构；同时要区分事务数据与分析数据，前者追求写入效率与一致性，后者追求查询与聚合性能。

标准落地的难点不在编写，而在执行。建议设立由信息化部门牵头、各业务部门参加的标准委员会，负责年度修订与例外审批；标准文件要有版本号与生效日期，旧版本继续服务存量系统，新版本只约束新建与改造项目；例外必须有书面申请、影响评估与退出期限。最常见的失败原因是标准由外部咨询团队编写、企业内部无人认领，交付即封存。标准只有进入采购文件、设计评审与验收清单，才真正具备约束力。

表11-3 管网核心属性字典示例

11.4 数据质量与治理

数据质量通常从完整性、位置精度、拓扑连通性、属性一致性、时效性五个维度评价，每个维度都要落到可判定的规则，而不是停留在“总体较好”的描述。完整性的业务后果是分析范围不完整，关阀时漏掉一段管就可能扩大停水；位置精度的后果是开挖时找不到管线；拓扑问题的后果是连通性分析给出错误路径；属性不一致的后果是水力模型率定失真；时效性不足的后果是新增管线长期游离于系统之外，形成“账外资产”。

完整性检查应覆盖三个层次：空间完整性，即已知路网与地块范围内是否存在未录入的管段；属性完整性，即必填字段的空值率；关联完整性，即阀门、消火栓、排口等附属设施是否挂接到管段。位置精度检查可设置两类规则：绝对精度依据测量方式分级，竣工测量、探测、设计图估算分别赋予不同的可信等级；相对精度检查明显矛盾，例如管线穿越建筑物基础、阀门位于河道中央、管段跨越地下隧道而未标注。发现矛盾后不应直接修改坐标，而应生成外业核查任务，核实后回写并记录依据。

拓扑连通性检查是管网分析的前提。常见缺陷包括悬挂点，即管段端点未与其他管段连接；孤立子网，即与水源不连通的独立片区；反向流向，即重力流管段标高倒挂；重复管段，即同一位置存在两条重叠记录。检查规则应写成可执行的查询：端点容差范围内是否存在同口径节点、重力流管段上下游底标高是否单调、雨水管与污水管是否误连。属性一致性检查则关注字段之间的逻辑关系，例如阀门口径不应大于所在管段管径、管径与建设年代应符合材料演进规律、压力等级应与所在分区相符。

时效性是最容易被忽视的维度。新建管线从竣工测量到入库的周期，直接决定系统能否反映真实管网。建议把“竣工测量成果入库”设为工程结算的前置条件，未入库不结算；把变更单闭环率、平均入库时长纳入管网部门考核。对于历史遗留的未入库管线，可通过年度普查、施工配合、外业探测分批补录，并为每条补录数据标注来源与可信等级，避免与竣工数据混为一谈。

治理组织比治理技术更重要。数据责任应由业务部门承担，对数据的完整性、准确性与更新及时性负责；信息化部门承担标准、平台与工具；测绘队伍承担采集与质检；审计或运营管理部门负责抽查。考核指标不宜过多，三到五项即可，例如新增管线入库及时率、必填字段完整率、拓扑缺陷整改率、外业核查任务闭环率。指标一旦纳入考核，就必须保证数据来源可审计，否则会出现“为了达标而批量填充默认值”的逆向激励。

治理节奏建议“先增量、后存量，先试点、后推广”。增量管控见效快，通过竣工入库与变更闭环即可止住新的欠账；存量清洗投入大，应选择管网复杂度适中、业务诉求强烈的片区试点，形成可复用的质检规则与作业流程后再推广。运动式治理往往在短期内动员大量人力，结束后缺乏常态化机制，数据很快回退。比较稳妥的目标是每年完成若干片区的深度治理，同时保持增量数据的高质量入库，用三到五年时间把整体质量提升到可支撑分析的水平。

表11-4 数据质量检查规则示例

【实践观察】片区试点的数据治理路径 存量数据治理常见的做法，是先选择几个管网密度与业务诉求都居中的片区试点，而不是一开始就全城铺开。试点以竣工图、探测报告与巡查记录为底稿，逐段核对管径、材质与埋深；用路网与地块数据反查缺失管段；对穿越建筑、标高倒挂等明显矛盾生成外业核查任务；核查结果回写时保留原始值与修改依据。试点结束后，形成可执行的质检规则与作业指导书，再向其他片区推广。这一路径的关键不是技术，而是把“改数据”变成“有依据地改数据”，并使核查任务进入既有工单体系，避免治理结束后无人维护。

11.5 共享交换与开放

共享交换分为三类场景，规则各不相同。企业内部共享发生在管网、营业、调度、工程、客服之间，重点是主数据一致与服务复用；政务部门共享面向住建、城管、水利、自然资源、应急与消防，重点是目录对接、责任清单与更新频率；社会开放面向公众与第三方，重点是脱敏、许可与可追溯。三类场景若套用同一套办法，往往不是管死就是失控。

政务共享的基础是数据目录与责任清单。每项共享数据应明确提供方、使用方、字段范围、更新频率、交换方式与争议处理机制。典型对象包括供水与排水管线、积水点、水源地与取水口、污水处理厂与泵站、用水户统计等。管线数据涉及城市安全，通常只提供范围与概要属性，精确坐标需按需申请；积水点数据在汛期需要高频更新，频率应在协议中写明，不能等到对方催问才推送。共享协议应每年复核，避免目录长期不更新。

应用程序接口（API）网关是共享交换的技术闸门，承担身份认证、权限校验、流量控制、版本管理与调用审计。服务粒度需要设计：按图层提供整幅数据适合底图类需求，按要素查询适合单点核实，按分析能力提供适合关阀、溯源等复杂场景。网关应强制所有调用携带应用标识与用途标签，便于事后审计与计量；应支持灰度发布与版本共存，避免一次升级导致所有调用方中断。没有网关的“共享”，最终都会退化为拷贝文件和私下传数据。

数据服务目录应以元数据驱动，支持检索、申请、审批、计量与评价。使用者能查到某项服务的字段、坐标系、更新时间、精度与使用限制，才能判断是否适用；提供方能看到调用量、失败率与评价，才能持续改进。目录不宜追求大而全，先接入高频、刚需的服务，再逐步扩展。服务命名要有业务含义，例如“按坐标查询最近阀门”，而不是只有开发人员看得懂的缩写。

隐私与脱敏需要区分数据类别。用户地址、户号、用水量、缴费记录属于个人信息，对外提供时必须聚合或去标识化；聚合口径要防止小样本反推，例如某一小区仅有一户用户时，区间统计也可能暴露个体信息。管线数据中的阀门、调压站等关键设施位置属于敏感信息，公开地图上应做概化处理。脱敏不是一次性工作，而应嵌入数据服务：同一个接口按调用方权限返回不同字段，而不是维护多份脱敏副本。

对外服务应优先采用开放地理空间信息联盟（OGC）标准，包括 WMS（网络地图服务）、WFS（网络要素服务）、WMTS 与 OGC API 系列，以降低对接成本；对内可采用更灵活的私有接口，但需在服务目录中登记并保持文档同步。标准的价值在于可替换性：采用标准服务后，前端地图库、第三方平台与监管系统都能以相同方式接入，不会因为更换软件而重写对接代码。标准化不等于放弃性能，瓦片与矢量切片可以在标准框架内做缓存与压缩优化。

表11-5 典型共享交换场景

11.6 性能与高可用

性能问题往往在特定时刻集中暴露：汛期指挥大屏同时被多个部门打开，早高峰营收与客服查询叠加，应急会商时多人同时做关阀分析，或者一次管线更新后瓦片缓存全部失效。这些场景的共同特点是并发高、时效强、失败代价大。性能设计应从场景出发，先明确每个场景的用户数、请求类型、响应时间要求与可降级方案，再倒推架构与资源，而不是等系统上线后靠加服务器补救。

海量三维渲染的关键是控制单帧加载量。倾斜摄影与点云应转换为三维瓦片，按空间分块与层级细节组织，视点远处加载粗层、近处加载细层；BIM 模型需轻量化，去除内部构件与冗余材质，保留业务关心的设备与空间；大量重复对象如消火栓、井盖应使用实例化渲染。客户端能力差异很大，指挥大屏、桌面浏览器与移动端的承载能力不在一个量级，必须提供分级画质与按需加载策略。三维的价值在于空间关系判断，若为了视觉效果牺牲可操作性，模型再精致也无法支撑业务。

瓦片金字塔的更新策略决定长期运维成本。预切片性能稳定但更新慢，动态切片灵活但服务端压力大，常见做法是底图预切、业务图层动态切片并按热点缓存。管线更新后只重切受影响的范围，瓦片目录带版本号，前端按版本请求，避免新旧瓦片混用造成管线错位。缓存层级应明确：浏览器缓存控制重复访问，反向代理缓存吸收突发流量，服务端缓存降低数据库压力，数据库查询缓存优化复杂分析。每层都要有命中率监控，命中率异常下降往往意味着缓存键设计有误。

并发容量可以用简单的测算方法估算。假设汛期大屏与桌面端合计二百个并发用户、平均每十秒发起一次请求、每次返回二百千字节，峰值带宽约四兆字节每秒，压力主要在服务端渲染而非网络；若同一场景下有一百人同时做缓冲区分析，每次分析涉及数万条管段，则瓶颈会转移到空间数据库的处理器与内存。测算的目的不是追求精确，而是找出瓶颈环节，据此决定是增加缓存、优化查询还是限制并发。

容灾设计应先确定恢复目标。管网数据与营收数据丢失的后果不同，前者影响抢修与调度，后者涉及用户权益与对账，二者的恢复点目标与恢复时间目标应分别设定。常见做法是同城双机房做主备或双活，数据库同步复制保证恢复点，异地备份防止区域性灾害，关键服务准备降级预案，例如三维不可用时回退到二维地图、实时数据中断时展示最近一次快照。容灾能力必须通过演练验证，只做备份不做恢复演练，等于没有备份。

可观测性包括指标、日志与链路追踪三类数据。与 GIS 相关的关键指标有：地图服务平均响应时间、瓦片命中率、空间查询慢查询数量、三维首屏加载时间、接口错误率与超时率。这些指标应写入运维看板并设置阈值告警。性能要求也应写入合同：明确典型场景的并发数、响应时间与可用性，约定验收时的压测方法与数据规模。没有量化条款的性能承诺，在纠纷中无法举证。

表11-6 典型场景的性能目标与保障手段

11.7 安全与合规

《中华人民共和国测绘法》是地理信息应用的基础法律约束。从事测绘活动需要相应资质，测绘成果的获取、持有、提供与利用受法律规范；向社会公开的地图必须经过审核，地图上表示的界线、重要地理信息与设施必须符合规定。水务企业的管线图、厂站布置图、水源地分布图在内部使用与对外发布时适用不同规则，不能把内部系统截图直接用于宣传材料或公众号推文。

涉密地理信息的管理红线是网络隔离。涉密数据不得在非涉密网络存储、传输与处理，确需使用的应在涉密单机或涉密网络中完成，成果经脱密处理后方可进入业务系统。实践中容易出现问题的环节包括：无人机航摄原始影像未经处理上传公有云、三维模型包含精确坐标对外发送、外业人员用个人网盘传输管线数据、开发测试环境直接使用生产数据。这些行为往往出于便利，但一旦发生泄露，责任落在数据持有单位。

网络安全等级保护 2.0 要求信息系统定级、备案、建设整改、测评与监督检查。水务企业的管网 GIS、调度系统、营收系统通常涉及大量用户信息与关键业务，定级不宜过低；被认定为关键信息基础设施的，还须履行更严格的保护义务，包括专门安全管理机构、人员背景审查、年度检测评估与应急预案演练。等保不是一次性测评，而是持续合规，系统架构变更、云平台迁移、接口开放都可能触发重新评估。

数据分类分级是合规工作的抓手。横向按业务领域分为供水、排水、污水、水环境、工程与客户服务；纵向按敏感程度分为公开、内部、敏感、涉密，其中涉密数据单独管理。分类分级结果应落到字段级，明确哪些字段可对外、哪些需脱敏、哪些禁止出库。用户用水数据属于个人信息，处理需遵循最小必要与告知同意原则；聚合后的区域用水统计在满足匿名化要求后，方可作为公共数据开放。

供应链安全近年成为新的风险点。GIS 平台、数据库、三维引擎、地图组件往往由外部厂商提供，组件漏洞、许可变更、服务终止都会影响业务连续性。采购时应要求提供软件物料清单，明确开源组件及其许可证；对境外软件与服务评估出口管制与数据回传风险；对云服务明确数据存放位置、备份策略与退出机制。系统集成商更换时，源代码、数据字典与部署文档的交付必须写入合同，避免被单一供应商锁定。

合规管理应形成清单化流程。新建系统上线前完成定级备案与安全评估；对外发布地图前完成地图审核；涉及个人信息的功能上线前完成隐私影响评估；使用商用密码的场景按要求开展密码应用安全性评估；跨主体共享数据前签订协议并明确责任。每项事务都要有责任部门与触发时点，而不是在检查前集中补材料。合规成本应纳入项目预算，通常只占总投资的小部分，却能避免系统返工甚至停运的风险。

表11-7 合规事项与触发时点

11.8 运维与成本

总拥有成本应覆盖软件许可、硬件与云资源、实施服务、数据生产、运维人力、培训与升级七个部分。很多项目在立项时只计算软件与实施费用，忽略了后续五到八年的数据更新、三维模型修模、接口维护与安全测评支出，导致系统上线后因预算不足而停滞。把全生命周期成本写进立项报告，并区分一次性投入与年度经常性支出，是避免“建得起、养不起”的基本方法。

云资源成本中，对象存储与网络流量往往被低估。遥感影像、无人机视频、三维瓦片体量大，冷数据长期占用标准存储不经济，应按访问频率分层：近期项目数据放标准存储，历史影像转低频或归档存储，瓦片按版本保留最近若干版。外网访问产生的下行流量在公众地图、移动巡检场景中可能持续增长，需通过内容分发网络与压缩控制。计算资源方面，空间分析与三维切片属于短时高负载，适合弹性伸缩，而数据库属于长期稳定负载，适合包年包月。

许可模式的选择影响长期灵活性。永久许可加年度维保适合需求稳定、部署在本地的核心系统；订阅制适合用户数波动大、需要持续升级的场景；按核数或按服务计费的模式要特别注意虚拟化与容器化环境下的计数规则。合同中应明确许可范围、并发定义、二次开发权利、数据导出权利与版本升级政策。许可谈判的核心不是单价，而是五年期的总支出与退出成本。

国产化替代应分层次推进，而不是一刀切。基础设施层包括芯片、服务器、操作系统与数据库，成熟度较高，可优先替换；平台层包括 GIS 平台、三维引擎与中间件，需重点验证空间函数完备性、三维渲染性能与大数据量下的稳定性；应用层受影响最小，但接口适配与前端兼容需要回归测试。替换前应建立性能基线，替换后用相同数据集与相同场景对比，避免出现“功能都有、性能减半”的情况。

运维组织应建立一线服务台、二线技术支持、三线厂商支持的分层机制，明确响应时限与升级路径。日常运维包括账号权限、数据备份、服务监控、版本发布与安全补丁；定期工作包括数据质量抽查、容量评估、容灾演练与账号审计。变更管理尤为关键，管线数据模型调整、接口升级、底图更换都可能影响多个应用，必须有影响评估、回滚方案与通知机制。运维交接时，文档、脚本与账号清单应与系统同步移交。

成本优化有几个见效较快的方向：一是数据分层，把访问频率低的历史影像与归档资料移出高性能存储；二是瓦片按需切片，减少预切范围与重切次数；三是压缩与格式优化，例如三维模型使用几何压缩、影像采用云优化格式；四是资源池化，把多个低负载系统合并到同一集群；五是许可复用，清理长期不用的账号与闲置实例。优化不应以牺牲关键场景的体验为代价，汛期与应急场景的资源必须留有余量。

表11-8 总拥有成本构成与优化手段

本章小结

架构与治理决定了 GIS 能否从展示工具变成生产系统。五层架构与两条纵线的意义在于隔离变化、明确责任，使感知设备的更新、应用需求的变化不至于动摇数据模型与服务接口；时空数据底座的价值在于用统一基准与多模存储支撑分析，而不是把数据堆在一起。

标准与主数据解决“对不上”的问题，质量治理解决“不敢用”的问题，共享开放解决“用不上”的问题。三者互为条件：没有统一编码，质量规则无从判定；没有质量分级，共享出去的只能是风险；没有服务目录，再好的数据也难以被业务发现。

性能、安全与成本是系统能否长期运行的三条底线。性能要在场景中定义并写进合同，安全要按测绘、等保、数据分类分级的底线清单逐项落实，成本要按全生命周期核算并持续优化。任何一项被忽略，都会在系统上线后的第二到第三年集中显现。

对管理者而言，判断一个新项目是否值得投入，可以问四个问题：数据从哪里来、由谁维护、服务被谁复用、三年后的运维费用由谁承担。四个问题都能得到明确回答，架构才算真正落地。

思考与练习

1. 请对照图11-1 与表11-1 辨析“五层”与“两条纵线”的分工：五层划分解决什么问题、两条纵线解决什么问题。若某企业五层都已建成，但感知层的测点编号在平台层找不到对应设施，请判断这是纵线缺失还是层次划分错误，并给出整改顺序。
2. 就你所在单位最近一次信息化立项，按 11.1 节的评审做法补做一份材料：一张数据流图、一份接口清单、一份复用清单。指出其中哪些能力本应由平台层统一提供、哪些应当留在应用侧迭代，并说明“平台只建设被三个以上应用复用的能力”这条原则在本单位是否适用。
3. 某市布设一万个压力与流量测点、每五分钟上报一次。请测算日增记录数与年增记录数（按每年 365 天），若保留五年原始数据，再测算总记录规模；然后结合表11-2 与 11.2 节的冷热分层，给出热、温、冷三层的存储介质与降采样规则。
4. 某管段台账出现三处记录：材质写“球铁”、埋深写“1.2 米”未注明管顶还是管中、阀门口径 DN300 大于所在管段 DN200。请对照表11-3 的取值规则与表11-4 的检查维度，逐条判定问题类型与处置建议，并说明哪些可以直接更正、哪些必须生成外业核查任务。
5. 汛期需要向应急、交警与公众提供积水点数据，同时要向统计部门提供月度用水户统计。请对照表11-5 与表11-7 列出两次共享各自的提供方、使用方、更新频率、敏感级别、合规触发时点与脱敏方式，并说明为什么“用水户统计”在只有一个用户的小区聚合仍可能暴露个人信息。
6. 11.4 节的数据质量治理与前面几章的具体场景互为条件：第 08 章的用水统计口径、第 09 章的竣工即入库、第 10 章的客户地址主数据，最终都要落到本章的“一数一源”。请为管网设施、用户与表具、监测设备三类主数据各指定权威系统与责任部门，指出新建系统应当只读引用还是可以自建，并说明这套安排如何减少第 10 章 10.4 节所说的派单错误。