StarRocks 4.0：FlatJSON，让 JSON 查询像列存一样高效

原创

StarRocks

发布于 2025-11-08 00:38:34

3120

导读：StarRocks 4.0 已正式发布！这一版本带来了多项关键升级。本篇聚焦 JSON 查询性能的系统性提升——通过全新的 FlatJSON 列式存储与执行优化机制，StarRocks 4.0 让 JSON 在实时分析场景中具备接近原生列存的性能。无论是日志、埋点还是 IoT 数据，用户都无需额外 ETL，即可直接对 JSON 进行高性能查询分析，真正让“灵活的数据结构”与“高效的分析能力”兼得。

在实时分析场景中，日志、点击流、埋点、用户画像等数据几乎无处不在。这些数据通常以 JSON 格式存储——它灵活、通用、无需建模，尤其适合快速变化的业务场景：字段可以随时新增或删除，系统之间也能无障碍传输。

正因如此，JSON 成为互联网业务中最常见的数据格式。然而，当这种灵活的数据进入数据库，情况就截然不同了。

在日志分析或行为分析场景中，即便 SQL 写得没问题，查询仍可能迟迟跑不出来。

SELECT 
    get_json_string(event, '$.type') AS event_type,
    COUNT(DISTINCT user_id)
FROM events_log
WHERE 
    get_json_string(event, '$.region') = 'US' AND
    to_datetime(get_json_int(dt, '$.event_ts')) BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY event_type;

这条简单的 SQL 为什么这么慢？因为在数据库眼里，JSON 就是一块黑盒：

存储层需要将每一行的完整 JSON 读入内存；
即便 SQL 只访问其中少数字段，也必须读取整个对象；
过滤条件无法利用索引，只能全表扫描；
基于字符串的计算代价高，无法使用字典编码等优化手段。

看似只是过滤 region='US'、分组 event_type 并做一次去重计数，但执行时间可能长达几十秒。CPU 飙升、延迟高企——这并非 SQL 写得复杂，而是因为 JSON 最初并非为分析而设计的。

当 JSON 成为分析的基础时，它的优势很快就会变成劣势：

存储臃肿：字段名和值反复存储，空间占用大，压缩效果差；
查询开销大：字段读取操作需要遍历和搜索 JSON，CPU 消耗高
Schema 变化快：字段随时增减，历史数据不一致，建模困难；
类型不统一：同一字段在不同记录里类型不同，增加查询复杂度；
字段数量多：单条 JSON 常常包含上百字段，但查询通常只关心少数字段。

数据库的几种应对方案

多年来，工程师一直在尝试各种解决思路，大体可以分为三类：

二进制序列化：典型代表是 PostgreSQL 的 JSONB。这种方式在写入时就解析 JSON 字符串，并将其序列化为二进制格式，以减少查询阶段的字符串解析开销。这类方案能够一定程度上优化性能，但依然不适合 OLAP 场景，StarRocks 的早期版本也采用了类似思路。
用户手工抽取：传统数仓更倾向于让用户在 ETL 阶段手动将 JSON 字段展开成独立列。这种做法能获得接近列存的性能，但代价是维护复杂。在 StarRocks 中，用户也可以通过 Generated Column（生成列）来实现类似能力，比如： ALTER TABLE tbl ADD COLUMN json_event_type STRING AS get_json_string(event, '$.event_type')
自动列化存储：理想的方向是让系统自动识别并抽取常用字段，实现“对用户无感知”的列式化存储。

不过，这种方案的实现极具挑战——系统需要智能地处理异构 schema、 schema 演进等复杂问题。因此，各数据库产品在这一方向的优化深度差异很大。

从 Binary JSON 到接近列存的 JSON

为了解决这些问题，StarRocks 在 2.3 版本支持了 Binary JSON，即以二进制序列化格式来存储 JSON，规避了每次解析字符串的开销，并且搜索字段时能够应用二分查找来降低 CPU 开销。但是即便如此，总体仍然是非常低效，以文首查询为例：

