1. 性能1.1 性能瓶颈到底在哪MPP数据库的性能问题十次里有八次不是慢在硬件而是慢在数据分布和查询计划上。我在使用MPP数据库的过程中最大的体会是它的架构决定了你的SQL写法要跟着数据流动方式走而不是像单机数据库那样只考虑索引和统计信息就够了。先看最基础但最容易被忽视的一个问题——数据分布。MPP集群把表的数据按照分布键分散到各个计算节点上查询的时候每个节点只管自己手里的那一份。分布键选得好join和聚合都能在节点本地完成选得不好节点之间就得来回传数据。这种节点间的数据搬运就是查询慢的最常见根源。举个例子我之前帮一个团队优化一条统计SQL原语句跑了一个多小时数据量其实也才几千万行。看了一圈执行计划发现两个千万级大表做join时结果集在节点之间做了重分布和广播某一个节点要接收来自其他所有节点的数据这等于退化成单机还在做全量数据搬运。后来把join字段改成了两边表的分布键执行时间直接落到五分钟以内。这种数量级的差别就是MPP架构下最常见的性能真相。怎么判断自己的表是不是有分布问题两类查询发言权执行计划里出现大面积的“Redistribute Motion”或者“Broadcast Motion”说明join的字段和表分布键不一致数据正在跨节点流动。某几个数据节点CPU跑满、其他节点闲置大概率是数据分布不均形成了个别节点的瓶颈。1.2 执行计划调优的核心思路MPP数据库里执行计划里最关键的节点就是Motion。Motion表示数据在两个计算节点之间的传输过程。你希望的是一条SQL产生的Motion越少越好并且Motion搬运的数据量越小越好。常见的优化目标就是让大表之间的连接尽量发生在节点本地。要做到这一点有几个实操习惯值得坚持第一把分布键的选择当作模型设计的一部分。分布键不只是一个字段它决定了这张表将来和谁亲、和谁疏。选分布键的几个约束条件尽量选join高频字段让关联的两张表用同一个分布键。分布键的基数要大不能是一两个枚举值。比如按“省份”分布最多也就几十个取值数据容易堆在少数节点上。分布键取值要均匀不要一个值占了半张表。第二给统计信息做体检。MPP对统计信息的依赖比单机数据库更敏感。没有统计信息优化器只能靠猜猜出来的执行计划通常伴随超大规模广播或者错误的重分布策略。一个通用的检查命令是看查询计划里的估算行数如果估算值跟实际值差了几个数量级那就是统计信息过期了赶紧重新做analyze。第三控制并发和资源队列。MPP集群的资源管理通常通过资源队列来限制不同业务对CPU、内存的占用。很多团队出现了一个大查询把集群资源吃满、其他业务全部排队的问题其实就是队列设置不合理。把监控查询、报表查询、核心交易查询分到不同队列每个队列设置独立的并发数和内存上限能避免互相影响。1.3 容易被忽略的写入性能读性能大家都盯着看写入性能反而经常被忽略。MPP数据库的写入性能问题主要出在两个地方一个是小批量频繁写入。每次写入都要经过主节点解析、分配、再分发到数据节点这个过程的固定开销很大。如果业务是按一次几行的方式写入的你会发现哪怕集群有几十个节点吞吐也上不去。正确的做法是把写入积累成批量最好一次写入几千行甚至更多。另一个是数据导入方式。MPP提供的最快加载方式是从文件并行导入而不是通过SQL逐条写入。我实测过用并行加载工具和逐条insert相比几天导入的数据可以压缩到几小时。原因是加载工具绕过了SQL解析和单点分发流程让外部数据直接并行走入各个节点。所以做ETL的时候优先走文件加载通道别偷懒写insert循环。注意MPP上的事务和并发控制也跟单机库不一样频繁并发小事务容易导致全局事务ID消耗过快、锁竞争加剧这也是一种更隐蔽的“性能问题”。2. 注意事项2.1 数据模型上的几个大坑MPP数据库对数据模型的要求几乎到了苛刻的地步。普通关系型数据库里能接受的反范式设计放到MPP里代价会被放大到难以接受。最典型的情况是为了查询方便在一张宽表里冗余了大量字段包括一些原本来自其他表的信息。扁平宽表确实能让查询少写几个join但它带来的问题是超宽表导致单行数据过大存储和传输的成本同步放大同时如果宽表里冗余了高频变动字段每次更新都可能引发全表级别的数据重写。MPP是列式、压缩、分布式存储的逻辑但更新依然是重操作。更合适的做法是尽可能按业务维度拆分维度表和事实表。MPP的强项本来就是处理星型模型和雪花模型把模型拆开利用它的分布能力和并行聚合反而更快。刻意模仿传统BI的宽表相当于放弃了它的核心能力。第二个坑是过度使用唯一约束和外键。MPP数据库在分布式架构下做唯一性校验的成本远高于单机因为唯一性检查通常需要跨节点汇总。很多业务场景其实不需要数据库层面的唯一约束用业务逻辑去保证就可以了没必要让每次写入都背上跨节点的验证开销。2.2 事务和锁的边界MPP数据库对事务的支持有一个边界通常支持读已提交级别的并发控制但在可重复读和串行化级别上或者在高并发环境下会有额外的限制。具体踩过的一个坑是在同一个事务里先做大批量更新再做查询。MPP下这个查询可能会看到旧版本的数据或者因为事务快照机制导致结果不一致。遇到这类问题最直接的规避方式是把“大批量修改”和“后续读取”拆成两个独立事务。锁方面也需要注意。一个大表的长时间锁会影响跟它相关的一切操作包括DDL、analyze和备份。有一次我执行了一个逻辑复杂的更新脚本执行了四十分钟都没结束期间同一张表的查询全部堵住。后来养成了一个习惯任何大批量DML操作执行前先评估耗时并且安排在业务低峰期如果中间还需要反复读取数据先把结果集导出或落成临时表再处理。2.3 安全与权限管理权限这块很多人以为跟普通数据库差不多实际差别不小。MPP里的角色、权限管理和对象归属都是集群级的不同节点上都要同步一致。实操中比较隐蔽的问题是存储过程或者自定义函数在定义时用的属主权限如果创建者后来被回收了权限调用方可能会突然发现函数不能用了。建议是建立独立的应用账号并对这些账号只授予最小必要权限。默认创建的超管账号不要直接给应用使用否则一旦应用被注入或者误操作影响范围是整个集群。还有一些细节值得一提外部表的使用范围、网络白名单、SSL连接开启与否这都属于上线前必须确认的清单项。我在实际运维中遇到过一次外部表指向了错误主机导致查询直接报错的情况排查了半天才发现是主机地址配置错误。这个过程中网络策略上的题目占比不小建议提前规划好所有可能访问MPP的网段避免上线后频繁改白名单。2.4 备份与恢复不是事后选项MPP数据库的备份通常是通过并行备份工具完成把每个节点的数据分别导出。它跟单机数据库的备份策略差距很大尤其是元数据备份和分布式事务一致性点上需要专人重点关注。很多团队把备份策略写成了“每天凌晨做一次全量”但缺少对恢复流程的演练和文档一旦真要恢复时间成本和风险全都会暴露出来。值得推荐的方案是高频增量备份加上定期的全量备份同时每个季度做一次恢复演习。恢复演练不仅验证备份的有效性还能检验团队的应急响应能力。有人会嫌恢复演习浪费时间等真出事故时发现备份文件损坏或恢复流程卡壳那才是大麻烦。3. 工具3.1 运维监控工具的组合拳MPP集群的运维监控离不开几个核心工具的组合使用集群状态查看工具检查各个节点是否在线、同步状态、segment是否正常。运维人员的日常工作有一半都靠它完成。参数配置工具查看和修改集群级配置参数比如资源队列、并发数等。日志分析日志MPP的日志分散在每个节点上直接逐个节点登录去看日志肯定不现实一般需要通过日志聚合的方式集中分析。我常用的一个动作组合是先跑一次集群状态命令再查看节点负载和近期错误日志最后用配置工具确认关键参数没有被改动。三分钟之内集群整体健康状况就能有个判断。3.2 数据加载与导出的正确姿势数据加载工具是MPP最重要的外部工具之一并行加载的效率是普通insert的十倍以上。它的工作方式是通过一个文件服务进程对外提供数据每个节点直接读取分配给自己的那部分文件跳过主节点转发。实际操作中有几点经验直接影响加载速度文件切分粒度要和节点数匹配。理想情况下文件数量是节点数的整数倍这样才能均匀分配到每个节点。数据文件不要压缩得太狠。虽然支持压缩格式但解压会占用CPU且限制并行度。出错处理要提前配置好。大批量导入时小部分脏数据是常态。需要设定跳过错误行的上限或者把错误数据单独记录下来否则一个报错就全部回滚会让加载时间翻倍。导出功能也类似尽量直接走并行通道导出到文件系统再去做后续分发。通过客户端连接执行select然后拼文件性能和效率都并不理想。3.3 日常维护脚本运维MPP集群时有几个小脚本非常值得提前写好能省掉大量重复劳动数据倾斜巡检脚本按分布键统计表的行数分布列出数据分布最不均匀的Top N张表。这个脚本建议每周跑一次发现倾斜及时处理。统计信息过期检查脚本筛选出数据变化量超过阈值但统计信息很久没有更新的表自动输出待analyze的列表。长交易监控脚本持续观察数据库里超过指定时长的交易发现异常可以提醒甚至自动终止。这些脚本的价值在于它们把“经验”固化成了“动作”。每次接手一个新的MPP集群我第一件事就是把这套监控脚本部署上去一周之后集群的真实情况就摸得八九不离十了。4. 编译4.1 为什么自己编译MPP大多数使用MPP的团队不会走到“编译源码”这一步官方通常提供编译好的安装包或用安装脚本部署。但如果你有这几类需求就绕不开编译需要修改内核代码来适配特殊的存储格式或者自定义聚合函数需要基于特定版本的代码加入自己的补丁需要精简安装包或者定制自己体系内的组件版本。我自己第一次编译是在向一个旧版本内核源码应用补丁的场景下当时也没有现成的二进包可用只能硬着头皮走源码编译。踩了一路的坑之后反而对MPP的架构理解深了一层。4.2 编译环境准备源码编译最怕的不是代码报错而是环境不干净导致的一堆“假报错”。建议在干净的操作系统环境里新起一台编译机避免跟生产环境混合使用。编译前必装的依赖大体包括GCC工具链、Python开发包、bison、flex、若干内核头文件包。不同操作系统上包名不一样但整体列表差不多。版本方面有个关键体验GCC版本太新或太旧都可能出现兼容问题优先选择发行版默认自带的编译器版本比自己手工升级一个特定GCC版本要省事得多。配置阶段有几个常见开关需要注意指定编译模式开发版或生产版生产环境推荐开启优化选项指定是否启用特定的扩展模块指定安装路径前缀建议使用独立目录而不是默认系统路径后面卸载方便。我第一次编译时没有指定前缀路径结果安装进了系统默认目录后面更新版本时清理起来特别麻烦。4.3 编译中的常见错误与排查编译过程最容易出的两类问题一类是缺少依赖的头文件另一类是flex和bison版本不匹配导致的语法生成文件失败。缺头文件的报错多数是字面意思缺什么就补什么例如缺某个名为xx-dev或xx-devel的包名搜索包名装上就行好在编译报错一般不拐弯。比较头疼的是版本不匹配导致的编译中断这种报错信息比较难读。有一个百试百灵的排查思路遇事先看配置阶段的输出再看编译日志里第一个Error的位置而不是从一堆警告里找线索。编译还是一个比较吃内存的过程。我在一台内存比较小的机器上编译过结果在链接阶段直接卡死。后来加了一块交换分区才勉强完成。如果你打算在虚拟机里编译内存至少给到2GB以上否则后续自定义功能编译大概率会不顺畅。注意编译前务必确认代码包完整性用官方校验值核对一下避免拉到被篡改或损坏的源码包这种事虽然概率低但一旦发生会浪费很长排查时间。4.4 自定义函数与扩展的编译比源码编译更常见的是编译自定义函数或插件扩展。MPP支持用多种语言写用户自定义函数其中编译型语言需要自行处理。编译自定义函数本质上就是写一个符合接口规范的共享库/类包然后拷贝到指定目录并创建函数声明。最容易出问题的地方有两处编译器版本与数据库服务器编译时的版本不一致导致生成的动态库加载报错。这种情况只能重新用数据库服务器同款编译器编译。权限和路径问题。动态库文件权限不对或者放错目录数据库加载时会直接拒绝。有一个习惯值得每个人养成写完自定义函数先在一个测试实例上加载验证成功之后再发到生产环境。不要在生产环境直接边测边调。5. FAQ 速查表5.1 高频问题查证问题现象可能原因快速排查/解决集群整体慢单条SQL执行计划中Motion特别多关联字段与分布键不一致查看执行计划调整SQL写法或重设表分布键某节点CPU高其他节点空闲数据分布不均或数据倾斜运行数据倾斜检查脚本重新选择分布键或重分布大批量写入速度远低于预期用了逐条insert而不是批量并行加载改成批量写入或文件加载方式查询结果出现不一致/脏读事务间竞争或快照隔离问题拆分为独立事务避免长时间更新后读取统计信息过期但未更新缺少自动analyze策略配置自动analyze或定期任务执行函数或扩展突然无法加载动态库文件缺失或编译器版本不匹配用与服务器相同版本编译器重新编译备份恢复流程卡壳缺少恢复演练、备份文件不完整定期演练验证备份完整性5.2 性能突然下降该怎么查这里再说一个尤其重要的方法论性能突然下降不要急着调参数更不要立刻重启集群。先做三件事看监控有没有长事务、锁等待、坏节点出现。看日志盘查当天节点日志里有没有异常报错。看执行计划对比之前正常的计划看看现在是哪里多出了Motion或者走了错误扫描方式。绝大多数“突然变慢”的问题都不是参数劣化而是某些表的数据量和分布情况发生了质变或者业务侧引入了一条变态SQL。跑一次最耗资源Top SQL排名通常就能锁定元凶。我曾经遇到过一个集群持续卡顿最后查到是一条被频繁调用的外部表接口查询由于外部数据源响应慢连带拖垮了整个集群的资源队列。5.3 FAQ之外的三个必读经验新增节点扩容之后一定别忘了重新平衡数据分布。扩容不是把节点加进去就完事了旧节点的数据不会自动分一部分给新节点。需要进行数据重分布否则新节点一直空闲扩容等于白扩。记住“指令优先于经验”集群的配置参数需要记清楚默认值改了什么也要有记录。很多人遇到问题会想起某个业界流传的“调优参数”随手就改但真正的问题不一定在参数本身上。文档和脚本要持续维护。MPP的运维场景千变万化今天手动解决的一个问题如果不固化成脚本和文档三个月后大概率会以同样的姿势再踩一遍。写在最后MPP数据库用得好不好技术参数的差距只占一半另一半在你能不能建立一套“数据分布意识”建表时想到查询方式写SQL时想到数据流动运维时想到监控指标。这种意识不是看几篇文档能建立的是一步步从慢查询、倾斜表、长事务的泥土里爬出来之后自然长出来的。我个人在实际操作中最深的体会是性能调优永远不要在出问题时才调而要在业务还没上来之前就把分布键选对、把统计信息的维护机制建好。后面运维的日子能不能清闲很大程度上取决于前面这些“不起眼的决定”做得好不好。如果你正准备把一个MPP集群投入生产建议从建表的第一天起就严格把关分布键和索引设计后面你会感谢那时候的自己。
