1. MPP是什么从一堆机器到一个数据库的转变做了这么多年数据相关的工作我越来越发现一个现象很多人一提分布式数据库就想到 Hadoop、Spark觉得 MPP 是某个仓库里的冷门概念。实际上 MPPMassively Parallel Processing大规模并行处理正是现代数据仓库、分析型数据库的底层骨架从 Greenplum 到 ClickHouse从 Teradata 到阿里云 AnalyticDB背后几乎都是同一套思路。这篇文章不聊虚的直接从架构、组件分工、平台选择三个角度把它讲透。先打个比方。你去银行办事如果只有一个柜台后面排一百个人效率再高也快不到哪去。MPP 的做法是把大厅切成几十个柜台每个柜台配一个业务员用户的数据提前按规则分到不同柜台大家同时办自己的业务最后把结果汇总给你。对用户来说你看到的还是一个银行、一个排队号但内部的吞吐量完全不在一个量级。这就是 MPP 最核心的思想——把一个大任务切碎交给多个节点并行处理对外仍呈现单一数据库的接口。但这里要明确一个关键区别MPP 是shared-nothing架构不是简单的多台机器跑同一个数据库。每台节点有自己独立的 CPU、内存、磁盘节点之间通过高速网络通信数据按分布策略切分到各个节点。查询进来以后由协调节点Master拆解成子任务分发到各计算节点Segment并行执行最后汇总返回。这套设计的好处是扩展性几乎是线性的——加节点就加算力瓶颈只在于网络和协调节点的调度能力。MPP 适用什么场景一句话海量数据的分析型负载。比如几亿行的事实表做多维聚合、几十个表的关联查询、按天跑批处理报表这些都是 MPP 的拿手好戏。而 OLTP 场景大量短小的事务、高频点查更新则不适合因为分布式事务协调成本太高单机数据库或 NewSQL反而更合适。搞清楚这个边界你才不会在技术选型时用错工具。我第一次接触 MPP 是在一个数仓迁移项目里。原来的 Oracle RAC 扛不住每日 3 亿行的增量导入和复杂的报表查询晚上跑批动辄四五个小时。换成 MPP 之后同样的 SQL 跑批压缩到 40 分钟以内而且这还是没做太多调优的结果。当时我最大的感受就是架构选对了很多优化其实是多余的。2. 架构拆解Master、Segment 与数据分布策略2.1 三种角色各干各的活一个典型的 MPP 数据库在逻辑上通常包含三类角色Master协调节点负责接收 SQL、生成执行计划、分发任务、汇总结果。它不存业务数据只保存元数据库表定义、分布信息等。有些实现里有 Standby Master用于高可用。Segment计算节点真正干活的角色。每个 Segment 持有部分数据负责执行分配给自己的子任务。Segment 之间不共享任何东西所以叫 shared-nothing。Interconnect互联网络节点间的通信层负责数据传输和 shuffle 操作。在 Greenplum 里是 UDP/TCP 混合的专用协议在 ClickHouse 里则是集群配置 分布式表。以一次典型的聚合查询为例客户端发一条SELECT region, SUM(amount) FROM sales GROUP BY region到 MasterMaster 把 SQL 解析成执行计划按region的分布键把任务发到所有 Segment 上。每个 Segment 扫描本地数据做局部聚合把结果返回给 MasterMaster 再合并。如果涉及 JOIN关联键的分布策略决定了数据是否需要跨节点重分布Redistribute或广播Broadcast这一步往往是性能的关键。2.2 数据分布Hash、Random 还是 Replicated这一节必须细说因为分布策略选错MPP 性能能差几十倍。常见的三种分布方式Hash Distribution哈希分布按某一列的哈希值取模决定行落在哪个 Segment。适用于等值关联和分组聚合可以让 join 在本地完成避免跨节点数据移动。这是最常用、最推荐的默认策略。Random Distribution随机分布数据不按规则散列近似均匀随机分配。适合没有合适分布键的表比如某些维度表但 join 时大概率要走重分布代价较高。Replicated Distribution复制分布每个节点都保存这张表的完整副本。适合小维度表join 时直接本地关联完全避免网络传输。维度表几千行到几万行时非常香。选分布键的原则归纳起来三条高频 join 的等值列、高基数列区分度足够、避免数据倾斜。比如订单表按customer_id哈希分布客户表也按customer_id哈希分布两表 join 时数据天然对齐无需 shuffle。如果你按order_status这种取值只有几个的列做分布键大概率会出现严重的数据倾斜某个 Segment 忙死、其他 Segment 空闲整体查询慢得离谱。我给一个真实案例。某电商数仓有一张订单明细表原先按order_id哈希分布但业务上高频查询是按用户维度统计订单金额每次 join 用户表都要触发大规模重分布查询秒级变成分钟级。后来我把订单表分布键改成user_id用户表同样按user_id分布同等数据量下关联查询从 120 秒降到 6 秒。这就是分布策略的威力。2.3 并行执行计划的思路MPP 的执行计划由三部分组成并行扫描多个 Segment 同时扫各自的数据分片。数据移动算子Redistribute、Broadcast、Gather汇总到 Master等步骤是执行计划中的通信开销大户。汇总阶段Master 或某个 Segment 负责最终归并。执行计划的调优重点就是减少数据移动。能用本地 join 就不要重分布能用复制表就不要广播大表。很多 MPP 数据库的 EXPLAIN 输出里都有Motion节点你观察一下它的类型和数据量基本就能定位瓶颈。3. 主流 MPP 平台对比从商业闭源到开源生态MPP 不是一个具体的产品而是一类架构。市面上的实现很多各有各的性格。我整理了一张对比表方便你做选型参考平台产品性质核心特点典型场景Greenplum开源PostgreSQL 衍生基于 PostgreSQLSQL 兼容性好支持丰富的分析函数和扩展擅长复杂查询企业级数仓、大规模 BI 报表ClickHouse开源C 实现列式存储 向量化执行单表聚合极快但 join 能力相对一般实时分析、OLAP 报表、时间序列DorisApache Doris开源兼容 MySQL 协议支持明细模型、聚合模型、唯一模型MPP 与列存结合交互式分析、实时数仓StarRocks开源从 Doris 分叉性能优化激进支持物化视图、外部目录极速分析、统一数仓Teradata商业老牌 MPP 数仓稳定性强成本高大型企业核心数仓Vertica商业现属 Micro Focus列式存储 弹性扩展擅长压缩和查询优化大规模分析、机器学习特征库AnalyticDB云服务阿里云兼容 MySQL/PostgreSQLServerless 弹性云上实时数仓Redshift云服务AWS基于 Paraccel 的列式 MPPS3 集成好AWS 生态分析3.1 Greenplum开源 MPP 的常青树Greenplum 基于 PostgreSQL 9.x 的分支开发结构上是多个 PostgreSQL 实例拼成一个集群。每个 Segment 本质是一个独立的 PostgreSQL 数据库Master 只做调度和元数据管理。它最大的优点是 SQL 功能非常完整——窗口函数、递归 CTE、JSON、甚至 PL/pgSQL 都能用对从 Oracle 迁移过来的团队很友好。但也有坑Greenplum 的存储是行存Heap或列存AOColumn。分析型负载强烈建议使用列存 压缩否则性能差距能有一倍以上。另外 Greenplum 的事务能力非常有限全局事务快照等场景支持较弱高并发写入不是它的强项。3.2 ClickHouse单表聚合之王ClickHouse 不算严格意义的 MPP很多人这么问。严格讲它确实是 shared-nothing 的分布式架构但和 Greenplum 这类 RDBMS 形态的 MPP 不同ClickHouse 的分布式能力通过Distributed表引擎实现数据分布在多台服务器上查询时分布式表把请求发到本地表并行执行再汇总。它的杀手锏是列式存储 向量化执行 稀疏索引对大面积扫描聚合速度快到夸张。但 ClickHouse 在多表关联上不如传统数据库成熟虽然新版本支持了更多的 join 优化但仍建议尽量通过宽表或预聚合来避免大表 join。适合日志分析、行为事件流、监控指标等场景。3.3 Doris 与 StarRocks国产 MPP 的崛起Apache Doris 和它的加强版 StarRocks 近几年非常火。两者都兼容 MySQL 协议这意味着现有 MySQL 生态的 BI 工具、ORM 框架基本可以无缝接入对团队的学习成本很低。Doris 支持三种数据模型明细模型Duplicate保留原始数据适合必须精确到行的场景。聚合模型Aggregate导入时按聚合键预聚合适合分钟级/小时级的预汇总表。唯一模型Unique主键去重适合需要 upsert 的场景。StarRocks 在 Doris 基础上强化了性能支持了更高效的物化视图、CBO基于代价的优化器和外部数据源联邦查询。如果预算有限又想要一个能扛住高并发交互式查询的数仓我通常优先推荐 StarRocks。3.4 云上 MPP把运维压力外包云服务商基本都提供了 MPP 形态的数据仓库产品比如 AWS Redshift、阿里云 AnalyticDB、腾讯云 TCHouse基于 ClickHouse。选择云服务最大的好处是弹性扩缩容和免运维但代价是有一定绑定毕竟 SQL 方言、生态工具、数据迁移方式都可能被锁住。如果你团队规模小、没有专职 DBA又恰好已经在云上直接用云数仓大概率比自建开源 MPP 划算。4. 平台支持与生态MPP 不是孤立存在的4.1 文件系统与存储接口MPP 集群需要底层存储的配合但和 Hadoop 的 HDFS 强绑定不一样MPP 通常要求高性能本地盘或共享存储。Greenplum 和 Doris 都支持 HDFS 作为外部存储读外部表但核心数据还是存在本地磁盘。在用本地盘时每个 Segment 的并发 IO 能力会直接影响查询性能所以 NVMe SSD 几乎是标配。有些公有云 MPP 服务会用云盘做数据冗余但高吞吐场景下云盘的延迟还是比本地盘明显选型时要关注规格参数。4.2 SQL 兼容性对比这是很多从传统数据库迁到 MPP 项目的人最关心的一点。我碰过不少项目原系统用的 Oracle 写法迁移到 MPP 后各种报错。这里列几个常见差异字符串拼接Oracle 用||Greenplum / Doris 也支持||但 ClickHouse 的concat语法稍有不同。分页查询MySQL 的LIMIT、Oracle 的ROWNUM、PG 的LIMIT基本能兼容但 ClickHouse 的LIMIT语法特殊且大 offset 性能极差。索引类型MPP 数据库通常没有传统 B-Tree 索引的强约束更多的是靠分区裁剪和统计信息优化。你不需要手动创建太多索引反而很多 MPP 不允许建高成本索引或意义不大。物化视图Greenplum 原生不支持自动刷新物化视图可用外部工具实现StarRocks 和 Doris 则支持异步/同步刷新这里差别很大。4.3 生态工具的接入一个 MPP 数据库要落地光有 SQL 不够必须能接入现有工具链。主流 BI 工具Tableau、FineBI、QuickBI、Superset基本都支持 JDBC / ODBC 连接 MPP但方言适配程度不同。例如 Tableau 对 Greenplum 有专门驱动ClickHouse 需要装第三方 JDBC 驱动官方也提供了。如果你用的是基于 MySQL 协议的 Doris / StarRocks那么多数组件直接按 MySQL 模式连省心不少。调度系统方面常见的 Apache Airflow、DolphinScheduler 都能通过 SQL 操作接入。ETL 工具方面要注意数据导入方式——Greenplum 用gpload或外部表并行加载ClickHouse 用INSERT INTO ... SELECT或 Kafka 引擎接入实时流Doris 用Stream Load或Broker Load做批量导入。每一家的导入管道设计都不一样提前规划好数据管道能省很多后期麻烦。5. 选型建议与落地踩坑实录最后说点掏心窝的话。MPP 选型没有最好的只有最适合当前业务阶段和团队能力的。我梳理了几条判断标准团队技术栈如果团队熟 PostgreSQLGreenplum 上手最快熟 MySQLDoris 或 StarRocks 更顺都是 Java 背景且偏实时流分析ClickHouse 配合 Flink 会顺手。查询模式以复杂关联查询为主优先 Greenplum / Doris以超大表聚合和宽表扫描为主ClickHouse 优势明显。并发与实时性高并发交互式报表StarRocks 和 Doris 表现很好跑批和 ETLGreenplum 也能胜任但并发不能开太高。运维成本如果团队没有专职运维直接选云上托管的 MPP 或 SaaS 分析平台别折腾自建否则后期一个月要修八次集群。再分享几个我在实际项目中踩过的坑坑一数据倾斜没有提前检查。有一次跑大表 join跑了半小时还没出结果后来定位发现有一个channel0的渠道占了总量 60%对应的分布键 hash 后集中在少数 Segment。解决方式是换一个高基数的分布键同时把该渠道单独分区处理。坑二并发太高把 Master 打爆。Greenplum 的 Master 是单点虽然有 Standby但高并发下 Master 的 CPU 会先撑不住。后续做法是加一层查询路由或限制用户并发数大查询任务只允许低并发小查询走另外的队列。坑三导入阶段没有做分区裁剪设计。分区键选的是天但业务查询按小时过滤导致每次扫描全量分区性能完全达不到预期。后来改成小时分区配合分区裁剪查询 IO 减少近 70%。每次 MPP 项目做完我都会重新审视一遍这个查询真的需要并行吗。有时候 SQL 本身就是低效的全表扫描就算 MPP 有 100 个节点也救不回来。分布键、分区策略、统计信息、执行计划分析这四个点做好MPP 才算真正用得明白。希望这篇文章能帮你在 MPP 的学习和选型上少走点弯路。