hive壓縮文件

⑴ 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社區找我們玩~

⑵ ubuntu 安裝hive下哪個壓縮包 src bin

ubuntu 安裝hive下哪個壓縮包 src bin
不行。 安裝 vm 下載：去官網下 VMware-player-5.0.1-894247.zip 安裝和配置ubanto 下載：去官網下 ubuntu-12.10-desktop-i386.iso 打開vm，載入ubanto iso文件，進行安裝更新 進入ubanto，如果是第一個進入，則需要設置root的密碼

⑶ hadoop文件格式和壓縮

Hadoop中的文件格式大致上分為面向行和面向列兩類：

面向行：TextFile、SequenceFile、MapFile、Avro Datafile

二進制格式文件大小比文本文件大。

生產環境常用，作為原始表的存儲格式，會佔用更多磁碟資源，對它的 解析開銷一般會比二進制格式高 幾十倍以上。

Hadoop API 提供的一種二進制文件，它將數據以<key,value>的形式序列化到文件中。這種二進制文件內部使用Hadoop 的標準的Writable 介面實現序列化和反序列化。它與Hadoop API中的MapFile 是互相兼容的。

MapFile即為排序後的SequeneceFile，它會額外生成一個索引文件提供按鍵的查找。文件不支持復寫操作，不能向已存在的SequenceFile(MapFile)追加存儲記錄，在執行文件寫操作的時候，該文件是不可讀取的。

Avro是一種用於支持數據密集型的二進制文件格式。它的文件格式更為緊湊，若要讀取大量數據時，Avro能夠提供更好的序列化和反序列化性能。並且Avro數據文件天生是帶Schema定義的，所以它不需要開發者在API 級別實現自己的Writable對象。最近多個Hadoop 子項目都支持Avro 數據格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。

面向列：Parquet 、RCFile、ORCFile

RCFile是Hive推出的一種專門面向列的數據格式。 它遵循「先按列劃分，再垂直劃分」的設計理念。當查詢過程中，針對它並不關心的列時，它會在IO上跳過這些列。

ORCFile （Optimized Record Columnar File)提供了一種比RCFile更加高效的文件格式。其內部將數據劃分為默認大小為250M的Stripe。每個Stripe包括索引、數據和Footer。索引存儲每一列的最大最小值，以及列中每一行的位置。

Parquet 是一種支持嵌套結構的列式存儲格式。Parquet 的存儲模型主要由行組（Row Group）、列塊（Column Chuck）、頁（Page）組成。

1、行組，Row Group：Parquet 在水平方向上將數據劃分為行組，默認行組大小與 HDFS Block 塊大小對齊，Parquet 保證一個行組會被一個 Mapper 處理。

2、列塊，Column Chunk：行組中每一列保存在一個列塊中，一個列塊具有相同的數據類型，不同的列塊可以使用不同的壓縮。

3、頁，Page：Parquet 是頁存儲方式，每一個列塊包含多個頁，一個頁是最小的編碼的單位，同一列塊的不同頁可以使用不同的編碼方式。

一般原始表數據使用文本格式存儲，其他的都是列式存儲。

目前在Hadoop中常用的幾種壓縮格式：lzo，gzip，snappy，bzip2,主要特性對比如下：

其性能對比如下：

2.1 lzo

hadoop中最流行的壓縮格式，壓縮/解壓速度也比較快，合理的壓縮率，支持split。適用於較大文本的處理。

對於lzo壓縮，常用的有LzoCodec和lzopCodec，可以對sequenceFile和TextFile進行壓縮。對TextFile壓縮後，mapred對壓縮後的文件默認是不能夠進行split操作，需要對該lzo壓縮文件進行index操作，生成lzo.index文件，map操作才可以進行split。如果設置LzoCodec，那麼就生成.lzo後綴的文件，可以用LzoIndexer 進行支持split的index計算，如果設置LzopCodec，那麼生成.lzo_deflate後綴的文件，不支持建立index。

⑷ 如何檢測hadoop中gz壓縮文件是否損壞

