hive使用心得

最近使用hive一個多月下來(終於完成第一期資料分析遷移工作了)，當時使用的0.8的版本（現在最新版本是0.8.1），一個多月下來收穫很多。從安裝環境、

調試、開發、業務理解、技術攻關、業務實現等，一一都體驗了一把。

總的來說，除了目前網上所介紹的常規hive使用和最佳化外。

因為目前hive只支援0.20的相關版本，所以我們的環境還是使用的0.20版本的hadoop來進行搭建。
使用hive和hadoop是一種綜合能力的體現，之前我在使用的過程當中，還涉及到很多系統層面的問題。如果讓hive和hadoop結合的更緊密，個人認為是從以下幾個角度進行：
第一：hive的類SQL語句本身進行調優
第二：就是hive的參數調優
第三：hadoop裡的hdfs的參數調優（儲存格式、壓縮格式、RPC調用、串連數控制）
第四：hadoop裡的map/reduce的調優（datanode間的資料轉送、處理大小、每個child的相關JVM設定等）
第五：就是hadoop環境裡的網路傳輸的調優（硬體環境）
第六：就是hdfs的儲存格式調優（文字格式設定、順序格式等）
第七：作業系統層面的磁碟I/O調優（多工等）
第八：作業系統層面的網路調優（緩衝區大小、串連數放大等）
第九：作業系統層面的記憶體調優（虛擬記憶體設定、記憶體控制等）
第十：hadoop的容錯機制的掌握，因為正常的運行到沒什麼，怕就是出現異常時，有相應的應對方案（調度器、隊列等）
第十一：hadoop的管理（包括datanode失效、namenode失效、加入或刪除datanode、負載平衡、叢集等）

另外網上更多的是基於SUN的JVM來搭建hadoop環境，但我在使用的過程中是用jrockit的JVM來搭建hadooop環境，主要是考慮到目前在jrockit 6.0的版本上效能比較強勁（體現在網路傳輸、線程、GC回收等）。

另一方面是使用到了多種程式語言，如SQL（不過還是跟真正在資料庫的SQL文法有區別的）、java、python（還好之前有用過python做過開發）、shell等。
現在先說說hive，畢竟在這次的開發過程中，hive使用比例很大。關於hive其中有些參數的使用和搭配，目前我還在測試過程當中（幾個關鍵參數），以後再詳細講解。
hive個人覺得更適合做一些彙總情境的相關處理，其自訂函數UDAF更能體現這樣的一個特點。
關於UDF這種自訂函數比較適合做一些欄位上的轉換處理，例如一個Text類型轉換成一個array類型；另外就是可以實現更為豐富的解碼方式，如在URL中有些參數使用了UTF-8編碼或者GBK編碼的方式。
還支援自訂的map/reduce方式（相關關鍵字）。

/*mapjoin*/這種標識（這裡描述有誤，mapjoin是提供了一種提高join的方式）。
支援多種儲存格式，如：行格式、檔案格式等，hdfs裡也支援多種儲存格式。
支援匯入/匯出資料，這裡需要提醒下，使用hive命令的匯出，會把一行資料進行合并，也就看不出欄位；所以一般都採用 hive -e 'select * from t' >> 123.txt這樣形式命令，才能使匯出的欄位由空格進行分割(後來驗證過，這是我的一個使用失誤，其實裡面還是有\001的符號，只是顯示的時候不顯示而已，所以兩種方式都適合)。
NULL和空值的區別，在hive的處理時需要注意（特別是與python這樣的指令碼結合使用，另外還有在python中的欄位切割問題）。

現在總結下hive不擅長的地方
因為我這次的開發工作單位是將有些用SAS計算的任務遷移到hadoop上面進行資料分析，因為SAS上有很多強勁的功能，在做資料分析時很有協助；但在hive上面就沒有這樣的功能了。舉例如下：
SAS上有類似與遊標的概念的東東，可以操作記錄行，並對記錄裡一某個欄位進行移動（如將某個欄位移到前一條記錄上面）
SAS有排重功能（也就是根據幾個欄位，去掉重複資料）
SAS可以輕鬆進行分組後，前取每個分組裡的前10條記錄（備忘：這裡後來我瞭解可以通過UDAF處理，SQL語句本身是不支援的）
SAS不好的地方就是進行解碼轉換（如經過UTF-8或者GBK編碼的方式，這裡主要指的是URL裡，就比較麻煩）
常見情境等，另外還有幾種情況描述起來較為複雜，這裡略之。

關於之前描述的前三種情況，如果只是簡單的用HIVE本身的SQL語句方式那是很難實現的，三種情況的共同點就是如何操作一行記錄。
hadoop裡有一種方式叫streaming，就是一行一行的讀取，然後通過指令碼的方式進行處理，在這裡剛好hive是支援指令碼的，所以可以用指令碼來實現操作一行記錄（我這裡使用的是python指令碼）
關於排重功能，在SAS實現的原理基本就是按照幾個關鍵字進行排序，然後進行排重處理（因為排序之後，重複的資料肯定是在一起的，這樣做排重處理就比較方便了）。
所以在hive這邊，首先也是進行按幾個關鍵字排序，然後採用指令碼方式進行去掉重複資料。
雖然指令碼的已耗用時間比純java要慢，但是因為指令碼滿足了業務需求，所以運行慢的缺陷我們是可以忽略的，畢竟hive後期調優中，也有關鍵字的支援map、reduce。
關於如何用指令碼進行取每個分組的前10條記錄（給一個簡單的業務情境，取每個地區(按上海、北京、深圳、廣州等)的銷售量前十名的業務員），由讀者自己可以思考下。
第四個情境，關於URL參數解碼問題，很簡單，就自訂一個UDF，然後通過java的方式來進行解決。這裡有個比較麻煩的地方就是如何區分出這個URL是用UTF-8編碼還是GBK編碼。

另補充兩點：

就是一個hiveSQL指令碼，最好別太多SQL，不然會導致一些異常情況出現。最好進行拆分。如下：

1.sql

1_1.sql

1_2.sql

形式，這樣方便在shell裡進行控制。
第二個就是多看源碼（hadoop源碼、hive源碼），發現有些參數配置，都在程式裡，但文檔中並沒有體現。

這些就是大致使用下來的感覺，後續還有新的體驗，再增加吧。
如有不懂的地方，可以提問。

這裡是再次補充下這個項目有關hive的使用問題：

 首先是去重問題，後來經過反覆測試發現，map個數不能是多個，不然前一個split的最後一條記錄，與後一個split的第一條記錄，無法進行匹配去重。

所以當碰到這樣的問題時，MR的優勢將無法體現出來，目前採用的是最簡單的方法就是map個數和redce個數都設定成1

但是不知道MR其中有一種chain方式是否可行。

綜上所述，當碰到這種上下記錄有關聯的時候，如何利用MR這種模式，還是要好好琢磨和不斷的測試的。