流式数据读取存在一个经典挑战：当数据读取速度超过处理能力时，系统往往会发生严重问题。

最常见的情况是内存耗尽导致进程崩溃，即使进程未崩溃，也会因低效的文件交换或暂停操作引发性能剧烈降级。

此类问题的解决方案通常归类为"反压机制（Backpressure）"，本文将解析传统反压方案，分析它存在的不足，再介绍 Lance format 在读取文件上的创新设计。

Push vs Pull

在讨论反压机制时，推（push）拉（pull）模型是无法绕开的。

推式系统中，生产者准备好数据后立即发送给消费任务，生产和消费天然并行，如果消费跟不上生产，数据则会积压在消费缓冲区，进而带来反压控制的问题。

而拉式系统中则由消费者主动向生产者拉取数据批次处理，消费者不拉数据时生产者可能出现空转的情况，反压机制天然生效，但并行能力受限。

如果我们深入去看，会发现所有并行扫描或查询引擎实现其实都会不同程度地同时使用两种模式。基于此催生了一些经典解决方案。

经典方案：RowGroup

经典解决方案是通过在生产者与消费者之间构建队列机制来限制可处理的行组（Row Group）数量。

当队列达到容量上限时，文件读取器将主动停止数据摄取。该队列存在多种实现范式：在推式工作流中可采用阻塞队列（Blocking Queue），在拉式工作流中则适用预取队列（Readahead Queue）：

以 PyArrow 扫描器的from_dataset方法为例，其batch_readahead参数（默认值16）控制文件预读批次数量：

batch_readahead - int, default 16    The number of batches to read ahead in a file. This might not work for all file formats. Increasing this number will increase RAM usage but could also improve IO utilization.

这种预读机制在以 parquet 为代表的使用 row group 作为读取单元的列存文件场景下，会面临下面的问题：

1. 粒度混淆问题：该限制阈值（如batch_readahead）通常难以明确区分其作用对象——是基于文件的行组（File-based Row Groups，通常为大粒度）还是计算批次（Compute-based Batches，通常为小粒度）

2. 动态依赖性问题：理想情况下，这个参数的最优阈值取决于查询运行时，根据列裁剪情况动态调整

3. 波动性问题：由于批次大小存在异构性（如Parquet文件内行组大小不均），单查询执行期间需实时适应阈值波动

4. 线程切换开销：批次缓冲需要引入解码线程与计算线程间的上下文切换，Lance 设计中规避了这类开销以降低调度延迟

总体来说，行组的特性为文件的读写配置，IO 性能带来了不确定性，尤其在多模场景中，非结构化数据的体量会让找到一种性能和可用性兼得的方案变得极其困难。

这也是 Lance 设计的初衷之一：它具备配置简单，适用于所有类型的数据集，不依赖行组这三大特性。

Lance 方案：I/O Buffer

要深入理解 Lance 的背压方案设计，我们需要重新审视其核心的 I/O 与解码分离机制。

每个Lance读取器采用双线程协同工作模型：调度线程（Scheduling Thread）负责动态生成 I/O 请求指令，解码线程（Decode Thread）则实时接收数据流并执行解码计算。

在这两个线程之间，存在一个关键的 I/O 调度器，其技术实现包括：

1. 接收调度线程的I/O请求后，基于优先级队列（Priority Queue）进行动态排序，通过令牌桶算法（Token Bucket）限制并发请求数，最终将处理完成的数据块通过环形缓冲区（Ring Buffer）投递给解码线程组

2. 这种架构天然形成了背压控制的黄金切入点——当解码吞吐下降时，调度器会自动触发流量控制机制，包括动态降级请求优先级、减少并发令牌发放等，从而避免系统过载。

当 I/O 调度器完成一个 I/O 请求后，会将数据放入解码器专用的队列——即 I/O 缓冲区。

若该队列填满，则表明解码器处理速度滞后，此时 I/O 调度器将停止发起新的 I/O 请求。待解码器追赶上处理进度、缓冲区开始清空时，I/O 请求的发起才会恢复运作。

I/O 缓冲区最精妙的设计在于其容量单位采用字节而非行数。更重要的是，其理想容量值可通过精确计算得出——我们需要确保缓冲区具备足够空间以充分饱和I/O带宽，使存储设备的吞吐能力得以最大化利用。

该计算需综合考虑存储介质特性（如 NVMe SSD 的队列深度）、网络传输延迟以及解码线程的平均处理速率等核心参数。

一个小问题

遗憾的是，我们在处理变长数据类型（如字符串、列表等）时遇到了一个棘手的问题。

由于无法预先确定磁盘读取的数据量——例如用户请求10,000个字符串时，可能只需1KiB也可能需要50MiB——这种不确定性给系统设计带来了根本性挑战：

我们始终坚持不中断 I/O 操作的原则，这意味着系统不会空转等待字符串长度元数据返回，而是继续处理其他列的低优先级请求。

当最终获取到字符串尺寸信息后，才会发起高优先级的数据读取请求。

但这一机制暴露了新的问题：当I/O缓冲区被低优先级请求占满时，系统可能无法为突然到来的高优先级请求分配空间。由于解码器严格按优先级顺序工作，被阻塞的高优先级请求会导致解码线程停滞，最终引发整个系统的死锁状态。

这种因动态负载失衡导致的级联故障，正是现代存储系统设计中需要攻克的核心难题之一。

当前我们的解决方案是允许高优先级请求绕过背压限制——当请求优先级高于背压队列中的所有待处理任务时，系统会强制放行。

这种方法虽然可行，但在工程实现上显得不够优雅。这促使我们开始思考："如果能预先获知请求优先级，系统设计将更加完善"。

事实上，我们完全可以在文件写入阶段就记录这些关键元数据。

这正是 Lance format v2.1 中实现的核心改进——通过持久化存储 I/O 优先级标记，使读取阶段能够基于预置的智能调度策略，从根本上优化资源分配机制。

这种前瞻性的设计将显著提升变长数据类型处理的确定性，同时保持系统整体的吞吐效率。

总结

在 Lance 中配置背压机制异常简单——事实上，其默认设置的 2G 缓冲区对绝大多数场景都已足够优化，常规使用根本无需手动调整。

这套机制使得系统能够高效读取海量数据文件后，从容不迫地进行低速处理，同时完全规避了内存溢出的风险。

这种特性在处理多模态数据时尤为重要，因为当遇到计算密集型处理环节时，大尺寸数据类型极易消耗过量内存资源。

Lance的背压控制通过智能流量调节，从根本上杜绝了内存浪费的可能性，确保系统始终在最优资源利用率下稳定运行。

推荐阅读

  点击阅读原文，跳转LanceDB GitHub