Hive的優化（一）—概念介紹

​介紹

        Hive是基於Hadoop的一個數據倉庫工具，能夠將結構化的數據文件映射爲一張數據庫表，並提供簡單的sql查詢功能，能夠將sql語句轉換爲MapReduce任務進行運行 。Hive自己是不能存儲數據的，它只是記錄數據的一些路徑信息，最終全部的操做都轉換成MapReduce操做，因此Hive的優化其本質上是對Hadoop的優化。

Hadoop的特色

         作過大數據開發的，hadoop在處理數據的過程當中有幾個特色。

         一、數據多不是問題，就怕出現數據傾斜。

​         二、對job較多的做業運行效率相對比較低，即便只有幾百行數據的表，若是屢次關聯彙總，產生幾十個job的話，至少也要跑個半小時。這是由於，map reduce的做業初始化的時間自己就比較長。

​         三、對於sum，max，min和count的UDAF來說不怕數據傾斜問題，由於hadoop會在map端對計算出來的結果進行彙總並優化，使得數據傾斜不成問題。

​         四、count（distinct），在數據量大的時候，效率會變得較低，這主要是由於count（distinct）是按照group by來對字段進行分組的，而且按照distinct的字段進行排序，通常是很容易形成數據傾斜的。例如一個大型的購物網站，若是按照男女對訪問量進行分組的話，而這個網站一天有20億的瀏覽量，按照那女分紅兩組，由兩個reduce來分別進行處理，這樣每一個reduce處理10億數據，顯然這樣的資源分配是不合理的，效率是比較低下的（就像一堆磚，有10我的能夠安排搬這些磚，而後你只安排2個搬搬磚，這樣就會形成資源的浪費，下降工做的效率）。

影響Hive性能的因素

        在考慮hive性能優化時，把HiveQL當作M/R程序來讀會有一種意想不到的收穫。也就是從M/R的運行角度來考慮優化性能，從更底層思考如何優化運算性能，而不只僅侷限於邏輯代碼的替換層面。

　　RAC（Real Application Cluster）的應用集羣就像一輛機動靈活的小貨車，響應快。Hadoop就像吞吐量巨大的輪船，啓動開銷大，若是每次只作小數量的輸入輸出有點殺雞用牛刀的感受，會使得Hadoop的特性得不到充分發揮，下降利用率。因此要想用好Hadoop使Hadoop的性能獲得充分，最早要作的就是增大每次任務所搭載的數據量。

　　Hadoop的核心能力是parition和sort，在MapReduce的shuffle階段，會對數據進行打亂->排序->再打亂->再排序，因次這也是優化的根本。

Hadoop的做業初始化須要很長的時間，所以當job數量過多時，會致使總體的做業運行時間偏長，從而影響總體的效率，所以這也是在實際生產環境中須要注意的地方，要儘可能使job數量變少。

        count（distinct）是按照group by來對字段進行分組的，但數據量較大而對應的分區字段較少時，或致使每一個分組的數據量過大，從而形成數據傾斜，所以在數據量較大的時候要謹慎考慮使用count(distinct).

        咱們知道在Hadoop中，數據傾斜是形成效率低下的主要緣由，所以在實際環境中，須要儘可能避免數據的傾斜問題。

        結論：在對hive進行優化時，應該要注意上述問題，針對上述問題來對Hive進行優化。在作優化的過程當中咱們要作到避實就虛，儘可能使用最少的job 數來執行任務，充分利用空閒 CPU 等各類方法，分解數據傾斜形成的負擔。

hive優化的原則

​         那麼，面對這些問題咱們應該如何處理呢？咱們可以採起哪些有效手段，來對這些問題進行優化呢？咱們能夠從一下幾個大方面來進行考慮：

​         一、設計一個好的模型，由於一個好的模型可以作到事半功倍。

​         二、從數據傾斜問題來考慮，能夠採起有效措施解決數據傾斜問題。

​         三、儘可能減小job的個數，能用一個job完成的，就堅定不用兩個job。

​         四、設置合理的map reduce的task個數，能夠有效地提高性能。

​         五、瞭解數據的分佈，本身動手解決數據的傾斜是個不錯的選擇

​         六、對於數據量較大的時候，要慎用count（distinct），由於容易產生數據傾斜。

​         七、對小文件進行合併，是一種比較行之有效提升效率的方法。

​         八、在優化時，要注意把握總體最優原則。

針對上述提出的問題，根據hive的特色在下一篇當中將具體介對於hive優化的一些具體細節。