企业官网建设流程全解析

1. 这不是函数手册，是HIVE实战中真正用得上的“活页备忘录”

你有没有过这样的经历：在写一个临时分析SQL时，突然卡在某个字符串处理环节——明明记得HIVE里有个函数能截取指定分隔符后的部分，但就是想不起名字；或者需要把一列JSON里的某个字段提出来，翻遍文档却找不到对应函数名，最后硬生生用split()+get_json_object()组合凑出结果，还担心性能出问题；又或者在排查数据倾斜时，发现count(distinct)跑得奇慢，临时想换approx_count_distinct，却不确定它和count(distinct)的误差范围到底能不能接受……这些不是理论问题，是每天在数仓开发、BI支持、数据治理一线真实发生的“卡点”。

“HIVE常用函数速查”这六个字背后，根本不是要你背下200个函数签名，而是帮你建立一套快速定位、准确调用、安全落地的函数使用心智模型。我带过的几个团队里，新人上手最快的方式，从来不是通读官方文档，而是直接打开一份按场景组织、带参数说明、有典型陷阱标注、甚至附带执行计划提示的速查表——它不教原理，但告诉你“什么情况下该用谁”“为什么这里不能用nvl()而必须用coalesce()”“lateral view explode()和posexplode()在处理空数组时行为差异有多大”。这份速查，是我过去十年在多个中大型数仓项目中，从血泪教训里抠出来的“最小可用函数集”，覆盖95%以上的日常ETL、报表加工、数据探查场景，所有函数都经过生产环境千万级数据量验证，参数说明全部基于HIVE 3.x（兼容HIVE 2.3+）真实语法，不掺杂任何已废弃或仅限特定引擎（如Spark SQL）的伪函数。

它适合三类人：刚转行做数据开发、还在用select * from table limit 10试错的新手；已经能写复杂SQL、但总在函数选型上犹豫不决、反复查文档的中级工程师；以及需要快速给业务方提供口径解释、临时补救数据异常的数仓运维同学。接下来的内容，没有一句废话，每个函数都配了“一句话定位”“参数详解”“实操示例”“避坑提示”四个模块，连unix_timestamp()这种看似简单的函数，我都标出了时区陷阱和字符串格式强校验的实测经验——因为真正的效率，从来不在写得快，而在改得少。

2. 函数分类逻辑：按“数据流阶段”而非“字母顺序”组织

很多初学者一上来就按A-Z查函数，结果在date_add()和date_sub()之间反复横跳，却忽略了它们本质是同一类时间运算的正负方向变体；或者在concat()、concat_ws()、collect_list()之间纠结，没意识到它们分别服务于“单行拼接”“多值拼接”“聚合拼接”三个完全不同的数据流阶段。我的分类逻辑非常朴素：数据进来之后，会经历哪几个关键处理阶段？每个阶段最常卡在哪？这样分类，你才能在写SQL时，顺着数据流向自然想到该用哪个函数，而不是靠记忆检索。

2.1 数据清洗阶段：解决“脏、乱、空、错”

这是ETL链路的第一道关卡，也是函数误用重灾区。比如业务系统传来的手机号字段，可能混着空格、短横线、括号，甚至“未知”“暂无”这类文本，直接cast(phone as bigint)会报错，但很多人第一反应是写case when层层判断，其实HIVE早有更优雅的解法。

• regexp_replace(string, pattern, replacement)
  一句话定位：用正则表达式批量替换非法字符，比replace()灵活十倍。
  参数详解：string是待处理字段；pattern是Java风格正则（注意HIVE不支持\d，必须写[0-9]）；replacement是替换内容，支持$1引用捕获组。
  实操示例：清洗手机号'138-1234-5678'→'13812345678'：

  select regexp_replace('138-1234-5678', '[^0-9]', '') as cleaned_phone; -- 输出：13812345678

  避坑提示：pattern为空字符串''会导致全字段被清空，务必加where length(trim(string)) > 0前置过滤；另外，正则匹配是贪婪模式，.*后面跟.*会吃掉所有内容，测试时先用select regexp_extract()抽样验证。

