Hive數據分析——Spark是一種基於rdd(彈性數據集)的內存分布式並行處理框架,比於Hadoop將大量的中間結果寫入HDFS,Spark避免了中間結果的持久化


轉自:http://blog.csdn.net/wh_springer/article/details/51842496

近十年來,隨着Hadoop生態系統的不斷完善,Hadoop早已成為大數據事實上的行業標准之一。

 

1  Hive基本原理

Hadoop是一個流行的開源框架,用來存儲和處理商用硬件上的大規模數據集。對於HDFS上的海量日志而言,編寫Mapreduce程序代碼對於類似數據倉庫的需求來說總是顯得相對於難以維護和重用,Hive作為一種基於Hadoop的數據倉庫解決方案應運而生,並得到了廣泛應用。

Hive是基於Hadoop的數據倉庫平台,由Facebook貢獻,其支持類似SQL的結構化查詢功能。Facebook設計開發Hive的初衷就是讓那些熟悉sql編程方式的人也可以更好的利用hadoop,hive可以讓數據分析人員只關注於具體業務模型,而不需要深入了解Map/Reduce的編程細節,但是這並不意味着使用hive不需要了解和學習Map/Reduce編程模型和hadoop,復雜的業務需求和模型總是存在的,對於Hive分析人員來說,深入了解Hadoop和Hive的原理和Mapreduce模型,對於優化查詢總有益處。

hive優點:成本低,可以通過類sql語句快速實現簡單或復雜的MapReduce統計。

借助於Hadoop和HDFS的大數據存儲能力,數據仍然存儲於Hadoop的HDFS中,Hive提供了一種類SQL的查詢語言:HiveQL(HQL),對數據進行管理和分析,開發人員可以近乎sql的方式來實現邏輯,從而加快應用開發效率。(關於Hadoop、hdfs的更多知識請參考hadoop官網及hadoop權威指南)

HQL經過解析和編譯,最終會生成基於Hadoop平台的Map Reduce任務,Hadoop通過執行這些任務來完成HQL的執行。

 

1.1   Hive組件

Hive的組件總體上可以分為以下幾個部分:用戶接口(UI)、驅動、編譯器、元數據(Hive系統參數數據)和執行引擎。

1)      對外的接口UI包括以下幾種:命令行CLI,Web界面、JDBC/ODBC接口;

2)      驅動:接收用戶提交的查詢HQL;

3)     編譯器:解析查詢語句,執行語法分析,生成執行計划;

4)     元數據Metadata:存放系統的表、分區、列、列類型等所有信息,以及對應的HDFS文件信息等;

5)     執行引擎:執行執行計划,執行計划是一個有向無環圖,執行引擎按照各個任務的依賴關系選擇執行任務(Job)。

 

需要注意的是,元數據庫一般是通過關系型數據庫MySQL來存儲。元數據維護了庫信息、表信息、列信息等所有內容,例如表T包含哪些列,各列的類型等等。因此元數據庫十分重要,需要定期備份以及支持查詢的擴展性。

 

讀時驗證機制

與傳統數據庫對表數據進行寫時嚴重不同,Hive對數據的驗證方式為讀時模式,即只有在讀表數據的時候,hive才檢查解析具體的字段、shema等,從而保證了大數據量的快速加載。

既然hive采用的讀時驗證機制,那么 如果表schema與表文件內容不匹配,會發生什么呢?

答案是hive會盡其所能的去讀數據。如果schema中表有10個字段,而文件記錄卻只有3個字段,那么其中7個字段將為null;如果某些字段類型定位為數值類型,但是記錄中卻為非數值字符串,這些字段也將會被轉換為null。簡而言之,hive會努力catch讀數據時遇到的錯誤,並努力返回。既然Hive表數據存儲在HDFS中且Hive采用的是讀時驗證方式,定義完表的schema會自動生成表數據的HDFS目錄,且我們可以以任何可能的方式來加載表數據或者利用HDFS API將數據寫入文件,同理,當我們若需要將hive數據寫入其他庫(如Oracle),也可以直接通過api讀取數據再寫入目標庫。在實際生產環境中,當需要數據倉庫之間的遷移時,就可以直接利用api將源庫的數據直接寫入hive庫的表文件中,包括淘寶開源的datax數據交換系統都采用類似的方式來交換跨庫數據。

再次注意,加載或者寫入的數據內容要和表定義的schema一致,否則將會造成字段或者表為空。

 