執行hive任務的時候，進入到8088的map詳細進度列表，即是RUNNING MAP attempts in job_1456816082333_1354，查看最後出錯的map是哪個節點或者在頁面直接點擊logs進入詳細log日誌查看，或者進入到節點的Hadoop的logs/userlogs目錄
根據jobid找到對應的目錄： application_1456816082333_1354，裡面有錯誤的文件id，然後刪除掉hdfs的對應的損壞文件。

⑸ hive 中的壓縮格式 rcfile，textfile，sequencefile 各有什麼區別

TextFile：
Hive默認格式，數據不做壓縮，磁碟開銷大，數據解析開銷大。
可結合Gzip、Bzip2、Snappy等使用（系統自動檢查，執行查詢時自動解壓），但使用這種方式，hive不會對數據進行切分，從而無法對數據進行並行操作。

⑹ Hive 資料庫表的基本操作，必須掌握的基本功

說明：hive 的表存放位置模式是由 hive-site.xml 當中的一個屬性指定的，默認是存放在該配置文件設置的路徑下，也可在創建資料庫時單獨指定存儲路徑。

資料庫有一些描述性的屬性信息，可以在創建時添加：

查看資料庫的鍵值對信息

修改資料庫的鍵值對信息

與mysql查詢語句是一樣的語法

刪除一個空資料庫，如果資料庫下面有數據表，那麼就會報錯

強制刪除資料庫，包含資料庫下面的表一起刪除(請謹慎操作)

[]里的屬性為可選屬性，不是必須的，但是如果有可選屬性，會使 sql 語句的易讀性更好，更標准與規范。

例如：[comment '欄位注釋信息'][comment '表的描述信息']等，[external]屬性除外

1. CREATE TABLE
創建一個指定名字的表，如果相同名字的表已存在，則拋出異常提示：表已存在，使用時可以使用IF NOT EXISTS語句來忽略這個異常。

如果創建的表名已存在，則不會再創建，也不會拋出異常提示：表已存在。否則則自動創建該表。

2. EXTERNAL
顧名思義是外部的意思，此關鍵字在建表語句中讓使用者可以創建一個外部表，如果不加該關鍵字，則默認創建內部表。

外部表在創建時必須同時指定一個指向實際數據的路徑（LOCATION），Hive在創建內部表時，會將數據移動到數據倉庫指向的路徑；

若創建外部表，僅記錄數據所在的路徑，不對數據的位置作任何改變。

內部表在刪除後，其元數據和數據都會被一起刪除。
外部表在刪除後，只刪除其元數據，數據不會被刪除。

3. COMMENT
用於給表的各個欄位或整張表的內容作解釋說明的，便於他人理解其含義。

4. PARTITIONED BY
區分表是否是分區表的關鍵欄位，依據具體欄位名和類型來決定表的分區欄位。

5. CLUSTERED BY
依據column_name對表進行分桶，在 Hive 中對於每一張表或分區，Hive 可以通過分桶的方式將數據以更細粒度進行數據范圍劃分。Hive採用對列值哈希，然後除以桶的個數求余的方式決定該條記錄存放在哪個桶當中。

6. SORTED BY
指定表數據的排序欄位和排序規則，是正序還是倒序排列。

7. ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
指定表存儲中列的分隔符，這里指定的是' '，也可以是其他分隔符。

8. STORED AS SEQUENCEFILE|TEXTFILE|RCFILE
指定表的存儲格式，如果文件數據是純文本格式，可以使用STORED AS TEXTFILE，如果數據需要壓縮，則可以使用STORED AS SEQUENCEFILE。

9. LOCATION
指定 Hive 表在 hdfs 里的存儲路徑，一般內部表（Managed Table）不需要自定義，使用配置文件中設置的路徑即可。
如果創建的是一張外部表，則需要單獨指定一個路徑。

1. 使用create table語句創建表
例子：

2. 使用create table ... as select...語句創建表
例子：

使用 create table ... as select ...語句來創建新表sub_student，此時sub_student 表的結構及表數據與 t_student 表一模一樣， 相當於直接將 t_student 的表結構和表數據復制一份到 sub_student 表。

