xiaohack's Blog - Apache Doris
type: channel
link: https://blog.xiaohack.org/tag/apache-doris/
items: 快手：从分散存储到统一分析，Apache Doris 在万亿规模广告场景的应用
items: 上市大模型企业数据基础设施的选择：MiniMax 基于阿里云 SelectDB 版，打造全球统一AI可观测中台
items: 构建 AI 数据基座：思必驰基于 Apache Doris 的海量多模态数据集管理实践
items: AI 能力揭秘（五）：Apache Doris 原生向量检索的设计及实现
items: 从 Greenplum 到 Doris：集群缩减 2/3、年省数百万，度小满构建超大规模数据分析平台技术实践

快手：从分散存储到统一分析，Apache Doris 在万亿规模广告场景的应用
type: item
date: 2026-02-02T12:01:30+08:00
description: 导读：面对万亿级广告数据存量、日均 3 亿行增量及数千个复杂查询模板的挑战，快手广告数据平台如何突破性能瓶颈、实现架构统一与体验跃升？本文系统介绍了快手广告团队从 ClickHouse on ES 混合架构，全面迁移至 Apache Doris 的统一分析实践，最终实现查询性能提升 20～90%，写入吞吐提升 3 倍，存储效率提升 60%。本文整理自快手高级计算引擎研发工程师 周思闽 在 Doris Summit 2025 中的演讲内容，并以演讲者第一视角进行叙述。快手是国内日活过亿的短视频平台，其广告投放平台是商业化外部广告主与快手电商商家进行广告投放的主要阵地，支持客户在平台上进行广告物料搭建、物料管理、策略变更、数据查看等操作，这对底层数据系统的存储、计算与查询性能提出了极高要求。要支撑如此大规模的广告投放与实时分析，底层数据架构面临巨大挑战。当前，快手的广告数据包括：由投放系统产生的物料数据以及用于数据分析的效果数据，这些数据呈现出三个显著特征：数据存量巨大：广告物料累计已达千亿级别，且随业务发展正向万亿规模迈进，存储体量位居公司前列，对架构扩展性提出极高要求。数据增长迅猛：仅 2025 年第一季度，日均新增广告物料数据同比激增 3.5 倍，要求底层引擎具备强大的实时写入与弹性扩展能力。数据模型复杂：整个数据体系涵盖约 700 个核心字段，涉及物料、投放、用户、效果等多个维度；同时，为应对多样化分析场景，沉淀的查询模板已超 4000 个，对查询引擎的兼容性与性能均是严峻考验。架构演进：从分散存储到统一分析01 早期架构及挑战早期存储架构中，物料数据由 MySQL、Elasticsearch 协同存储；效果数据主要存储与 Clickhouse 中。数据分析时，将分散在 MySQL、Elasticsearch 中的物料数据与 ClickHouse 中的效果数据进行高效关联查询，从而为广告主提供完整、及时的投放效果洞察。在如上所说的 ClickHouse on ES 架构中，用户提交的查询通常包含 Elasticsearch 外表（a）与 ClickHouse 内表（b）。ClickHouse 会解析查询中外表部分，将其转换为 Elasticsearch 查询语句，通过 HTTP 请求获取数据并封装为 Block，最后在引擎内部完成与内表的关联计算。然而，随着 Elasticsearch 中数据量持续增长，该架构逐渐暴露诸多问题：查询性能恶化：慢查询率上升至 35%，平均查询耗时达到 1.4 秒；存储瓶颈：Elasticsearch 单分片难以支撑 10 亿级以上数据量，扩容与数据重分布成本高；运维复杂度高：数据链路依赖组件多，运维与监控成本显著上升；问题定位困难：缺少 ClickHouse 与 Elasticsearch 之间的全链路可观测手段，出现查询延迟、数据不一致等问题时，需跨系统排查，耗时较长。02 选型目标及调研基于上述问题及挑战，我们为新架构设定了明确目标：慢查询率低于 5%；运维排查耗时降低至分钟级；支持单表万亿级别数据存储；保障数据实时性，延迟低于 5 分钟。基于以上目标，我们对 Apache Doris、ClickHouse、Elasticsearch 等主流 OLAP 引擎进行了全面的调研与性能压测。测试涵盖了写入吞吐、查询延迟、存储压缩率、全文检索性能等关键维度。在这过程中，ClickHouse 首先被排除，因其不支持唯一键模型，而广告物料数据存在大量更新场景，要求引擎具备主键更新能力。因此，重点在 Elasticsearch 与 Apache Doris 之间进行对比。综合测试结果，Apache Doris 在写入性能、查询效率、存储成本及运维复杂度等方面均表现优异，不仅能够满足既定架构目标，还在多个场景下显著优于 Elasticsearch。因此，我们最终选定 Apache Doris 作为下一代广告数据分析引擎。03 基于 Apache Doris 的统一分析引擎在实际应用中，我们引入 Apache Doris（计算引擎） 替换了原先架构中的 Elasticsearch、ClickHouse，设计了统一分析引擎 Bleem。通过在外部表模块中引入数据缓存层与元数据服务层，有效提升了跨源查询效率，使数据湖外表的查询性能接近内表水平，实现了关键的性能突破。具体来看，Bleem 架构自下而上分为 5 层：存储层：数据湖中的 Hive/Hudi 数据存储于 HDFS；存算分离模式下的内表数据存放于对象存储 BlobStore；存算一体模式下的内表数据则存储于本地磁盘。缓存层：将 Hive/Hudi 外部表数据缓存至 Alluxio，保障 I/O 稳定性，提升数据读取效率。计算层：Apache Doris…

