“

某个疯狂星期四的早上，一位做实时风控的数据工程师小李盯着 SQL 编辑器发了五分钟的呆。

他手上有一张支付流水表，几亿行，实时入库。产品要求他在查询时直接给每笔金额打上风险等级——高、中、低，逻辑不复杂，但有十几条判断规则，还会随业务迭代频繁变更

小李写了半天 SQL CASE WHEN，觉得维护性太差；想用存储过程，发现和下游 Python 模型对接又是一套逻辑。最后他把数据导出来，写了个 Python 脚本跑了一遍，结果发现时效慢了半小时，还要维护两套逻辑链路。

这种割裂感，做过实时分析的人都懂——SQL 擅长查，Python 擅长算，但它俩分处两个世界，数据每次得搬家才能做复杂处理。

这不是小李一个人的问题。

两行代码，Python 进了 Doris SQL

传统分析链路的标准动作是：SQL拉数据 → 导出 → Python 脚本处理 → 结果回写。

这条路走通了，但走远了。

数据从Doris 出去，到 Python 环境跑一圈，再回来，中间每多一跳，就多一处延迟、多一处故障点、多一段调试地狱。

更麻烦的是，进入 AI 分析时代之后，要处理的东西越来越复杂：日志解析、JSON 字段展开、文本打标签、特征加工、模型打分......

这些逻辑放在 SQL 里写，既难写又难维护；放在外部脚本里跑，又和分析主链路脱节。

问题的根本不是 SQL 不行，而是单靠 SQL 这一套，已经覆盖不了现在的业务复杂度了。

Apache Doris 的 Python UDF 想解决的，就是这个撕裂：让 Python 直接进SQL，数据不出门，复杂逻辑就地处理。

先来看最直接的效果。

在 Doris 里，开发者可以这样创建一个 Python 函数：

CREATEFUNCTION py_risk_level(DOUBLE) RETURNSSTRINGPROPERTIES ("type" = "PYTHON_UDF","symbol" = "evaluate","runtime_version" = "3.12.11","always_nullable" = "true","volatility" = "immutable") ASdefevaluate(amount):if amount isNone:returnNoneif amount >= 10000:return"high"if amount >= 1000:return"medium"return"low";

创建之后，这个函数和Doris 内置函数没有任何区别，直接在 SQL 里调用：

SELECT user_id, amount, py_risk_level(amount) AS risk_levelFROM payment_eventsWHERE dt = '2026-07-30';

小李看到这段代码的第一反应是："就这？"

对，就这。

业务规则变了，改Python 函数就行，不用再去维护外部脚本，也不用管数据导出的事。

规则和查询在一个地方，逻辑一目了然，排查问题也少一半的复杂度。

更值得说的是，Python UDF 不只支持标量计算（一行进、一行出），还支持 UDAF 聚合函数（多行进、一行出）和 UDTF 表函数（一行进、多行出）。

三种形态都覆盖了，意味着不管是给单条记录打标签、对一组数据做统计，还是把一个 JSON 数组拆成多行，Python 函数都能接手。

能跑不够，还要跑得快

很多人听到Python UDF第一个疑虑是性能。

这个担忧合理，但 Doris 的实现方式针对这个问题做了专门设计。

核心在于：不是逐行调用，而是批量传输。

Doris BE 在执行过程中，会把输入数据打包成 Arrow RecordBatch 的列式格式，通过 Arrow Flight 协议高效传输给独立的 Python Server，Python 函数对整批数据完成计算后，再以列式格式返回结果。

一次往返处理一批数据，彻底规避了传统逐行调用带来的频繁进程切换和序列化开销。

对于大量的字段转换和特征计算场景，Python UDF 还支持直接声明 Pandas Series 类型，启用向量化计算路径：

import pandas as pddefevaluate(amount: pd.Series) -> pd.Series:return pd.cut(        amount,        bins=[-float("inf"), 100, 1000, 10000, float("inf")],        labels=[0, 1, 2, 3]    ).astype("Int64")

