简介：本文咱们将通过一个理论的磁盘空间优化案例来阐明，如何帮忙客户做老本优化。

作者 | 玉翮
起源 | 阿里技术公众号

一背景形容

目前，企业的外围数据个别都以二维表的形式存储在数据库中。在核心技术自主可控的大环境下，政企行业客户都在纷纷尝试应用国产数据库或开源数据库，尤其在数据仓库OLAP畛域的步调更快，Greenplum的利用越来越宽泛，阿里云ADB PG的市场机会也越来越多。另外，随着近年来数据中台的价值被宽泛认可，企业建设数据中台的需要也十分迫切，数据中台的很多场景都会用到Greenplum或ADB PG。因而，往年阿里云应用ADB PG帮忙很多客户降级了外围数仓。咱们发现，客户往往比拟关注应用云原生数仓的老本。到底如何帮忙客户节约老本，便值得咱们去摸索和落地。

ADB PG全称云原生数据仓库AnalyticDB PostgreSQL版，它是一款大规模并行处理（MPP）架构的数据库，是阿里云基于开源Greenplum优化后的云原生数据仓库，因而本文探讨的老本优化办法也实用于Greenplum开源版。图1是ADB PG的架构示意图（Greenplum亦如此），Master负责承受连贯申请，SQL解析、优化、事务等解决，并散发工作到Segment执行；并协调每一个Segment返回的后果以及把最终后果出现给客户端程序。Segment是一个独立的PostgreSQL数据库，负责业务数据的存储和计算，每个Segment位于不同的独立物理机上，存储业务数据的不同局部，多个Segment组成计算集群；集群反对横向扩大。从架构上很分明，节约Greenplum的老本，最重要的是要尽可能节约Segment的服务器数，但既要保障整体MPP的算力，也要能满足数据对存储空间的需要。通常，数据仓库中的数据是从企业各个领域的上游生产零碎同步而来，这些数据在剖析畛域有生命周期，很多数据须要反馈历史变动，因而数据仓库中数据的特点是起源多、历史数据多、数据量比拟大。数据量大，必然耗费存储空间，在MPP架构下就是耗费服务器老本。帮客户优化老本，节约存储空间是首当其冲的。

图1：ADB PG的架构示意图

上面，咱们将通过一个理论的磁盘空间优化案例来阐明，如何帮忙客户做老本优化。

二 ADB PG & Greenplum的磁盘治理简介

1 ADB PG磁盘治理的关键技术点

ADB PG是基于Greenplum（简称“GP”）内核批改的MPP数据库，对于磁盘空间治理来讲，有几个技术点与Greenplum是通用的：

（1）业务数据次要散布在Segment节点；

（2）Segment有Primary和Mirror节点，因而，业务可用空间是服务器总空间的1/2；

（3）Greenplum的MVCC机制，导致表数据产生DML后产生垃圾数据dead tuples；

（4）复制表（全散布表）会在每个Segment上存储雷同的数据拷贝；散布表会依据散布键打散存储数据到各个Segment。

（5）Greenplum有Append Only类型的表，反对压缩存储，能够节约空间；当然用户拜访时，解压缩须要工夫，所以须要在性能和空间之间获得均衡。

云原生数据库的特点是不再独自提供数据库存储和计算的内核，也会配套运维治理平台，简称“数据库管控”。搞清楚ADB PG磁盘治理原理后，咱们须要理解数据库管控在磁盘水位治理方面的设计。

2 数据库管控的磁盘预留机制

咱们看下某数仓试验环境的各个Segment节点的磁盘占用示意图。

图2：Segment维度的磁盘占用示意图

上图第一个百分比是Segment所在物理机的磁盘应用百分比；第二个百分比是数据库管控的磁盘应用百分比。管控的数据为啥要跟服务器理论占用不统一呢？其实就是水位治理中第一个很重要的预防性措施：空间预留。即，ADB的管控在创立Segment实例时，依据服务器的空间，进行了肯定的预留，占比大略是12%，即20T的服务器，管控认为业务最大可用17.6T，这个逻辑会告诉监控零碎。所以计算磁盘占比时，监控零碎的分母不是20T，而是17.6T。这是第一级保护措施。

