转载说明：本文译载自 Lance v2: A New Columnar Container Format。原作者：Weston Pace。原文发布时间：2024-04-13。本文保留原文的完整技术论证、示意图与示例代码，仅做适合本站渲染的 Markdown 规范化处理。Lance v2：一种新的列式容器格式 Lance v2：一种新的列式容器格式为什么需要一种新格式？ Lance 之所以被发明出来，是因为现有列式格式的 reader 和 writer 无法高效处理 AI/ML 工作负载。Lance v1 解决了其中一部分问题，但在不少场景里仍然吃力。与此同时，btrblocks、procella 和 vortex 等项目，也在各自的使用场景里发现了 Parquet 的类似问题。下面我想介绍一种新格式 Lance v2，它就是为了解决这些问题而设计的。不过在此之前，我想先说明一下我们在现代工作负载里总结出来的几类典型需求。点查找 点查找（point lookup）是指只访问少量行的查询。只要你在用二级索引，这种访问就非常关键。比如在 LanceDB 里，无论语义搜索还是全文检索，最后都会落到点查找上。Parquet 在点查找上的主要问题是：它的编码方式并不是为“可切片读取”设计的，因此为了访问单行数据，你往往不得不把整页数据都加载进来。这在多模态场景下尤其糟糕，因为值本身通常很大，而且也更难通过 I/O 合并来缓解问题。 Parquet 在点查找场景下面临挑战 Parquet 在点查找场景下面临挑战宽列 所谓宽列，是指每个值都非常大的列。传统数据库工作负载里的列通常都比较小（float、double 等）。字符串往往已经算最大的列了，但在实际中通常也不算特别大。在 ML 工作负载里，我们经常希望存储张量，比如语义检索 embedding（例如 4KiB 的 CLIP embedding），甚至直接存图片（那就更大了）。 宽列场景的挑战 当文件里有宽列时，根本不可能选出一个合适的 row group 大小极宽 Schema 很多用户工作负载的 schema 都非常宽。它们可能来自金融场景（有时每个 ticker 都对应一列），也可能来自特征存储（单条记录可能有数千个 feature）。Parquet 以及其他列式格式虽然通过强大的列裁剪缓解了一部分问题，但我们仍然需要加载文件中所有列的 schema 元数据。对于低延迟工作负载，这是不小的成本；如果你要在多个文件间缓存元数据，它还会带来可观的内存开销。 极宽 Schema 的性能问题 即便做了高度选择性的列投影，很多 Parquet reader 在极宽 Schema 上的表现仍然不好灵活编码 Parquet 虽然支持一套很强大的编码系统，但它并没有跟上那些新的、甚至带有特定用途色彩的编码的发展。要新增一种编码，必须修改 file reader 自身。这很困难，因为 Parquet 的实现非常多，而且随着技术成熟，Parquet 的开发节奏也放缓了。灵活元数据 在 Parquet 中，编码只能控制 data page 里放什么。这意味着编码对列元数据或文件元数据完全没有访问能力。以字典编码为例：我们明明知道整个列里的字典是恒定不变的，理想情况下应该把它放进列元数据里，但实际却被迫在每个 row group 中都存一遍。另一个例子是为运行长度编码（RLE）列构建 skip table。如果能把这些信息放在列元数据里，我们就可以用略微增大的元数据，换来 RLE 列点查找时显著更快的速度。 元数据灵活性不足的问题 元数据不够灵活，会在很多场景里逼出一些很别扭的编码决策还有更多 在构建 Lance v2 时，我们还考虑过更多用例，其中有些也许稍显“偏门”。我就不把它们一一展开了。下面列出一些我们已经考虑并吸收进设计、但不值得单独展开说明的点：存储行数并不相同的列（例如非表格数据）以“每次写一个 array”的方式写数据，而不是“每次写一个 record batch”更灵活、可配置的对齐方式，例如让 page 按 4KiB 扇区对齐，以支持 direct I/O处理极大的 cell（例如 50MiB 视频）时，把视频当成 “blob” 单独存放（它们不进入 page），page 里只记录 blob 的位置和长度这种格式长什么样？ 下面我来介绍 Lance v2 格式（去看一眼吧，整个定义不到 50 行 protobuf），并解释它如何解决我上面提到的各类用例。 Lance v2 格式概览 Lance v2 格式的高层概览 🥱 后面这部分会更详细地展开这个文件格式的设计决策。如果你现在只想弄清楚我们到底在解决什么问题，那完全可以先跳过，等哪天你精神好一点的时候再回来读。特性 1：编码就是扩展…