Daft 路线图深度解析高性能 AI 数据引擎未来一年的演进方向【免费下载链接】DaftHigh-performance data engine for AI and multimodal workloads. Process images, audio, video, and structured data at any scale项目地址: https://gitcode.com/GitHub_Trending/da/DaftRoadmap 导读Daft 是一个面向 AI 与多模态负载的高性能数据引擎其官方路线图docs/roadmap.md最后更新于 2026 年 3 月划定了未来一年的四大重点方向——性能、关键特性、可观测性、可扩展性并公开了若干未来工作候选特性。阅读本文你将理解 Daft 团队在每个方向上的具体技术目标如基于 Arrow Flight RPC 的原生 Shuffle、Checkpointing、Kubernetes 部署、Arrow C Interface 原生扩展等并对照当前仓库源码掌握这些能力的已落地部分与演进脉络为技术选型、二次开发或社区贡献提供依据。一、路线图总览五大方向Daft 路线图将工作分为五大板块其中前四块是coming year未来一年的正式规划第五块是仍在评估中的候选特性板块核心目标仓库中已可观察的落地痕迹Performance 性能大规模 Shuffle、分布式引擎Flotilla优化、内存管理、哈希算子改进daft/runners/flotilla.py 中的 Flight shuffle 相关代码Key Features 关键特性Checkpointing、Kubernetes 支持、多分布式后端daft/checkpoint.py、k8s/charts/quickstartObservability 可观测性Daft Dashboard、调试信息与运行历史、资源利用率指标daft/subscribers 事件日志体系、daft/dashboard.pyiExtensibility 可扩展性原生扩展Arrow C Interface、数据源重构、Arrow2 弃用src/common/arrow-ffi 的 FFI 工具Future Work 未来工作Delta Lake 增强、VARIANT 类型、ResultT类型处于讨论阶段欢迎社区贡献需要特别说明的是路线图中的条目随时可能调整本文对照仓库给出的已落地痕迹仅代表当前代码快照下的实现状态不构成对路线图最终交付的承诺。二、性能Performance把大规模分布式执行做到极致性能是 Daft 路线的第一优先级四项规划分别覆盖数据搬移、任务调度、内存与算子内核。1. 大规模 Shuffle基于 Arrow Flight RPC 的 P2P 数据搬运路线图提出的第一项性能工作是Performant large scale shuffles大规模高性能 Shuffle——为分布式引擎 Flotilla 提供原生 Shuffle 服务用于节点间的数据传递其核心技术方案是基于 Arrow Flight RPC 的专用点对点peer-to-peer服务对应官方讨论区 #6472 号讨论。从当前仓库源码看这一方向已经进入工程落地阶段daft/runners/flotilla.py 直接导入了FlightPartitionRef、FlightPartitions等类型说明 Flight 已成为 Flotilla 中分区数据引用与传递的一等公民SwordfishTaskMetadata中带有is_flight_shuffle: bool标志标明某个任务是否走 Flight shuffle 路径_clear_flight_shuffle_dirs以ray.remote装饰的远端函数与clear_flight_shuffle_dirs_on_all_nodes负责在 worker 节点上清理 Flight shuffle 产生的临时目录暗示 Flight shuffle 会在节点本地落盘交换数据。这印证了路线图的思路用 Arrow Flight RPC 作为节点间分区数据交换的传输协议替代传统的对象存储中转从而显著降低大规模 Shuffle 的延迟与带宽开销。对于关注该特性的读者可以从上述flotilla.py文件追踪is_flight_shuffle标志的完整调用链理解 shuffle 路径的触发条件。2. 分布式引擎Flotilla优化动态调度与动态分区第二项规划是优化 Flotilla 的调度与执行目标包括动态调度与执行任务dynamically schedule and execute tasks最小化 worker 的启动开销与资源竞争minimize worker setup overhead and contention引入动态分区dynamic partitioning。这对应 Flotilla 从静态任务图走向运行时自适应的演进。仓库中 daft/runners/flotilla.py 已通过 Ray 的 actor/remote 机制管理 worker 生命周期而路线图则进一步要求调度器能在运行时根据数据倾斜、节点负载等因素动态调整分区策略——这通常需要与第三项内存管理联动让调度决策建立在真实的资源反馈之上。3. 内存管理降低 OOM、支撑背压与动态批处理第三项规划是在本地 runner 中跟踪与管理内存使用实现三个直接收益降低 OOMOut of Memory概率在执行前即对算子所需内存有预估背压backpressure当下游消费慢于上游生产时通过内存水位触发限流动态批处理dynamic batching根据可用内存动态调整批大小。仓库中与内存估计相关的基础设施已经存在——tests/test_size_estimations.py 专门测试大小估算逻辑说明 Daft 已有按分区MicroPartition估算内存占用的能力路线图则是将其系统化地接入本地 runner 的执行循环形成完整的内存治理闭环。对于处理超大文件或流式数据的用户这条路线直接关系到同样的内存能稳定跑多大的数据集。4. 哈希算子改进低基数列上的 GroupBy 与 Hash Join第四项规划聚焦哈希类算子的底层技术改进**分区partitioning**技术改进**哈希表构建hash-table building**技术重点场景是低基数low-cardinality情况下的 groupby 聚合与哈希连接hash join。低基数场景的经典痛点是桶数远大于唯一键数时哈希表空转、内存浪费严重。Daft 在这方面的优化将直接影响groupby()、join()等日常高频操作的性能。仓库中 daft/functions/agg.py 与 daft/expressions 定义了聚合与连接表达式底层则由 Rust 内核src/daft-core实现哈希表与分区逻辑读者可据此定位到具体算子实现。三、关键特性Key Features让长任务可恢复、部署更灵活1. Checkpointing长时运行任务的断点续跑路线图第一项关键特性是Checkpointing——支持从给定检查点checkpoint恢复长时间运行的工作负载对应官方讨论区 #6446 号讨论。值得注意的是这一能力在当前仓库中已有相当完整的落地实现是路线图中已交付程度最高的条目之一daft/checkpoint.py 定义了CheckpointStore、CheckpointConfig、IdempotentCommit与KeyFilteringSettings四个核心组件CheckpointStore负责标识检查点状态存放在哪里通过path指定存储根目录 URI如s3://bucket/checkpoints并配合io_config指定对象存储后端配置CheckpointConfig负责指定按什么键跟踪处理进度例如按file_id追踪每个文件是否已处理两者配合即可实现精确一次的断点续跑语义官方文档给出了最小使用范式见 daft/checkpoint.py 中的 docstring 示例store daft.CheckpointStore(s3://bucket/ckpt) config daft.CheckpointConfig(storestore, onfile_id) df daft.read_parquet(s3://input/, checkpointconfig)此外daft/dataframe/_checkpoint_commit.py 与 src/daft-checkpointRust 侧实现含tests/单测共同支撑幂等提交IdempotentCommit语义。对于每天跑数小时甚至数天的 ETL、向量化流水线这一特性意味着进程崩溃后无需从头重跑只需从最近检查点恢复。2. Kubernetes 支持直接在 K8s 上跑分布式 Daft第二项关键特性是让分布式 Daft 直接运行在 Kubernetes 上。这一方向同样已在仓库中部分落地官方部署文档 docs/distributed/kubernetes.md 提供了完整的 Helm 快速开始指南仓库内置了 Quickstart Helm Chartk8s/charts/quickstart包含values.yaml、job.yaml、head-deployment.yaml、worker-deployment.yaml、serviceaccount.yaml等模板覆盖两种运行模式简单模式Simple Mode——使用原生 runnernative runner在 K8s 上跑单机任务# my_script.py # /// script # dependencies [daft] # /// import daft df daft.from_pydict({ a: [3, 2, 5, 6, 1, 4], b: [True, False, False, True, True, False] }) df df.where(df[b]).sort(df[a]) print(df.collect())部署与清理# 用脚本安装 job helm install my-job oci://ghcr.io/eventual-inc/daft/quickstart \ --set-file job.scriptmy_script.py # 查看日志 kubectl logs -f job/my-job-quickstart-job # 清理 helm uninstall my-job分布式模式Distributed Mode——在 K8s 上拉起 Ray 集群head 多个 worker以ray[client]2.46.0为依赖运行同样的 Daft 作业由 k8s/charts/quickstart/templates/head-deployment.yaml 与 worker-deployment.yaml 分别编排集群头部与工作节点。前置要求为 Kubernetes 1.19、Helm 3.x 及配置好凭据的 kubectl。路线图中Kubernetes 支持的后续方向是在此 Quickstart 基础上深化为生产级的分布式运行体验与 Flotilla 调度、Dashboard 观测联动。3. 多分布式后端通用接口 Ray 持续支持第三项关键特性是Multiple distributed backends——通过通用接口支持多种分布式后端同时继续支持 Ray 作为后端之一。从源码结构看这一抽象已在 Python 层成型daft/runners/runner.py 定义了泛型基类Runner(Generic[PartitionT])并通过runner_io属性将执行与 IO 解耦具体实现包括 daft/runners/native_runner.py本地/原生执行、daft/runners/ray_runner.pyRay 后端与 daft/runners/flotilla.pyFlotilla 分布式执行。因此可以推断未来新增后端如直接跑在 Kubernetes 上的调度器只需实现Runner接口约定即可复用上层 DataFrame API。对于有私有调度系统的团队这一接口即接入点。四、可观测性Observability让分布式任务看得见、可回溯1. Daft Dashboard集群/任务/分区三级观测路线图规划了Daft Dashboard——面向 Flotilla 的可观测性面板提供集群cluster、任务task与分区partition三个粒度的观测能力。仓库中 Dashboard 已有前端与 Rust 后端骨架Python 侧类型声明位于 daft/dashboard.pyiRust 后端在 src/daft-dashboard其frontend/目录包含 40 个.tsx组件与配套.ts类型说明面板 UI 已具备相当规模事件体系方面daft/subscribers 提供event_log.py、event_log_sink.py、events.py等模块构成从执行事件到日志落地的管道docs/observability/dashboard.md 记录了使用方法。路线图目标是在此基础上补全Flotilla 集群视角的观测包括每个 worker 的负载、任务级执行时间线、分区级数据分布等。2. 改进调试调试信息与运行历史第二项规划是捕获并检索调试信息与运行历史run history——即在任务结束后仍能回溯当时每个阶段发生了什么、哪个分区失败、耗时多少。这与仓库中的事件日志event log体系直接相关daft/subscribers/event_log.py 与 daft/subscribers/event_log_sink.py 支持将执行事件写入持久化 sink为事后检索运行历史提供了数据基础。路线图进一步要求提供更易用的检索与导出能力如按 query id 查询历史运行、导出 profiling 数据。tools/trace_to_speedscope.py 已能将追踪数据转换为 Speedscope 火焰图格式是调试体验的一个具体落点。3. 内存与 CPU 观测资源利用率指标第三项规划是捕获并检索资源利用率指标memory CPU utilization metrics。结合上文性能板块第 3 条内存管理两者互为表里内存管理负责控制资源观测负责可视化。仓库的 src/common/metricsRust 侧指标基础设施与 src/common/system-info系统信息采集为此提供了底层支撑后续将把它们暴露为可查询的指标流。五、可扩展性Extensibility降低二次开发门槛1. 原生扩展通过 Arrow C Interface 用任意语言扩展 Daft路线图提出支持基于 Arrow C 接口Arrow C interfaces的 Daft 原生扩展让开发者能用任何支持 C 互操作的语言扩展 Daft。这意味着 Daft 的扩展点将不限于 Python 与 RustC、C、Rust、Go 等语言均可接入。仓库中的 src/common/arrow-ffi 正是这条路的基石src/common/arrow-ffi/src/lib.rs 模块注释明确写道FFI utilities for converting between PyArrow and Rust Arrow arrays在 PyArrow 与 Rust Arrow 数组间转换的 FFI 工具其中使用FFI_ArrowArray、FFI_ArrowSchema、FFI_ArrowArrayStream等 Arrow C 结构体实现与 PyCapsulePyCapsule包装FFI_ArrowSchema导出的互通支持从原始指针安全重建数组/流并允许消费方指定期望的 schema 进行 castFFI_ArrowSchema互转与校验。此外仓库已有examples/hello、examples/hello_cppC、examples/dvectorRust三套原生扩展示例工程分别演示了 Python Rust、Python C 的扩展写法其中 examples/hello_cpp/src/hello_cpp.cpp 是 C 侧的直接参考。这为Arrow2 弃用后如何写扩展给出了现成模板。2. 数据源重构让新增原生 Rust 数据源更简单第二项规划是简化 source pipeline使新增原生 Rust 数据源native Rust sources变得直接。当前仓库的 IO 层已有大量以_前缀命名的格式模块如 daft/io/_parquet.py、daft/io/_csv.py、daft/io/_json.py 等Rust 侧则对应 src/daft-scan扫描器与 src/daft-file 等 crate。路线图的重构目标是收敛这些接口让贡献者只需实现少量 trait 即可注册一种新格式而不是打通一整套扫描/解码/分区管线。3. Arrow2 弃用deprecation路线图明确将Arrow2 弃用列为可扩展性方向之一对应官方讨论区 #5741 号讨论。Arrow2 是早期 Daft 使用的 Apache Arrow 社区分支实现社区维护已停止业界主流已迁移至 arrow-rs。从当前仓库结构看Rust 侧 crate 大量基于 arrow-rs如 src/common/arrow-ffi 中与 arrow-rs 的FFI_ArrowSchema/FFI_ArrowArray互操作说明迁移已在推进中。完成 Arrow2 弃用后Daft 将能享受 arrow-rs 的持续维护与性能改进这也是原生扩展计划的前提之一。六、未来工作Future Work候选特性与社区贡献机会以下特性尚不在正式路线图上但被团队标记为社区贡献机会已在官方仓库以help wanted与good first issue标签标记Daft 团队愿意提供技术方向指导并协助界定工作范围1. 改进 Delta Lake 支持两个具体议题均有对应 issue读取带删除向量deletion vectors的表Deletion Vector 是 Delta Lake 2.x 引入的优化用于记录已删除行而不重写数据文件读取支持可显著提升含高频更新的表上的扫描效率读取带列映射column mappings的表列映射允许逻辑列名与物理存储名解耦支持后可在不重写数据的情况下安全地重命名/删除列。当前仓库已提供 Delta Lake 连接器daft/io/delta_lake与教程tutorials/delta_lake这两项增强将补齐与最新 Delta Lake 协议的对齐。2. VARIANT 类型路线图计划在 Daft 类型系统中引入VARIANT类型并做到与 Parquet 的 VARIANT 兼容。VARIANT 是半结构化类型可容纳任意 JSON 风格的嵌套数据对象、数组、标量且以紧凑二进制存储广泛用于日志、事件流等 schema 频繁演化的数据。落地后Daft 用户将能以统一类型处理结构未知的列无需预先推断 schema。仓库类型系统入口位于 daft/datatype.py 与 src/daft-schema未来 VARIANT 将作为DataType的新成员接入。3.ResultT类型路线图计划为类型系统增加ResultT即 Either类型用于优雅处理可能失败的操作——例如解析失败、类型转换失败、远程调用异常等场景不再只能整行报错而是将错误作为值随行保留供下游选择性处理。这与 Rust 的ResultT, E语义一脉相承落地后将为数据清洗与容错流水线提供一等公民的错误处理能力。七、如何跟踪与参与跟踪进度路线图条目会随实际进展动态调整最权威的更新来源是 docs/roadmap.md 本身每个条目在官方讨论区/issue 系统中均有对应编号如 Shuffle 讨论 #6472、Checkpointing 讨论 #6446、Arrow2 弃用讨论 #5741、Delta Lake 删除向量 issue #1954、列映射 issue #1955可据此跟进技术方案讨论。参与贡献对路线图条目尤其是未来工作板块的help wanted/good first issue条目感兴趣的开发者可通过提交 issue/PR 或加入官方 Slack 社区与团队沟通团队会协助界定工作范围并评审 PR。本地验证本文引用的所有已落地痕迹均可在当前仓库对应路径直接查看——包括 daft/runners/flotilla.pyFlight shuffle、daft/checkpoint.pyCheckpointing、k8s/charts/quickstartKubernetes 部署、src/common/arrow-ffiArrow C Interface 基础以及 examples 下的原生扩展示例工程。综上Daft 的路线图描绘了一条清晰的演进主线性能上以 Flight Shuffle 与动态调度打通大规模分布式执行可靠性上以 Checkpointing 与资源治理支撑长任务部署上以 Kubernetes 与多后端抽象扩展落地形态开放上以 Arrow C Interface 与数据源重构降低生态扩展门槛。其中 Checkpointing、Kubernetes Quickstart、Flight shuffle 骨架与 FFI 基础已在仓库中可查可跑其余条目则为社区协作留下了明确的技术靶点。【免费下载链接】DaftHigh-performance data engine for AI and multimodal workloads. Process images, audio, video, and structured data at any scale项目地址: https://gitcode.com/GitHub_Trending/da/Daft创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Daft 路线图深度解析：高性能 AI 数据引擎未来一年的演进方向
Daft 路线图深度解析高性能 AI 数据引擎未来一年的演进方向【免费下载链接】DaftHigh-performance data engine for AI and multimodal workloads. Process images, audio, video, and structured data at any scale项目地址: https://gitcode.com/GitHub_Trending/da/DaftRoadmap 导读Daft 是一个面向 AI 与多模态负载的高性能数据引擎其官方路线图docs/roadmap.md最后更新于 2026 年 3 月划定了未来一年的四大重点方向——性能、关键特性、可观测性、可扩展性并公开了若干未来工作候选特性。阅读本文你将理解 Daft 团队在每个方向上的具体技术目标如基于 Arrow Flight RPC 的原生 Shuffle、Checkpointing、Kubernetes 部署、Arrow C Interface 原生扩展等并对照当前仓库源码掌握这些能力的已落地部分与演进脉络为技术选型、二次开发或社区贡献提供依据。一、路线图总览五大方向Daft 路线图将工作分为五大板块其中前四块是coming year未来一年的正式规划第五块是仍在评估中的候选特性板块核心目标仓库中已可观察的落地痕迹Performance 性能大规模 Shuffle、分布式引擎Flotilla优化、内存管理、哈希算子改进daft/runners/flotilla.py 中的 Flight shuffle 相关代码Key Features 关键特性Checkpointing、Kubernetes 支持、多分布式后端daft/checkpoint.py、k8s/charts/quickstartObservability 可观测性Daft Dashboard、调试信息与运行历史、资源利用率指标daft/subscribers 事件日志体系、daft/dashboard.pyiExtensibility 可扩展性原生扩展Arrow C Interface、数据源重构、Arrow2 弃用src/common/arrow-ffi 的 FFI 工具Future Work 未来工作Delta Lake 增强、VARIANT 类型、ResultT类型处于讨论阶段欢迎社区贡献需要特别说明的是路线图中的条目随时可能调整本文对照仓库给出的已落地痕迹仅代表当前代码快照下的实现状态不构成对路线图最终交付的承诺。二、性能Performance把大规模分布式执行做到极致性能是 Daft 路线的第一优先级四项规划分别覆盖数据搬移、任务调度、内存与算子内核。1. 大规模 Shuffle基于 Arrow Flight RPC 的 P2P 数据搬运路线图提出的第一项性能工作是Performant large scale shuffles大规模高性能 Shuffle——为分布式引擎 Flotilla 提供原生 Shuffle 服务用于节点间的数据传递其核心技术方案是基于 Arrow Flight RPC 的专用点对点peer-to-peer服务对应官方讨论区 #6472 号讨论。从当前仓库源码看这一方向已经进入工程落地阶段daft/runners/flotilla.py 直接导入了FlightPartitionRef、FlightPartitions等类型说明 Flight 已成为 Flotilla 中分区数据引用与传递的一等公民SwordfishTaskMetadata中带有is_flight_shuffle: bool标志标明某个任务是否走 Flight shuffle 路径_clear_flight_shuffle_dirs以ray.remote装饰的远端函数与clear_flight_shuffle_dirs_on_all_nodes负责在 worker 节点上清理 Flight shuffle 产生的临时目录暗示 Flight shuffle 会在节点本地落盘交换数据。这印证了路线图的思路用 Arrow Flight RPC 作为节点间分区数据交换的传输协议替代传统的对象存储中转从而显著降低大规模 Shuffle 的延迟与带宽开销。对于关注该特性的读者可以从上述flotilla.py文件追踪is_flight_shuffle标志的完整调用链理解 shuffle 路径的触发条件。2. 分布式引擎Flotilla优化动态调度与动态分区第二项规划是优化 Flotilla 的调度与执行目标包括动态调度与执行任务dynamically schedule and execute tasks最小化 worker 的启动开销与资源竞争minimize worker setup overhead and contention引入动态分区dynamic partitioning。这对应 Flotilla 从静态任务图走向运行时自适应的演进。仓库中 daft/runners/flotilla.py 已通过 Ray 的 actor/remote 机制管理 worker 生命周期而路线图则进一步要求调度器能在运行时根据数据倾斜、节点负载等因素动态调整分区策略——这通常需要与第三项内存管理联动让调度决策建立在真实的资源反馈之上。3. 内存管理降低 OOM、支撑背压与动态批处理第三项规划是在本地 runner 中跟踪与管理内存使用实现三个直接收益降低 OOMOut of Memory概率在执行前即对算子所需内存有预估背压backpressure当下游消费慢于上游生产时通过内存水位触发限流动态批处理dynamic batching根据可用内存动态调整批大小。仓库中与内存估计相关的基础设施已经存在——tests/test_size_estimations.py 专门测试大小估算逻辑说明 Daft 已有按分区MicroPartition估算内存占用的能力路线图则是将其系统化地接入本地 runner 的执行循环形成完整的内存治理闭环。对于处理超大文件或流式数据的用户这条路线直接关系到同样的内存能稳定跑多大的数据集。4. 哈希算子改进低基数列上的 GroupBy 与 Hash Join第四项规划聚焦哈希类算子的底层技术改进**分区partitioning**技术改进**哈希表构建hash-table building**技术重点场景是低基数low-cardinality情况下的 groupby 聚合与哈希连接hash join。低基数场景的经典痛点是桶数远大于唯一键数时哈希表空转、内存浪费严重。Daft 在这方面的优化将直接影响groupby()、join()等日常高频操作的性能。仓库中 daft/functions/agg.py 与 daft/expressions 定义了聚合与连接表达式底层则由 Rust 内核src/daft-core实现哈希表与分区逻辑读者可据此定位到具体算子实现。三、关键特性Key Features让长任务可恢复、部署更灵活1. Checkpointing长时运行任务的断点续跑路线图第一项关键特性是Checkpointing——支持从给定检查点checkpoint恢复长时间运行的工作负载对应官方讨论区 #6446 号讨论。值得注意的是这一能力在当前仓库中已有相当完整的落地实现是路线图中已交付程度最高的条目之一daft/checkpoint.py 定义了CheckpointStore、CheckpointConfig、IdempotentCommit与KeyFilteringSettings四个核心组件CheckpointStore负责标识检查点状态存放在哪里通过path指定存储根目录 URI如s3://bucket/checkpoints并配合io_config指定对象存储后端配置CheckpointConfig负责指定按什么键跟踪处理进度例如按file_id追踪每个文件是否已处理两者配合即可实现精确一次的断点续跑语义官方文档给出了最小使用范式见 daft/checkpoint.py 中的 docstring 示例store daft.CheckpointStore(s3://bucket/ckpt) config daft.CheckpointConfig(storestore, onfile_id) df daft.read_parquet(s3://input/, checkpointconfig)此外daft/dataframe/_checkpoint_commit.py 与 src/daft-checkpointRust 侧实现含tests/单测共同支撑幂等提交IdempotentCommit语义。对于每天跑数小时甚至数天的 ETL、向量化流水线这一特性意味着进程崩溃后无需从头重跑只需从最近检查点恢复。2. Kubernetes 支持直接在 K8s 上跑分布式 Daft第二项关键特性是让分布式 Daft 直接运行在 Kubernetes 上。这一方向同样已在仓库中部分落地官方部署文档 docs/distributed/kubernetes.md 提供了完整的 Helm 快速开始指南仓库内置了 Quickstart Helm Chartk8s/charts/quickstart包含values.yaml、job.yaml、head-deployment.yaml、worker-deployment.yaml、serviceaccount.yaml等模板覆盖两种运行模式简单模式Simple Mode——使用原生 runnernative runner在 K8s 上跑单机任务# my_script.py # /// script # dependencies [daft] # /// import daft df daft.from_pydict({ a: [3, 2, 5, 6, 1, 4], b: [True, False, False, True, True, False] }) df df.where(df[b]).sort(df[a]) print(df.collect())部署与清理# 用脚本安装 job helm install my-job oci://ghcr.io/eventual-inc/daft/quickstart \ --set-file job.scriptmy_script.py # 查看日志 kubectl logs -f job/my-job-quickstart-job # 清理 helm uninstall my-job分布式模式Distributed Mode——在 K8s 上拉起 Ray 集群head 多个 worker以ray[client]2.46.0为依赖运行同样的 Daft 作业由 k8s/charts/quickstart/templates/head-deployment.yaml 与 worker-deployment.yaml 分别编排集群头部与工作节点。前置要求为 Kubernetes 1.19、Helm 3.x 及配置好凭据的 kubectl。路线图中Kubernetes 支持的后续方向是在此 Quickstart 基础上深化为生产级的分布式运行体验与 Flotilla 调度、Dashboard 观测联动。3. 多分布式后端通用接口 Ray 持续支持第三项关键特性是Multiple distributed backends——通过通用接口支持多种分布式后端同时继续支持 Ray 作为后端之一。从源码结构看这一抽象已在 Python 层成型daft/runners/runner.py 定义了泛型基类Runner(Generic[PartitionT])并通过runner_io属性将执行与 IO 解耦具体实现包括 daft/runners/native_runner.py本地/原生执行、daft/runners/ray_runner.pyRay 后端与 daft/runners/flotilla.pyFlotilla 分布式执行。因此可以推断未来新增后端如直接跑在 Kubernetes 上的调度器只需实现Runner接口约定即可复用上层 DataFrame API。对于有私有调度系统的团队这一接口即接入点。四、可观测性Observability让分布式任务看得见、可回溯1. Daft Dashboard集群/任务/分区三级观测路线图规划了Daft Dashboard——面向 Flotilla 的可观测性面板提供集群cluster、任务task与分区partition三个粒度的观测能力。仓库中 Dashboard 已有前端与 Rust 后端骨架Python 侧类型声明位于 daft/dashboard.pyiRust 后端在 src/daft-dashboard其frontend/目录包含 40 个.tsx组件与配套.ts类型说明面板 UI 已具备相当规模事件体系方面daft/subscribers 提供event_log.py、event_log_sink.py、events.py等模块构成从执行事件到日志落地的管道docs/observability/dashboard.md 记录了使用方法。路线图目标是在此基础上补全Flotilla 集群视角的观测包括每个 worker 的负载、任务级执行时间线、分区级数据分布等。2. 改进调试调试信息与运行历史第二项规划是捕获并检索调试信息与运行历史run history——即在任务结束后仍能回溯当时每个阶段发生了什么、哪个分区失败、耗时多少。这与仓库中的事件日志event log体系直接相关daft/subscribers/event_log.py 与 daft/subscribers/event_log_sink.py 支持将执行事件写入持久化 sink为事后检索运行历史提供了数据基础。路线图进一步要求提供更易用的检索与导出能力如按 query id 查询历史运行、导出 profiling 数据。tools/trace_to_speedscope.py 已能将追踪数据转换为 Speedscope 火焰图格式是调试体验的一个具体落点。3. 内存与 CPU 观测资源利用率指标第三项规划是捕获并检索资源利用率指标memory CPU utilization metrics。结合上文性能板块第 3 条内存管理两者互为表里内存管理负责控制资源观测负责可视化。仓库的 src/common/metricsRust 侧指标基础设施与 src/common/system-info系统信息采集为此提供了底层支撑后续将把它们暴露为可查询的指标流。五、可扩展性Extensibility降低二次开发门槛1. 原生扩展通过 Arrow C Interface 用任意语言扩展 Daft路线图提出支持基于 Arrow C 接口Arrow C interfaces的 Daft 原生扩展让开发者能用任何支持 C 互操作的语言扩展 Daft。这意味着 Daft 的扩展点将不限于 Python 与 RustC、C、Rust、Go 等语言均可接入。仓库中的 src/common/arrow-ffi 正是这条路的基石src/common/arrow-ffi/src/lib.rs 模块注释明确写道FFI utilities for converting between PyArrow and Rust Arrow arrays在 PyArrow 与 Rust Arrow 数组间转换的 FFI 工具其中使用FFI_ArrowArray、FFI_ArrowSchema、FFI_ArrowArrayStream等 Arrow C 结构体实现与 PyCapsulePyCapsule包装FFI_ArrowSchema导出的互通支持从原始指针安全重建数组/流并允许消费方指定期望的 schema 进行 castFFI_ArrowSchema互转与校验。此外仓库已有examples/hello、examples/hello_cppC、examples/dvectorRust三套原生扩展示例工程分别演示了 Python Rust、Python C 的扩展写法其中 examples/hello_cpp/src/hello_cpp.cpp 是 C 侧的直接参考。这为Arrow2 弃用后如何写扩展给出了现成模板。2. 数据源重构让新增原生 Rust 数据源更简单第二项规划是简化 source pipeline使新增原生 Rust 数据源native Rust sources变得直接。当前仓库的 IO 层已有大量以_前缀命名的格式模块如 daft/io/_parquet.py、daft/io/_csv.py、daft/io/_json.py 等Rust 侧则对应 src/daft-scan扫描器与 src/daft-file 等 crate。路线图的重构目标是收敛这些接口让贡献者只需实现少量 trait 即可注册一种新格式而不是打通一整套扫描/解码/分区管线。3. Arrow2 弃用deprecation路线图明确将Arrow2 弃用列为可扩展性方向之一对应官方讨论区 #5741 号讨论。Arrow2 是早期 Daft 使用的 Apache Arrow 社区分支实现社区维护已停止业界主流已迁移至 arrow-rs。从当前仓库结构看Rust 侧 crate 大量基于 arrow-rs如 src/common/arrow-ffi 中与 arrow-rs 的FFI_ArrowSchema/FFI_ArrowArray互操作说明迁移已在推进中。完成 Arrow2 弃用后Daft 将能享受 arrow-rs 的持续维护与性能改进这也是原生扩展计划的前提之一。六、未来工作Future Work候选特性与社区贡献机会以下特性尚不在正式路线图上但被团队标记为社区贡献机会已在官方仓库以help wanted与good first issue标签标记Daft 团队愿意提供技术方向指导并协助界定工作范围1. 改进 Delta Lake 支持两个具体议题均有对应 issue读取带删除向量deletion vectors的表Deletion Vector 是 Delta Lake 2.x 引入的优化用于记录已删除行而不重写数据文件读取支持可显著提升含高频更新的表上的扫描效率读取带列映射column mappings的表列映射允许逻辑列名与物理存储名解耦支持后可在不重写数据的情况下安全地重命名/删除列。当前仓库已提供 Delta Lake 连接器daft/io/delta_lake与教程tutorials/delta_lake这两项增强将补齐与最新 Delta Lake 协议的对齐。2. VARIANT 类型路线图计划在 Daft 类型系统中引入VARIANT类型并做到与 Parquet 的 VARIANT 兼容。VARIANT 是半结构化类型可容纳任意 JSON 风格的嵌套数据对象、数组、标量且以紧凑二进制存储广泛用于日志、事件流等 schema 频繁演化的数据。落地后Daft 用户将能以统一类型处理结构未知的列无需预先推断 schema。仓库类型系统入口位于 daft/datatype.py 与 src/daft-schema未来 VARIANT 将作为DataType的新成员接入。3.ResultT类型路线图计划为类型系统增加ResultT即 Either类型用于优雅处理可能失败的操作——例如解析失败、类型转换失败、远程调用异常等场景不再只能整行报错而是将错误作为值随行保留供下游选择性处理。这与 Rust 的ResultT, E语义一脉相承落地后将为数据清洗与容错流水线提供一等公民的错误处理能力。七、如何跟踪与参与跟踪进度路线图条目会随实际进展动态调整最权威的更新来源是 docs/roadmap.md 本身每个条目在官方讨论区/issue 系统中均有对应编号如 Shuffle 讨论 #6472、Checkpointing 讨论 #6446、Arrow2 弃用讨论 #5741、Delta Lake 删除向量 issue #1954、列映射 issue #1955可据此跟进技术方案讨论。参与贡献对路线图条目尤其是未来工作板块的help wanted/good first issue条目感兴趣的开发者可通过提交 issue/PR 或加入官方 Slack 社区与团队沟通团队会协助界定工作范围并评审 PR。本地验证本文引用的所有已落地痕迹均可在当前仓库对应路径直接查看——包括 daft/runners/flotilla.pyFlight shuffle、daft/checkpoint.pyCheckpointing、k8s/charts/quickstartKubernetes 部署、src/common/arrow-ffiArrow C Interface 基础以及 examples 下的原生扩展示例工程。综上Daft 的路线图描绘了一条清晰的演进主线性能上以 Flight Shuffle 与动态调度打通大规模分布式执行可靠性上以 Checkpointing 与资源治理支撑长任务部署上以 Kubernetes 与多后端抽象扩展落地形态开放上以 Arrow C Interface 与数据源重构降低生态扩展门槛。其中 Checkpointing、Kubernetes Quickstart、Flight shuffle 骨架与 FFI 基础已在仓库中可查可跑其余条目则为社区协作留下了明确的技术靶点。【免费下载链接】DaftHigh-performance data engine for AI and multimodal workloads. Process images, audio, video, and structured data at any scale项目地址: https://gitcode.com/GitHub_Trending/da/Daft创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考