1.2   Hive數據模型

從數據倉庫的角度看,Hive是建立在Hadoop上的數據倉庫基礎架構,可以方便的ETL操作。Hive沒有專門的數據存儲格式,也沒有為數據建立索引,用於可以非常自由的組織Hive中的表,只需要在創建表的時候定義好表的schema即可。Hive中包含4中數據模型:Tabel、ExternalTable、Partition、Bucket。

 

圖:hive數據模型

a)         Table:類似與傳統數據庫中的Table,每一個Table在Hive中都有一個相應的目錄來存儲數據。例如:一個表t,它在HDFS中的路徑為:/user/hive/warehouse/t

b)        Partition:類似於傳統數據庫中划分列的索引。在Hive中,表中的一個Partition對應於表下的一個目錄,所有的Partition數據都存儲在對應的目錄中。例如:t表中包含ds和city兩個Partition,則對應於ds=2014,city=beijing的HDFS子目錄為:/user/hive/warehouse/t/ds=2014/city=Beijing

需要注意的是,分區列是表的偽列,表數據文件中並不存在這個分區列的數據。

c)         Buckets:對指定列計算的hash,根據hash值切分數據,目的是為了便於並行,每一個Buckets對應一個文件。將user列分數至32個Bucket上,首先對user列的值計算hash,比如,對應hash=0的HDFS目錄為:/user/hive/warehouse/t/ds=2014/city=Beijing/part-00000;對應hash=20的目錄為:/user/hive/warehouse/t/ds=2014/city=Beijing/part-00020

d)        External Table指向已存在HDFS中的數據,可創建Partition。Managed Table創建和數據加載過程,可以用統一語句實現,實際數據被轉移到數據倉庫目錄中,之后對數據的訪問將會直接在數據倉庫的目錄中完成。刪除表時,表中的數據和元數據都會刪除。ExternalTable只有一個過程,因為加載數據和創建表是同時完成。數據是存儲在Location后面指定的HDFS路徑中的,並不會移動到數據倉庫中。

 

1.3   Hive翻譯成MapReduce Job

Hive編譯器將HQL代碼轉換成一組操作符(operator),操作符是Hive的最小操作單元,每個操作符代表了一種HDFS操作或者MapReduce作業。Hive中的操作符包括:

表:Hive執行常用的操作符列表

操作符

描述

TableScanOperator

掃描hive表數據

ReduceSinkOperator

創建將發送到Reducer端的<Key,Value>對

JoinOperator

Join兩份數據

SelectOperator

選擇輸出列

FileSinkOperator

建立結果數據,輸出至文件

FilterOperator

過濾輸入數據

GroupByOperator

Group By 語句

MapJoinOperator

Mapjoin

LimitOperator

Limit語句

UnionOperator

Union語句

 

對於MapReduce操作單元,Hive通過ExecMapper和ExecReducer執行MapReduce任務。

對於Hive語句:

 

[sql]  view plain  copy
 
  1. INSERT OVERWRITETABLE read_log_tmp  
  2. SELECT a.userid,a.bookid,b.author,b.categoryid  
  3. FROM user_read_log aJOIN book_info b ON a.bookid= b.bookid;  

 

其執行計划為:

 

 

圖:reduce端join的任務執行流程

 

1.4   與一般SQL的區別

Hive 視圖與一般數據庫視圖

Hive視圖與一般數據庫視圖作用角色相同,都是基於數據規模縮減或者基於安全機制下的某些條件查詢下的數據子集。Hive視圖只支持邏輯視圖,不支持物化視圖,即每次對視圖的查詢hive都將執行查詢任務,因此視圖不會帶來性能上的提升。作為Hive查詢優化的一部分,對視圖的查詢條件語句和視圖的定義查詢條件語句將會盡可能的合並成一個條件查詢。

 

Hive索引與一般數據庫索引

相比於傳統數據庫,Hive只提供有限的索引功能,通過在某些字段上建立索引來加速某些操作。通常當邏輯分區太多太細,partition無法滿足時,可以考慮建立索引。Hive1.2.1版本目前支持的索引類型有CompactIndexHandler和Bitmap。

