趋近智
趋近智
数据湖提供了将存储与计算资源分开扩展的灵活性。这种解耦可以降低成本并简化容量规划，但也带来了显著的性能瓶颈：网络延迟。传统数据库的存储引擎通常位于同一台物理机器或经过优化的低延迟专用存储区域网络（SAN）上。数据湖架构中的查询引擎必须通过网络连接从Amazon S3、Azure Blob Storage或Google Cloud Storage等对象存储服务获取数据。
网络I/O通常是查询生命周期中最慢的操作。获取文件头以读取元数据或获取列块进行处理会产生数十到数百毫秒的延迟。当查询需要扫描数TB的数据时，这种延迟会累积，导致性能缓慢。缓存策略通过将常用数据存储在更靠近计算资源的位置来降低此开销，这实际上是用对象存储廉价但缓慢的容量换取本地内存或SSD昂贵但快速的性能。
分布式系统中的优化发生在多个层次。查询通常会先通过一个协调器节点，然后任务才被分配给工作节点。在此生命周期的每个阶段都存在缓存机会，针对不同类型的数据获取开销。
在查询引擎读取一行数据之前，它必须了解表结构。这需要与目录（例如Hive Metastore或AWS Glue）通信，以获取模式定义并列出分区位置。对于包含数千个分区的表，此元数据发现过程可能比实际的查询执行时间更长。
元数据缓存将文件列表和分区映射存储在协调器节点的内存中。当用户执行重复查询时，引擎会跳过对对象存储的耗时列表操作，并立即使用缓存的文件映射生成查询计划。
这是分析中最常见的缓存形式。它解决了将原始数据文件（Parquet或Avro）从对象存储传输到工作节点的开销。当工作节点创建一个读取文件分区的任务时，它会首先检查其本地存储。
如果数据不存在（缓存未命中），工作节点会从对象存储中拉取数据，并将其副本写入本地NVMe SSD或RAM。随后对同一文件分区的请求将直接从本地硬件提供。此技术能显著提高吞吐量 (throughput)，通常将I/O性能提升一个数量级。
元数据缓存和数据缓存优化了查询执行的过程，而结果集缓存则存储最终输出。这对于多个用户查看相同可视化的仪表板场景特别有效。引擎不再从原始文件重新计算聚合，而是从内存中提供预先计算的结果。这能将查询时间缩短到接近零，但需要严格的失效逻辑来确保用户不会看到过时信息。
数据获取流程图，显示了工作节点如何优先使用本地SSD缓存，然后才回退到远程对象存储。
为了衡量缓存的影响，工程师会关注有效访问时间（EAT）。此指标代表获取一个数据单元的平均时间，并根据数据在缓存中找到的概率（命中率）进行加权计算。
EAT的计算公式是：
其中：
即使是适度的命中率也能显著降低应用程序感知的总延迟。然而，当命中率接近100%时，系统实际上表现得就像数据在本地一样，完全掩盖了网络限制。
该图显示了延迟如何随着缓存命中率的提高而线性降低。
分布式缓存中的主要难题之一是保持一致性。在数据湖中，文件是不可变的，但表不是。数据集可能会通过摄取作业添加新分区，或通过压缩作业将小文件重写为大文件而得到更新。
如果工作节点上的缓存保留了对已被逻辑删除或覆盖的文件的引用，查询引擎可能会返回不正确的数据，或者因 FileNotFoundException 而失败。
Apache Iceberg和Delta Lake等现代开放表格式通过快照隔离来解决此问题。
由于数据更改时文件路径也会改变，缓存便能有效进行自我管理。旧文件路径会逐渐停止使用，最终由替换策略淘汰，而新文件路径则会生成新的缓存条目。
工作节点上的存储空间是有限的。当缓存满时，系统必须决定删除哪些数据以为新数据块腾出空间。淘汰策略的选择会影响缓存命中率和整体性能。
在部署Trino或Apache Spark等引擎时，由于硬件要求（配置SSD会增加基础设施成本），缓存并非总是默认启用。
在 Trino 中，启用分层存储缓存需要配置 hive.cache.enabled 属性并定义缓存目录。Trino使用一个名为Rubix的库来管理文件系统和本地磁盘之间的交互。
在 Apache Spark 中，缓存通常是明确的。数据工程师会在DataFrame上使用 .cache() 或 .persist() 方法。这会将数据加载到执行器的内存中。然而，商业平台（如Databricks）上的Spark最新版本实现了类似于上述透明I/O缓存的自动磁盘缓存，用户无需进行代码更改。
经过适当调整的缓存策略能将解耦的数据湖从一个冷存储库转变为一个高性能分析引擎，能够服务交互式仪表板和迭代机器学习 (machine learning)工作负载。
这部分内容有帮助吗？
© 2026 ApX Machine LearningAI伦理与透明度•