单节点数据工程：DuckDB、DataFusion、Polars及LakeSail

曩十载间，数据工程与分布式集群浑然一体。若数据集逾数吉字节，则常规之道必于AWS EMR或Databricks上启Apache Spark之集群。此分布式范式，遂引巨量运维之繁复：调校JVM之配置，分配执行者，细调shuffle之分区，复需支付甚巨之“序列化之税”，以迁数据于网络套接字与语言运行时之间。

近者，数据工程之境，独木复兴。非扩而至于群集，乃升而于单机。今之笔记本电脑，多具十二核以上之CPU，迅捷之NVMe SSD，可速读数吉每秒，乃至百二十八GB之RAM。云供者，以百核千兆之虚拟机，价不及Kubernetes或Spark群集之什一。

此物理之变，仅半其事耳。其真之触媒，乃基于 Apache Arrow、向量化执行、及离核内存管理之新世代数据技术。如 DuckDB、Apache Arrow DataFusion、Polars、LakeSail 等器，使一单笔记本电脑或虚拟机，可处理数百吉字节乃至太字节之数据。今可于本地或单节点执行繁复之分析管道，而无分布式 JVM 运行时之冗余。

核心基石：柱状内存与 Apache Arrow

欲知单节点数据工程何以处理昔需百集群节点方能成之数据集，必察数据于内存中结构之状。

旧式数据库及处理运行时，为应事务工作负载（OLTP）而设，皆用行向布局。其于内存中，将单条记录之诸字段连续存储：[User_ID, Age, Name]者，继而录次之。当施析理之问（OLAP），若仅针对列之少（如计用户之平均年岁），行向引擎必遍索记忆中全录之构。此程载不相关之数据（如名与号）入CPU之L1/L2缓存，致缓存蒙尘，内存频宽徒耗。

竖表查询引擎，以列式存储数据，连续存取，此弊得解。[Age, Age, Age]于一缓冲区中，且[Name, Name, Name]他处亦然。CPU唯读查询所需之列。

Row-Oriented Layout (OLTP):
┌──────────────────────────────┬──────────────────────────────┐
│ ID 1 │ Age 1 │ Name 1        │ ID 2 │ Age 2 │ Name 2        │
└──────────────────────────────┴──────────────────────────────┘

Columnar Layout (Arrow/OLAP):
┌──────────┬──────────┐ ┌──────────┬──────────┐ ┌──────────┬──────────┐
│ ID 1     │ ID 2     │ │ Age 1    │ Age 2    │ │ Name 1   │ Name 2   │
└──────────┴──────────┘ └──────────┴──────────┘ └──────────┴──────────┘

Apache Arrow一统列式内存之布局。其立开源、无语言之规，以应内存列式之数据。因定共通之内存格式，Arrow除历史所滞之数据管道序列之税。

古之架构，欲通 Python 脚本与 Java 或 C++ 引擎之数据，必先将数据序列化为字节流（如 JSON 或 Protobuf），复在彼端反序列化之。此序列化之费，常占查询执行时之八成。

箭矢使进程间通信（IPC）无需复制。箭矢于内存中表数据，于Python、Rust、C++皆同，故异进程可内存映射（mmap）同物理内存缓冲。引擎可藉交换内存指针，将数据集传于Python以供机器学习或可视化。未尝有字节之复制，亦无序列化之事。

复次，Arrow之连续内存对齐，合乎今时CPU缓存行之布局，故运用单指令多数据（SIMD）指令集（如Intel/AMD之AVX-512或ARM之Neon）自当顺遂。SIMD使CPU得以于一时钟周期内，将一指令（如滤较或算加）施于数据点之矢。此硬件级之并行，化数据处理之内存或CPU所限为直运于处理器之高效作业。

过程内SQL巨擘：DuckDB架构&特性

DuckDB已为单节点SQL分析之标准数据库引擎。其设计为进程内分析数据库，直运行于主进程（如Python解释器或CLI二进制文件）内，而非独立服务器守护进程。此消弭了PostgreSQL或Snowflake等客户端-服务器数据库之网络套接字延迟及IPC开销。

DuckDB之执行引擎，采向量化查询执行之模。非逐行处理数据（此乃火山迭代模型），亦非一次性处理整列（此易致L1/L2缓存溢出于大表），DuckDB乃以小而缓存友好之向量处理数据。此向量通常含2048元素。

