2025-12-09 17:39:55 中华网
在数据爆炸的今天，一个被行业默认的“真理”正在被打破——JSON 数据灵活但慢，这似乎是无法改变的宿命。日志、事件、用户行为数据以指数级速度增长，JSON 作为最主流的半结构化数据格式，虽然能够灵活适应业务变化，但在大规模分析场景中，却长期背负着“性能杀手”的标签。传统方案只有两条路：要么放弃灵活性，提前把 JSON 展平成固定结构的宽表;要么保留灵活性，接受查询缓慢的现实。这道看似无解的选择题，困扰了整个数据行业多年。
云器 Lakehouse 原生 JSON 引擎+生成列+自动索引：重新定义半结构化数据的处理方式
2025 年，云器科技交出了一份让业界意外的答卷。基于自研的 Single-Engine 架构，云器 Lakehouse 通过「原生 JSON 引擎 + 生成列 + 自动索引」技术组合，首次在工业级场景中实现了一个看似不可能的目标——让复杂嵌套的 JSON 数据，获得了与传统宽表几乎相当的查询性能。
这不是简单的性能优化，而是一次范式转变。云器 Lakehouse 的核心创新在于，它能够在湖仓中原生存储 JSON 数据的同时，自动为嵌套字段建立索引。无论数据结构多么复杂、字段如何频繁变化，系统都能自动适配。开发者不需要预定义 schema，不需要编写 ETL 脚本，不需要维护复杂的宽表——一切都在后台自动完成。
用云器科技团队的话说：“我们改变的是处理 JSON 的方式，让数据入湖就能分析。”
从“1 天等待”到“定义即可查”：数美科技的真实战场
数美科技是这场技术革新的首批验证者。作为业务安全与内容风控领域的头部企业，数美科技每天要处理超过 30 亿次风控请求，管理着 2PB 规模的半结构化数据。这些数据大多以 JSON 格式存储，包含数千个不同字段，结构复杂、深度嵌套，且随着业务演进持续变化。
在采用云器Lakehouse 之前，数美科技的数据团队采用业界普遍的Lambda架构数据平台。原有架构需要同时维护 Spark、ClickHouse、Elasticsearch 等多套系统。这套架构对 JSON 数据的处理方式是典型的“展平-固化”模式：Spark 需要将 JSON 的嵌套结构展平成固定的宽表，每个字段都要提前定义好类型和位置。一旦业务需要新增字段或调整数据结构，就必须修改整个数据流程——从 Spark 的 ETL 脚本，到 ClickHouse 的表结构，再到下游所有依赖这些数据的任务，都需要逐一修改和重新部署。整个变更周期往往需要 1 天时间。
更大的问题在于：在风控业务中,数据结构的变化不是偶发事件，而是常态。新的风险特征不断涌现，业务策略持续调整，日志字段频繁增删——每一次变化都意味着一次完整的数据改造工程。对于需要实时响应、快速迭代的风控场景来说，这种"改一处动全身"的架构模式，既制约了业务敏捷性，也消耗了大量工程资源。
数美科技需要的是一个能够拥抱数据变化，而非对抗数据变化的解决方案。
云器Lakehouse 的接入改变了这一切。在数美科技的生产环境中，面对数百 TB 级别的 JSON 日志单表，系统实现了中位数查询响应时间仅 100-200 毫秒，95% 的查询在 1-2 秒内完成。更关键的是，这种性能是在保持 JSON 原生格式、无需任何预处理的前提下实现的。
数美科技的数据负责人这样描述使用体验：“现在我们实现了真正的‘定义即可查’。业务人员想看什么维度，直接写 SQL 就行，几乎是实时返回结果。以前需要提前一天申请的数据需求，现在当场就能完成。”
更值得关注的数字是：整体存储加计算成本下降超过 50%，系统架构从多套异构组件简化为单一平台，运维复杂度大幅降低。
重新定义半结构化数据的可能性
让复杂半结构化数据的实时处理链路，像普通的 SQL 查询一样简单——这是云器这样的新一代增量数据引擎的独特魅力。
在数美科技的案例中，业务人员不需要懂 Spark、不需要理解 ETL、不需要等待数据工程师的排期，只需要像查询普通数据库一样写一条 SQL，就能在数百 TB 的 JSON 数据中秒级获得答案。这种"极简"背后，是云器 Lakehouse 将复杂性下沉到引擎层的系统性设计。
云器科技用一个数百 TB 级的生产案例，向行业展示了数据基础设施创新的另一种可能。当引擎足够智能，它简化的不仅是技术架构的复杂度，更是数据使用的门槛——数据工程师不再需要为每次字段变更重写 ETL 脚本，业务人员不再需要为一个临时分析等待一天，企业不再需要在“灵活应对变化”和“保证查询性能”之间做艰难取舍。灵活与高效的统一，重新定义了半结构化数据的价值边界。
