计算与存储分离

在传统关系型数据库管理系统和早期大数据平台（如 Hadoop HDFS）中，存储和处理能力紧密结合。如果磁盘空间不足，您必须向集群添加更多服务器。这种操作不可避免地会为系统增加更多 CPU 和 RAM，无论您是否真的需要额外的处理能力。这种架构造成资源不匹配，您通常只需为保留历史数据而支付闲置计算资源的费用。

现代数据湖架构从根本上摒弃这种耦合模式。相反，它们实现了计算与存储的分离。在此设计中，数据存放在持久化对象存储层中（如 AWS S3、Azure Blob 存储或 Google Cloud 存储），而数据处理则使用 Apache Spark、Trino 或 Databricks 等引擎在单独的短暂层中进行。

分离的经济效益

分离的主要驱动因素是能够根据不同的工作负载要求独立扩展资源。随着组织积累日志、交易历史和传感器遥测数据，数据存储需求通常随时间线性或指数级增长。然而，计算能力需求通常是周期性或突发性的，在夜间 ETL 任务或月末报告期间达到高峰，而在非工作时间保持较低水平。

当这些组件分离时，总拥有成本从刚性的阶梯函数变为灵活的线性方程。

$总成本 = 存储成本 + 计算成本$

在此方程中，$存储成本$ 代表在对象存储上保留数据的持续低成本（通常按每千兆字节每月计费），而 $计算成本$ 则成为活跃处理时间的函数。如果没有查询运行，$计算成本$ 理论上可以降至零。这使得工程团队能够将数PB的历史数据保留在“冷”存储层中，而无需维护一个庞大、始终在线的集群来承载它。

架构组件

为了实现这种架构，系统依赖于高吞吐量 (throughput)网络带宽作为存储和处理器之间的总线。

1. 存储层： 这是一个高持久性、广泛复制的存储库。它充当“事实来源”。它是被动的；它不执行逻辑。它只接受 PUT、GET 和 LIST 请求。
2. 计算层： 这由无状态集群组成。这些节点可以在重负载期间进行配置、扩展，并在作业完成后立即终止。由于它们不持有任何持久状态，因此丢失计算节点不会导致数据丢失。

这种架构将处理单元与数据持久层分离。计算节点通过网络访问数据，而不是从本地磁盘读取。

网络 I/O 的权衡

计算与存储的分离带来了显著的可伸缩性和成本优势，但同时也引入了延迟惩罚。在耦合架构（如 HDFS）中，代码执行通常会移动到数据所在的节点。这被称为数据本地性。从本地磁盘读取数据比通过网络连接读取数据要快得多。

在分离式数据湖中，网络成为瓶颈。每个处理的字节都必须通过网络从对象存储传输到计算集群的内存。为了减轻这种延迟，现代数据湖依赖于三种技术策略：

1. 列式格式： 使用 Apache Parquet 或 ORC 等格式，计算引擎能够仅读取查询所需的特定列，从而显著减少网络流量。
2. 分区裁剪： 将数据组织成目录结构（例如，date=2023-01-01/），使引擎能够跳过存储桶中与查询过滤器不匹配的整个部分。
3. 缓存： 许多查询引擎在计算节点上实现本地 SSD 缓存。数据首次从对象存储中拉取时，会被本地缓存。后续查询则从“热”本地缓存中读取，模拟耦合架构的性能。

无状态性与弹性

这种分离的一个主要技术优势是计算层的无状态特性。在传统数据库中，升级软件通常需要复杂的迁移计划和潜在的停机时间。在分离式架构中，您可以启动一个运行最新版 Spark 或 Trino 的新集群，将其指向 S3 中相同的数据，并切换流量。如果新集群出现故障，数据在存储层中保持不变。

这种无状态性也使得可以使用 Spot 实例 (AWS) 或抢占式虚拟机 (GCP)。这些是云服务提供商以大幅折扣提供的多余计算容量。由于计算节点不持有“事实来源”，该架构能够应对节点被云提供商突然回收的情况。调度器只需在不同节点上重试任务，并再次从存储层获取数据。

通过隔离这些关注点，您可以优化存储布局以实现持久性和成本效益，同时优化计算层以提高速度和并发性。这种分离是构建可伸缩数据湖的基础。