宋陽

（上海大學(xué)計(jì)算機(jī)工程與科學(xué)學(xué)院，上海 200444）

1 引言

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

2 文本存儲(chǔ)

文本存儲(chǔ)是最簡單最高效的存儲(chǔ)方式，具有存儲(chǔ)成本低的優(yōu)勢。但是，以文本形式存儲(chǔ)的數(shù)據(jù)很難進(jìn)行數(shù)據(jù)分析。因?yàn)楦鱾€(gè)系統(tǒng)產(chǎn)生的數(shù)據(jù)格式不同，在分析文本數(shù)據(jù)前，需要耗費(fèi)大量的人力對其進(jìn)行數(shù)據(jù)預(yù)處理，甚至轉(zhuǎn)換到其他存儲(chǔ)形式后再進(jìn)行分析處理，這給數(shù)據(jù)的利用造成了極大的困難。

但是，由于文本存儲(chǔ)的實(shí)現(xiàn)方式簡單，在缺乏人力和設(shè)備資源的高校，或者在沒有可見的數(shù)據(jù)分析需求的情況下，先對數(shù)據(jù)以文本的形式存儲(chǔ)下來不失為一種簡單易行的辦法。但也要重視對文本文件的備份和管理，注重?cái)?shù)據(jù)的完整性，為今后的數(shù)據(jù)應(yīng)用和擴(kuò)展提供便利。

3 關(guān)系型分布式數(shù)據(jù)庫

關(guān)系型分布式數(shù)據(jù)庫是數(shù)據(jù)庫技術(shù)與網(wǎng)絡(luò)技術(shù)相結(jié)合的產(chǎn)物。分布式數(shù)據(jù)庫的典型定義是:分布式數(shù)據(jù)庫是一個(gè)數(shù)據(jù)集合，這些數(shù)據(jù)在邏輯上屬于同一個(gè)系統(tǒng)，但物理上卻分散在計(jì)算機(jī)網(wǎng)絡(luò)的若干站點(diǎn)上，并且要求網(wǎng)絡(luò)的每個(gè)站點(diǎn)具有自治的處理能力，能執(zhí)行本地的應(yīng)用[1]。

3.1 關(guān)系型分布式數(shù)據(jù)庫的優(yōu)勢

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

3.2 關(guān)系型分布式數(shù)據(jù)庫的缺點(diǎn)

關(guān)系型分布式數(shù)據(jù)庫的部署復(fù)雜度比較高，而且對數(shù)據(jù)庫管理員的技能要求較高。通信開銷較大也是關(guān)系型分布式數(shù)據(jù)庫的困難點(diǎn)，當(dāng)故障發(fā)生后系統(tǒng)恢復(fù)也比較復(fù)雜。例如，在網(wǎng)絡(luò)通信傳輸速度不高時(shí)，系統(tǒng)的響應(yīng)速度慢，與通信相關(guān)的因素往往導(dǎo)致系統(tǒng)故障，同時(shí)系統(tǒng)本身的復(fù)雜性也容易導(dǎo)致較高的故障率。

分布式數(shù)據(jù)庫比較典型的應(yīng)用在銀行系統(tǒng)、大型連鎖超市、交通票務(wù)系統(tǒng)等。分布式數(shù)據(jù)庫系統(tǒng)往往需要一個(gè)專業(yè)團(tuán)隊(duì)的時(shí)刻維護(hù)，人力成本較高。由于成本和人力資源上的要求，在一般規(guī)模的高校中，分布式操作系統(tǒng)并不一定適用。高校在考慮部署分布式數(shù)據(jù)庫時(shí)，需要考慮是否具有維護(hù)數(shù)據(jù)庫的必要條件。

4 非結(jié)構(gòu)化數(shù)據(jù)庫

非結(jié)構(gòu)化數(shù)據(jù)庫（NoSQL）不以符合關(guān)系型范式作為表設(shè)計(jì)要求，而以一定的數(shù)據(jù)冗余方便數(shù)據(jù)的存儲(chǔ)和查詢。非結(jié)構(gòu)化數(shù)據(jù)庫發(fā)展迅速，而且絕大多數(shù)都提供了分布式部署的方案，十分適合存儲(chǔ)海量數(shù)據(jù)。

4.1 非結(jié)構(gòu)化數(shù)據(jù)庫的優(yōu)勢

非結(jié)構(gòu)化數(shù)據(jù)庫最近幾年的發(fā)展迅速，開源社區(qū)十分活躍，有大量的優(yōu)質(zhì)開源項(xiàng)目和及時(shí)的維護(hù)團(tuán)體，發(fā)行版本更迭迅速。由于不用維護(hù)文檔之間的二維關(guān)系，非結(jié)構(gòu)化數(shù)據(jù)庫具有易于操作和管理的優(yōu)勢。非結(jié)構(gòu)化數(shù)據(jù)庫與關(guān)系數(shù)據(jù)庫為互補(bǔ)關(guān)系，在應(yīng)用中要發(fā)揮非結(jié)構(gòu)化數(shù)據(jù)庫長于存儲(chǔ)和檢索的功能，將占用空間比較大的非結(jié)構(gòu)化檔案數(shù)據(jù)及其元數(shù)據(jù)存到非結(jié)構(gòu)化數(shù)據(jù)庫中，將占用空間不大的元數(shù)據(jù)信息復(fù)制導(dǎo)入到關(guān)系數(shù)據(jù)庫中進(jìn)行管理，以保持?jǐn)?shù)據(jù)之間的聯(lián)系[3]。

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

4.2 非結(jié)構(gòu)化數(shù)據(jù)庫的問題

非結(jié)構(gòu)化數(shù)據(jù)庫在數(shù)據(jù)搜索方面需要付出一定的代價(jià)。MongoDB提供對二級索引的支持，創(chuàng)建索引可以極大地提高數(shù)據(jù)查詢的相應(yīng)速度，但是也會(huì)降低數(shù)據(jù)插入的速度。這一點(diǎn)與結(jié)構(gòu)化數(shù)據(jù)庫的索引所帶來的性能影響類似。

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

5 索引與非結(jié)構(gòu)化數(shù)據(jù)庫的結(jié)合

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

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

6 結(jié)語

本文簡要總結(jié)了幾種適合高校建設(shè)大數(shù)據(jù)存儲(chǔ)系統(tǒng)的幾種方案，并討論了各自的優(yōu)缺點(diǎn)和困難點(diǎn)。在考慮存儲(chǔ)系統(tǒng)應(yīng)有的功能的同時(shí)，也要考慮方案的實(shí)施代價(jià)和維護(hù)成本。一個(gè)好的方案既需要與實(shí)際應(yīng)用需求相結(jié)合的精細(xì)設(shè)計(jì)，也需要在實(shí)踐中不斷探索。