Ⅰ 大數據開發工程師Hive(Hive如何進行優化)
1數據存儲及壓縮優化
針對hive中表的存儲格式通常有textfile和orc，壓縮格式一般使用snappy。相比於 textfile格式存儲，orc佔有更少的存儲。因為hive底層使用MR計算架構，數據流是hdfs到磁碟再到hdfs，而且會有很多次IO讀寫操作，所以使用orc數據格式和snappy壓縮策略可以降低IO讀寫，還能降低網路傳輸量，這樣在一定程度上可以節省存儲空間，還能提升hql的執行效率；
2 Hive Job優化
①調節Jvm參數，重用Jvm；
②合理設置Map個數；
③合理設置Rece個數；
3 Sql語法優化
① 建表優化 ：
1) Hive創建表的時候，可以建分區表，分桶表；
2) Hive創建表的時候，可以指定數據存儲格式：TextFile、SequenceFile、RCfile 、ORCfile；
② 查詢時優化 ：
1) 列裁剪，在查詢時只讀取需要的列，避免全列掃描，不要使用select * from table；
2) 分區裁剪：在查詢時只讀取需要分區的數據，避免全表掃描；
3) 開啟謂詞下推：set hive.optimize.ppd = true，默認是true：
a. 將Sql語句中的where謂詞邏輯都盡可能提前執行，減少下游處理的數據量；
4) 大表join小表：
a. 開啟MapJoin：set hive.auto.convert.join=true：
b. MapJoin是將Join雙方比較小的那個表直接分發到各個Map進程的內存中，在 Map進程中進行Join操作， 這樣就不用進行Rece步驟 ，從而提高了速度( 大表left join小表才有效 ，小表left join大表會失效)；
5) 大表join大表：
a. SMB Join ：Sort Merge Bucket Join(數據不僅分桶了，而且每個桶數據是排好序了)；
b. 開啟SMB Join之後，底層是根據兩個表join欄位進行分桶存儲，這樣的話，兩張表就變為了基於桶之間join關聯查詢，而不是基於整張表的join，減少了笛卡爾積；
6) 少用in，用left semi join替代in：
a. 原始寫法：select a.id, a.name from a where a.id in (select b.id from b)；
b. 用join改寫：select a.id, a.name from a join b on a.id = b.id；
c. left semi join改寫：select a.id, a.name from a left semi join b on a.id = b.id；
7) 用union all代替union，因為union all不需要去重，也不需要排序，效率高於union；
(每天1小題，進步1點點)
Ⅱ 數據倉庫-Hive基礎（七） Hive 的壓縮優化
一般用orc或者parquet
orc
結尾加上 STORED AS orc ，同理，用Parquet模式我們加上 STORED AS PARQUET ;
一般SNAPPY壓縮和解壓縮比比較高，所以一般如果壓縮就用snappy，結尾加上 tblproperties ("orc.compress"="SNAPPY"); 即可
在實際的項目開發當中，hive表的數據存儲格式一般選擇：orc或parquet。壓縮方式一般選 擇snappy。
Ⅲ Hive支持的數據類型
#整型
TINYINT — 微整型，只佔用1個位元組，只能存儲0-255的整數。
SMALLINT– 小整型，佔用2個位元組，存儲范圍–32768 到 32767。
INT– 整型，佔用4個位元組，存儲范圍-2147483648到2147483647。
BIGINT– 長整型，佔用8個位元組，存儲范圍-2^63到2^63-1。
#布爾型
BOOLEAN — TRUE/FALSE
#浮點型
FLOAT– 單精度浮點數。
DOUBLE– 雙精度浮點數。
#字元串型
STRING– 不設定長度。
Structs：一組由任意數據類型組成的結構。比如，定義一個欄位C的類型為STRUCT {a INT; b STRING}，則可以使用a和C.b來獲取其中的元素值；
Maps：和Java中的Map相同，即存儲K-V對的；
Arrays：數組；
復雜數據類型的聲明必須使用尖括弧指明其中數據欄位的類型。定義三列，每列對應一種復雜的數據類型，如下所示。
TEXTFILE //文本，默認值
SEQUENCEFILE // 二進制序列文件
RCFILE //列式存儲格式文件 Hive0.6以後開始支持
ORC //列式存儲格式文件，比RCFILE有更高的壓縮比和讀寫效率，Hive0.11以後開始支持
PARQUET //列出存儲格式文件，Hive0.13以後開始支持
#參考博客：
http://lxw1234.com/archives/2015/06/238.htm
http://www.cnblogs.com/zlslch/p/5659714.html
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types
#
Ⅳ hive的數據存儲
首先，Hive 沒有專門的數據存儲格式，也沒有為數據建立索引，用戶可以非常自由的組織 Hive 中的表，只需要在創建表的時候告訴 Hive 數據中的列分隔符和行分隔符，Hive 就可以解析數據。
其次，Hive 中所有的數據都存儲在 HDFS 中，Hive 中包含以下數據模型：表(Table)，外部表(External Table)，分區(Partition)，桶(Bucket)。
Hive 中的 Table 和資料庫中的 Table 在概念上是類似的，每一個 Table 在 Hive 中都有一個相應的目錄存儲數據。例如，一個表 pvs，它在 HDFS 中的路徑為：/wh/pvs，其中，wh 是在 hive-site.xml 中由 ${hive.metastore.warehouse.dir} 指定的數據倉庫的目錄，所有的 Table 數據（不包括 External Table）都保存在這個目錄中。
Partition 對應於資料庫中的 Partition 列的密集索引，但是 Hive 中 Partition 的組織方式和資料庫中的很不相同。在 Hive 中，表中的一個 Partition 對應於表下的一個目錄，所有的 Partition 的數據都存儲在對應的目錄中。例如：pvs 表中包含 ds 和 city 兩個 Partition，則對應於 ds = 20090801, ctry = US 的 HDFS 子目錄為：/wh/pvs/ds=20090801/ctry=US；對應於 ds = 20090801, ctry = CA 的 HDFS 子目錄為；/wh/pvs/ds=20090801/ctry=CA
Buckets 對指定列計算 hash，根據 hash 值切分數據，目的是為了並行，每一個 Bucket 對應一個文件。將 user 列分散至 32 個 bucket，首先對 user 列的值計算 hash，對應 hash 值為 0 的 HDFS 目錄為：/wh/pvs/ds=20090801/ctry=US/part-00000；hash 值為 20 的 HDFS 目錄為：/wh/pvs/ds=20090801/ctry=US/part-00020
External Table 指向已經在 HDFS 中存在的數據，可以創建 Partition。它和 Table 在元數據的組織上是相同的，而實際數據的存儲則有較大的差異。
Table 的創建過程和數據載入過程（這兩個過程可以在同一個語句中完成），在載入數據的過程中，實際數據會被移動到數據倉庫目錄中；之後對數據對訪問將會直接在數據倉庫目錄中完成。刪除表時，表中的數據和元數據將會被同時刪除。 External Table 只有一個過程，載入數據和創建表同時完成（CREATE EXTERNAL TABLE ……LOCATION），實際數據是存儲在 LOCATION 後面指定的 HDFS 路徑中，並不會移動到數據倉庫目錄中。當刪除一個 External Table 時，僅刪除元數據，表中的數據不會真正被刪除。
Ⅳ Hive insert 欄位表錯位踩坑
往 Hive 表 insert 數據後，查詢時出現個別行欄位錯位，插入語句如下：
首先測試源表數據查詢：
查詢來的數據沒發現有什麼異常；照理說逐欄位查出來沒問題，再逐欄位插入應該不會錯位。實際上 hive 的 insert 跟想像中傳統的 insert 不太一樣。
由於不是全表錯位，而是個別行錯位，首先根據關鍵字查詢 hive 錯位那行數據，導出文本到本地。肉眼查看發現有部分"亂碼"(異常字元: ^M ，如果經驗豐富一眼就能看出這個是 \001 ，vim 下可以通過組合鍵 ctrl + a 輸出），懷疑是異常字元導致，通過 linux od 命令查看 16 進制編碼，如圖所示：有好幾個 \001 ，多麼眼熟的數字啊 - 這是 hive 默認欄位分隔符。
一般 insert A from select B 我們沒有關注 A 表的欄位分隔符，看到 \001 直覺跟 A 表的欄位分隔符有關：
查看 A 的表結構，欄位分隔符默認的 \001 。存儲類型： textfile 。
進一步分析：textfile 是 hive 默認的存儲結構，行存儲，存儲的實際數據結構跟表邏輯結構一致。導入數據時會直接把數據文件拷貝到 hdfs上不進行處理。源文件可以直接通過hadoop fs -cat 查看； 例如 text 欄位分隔符: \001 , 換行符: \n，表在 hdfs 實際存儲的格式為：
v1\001v2\001v3\n
v4\001v5\001v5
猜測欄位值缺失錯位的根源在於：文本中的不可見字元 \001 插入到表中，而表以 \001 作為欄位分隔符，導致查詢欄位錯位。
再來看這條 SQL：
我們可以還原這條 SQL 從插入到查詢異常的全流程:
第一種方式可行且更加合理；
第二種方式可行，一種補救方案，但是 orc 等格式不支持 load 操作
第三種方式臨時解決問題，不能根本上解決問題；
對 hive 的基礎知識了解不足，導致問題出現排查速度較慢。
數據源頭進行必要的數據 ETL 清洗，對欄位分隔符的處理必須謹慎。
Hive 表盡可能使用 orc parquet 這類存儲方式，空間佔用，查詢效率相對 textfile 有大幅提升，同時可以規避欄位分隔符，錯位等問題。
更深入一步 了解 hive orc 這類存儲方式實現原理。
Ⅵ 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分桶表的儲存格式是什麼固定的還是可以隨意指定
對於每一個表或者是分區，Hive可以進一步組織成桶，也就是說桶是更為細粒度的數據范圍劃分。Hive是針對某一列進行分桶。Hive採用對列值哈希，然後除以桶的個數求余的方式決定該條記錄存放在哪個桶中。分桶的好處是可以獲得更高的查詢處理效率。使取樣更高效
hive表數據是在hdfs中儲存的並沒有固定的儲存格式，hive只保存管理表元數據。
桶就是將數據表由一個文件存儲分為多個文件存儲
分桶語法:
create table t_buck(id string,name string)
clustered by (id) into 4 buckets;
指定了根據id分成4個桶,最好的導入數據方式是insert into table.
要開啟模式開關
set hive.enforce.bucketing = true;
set maprece.job.reces=4;
查詢時cluster by指定的欄位就是partition時分區的key
Ⅷ 【大數據-數倉】HIVE下的文件存儲遇到的一個問題（TEXTFILE、RCFILE）
問題：
Failed with exception Wrong file format. Please check the file's format.
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MoveTask
解決：
當遇到這個問題時，可以肯定一點的是，文件的格式和建表時指定的存儲格式是不一致的。
由此可以定位到問題出在哪裡了。
1.確定數據源的格式：
一般都是txt/csv文件
2.確定建表時指定的存儲格式
show create table table_name;
然後查看：
STORED AS INPUTFORMAT #指定的存儲格式
3.重新建表並修改指定的存儲格式
Ⅸ 「Hive進階篇」詳解存儲格式及壓縮方式
hive優化除了有hql語句邏輯優化，hql參數調優等等，還有一個不起眼的細節容易被忽視掉， 那便是hive數倉模型表的存儲格式和壓縮方式 ，hive底層數據是依託在hadoop，以HDFS文件存儲在集群上的， hive數倉模型表選擇一個合適的存儲格式和壓縮方式也是hive優化的一點 。
本篇就來聊一聊這塊知識點吧。😄
hive主要有textfile、sequencefile、orc、parquet 這四種存儲格式，其中sequencefile很少使用，常見的主要就是orc和parquet這兩種，往往也搭配著壓縮方式合理使用。
建表聲明語句是： stored as textfile/orc/parquet
行式存儲，這是hive表的默認存儲格式，默認不做數據壓縮，磁碟開銷大，數據解析開銷大，數據不支持分片（即代表著會帶來無法對數據進行並行操作）
行列式存儲，將數據按行分塊，每個塊按列存儲，其中每個塊都存儲著一個索引，支持none和zlib和snappy這3種壓縮方式，默認採用zlib壓縮方式，不支持切片，orc存儲格式能提高hive表的讀取寫入和處理的性能。
列式存儲，是一個面向列的二進制文件格式（不可直接讀取），文件中包含數據和元數據，所以該存儲格式是自解析的，在大型查詢時效率很快高效，parquet主要用在存儲多層嵌套式數據上提供良好的性能支持，默認採用uncompressed不壓縮方式。
行存儲引擎 ：同一條數據的不同欄位都在相鄰位置，所以當要查找某一條記錄所有數據時行存儲查詢速度比較快
列存儲引擎 ：以列來聚集數據，相同欄位的值聚集在一起，所以當查詢某一個指定列的所有數據時，列存儲查詢速度比較快
hive主要支持gzip、zlib、snappy、lzo 這四種壓縮方式。
壓縮不會改變元數據的分割性，即壓縮後原來的值不變。
建表聲明語句是： tblproperties("orc.compress"="SNAPPY")
壓縮方式的評判標准主要有以下幾點：
針對壓縮方式做一個小結對比：