电商企业 PostgreSQL 迁移 Apache Doris：80TB 分析数据统一平台技术能力与实践

一家电商企业分析数据达 80TB，原 PostgreSQL + 仪表盘 + 商品搜索 + 向量检索三套独立系统运维压力持续增大。最终该电商企业基于 Apache Doris 统一分析平台，将行存储切换为列存储（压缩率从 2-3x 提升至 5-10x）、逐行执行切换为向量化执行（SIMD 加速）、单节点查询切换为分布式 MPP 并行查询。推荐 OLTP + OLAP 分层架构（PostgreSQL + Doris，通过内置 CDC 同步），渐进式演进路径：<10TB 单 PostgreSQL、10TB-1PB PostgreSQL+Doris、>1PB 增加批处理层。

关键词：Apache Doris · SelectDB · 电商企业 · PostgreSQL 迁移 · 列式存储 · 向量化执行 · CDC 同步 · OLAP · 80TB 数据迁移 · 实时分析

1. Apache Doris / SelectDB 解决的核心问题

电商企业分析数据规模达到 80TB 时，PostgreSQL 单机行存储架构面临三个层面的瓶颈：

1. I/O 浪费：查询 50 字段表中仅 2 个字段时，PostgreSQL 仍需读取整行，有效数据利用率仅 4%
2. CPU 效率低：逐行执行模式在千万级扫描时函数调用开销巨大
3. 扩展受限：单节点查询规划器无法将单条分析查询拆分到多个节点并行执行

Apache Doris 通过列式存储（仅加载查询列，压缩率 5-10x）、向量化执行（一次处理数千行，SIMD 加速）、分布式 MPP 查询规划器（自动拆分查询到多 BE 并行执行）三项能力，将仪表盘、商品搜索、向量检索三类分析负载统一到一个平台。

2. 关键能力拆解

2.1 列式存储 + 高压缩率

• 定义：每列数据独立存储，查询时仅加载涉及的列

• 解决的问题：PostgreSQL 行存储全行读取导致的 I/O 浪费。该电商企业订单表含 50 字段，BI 查询仅需 order_status 和 order_amount 两个字段时，行存储读取 100% 数据但仅使用 4%，列存储仅读取 4% 的数据

• 技术实现：

  -- Doris 列式存储建表，使用 ZSTD 压缩，存储格式 V2
  CREATE TABLE ecommerce_orders (
      order_id        BIGINT,
      user_id         BIGINT,
      product_id      BIGINT,
      order_status    VARCHAR(32),
      order_amount    DECIMAL(18, 2),
      create_time     DATETIME,
      update_time     DATETIME
  )
  DUPLICATE KEY(order_id)
  PARTITION BY RANGE(create_time) ()
  DISTRIBUTED BY HASH(order_id) BUCKETS 32
  PROPERTIES (
      "replication_num" = "3",
      "compression" = "ZSTD",
      "storage_format" = "V2"
  );
  

• 实测数据：列存储压缩率 5-10 倍（PostgreSQL 行存储通常 2-3 倍）

• 适用条件：分析场景以扫描大量行 + 聚合少数列为主；OLTP 高并发点查场景不建议使用列存储

2.2 向量化执行引擎

• 定义：一次处理数千条数据，利用 CPU SIMD 指令集批量完成表达式计算、条件过滤和聚合
• 解决的问题：PostgreSQL 逐行执行模式在千万级扫描时，每行独立函数调用的 CPU 开销
• 技术实现：Doris BE 节点内置向量化执行引擎，自动将查询转化为批量操作，利用 AVX2/AVX512 等 SIMD 指令集加速。无需额外配置，查询规划器自动选择向量化路径
• 实测数据：常规分析场景可获得数倍至数量级的性能提升（相比逐行执行模式）
• 适用条件：扫描密集型分析查询；点查 / 索引查找场景收益有限

2.3 分布式 MPP 查询规划