• coalesce(T1, T2, ..., TN)
  一句话定位：返回参数列表中第一个非NULL值，是处理NULL的终极安全阀。
  参数详解：支持任意类型，但所有参数必须同类型（HIVE严格检查），否则报错SemanticException.
  实操示例：用户表中phone、mobile、contact三列可能有NULL，取首个有效值：

  select coalesce(phone, mobile, contact, '未留联系方式') as final_contact from user_table;

  避坑提示：nvl(a, b)只能处理两个参数，且当a为''（空字符串）时不会触发替换——coalesce()才是真·NULL处理器；另外，coalesce()在底层会生成CASE WHEN逻辑，若参数过多（>10个），建议拆成子查询提升可读性。

• nullif(a, b)
  一句话定位：当a等于b时返回NULL，否则返回a，专治“伪NULL”（如'N/A'、'NULL'字符串）。
  参数详解：a和b必须同类型，比较是严格相等（=），不进行隐式转换。
  实操示例：将订单状态字段中的'CANCELLED'、'UNKNOWN'统一转为NULL：

  select nullif(nullif(status, 'CANCELLED'), 'UNKNOWN') as clean_status from order_table;

  避坑提示：嵌套nullif()是合法且高效的，比case when status in ('CANCELLED','UNKNOWN') then null else status end少一次扫描；但注意nullif('1', 1)会因类型不匹配报错，字符串和数字必须显式转换。

提示：数据清洗阶段最大的陷阱是“过度清洗”。比如用trim()去空格时，如果业务约定“用户名首尾空格有意义”，强行trim()反而破坏业务语义。我的做法是：先用select count(*) from t where length(name) != length(trim(name))统计影响行数，再和产品确认规则，绝不凭经验下刀。

2.2 字符串处理阶段：解决“拆、拼、提、判”

当数据干净后，核心任务是结构化提取信息。这里最容易犯的错误是“用错工具”：该用get_json_object()提JSON字段，却用split()+array硬拆；该用parse_url()解析URL，却用substr()+instr()手动找位置。函数选错，轻则SQL难维护，重则数据解析错误。

• get_json_object(json_string, path)
  一句话定位：从JSON字符串中精准提取指定路径的值，支持嵌套和数组索引。
  参数详解：json_string必须是合法JSON（双引号包裹，无单引号）；path是JSONPath语法，如$.store.book[0].title，[0]表示第一个元素，[*]表示所有元素（返回JSON数组字符串）。
  实操示例：从日志字段log_json中提取用户ID和设备型号：

  select get_json_object(log_json, '$.user.id') as user_id, get_json_object(log_json, '$.device.model') as device_model from log_table;

  避坑提示：get_json_object()对非法JSON返回NULL，不报错，所以必须加where get_json_object(log_json, '$.user.id') is not null过滤；另外，path中不能有变量，动态路径需用json_tuple()配合lateral view。

• parse_url(url, partToExtract [, key])
  一句话定位：标准URL解析器，比正则更稳定，支持提取协议、域名、路径、参数等。
  参数详解：url是完整URL；partToExtract是提取部分，如'HOST'、'PATH'、'QUERY'；key是当partToExtract='QUERY'时，指定要取的参数名。
  实操示例：分析流量来源，提取UTM参数：

  select parse_url(landing_url, 'HOST') as domain, parse_url(landing_url, 'QUERY', 'utm_source') as utm_source, parse_url(landing_url, 'QUERY', 'utm_medium') as utm_medium from traffic_table;

  避坑提示：parse_url()对非标准URL（如缺协议头http://）返回NULL，生产环境务必先用regexp_like(landing_url, '^https?://')校验；另外，QUERY部分只支持单层键值对，嵌套JSON参数需二次get_json_object()。

• split(string, delimiter)+lateral view explode(array)
  一句话定位：将字符串按分隔符切分为数组，再炸开为多行，是处理“一对多”关系的黄金组合。
  参数详解：split()返回array<string>；explode()将数组每个元素转为一行；lateral view是HIVE特有语法，让explode()结果能与原表字段关联。
  实操示例：用户标签字段tags存为'vip,active,paid'，需展开为每用户每标签一行：

  select user_id, tag_name from user_table lateral view explode(split(tags, ',')) tmp as tag_name;

  避坑提示：split()遇到空字符串''返回['']（含一个空元素），explode()会炸出一行空值，需加where tag_name != ''过滤；另外，posexplode()可同时返回索引和值，用于排序场景。

