基于HBase/Spark的教學大數據存儲及索引模型研究

唐 立，李亞平，曲金帥

(1.安徽經濟管理學院 信息工程系，安徽 合肥 230031;2.安徽經濟管理學院 教務處，安徽 合肥 230031；3.合肥工業大學 管理學院，安徽 合肥 230009；4. 云南民族大學 云南省高校信息與通信安全災備重點實驗室，云南 昆明 650500)

隨著教育領域對大數據訴求的增強，教學過程與結果數據的持續采集，動態匯集成了新數據形式的教學大數據.教學大數據更能精準刻畫全維度的“學生畫像”，服務于師生教學和學校管理[1].而傳統的關系型數據庫系統用來儲存爆炸式增長的教學大數據將力不從心，非關系型數據庫系統具有強大的擴張性和高并發性，可以彌補關系型數據庫的不足[2].

非關系數據庫中的apache HBase是開源分布式的列式存儲系統，因為它有高擴展性和并發性而被廣泛使用，成為當前的熱門存儲技術之一[3].目前針對HBase存儲和查詢的相關研究比較多，如李正武[4]利用Hadoop集群的HBase對區域化橋梁健康監測數據進行分布式存儲；李攀宇[5]利用HBase分布式存儲交通數據，運用HBase的行鍵設計結合二級索引，解決時空維度分布不均引起的熱點問題；董萌萍[6]設計與實現了一種基于HBase的農作物病蟲害數據存儲系統，彌補傳統關系數據庫的不足.以上研究針對不同的應用場景，設計出不同模式的HBase存儲以解決數據在存儲與查詢過程中面臨的效率問題.但是數據存儲時的負載均衡和寫熱點問題，索引時針對屬性過濾的效率問題都沒有得到很好的解決.

本文根據教學大數據存儲結構的特點和常用查詢概率出發，設計了基于組合行鍵的HBase系統，進行Region預分區和構建cost評分函數，解決寫熱點和負載均衡的問題.然后利用組合行鍵和Spark分布式的屬性過濾，到達快速查詢的目的.

1 教學大數據存儲與索引系統框架

教學大數據是指教學活動產生的，根據教學需求采集到的，用來促進教學模式創新以及教學質量提升的數據集合[1].教學大數據來源比較廣泛，數據大量而分散，結構復雜而異構.為了實現此類大數據的檢測統計、管理、預測和分析等智能應用，就要建立一套完整的教學大數據存儲與索引系統，實現海量教學數據的存儲和查詢，為智能化教學應用提供高效的數據支撐.

本文設計基于Spark/HBase的教學大數據系統框架如圖1所示.框架主要分為2大塊：1)通過數據元數據或教學數據的采集，構建HBase表.主要經過行鍵設計，行鍵表達式和算法實現，負載均衡問題解決，然后入庫.2)根據用戶查詢請求，進行語義分析，邏輯優化，基于行鍵過濾出模糊結果集，然后基于SparkRDD分布式處理進行屬性過濾，得到精確查詢結果.

系統要解決的問題：1)基于HBase的存儲設計，如何既能滿足索引需求，又能解決均衡負載和寫熱點問題，達到高效存儲目的.2)快速索引，對于用戶提出的多特征值的復雜查詢問題，如何利用行鍵和SparkRDD快速進行收索，滿足用戶查詢的需求.

2 基于HBase的教學大數據存儲設計

根據HBase表的邏輯結構特點，將教學大數據的模型設置為由行鍵RowKey、列族ColumnFamily和時間戳TimeStamp組成，如圖2所示.根據查詢需求把行鍵設計為組合行鍵，用于對教學數據的唯一索引.列族映射存放著教學數據的其他屬性，同時也可以按需求動態擴展屬性列.時間戳主要是標記數據的記錄時間，便于區分數據的不同版本.

2.1 教學大數據的組合行鍵的設計

在HBase中構造存儲數據表，行鍵的設計是最為關鍵的.行鍵就是要反映數據重要特征字段的，并且具有唯一性.為了提高數據查詢性能，利用教學數據中查詢頻率最高的若干個字段組合成行鍵，與普通列值數據冗余存放在多張HBase數據表中.