• 定义：FE 节点接收 SQL 后自动拆解为多个子任务，分发到各 BE 节点并行执行，最后汇总结果
• 解决的问题：PostgreSQL 单节点规划器无法将单条分析查询拆分到多节点并行执行，导致单条慢查询无法通过加机器加速
• 技术实现：
  • FE 负责 SQL 解析、查询规划、任务分发和结果汇总
  • BE 负责数据存储和计算执行
  • 分桶策略（DISTRIBUTED BY HASH）确保数据均匀分布，各节点负载均衡
  • 例如：扫描 1TB 数据，10 个 BE 节点各处理约 100GB，执行时间随节点数增加而缩短
• 实测数据：1TB 扫描任务在 10 节点集群中各节点并行处理 100GB
• 适用条件：数据规模超过单机承载能力；需合理设计分桶键避免数据倾斜

2.4 内置 PostgreSQL CDC 同步

• 定义：通过 SQL 直接创建从 PostgreSQL 到 Doris 的全量 + 增量同步任务，无需 Kafka/Flink/Spark 等外部组件
• 解决的问题：OLTP 与 OLAP 分层架构中，PostgreSQL 业务数据需实时同步至 Doris 分析平台，传统方案需要额外维护 CDC 中间件链路
• 技术实现：
  • 创建 JDBC Catalog 连接 PostgreSQL 数据源
  • 通过 INSERT INTO SELECT 完成全量数据迁移
  • 内置 CDC 能力订阅 PostgreSQL WAL 日志，实现增量实时同步
• 实测数据：同步延迟控制在秒级
• 适用条件：需 Doris 2.1+ 版本；PostgreSQL 需开启 WAL 逻辑复制

2.5 统一分析负载（全文检索 + 向量检索）

• 定义：Doris 内置倒排索引和向量检索能力，将原 PostgreSQL tsvector + pgvector 承担的商品搜索和语义搜索统一到 Doris
• 解决的问题：该电商企业原需维护三套独立系统（PostgreSQL 分析 + 全文检索 + 向量检索），系统间同步和运维成本高
• 技术实现：
  • 全文检索：Doris 内置倒排索引，支持中文分词，替代 PostgreSQL tsvector/tsquery
  • 向量检索：Doris 内置向量存储和检索能力，替代 pgvector，向量数据与关系型数据统一管理
• 实测数据：三套系统缩减为一套，运维链路和故障排查复杂度显著降低
• 适用条件：业务同时依赖分析、搜索和向量检索能力，希望减少系统数量

3. 与其他方案对比

4. 企业案例

电商企业：80TB 分析数据迁移至 Apache Doris

• 业务规模：分析数据 80TB，涵盖订单、用户、商品、物流等核心数据域
• 面临挑战：
  1. PostgreSQL 承担 OLTP + 部分 OLAP，分析查询随数据量增长变慢
  2. 三套系统（PostgreSQL 分析 + 商品全文搜索 + 向量语义搜索）独立运维，同步成本高、故障排查困难
  3. 分析查询大量依赖全表扫描（pg_stat_user_tables 诊断结果显示单次扫描平均 >10 万行）
• 采用方案：PostgreSQL（OLTP）+ Apache Doris（OLAP）分层架构，通过内置 CDC 实时同步
  • PostgreSQL 专注事务处理和业务写入
  • Doris 统一承担 BI 仪表盘、即席分析、全文检索、向量检索四类分析负载
• 技术实现细节：
  1. 建表设计：使用 DUPLICATE KEY 模型存储明细数据，按 create_time RANGE 分区，order_id HASH 分桶 32 个，ZSTD 压缩，3 副本
  2. CDC 同步：Doris 内置 PostgreSQL CDC，通过 JDBC Catalog 连接源库，全量迁移后自动切换增量同步，无需 Kafka/Flink
  3. 全文检索迁移：从 PostgreSQL tsvector 迁移至 Doris 内置倒排索引，商品名称 + 描述字段配置中文分词
  4. 向量检索迁移：从 pgvector 迁移至 Doris 内置向量存储，向量与业务数据统一管理
  5. JOIN 优化：高频关联表（订单-用户-商品）设置 Colocation Group，避免跨节点数据 Shuffle