注意：字符串处理阶段，性能是隐形杀手。get_json_object()在HIVE 3.x中已优化为向量化执行，但regexp_replace()仍走MR模式，大数据量时慎用复杂正则。我的经验是：简单替换（如去空格）用replace()，复杂逻辑（如邮箱校验）提前在ETL上游用Flink/Spark处理，HIVE只做最终拼装。

2.3 时间日期处理阶段：解决“转、算、分、聚”

时间函数是数仓SQL的高频区，也是误差高发区。最典型的误区是混淆“时间戳”和“日期字符串”——unix_timestamp('2023-01-01')默认按yyyy-MM-dd解析，但unix_timestamp('01/01/2023')会因格式不匹配返回0，导致整个分区计算错误。

• unix_timestamp([string [, pattern]])和from_unixtime(unixtime [, pattern])
  一句话定位：双向时间戳转换器，unix_timestamp()将字符串转为秒级时间戳，from_unixtime()反之。
  参数详解：unix_timestamp(string, pattern)中pattern必须是Java SimpleDateFormat格式（如'yyyy-MM-dd HH:mm:ss'），pattern缺失时默认'yyyy-MM-dd HH:mm:ss'；from_unixtime()的pattern同理，缺失时默认'yyyy-MM-dd HH:mm:ss'。
  实操示例：将日志时间'2023-01-01 12:30:45'转为时间戳，再格式化为'20230101'：

  select unix_timestamp('2023-01-01 12:30:45') as ts, from_unixtime(unix_timestamp('2023-01-01 12:30:45'), 'yyyyMMdd') as date_key; -- 输出：1672576245, 20230101

  避坑提示：unix_timestamp()对非法字符串（如'2023-13-01'）返回0，不是NULL！必须用where unix_timestamp(ts_str) > 0过滤；另外，from_unixtime()默认输出UTC时间，若需本地时区（如东八区），需在HIVE配置中设置hive.exec.timezone=Asia/Shanghai，否则所有时间显示慢8小时。

• date_add(start_date, num_days)/date_sub(start_date, num_days)/months_add(start_date, num_months)
  一句话定位：日期加减运算，date_add/sub按天，months_add按月（自动处理月末逻辑）。
  参数详解：start_date是'yyyy-MM-dd'格式字符串；num_days是整数，可为负；months_add在HIVE 3.1+支持，旧版本用add_months()。
  实操示例：计算用户注册后30天的活跃截止日：

  select date_add(regist_date, 30) as active_deadline from user_table;

  避坑提示：date_add('2023-01-31', 1)返回'2023-02-01'（正确），但date_add('2023-01-31', 30)返回'2023-03-02'（非'2023-03-01'），因为1月31日+30天=3月2日；months_add('2023-01-31', 1)才返回'2023-02-28'（自动取当月最后一天）。

• to_date(string)/year(date)/month(date)/day(date)/hour(string)
  一句话定位：日期字段拆解器，to_date()提取日期部分，year()等提取具体单位。
  参数详解：to_date()输入可以是时间戳或'yyyy-MM-dd HH:mm:ss'字符串，输出'yyyy-MM-dd'；year()等函数输入必须是date或timestamp类型，字符串需先cast()。
  实操示例：按年月统计订单量：

  select year(order_time) as order_year, month(order_time) as order_month, count(*) as order_cnt from order_table group by year(order_time), month(order_time);

  避坑提示：to_date()对'2023-01-01 12:30:45'返回'2023-01-01'，但对'20230101'（无分隔符）返回NULL，必须先from_unixtime(unix_timestamp('20230101', 'yyyyMMdd'))；另外，hour()函数输入是string，但实际解析的是HH:mm:ss格式，'2023-01-01 12:30:45'能正确提取12，'12:30:45'也可以。

实操心得：时间函数最大的坑是“时区漂移”。我在某次大促复盘中发现，凌晨0点的订单量统计少了30%，最后定位到是from_unixtime()在集群不同节点时区不一致。解决方案是：所有时间计算统一用unix_timestamp()转为UTC时间戳，存储和计算全程用bigint，展示时再from_unixtime(ts, 'yyyy-MM-dd HH:mm:ss')，彻底规避时区问题。

2.4 聚合与分析阶段：解决“统、估、排、窗”

这是SQL性能和结果准确性的决战区。新手常犯的错误是滥用count(distinct)导致数据倾斜，或忽略窗口函数的order by必要性，导致row_number()结果随机。

