数美科技的数百TB大数据平台实践：从"1天响应"到“定义即可查”
📌 导语：
大数据平台面临一个根本性矛盾：用于分析的数据字段可（灵活）调整与数据的加工和分析（性能）的矛盾。
Spark查询JSON灵活但慢（数十分钟），ClickHouse查询宽表快（秒级）但Schema固化。每次业务需要新的查询维度，都需要平台团队开发ETL、打平JSON、写入ClickHouse，耗时至少1天。
数美科技每天100亿次风控请求，2PB半结构化日志需要高频即席分析。业务人员发现异常后需要立即多维下钻，但传统架构将"秒级需求"拉长到"天级响应"。
2024年8月起，我们基于云器Lakehouse突破了这个悖论：让JSON半结构化数据具备宽表级查询性能。 最终实现业务人员 "定义即可查" ——定义SQL即可直接在500TB原始JSON上秒级查询，无需ETL、无需等待。
本文分享数美科技的技术实践：
- 如何让数百TB级JSON半结构化数据实现秒级查询
- 如何让业务人员从"提需求等1天"到"定义即可查"
- 云器Lakehouse如何突破"灵活性vs性能"的技术矛盾
一、业务背景与原有架构
1.1 日均百亿次请求：风控场景下的数据挑战
数美科技成立于2015年，专注于为互联网企业提供全栈式业务安全解决方案。凭借先进的AI技术和大数据分析能力，在内容安全、营销反欺诈、账户安全、设备指纹等领域建立了强大的技术壁垒。
目前，数美的服务已覆盖金融、电商、社交、直播、游戏等多个行业，为超过1000家企业提供风控服务，包括工商银行、银联、小红书、爱奇艺等头部企业。每天超过100亿次的请求处理量，不仅体现了数美在行业中的领先地位，也对底层数据架构提出了极为严苛的要求。
1.2 五大系统并存：2PB数据的分散式管理困境
数美的核心业务依赖海量风控数据的实时分析与决策。在2PB级存储规模、每天百TB级增量数据的压力下，我们需要支撑以下四类关键场景：
场景一：原始明细日志的即席查询分析
- 数据特征：JSON格式半结构化日志，10层以上嵌套，上千个字段
- 查询需求：业务人员需要在百TB级单表上进行多维度分析
- 现实困境：受限于Spark查询性能，只能由平台人员针对特定列提取数据，展开打平后写入ClickHouse，业务人员再从ClickHouse查询，一个需求至少需要1天响应时间
场景二：离线加工与特征提取
- 通过HBase进行数据特征提取
- Spark进行T+1批量数据离线加工
场景三：AI训练数据抽样
- 从原始明细日志中抽样数据
- 提供给AI平台进行算法/模型训练
场景四：全文检索
- 通过Elasticsearch进行日志检索及数据提取
- 支持快速定位问题和异常分析
为满足这些场景，我们构建了基于传统Hadoop生态的复杂架构：
（图：数美原有系统架构）
如图所示，五大系统各司其职：Spark负责离线计算、HBase提取特征、ClickHouse支撑即席查询、ES处理日志检索、AI平台进行模型训练。这种架构在业务早期满足了功能需求，但随着数据规模的爆发式增长，弊端逐渐显现。
二、架构矛盾与技术突破
2.1 灵活性与性能的架构矛盾
随着数据规模从TB级向PB级跨越，传统架构陷入"灵活性与性能"的根本性矛盾。
风控业务需要对原始JSON日志进行高频即席分析：今天按user_id分析，明天可能按device_fingerprint分析；查询维度不固定，10层以上嵌套、上千个字段无法预知。但Spark查询JSON虽然灵活，百TB级数据扫描耗时数十分钟；ClickHouse查询宽表虽然秒级，但Schema固化，每次新增字段都需要ETL开发，流程变成：提需求 → 打平JSON → 写入CK → 次日分析。要灵活性就没性能，要性能就没灵活性。
为了平衡这个矛盾，数美科技构建了五套系统各司其职的架构。这带来了连锁问题：数据分散多平台需要来回切换，同一份数据在五个系统各存一份，五套独立集群资源无法共享整体利用率不足30%，五套技术栈和监控体系使运维复杂度居高不下。但这些都是表象，根源在于技术架构无法同时满足灵活性和性能。
2.2 重新定义选型标准
面对架构升级，我们明确了核心诉求：必须让JSON半结构化数据同时具备灵活性和性能。
传统选型思路是"功能拆分"，但业务需要的是"既灵活又快"，而不是"要么灵活要么快"。新平台必须满足：
- 灵活性 ：业务人员直接在原始JSON日志上查询，无需提前定义Schema，无需ETL开发
- 高性能 ：单表500TB的JSON数据，查询性能达到秒级，不逊于ClickHouse宽表
- 降低复杂度 ：能够支撑更多场景，减少多系统架构带来的数据冗余和运维成本
同时考虑：运维简化（全托管服务）、出海支持（多云部署能力）。
2.3 云器Lakehouse的技术突破
经过POC验证，云器Lakehouse的核心能力实现了技术突破：
关键技术：JSON类型优化 + 生成列技术 + 自动索引
- 云器Lakehouse支持原生JSON类型字段，并在存储计算层面做了大量优化
- 对嵌套结构内的key可灵活自定义生成列，SQL操作，追加即可，灵活方便
- 对生成列实现自动索引，实现更好的数据裁剪，提升性能
让JSON半结构化数据同时拥有灵活性和宽表级性能：
- 保持JSON灵活性：业务人员想查哪个字段就查哪个，嵌套10层也能直接访问
- 获得宽表性能：自动索引让查询性能达到秒级
这意味着业务人员定义SQL即可直接在原始JSON上得到结果，无需"提需求 → 等ETL → 次日查询"，平台团队无需针对每个需求开发ETL，真正实现**"定义即可查"**。
其他关键能力：
- 一体化架构：存算分离设计，一份数据支持离线加工、实时分析、全文检索等多场景应用，解决了数据冗余和资源隔离问题。
- 企业级能力：全托管服务降低运维复杂度，7×24小时支持保障稳定性，完整的任务管理、数据血缘、权限管理体系满足企业需求。
2.4 期望达成的目标
基于云器Lakehouse的能力，我们制定了明确目标：
- 核心技术突破：让业务人员直接在500TB原始JSON日志上秒级查询，实现"定义即可查"
- 业务价值目标：需求响应从1天缩短至秒级，业务人员实现分析自闭环
- 架构目标：用一套平台替代Spark + ClickHouse + ES，逐步整合HBase和AI平台数据
- 成本目标：整体存储+计算成本降低50%以上（一体化架构带来的附加收益）
三、实战验证：成本减半、性能翻倍的落地实践
经过3个月的POC验证（2024年8-9月）和分阶段上线，云器Lakehouse在生产环境中稳定运行，各项目标均得到验证。
3.1 从"五套系统"到"一体化平台"：架构演进之路
（图：数美升级后的系统架构图）
升级后的架构实现了根本性变革：
| 维度 | 升级前 | 升级后 |
|---|---|---|
| 存储 | Spark HDFS、HBase、ClickHouse、ES各存一份 | 云器Lakehouse统一存储 |
| 计算 | 5套独立集群，资源隔离 | 统一资源池，弹性调度 |
| 数据分析 | 业务提需求 → 平台提数 → 隔日分析 | 业务人员直接自助查询分析 |
| 平台角色 | 疲于支持"提数"需求 | 专注平台能力建设 |
一体化带来的核心价值：
- 数据只存一份，支持离线加工、实时分析、全文检索、点查等多场景
- 业务人员在同一平台完成所有分析工作，无需跨系统切换
- 平台团队从"需求响应"转向"平台建设"，价值释放
3.2 存储降68%、计算降66%：成本优化的技术密码
整体成本优化成果：
整体存储+计算成本降低50%，具体拆解：
- 存储成本：整体存储size降低68%（原100TB存储，现在只需32TB）
- 离线加工计算：计算资源降低66%
- 实时分析计算：计算资源降低30%
降本增效的技术说明：
| 领域 | 因素 | 细节说明 |
|---|---|---|
| 存储 | • 一体化平台支持离线/实时/分析/检索场景，减少数据冗余存储； | |
| • 同一份数据云器Lakehouse有更高的压缩比； | ||
| • 存算分离带来的资源独立扩展，减少浪费。 | ||
| • Hdfs 两份 + CK 一份 -> 云器Lakehouse 一份； | ||
| • Hdfs 两份 + ES 一份 -〉云器Lakehouse 一份； | ||
| • 整体存储size整体降低68% 左右（降低到原来的32%）； | ||
| • 相对于hdfs单份数据的压缩，也能降低20%-30%的size； | ||
| • 存储在COS上，可单独无限扩展； | ||
| • 基于对象存储，拥有天然的分层存储能力，无需导数据即可实现分层存储。 | ||
| 计算 | • 新一代向量化增量计算引擎，带来更多的数据加工/查询性能的提升，进而实现降本 | |
| • 存算分离带来的资源独立扩展，减少浪费 | ||
| • 相对于开源的Spark任务加工，在数美的业务场景下，性能提升3倍 | ||
| • 相对于Clickhouse，查询性能也提升30%左右，并且复杂关联查询提升更多 | ||
| • 计算资源可独立扩展，解决存算一体模式下，存储扩容需要同时扩容计算，导致计算资源浪费的问题 | ||
| 运维 | • 云器全托管服务，用户只需要关注自己业务就行 | |
| • 为数美独立部署全托管服务，服务运维全在云器侧 | ||
| • 数美驻需要关注业务相关任务即可 | ||
| • 7*24小时服务体系 | ||
| 开发 | • 一体化平台，减少数据导入导出 | |
| • 减少多平台，多任务，多语言开发，降低任务开发门槛，提升开发效率 | ||
| • 数据都在云器Lakehouse内部，无需导出即可满足多场景业务需求，减少导入导出任务开发和资源成本 | ||
| • 云器一套SQL语言支持多场景，代替传统的scala/java/python/sql 等多种语言 | ||
| 长期持续降本能力 | • 平台持续优化带来的持续降本能力 | |
| • 云器Lakehouse每年的性能都会有大量优化； |
◦ 每年30%的资源增长支撑70%的业务增长，核心在平台本身的性能持续优化
• 存储的持续优化：更优的压缩比，更好的存储策略，更优的索引机制等 |
3.3 技术范式突破：JSON半结构化数据的"定义即可查"
这是整个实践中最关键的技术验证——让JSON半结构化数据同时拥有灵活性和宽表级性能。实现业务人员的"定义即可查"，即取消原来ETL开发的过程，变成即时的高性能复杂查询，以支撑业务分析的灵活性。
云器Lakehouse对JSON类型字段的嵌套key实现自动索引，使半结构化数据具备宽表级查询性能。技术对比如下：
| 方案 | 灵活性 | 性能 | 业务流程 |
|---|---|---|---|
| Spark查JSON | ✅ 灵活（想查什么查什么） | ❌ 慢（数十分钟） | 业务无法即时分析 |
| CK宽表 | ❌ 固化（需预定义Schema） | ✅ 快（秒级） | 提需求→ETL开发→次日查询 |
| 云器Lakehouse | ✅ 灵活（原始JSON） | ✅ 快（秒级） | 定义即可查，无需ETL |
这不是妥协，是范式突破 ：业务人员定义SQL查询，直接在原始JSON日志上秒级得到结果，无需等待ETL开发和数据转换，真正实现"发现问题→定义查询→立即分析→快速响应"的敏捷闭环。
3.3.1 单表数百TB级JSON半结构化日志查询分析
测试规模：
- 数据量：数百TB单表数据，千条生产查询SQL
- 查询分布：50%查询1天范围内数据，50%查询3天-1个月范围数据
- 资源配置：16 CRU (128 Core)，1 replica AP集群
性能测试结果：
| 测试场景 | 平均 QPS | 平均响应时间 | 中位数响应时间 | 95%分位数 |
|---|---|---|---|---|
| 单并发（当天查询sql 和其他周期sql 比例 5:5） | 1 | 517ms | 174ms | 1,984ms |
| 多并发（全部为当天查询 SQL ） | 30.8 | 254.6ms | 119ms | 888.8ms |
| 多并发（当天查询 SQL和其他周期查询 SQL比例 8:1 ） | 18 | 410.97ms | 192ms | 1370.8 |
关键发现：
- 中位数响应时间在100-200ms级别，大部分查询实现毫秒级响应
- 95%分位数在1-2秒内，即使复杂查询也能保持秒级性能
- 多并发场景下，系统仍能保持高吞吐（QPS 18-30）和低延迟
这意味着业务人员在数百TB数据上的即席查询，可以获得与传统OLAP数据库（如ClickHouse）相当的性能体验。
3.3.2 替换ES：文本误杀场景的性能验证
业务场景 ： 内容审核中的文本误杀排查，需要批量查询上千个requestId，快速定位误判问题。原先Spark平台计算需要30分钟以上，业务方希望优化到10分钟以内。
云器Lakehouse性能表现：
| 缓存状态 | 执行时间 | 业务满足度 |
|---|---|---|
| 冷启动 (无cache) | 1.4 分钟 | ✅ 满足10分钟要求 |
| 热查询 (有cache) | 2.8秒 | 🚀 秒级响应 |
性能提升分析：
- 冷启动场景下，查询时间从30分钟降至1.4分钟，性能提升20倍， 超出业务预期
- 热查询场景下，直接实现秒级响应
- 这一结果验证了云器Lakehouse可以直接替代ES的检索能力，且性能更优
3.3.3 替换ClickHouse：3个CK实例合并的全面验证
迁移目标 ： 将ae/fp/main三个独立的ClickHouse实例合并到一个云器Lakehouse平台，在降低资源成本的同时，打破数据孤岛，实现跨数据源关联分析。
（图：ClickHouse vs 云器Lakehouse）
数据导入效果：
- 完成ae/fp/main全量数据近实时导入，每天增量数据30+TB（导入前压缩的数据量）
- 数据新鲜度：10分钟内
- 导入后数据单副本Size压缩50%以上
- 导入资源成本可控，支持线性扩展
查询性能对比：
在资源降低40%（对比最大的CK集群）的情况下：
- ae/fp/main数据查询P99性能均保持在秒级别
- 完全满足业务查询要求
- 相对ClickHouse，复杂关联查询性能提升30%以上
四、技术范式突破的价值与经验
4.1 范式突破：消解"灵活性vs性能"的矛盾
传统数据架构存在一个根本性矛盾：要灵活性就牺牲性能（Spark查JSON），要性能就牺牲灵活性（ClickHouse宽表）。所有数据平台都在这个矛盾中做妥协。
云器Lakehouse的技术突破在于：用技术手段消解了这个悖论。
通过对JSON嵌套key的自动索引，让半结构化数据同时拥有：
- JSON的灵活性 ：业务人员想查什么字段就查什么，无需预定义Schema
- 宽表的性能 ：查询性能达到秒级，不逊于传统OLAP数据库
这不是在两者之间找平衡，而是突破了传统架构的技术约束，开辟了新的可能性。
4.2 业务价值：从"天级响应"到"定义即可查"
核心价值 ：让业务人员从"提需求 → 等ETL → 次日分析"变为"定义即可查"
什么是"定义即可查"？
- 业务人员定义SQL查询需求，就能直接在原始JSON上秒级得到结果
- 无需等待平台团队开发ETL、转换数据
- 从"定义"到"查询结果"，中间不再有等待环节
技术层面验证：
- 单表500TB的JSON数据实现秒级查询
- 替代Spark、ClickHouse、ES三套系统
- 存储+计算成本降低50%（一体化架构的附加收益）
业务层面价值：
- 风控异常发现后，可立即定义查询逻辑进行多维分析，响应速度从1天缩短至秒级
- 业务人员无需依赖平台团队"提数"，真正实现分析自闭环
- 平台团队从重复性ETL开发中解放，专注平台能力建设
4.3 打破数据孤岛：提升业务分析便捷性
- 实现跨数据源关联分析 ：3个CK实例合并成一个云器Lakehouse平台，原本需要在三个系统分别查询再手动关联的场景，现在可以直接通过SQL JOIN完成；
- 提升单数据源分析能力 ：ae相关的4张表合并成一张表，简化查询逻辑，保持高性能的同时，提升全量数据完整分析能力；
- 消除数据冗余 ：ae/fp/main数据完成全量接入云器后，HBase/Spark周期任务针对这部分数据无需再存多份，进一步降低存储成本关键成功要素。
4.4 效率提升10倍：让业务人员成为数据分析师
- 分析效率大幅提升 ：业务人员从"提需求 → 等待1天 → 获取数据"变为"直接查询 → 秒级响应 → 即时分析"，分析效率提升10倍以上。
- 平台团队价值转型 ：平台团队从疲于应付各类数据提取需求，转向专注平台能力建设和技术创新。
- 数据价值深度挖掘 ：数据孤岛打破后，业务人员可以更灵活地进行多维度关联分析，发现更多业务洞察。
4.5 关键成功要素
- 抓住核心矛盾 ：深入分析出业务人员无法自助分析、多系统资源隔离、JSON数据查询慢等具体痛点，而非笼统的"系统慢"或"成本高"。
- 找到技术突破点 ：使用真实生产数据，通过3个月POC验证，确认云器Lakehouse的JSON自动索引能力能够解决具体问题。
- 渐进式验证 ：从ClickHouse/Spark到ES/HBase，每一步都用真实生产数据验证技术可行性。
- 深度产品协同 ：与云器团队紧密合作，针对数美场景持续优化，确保技术能力落地。
五、持续演进：从POC到生产，从数据到AI
数美科技与云器的合作始于2024年8月。经过快速的POC验证（8月海外POC，9月国内POC）和分阶段上线，目前ClickHouse和Spark主体任务已切换至云器，并稳定运行9个月以上。
下一步计划：
- ES迁移进行中 ：ES业务正在上生产，随后是HBase相关业务，相关业务会逐步全量切换到云器，真正实现一份存储、多场景应用。
- 打通AI训练全流程 ：AI模型训练的数据源头都在云器Lakehouse，后续将打通AI训练需要的样例提取/存储/管理等端到端流程，提升AI团队算法及模型训练效率。
- 多云战略推进 ：在海外建立统一的大数据平台，支撑全球业务发展。
🎁 体验福利
✅ 新用户赠200元体验代金券
✅ 免费领取《云器Lakehouse技术白皮书》
➤ 即刻通过下方网址体验：
