Reprint Notice（转载提示）：本文转载自 https://lancedb.com/blog/designing-a-table-format-for-ml-workloads。 原作者：Weston Pace。原始发布日期：2024-03-25。 根据本站规范，原文中的导流与推广内容已移除。面向机器学习工作负载的表格式设计 这几年，table format（表格式） 这个方向明显进入了快车道，Iceberg、Delta、Hudi 等技术都在高速演进。选择多了之后，我被问得最多的问题之一就是：既然已经有这么多现成方案，Lance 为什么不直接用其中一个？ 这篇文章就来回答这个问题，并顺带介绍 Lance 的 table format 设计。先给个超短结论：现有很多表格式并不适配我们用户的真实工作流。常见操作要么需要大量数据拷贝、要么速度不够、要么难以并行化。什么是 Table Format？ 更准确地说，table format 更像一种协议：它描述了表的基础操作（比如增行、删行）如何发生。换句话说，它告诉我们数据文件会怎样变化、需要记录哪些元数据、还需要哪些额外结构（例如 deletion files）等。 考虑到篇幅，本文不会逐条展开 Lance table format 的所有操作。更完整的说明可参考 our docs。如果你熟悉 Iceberg 或 Delta，会发现 Lance 并没有本质上完全不同；接下来的内容我会重点讲它真正不同的部分。 💡 “Table formats stuff the CRUD into file formats” 这个口号多少有点争议，但抓重点抓得很准。现代工作负载 我说“现代工作负载”时，主要指大规模 ML 工作负载：训练模型、开发模型、上线模型、评估模型，等等。它们并不只等于 LLM（模型类型很多），而且形态差异很大。但我们确实反复看到了几类共性。宽数据的诅咒 随着数据科学不断深入，研究对象越来越“宽”。文本不再只是几个标签，而是长文、网页、源码；音频、图像、视频这类多模态数据大量进入；即便是数值数据，也会因为 tensor、vector embedding 之类对象而迅速变重。 我在处理宽数据时有个观察，姑且叫它 the curse of wide data（名字听起来就很带感）：只要你有一部分数据是宽的，最后大多数数据都会变宽。 为了证明这一点，我们团队的一只猫已经同意友情出演： Wide Data Demonstration 数据宽度可视化：一个“超宽列”就足以主导整体存储开销（并由我们的吉祥物亲自助演）。 如果猫还不够有说服力，那就看个工程例子：TPC-H line items 这种经典表，从 16 列加到 17 列时，只要新增一个 3KiB 的向量 embedding 列，整张表就会从“几乎没有宽数据”瞬间变成“99% 都是宽数据”。 TPC-H with Wide Data 数据分布分析：向 TPC-H line items 表增加 3KB 向量 embedding 后，数据分布会发生剧烈偏移，embedding 一列就占到总存储的 99%。表会横向和纵向一起增长 你脑子里“数据库表”的默认形象，多半是随时间越长越“长”——也就是不断增加新行。比如销售流水、网站点击日志，或者（没错）每多一篇 table format 文章就多一行。 但数据科学家一加入，事情就开始“横向生长”了。表会向两侧扩展，常常从一个大列一路长出一批新列。举个例子：一个研究项目先抓取 Wikipedia，只有一个很胖的 article text 列，里面放 wiki 标记文本。接着数据科学团队开始发力：加 sentiment analysis，再加 political bias，又抓一批新数据再加 edit count……如此循环往复，最后在一些场景里，列数会来到几百甚至上千。 Growing in 2D ML 数据最初可能只是一组核心观测；随着时间推移，新观测行和新特征列会同时增长。 这种“不断扩列”会一直发生：研究者每发现一个新信号，就会再加一个特征。现在甚至已经有人开始担心 数万列数据集 （我们在真实用户里更常见的还是几百到几千列）。 Feature Engineering 特征工程复杂度：随着分析能力升级，ML 数据集的特征列会持续膨胀，属性空间不断外扩。数据就是会“脏” 这不是新观点，但值得反复强调。现实里它有很多表现：清洗操作（编辑、删除等）很重要；数据必须可搜索，不然用户根本搞不清自己手里有什么；数据常来自爬取或外部系统，外键极其常见（我都想不起来上次遇到“没有 UUID 类列”的客户是什么时候了）。 旧数据要去重，新数据入库时也要去重（有时我甚至怀疑，用户是不是都忘了“不用 m…