系统无法利用索引过滤，需要读取所有 JSON 数据，带来巨大的 I/O 放大
每一行都要多次 get_json_*，解析 region、 event_type、 user_id
过滤条件 region='US' 需要逐字符比较，CPU 热点函数可能 80-90% 都耗在解析和比较上
聚合阶段又要基于字符串做哈希和去重，无法利用字典编码进行优化

哪怕只有几千万行数据，这样的查询依旧可能需要几十秒。

JSON 能力的持续演进

在持续优化 JSON 查询性能的过程中，StarRocks 逐步实现了从“字符串存储”到“列式存储”的演进：

2.3 之前：不支持原生 JSON，仅能以字符串形式存储；
2.3 版本：引入 JSON 类型，采用二进制序列化格式，并补充丰富的 JSON 查询函数；
3.3 版本：推出 FlatJSON 列式存储，自动将 JSON 中的高频字段列化，使存储层性能首次接近列存；
4.0 版本：在执行层加入 索引、全局字典、延迟物化 等优化，使 JSON 查询性能接近原生列存字段。

性能差异直观对比

在深入技术细节之前，可以先直观感受不同方案带来的性能差异。以文首相同的查询为例，不同版本的 JSON 实现具有显著的性能差异：

接下来，本文将从技术原理角度展开介绍 FlatJSON 如何实现“既灵活又高效”的存储与查询能力。

FlatJSON 列式存储

要理解 FlatJSON 的设计原理，首先需要回顾 StarRocks 的基础存储结构：

Segment 是 StarRocks 的最小文件存储单元，通常大小约为 1GB，每次导入数据至少会生成一个 Segment 文件；
Segment 采用列式存储格式，每个列（Column）独立存储为多个 Page，Page 层面支持 Encoding + Compression；
Segment 内部支持多种索引：默认会创建轻量级索引（如 ZoneMap、SortKey Index），同时支持按需构建复杂索引（如 Bitmap Index、Bloomfilter Index）；
数据在写入时会根据用户指定的 ORDER BY 进行排序。

基于这一架构，FlatJSON 在数据导入阶段进行列化存储：

扫描 JSON 键集合，统计字段频率，识别出“热字段”（例如每条记录都包含 "region" 字段）；
自动推断字段类型——能以数值存储的字段绝不存为字符串，对于多类型字段选择可兼容的公共类型；
将识别出的字段单独存储为列式格式（如 INT、STRING、DOUBLE 等）；
对低频或不固定字段，统一写入一个“冗余列”，以 JSON 类型存储，作为兜底方案。

经过这一过程，原本需要层层解析的 JSON 数据，在物理存储上被转化为一张“半结构化表”。

在 Segment 文件内部，这些字段已经与普通列无异——可被按需读取，也能创建索引。

为什么 FlatJSON 更快？

列存压缩更高效：低基数字段（如 region）可使用字典编码，减少存储空间；
消除冗余存储：无需重复存储 JSON key；
I/O 成本更低：查询只需读取被列化的字段；
免解析执行：查询阶段不再解析 JSON 字符串，直接读取 Segment 文件中的列数据

SELECT 
    get_json_string(event, '$.type') AS event_type,
    COUNT(DISTINCT user_id)
FROM events_log
WHERE 
  to_datetime(get_json_int(dt, '$.event_ts')) 
    BETWEEN '2024-01-01' AND '2024-12-31'
  AND get_json_string(event, '$.region') = 'US'
GROUP BY event_type;

回到文首的示例查询：

存储引擎只需读取 $.type、$.event_ts、$.region 这几个被列化的字段，无需再加载完整的 JSON 数据；
对于表达式 get_json_string(event, '$.type')，系统不再解析 JSON 字符串，而是直接读取 Segment 文件中的对应列。

得益于这种列式化设计，JSON 性能有了质的飞跃！

FlatJSON 列式查询

在存储实现列化之后，执行层的优化同样关键。以下将介绍 FlatJSON 在执行阶段的四项核心技术，以及它们如何进一步提升查询性能。

索引（Index）：把大海捞针变成定向查找

为避免全表扫描，FlatJSON 支持在已列化字段（如 region、event_time、event_type）上创建合适的索引，例如 ZoneMap。ZoneMap 会记录每个 Page 的最小值和最大值，在查询时可据此快速判断哪些 Page 可能命中过滤条件，从而跳过无关数据。

