来自韦斯·麦金尼文章：
15年前，也就是2008年4月，我开始构建数据分析工具。我当时所感知到的是数据科学的迫切“Python化”。这不仅是为了让新一代的数据从业者更容易获得数据科学，也是为了让现有的数据科学家更有效率。
到2013年，Pandas已经足够成功，我将其开发交给其他核心开发人员，我的书《Python for Data Analysis》刚刚出版。“Python化”的故事看起来很好
我们很快就开始遇到Pandas在构建大规模多租户云分析服务方面的一些限制。Pandas的性能、规模和内存使用问题对我们影响很大，尽管大多数Pandas用户非常满意，因为很少有人真正拥有“大数据”。
在对Pandas进行重新设计的原型设计时，我开始思考导致我们陷入困境的更基本的问题。
几个相互关联的问题：Pandas与NumPy的关系积累了粗糙的边缘，而NumPy旨在进行数值计算，而不是构建数据库。Pandas解决了数据库系统也能解决的许多问题，但数据科学生态系统中几乎没有人拥有使用数据库技术构建数据框架库的专业知识。
在更深层次的基础设施寻求解决方案似乎更可行。到2015年初，我公开谈论这一点，描述了在数据库和数据框架类系统之间实现更好的互操作性、可组合性和重用的愿景。在2015年4月的一次演讲中，我将其描述为“大数据工具解耦”
为什么我关心互操作性、模块化、可组合性、解耦等问题？
有很多根本原因，但其中一个主要原因是计算硬件的演变。这体现在更快的存储设备、更快的网络以及更快和更专业的处理器上。更快的存储和网络意味着我们必须重新思考如何存储，访问和移动我们需要在不同类型的系统中处理的大型数据集。
ML/AI生态系统是首批推动者之一，它使开发人员能够通过面向用户的框架（如TensorFlow和PyTorch）无缝利用硬件加速，并辅以XLA、MLIR和JAX等新的编译器技术。
迈向更加模块化、可组合的数据栈
构建一个成功的独立软件项目已经够难的了。构建需要在多个软件项目之间协调和达成协议的东西可能会更加困难。在这种觉醒中，出现了许多新的开源计划。我想强调其中一些，不是因为我认为它们是最终的解决方案，而是因为它们有助于照亮道路，并展示未来可能的样子：
- Apache Arrow（2015）-独立于语言的计算和数据交换层，以及跨重要编程语言的支持系统基础设施
- Ibis （2014年） dplyr 2012-后端不可知数据帧接口
- RAPIDS （2018）-用于数据分析和机器学习的GPU加速库
- DuckDB的 （2018）和 Velox （2021）-提供快速列式查询处理的嵌入式系统
- Substrait（2021）-一种独立于语言的中间表示（IR）中间件，用于分析计算，以帮助将用户界面与计算引擎解耦
这些项目共同致力于在数据交换、查询执行和编程接口中实现模块化。我将简要地介绍其中的每一个，然后总结一下对该领域未来几年开源工程工作的一些想法。
结构化数据交换和计算结构：Apache Arrow
自成立以来的七年里，Arrow 对数据分析领域产生了深远的影响。它已被采用为独立于语言和硬件的快速交换和计算层，我现在比以往任何时候都更相信“未来是 Arrow-native 的”。
如果没有数据交换和内存计算的标准化解决方案，系统之间的互操作就会在计算成本和开发时间方面付出巨大的代价。
最近的 Arrow 项目（例如 Flight、Flight SQL 和ADBC）正在为数据库和分布式系统标准化它们如何使用 Arrow 内存格式与外部系统交互铺平道路。
除了简化彼此之间的数据交换和组合系统之外，Arrow 的另一个主要好处是它为硬件供应商提供了一个稳定的目标，以开发加速“内核”以在其硬件上进行分析。在数值计算和线性代数中，我们已经将像 Intel 的 MKL（现在的 oneMKL）这样的硬件优化内核库视为理所当然。Arrow 通过 RAPIDS 和嵌入式数据库引擎等项目（如下所述）使分析和数据库操作能够发生同样的事情。
像 Polars 这样的新的高性能数据框架库是基于 Arrow 构建的，pandas在许多地方都通过基于 Arrow 的加速进行了自我改造。看到这些改进渗透到Dask等其他项目中，我感到很高兴。
硬件加速：RAPIDS
自 NVIDIA 于 2006 年推出 CUDA 以来，开发人员已经可以使用一组低级工具来实现 GPU 上的通用计算。GPU 的并行架构（每个设备有数千个处理核心）提供比 CPU（最多几十个核心）更高的吞吐量。在引入 CUDA 后的十年里，开发人员构建了一系列开源软件，可以利用 GPU 硬件来加速某些类型的数据分析和机器学习工作负载，尤其是深度学习训练和推理。但由于需要使用 C/C++ 进行编程以使用 CUDA，GPU 的更广泛采用受到了阻碍。
看到了在数据应用中加速采用 GPU 加速的机会，NVIDIA 于 2016 年开始开发一套基于 CUDA 构建的特定领域开源库。这套库于 2018 年以RAPIDS 的形式发布，包括 CUDA DataFrames (cuDF)、CUDA MachineLearning (cuML) 等，旨在加速内部使用 Arrow 内存格式进行分析和机器学习的数据处理。他们的 Python API 旨在最大限度地提高与现有类似 Python 库的相似性（cuDF 镜像 pandas；cuML 镜像 scikit-learn）。
RAPIDS 很快被许多 Python 用户以及包括 Dask 和 BlazingSQL 在内的项目采用。
模块化查询处理：DuckDB、Velox 等
自从 Vertica、Vectorwise、SAP HANA 等第一波分析 DBMS 从 2000 年代中后期开始开发以来，分析数据库用户已经获得了极快的性能。产生这些商业系统的尖端研究直接导致了当今流行的现代 DBMS 技术，例如 BigQuery、Clickhouse、Databricks SQL、Redshift 或 Snowflake。
不幸的是，很少有专家能够设计和实现此类系统，并且创建的大部分软件都被隐藏在闭源商业产品中。
近年来，随着 DuckDB、Velox 和 DataFusion（Arrow Rust 项目的一部分）等新型嵌入式列式数据库引擎的出现，发生了一件令人难以置信的事情。更好的是，这些项目设计用于基于 Arrow 的系统。
模块化编程接口：Ibis、dplyr 等
我尝试将 SQL 和数据框架 API 结合起来的是Ibis，它已经发展并发展了七年多了。我没有克隆 pandas API，而是与Phillip Cloud和其他人合作设计了一个延迟计算的表达式系统，该系统易于使用、可扩展，并且可以支持广泛的类 SQL 和非类 SQL 数据处理用例。我们希望完全覆盖 SQL 功能，但具有强大的类型检查和表达式片段的轻松重用，使开发人员能够更高效地编写复杂的分析工作负载，这些工作负载也可以跨不同的执行引擎和处理框架移植。
在过去几年中，我们对 Ibis 的内部进行了重大改进，并将支持扩展到 16 个不同的执行后端。我们正在努力使 Ibis 成为使用 Python 的企业的终极数据库分析 API。很高兴看到该项目被 Google Cloud、Microsoft 和其他公司的数据库 API 项目采用。
模块化、便携式数据框架 API 的类似趋势也出现在其他地方。当开始从事Ibis工作时，我部分受到了 2012 年启动的 R dplyr和 tidyverse 项目的启发。最近在 Python 生态系统中，Modin项目通过定义扩展的关系代数，使大部分 pandas 代码能够在分布式集群上编译和执行。
构建和维护 Ibis 和 dplyr 等库或 Malloy 等新查询语言的一个挑战是，它们必须实现特定于引擎的后端接口，生成特定的 SQL 方言或另一种查询表示形式，这意味着大量额外的实现复杂性和出现错误的机会以及不一致的情况等等。如果有一种标准化的方法来操作和传输分析查询表达式不是很好吗？
数据分析的“IR”：Substrait
SQL 通常被认为是分析查询的标准，但实际上，每个 SQL 数据库都开发了自己的略有不同的查询语言，因此很少有 SQL 方言在实践中是可移植的。切换到新数据库通常意味着重写大量查询并学习高级数据操作的新语法（例如，用于处理嵌套数据）。表示查询和数据操作表达式的这种碎片化阻碍了在这一级别实现模块化或互操作性的努力。
最近，云“lakehouse”架构的流行以及在公共数据集之上利用不同执行引擎的需求使得查询持久性和互操作性问题变得更加痛苦。Airbnb 和 LinkedIn 等公司甚至开发了sqlglot和Coral等 SQL 转译器项目。
认识到这些趋势的不可持续性，由Jacques Nadeau（也是 Arrow 的关键开发人员）领导的一组开发人员开始使用Substrait来定义查询的标准化低级中间表示，以使系统能够独立于自己的本机而相互交互SQL 方言或其他查询语言。
Substrait 是本文中最深奥、最不面向用户的项目之一，但我相信它是使执行引擎变得更加模块化和可组合性的重要组成部分，并使 Ibis 或 dplyr 等“前端”框架更容易专注于提供愉快且高效的用户体验，而不会陷入支持每个后端目标的怪癖中。
我希望分布式执行框架能够通过模块化引擎支持，使用 Substrait 作为在调度程序和后端引擎之间移动的查询片段的可替代 IR，为 Arrow 格式的数据提供强大的支持。
我认为我们最终会看到下一代文件格式的采用，这些格式在现代存储和处理硬件上提供更好的性能，但现在的“传统”列格式 Parquet 和 ORC 将伴随我们很长一段时间。
像 Iceberg 和 Delta Lake 这样的新的可扩展数据集管理框架可以适应未来的新文件格式，因此在某种程度上，文件格式和数据集管理与上面讨论的许多问题是正交的。
最后，随着开发人员的注意力从“谁能构建最快的执行引擎”转移，我预测未来几年将再次带来新一波对用户界面生产力的投资（以 Ibis、dplyr 和 Malloy 等项目为代表）。