函数入参和返回值都是 Pandas Series，Doris 检测到类型声明后会走向量化执行路径，不再逐元素循环，而是把整列数据交给 Pandas 底层做批量操作。

几亿行数据做分桶打标，这条路比Python 循环快不是一星半点。

有人可能会问：Python Server挂掉了怎么办？业务查询会不会跟着挂？

Doris 的设计里对这件事做了明确的隔离和自愈机制。

Python UDF 运行在独立进程中，挂了Doris BE 会自动重启，不影响主查询链路；同一个函数的多次调用会复用 Python 进程，不用每次都重新拉起环境；进程的生命周期和资源使用由 Doris 统一管理，业务开发者感知不到底层的这些细节，用起来仍然是一次普通的 SQL 调用。

这对生产环境来说很重要。

能跑起来只是第一步，能稳定跑、能恢复、能隔离，才是进生产的门槛。

从风控到 AI 打分，实际能用在哪

说了这么多机制，回到最现实的问题：业务里能用在哪？

风控是最直接的场景。

规则引擎往往有几十条判断逻辑，条件嵌套深、更新频率高，SQL CASE WHEN 写到第十条就开始怀疑人生。

用 Python UDF 封装规则逻辑，更新规则只需修改函数，不影响查询结构，也不需要重新发布下游服务。

JSON 和日志解析是另一类高频需求。

日志数据进Doris 之后，往往需要从原始字段里解析出结构化信息，复杂的嵌套结构用 SQL JSON 函数处理起来非常受限，用 Python UDF 调用 json 标准库或者 jsonpath 工具就自然很多。

对于在数据平台里做特征工程的团队，Python UDF 可以把原来散落在 Spark任务或 Python 脚本里的特征加工逻辑，直接内嵌到 Doris 查询中。不需要另起一套处理流程，特征计算和数据查询在一个链路完成，链路短了，时效自然就提上来了。

最有想象空间的是 AI 分析场景。

把训练好的轻量模型（比如 sklearn 或者ONNX 格式的分类模型）打包成 ZIP，通过 Doris Python UDF 的模块加载方式注册为函数，就能在 SQL 查询中直接调用模型推理。

数据进库，模型打分，结果返回，全在一次查询里完成，不需要把数据导出给推理服务再等结果回来。

顺便说一下模块化加载这个能力。

对于复杂的 Python 函数，Doris 支持把代码打成 ZIP 包上传，通过 file 和 symbol 参数指定模块入口：

CREATEFUNCTION py_model_score(DOUBLE) RETURNSSTRINGPROPERTIES ("type" = "PYTHON_UDF","file" = "file:///opt/doris/udf/risk_model.zip","symbol" = "risk_model.predict","runtime_version" = "3.10.12","volatility" = "immutable");

这对团队协作更友好——代码在版本控制里管理，评审、测试、发布走正规流程，不会因为有人临时改了内联代码而埋下隐患。

结语

数据分析正在变复杂，不是因为数据变多了，而是要从数据里得到的东西变多了。

统计归统计，规则判断归规则判断，模型打分归模型打分，这些原本分散在不同工具和脚本里的逻辑，正在被要求越来越紧密地协同。

Doris Python UDF 做的事，本质上是把这条链路拉短：让开发者在不拆分分析流程的前提下，把Python 生态的灵活性带进SQL 查询。数据留在 Doris，逻辑也留在 Doris，不再为了用 Python 而多维护一条并联的链路。

小李用 Python UDF 重写了他的风控逻辑，上线那天发现时效从半小时回到了秒级，运维同事也不用再盯着那个每天跑一次的 Python 脚本了。

他说了一句话，我觉得说到点上了："以前是 SQL 管查，Python 管算，现在终于不用两边跑了。"

对于想在生产环境稳定使用这一能力的团队，SelectDB 商业化产品也已将 Python UDF/UDAF/UDTF 纳入支持范围，在社区版基础上提供更完整的运维保障、安全合规和技术支持体系。

技术的进步，有时候不是发明了什么新东西，而是把两件原本分开的事，以一种合理的方式连起来了。