• count(distinct col)vsapprox_count_distinct(col [, relativeSD])
  一句话定位：精确去重计数 vs 近似去重计数，后者用HyperLogLog算法，内存占用低90%。
  参数详解：count(distinct)是精确值，但mapred.reduce.tasks不足时易OOM；approx_count_distinct()第二个参数relativeSD是相对标准差，默认0.015（误差±1.5%），可设为0.03提升速度。
  实操示例：统计日活用户（DAU），百万级UV用近似函数：

  select dt, count(distinct user_id) as dau_exact, approx_count_distinct(user_id, 0.03) as dau_approx from event_log where dt = '2023-01-01' group by dt;

  避坑提示：approx_count_distinct()在HIVE 3.x中已向量化，但count(distinct)在小数据量（<10万）时更快，我的阈值是：UV < 50万用精确，>50万用近似；另外，approx_count_distinct()不支持grouping sets，需单独写。

• row_number() over (partition by ... order by ...)/rank()/dense_rank()
  一句话定位：窗口函数三剑客，row_number严格排序（1,2,3），rank并列跳号（1,1,3），dense_rank并列不跳号（1,1,2）。
  参数详解：partition by是分组依据，order by是排序依据，order by不可省略，否则报错；order by字段必须在select中出现（HIVE严格模式）。
  实操示例：取每个品类销量Top3的商品：

  select * from ( select category, item_name, sales_amt, row_number() over (partition by category order by sales_amt desc) as rn from item_sales ) t where rn <= 3;

  避坑提示：row_number()在数据量大时，order by字段若有NULL，会排在最前（HIVE默认NULLS FIRST），需显式写order by sales_amt desc NULLS LAST；另外，over()中不能用别名，order by sales_amt必须写原字段名。

• collect_set(col)/collect_list(col)
  一句话定位：聚合为去重集合 vs 保留重复列表，是group by后“合并多值”的标配。
  参数详解：collect_set()返回array<type>，自动去重；collect_list()返回array<type>，保留所有值及顺序（按输入行序）。
  实操示例：统计用户购买品类集合：

  select user_id, collect_set(category) as bought_categories from order_detail group by user_id;

  避坑提示：collect_set()和collect_list()在HIVE 3.x中已支持limit（如collect_set(category, 100)取前100个），避免数组过大OOM；另外，collect_set()对NULL值自动过滤，若需保留NULL，用collect_list()+array_distinct()。

常见问题：窗口函数报错FAILED: SemanticException [Error 10004]: Line x:x Invalid table alias or column reference 'xxx'。90%是因为over()里的order by字段没在select列表中，或者用了别名。我的检查清单是：1）确认order by字段存在且类型正确；2）确认该字段在select中是原始字段名，非别名；3）确认partition by字段已group by或在select中。

3. 核心函数实操全流程：从需求到上线的完整闭环

光知道函数怎么用还不够，真实项目里，一个函数从选型到上线，要经历需求确认、SQL编写、性能压测、结果校验、上线发布五个环节。我以“计算用户7日留存率”这个经典需求为例，带你走一遍完整流程，所有步骤均来自某电商数仓的真实迭代记录。

3.1 需求确认：明确口径，避免“函数写对，结果错”

留存率看似简单，但业务方常模糊说“新用户第二天还来就算留存”，没说清楚“新用户”定义（首次下单？首次注册？）、“还来”定义（访问？下单？支付？）、“第二天”是自然日还是24小时。我强制要求：所有指标需求必须书面确认三要素——统计主体、行为事件、时间窗口。

• 统计主体：user_id（去重，排除测试账号）
• 行为事件：event_type = 'pay_success'（支付成功，非下单）
• 时间窗口：“7日”指注册后第7天当天发生支付，非7×24小时

确认后，技术方案明确：需关联user_register表（注册时间regist_ts）和event_log表（事件时间event_ts），计算date_diff(event_ts, regist_ts) = 7的用户数。

3.2 SQL编写：函数选型与组合策略

核心难点是date_diff()函数——HIVE原生不支持，需用datediff()替代，但datediff()只支持date类型，而regist_ts和event_ts是timestamp。方案有二：
A）cast(regist_ts as date)+cast(event_ts as date)→ 简单但丢失小时精度，若用户注册在23:59，支付在次日00:01，datediff()算出为1天，实际是2分钟，错误！
B）unix_timestamp(event_ts) - unix_timestamp(regist_ts)→ 得到秒数，除以86400得天数，再floor()取整 → 精确到秒，但计算开销大。