预留空间，还有重要的一点起因是数据库自身有WAL事务日志、谬误日志等也占用空间。因而，磁盘的空间有一部分须要给日志应用，客户的业务数据无奈应用100%的服务器空间，这就是为何图2中，会显示两个空间百分比的起因。

3 数据库管控的“锁定写” 爱护机制

第二级保护措施是“磁盘满锁定写”。在17.6T的根底上，管控并不让业务齐全写满，写满容易造成数据文件损坏，带来数据库宕机及无奈复原的劫难。因而，这里有第二个阈值，即当磁盘写到90%时，数据库管控的主动巡检工作会启动“锁定写”的操作，此时所有申请ADB的DML都会失败。这是一个重要的爱护机制。如下图3所示，如果达到阈值，会提醒“need to lock”。阈值能够配置，如果磁盘空间缓和，能够依据理论状况适当调大阈值。

图3：数据库管控的自动化锁盘日志示例

以上数据库管控的两个机制能够无效保障磁盘在平安水位下运行。这些设计，是咱们做老本优化的根底，磁盘的老本优化意味着服务器的磁盘尽可能物尽其用。节约磁盘空间，就必须要在绝对较高的磁盘水位运行（这里是指数据量的确很大的状况），因而，磁盘无效治理，及时的问题监控发现的机制十分重要。

三磁盘空间优化计划

上面咱们以某客户的案例来阐明磁盘空间优化办法。该客户数据仓库中的数据（含索引）大于1.5PB，但客户一期为ADB数仓洽购了40台机器，约800T总容量。客户明确要求阿里云须要配合业务方做好数仓设计，帮其节约老本。客户把老本优化的KPI曾经定好了，须要阿里云通过技术去落实。咱们协同业务方在设计阶段做了一些预案，技术上次要从表压缩和冷热数据拆散的角度去做思考；业务上，让开发商从设计上，尽量缩减在ADB中的存量数据。最终，开发商预估大略有360T左右的热数据从旧的数仓迁徙到ADB。上线前，开发商须要把必要的根底业务数据（比方贴源层，中间层），从DB2迁徙到ADB PG。迁徙实现，业务进行试运行期，咱们发现空间简直占满（如图2）。空间优化火烧眉毛，于是咱们发动了磁盘空间优化治理。图4是磁盘空间治理优化的框架。

图4：磁盘水位优化框架

接下来，咱们开展做一下阐明。

1 表的存储格局及压缩

表的压缩存储能够无效保障客户节约存储空间。Greenplum反对行存、Append-only行存、Append-only列存等存储格局。若心愿节约存储空间，Append-only列存表是较好的抉择，它较好的反对数据压缩，能够在建表时指定压缩算法和压缩级别。适合的压缩算法和级别，能够节约数倍存储空间。建示意例语句如下：

CREATE TABLE bar (id integer, name text)    WITH(appendonly=true, orientation=column, COMPRESSTYPE=zstd, COMPRESSLEVEL=5)    DISTRIBUTED BY (id);

列存表必须是Append-only类型，创立列存表时，用户能够通过指定COMPRESSTYPE字段来指定压缩的类型，如不指定则数据不会进行压缩。目前反对三种压缩类型：

zstd、zlib和lz4，zstd算法在压缩速度、解压缩度和压缩率三个维度上比拟平衡，实际上举荐优先思考采纳zstd算法。zlib算法次要是为了兼容一些已有的数据，个别新建的表不采纳zlib算法。lz4算法的压缩速度和压缩率不如zstd，然而解压速度显著优于zstd算法，因而对于查问性能要求严格的场景，举荐采纳lz4算法。

用户能够通过指定COMPRESSLEVEL字段来决定压缩等级，数值越大压缩率越高，取值范畴为1-19，具体压缩等级并不是数字越大越好，如上文所述，解压缩也耗费工夫，压缩率高，则解压缩会绝对更慢。因而，须要依据业务理论测试来选定，个别5-9都是有理论生产实践的压缩级别。

