摘要：某头部保险公司引入 SelectDB 建设统一 OLAP 底座，支撑百亿级明细查询与复杂分析。上线后，典型查询响应提速 50%，资源峰值下降约 20%，并为统一实时分析与智能化应用奠定基础。
面对保险业务规模持续增长和数字化应用深入一线带来的数据服务挑战，某头部保险公司通过建设以 SelectDB 为核心的统一 OLAP 底座，推动数据分析能力从“多引擎分散承载”向“统一实时服务”演进。
在闪查 Plus 项目中，某头部保险公司实现百亿级保单明细数据的高效查询与实时分析服务。平台生产环境稳定支撑高并发业务访问，并通过 500 并发即席查询、300 并发嵌套复杂 SQL 等高压力场景验证了系统承载能力；典型查询响应时间由 4 秒降低至约 2 秒，生产集群资源峰值下降约 20%。通过实时数据接入、高并发查询和多维分析能力建设，项目不仅提升了业务查询效率，也为后续统一 OLAP 产品化推广和智能分析应用建设奠定了基础。
本文整理自某头部保险公司在相关技术交流中的实践内容，并以项目建设视角呈现统一 OLAP 底座升级过程。
一、业务背景：保险业务增长带来的数据分析新要求
某头部保险公司业务覆盖车险、非车险、核保、理赔、保单、柜面和渠道等多个领域。随着业务规模持续扩大，其数据分析需求正在从传统经营报表逐步向明细化、实时化、自助化方向发展，分析对象也从日报、月报中的汇总指标，下沉至保单、客户、车辆、机构、渠道、理赔过程和核保要素等业务明细。
1.1 数据消费模式的改变
某头部保险公司面对的不只是数据量增长，更是数据消费模式的变化：
从汇总看数到明细运营：分析对象从经营报表逐步下沉至业务过程明细；
从固定报表到自助分析：业务人员需要围绕实际经营问题，自主调整指标、筛选条件和分析维度；
从单一主题到交叉分析：一次业务判断往往需要关联保单、客户、车辆、机构、渠道等多个主题的数据；
从批量取数到在线服务：数据平台开始直接服务业务操作、经营分析和异常排查，查询时效性和稳定性成为业务体验的一部分。
1.2 为什么需要重新审视 OLAP 底座
原有系统分别承担检索、关系型分析和核心数仓等职责，多套系统分工以满足不同类型的分析需求。而随着高并发访问和灵活自助分析需求持续增加，业务更需要一个统一的数据服务入口，承接百亿级明细检索、多维聚合分析、复杂关联查询和实时数据服务。
继续在原有系统上叠加索引、宽表、接口和同步任务，虽然能短期缓解局部压力，但长期会导致数据链路复杂化、资源投入增加以及运维成本提升，也难以持续支撑不断增长的灵活查询和高并发服务需求。
因此，某头部保险公司开始评估统一 OLAP 技术底座：以分布式分析引擎承接实时数据接入、明细检索、多维聚合、多表关联和自助查询，同时保留核心数仓在历史沉淀和离线计算中的职责。
二、闪查项目现状与挑战
闪查项目是某头部保险公司中灵活性要求高、并发压力大的典型查询场景，也是验证统一 OLAP 底座能力的关键试点。项目需要同时支持：
百亿级明细查询：支持保单、核保及相关业务明细的历史查询；
清单式检索：根据保单号、客户、车辆、机构、渠道等条件快速定位明细；
多维聚合分析：按机构、区域、产品、渠道、时间等维度进行统计；
复杂多表关联：关联明细事实与客户、机构、产品、渠道等维度数据；
上百指标自由组合：支持业务人员自助分析，按需选择指标与过滤条件；
实时数据消费：通过 Flink CDC 等链路接入增量数据，缩短数据产生到可查询的时间；
高并发稳定服务：满足生产高峰期查询服务要求，并通过压测验证更高并发下的稳定性。
2.1 原有技术架构
在某头部保险公司的整体数据架构中，GaussDB（DWS） 作为统一的核心分布式数仓底座，全量汇聚并高效支撑了保险、理赔、柜面、渠道等全量业务数据的历史流转。
随着数字化应用逐步深入业务一线，高并发查询和任意维度自助分析需求快速增加，原有数据服务链路开始面临新的压力。
改造前，数据链路由多套系统共同承载：
业务数据源：保险、理赔、柜面、核心系统和渠道等系统提供业务数据；
数据加工层：通过 ETL 工具完成离线抽取、加工和汇聚；
**GaussDB（DWS）：**承担核心数仓、全量历史数据沉淀和离线批处理；
Oracle：承接部分关系型查询和多维分析；
Elasticsearch：承接明细清单、条件检索及部分检索类查询；
应用与分析入口：闪查、自助分析、多维分析和固定报表等需求，分别访问不同的数据服务与查询引擎。
这种架构可以按系统特性覆盖不同负载，但查询能力分散在多个引擎，实时数据、历史数据与查询服务之间存在较多同步和加工环节。
2.2 架构的主要痛点
高并发下资源相互争用：ES、Oracle 和 DWS 分别承接不同查询负载，缺少统一的资源调度；高峰期清单查询、报表和自助分析容易相互争抢资源并出现排队。
多表关联和多维聚合受限：ES 适合部分清单检索，但不擅长复杂关联和多维聚合；Oracle 在大规模、高并发分析下扩展压力较大；DWS 直接承接在线自助查询又可能影响离线计算。
灵活自助查询依赖预加工：原有链路依赖宽表、固定接口和预设索引，新增指标或分析维度通常需要调整加工逻辑，难以快速支持临时分析需求。
实时链路较长且治理复杂：数据需要在消息队列、流处理、检索系统和分析系统之间流转，实时性、一致性和故障排查成本随之上升。
因此，闪查既是业务优先级高的改造场景，也能够完整检验统一 OLAP 引擎在实时接入、复杂查询和高并发服务上的能力。
三、OLAP 选型：SelectDB 与 StarRocks 同口径 POC 验证
自 2024 年起，该公司启动统一 OLAP 底座专项选型工作，团队基于闪查业务真实负载，对 SelectDB 与 StarRocks 开展同口径对比验证，重点关注生产场景下的综合承载能力，而非单条 SQL 的极限执行耗时。
本次选型以生产实际可用性为核心评判标准，重点考察：高并发场景下查询成功率、时延稳定性、实时写入表现、资源治理能力以及运维可控性。
3.1 POC 测试方法
POC 测试严格保持验证条件一致：
相同的数据规模、表结构和查询逻辑；
相同配置的 5 台 128 核 / 512G 物理服务器集群；
对两款产品分别完成部署、数据装载和查询压测；
同时观察平均响应时间、成功率、并发稳定性和资源占用；
将实时写入、复杂 Join、去重明细、全文检索和多条件即席分析纳入验证范围。
3.2 POC 结果与选型结论
本次测试围绕闪查实际业务中最具挑战性的场景展开，包括亿级大表关联、高频去重明细、多条件即席分析和全文检索等。
测试结果表明，面对保险业务场景中“明细查询 + 多维分析 + 高并发访问”的综合需求，OLAP 平台的核心竞争力不仅体现在单次查询速度，更体现在高压力环境下持续稳定服务业务的能力。
基于同等硬件、同等数据规模和同等测试条件，SelectDB 在复杂查询、高并发承载、资源利用效率以及检索融合能力方面表现出更强的生产适配能力。
1、复杂查询性能：支撑业务从固定报表走向灵活分析
在亿级大表关联、嵌套去重、多层子查询、多条件筛选等业务典型复杂 SQL 测试中，SelectDB 在低并发情况下查询时延明显优于 StarRocks。
随着并发压力抬升，StarRocks 在部分复杂查询场景中出现查询失败，无法完成压测（表格以“0%”表示 ），而 SelectDB 仍能够保持较高查询成功率，响应时延增长更加平稳。
2、高并发承载能力：保障业务高峰期间稳定服务
逐级加压测试显示，面对 500 并发即席查询、300 并发嵌套复杂 SQL 等高压力场景，StarRocks 在中高并发出现大量查询失败、任务堆积；
相比之下，SelectDB 在并发持续提升过程中保持稳定查询成功率，集群运行状态更加稳定，不易出现资源竞争导致的服务雪崩。
3、混合负载资源消耗：提升资源利用效率，降低长期建设成本
在真实流量模型开展混合负载压测，在吞吐量、时延、成功率保持同等验收基线的条件下，SelectDB 集群整体资源占用相比 StarRocks 降低 15%，资源调度和内存管控更精细，硬件利用率更高，长期 TCO 更优。
4、原生全文检索：推动多引擎架构向统一分析平台演进
SelectDB 内置倒排索引，支持结构化筛选与文本检索联合查询，可承载保单清单检索场景。而 StarRocks 缺少原生全文检索能力，检索场景必须引入外部组件，增加架构复杂度与运维成本。
相比依赖独立 ES 集群的传统方案，SelectDB 可以减少部分检索链路的数据同步和系统维护工作，推动查询能力向统一 OLAP 平台收敛。
四、闪查改造与上线验证
POC 完成后，闪查项目进入生产改造阶段。
项目目标不是简单替换某一个数据库组件，而是将原来分散在 ES、Oracle 和 DWS 消费侧的明细查询、多维分析和自助分析能力逐步收敛至统一 OLAP 平台—— SelectDB，并通过实时增量接入、双跑校验和灰度发布控制迁移风险。
4.1 迁移实施过程
SQL 与语义适配：梳理历史 SQL、视图、函数、权限和指标口径，完成兼容性适配与回归验证；
历史数据迁移：完成历史明细的全量装载，并校验表级数据量、关键指标和典型查询结果；
实时链路建设：通过 Flink CDC 接入业务增量数据，建立数据延迟、断点续传和一致性校验机制；
双跑验证：保留原有链路，与 SelectDB 并行运行，对比数据结果、查询性能和异常处理情况；
灰度切换：按功能模块、用户范围和流量等级分批切换，持续观察查询成功率、时延和资源使用情况；
回滚保障：在切换窗口保留原链路作为回退路径，确保业务连续性。
4.2 闪查上线效果
完成 SelectDB 上线后，闪查在并发承载能力、查询响应速度、资源利用效率和架构简化等方面取得明显改善。
高并发承载能力提升：生产环境稳定承载业务侧 300+ QPS；同期极限压测达到 500+ QPS；
资源使用更加高效：相比原有链路，生产集群资源峰值整体下降约 20%；
查询响应效率提升：百亿级保单清单及复杂自助分析的典型查询响应时间，由 4 秒降至约 2 秒；在现有线上监控口径下，平台 P99 查询响应控制在 3 秒以内。
架构链路进一步简化：通过统一实时链路，减少了 ES、Oracle、DWS 之间的数据同步和重复加工，降低多系统协同成本。
五、从闪查试点走向统一 OLAP
闪查项目验证了 SelectDB 在生产环境中的综合能力。
自 2024 年完成选型后，某头部保险公司开始将 SelectDB 从单一项目底座逐步推广为统一 OLAP 产品，优先承接实时查询、多维分析、自助查询和高并发数据服务。
5.1 与 DWS 形成职责互补
统一 OLAP 并不意味着替换已有数仓体系，而是在不同负载特点下形成更加清晰的数据服务分工。后续架构按照负载特点进行分工：
DWS：继续承担核心数仓、历史数据沉淀和离线批处理；
SelectDB：面向实时 OLAP、明细服务、高并发自助分析和实时数据消费；
Flink CDC：负责业务数据的实时采集和增量同步；
业务应用与 BI 工具：通过统一 SQL 和数据服务访问 SelectDB。
这种分工减少了系统职责重叠，同时避免由核心数仓直接承接全部在线高并发查询。
5.2 后续演进方向
在统一 OLAP 底座基础上，某头部保险公司未来可进一步探索语义层、指标服务和 AI Agent 数据工具，使业务人员通过自然语言完成指标查询、明细筛选和多维分析。
SelectDB 提供实时、统一、可控的数据查询能力，Flink CDC 缩短业务数据进入分析平台的链路延迟，为智能分析应用提供可靠的数据基础。
六、结语
闪查 Plus 项目的落地，为后续高并发实时分析场景的复制推广奠定了可靠基础。某头部保险公司逐步完成统一 OLAP 底座的升级，也为超大规模数据场景下的高并发自助分析积累了可复制的实践经验。
未来，团队将持续推进更加统一、智能、高性能的实时数据处理能力建设，让数据更快、更稳定地服务经营决策与业务创新。
SelectDB 基于 Apache Doris 构建，为企业提供极速、统一、Agent Native 的数据分析能力，致力于成为智能体时代首选的分析引擎，让数据更高效地服务于 AI 推理、实时决策与业务创新。