上市大模型企业数据基础设施的选择：MiniMax 基于阿里云 SelectDB 版，打造全球统一AI可观测中台
type: item
date: 2026-01-27T12:50:20+08:00
description: MiniMax 全球领先的通用人工智能科技公司。旗下主要有 MiniMax M2.1、Hailuo 2.3、Speech 2.6 和 Music 2.0 等大模型，MiniMax Agent、海螺 AI、星野、Talkie 等产品，以及为企业客户与开发者提供 API 服务的 MiniMax 开放平台。截至目前，MiniMax 已有超过 200 个国家及地区的逾 2.12 亿名个人用户以及超过 100 个国家的企业客户。在技术层面，MiniMax 坚持文本、视频、语音等全模态模型自主研发。目前，其全模态模型已进入国际第一梯队，被业内称为“全球唯四实现这一水平的企业之一”。在推理能力和效率方面，MiniMax 近年来的模型迭代节奏明显加快，在多项国际评测榜单中进入全球前列。相关模型以较低算力成本实现接近国际顶尖闭源模型的性能表现，也在海外开发者社区中获得关注。MiniMax 通过开放平台赋能多个行业，将领先的模型能力以 API 方式提供给企业和开发者。随着模型调用量的指数级增长，训练与推理产生的运行日志数据量也急剧膨胀。 这些日志对于 AI 应用的运行监控、性能优化与问题排查至关重要，因此，选择一款能够支撑高吞吐、易查询、低成本的日志存储与检索引擎，成为保障业务稳定高效运行的关键 。面对海量、实时且不断增长的日志数据处理需求，MiniMax 经过深度评估，最终选择阿里云数据库 SelectDB 版作为其全新可观测性数据平台的核心基座。阿里云数据库 SelectDB 版凭借其更低的成本、更高的查询性能以及更灵活的查询方式在众多产品中脱颖而出。其关键特性精准匹配了现代 AI 业务的严苛要求：云原生存算分离架构：基于对象存储 OSS 的存储层与弹性计算层解耦，支持独立、无损的弹性伸缩，为应对日志洪峰提供了近乎无限的扩展能力。多集群硬隔离与数据共享：支持云原生多集群硬隔离能力，用户可以将单个实例的计算资源划分为多个逻辑集群，不同集群之间的分配独立的计算资源，实现了不同集群的严格物理资源隔离和数据共享。智能缓存加速：通过单副本本地读写缓存、智能数据淘汰策略、高效列式存储格式和先进压缩算法，显著提升了海量数据的读写效率。阿里云数据库 SelectDB 植根于开源 Apache Doris 的坚实基础，深度融合云随需而用的特性，依托阿里云基础设施，构建起云原生存算分离的全新架构，面向企业海量数据的实时分析需求，提供极速实时、湖仓融合统一、简单易用的云上数仓服务。基于阿里云 SelectDB 版，MiniMax 构建了覆盖国内及海外业务的统一日志可观测中台。 以 SelectDB 独立负责所有日志的存储与查询分析，实现了 “一个平台，全球覆盖” 。这彻底终结了以往为不同业务集群分散部署、独立运维多套系统的复杂局面，在架构上实现了极大的简化。阿里云数据库 SelectDB 在 MiniMax 的成功实践足以说明：SelectDB 能够很好地满足 AI 时代海量数据实时处理与分析的需求。不仅为 MiniMax 自身业务的高效运营提供了坚实保障，也为广大面临类似日志处理挑战的 AI 大模型企业，提供了一个高性能、低成本的可靠技术解决方案。不止于此， 面对大模型与多模态 AI 的快速发展，SelectDB 已从被动存储分析向主动智能分析演进。目前，SelectDB 已具备 AI 原生支持能力，深度融合向量索引、文本搜索与结构化分析能力，实现高效的混合检索，显著提升结果相关性、实时性与准确性。更进一步，SelectDB 内置 AI 函数（如语义理解、特征提取）并支持基于 MCP 的 Agent 分析接口，可直接升级为企业的 “AI 分析中枢” ，为业务智能决策与创新提供稳定、高效的数据底座。