2 冷热数据分层存储

在大型企业的数据仓库设计中，MPP数据库（ADB属于MPP）只是其中一种数据存储，而且是偏批处理、联机查问、adHoc查问的场景应用较多；还有很多冷数据、归档数据，其实个别都会布局相似Hadoop、MaxCompute甚至OSS进行存储；另外，近年来衰亡的流数据的计算和存储，需要也十分强烈，能够通过Kafka、Blink、Storm来解决。因而，当MPP数据库空间告急时，咱们也能够做冷热数据分级存储的计划。ADB PG的分级存储计划，大抵有两种：1是业务方本人治理冷数据和热数据；2是利用ADB PG冷热数据分层存储和转换性能。

业务方通过PXF表面拜访HDFS冷数据

业务方把局部冷数据以文件的形式存到HDFS或Hive，能够在ADB创立PXF内部表进行拜访；内部表不占用ADB PG的磁盘空间。PXF作为Greenplum与Hadoop集群数据交互的并行通道框架，在Greenplum中通过PXF能够并行加载和卸载Hadoop平台数据。具体应用办法如下：

（1）控制台开明PXF服务

· 登录ADB管控台，拜访ADB PG实例内部表页面，点击开明新服务

图5：PXF表面服务

填写具体的Hadoop的服务信息后（波及kerberos认证，非此文重点），PXF服务会启动，启动胜利后如上图。

（2）创立PXF扩大

`-- 管理员执行

create extension pxf_fdw;`

（3）创立PXF表面

CREATE EXTERNAL TABLE pxf_hdfs_textsimple(location text, month text, num_orders int, total_sales float8)LOCATION ('pxf://data/pxf_examples/pxf_hdfs_simple.txt?PROFILE=hdfs:text&SERVER=23')FORMAT 'TEXT' (delimiter=E',');

阐明：Location是hdfs源文件信息，/data/pxf_examples/pxf_hdfs_simple.txt，即业务拜访的内部冷数据文件；SERVER=23指明了Hadoop表面的地址信息，其中23是集群地址信息的寄存目录，在图8中能够依据PXF服务查到。

（4）拜访内部表

拜访内部表就和拜访一般表没有区别

图6：内部表拜访示例

ADB PG冷热数据分层存储计划

下面的pxf表面拜访，有一个弊病，是如果冷数据（表面）要和热数据join，效率较差，起因是数据要从HDFS加载到ADB，再和ADB的表进行Join，徒增大量IO。因而，ADB PG在Greenplum的PXF表面的根底上，提供了冷热数据转换的性能，业务方能够在须要Join表面和一般表剖析时，把内部表先转换为ADB的一般表数据，再做业务查问，整体计划称为冷热数据分层存储。因为都是利用PXF表面服务，3.4.1中的第1和第2步骤能够复用。额定的配置办法如下：

(1) 配置分层存储默认应用方才的Foreign Server

用超级管理员执行

ALTER DATABASE postgres SET RDS_DEF_OPT_COLD_STORAGE TO 'server "23",resource "/cold_data", format "text",delimiter ","';

留神，这里须要将postgres替换为理论的数据库名，并将/cold_data替换为理论在HDFS上须要用来存储冷数据的门路。

(2) 重启数据库实例后执行查看

SHOW RDS_DEF_OPT_COLD_STORAGE;
验证是否配置胜利。

(3) 创立测试表，并插入大量测试数据

create table t1(a serial) distributed by (a);insert into t1 select nextval('t1_a_seq') from generate_series(1,100);postgres=# select sum(a) from t1;sum------5050(1 row)

此时，t1表的数据是存在ADB的本地存储中的，属于热数据。

(4) 将表数据迁徙到冷存HDFS

alter table t1 set (storagepolicy=cold);

图7：转换数据为冷数据

留神这个NOTICE在以后版本中是失常的，因为在冷存上是不存在所谓散布信息的，或者说散布信息是内部存储（HDFS）决定。