Volcano Model:       [Row 1] ──► [Operator] ──► [Row 2] ──► [Operator]
Column-at-a-time:    [Entire Column (10M rows)] ──► [Operator] (Overflows Cache)
Vectorized Model:    [Vector of 2048 rows] ──► [L1/L2 CPU Cache] ──► [Operator]

将此诸矢维持其小，俟得入CPU之L1/L2缓存，则DuckDB可极减内存频带之阻。CPU乃以SIMD之指令施诸矢，使执行之脉管常盈数据。

欲应数据集逾物理内存之需，DuckDB施以离核执行。当内存耗至用户所定之限，DuckDB之缓冲管理器自将中段查询状态（如哈希联接表、排序缓冲、或聚合状态）溢出至暂存磁盘文件。此溢出机制，乃以块式缓冲池为基础，使数据页错误至磁盘，令汝得以于数据集远超系统内存之境运行查询。

最新v1.5.3版本（二零二六年五月），DuckDB增数项之新，扩其单节点之用：

呱呱远程协议：DuckDB今附核心之延，行呱呱之协议。此协议使用户得于需时，使DuckDB行于客主之构，便远附与远询之调，而不失引擎之简。
生境與格式更新： 冰山擴充已升級，支援MERGE INTO之操作，使能於本地DuckDB會話中直據冰山表施以複雜之Delta更新。
亞馬遜安全與IRSA： IRSA（为服务账户提供 IAM 角色的原生支持）已加入，于容器化单节点管道中运行 DuckDB 时，可简化安全 S3 访问。
静态链接： 该分发版现于 Linux 平台静态链接 jemalloc，提升内存分配速度，并减少重载时碎片化。

下文之Python脚本，示以配置DuckDB之内存限额，以新AWS扩展功能注册S3凭证，并运行溢写至磁盘之查询：

import duckdb

# Initialize DuckDB connection
con = duckdb.connect(database='local_cache.db')

# Set memory limit to force out-of-core spilling on smaller datasets
con.execute("SET max_memory='8GB';")
con.execute("SET temp_directory='./duckdb_temp';")

# Load S3 and AWS extensions (built-in in v1.5.3)
con.execute("INSTALL aws;")
con.execute("LOAD aws;")

# Autodetect AWS credentials from environment (supports IRSA)
con.execute("CALL load_aws_credentials();")

# Query a large Parquet dataset directly on S3 with predicate pushdown
# DuckDB only downloads the columns and row groups that match the filter
query = """
    SELECT 
        user_id, 
        COUNT(event_id) as event_count,
        AVG(session_duration) as avg_duration
    FROM read_parquet('s3://my-lakehouse/bronze/events/**/*.parquet')
    WHERE event_date >= '2026-01-01'
    GROUP BY user_id
    HAVING event_count > 1000
    ORDER BY avg_duration DESC
"""

# Execute and stream results
result = con.execute(query).fetchdf()
print(result.head())

DuckDB兼具SQL支持、向量化性能与离线稳定性，为本地分析任务之核心利器。

可扩展之 Rust 处理：Apache Arrow DataFusion

DuckDB 乃分析数据库，而 Apache Arrow DataFusion 乃可扩展之查询引擎框架也。以 Rust 为文，以 Apache Arrow 为其本内存格式，DataFusion 广泛用于构建他数据库、查询引擎及定制数据平台（如 Bauplan、Spice.ai、LakeSail）。

DataFusion之设计，乃模块之制。其解构查询之谋、优化之阶、执行之序。若尔欲建定制之数据器，可注册定制之目录，撰用户自定之逻辑优化则（如定制之谓词下推），或接定制之物理执行节点。

欲求线程并行，DataFusion乃用 Rust 之异步 Tokio 运行时。非固系执行于定数之线程，DataFusion 乃分物理计划碎片（以异步 Arrow RecordBatch 流表之）于 Tokio 工作线程池。此使引擎得适于多核架构，避重 I/O 负荷下线程争竞之患。

近岁v53.x、v54.x之版，DataFusion社群增数优化：

