高校大數據存儲方案探索

宋陽

（上海大學計算機工程與科學學院，上海 200444）

1 引言

大數據分析是當今社會的一個熱門話題。隨著科技水平的不斷發展，存儲設備的制造成本不斷下降，各類業務系統逐漸選擇將運行過程中產生的結果和中間數據進行存儲，不再選擇舍棄。隨著數據的不斷積累，人們逐漸認識到，充分利用所積累的數據進行分析，可以得到具有啟發性的結果，為今后的工作決策做支撐。高等院校的信息系統面向全體師生，固定用戶具有一定的規模，而且多數高校的信息化工作已經有很長的時間，在這過程中積累了大量的數據。如今，各個高校越來越重視大數據分析所能帶來的優勢分析，為服務師生提供更好的決策支持。這就涉及高校現有信息系統中的傳統數據存儲方式轉變為適合大數據分析的存儲方式。本文介紹了幾種適合高校大數據存儲的可行方案，并討論了各自的優缺點。

2 文本存儲

文本存儲是最簡單最高效的存儲方式，具有存儲成本低的優勢。但是，以文本形式存儲的數據很難進行數據分析。因為各個系統產生的數據格式不同，在分析文本數據前，需要耗費大量的人力對其進行數據預處理，甚至轉換到其他存儲形式后再進行分析處理，這給數據的利用造成了極大的困難。

但是，由于文本存儲的實現方式簡單，在缺乏人力和設備資源的高校，或者在沒有可見的數據分析需求的情況下，先對數據以文本的形式存儲下來不失為一種簡單易行的辦法。但也要重視對文本文件的備份和管理，注重數據的完整性，為今后的數據應用和擴展提供便利。

3 關系型分布式數據庫

關系型分布式數據庫是數據庫技術與網絡技術相結合的產物。分布式數據庫的典型定義是:分布式數據庫是一個數據集合，這些數據在邏輯上屬于同一個系統，但物理上卻分散在計算機網絡的若干站點上，并且要求網絡的每個站點具有自治的處理能力，能執行本地的應用[1]。

3.1 關系型分布式數據庫的優勢

分布式數據庫通過增加適當的數據冗余，提高系統的可靠性。在集中式數據庫中，盡量減少冗余度是系統目標之一，要求表結構符合范式規則。其原因是，冗余數據浪費存儲空間且容易造成不一致性。而在關系型分布式數據庫中卻希望增加冗余數據，可以打破減少冗余這一要求，在不同的設備、機架、機房中存儲同一數據片段的多個副本，從而提高整個系統的可靠性，并且可以提高系統的整體性能。常見的關系型集中式數據庫MySql和SqlServer等，都提供分布式部署的擴展功能。一旦遷移到分布式數據庫模式后，易于集成到現有的信息系統，也易于擴充數據庫規模[2]。

3.2 關系型分布式數據庫的缺點

關系型分布式數據庫的部署復雜度比較高，而且對數據庫管理員的技能要求較高。通信開銷較大也是關系型分布式數據庫的困難點，當故障發生后系統恢復也比較復雜。例如，在網絡通信傳輸速度不高時，系統的響應速度慢，與通信相關的因素往往導致系統故障，同時系統本身的復雜性也容易導致較高的故障率。

分布式數據庫比較典型的應用在銀行系統、大型連鎖超市、交通票務系統等。分布式數據庫系統往往需要一個專業團隊的時刻維護，人力成本較高。由于成本和人力資源上的要求，在一般規模的高校中，分布式操作系統并不一定適用。高校在考慮部署分布式數據庫時，需要考慮是否具有維護數據庫的必要條件。

4 非結構化數據庫

非結構化數據庫（NoSQL）不以符合關系型范式作為表設計要求，而以一定的數據冗余方便數據的存儲和查詢。非結構化數據庫發展迅速，而且絕大多數都提供了分布式部署的方案，十分適合存儲海量數據。

4.1 非結構化數據庫的優勢

非結構化數據庫最近幾年的發展迅速，開源社區十分活躍，有大量的優質開源項目和及時的維護團體，發行版本更迭迅速。由于不用維護文檔之間的二維關系，非結構化數據庫具有易于操作和管理的優勢。非結構化數據庫與關系數據庫為互補關系，在應用中要發揮非結構化數據庫長于存儲和檢索的功能，將占用空間比較大的非結構化檔案數據及其元數據存到非結構化數據庫中，將占用空間不大的元數據信息復制導入到關系數據庫中進行管理，以保持數據之間的聯系[3]。

例如流行的MongoDB數據庫，提供各種語言的客戶端開發包和數據導入工具，并且文檔十分完善，易于上手。MongoDB支持在集群中部署，提高整體的數據查詢相應速度和擴展性，而且在海量數據集中的查詢性能十分優秀。HBase數據庫是ApacheHadoop項目的一部分，是Apache的頂級項目。HBase建立在Hadoop的分布式文件存儲系統HDFS上，具有更好的可靠性和擴展性，十分適合存儲海量數據。而且HBase與強大的Hadoop大數據處理模型生態圈具有先天的支持優勢，可以無縫的進行Map/Reduce等的數據處理計算。

4.2 非結構化數據庫的問題

非結構化數據庫在數據搜索方面需要付出一定的代價。MongoDB提供對二級索引的支持，創建索引可以極大地提高數據查詢的相應速度，但是也會降低數據插入的速度。這一點與結構化數據庫的索引所帶來的性能影響類似。

HBase不支持二級索引，僅在RowKey和ColumnFamily上有索引，所以對存儲在HBase中的數據進行值的掃描操作是十分耗時的，而且在RowKey的設計上也要求遵循哈希分散的原則，以盡量將數據分散到各個節點上。HBase與MongoDB相比較而言，更適合數據的寫入，而不適合數據的頻繁查詢。

5 索引與非結構化數據庫的結合

在前文中提到，非結構化數據庫雖然在海量數據存儲上具有優勢，但是在數據查詢與篩選上要么犧牲數據錄入速度，要么犧牲響應速度。從這一點出發，如果索引的創建和數據的錄入分開，那么是否可以找到一種更優的方案，既保障數據錄入速度，又能在數據查詢時保持快速響應。王文賢等人提出了一種索引技術與HBase結合的數據存儲方案[4]，并與華為的hindex方案進行了比較。該方案在數據錄入HBase的同時，利用Solr技術創建數據條目的倒排索引，并且在數據查詢時先在solr中進行搜索，再根據搜索結果在HBase中取出數據，從而同時保證了較高的數據錄入速度和響應速度。

創建索引與數據錄入分為了兩個操作，如何保證索引與存儲的一致性是一個挑戰。HBase是基于高可靠性HDFS分布式文件系統之上的，可以保證存儲數據的一致性和完整性，由索引所引入的額外冗余破壞了這一優勢，此時存儲系統不再具有熱機故障恢復的能力。其次，對創建好的索引進行修改也是一個耗費巨大的操作，重新創建索引會導致一段停止服務時間，這在頻繁插入或修改數據的情況下十分影響用戶體驗。這一方案中，索引與業務系統的對接，系統的擴展性，數據冗余開銷代價等都是需要進一步探索的話題。

6 結語

本文簡要總結了幾種適合高校建設大數據存儲系統的幾種方案，并討論了各自的優缺點和困難點。在考慮存儲系統應有的功能的同時，也要考慮方案的實施代價和維護成本。一個好的方案既需要與實際應用需求相結合的精細設計，也需要在實踐中不斷探索。