（5）验证冷数据表的应用

首先，通过查看表的定义，验证表曾经迁徙到冷存

图8：冷存表的定义

而后失常查问表数据；

postgres=# select sum(a) from t1;sum------5050(1 row)

（6）将数据迁回热存

alter table t1 set (storagepolicy=hot);

图9：数据迁回热存

留神：迁徙回热存后，distributed信息失落了，这是以后版本的限度。如果表有索引，则索引在迁徙后会失落，须要补建索引。以上两个计划，都能肯定水平上把冷数据从ADB PG中迁徙到内部存储，节约ADB PG的空间。

计划1，Join效率低，不反对冷热数据转换，但不再占用ADB的空间；

计划2，Join效率高，反对冷热数据转换，局部工夫须要占用ADB的空间。

两个计划各有利弊，实际上我的项目中，依据业务利用来定。在该客户案例中，冷热数据分层存储计划，为整体ADB节约了数百T空间，这数百T空间中，大部分是设计阶段解决的，少部分是试运行期间进一步优化的。

3 垃圾数据vacuum

因为GP内核的MVCC管理机制，一个表的DML（t2时刻）提交后的数据元组，实际上并没有立刻删除，而是始终与该表的失常元组存储在一起，被标记为dead tuples；这会导致表收缩而占用额定空间。垃圾数据回收有两个办法：内核主动清理、SQL手动清理。主动清理的机制是：表的dead tuples累积到肯定百分比，且所有查问该表的事务（t1时刻<t2时刻）都曾经完结，内核会主动auto vacuum垃圾数据。这个机制，自身没有问题，然而在大库和大表场景下有肯定问题，一个大表上T，数据变动10G才1%，多个大表一起变动，就会累计给整体空间带来问题，因而必须辅以手动回收。

手动回收办法

（1）统计出零碎的top大表；

select *,pg_size_pretty(size) from (select oid,relname,pg_relation_size(oid) as size from pg_class where  relkind = 'r' order by 3 desc limit 100)t;  -- limit 100示意top100

（2）查问大表的dead tuple占比和空间；

-- 依据统计信息查问膨胀率大于20%的表

SELECT ((btdrelpages/btdexppages)-1)*100||'%', b.relname  FROM gp_toolkit.gp_bloat_expected_pages a  join  pg_class b on  a.btdrelid=b.oid  where btdrelpages/btdexppages>1.2;

（3）应用pg_cron定时工作帮忙业务回收垃圾数据

vacuum tablename;

或

vacuum analyze tablename;-- 先执行一个VACUUM 而后是给每个选定的表执行一个ANALYZE

或

vacuum full tablename;

这里须要与业务沟通分明执行工夫，具体vacuum时，尽管不影响读写，但还是有额定的IO耗费。vacuum full tablename要谨慎应用，两者的区别要重点阐明一下：简略的VACUUM(没有FULL)只是回收表的空间并且令原表能够再次应用。这种模式的命令和表的一般读写能够并发操作，因为没有申请排他锁。然而，额定的空间并不返回给操作系统；仅放弃在雷同的表中可用。VACUUM FULL将表的全部内容重写到一个没有任何垃圾数据的新文件中（占用新的磁盘空间，而后删除旧表的文件开释空间），相当于把未应用的空间返回到操作系统中。这种模式要慢许多并且在解决的时候须要在表上施加一个排它锁。因而影响业务应用该表。

（4）vacuum退出业务代码的失当环节进行回收

如果某些表，更新频繁，每日都会收缩，则能够退出到业务的代码中进行vacuum，在每次做完频繁DML变更后，立刻回收垃圾数据。

零碎表也须要回收

这是一个极其容易漠视的点。特地是在某些数据仓库须要频繁建表、改表（长期表也算）的场景下，很多存储元数据的零碎表也存在收缩的状况，而且膨胀率跟DDL频繁度正相干。某客户呈现过pg_attribute收缩到几百GB，pg_class收缩到20倍的状况。以下表，是依据理论总结进去比拟容易收缩的pg零碎表。

