1整體架構
1.1Hbase原有系統架構
HBase是ApacheHadoop的數據庫，能夠對大型數據提供隨機、實時的讀寫訪問。HBase的目標是存儲並處理大型的數據。HBase是一個開源的、分佈式的、多版本的、面向列的存儲模型，它存儲的是鬆散型數據。相比傳統的關係型數據庫，HBase具有易擴展、大數量、擴展靈活、成本低等優勢。
1.2OTT用戶行爲數據系統架構圖
在OTT體系中，每個機頂盒終端就是一個用戶，有唯一的用戶標識UserID；用戶透過機頂盒來訪問和使用互聯網電視業務，用戶在盒端系統上產生的所有行爲日誌都上傳給系統平臺（OpenApi），由系統平臺進行數據的處理後進行入庫，供經分系統進行單用戶或批量用戶的查詢。
2數據結構
2.1數據結構設計
Hbase底層是基於列式存儲的，可以在不浪費存儲空間的情況下將表設計得非常稀疏。因此可以將所有的用戶行爲數據存儲在一張寬的表中，消除在進行“行爲間組合查詢條件”查詢時帶來的表聯開銷。由於Hbase目前並不能很好的處理兩個或者三個以上的列族，本場景中採用單列族設計，列族的大版本數（MaxVersion）設定爲1。想要獲得較好的查詢效率，應該將頻繁查詢的條件放在RowKey中，儘量保證查詢條件都在RowKey中有所體現。從圖3可以看出Hbase的查詢效率從高到低依次爲RowKey、ColumnFamily、ColumnQualifier、TimeStamp和Value。因此想要獲得較好的查詢效率，應該將頻繁查詢的條件放在RowKey中，儘量保證查詢條件都在RowKey中有所體現。本應用場景中，需要頻繁查詢的條件依次爲用戶身份標識（userID）、行爲發生時間、行爲類型和行爲類型所包含的字段及其屬性值。根據查詢條件的頻繁度，可將RowKey設計成userID、行爲發生時間和用戶行爲ID的組合。同時考慮到RowKey的散列性，Key設計方案爲：反轉userID+“，”+行爲發生日期+“，”+用戶行爲ID。由於單個用戶在特定的某一天，相同的行爲類型可以發生多次（例如123456789用戶在2013年9月1日這一天可以發生多次播放行爲），如果採用真實的字段名稱作爲列名，後來寫入的數據會把前面寫入的數據覆蓋掉。爲了保證數據的完整性，需要在原有字段名的後面加上一個當天唯一的列ID以作區分。列ID僅僅爲了保證數據的完整性，無任何實際意義，可以是一個從0開始依次遞增的數字序列。
2.2數據格式
源數據部分表示由平臺產生的原始日誌，自訂部分表示源數據經過人工處理後的擴展屬性，行爲ID爲人爲定義，列ID爲人工生成的標識ID。列ID在一天內的.同一個行爲日誌中具有唯一性。由反轉userID和用戶行爲發生的日期以及用戶行爲ID組成RowKey，由真實的列名加上列ID組成Hbase裏面的列名。
3數據處理
源數據入庫過程分爲2個步驟，源數據處理和並行入庫。源數據處理部分進行源數據整理，包括日誌的清洗，RowKey和列ID的生成。並行入庫過程將處理好的源數據以MapReduce方式將源數據匯入到Hbase中。
3.1數據入庫
源數據處理過程負責進行數據清洗及RowKey和列ID的生成，並將生成好的數據檔案拷貝到HDFS中。一種列ID的設計方案是將列ID設定爲一個從0開始依次遞增的數字序列，此ID使得同一天內，同一種用戶行爲類型的每一條數據都具有唯一標識。以表1中模擬的播放日誌數據爲例。並行入庫部分負責將處理好的源數據以MapReduce方式從HDFS匯入到Hbase中。此方式透過讀取HDFS上的檔案，以Put的方式在Map過程中完成數據寫入，無Reduce過程。
3.2數據查詢
進行用戶行爲軌跡查詢時需要輸入userID的集合、用戶行爲發生的時間區間和行爲類型資訊這3個參數。這3個參數限定了查詢的範圍，即指定用戶在指定時間內發生的指定行爲。透過解析userID參數可以得到RowKey的前綴部分；解析用戶行爲發生的時間區間參數可以得到RowKey的中間部分；解析行爲類型參數可以得到RowKey的後綴部分和各行爲查詢所需要的字段。組成RowKey的全部參數集合都確定後，可以透過迭代將查詢所涉及到的RowKey全部窮舉出來，生成Get對象的列表，進行批量提交。在生成Get對象的時候，可以調用多重列前綴過濾器（MultipleColumnPrefixFilter），使查詢結果只包含所需字段，提高查詢效率。
3.2.1單用戶查詢
查詢數據時，根據上文提到的查詢邏輯，將生成的Get的列表一次性提交，獲取查詢結果。由於Hbase的設計是基於列的，想要使查詢結果按行顯示，還需進行查詢結果的解析。同時，部分在HBase中無法實現的數據篩選功能如“行爲間組合查詢條件”、值過濾等，可在此時透過編程語言靈活實現。遍歷結果進行解析時，可以生成一個哈希表resultMap、resultMap的key爲列ID、value爲真實字段名的字元串組合。在遍歷中可以根據列ID將真實字段名所對應的查詢值替換哈希表中value的值。遍歷完成後對resultMap的值集合進行排序，排序結果即爲用戶的行爲軌跡。此方法僅需對查詢結果進行一次遍歷即可完成解析。
3.2.2批量用戶查詢
批量用戶查詢時採用MapReduce方式提交查詢、解析查詢結果。由於Hbase官方提供的MapReduce接口InputFormat（TableInputFormat）只支援Scan方式來獲取數據，並不適用Get方式。因此實現批量用戶行爲軌跡的分佈式提取和解析，需要自訂3個類，即PrefixInputFormat（繼承自InputFormat）、PrefixSplit（繼承自InputSplit）和PrefixRecordReader（繼承自RecordReader）。自訂這3個類的目的在於將輸入的userID參數（包含RowKey前綴資訊）、日期區間參數（包含RowKey中間部分資訊）和用戶行爲類型參數（包含RowKey的後綴資訊和查詢所需的列）傳入到PrefixInputFormat中，在PrefixInputFormat根據每個userID所在的Region將其分配到不同的PrefixSplit上，在PrefixRecordReader中根據PrefixSplit傳入的參數資訊完成RowKey的組裝和Get列表的生成，並將Get列表作爲VALUEIN傳遞給Mapper進行查詢和解析。
4性能對比
測試數據：天翼視訊9月1日到10日之間10d的登陸、播放、訪問和訂購數據，總計條數約1億條，日誌檔案總大小21G；任務描述：找出在9月1日到9月10日這段時間內輸入用戶集合中同時發生播放、訂購、訪問、登陸4種行爲的活躍用戶，並提取這部分用戶在這段時間內的用戶行爲軌跡。
5結論
本文透過對HBase數據架構及數據字段設計的分析，設計了基於互聯網電視用戶行爲分析的數據系統模型和數據庫表結構。經過實際測試發現，在提取用戶行爲軌跡的數據分析時，HBase與傳統的關係型數據庫相比，在讀寫性能上均具有明顯優勢。伴隨互聯網電視業務發展和用戶行爲數據量的增加，對用戶行爲數據的查詢及分析顯得尤爲重要目前,在對普通的互聯網電視用戶的盒端對用戶行爲數據的採集方面還不夠完善，還需要繼續完善補充用戶行爲字段，優化完善基於HBase數據字段及數據庫結構，建立數據挖掘模型，透過對用戶行爲數據的深層次挖掘分析來優化完善業務和產品，爲互聯網電視業務在新疆兵團的持續優化發展和運營分析提供決策支援。