基于Hadoop 的教學資源存儲與檢索研究

劉婭

(連云港師范高等專科學校 數學與信息工程學院,江蘇 連云港 222006)

1 概述

隨著校園網中教學資源的不斷積累,通常需要擴展數據庫系統容量以滿足應用需求。目前擴容傳統的關系數據庫系統有兩種技術方案：一種是使用更大的服務器,解決數據庫磁盤空間不足的問題。這種方法需要購置新的設備,增加了運營成本。另一種是使用集群,將大量成本較低、性能一般的PC 組成集群,利用集群完成海量數據的存儲和計算。即當存儲空間不足時,在集群上增加節點,通過增加Region Server 的數量擴展容量。例如：將集群從3 個擴充到5 個Region Server 時,存儲空間和處理容量都可以同時翻倍。Google 是大數據技術架構的標桿,多年來它一直踐行低成本之道：使用大量普通的PC 服務器,提供有冗余的集群服務。因此,從技術和成本出發,本文采用Hadoop 集群的方法擴容校園網數據庫系統。

2 核心存儲策略

校園網中教學資源的特點是數據量大,數據類型多。既存在課程編號、課程名稱等可以用固定數據類型表達的資源,又存在無法用固定數據類型表達的資源,如圖像、音頻、視頻、教學文檔等。視頻等非結構化資源的數據量比結構化資源的數據量要大,可以達到10 幾倍甚至幾十倍的體量。

HBase 是運行在Hadoop 集群下的一個面向列、基于鍵值的開源的分布式數據庫[1-2],具有很強的擴展性。HDFS 是Hadoop 兼容性最好、標準的分布式文件系統,以流的方式進行訪問,具有高效的數據處理模式：一次寫入、多次讀取[3-4]。針對校園網中教學資源的特點及應用場景,采用基于Hbase 和HDFS 的存儲策略：使用HBase 存儲課程編號、課程名稱等格式化數據,而視頻等非格式化數據資源則使用適合存儲大文件和流式讀寫操作的HDFS 文件系統存儲。

3 存儲結構設計

3.1 Hbase 表設計

圖片、視頻等非格式化資源是教學資源管理的難重點。下面設計存儲非格式化資源的Hbase 表。

3.1.1 文檔資源信息表

該表用以存儲文檔資源信息,包括WORD、PDF 等電子文檔。HBase 官方建議列族的數量不要超過3 個,并且盡可能少[5]。因此,表設計兩個列族：BASE_Info 用以存儲文檔資源的基本信息,EXT_Info 用以存儲文檔資源的擴展信息,邏輯結構如表1所示。各列定義如表2 所示。

表1 文檔信息表

表2 文檔信息表列定義

3.1.2 圖片資源信息表

該表用以存儲圖片資源信息,包括IMG 、BMP、JPG 等。邏輯結構如表3 所示。

表3 圖片信息表

表3 中列族BASE_Info 與表1 中的BASE_Info 相同。EXT_Info 中列定義如表4 所示。

表4 圖片信息表擴展列定義

3.1.3 音、視頻資源信息表

該表用以存儲音頻和視頻資源信息,包括各類音頻和視頻文件。邏輯結構如表5 所示。

表5 音視頻信息表

表5 中列族BASE_Info 與表1 中的BASE_Info 相同。EXT_Info 中列定義如表6 所示。

表6 音視頻信息表擴展列定義

3.2 行鍵設計

行鍵(Rowkey)是HBase 表行的主鍵,是行的唯一標識。一般情況下,Hbase 表僅支持基于主鍵的查詢,非主鍵查詢只能通過全表Scan 來進行,導致成本高、效率低。因此,行鍵的設計是關鍵點,直接影響從HBase 中讀取數據的性能。根據HBase 表行鍵設計原則和教學資源管理要求,存儲非格式化資源表的行鍵格式如下所示：

Rowkey =< User_ID >< File_ID >< C_TM >

加鹽前綴(salt) 確保所有行數據均勻分布在Region Server上,實現負載均衡。HBase 中的行是按照RowKey 在字典中的順序排序的,RowKey 相近的行存儲在相近的位置,這對Scan 操作非常友好,順序讀的效率比隨機讀要高。但是,如果大量的讀寫操作總是集中在某個RowKey 范圍,那么使得某個RegionServer 成為熱點,拖累RegionServer 的性能。一般來說校園網會劃分多個子網,將子網和RegionServer 都按數字編號：0,1,2…,每個子網的數據存儲到相同編號的RegionServer 上。這種方法能很好的實現負載均衡。

RowKey 中的User_ID(用戶編號)+ File_ID(文件編號)+C_TM(文件創建時間)組合,能滿足多條件查詢。文中對于非格式化數據資源采用HDFS 文件系統存儲,在HBase 在表中存儲其文件信息。假設當前有一個存儲非格式化資源的HBase 表,部分數據如表7 所示。

表7 音視頻數據表

