如何在Polars分组场景下高效关联另一DataFrame？

背景 #

我有两个Polars DataFrame：

• source_df：每个Key对应大量行（数十万级），结构如下：

┌─────────────┐
| Key | Value |
| --- | ----- |
| k1  | v12   |
| k1  | v12   |
| k1  | v13   |
...
| k2  | v21   |
...

• metadata_df：每个Key仅对应一行，结构如下：

┌─────────────────────────────────────────────────────────────────────┐
| Key | lower_bound | upper_bound | outlier_model_fitted_stat_1 | ... |
| --- | ----------- | ----------- | --------------------------- | --- |
| k1  | lb1         | ub1         | omfs1                       | ... |
| k2  | lb2         | ub2         | omfs2                       | ... |
...

预处理逻辑 #

metadata_df中部分列由用户预设，未预设则为Null，需基于source_df对应Key的Value计算得出。需按以下顺序逐Key执行预处理：

1. 根据metadata_df中用户设定的上下限，将source_df中超出范围的值设为NaN或标记；
2. 推断value_type（以整数/浮点数为主），用户预设值优先；
3. 判断数值是否应转为分类类型（可由用户预设）；
4. 对仍为数值类型的数据拟合自定义异常值检测模型并过滤异常值（不可预设）；
5. 为值拟合归一化模型（不可预设）。

最终目标是更新metadata_df，添加value_type分类项及异常值、归一化模型参数结构体。

当前候选方案 #

由于source_df的行数远多于metadata_df，我希望避免使用apply和UDF以提升性能，目前有四个候选方案：

• 方案1：先执行source_df.join(metadata_df, on='Key')，再通过表达式仅计算未预设列，但会重复metadata_df的数据；
• 方案2：将source_df转置为按Key分列，逐列手动关联metadata_df，但会生成稀疏DataFrame且无法利用并行化；
• 方案3：对source_df分组后用.all()聚合，再关联metadata_df，通过.arr方法处理，但.arr方法有限，可能影响惰性执行/并行化；
• 方案4：将计算拆分为多个分组步骤，提前过滤已预设的Key以避免关联，但会拆分出多个分组操作。

问题 #

1. 是否存在更优的方案？
2. 若无更优方案，哪种方案效率最高？
3. 后续最终预处理需全量关联，当前是否有必要纠结关联方式？
   我现有基于apply和UDF的方案虽比Pandas快，但仍有优化空间，求指点。

方案选型建议 #

优先推荐方案1（关联后批量计算） #

Polars针对大表关联小表做了专门优化，metadata_df作为小表，关联到source_df后虽会重复小表数据，但Polars的列式存储和表达式引擎能高效处理——重复的元数据会被压缩存储，不会带来额外内存压力。

核心优势：

• 完全利用Polars的向量化并行计算能力，所有步骤可通过表达式链式调用，避开UDF的性能瓶颈；
• 逻辑清晰，预处理的依赖顺序（如先过滤上下限再拟合模型）可通过表达式先后顺序自然实现；
• 支持惰性执行，通过.lazy()模式能进一步优化执行计划，减少中间内存占用。

实现思路示例：

# 转为惰性模式提升性能
lazy_source = source_df.lazy()
lazy_metadata = metadata_df.lazy()

# 关联后处理
processed = (
    lazy_source
    .join(lazy_metadata, on='Key')
    # 步骤1：根据上下限过滤值
    .with_columns(
        pl.when(
            (pl.col('Value') < pl.col('lower_bound')) | (pl.col('Value') > pl.col('upper_bound'))
        ).then(pl.lit(None)).otherwise(pl.col('Value')).alias('filtered_Value')
    )
    # 步骤2：推断value_type（优先用预设值）
    .with_columns(
        pl.when(pl.col('value_type').is_not_null())
        .then(pl.col('value_type'))
        .otherwise(pl.col('filtered_Value').dtype().cast(pl.Utf8)).alias('value_type')
    )
    # 后续步骤按逻辑继续用表达式实现...
)

方案4作为补充优化 #

如果metadata_df中预设列的Key占比很高，可以拆分计算：

1. 从metadata_df提取已完成预设的Key集合，过滤出source_df中需要计算的Key子集；
2. 对该子集单独执行分组计算，生成新增的元数据列；
3. 将计算结果合并回metadata_df。

这种方式能减少不必要的关联和计算，但缺点是逻辑拆分后代码复杂度上升，若预设Key占比低，收益不明显。

不推荐方案2和3 #

• 方案2转置生成稀疏表会浪费大量内存，且逐列处理无法利用Polars的并行优化，性能必然最差；
• 方案3用.arr聚合后处理，数组操作的灵活性远不如直接关联后的列式计算，且很多自定义模型的拟合逻辑难以用数组表达式实现，反而会被迫引入UDF，违背初衷。

关于关联方式的纠结 #

后续最终预处理需要全量关联的话，优先直接用方案1的关联模式——提前关联能让所有预处理步骤统一在一个执行计划中，Polars的查询优化器会自动合并冗余操作，比分多次拆分计算的效率更高。没必要为了避免暂时的数据重复而牺牲整体性能。

额外优化点 #

1. 始终用惰性模式（.lazy()）执行，Polars会自动优化执行计划，避免不必要的内存读写；
2. 对于自定义异常值/归一化模型，尽量用Polars的内置表达式组合实现，实在无法避开UDF时，用pl.map_groups()替代apply，map_groups能更好地利用Polars的并行机制；
3. 如果source_df的Value列类型不统一，先提前做类型推断和转换，避免后续计算中出现类型错误。

内容的提问来源于stack exchange，提问作者Matthew McDermott