基于湖仓一体的医疗大数据中心存储架构设计

一、设计原则：构建面向未来的BI与AI一体化数据平台

在构建现代卫生健康大数据中心时，我们必须超越传统的、孤立的系统建设模式。参考所提供的架构图，我们的存储设计将围绕四大核心原则展开，旨在构建一个BI与AI一体化、拥有统一元数据、支持一湖多引擎、并实现降本增效的先进数据平台。

BI与AI一体化：平台需同时支撑面向管理者的“智慧监管应用”和面向公众的“便民服务应用”，以及更深层次的AI模型开发与训练。这意味着底层存储必须能无缝支持BI报表的高并发查询和AI模型训练的大吞吐量读取。
统一元数据与元仓：如图中“数据资产管理”模块所示，通过建立统一的元数据中心（元仓），对所有数据进行集中编目，形成完整的数据血缘和健康画像，确保数据可发现、可理解、可追溯，这是打破数据孤岛、提升数据质量的先决条件。
一湖多引擎：架构图的“计算分析”层清晰地展示了多种引擎并存的模式。我们的存储设计必须支持StarRocks等高性能分析引擎、Flink等实时计算引擎以及Spark等批处理引擎在同一份数据上协同工作，避免数据在不同系统间冗余拷贝。
降本增效：这是贯穿始终的目标。通过存算分离和冷热分层的核心技术，在满足性能需求的同时，最大限度地降低海量医疗数据的存储和计算成本。

二、数据湖存储规划：从对象存储到高性能块存储

基于存算分离的核心理念，我们将采用混合存储介质的策略，以平衡成本与性能。

2.1 分布式对象存储：数据湖的基石

数据湖的物理基础是分布式对象存储（如HDFS或云上的S3、OSS）。它将作为我们统一的数据底座，承载从“数据源”采集而来的全量、多模态数据。

数据湖对象存储应包括：

全周期数据：涵盖从ODS层的原始数据、DWD层的明细数据，到DWS层的汇总数据和ADS层的应用数据，所有分层的数据都将存放在对象存储中。
多模态数据：无论是来自HIS、EMR的结构化/半结构化数据，还是来自PACS系统的海量非结构化影像数据（DICOM），以及物联网设备的流式数据，都将统一入湖存储。
开放格式文件：湖内数据主要以Apache Parquet等开放列式格式存储，以实现高效压缩和分析性能。在此之上，我们采用Apache Iceberg或Apache Paimon等先进的开放表格式进行组织和管理，为数据湖带来ACID事务、模式演进和时间旅行等关键的数据仓库能力，确保数据的高可靠性和一致性。

2.2 SSD全闪高性能块存储：特定场景的“加速器”

虽然对象存储是主力，但在某些对延迟和IOPS（每秒读写次数）有极致要求的场景，配置SSD全闪高性能块存储是必要的“加速器”，它并非用于存储数据湖本身，而是服务于计算和管理组件：

分析引擎的热数据缓存：对于像StarRocks这样的高性能MPP分析引擎，其BE（Backend）节点可以配置SSD，用于缓存最频繁访问的热数据或中间计算结果。当用户进行交互式分析时，数据直接从SSD读取，可将查询延迟降低至亚秒级，极大提升BI体验。
实时流处理的低延迟缓冲：在使用Kafka作为消息队列，Flink进行实时数据处理的场景中，Kafka的Broker节点需要极低的写入延迟来持久化消息流。将Kafka的日志部署在SSD上，可以确保数据在写入数据湖（ODS层）前的管道稳定、高效。
统一元数据服务的数据库：平台的“大脑”——统一元数据目录（如Hive Metastore），其后台数据库存储着所有数据表的元数据信息。为保证所有计算引擎（StarRocks, Flink, Spark）都能快速进行数据发现和查询规划，该数据库必须部署在SSD上，以实现元数据的高速读写。

三、数据分层设计：从ODS到ADS的价值提炼

我们采用业界成熟的数据仓库分层理论，在统一的数据湖存储之上，对数据进行逻辑分层，实现数据从原始到应用的逐级加工和价值提炼。

