严格基于指定文件（核心为《01智慧城市一网统管平台-系统总体架构及其功能要点》《03智慧城市一网统管平台-系统数据库表》《05智慧城市一网统管平台 数据中枢系统功能设计》《06行业应用系统功能设计-01城管住建.docx》《02数据库表设计命名规范及英文简称对照表》），拆解城管住建领域“物联网设备→数据中枢→业务应用”的全链路数据流转逻辑，所有架构节点、数据存储、流转规则均来自文件原文，不涉及外部信息。

一、数据流转架构总览：文件依据与核心目标

根据《01总体架构》2.2节“数据中枢定位”及《06-01城管》3.1节“数据驱动治理”要求，城管住建数据流转的核心目标是实现“设备数据实时接入、中枢统一处理、业务精准应用”，解决传统“数据割裂、流转断点、应用脱节”痛点（《01总体架构》P11）。
核心支撑文件及作用：

• 《05数据中枢》：提供“设备接入、数据清洗、存储分发”的核心模块，是数据流转的“中枢枢纽”；

• 《03数据库表》：按“基础层（sys_）→业务层（biz_）→统计层（stat_*）”分层存储流转数据，符合《02命名规范》；

• 《06-01城管》：明确物联网设备类型（如市政传感器、违建摄像头）与业务应用场景（如设施监测、违建处置），定义流转边界。

数据流转总体链路如下（基于文件的三层架构）：

graph LR
A[物联网设备层] -->|实时采集| B[数据中枢层]
B -->|清洗/存储/分发| C[城管住建业务应用层]
C -->|处置结果反馈| B[数据中枢层]

二、第一层：物联网设备层——数据采集源头（文件定义的设备类型与采集规则）

2.1 设备类型与数据内容（《06-01城管》《05数据中枢》）

根据《06-01城管》3.2-3.7节专题需求，城管住建需接入6大类物联网设备，每类设备对应明确的数据采集内容，均需关联《03数据库表》的设备基础信息：

设备类别	具体设备（文件依据）	采集数据内容（对应《03数据库表》字段）	采集频率（文件要求）
市政设施设备	路灯亮度传感器、井盖定位器、管网压力传感器（《06-01城管》3.2节）	路灯亮度（brightness）、井盖开合状态（open_status）、管网压力（pressure）→ 存储至biz_device_telemetry_data	实时（10秒/次）
市容秩序设备	占道经营AI摄像头、违规广告识别摄像头（《06-01城管》3.3节）	违规行为图片（image_url）、识别结果（recog_result）→ 存储至biz_ai_image_recognition	事件触发（检测到违规时采集）
环境卫生设备	垃圾站满溢传感器、公厕人流量计数器（《06-01城管》3.4节）	垃圾填充率（fill_rate）、公厕实时人数（people_count）→ 存储至gen_garbage_collect_supv/gen_public_toilet_supv	定时（1分钟/次）
园林绿化设备	土壤湿度传感器、病虫害监测摄像头（《06-01城管》3.6节）	土壤湿度（humidity）、叶片病害程度（disease_level）→ 存储至biz_device_telemetry_data	定时（5分钟/次）
违建治理设备	违建监测AI摄像头、卫星遥感设备（《06-01城管》3.5节）	建筑轮廓变化（contour_change）、违建面积（illegal_area）→ 存储至biz_ai_image_recognition/gen_illegal_build_clue_mng	定时（1小时/次，卫星遥感每日1次）
建筑工地设备	噪音传感器、扬尘传感器、施工进度摄像头（《06-01城管》3.7节）	噪音值（noise）、扬尘浓度（pm25）、施工机械状态（mach_status）→ 存储至biz_device_telemetry_data	实时（5秒/次，噪音/扬尘）；定时（30分钟/次，进度）

2.2 数据采集与接入规则（《05数据中枢》《01总体架构》）

1. 接入协议：所有设备需通过MQTT协议接入（《05数据中枢》20.7.3节“设备接入协议”），数据格式为JSON，字段命名需符合《02命名规范》（snake_case），如“路灯亮度”字段名必须为brightness；

2. 设备注册：设备需先在《03数据库表》sys_device表完成注册（录入device_code设备编码、device_type设备类型、area_code所属区域），未注册设备数据将被数据中枢拦截（《05数据中枢》20.7.1节“设备注册管理”）；

3. 数据预处理：设备采集数据需经过“格式校验+范围过滤”（如噪音值需在30-120dB之间），无效数据（如超出范围、字段缺失）存储至biz_device_invalid_data（设备无效数据表），并触发预警（《05数据中枢》20.7.4节“数据清洗”）。

