Databricks Spark SQL是否会执行CASE表达式的所有UDF分支？

我在使用Databricks SQL，有几个用于GeoIP/ISP查询的SQL UDF，每个UDF都通过CASE表达式区分IPv4和IPv6的处理逻辑：

CASE
  WHEN ip_address LIKE '%:%:%' THEN     -- IPv6 path
    ...
  ELSE                                   -- IPv4 path
    inet_aton(ip_address)
END

测试输入全是IPv6，按道理IPv4分支不会执行，但运行以下查询时：

WITH test_ipv6 AS (
  SELECT * FROM VALUES
    ('3FFE:FFFF:7654:FEDA:1245:BA98:3210:4562', 'Example IPv6'),
    ...
)
SELECT
  ip_address,
  get_geo_location(ip_address),
  get_isp_location(ip_address),
  get_geo_country_code(ip_address),
  get_isp_country_code(ip_address)
FROM test_ipv6;

出现错误：

[INVALID_ARRAY_INDEX] The index 4 is out of bounds.

错误来自IPv4专属的辅助UDF inet_aton：

CREATE OR REPLACE FUNCTION inet_aton(ip_addr STRING)
RETURNS BIGINT
DETERMINISTIC
RETURN (
  SELECT
    element_at(regexp_extract_all(ip_addr, '(\\d+)'), 1) * POW(256, 3) +
    element_at(regexp_extract_all(ip_addr, '(\\d+)'), 2) * POW(256, 2) +
    element_at(regexp_extract_all(ip_addr, '(\\d+)'), 3) * POW(256, 1) +
    element_at(regexp_extract_all(ip_addr, '(\\d+)'), 4) * POW(256, 0)
);

这个UDF本不该在IPv6输入时执行，但Databricks似乎还是执行了它。现提出三个疑问：

1. Databricks/Spark SQL是否保证CASE表达式的懒加载？优化器是否会执行未命中分支的表达式？
2. 对于SQL UDF，优化器是否会将UDF体视为完全透明，无视CASE谓词进行折叠/执行？
3. 在SQL UDF中安全区分IPv4与IPv6逻辑是否有官方指引或最佳实践？

1. Databricks/Spark SQL的CASE表达式懒加载机制 #

Spark SQL（包括Databricks SQL）不保证CASE表达式的完全懒加载。优化器可能基于执行计划的优化需求，对CASE分支中的表达式进行提前求值，尤其是当表达式被标记为DETERMINISTIC（确定性）时。即使谓词判断明确不会进入某个分支，优化器也可能在执行计划阶段预计算该分支的表达式，导致未命中分支的代码被执行。

2. SQL UDF与优化器的交互 #

对于标记为DETERMINISTIC的SQL UDF，Spark优化器会将其视为透明的可折叠表达式。也就是说，优化器可能尝试在查询计划的早期阶段计算UDF的值，而忽略CASE表达式的谓词判断。这是因为确定性函数的返回值只依赖输入，优化器会认为提前计算不会改变结果，从而触发UDF的执行——哪怕它本来应该在不满足条件的分支里。你的inet_aton函数标记了DETERMINISTIC，这正是优化器提前执行它的核心原因之一。

3. 在SQL UDF中安全区分IPv4/IPv6的最佳实践 #

方法一：在UDF内部添加类型校验 #

不要依赖外部CASE表达式控制UDF的执行，而是在UDF内部先验证IP类型，再执行对应逻辑。比如修改inet_aton函数，先判断输入是否为IPv4，否则返回NULL：

CREATE OR REPLACE FUNCTION inet_aton(ip_addr STRING)
RETURNS BIGINT
DETERMINISTIC
RETURN (
  SELECT
    CASE WHEN ip_addr RLIKE '^\\d+\\.\\d+\\.\\d+\\.\\d+$' THEN
      element_at(regexp_extract_all(ip_addr, '(\\d+)'), 1) * POW(256, 3) +
      element_at(regexp_extract_all(ip_addr, '(\\d+)'), 2) * POW(256, 2) +
      element_at(regexp_extract_all(ip_addr, '(\\d+)'), 3) * POW(256, 1) +
      element_at(regexp_extract_all(ip_addr, '(\\d+)'), 4) * POW(256, 0)
    ELSE NULL END
);

这样即使UDF被提前执行，也不会因为IPv6输入抛出数组越界错误。

方法二：使用内置IP处理函数 #

Databricks SQL提供了内置的is_ipv4()、is_ipv6()函数，比自定义的LIKE或正则判断更可靠。可以在外部CASE表达式中使用这些函数，或者在UDF内部调用它们：

-- 外部CASE中使用内置函数
CASE
  WHEN is_ipv6(ip_address) THEN     -- IPv6 path
    ...
  WHEN is_ipv4(ip_address) THEN     -- IPv4 path
    inet_aton(ip_address)
  ELSE NULL
END

方法三：移除DETERMINISTIC标记（谨慎使用） #

如果不需要UDF的确定性优化，可以去掉DETERMINISTIC关键字。这样优化器会减少提前求值的操作，更可能遵循CASE表达式的分支逻辑。但这种方法会影响查询性能，因为UDF无法被优化折叠，需要权衡场景使用。

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