整體說明
- 會進行此次檢測的背景介紹，通過官方以及自己的學習了解進行一些基礎解釋；
- 使用具體的線上資料進行壓縮比，查詢性能的測驗；
- 查詢性能的不同場景，大資料計算、用戶查詢性能等，包含Spark以及Impala的性能測驗【這部分都是生產中會實際遇到的，希望能給大家闡述的清晰】；
- 包含具體生產場景的專案選型；
背景
- 當前背景為生產中真是遇到的問題，并且進行測驗和選型；
- 當前資料層作為資料湖的上游，作為所有資料分析的基礎，資料倉庫的程序以及所有服務的資料來源，滿足各種場景是實際生產中所需要的，包括資料倉庫、標簽層建設等Spark資料處理，分析團隊Impala資料查詢，各類BI類查詢，統一資料底座資料湖資料置入DW；
存盤編碼說明
| file format | characteristics | hive storage option |
|---|---|---|
| TextFile | 純文本 | STORED AS TEXTFILE |
| SequenceFile | 基于行，二進制鍵值，可分割 | STORED AS SEQUENCEFILE |
| Avro | 基于行，二進制或JSON，可拆分 | STORED AS AVRO |
| RCFile | 列式存盤, RLE【游程編碼】 | STORED AS RCFILE |
| ORCFile | Optimized RC, Flatten | STORED AS ORC |
| Parquet | 列式二進制編碼 | STORED AS PARQUET |
TextFile
- 資料不做壓縮，磁盤開銷大，資料決議開銷大，
Parquet
- Parquet檔案是以二進制方式存盤的，所以是不可以直接讀取的，檔案中包括該檔案的資料和元資料，因此Parquet格式檔案是自決議的，
- Impala推薦使用parquet格式，不支持ORC,Rcfile
壓縮格式說明
| compression format | characteristics | splittable |
|---|---|---|
| GZip | 比Snappy或LZO占用更多的CPU資源;提供更高的壓縮比;對于冷資料來說，這是一個很好的選擇 | no |
| BZip2 | 比GZip壓縮更大 | yes |
| LZO | 熱資料的更好選擇 | yes if indexed |
| LZ4 | 明顯快于LZO | no |
| Snappy | 性能優于LZO，是熱資料的更好選擇 | yes |
Snappy
- 用于大資料快速的查詢，和Parquet聯用支持分隔，為快而生，查詢程序中減少大量的IO；
空間壓縮效果實測
說明
資料表說明
- 程序中使用的是兩張分別為100個欄位，資料量為8500w的資料表；
不同形式壓縮效果
textfile
- 38.9 G 116.8 G
parquet
- 4.1 G 12.2 G
parquet+snappy
- 4.2 G 12.7 G
Impala查詢實測
說明
資料表說明
- 程序中使用的是兩張分別為100個欄位，資料量為8500w的資料表；
測驗方法說明
- python直連Impala集群，每單一次查詢都進行Impala的connect和close，每個查詢分別進行10次，并且計算平均值；
單表條件聚合計算
50個欄位的textfile
平均值為: 1.2
{0: 1, 1: 2, 2: 1, 3: 1, 4: 1, 5: 1, 6: 2, 7: 1, 8: 1, 9: 1}
textfile
平均值為: 1.6
{0: 2, 1: 2, 2: 1, 3: 2, 4: 1, 5: 2, 6: 2, 7: 1, 8: 1, 9: 2}
parquet磁區表
平均值為: 0.8
{0: 2, 1: 0, 2: 1, 3: 1, 4: 1, 5: 0, 6: 1, 7: 1, 8: 1, 9: 0}
textfile磁區表
平均值為: 2.1
{0: 7, 1: 1, 2: 2, 3: 1, 4: 2, 5: 2, 6: 1, 7: 2, 8: 1, 9: 2}
parquet+snappy磁區表
平均值為: 1.3
{0: 2, 1: 1, 2: 1, 3: 2, 4: 1, 5: 1, 6: 1, 7: 2, 8: 1, 9: 1}
多表關聯后聚合計算
50個欄位的textfile
平均值為: 2.7
{0: 3, 1: 2, 2: 2, 3: 2, 4: 3, 5: 2, 6: 4, 7: 3, 8: 3, 9: 3}
textfile
平均值為: 2.9
{0: 4, 1: 3, 2: 3, 3: 2, 4: 3, 5: 3, 6: 2, 7: 3, 8: 3, 9: 3}
parquet磁區表
平均值為: 34.5
{0: 28, 1: 29, 2: 29, 3: 31, 4: 30, 5: 59, 6: 32, 7: 45, 8: 33, 9: 29}
textfile磁區表
平均值為: 26.8
{0: 25, 1: 28, 2: 27, 3: 27, 4: 26, 5: 27, 6: 27, 7: 27, 8: 27, 9: 27}
parquet+snappy磁區表
平均值為: 2.9
{0: 3, 1: 3, 2: 3, 3: 3, 4: 3, 5: 3, 6: 2, 7: 3, 8: 3, 9: 3}
專案選型
使用場景
- 資料倉庫、標簽層建設等Spark資料處理；
- 分析團隊Impala資料查詢，各類BI類查詢；
- 統一資料底座資料湖資料置入DW；
目標
- 能夠滿足所有的使用場景，在滿足使用場景的情況下查詢效率更高，盡量少的占用磁盤空間；
選型結論
- TextFile一定不會使用，很占用磁盤空間，那么一定需要選型資料編碼格式；
- 在資料倉庫以及標簽層建設中都是基于一部分粒度的一部分資料的計算，所以列式存盤占優，那么存盤編碼選型就壓在了RCFile、ORCFile、Parquet；
- 在是否選擇壓縮程序中我們的考量，既能滿足寫入的效率不低，又能滿足查詢的效率足夠高；經過測驗，實際上添加壓縮對于寫入的效率影響不大，后續我會補充這部分的實際測驗程序；那么在壓縮格式中挑選，壓縮比高、支持分隔（目前大資料條件下必備），查詢效率高，經過實際測驗Snappy完全符合條件；
- 最終的編碼選型，因為使用場景要滿足分析團隊的Impala查詢，Parquet直接成為首選；
- Parquet+Snappy
結論
空間壓縮效果
- parquet+snappy >= Parquet >> TextFile
Impala查詢效果
單表聚合查詢
- 效率基本一致；
多表聯合聚合查詢
- parquet+snappy磁區表 = TextFile未磁區 >> TextFile磁區表 > parquet磁區表
Spark查詢效果
- 因為專案中都在使用，并且Spark并行執行下效率差不是特別明顯，所以此處暫時不做效率測驗；
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423964.html
標籤：其他
上一篇：pandas使用query函式基于判斷條件獲得dataframe中滿足條件的資料行(row)的索引串列（index of rows matching conditions in dataframe）
下一篇：GTD全球恐怖主義可視化系統