1. 这个版本优化到底解决了什么问题1.1 日志场景里的 JSON 数组字段做数仓的人大概率都有过这种经历上游埋点日志为了省事把一个事件的所有上下文全塞进一个大 JSON 字段里其中一定会有个数组字段比如用户浏览商品列表、曝光位、优惠券列表、标签列表。拿一个电商场景举例用户行为日志表里有个event_json字段长这样{ event_type: item_click, item_list: [ {item_id: 123456, price: 19.9, category: 手机}, {item_id: 789012, price: 29.9, category: 配件} ], page: home_feed }这类数据在 Doris 1.0 之前处理起来很头疼。我需要把item_list这个数组拆开变成一行一个商品再跟user_id、event_time关联起来做漏斗分析。当时最原始的做法是用split_part、regexp_extract这类字符串函数去切或者直接在导入链路里用语言写 UDF 处理。结果就是性能差、代码丑、维护成本高而且一遇到数组里有嵌套对象或者字段顺序变化正则就得跟着改。1.1 版本的优化表面上只是多了一组 JSON 数组解析手段但底层把字符串剪切的思路换成了结构化解析 炸裂的思路。这个思路转换才是我觉得真正值得说的东西。这篇文章会把表结构设计、导入设置、查询改写、参数调优四个方向完整过一遍重点是我在真实业务里踩过的坑和压测后的结果不是单纯讲文档里的语法。1.2 优化前用的土办法及其瓶颈我先说说优化前是怎么写的大家可以对号入座。当时最通用的写法是先用regexp_extract把数组整体抓出来再按逗号切分成多行。比如SELECT user_id, split_part(item_str, ,, 1) AS item_info FROM ( SELECT user_id, regexp_extract(event_json, item_list:\\[(.*?)\\], 1) AS item_list_str FROM user_event_log ) t LATERAL VIEW explode_split(item_list_str, ,) tmp AS item_str这套逻辑有三个明显问题。第一JSON 数组里的分隔符不只是逗号数组元素里如果嵌套了对象对象内部也有逗号split_part根本分不清逗号是在哪一层。第二每次查询都要重新做正则匹配和字符串切分CPU 资源全耗在无意义的模式匹配上数据量一大就卡死。第三遇到 JSON 字段里带了转义引号、反斜杠或者数组元素顺序变化正则匹配结果直接错位轻则丢数据重则查出来的字段全部变成 NULL。更坑的是这种写法没办法走任何索引或优化器下推。Doris 对字段的裁剪、过滤、分布式执行只对明确的结构化字段有效。一旦把事件 JSON 当作一个黑盒字符串处理整条查询就退化成全表扫描 逐行正则性能天花板非常低。我优化前跑一个 1000 万行的数组拆解查询要 5 分钟出头优化后只需要 20 多秒差距就是这么来的。2. 优化思路从字符串搬运工到结构化解析2.1 JSONB 与二进制 JSON 的底层差异1.1 版本优化里一个很关键的点是把 JSON 当成字符串处理变成了当成 JSONB 处理。JSONB 是 JSON 的二进制存储格式解析一次之后会变成一种紧凑的结构化表示后续读取字段、遍历数组都不需要再对原始字符串做重复解析。类比一下字符串 JSON 就像一份没编译的源码每次执行都要重新解释一遍JSONB 就像提前编译好的字节码加载完只需要按偏移量去取字段就好。在数仓场景里同一个 JSON 字段往往需要被多个查询反复读取用字符串解析等于每次查询都在重复编译而用 JSONB 可以做到解析一次、后续复用。Doris 1.1 版本里比较实用的做法是在查询时先用解析函数把字符串转成 JSONB例如JSONB_PARSE、TRY_JSONB_PARSE。前者遇到非法 JSON 直接报错后者返回 NULL 并忽略异常。如果整个表导入时就已经是 JSONB 列类型写入时就会完成校验和解析查询时直接取二进制结构效果更明显。我实际测试过同一份数据用字符串函数取数组子字段和用 JSONB 函数取数组子字段单次查询 CPU 时间能差 3 到 5 倍。如果查询里还要炸数组、再做聚合差距会被进一步放大因为炸裂本身就要反复解析数组里的每个元素。2.2 1.1 版本解析函数的选型对比这个版本里常用的 JSON 函数组合我整理了一个选型表大家可以直接对照着用函数输入类型典型用途注意点JSONB_PARSE(string)字符串 JSON把普通字符串转成 JSONB非法 JSON 会报错建议先确认数据质量TRY_JSONB_PARSE(string)字符串 JSON安全解析解析失败返回 NULL适合上游数据不规范的情况JSON_EXTRACT(json, $.path)JSONB / 字符串按 JSONPath 提取子节点返回 JSONB 类型可继续嵌套使用JSON_EXTRACT_STRING(json, $.path)JSONB / 字符串提取子节点并转为 STRING适合取数组元素里的字段值EXPLODE_JSON_ARRAY(json)JSON 数组将数组炸成多行常配合 LATERAL VIEW返回一个临时列JSON_ARRAY_LENGTH(json)JSON 数组返回数组长度可用来过滤超大数组选型逻辑很简单JSONB_PARSE负责把字符串转结构化JSON_EXTRACT负责定位到数组字段EXPLODE_JSON_ARRAY负责把数组炸开。如果数组里的每个元素是一个对象炸开之后还需要再配合JSON_EXTRACT_STRING取具体字段。这套组合逻辑比正则切分可靠得多因为它遵循 JSON 语法规范不会因为逗号层级问题产生歧义。另外Doris 函数名在不同小版本里可能有细微差异比如有些版本里EXPLODE_JSON_ARRAY也叫EXPLODE_JSONB_ARRAY。遇到报函数找不到的时候先用SHOW FUNCTIONS确认一下别写完才发现函数名不对。2.3 如何用 EXPLODE 拆数组而不是拼正则核心的拆数组写法是LATERAL VIEW加EXPLODE_JSON_ARRAY。逻辑上相当于先定位到 JSON 中的数组节点然后把这个数组平铺成一张临时表每一行对应数组里的一个元素。比如SELECT user_id, tmp.item_json FROM user_event_log LATERAL VIEW EXPLODE_JSON_ARRAY( JSON_EXTRACT(JSONB_PARSE(event_json), $.item_list) ) tmp AS item_json这个写法最关键的地方是JSON_EXTRACT已经拿到了数组节点EXPLODE_JSON_ARRAY只需要负责遍历。对比之前正则切分它不需要关心数组里到底嵌套了多少层花括号也不需要处理转义字符因为解析器已经把字符串还原成了真正的数组结构。拆出来的item_json如果是对象继续提取字段时可以这么写SELECT user_id, JSON_EXTRACT_STRING(item_json, $.item_id) AS item_id, JSON_EXTRACT_DOUBLE(item_json, $.price) AS price FROM user_event_log LATERAL VIEW EXPLODE_JSON_ARRAY( JSON_EXTRACT(JSONB_PARSE(event_json), $.item_list) ) tmp AS item_json WHERE event_time 2024-01-01 00:00:00这套写法的优势是每个操作都基于 JSON 语义完全规避了字符串切分的误伤。我在实际业务里用这个写法替换了原先几百行正则逻辑代码量直接减掉一半还多而且查询结果准确率从约 95% 提升到 99.9% 以上剩下的 NULL 基本都是上游原始数据本身缺失或非法。3. 实操表结构设计、加载和查询改写3.1 表结构设计字段存 STRING 还是 JSONB要不要在表结构里直接用 JSONB 列类型取决于使用场景。如果整个表的 JSON 字段数量不多而且每次查询都只取其中一小部分可以在写入时先不转查询时用JSONB_PARSE再转。这样导入链路简单也不会因为某一行 JSON 格式不合法导致整个导入失败。如果表是高频分析的核心表每次查询几乎都要解析 JSON建议导入阶段就落成 JSONB 列。比如把原始event_json经过TRY_JSONB_PARSE后加载进目标表。这样做的收益是解析结果在存储层已经固定查询阶段省去重复解析。代价是对于每条记录导入时需要多做一次解析写入性能会下降一些。我的建议是底层 ODS 表保留原始 STRING方便排查问题和重新处理上层 DWS 或 ADS 表再用 JSONB 落地这时候你已经完成了清洗不需要再担心非法 JSON。这个分层思路在实时和离线链路里都适用千万不要在原始层就把 JSON 结构丢了。3.2 导入阶段的 JSON 解析设置离线导入用 Broker Load 时可以通过jsonpaths参数做字段映射。比如原始日志是一个整体 JSON 对象可以指定要映射到表里的字段LOAD LABEL label_20240101 ( DATA INFILE(hdfs://path/to/log/) INTO TABLE user_event_log COLUMNS TERMINATED BY \t FORMAT AS json jsonpaths [$.user_id, $.event_time, $.event_json] ) WITH BROKER broker_1 PROPERTIES ( strict_mode false );但数组字段本身没法在导入阶段直接平铺到多行。Broker Load 的jsonpaths只能做 JSON 到列的提取不能把一个数组拆成多行。所以常规做法是导入时保留整个 JSON 字符串或者把数组字段先提取成一个 STRING 子列查询时再炸。实时导入走 Routine Load 时同理可以在消费端先做一次JSONB_PARSE然后把解析后的结果写入 Doris但要注意解析失败的脏数据怎么处理别让一条坏消息卡住整个导入任务。这里有个容易踩的坑如果在导入阶段就调JSON_EXTRACT提取数组字段提取结果会变成字符串Doris 不会自动把它识别成数组。后面查询时再用EXPLODE_JSON_ARRAY炸串有时能炸出很多单字符的 [ ] 记录是因为数组被转成了 STRING 后又被当成普通字符串处理了。最稳妥的方案是导入时只做JSONB_PARSE或保留原始 STRING不做任何数组提取把数组解析留到查询端。3.3 查询阶段lateral view explode_json_array 的写法查询阶段我会把它总结成四步过滤、解析、定位、炸裂。过滤要前置先只捞需要的时间范围和用户范围减少参与解析的数据量解析用JSONB_PARSE或TRY_JSONB_PARSE定位用JSON_EXTRACT拿到数组字段炸裂用EXPLODE_JSON_ARRAY配合 LATERAL VIEW。完整示例SELECT user_id, event_time, JSON_EXTRACT_STRING(item_tmp.item_json, $.item_id) AS item_id, JSON_EXTRACT_STRING(item_tmp.item_json, $.category) AS category, JSON_EXTRACT_DOUBLE(item_tmp.item_json, $.price) AS price FROM user_event_log LATERAL VIEW EXPLODE_JSON_ARRAY( JSON_EXTRACT(TRY_JSONB_PARSE(event_json), $.item_list) ) item_tmp AS item_json WHERE event_time 2024-01-01 00:00:00 AND event_time 2024-01-02 00:00:00如果原始 JSON 里item_list字段不存在JSON_EXTRACT返回 NULLEXPLODE_JSON_ARRAY(NULL)不会报错只会不输出任何行。这其实是一个很好用的过滤特性相当于实现了只有包含数组字段的日志才会被展开。但要注意如果你希望不包含数组的记录也保留一行就不能单纯依赖 LATERAL VIEW需要再加一个 UNION 或使用 OUTER 语义否则会丢掉这部分记录。这种写法下优化器能把用户维度、时间维度的条件下推到存储层只有很小比例的数据进入 JSON 解析和炸裂性能提升非常明显。不要写成先全表炸开再 where 过滤那是典型的反面教材。3.4 参数调优并发、内存和超时JSON 数组炸裂本质上是行数膨胀不是每个数据块都均匀地多出 5 行而是某些用户的数据特别多。比如头部用户一次点击事件里挂了 1000 个商品炸完之后这个用户能产生 1000 行而普通用户只有 5 行。这种数据倾斜会直接拖慢整个查询。实际操作中我有两个调优方向。第一个是提高实例并发数让每个 BE 节点上的扫描和计算任务都能铺满SET parallel_fragment_exec_instance_num 16;这个参数在 1.1 版本中很关键。默认值可能只有 4 或 8对于大量 JSON 数组炸裂的任务来说不够用。我压测时把它从 4 调到 16整体耗时下降约 40%。但不是无限调大就好机器 CPU 核数有限调太大会导致任务排队和上下文切换开销反而变慢。一般建议按 BE 节点 CPU 核数的四分之一到二分之一来设置。第二个是内存和超时设置。炸裂后数据量膨胀如果连接的算子没有足够的执行内存会触发落盘甚至报错。可以适当调大查询内存上限SET exec_mem_limit 8G;同时需要关注查询超时时间默认查询超时一般够用但在 1000 万级数据量且有复杂嵌套时建议放宽到 600 秒SET query_timeout 600;还有一个小技巧如果数组字段很大可以先在LATERAL VIEW前用JSON_ARRAY_LENGTH做一次预过滤比如只关心事件里商品数量不超过 100 的记录WHERE JSON_ARRAY_LENGTH(JSON_EXTRACT(TRY_JSONB_PARSE(event_json), $.item_list)) 100这样可以在炸裂前把极端大的数组排除掉避免 OOM 风险。这个预过滤看着多算了一次数组长度但实际执行中由于过滤条件可以提前生效整体开销反而更小。4. 压测与瓶颈定位实录4.1 测试数据和压测环境我先跑了一组对比测试用的是某模拟项目里的用户行为日志数据量约 1000 万行事件 JSON 中数组平均长度在 5 到 10 之间最大数组长度 200。压测环境是 3 个 BE 节点每个节点 16 核 64GB 内存副本数 1关闭查询缓存避免缓存干扰结果。测试 SQL 分别采用两套方案方案 A优化前正则提取数组字符串 split_part切分。方案 B优化后JSONB_PARSEJSON_EXTRACTEXPLODE_JSON_ARRAY。每个查询都跑 3 次取平均值。查询目标是统计每个品类被点击的次数需要把数组里的每个商品拆成独立行再按品类聚合。4.2 优化前后的性能对比数据结果如下表指标方案 A正则切分方案 BJSONB explode提升查询耗时312 秒27 秒约 11.6 倍峰值内存8.2 GB3.4 GB约 2.4 倍扫描行数1000 万1000 万-输出行数6100 万6100 万-结果准确率96.3%99.8%-耗时从 312 秒降到 27 秒最直接的原因不是 JSON 解析本身变快了多少而是原来正则匹配的过程中CPU 用了大量时间在回溯和字符扫描上。JSONB 解析是线性扫描加结构化索引没有回溯开销所以即使总输出行数都是 6100 万整体计算压力也小得多。峰值内存下降是因为方案 A 需要把正则匹配出来的整个字符串临时存起来再切分中间对象非常多方案 B 中数组的每个元素以二进制结构存在内存占用小炸裂时只需要在元素级别创建临时对象。需要注意的是输出行数相同说明两个方案都完成了同样的语义但 3.6% 的结果差异主要来自正则方案在字段错位和转义时丢掉的记录。优化后准确率接近 100%剩下零点几个百分点的 NULL 是原始 JSON 里就没有category字段。4.3 监控中发现的两个隐形瓶颈压测过程中我盯了 BE 节点的监控发现两个容易被忽略的瓶颈。第一个是单节点 CPU 使用率不均。数据是按用户 ID 分桶的但有的用户行为数据特别多事件 JSON 数组也长。炸裂阶段这些大分桶所在的节点 CPU 明显比其他节点高。解决方法是给表重新设计分桶策略或者查询时把并发度调大把大分桶的计算任务再切碎。对于极端倾斜还可以先按数组长度分桶让短数组和长数组分散到不同节点。第二个是网络传输量被低估。炸裂结果集要经过 shuffle 到聚合节点6000 多万行按品类分组中间临时数据非常多。后来我在聚合节点上加了更多本地预聚合减少网络传输的数据量效果立竿见影。具体做法是先用子查询在单节点内完成局部聚合再对外层做最终聚合而不是直接全局聚合。这个经验说明JSON 数组解析优化不只是改一个函数那么简单它是从存储、解析、并发、传输、聚合的全链路优化。少了任何一环性能都会被拖住。5. 常见问题与排查速查表5.1 JSON 解析出来的数组元素变成 NULL这是我在群里被问过最多的问题。现象是EXPLODE_JSON_ARRAY能炸出元素但后面用JSON_EXTRACT_STRING取字段结果全是 NULL。排查路径主要看两点。第一路径大小写是否完全一致。JSON 字段名区分大小写$.ItemList和$.item_list是两个完全不同的路径。第二确认数组里的元素类型。如果数组元素本身是字符串而不是对象比如[item_123, item_456]你取$.item_id当然什么也取不到因为元素没有这个字段。如果用了JSONB_PARSE在解析时就报错说明原始 JSON 里有非法字符比如未闭合的引号、多余的逗号。这时候要用TRY_JSONB_PARSE代替它会返回 NULL 而不是中断整个查询。5.2 数组太大导致 OOM当某个用户的数组长度达到上千甚至上万炸裂后瞬间产生海量行内存很容易被打爆。我之前遇到过一条日志里塞了 5000 个商品详情直接导致一个查询任务失败。处理方案有三个。最简单的是在炸裂前用JSON_ARRAY_LENGTH过滤超长数组比如超过 500 的直接丢弃因为这种极端数据往往会对统计结果产生严重干扰做数据分析时本来就应该剔除。第二个方案是提高exec_mem_limit给足炸裂和聚合阶段的内存空间。第三个方案是调整并行度避免多个超大数组集中在同一个 BE 实例上执行用parallel_fragment_exec_instance_num分散压力。如果业务上确实需要处理超长数组建议不要在即席查询里做而是通过增量导入链路提前把长数组拆成明细表用调度任务分片处理。5.3 数组内对象字段怎么取子字段数组里是对象的情况最普遍取值公式就一句话先炸出元素再按路径从元素里取子字段。不要试图用一个JSON_EXTRACT直接取出所有子字段除非你确定只取某个特定字段。比如数据结构是{item_list: [{item_id: 1, item_info: {category: 手机}}]}想取category可以写成JSON_EXTRACT_STRING( item_json, $.item_info.category )这里item_json是EXPLODE_JSON_ARRAY炸出来的元素嵌套路径用点号连接即可。如果嵌套层级特别深建议先用JSON_EXTRACT把中间对象取出来再用下一步提取避免一次路径写太长维护困难。5.4 查询语法报错怎么办1.1 版本的函数到底有哪些不同构建版本可能有差异。如果执行LATERAL VIEW EXPLODE_JSON_ARRAY报函数不存在先用SHOW FUNCTIONS LIKE %json%看当前版本支持的函数名。我遇到过一次环境里只有EXPLODE_JSONB_ARRAY没有EXPLODE_JSON_ARRAY改个函数名就通过了。另外Doris 的LATERAL VIEW后面不能直接用聚合表达式包裹炸裂结果。如果你要统计炸裂后的总数不要写成SELECT COUNT(EXPLODE_JSON_ARRAY(...))正确做法是先把炸裂结果放到子查询里再外层做 COUNT。这属于 SQL 逻辑问题和版本关系不大但排查时容易被忽略。6. 总结一下我在实战中的体会如果你正在被 JSON 数组字段解析折磨我的建议是直接把正则方案扔掉切换到 JSONB EXPLODE_JSON_ARRAY的组合。这个优化不是 1.1 版本之后才有的唯一路径但绝对是在那个阶段性价比最高的路径。我在实际项目中最大的体会是解析函数选型只解决了 30% 的问题剩下 70% 还是在表结构设计和数据分布上。写入阶段保留干净的结构化字段查询阶段用预过滤挡掉脏数据再用合理的并发度分散炸裂压力这套组合打下来1000 万级别的日志查询从五分钟缩到半分钟以内是很正常的。如果你觉得每次查询都做数组炸裂还是太慢可以考虑在导入阶段就把明细结果落到一张预先拆好的表里。用调度任务把解析 炸裂 行转列做成离线流程查询时直接查明细表。这个方案适合高频报表场景缺点是明细表会膨胀得比较快需要做好生命周期管理。最后再分享一个小技巧上线这类优化前先在 BE 节点上跑几条典型 SQL用EXPLAIN看执行计划确认LATERAL VIEW被正确下推到了扫描阶段而不是在聚合阶段才做炸裂。前者性能非常好后者会先聚合再膨胀内存容易爆。多花五分钟看一下执行计划能省下后面排查问题的半天时间。