redshift – Page 2 – Gea-Suan Lin's BLOG

Amazon Redshift 的 Data Ingestion

在 AWS 放出的「Amazon redshift migration and load data 20150722」這份投影片則是解釋了 data ingestion 時的建議行為。

其實這張就道盡目前 Amazon Redshift 架構上的最佳作法，也就是每次都 TRUNCATE 掉重新 import。後面的所有方法其實都是 workaround，效能不會太好... XD

另外後面是介紹倒資料進 Amazon Redshift 的方式，官方是還蠻推 AWS Data Pipeline，但你用過就會知道有多麻煩與痛苦...

在「Amazon redshift optimizing performance 20150721」這篇給了不少效能調校的細節，這邊的效能調校都是針對多機器時的設計規劃 (multi nodes)。

本文圖多並且穿插大量文字，但應該是可以輕鬆讀。我從中選了重點投影片出來，在讀完這篇導讀後建議再點進去從頭讀一次，會對 Amazon Redshift 有更多了解。

第一個主題是資料的放置方式，有這幾種：

中間還有好幾張投影片是說明測試資料的類型，測試出來的結果可以看到效能還是差很多：

再來是講資料不平均當然會造成沒辦法充分運用機器效能：

然後給了一些建議：

接下來是講 sort keys 有三種，其中 interleaved 很特別，有興趣的可以研究看看，不然 compound keys 應該是已經很好用了：

接下來是每個欄位都可以設定壓縮格式，可以看到壓縮的部份如果設計的好，效能也會上升不少：

然後原始資料可以儘量拆成多個檔案再匯入 Amazon Redshift，這樣可以加速進行：

最後則是 VACUUM 的操作介紹，如果可以允許完整 deep copy 的話會更好，因為這算是最乾淨的作法：

是份很有用的投影片 :p

會把 query 的步驟拆成多個步驟，針對比較吃資源的步驟標出來，讓設計的人可以思考要怎麼改。

這邊的 Amazon Redshift 都是跑在 Oregon (us-west-2)，前者的價錢是 USD$9.6/hour，後者是 USD$8/hour，大約貴一些。這是同一個 query 跑過多次後穩定的數字，用 PostgreSQL 的 \timing 出來的數字計算。

先從比較簡單的 query 開始，這個表格大約六億筆資料，如果以記憶體大小算的話，是 memory-fit。

前者是：

dev=# SELECT COUNT(DISTINCT x) FROM t;
 count  
--------
 925612
(1 row)

Time: 3345.946 ms

後者是：

dev=# SELECT COUNT(DISTINCT x) FROM t;
 count  
--------
 925612
(1 row)

Time: 2145.132 ms

再來條件多一點，一樣前者是：

dev=# SELECT x, COUNT(*) AS cnt FROM t GROUP BY x ORDER BY cnt DESC LIMIT 20;
...
(20 rows)

Time: 2121.002 ms

後者是：

dev=# SELECT x, COUNT(*) AS cnt FROM t GROUP BY x ORDER BY cnt DESC LIMIT 20;
...
(20 rows)

Time: 1388.102 ms

發現比較貴的 cluster 的反而比較慢 (大台 dw2.8xlarge 組成的)，用多台小台的去堆反而比較快。晚點找時間測沒辦法 memory-fit 的速度。

意外的跟直覺不太一樣，要測過才知道...