通過教學大數據的日常查詢記錄和管理日志來看，關于CourseID、StudentID、TeacherID的特征值查詢符合大多數用戶的查詢習慣，基于CourseID、StudentID、TeacherID的特征值的查詢頻率較多.同時由于CourseID在教學大數據中的占有比例相對于StudentID、TeacherID要小，如果把CourseID作為單獨的行鍵索引會增大查詢開銷.因此本文設計2張表，分別以和< CourseID>2種組成的復合行鍵.這樣當CourseID固定后做查詢時，通過 和 表可對StudentID或TeacherID的不同組合做精細查詢.這種方式的具體實現如下：

CourseID+ StudentID：

Row-Key:CourseID{

Column Family: StudentID{

Column:( Attribute)

}

}

CourseID+ TeacherID：

Row-Key:CourseID{

Column Family: TeacherID {

Column:( Attribute)

}

}

2.2 RowKey表達式及行鍵生成算法

RowKey表達式是一般都是特征值的編碼與解碼規則.RowKey通過對字段來源的抽象和約定，按一定的規則定義好RowKey，然后執行數據轉換時解析RowKey表達式，并從指定位置提取多個特征值[7].本文組合RowKey表達式是從HBase中的數據行鍵將字段名、字段名稱值或固定字符按一定的形式轉換運算后生成的.組合RowKey的生成算法如下.

定義1轉義字符表達式為[ ]，解碼時對括號里的內容進行轉義計算.

定義2字段名表達式C(index)，獲取索引為index的字段名稱.

定義3字段值表達式V(name|index)，按字段名稱或索引號來獲取字段值.

定義4字符串斷取表達式Sub(string，start，num)，從字符串string的start位置斷取num數量的字符.

定義5字符串的格式化表達式T(format)，將字符串轉換為format對應的格式.

定義6文件名表達式為F，表示獲取的數據文件名稱.

步驟1 讀取行鍵表達式字符串如“CDE”，并將字符串分解成字符集合EXP.

步驟2 初始化變量：遍歷行鍵字符集合EXP，循環變量n=0；臨時緩存字符串TMP；轉義控制符TC初始為false；字符串控制SC初始為false；返回結果字符串SR初始為空；狀態變量S初始為空.

步驟3.1 初始轉義控制符TC=false；表示處于非轉義的狀態.

對于畫面上2/3區域，我們使用了去朦朧+46、飽和度-16的漸變濾鏡進行處理。去霧工具在提高反差的同時也會增強畫面飽和度，所以我們使用了負向的飽和度設置平衡這個問題。遠景的山脈受到的霧氣影響更加明顯，所以我們再使用去霧設置為+18的畫筆工具對這個部分進行一些額外的手動處理?，F在，畫面整體看上去有些偏藍。一般情況下我會重新調整白平衡設置來解決這個問題，對于這張照片來說，我覺得使用色溫7400、色調+4的參數，效果恰好給綠色帶來了更豐富的變化。

步驟3.2 對字符串EXP[n]進行判斷：‘[’表示轉義開始，并設置TC=true，否則將EXP[n]添加到SR，跳轉步驟3.6；‘]’表示轉義結束，TC= false，把TMP添加到SR，接著跳轉到步驟3.6，否則繼續進行一下步.

步驟3.3 對字符串控制SC的判斷：當SC= true處于字符狀態，若EXP[n]為空表示字符狀態結束，與此同時設置SC= false，若EXP[n]不為空，則將EXP[n]添加到TMP中，再跳轉步驟3.6；當SC= false，則進一步判斷，運行步驟3.5.

步驟3.4 判斷 EXP[n]是否為空，如果是空則表示開啟字符狀態，SC設置為 true，跳轉步驟3.6；如果EXP[n]是非空，字符是文件名，則取文件名放入TMP，字符是C、T、V、Sub中的任意一個，則S設置為相應的字符，再跳轉步驟3.6.如果都不是則繼續下一步.