我选B方案，因为留存率对精度敏感。完整SQL：

-- 步骤1：生成注册用户基础表（去重+过滤） with reg_users as ( select distinct user_id, cast(regist_ts as bigint) as regist_ts -- 转为bigint，避免浮点误差 from user_register where dt >= '2023-01-01' and user_id not rlike '^test_' ), -- 步骤2：生成支付事件表（关联注册时间） pay_events as ( select e.user_id, e.event_ts, r.regist_ts, floor((unix_timestamp(e.event_ts) - unix_timestamp(r.regist_ts)) / 86400) as day_diff from event_log e inner join reg_users r on e.user_id = r.user_id where e.dt >= '2023-01-01' and e.event_type = 'pay_success' ), -- 步骤3：计算7日留存（day_diff = 7） retention_7d as ( select count(distinct user_id) as retained_users, count(distinct case when day_diff = 7 then user_id end) as day7_users from pay_events ) select retained_users, day7_users, round(day7_users * 1.0 / retained_users, 4) as retention_rate from retention_7d;

3.3 性能压测：用explain看懂执行计划

写完SQL不能直接跑，先explain extended看执行计划。关键看三点：
1）Stage Plans中是否有MapReduce任务（MR慢），HIVE 3.x应尽量是Tez或Spark；
2）Map Operator Tree中Filter Operator是否下推到TableScan（减少数据传输）；
3）Group By Operator的Keys是否包含分区字段（利用分区剪枝）。

实测发现：event_log表未按dt分区，where e.dt >= '2023-01-01'无法剪枝，全表扫描。解决方案：联系数据平台组，为event_log添加dt分区，并修改上游采集任务按天写入。压测对比：优化前耗时42分钟，优化后2.3分钟。

3.4 结果校验：三步交叉验证法

上线前必须校验，我用三步法：
第一步：抽样人工核对
取10个user_id，查其regist_ts和event_ts，手算day_diff，确认SQL逻辑无误。
第二步：小数据量全量比对
用dt = '2023-01-01'（单日数据），导出结果与Excel公式计算比对，误差为0。
第三步：历史数据回溯验证
用已知的上周留存率（BI系统已有），跑SQL查相同日期，结果偏差<0.1%，符合预期。

3.5 上线发布：加监控，防故障

上线不是终点，而是开始。我强制要求：

• 所有指标SQL必须加/* retention_7d_v1 */注释，便于追踪版本；
• 在调度系统中配置失败告警（邮件+钉钉），失败时自动重试2次；
• 每日首跑后，自动校验retained_users环比波动，超±10%触发人工核查。

上线首周，监控发现retained_users突降50%，排查发现是user_register表某天数据延迟2小时，dt分区未更新。立即修复上游任务，加max(dt)校验逻辑，问题解决。

实操心得：函数本身没有bug，但组合使用时的边界条件才是雷区。比如floor((unix_timestamp(e.event_ts) - unix_timestamp(r.regist_ts)) / 86400)，若event_ts < regist_ts（数据乱序），结果为负数，case when day_diff = 7会漏掉。我在pay_eventsCTE中加了where e.event_ts >= r.regist_ts过滤，这才是生产代码的成熟度。

4. 高频问题排查与独家避坑技巧实录

在上百个HIVE项目中，我整理出最常被问、最易踩坑的12个问题，每个都附真实场景、错误原因、解决代码和底层原理。这不是文档搬运，是血泪总结。

4.1 问题1：get_json_object()返回NULL，但JSON字符串肉眼可见是合法的

场景：日志字段log_json值为{"user":{"id":"123"},"event":"click"}，select get_json_object(log_json, '$.user.id')却返回NULL。
错误原因：JSON字符串中混入了不可见字符（如BOM头、零宽空格），get_json_object()解析失败。
解决代码：

-- 先用hex()看原始字节 select hex(log_json) from log_table limit 1; -- 若输出以'EFBBBF'开头，说明有UTF-8 BOM头，用translate()清除 select get_json_object(translate(log_json, '\uFEFF', ''), '$.user.id') as user_id;

