《Hive權威指南》第九章模式設計

9.9 （幾乎）總是使用壓縮

hive看上去與實際操作都像乙個關係型資料庫，但是事實上hive是反模式。

對於資料集增長很快的情況，可以使用這種方式，在表名中加入乙個時間戳，例如upply_2020_05_20、upply_2020_05_21等。

當然對於hive，這種情況應該使用分割槽表。hive通過where子句來選擇需要查詢的分割槽。

通過過濾分割槽可以優化hive的查詢，避免全表掃瞄。

每乙個分割槽一般會對應著包含多個檔案的資料夾，如果表使用了動態分割槽，可能會建立非常多分割槽這又可能會導致產生很多的小檔案，最終導致namenode掛掉。

hdfs檔案系統namenode必須將所有系統檔案的元資料資訊儲存在記憶體中，每個檔案的元資料資訊大約150個位元組。mapr和amazon s3就沒有這個限制。

mapreduce會將乙個任務（job）轉換成多個任務（task）。預設情況下，每個task都是乙個新的jvm例項，都需要開啟和銷毀。對於小檔案，每個檔案都會對應乙個task。在某些情況下，jvm開啟和銷毀的時間中銷毀可能比實際處理資料的時間還長！所以必要的時候開啟jvm重用，也是有效的調優方式。

理想情況下分割槽方案不應該導致產生太多的分割槽和資料夾目錄，並且每個目錄下的檔案應該足夠大，應該是檔案系統中塊打下的若干倍。

在設計分割槽表時，盡量考慮分割槽數量的增長是「均勻的」，而且每個分割槽下包含的檔案大小至少是檔案系統中塊的大小至少是檔案系統中塊的大小或塊大小的數倍。同時有必要考慮這種粒度級別在未來是否是適用的，必要的情況可以建立多級分割槽。例如一張按照時間和地區進行劃分。

終極目標就是優化查詢效能

hive沒有主鍵或基於序列秘鑰生成的自增鍵的概念。

在很多大資料場景，星型架構型別設計並非最優的。其主要原因是為了最小化磁碟尋道時間，我們可以避免標準化，例如傳統資料庫需要使用外來鍵的關係的情況。

標準化：值資料庫組織資料的過程。

原則：根據設計規則建立表並建立表之間的關係

取消冗餘度與不一致相關性

非標準化資料允許被掃瞄或寫入到大的、連續的磁碟儲存區域，從而優化磁碟驅動器的***i/o***效能。當然標準化資料可能會導致資料重複，更嚴重的場景是，導致資料不一直的風險。加大了資料管理的難度。

hive本身提供了乙個獨特的語法，它可以從乙個資料來源產生多個資料聚合，而無需每次聚合都要重新掃瞄一次。對於大的資料輸入集來說，這個優化可以節省非常可觀的時間。具體示例如下：

hive>
insert overwrite table sales
>
select
*from history where
action
='purchased'
;hive>
insert overwrite table sales
>
select
*from history where
action
='returned'
;

使用下面這種方式，只需要掃瞄history表一次即可：

hive>
from history
>
insert overwrite sales select
*where
action
='purchased'
>
insert overwrite credits select
*where
action
='returned'

很多etl處理過程會涉及多個處理步驟，每個步驟又會產生乙個或多個臨時表，這些表僅供下乙個job使用。對臨時表進行分割槽也是很有必要的，比如某一天的資料有問題，就不用從資料來源重跑所有資料，也不會因為下一次的任務而overwrite臨時表。同時執行兩個例項，只要指定不同的分割槽即可。

乙個更魯棒性的處理方法就是整個過程中使用分割槽。這樣就不會存在同步問題，同時也允許使用者對中間資料按日期進行比較。缺點就是需要管理中間表，以及對舊的分割槽資料的刪除。

分割槽提供了乙個隔離資料和優化查詢的便利方式。不過並非資料集都能形成合理的分割槽，就像前面提到的動態分割槽場景。

分桶是將資料集分解成更容易管理的若干部分的另乙個技術。

例如：

hive>
create
table weblog (user_id int
, url string, source_ip string)
> partitioned by
(dt string)
>
clustered
by(user_id)
into
96 buckets;

將user_id作為分桶字段，則會根據user_id的值進行雜湊分發到桶中。分桶之後具體在使用的時候，有兩種方式：

-- 設定：自動按照分桶表的bucket 進行分桶 set hive.enforce.bucketing =

true

-- 設定reduce task為96，並在插入語句中新增cluster by [filed_name]
set mapred.reduce.tasks=
96

警告

對於所以表的元資料，指定了分桶並不能保證表可以正確地填充。使用者可根據以上示例來確保是否正確地填充了表。

分桶的幾個優點：

使用alter [table_name] add columns (field_name type)命令，可以在表的末尾新增乙個字段。之前缺失新新增的字段的資料，就補null。

實際生產中，隨著時間的推移，很有可能會為底層資料增加乙個新的字段。

hive通常使用行式儲存，不過hive也提供了乙個列式serde來以混合列式格式儲存資訊。

stat

uidage

nybob

30nj

sara

40ny

peter

14ny

sandra

5如果以上資料量很大，那麼state欄位與age欄位這樣的列會有很多重複資料。這種場景使用列式儲存是非常適用的。例如rcfile採用遊程編碼，相同的資料不會重複儲存，很大程度上節約了儲存空間。

一般生產中只會取寬表的部分字段，使用列式儲存，避免整行資料的讀取與過濾。後續會詳細介紹如何使用格式。

另外的：

列式儲存由於相同列的字段型別相同，可以使用高壓縮率的演算法對檔案進行壓縮，而行式資料庫由於一行各個字段型別可能不同，在壓縮方式上不容易獲得乙個高的壓縮比（也就是空間利用率不高）

列式資料庫的每一列都可以作為索引，而行式資料庫並非所有的字段都適合作為索引。

幾乎所有的場景都可以使用壓縮，使磁碟上儲存的資料量變小，這樣可以通過降低i/o來提高查詢執行速度。hive可以無縫使用很多壓縮型別。

唯一不使用壓縮的理由是，資料要直接要提供給外部系統使用，或者使用非壓縮格式（例如文字格式）是最最相容的。

壓縮和解壓縮都會消耗cpu資源。mapreduce任務往往是i/o密集型的，因此cpu開銷往往不是問題。當然對於工作流這樣的cpu密集型的場景，例如一些機器學習演算法，壓縮實際上可能會從更多必要的操作中獲取寶貴的cpu資源，從而降低效能。

《Hive權威指南》第九章模式設計

第九章設計模式抽象工廠模式

第九章（筆記）

第九章作業

《Hive權威指南》第九章 模式設計

第九章 設計模式 抽象工廠模式

第九章（筆記）

第九章作業

相關推薦

《Hive權威指南》第九章模式設計

第九章設計模式抽象工廠模式