221 lines
12 KiB
Markdown
221 lines
12 KiB
Markdown
# 数据中台 模块规划
|
||
|
||
---
|
||
|
||
## 1. 模块定位
|
||
|
||
数据中台是整个医养平台的**数据资产管理与智能分析体系**，负责汇聚全平台各业务系统产生的数据（结构化/半结构化/非结构化），通过数据湖、数据仓库、主题库和专题库的分层架构，为运营决策、AI模型训练、政府监管上报和区域医养事业评估提供高质量数据支撑。
|
||
|
||
数据中台不直接面向业务用户，而是作为**数据资产的统一管理层**，对上层消费系统（运营管理、AI服务、政府监管）提供标准化数据服务。
|
||
|
||
---
|
||
|
||
## 2. 建设目标
|
||
|
||
1. 构建医养数据湖，统一汇聚全平台数据资产
|
||
2. 建立 ODS → 基准层 → 主题层 → 专题层的分层数仓体系
|
||
3. 建立数据治理平台（数据质量/数据血缘/数据目录）
|
||
4. 构建医疗知识图谱（ICD-10/SNOMED CT/中医知识体系）
|
||
5. 构建 AI 大模型训练数据管理平台（DeepSeek 垂直微调数据集管理）
|
||
6. 提供标准化的数据服务API（报表查询/指标计算/数据导出）
|
||
|
||
---
|
||
|
||
## 3. 核心功能范围
|
||
|
||
### 3.1 一级模块
|
||
|
||
1. 数据湖基座
|
||
2. 数据仓库（分层体系）
|
||
3. 数据治理平台
|
||
4. 医疗知识图谱
|
||
5. AI大模型训练数据管理
|
||
6. 数据服务与API
|
||
|
||
### 3.2 二级功能清单
|
||
|
||
**数据湖基座**：
|
||
|
||
- 全平台数据接入（数据库CDC/Kafka流/文件上传）
|
||
- 多源异构数据统一存储（结构化表/JSON/文件/时序数据）
|
||
- 数据分区策略（按时间/机构/数据类型分区）
|
||
- 数据访问权限管理（列级/行级权限）
|
||
- 数据生命周期管理（冷热分层/自动归档）
|
||
|
||
**数据仓库分层体系**：
|
||
|
||
- ODS层（贴源层）：从各业务系统实时/批量同步原始数据
|
||
- 基准层（DWD）：数据清洗/标准化/维度建模
|
||
- 主题层（DWS）：老人域/机构域/服务域/健康域等主题宽表
|
||
- 专题层（ADS）：运营指标/监管上报/AI训练集等面向具体场景的专题表
|
||
|
||
**数据治理平台**：
|
||
|
||
- 数据目录（元数据管理，数据资产全景地图）
|
||
- 数据血缘（字段级来源追踪）
|
||
- 数据质量规则配置（完整性/一致性/时效性监控）
|
||
- 数据标准（统一字段命名、枚举值、编码规范）
|
||
- 数据问题工单（数据质量问题发现→修复→关闭闭环）
|
||
|
||
**医疗知识图谱**：
|
||
|
||
- ICD-10疾病分类体系（国家标准10000+节点）
|
||
- SNOMED CT 国际医学术语（⚠️ 待确认授权）
|
||
- 药品知识图谱（药品-适应症-禁忌-相互作用-价格）
|
||
- 中医知识体系（证候-方剂-药材-经络关系）
|
||
- 护理规范知识库（养老护理操作规范、评估量表）
|
||
- 知识图谱查询API（供AI服务22号调用）
|
||
|
||
**AI大模型训练数据管理**：
|
||
|
||
- 标注任务管理（标注人员分配/质检/审核）
|
||
- 训练数据集版本管理（数据集切割/版本记录）
|
||
- 数据脱敏工具（患者隐私字段自动脱敏）
|
||
- 训练数据质量评估（标注一致性、数据分布分析）
|
||
- 与AI服务（22号）训练管道对接
|
||
|
||
**数据服务与API**：
|
||
|
||
- 统一查询API（支持SQL/REST两种接口）
|
||
- 指标计算服务（平台关键指标实时/离线计算）
|
||
- 监管报表生成（对接01号政府监管系统的数据上报）
|
||
- 数据导出服务（Excel/CSV/JSON格式导出审批）
|
||
- 数据订阅推送（增量数据变化推送给订阅系统）
|
||
|
||
### 3.3 数据分层模型
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ 专题层ADS │ 运营看板 │ 监管上报 │ AI训练集 │ 选题分析 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ 主题层DWS │ 老人主题 │ 机构主题 │ 服务主题 │ 健康主题 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ 基准层DWD │ 清洗/标准化/维度建模（数据规范化处理） │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ 同步层ODS │ 全平台27个业务系统原始数据实时/批量同步 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ 数据湖 │ 结构化+半结构化+非结构化数据统一存储 │
|
||
└─────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 4. 与现有 mall 的关系
|
||
|
||
**契合度：D（不适配）**
|
||
|
||
| 能力需求 | mall 现状 | 结论 |
|
||
| ----------------------------- | --------- | ---------- |
|
||
| 数据湖架构（Hadoop/对象存储） | 无 | 须独立建设 |
|
||
| 分层数仓（ODS/DWD/DWS/ADS） | 无 | 须独立建设 |
|
||
| 数据治理平台 | 无 | 须独立建设 |
|
||
| 医疗知识图谱 | 无 | 须独立建设 |
|
||
| AI训练数据管理 | 无 | 须独立建设 |
|
||
| OLAP分析引擎 | 无 | 须独立建设 |
|
||
|
||
mall 是通用电商平台，不具备任何大数据处理和数据治理能力，强行堆入会导致维护灾难（OLTP与OLAP完全不同的技术栈和运维要求）。
|
||
|
||
---
|
||
|
||
## 5. 规划判断
|
||
|
||
**独立建设（大数据平台架构）**
|
||
|
||
云原生路线（推荐云部署，降低运维难度）：
|
||
|
||
- **数据湖存储**：阿里云OSS / 腾讯云COS（对象存储）
|
||
- **实时数据接入**：Apache Kafka（CDC流数据）
|
||
- **批量数据同步**：DataX / SeaTunnel（从各业务系统导入）
|
||
- **计算引擎**：Apache Spark（批计算）+ Apache Flink（流计算）
|
||
- **数据仓库**：ClickHouse（OLAP分析）或阿里云MaxCompute（云数仓）
|
||
- **数据治理**：Apache Atlas / 自研
|
||
- **知识图谱**：Neo4j（图数据库）
|
||
- **调度**：Apache DolphinScheduler（数据任务调度）
|
||
- **可视化**：Superset / 自研（数据探索）
|
||
|
||
---
|
||
|
||
## 6. 需新增业务能力
|
||
|
||
1. **数据标准体系**：统一全平台的字段命名规范、枚举值标准、编码规范
|
||
2. **医疗数据脱敏工具**：批量脱敏（姓名/身份证/手机号/病历关键信息）
|
||
3. **数据访问审批流程**：敏感数据（健康档案/医疗记录）的访问申请与审批
|
||
4. **数据质量监控**：每日自动检测数据完整性、一致性，异常自动告警
|
||
5. **监管数据上报格式**：按照民政/卫健委数据上报标准生成上报文件（⚠️ 待确认各地标准）
|
||
|
||
---
|
||
|
||
## 7. 需新增数据模型（数据治理侧）
|
||
|
||
| 模型 | 关键字段 |
|
||
| --------------------- | ----------------------------------------------------------------------------------------------- |
|
||
| `data_catalog` | id, table_name, layer(ods/dwd/dws/ads), description, owner, sensitivity_level, update_frequency |
|
||
| `data_lineage` | id, source_table, source_column, target_table, target_column, transform_logic, created_at |
|
||
| `data_quality_rule` | id, table_name, rule_type, rule_config(JSONB), alert_threshold, is_active |
|
||
| `data_quality_result` | id, rule_id, check_date, total_count, fail_count, fail_rate, status |
|
||
| `knowledge_node` | id, graph_type(icd10/drug/cm), code, name, properties(JSONB), created_at |
|
||
| `knowledge_relation` | id, source_node_id, target_node_id, relation_type, weight, source_doc |
|
||
| `dataset_version` | id, name, purpose(ai_train/report/export), snapshot_date, record_count, status, is_desensitized |
|
||
|
||
---
|
||
|
||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||
|
||
| 类别 | 技术选型 | 用途 |
|
||
| ---------- | ----------------------- | ---------------------- |
|
||
| 数据湖存储 | 阿里云OSS / 腾讯云COS | 原始数据湖存储 |
|
||
| 数据同步 | DataX / SeaTunnel | 业务系统→数仓增量同步 |
|
||
| 流处理 | Apache Flink | 实时数据流处理与聚合 |
|
||
| 批处理 | Apache Spark | 大规模批计算任务 |
|
||
| OLAP引擎 | ClickHouse | 高性能分析查询 |
|
||
| 图数据库 | Neo4j | 医疗知识图谱存储与查询 |
|
||
| 任务调度 | Apache DolphinScheduler | 数据任务的DAG调度 |
|
||
| 数据治理 | Apache Atlas | 元数据管理与血缘追踪 |
|
||
| 数据可视化 | Apache Superset | 数据探索与自助分析 |
|
||
|
||
---
|
||
|
||
## 9. 外部系统对接关系
|
||
|
||
| 对接系统 | 方向 | 内容 |
|
||
| -------------------- | --------------------- | -------------------------------- |
|
||
| 全部27个业务系统 | 数据流入 | 业务数据同步到ODS层 |
|
||
| 政府监管系统（01） | 数据流出 | 上报标准格式数据文件 |
|
||
| AI服务（22） | 双向 | 知识图谱API供应 + 训练数据集供应 |
|
||
| 运营管理（24） | 数据流出 | 经营分析指标供应 |
|
||
| ClickHouse（分析库） | 数据流出 | ADS层面向分析的宽表 |
|
||
| SNOMED CT授权方 | 数据引入（⚠️ 待确认） | 国际医学术语授权 |
|
||
|
||
---
|
||
|
||
## 10. 风险与边界
|
||
|
||
| 风险 | 说明 | 应对 |
|
||
| -------------------------------- | ---------------------------------------------- | ---------------------------------------------------------- |
|
||
| 建设周期长 | 大数据平台建设周期往往在6-12个月以上 | P2优先级，待核心业务系统稳定后再建 |
|
||
| 运维复杂度 | Kafka/Spark/Flink/ClickHouse等技术栈运维门槛高 | 优先选用云托管服务（如阿里云DataWorks）降低运维成本 |
|
||
| 数据隐私合规 | 医疗数据属于敏感个人信息（PIPL/等保三级） | 数据分类分级 + 脱敏 + 访问审批 + 等保合规 |
|
||
| 数据标准不统一 | 各业务系统字段定义不统一，数据清洗工作量大 | 在业务中台（25）建立统一数据标准，从源头控制数据质量 |
|
||
| 知识图谱授权 | SNOMED CT商业授权费用较高 | 先用ICD-10（国标免费）+自建医养知识图谱，后续评估SNOMED CT |
|
||
| 边界：数据中台只做数据，不做业务 | 避免将业务逻辑放到数仓中实现 | 严格区分数据层和应用层的职责边界 |
|
||
|
||
---
|
||
|
||
## 11. 实施优先级与分期建议
|
||
|
||
**优先级：P2**
|
||
|
||
| 分期 | 内容 | 前置条件 |
|
||
| ------ | ------------------------------------------- | ------------------------------- |
|
||
| 第一期 | ODS同步 + ClickHouse + 运营基础报表 | P0/P1业务系统产生足够数据后启动 |
|
||
| 第二期 | 数据治理 + 主题层建模 + 知识图谱（ICD-10） | 数仓稳定运行3-6个月后启动 |
|
||
| 第三期 | AI训练数据管理 + SNOMED CT + 全链路数据血缘 | AI服务（22）建设期间同步 |
|
||
|
||
---
|
||
|
||
## 12. 结论
|
||
|
||
数据中台是医养平台的**数据智慧层**，mall 完全不具备大数据处理和数据治理能力，**必须独立建设**。
|
||
|
||
建议初期不追求完整的大数据平台，而是以"ClickHouse + 基础运营报表 + 数据同步"为MVP，在各业务系统积累足够数据后再逐步完善数仓分层和数据治理体系。优先使用云托管大数据服务降低运维负担，待数据量规模化后再评估自建集群的必要性。
|