湖仓一体架构基础：数据湖与数据仓库的融合
2.1 从“两套系统”到“一套架构”：为什么需要湖仓一体
在传统大数据技术栈中，数据仓库与数据湖长期处于割裂状态。数据仓库（如 Teradata、Greenplum、传统 Hive 数仓）擅长承载结构化业务数据，提供强一致性事务、细粒度权限控制和成熟的 SQL 分析能力，但其扩展成本高、Schema 僵化，难以容纳半结构化日志、图片特征向量等原始数据。数据湖（如 HDFS + Spark、S3 + Presto）则以低成本存储海量任意格式数据，支持“先存储、后定义 Schema”的灵活模式，却往往缺乏事务保障、索引管理和数据质量约束，容易退化为“数据沼泽”。
湖仓一体（Lakehouse）的核心思想是：在低成本对象存储或分布式文件系统之上，构建一层具备数据仓库级事务、索引、治理能力的统一存储与计算平台。它并非简单地将数据仓库“搬进”数据湖，而是从存储格式、元数据管理、计算引擎三个层面重新设计，使同一份数据既能支撑 BI 报表、即席查询，也能直接供给机器学习训练。
关键认知：湖仓一体的本质不是“一个系统同时做湖和仓”，而是“一套存储底座 + 多种计算负载 + 统一治理层”。数据仍然存放在廉价的分布式存储中，但通过表格式（如 Delta Lake、Iceberg、Hudi）为其增加了事务日志、版本快照和索引能力，从而让数据湖“仓库化”。
2.2 常见架构组件：五层视图
一个生产级湖仓一体平台通常包含以下五个核心组件层，理解这些组件是进行容量规划的前提——因为每一层都会产生独立的资源消耗模式。
| 层次 | 核心组件 | 容量规划关注点 |
|---|---|---|
| 存储层 | 对象存储（S3/OSS）、HDFS、分布式文件系统 | 原始数据量、副本因子、压缩比、版本保留策略 |
| 表格式层 | Delta Lake、Apache Iceberg、Apache Hudi | 事务日志大小、小文件数量、快照过期周期 |
| 元数据与治理层 | Hive Metastore、Unity Catalog、数据血缘工具 | 元数据服务节点规格、索引存储开销 |
| 计算引擎层 | Spark、Flink、Presto/Trino、StarRocks | CPU/内存配比、Executor 数量、并发查询数 |
| 调度与接入层 | Airflow、DolphinScheduler、Kafka、REST API | 调度频率、任务依赖复杂度、API 网关吞吐 |
2.3 部署模式：三种主流选择
根据企业的云环境、数据规模和运维能力，湖仓一体的部署模式可分为以下三类。容量规划策略会因部署模式不同而差异显著。
模式一：云原生托管模式（SaaS / PaaS）
使用云厂商提供的全托管湖仓服务（如 AWS Lake Formation + EMR、阿里云 MaxCompute + DataWorks、Databricks Lakehouse）。企业无需关心基础设施，容量规划主要聚焦于计算资源的弹性伸缩策略和存储生命周期管理。例如，设置 Spark 集群在 8:00-10:00 的报表高峰期自动扩容至 200 个 Executor，在夜间缩容至 20 个。
模式二：自建开源模式（On-Premises / 私有云）
基于开源组件（HDFS + Iceberg + Spark + Trino）自行搭建。此模式容量规划需考虑硬件采购周期，通常需要提前 3-6 个月预估增长。核心规划对象包括：NameNode 内存（每 100 万个文件块约需 1GB 内存）、DataNode 磁盘容量（建议预留 30% 余量用于数据重平衡）、计算节点 CPU:内存比（Spark 推荐 1:4 至 1:6）。
模式三：混合模式（数据湖在云、数仓在本地或反之）
部分企业出于数据合规或迁移成本考虑，将历史冷数据存放在本地 HDFS，将热数据或需要弹性计算的数据放在云上。这种模式下，网络带宽成为容量规划的关键瓶颈，需要评估跨地域数据传输的吞吐量和延迟。
选型建议：如果团队运维能力有限且预算充足，优先选择云托管模式，将精力聚焦在业务建模和数据治理上；如果对数据主权有强要求或已有成熟 Hadoop 运维团队，可考虑自建模式，但务必为硬件扩容预留足够长的采购周期。
2.4 案例：某金融企业湖仓一体部署规划
某股份制银行计划构建湖仓一体平台，用于整合核心交易数据（Oracle 每日增量约 200GB）、用户行为日志（Kafka 每日约 1.5TB）和外部征信数据（每日约 100GB）。他们选择了自建开源模式，采用 Iceberg + Spark + Trino 架构。
容量规划初期估算如下：
存储容量估算：
- 每日新增原始数据：200GB + 1500GB + 100GB = 1.8TB
- 压缩后（Parquet + Snappy，压缩比约 1:4）：约 450GB/日
- 年存储量：450GB × 365 ≈ 164TB
- 考虑 3 副本（HDFS 默认）：164TB × 3 = 492TB
- 加上 Snapshot 保留（30 天）和临时文件：约 550TB 裸容量
计算资源估算：
- 每日 ETL 任务（Spark）：高峰时段需 80 个 Executor（每个 8GB 内存 + 4 vCPU）
- 即席查询（Trino）：需支持 30 个并发查询，每个查询峰值 5GB 内存
- 总计算内存需求：80×8GB + 30×5GB ≈ 790GB，预留 40% 余量后约 1.1TB实际运行三个月后发现，Iceberg 的元数据表（Manifest 文件）增长速度超出预期，因为该银行每 5 分钟执行一次微批写入，产生了大量小文件。通过调整提交频率为每 15 分钟一次，并启用定期 Compaction（合并小文件），元数据开销降低了约 60%。
2.5 常见误区与复盘
误区一：认为湖仓一体不需要容量规划。湖仓一体虽然实现了存储与计算分离，但并不意味着资源无限。对象存储的请求数（QPS）限制、元数据服务的连接数上限、计算集群的队列资源仍然需要精细规划。曾有一家企业因未预估 Iceberg 元数据操作频率，导致 Metastore 服务频繁超时。
误区二：忽略“小文件问题”对容量和性能的双重打击。流式写入或高频微批任务会产生海量小文件（远小于 HDFS Block 默认 128MB）。每个小文件都会占用 NameNode 内存、增加查询时打开文件的开销。容量规划时不仅要算“数据总量”，还要估算文件数量。建议设置自动 Compaction 策略，将文件大小优化至 256MB-1GB 区间。
复盘要点：在湖仓一体容量规划中，务必区分“存储容量”与“元数据容量”。存储容量关注字节数，元数据容量关注文件数和分区数。一个包含 1 亿个文件的表，即使总数据量只有 10TB，其对 NameNode 和 Metastore 的压力也远大于一个包含 1 万个文件但数据量为 100TB 的表。规划时建议按“文件数 × 平均元数据开销”单独建模。
最后需要强调的是，湖仓一体架构的容量规划是一个持续迭代的过程。随着业务增长、查询模式变化和新技术组件引入，原有的规划假设会逐渐失效。建议每季度对存储增长趋势、计算资源利用率、小文件数量、元数据服务负载等关键指标进行复盘，并据此调整扩容计划和治理策略。只有将容量规划嵌入日常运维循环，才能真正实现湖仓一体平台在成本与性能之间的长期平衡。