性能提升的核心来自于扫描量的降低：

通过利用过滤条件的选择度，系统可以直接跳过无关的数据块，将 I/O 成本从“全表扫描”降至“部分数据读取”。这种方式在谓词选择度较高的场景（例如 region='US' AND dt BETWEEN ...）中效果最为显著；当分区键或排序键与查询条件对齐时，收益会进一步提升。
若查询条件选择度较低，或使用模糊匹配（如 LIKE '%xx'），索引过滤的效果会受到限制。
但在多数典型分析场景中，通过 ZoneMap 过滤，I/O 开销仍能减少一个数量级，从而显著提升整体查询性能。

高效解码（Dictionary Decoding）

对于低基数字符串字段，Segment 在写入时会自动进行字典编码。以 region 字段为例，系统会将其拆分为两部分存储：字典和字典码，从而消除重复字符串。

在查询执行阶段，StarRocks 会对字典编码数据进行谓词改写：例如 region='US' 会被改写为 region=1，然后利用索引直接过滤对应的数据块。这种方式避免了频繁的字符串比较，计算更轻量，内存与 I/O 效率均明显提升。

在完成过滤后，系统再将字典码翻译回实际字符串，用于计算。

延迟物化（Late Materialization）

在传统的执行路径中，数据库通常会在过滤之前就将整行数据解码。这意味着，即使最终被过滤掉的记录，也已经付出了完整的解析与对象创建成本。

延迟物化的思路正好相反：在初始阶段仅使用轻量级的数据结构（例如行号）来表示记录，在完成所有过滤操作之后，再根据筛选结果去读取真正需要的列。以 region='US' 为例，StarRocks 会先读取并过滤 region 字段，仅记录满足条件的行号。随后再按照这些行号读取 user_id 字段，从而避免无谓的数据加载。

延迟物化的核心在于延后不必要的计算与解码：它减少了 I/O 读量，提高了缓存命中率，并让 CPU 资源集中用于真正需要的数据。

因此，在低选择度的查询中，这一机制能显著降低无效计算成本。

全局字典（Global Dictionary）：把字符串降维成整数计算

在 StarRocks 中，字符串一直是影响查询性能的关键因素。无论是过滤还是聚合，都需要进行逐字符比较或字符串哈希，不仅消耗大量 CPU，还容易破坏缓存局部性。为此，StarRocks 在 Segment 局部字典的基础上引入了 全局字典，通过汇总各节点的局部字典，构建出统一的全局映射表。

有了全局字典，字典编码的使用范围不再局限于单个 Segment，而可扩展到 聚合、排序、关联等计算场景。原本昂贵的字符串运算被“降维”为整数运算：CPU 只需执行轻量的整型比较或哈希操作，缓存命中率显著提升，哈希表也更紧凑、更高效，聚合时的冲突率大幅降低。

例如，原本的 GROUP BY region 操作需要在哈希表中频繁进行字符串查找和更新；使用全局字典后，执行计划可改写为 GROUP BY region_code，以整数完成聚合，仅在最终输出阶段再将整数解码为字符串，从而显著减少计算开销。

小结对比

回到文首的示例，可以直观看出两种执行方式的差异：

传统 JSON 查询：读取完整 JSON → 路径解析 → 类型转换 → 执行过滤与聚合；
FlatJSON 查询：直接命中列存字段 → 索引与字典过滤 → 全局字典计算 → 延迟解码。

相比传统方式，FlatJSON 在执行路径上大幅减少了解析、比较和全量扫描等开销。

在实际测试中，对 10 亿行 JSON 数据执行相同的聚合查询，传统方式可能耗时约 30 秒，

而基于 FlatJSON 的查询仅需 约 500 毫秒，I/O 与 CPU 成本均降低了数个数量级。

业务场景的真实收益

在真实的业务场景中，FlatJSON 的价值不仅体现在性能提升上，更体现在对灵活性与易用性的平衡。

埋点日志分析