ODS (Operational Data Store) - 原始数据层
- 规划：此层是数据入湖的第一站，直接对接“数据采集”层的多模态数据源。所有来自HIS、EMR、LIS、PACS等系统的原始数据，以其原生格式或仅做简单格式统一（如转为Parquet），完整地、不可变地存储在此。
- 作用：作为数据的“备份源”，保留最全的历史信息，用于数据审计、问题追溯和未来用新算法进行重算。
DWD (Data Warehouse Detail) - 明细数据层
- 规划：此层对应架构图中的“数据治理”环节。通过Flink或Spark任务，对ODS层的数据进行清洗（去除无效记录）、标准化（如“模型转换”、“标签管理”，统一诊断、药品编码）、关联（通过患者主索引，将不同来源的明细记录关联到同一患者）。此层数据以Iceberg/Paimon表的形式组织，保证了数据的事务性和一致性。
- 作用：形成干净、规范、以实体（如患者、医嘱、检查）为核心的明细事实表，是后续数据分析和挖掘的基础。
DWS (Data Warehouse Summary) - 汇总数据层
- 规划：基于DWD层的数据，按照不同的分析主题（如“健康档案库”、“电子病历库”、“医疗服务库”等）进行轻度聚合和汇总，构建跨业务流程的宽表。例如，生成以患者为维度，包含其人口学信息、历次就诊关键诊断、主要用药等信息的“患者健康画像”宽表。
- 作用：预先计算常用的统计指标，提升分析效率，为上层应用提供更便捷的数据视图，直接支撑“数据开发服务”。
ADS (Application Data Service) - 应用数据层
- 规划：此层是数据的最终出口，直接面向“数据应用”层的各类服务。根据“便民服务”、“智慧监管”、“业务协同”等具体应用的需求，从DWS或DWD层抽取数据，生成高度聚合的报表、指标或数据集。
- 作用：为前端应用提供定制化的数据。例如，为“资源目录”和“服务订阅”提供可供查询的数据接口；为AI模型的“病历解析”提供训练和推理所需的特征数据；为BI仪表盘提供最终的KPI结果数据。这一层的数据可以直接由StarRocks进行高速查询和展现。

四、冷热归档设计：实现成本与性能的最优平衡

为实现“降本增效”，我们必须对数据进行生命周期管理，实施冷热分离与归档策略，这与架构图中“热-温-冷冷热分离”的设计完全契合 11。

热数据：
- 定义：最近1-3个月内频繁访问的数据，如ADS层的核心报表、DWS层的常用主题宽表。
- 存储策略：存放在对象存储的标准层，并可被StarRocks等引擎自动缓存到其本地SSD中，以获得极致查询性能。
温数据：
- 定义：访问频率降低的数据，如3个月至2年前的DWD明细数据。
- 存储策略：通过对象存储的生命周期策略，自动下沉到低频访问（Infrequent Access）存储层，在保证在线访问能力的同时，降低存储成本。
归档存储：
- 定义：因法规遵从（如病历需保存数十年）或长期科研需要而必须保留，但几乎不再访问的历史数据。主要是ODS层中超过2年以上的原始数据和DWD层的历史明细。
- 设计：同样利用生命周期策略，将这部分数据自动迁移到成本最低的归档存储层或深度归档存储层。这些数据虽然不用于日常分析，但其元信息仍在统一元数据目录中可见。当需要进行历史审计或回顾性研究时，可通过申请流程将其“解冻”恢复至标准层进行访问。

通过这套精细化的存储设计，我们不仅构建了一个能够容纳全量、多模态健康医疗数据的统一数据湖，更通过分层、分区、冷热分离和多介质协同，打造了一个在性能、成本、灵活性和治理能力上都达到最优平衡的现代化数据基石，为上层的智慧医疗应用提供了源源不断的动力。

Works cited

湖仓一体技术白皮书 - 信息资源系统, accessed August 7, 2025, https://13115299.s21i.faiusr.com/61/1/ABUIABA9GAAgqsj7owYo4dyXxAU.pdf
开放式湖仓是湖仓一体架构的最终归宿 - InfoQ, accessed August 7, 2025, https://www.infoq.cn/article/n8d436zu9qv1uyseiqcw
数据仓库、数据湖与湖仓一体| IBM, accessed August 7, 2025, https://www.ibm.com/cn-zh/think/topics/data-warehouse-vs-data-lake-vs-data-lakehouse
Data Lakehouse Architecture | Databricks, accessed August 7, 2025, https://www.databricks.com/product/data-lakehouse
Data Governance Issues in Lake House Migrations - Visvero, accessed August 7, 2025, https://visvero.com/data-governance-issues-in-lake-house-migrations/
数据湖仓一体 - IBM, accessed August 7, 2025, https://www.ibm.com/cn-zh/architectures/hybrid/data-lakehouse
存算分离实践：JuiceFS 在中国电信日均PB 级数据场景的应用, accessed August 7, 2025, https://juicefs.com/zh-cn/blog/user-stories/application-of-juicefs-in-china-telecoms-daily-average-pb-data-scenario
Why Healthcare Analytics Needs a Data Lakehouse - Sigma Software, accessed August 7, 2025, https://sigma.software/about/media/why-healthcare-analytics-needs-a-data-lakehouse
A Lakehouse Architecture for the Management and Analysis ... - OSTI, accessed August 7, 2025, https://www.osti.gov/servlets/purl/1865733
深度对比Delta、Iceberg和Hudi三大开源数据湖方案_开源_胡争(子毅 ..., accessed August 7, 2025, https://www.infoq.cn/article/fjebconxd2sz9wloykfo
Design a data lakehouse for health insurance analytics - Oracle Help Center, accessed August 7, 2025, https://docs.oracle.com/en/solutions/design-healthcare-lakehouse/index.html
快速使用|架构原理|官方答疑 - Apache RocketMQ 中文社区, accessed August 7, 2025, https://rocketmq-learning.com/learning/dynamic/

目录

一、 设计原则：构建面向未来的BI与AI一体化数据平台

二、 数据湖存储规划：从对象存储到高性能块存储