UDF
UDF 是用户定义函数，在 Spark SQL 或 DataFrame 中注册以扩展内置函数能力，通常用 Python、Scala 或 Java 编写，对每行输入返回输出值，但无法被 Catalyst 优化器深入优化。
时间轴 (近 90 天)
UDF 之外的开销可能吃掉 GPU 加速收益：数据在 CPU 与 GPU 之间来回传输的代价很高，如果一段 GPU UDF 前后夹着频繁 fallback 到 CPU 的算子，整体反而变慢，因此迁移应以整条算子链为单元评估，而不是单点替换。
不适合 GPU 迁移的 UDF 包括：含大量分支跳转、依赖 Python 对象逐行操作、或需要外部网络调用的 UDF，这类逻辑搬到 GPU 上往往收益有限甚至引入额外拷贝开销。
CPU 与 GPU 实现即使逻辑一致，也可能在浮点累加顺序、空值（NaN/Null）传播、整数溢出和时区转换上产生差异，因此 Agent 生成的候选实现必须通过与原始 UDF 的样本比对来验证，验收时应用相对误差或绝对误差阈值而非严格相等。
Spark UDF（User Defined Function）是用户在 Spark SQL 或 DataFrame API 中注册的自定义函数，通常用 Python（PySpark）或 Scala/Java 编写，对每一行输入返回一个输出值。
Spark 的 Catalyst 优化器无法穿透 UDF 内部做算子下推或向量化，且 Python UDF 需要 JVM 与 Python 进程之间序列化传参，逐行调用开销显著。
RAPIDS Accelerator for Apache Spark 遇到自定义 UDF 时无法自动翻译，需开发者或 Agent 提供 GPU 可执行的等价实现。
适合 GPU 迁移的 UDF 典型形态包括：向量化的数值计算、字符串匹配与正则、时间戳运算、以及可在列上批量执行的标量函数。
UDF 方案在将数百万条日志记录与数千条 CIDR 规则关联时性能瓶颈突出，因为每行数据都要经历 JVM 或 Python 解释器的调用开销
过去在 SQL 中分析 IP 数据的常见做法是用正则表达式、编写自定义 UDF 或依赖位运算，这些方案难以维护且易出错
全部知识事实 (9)
UDF 之外的开销可能吃掉 GPU 加速收益：数据在 CPU 与 GPU 之间来回传输的代价很高，如果一段 GPU UDF 前后夹着频繁 fallback 到 CPU 的算子，整体反而变慢，因此迁移应以整条算子链为单元评估，而不是单点替换。
50%待验证不适合 GPU 迁移的 UDF 包括：含大量分支跳转、依赖 Python 对象逐行操作、或需要外部网络调用的 UDF，这类逻辑搬到 GPU 上往往收益有限甚至引入额外拷贝开销。
50%待验证CPU 与 GPU 实现即使逻辑一致，也可能在浮点累加顺序、空值（NaN/Null）传播、整数溢出和时区转换上产生差异，因此 Agent 生成的候选实现必须通过与原始 UDF 的样本比对来验证，验收时应用相对误差或绝对误差阈值而非严格相等。
50%待验证Spark UDF（User Defined Function）是用户在 Spark SQL 或 DataFrame API 中注册的自定义函数，通常用 Python（PySpark）或 Scala/Java 编写，对每一行输入返回一个输出值。
50%待验证Spark 的 Catalyst 优化器无法穿透 UDF 内部做算子下推或向量化，且 Python UDF 需要 JVM 与 Python 进程之间序列化传参，逐行调用开销显著。
50%待验证RAPIDS Accelerator for Apache Spark 遇到自定义 UDF 时无法自动翻译，需开发者或 Agent 提供 GPU 可执行的等价实现。
50%待验证适合 GPU 迁移的 UDF 典型形态包括：向量化的数值计算、字符串匹配与正则、时间戳运算、以及可在列上批量执行的标量函数。
50%待验证UDF 方案在将数百万条日志记录与数千条 CIDR 规则关联时性能瓶颈突出，因为每行数据都要经历 JVM 或 Python 解释器的调用开销
50%待验证过去在 SQL 中分析 IP 数据的常见做法是用正则表达式、编写自定义 UDF 或依赖位运算，这些方案难以维护且易出错
50%