xiaohack's Blog - OLAP
type: channel
link: https://blog.xiaohack.org/tag/olap/
items: 快手：从分散存储到统一分析，Apache Doris 在万亿规模广告场景的应用
items: 双 11 大促峰值不翻车：淘天集团 Paimon + StarRocks 大规模 OLAP 查询实战与优化
items: AI时代，当 MySQL 遇见列式存储引擎 DuckDB
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…

双 11 大促峰值不翻车：淘天集团 Paimon + StarRocks 大规模 OLAP 查询实战与优化
type: item
date: 2026-01-27T16:56:12+08:00
description: 作者：朱奥 /淘天集团高级数据工程师导读：双 11 等大促场景会在短时间内集中爆发：运营与业务 BI 在开卖后的窗口期密集访问数据产品，瞬时请求量陡增，对查询引擎的稳定性、成本与治理体系提出极高要求。与此同时，业务对近实时数据产品的诉求持续增强，传统“多存储、多链路、依赖回刷”的模式在研发效率、回刷成本与响应速度上逐步暴露瓶颈。本文围绕 Paimon 与 StarRocks 的组合实践，梳理淘天在大规模 OLAP 查询场景下的架构演进与双 11 保障体系：通过实时与离线统一入湖，消除数据同步链路与多份存储成本；基于稳定中间层叠加在线现算与维表实时关联，将高消耗回刷转化为秒级查询，核心场景回刷效率提升约 80%，年化节省成本接近 1000 万；同时结合 StarRocks + RoaringBitmap 低成本解决跨天交叉实时 UV 计算难题，满足大促近实时决策需求。1 淘天集团营销活动 OLAP 查询的探索背景与核心策略1.1 当前数据架构首先，简要介绍当前的数据架构与数据流转方式。从 DWD 层开始，我们的数据分为实时与离线两条主链路：实时数据主要存储在 TT中，在业界可类比为 Kafka 一类的消息队列；离线数据主要存储在 ODPS 中。在数据加工与写入层面，我们会启动 Flink 流批一体任务：实时侧持续消费 TT 中的数据；离线侧消费 ODPS 中的数据；在计算过程中，任务会关联多类 ODPS 维表，例如类目维表、商家分层等维度信息。计算完成后，结果统一写入 ADS 层的Holo 表中，并在数据服务层对外透出。在纯离线场景下，我们会通过 ODPS 任务读取 ODPS 数据，同时写入 ADS 层对应的 ODPS 表。这里既包含历史天级数据，也包含历史小时级数据。当存在查询加速需求时，我们还会将 ODPS 数据进一步导入到 Holo 中。在数据服务层，我们主要通过 Holo 或 MC 对外提供数据服务。我们会根据查询时延要求选择不同的服务路径：当业务对响应速度要求更高、需要达到毫秒级时，通常通过 Holo 提供查询服务；当时延要求相对宽松，例如百毫秒级或秒级，则更多通过 MC 来承载查询请求。1.2 业务诉求与核心痛点随着业务发展，我们当前面临的诉求主要来自两个方向：一是业务侧希望获得更多实时数据产品；二是业务 BI 的实时分析需求持续增长。这对数据研发提出了新的挑战：进一步提升研发效率。回到现有架构，其核心痛点主要体现在两方面：流批存储不统一：实时数据存储在 TT 中，离线数据存储在 ODPS 中；当存在查询加速需求时，部分数据还需要进一步落到 Holo 表中。整体开发架构较为复杂，数据需要在多个存储介质之间流转，导致端到端链路拉长。在查询特性上，Holo 在点查场景具备更突出的性能优势，且整体稳定性较强，在淘天历年大促期间的表现也相对稳定。但在更常见的 Shuffle 场景下，整体查询性能相对一般。尤其当 OLAP 查询负载更重、需要进行更复杂的计算，或需要关联规模较大的维表时，Shuffle 相关的执行效率会成为瓶颈，导致查询耗时明显拉长。数据更新与维护上也存在较高成本。以 ODPS 中的维表为例（如类目维表、商家分层维表等），当维表发生业务变更时，往往需要触发 ADS 层任务的回刷，从而带来额外的回刷开销。业务对“近实时”的诉求在部分场景下出现了被动降级。例如在跨天实时 UV 等场景中，由于 state 规模较大、成本较高等原因，方案不得不从实时级别降级到小时级别。从业务视角看，近实时能力仍然是明确存在的需求。1.3 核心策略1）架构简化提效架构上实现 存储介质的统一：将实时与离线数据统一沉淀到 Paimon 的湖存储中。在此基础上， StarRocks 可以直接面向湖存储进行高性能分析查询，从而能够消除数据同步链路以及多份存储带来的成本。降低使用门槛，让数据更容易被上层分析与 BI 使用。以实时链路为例，原本实时数据存储在 TT 中，而 TT 的数据形态具有明显特征：每行数据是一个字符串、缺少 schema。在这种形态下，数据虽然可以被消费，但如果要面向 BI 分析使用，往往还需要额外进行反序列化与解析，这会带来不可忽视的工程与使用成本。在统一存储之后，Paimon 将实时与离线数据沉淀在同一张表中，并提供明确的 schema。这意味着，上层使用方可以直接面向结构化数据开展分析：即使分析师的数据开发能力不强，也可以基于 Paimon 的近实时中间层，通过 StarRocks 自助完成对近实时数据的分析。在这种模式下，过去一些相对简单的取数与分析需求，可以由 BI 或分析师通过自助方式直接完成，不再必须提交给数据研发排期处理，从而在一定程度上减少数据开发侧的需求量与交付压力。2） 业务难点攻坚通过稳定的中间层 Pa…