pg_attribute -- 存储表字段详情pg_attribute_encoding -- 表字段的扩大信息pg_class -- 存储pg的所有对象pg_statistic  -- 存储pg的数据库内容的统计数

图10：pg_class膨胀率示例

手动Vacuum的限度

手动做vacuum有肯定的限度，也要留神。

（1）不要在IO使用率高的期间执行vacuum；

（2）vacuum full须要额定的磁盘空间能力实现。

如果磁盘水位高，残余空间少，可能不够vacuum full大表；能够采取先删除一些历史表，腾出磁盘空间，再vacuum full指标table。

（3）必须先完结指标table上的大事务

有一次例行大表保护时，一个表做了一次vacuum，收缩的空间并没有回收，认真一查pg_stat_activity，发现这个表上有一个大事务（启动工夫比手动vacuum启动更早）还没完结，这个时候，内核认为旧的数据还可能被应用，因而还不能回收，手动也不能。

4 冗余索引清理

索引自身也占用空间，尤其大表的索引。索引是数据库进步查问效率比拟罕用又根底的形式，用好索引不等于尽可能多的创立索引，尤其在大库的大表上。空间缓和，能够试着查一下是否有冗余索引能够清理。

排查思路

（1）是否有蕴含“异样多”字段的复合索引；

（2）是否有存在前缀字段雷同的多个复合索引；

（3）是否存在优化器从来不走的索引。

排查办法与例子

首先，咱们从第1个思路开始，查问索引蕴含字段大于等于4个列的表。SQL如下：

with t as (select indrelid, indkey,count(distinct unnest_idx) as unnest_idx_count        from pg_catalog.pg_index, unnest(indkey) as unnest_idx group by 1,2 having count(distinct unnest_idx)>=4 order by 3 desc)select relname tablename,t.unnest_idx_count idx_cnt from pg_class c ,t where c.oid=t.indrelid;

某个客户，就建了很多10个字段以上的复合索引，如下图所示：

图11：按索引列数排序的复合索引

个别超过6个字段的复合索引，在生产上都很少见，因而咱们初步判断是建表时，业务方创立了冗余的索引；接下来，能够依照索引的大小排序后输入冗余索引列表。SQL如下：

with t as (select indrelid,indexrelid, indkey,count(distinct unnest_idx) as unnest_idx_count from pg_catalog.pg_index, unnest(indkey) as unnest_idx group by 1,2,3 having count(distinct unnest_idx)>=3 order by 3 desc)select relname tablename,(pg_relation_size(indexrelid))/1024/1024/1024 indexsize,t.unnest_idx_count idx_cnt from pg_class c ,t where c.oid=t.indrelid order by 2 desc;

图12：按大小排序的复合索引

这里，咱们很分明发现，局部索引的大小都在500G以上，有10多个索引的size超过1TB，看到这些信息时，咱们震惊又开心，开心的是应该能够回收很多空间。接下来，须要跟业务方去沟通，通过业务方确认不须要再删除。

在这个客户案例中，咱们删除了200多个冗余索引，大小达24T，间接开释了7%的业务空间！十分可观的空间优化成果。这次优化也十分及时，我记得优化在11月底实现；接着正好12月初顶峰降临，业务方又写入了20TB新数据，如果没有这次索引优化，毫不夸大：12月初该客户的ADB集群撑不住了！

第（2）个思路（是否有存在前缀字段雷同的多个复合索引），排查SQL如下。最好把索引及蕴含的字段元数据导出到其余GP库去剖析，因为波及到索引数据的剖析比照（波及向量转字符数组，以及子集与超集的计算），比拟耗费性能；

select idx1.indrelid::regclass,idx1.indexrelid::regclass, string_to_array(idx1.indkey::text, ' ') as multi_index1,string_to_array(idx2.indkey::text, ' ') as multi_index2,idx2.indexrelid::regclass from pg_index idx1 , pg_index idx2  where idx1.indrelid= idx2.indrelid and idx1.indexrelid!=idx2.indexrelid and idx1.indnatts > 1and string_to_array(idx1.indkey::text, ' ') <@ string_to_array(idx2.indkey::text, ' ');