日期谓词预像： DataFusion今优化含日期函数之问（如date_trunc等），然未竟。date_part者，审其数理之"逆象"也。非于每行施以时序之术，优者改写其滤限于原分域之界，遂得分域之精简。
排序下推阶段二：今引擎先以物理统计排序文件组，而后行排序之令。若一集Parquet文件含非重叠之排序区间，DataFusion则省却全局排序合并之步，遂减规划与CPU执行之时。
无空值反连接已优化对空值抗连接的支持，此情形常见于SQL查询中。NOT IN条款。
变体类型整合： 规划者已引入对二进制VARIANT格式的初步支持，为格式无关的半结构化数据查询奠定基础。

下列 Rust 代码片段演示如何初始化 DataFusion 上下文，注册内存中的 Arrow 表，并编程执行查询：

use datafusion::prelude::*;
use datafusion::arrow::record_batch::RecordBatch;
use datafusion::arrow::schema::{DataType, Field, Schema};
use datafusion::arrow::array::{Int32Array, StringArray};
use std::sync::Arc;

#[tokio::main]
async fn main() -> datafusion::error::Result<()> {
    // Create a local execution context
    let ctx = SessionContext::new();

    // Define a simple schema
    let schema = Arc::new(Schema::new(vec![
        Field::new("id", DataType::Int32, false),
        Field::new("name", DataType::Utf8, false),
    ]));

    // Create Arrow arrays
    let id_array = Int32Array::from(vec![1, 2, 3, 4, 5]);
    let name_array = StringArray::from(vec!["Alice", "Bob", "Charlie", "David", "Eve"]);

    // Build the record batch
    let batch = RecordBatch::try_new(
        schema.clone(),
        vec![Arc::new(id_array), Arc::new(name_array)],
    )?;

    // Register the record batch as an in-memory table
    ctx.register_batch("users", batch)?;

    // Execute SQL query
    let df = ctx.sql("SELECT name FROM users WHERE id > 2").await?;

    // Print the physical execution plan
    df.show().await?;

    Ok(())
}

此库优先模式，使DataFusion成为构建专业高性能数据系统之首选

向量化DataFrame：Polars Eager & 懒惰管道

夫以 Python、Rust 或 JavaScript 为业者，DataFrame 乃其处理数据之首选 API。虽 Pandas 久为 Python 之标准，然其单线程，内存占用甚巨（常需五至十倍于数据集之 RAM），且不支查询优化。

Polars者，乃 Rust 之原生、Arrow 之支撑之 DataFrame 之庖厨也，意欲代 Pandas。其优化于多核之执行，用特制之窃取工作之 CPU 调度器，分执行之块于可用之核。

Polars 提供二种执行之模式：

急切之 API： 立即执行操作，按步进行，仿若 Pandas 之行为。此模式于 Jupyter Notebooks 中交互调试甚为有益。
惰性 API： 构建逻辑有向无环图（Directed Acyclic Graph, DAG），以表管道。当调用 .collect() 时，Polars 将 DAG 递予查询优化器。优化器施以数则规则：
- 投影下推： 仅读取查询中明确引用之列。
- 命谓下推： 将过滤操作尽可能移近存储层（推入Parquet读取器）。
- 公共子表达式消除： 识别重复计算，执行一次。

Eager: Load File (All Columns) ──► Filter Rows ──► Select Columns
Lazy:  Query Planner ──► Push Filter & Select Into File Reader ──► Load File (Filtered & Pruned)

二零二六年，极光之师正式稳定其流式执行之机。此机可于超乎物理内存之数据集上，行内存外DataFrame之执行。流式之机今支持：

流式合并与截至连接：适于时序对齐（如合并金融逐笔数据或物联网传感器指标）。
流式聚合： 繁复之統計計算（含偏態、峰態及熵）今可於流動模式行之。
直達雲端匯流： Polars可直將資料流回儲存格式，如Delta Lake(sink_delta)與Apache Iceberg(sink_iceberg)，無需實化中間表格。

欲启流引擎，开发者设 Polars 以用流执行径。

import polars as pl

# Enable streaming engine affinity globally
pl.Config.set_engine_affinity("streaming")

# Define a Lazy pipeline querying a folder of compressed CSVs
lazy_query = (
    pl.scan_csv("./data/raw_metrics/*.csv")
    .filter(pl.col("metric_type") == "cpu_utilization")
    .with_columns(
        (pl.col("metric_value") * 100).alias("percentage")
    )
    .group_by(["host_id", "timestamp"])
    .agg([
        pl.col("percentage").mean().alias("mean_cpu"),
        pl.col("percentage").skew().alias("skew_cpu") # Uses new streaming aggregations
    ])
    .sort("mean_cpu", descending=True)
)