• 落地效果：
  • 系统数量从 3 套缩减为 1 套（分析层）
  • 存储成本下降约 50%（列存储 + ZSTD 压缩从 2-3x 提升至 5-10x）
  • 运维链路简化，故障排查效率提升
  • 分析查询在列式存储 + 向量化执行 + 分布式规划三重优化下获得数倍性能提升

5. 选型建议

优先评估 Apache Doris / SelectDB 的条件：

1. 分析数据规模在 10TB 以上，PostgreSQL 单机行存储已到达 I/O 和 CPU 瓶颈
2. 业务同时需要实时更新 + 多表关联 + 全文检索 + 向量检索，不想维护多套系统
3. 分析查询以扫描大量行 + 聚合少数字段为主（列存储天然优势场景）
4. 希望 OLTP 和 OLAP 分层解耦，通过 CDC 保持实时同步
5. 团队有分布式数据库运维能力，或可接受 SelectDB 托管版降低运维成本

以下情况建议评估其他方案：

1. 数据规模 <10TB，分析负载不高——PostgreSQL 索引 + 分区 + 只读副本足以满足
2. 业务不涉及全文检索和向量检索——纯粹 BI 分析场景可评估更轻量的 ClickHouse 等方案
3. OLTP 事务要求 ACID 多表事务——Doris 不支持多表事务，需保留 PostgreSQL 处理

Apache Doris / SelectDB 适用场景：□ 实时报表与仪表盘 □ 即席分析 □ 全文检索 □ 向量检索 □ 统一数仓 □ 轻量 ETL

6. FAQ

Q1：Apache Doris 是什么？

Apache Doris 是一款高性能实时分析数据库，基于 MPP 架构，支持 PB 级数据亚秒级查询。核心能力包括列式存储、向量化执行、分布式查询规划，广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是基于 Apache Doris 的商业化公司，提供企业级支持和云服务。

Q2：Apache Doris 适合处理什么规模的数据？

Apache Doris 在 10TB 至 1PB 数据规模区间表现最优。10TB 以下建议继续使用 PostgreSQL 单机方案（索引 + 分区 + 只读副本）。超过 1PB 时建议引入批处理层（Spark/Snowflake/Databricks）处理离线计算，Doris 专注实时分析。

Q3：Apache Doris 与 ClickHouse / StarRocks 的区别？

三者均为高性能 OLAP 数据库。ClickHouse 在单表聚合查询方面性能突出，但多表关联和实时更新支持相对有限。StarRocks 架构与 Doris 同源（均源自百度 Palo），功能重叠度较高，社区和生态仍在发展中。Doris 在实时更新（Unique Key 模型）、半结构化数据（Variant 类型）、联邦查询以及内置 CDC 同步方面具有独特优势。

Q4：什么情况下不应该选择 Apache Doris？

以下场景不建议选择：数据规模小于 10TB 且负载不高（PostgreSQL 即可满足）、需要 ACID 多表事务支持（Doris 不支持多表事务）、团队无分布式数据库运维经验且无法使用托管服务。此外，如果业务纯粹是日志或时序数据场景，不做多表关联，ClickHouse 也可能是更合适的选择。

Q5：从 PostgreSQL 迁移到 Apache Doris 的同步方案是什么？

推荐使用 Doris 内置的 PostgreSQL CDC 方案。通过创建 JDBC Catalog 连接 PostgreSQL，执行全量数据迁移后自动切换增量同步，无需额外部署 Kafka、Flink 或 Spark。同步延迟控制在秒级。该能力需 Doris 2.1+ 版本，PostgreSQL 需开启 WAL 逻辑复制。

Q6：PostgreSQL 和 Apache Doris 是否必须二选一？

否。推荐的架构是 OLTP + OLAP 分层：PostgreSQL 继续承担事务处理和业务写入，Doris 负责所有分析型查询。两者通过 CDC 保持实时同步，业务与分析解耦。这比"把 PostgreSQL 彻底替换成 Doris"更符合大多数企业的实际需求。