痛点：实时看板需要对最新埋点数据进行聚合和分组，通常涉及数十亿行 JSON。传统模式下，查询需要逐行解析 JSON，返回结果往往需要数十秒甚至更久；同时，埋点字段变化频繁，新字段出现时必须修改 ETL 流程。

FlatJSON 方案：在数据导入阶段，系统会自动将常用字段（如 user_id、event_time、region、event_type 等）拍平成列存格式。新字段出现时，不会影响现有查询，用户仍可通过 JSON 函数直接访问，系统会根据访问频率判断是否列化。

收益：查询延迟从数十秒降至数百毫秒；同时兼容频繁变化的埋点 schema，分析团队无需因字段变更频繁修改表结构或 ETL 流程。

电商报表生成

痛点：电商订单数据通常以 JSON 形式存储，包含 SKU、价格、促销、地域、配送等上百个字段。传统方案依赖复杂的 ETL 流程来抽取字段，开发与维护成本高；当字段新增或类型不一致（例如 price 既可能是字符串也可能是数值）时，整个数据流水线容易出错。

FlatJSON 方案：在导入阶段，FlatJSON 自动识别并列化高频字段，同时保留完整的 Binary JSON 结构。即使 schema 动态变化或字段类型异构，查询仍可正常执行，常用字段的访问性能依旧接近原生列存。

收益：报表生成时间从分钟级缩短至秒级，开发和运维团队无需频繁调整 ETL 流程，分析团队能更快速地响应业务变化。

IoT 实时监控

痛点：IoT 设备上报的数据通常以 JSON 格式存储，包含数十个指标，不同型号设备间的字段差异显著（异构 schema 十分常见）。传统模式下，数据库需要完整解析 JSON；若字段缺失或类型不一致，查询容易退化甚至报错。

FlatJSON 方案：FlatJSON 会在导入阶段自动将高频指标（如温度、湿度等）列化存储，其余字段保留在 Binary JSON 中。查询时系统能自动跳过不存在的字段，避免执行错误；对于类型不一致的字段，执行层可进行统一处理或延迟物化。

收益：支持千万级设备数据的实时聚合，能够在秒级生成监控报表。同时，IoT 场景中的动态与异构 schema 由系统自动处理，显著减少人工清洗和建模成本。

FlatJSON 不仅解决了性能问题，也让动态 schema 与异构 schema 成为可控的系统成本。对开发者而言，不必再因字段新增、缺失或类型不一致而焦虑；对分析师而言，依旧可以通过 SQL 自由查询，而无需担心底层数据结构的频繁变化。

如何使用 FlatJSON

FlatJSON 的启用方式非常简单，使用方法与标准 JSON 类型几乎相同。

-- Minimal table with a JSON column and FlatJSON enabled
CREATE TABLE events_log (
dt DATE,
event_id BIGINT,
event JSON
)
DUPLICATE KEY(`dt`, event_id)
PARTITION BY date_trunc('DAY', dt)
DISTRIBUTED BY HASH(dt, event_id)
PROPERTIES (
"flat_json.enable" = "true", -- enable FlatJSON for this table
"flat_json.null.factor" = "0.3" -- optional: skip extracting too-sparse fields
);

可以通过表属性来开启或关闭 FlatJSON；新导入的 JSON 数据会自动被列化存储。

此外，还可以通过参数 flat_json.null.factor 设置阈值，以避免抽取过于稀疏的字段。

插入几行示例数据

INSERT INTO events_log VALUES
('2025-09-01', 1001, PARSE_JSON('{
"user_id": 12345, "region": "US", "event_type": "click", "ts": 1710000000
}')),
('2025-09-01', 1002, PARSE_JSON('{
"user_id": 54321, "region": "CA", "event_type": "purchase", "ts": 1710000300,
"experiment_flag": "A" -- rare field, remains in JSON fallback
}'));

像平常一样使用 JSON 函数进行查询。

-- Filter + group on fields that FlatJSON likely extracted (high-occurrence)
SELECT
get_json_string(event, '$.event_type') AS event_type,
COUNT(*) AS cnt
FROM events_log
WHERE
get_json_string(event, '$.region') = 'US'
AND get_json_int(event, '$.ts') BETWEEN 1710000000 AND 1710003600
GROUP BY event_type;