注意：
(1). select 中選取的列名（如果是 * 則表示選取所有列名）會作為新表 sub_student 的列名。

(2). 該種創建表的方式會改變表的屬性以及結構，例如不能是外部表，只能是內部表，也不支持分區、分桶。

如果as select後的表是分區表，並且使用select *，則分區欄位在新表裡只是作為欄位存在，而不是作為分區欄位存在。

在使用該種方式創建時，create 與 table 之間不能加 external 關鍵字，即不能通過該種方式創建外部目標表，默認只支持創建內部目標表。

(3). 該種創建表的方式所創建的目標表存儲格式會變成默認的格式textfile。

3.使用like語句創建表
例子：

注意：
(1). 只是將 t_student 的表結構復制給 sub1_student 表。

(2). 並不復制 t_student 表的數據給 sub1_student 表。

(3). 目標表可以創建為外部表，即:

⑺ hive下導入數據,生成表後的壓縮率大致有多大

hive不做壓縮的，只是在hdfs中移動數據，或是從本地文件系統移動到hdfs。原來是多大就是多大。
如果要壓縮，可以先壓縮好再導入，hive是不會替你做這步的。hive支持gz格式和lzo格式。gz格式原生支持。lzo格式需要某個特殊的serde。

⑻ hive 外部表和內部表 數據壓縮上有區別嗎

Hive中內部表與外部表的區別：
Hive
創建內部表時，會將數據移動到數據倉庫指向的路徑；若創建外部表，僅記錄數據所在的路徑，不對數據的位置做任何改變。在刪除表的時候，內部表的元數據和數據會被一起刪除，而外部表只刪除元數據，不刪除數據。這樣外部表相對來說更加安全些，數據組織也更加靈活，方便共享源數據。
需要注意的是傳統資料庫對表數據驗證是
schema
on
write（寫時模式），而
Hive
在load時是不檢查數據是否符合schema的，hive
遵循的是
schema
on
read（讀時模式），只有在讀的時候hive才檢查、解析具體的數據欄位、schema。
讀時模式的優勢是load
data
非常迅速，因為它不需要讀取數據進行解析，僅僅進行文件的復制或者移動。
寫時模式的優勢是提升了查詢性能，因為預先解析之後可以對列建立索引，並壓縮，但這樣也會花費要多的載入時間。

⑼ hive的幾種文件格式

hive文件存儲格式包括以下幾類：

1、TEXTFILE

2、SEQUENCEFILE

3、RCFILE

4、ORCFILE(0.11以後出現)

其中TEXTFILE為默認格式，建表時不指定默認為這個格式，導入數據時會直接把數據文件拷貝到hdfs上不進行處理；

SEQUENCEFILE，RCFILE，ORCFILE格式的表不能直接從本地文件導入數據，數據要先導入到textfile格式的表中， 然後再從表中用insert導入SequenceFile,RCFile,ORCFile表中。

前提創建環境：

hive 0.8

創建一張testfile_table表，格式為textfile。

create table if not exists testfile_table( site string, url string, pv bigint, label string) row format delimited fields terminated by ' ' stored as textfile;

load data local inpath '/app/weibo.txt' overwrite into table textfile_table;

一、TEXTFILE
默認格式，數據不做壓縮，磁碟開銷大，數據解析開銷大。
可結合Gzip、Bzip2使用(系統自動檢查，執行查詢時自動解壓)，但使用這種方式，hive不會對數據進行切分，
從而無法對數據進行並行操作。
示例：

總結:
相比TEXTFILE和SEQUENCEFILE，RCFILE由於列式存儲方式，數據載入時性能消耗較大，但是具有較好的壓縮比和查詢響應。數據倉庫的特點是一次寫入、多次讀取，因此，整體來看，RCFILE相比其餘兩種格式具有較明顯的優勢。

⑽ hive性能優化及參數調優

記錄一下自己在工作中經常用到的幾個參數設置，從調整的實際效果看還是有效果的。

企業相關伺服器資源配置：平均600台active的節點，

每個節點可用的內存在200G左右，可用的memory total：116T