原理：translate(string, from_chars, to_chars)将from_chars中每个字符替换为to_chars对应位置字符，'\uFEFF'是BOM的Unicode，替换成空字符串即清除。

4.2 问题2：count(distinct)任务OOM，Reduce阶段卡死

场景：统计千万级用户的行为去重，count(distinct user_id)任务在Reduce端内存溢出。
错误原因：count(distinct)在Map端不做聚合，全量数据发往Reduce，单个Reduce需加载所有去重值。
解决代码：

-- 方案1：用approx_count_distinct（推荐） select approx_count_distinct(user_id) as uv from event_log; -- 方案2：两阶段聚合（兼容旧版本） select count(*) as uv from ( select distinct user_id from event_log ) t;

原理：approx_count_distinct()用HyperLogLog算法，内存占用恒定O(1)，而count(distinct)是O(N)；两阶段聚合在Map端先group by user_id，大幅减少Reduce数据量。

4.3 问题3：date_add()计算结果不符合预期，如date_add('2023-01-31', 1)得'2023-02-01'但date_add('2023-01-31', 30)得'2023-03-02'

场景：计算“注册后30天”作为服务有效期，用户1月31日注册，系统显示3月2日到期，用户投诉。
错误原因：date_add()是按“日历日”加减，非“月”概念。1月31日+1天=2月1日，+30天=3月2日（1月31日→2月28日是28天，再+2天=3月2日）。
解决代码：

-- 用months_add()，自动处理月末 select months_add('2023-01-31', 1) as expire_date; -- '2023-02-28' -- 或用add_months()（HIVE 2.x） select add_months('2023-01-31', 1) as expire_date;

原理：months_add()按月历计算，1月31日加1个月，2月无31日，自动取2月最后一天28日。

4.4 问题4：split()后explode()，结果多出空行

场景：tags字段为'vip,active,'（末尾有逗号），lateral view explode(split(tags, ','))炸出'vip'、'active'、''三行。
错误原因：split()对末尾分隔符仍生成空元素，explode()照单全收。
解决代码：

-- 方案1：用array_remove()过滤空字符串 select user_id, tag_name from user_table lateral view explode(array_remove(split(tags, ','), '')) tmp as tag_name; -- 方案2：用regexp_replace()预处理 select user_id, tag_name from user_table lateral view explode(split(regexp_replace(tags, ',+$', ''), ',')) tmp as tag_name;

原理：array_remove(array, value)移除数组中所有等于value的元素；regexp_replace(tags, ',+$', '')用正则删除末尾连续逗号。

4.5 问题5：coalesce()报错SemanticException: Column xxx is of type string but expression 'yyy' is of type bigint

场景：select coalesce(phone, 123456789) from user_table报类型不匹配。
错误原因：coalesce()要求所有参数同类型，phone是string，123456789是bigint，HIVE不自动转换。
解决代码：

-- 显式转换 select coalesce(phone, cast(123456789 as string)) as final_phone from user_table; -- 或用字符串字面量 select coalesce(phone, '123456789') as final_phone from user_table;

原理：HIVE类型检查严格，coalesce()的类型推导取所有参数的公共类型，无公共类型则报错。

4.6 问题6：from_unixtime()输出时间比本地时间慢8小时

场景：select from_unixtime(1672576245)返回'2023-01-01 04:30:45'，但期望是'2023-01-01 12:30:45'。
错误原因：HIVE默认用UTC时区，from_unixtime()将时间戳解释为UTC时间，再转为字符串。
解决代码：

-- 方案1：全局配置（推荐，一劳永逸） -- 在hive-site.xml中添加： -- <property><name>hive.exec.timezone</name><value>Asia/Shanghai</value></property> -- 方案2：会话级设置 set hive.exec.timezone=Asia/Shanghai; select from_unixtime(1672576245); -- 方案3：手动加8小时（不推荐） select from_unixtime(1672576245 + 8*3600);

原理：unix_timestamp()和from_unixtime()是互逆函数，但时区是独立配置项，hive.exec.timezone控制from_unixtime()的输出时区。

4.7 问题7：regexp_extract()提取结果为空，但正则在在线工具中验证通过

场景：select regexp_extract('abc123def', '([0-9]+)', 1)返回空字符串。
错误原因：HIVE的regexp_extract()要求正则必须完全匹配整个字符串，