# Execute the query out-of-core using the streaming engine
# This will process files in batches, avoiding Out-Of-Memory (OOM) crashes
result_df = lazy_query.collect(streaming=True)
print(result_df.head())

Polars之融合表意DataFrame之API、惰性查询之优化、流式处理之稳定，遂成Python与Rust开发者之强引擎。

比较之论：评单节点引擎

择器之道，在审其构异，察其API之要。

需审度之要权衡

API之选：若君之团队撰标准SQL，则DuckDB为自然之始。若君撰程序代码，则Polars之表达式语言较SQL更富表现，且易并行。
可延展性抑或即用之便： 鸭数据库与波拉斯乃全然面向用户之应用。数据融合则为一引擎之框架。若尔欲构建定制数据库，或需更易物理查询执行层之运作，则当用数据融合。
内存足迹： DataFusion与Polars于内存操作，其内存占用较DuckDB为轻，此盖因Rust之内存管理模型，且直映Arrow结构。然DuckDB之缓冲管理，于需巨量磁盘溢出之繁复查询，则更为成熟。

零JVM Spark：LakeSail之高性能管道

既有数据代码库之团队，采行单节点工具之主要障碍，乃旧式API之遗痕。多组织有数千行PySpark所撰之Apache Spark代码。改写此等管道为DuckDB SQL或Polars DataFrames，费工甚巨，且引致验证之风险。

古之运行PySpark于本地，必设一Spark集群。此集群运行于Java虚拟机（JVM），遂致配置繁复，内存开销甚巨。寻常本地Spark会话，仅启即耗四GB内存，纵处理百MB之CSV文件亦然。

复次，PySpark乃借Py4J之关隘桥通。当汝之PySpark码呼Python用户定义之函数（UDF），其数据必先序列化，自JVM送至Python工作进程，经其处理，复序列化，再送回JVM。此跨进程序列化之税，致Spark中PythonUDF之执行迟缓。

Traditional PySpark UDF Path:
[JVM Executor] ──(Serialize via Py4J)──► [Python Worker] ──► [Run UDF] ──(Serialize)──► [JVM Executor]

湖帆（其开源版本Sail引擎）解此之限。Sail乃纯Rust、无JVM之计算引擎，设为Apache Spark之即插即用替代品。其行Spark Connect协议，使既有PySpark及Spark SQL应用，不须改易，仅连Sail服务器于gRPC即可运行。

LakeSail PySpark Connect Path:
[PySpark Session] ──(Spark Connect gRPC Logical Plan)──► [LakeSail Rust Server] ──► [DataFusion Physical Execution]

引擎之下，Sail易Spark之JVM Catalyst优化器及Tungsten执行引擎为Apache DataFusion与Apache Arrow。此架构有数利：

零JVM开销：Sail启于毫秒，有可忽之闲内存之迹。可于小单核VM或本地 laptops 运行Spark之码。
零拷贝Python UDF执行： 船帆将 Python 解释器直接嵌入其 Rust 二进制文件，以 PyO3 为之。执行 Python UDF 时，船帆将 Arrow 内存缓冲区的指针直接传递予 Python 解释器。UDF 在进程中执行，无需序列化，消弭了跨进程 Py4J 的瓶颈。
原生开放格式：Sail 乃具 Rust 之基，以支 Delta Lake、Apache Iceberg 及 Parquet，直合 AWS Glue、Unity Catalog、Polaris REST Catalog.

欲使 PySpark 之管于本地 Sail 会中行，则装其包，而指会建者于本地 Sail gRPC 之港：

# Install pysail and PySpark client supporting Spark Connect
pip install pysail pyspark

于尔之终端，启帆之服务器：

# Start local Sail gRPC server on port 50051
sail spark server --port 50051

于尔之Python代码，以标准远程连接字符串，连结SparkSession至本地帆之服务器：

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, udf
from pyspark.sql.types import IntegerType

# Connect to the local Sail Rust-native server over Spark Connect protocol
spark = SparkSession.builder \
    .remote("sc://localhost:50051") \
    .getOrCreate()

# Load a local Parquet dataset using standard Spark DataFrame API
df = spark.read.parquet("./data/raw_orders")