步驟3.5 如果EXP[n]為‘)’，是指一個帶參數的符號結束，根據S中的符號類型，C取列名，V取列值放入TMP，T按String.Tostring(format)的方法將TMP進行格式化，Sub斷取TMP的字符串.

步驟3.6n+=1，如果n小于或等于集合中的最大行數，則回到步驟3.1，否則進行下一步.

步驟4 返回SR.

按照以上算法步驟舉例，現有教學大數據中一系列命名為CourseID_A_01012.DAT的課程數據文件，使它以組合RowKey的算法存入HBase數據庫中，則RowKey表達式為Sub(F,10,1)Sub(F,14,3)"S"V(StudentID).T("000").式中的F是指CourseID_A_01012.DAT文件名字符串、Sub(F,10,1)斷取文件名稱為F中的第10個字符、Sub(F,14,3)斷取文件名稱F中的第14，15，163個字符、"S"取固定字符S、V(StudentID).T("000")取StudentID列的值并轉換格式為"000"，最后將這些字符順序的組合起來.教學大數據的存儲轉換過程如圖3所示.

2.3 數據入庫及均衡負載優化處理

整個教學大數據入庫流程如圖4所示.1)根據教學元數據文件特點以及查詢習慣設計組合行鍵；2)根據設計好的RowKey，歸類相應的教學數據列族；3)提取教學大數據屬性數據的名稱和值，作為HBase列族的列限定符和列值；4)按組合行鍵的記錄，根據規則匹配入庫到指定的Region預分區.

本文的RowKey設計是一種組合RowKey，因為這種組合RowKey的前綴本是取元數據文件名的第10個字符，如2.2節所述，該字符表示的是教學中Course的學科類別，本身不是有序的，所以這樣組合RowKey設計本身就解決了寫熱點問題[9].

根據教學大數據的特點，以Course的類別來預設分區以緩解負載均衡問題.首先是按一級學科進行分類成若干個Region Server；然后對每個Region Server再分出若干個二級或三級學科Course集的Region，由于本文設計的組合RowKey是與Course有密切關系，很容易根據RowKey將Course存放在對應的Region中；最后把選取負載因子作為請求數目預測值，構建cost評分函數，以此來檢測并遷移負載，達到負載均衡的目的.其算法過程如下：

收集每分鐘每一個Region的寫入請求數目，得到長度為n的序列R=(r1，r2…，rn),使用二階差分指數平滑法對未來寫請求數進行預測[10].

(1)

(2)

(3)

最終預測結果如下：

(4)

數據熱度值θi是按秒為單位，就是對預測值除以60，如公式(5).

(5)

對HBase集群中的每個Region Server的負載總和計算如公式(6)，其中m為當前Region Server下的Region總數.

(6)

平均負載的計算如公式(7)，其中k是Region Server的數目.

(7)

我們設定最大負載loadmax=1.05×loadavg，最小負載為loadmin=0.95×loadavg.當1個Region Serverj的負載滿足loadminloadmax，表示超載；而loadj

cost = write_cost + msize_cost +sf_cost + locality_cost.

(8)

公式(8)中：write_cost為寫請求，msize_cost為memstore容量評分，sf_cost為StoreFile評分，locality_cost本地性評分.

個Region Server超載的情況下，需要根據公式(8)cost測評函數[11-12]遍歷計算出負載不足的Region Server中最小的Region，并執行遷移操作，以此來實現負載均衡.

3 基于Spark教學大數據索引

3.1 基于Spark查詢框架

對于教學大數據在智慧教學和教學研究中的應用，在進行數據查詢時，查詢語句是多樣化的，根據各種角色查詢習慣分析，常被用到的查詢條件包含CourseID、StudentID、TeacherID和其他屬性.因此對查詢語義進行解析，提取CourseID、StudentID、TeacherID的常用信息，利用組合行鍵實現模糊結果集的提取.再將模糊結果集以彈性分布式數據集(resilientdistributed dataset，RDD) RDD的形式存儲在Spark的內存環境中，并行完成屬性過濾，得到精確結果集，最終將結果返回給用戶.