三、第二层：数据中枢层——数据处理核心（文件定义的“接入→清洗→存储→分发”闭环）

数据中枢是城管住建数据流转的“核心枢纽”，基于《05数据中枢》20.7（设备管理）、20.8（运行监测）、20.9（预警告警）、20.10（指挥协调）模块，实现数据全生命周期处理，每环节均关联《03数据库表》存储。

3.1 第一步：数据接入（对接设备层，《05数据中枢》20.7节）

• 核心模块：设备管理模块的“设备接入网关”，负责接收所有物联网设备的MQTT数据；

• 关键操作：

  1. 验证设备合法性：通过device_code查询sys_device表，确认设备已注册且状态为“启用（enable_status=1）”；

  2. 数据格式转换：将设备JSON数据转换为《03数据库表》字段格式，如将设备上报的“lamp_brightness”转换为brightness（符合《02命名规范》）；

  3. 数据暂存：合法数据暂存至Kafka队列（《01总体架构》P83“关键组件”），等待清洗；无效数据记录至biz_device_invalid_data，并推送预警至biz_early_warn_alert（预警类型：“设备数据无效”）。

3.2 第二步：数据清洗与融合（《05数据中枢》20.8节）

• 核心模块：运行监测模块的“数据清洗引擎”，解决“数据格式不统一、冗余重复、关联缺失”问题；

• 关键操作：

  1. 格式统一：将不同设备的同类型数据标准化（如所有亮度数据统一为“流明”单位），存储至biz_device_telemetry_data表；

  2. 冗余剔除：删除重复数据（如10秒内同一设备上报的相同亮度值），保留最新一条；

  3. 数据融合：关联多源数据，如将“违建摄像头数据”（biz_ai_image_recognition）与“区域数据”（sys_area）融合，补充area_name区域名称，生成gen_illegal_build_clue_mng（违建线索表）；

• 文件依据：《05数据中枢》20.8.2节“数据清洗规则”、《02命名规范》P5“业务表字段统一要求”。

3.3 第三步：数据存储（分层存储，《03数据库表》《02命名规范》）

根据《02命名规范》“数据库表分层设计”，数据中枢将清洗后的数据按“基础层→业务层→统计层”存储，支撑后续业务应用调用：

存储层级	对应数据表（《03数据库表》）	存储数据类型	支撑场景（文件依据）
基础层（sys_*）	sys_device（设备基础）、sys_area（区域基础）、sys_dict_*（字典表）	设备注册信息、行政区划、数据字典（如设备类型、预警等级）	所有业务应用的基础数据支撑（如设备归属区域查询）（《06-01城管》3.2节）
业务层（biz_*）	biz_device_telemetry_data（设备遥测）、biz_ai_image_recognition（AI识别）、biz_early_warn_alert（预警）	设备实时数据、AI识别结果、预警事件	市政设施监测、违建识别等实时业务（《06-01城管》3.5节）
业务层（gen_*）	gen_illegal_build_clue_mng（违建线索）、gen_garbage_collect_supv（垃圾清运）	行业专属业务数据（城管住建细分场景）	违建处置、环境卫生监管（《06-01城管》3.4节）
统计层（stat_*）	stat_urban_fac_status（设施状态统计）、stat_illegal_build_handle（违建处置统计）	分钟/小时/日维度的统计数据（如设施完好率、违建整改率）	核心指标计算、大屏展示（《06-01城管》3.1节大屏总览）

3.4 第四步：数据分发（推送至业务应用，《05数据中枢》20.10节）

• 核心模块：指挥协调模块的“数据分发引擎”，按“业务需求+权限控制”推送数据至对应业务应用；

• 分发方式与规则：

  1. 实时推送：高优数据（如违建预警、噪音超标）通过WebSocket推送至《04我的工作台》“我的预警”模块（《05数据中枢》20.9.4节“预警推送”），推送延迟≤10秒；

  2. 定时拉取：统计数据（如设施日完好率）通过API接口（/api/v1/data/stat/urban）供业务应用定时拉取，拉取频率≤5分钟/次（《05数据中枢》20.8.3节“数据查询接口”）；

  3. 权限控制：分发数据需按area_code（区域）、dept_id（部门）过滤（如西湖区城管仅能获取area_code=330106的数据），权限信息来自《03数据库表》sys_user_role（用户角色）、sys_role_data（角色数据权限）（《05数据中枢》20.15.2节“数据权限控制”）。

四、第三层：业务应用层——数据消费终端（城管住建六大专题应用）