以下是排查例子user_t上复合第2个问题的索引，如下：

以下是查问后果

以上例子后果解释：multi_index1是multi_index2的子集，前者的索引列曾经在后者中做了索引，因而，multi_index1属于冗余索引。

第（3）个思路：是否存在优化器从来不走的索引，排查的SQL如下：

SELECT    PSUI.indexrelid::regclass AS IndexName    ,PSUI.relid::regclass AS TableNameFROM pg_stat_user_indexes AS PSUI    JOIN pg_index AS PI     ON PSUI.IndexRelid = PI.IndexRelidWHERE PSUI.idx_scan = 0     AND PI.indisunique IS FALSE;

上面以一个测试表，讲述排查例子

执行SQL能够查到idx_scan=0的索引idx_b

另外，有一个很重要的知识点，Append-Only列存表上的索引扫描只反对bitmap scan形式，如果Greenplum敞开了bitmap scan的索引扫描形式，那么所有AO列存表的拜访都会全表扫描，即实践上AO列存表上的所有非惟一索引都无奈应用，能够全副drop掉。当然，这个操作危险很高，要求整个database里应用AO列存表的业务简直都只做批处理，不存在点查或范畴查找的业务。综上，删除冗余索引，能够帮忙客户节约磁盘空间。

5 复制表批改为散布表

家喻户晓，ADB PG的表散布策略有DISTRIBUTED BY（哈希散布），DISTRIBUTED RANDOMLY（随机散布），或DISTRIBUTED REPLICATED（全散布或复制表）。前两种的表会依据指定的散布键，把数据依照hash算法，打散散布到各个Segment上；复制表，则会在每个Segment上寄存残缺的数据拷贝。复制表散布策略(DISTRIBUTED REPLICATED)应该在小表上应用。将大表数据复制到每个节点上无论在存储还是保护上都是有很高代价的。查问全散布表的SQL如下：

select n.nspname AS "schemaname",c.relname AS "tablename",case when p.policytype='p' then 'parted' when p.policytype='r' then 'replicated' else 'normal' end  as "distrb_type", pg_size_pretty(pg_relation_size(c.oid))from pg_class cleft join gp_distribution_policy p on c.oid=p.localoidleft join pg_namespace n on c.relnamespace=n.oidwhere n.nspname='public'and c.relkind='r'and p.policytype='r'order by 4 desc;

查问后果如下图，找到了大略10TB的全散布表，前3个表较大能够批改为哈希散布表，大略能够节约7T空间。

图13：业务库中的复制表

6 长期表空间独立寄存

咱们晓得，Greenplum的默认表空间有两个

如果建表不指定表空间，默认会放到pg_default表空间，蕴含堆表、AO表、列存表、长期表等。具体到Segment的文件目录，则是每个Segment服务器上的~/data/Segment/${Segment_id}/base/${database_oid}目录下。同时，Greenplum在多种场景都会产生长期表，如：

（1）sql中order by、group by等操作；

（2）GP引擎因为数据读取或shuffle的须要，创立的长期表；

（3）业务方在ETL工作中创立的长期表。

这样存在一个问题，就是业务运行产生的长期表也会占用空间，但这部分不是业务表的数据占用，不不便准确治理大库的磁盘空间；因而咱们把长期表的表空间独立进去，在服务器文件层面也独立进去，不便与业务数据进行别离精细化治理。益处还有：咱们能够别离监控长期表空间、数据表空间、wal日志、谬误日志，晓得各个局部占用状况，如果磁盘空间告警，能够针对性采取措施。Greenplum创立长期表空间的办法，比拟规范，如下：

查看长期表的表空间现状，发现都在base目录下，即与数据目录共用