CompactIndexHandler壓縮索引通過將列中相同的值得字段進行壓縮從而減小存儲和加快訪問時間。需要注意的是Hive創建壓縮索引時會將索引數據也存儲在Hive表中。對於表tb_index (id int, name string)而言,建立索引后的索引表中默認的三列一次為索引列(id)、hdfs文件地址(_bucketname)、偏移量(offset)。特別注意,offset列類型為array<bigint>。

Bitmap位圖索引作為一種常見的索引,如果索引列只有固定的幾個值,那么就可以采用位圖索引來加速查詢。利用位圖索引可以方便的進行AND/OR/XOR等各類計算,Hive0.8版本開始引入位圖索引,位圖索引在大數據處理方面的應用廣泛,比如可以利用bitmap來計算用戶留存率(索引做與運算,效率遠好於join的方式)。如果Bitmap索引很稀疏,那么就需要對索引壓縮以節省存儲空間和加快IO。Hive的Bitmap Handler采用的是EWAH(https://github.com/lemire/javaewah)壓縮方式。

圖:Hivecompact索引及bitmap索引 

從Hive索引功能來看,其主要功能就是避免第一輪mr任務的全表掃描,而改為掃描索引表。如果索引索引表本身很大,其開銷仍然很大,在集群資源充足的情況下,可以忽略使用hive下的索引。

 

2     Schema設計

沒有通用的schema,只有合適的schema。在設計Hive的schema的時候,需要考慮到存儲、業務上的高頻查詢造成的開銷等等,設計適合自己的數據模型。

 

2.1   設置分區表

對於Hive來說,利用分區來設計表總是必要的,分區提供了一種隔離數據和優化查詢的便利的方式。特別是面對日益增長的數據規模。設置符合邏輯的分區可以避免進行全表掃描,只需加載特定某些hdfs目錄的數據文件。

設置分區時,需要考慮被設置成分區的字段,按照時間分區一般而言就是一個好的方案,其好處在於其是按照不同時間粒度來確定合適大小的數據積累量,隨着時間的推移,分區數量的增長是均勻的,分區的大小也是均勻的。達觀數據每日處理大量的用戶日志,對於user_log來說,設置分區字段為日期(天)是合理的。如果以userid字段來建立動態分區,而userid的基數是非常大的,顯然分區數目是會超過hive的默認設置而執行失敗。如果相對userid進行hash,我們可以以userid進行分桶(bucket),根據userid進行hash然后分發到桶中,相同hash值的userid會分發到同一個桶中。每個桶對應着一個單獨的文件。

 

2.2   避免小文件

雖然分區有利於隔離數據和查詢,設置過多過細的分區也會帶來瓶頸,主要是因為HDFS非常容易存儲大數據文件,由於分區對應着hdfs的目錄結構,當存在過多的分區時,意味着文件的數目就越多,過多增長的小文件會給namecode帶來巨大的性能壓力。同時小文件過多會影響JOB的執行,hadoop會將一個job轉換成多個task,即使對於每個小文件也需要一個task去單獨處理,task作為一個獨立的jvm實例,其開啟和停止的開銷可能會大大超過實際的任務處理時間。因此,hive表設計的分區不應該過多過細,每個目錄下的文件足夠大,應該是文件系統中塊大小的若干倍。

 

查詢避免生成小文件

既然hive或者說hadoop需要大文件,HQL執行語句也需要注意輸入文件和輸出文件的大小,防止生成過多小文件。hive可以通過配置參數在mr過程中合並小文件。

Map合並小文件:

 

[sql]  view plain  copy
 
  1. setmapred.max.split.size=256000000  #每個Map最大輸入大小(單位:字節)  
  2. set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat  #執行Map前進行小文件合並  

 

輸出合並:

 

[sql]  view plain  copy
 
  1. set hive.merge.mapfiles= true                 #在Map-only的任務結束時合並小文件  
  2. sethive.merge.mapredfiles= true               #在Map-Reduce的任務結束時合並小文件  
  3. set hive.merge.size.per.task= 256*1000*1000    #合並文件的大小  
  4. set hive.merge.smallfiles.avgsize=16000000     #當輸出文件的平均大小小於該值時,啟動一個獨立的map-reduce任務進行文件merge  



 

 

[sql]  view plain  copy
 
  1. </pre><p>一個獨立的map-reduce任務進行文件merge</p><p align="left"><pre name="code" class="sql">create table user_log (user_id int,url string,source_ip string)  
  2. partitionedby (dt  string)  
  3. clusteredby (user_id) into 96 buckets;  

 

我們知道hive輸出最終是mr的輸出,即reducer(或mapper)的輸出,有多少個reducer(mapper)輸出就會生成多少個輸出文件,根據shuffle/sort的原理,每個文件按照某個值進行shuffle后的結果。我們可通過設置hive.enforce.bucketing=true來強制將對應記錄分發到正確桶中,或者通過添加cluster by語句以及設置setmapred.reduce.tasks=96來設置reducer的數目,從而保證輸出與schema一致。根據hive的讀時驗證方式,正確的插入數據取決與我們自己,而不能依靠schema。

 

2.3   選擇文件格式

Hive提供的默認文件存儲格式有textfile、sequencefile、rcfile等。用戶也可以通過實現接口來自定義輸入輸的文件格式。

在實際應用中,textfile由於無壓縮,磁盤及解析的開銷都很大,一般很少使用。Sequencefile以鍵值對的形式存儲的二進制的格式,其支持針對記錄級別和塊級別的壓縮。rcfile是一種行列結合的存儲方式(text file和sequencefile都是行表[row table]),其保證同一條記錄在同一個hdfs塊中,塊以列式存儲。一般而言,對於OLTP而言,行表優勢大於列表,對於OLAP而言,列表的優勢大於行表,特別容易想到當做聚合操作時,列表的復雜度將會比行表小的多,雖然單獨rcfile的列運算不一定總是存在的,但是rcfile的高壓縮率確實減少文件大小,因此實際應用中,rcfile總是成為不二的選擇,達觀數據平台在選擇文件存儲格式時也大量選擇了rcfile方案。

 

3     查看執行計划及優化

達觀的數據倉庫基於Hive搭建,每日需要處理大量的計算流程,Hive的穩定性和性能至關重要。眾多的任務需要我們合理的調節分配集群資源,合理的配置各參數,合理的優化查詢。Hive優化包含各個方面,如job個數優化、job的map/reducer個數優化、並行執行優化等等,本節將主要從HQL查詢優化角度來具體說明。

3.1   Join語句

對於上述的join語句

 

[sql]  view plain  copy
 
  1. INSERT OVERWRITETABLE read_log_tmp  
  2. SELECT a.userid,a.bookid,b.author  
  3. FROM user_read_log aJOIN book_info b ON a.bookid= b.bookid;  

 

explain該查詢語句后:

 

 

圖:map端join的執行計划

由於表中數據為空,對於小數據量,hive會自動采取map join的方式來優化join,從mapreduce的編程模型來看,實現join的方式主要有map端join、reduce端join。Map端join利用hadoop 分布式緩存技術通過將小表變換成hashtable文件分發到各個task,map大表時可以直接判斷hashtable來完成join,注意小表的hashtable是放在內存中的,在內存中作匹配,因此map join是一種非常快的join方式,也是一種常見的優化方式。如果小表夠小,那么就可以以map join的方式來完成join完成。Hive通過設置hive.auto.convert.join=true(默認值)來自動完成map join的優化,而無需顯示指示map join。缺省情況下map join的優化是打開的。 

Reduce端join需要reducer來完成join過程,對於上述join代碼,reduce 端join的mr流程如下,

 

 

圖:reduce端join的mapreduce過程

相比於map join, reduce 端join無法再map過程中過濾任何記錄,只能將join的兩張表的所有數據按照join key進行shuffle/sort,並按照join key的hash值將<key,value>對分發到特定的reducer。Reducer對於所有的鍵值對執行join操作,例如0號(bookid的hash值為0)reducer收到的鍵值對如下,其中T1、T2表示記錄的來源表,起到標識作用:

 

 

圖:reduce端join的reducer join

Reducer端join無法避免的reduce截斷以及傳輸的大量數據都會給集群網絡帶來壓力,從上圖可以看出所有hash(bookid)% reducer_number等於0的key-value對都會通過shuffle被分發到0號reducer,如果分到0號reducer的記錄數目遠大於其他reducer的記錄數目,顯然0號的reducer的數據處理量將會遠大於其他reducer,因此處理時間也會遠大於其他reducer,甚至會帶來內存等其他問題,這就是數據傾斜問題。對於join造成的數據傾斜問題我們可以通過設置參數setHive.optimize.skewjoin=true,讓hive自己嘗試解決join過程中產生的傾斜問題。

3.2   Group by語句

我們對user_read_log表按userid goup by語句來繼續探討數據傾斜問題,首先我們explain group by語句:

 

[sql]  view plain  copy
 
  1. explain select userid,count(*)from user_read_log groupby userid  

 

 

 

圖:goupby的執行計划

 

Group by的執行計划按照userid的hash值分發記錄,同時在map端也做了本地reduce,group by的shuffle過程是按照hash(userid)來分發的,實際應用中日志中很多用戶都是未注冊用戶或者未登錄,userid字段為空的記錄數遠大於userid不為空的記錄數,當所有的空userid記錄都分發到特定某一個reducer后,也會帶來嚴重的數據傾斜問題。造成數據傾斜的主要原因在於分發到某個或某幾個reducer的數據量遠大於其他reducer的數據量。

對於groupby造成的數據傾斜問題,我們可以通過設置參數 

 

[sql]  view plain  copy
 
  1. set hive.map.aggr=true (開啟map端combiner);  
  2. set hive.groupby.skewindata=true;  

 

這個參數的作用是做Reduce操作的時候,拿到的key並不是所有相同值給同一個Reduce,而是隨機分發,然后Reduce做聚合,做完之后再做一輪MR,拿前面聚合過的數據再算結果。雖然多了一輪MR任務,但是可以有效的減少數據傾斜問題可能帶來的危險。

 

Hive解決數據傾斜

正確的設置Hive參數可以在某種程度上避免的數據傾斜問題,合適的查詢語句也可以避免數據傾斜問題。要盡早的過濾數據和裁剪數據,減少后續處理的數據量,使得join key的數據分布較為均勻,將空字段隨機賦予值,這樣既可以均勻分發傾斜的數據:

 

[sql]  view plain  copy
 
  1. select userid,namefrom user_info a  
  2. join (  
  3.     select case when userid isnull then cast(rand(47)*100000as int)  
  4.     else userid  
  5.     from user_read_log  
  6. ) b on a.userid= b.userid  

 

 

如果用戶在定義schema的時候就已經預料到表數據可能會存在嚴重的數據傾斜問題,Hive自0.10.0引入了skew table的概念,如建表語句

 

[sql]  view plain  copy
 
  1. CREATE TABLE user_read_log (useridint,bookid,…)  
  2. SKEWEDBY (userid) ON (null)[STORED AS DIRECTORIES];  

 

需要注意的是,skewtable只是將傾斜特別嚴重的列的分開存儲為不同的文件,每個制定的傾斜值制定為一個文件或者目錄,因此在查詢的時候可以通過過濾傾斜值來避免數據傾斜問題:

 

[sql]  view plain  copy
 
  1. select userid,namefrom user_info a  
  2. join (  
  3. select userid from user_read_log where pt=’2015’and userid isnot null  
  4. ) b on a.userid= b.userid  

 

可以看出,如果不加過濾條件,傾斜問題還是會存在,通過對skewtable加過濾條件的好處是避免了mapper的表掃描過濾操作。

3.3   Join的物理優化

Hive內部實現了MapJoinResolver(處理MapJoin)、SkewJoinResolver(處理傾斜join)、CommonJoinResolver

(處理普通Join)等類來實現join的查詢物理優化(/org/apache/hadoop/hive/ql/optimizer/physical)。

CommonJoinResolver類負責將普通Join轉換成MapJoin,Hive通過這個類來實現mapjoin的自動優化。對於表A和表B的join查詢,會產生3個分支:

1)        以表A作為大表進行Mapjoin;

