简介这份资源是面向水利行业信息化建设者、政府水利主管部门及系统集成商的《智慧水利大数据综合管理平台建设方案》文档围绕监测监控体系现状与问题给出从建设目标、原则、内容到周期、投资概算与建设依据的完整实施思路。方案重点梳理通信网络、监测信息接收与管理、业务应用系统、视频会商系统及机房硬件环境等现状并归纳信息化管理体制不统一、数据资源环境分散、应用服务平台缺失、基础设施不健全等主要问题进而提出数据采集集成、数据资源集成、应用服务资源集成与业务应用系统集成的总体架构路径。压缩包共1个文件为单份docx方案文档体积约5.35MB目录层级清晰便于按章节检索查阅。目前已有292人学习下载适合用于项目立项论证、方案编写参考与投标技术思路整理。1. 一份 295 页的水利信息化方案真正能落地的只有四件事很多人拿到《智慧水利大数据综合管理平台建设方案》这类文档第一反应是页数吓人、章节齐全、从现状分析一路写到招投标但真让他动手搭点什么反而不知道从哪里下手。我自己拆过几份类似的方案结论比较反直觉架构图、体系框图、云数据服务体系这些章节占了三分之二篇幅实际能对应到工程动作的只有四件事——把监测终端的数据接进来、把异构数据资源整合成一张表、把业务应用通过统一门户挂出去、把视频会商和机房环境撑住。这份方案的目录结构很典型1 到 4 章讲目标、原则、现状、总体框架5 章讲数据汇集流程、自动终端接收、共享交换、流媒体接入6 章讲水文水资源数据库、共享交换库、云数据服务、备份管理7 章讲应用支撑平台从系统资源服务层到业务服务层8 章是真正的重头戏集成化综合信息展示一口气列了预警监视、水文、工情、地下水、水资源、水质、气象、灾情、凌情、农村饮水、水土保持、农田水利等近二十个查询主题。9、10 章才是网络、会商、机房和招投标。所以这篇不按原目录顺序复述而是按“数据怎么进、库怎么建、应用怎么挂、大屏怎么出、怎么验证”的顺序拆一遍。适合正在做水利、水务、水文信息化项目的开发、集成和实施人员尤其是需要把一份方案文档翻译成技术任务书的人。2. 数据采集与汇集从终端报文到共享交换库的完整链路2.1 为什么先定接入范围再谈协议方案里把“接入范围”和“数据汇集流程设计”放在第 5 章开头这个顺序是对的。水利数据源的异构程度远超一般业务系统水文站用 SL 651 报文水位计走 Modbus RTU部分老站点还在用自定义的 ASCII 帧视频走 GB/T 28181气象和墒情可能是第三方 HTTP 接口。如果一上来就写代码最后一定变成十几个 if-else 堆在一个接收服务里。我一般先产出一张接入清单表把每一类数据源的协议、频率、责任单位、是否可改造列清楚再决定哪些走统一接收、哪些走定制适配。这是后面写代码和排错的基础。数据类别常见协议上报频率接入方式备注水文遥测SL 651 / 自定义报文560 分钟TCP 长连接 报文解析需处理补传和重传水位流量Modbus RTU over TCP110 分钟采集网关轮询注意寄存器偏移视频流GB/T 28181实时流媒体转发不做存储时只做转发气象墒情HTTP/JSON1 小时定时拉取接口限流要处理业务系统数据库直连或 API按需共享交换需字段映射2.2 自动终端数据接收服务的实现方案 5.4 提到的“自动终端数据接收”落到代码上就是一个 TCP 服务加一个解析器。下面是我常用的最小可用骨架用 Python 写方便快速验证协议正式环境再考虑用 Netty 或 Go 重写。import socketserver import struct # 报文头2 字节起始符 2 字节长度 1 字节站号 HEADER b\x7e\x7e STATION_MAP { 1: {name: 示例水文站, type: water_level}, 2: {name: 示例雨量站, type: rainfall}, } class FrameHandler(socketserver.BaseRequestHandler): def handle(self): buf b while True: chunk self.request.recv(1024) if not chunk: break buf chunk while len(buf) 5: if buf[:2] ! HEADER: buf buf[2:] # 丢弃脏数据重新对齐帧头 continue frame_len struct.unpack(H, buf[2:4])[0] if len(buf) frame_len 4: break # 半包等下一次 recv frame buf[4:frame_len 4] self.parse(frame) buf buf[frame_len 4:] def parse(self, frame): station_id frame[0] # 后两字节为 CRC16解析前先校验 payload, crc frame[1:-2], frame[-2:] value struct.unpack(f, payload[:4])[0] meta STATION_MAP.get(station_id, {name: 未知站, type: unknown}) print(f{meta[name]} 上报值{value}) if __name__ __main__: # 监听 8801允许地址复用避免重启时端口占用 socketserver.TCPServer.allow_reuse_address True with socketserver.ThreadingTCPServer((0.0.0.0, 8801), FrameHandler) as srv: srv.serve_forever()这段代码有三个关键点值得说明。第一buf的粘包处理用的是“帧头对齐 长度字段”的方式而不是固定长度切片因为水利终端因网络抖动导致半包非常常见第二遇到非帧头字节时只丢弃两个字节而不是清空缓冲区避免把后续正常帧一起丢掉第三parse里预留了 CRC 校验位置但没实装实际项目里必须补上否则脏数据会直接进库。提示生产环境的接收服务一定要做落盘缓冲。网络中断恢复后终端会批量补传如果解析程序直接写数据库很容易在补传洪峰时把连接池打满。2.3 数据共享与交换机制的落地方式方案 5.8 讲“信息共享交换机制”落到技术上是两件事数据怎么给出去以及给出去的数据怎么保证一致。常见做法是把共享交换库单独建一个 schema业务库到交换库之间用定时任务或 CDC 同步对外只暴露交换库的视图或 API。我一般用一张映射配置表驱动整个同步流程而不是每个表写一段脚本-- 共享交换任务配置表一行代表一个同步任务 CREATE TABLE etl_job_config ( id BIGSERIAL PRIMARY KEY, src_table VARCHAR(128) NOT NULL, -- 源表名 dst_table VARCHAR(128) NOT NULL, -- 目标表名 sync_mode VARCHAR(16) NOT NULL, -- full / incr incr_column VARCHAR(64), -- 增量字段如 update_time last_sync_ts TIMESTAMP, -- 上次同步水位 batch_size INT DEFAULT 2000, enabled BOOLEAN DEFAULT TRUE ); -- 查询待执行的增量任务 SELECT id, src_table, dst_table, incr_column, last_sync_ts FROM etl_job_config WHERE enabled TRUE AND sync_mode incr AND last_sync_ts NOW() - INTERVAL 5 minutes;last_sync_ts是断点续传的核心所有增量任务都必须基于它取数而不是基于当前时间。batch_size控制单批提交量水利数据单表动辄上千万行一次全量拉取会拖垮源库。sync_mode区分全量和增量只有小维表才允许全量。3. 数据资源库设计水文、水资源与共享交换库怎么分工3.1 主题库和交换库不能混为一谈方案第 6 章把“水文、水资源数据库”和“共享交换数据库”并列这个划分有必要但很多项目落地时会偷懒把两套库合并成一套结果就是业务查询和对外共享互相拖累。主题库面向业务分析宽表多、索引多、允许冗余追求查询快交换库面向对外供给结构稳定、变更受控、字段语义明确追求可解释。两者之间应该有一层 ETL而不是让外部系统直连主题库。具体怎么划分可以先定维度再定事实表。库类型面向对象表设计倾向更新频率是否允许外部直连主题库内部业务分析宽表、星型模型分钟小时否共享交换库外部单位/上级平台规范化、字段固定小时天是只读视图原始库数据接入层与报文一一对应实时否元数据库运维管理小表、字典变更时否3.2 水文与水资源主题库的建表思路以水位和降雨为例原始表只负责存储主题表负责查询。原始表按接收时间分区主题表按站点和业务时间做聚合。-- 原始观测表只追加不更新 CREATE TABLE ods_station_obs ( id BIGSERIAL, station_id VARCHAR(32) NOT NULL, obs_time TIMESTAMP NOT NULL, metric VARCHAR(32) NOT NULL, -- water_level / rainfall / flow value NUMERIC(12,3), quality SMALLINT DEFAULT 0, -- 0 未校验 1 正常 2 可疑 3 异常 recv_time TIMESTAMP DEFAULT NOW(), PRIMARY KEY (id, obs_time) ) PARTITION BY RANGE (obs_time); -- 按天分区的示例 CREATE TABLE ods_station_obs_20250101 PARTITION OF ods_station_obs FOR VALUES FROM (2025-01-01) TO (2025-01-02); -- 小时聚合主题表供大屏和报表使用 CREATE TABLE dws_station_hourly ( station_id VARCHAR(32) NOT NULL, stat_hour TIMESTAMP NOT NULL, avg_value NUMERIC(12,3), max_value NUMERIC(12,3), min_value NUMERIC(12,3), sample_cnt INT, PRIMARY KEY (station_id, stat_hour) );quality字段是水利数据特有的来自人工校验和设备自检主题表聚合时可以只取quality 1的记录也可以在遇到可疑值时降权。分区按天做主要因为水利数据的时间跨度长、查询几乎总带时间条件分区裁剪带来的收益很明显。sample_cnt用来识别数据缺失如果某小时样本数明显低于平时说明终端可能掉线这在数据质量监控里是重要信号。3.3 云数据服务体系与备份策略方案 6.4 提到“云数据服务体系建设”实际要做的是把数据能力以服务形式暴露查询服务、订阅服务、统计服务。备份方面我通常按“全量 增量 归档”三层来做而不是只配一个每日全备。#!/bin/bash # 每日全量备份保留 7 天 DATE$(date %Y%m%d) pg_dump -h 127.0.0.1 -U hydro -F c hydro_db /backup/full/hydro_${DATE}.dump find /backup/full -name hydro_*.dump -mtime 7 -delete # 归档库按月保留冷数据迁移后单独备份 pg_dump -h 127.0.0.1 -U hydro -F c hydro_archive /backup/archive/hydro_arc_${DATE}.dump # 校验备份文件可读性避免备份成功但无法恢复 pg_restore -l /backup/full/hydro_${DATE}.dump /dev/null || echo 备份文件损坏: ${DATE}-F c是自定义格式支持并行恢复和压缩比纯 SQL 文本更实用。find -mtime 7保留最近 7 天具体天数按存储容量和恢复目标调整。最后一步的pg_restore -l只读取目录不实际恢复能快速发现备份文件损坏这是我踩过“备份明明成功、恢复时才发现文件不完整”的坑之后加上的。4. 应用支撑平台与集成门户把二十个查询主题挂到一套框架上4.1 应用支撑平台的分层与职责边界方案第 7 章给了五层系统资源服务层、公共基础服务层、应用服务层、业务服务层、服务管理。这个分层本身没问题问题在于很多项目把“公共基础服务”做成了万能垃圾桶最后用户、权限、日志、字典全堆在里面。我的做法是按“是否被两个以上业务系统复用”来判断只被一个系统用的逻辑放在该系统内跨系统的才上移。这样公共层不会膨胀边界也清楚。鉴权是公共基础服务里最容易做错的。水利项目里常见的是门户 SSO 加业务系统自建账号两套并存用户抱怨要记两个密码。合理的做法是统一走一套令牌业务系统只做本地授权不做本地认证。// 前端统一的令牌注入所有业务请求都带同一枚 token const request axios.create({ baseURL: /api, timeout: 15000 }); request.interceptors.request.use(config { const token sessionStorage.getItem(hydro_token); if (token) { config.headers[Authorization] Bearer ${token}; // 统一头部 } // 业务系统标识便于网关做路由和限流 config.headers[X-System-Code] window.__SYSTEM_CODE__; return config; }); request.interceptors.response.use( res res.data, err { // 401 统一跳转门户登录不在各业务系统里重复实现 if (err.response err.response.status 401) { window.location.href /portal/login; } return Promise.reject(err); } );X-System-Code这个头是给网关用的不同业务系统可以据此做独立限流和审计排查问题时能直接定位是哪个系统在打接口。令牌放sessionStorage而不是localStorage是因为水利内网终端经常多人共用会话级存储更符合实际使用习惯。4.2 集成门户与业务应用接入方式方案 8.4 讲“综合业务管理接入与集成”8.5 讲“集成门户管理”。技术上有三种接入方式选哪种取决于老系统的改造意愿。接入方式适用场景用户体验改造工作量风险iframe 嵌入老系统无法改造一般样式不统一低跨域、cookie 问题页面级集成微前端前端可改造好中需要约定路由和通信接口级集成只要数据不要界面好中高需要对方提供稳定 API反向代理聚合多系统同一域好低需处理路径冲突和鉴权透传微前端接入时子应用要注册生命周期并声明挂载点主应用负责路由分发和共享状态。关键是子应用不能再自己初始化一套全局样式和请求库否则会出现样式污染和重复拦截器。注意iframe 方案看起来最省事但子系统的X-Frame-Options、SameSiteCookie 和内网证书问题会在联调阶段集中爆发最好在方案阶段就确认这些细节不要留到上线前。4.3 预警监视与查询专题的通用实现方案 8.3 列了近二十个查询专题如果每个专题各写一套页面维护成本会失控。我的做法是抽象出一套“查询专题配置”数据源、字段、筛选条件、图表类型全部配置化页面用同一个渲染器加载不同配置。{ topicCode: water_level_query, topicName: 水文信息查询与分析, dataSource: dws_station_hourly, dimensions: [station_id, stat_hour], metrics: [ { field: avg_value, label: 平均水位, unit: m }, { field: max_value, label: 最高水位, unit: m } ], filters: [ { field: station_id, type: multiSelect }, { field: stat_hour, type: dateRange, required: true } ], chartType: line, alertRule: { field: max_value, operator: , threshold: 5.0 } }required: true的筛选条件必须强制用户填写否则时间范围不设限会全表扫描。alertRule复用了预警监视的阈值配置查询页和预警页共享同一份规则避免两处配置不一致。这套配置化思路对防汛、防旱、水资源、防凌这些专题都适用区别只在指标和阈值。5. 集成化综合信息展示与预警监视的大屏落地技巧5.1 大屏数据接口的最小化设计8.3.1 的预警监视集成方案最终要落在一块大屏上。大屏接口有个通病为了省事前端直接调多个明细接口再自己聚合结果刷新一次打十几个请求页面卡顿。我的做法是给大屏单独设计聚合接口一次返回页面上所有卡片需要的数据。-- 预警监视大屏按站点返回最近状态与是否越限 SELECT s.station_id, s.station_name, o.metric, o.value, o.obs_time, CASE WHEN o.value t.threshold_value THEN 1 ELSE 0 END AS is_alert, t.threshold_value FROM dim_station s JOIN LATERAL ( SELECT metric, value, obs_time FROM dws_station_hourly WHERE station_id s.station_id ORDER BY stat_hour DESC LIMIT 1 ) o ON TRUE LEFT JOIN alert_threshold t ON t.station_id s.station_id AND t.metric o.metric WHERE s.enabled TRUE;LATERAL子查询取每站最新一条比用窗口函数再过滤更直观。LEFT JOIN阈值表是为了兼容还没配阈值的站点这类站点应该显示为“未配置”而不是“正常”否则会掩盖配置缺失。enabled过滤掉已停用站点大屏上不应该出现废弃站。5.2 流媒体接入与视频会商环境的关键参数方案 5.7 和 9.3 涉及流媒体与会商。GB/T 28181 接入时最容易出问题的是心跳和注册有效期两个参数。心跳间隔太短会浪费带宽太长会导致设备被判离线注册有效期必须大于心跳间隔的两倍以上否则设备会在正常心跳之间被踢下线。参数建议值说明心跳间隔60 秒内网可放宽到 120 秒注册有效期3600 秒必须远大于心跳间隔流传输方式TCP 优先丢包环境下比 UDP 稳定视频转发模式按需转发避免所有点位同时拉流关键帧间隔2 秒以内影响首帧显示速度按需转发是重点。如果所有点位都在平台启动时同时拉流出口带宽会瞬间打满实际使用中绝大多数点位根本没人看。会话开始时拉流、结束就释放这是最经济的方式。5.3 平台上线前的验证清单与排错顺序平台做完不能只看页面能不能打开要按数据链路从下往上验。我一般会按下面的顺序排查因为上游有问题时下游的现象会互相干扰。终端接入层抽查三个不同厂商的终端确认数据能收、能落库、有质量标记。存储层查最大分区和最小分区的时间边界确认分区自动创建任务没有失效。聚合层对比源表和聚合表同一小时的sample_cnt差异超过阈值就说明聚合任务漏跑。服务层用同一令牌分别访问网关和业务接口确认鉴权透传没有断。展示层断网重连后看大屏是否自动恢复超时和重试逻辑最容易在这里暴露。# 检查最近一小时聚合任务是否有漏跑 psql -h 127.0.0.1 -U hydro -d hydro_db -c SELECT date_trunc(hour, obs_time) AS h, count(*) FROM ods_station_obs WHERE obs_time NOW() - INTERVAL 3 hours GROUP BY 1 ORDER BY 1; # 检查服务端口与进程状态 ss -lntp | grep -E 8801|8080|5060第一条 SQL 按小时统计原始表记录数如果某个小时明显偏低先查接收服务而不是聚合任务。第二条确认接收服务、网关、流媒体端口都在监听5060是 GB/T 28181 常用信令端口端口没起就不用往下查了。最后一招是给关键链路打时间戳。在接收、落库、聚合、接口返回四个位置各记一次时间出问题时能直接看出卡在哪一段比反复猜要快得多。这套时间戳日志在验收阶段的价值往往比多做几个查询页面更高。本文还有配套的精品资源点击获取