业务应用层是数据流转的“最终消费端”，基于《06-01城管》3.2-3.7节六大专题，每类应用均通过“调用数据中枢API+关联数据库表”实现数据消费，同时将处置结果反馈至数据中枢，形成闭环。

4.1 专题应用与数据中枢的对接逻辑（文件依据）

专题应用	调用数据中枢模块/接口（《05数据中枢》）	消费数据类型（《03数据库表》）	处置结果反馈（更新数据表）
市政设施专题	20.8节“运行监测”接口（/api/v1/monitor/fac/status）；20.9节“预警告警”接口	biz_device_telemetry_data（设备状态）、sys_urban_fac（设施基础）	设施维护工单结案后，更新sys_urban_fac的fac_status（恢复正常）、biz_urban_evt_wo的deal_status（已结案）
违建治理专题	20.16节“AI监测识别”接口（/api/v1/ai/recog/illegal-build）；20.10节“指挥协调”接口	biz_ai_image_recognition（AI识别）、gen_illegal_build_clue_mng（违建线索）	违建拆除后，更新gen_illegal_build_disposal的disposal_status（已拆除）、stat_illegal_build_handle的rectify_rate（整改率）
环境卫生专题	20.8节“运行监测”接口（/api/v1/monitor/garbage/fill-rate）；20.7节“设备管理”接口	gen_garbage_collect_supv（垃圾填充率）、biz_device_telemetry_data（公厕人流）	垃圾清运完成后，更新gen_garbage_collect_supv的fill_rate（0%）、biz_urban_evt_wo的finish_time（结案时间）
建筑工地专题	20.8节“运行监测”接口（/api/v1/monitor/construction/noise）；20.9节“预警告警”接口	biz_device_telemetry_data（噪音/扬尘）、gen_construction_qual（资质）	噪音超标整改后，更新biz_early_warn_alert的handle_status（已解除）、gen_construction_schedule的rectify_status（已整改）

4.2 数据流转闭环示例（以“违建治理”为例，《06-01城管》3.5节）

1. 设备层：违建AI摄像头采集建筑轮廓变化数据，通过MQTT协议上报数据中枢；

2. 数据中枢层：

   • 接入：验证摄像头device_code（sys_device表），确认合法后暂存Kafka；

   • 清洗：转换数据格式，关联sys_area表补充区域信息，生成违建线索（gen_illegal_build_clue_mng）；

   • 存储：线索数据存入gen_illegal_build_clue_mng，AI识别结果存入biz_ai_image_recognition；

   • 分发：通过WebSocket推送违建预警至《04工作台》“我的预警”，同时通过API供违建专题应用拉取线索数据；

3. 业务应用层：

   • 违建专题应用拉取线索数据，生成处置工单（biz_urban_evt_wo）；

   • 处置完成后，将“拆除完成”结果反馈至数据中枢，更新gen_illegal_build_disposal的disposal_status；

4. 中枢反馈更新：数据中枢基于反馈结果，更新stat_illegal_build_handle的“违建整改率”，同步至城管核心指标（5.3节）。

五、数据流转的安全与合规保障（《01总体架构》《02命名规范》）

1. 数据传输安全：设备→数据中枢、数据中枢→业务应用的所有数据均通过TLS 1.3加密（《01总体架构》P93“安全防护”），防止数据窃取；

2. 敏感数据保护：涉及个人信息的数据（如网格员位置）需脱敏存储（《02命名规范》P9），如sys_user表的user_phone字段需AES加密；

3. 操作审计：所有数据查询、修改操作需记录至biz_data_oper_log（数据操作日志表），包含“操作人、操作时间、数据内容”，日志保留6个月（《05数据中枢》20.15.5节“审计日志”）；

4. 数据备份：核心数据表（如sys_device、gen_illegal_build_clue_mng）需按《01总体架构》P96“备份策略”执行：每日全量备份+每小时增量备份，RPO≤1小时。

六、总结：数据流转的“文件闭环”

城管住建数据流转架构完全基于指定文件构建，核心逻辑可概括为：

• 源头合规：设备类型、采集规则来自《06-01城管》《05数据中枢》，确保数据“采得对”；

• 处理规范：清洗、存储、分发环节严格遵循《05数据中枢》模块职责与《03数据库表》分层逻辑，确保数据“处理好”；

• 应用适配：业务应用调用数据中枢API，反馈结果更新数据表，形成“采集→处理→应用→反馈”闭环，符合《01总体架构》“数据驱动治理”目标。

所有流转节点均无外部依赖，仅针对指定文件，确保与一网统管平台整体架构完全兼容。