# Define a standard Python UDF
@udf(returnType=IntegerType())
def calculate_tax(amount):
    # This runs in-process via Sail's PyO3 integration
    # Zero serialization tax is paid between Rust and Python
    return int(amount * 0.08)

# Execute transformations and show results
processed_df = df.filter(col("status") == "COMPLETED") \
                 .withColumn("tax", calculate_tax(col("total_amount")))

processed_df.show()

湖帆（LakeSail）存其Spark API之表，易其执行之机，使众得易其旧PySpark之管，而独于一节点行之，无JVM之累.

规模之阈：独节点破乎何时？

虽单节点数据工程可扩机器独力所处理之数据之量，然非灵丹妙药。及至某境，物理资源之限，使单节点之构不切实际。

主要瓶颈在于I/O。于内存外执行时，将数据溢出至磁盘，则瓶颈自内存容量移至磁盘读写带宽。纵使于高速NVMe SSD，亦需时以读写数百吉字节之中间连接表或排序缓冲，此致延迟。若查询于磁盘读取写入临时块所耗时，较之CPU周期执行所耗时为多，则系统为I/O所限。

次隘，在於詢問規劃與CPU執行之擴展。若汝之詢問必須掃視多TB之資料，即使用於64核之向量化引擎，亦需數分鐘方克完成掃視。若汝之商業SLA要求毫秒級或秒級之詢問延遲，則需並行分佈掃視與處理之工作於多機器之上。

第三之隘，在组织之并。若一虚拟机承吾分析之库，而数百之析理者或BI之仪表盘同时询之，则CPU之核将受线程之饥，锁之争将缓众人之时。

欲导尔架构之变，可循此操作之决：

MPP之境：渐展于Spark、Dremio、Bauplan、SpiceAI及MotherDuck

若数据之广、迟滞之求、并作之需逾越单节点之限，则必迁于分布式MPP（并行巨量处理）之构。今之MPP之境，其途有数，视作业之式而定.

MotherDuck（双行）

欲将 DuckDB 之劳作扩于云上，而无需管理设施者，MotherDuck 提供基于 DuckDB 之无服务器平台。

MotherDuck 之核心架构模式为 双重执行。（昔称混合执行）。汝提交查询时，MotherDuck之查询规划者，审数据集之所在。其分查询之谋：于汝之笔记本电脑CPU，以本地缓存之数据，本地执行查询之部分；于MotherDuck之云端计算节点，执行其他部分（若云端所驻之Parquet或Iceberg表格）。引擎以特制之“桥”运算符，动态联结此流。

二零二六年早，MotherDuck增原生日语。PostgreSQL线协议端点此使 BI 工具与旧式应用得直连 MotherDuck，用标准 PostgreSQL 驱动，无复需于客机安装 DuckDB 运行时。复有 MotherDuck 之特色焉。脉动（无服务器）计费以一秒为增，而雁湖之融合以扩容至京字节之境.

建构图（无服务器Python管道）

数据匠于Apache Iceberg构建管道作业，建构图供无服务器、"无基建"之执行引擎。

非管理 Spark 或 Kubernetes 集群以运行定时数据转换，汝但定义汝之管渠步骤为标准 Python 或 SQL 函數。Bauplan 随需而生无状之计算，以执行代码，既毕则立止，用计每调一用之模。

Bauplan 融合 Apache Iceberg 與 Project Nessie，供「數據Git」之體驗。開發者與人工智能之代理，可於湖屋中創立獨立分支，運行實驗性之 Python 管道以驗證變更，並將更新原子式合併回生產，無需擔憂數據之毀損，亦無需支付闲置之預備計算資源之費用.

Spice.ai (聯邦查詢加速)

Spice.ai (SpiceAI) 专攻高性能应用与AI智能体之数据访问层。其作联邦查询运行时，能加速迟缓之数据查询，乃于本地具现"热"数据集。

Spice.ai 施行层级缓存之模。其将查询结果存于内存，复将活跃数据工作集缓存于高性能本地引擎，如DuckDB或Cayenne（一原生列式引擎）。

近岁，Spice.ai于其v2.0之新补，添设一前缀感知之文件缓存，以促数据湖之检阅，复设一统计缓存。 用以记录文件元数据，并有原生变更数据捕获（CDC）同步功能，可自数据库（如 PostgreSQL WAL 流）直接将更新流至本地加速缓存。此法令本地缓存之表实时更新，无需繁复之 Kafka 或 Debezium 设置。

