BugEnigma上个月我帮同事排查一个数据任务，user_id 字段莫名其妙变成 NULL，他在群里发了好多日志截图，最后发现是字符串里藏了一个不可见字符。这种问题在大数据开发里几乎天天见，也是为什么我一直觉得，字符串函数不是“一门课里最简单的一节”那么简单。这篇就从我日常写 ETL 的实际经验出发，把大数据场景里最常用的字符串函数逐个拆开讲，落到 Hive 和 Spark SQL 上，最后再补一段 Python UDF 的实战用法。无论你是刚接触数仓、正在学大数据课程，还是准备大数据面试，这一篇都值得认真看。
1. 为什么大数据任务里最先要过的是字符串函数这一关
1.1 一个让字段全部变 NULL 的真实场景
先讲一下开头提到的那个问题。原始日志是从接口服务里落盘的，里面每条记录都有一个 user_id，但抽到 Hive 里做 join 的时候，明明数据源里有值，关联出来的结果却是 NULL。开发小哥最初怀疑是 join 逻辑写错了，检查了半天没发现毛病。后来我把这个字段用 hex() 函数打出来看了一眼，才发现问题：user_id 最前面多了一个 EF BB BF，也就是 UTF-8 的 BOM 字符。
这种字符在文本文件里肉眼看不见，在 Excel 里也看不出来，但一旦进入大数据链路，它会让字符串比较、group by、join 全部失效。更坑的是，常见的 trim() 函数根本处理不了它，因为 trim() 默认只去掉普通 ASCII 空格，也就是 \u0020，而 BOM、不间断空格、零宽空格这些都不在 trim 的清理范围内。最后我们用 regexp_replace 把这些不可见字符替换成空串，问题才解决。
这个案例很小，但它说明了一个核心问题：字符串函数在大数据开发里不是背几个函数名就完事，而是要理解每个函数的行为边界，知道哪些脏数据它处理得了，哪些处理不了。
1.2 字符串函数在大数据开发里的真实定位
大数据领域有一个共识：对数据最基本、最重要的要求就是减少错误、保证质量。但真实世界里的数据，尤其是日志类数据，几乎都是非结构化的字符串。一条日志里可能混合着时间、级别、JSON 主体、IP、设备号，乱七八糟什么都有。要把这些数据变成可分析的结构化表，第一步就是靠字符串函数去做解析和清洗。
在我做过的项目里，字符串函数主要承担三件事：
- 数据清洗：去掉空格、去掉不可见字符、纠正错误的分隔符、统一编码格式。
- 字段标准化：把大小写不统一的值转成统一格式，把日期从多种格式转成标准格式，对手机号、身份证号做脱敏处理。
- 日志解析：从长日志里截取指定片段，按分隔符拆成数组，用正则提取关键字段。
所以你看，字符串函数看似是基础，实际上决定了数仓里最底层 ODS 层的数据质量。ODS 层的数据一旦脏了，后面所有指标、报表、模型全都会被污染。这也是为什么我始终觉得，字符串函数这一节值得花时间好好啃，而不是背几个例子就够了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从 Hive 到 Spark SQL：高频字符串函数的参数与行为拆解
这一部分我把实际开发中使用频率最高的字符串函数按功能分类，逐个讲清楚参数含义、返回值、常见使用姿势。Hive 和 Spark SQL 的语法大部分一致，我会把差异点单独标出来。
2.1 截取与长度：substring、substr、length 的边界陷阱
先看一组最常用的：
sql复制SELECT
substring('2025-04-01 12:33:45', 1, 10) AS date_part, -- 2025-04-01
substr('2025-04-01 12:33:45', 12, 8) AS time_part, -- 12:33:45
length('大数据') AS char_len -- 3
;
substring 和 substr 是同一个函数，不同引擎里互为别名，作用完全一样。第一个参数是字符串，第二个参数是起始位置，第三个参数是截取长度。位置从 1 开始，这一点和 Java、Python 里数组下标从 0 开始完全不同，很多从编程语言转过来的人第一次写 SQL 都会踩这个坑。
还有两个容易忽略的边界行为：
- 如果第二个参数传 0，不会报错，而是返回整个字符串。
- 如果第二个参数传负数，会从字符串尾部开始计算位置。比如
substring('abcde', -2)返回'de'。
length 函数返回的是字符数，不是字节数。对于中文、表情符号这些多字节字符，length 数的是字符个数，而不是 UTF-8 编码下的字节数。如果你需要按字节截断，直接靠 length 和 substring 是不行的，得先做字符集转换或者用其他方式处理。实际业务里绝大多数场景需要的是字符数，所以这个差异通常不会造成问题，但如果你在做文件编码转换类的任务，就要特别小心。
2.2 拼接与格式化：concat、concat_ws、lpad/rpad
拼接字符串在构建业务主键、格式化输出时非常常用：
sql复制SELECT
concat('a', 'b', 'c') AS col1, -- abc
concat('a', NULL, 'c') AS col2, -- NULL
concat_ws('_', 'a', NULL, 'c') AS col3, -- a_c
concat_ws('-', '2025', '04', '01') AS col4 -- 2025-04-01
;
这里最重要的坑是：concat 只要有一个参数是 NULL，整个结果就是 NULL。这在数据清洗时非常危险，因为日志里某个字段经常会有缺值，一旦拼接出来的结果是 NULL，后续判断就会全部走偏。所以我在实际项目里优先推荐 concat_ws，它会跳过 NULL 值继续拼接，不会因为一个字段为空就把整条记录弄丢。
concat_ws 的第一个参数是分隔符。它特别适合用来构造组合业务主键，比如 concat_ws('_', dt, user_id, order_id)，这样生成的字符串可读性好，而且不容易和其他字段串味。
再看补位函数：
sql复制SELECT
lpad('7', 2, '0') AS hour_part, -- 07
rpad('abc', 5, 'x') AS padded -- abcxx
;
lpad 表示在左边补字符到指定长度，rpad 是在右边补。这个在时间字段标准化时非常有用，比如小时字段是 7，你想统一成 07 再拼进分区路径，lpad(hour, 2, '0') 一步搞定。
但 lpad 和 rpad 有一个容易忽略的行为：如果原始字符串已经比目标长度长，它不会保持不变，而是会从尾部截断。比如 lpad('abc', 2, '0') 返回 'ab'。这在处理变长字段时可能会意外丢数据，使用前最好先确认字符串长度分布。
2.3 查找与替换：instr、locate、replace、regexp_replace
定位字符串位置和替换内容，是所有数据清洗任务的核心操作。
sql复制SELECT
instr('hello world', 'world') AS pos1, -- 7
locate('world', 'hello world') AS pos2, -- 7
replace('2025/04/01', '/', '-') AS date1, -- 2025-04-01
regexp_replace('a b', '\\s+', ' ') AS collapsed -- a b
;
先说 instr(str, substr)，它返回子串第一次出现的位置，从 1 开始，找不到返回 0。locate(substr, str, pos) 作用和 instr 类似，但参数顺序是反的，locate 先写要找的子串，再写原始字符串，最后还可以传一个起始搜索位置。这两个函数很容易记混，我建议一个项目里统一只用其中一个，别混着写，不然过两个月回来看代码还得猜意思。
replace 是普通字符串替换，不是正则。它会把所有出现的目标子串都替换掉。regexp_replace 则支持正则表达式，功能强很多，但性能开销也更大。我在项目里的原则是：能用普通 replace 解决的，绝不上正则。比如把日期里的 / 换成 -，这种简单替换用 replace 就够了。
正则替换里最常见的需求是清理空白、去除非数字、脱敏。举几个例子：
sql复制SELECT
regexp_replace(' a b ', '\\s+', '') AS no_space, -- ab
regexp_replace('phone:13812341234', '[^0-9]', '') AS only_num, -- 13812341234
regexp_replace('2025-04-01', '(\\d{4})-(\\d{2})-(\\d{2})', '$3/$2/$1') AS reformat -- 01/04/2025
;
这里必须多说一句转义。Hive 和 Spark SQL 的字符串字面量本身会对反斜杠做一层解析，正则引擎又会做一层解析，所以你在 SQL 里写正则时，反斜杠通常要写两个。比如匹配一个数字，要写 \\d 而不是 \d。很多新手正则写出来没效果，就是因为少写了一个反斜杠。
2.4 拆分与提取：split、regexp_extract
处理日志时，split 和 regexp_extract 是两个大杀器。
sql复制SELECT
split('a,b,c', ',') AS arr1, -- ["a","b","c"]
split('a|b|c', '\\|') AS arr2, -- ["a","b","c"]
regexp_extract('ts=2025-04-01 12:33:45 level=INFO', '(\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2}:\\d{2})', 1) AS ts
;
split 返回一个字符串数组，第一个参数是原始字符串，第二个参数是分隔正则。注意，这里的分隔符也是按正则处理的，所以遇到竖线、点、括号这类正则特殊字符时，必须要转义。比如切分 a|b|c，分隔符要写成 '\\|'，直接写 '|' 会把每个字符都切开。
split 的另一个特点是会把空字符串保留下来。比如 split('a,b,', ',') 返回 ["a","b",""]，末尾那个空字符串不会自动去掉。这在做字段对齐时很容易引发问题，后面讲边界行为时我会专门展开。
regexp_extract 是提取利器。它有三个参数：原始字符串、正则表达式、分组索引。索引从 1 开始，0 表示返回整个匹配到的字符串。比如从日志里提取 IP：
sql复制SELECT regexp_extract('ip=10.20.30.40 user=Tom', 'ip=([0-9.]+)', 1) AS ip;
这里返回 10.20.30.40。分组的力量在于，你可以把一个正则里多个字段同时提取出来，但要注意分组编号千万别数错。正则里每出现一个左括号就是一个分组，括号一多，索引就很容易错位，后面我会专门讲这个坑。
2.5 大小写与空白处理：upper、lower、trim 系列
最后这组函数虽然简单，但在做数据标准化时不可替代。
sql复制SELECT
upper('aBc') AS upper_val, -- ABC
lower('AbC') AS lower_val, -- abc
trim(' abc ') AS trimmed, -- abc
ltrim(' abc') AS left_trim, -- abc
rtrim('abc ') AS right_trim -- abc
;
upper 和 lower 一般用来统一大小写，尤其在 join 的时候，同一个用户的邮箱在 A 表里是全大写，在 B 表里是全小写，直接关联会丢失数据。常见的处理是两边都 lower(trim(col)) 再关联。
trim 系列是去空格的基础函数。但请记住，这里的“空格”默认指普通 ASCII 空格。Tab、换行、全角空格、BOM、不间断空格，这些都不在默认处理范围内。做数据清洗时，如果发现 trim 之后数据表面上看干净了，但 join 还是对不上，多半就是遇到了这类不可见字符。这时就要把 regexp_replace 请出来。
3. 字符串函数里最容易踩的坑：从不可见字符到正则语义
这一节专门讲我在真实项目里踩过、也帮别人排查过的几个典型问题。这些问题不是函数不会用，而是对边界行为理解不够。
3.1 不可见字符与编码差异：为什么 trim“去不掉空格”
前面提过 BOM 字符的问题，这里把它彻底拆开。
一次典型的排查过程是这样的：
- 先查
length(user_id)，发现比预期多 1 或者多 2，但肉眼看不出来。 - 再查
hex(user_id)，看到字符串前面多出EF BB BF或者其他十六进制字节。 - 根据不同的十六进制判断具体是什么不可见字符。
常见的不可见字符有这么几类：
| 字符 | Unicode 编码 | 常见来源 |
|---|---|---|
| 普通空格 | U+0020 | 键盘空格，trim 可处理 |
| 不间断空格 | U+00A0 | 网页复制内容、Word 排版 |
| 零宽空格 | U+200B | 部分系统导入、程序拼接 |
| BOM | U+FEFF | UTF-8 文件头、Csv 导出 |
| 全角空格 | U+3000 | 中文输入法生成 |
处理方式一般用 regexp_replace 把这些字符统一换掉。如果你不知道具体有哪些不可见字符，可以先把所有不可见字符和空白字符都清理掉，比如：
sql复制SELECT
regexp_replace(user_id, '[\\p{Cc}\\p{Cf}\\p{Zs}]', '') AS cleaned_id
FROM raw_table;
这里的 \p{Cc} 是控制字符，\p{Cf} 是格式字符，\p{Zs} 是空格分隔符。这个组合能覆盖大部分空字符、零宽字符和特殊空白。但要注意，\s 并不能覆盖全部，它只包含常见的 [ \t\n\x0B\f\r]，遇到不间断空格和零宽空格时就不管用了。
这种清洗逻辑建议放在 ODS 层的公共清洗模板里，每次数据接入都自动执行一遍，而不是等到业务使用方发现 join 对不上再去补救。数据质量的成本，越靠前修复越低。
3.2 正则函数的贪婪匹配与分组提取问题
正则默认是贪婪匹配的，也就是说，能多匹配就多匹配。这个特性在提取日志字段时经常惹祸。
举个直观的例子：
sql复制SELECT regexp_extract('abcabc', '(.*)b', 1);
很多人以为 (.*)b 会匹配到第一个 b 前面的 a，返回 a。但实际上正则引擎会尽量让 .* 多吞字符，同时还要保证后面跟一个 b，所以它会匹配到最后一个 b，最终返回 abca。
解决方法有两个：
- 使用非贪婪模式，写成
(.*?)b，这样会从最短匹配开始找，返回a。 - 不使用
.*，而是用更精确的字符集，比如([^b]*)b，明确告诉正则引擎不能跨越b。
在处理日志时，我强烈建议多用字符集，少用 .*。比如要从 a=1;b=2;c=3 里提取 a 的值，写 regexp_extract(log, 'a=([^;]+)', 1) 比写 regexp_extract(log, 'a=(.*);', 1) 更可靠。因为 [^;]+ 明确限定了不能包含分号，永远不会越界。
分组索引的问题也很常见。正则里括号一多，索引就容易数错。我自己的习惯是：写复杂的提取正则时，先在本地或者在线正则工具里验证一遍，数清楚每个左括号的分组编号，再贴到 SQL 里。不要靠肉眼硬数，不然很容易出现提取出来的值不对、但又不报错的情况。
3.3 split 与 regexp_extract 的返回结果边界
split 和 regexp_extract 的边界行为，是另一个高频踩坑点。
先看 split：
sql复制SELECT
split('a,b,', ',') AS arr1, -- ["a","b",""]
split(',,a', ',') AS arr2 -- ["","","a"]
;
分隔符在开头和结尾，都会产生空字符串元素。如果切完直接取最后一个元素，比如 split('a,b,', ',')[2]，返回的是空串而不是你想要的 b。这种情况在解析 CSV、管道符日志时经常发生。我通常会在拆完之后用 filter 或者 array_remove 把空串过滤掉