簡介：本文我們將通過一個實際的磁盤空間優化案例來說明，如何幫助客戶做成本優化。

作者 | 玉翮
來源 | 阿里技術公眾號

一 背景描述

目前，企業的核心數據一般都以二維表的方式存儲在數據庫中。在核心技術自主可控的大環境下，政企行業客戶都在紛紛嘗試使用國產數據庫或開源數據庫，尤其在數據倉庫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如下：

SELECTPSUI.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

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的ADBPGGreenplum成本优化之磁盘水位管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。