hive學習之一：認識hive

anickname發表於2016-03-15
Hive
  有些時候總感覺對某個概念，某項技術理解的不夠深，理解的不到位，其實是自己站的高度不夠高。拋開具體的技術細節不談，
多想想設計的初衷，多想想為什麼，收穫頗豐。以下是我對hive的一些思考，在此做個記錄，不對的地方，還請指正。
一.認識hive
hive一個資料倉儲工具，不同於資料庫。資料倉儲注重於資料分析（OLAP）和歷史資料儲存，面向主題，而資料庫則是面向事務(OLTP)，儲存
線上交易資料,資料庫設計儘量避免冗餘，而資料倉儲的設計有意引入冗餘。
1.面向主題和麵向事務
  面向主題簡單理解是面向某一類資訊，面向事務偏重的資料的完整性。如：
  商品id，商品名稱，商品價格，交易時間，交易數量，交易金額。
  在這樣的一條交易資料中，面向事務側重整條交易資料的完整性，而在面向主題的概覽中，將資訊按主題分類：
  商品類：
     商品id
     商品名稱
     商品價格
  交易類：
     交易時間
     交易數量
     交易金額
2.關於冗餘資料
  如下的資料庫設計是為了避免冗餘：
  有一個學生班主任表欄位如下（班主任和學生的關係是1:N）
  學生ＩＤ　　學生姓名　　班主任ＩＤ　班主任姓名　班主任家庭住址
  那麼這裡，我們每插入一條學生記錄，都必須要插入一次班主任的姓名和家庭住址資訊，這就是典型的資料冗餘。
  這樣的冗餘帶來的麻煩就是：
  １。班主任姓名和住址要多次插入同樣資料，存在插入錯誤的危險。
  ２。班主任搬家了。。。那麼要更新班主任家庭住址Ｎ次～
  為避免冗餘：
  表拆分為
  學生班主任表
  學生ＩＤ　學生姓名　班主任ＩＤ
  班主任表
  班主任ＩＤ　班主任姓名　班主任住址
  但是在資料倉儲中，設計冗餘的目的是以空間換時間，減少關聯的開銷和提高資料讀取的速度。
  
二.關於hive資料型別的思考
   hive資料型別分兩大類：一是基本資料型別，二是負載型別。
   基本有如tinyint，smallint，int.....（不列舉全部）,在大部分情況下，設計資料表的時候，都能夠正常完成。但是卻少有考慮資料型別
   對查詢效能的影響。比如在定義“員工資訊”表時，將員工年齡定義為int型別，並沒有任何語法語義錯誤。但是從查詢效能上
   來考量有瑕疵，這是因為採用int型別儲存資料佔用的資料表空間比用smallint或tinyint儲存佔用空間更大，查詢時要消耗更
   多的磁碟IO，在資料集很大的時候，會對查詢效能有一定的影響。另外如果hive對某列建立索引，該列的值越短越好，這樣可以
   提高查詢效能，對索引處理會更快。
   
   
三.hive三觀
   樹立這些觀念有助於更好的利用hive的特點和優勢。
   1.資料倉儲觀
     hive是資料倉儲工具，資料倉儲與資料庫密不可分，不關注細節。我們可以偏見地像對待資料庫一樣簡單粗暴地對待hive。
     在hive裡我們可以像運算元據庫一樣來操作它。
     1-1.常見的資料模型操作（SQL）：資料庫，表，檢視，索引，分割槽，桶
     1-2.訪問方式：Client（JAVA APT通過thrift server訪問），cli（命令列），web ui（直觀方便）。
     1-3.內建的操作符和函式。
     1-4.hive資料檔案的存放及後設資料資訊的管理
   2.MapReduce觀
     2-1.絕大多數hiveQL都是別轉換成MR執行的，因此要樹立的一種觀念是HQL就是MR，在進行Hive調優的時候，很多時候其實都是
     對MR調優。比如要考慮資料傾斜問題會對MR造成的影響。基於MR的特性，我們可以預見的是hive適合處理大資料量的離線分析，
     而且是冷資料（只讀不寫）。具有高延遲的特點，不適合低延遲快速響應的場合。
     2-2.hive的後設資料是和很多hadoop元件共享的，比如和impala，Hbase共享後設資料。對hive資料的操作同樣會影響其他元件的資料。
   3.高擴充套件性觀
     有些時候，hive自帶的函式不能滿足實際開發需求，我們可以通過自定義UDF來擴充套件hive的功能，還可以通過改動一些底層
     原始碼來實現想要的功能。而這些改動都是基於Java，所以改動的成本低，易於程式設計。類似於ETL工具Sqoop。比如自定義輸入輸出格式化處理，自定義分隔符處理程式，自定義業務邏輯處理過程等等，這極大的豐富和擴充套件了hive的功能。
     
     

相關文章