diff --git a/契合度/26-数据中台-模块规划.md b/契合度/26-数据中台-模块规划.md new file mode 100644 index 0000000..b5a8ffa --- /dev/null +++ b/契合度/26-数据中台-模块规划.md @@ -0,0 +1,220 @@ +# 数据中台 模块规划 + +--- + +## 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，在各业务系统积累足够数据后再逐步完善数仓分层和数据治理体系。优先使用云托管大数据服务降低运维负担，待数据量规模化后再评估自建集群的必要性。 diff --git a/契合度/27-技术中台-模块规划.md b/契合度/27-技术中台-模块规划.md new file mode 100644 index 0000000..da4523f --- /dev/null +++ b/契合度/27-技术中台-模块规划.md @@ -0,0 +1,235 @@ +# 技术中台 模块规划 + +--- + +## 1. 模块定位 + +技术中台是整个医养平台的**技术基础设施层**，负责为所有业务系统提供统一的微服务架构、医疗互联互通协议（HL7/FHIR）、API网关治理、消息队列、区块链存证和国密安全加密等基础技术能力，确保整个平台的高可用、高安全、高可扩展性。 + +技术中台不直接提供业务功能，而是作为平台**技术底座**，是所有业务系统稳定运行的基础保障。 + +--- + +## 2. 建设目标 + +1. 建立微服务架构体系（服务拆分/注册/发现/治理） +2. 实现医疗互联互通标准协议（HL7 FHIR R4）的统一适配 +3. 构建独立API网关（统一鉴权/限流/熔断/审计） +4. 建立统一消息队列体系（异步解耦/顺序保障/死信处理） +5. 构建区块链存证服务（服务记录/审批数据/电子签章不可篡改） +6. 建立国密加密体系（SM2/SM3/SM4满足医疗数据合规加密要求） +7. 提供统一的监控告警、日志采集和链路追踪能力 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +1. 微服务治理平台 +2. 医疗互联互通协议层（HL7/FHIR） +3. API网关 +4. 消息队列服务 +5. 区块链存证服务 +6. 国密安全加密服务 +7. 统一监控与可观测性 + +### 3.2 二级功能清单 + +**微服务治理平台**： + +- 服务注册与发现（Nacos） +- 服务配置中心（动态配置下发，无需重启） +- 服务熔断与降级（Sentinel/Resilience4j） +- 负载均衡策略配置 +- 灰度发布与蓝绿部署支持 +- 服务版本管理与 API 契约管理（OpenAPI 3.0） + +**医疗互联互通协议层**： + +- HL7 FHIR R4 资源适配（Patient/Observation/MedicationRequest等标准资源） +- FHIR Server（开源 HAPI FHIR） +- 接口适配网关（将各业务系统内部接口适配为FHIR标准接口） +- 医疗数据交换格式校验（与外部HIS/LIS/PACS对接时格式验证） +- 互联互通成熟度等级评测支持（⚠️ 待确认目标等级与评测节点） + +**API网关**： + +- 统一鉴权（JWT/OAuth2.0/API Key多种鉴权方式） +- 请求限流（按IP/用户/接口的多维度限流） +- 熔断降级（自动熔断异常服务，返回fallback响应） +- 请求路由（按路径/版本/灰度标签路由） +- 接口审计日志（所有API调用完整记录） +- SSL/TLS终止（统一证书管理，加密传输） + +**消息队列服务**： + +- 业务解耦消息发布订阅（各业务系统间异步通信） +- 顺序消息支持（如审批流程的顺序节点推进） +- 延迟消息（定时提醒/超时预警等场景） +- 消息重试与死信队列（消费失败后的重试与人工处理） +- 消息轨迹追踪（消息全链路状态查询） +- 与区块链存证联动（关键业务消息的存证触发） + +**区块链存证服务**： + +- 存证数据写入（服务记录/长护险服务凭证/审批结果/电子合同） +- 存证哈希查询（按业务ID查询对应区块链哈希） +- 存证验真（对比本地数据与链上哈希，验证未被篡改） +- 区块链平台管理（节点状态/存证量统计） +- 对接公信力区块链平台（⚠️ 待确认：百度超级链/腾讯TrustSQL/蚂蚁链等，需政府监管认可） + +**国密安全加密服务**： + +- SM2（非对称加密）：关键数据的加密存储与数字签名 +- SM3（哈希算法）：数据完整性校验（替代SHA-256） +- SM4（对称加密）：批量数据的加密传输与存储 +- 密钥管理服务（KMS）（密钥生成/存储/轮换/销毁） +- 国密TLS（TLCP协议支持，⚠️ 需专用服务器支持） +- 电子签章服务（结合SM2完成电子文件签章） + +**统一监控与可观测性**： + +- 指标监控（Prometheus + Grafana：系统负载/接口响应时间/错误率） +- 日志采集（ELK：Elasticsearch + Logstash + Kibana） +- 分布式链路追踪（SkyWalking / Jaeger） +- 告警规则配置与通知（告警→飞书/钉钉/短信通知） +- 容量规划看板（各服务资源使用趋势预测） +- 故障自动诊断（AIOps初级能力，基于历史告警模式） + +### 3.3 技术架构总览 + +| 层次 | 组件 | 作用 | +| -------- | ----------------------------- | -------------------- | +| 接入层 | API网关（Kong/APISIX） | 统一入口、鉴权、限流 | +| 服务层 | Nacos + Sentinel | 服务注册、发现、熔断 | +| 通信层 | RabbitMQ / Kafka | 异步消息解耦 | +| 安全层 | 国密SDK + KMS | 数据安全加密 | +| 互联层 | HAPI FHIR Server | 医疗标准协议适配 | +| 存证层 | 区块链平台 | 关键数据不可篡改 | +| 可观测层 | ELK + Prometheus + SkyWalking | 全链路监控 | +| 基础设施 | Docker + Kubernetes | 容器化部署与弹性伸缩 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +| 能力需求 | mall 现状 | 结论 | +| ----------------------------- | ------------------------------------- | ---------- | +| HL7/FHIR 医疗互联互通协议 | 无 | 须独立建设 | +| 区块链存证服务 | 无 | 须独立建设 | +| 国密加密体系（SM2/SM3/SM4） | 无 | 须独立建设 | +| 微服务治理平台 | mall 为单体或简单分层架构，无中台治理 | 须独立建设 | +| 统一API网关（含医疗合规审计） | 无 | 须独立建设 | +| 分布式消息队列 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备任何医疗互联互通、区块链存证、国密加密等专业技术能力，强行堆入会导致整体架构崩溃和医疗数据合规失控。 + +--- + +## 5. 规划判断 + +**独立建设（Platform Engineering，技术基础设施优先建设）** + +建议云原生方案（降低运维难度，按需弹性伸缩）： + +- **容器化**：Docker + Kubernetes（阿里云ACK / 腾讯云TKE托管） +- **API网关**：Kong（开源版）/ APISIX +- **服务治理**：Spring Cloud Alibaba（Nacos + Sentinel + Seata） +- **消息队列**：RabbitMQ（业务消息）+ Kafka（日志/流数据） +- **区块链**：⚠️ 待确认平台（需政府认可，优先考虑已在民政系统使用的公链） +- **国密**：BouncyCastle（Java国密库）/ GmSSL（C/Python国密库） +- **FHIR Server**：HAPI FHIR（开源，Java） +- **监控**：Prometheus + Grafana + SkyWalking + ELK + +--- + +## 6. 需新增业务能力 + +1. **DevOps流水线**：CI/CD自动化发布（Jenkins / GitLab CI + Helm Chart部署） +2. **灾备方案**：关键数据的异地双活或同城双备（医疗数据丢失不可接受） +3. **等保三级合规**：系统安全等级保护三级认证（医疗信息系统要求） +4. **国密TLS通信**：部分政府对接接口可能要求国密通信链路 +5. **接口标准文档**：OpenAPI 3.0规范维护，供对接方接入使用 + +--- + +## 7. 需新增数据模型（基础设施侧） + +| 模型 | 关键字段 | +| --------------------- | ---------------------------------------------------------------------------------- | +| `blockchain_record` | id, biz_type, biz_id, data_hash(SM3), chain_tx_id, chain_time, verify_status | +| `api_call_log` | id, gateway_id, path, method, client_ip, user_id, status_code, latency_ms, ts | +| `encryption_key_meta` | id, key_type(SM2/SM4), key_version, created_at, expire_at, status, managed_by_kms | +| `fhir_resource_log` | id, resource_type, resource_id, operation, requestor, source_system, created_at | +| `service_health` | id, service_name, instance_id, status, cpu_pct, mem_pct, latency_p99, check_at | +| `alert_rule` | id, metric_name, condition, threshold, severity, notify_channels(JSONB), is_active | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ----------- | ------------------------------------- | ------------------- | +| 容器编排 | Kubernetes（云托管） | 服务部署与弹性伸缩 | +| API网关 | Kong / APISIX（开源） | 统一鉴权/限流/路由 | +| 服务注册 | Nacos | 微服务注册与配置 | +| 熔断限流 | Sentinel | 流量控制与熔断 | +| 消息队列 | RabbitMQ + Kafka | 业务解耦 + 日志流 | +| 链路追踪 | SkyWalking | 分布式链路追踪 | +| 日志管理 | ELK Stack | 日志采集与查询 | +| 监控 | Prometheus + Grafana | 指标监控与可视化 | +| FHIR服务 | HAPI FHIR（开源） | HL7 FHIR R4标准适配 | +| 国密加密 | BouncyCastle / GmSSL | SM2/SM3/SM4加密 | +| KMS密钥管理 | 阿里云KMS / 腾讯云KMS | 密钥安全管理 | +| 区块链 | ⚠️ 待确认（蚂蚁链/腾讯链/百度超级链） | 关键数据存证 | + +--- + +## 9. 外部系统对接关系 + +| 对接系统 | 方向 | 内容 | +| ---------------- | ------------------------- | ------------------------------------ | +| 全部27个业务系统 | 依赖 | API网关/消息队列/国密加密/区块链存证 | +| 志愿者管理（12） | 调用区块链存证 | 时间银行积分存证 | +| 长护险（18） | 调用区块链存证 | 服务凭证存证 | +| 政府审批（04） | 调用区块链存证 + 电子签章 | 审批结果存证 | +| 外部HIS/LIS | 依赖FHIR适配层 | 医疗数据互联互通 | +| 运营监控人员 | 使用监控平台 | 系统健康状态监控 | +| 等保测评机构 | 外部审查 | 等保三级合规评测 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------------------ | ------------------------------------------- | ------------------------------------------------------------ | +| 技术复杂度高 | 微服务+区块链+国密+FHIR并行建设复杂度极高 | 分期建设，P0阶段先建API网关+微服务治理，其他逐步扩展 | +| 区块链平台选择 | 国内区块链平台众多，政府认可度不同 | 与政府监管部门确认认可的区块链平台后再选型 | +| 国密TLS兼容 | 国密TLS需要专用客户端支持，兼容性有限 | 非强制要求时用标准TLS，政府接口按要求提供国密通道 | +| FHIR标准复杂 | FHIR资源模型学习成本高，国内HIS适配程度不一 | 先完成Patient/Observation等核心资源，逐步扩展 | +| 等保三级成本 | 等保三级测评和整改成本较高（数十万元+） | 提前规划等保要求，在系统设计阶段就满足技术要求，避免后期整改 | +| 边界：技术中台只做通用技术能力 | 不在技术中台中实现任何业务逻辑 | 技术中台只提供协议/安全/治理/存证等通用技术服务 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2（分期建设，基础部分需在P0之前就绪）** + +| 分期 | 内容 | 时间节点 | +| ------------------------ | ---------------------------------------------------------- | ------------------ | +| 前置建设（P0系统上线前） | Docker+K8s基础环境 + API网关 + Nacos + RabbitMQ + 基础监控 | 在P0系统开发前完成 | +| 第一期 | 国密加密服务 + ELK日志 + SkyWalking链路追踪 | P0/P1系统建设期间 | +| 第二期 | HAPI FHIR Server + 外部HIS对接 | P1系统建设期间 | +| 第三期 | 区块链存证 + 等保三级合规建设 + 国密TLS | P2阶段按需推进 | + +--- + +## 12. 结论 + +技术中台是整个医养平台的**技术底座**，其微服务治理、API网关、国密加密、HL7/FHIR协议、区块链存证等能力在 mall 中完全缺失，**必须独立建设**。 + +技术中台的建设应遵循"先基础后专业"的原则：优先完成API网关、微服务治理、容器化部署等通用基础设施（在P0业务系统之前就绪），再根据业务需求逐步引入HL7/FHIR医疗互联互通、国密加密和区块链存证等专业医疗技术能力。建议优先采用云托管服务（K8s/KMS/日志服务等）降低运维复杂度，让团队聚焦业务能力建设。