简介这套70页PPT是一份面向煤矿行业信息化建设者、智慧矿山项目规划人员与方案架构师的完整解决方案系统梳理了智慧矿山数据中台及管控一体化平台的建设路径。内容从煤矿行业背景切入列举神东、陕北等13个亿吨级煤炭能源基地对比井工与露天煤矿的主要工艺流程并指出矿山数据融合困难、被动式故障监测、缺少多系统协同联动与大数据分析等现实痛点在此基础上结合物联网、云计算、大数据、人工智能、自动控制等技术阐述了智慧矿山的定义与建设规划突出数据中台在数据存储、计算、分析、服务中的作用以及管控一体化平台如何实现人、机、环、管的智能协同与辅助决策。压缩包内为1个pptx文件大小23.98MB包含70页图文兼顾行业现状、痛点分析、方案设计与推广计划可直接用于项目立项、售前交流或内部培训。已有42人学习下载适合作为智慧矿山领域的高质量参考资料。1. 智慧矿山的数据中台先别急着上湖仓一体矿业集团的数据部门大多遇到过同一个场景安全生产管控平台上显示今日产量是12000吨MES里查到的是11850吨调度日报又是12300吨。三个数都来自各自的源系统但没有人能第一眼判断哪个才是对的。智慧矿山不是缺数据是缺一套能让数据对得上账的中间层。数据中台在矿山场景里核心职责不是把数据库全部搬到一个湖里而是完成跨系统的编码统一、时序数据治理、指标口径收敛让管控一体化平台上的每个数字都有血缘可查、有责任可追。下面的内容写给正在做智慧矿山数据底座的技术负责人按数据域建模、管控链路、冷热存储三条线把方案拆开每一步都能拿去对齐实际需求。2. 矿山数据中台的四个数据域与分层建模2.1 先分域哪些数据必须进中台哪些留在边缘矿业信息系统表面上很多但按数据性质可以归成四类。生产域包括采掘、运输、提升、选矿环节的班报和工况数据安全域包括瓦斯、粉尘、水害、边坡监测、人员定位等报警与测点数据设备域包括PLC、传感器、点检记录和维修工单经营域包括物资消耗、能耗、销售和人力成本。四类数据的产生频率和口径差异很大IoT数据5秒一条业务数据一天几条如果全部按同一套频率采集中台会变成存储黑洞。实际操作里我一般先做一次源系统盘点用一张表格把每个源系统的数据域、更新频率、主键、是否有时间字段列出来。这一步决定后续DWD层能做到多干净。智慧矿山数据中台不需要纳管所有数据边缘侧能独立闭环的比如皮带保护装置本机报警让边缘网关直接处理只有需要跨系统关联、上级调度、事后审计的数据才进入中台。这个取舍能省下差不多一半的存储和链路成本。2.2 四层模型在矿山的具体映射行业里数据中台普遍采用 ODS、DWD、DWS、ADS 四层划分矿山场景不是另起炉灶但每层的内容要有现场感。ODS层保留源系统原样数据全量落地每小时增量同步DWD层做清洗把吨和t统一把设备编码从BD-01改成集团标准编码JIAO_EC_SHAFT_01DWS层按主题汇总形成设备开动率、安全报警量、日产量等当日指标ADS层面向管控一体化平台输出服务化数据比如大屏指标、调度看板、告警联动所需字段。下面这段 Hive/Spark SQL 是DWD层清洗的典型写法处理的是产量数据编码统一的问题-- 智慧矿山DWD层产量明细清洗示例 INSERT OVERWRITE TABLE dwd_prod_yield_detail PARTITION (stat_date) SELECT standard_mine_code, -- 集团标准矿井编码 CASE WHEN source_system MES THEN workface_id ELSE mapping_workface_id END AS workface_id, -- 作业面ID统一 CAST(REPLACE(yield_value, t, ) AS DECIMAL(12,2)) AS yield_ton, biz_time, current_timestamp AS etl_time, MES|EXCEL_IMPORT AS source_flag -- 记录来源便于血缘反查 FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY source_system, biz_time, workface_id ORDER BY etl_time DESC) AS rn FROM ods_prod_yield_raw WHERE stat_date ${bizdate} ) t WHERE rn 1; -- 同一时刻同一工作面只保留最新一条这段SQL做三件事一是通过ROW_NUMBER去重解决MES系统和人工上报并存时同一时刻产量重复的问题二是把不同的质量单位统一成吨三是把源系统的作业面ID映射到集团编码。参数方面${bizdate}是调度系统传入的业务日期source_flag字段用于后期排查某个数字到底来自哪个源系统。生产环境里我还会加一条质量规则产量为负或超过额定产能5倍的记录直接进异常表不进入DWS层。2.3 编码统一跑不掉中台的第一个硬仗矿山行业编码混乱是普遍问题——一个集团下属三个矿各有一套设备编码、巷道编码、作业面编码。管控一体化平台要做到跨矿对比中台就必须建三套基础映射表设备映射、作业面映射、物料编码映射。编码映射表本身要持久化不能一次性在SQL里用CASE WHEN写死。因为新的设备会不断接入映射需要运营维护。编码映射表建议设计成dim_mapping_code带生效区间结构如下映射类型源系统编码集团标准编码生效日期失效日期维护人设备编码MES:BD-01JIAO_EC_SHAFT_012024-01-019999-12-31数据组作业面3#LeftFaceFACE_HB_3L2024-06-019999-12-31生产部DWD层每次调度都通过时间区间关联这张表保证编码只有一个权威版本。这里容易被忽视的是修改映射表要有审计不能直接UPDATE否则历史数据的分区重算会跟着出错。每次调整映射都生成一个新批次再回刷近7天分区保留时间版本。编码映射表建好后DWD层的主数据维度才立得住后面DWS、ADS才能按同一套口径聚合。这一步在智慧矿山数据中台里是所有下游应用的地基磨刀不误砍柴工。3. 管控一体化平台的数据链路报警联动与指标闭环3.1 不要做大屏聚合要做事件闭环很多管控一体化平台在实践中最后变成了数据大屏十几个图表轮播按钮点了只有漂亮的曲线没有处置动作。真正的管控是要把数据变成指令比如瓦斯超限不仅要在屏幕上变红还要自动判断当前作业面人员是否在限制区域通风机是否运行再决定是声光报警还是直接触发撤人流程。数据中台在这里扮演的是链路中枢。安全监测系统产生一条报警原始事件中台实时链路把这条事件与人员定位、设备状态、当班计划做关联输出一条带上下文标签的待处置事件管控一体化平台拿到这条已关联的数据直接展示并调用流程引擎发出工单。这样中台的作用不再是攒数据而是把数据变成可以被管控流程消费的决策原料。3.2 实时联动示例瓦斯超限事件关联这里用 Flink SQL 来写实时关联逻辑常见做法是把三条流先经 Kafka 接入再按矿井和作业面进行五秒的窗口关联-- 管控一体化平台实时关联瓦斯报警 人员定位 通风机状态 CREATE TABLE kafka_gas_alarm ( -- 瓦斯报警事件流 mine_code STRING, face_id STRING, gas_value DOUBLE, alarm_level STRING, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 10 SECOND ) WITH (connector kafka, topic gas-alarm, format debezium-json); CREATE TABLE kafka_person_loc ( -- 人员定位事件流 mine_code STRING, face_id STRING, person_count INT, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 10 SECOND ) WITH (connector kafka, topic person-location); CREATE TABLE kafka_fan_status ( -- 通风机状态流 mine_code STRING, face_id STRING, fan_speed DOUBLE, status STRING, event_time TIMESTAMP(3), WATERMARK FOR event_time AS event_time - INTERVAL 10 SECOND ) WITH (connector kafka, topic fan-status); INSERT INTO ads_control_decision SELECT g.mine_code, g.face_id, g.gas_value, p.person_count AS inside_person_cnt, f.status AS fan_run_state, CASE WHEN g.gas_value 1.0 AND f.status RUNNING THEN ALARM_EVACUATE WHEN g.gas_value 0.8 THEN ALARM_RESTRICT ELSE MONITOR END AS decision, CURRENT_TIMESTAMP AS calc_time FROM kafka_gas_alarm g LEFT JOIN kafka_person_loc p ON g.mine_code p.mine_code AND g.face_id p.face_id AND p.event_time BETWEEN g.event_time - INTERVAL 20 SECOND AND g.event_time LEFT JOIN kafka_fan_status f ON g.mine_code f.mine_code AND g.face_id f.face_id AND f.event_time BETWEEN g.event_time - INTERVAL 20 SECOND AND g.event_time;这段SQL把三条流按矿井和作业面关联输出一个决策字段。关键参数是20秒的关联窗口——太小会丢掉排队的数据太大会把上一班的撤离信息也关联进来导致误判。WATERMARK延迟10秒是为了容忍Kafka分区乱序。生产上建议把decision这个枚举值先写到一份配置表里阈值可以动态调整不要写死在SQL里否则安全规程一改就要重跑作业。除了Flink实时链路管控一体化平台还需要定期计算如月累计产量达成率选矿回收率万吨耗电量这类超越现场实时状态的全局指标。这类指标走DWS层每日批处理在平台里以卡片形式展示背后的数据血缘可以直接追溯到一个日汇总表和实时链路分开避免当日实时指标和月度汇总数字在时间口径上打架。3.3 批量与实时的边界别搞混管控一体化平台最常出的问题不是链路不通而是实时指标和批量指标对不上。比如上午10点看到的今日产量是实时流算的下午变成了批量任务覆盖的值两个数差了几十吨使用者就会对平台失去信任。我常用的对策是对指标做链路分级先明确每一类指标的服务对象和更新频率链路类型更新频率典型数据服务对象实时链路秒级瓦斯报警、断电联锁、人员超时调度大屏、联动工单准实时链路分钟级设备OEE、当班产量班组长看板批量链路日级/小时级产量结算、能耗成本、回收率经营分析、月度考核三种链路不混用不在一个看板上展示同名义的指标。另外中台的调度系统要清楚标注每张ADS表的产出时刻平台端前端加一个数据时间的展示字段比如产量时间2024-06-30 09:00批量结算。这既是对数据团队的倒逼也是让业务方理解数据延迟的抓手。管控一体化平台的信任恰恰来自这些如实的时间标签而不是大屏的画质。4. 时序数据的冷热分层与归档表设计4.1 先算账一个矿井一年产生多少时序数据智慧矿山的核心数据类型是时序测点。以一个中型矿井为例安全监测、环境监测、设备状态加在一起约2000个测点5秒采集一次一天就是 2000 × 17280 ≈ 3456万条记录。一年超过120亿条。如果不做分级存储任何中台都会被拖垮查询性能也会随时间线性下降。热点查询当班报警、近7天趋势访问量最大历史审计事故回溯、月度分析访问量小但查询范围大这两类需求天然有冲突。提示时序测点数不要一律入湖先按应用实际访问频率分类否则冷热分层会变成空话。数据中台里的冷热数据不能靠感觉划分。我一般把时序数据分成三段热数据7天内温数据7到180天冷数据180天以上。热数据放ClickHouse或Doris的本地SSD温数据放普通HDFS/对象存储但保留在可查询分区中冷数据转入归档表并做列级裁剪。下表是常用分级策略实际设置可根据矿规模和硬件预算调整级别保留范围存储介质压缩算法查询特征归档表标记热7天ClickHouse SSDLZ4秒级交互、告警联动is_cold0温180天Hive/对象存储ZSTD月度报表、班组对比is_cold0冷3年起对象存储归档表ZSTD/加密审计、年度回溯is_cold14.2 归档表设计原则分区和列裁剪缺一不可冷热数据分层最容易被做成把旧数据DELETE。删除确实释放了空间但矿山行业有安全规程和设备生命周期审计要求三年的测点数据通常需要保留。常见做法是设计独立的归档表用stat_date进行月度分区并按测点ID做桶划分配合列式存储和按需列裁剪。这里给出ClickHouse冷热分离建表的参考-- 智慧矿山时序测点冷热分离表按月份分区 CREATE TABLE wh_mine.time_series_metric ( stat_date Date, mine_code LowCardinality(String), face_id LowCardinality(String), metric_code LowCardinality(String), sample_time DateTime64(3), metric_value Float64, quality_flag UInt8, -- 0:正常 1:插值 2:异常 is_cold UInt8 DEFAULT 0 -- 归档标记0热/温1冷 ) ENGINE MergeTree PARTITION BY toYYYYMM(stat_date) ORDER BY (stat_date, mine_code, face_id, metric_code, sample_time) TTL stat_date INTERVAL 7 DAY TO VOLUME cold_volume SETTINGS storage_policy hot_cold_policy;这个表的关键参数有三个。PARTITION BY toYYYYMM(stat_date)决定了按月度裁剪查询带上stat_date范围时能快速跳过无关分区。ORDER BY决定了索引粒度时间矿井作业面测点是最贴合矿山查询习惯的顺序。TTL ... TO VOLUME cold_volume让数据在7天后自动迁移到配置的冷存储卷迁移过程对查询透明改写无需人工介入。这里用TTL自动迁移而非应用层删除避免了漏执行任务导致存储暴涨的情况。我的经验是is_cold标记不是必需的如果TTL已经按volume桶区分物理介质可以省掉靠系统元数据判断冷热。需要保留这个字段的原因是管控一体化平台某些查询想主动排除冷数据比如近半年趋势图不查三年数据加WHERE is_cold 0能显著减少扫描量。4.3 让归档表承担回溯查询别让它拖沓冷热分层之后常见的新问题是需要一个跨热温冷三段的查询能力例如做年度事故回溯要求把某几天的完整时序导出。这是数据中台的冷热数据最容易被低估的难点。如果直接在Flink SQL里查冷存储可能因为对象存储拉取慢把实时链路拖死。我常用的做法是异步归档查询通道。把大范围的冷数据查询请求转成一条异步任务任务从归档表按分区读取结果写回一张导出结果表完成后通知平台端下载。查询超时设成30秒超过就提示用户走异步。这样既照顾了审计需求又让热数据查询永远保持在秒级。下面是一个归档查询任务的核心逻辑把一次回溯查询拆成按月循环的多个分区扫描-- 归档表异步查询按分区批量扫描并合并结果 INSERT INTO ads_cold_export_result SELECT export_id, stat_date, face_id, count() AS sample_cnt, avg(metric_value) AS avg_value, max(metric_value) AS max_value, min(metric_value) AS min_value FROM wh_mine.time_series_metric WHERE export_id EXP_20240630_01 AND stat_date BETWEEN 2024-01-01 AND 2024-06-30 AND face_id IN (FACE_HB_3L, FACE_HB_4R) GROUP BY export_id, stat_date, face_id ORDER BY stat_date;注意这个查询的过滤条件全部包含在分区键和排序键里stat_date走分区裁剪face_id走稀疏索引。在几亿行冷数据上返回月汇总通常在几秒内可完成。实际调优中export_id要提前在调度里生成并按月拆成子批次不要让单条SQL扫描半年以上全量数据一次扫描太多分区反而比循环扫描慢因为单个大查询会在读取对象存储时出现大量并发退避。5. 验证中台是否真正支撑起管控一体化数据血缘与健康度检查5.1 三个健康度指标缺一个都不行从平台管理者视角判断中台是否持续可用的不是任务没挂而是数据链路新鲜、正确、可回溯三个维度。具体我会每天检查三个指标。数据新鲜度每张ADS表的上次产出时间与调度计划偏差超过30分钟即告警。数据准确率DWD层质量规则拦截到的异常记录数占当日总记录数比例超过阈值则暂停DWS依赖该表的任务。血缘覆盖率ADS报表中有血缘关系可查的占比目标是不低于95%。这三项指标直接写进中台的运营大屏每天早会先看它们。5.2 用血缘反查快速定位数据对不上管控一体化平台上线后最有价值的是数据血缘。业务方发现异常时通过血缘可以把异常报表追溯到源系统记录。常见做法是中台自动记录每张ADS表的SQL解析结果形成source_table → target_table的邻接表。排障时从问题指标反向展开依赖图定位是源系统脏数据、映射变更还是加工逻辑变更。下面是一段Neo4j/Cypher的写法适配ERP、MES、中台表血缘反查的场景// 从控制平台指标表反查依赖链 MATCH path (target:ADS {name: ads_control_decision})-[:DEPENDS_ON*1..3]-(src) RETURN path ORDER BY length(path) DESC, src.source_system LIMIT 30;执行后可以看到ads_control_decision表依赖的Kafka主题、DWD表、维度映射表以及各自的源系统标注。实际使用中还有一条好经验每个DWD/DWS表建表时DDL注释里写入业务口径说明负责人血缘和口径文档放在一起能减少一半的指标口径扯皮。5.3 冷热规则调整的一个落地技巧最后分享一个容易被忽略的细节在完成TTL配置并上线后别直接把冷/热存储参数写死在建表语句里。很多团队上线半年后调整热数据保留期发现要重建表导致历史分区全部重建。在ClickHouse里可用动态修改TTL的方式避免这种问题。ALTER TABLE wh_mine.time_series_metric MODIFY TTL stat_date INTERVAL 14 DAY TO VOLUME cold_volume;MODIFY TTL能即时把热窗从7天调整为14天后台线程会在下一次合并时把边界前移的数据迁移到冷存储。需要注意修改TTL后要观察system.parts里move_ttl_info的状态确认历史分区的迁移目标正确否则新老数据会混在同一个卷上。另一个技巧是把TTL阈值做成配置中心的参数每天由调度任务检查配置是否变化有变化才执行ALTER TABLE避免每次发布重复执行相同DDL造成元数据版本膨胀。当采集频次从5秒一测升级到秒级、设备测点翻倍时这套参数化规则只需要在配置中心改一个值剩下的由中台自动完成迁移。本文还有配套的精品资源点击获取