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

劉婭

(連云港師范高等?？茖W校 數(shù)學與信息工程學院,江蘇 連云港 222006)

1 概述

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

2 核心存儲策略

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

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

3 存儲結(jié)構(gòu)設計

3.1 Hbase 表設計

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

3.1.1 文檔資源信息表

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

表1 文檔信息表

表2 文檔信息表列定義

3.1.2 圖片資源信息表

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

表3 圖片信息表

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

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

3.1.3 音、視頻資源信息表

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

表5 音視頻信息表

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

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

3.2 行鍵設計

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

Rowkey =< User_ID >< File_ID >< C_TM >

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

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

表7 音視頻數(shù)據(jù)表

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

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

3.3 Hbase 表壓縮

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

4 二級索引設計

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

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

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

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

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

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

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

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

上述的每一步查詢都是根據(jù)HBase 中的一級索引RowKey 來查詢,所以查詢速度非?？?。解決方案中第二步使用Phoenix 的覆蓋索引實現(xiàn),即把原數(shù)據(jù)存儲在索引數(shù)據(jù)表。

5 性能測試

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

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

測試結(jié)果：

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

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

[INSERT], Operations,100.0 //執(zhí)行insert 操作的總數(shù),100

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

測試結(jié)果顯示：數(shù)據(jù)庫性能良好,能滿足教學資源管理需求。

6 結(jié)論

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