從資料倉庫系統對比看Hive發展前景

本文講的是<b>從資料倉庫系統對比看Hive發展前景</b>,大資料時代的資訊爆炸，使得分布式/并行處理變得如此重要。無論是傳統行業，還是新興行業(特别是網際網路行業)，日常業務運作所産生的海量使用者和服務資料都需要更大的硬體資源來處理。需要并行處理的應用領域主要為網頁搜尋、廣告投放和機器翻譯等。從單機應用到叢集應用的過渡中，誕生了MapReduce這樣的分布式架構，簡化了并行程式的開發，提供了水準擴充和容錯能力。

　　雖然MapReduce(Hadoop)的應用非常廣泛，但這類架構暴露出來的程式設計接口仍然比較低級，編寫複雜處理程式或Ad-hoc查詢仍然十分耗時，并且代碼很難複用。目前，Google、Facebook和微軟等公司都在底層分布式計算架構之上又提供更高層次的程式設計模型，将開發者不關心的細節封裝起來，提供了更簡潔的程式設計接口。

　　目前應用最廣泛的當屬Facebook開源貢獻的Hive。Hive是一個基于Hadoop的資料倉庫平台，通過Hive，可以友善地進行資料提取轉化加載(ETL)的工作。Hive定義了一個類似于SQL的查詢語言HQL，能夠将使用者編寫的SQL轉化為相應的MapReduce程式。當然，使用者也可以自定義Mapper和Reducer來完成複雜的分析工作。從2010年下半年開始，Hive成為Apache頂級項目。

　　基于MapReduce的Hive具有良好的擴充性和容錯性。不過由于MapReduce缺乏結構化資料分析中有價值的特性，以及Hive缺乏對執行計劃的充分優化，導緻Hive在很多場景下比并行資料倉庫慢(在幾十台機器的小規模下可能相差更大)，Hive的架構如圖1所示。

▲圖1 Hive架構圖

　　強大的資料倉庫和資料分析平台至少需要具備以下幾點特性。

　　·靈活的存儲引擎

　　·高效的執行引擎

　　·良好的可擴充性

　　·強大的容錯機制

　　·多樣化的可視化

　　本文将簡要闡述Hive是否完全具備了以上幾點，以及與傳統的并行資料倉庫對比優劣如何。

　　<b>存儲引擎</b>

　　Hive沒有自己專門的資料存儲格式，也沒有為資料建立索引，使用者可以非常自由地組織Hive中的表，隻要在建立表時告訴Hive資料中的列分隔符和行分隔符，Hive就可以解析資料。Hive的中繼資料存儲在RDBMS中，所有資料都基于HDFS存儲。Hive包含Table、External Table、Partition和Bucket等資料模型。

　　并行資料倉庫需要先把資料裝載到資料庫中，按特定的格式存儲，然後才能執行查詢。每天需要花費幾個小時來将資料導入并行資料庫中，而且随着資料量的增長和新的資料源加入，導入時間會越來越長。導入時大量的寫I/O與使用者查詢的讀I/O産生競争，會導緻查詢的性能很差。

　　Hive執行查詢前無需導入資料，執行計劃直接執行。Hive支援預設的多種檔案格式，同時也可以通過實作MapReduce的InputFormat或OutputFormat類，由使用者定制格式。因為公司的資料種類很多，存儲于不同的資料源系統，可能是MySQL、HDFS或者Hypertable等，很多時候Hive的分析過程會用到各種資料源的資料。當然使用多個存儲資料源，除了功能上要能夠支援導入/導出之外，如何根據各種存儲源的能力和執行流獲得最優執行計劃也是件麻煩事兒。

作者：王玉圓

來源： IT168

原文标題：從資料倉庫系統對比看Hive發展前景