构建 AI 数据基座：思必驰基于 Apache Doris 的海量多模态数据集管理实践
type: item
date: 2026-01-23T16:06:01+08:00
description: 导读：面对海量多模态数据管理困境，思必驰通过构建以 Apache Doris 为核心的数据集平台，实现了数据从“散、乱、滞”到“统、明、畅”的转变。在关键场景中，存储占用下降 80%、查询 QPS 提升至 3w，不仅实现可量化的效率提升和成本优化，更系统化地提升了 AI 研发效率与模型质量。本文整理自 思必驰数据中台架构师魏凯君在 Doris Summit 2025 中的演讲内容，并以演讲者第一视角进行叙述。思必驰作为专注于对话式人工智能的平台型企业，围绕“云+芯”战略布局，致力于提供软硬件结合的全链路 AI 产品与服务。在长期服务智能车载、家居等终端场景中，我们积累了海量的多模态训练语料（包含音频、文本及人工标注）。早期的数据管理方式逐渐成为 AI 研发的瓶颈。各业务团队的标注数据分散在不同的存储系统中，依赖人工进行维护和同步。随着数据规模快速增长至 PB 级别，传统方式在三个方面面临严峻挑战：数据一致性问题：同一份数据在不同团队中存在多个副本，且更新不同步，影响模型训练的一致性。协同效率低下：算法工程师难以快速查找、复用跨团队的数据资产，重复标注与数据准备浪费了大量时间。版本追溯困难：模型迭代时，无法精准关联训练所使用的数据版本，导致问题复现与效果归因困难。这些问题使得数据资产化与高效协同成为制约 AI 研发规模化的关键。为此，我们决定构建一个统一的数据集管理平台，目标是将原始数据标准化、资产化，打造一个支持高效调用、可靠追溯、安全共享的“AI 数据基座”。为何是 Apache Doris？思必驰与 Apache Doris 的合作始于早期技术实践。在 Doris 0.12 版本时期，我们率先将其应用于内部实时数仓场景，并随业务发展，逐步建立起面向外部服务的 Doris 集群，支撑了包括实时看板、用户画像与自助分析在内的多项数据能力。此外，Doris 在海量业务日志场景（容器日志）中也发挥了关键作用，替代了原有的 Elasticsearch，并基于 Doris 自建日志查询平台，服务智能座舱语音业务。在同等硬件资源下，日志写入性能从原来的 100w/s 提升至 300w/s，存储成本也降低了 50% 以上。基于 Doris 在性能、成本、稳定性方面的综合优势，在构建数据集平台时，它自然成为数据底座的首选。我们的新场景对数据库提出了更高要求：海量数据去重与高效查询：需处理 10 亿级样本的快速去重与复杂筛选。完善的版本管理：需支持数据集的版本化存储、快速切换与对比。支持向量检索能力：为后续的相似样本检索、特征比对提供支持。高性价比存储：需利用高效压缩与冷热分离，降低 PB 级数据的存储成本。综合评估，Apache Doris 在满足上述核心需求的同时，其简洁的架构、易用的运维以及活跃的社区，使其成为最优方案。面向 AI 大规模训练的数据基座我们采用类 MLOps 理念，设计了贯穿数据-模型-应用的标准化流水线。数据预处理：原始的多模态数据（语音、文本等）通过采集、回流进入系统，经由专业的标注平台进行加工，再进入 AI 数据前台进行清洗与特征提取。数据集管理系统：经过预处理的数据，汇入 基于 Apache Doris 构建的数据集管理系统（即本文核心） 。该系统是整个 AI 中台的关键，负责数据的版本化存储、管理与发布，为模型训练与测试提供数据支撑。模型训练及管理：测试数据集进入模型训练系统进行训练，生成的模型经模型管理平台统一管理，最终部署上线，服务于业务应用。由上图可知，数据集管理系统被囊括在 AI 中台这一架构中。纵观整个 AI 中台，主要包括三个部分：数据管理系统：基于 Apache Doris 和 Elasticsearch 构建，提供页面、客户端和相应的 SDK；AI 平台：基于推理与训练框架，以及资源管理与任务调度框架构建；同样提供页面、客户端和 SDK。底层基础设施：涵盖计算层、分布式存储体系及优化后的网络层。为满足不同业务场景需求，数据集管理 系统设计了单中心和多中心两种部署架构：单中心：面向核心研发场景，数据访问统一指向本中心的 Apache Doris、Elasticsearch、Kafka 及相关文件系统，保证最强的一致性与性能。多中心：面向跨地域或异构计算资源场景， 采用分布式设计。主中心的数据层使用 Apache Doris，各分中心采用独立的分布式文件系统，这些存储之间可以实现数据的相互同步。针对各个中心的训练任务，系统能够读取这些分布式文件存储中的数据进行训练。数据版本毫秒级切换，存储占用下降 80%过去，我们依靠人工在文件系统中维护数据集目录，随着版本激增，混乱与错误难以避免。新平台需要实现类似代码库的版本管理能力（对比、切换、回滚）。为此，我们利用 Doris 的特性进行改进：列式存储：将标…