1、**set hive.exec.parallel=true;**

開啟job的並行：基本每個hql腳本都會開啟這個參數，默認並行度為8，

在集群資源充足的情況下，可以提高job並行的數量：

set hive.exec.parallel.thread.number=16;  (企業生產中我是很少用到這個的，都是用的默認值，因為太消耗資源怕影響別的任務，搞不好會被運維抓住，郵件通報批評！當然使用時還是看具體情況吧！)

因為需求中一張表的job的數量每次基本都在20個以上，在相關維度多，涉及到的欄位邏輯復雜的情況下，

一張表中job的數量會超過100個，之前做的一個需求中insert插入的腳本中job的數量達到了169個，

在測試環境運行的時候只用了一個小時就跑完了，數據量在一億條左右，大概有一百多G。

2、**set hive.map.aggr=true；**

在map端中會做部分聚集操作，效率更高但需要更多的內存，可以根據自己企業的資源情況來設置，

如果我的腳本涉及到的數據量不大的話，我一般不會開啟這個參數。

3、**set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;**

hive0.5開始的默認值，執行map前進行小文件合並，在一個job中生成的map的數量很多的時候，

和第二個參數一起開啟配合使用，在實際生產中多次驗證發現可以減少一倍以上的map數量。

在開啟前我的一個job的map數量有577個，開啟後的map的數量只有196個，極大提高程序的運行效率。

4、**set mapred.max.split.size=256000000；**

每個Map(一個切片的)最大輸入大小(這個值決定了合並後文件的數量)，和第3個參數配合一起使用

默認值也是256000000，

mapred.min.split.size默認值是10000000

dfs.block.size默認是128M，這個參數通過hive來更改是沒有實際用的，只能通過hdfs來修改

***實際在hive中，並不是split的大小要小於等於blocksize，而是可以遠大於blocksize，為什麼？？？(map的數量)***

<1>當hive需要處理的文件是壓縮，且壓縮演算法不支持文件切分的時候，決定map個數的因素主要是文件塊實際存儲的大小，

如果文件塊本身很大，比如500Mb左右，那麼每個map處理的splitsize至少要是500Mb左右。

這個時候我們不能人為通過參數降低每個map的splitsize來增加map個數，只能通過增加splitsize，減少map個數,

如果hive處理的文件是壓縮模式，且壓縮模式不支持文件切分，那麼這個時候我們只能通過控制參數來減少map個數，而不能通過配置參數來增加map個數，所以Hive對於壓縮不可切分文件的調優有限

<2>如果Hive處理的的文件為非壓縮格式或者壓縮可切分，且inputFormat為CombineHiveInputFormat時，

則控制map個數是由以下四個參數起作用，關於這四個參數作用優先順序與使用注意事項請參考如下：

一般來講這幾個參數的結果大小要滿足以下條件：

max.split.size >= min.split.size >= min.size.per.node >= min.size.per.rack

幾個參數的作用優先順序為：

max.split.size <= min.split.size <= min.size.per.node <= min.size.per.rack

總結：所以對於控制map的個數進行調優，首先需要看是否開啟了壓縮，壓縮演算法是否支持切分，參數的設置等等！

5、**set mapred.min.split.size.per.node=256000000；**

一個節點上split的至少的大小(這個值決定了多個DataNode上的文件是否需要合並) ，

和第3和第4個參數一起配合使用。

6、**set mapred.min.split.size.per.rack=256000000；**

一個交換機下split的至少的大小(這個值決定了多個交換機上的文件是否需要合並) ，

也適合第3，4，5的參數一起配合使用。

7、**set hive.exec.mode.local.auto=true；**

開啟本地模式，這個參數在自己學習中可能經常用到，但是在實際生產中用到的還是比較少，

因為這個參數開啟後，針對的是小數據集，在單台機器上處理所有的任務，對生產中的任務不適用！

8、**set hive.exec.recers.bytes.per.recer=512*1000*1000；**

每個rece任務處理的數據量，默認為256M，在hive0.14.0之前默認是1G，我們公司設置的是512M，寫的是512*1000*1000因為在網路傳輸中用的是1000，而不是1024機制，

