Apache DataFusion 中自定义执行计划指标的实现与思考

Apache DataFusion 作为高性能查询执行引擎，其执行计划(ExecutionPlan)的监控指标(MetricValue)系统一直采用简单的单值统计模式。随着分布式查询场景的普及，这种设计在复杂监控需求面前逐渐显现出局限性。

现有指标系统的局限性

当前 DataFusion 的 MetricValue 枚举仅支持基础统计类型：

• 计数器(Count)
• 测量值(Gauge)
• 计时器(Timer)
• 时间戳(Timestamp)
• 以及少量硬编码变体如 SpillCount 或 OutputRows

这种设计在分布式环境下存在明显不足：

1. 无法捕捉指标分布特征（如 P99 计算时间）
2. 难以识别分区间的资源使用倾斜情况
3. 只能追踪简单统计量（平均值/最小值/最大值）
4. 难以定位延迟或内存使用方面的异常值

解决方案设计

方案一：直接扩展 MetricValue 枚举

最直接的解决方案是在 MetricValue 中新增 Distribution 类型：

Distribution {
    name: Cow<'static, str>,
    value: Arc<Mutex<TDigest>>,
}

其中 TDigest 是一种高效的近似分位数计算算法，适合大规模数据流的统计。

方案二：通用自定义指标接口

更灵活的方案是引入通用接口：

Custom {
    name: Cow<'static, str>,
    value: Arc<dyn CustomMetricValue>,
}

trait CustomMetricValue: Debug + Send + Sync {
    fn new_empty() -> Arc<dyn CustomMetricValue>;
    fn aggregate(&self, other: &dyn CustomMetricValue) -> Arc<dyn CustomMetricValue>;
}

这种设计允许用户：

1. 实现复杂的指标聚合逻辑
2. 跟踪带元数据的慢查询
3. 自定义各种分布统计方法

技术实现考量

在实际实现中需要考虑以下关键点：

1. 线程安全：指标收集通常跨线程，需要 Arc 或原子操作保证线程安全

2. 性能开销：分布式统计可能引入额外计算，需要权衡监控粒度和性能影响

3. 序列化支持：分布式场景下指标需要跨节点传输，需实现序列化

4. 内存占用：复杂统计可能消耗较多内存，特别是长期运行的查询

5. 扩展性：系统应支持未来新增统计类型而不破坏兼容性

实际应用场景

增强后的指标系统可以支持：

1. 性能调优：通过 P99/P95 等分位数定位慢操作
2. 资源监控：发现内存/CPU 使用不均衡的分区
3. 异常检测：识别偏离正常范围的执行节点
4. 容量规划：基于历史指标分布进行资源预估

总结

DataFusion 的指标系统扩展不仅解决了当前分布式监控的痛点，更为未来的可观测性需求提供了灵活的基础。通过自定义指标接口，用户可以根据具体场景实现从简单计数到复杂分布统计的各种监控需求，大大增强了系统在复杂环境下的可观测性和可运维性。

这种演进也体现了现代数据处理系统的一个重要趋势：执行引擎不仅要关注查询性能本身，还需要提供丰富的运行时洞察能力，帮助运维人员理解系统行为并快速定位问题。