postgres=# select * from pg_relation_filepath('tmp_jc'); pg_relation_filepath----------------------base/13333/t_845345#查问实例的Segment的所有hosts，用于创立长期表空间目录psql -d postgres -c 'select distinct address from gp_Segment_configuration order by 1' -t > sheng_seg_hosts#创立长期表空间的文件目录gpssh -f sheng_seg_hosts -e "ls -l /home/adbpgadmin/tmptblspace"gpssh -f sheng_seg_hosts -e "mkdir -p /home/adbpgadmin/tmptblspace"~$ gpssh -f dg_seg_hosts -e "ls -l /home/adbpgadmin/tmptblspace"# 创立长期表空间postgres=# create tablespace tmp_tblspace location '/home/adbpgadmin/tmptblspace';postgres=# select * from pg_tablespace;   spcname    | spcowner | spcacl | spcoptions--------------+----------+--------+------------ pg_default   |       10 |        | pg_global    |       10 |        | tmp_tblspace |       10 |        |(3 rows)#批改角色的长期表空间postgres=# alter role all set temp_tablespaces='tmp_tblspace';#退出psql，而后从新登录#创立长期表进行验证create temp table tmp_jc2(id int);insert into tmp_jc2 select generate_series(1,10000);#查看表的filepath，发现长期表空间的文件门路不是base目录了select * from pg_relation_filepath('tmp_jc2');--------------------------------------------------- pg_tblspc/2014382/GPDB_6_301908232/13333/t_845369

表空间独立后，监控能够辨别长期表空间、数据表空间、WAL日志、谬误日志进行独立监控和告警，以下是监控采集输入的样例：

~$ sh check_disk_data_size.shusage: sh check_disk_data_size.sh param1 param2, param1 is file recording Segment hosts; param2 data, xlog, log or temp

监控输入的成果如下

图14：监控采集输入示意图

这样能够很分明的理解业务数据或长期表数据在每个节点上的理论size，以及是否存在数据歪斜状况（超过平均值的10%）独自揭示，十分实用。

7 其余优化计划

除了下面详述的优化计划，一般来讲，Greenplum还有一些通用的解决办法：扩容Segment计算节点、业务数据裁剪、备份文件清理。计算节点扩容是最无效的。一般来讲，不论是阿里本人的业务，还是内部客户的业务，数据库的磁盘占用达到60%，思考业务增量便会布局扩容，这些“根本实际”咱们须要通知客户。

业务数据裁剪，除了冷数据外，有一些两头表和历史表，咱们也能够推动业务方做好数据生命周期治理，及时删除或转存归档。另外，对于长期运维操作，留下的备份文件，在操作完后须要及时进行清理，这个简略的习惯是非常容易疏忽的，须要留神。在大库的磁盘治理中，任何小问题都会放大。

四优化收益

1 为客户节约服务器老本

本案例，客户原DB2的数据量大于1PB，而咱们通过上述办法综合优化，在ADB中只保留了300多T的数据，就让整体业务残缺的运行起来。为客户节约了大略100台服务器及相干软件license费用，约合金额千万级别。

2 防止磁盘水位过高造成次生灾祸

磁盘水位高会带来很多问题，通过磁盘空间优化计划，能够防止这些问题的产生。包含：

1.业务略微增长，可能导致磁盘占满，产生“写锁定”，数据库长期罢工；

2.磁盘空间有余时，运维人员定位问题无奈创立长期表；

3.ADB的大表保护，例如vacuum full，无空余磁盘空间应用。

以上磁盘空间优化办法不肯定十分全面，心愿对读者有所帮忙。如果文中有疏漏或读者有补充，欢送多多交换，一起探讨上云老本优化。

名词解释

业务方：指应用Greenplum做业务开发或数据分析的用户，通常是客户或客户的开发商。

OLAP：指联机剖析解决型零碎，是数据仓库零碎最次要的利用，专门设计用于反对简单的大数据量的剖析查询处理，并疾速返回直观易懂的后果。

DML：指减少、删除、批改、合并表数据的SQL，在数据库畛域叫DML型SQL。

PB：1PB=1024TB=1024 * 1024 GB

原文链接
本文为阿里云原创内容，未经容许不得转载。

一 背景形容