User_ID 存儲在另一張表中,User_ID 含義如下：1 代表張三；2 代表李四；3 代表王五。File_TP 也存儲在另一張表中,File_TP 含義如下：1 Doc 文檔資源,包括WORD、PDF 等電子文檔；2 Img 圖像資源,包括BMP、JPG 等；3 Video 音視頻資源,包括各類音頻、視頻文件；4 Other 其他資源。現有一個多條件的查詢要求：查找“張三”在“20200907 到20200917”期間創建的關于“課程簡介”的“視頻”數據。查詢時同時輸入5 個條件find(20200907, 20200917,“課程簡介”,“視頻”,“張三”),可以得到第1 和第5 條記錄。第2 條記錄由于不屬于“張三”所以不會被查詢到。

行鍵是按字典序有序存儲的,這個特性也要求其設計為定長的[4]。根據Hbase 官方文檔,行鍵長度不要超過16 個字節。設計行鍵為salt 為1 個字符,User_ID 為6 個字符,File_ID 為6 個字符,C_TM為8 個字符。

3.3 Hbase 表壓縮

壓縮是數據庫解決存儲的重要手段,對Hbase 表進行數據壓縮目的有兩個：(1)節省存儲空間；(2)減少網絡傳輸的數據,減輕網絡傳輸負載。Hbase 支持的壓縮格式有：GZ, Snappy,LZ0,LZ4。GZ:適用冷數據(數據訪問不頻繁)壓縮,壓縮率較高,解壓/壓縮速度慢,CPU 消耗高。Snappy 和LZ0：用于熱數據(數據訪問頻繁)時使用壓縮,CPU 消耗低,解壓/壓縮速度比GZ 快,但是壓縮率不如GZ 高。LZ4 具有極高的解壓/壓縮速度,壓縮率和LZ0 的壓縮率相當。大部分應用,開啟Snappy 或者LZO 壓縮會是比較好的選擇。其中Snappy 整體性能優于LZO,主要表現在解壓/壓縮速度更快,是使用較多的一種壓縮方式。因此,本文采用它作為數據壓縮算法。

4 二級索引設計

Hbase 表使用RowKey 精確查詢一條記錄, 如果不通過RowKey 查詢數據, 就需要全表掃描, 效率非常低。為了使非RowKey 字段檢索也能做到秒級響應,或者支持各個字段進行模糊查詢等,需要構建二級索引,以滿足現實中復雜多樣的應用需求。例如查詢用戶時可能需要通過用戶名、姓名、手機號查詢。設計時不能把查詢字段都放到RowKey 中,RowKey 的長度有限制。二級索引的本質就是建立各列值與RowKey 之間的對應關系,通過二級索引搜索滿足條件的 RowKey,之后再利用RowKey 進行相應的查詢。

假設現在需要查詢包含“聽力訓練”的“音頻”數據,也就是說2 個條件同時輸入：find(“聽力訓練”,“音頻”)。RowKey 現在不能使用,就需要用二級索引來解決這個問題。解決方案如下：

第一步：創建兩張HBase 表。第一張HBase 表的RowKey 是數據中的File_NM字段的值,每一個列的值就是“音視頻”表的RowKey(和Name 對應的RowKey),這張表命名為name_indexer表。第二張HBase 表的RowKey 是數據中的File_SUBTP 字段的值,每一個列的值就是“音視頻”表的RowKey(和File_SUBTP 對應的RowKey),這張表命名為file_subtp_indexer 表；

第二步：將“音視頻”表中的記錄導入name_indexer 和file_subtp_indexer 表。

建立了對應的二級索引表后,就可以實現非RowKey 的非全表查詢,查詢過程如下：

第一步：按照RowKey 從name_indexer 表中查詢“聽力訓練”的記錄,查詢到的記錄的所有列值就是需要在“音視頻”表中查詢的RowKey 的值。

第二步：按照RowKey 從file_subtp_indexer 表中查詢“音頻”的記錄,查詢到的記錄的所有列值就是需要在“音視頻”表中查詢的RowKey 的值。

第三步：合并上面兩步查詢出來的記錄并去重,得到了在“音視頻”表中符合需求的RowKey,然后在根據這些RowKey 去“音視頻”表中查詢。

上述的每一步查詢都是根據HBase 中的一級索引RowKey 來查詢,所以查詢速度非常快。解決方案中第二步使用Phoenix 的覆蓋索引實現,即把原數據存儲在索引數據表。

5 性能測試

測試環境：在具有3 個節點的集群上搭建測試環境。使用YCSB(Yahoo! Cloud Serving Benchmark")作為測試工具。

測試場景: YCSB 自帶了6 種壓力測試場景, 選擇其中的a場景(50%的讀和50%的寫)進行測試。

測試結果：

[OVERALL], RunTime (ms),2689.0 // 數據加載所用時間：2.689 秒

[CLEANUP], AverageLatency(us),62574.0 // 平均響應時間62.574ms

[INSERT], Operations,100.0 //執行insert 操作的總數,100

[INSERT], AverageLatency (us),13580.54 //每次insert 操作的平均時延,13.58054ms

測試結果顯示：數據庫性能良好,能滿足教學資源管理需求。

6 結論

本文基于Hadoop 技術對教學資源進行存儲管理。設計了Hbase 數據庫中存儲資源的表的邏輯結構,針對查詢需求重點設計了行鍵和二級索引。最后,通過實驗測試數據庫性能。結果表明數據庫性能表現良好,能夠有效進行教學資源的存儲管理。