在传统的数据库和数据仓库中，架构设计针对每个系统的存储、计算、SQL 和 API 进行了优化。大多数数据库和数据仓库都有自己独特的系统设计，这些设计作为一个整体的数据系统出现。几十年来，这种模式运行良好。公司和用户可以轻松安装系统并开始存储和查询数据。
然而，近年来，我们看到数据库系统发生了转变；我们看到主要的商业云数据仓库供应商开始支持存储方面的开放标准，例如Snowflake 开始支持 Apache Iceberg 和 Apache Parquet，Databricks 开源了 Delta Lake 格式，BigQuery 支持 Apache Iceberg 格式，AWS Redshift 支持 Apache Iceberg；在数据输出格式方面，Snowflake、BigQuery、Databricks、Dremio 开始支持 Arrow 格式，我们看到这一趋势在未来几年将成为主流。
这一趋势不仅止步于存储和输出格式，还进一步深入到分解的执行引擎，例如Meta 开源的 Velox，这是一个可组合的执行引擎，可以取代 Presto worker 和 Spark 引擎。DuckDB 作为一种新型进程内分析数据库，发展迅猛。Apache DataFusion 是另一个可扩展查询引擎的例子，它使用 Apache Arrow 作为内存格式。
其他项目如Ibis 标准化 Dataframe 库，以及Substrait 标准化计算引擎之间的中间表示(IR)。推动这一运动的主要公司之一是Voltron Data，它正在将创新推向数据系统的新前沿。
尽管构建数据系统非常昂贵，数据库供应商需要筹集数亿美元来构建，但如今我们拥有数百种服务于不同细分市场的数据库选择。
在这篇博文中，我将分享为什么可组合数据系统概念成为构建数据系统的新前沿，这一新趋势的好处，以及它将如何赋能和驱动新一代分析应用。
最后，我们将分享大语言模型(LLM)到 SQL 已成为数据供应商的新趋势，例如 Snowflake 近期发布的Snowflake Copilot 和 Databricks 发布的Databricks AI/BI Genie。未来几年，更多供应商将加入这一行列，在其数据基础设施中启用 LLM 能力。在可组合数据系统的背景下，我们如何将 LLM 接口模块化，为 LLM Agents 提供一个标准层，使其适应 LLM 时代的可组合数据栈生态系统。
Wes McKinney 关于“无国界数据科学”的演讲清楚地阐述了这一挑战；我们多年来一直在经历“语言孤岛”，这意味着我们必须在不同的编程语言（如 Python、R、JVM、Julia 等）之间重复实现相同的逻辑和代码。语言孤岛使得存储（数据访问）、数据结构（内存格式）、通用计算引擎以及高级分析等通用模式无法重用，并且高度依赖于前端（语言）。
由于人工智能军备竞赛，即使在当前人工智能趋势开始之前，企业就需要更快、更具可扩展性且更具成本效益的机器学习基础设施。
驱动计算机产业发展的引擎——中央处理器 (CPU) 的性能已经达到顶峰。然而，我们需要执行的计算量仍在快速呈指数级增长。这在 AI/ML 工作负载中更为显著，其中数据消耗规模更大。
引用自英伟达 CEO 黄仁勋在 COMPUTEX 2024 主题演讲中的最新发言
如果处理需求和我们需要处理的数据继续呈指数级增长，而性能没有跟上，我们将经历计算通胀。事实上，我们现在正看到这种情况。全球数据中心电力消耗量正在大幅增长，计算成本也在增加。我们正在经历计算通胀。这种情况无法持续；数据将继续呈指数级增长，但 CPU 性能的扩展将永远不会回归。
通过并行处理，在 CPU 中添加 GPU 大大改进了新的芯片架构。专用硬件，如 GPU、TPU 和 ASIC，可以将当前需要大量时间的任务极快地加速完成。这将成为数据处理和分析领域即将到来的重大演进。
为了重新架构和重新实现最初为 CPU 设计的算法，软件需要完全重写。这将使任务能够被卸载、加速并并行运行，从而实现极快的数据处理速度。
将数据栈模块化更有意义，这样我们可以轻松地在不同芯片之间重新实现和交换逻辑，而不是重复重写单体式数据库和数据仓库。
实现可组合数据生态系统的两个最重要的特征是可重用性和互操作性；这意味着模块/库需要紧凑成组件，并有一个开放社区商定的标准，以允许下游和上游依赖项相互协作，这需要补充两种力量：开源和标准化。
考虑到近期旨在标准化数据栈不同方面的开源项目的流行，我们倡导在数据管理系统的设计方式上实现范式转变。
我们相信，通过将这些分解成可重用组件的模块化栈，可以简化开发，同时为用户创造更一致的体验。
在Voltron Data 可组合法典中，他们概述了三个主要层；这并非数据系统的新架构设计；它通常已在内部实现到我们今天都在使用的传统数据系统中。不同之处在于，我们现在必须将其分解为带有标准的逻辑组件。这三个主要层是
用户界面
用户界面通常是用户发起数据操作的地方，通常指 SQL、API 以及 Python、R、Java 等语言。
执行引擎
引擎是执行数据操作的地方，例如查询优化、执行逻辑计划和物理计划等。
数据存储
数据存储层是数据存储的地方以及数据的存储方式。
如果您对详情感兴趣，请查阅 Voltron Data 的文章，《可组合法典》。
利用可组合数据栈构建您的下一个数据系统的优势非常直接；我将引用 Voltron Data 所称的“MICE”。它代表了模块化 (Modular)、互操作性 (Interoperable)、可定制性 (Customizable) 和可扩展性 (Extensible)。
基于可组合数据系统，您可以轻松扩展到新的硬件和引擎。它具有高度可定制性，组件可以轻松连接和交换信息。它可以独立工作，也可以轻松替换新的模块。
具体来说，随着计算环境的发展，可组合数据栈将更容易充分利用 GPU 和其他硬件。
您可能认为可组合数据系统在纸面上看起来很棒，但在实践中如何呢？好的，让我向您展示 FDAP 栈。
基于可组合数据栈概念的最值得关注的最新案例研究之一是 — InfluxDB 3.0。2023 年 10 月，Influx Data 创造了一个新术语“FDAP 栈”，这证明使用可组合系统并未牺牲性能；它带来了比传统设计更多的功能和更好的性能。可组合数据系统并未牺牲性能。
Andrew Lamb 在 Data Council 的最新演讲中概述了 InfluxDB 如何将其基础设施转变为 — FDAP 栈。
早在 2020 年，Influx Data 的 CTO Paul Dix 就设想了这种将改变 OLAP 数据库基础设施的新架构。新 FDAP 栈之所以非常有意义，关键在于数据处理和分析系统之间传输的数据量呈指数级增长，这得益于数据科学和 AI/ML 工作负载的新趋势。
传统上，数据是在 OLAP 和数据仓库系统内部处理的，这对于大多数用例来说已经足够。主要用例包括处理大量数据并将其聚合成指标，用于商业智能和报告目的。然而，在需要传输大量数据的机器学习和数据科学用例中，传统的 ODBC 在将数据移出这些系统时表现不佳。
FDAP 栈旨在利用底层架构的开放标准。这包括利用网络协议 (Flight)、查询引擎 (DataFusion)、内存格式 (Arrow) 和存储格式 (Parquet)。这样做是为了减少系统之间传输数据的开销，并显著减少创建新分析系统所需的工程工作量。
如果您对详情感兴趣，请查阅 Influx Data 的文章，《Flight、DataFusion、Arrow 和 Parquet：使用 FDAP 架构构建 InfluxDB 3.0》。
近期大语言模型 (LLM) 的兴起开启了将 LLM 能力引入数据基础设施的新一轮实现浪潮。Snowflake 和 Databricks 等供应商已开始新的竞争。近期，Snowflake 推出了Snowflake Copilot，Databricks 推出了Databricks AI/BI Genie。
今年四月初，Pinterest 工程团队分享了他们如何在内部利用 LLM 作为用户界面来检索数据；他们还分享了为用户提供的解决方案带来了惊人的投资回报率（ROI），引用如下。
在我们的实际数据中（重要的一点是未控制任务差异），我们发现使用 AI 协助编写 SQL 查询的任务完成速度提高了 35%。
将 LLM 能力引入数据系统将成为所有数据系统的下一个新接口，使得组织中更多用户能够访问数据。
为了实现我们的目标，根据 Voltron Data 定义的三个主要层，我们需要一个额外的层来支持 LLMs。在这个层和用户界面之间，我们需要一个 LLM 中间表示 (LIR) 来连接数据系统和 LLM Agents 之间的上下文。
LLM Agents
LLM Agents 是利用 LLMs 执行各种任务的系统，例如聊天机器人、虚拟助手和客户服务自动化。
LLM 中间表示 (LIR, 位于 LLM Agents 和用户界面之间)
位于 LLM Agents 和用户界面（SQL、API）之间的 LIR 为 LLM Agents 和执行引擎提供了业务上下文，包括业务术语、概念、数据关系、计算、聚合以及用户的访问属性。
在现有可组合数据系统的基础上增加这两个设计，我们可以实现两件事。
为了更好地理解用户查询并提供准确结果，使用 LIR 为执行引擎提供上下文至关重要。语义引擎应被设计成可嵌入 LLM Agent 的架构和设计中。
这种上下文包括用户的角色，如其身份、权限和偏好，以及数据的语义上下文，包括关系和层级。
通过识别这些信息，系统可以确保查询返回在上下文中准确的结果。这种方法将执行引擎转变为一个“上下文感知”的执行引擎或“语义引擎”。
听起来很棒？现在，您可能会开始思考。纸面上听起来很棒，但具体的实现是什么样的？
这就是我们启动Wren AI 项目的原因。
Wren AI 是构建在语义引擎 — Wren Engine 之上的 LLM Agent；在 Wren Engine 中，我们设计了名为“建模定义语言 (MDL)” 的 LIR。
实现表明，MDL 可以通过 RAG 架构帮助将上下文带给 LLMs，并在查询规划阶段在逻辑计划中预定义一个上下文感知层；传递到Wren Engine 的 SQL 查询将根据不同的用户角色和 MDL 提供的语义上下文动态生成逻辑计划。
建模定义语言提供了一种形式化的语法和规则，用于以结构化的、类似代码的格式描述数据模型、关系、转换和分析逻辑。
它具有以下几个重要目的
在我们的文档中了解更多关于 MDL 的信息。
Wren Engine 是 Wren AI 项目的语义引擎；该引擎基于 DataFusion（正在进行中）作为查询引擎（内部 IR 和用户界面），并使用 Ibis 作为数据源的统一 API 接口。
Wren Engine 将根据来自不同用户角色和上下文的查询，根据 MDL 中预定义的语义生成不同的逻辑计划。
Wren AI 项目完全在 GitHub 上开源，任何 LLM 开发者或用户都可以自由地将其托管作为即席和分析用例的 AI Agent，支持任何 LLM，而 Wren Engine 可用作内部和外部 AI Agents 开发的语义引擎。
Wren Engine 旨在与可组合数据系统兼容。它遵循两个重要特性：可嵌入性和互操作性。考虑到这两个设计，您可以通过我们的 API 在您的 AI Agent 中重用语义上下文，并自由连接您的本地和云数据源，完美融入您现有的数据栈。
您可以在我们的 GitHub 上查看更多详情。
希望这篇文章能够开启关于可组合数据系统的新对话，并使数据通过 AI(LLM) 变得更易于访问和普及。
如果您对此主题有任何想法想讨论，请随时在本文中留言。谢谢！
感谢 Andrew Lamb、Cheng Wu、Colleen Huang、Jia-Xuan Liu、Jimmy Yeh、William Chang 审阅并提供了反馈！
立即使用 AI 赋能您的数据！