基于Spark的教學大數據框架如圖5所示，其過程為：1)用戶根據需求提交查詢條件；2)對查詢語義進行解析，提取與組合行鍵相關的特征條件，同時對查詢語義進行邏輯優化；3)運用組合行鍵的算法從HBase表中篩選出符合特征條件的模糊結果集；4)將模糊結果集以SparkRDD形式分布存儲在內存環境中[13]，根據邏輯優化后的查詢條件，對其他數據屬性進行分布式過濾查詢；5)每個RDD并行過濾查詢，得到相應的結果RDDr；6)排序合并所有的RDDr，把查詢結果返回給用戶.

3.2 組合行鍵的算法

本文是依據用戶查詢習慣，提出基于組合行鍵的查詢，根據查詢條件CourseID+ StudentID和CourseID+TeacherID兩種不同的組合行鍵，可以快速度得到模糊結果集，具體算法如下：

輸入查詢條件θ

輸出組合行健集合查詢的模糊結果集FR

利用SparkRDD對模糊結果集進行分布式屬性filter，最終精確結果集合.

4 實驗與分析

4.1 實驗數據與運行環境

本文的實驗數據采集于安徽經濟管理學院教務處2008年以來所有的學生數據，其中除了包含關系型元數據，還有非關系型非結構化數據如：視頻、圖像、聲音等，數據量約為110萬條.為了比對大數據量處理能力，在此數據基礎上，通過代碼生成技術生成約 2 000 萬條.

本實驗所用的Spark與HBase部署在以1個Master節點和3個Slave節點的集群框架上.所有節點機器配有CUP i3 2.75GHZ 、內存4G配置，使用linux操作系統.服務平臺配置為ThinkServer RD650，處理器類型E5-2609v4，內存 16 GB，硬盤1T.所使用的HBase版本為1.3.1，Spark為2.1.0，Hadoop為2.7.3.其中HBase的實驗平臺中的Master和Region Servers分布如圖5所示.

4.2 寫入對比實驗結果與分析

原生系統是未設置預分區，本文采用的是組合rowkey設計，對表使用預分區后，采用負載均衡優化后的系統.進行插入操作，進行批量的數據寫入操作，如圖6所示.

通過圖6可以看出優化后的HBase系統相對于優化前提高了寫入性能.沒有優化的原生態系統，沒有預分區，會不斷自我分裂造成運算時間的消耗，同時連續性增長的rowkey，會造成寫熱點問題不斷頻發，從而耗費大量的寫入響應時間.

4.3 檢索對比實驗和分析

把實驗數據按不同數量分類，在相同檢索條件下，以文獻[4]基于Hadoop下的檢索和本文提出的基于Spark下的檢索進行對比實驗，如圖7所示.

可以從圖7看出，基于Spark的檢索比文獻[4]基于Hadoop的檢索時間要小，而且隨著數量級別越大，它們的檢索時間差距越大.這是因為Spark是基于內存的并行計算框架，它具有彈性分布式數據集RDD和分布式運行架構，可以精確讀取存儲的數據，幾乎沒有磁盤訪問的時間開銷，所以基于Spark的分布式屬性過濾可以大大提高教學大數據的查詢速度.

5 結語

為了滿足教學大數據的存儲和索引的需求，實現對海量教學數據進行準確高效的處理和管理.本文設計了基于Spark/HBase的教學大數據存儲和索引模型，它基于HBase設計組合行鍵，并根據Course的類別進行預分區后，通過負載因子預測請求數，構建cost評分函數，來檢測并遷移負載，達到解決寫熱點和負載均衡的問題.然后利用組合行鍵對查詢數據進行模糊集篩選，通過Spark分布式的屬性過濾，實現高效查詢目的.實驗證明該模型設計的有效性，通過與原生系統和文獻[4]進行對比，本文設計的模型在存儲寫入和查詢響應時間上具有明顯優勢.

在研究的實驗過程中也發現了問題，研究適合大部分常規查詢用戶范疇，但是如果遇到非典型的非行鍵的列查詢，則需要對全表進行掃描了，這樣的查詢效率并不高.后續將對此繼續展開研究.