將該參數值調小可以增加rece的數量，提高運行的效率，

當然也不是rece的數量越多越好，因為啟動和初始化rece都是會消耗資源和時間的，

而且有多少個rece就會有多少個輸出文件，如果這些文件作為下一個任務的輸入，就會造成小文件過多的問題

9、**hive.exec.recers.max**

每個任務最大的rece數，默認為1009，在hive0.14.0之前默認是999

計算recer數的公式很簡單N=min(參數9，總輸入數據量/參數8)

即，如果rece的輸入（map的輸出）總大小不超過1G,那麼只會有一個rece任務；

10、**set mapred.rece.tasks = 15；**

設置rece的個數(在實際生產中謹慎使用)

那麼什麼時候可以進行手動設定rece數量呢？比如系統自動計算的rece個數，因為集群資源不足，

造成程序運行出現OOM(內存溢出不足)時，可以根據推定的rece個數手動增加數量，保證程序在跑的慢的基礎上可以完整運行

那麼在什麼情況下只有一個rece呢？

<1>、當map的輸出文件小於hive.exec.recers.bytes.per.recer時

<2>、手動設置set mapred.rece.tasks =1時

<3>、使用了order by時(全局排序會使用一個rece去處理)

<4>、表關聯時出現笛卡爾積

<5>、單獨使用count時，比如：select count(*) from tablename，

如果改寫加入了group by配合使用就不會出現一個rece，比如：select sign_date,count(*) from tablename group by sign_date;

11、**set mapred.job.reuse.jvm.num.tasks=10；**

用於避免小文件的場景或者task特別多的場景，這類場景大多數執行時間都很短，因為hive調起maprece任務，JVM的啟動過程會造成很大的開銷，尤其是job有成千上萬個task任務時，JVM重用可以使得JVM實例在同一個job中重新使用N次

12、**set hive.exec.dynamic.partition=true；**

表示開啟動態分區功能

13、**set hive.exec.dynamic.partition.mode=nonstrict；**

表示允許所有分區都是動態的，

默認是strict，表示必須保證至少有一個分區是靜態的

14、**set hive.groupby.skewindata=true；**

有數據傾斜的時候進行負載均衡 ，決定group by操作是否支持傾斜數據，其實說白了就相當於MR中的conbiner做了一次預聚合。

注意：只能對單個欄位聚合。

控制生成兩個MR Job,第一個MR Job Map的輸出結果隨機分配到rece中減少某些key值條數過多某些key條數過小造成的數據傾斜問題。

在第一個 MapRece 中，map 的輸出結果集合會隨機分布到 rece 中， 每個rece 做部分聚合操作，並輸出結果。這樣處理的結果是，相同的 Group By Key 有可能分發到不同的rece中，從而達到負載均衡的目的；

第二個 MapRece 任務再根據預處理的數據結果按照 Group By Key 分布到 rece 中（這個過程可以保證相同的 Group By Key 分布到同一個 rece 中），最後完成最終的聚合操作

15、**set hive.auto.convert.join=true；**

開啟map join

16、**set hive.mapjoin.smalltable.filesize=512000000；**

map join的小表的大小，也是開啟和關閉map join的閾值

17、**hive.exec.compress.output=true；**

開啟壓縮，我們公司使用的是默認的壓縮演算法deflate

壓縮演算法有：<1>、org.apache.hadoop.io.compress.GzipCodec,

  <2>、org.apache.hadoop.io.compress.DefaultCodec,

  <3>、com.hadoop.compression.lzo.LzoCodec,

  <4>、com.hadoop.compression.lzo.LzopCodec,

  <5>、org.apache.hadoop.io.compress.BZip2Codec

使用的壓縮演算法：

set maprece.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.DefaultCodec

**針對上述小文件合並的三個參數值做以下解釋：**

大於文件塊大小128m的，按照128m來分隔，小於128m,大於100m的，按照100m來分隔，把那些小於100m的（包括小文件和分隔大文件剩下的），進行合並