2)        以表A作為大表進行Mapjoin;

3)        Map-reduce join

由於不知道輸入數據規模,因此編譯時並不會決定走那個分支,而是在運行時判斷走那個分支。需要注意的是要像完成上述自動轉換,需要將hive.auto.convert.join.noconditionaltask設置為true(默認值),同時可以手工控制轉載進內存的小表的大小(hive.auto.convert.join.noconditionaltask.size)。

MapJoinResolver 類負責迭代各個mr任務,檢查每個任務是否存在map join操作,如果有,會將local map work轉換成local map join work。

SkewJoinResolver類負責迭代有join操作的reducer任務,一旦單個reducer產生了傾斜,那么就會將傾斜值得數據寫入hdfs,然后用一個新的map join的任務來處理傾斜值的計算。雖然多了一輪mr任務,但是由於采用的map join,效率也是很高的。良好的mr模式和執行流程總是至關重要的。

 

4     窗口分析函數

Hive提供了豐富了數學統計函數,同時也提供了用戶自定義函數的接口,用戶可以自定義UDF、UDAF、UDTF Hive 0.11版本開始提供窗口和分析函數(Windowingand Analytics Functions),包括LEAD、LAG、FIRST_VALUE、LAST_VALUE、RANK、ROW_NUMBER、PERCENT_RANK、CUBE、ROLLUP等。

