Hive是蜂房的意思,爲何hadoop上的這層數據倉庫叫Hive?html
由於生物學上蜂房是一個結構至關精良的建築,取名Hive足見則個數據倉庫在數據存儲上也是堪稱精良的。Hive是Facebook開發的構建於Hadoop集羣之上的數據倉庫應用,它提供了相似於SQL語法的HQL語句做爲數據訪問接口,這使得普通分析人員的應用Hadoop的學習曲線變緩。mysql
第一:Hive是創建在 Hadoop 上的數據倉庫基礎構架。程序員
第二:很低的學習代價即可以讓用戶在Hadoop中進行存儲、查詢和分析存儲的大規模數據。web
簡單的理解:若是用戶只是須要完成大規模數據的分析這件事情,那麼,你只要有一套hadoop環境+一個hive數據庫,只要你懂SQL,你沒必要懂MapReduce程序如何編程、hadoop如何工做,你的SQL需求將自動被編譯到整個集羣中去進行分佈式計算,以提升分析效率。sql
Hive是Facebook開發的構建於Hadoop集羣之上的數據倉庫應用,它提供了相似於SQL語法的HQL語句做爲數據訪問接口,這使得普通分析人員的應用Hadoop的學習曲線變緩。至於Facebook爲何使用Hadoop和Hive組建其數據倉庫,其內部人員分享了他們的一些經歷,大體的過程是以下的:數據庫
1,Facebook的數據倉庫一開始是構建於MySQL之上的,可是隨着數據量的增長某些查詢須要幾個小時甚至幾天的時間才能完成。apache
2,當數據量接近1T的時候,mysqld後臺進程宕掉,這時他們決定將他們數據倉庫轉移到Oracle。固然此次轉移的過程也是付出了很大的代價的,好比支持的SQL方言不一樣,修改之前的運行腳本等等。編程
3,Oracle應付幾T的數據仍是沒有問題的,可是在開始收集用戶點擊流的數據(天天大約400G)以後,Oracle也開始撐不住了,由此又要考慮新的數據倉庫方案。json
4,內部開發人員花了幾周的時間創建了一個並行日誌處理系統Cheetah,這樣的話勉強能夠在24小時以內處理完一天的點擊流數據。緩存
5,Cheetah也存在許多缺點。後來發現了Hadoop項目,並開始試着將日誌數據同時載入Cheetah和Hadoop作對比,Hadoop在處理大規模數據時更具優點,後來將全部的工做流都從Cheetah轉移到了Hadoop,並基於Hadoop作了不少有價值的分析。
6,後來爲了使組織中的多數人可以使用Hadoop,開發了Hive,Hive提供了相似於SQL的查詢接口,很是方便。與此同時還開發了一些其它工具。
7,如今集羣存儲2.5PB的數據,而且以天天15TB的數據在增加,天天提交3000個以上的做業,大約處理55TB的數據...
如今不少大的互聯網公司出於成本考慮都在研究、使用Hadoop;數據的價值正獲得愈來愈多的人的重視,而這種重視,又體現出Hadoop存在的巨大價值。
使用hive的緣由
1 超大數據集設計的計算擴展能力
2 支持HiveSql查詢——簡單,學習代價低
3 統一的元數據管理
淘寶對hive的貢獻
1 UDFs
2 創建、刪除臨時函數
3 GBK支持
4 徹底JDBC
5 Multi Distinct Aggregation支持
6 認證和權限
7 bug fix
淘寶將來對hive的計劃
1 Hive IDE
2 Multi Distinct Aggregation優化
3 Multi Group By優化
4 極限存儲的索引和文件
5 表統計信息的支持
6 採用TFile作列存儲
TDM團隊在Hive上的工做
持續優化Hive的查詢優化器,使SQL更加高效的運行;
不斷引入一些database特性、包括hash join、列存儲、多存儲引擎、SQL/MED等,將成熟的數據庫/並行數據庫理論應用於Hive之上,使它的性能不斷與並行數據倉庫接近;
增強MapReduce層的優化,使MR執行框架更合理高效的執行Hive翻譯的MR代碼。
TDM團隊主要的工做是優化hive的查詢效率。
金融數據信息的與日俱增,使得某些數據表變得極爲龐大,這種大的規模程度用傳統的關係型數據庫查詢語句處理大表的關聯查詢已經遇到了瓶頸。金融數據大表的出現對hive在數據存儲中的應用與發展提供了先決條件。
數據量(行)
表1 2247667 224w
表2 85201483 8520w
表3 28376850 2837w
表4 28735268 2873w
Hive的階段進展
1 在hadoop的平臺架構下,完成hive數據倉庫與mysql、sqlserver以及其餘關係型數據的數據遷移。
2 學習和研究HiveSql查詢語句的優化。其實對於用戶來講,或者說對於Hive程序員來講,優化HiveSql語句是整個工做的主要任務。
3 學習和研究Hive執行過程的優化,這是比較高級別的優化,須要深刻了解Hive和hadoop的原理和過程。
(表相關信息)存在關係數據庫中。
爲何要存在RDBMS中,獲取元數據信息須要很低的延時,這在hdfs上是沒法知足。
分析HiveSQL以後生成的MapReduce任務在運行的時候若是須要訪問元數據信息時,它並不會直接去訪問MetaStore。那麼,他們是如何得到須要的元數據信息的呢?原來,當將生成的物理計劃序列化到plan.xml的時候,已經將相應的元數據信息保存到了plan.xml中。而plan.xml文件以後會被放入Hadoop的分佈式緩存中,因此MapReduce任務就能夠從分佈式緩存中得到須要的元數據信息。
存在hdfs中。
Hive 沒有專門的數據存儲格式,也沒有爲數據創建索引,用戶能夠很是自由的組織 Hive 中的表,只須要在建立表的時候告訴 Hive 數據中的列分隔符和行分隔符,Hive 就能夠解析數據。
第一,不加外部連接建立的表,數據存儲在hive-site.xml配置的${hive.metastore.warehouse.dir} 指定的數據倉庫的目錄下;數據須要load。
例子:
<property>
<name>hive.metastore.warehouse.dir</name>
<value>/user/hive/warehouse</value>
<description>location of default database for the warehouse</description>
</property>
第二,加外部連接穿件的表,數據存在建立表時指定的hdfs路徑下。
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
這些信息屬於元數據信息,能夠去mysql中查看。
Primitive types:
· TINYINT
· SMALLINT
· INT
· BIGINT
· BOOLEAN
· FLOAT
· DOUBLE
· STRING
· BINARY(Note: Only available starting with Hive 0.8.0)
· TIMESTAMP(Note: Only available starting with Hive 0.8.0)
Complex types:
· arrays: ARRAY<data_type>
· maps: MAP<primitive_type, data_type>
· structs: STRUCT<col_name : data_type [COMMENT col_comment], ...>
· union: UNIONTYPE<data_type, data_type, ...>
符合類型的應用:
CREATE TABLE union_test(
foo UNIONTYPE<int, double, array<string>, struct<a:int,b:string>>);
SELECT foo FROM union_test;
{0:1}
{1:2.0}
{2:["three","four"]}
{3:{"a":5,"b":"five"}}
{2:["six","seven"]}
{3:{"a":8,"b":"eight"}}
{0:9}
{1:10.0}
二者大同小異,在語法上基本一致,在數據類型等稍有差別,而這些QL將是用戶與hive進行交互的直接語言!
查詢語言 |
HQL |
SQL |
數據存儲位置 |
HDFS |
Raw Device 或者 Local FS |
數據格式 |
用戶定義 |
系統決定 |
數據更新 |
不支持 |
支持 |
索引 |
無 |
有 |
執行 |
MapRedcue |
Executor |
執行延遲 |
高 |
低 |
可擴展性 |
高 |
低 |
數據規模 |
大 |
小 |
https://cwiki.apache.org/confluence/display/Hive/LanguageManual
DDL:
CREATE TABLE IF NOT EXISTS pokes (foo INT, bar STRING);
CREATE TABLE u_data ( userid INT, movieid INT, rating INT, unixtime STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' STORED AS TEXTFILE;
SHOW TABLES;
ALTER TABLE pokes ADD COLUMNS (new_col INT);
DROP TABLE IF EXISTS pokes;
DML:
LOAD DATA LOCAL INPATH './examples/files/kv1.txt' OVERWRITE INTO TABLE pokes;
Load語句的使用注意Local和overwrite的選擇。
Sql query:
hive> FROM invites a INSERT OVERWRITE TABLE events SELECT a.bar, count(*) WHERE a.foo > 0 GROUP BY a.bar; hive> INSERT OVERWRITE TABLE events SELECT a.bar, count(*) FROM invites a WHERE a.foo > 0 GROUP BY a.bar; ROM invites a INSERT OVERWRITE TABLE events SELECT a.bar, count(*) WHERE a.foo > 0 GROUP BY a.bar; hive> INSERT OVERWRITE TABLE events SELECT a.bar, count(*) FROM invites a WHERE a.foo > 0 GROUP BY a.bar;
hive> FROM pokes t1 JOIN invites t2 ON (t1.bar = t2.bar) INSERT OVERWRITE TABLE events SELECT t1.bar, t1.foo, t2.foo;
載錄 http://www.open-open.com/lib/view/open1341214750402.html
Join查找操做的基本原則:應該將條目少的表/子查詢放在 Join 操做符的左邊。緣由是在 Join 操做的 Reduce 階段,位於 Join 操做符左邊的表的內容會被加載進內存,將條目少的表放在左邊,能夠有效減小發生內存溢出錯誤的概率。
Join查找操做中若是存在多個join,且全部參與join的表中其參與join的key都相同,則會將全部的join合併到一個mapred程序中。
案例:
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1) 在一個mapre程序中執行join
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2) 在兩個mapred程序中執行join
Map join的關鍵在於join操做中的某個表的數據量很小,案例:
SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a join b on a.key = b.key
Mapjoin 的限制是沒法執行a FULL/RIGHT OUTER JOIN b,和map join相關的hive參數:hive.join.emit.interval hive.mapjoin.size.key hive.mapjoin.cache.numrows
因爲join操做是在where操做以前執行,因此當你在執行join時,where條件並不能起到減小join數據的做用;案例:
SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key)
WHERE a.ds='2009-07-07' AND b.ds='2009-07-07'
最好修改成:
SELECT a.val, b.val FROM a LEFT OUTER JOIN b
ON (a.key=b.key AND b.ds='2009-07-07' AND a.ds='2009-07-07')
在join操做的每個mapred程序中,hive都會把出如今join語句中相對靠後的表的數據stream化,相對靠前的變的數據緩存在內存中。固然,也能夠手動指定stream化的表:SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)
Map端聚合,首先在map端進行初步聚合,最後在reduce端得出最終結果,相關參數:
· hive.map.aggr = true是否在 Map 端進行聚合,默認爲 True
· hive.groupby.mapaggr.checkinterval = 100000在 Map 端進行聚合操做的條目數目
數據傾斜聚合優化,設置參數hive.groupby.skewindata = true,當選項設定爲 true,生成的查詢計劃會有兩個 MR Job。第一個 MR Job 中,Map 的輸出結果集合會隨機分佈到 Reduce 中,每一個 Reduce 作部分聚合操做,並輸出結果,這樣處理的結果是相同的 Group By Key 有可能被分發到不一樣的 Reduce 中,從而達到負載均衡的目的;第二個 MR Job 再根據預處理的數據結果按照 Group By Key 分佈到 Reduce 中(這個過程能夠保證相同的 Group By Key 被分佈到同一個 Reduce 中),最後完成最終的聚合操做。
文件數目過多,會給 HDFS 帶來壓力,而且會影響處理效率,能夠經過合併 Map 和 Reduce 的結果文件來消除這樣的影響:
· hive.merge.mapfiles = true是否和並 Map 輸出文件,默認爲 True
· hive.merge.mapredfiles = false是否合併 Reduce 輸出文件,默認爲 False
· hive.merge.size.per.task = 256*1000*1000合併文件的大小
經過left outer join進行查詢,(假設B表中包含另外的一個字段 key1
select a.key from a left outer join b on a.key=b.key where b.key1 is null
經過left semi join 實現 in
SELECT a.key, a.val FROM a LEFT SEMI JOIN b on (a.key = b.key)
Left semi join 的限制:join條件中右邊的表只能出如今join條件中。
Order by 實現全局排序,一個reduce實現,效率低
Sort by 實現部分有序,單個reduce輸出的結果是有序的,效率高,一般和DISTRIBUTE BY關鍵字一塊兒使用(DISTRIBUTE BY關鍵字 能夠指定map 到 reduce端的分發key)
CLUSTER BY col1 等價於DISTRIBUTE BY col1 SORT BY col1
Hive中的每一個分區都對應hdfs上的一個目錄,分區列也不是表中的一個實際的字段,而是一個或者多個僞列,在表的數據文件中實際上並不保存分區列的信息與數據。Partition關鍵字中排在前面的爲主分區(只有一個),後面的爲副分區
靜態分區:靜態分區在加載數據和使用時都須要在sql語句中指定
案例:(stat_date='20120625',province='hunan')
動態分區:使用動態分區須要設置hive.exec.dynamic.partition參數值爲true,默認值爲false,在默認狀況下,hive會假設主分區時靜態分區,副分區使用動態分區;若是想都使用動態分區,須要設置set hive.exec.dynamic.partition.mode=nostrick,默認爲strick
案例:(stat_date='20120625',province)
Hive支持在group by時對同一列進行屢次distinct操做,卻不支持在同一個語句中對多個列進行distinct操做。
注意事項:在使用自定義的mapred腳本時,關鍵字MAP REDUCE 是語句SELECT TRANSFORM ( ... )的語法轉換,並不意味着使用MAP關鍵字時會強制產生一個新的map過程,使用REDUCE關鍵字時會產生一個red過程。
自定義的mapred腳本能夠是hql語句完成更爲複雜的功能,可是性能比hql語句差了一些,應該儘可能避免使用,若有可能,使用UDTF函數來替換自定義的mapred腳本
UDTF將單一輸入行轉化爲多個輸出行,而且在使用UDTF時,select語句中不能包含其餘的列,UDTF不支持嵌套,也不支持group by 、sort by等語句。若是想避免上述限制,須要使用lateral view語法,案例:
select a.timestamp, get_json_object(a.appevents, '$.eventid'), get_json_object(a.appenvets, '$.eventname') from log a;
select a.timestamp, b.*
from log a lateral view json_tuple(a.appevent, 'eventid', 'eventname') b as f1, f2;
其中,get_json_object爲UDF函數,json_tuple爲UDTF函數。
UDTF函數在某些應用場景下能夠大大提升hql語句的性能,如須要屢次解析json或者xml數據的應用場景。
Count和sum函數多是在hql語句中使用的最爲頻繁的兩個聚合函數了,可是在hive中count函數在計算distinct value時支持加入條件過濾。