这是一篇翻译文章。
作者是：Wes McKinney.
原文地址：The Road to Composable Data Systems: Thoughts on the Last 15 Years and the Future。
与 Meta、Databricks、Sundeck 等公司合作的 关于可组合数据管理系统 VLDB 论文 已经发布！这篇文章反映了我是如何思考这些问题的，以及未来可能是什么样子。请欣赏。
1. 入门时间：2008 年至 2015 年
15 年前，也就是 2008 年 4 月，我开始构建数据分析工具。从那时起，世界发生了很大变化。回到 2000 年代后期，我当时感受到的是数据科学急迫的“Python 化”。这既是为了让现有的数据科学家更有效率，也是为了让大量新一代数据从业者更容易接触到数据科学。在 2011 年的一篇博文中，我写道，需要更好地协调 Python 项目，以创建更高效的端到端用户体验，并一度断言“碎片化正在扼杀我们”。
到了 2013 年，pandas 已经足够成功了，我把控制权交给了最初由 Jeff Reback. 领导的其他核心开发人员。在过去的十年里，他们做了令人难以置信的工作来发展这个项目和它的用户社区。大约在那个时候，Jupyter 也与其他重要项目（如 scikit-learn 和 statsmodels）一起建立起来。我的书《Python for Data Analysis》刚刚出版。尽管我们不知道随着机器学习、数据工程和分布式计算框架的到来，Python 会变得多么流行，但“Python 化”的故事看起来还不错。
当 Chang She 和我开始在可视化分析初创公司 DataPad 工作时，我们很快就开始体验到 pandas 在构建大规模、多租户云分析服务方面的一些局限性。pandas 的性能、规模和内存使用问题对我们影响很大，尽管大多数 pandas 用户都非常满意，因为很少有人真正拥有“大数据”。除了性能和资源使用问题外，与其他系统（例如其他存储或计算平台）的互操作性和可组合性是另一个痛点。在对 pandas 进行彻底重新设计的原型设计时，我开始思考导致我们陷入困境的更基本的问题。我在网上疯传的 PyData NYC 2013 演讲“我讨厌 pandas 的 10 件事”中表达了一些挫败感（注意：我仍然爱 pandas！）
简短截说是我觉得有几个相互关联的问题：pandas 从它与 NumPy 的关系中积累了粗糙的边缘，而 NumPy 旨在用于数值计算，而不是构建数据库。pandas 解决了许多数据库系统也解决了的问题，但数据科学生态系统中几乎没有人具备使用数据库技术构建 DataFrame 库的专业知识。立即求值的 API（相对于“延迟”的 API）使得有效的“查询”规划和执行更加困难。除非为互操作创建更快、更有效的“标准”，否则与其他系统的数据互操作性总是痛苦的。
我以十五年的后见之明来看待这个问题的另一种方式是，pandas 必须自己承受这一切，这对于一个完全基于志愿者的开源项目来说是一个巨大的负担。诸如与语言无关的数据互操作性标准或用于高效查询处理的即插即用组件之类的东西在当时是不切实际的想法，但直到现在才变得更加现实。
2014 年底，当 DataPad 团队和我加入 Cloudera 时，我的视野开始扩大，为一些更深层次的基础设施问题寻求解决方案似乎变得更加可行。到 2015 年初，我开始公开谈论这个问题，描述了在数据库和 DataFrame 类系统之间实现更好的互操作性、可组合性和重用性的愿景。在 2015 年 4 月的一次演讲中，我将其描述为“伟大的数据工具解耦”（这当然不是我提出的想法，因为存储“拆分”是 Hadoop 生态系统 存在的理由 之一）：
(请看这个演讲的视频，从 4:20 到 6:35)
值得庆幸的是，大约在这个时候，人们开始集体意识到需要对许多此类或问题采取跨领域解决方案。由于现在是 2023 年，我预测我们将“在 2025 年到达那里”，所以我将在接下来的文章中讨论为什么这项工作现在一直在进行，以及为了帮助我们实现这些目标所做的一些工作。最后，我将就我认为我们在未来几年需要投资的地方进行一些思考，以加速下一波进展。
2. 为什么是现在？不断变化的硬件格局
很多人都问，为什么我们这么多人开始关注互操作性、模块化、可组合性、解耦等问题。Julien Le Dem 是 Parquet 文件格式的共同设计者，后来又与我们共同设计了 Apache Arrow，他创造了“解构数据库”这个术语，用来描述将垂直集成系统分解为模块化、可重用组件的过程。
有许多根本原因，但其中一个主要原因是计算硬件的发展。这体现在更快的存储设备、更快的网络以及更快、更专业的处理器上。更快的存储和网络意味着我们必须重新思考如何在不同类型的系统中存储、访问和移动我们需要处理的大型数据集。多核 CPU 和专用处理器(如 GPU 和 TPU)的快速发展意味着我们必须重新思考编程接口，以使开发人员无需计算机工程博士学位即可使用尖端硬件。实际应用程序中的计算管道在数据处理和使用的编程语言方面也变得更加异构。从这个角度来看，以传统的垂直集成方式构建每个处理组件变得越来越不理想。
ML/AI 生态系统是使开发人员能够通过面向用户的框架（如 TensorFlow 和 PyTorch）无缝利用硬件加速的先行者之一，并辅以 XLA、MLIR 和 JAX 等新的编译器技术。LLVM、MLIR 和 Swift 的创造者 Chris Lattner 甚至成立了一家名为 Modular 的新公司，旨在继续在编译器技术方面进行创新，以帮助硬件异构计算和开发人员提高人工智能的生产力。
3. 迈向更加模块化、可组合的数据堆栈
构建一个成功的独立软件项目已经够难的了。构建需要在多个软件项目之间进行协调和一致的东西可能更加困难。在这种觉醒中，出现了许多新的开源计划。我想强调其中的一些，不是因为我认为它们是最终的解决方案，而是因为它们正在帮助照亮道路并展示未来可能是什么样子：
- Apache Arrow（2015）——独立于语言的计算和数据交换层，支持跨重要编程语言的系统基础设施
- Ibis （2014） 和 dplyr （2012）——与后端无关的 DataFrame 接口
- RAPIDS （2018）——用于数据分析和机器学习的 GPU 加速库
- DuckDB （2018） 和 Velox （2021）——提供快速列查询处理的嵌入式系统
- Substrait （2021）——用于分析计算的独立于语言的中间表示(IR)中间件，以帮助将用户界面与计算引擎解耦
这些项目共同致力于实现数据交换、查询执行和编程接口的模块化。我将简要介绍它们中的每一个，然后总结一下该领域未来几年开源工程工作的一些想法。
4. 结构化数据交换和计算结构：Apache Arrow
成立七年来，Arrow 对数据分析领域产生了深远的影响。它已被采用为独立于语言和硬件的快速交换和计算层，我现在比以往任何时候都更相信“未来是 Arrow 原生的”。如果没有数据交换和内存计算的标准化解决方案，系统之间的互操作将在计算成本和开发时间上付出巨大代价。一些最近的 Arrow 子项目，如 Flight、Flight SQL 和 ADBC，正在为数据库和分布式系统铺平道路，以标准化它们如何使用 Arrow 内存格式与外部系统进行交互。
除了简化数据交换和相互组合系统之外，Arrow 的另一个主要好处是它为硬件供应商提供了一个稳定的目标，可以开发用于在其硬件上进行分析的加速“内核”。在数值计算和线性代数中，我们已经将硬件优化的内核库（如英特尔的 MKL（现在的 oneMKL）视为理所当然。Arrow 通过 RAPIDS 等项目和如下所述的嵌入式数据库引擎，使分析和数据库操作也能实现同样的功能。
2017 年，我写了一篇关于为什么我认为 Arrow 为“我讨厌 pandas 的 10 件事”提供许多解决方案的文章。将近 6 年过去了，我想说，总的来说，事情进展得和我所希望的一样好。像 Polars 这样的新型高性能 DataFrame 库是基于 Arrow 构建的，pandas 在许多地方都使用基于 Arrow 的加速进行了改造。看到这些改进渗透到 Dask 等其他项目中，我感到很有成就感。
5. 硬件加速：RAPIDS
自从 2006 年 NVIDIA 推出 CUDA 以来，开发人员已经可以使用一组底层工具，从而在 GPU 上实现通用计算。GPU 的并行架构（每个设备有数千个处理核心）提供了比 CPU （最多几十个核心）更高的吞吐量。在引入 CUDA 后的十年中，开发人员构建了一系列开源软件，这些软件可以利用 GPU 硬件来加速某些类型的数据分析和机器学习工作负载，尤其是深度学习训练和推理。但是，由于需要用 C / C++编程才能使用 CUDA，GPU 的广泛采用受到了阻碍。
NVIDIA 看到了在数据应用中加速采用 GPU 加速的机会，于 2016 年开始开发一套基于 CUDA 构建的特定领域开源库。该库套件于 2018 年作为 RAPIDS 发布，包括 CUDA DataFrames （cuDF）、CUDA MachineLearning （cuML） 等），旨在加速内部使用 Arrow 内存格式进行分析和机器学习的数据处理。他们的 Python API 旨在最大限度地提高与现有类似 Python 库的相似性（cuDF 对标 pandas；cuML 对标 scikit-learn）。RAPIDS 很快被许多 Python 用户以及包括 Dask 和 BlazingSQL 在内的项目所采用。
6. 模块化查询处理：DuckDB、Velox 等
自从第一波分析型 DBMS（如 Vertica、Vectorwise、SAP HANA 和许多其他在 2000 年代中后期开发的数据库）出现以来，分析型数据库用户已经获得了极快的性能。产生这些商业系统的前沿研究直接导致了当今流行的现代 DBMS 技术，例如 BigQuery、Clickhouse、Databricks SQL、Redshift 或 Snowflake。遗憾的是，很少有专家能够设计和实现这样的系统，而且创建的大部分软件都被隐藏在闭源商业产品中。
一件不可思议的事情是，近年来 DuckDB、Velox 和 DataFusion（Arrow Rust 项目的一部分）等新型嵌入式列式数据库引擎的出现。更妙的是，这些项目被设计为在基于 Arrow 的系统中使用。将尖端的分析 SQL 处理添加到几乎任何应用程序的能力对我们行业来说都是一个颠覆性和变革性的变化。CMU 数据库教授 Andy Pavlo 做出了大胆的预测，“这些查询执行组件的商品化意味着所有的 OLAP DBMS 将在未来五年内大致相当……每个 DBMS 都将拥有与十年前 Snowflake 所独有的相同的向量化执行能力。”我相信他是对的，这是一件大事。
7. 模块化编程接口：Ibis、dplyr 等
在我帮助启动 Arrow 项目的同时，我也回到了与数据库和 DataFrame 引擎交互的程序员接口的设计阶段。我尝试将 SQL 和 DataFrame API 结合起来的是 Ibis，它已经发展了七年多了。我没有克隆 pandas API，而是与 Phillip Cloud 和其他人一起设计了一个易于使用、可扩展的惰性求值表达式系统，该系统可以支持广泛的类 SQL 和非 SQL 数据处理场景。我们想要完全覆盖 SQL 功能，但要有强大的类型检查和易于重用的表达式片段，以使开发人员能够更高效地编写复杂的分析工作负载，这些工作负载还可以跨不同的执行引擎和处理框架移植。在过去的几年中，我们对 Ibis 的内部进行了重大改进，并将支持扩展到 16 个不同的执行后端。我们正在努力使 Ibis 成为使用 Python 的企业的终极数据库分析 API。很高兴看到该项目被 Google Cloud、Microsoft 和其他公司的数据库 API 项目采用。
类似的模块化、可移植 DataFrame API 趋势也在其他地方出现。当我开始为 Ibis 工作时，我的部分灵感来自于 2012 年启动的 R 语言 dplyr 和 tidyverse 项目。最近，在 Python 生态系统中，Modin 项目通过定义扩展的关系代数，使大量 pandas 代码子集能够在分布式集群上编译和执行，从而为 DataFrame 操作带来了更严格和形式化的功能。
顺便说一句，我也对创建编译为 SQL 的全新查询语言（如 Malloy 和 PRQL）的努力感到非常兴奋。
构建和维护像 Ibis 和 dplyr 这样的库或像 Malloy 这样的新查询语言的一个挑战是，它们必须实现特定于引擎的后端接口，以生成特定的 SQL 方言或其他查询表示，这意味着许多额外的实现复杂性、出现 bug 和不一致的机会等等。如果有一种标准化的方法来操作和传输分析查询表达式，那不是很好吗？
8. 数据分析的 “中间表示（IR）”：Substrait
SQL 通常被认为是分析查询的标准，但在实践中，每个 SQL 数据库都开发了自己略有不同的查询语言，因此在实践中很少有 SQL 方言是可移植的。切换到一个新的数据库通常意味着重写大量的查询和学习新的语法来进行高级数据操作(例如，处理嵌套数据)。表示查询和数据操作表达式的这种碎片化阻碍了在这一层上实现模块化或互操作性的努力。
近年来，云“湖仓一体”架构的普及以及在通用数据集之上使用不同执行引擎的需求使得查询持久性和互操作性问题更加痛苦。像 Airbnb 和 LinkedIn 这样的公司已经开发了 SQL 转译器项目，如 sqlglot 和 Coral。
认识到这些趋势的不可持续性，由 Jacques Nadeau（他也是 Arrow 的关键开发人员）领导的一组开发人员启动了 Substrait，为查询定义一个标准化的低级中间表示，使系统能够独立于自己的本地 SQL 方言或其他查询语言相互交互。
Substrait 是这篇文章中比较深奥、最不面向用户的项目之一，但我相信它是使执行引擎变得更加模块化和可组合的重要组成部分，并使“前端”框架（如 Ibis 或 dplyr ）更容易专注于提供愉快和高效的用户体验，而不会陷入支持每个后端目标的古怪之处中。
9. 还缺少什么？查询优化、分布式计算、文件格式、数据集管理
我在这篇文章中省略了一些领域，包括模块化查询优化（如 Apache Calcite）、分布式执行框架（如 Python 的 Dask 或 Ray）、文件格式（如 Parquet 或 ORC）和大规模数据集管理工具（如 Apache Iceberg 或 Delta Lake）。这些都是整个故事的重要组成部分。
我希望分布式执行框架能够开发对 Arrow 格式数据的强大支持，并支持使用 Substrait 作为在调度程序和后端引擎之间交互的查询片段的可互换的中间表示。
我认为我们最终会看到下一代文件格式的采用，这些格式在现代存储和处理硬件上提供了更好的性能，但现在的“遗留的”列式格式 Parquet 和 ORC 将伴随我们很长很长一段时间。
新的可扩展数据集管理框架（如 Iceberg 和 Delta Lake）可以适配支持未来的新文件格式，因此在某种程度上，文件格式和数据集管理与上面讨论的许多问题是正交的。
随着最近人工智能系统的爆炸式增长，我预计我们还将看到专业存储和数据访问技术的创新，以加速机器学习和生成式人工智能应用。Lance 是这里一个让我兴奋的新项目。
10. 总结与展望
我对模块化、互操作性和可组合性以及我称之为“大解耦”的持续趋势的未来持乐观态度。作为一个开源社区，我们在上述项目上有许多年的增量工作要做，以充分实现它们的潜力，但是看到开发人员聚集在一起，支持这些关键的开源标准化工作，这是令人鼓舞的。
通过 DuckDB、Velox 和 DataFusion 等项目将查询执行“白菜化”肯定会成为生态系统中的颠覆性趋势，因为我们开始理所当然地认为几乎任何系统都可以配备尖端的列式查询处理能力。此外，这些模块化、可重复使用的组件的持续改进将或多或少地在所有依赖它们的项目中立即可用。这太令人兴奋了。
最后，随着开发人员的精力从“谁能构建最快的执行引擎”转移，我预测未来几年将带来新一轮的用户界面生产力投资浪潮（以 Ibis、dplyr 和 Malloy 等项目为代表），因为人机交互（或 LLM 交互）程序员将再次成为完成任务的瓶颈。
我期待着接下来的事情，随着事情的进展，我一定会在未来重新审视这些话题。
如果您错过了上面的内容，请查看我们关于这些主题的 VLDB 2023 论文！