窗口函數是深受數據分析人員的喜愛,利用窗口函數可以方便的實現復雜的數據統計分析需求,oracle、db2、postgresql等數據庫中也提供了window function的功能。窗口函數與聚合函數一樣,都是對表子集的操作,從結果上看,區別在於窗口函數的結果不會聚合,原有的每行記錄依然會存在。

窗口函數的典型分析應用包括:

1)        按分區聚合(排序,topn問題)

2)        行間計算(時間序列分析)

3)        關聯計算(購物籃分析)

我們以一個簡單的行間計算的例子說明窗口函數的應用(關於其他函數的具體說明,請參考hive文檔)。用戶閱讀行為的統計分析需要從點擊書籍行為中歸納統計出來,用戶在時間點T1點擊了章節A,在時間點T2點擊了章節B,在時間點T3點擊了章節C 。用戶瀏覽日志結構如下表所示。

USER_ID

BOOK_ID

CHAPTER_ID

LOG_TIME

1001

2001

40001

1443016010

1001

2001

40004

1443016012

1001

2001

40005

1443016310

通過對連續的用戶點擊日志分析,通過Hive提供的窗口分析函數可以計算出用戶各章節的閱讀時間。按照USER_ID、BOOKID構建窗口,並按照LOG_TIME排序,對窗口的每一條記錄取相對下一條記錄的LOG_TIME減去當前記錄的LOG_TIME即為當前記錄章節的閱讀時間。

 