AI时代，当 MySQL 遇见列式存储引擎 DuckDB
type: item
date: 2026-01-23T17:51:01+08:00
description: 作者：ba0tiao编者按：在AI浪潮席卷全球的今天，有人认为传统关系型数据库已走向黄昏，MySQL 的生命力正在被边缘化。但事实真的如此吗？AliSQL，作为 MySQL 的重要分支，自2010年诞生以来，始终默默支撑着阿里巴巴集团核心业务的高并发、高可用需求。它从未消失，只是沉寂太久。2026年，AliSQL社区的一帮开发者们，开始为AliSQL注入创新的血液！这是他们的第一篇，系统阐述了MySQL深度融合DuckDB的重大技术实践。这不仅是对“MySQL 只擅长 TP”这一行业共识的突破性回应，更是一次兼具工程魄力与架构远见的创新——在保持 MySQL 协议、语法、运维体系完全兼容的前提下，以轻量、高效、零侵入的方式，为MySQL 注入了 OLAP 能力。国内首场《2026 AliSQL Innovate 用户大会暨 AliSQL DuckDB 开源发布会》将于2月3日在杭州开启！席位有限，快来报名吧：https://page.aliyun.com/form/act1162737496/index.htmMySQL的插件式存储引擎架构MySQL的核心创新之一就是其插件式存储引擎架构（Pluggable Storage Engine Architecture），这种架构使得MySQL可以通过多种不同的存储引擎来扩展自己的能力，从而支持更多的业务场景。MySQL的插件式架构如下图所示：MySQL的插件式存储引擎架构可以划分为四个主要的部分：运行层(Runtime Layer)：负责MySQL运行相关的任务，比如通讯、访问控制、系统配置、监控等信息。Binlog层(Binlog Layer): 负责Binlog的生成、复制和应用。SQL层(SQL Layer)：复制SQL的解析、优化和SQL的执行。存储引擎层(Storage Engine Layer)：负责数据的存储和访问。MySQL在SQL计算和数据存储之间设计了一套标准的数据访问控制接口(Plugable Engine Interface)，SQL层通过这个标准的接口进行数据的更新、查询和管理，存储引擎得以作为独立组件实现“热插拔”式集成。目前MySQL中常用的存储引擎包括：MyISAM：MySQL最早使用的引擎，因为不支持事务已经被InnoDB取代。但是一直到MySQL-5.7还是系统表的存储引擎。InnoDB：MySQL的默认引擎。因期对事务的支持以及优秀的性能表现，逐步替代MyISAM成为MySQL最广泛使用的引擎。CSV： CSV文件引擎，MySQL慢日志和General Log的存储引擎。Memory：内存表存储引擎，也可作为SQL执行时内部临时表的存储引擎。TempTable：MySQL-8.0引入的引擎，用于存储内部临时表。InnoDB作为引擎引入到MySQL，是MySQL插件式引擎架构的一个非常重要的里程碑。在互联网发展的初期，MyISAM因其简单高效的访问赢得了互联网业务的青睐，和Linux、Apach、PHP一起被称为LAMP架构。随着电商、社交互联网的兴起，MyIASAM的短板越来越明显。InnoDB因其对事务ACID的支持、在并发访问和性能上的优势，大大的拓展了MySQL的能力。在InnoDB的加持下，MySQL成为最流行的开源OLTP数据库。随着MySQL的广泛使用，我们看到有越来越多基于TP数据的分析型查询。InnoDB的架构是天然为OLTP设计，虽然在TP业务场景下能够有非常优秀的性能表现。但InnoDB在分析型业务场景下的查询效率非常的低。这大大的限制了MySQL的使用场景。时至今日，MySQL一直欠缺一个分析型查询引擎。DuckDB的出现让我们看到了一种可能性。DuckDB简介DuckDB 是一个开源的在线分析处理（OLAP）和数据分析工作负载而设计。因其轻量、高性能、零配置和易集成的特性，正在迅速成为数据科学、BI 工具和嵌入式分析场景中的热门选择。DuckDB主要有以下几个特点：卓越的查询性能：单机DuckDB的性能不但远高于InnoDB，甚至比ClickHouse和SelectDB的性能更好。优秀的压缩比：DuckDB采用列式存储，根据类型自动选择合适的压缩算法，具有非常高的压缩率。嵌入式设计：DuckDB是一个嵌入式的数据库系统，天然的适合被集成到MySQL中。插件化设计：DuckDB采用了插件式的设计，非常方便进行第三方的开发和功能扩展。友好的License：DuckDB的License允许任何形式的使用DuckDB的源代码，包括商业行为。基于以上的几个原因，我们认为DuckDB非常适合成为MySQL的AP存储引擎。因此我们将DuckDB集成到了AliSQL中。DuckDB引擎的定位是实现轻量级的单机分析能力，目前基于DuckD…

从 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…