数据湖概念与架构
各位，今天咱们聊聊数据湖。这个概念这几年火得不行，但说实话，很多人对它理解有偏差。我刚开始做数据平台的时候，也踩过不少坑。
数据湖，说白了就是一个集中存储。你能把各种格式的数据都扔进去——结构化的表、半结构化的日志、非结构化的图片和测序FASTQ文件。它跟传统的数据仓库完全是两码事。
数据湖 vs 传统数据仓库
这两者的区别，是我在项目中常被问到的。很多刚入行的朋友容易搞混。
| 维度 | 数据湖 | 数据仓库 |
|---|---|---|
| 数据结构 | 原始格式，Schema-on-Read | 预先建模，Schema-on-Write |
| 存储成本 | 低成本，用对象存储（如S3） | 较高，依赖专用硬件 |
| 处理方式 | ETL和ELT都支持 | ETL为主 |
| 典型用户 | 数据科学家、AI工程师 | 业务分析师、BI报表 |
| 数据质量 | 较宽松，允许”脏数据” | 严格治理，高质量 |
你想想看，数据仓库就像高级餐厅，所有食材都经过精加工，直接能上桌。而数据湖呢，更像一个大型农贸市场，原材料随便放，你要吃什么得自己动手处理。为什么会这样？因为数据湖的设计哲学就是「先存再说，用的时候再处理」。
我的习惯：做多组学项目时，原始测序数据、表达量矩阵、临床信息，我都会原封不动扔进数据湖。这样即使后续分析管线变了，也不怕重跑。数据仓库只放清洗好的汇总表给业务用。
典型分层架构
数据湖不是把文件乱堆一气。我见过不少失败的案例，都是因为没做好分层，最后变成了「数据沼泽」。我个人习惯用三层架构，清晰又好管理。
这三层分别是：Ingest（摄取层）、Stage（缓冲层）、Curate（治理层）。
Ingest 层
这是数据入口。所有来源的数据都在这落地。比如多组学中的FASTQ文件、BAM文件、VCF文件。我建议这一层只做简单分流，不做任何转换。为什么？因为原始数据一旦被修改，后面的分析就可能出问题。
# 一个典型的Ingest脚本片段（伪代码）
function ingest_data(source_path, target_path):
if is_new_file(source_path):
copy_to_storage(source_path, f"ingest/{date}/{filename}")
log_metadata(filename, checksum, source)
else:
print("文件已存在，跳过")
Stage 层
数据进入Stage层后，会做初步的格式统一。比如将所有文本日志转成Parquet格式。这样查询效率能提升10倍以上。记得，Stage层的数据依然是「半成品」，没有经过清洗和校准。
Curate 层
这一层的数据才是真正「能用」的。我去过一家药企，他们的Curate层里存的是经过质控的表达量矩阵、标准化后的蛋白质组数据。业务团队直接从这里取数做分析。
关键点：Curate层的数据需要做版本管理。我在项目中遇到过分析结果对不上的情况，最后发现是Curate层数据被静默覆盖了。从那以后，我坚持用Delta Lake或者Apache Iceberg来做数据版本控制。
元数据管理的基本思想
没有元数据管理的数据湖，就是数据沼泽。嗯，这里要注意。元数据就是数据的「身份证」和「户口本」。它告诉你这个文件是谁产生的，什么时候产生的，格式是什么，包含了什么信息。
我的经验是，元数据管理需要做三件事：
- 自动采集：数据进入Ingest层时，自动提取元数据
- 统一存储：所有元数据集中存放，方便检索
- 血缘追踪：记录数据从哪来、经过了哪些处理、最终去哪了
举个例子，一个典型的元数据记录长这样：
{
"dataset_id": "RNA_SEQ_TUMOR_001",
"source": "Illumina NovaSeq 6000",
"run_date": "2024-03-15",
"file_format": "FASTQ",
"checksum": "a1b2c3d4e5f6...",
"size_bytes": 1280000000,
"sample": "patient_01_tumor",
"tissue_type": "liver_cancer",
"processing_pipeline": "standard_sarek_v3.2",
"stage": "stage",
"created_at": "2024-03-16T10:30:00Z"
}
避坑指南：我曾经遇到团队用Excel表格管理元数据，结果数据量一大就崩溃了。我的建议是直接用Hive Metastore或者AWS Glue Data Catalog这种专业工具。它们支持自动爬取，还能跟Spark、Presto这些引擎无缝对接。
你想想看，如果没有元数据，你怎么知道这个FASTQ文件来自哪个病人？基因测序用的什么平台？做了哪些质控？这些问题看似简单，但在实际项目中，一旦数据量达到PB级别，没有元数据管理就等于大海捞针。
数据湖的本质，不是把数据堆起来就完事。它需要清晰的分层架构、严格的元数据治理，以及适合多组学场景的存储策略。从Ingest到Stage再到Curate，每一层都有它的使命。理解了这些，我们后面讲ETL管线优化时才不会跑偏。