AI 能力揭秘（五）：Apache Doris 原生向量检索的设计及实现
type: item
date: 2026-01-21T17:05:23+08:00
description: 引言：随着大模型和多模态 AI 的快速发展，向量已成为文本、图像、音视频等多元数据的通用语义表示。在这种背景下，检索增强生成（RAG）技术成为连接私有知识与大模型的核心桥梁，而高效的向量检索则是其关键支柱。与将向量检索视为独立外挂服务的方案不同，Apache Doris 4.0 选择将向量检索能力深度集成于其 MPP 分析型数据库内核。实现向量检索与 SQL 计算、实时分析和事务保障的无缝融合。本文旨在深入剖析 Doris 向量检索的系统级设计与工程实践，展示其如何在性能、易用性与规模扩展之间取得的平衡。1. ANN 索引核心设计Apache Doris 的向量索引基于 ANN（近似最近邻）算法实现，并非独立的外挂组件，而是深度集成于存储、执行与 SQL 引擎中的原生能力。在 4.x 版本中，其核心 ANN 索引能力主要包括以下几方面：多索引类型与距离度量支持：支持主流的 ANN 索引类型（HNSW、IVF）及常见距离度量（L2 距离、内积）。用户可根据业务在构建速度、内存占用与召回率上的要求灵活权衡。原生 SQL 集成：向量检索以原生 SQL 算子形式提供，支持直接定义向量列、通过 ORDER BY distance LIMIT K 进行相似度搜索，并能与过滤、聚合、JOIN 等算子自由组合，天然支持混合检索与分析。构建与查询解耦：采用异步索引构建机制，数据导入后即可查询，索引在后台构建并加载，避免导入阻塞，保障查询高峰期的稳定低延迟写入。向量压缩优化：在导入与构建阶段支持标量量化（SQ）、乘积量化（PQ）等压缩技术，显著降低存储与内存开销，提升高维大规模向量场景的资源效率。分布式并行执行：依托于分布式架构，Doris 向量索引天然支持数据分片与索引分布式存储；查询可在各 BE 节点并行执行；Top-K 结果在上层进行合并与裁剪。随着节点数量增加，系统能够在数据规模与吞吐能力上实现近线性扩展。2. Benchmark & AnalysisApache Doris 的目标并非追求单一指标的极限表现，而是在真实生产负载下，实现性能的均衡性、系统稳定性与架构可扩展性。本次测试将围绕这一目标展开，所用工具为 ZillizTech 开源的向量搜索 BenchMark：https://github.com/zilliztech/VectorDBBench。云服务商：阿里云CPU：Intel Xeon Platinum 8369B @ 2.70GHz (16 核)内存：64GB2.1 导入与构建性能测试结果表明，在 Performance768D1M 数据集上，Apache Doris 在保证同等索引质量的前提下，导入性能显著优于对比系统。尤为重要的是，其导入速度的提升并未以牺牲图结构质量为代价。Doris 在 QPS 达到 895 的同时，仍保持了 97% 以上的召回率，在性能三角的三个维度上取得了出色的平衡。2.2 查询性能即便单独考量查询性能，Apache Doris 同样处于业界第一梯队。在 Performance768D10M 数据规模上，当召回率要求高于 95% 时，Apache Doris 的 QPS 表现优于 OpenSearch 与 Qdrant。此结果为默认配置下的开箱性能，未针对 Segment 文件数量等进行专项调优。这里比较的是开箱性能测试，即不做 segment 文件数量的优化时的性能对比。Milvus 的 flat 版本以及 Cloud 版本会有更好的性能表现，但是其出品的 VectorDBBench 只提供了 SQ8 量化后的成绩。3. 核心设计与性能优化Apache Doris 采用 FE（协调节点）与 BE（计算节点）构成的分布式架构。BE 作为核心执行单元，承担查询计划执行与数据导入任务，负责几乎所有高负载计算与大规模数据吞吐，是系统高性能的基石。尤其在向量场景下，数据写入、索引构建与向量距离计算都属于典型的 CPU 与内存密集型工作。为充分发挥其性能、保障系统稳定运行，我们对 ANN 索引的写入、构建与查询路径进行了系统优化。3.1 写入与构建路径优化优化主要分为两类：功能优化与性能优化。在功能层面，依托 Doris 成熟的分布式集群管理与存储管理能力，引入 LightSchemaChange 实现轻量级的索引管理机制，这是目前专用向量数据库普遍不具备的能力。在性能层面，重点聚焦于索引构建流程的优化，以显著提升索引构建速度和整体吞吐能力。3.1.1 异步索引构建机制Apache Doris 针对 ANN 索引构建开销大的问题，提供了异步构建机制。用户可在数据导入后，选择业务低峰期触发索引构建；在查询高峰时，仅需将已建好的索引加载至内存即可快速检索，从而将密集的 CPU 消耗转移至成本更低的时段。在 …

