A. Hadoop 壓縮從理論到實戰
在大數據領域，無論上層計算引擎採用的是什麼，在存儲過程中，壓縮都是一個避不開的問題。合適的壓縮選擇可以降低存儲成本、減少網路傳輸I/O。而錯誤的壓縮選擇則可能讓 cpu 負荷達到瓶頸、降低並發度等等，所以是否選擇壓縮、選擇什麼壓縮格式在大數據存儲環節中都是一個至關重要的問題。
點評：壓縮時間和壓縮率之間的取捨本質上是 cpu 資源和存儲資源的取捨。是否需冊猛要支持分片也不是絕對的，如果單個文件大小均小於 splitSize，則沒必要支持分片。
點評：一階段考慮盡可能支持分片（單個文件大於 splitSize 時）。二階段考慮盡可能快的壓悄姿基縮速度。三階段根據是作為長期歸檔（幾乎不用）or 作為下一作業輸入，考慮盡可能高的壓縮能力 or 支持分片。
點評：有兩點需要注意，第一點：這里的速度和壓縮率沒有具體測試數據，而是給出了一個模糊的表達。因為即使具體測試了速度和壓縮率，也會因數據不同而結果有很大的差異。後面會給出測試的腳本，大家可以結合自己的表數據自行測試。第二點：有些壓縮格式性能參數很相似，為什麼 Hadoop 中要搞這么多種？較為直觀的一個原因是：不同存儲格式支持的壓縮是不一樣的，比如 orc 存儲格式只支持 zlib 和 snappy 兩種壓縮 [8] ，parquet 雖然支持很多壓縮格式，但是不支持 bzip2 [7]
以下摘自《Hadoop The Definitive Guide》
重點閱讀文中加粗片段。大致意思是：因為 gzip 壓縮格式使用的 DEFLATE 壓縮演算法沒辦法做到隨機任意讀取，必須同步順序讀取。也就意味著沒辦法為每一個 block 創建一個分片(split)，然後為該分片啟一個 mapper 去讀取數據。所以即使 gzip 文件有很多 block，MR 程序也只會啟動一個 Mapper 去讀取所有的 block。也即 gzip 這種壓縮格式不支持分片。相反的，如果壓縮格式使用的演算法支持隨機任意讀取，那麼就可以為每一個 block 創建一個分片，同時啟動一個 mapper 去讀取數據，這樣有多少個 block 就有多少個分片，就有多少個 mapper ，這些 mapper 並行讀取數據，效率大大提升。上述涉及到幾個小概念，接下來分別進行詳述。
一句話總結: zlib、gzip 在大數據語境中都是一種 壓縮格式 ，他們使用相同的 壓縮演算法: DEFLATE，DefaultCodec 是 zlib 使用的 編解碼器 ，Gzip 使用的編解碼器是 GzipCodec
我們知道，Hadoop 在任務切分時，是按照文件的粒度進行的。即一個文件一個文件啟謹進行切分。而每一個文件切分成幾塊，取決於 splitSize 的大小。比如兩個文件，第一個文件 300M，第二個文件150M。分片大小是128M，那麼對於第一個文件將會切分成3片（128M，128M，44M），第二個文件會切分成2片（128M，22M）。共計5片。所以分片數量除了由文件數決定，另一個決定因素就是 splitSize 即分片大小。
splitSize 如何計算？
幾個前提：
影響參數：
接下來進行實際驗證：
經過了 2.4.2 中的一系列實驗，驗證了一個結論：當一個輸入格式支持分片時，mapper 數量是無限制的，反之 mapper 數量小於等於文件的數量。所以我們可以通過設置參數來試圖調小分片大小來增加 mapper 數量看其上限是否等於文件數量即可。假如輸入的文件個數只有一個，那麼當 mapper 數量大於1的時候，說明該輸入格式是支持分片的。
大家可以根據自己數據集和想測試的壓縮和存儲格式自行修改腳本。通過以上腳本跑出來的結果如下：
由 2.1 中評價壓縮的三項指標可知，壓縮率、壓縮/解壓速度、是否支持分片是衡量壓縮最重要的三項指標。3.1.1小節中只對壓縮率進行了測試。壓縮/解壓速度可以通過跑一些查詢語句進一步測試。這里就不展開測試了。業界中常用的存儲格式一般是 parquet, orc,所以上面測試除了純文本只測試了這兩種存儲格式。
我們可以通過 hive> set io.compression.codecs; 來查看當前Hadoop集群支持的壓縮，在公司的集群中查詢得到的結果是：
可以看到 lzo 有兩種編解碼器: LzoCodec 和 LzopCodec。他們之間有什麼區別呢？
如果你閱讀過關於 Hadoop 壓縮的文章，應該可以看到，絕大多數文章中對於 snappy 是否支持分片都是直接給出的否定的答案。 CDH 的文檔中也指出來 snappy 是不支持分片的。
看文中加粗片段，雖然 snappy 本身是不支持分片的，但是如果 snappy 存儲在一些特定的存儲格式比如 SequenceFile 或者 Avro 中，那麼是可以支持分片的。也就是說 snappy 是否支持分片是分情況討論的。不能說使用了 snappy 壓縮就一定不支持分片。前面提到了，業界中常用的存儲格式一般是 parquet 或者 orc，而上面 CDH 的文章中恰恰沒有提到 parquet 和 orc 是否支持，接下來以 parquet 為例，進行測試。測試內容即為 parquet + snappy 組合，是否支持分片。
首先准備數據，因為之前做壓縮率測試，已經有了 parquet + snappy 文件了，這里直接拿來用。
一共3個輸入文件，啟了6個mapper，說明輸入文件是可以分片的。即 parquet + snappy 的組合是支持分片的。在《Hadoop The Definitive Guide》中也對 parquet 是否支持分片有說明：
以 maprece.output.fileoutputformat.compress.codec 為例，這個參數可以在三個地方配置：
那麼當三者都設置時，以哪個為准呢？按照經驗來看，一定是粒度小的優先順序大於粒度大的優先順序。經過測試也驗證了這種猜測。即：表級別 > hive > hadoop
初學者往往容易混淆存儲格式和壓縮格式之間的關系，其實二者是完全獨立的。如果完整的閱讀了該篇文章，應該已經消除了這一塊理解對誤區。這里總結一下：比如 parquet, orc，他們都是常見的 存儲格式 。是否使用壓縮，使用何種壓縮都是可以設置的。而 zlib、gzip、lzo、lz4、snappy 等等這些都是常見的 壓縮格式 ，他們既可以依附於某些 存儲格式 ，比如之前提到的 parquet + snappy，orc + zlib 等等。也可以脫離特定的 存儲格式 ，比如純文本文件進行壓縮，text + parquet, text + bzip2 等等。
B. Hive優化之Hive的配置參數優化
Hive是大數據領域常用的組件之一，主要用於大數據離線數倉的運算，關於Hive的性能調優在日常工作和面試中是經常涉及的一個點，因此掌握一些Hive調優是必不可少的一項技能。影響Hive效率的主要因素有數據傾斜、數據冗餘、job的IO以及不同底層引擎配置情況和Hive本身參數和HiveSQL的執行等。本文主要從建表配置參數方面對Hive優化進行講解。
1. 創建一個普通表
table test_user1(id int, name string,code string,code_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',';
2. 查看這張表的信息
DESCRIBE FORMATTED test_user1;
我們從該表的描述信息介紹建表時的一些可優化點。
2.1 表的文件數
numFiles表示表中含有的文件數，當文件數過多時可能意味著該表的小文件過多，這時候我們可以針對小文件的問題進行一些優化，HDFS本身提供了解決方案：
（1）Hadoop Archive/HAR：將小文件打包成大文件。
（2）SEQUENCEFILE格式：將大量小文件壓縮成一個SEQUENCEFILE文件。
（3）CombineFileInputFormat：在map和rece處理之前組合小文件。
（4）HDFS Federation：HDFS聯盟，使用多個namenode節點管理文件。
除此之外，我們還可以通過設置hive的參數來合並小文件。
（1）輸入階段合並
需要更改Hive的輸入文件格式，即參數hive.input.format，默認值是org.apache.hadoop.hive.ql.io.HiveInputFormat，我們改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。這樣比起上面對mapper數的調整，會多出兩個參數，分別是mapred.min.split.size.per.node和mapred.min.split.size.per.rack，含義是單節點和單機架上的最小split大小。如果發現有split大小小於這兩個值（默認都是100MB），則會進行合並。具體邏輯可以參看Hive源碼中的對應類。
（2）輸出階段合並
直接將hive.merge.mapfiles和hive.merge.mapredfiles都設為true即可，前者表示將map-only任務的輸出合並，後者表示將map-rece任務的輸出合並，Hive會額外啟動一個mr作業將輸出的小文件合並成大文件。另外，hive.merge.size.per.task可以指定每個task輸出後合並文件大小的期望值，hive.merge.size.smallfiles.avgsize可以指定所有輸出文件大小的均值閾值，默認值都是1GB。如果平均大小不足的話，就會另外啟動一個任務來進行合並。
2.2 表的存儲格式
通過InputFormat和OutputFormat可以看出表的存儲格式是TEXT類型，Hive支持TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式，可以通過兩種方式指定表的文件格式：
（1）CREATE TABLE ... STORE AS <file_format>:在建表時指定文件格式，默認是TEXTFILE
（2）ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT <file_format>:修改具體表的文件格式
如果要改變創建表的默認文件格式，可以使用set
hive.default.fileformat=<file_format>進行配置，適用於所有表。同時也可以使用set
hive.default.fileformat.managed = <file_format>進行配置，僅適用於內部表或外部表。
擴展：不同存儲方式的情況
TEXT,
SEQUENCE和
AVRO文件是面向行的文件存儲格式，不是最佳的文件格式，因為即便只查詢一列數據，使用這些存儲格式的表也需要讀取完整的一行數據。另一方面，面向列的存儲格式(RCFILE,
ORC, PARQUET)可以很好地解決上面的問題。關於每種文件格式的說明，如下：
（1）TEXTFILE
創建表時的默認文件格式，數據被存儲成文本格式。文本文件可以被分割和並行處理，也可以使用壓縮，比如GZip、LZO或者Snappy。然而大部分的壓縮文件不支持分割和並行處理，會造成一個作業只有一個mapper去處理數據，使用壓縮的文本文件要確保文件不要過大，一般接近兩個HDFS塊的大小。
（2）SEQUENCEFILE
key/value對的二進制存儲格式，sequence文件的優勢是比文本格式更好壓縮，sequence文件可以被壓縮成塊級別的記錄，塊級別的壓縮是一個很好的壓縮比例。如果使用塊壓縮，需要使用下面的配置：set
hive.exec.compress.output=true; set io.seqfile.compression.type=BLOCK
（3）AVRO
二進制格式文件，除此之外，avro也是一個序列化和反序列化的框架。avro提供了具體的數據schema。
（4）RCFILE
全稱是Record Columnar File，首先將表分為幾個行組，對每個行組內的數據進行按列存儲，每一列的數據都是分開存儲，即先水平劃分，再垂直劃分。
（5）ORC
全稱是Optimized Row Columnar，從hive0.11版本開始支持，ORC格式是RCFILE格式的一種優化的格式，提供了更大的默認塊(256M)
（6）PARQUET
另外一種列式存儲的文件格式，與ORC非常類似，與ORC相比，Parquet格式支持的生態更廣，比如低版本的impala不支持ORC格式。
配置同樣數據同樣欄位的兩張表，以常見的TEXT行存儲和ORC列存儲兩種存儲方式為例，對比執行速度。
TEXT存儲方式
總結： 從上圖中可以看出列存儲在對指定列進行查詢時，速度更快， 建議在建表時設置列存儲的存儲方式 。
2.3 表的壓縮
對Hive表進行壓縮是常見的優化手段，一些存儲方式自帶壓縮選擇，比如SEQUENCEFILE支持三種壓縮選擇：NONE，RECORD，BLOCK。Record壓縮率低，一般建議使用BLOCK壓縮；
ORC支持三種壓縮選擇：NONE，ZLIB，SNAPPY。我們以TEXT存儲方式和ORC存儲方式為例，查看錶的壓縮情況。
配置同樣數據同樣欄位的四張表，一張TEXT存儲方式，另外三張分別是默認壓縮方式的ORC存儲、SNAPPY壓縮方式的ORC存儲和NONE壓縮方式的ORC存儲，查看在hdfs上的存儲情況：
TEXT存儲方式
默認壓縮ORC存儲方式
SNAPPY壓縮的ORC存儲方式
NONE壓縮的ORC存儲方式
總結 ：可以看到ORC存儲方式將數據存放為兩個block，默認壓縮大小加起來134.69M，SNAPPY壓縮大小加起來196.67M，NONE壓縮大小加起來247.55M，TEXT存儲方式的文件大小為366.58M，且默認block兩種存儲方式分別為256M和128M，ORC默認的壓縮方式比SNAPPY壓縮得到的文件還小，原因是ORZ默認的ZLIB壓縮方式採用的是deflate壓縮演算法，比Snappy壓縮演算法得到的壓縮比高，壓縮的文件更小。 ORC不同壓縮方式之間的執行速度，經過多次測試發現三種壓縮方式的執行速度差不多，所以建議採用ORC默認的存儲方式進行存儲數據。
2.4 分桶分區
Num Buckets表示桶的數量，我們可以通過分桶和分區操作對Hive表進行優化：
對於一張較大的表，可以將它設計成分區表，如果不設置成分區表，數據是全盤掃描的，設置成分區表後，查詢時只在指定的分區中進行數據掃描，提升查詢效率。要注意盡量避免多級分區，一般二級分區足夠使用。常見的分區欄位：
（1）日期或者時間，比如year、month、day或者hour，當表中存在時間或者日期欄位時，可以使用些欄位。
（2）地理位置，比如國家、省份、城市等
（3）業務邏輯，比如部門、銷售區域、客戶等等
與分區表類似，分桶表的組織方式是將HDFS上的一張大表文件分割成多個文件。分桶是相對分區進行更細粒度的劃分，分桶將整個數據內容按照分桶欄位屬性值得hash值進行區分，分桶可以加快數據采樣，也可以提升join的性能(join的欄位是分桶欄位)，因為分桶可以確保某個key對應的數據在一個特定的桶內(文件)，所以巧妙地選擇分桶欄位可以大幅度提升join的性能。通常情況下，分桶欄位可以選擇經常用在過濾操作或者join操作的欄位。
創建分桶表
create
table test_user_bucket(id int, name string,code string,code_id string )
clustered by(id) into 3 buckets ROW FORMAT DELIMITED FIELDS TERMINATED
BY ',';
查看描述信息
DESCRIBE FORMATTED test_user_bucket
多出了如下信息
查看該表的hdfs
同樣的數據查看普通表和分桶表查詢效率
普通表
分桶表
普通表是全表掃描，分桶表在按照分桶欄位的hash值分桶後，根據join欄位或者where過濾欄位在特定的桶中進行掃描，效率提升。
本文首發於： 數棧研習社
數棧是雲原生—站式數據中台PaaS，我們在github上有一個有趣的開源項目： FlinkX
FlinkX是一個基於Flink的批流統一的數據同步工具，既可以採集靜態的數據，比如MySQL，HDFS等，也可以採集實時變化的數據，比如MySQL
binlog，Kafka等，是全域、異構、批流一體的數據同步引擎，大家如果有興趣，歡迎來github社區找我們玩~
C. 壓縮包在root用戶下解壓過了,怎麼才能把它刪除然後在hadoop用戶下再解壓
如果需要刪除在root用戶下解壓的壓縮包，再在hadoop用戶下解壓，可以按照以下步驟進行：
1. 以root身份登錄系統，找到需要刪除的壓縮包所在目錄，刪除該文件，可以使用命令：sudo rm -f 壓縮包名稱。
2. 切換至hadoop用戶，並切換至需要解壓的目錄。
3. 用hadoop用戶許可權再次下載需要解壓的壓縮包，可以使用cp或wget等命令。
4. 解壓該文件，可以使用unzip或tar等命令進行解壓操作。
需要注意的是，對於需要維護的高級操作，應該充分理解相關命令的用法，避免誤操作誤操作造成不必要的麻煩。
D. 如何在Scala中讀取Hadoop集群上的gz壓縮文件
（1）一個從文件創建的Scala對象，或（2）一個並行切片（分布在各個節點之間），或（3）從其他RDD轉換得來，或（4）改變已有RDD的持久性，如請求將已有RDD緩存在內存中。Spark應用稱為driver，實現單個節點或一組節點上的操作。