2. 药物研发数据平台典型架构解析

药物研发数据平台不是单一系统，而是一条从实验产生数据到最终支撑决策的完整链路。理解这条链路的分层结构、组件职责与依赖关系，是运维工程师判断故障影响面、定位性能瓶颈、规划容量与变更窗口的基础。本节从运维视角拆解典型五层架构，并给出关键依赖与常见风险点。

一、五层架构的职责边界

典型药物研发数据平台可划分为采集层、存储层、计算层、分析层与应用层。分层的目的不是画图好看，而是明确“谁产生数据、谁保存数据、谁加工数据、谁消费数据”，从而在故障时快速圈定影响范围。

• 采集层：对接实验室仪器（如HPLC、质谱、测序仪）、LIMS/ELN系统、外部数据库与文件服务器。核心组件包括采集代理、消息队列（Kafka/RabbitMQ）、文件落地网关与元数据登记服务。运维关注点：采集延迟、消息积压、文件完整性校验。
• 存储层：承担原始数据、清洗后数据与结果数据的持久化。常见组合为对象存储（S3/MinIO）存原始大文件、关系库（PostgreSQL/MySQL）存元数据与结构化结果、列式存储（Parquet+Hive/ClickHouse）存分析宽表。运维关注点：容量水位、副本一致性、冷热分层策略。
• 计算层：执行数据清洗、格式转换、特征计算与批量任务。组件包括调度器（Airflow/DolphinScheduler）、计算引擎（Spark/Flink）与容器平台（Kubernetes）。运维关注点：任务排队时长、资源争抢、失败重试与幂等性。
• 分析层：面向统计、建模与可视化查询，提供SQL网关、Notebook服务与模型训练环境。运维关注点：查询并发、慢查询、资源隔离。
• 应用层：面向研发人员的Web门户、报表、API与审批流。运维关注点：接口可用性、响应时间、权限与审计。

下面用一张架构关系图呈现五层之间的数据流向与关键依赖。图中箭头方向表示数据或请求的流动方向，虚线表示控制/调度依赖。

二、运维视角的关键依赖链

架构图只是静态结构，真正决定可用性的是依赖链。以一次“质谱原始文件入库并生成分析宽表”为例，其依赖顺序为：采集代理 → 消息队列 → 文件网关 → 对象存储 → 元数据库 → 调度器 → Spark → ClickHouse → 查询网关 → 门户。这条链上任一环节异常，都会导致下游任务失败或数据延迟。

运维中需要重点识别三类依赖：

• 强依赖：如对象存储不可用，采集与计算同时中断，属于P0级故障。
• 弱依赖：如Redis缓存失效，查询变慢但数据仍可返回，属于P2级降级。
• 隐式依赖：如K8s节点时间不同步导致Spark任务时间戳错乱，往往在故障后才被发现。

三、典型故障场景与判断依据

以下给出一个可参考的排障判断表，用于快速定位链路中的异常环节。表中参数为教学示例，实际阈值需结合平台规模调整。

四、容量与变更的运维要点

药物研发数据具有“原始文件大、保留周期长、分析查询突发”的特点。容量规划时，对象存储应按年增长量的1.5倍预留，关系库重点监控连接数与慢查询，ClickHouse需关注分区合并与磁盘水位。变更窗口应避开实验数据集中回传时段，通常选择夜间或周末，并提前在预发环境验证调度DAG的兼容性。