从 Greenplum 到 Doris：集群缩减 2/3、年省数百万，度小满构建超大规模数据分析平台技术实践
type: item
date: 2026-01-19T18:09:47+08:00
description: 度小满引入 Apache Doris 替换原有 Greenplum，实现整体查询效率提升 82%，与此同时，集群缩减 2/3、年省数百万的巨大效益。本文将分享度小满如何基于 Doris 从 0 到 1 构建超大规模数据分析平台，并围绕平滑迁移、异地多活容灾等方面，分享实践经验。本文整理自度小满 Doris 数据库负责人汤斯在 Doris Summit 2025 中的演讲，并以演讲者第一视角进行叙述。度小满金融（原百度金融）作为一家覆盖现代财富管理、支付、金融科技等多板块的科技公司，数据的分析处理对其极为重要，已经深度融入业务生命周期的每个环节，是进行风险控制、商业决策、用户体验优化及运营提效的基石。随着业务高速发展，度小满原有基于 Greenplum 搭建的 OLAP 平台，逐渐暴露出三大痛点：规模与稳定性瓶颈：存储已接近饱和，扩容至百余台已接近硬件规模的承载上限，如果继续扩容，将面临更严重的稳定性挑战。性能与体验不佳：Greenplum SQL 查询执行速度慢，且经常出现 “计算时间远小于排队时间” 的情况，严重影响业务分析效率。缺失技术支持：当前使用的 Greenplum 6 版本技术架构已显得陈旧，并且 2024 年 Greenplum 宣布将停止开源，后续的技术支持与迭代升级将无法保障。为了应对这些痛点，度小满金融迫切寻找更为高效、稳定且具备现代化技术架构的数据处理解决方案，以支持其未来的业务发展。Apache Doris：高吞吐、快查询面对日益增长的业务体量与复杂多变的分析需求，选用一个高效、可靠的数据库系统，已成为支撑业务稳健发展与快速创新的关键。Apache Doris 以其出色的性能表现与高度灵活的架构，成为众多场景下的优选方案。为深入验证其在海量数据与复杂分析场景中的能力，我们展开了一系列性能测试，关键结果如下：查询性能：在 1TB TPC-DS 标准测试集中， Apache Doris的查询速度约是 Greenplum 6 的 20-30 倍。导入性能：在基于 Flink 写入的 TPS 测试中，基于单分片导入，压测最大 TPS 为：5000W/s。JSON 数据处理：针对新推出的 Variant JSON 数据类型，测试显示：存储 2-3 万 Key 时，其空间占用仅为普通 JSON 的 1/10 甚至更低，查询效率则提升至 10 倍以上。综上可知，Apache Doris 在写入吞吐、响应速度及存储效率上表现卓越，有力证明了其应对大规模、实时化、半结构化数据分析挑战的坚实技术基础。基于 Apache Doris 的大规模数据分析平台在上述详实的选型调研之后，我们决定采用 Apache Doris 替代原有 Greenplum 集群，构建超大规模数据分析平台。为验证 Apache Doris 在真实业务场景中的表现，我们先进行了小范围试点，部署了少量 Doris 集群，并先行接入几个关键业务方。试点期间，系统在性能、稳定性和易用性方面获得高度评价。基于这一积极反馈，我们稳步扩展 Doris 集群规模，最终在效率与成本上实现大幅提升：整体效率：端到端分析任务耗时从 274 秒降至 47 秒，效率提升 82%，任务超时查杀比例从 1.3%骤降至 0.11%，降幅达 91%，彻底解决高峰期排队问题实现 0 排队，使分析师的工作不再因拥堵而中断，体验和生产力均有极大提升。集群成本：在同等资源成本下， Doris 仅以 1/3 的集群数量即可提供与 Greenplum 同等的服务能力，存储性能提升 200%。截至目前，已完成 百余台原 Greenplum 服务器的清退工作，以更少的硬件资源支撑了更高的计算与存储需求，实现年度硬件成本节约数百万元。从 0-1 数据平台建设经验我们基于 Apache Doris 成功替换了 Greenplum，完成了从 0-1 的数据平台重构，覆盖架构设计、数据流转与业务协同的系统性工程。以下将围绕快速平滑迁移、异地多活容灾与全链路生态集成三个核心环节，展开具体实践。01 快速迁移为保障业务连续性与数据安全，我们开发了自动化迁移工具 SqlGlot，将大规模数据从原有 GP 集群迁移至 Doris 集群。整个过程历经半年，累计迁移 PB 级规模数据，全程业务无感知。表结构迁移：在表结构迁移阶段，团队从 GP 系统中导出表结构及相关元数据，借助 SqlGlot 工具实现字段映射与语法适配，并在此基础上完成分区构建与分桶策略设计，确保每个分桶数据量控制在 1G～3G 的合理范围内。该流程最终成功转换超过 20,000 张表，并保障了所有表的分区与分桶结构符合业务与性能要求。表数据迁移：我们通过分布式导出将 GP 数据并行迁移至 Doris 机器，并基于 Doris 官方推荐的 Stream…

从 Greenplum 到 Doris：集群缩减 2/3、年省数百万，度小满构建超大规模数据分析平台技术实践
type: item
date: 2026-01-19T16:04:00+08:00
description: 度小满引入 Apache Doris 替换原有 Greenplum，实现整体查询效率提升 82%，与此同时，集群缩减 2/3、年省数百万的巨大效益。本文将分享度小满如何基于 Doris 从 0 到 1 构建超大规模数据分析平台，并围绕平滑迁移、异地多活容灾等方面，分享实践经验。本文整理自度小满 Doris 数据库负责人汤斯在 Doris Summit 2025 中的演讲，并以演讲者第一视角进行叙述。度小满金融（原百度金融）作为一家覆盖现代财富管理、支付、金融科技等多板块的科技公司，数据的分析处理对其极为重要，已经深度融入业务生命周期的每个环节，是进行风险控制、商业决策、用户体验优化及运营提效的基石。随着业务高速发展，度小满原有基于 Greenplum 搭建的 OLAP 平台，逐渐暴露出三大痛点：规模与稳定性瓶颈：存储已接近饱和，扩容至百余台已接近硬件规模的承载上限，如果继续扩容，将面临更严重的稳定性挑战。性能与体验不佳：Greenplum SQL 查询执行速度慢，且经常出现 “计算时间远小于排队时间” 的情况，严重影响业务分析效率。缺失技术支持：当前使用的 Greenplum 6 版本技术架构已显得陈旧，并且 2024 年 Greenplum 宣布将停止开源，后续的技术支持与迭代升级将无法保障。为了应对这些痛点，度小满金融迫切寻找更为高效、稳定且具备现代化技术架构的数据处理解决方案，以支持其未来的业务发展。Apache Doris：高吞吐、快查询面对日益增长的业务体量与复杂多变的分析需求，选用一个高效、可靠的数据库系统，已成为支撑业务稳健发展与快速创新的关键。Apache Doris 以其出色的性能表现与高度灵活的架构，成为众多场景下的优选方案。为深入验证其在海量数据与复杂分析场景中的能力，我们展开了一系列性能测试，关键结果如下：查询性能：在 1TB TPC-DS 标准测试集中， Apache Doris的查询速度约是 Greenplum 6 的 20-30 倍。导入性能：在基于 Flink 写入的 TPS 测试中，基于单分片导入，压测最大 TPS 为：5000W/s。JSON 数据处理：针对新推出的 Variant JSON 数据类型，测试显示：存储 2-3 万 Key 时，其空间占用仅为普通 JSON 的 1/10 甚至更低，查询效率则提升至 10 倍以上。综上可知，Apache Doris 在写入吞吐、响应速度及存储效率上表现卓越，有力证明了其应对大规模、实时化、半结构化数据分析挑战的坚实技术基础。基于 Apache Doris 的大规模数据分析平台在上述详实的选型调研之后，我们决定采用 Apache Doris 替代原有 Greenplum 集群，构建超大规模数据分析平台。为验证 Apache Doris 在真实业务场景中的表现，我们先进行了小范围试点，部署了少量 Doris 集群，并先行接入几个关键业务方。试点期间，系统在性能、稳定性和易用性方面获得高度评价。基于这一积极反馈，我们稳步扩展 Doris 集群规模，最终在效率与成本上实现大幅提升：整体效率：端到端分析任务耗时从 274 秒降至 47 秒，效率提升 82%，任务超时查杀比例从 1.3%骤降至 0.11%，降幅达 91%，彻底解决高峰期排队问题实现 0 排队，使分析师的工作不再因拥堵而中断，体验和生产力均有极大提升。集群成本：在同等资源成本下， Doris 仅以 1/3 的集群数量即可提供与 Greenplum 同等的服务能力，存储性能提升 200%。截至目前，已完成 百余台原 Greenplum 服务器的清退工作，以更少的硬件资源支撑了更高的计算与存储需求，实现年度硬件成本节约数百万元。从 0-1 数据平台建设经验我们基于 Apache Doris 成功替换了 Greenplum，完成了从 0-1 的数据平台重构，覆盖架构设计、数据流转与业务协同的系统性工程。以下将围绕快速平滑迁移、异地多活容灾与全链路生态集成三个核心环节，展开具体实践。01 快速迁移为保障业务连续性与数据安全，我们开发了自动化迁移工具 SqlGlot，将大规模数据从原有 GP 集群迁移至 Doris 集群。整个过程历经半年，累计迁移 PB 级规模数据，全程业务无感知。表结构迁移：在表结构迁移阶段，团队从 GP 系统中导出表结构及相关元数据，借助 SqlGlot 工具实现字段映射与语法适配，并在此基础上完成分区构建与分桶策略设计，确保每个分桶数据量控制在 1G～3G 的合理范围内。该流程最终成功转换超过 20,000 张表，并保障了所有表的分区与分桶结构符合业务与性能要求。表数据迁移：我们通过分布式导出将 GP 数据并行迁移至 Doris 机器，并基于 Doris 官方推荐的 Stream…