[sql]  view plain  copy
 
  1. SELECT  
  2.     Userid, bookid, chapterid, end_time – start_timeas read_time  
  3. FROM  
  4. (  
  5.     SELECT userid, bookid, chapterid, log_timeas start_time,  
  6.     lead(log_time,1,null) over(partitionby userid, bookidorder by log_time)as end_time   
  7.     FROM user_read_logwhere pt=’2015-12-01’  
  8. ) a;  

 

 

通過上述查詢既可以找出2015-12-01日所有用戶對每一章節的閱讀時間。感謝窗口函數,否則hive將束手無策。只能通過開發mr代碼或者實現udaf來實現上述功能。

窗口分析函數關鍵在於定義的窗口數據集及其對窗口的操作,通過over(窗口定義語句)來定義窗口。日常分析和實際應用中,經常會有窗口分析應用的場景,例如基於分區的排序、集合、統計等復雜操作。例如我們需要統計每個用戶閱讀時間最多的3本書:

 

  •  

 

圖:行間計算示意圖及代碼

對上述語句explain后的結果:

 

 

圖:行間計算的執行計划

窗口函數使得Hive的具備了完整的數據分析功能,在實際的應用環境中,達觀數據分析團隊大量使用hive窗口分析函數來實現較為復雜的邏輯,提高開發和迭代效率。

 

5     總結

本文在介紹Hive的原理和架構的基礎上,分享了達觀團隊在Hive上的部分使用經驗。Hive仍然處在不斷的發展之中,將HQL理解成Mapreduce程序、理解Hadoop的核心能力是更好的使用和優化Hive的根本。

技術的發展日新月異,隨着Spark的日益完善和流行,hive社區正考慮將spark作為hive的執行引擎之一。Spark是一種基於rdd(彈性數據集)的內存分布式並行處理框架,內部集成了Spark SQL模塊來實現對結構化數據的SQL功能。相比於Hadoop將大量的中間結果寫入HDFS,Spark避免了中間結果的持久化,速度更快且更有利於迭代計算。 具體需要結合自身的業務需求,采取合理的框架架構,提升系統的處理能力。

 

 

參考:

1.  Hive wiki:https://cwiki.apache.org/confluence/display/Hive/Home

2.  Hive Design Docs:https://cwiki.apache.org/confluence/display/Hive/DesignDocs

3.  Hadoop: The Definitive Guide (3rd Edition)

4. Programming Hive

5. Analytical Queries with Hive:http://www.slideshare.net/Hadoop_Summit/analytical-queries-with-hive

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM