本章節咱們將介紹爲何需要在Kylin建立Cube過程當中使用Hive視圖。而假設使用Hive視圖。可以帶來什麼優勢。解決什麼樣的問題。以及需要學會怎樣使用視圖。使用視圖有什麼限制等等。html
1. 爲何需要使用視圖android
Kylin建立Cube的過程當中使用Hive的表數據做爲輸入源。但是有些狀況下，Hive中的表定義和數據並不能知足分析的需求。好比有些列的值需要進行處理，有些列的類型不知足需求，甚至有時候咱們在建立Hive表時爲了方便快捷，會將Hive表的所有列的字段類型都定義爲string，所以很是多狀況下在使用Kylin以前需要對Hive上的數據格式等問題進行適當的處理。ios
但是假設在Hive中經過改動原表來解決上面的問題，比方使用alter table的方式改動原始表的Schema信息未免會對其餘依賴Hive的組件有所影響（好比可能致使經過Sqoop等方式導入數據失敗）。而且也有可能致使以前的做業沒法正常執行。因而咱們需要考慮在不改變原表的狀況下解決問題，所以咱們想到的方案是使用Hive的視圖。web
固然，除了Hive數據源自己Schema等限制以外，Kylin對於Hive的使用另外一定的限制，這也間接的致使咱們需要使用視圖：算法
A. 同一個項目下使用一樣表（可能依據不一樣的filter條件過濾。或者設置了不一樣的維度等）建立了不一樣的Cube，會致使查詢的時候定位到錯誤的Cube等異常問題。sql
B. 僅僅支持星型模型數據庫
咱們的來源表可能包括多張事實表和多張維表，那麼就需要將多張事實表整合成一張大的寬表。apache
2. 怎樣使用視圖cookie
Hive眼下僅僅支持邏輯視圖，而咱們需要的僅僅是對Hive原始的Schema信息的改動，而並非但願經過物化視圖優化查詢速度。所以眼下Hive對視圖的支持可以知足Kylin的需要。函數
如下依據不一樣的場景分別介紹一下怎樣建立視圖做爲Kylin的輸入源：
A. 分表的狀況
兩個表具備一樣的結構。但是保存不一樣的數據。好比一個表保存Android端的訪問數據，一個訪問iOS端的數據。那麼就可以經過Hive的view解決。
好比有一個用戶有兩張表product_android和product_ios。這兩個表具備一樣的表結構，用戶需要將平臺（Android或者IOS）做爲一個維度進行分析。所以咱們爲其建立了這種view：
create view palearn_cube as select userid, eventid, label, day, 'android' as platformfrom palearn_android WHERE category='gc001' UNION ALL select userid, eventid, label, day, 'ios' as platform frompalearn_ios WHERE category='gc001';
這樣可以將palearn_cube做爲事實表來建立Cube，當中而platform做爲當中的一個維度
B. 本身定義函數
Kylin中使用Apache Calcite做爲SQL的查詢引擎，但是Kylin支持的本身定義函數代價比較大。所以假設需要使用本身定義函數，那麼可以在Hive中建立視圖來對字段進行處理。
C. 雪花模型的支持
眼下Kylin僅支持星型模型，而經過在Hive中建立視圖，咱們可以很是easy地把雪花模型轉換爲星型模型，甚至生成一個大的寬表。
D. 頻繁改動表字段名
Kylin直接使用Hive中的字段名做爲元數據。假設頻繁改動事實表或者維度表的字段名會致使元數據錯誤（https://issues.apache.org/jira/browse/KYLIN-1173）。所以經過視圖添加一層映射是比較好的方法。這樣可以使得原生的Hive表的字段名對Kylin的Cube透明，此後再需要改動字段名的時候不會對Cube有所影響，僅僅需要改動view的定義。
E. UHC維度
當一個維度的cardinality比較大時可能會出現的問題比較多。首先可能致使Extract Fact Table Distinct Columns這一步時致使reducer出現OOM；其次在建立維度字典樹可能會致使維度字典樹太大佔領大量的內存；另外會致使cube的構建速度緩慢。佔用大量的存儲空間。此時就需要思考一下這種UHC維度是不是必須的。可否夠提取出部分信息減少維度。好比timestamp維度，可否夠精確到5分鐘，具體地址的維度，可否夠精確到縣、鎮。這樣可以大大減少維度數。而且更具體的信息並無太大的統計意義。好比url類型的維度，可否夠把參數去掉僅僅保留訪問路徑。
F. Hive中表字段類型變化
比方咱們以前有一個需求計算一個指標的Count Distinct值，儘管這個字段存放的內容爲整數值。但是Hive表字段類型爲string，Kylin中Count Distinct聚合函數不支持字符類型，所以咱們在Hive中建立視圖解決問題，即將string類型轉換爲整數類型。
G. 複合數據類型處理
由於Hive中可以定義複雜的數據類型，好比map、struct，而Kylin中沒法處理這種類型，因此需要使用視圖將複雜類型字段進行拆分出維度和度量。
在咱們眼下的實踐中，有一部分Cube依賴的事實表都是經過view建立的，這樣添加了一層映射，可以減少cube對原始表的依賴，提升靈活性。
3. 使用視圖限制
由於Hive的限制，Hive不能對view使用HCatalog獲取數據
（https://issues.apache.org/jira/browse/HIVE-10851），所以當你在Kylin中load一個view的時候，Kylin計算表的cardinality的job沒法獲取到cardinality的值。這時就要求用戶知道每一列的cardinality大體的狀況。假設實在不肯定可以到Hive裏面查詢一下。
4. 使用視圖實戰
這裏我給朋友們簡單演示一下視圖的使用，事實上視圖在咱們項目中仍是會經常遇到的。
不知道朋友們還記不記得以前咱們建立過三張表（請查看「Apache Kylin進階部分之多維分析的Cube建立實戰」章節）：
事實表：kylin_flat_db.web_access_fact_tbl
維表：kylin_flat_db. region_tbl
維表：kylin_flat_db.city_tbl
假設您依據本書實戰的話。當前Hive的kylin_flat_db數據庫如下應該有這三張表。咱們現在將在Hive中對這三張表建立視圖。依據視圖來構建Cube。大概過程例如如下：
步驟一：建立視圖
在Hive Cli中執行例如如下SQL：
use kylin_flat_db;
create view v_pvuv as select a.DAYas v_date,
b.regionname,
c.cityname,
hash(a.cookieid) as cookieid,
a.pv
from web_access_fact_tbl a
join region_tbl b
on a.regionid = b.regionid
join city_tbl c
on a.cityid = c.cityid;
這裏對cookieid字段（字符串類型）使用hash函數處理。結果處理爲整數類型，咱們這樣作的目的是爲了使用Count Distinct（眼下僅僅支持整數類型）精確去重。
注：hash算法的特色是可反覆和不可逆的，即針對不一樣的字符串進行hash處理。結果可能會反覆的，因此上面的方法存在必定的問題。在實際項目中咱們使用Hive本身定義函數對需要使用Count Distinct精確的字段（整數類型就沒必要處理了）處理成整數類型。
步驟二：建立項目
建立「view_project」project，固然也可以使用不論什麼已經存在的project。
步驟三：導入數據源
導入kylin_flat_db數據庫下剛纔建立的視圖v_pvuv。
步驟四：建立Model
這裏咱們做爲演示，僅僅選了一張視圖做爲事實表。沒有維表。
當中：
維度字段：v_date。regionname，cityname
度量字段：cookieid，pv
分區字段：v_date
步驟五：建立Cube
由於朋友們對於怎樣建立Cube都很是熟悉了，這裏咱們簡要羅列幾步。
建立Cube所選的維度例如如下：
建立Cube所選的度量例如如下：
當中咱們使用精確的COUNT_DISTINCT函數來計算cookieid字段中值，因此返回類型爲bitmap。
步驟六：構建Cube
設置構建的結束時間，而後構建Cube。
步驟七：查詢Cube
查詢例如如下SQL：
select v_date,
regionname,
cityname,
count(distinct cookieid)
from V_PVUV
group by v_date,
regionname,
cityname;
結果爲：
在咱們使用Kylin的過程當中。對於上面提到的問題很是多都可以經過Hive的視圖進行解決。假設朋友們在Kylin使用過程當中遇到一些Kylin自身沒法解決的時候。可以嘗試一下Hive的視圖，或許會給您帶來驚喜。