1 Parquet 缓存中的网络、解码与内存开销
《LiquidCache: Efficient Pushdown Caching for Cloud-Native Data Analytics》研究的是对象存储与计算节点之间的独立缓存层，如何高效执行过滤。论文发表于 PVLDB 2025，由 Wisconsin--Madison 与 InfluxData 的研究者共同完成，系统基于 Apache DataFusion 实现。1
InfluxDB 3 同样基于 Parquet、Arrow 和 DataFusion 构建。2 借着这篇论文，也可以窥见 InfluxDB 3 背后的一些工程思考：缓存应该保存什么样的数据表示，如何在压缩率、内存占用与查询执行成本之间做取舍。
在论文讨论的独立缓存部署中，缓存命中后，数据仍然需要经过网络到达计算节点。对于只保留少量行的分析查询，把涉及的 Parquet 数据传过去、再完成过滤，会浪费缓存与计算节点之间的带宽。将过滤下推到缓存节点，可以提前排除无效行，但也把 Parquet 的解压和解码放到了缓存侧。
Figure 1 给出了 ClickBench Q22 的时间拆分。论文的 Parquet 下推基线中，解压和解码占用超过 90% 的 CPU 时间，真正执行过滤表达式的部分不到 10%。缓存服务器需要为过滤准备数据，这部分准备工作比过滤本身贵得多。1
图 1：解压、解码与过滤的 CPU 时间。该比例来自 Q22 及论文所用实现，不能代表所有 Parquet 查询。原图来自论文 Figure 1，第 5662 页。1
直接把解码后的 Arrow 数据缓存起来，后续查询可以省去重复解码，但需要更多内存。以论文单独分析的 Title 字符串列为例，Parquet 大小为 2.4 GB，Arrow 为 12.9 GB。独立缓存原本希望用较少 CPU 服务多个计算节点，全部保存成 Arrow 后，内存容量又成为约束。1
LiquidCache 在缓存层将 Parquet 转成 Liquid 表示，并将编码方式与过滤执行一起设计：保留较高压缩率，支持按元素访问，只解码当前过滤步骤需要的数据，适用时直接在编码上完成比较。对象存储中的 Parquet 文件保持原样，计算端通过连接器接入缓存。这个设计同时处理重复解码、内存膨胀和无效数据传输，改变的是缓存内部的数据表示与执行路径。1
2 Liquid 表示、过滤执行与后台转码
2.1 查询路径与缓存组织
LiquidCache 在缓存节点内嵌 DataFusion。计算端通过 TableProvider 获取表结构、生成查询计划，再将可以下推的扫描与算子交给缓存端；计划通过 protobuf 传递，返回数据使用基于 gRPC 的 Arrow Flight。其余算子继续在计算节点执行。1
图 2：示例查询将 school = 'UW-Madison' 下推到缓存侧，DISTINCT 留在计算侧。图中第 9 步是后台转码，后续查询可以复用 Liquid 数据。原图来自论文 Figure 3，第 5665 页。1
缓存节点先查内存，再查本地磁盘，最后回源。内存中已完成转码的数据以 Liquid batch 驻留，转码过程中也可以保留 Arrow 或其他可执行的中间表示；磁盘保存回源下载的 Parquet 字节，也接收从内存淘汰的 Liquid batch。各层的数据表示与转换条件如下。1
| 位置 | 数据表示 | 形成条件 | 读取或转换方式 |
|---|---|---|---|
| 对象存储 | Parquet | 原始数据持久化 | 缓存未命中时读取所需字节范围 |
| 缓存节点磁盘 | Parquet 字节 | 回源下载并缓存 | 读取后解码为 Arrow |
| 缓存节点内存 | Arrow 或编码中间态 | Parquet 已解码，Liquid 转码尚未完成 | 后台继续转成 Liquid |
| 缓存节点内存 | Liquid | 后台转码完成或从磁盘重新加载 | 按过滤与输出需求选择解码深度 |
| 缓存节点磁盘 | Liquid（FlatBuffers 风格布局） | Liquid batch 从内存淘汰 | 读回已有 Liquid 编码，无需重新从 Parquet 转码 |
冷读下载范围由查询和 Parquet 元数据决定，小范围请求可以合并。所需数据尚未以 Liquid 缓存时，Parquet 解码出的 Arrow 用于当前查询，同时进入后台转码队列；查询可以使用已有的 Arrow 或编码中间态，不必等 Liquid 全部生成。后续命中 Liquid 时，编码支持的过滤可以直接执行，需要原始值的部分再按需解码。这里要区分生成缓存表示的 Arrow → Liquid 转码，与查询执行时的 Liquid 解码，二者发生的条件不同。1
Liquid 的内存缓存单元是列内的 batch，默认包含 8192 行，缓存项由文件名、RowGroup、列索引和行号定位。淘汰使用列级 LRU，因为同一列的多个 batch 往往一起访问，不同列的热度则可能差别很大。表中列出的是各层可能出现的数据状态，Parquet 与 Liquid 磁盘副本的保留取决于空间管理与淘汰策略；论文将具体的磁盘空间管理留给部署实现。1
这种组织允许不同过滤条件复用同一份列数据。查询从 A = 'Madison' 改成 A = 'Utah'，已有的 Liquid 列仍然有用；能够省下多少执行工作，取决于新的过滤条件是否适合直接在编码上计算。缓存生命周期跟随文件：论文假定 Catalog 管理导入和 Compaction，文件被移除时，相应缓存项也被移除。
下推范围也有约束。论文支持同表列上的过滤，排除昂贵 UDF；列投影总是下推，COUNT、SUM、AVG、MIN、MAX 等低成本聚合也可以下推。DISTINCT 等需要维护较大内存结构的操作留在计算侧。对上述可下推算子，原型没有进一步做基于成本的选择；跨引擎的 Substrait 计划支持也属于后续工作，论文实现使用 DataFusion 自身的计划格式。1
2.2 Liquid 相对 Arrow 的取舍与编码方式
图 3：同一列字符串从 Arrow 逐步转成 Liquid，括号标出中间阶段使用的表示。原图来自论文 Figure 4，第 5666 页。1
这张图画的是同一列字符串在 LiquidCache 中逐步压缩的过程。最左边的 Liquid (Arrow) 表示缓存当前仍以 Arrow 数组保存数据；之后依次转成字典表示、Key 被压缩的表示，最右边再压缩字典里的字符串。括号说明当前的编码阶段，每个阶段都可以用于查询。1
Arrow 为什么占用较多内存
图中最左边按行保存展开的字符串，例如 Apache DataFusion 出现三次，就占了三份字符串空间。这种表示方便直接计算，但重复内容也留在内存里。普通 Arrow 整数数组则按类型保留固定位宽，例如 Int64 每个值占 64 bit，即使实际数值很小。3
Liquid 增加了哪些压缩
先用字典去重：图中只有四种不同字符串，各保存一份，每行只记录一个整数 Key。再压缩 Key：四种取值用 2 bit 就够了，图中的 Key 因此从 32 bit 缩小到 2 bit。最后用 FSST 压缩字典值：把反复出现的字符串片段换成短编码，图中 Apache DataFusion 就被表示为 cd。整数列也有类似思路，先减去基准值，再用较少的 bit 保存差值。1
Arrow 本身也支持字典编码，其标准字典索引使用 8、16、32 或 64 bit 整数。3 Liquid 在此基础上进一步按实际取值压缩 Key，并给字典字符串叠加 FSST。论文 Title 列的内存占用依次为：Arrow 12.9 GB → 字典编码 5.0 GB → Key 压缩后 4.7 GB → 完整 Liquid 2.0 GB。收益来自这些具体编码，大小比例随数据分布变化。1
Liquid 更快的情况
当 Arrow 数据放不进缓存时，Liquid 的体积优势可以减少缓存未命中后的磁盘读取或回源，省下的 IO 时间可能超过新增的解码时间。论文中采用 8 GB 数据缓存的 TPC-H 实验就体现了这一点。如果过滤还能直接比较编码，或提前排除大量后续无需解码的数据，Liquid 的执行成本也会降低。1
Liquid 更慢的情况
当 Arrow 数据已经在内存里，过滤又需要读取大量原始字符串时，Arrow 可以直接计算，Liquid 还要先解码。论文中的 Q20、Q23 因此比 Arrow 慢，即使最终输出的行很少。首次生成 Liquid 还要付出后台转码成本。因而，比较快慢要看省下了多少 IO 和内存访问，以及为此多做了多少转码、解码。1
2.3 选择性解码与延迟物化
图 4：上方先解码两列再过滤，下方先用第一列的过滤结果缩小第二列的解码范围。原图来自论文 Figure 6，第 5667 页。1
图中两条路径的区别
图里的两列都用于过滤。上方的 Eager 路径先解码两列，分别计算过滤条件，最后合并结果；下方的 Late 路径先处理第一列，用过滤结果决定第二列需要解码哪些行。第一列已经排除的行，第二列就可以跳过。这里的物化，可以理解为把编码数据还原成当前算子需要的值。1
选择性解码：只还原需要输出的数据
以过滤条件 status = 500 AND latency > 1000、最终返回 url 为例。选择性解码（Selective Decoding）先完成过滤，得到标记哪些行通过的 Bitmap，再只解码这些行的 url。未通过过滤的行，其 url 无需展开。这一步节省的是输出列的解码工作。1
延迟物化：过滤列也可以少解码
延迟过滤物化（Late Filter Materialization）把同样的办法用到过滤列本身。假设先判断 status = 500，只留下 1% 的行，那么后续只需解码这 1% 对应的 latency，再判断是否大于 1000；最后才解码符合两个条件的 url。这样，后续过滤列的解码和比较也减少了。例子假设先处理 status，实际顺序由执行计划决定。1
Liquid 为什么能跳过这些数据
Liquid 的编码支持独立访问元素，可以直接按 Bitmap 选择需要解码的位置。Parquet 的压缩通常以 page 为单位，即使只需要页内几行，也可能仍要解压整个相关 page；实际能跳过多少工作还取决于编码和 reader。因此，相同的过滤结果，在 Liquid 中可以用于更细粒度的解码。1
能直接比较编码时，进一步省掉解码
字符串等值过滤可以把查询常量用相同的符号表编码，直接比较编码后的字典值，再通过 Key 找到对应行。遇到 LIKE '%xxx%' 这样的子串条件，论文实现仍需还原字典中的字符串，但可以先在去重后的字典上判断，再映射回各行。解码到哪一步，取决于过滤表达式需要什么数据。1
2.4 转码成本与格式兼容性
转码按查询需要的列和 batch 逐步进行。已有查询解码出的 Arrow 数据可以直接复用，后台任务再将其转换成 Liquid。缓存节点等待对象存储 IO、计算节点执行 Join 或聚合，以及负载较低的时段，都可以为后台转码提供 CPU 时间。1
后台执行改变的是转码与查询的重叠关系，CPU 工作量仍然存在。若存储读得很快，或者缓存节点一直处于高负载，转码就可能争抢资源。原始 Parquet、暂存的 Arrow 与 Liquid 也可能在转换期间同时存在，稳态缓存大小不能直接代表转码时的峰值内存。
对象存储中的权威数据继续使用 Parquet，Liquid 则作为可重建的缓存副本，既可以驻留内存，也可以在淘汰时写入缓存节点的磁盘。磁盘上的 Liquid 可以直接重新加载，缓存副本丢失后仍能从原始 Parquet 重建。下游通过 Arrow 接收结果，部分可表达为字典数组的数据还可以保留编码后传输。由于 Liquid 的使用范围限于缓存层，更新其内部编码无需同步修改对象存储里的历史文件与所有 Parquet 消费者。引擎仍需接入相应连接器和下推计划。1
3 实验配置、性能收益与退化条件
3.1 测试环境与基线
论文主实验使用 ClickBench 的约 15 GB、1 亿行 Web 分析数据，选取 Q10、Q19、Q20、Q21、Q22、Q23、Q31，覆盖字符串、整数和多列过滤。过滤通过率从小于 0.01% 到 13.2%，其中 Q22 为 0.02%。这里的 selectivity 指通过过滤的行比例，数值越低，排除的数据越多。1
机器为 CloudLab 6525，16 核、32 线程的 x86_64 CPU，128 GB 内存、SATA SSD，网络为 10 Gbps。实验关闭 TLS，Arrow Flight 不额外压缩。每条查询执行 5 次，取后 3 次平均值；延迟覆盖 SQL 解析到结果返回，除非另行说明，Liquid 已完成转码。1
对照方法由论文统一实现：
| 方法 | 缓存数据表示 | 过滤执行位置 |
|---|---|---|
| Parquet (file server) | Parquet 字节 | 计算节点 |
| Parquet (pushdown) | Parquet 字节 | 缓存节点 |
| Arrow (pushdown) | Arrow 数组 | 缓存节点 |
| LiquidCache | Liquid 编码 | 缓存节点 |
File server 是支持 Range Request 的静态文件服务；另外两种下推基线同样内嵌 DataFusion，并通过 Arrow Flight 返回数据。这组对比用于分析缓存表示与执行位置，没有直接测试 GooseFS 或 Alluxio 产品。1
3.2 热缓存、内存容量与优化贡献
图 5：依次比较端到端延迟、网络字节数、缓存侧 CPU 时间与数据缓存内存。网络图使用对数轴，延迟图中超出纵轴范围的柱子另标数值；内存统计不包括执行时的数据结构。原图来自论文 Figure 7，第 5670 页。1
在这组查询上，LiquidCache 与 Arrow 下推的端到端延迟均不超过 0.5 秒，Parquet 下推最高约 2 秒，file server 最高约 13 秒。LiquidCache 在多数查询上接近 Arrow，但 Q20、Q23 涉及大字符串列，仍需额外解码，其延迟高于 Arrow。1
网络收益主要来自提前过滤。三种下推方案的流量接近，LiquidCache 在适用时发送部分编码的数据，还能略微减少传输。Q19---Q23 的通过率很低，流量与 file server 拉开多个数量级；Q10、Q31 通过的行较多，差距缩小。不能将这部分收益全部归因于 Liquid 编码，Parquet 下推本身也减少了大量网络传输。1
CPU 则体现了改变表示的价值。论文对 Q22 进一步拆分，缓存侧 CPU 时间从 Parquet 下推的 27 秒降到 LiquidCache 的 2.7 秒，接近 Arrow 下推。这里统计的是各核累计的 CPU 时间，和前面的端到端延迟不同，不能据此声称这条查询快了 10 倍。Arrow 省去了重复解码，但更大的未压缩数据带来更多内存停顿；Liquid 在保留压缩的同时，减少了实际需要解码的数据。1
内存统计只计算缓存数据，不包含 Join 哈希表等运行时结构。Q23 的 Arrow 缓存超过 30 GB，Liquid 与 Parquet 接近。第 2.2 节拆解的 Title 列中，完整 Liquid 为 2.0 GB，原始 Parquet 为 2.4 GB；这一比例对应具体列的数据分布。1
论文另用 TPC-H SF100 的 8 条扫描较重查询测试数据大于缓存的情况，总内存上限设为 24 GB，其中 8 GB 用于数据缓存，16 GB 留给执行过程。数据能放入缓存时，Arrow 表现很好；超出容量后，体积更小的 Liquid 保留了明显优势。该实验还比较了 ORC，不过 ORC 与 Parquet 在 DataFusion 中的集成程度不同，结果同时受到 reader 和执行引擎实现影响。1
消融实验显示，选择性解码对输出列较多、过滤后只剩少量行的查询收益较大；多列谓词还需要延迟物化来减少过滤阶段的解码。直接在编码上计算的收益依赖表达式。论文专门修改 Q22 的过滤条件，使其适配大列上的编码比较，完整优化将耗时从 Parquet 基线的 34.1 秒降到 0.4 秒。这个结果来自改写后的 Q22，应与原始查询分开看。1
3.3 冷读转码与下推退化
图 6：Parquet 直接读文件；LiquidCache (blocking) 逐 batch 同步转码；LiquidCache 将转码与 IO 重叠。左侧为冷读，右侧为稳定后的热读。原图来自论文 Figure 12，第 5672 页。1
冷读实验覆盖跨洲 S3、较近区域的 S3／S3 Express、同集群 MinIO、本地 SSD 和内核 page cache。IO 较慢时，后台转码能够与等待重叠，延迟接近直接读取 Parquet；数据已经位于 page cache、存储吞吐超过转码吞吐时，转码成本变得可见。另一个 Q21 实验把后台转码限制为 4 个线程，缓存内存逐渐缩小约 4 倍，查询延迟增加约 20%。后台转码有收益，也有可观测的代价。1
更直接的反例是 ClickBench Q27：99% 的行通过过滤，Parquet 压缩后大小约为未压缩数据的 31%，LiquidCache 反而比 file server 慢约 3 倍。返回的数据大多仍然有效，下推后却以更大的内存表示传输，网络成本超过了直接发送压缩数据。1
在扫描列与输出列相同、按相同未压缩数据量估算、忽略协议开销且不额外压缩输出时，通过过滤的数据比例需要小于压缩后体积占比，下推才会减少网络字节数。实际决策还要考虑投影、聚合、输出行宽和两端 CPU 负载。原型支持由用户指定哪些表采用计算节点本地的 Liquid 缓存，但自动成本选择仍是后续工作。1
以上数据均来自论文，未在本地复跑。它们验证了特定查询、资源配置和缓存状态下的收益；生产环境的缓存命中率、并发竞争、持续转码吞吐与尾延迟，仍需要用自己的负载确认。
4 结束语
我一直在思考，相对于 GooseFS、Alluxio 这类通用缓存，垂类系统自己做缓存的优势究竟在哪里。
讨论这些优势有一个前提：一定要从实际的 workload 出发，先看时间花在哪里、哪个资源已经成为瓶颈。优化有顺序，先解决当前最主要的瓶颈，再重新测量，确认瓶颈转移到了哪里，一个瓶颈一个瓶颈地解决。比如回源 IO 降下来之后，解码 CPU 才可能成为主要开销，继续增加缓存容量就未必还有同样的收益。具体先做什么，要由负载和资源配置决定，后面这些优化也需要按这个顺序判断是否值得投入。
4.1 缓存优化方案汇总
下面按方案归纳各自处理的瓶颈。通用缓存主要对照 GooseFS、Alluxio，并补充 CacheLib 组件；已有能力与尚需引擎协作的部分分别注明。表中"未查到"仅表示截至 2026-09-11 未找到同等机制的公开证据。
| 代表方案 | 解决的问题 | 核心做法 | 通用缓存是否已有实现（含链接） |
|---|---|---|---|
| GooseFS／Alluxio45 | 回源慢、重复读取 | 按文件字节范围缓存 page，复用已读数据。 | 已有 ：GooseFS Page Store、Alluxio Paging Worker。 |
| LiquidCache1 | 内存膨胀、重复解码、无效传输 | 按 RowGroup6 内的列与默认 8192 行 batch 缓存，后台压缩为 Liquid；结合选择性解码、延迟过滤物化、编码上计算，在缓存侧完成过滤与投影。 | 部分 ：Alluxio 已展示 Parquet 下推；Liquid 式压缩表示与解码协同未查到同等实现。 |
| ReCache（PVLDB 2017）7 | 只看命中，忽略重算成本 | 测量读取、解析、执行与复用成本，结合复用次数和大小，优先保留更能节省计算的对象。 | 部分 ：Alluxio 静态优先级 可表达重要性，未核实自动测量重算收益。 |
| PACMan（NSDI 2012）8 | 局部命中，作业仍拖尾 | 在 IO 主导的单轮并行作业中，按输入完整覆盖评估缓存收益，减少未命中任务拖慢整个作业。 | 部分 ：Alluxio 可保护作业数据集，未核实按作业完整性做全局决策。 |
| Snowflake（NSDI 2020）9 | 负载倾斜、扩容搬迁、空间争用 | 调度兼顾缓存局部性与预计完成时间；扩容后按需建立缓存；临时中间数据优先使用本地空间。 | 部分 ：Alluxio／Presto 已有局部性调度，DORA 已有扩容后按需填充；临时空间优先策略未查到。 |
| StarRocks10 | 缓存污染、磁盘拥塞 | 按语句及扫描范围控制填充（3.3.2 起，有例外）；缓存盘拥塞时由 I/O Adaptor 将部分读取转向远端。 | 部分 ：已有 Alluxio 路径准入和超时回源，分别区别于语句感知准入、按拥塞主动分流。 |
| Doris（4.x）11 | Compaction 冲掉热点 | 临时读取进入低优先级 Disposable 队列；Cumulative 输出上传时填充缓存，Base 输出默认仅在空间充足时填充。 | 部分 ：Alluxio 已有优先级淘汰，Compaction 类型与读写阶段仍需上层识别。 |
| Tectonic-Shift（ATC 2023）12 | 无效写入、SSD 磨损 | 根据 ML 任务与访问历史预测复用，决定准入和重插入，并用 PID 反馈约束写入速率。 | 部分 ：CacheLib Navy 已有写入预算控制，任务感知预测由 Shift 定制。 |
| Alluxio／Uber（ATC 2024）13 | 容量争抢、过期数据堆积 | 按表／分区准入，用分层配额约束共享容量，通过 scope 索引批量回收过期分区。 | 已有 ：Alluxio／Uber 集成 已实现；GooseFS Table 管理 也支持按分区释放缓存。 |
预取方面，Alluxio DA-3.7 已有自适应顺序预读和整文件预加载。本文的设想是进一步结合投影、动态过滤和算子进度安排预取，在查询取消或数据被排除时停止，并限制预取带宽。
内存压缩要先对齐比较对象。 Liquid 的内存优势主要是相对于解码后的 Arrow 数组，原样缓存 Parquet 的通用缓存本来就保留了文件中的压缩。Liquid 的特点在于将紧凑表示与按元素解码、过滤执行一起设计，不能据此推导它一定比缓存 Parquet 字节更省空间。类似地，page 缓存也能承接引擎裁剪后的范围读取，是否缓存了无用列，还取决于上层实际发出了哪些 IO。
过滤下推也已经进入通用缓存的探索范围。 表中的 Alluxio 白皮书展示了 Worker 执行 Parquet 点查、只返回所需列与匹配行，并缓存已反序列化的文件元数据。不过材料没有给出这项能力的正式发布版本，也没有披露 Liquid 式内存编码与多列延迟物化，不能直接等同于 LiquidCache 的完整方案。14
这些结果使比较更具体了：按表管理、配额、生命周期和部分调度能力已经能通过通用缓存与引擎的集成实现。更值得追问的是引擎能提供哪些信息、缓存能执行哪些决策，以及双方是否一起优化查询的完成时间。底层继续使用 page，也能做出很多有价值的工作。
4.2 缓存表示与实际瓶颈
这篇文章给了我一个全新的思路：缓存可以保存一份专门为计算准备的数据表示。Parquet 在对象存储上承担压缩、持久化和生态兼容的职责，缓存层则可以重新编码数据、与过滤算子一起优化。只要能够从原始文件重建，内部表示就有更大的调整空间，采用一种新的编码不必先推动所有上下游一起迁移文件格式。
这样看，垂类系统的优势除了智能预取、选择缓存哪些数据，还可以继续深入到命中之后：读出来的数据还要做多少次解码，过滤前需要物化多少行，哪些计算可以直接在编码上完成。缓存命中率相同，后面的 CPU 和网络开销仍然可能差很多。能省下多少重复工作，还要和新增的集成、运维及资源隔离成本一起评估。
当然，对工程来说，最重要的事情还是瓶颈到底是什么。对象存储的首字节延迟、缓存与计算之间的带宽、Parquet 解码 CPU、内存容量，甚至更上层的 Join 和聚合，决定了优化应该落在哪里。LiquidCache 的起点是 Q22 中超过 90% 的 CPU 时间花在解压和解码上；Q27 下推后慢了 3 倍，则说明换一个过滤通过率，同一项优化就可能产生反效果。1 先把瓶颈测出来，再决定缓存要懂多少业务。
5 参考资料
1 Xiangpeng Hao、Andrew Lamb、Yibo Wu、Andrea Arpaci-Dusseau、Remzi Arpaci-Dusseau：LiquidCache: Efficient Pushdown Caching for Cloud-Native Data Analytics，PVLDB，18(13)：5662--5675，2025，DOI：10.14778/3773731.3773741。正文与配图以此 PDF 为准。
2 Paul Dix：InfluxDB 3 Core & Enterprise GA: The Next Generation Time Series Platform for Developers is Here，InfluxData 官方博客，页面更新日期：2025-11-20；核查日期：2026-09-11。本文引用其 FDAP 技术栈说明，用于交代与 LiquidCache 相通的技术背景。
3 Apache Arrow：Arrow Columnar Format，核查日期：2026-09-11。本文引用 Fixed-size Primitive、Variable-size Binary 与 Dictionary-encoded Layout，用于区分普通数组布局和字典数组。
4 腾讯云：GooseFS Page Store 缓存，文档更新日期：2026-04-03；核查日期：2026-09-11。
5 Alluxio：Caching --- Paging Worker Storage，核查日期：2026-09-10。本文仅引用该文档描述的 page 缓存路径。
6 Apache Parquet：Concepts，用于核对 RowGroup、column chunk 与 page 的层级及语义，核查日期：2026-09-10。
7 Tahir Azim、Manos Karpathiotakis、Anastasia Ailamaki：ReCache: Reactive Caching for Fast Analytics over Heterogeneous Data，PVLDB，11(3)：324--337，2017。本文引用第 5 节的缓存准入和成本驱动淘汰。
8 Ganesh Ananthanarayanan 等：PACMan: Coordinated Memory Caching for Parallel Jobs，NSDI 2012。本文引用其波次执行模型与作业级缓存收益分析。
9 Midhul Vuppalapati 等：Building An Elastic Query Engine on Disaggregated Storage，NSDI 2020，449--462。本文引用第 4.2、5、6.1 节；描述对应论文当时的 Snowflake 实现。
10 StarRocks：Data Cache，核查日期：2026-09-11，所读页面标记为 Latest-4.1。本文引用填充规则与 I/O Adaptor，填充规则的起始版本以文档标注的 3.3.2 为准。
11 Apache Doris：File Cache Internals: Cache Slicing, Multi-Queue Management, Eviction, and Warm-Up，4.x 文档，核查日期：2026-09-11。本文引用多队列和 Compaction 的读写缓存策略。
12 Mark Zhao 等：Tectonic-Shift: A Composite Storage Fabric for Large-Scale ML Training，USENIX ATC 2023。本文引用第 5.1 节的任务信息、准入／重插入策略和闪存写入速率控制。
13 Chunxu Tang 等：Data Caching for Enterprise-Grade Petabyte-Scale OLAP，USENIX ATC 2024。本文引用第 4.4、5.1、5.2 节的 scope 索引、准入与分层配额，以及第 6.1.2、8 节的 Presto 调度集成与超时回源保护。
14 David Zhu、Yuyang Wang、Venkata Pradeep Panchumarthi、Sreeram Garlapati、Bin Fan：Meet in the Middle for a 1,000x Performance Boost Querying Parquet Files on Petabyte-Scale Data Lakes，Alluxio／Salesforce 技术白皮书，核查日期：2026-09-11。本文引用点查场景中的 Worker 谓词／投影下推及元数据缓存实验，未核实正式发布版本，也不采用标题中的性能倍数作跨系统比较。