Dremio (分布式 MPP 湖仓平台)

企业级BI，多源数据联邦，及语义层管理，Dremio乃湖仓之中枢引擎也。

Dremio基于Apache Arrow自下而上构建，尽除序列化之税。Dremio询数据时，物理执行计划以Arrow列式格式原生处理内存结构，复以Arrow Flight将结果流至客户端（如Python脚本或BI工具）。

Dremio于浩瀚云数据湖间，以三层架构达至秒以下之速：

列式云缓存（C3）：自动将对象存储（如AWS S3或Azure ADLS）之数据块，缓于执行节点之本地NVMe驱动器，化远云I/O为近盘读取之速。
遐思： Dremio之查询规划者，自若无形，以物理优化之预计算Iceberg材料化，以速用户之查询。自Dremio v26始，Reflections唯存Iceberg格式存储数据，废旧式以简存储之道。Dremio之自主Reflections 依人工智能观七日之内查询之律，自为立、更、废映像，以保仪表盘之优效，无需人手之理.
启目录（由Apache Polaris所驱）: Dremio 之自具目录，乃基于 Apache Polaris 而成，至二零二六年，始晋为 Apache 之顶级项目。Open Catalog 实施 Apache Iceberg 之 REST 规范，使他种引擎（如 Spark 或 Flink）得安全查询同表。其供细微之访问控制（FGAC），含列之掩蔽与行之筛选。

Dremio 之 AI 语义层許團隊一一定義虛擬資料集（視圖），一用於諸BI與AI應用。此層直嵌入列與資料集，載述、維基、標籤。義理層教AI模型識數據商業脈絡，使AI使者能生成正軌SQL詢問，非憶幻泛常之碼。Dremio亦嵌入創生AI功能，自生成維基述說，依模式建議標籤。

建筑选择框架与结论

今之數據工程，非復擇於本地腳本與廣大集群也。乃在配適其工具鏈於數據體量、延遲SLA與組織所需。

为导汝之择，循此决疑之树。

君之劳役，运行于本地乎，抑或单节点乎？
- 若君好以SQL为分析查询之文：用之DuckDB(达克数据库)此无需配置，能处理超乎内存之数据，以溢出内存方式为之。
- 若尔撰程序之Python或RustDataFrame之管道：用之波拉斯，其惰性优化器与稳定流引擎，可促速行。
- 若汝有旧式PySpark或Spark SQL之码，而欲避JVM之累：当用LakeSail，此可本生于Rust，行Spark Connect gRPC之逻辑策。
- 若汝在构制自用之问询引擎或析理之器：亦当用Apache Arrow DataFusion 乃尔之模块编译框架也。
尔之作业是否逾越单节点之能（多TB规模、高并发、或跨源BI）？
- 若尔欲求无服务器、混合之 DuckDB SQL 代码之延展： 则用 MotherDuck。
- 若需于 Iceberg 上直建无服务器 Python 管道，兼具类 Git 版本控制之能：用之造物之图.
- 若需缓存并加速联邦数据以供本地AI/RAG应用之用：用之辛普斯·爱伊.
- 若需企业级BI、语义治理、多源联邦及Iceberg上的亚秒级SQL查询：用之Dremio(Dremio).

单节点数据技术，已拓机器之能。藉Apache Arrow以零拷贝内存布局，DataFusion类编译器，及向量化执行引擎之力，可处以往需繁复分布式集群方能为之之务。

尔营新数台，首当审尔事可独于单结运行否。今世竖列引擎，使尔得营、试、行管渠，而地构之繁简甚微。及尔数据之广或组司之并需散布之制，则当循渐易，用通开之准，若 Apache Iceberg 与 Apache Arrow 是也.

加速尔湖宅之技

欲深谙现代数据架构之道，可循下列诸步：

览湖居参考之文探求"构架Apache Iceberg湖仓"复有诸技术之著述，述分区调适、目录设计、查询优化之事于其间。書籍。AlexMerced.com。
自建本地管道：始下载之pysail或polars乃以之试于本地Parquet数据集。较诸既有框架，观其查询规划之时与CPU内存之迹。
评Dremio Cloud若汝地之查询引擎触及其限，或需跨多源聚散数据，直于汝之S3数据湖部署Dremio。试Dremio Cloud三十日免费。Dremio.com(德瑞米奥网)入门指南.

推薦訂閱源

DEV Community