4.1.4 數(shù)據(jù)分析技術
數(shù)據(jù)分析是Google 最核心業(yè)務,每一次簡單的網(wǎng)絡點擊背后都需要進行復雜的分析過程,因此Google對其分析系統(tǒng)進行不斷的升級改造之中。MapReduce是Google最早采用的計算模型,適用于批處理,其具體內容已在上一節(jié)介紹。圖是真實社會中廣泛存在的事物之間聯(lián)系的一種有效表示手段,因此對圖的計算是一種常見的計算模式,而圖計算會涉及到在相同數(shù)據(jù)上的不斷更新以及大量的消息傳遞,如果采用MapReduce去實現(xiàn),會產(chǎn)生大量不必要的序列化和反序列化開銷,F(xiàn)有的圖計算系統(tǒng)并不適用于Google的應用場景,因此Google 設計并實現(xiàn)了Pregel 圖計算模型。Pregel是Google 繼MapReduce 之后提出的又一個計算模型,與MapReduce 的離線批處理模式不同,它主要用于圖的計算。該模型的核心思想源于著名的BSP計算模型。Dremel是Google 提出的一個適用于Web 數(shù)據(jù)級別的交互式數(shù)據(jù)分析系統(tǒng),通過結合列存儲和多層次的查詢樹,Dremel 能夠實現(xiàn)極短時間內的海量數(shù)據(jù)分析。Dremel 支持著Google 內部的一些重要服務,比如Google 的云端大數(shù)據(jù)分析平臺Big Query。Google 在VLDB 2012 發(fā)表的文章中介紹了一個內部名稱為PowerDrill的分析工具,PowerDrill 同樣采用了列存儲,且使用了壓縮技術將盡可能多的數(shù)據(jù)裝載進內存。PowerDrill 與Dremel 均是Google 的大數(shù)據(jù)分析工具,但是其關注的應用場景不同,實現(xiàn)技術也有很大差異。Dremel 主要用于多數(shù)據(jù)集的分析,而PowerDrill 則主要應用于大數(shù)據(jù)量的核心數(shù)據(jù)集分析,數(shù)據(jù)集的種類相較于Dremel 的應用場景會少很多。由于PowerDrill 是設計用來處理少量的核心數(shù)據(jù)集,因此對數(shù)據(jù)處理速度要求極高,所以其數(shù)據(jù)應當盡可能的駐留在內存,而Dremel 的數(shù)據(jù)則存儲在磁盤中。除此之外,PowerDrill 與Dremel 在數(shù)據(jù)模型、數(shù)據(jù)分區(qū)等方面都有明顯的差別。從實際的執(zhí)行效率來看, Dremel可以在幾秒內處理PB 級的數(shù)據(jù)查詢,而PowerDrill 則可以在30 至40 秒里處理7820 億個單元格的數(shù)據(jù),處理速度快于Dremel。二者的應用場景不同,可以相互補充。
微軟提出了一個類似MapReduce 的數(shù)據(jù)處理模型,稱之為Dryad,Dryad 模型主要用來構建支持有向無環(huán)圖(Directed Acycline Graph,DAG)類型數(shù)據(jù)流的并行程序。Cascading通過對Hadoop MapReduce API 的封裝,支持有向無環(huán)圖類型的應用。Sector/sphere可以視為一種流式的MapReduce,它由分布式文件系統(tǒng)Sector 和并行計算框架sphere 組成。Nephele/PACTs [68]則包括PACTs(Parallelization Contracts)編程模型和并行計算引擎Nephele。MapReduce 模型基本成為了批處理類應用的標準處理模型,很多應用開始嘗試利用MapReduce 加速其數(shù)據(jù)處理。
實時數(shù)據(jù)處理是大數(shù)據(jù)分析的一個核心需求。很多研究工作正是圍繞這一需求展開的。前面介紹了大數(shù)據(jù)處理的兩種基本模式,而在實時處理的模式選擇中,主要有三種思路:
1) 采用流處理模式。雖然流處理模式天然適合實時處理系統(tǒng),但其適用領域相對有限。流處理模型的應用主要集中在實時統(tǒng)計系統(tǒng)、在線狀態(tài)監(jiān)控等。
2) 采用批處理模式。近幾年來,利用批處理模型開發(fā)實時系統(tǒng)已經(jīng)成為研究熱點并取得了很多成果。從增量計算的角度出發(fā),Google 提出了增量處理系統(tǒng)Percolator,微軟則提出了Nectar和DryadInc。三者均實現(xiàn)了大規(guī)模數(shù)據(jù)的增量計算,但是這些系統(tǒng)和MapReduce 并不兼容,因此Incoop和IncMR實現(xiàn)了MapReduce 框架下的增量計算。Yahoo 的Nova則支持有狀態(tài)的增量數(shù)據(jù)計算模式。HOP在MapReduce 處理的過程中引入管道(pipeline)的概念。在保證Hadoop 容錯性的前提下,使數(shù)據(jù)在各個任務間以管道的方式交互,增加了任務的并發(fā)性,提高了數(shù)據(jù)處理的實時性。中國人民大學WAMDM 實驗室在HOP 基礎上開發(fā)的COLA 系統(tǒng)在HOP 系統(tǒng)的基礎上增加了數(shù)據(jù)采樣、結果估計、置信區(qū)間計算等功能模塊,一定程度上提高了HOP 的實時性。原位分析可以避免將文件集中傳輸?shù)椒治龇⻊掌魃系耐ㄓ嶉_銷,大大提高了實時性。和從原位分析的角度出發(fā),分別實現(xiàn)了針對大規(guī)模日志分析的原位MapReduce(In-situ MapReduce)和ContinuousMapReduce。原始的MapReduce 模型并不能很好的支持迭代計算,計算代價很大。而迭代計算是圖計算、數(shù)據(jù)挖掘、機器學習等領域常見的運算模式,不少研究工作通過改進MapReduce 模型迭代計算的效率來提高其實時性。HaLoop通過在各個task tracker 對數(shù)據(jù)進行緩存(cache)和創(chuàng)建索引(index)的方式來減少磁盤IO,并提供了一套新的編程接口。但是HaLoop的動靜態(tài)數(shù)據(jù)無法分離,且沒有一個客觀的停止迭代的標準。Twister系統(tǒng)將Hadoop 的全部數(shù)據(jù)存放在內存中,采用獨立模塊傳遞所有的消息和數(shù)據(jù)。但是數(shù)據(jù)駐留內存的限制使其難以實用,且其計算模型的抽象度不高,支持的應用也很有限。Twister 仍處于初步的研究階段。
iMapReduce介紹了一種基于MapReduce 的迭代模型,但是它的靜態(tài)調度策略和粗粒度的task 可能會導致資源利用不佳和負載不均。iHadoop實現(xiàn)了MapReduce 的異步迭代,但是在task 之間的復用上并無太大改進。PrIter是在Hadoop 的基礎上開發(fā)的,支持帶優(yōu)先級的迭代計算,能夠保證迭代過程的快速收斂,適合top-k 之類的在線查詢。最新版本的PrIter 已經(jīng)支持基于內存和基于文件的數(shù)據(jù)存儲方式。Spark將中間結果存放在內存中,支持除Map 和Reduce 之外的多種操作類型。但是Spark 不適用異步細粒度更新狀態(tài)的應用,同時在容錯性方面有待提升。Facebook 結合自己的應用場景構建了實時的Hadoop 系統(tǒng),主要是實現(xiàn)了高可用的NameNode,對并發(fā)讀和實時負載性能進行了優(yōu)化,改造HBase 使其適合真實的實時生產(chǎn)環(huán)境。
3) 二者的融合。有不少研究人員嘗試將流處理和批處理模式進行融合,主要思路是利用MapReduce 模型實現(xiàn)流處理。DEDUCE 系統(tǒng)擴展了IBM 的流處理軟件System S,使其支持MapReduce。C-MR 系統(tǒng) 通過3 個方面的工作實現(xiàn)了支持流處理的持續(xù)型MapReduce( Continuous-MapReduce):
a)將并行流處理中的窗口概念透明的擴展到MapReduce 模型中;
b) 有效結合了包括CPU、GPU 在內的多種異構計算能力;
在Hadoop 系統(tǒng)基礎上進行擴展,繞開HDFS 的限制,實現(xiàn)了一個全內存處理的高效流處理系統(tǒng)。StreamMapReduce結合事件流處理(Event Stream Processing)的特點,對MapReduce 中的Mapper 和Reducer 進行重新定義,增加了持續(xù)的、低延遲的數(shù)據(jù)處理能力。
在充分調研基礎上,作者認為原始的MapReduce 框架不適合處理快速數(shù)據(jù)。結合快速數(shù)據(jù)的特點,文中設計了一個類似MapReduce 的框架——MapUpdate,并在該框架基礎上實現(xiàn)了一個原型系統(tǒng)Muppet。和上述這些系統(tǒng)相比,SSS最大的特點就是在支持快速流處理的同時也能夠支持大規(guī)模靜態(tài)數(shù)據(jù)的處理,也就是說兼具流處理和批處理。中提出名為離散流(Discretized Streams)的編程模型,并在Spark基礎上實現(xiàn)了一個原型系統(tǒng)Spark Streaming。
4.2 大數(shù)據(jù)處理工具
關系數(shù)據(jù)庫在很長的時間里成為數(shù)據(jù)管理的最佳選擇,但是在大數(shù)據(jù)時代,數(shù)據(jù)管理、分析等的需求多樣化使得關系數(shù)據(jù)庫在很多場景不再適用。本節(jié)將對現(xiàn)今主流的大數(shù)據(jù)處理工具進行一個簡單的歸納和總結。
Hadoop 是目前最為流行的大數(shù)據(jù)處理平臺。Hadoop 最先是Doug Cutting 模仿GFS、MapReduce 實現(xiàn)的一個云計算開源平臺,后貢獻給Apache。Hadoop 已經(jīng)發(fā)展成為包括文件系統(tǒng)(HDFS)、數(shù)據(jù)庫(HBase、Cassandra)、數(shù)據(jù)處理(MapReduce)等功能模塊在內的完整生態(tài)系統(tǒng)(Ecosystem)。某種程度上可以說Hadoop 已經(jīng)成為了大數(shù)據(jù)處理工具事實上的標準。對Hadoop 改進并將其應用于各種場景的大數(shù)據(jù)處理已經(jīng)成為新的研究熱點。主要的研究成果集中在對Hadoop 平臺性能的改進、高效的查詢處理、索引構建和使用、在Hadoop 之上構建數(shù)據(jù)倉庫、Hadoop 和數(shù)據(jù)庫系統(tǒng)的連接、數(shù)據(jù)挖掘、推薦系統(tǒng)等。
除了Hadoop,還有很多針對大數(shù)據(jù)的處理工具。這些工具有些是完整的處理平臺,有些則是專門針對特定的大數(shù)據(jù)處理應用。表7 歸納總結了現(xiàn)今一些主流的處理平臺和工具,這些平臺和工具或是已經(jīng)投入商業(yè)使用,或是開源軟件。在已經(jīng)投入商業(yè)使用的產(chǎn)品中,絕大部分也是在Hadoop 基礎上進行功能擴展,或者提供與Hadoop 的數(shù)據(jù)接口。
表7 大數(shù)據(jù)工具列表
5、大數(shù)據(jù)時代面臨的新挑戰(zhàn)
綜上所述,大數(shù)據(jù)時代的數(shù)據(jù)存在著如下幾個特點:多源異構;分布廣泛;動態(tài)增長;先有數(shù)據(jù)后有模式。
正是這些與傳統(tǒng)數(shù)據(jù)管理迥然不同的特點,使得大數(shù)據(jù)時代的數(shù)據(jù)管理面臨著新的挑戰(zhàn),下面會對其中的主要挑戰(zhàn)進行詳細分析。
5.1 大數(shù)據(jù)集成
數(shù)據(jù)的廣泛存在性使得數(shù)據(jù)越來越多的散布于不同的數(shù)據(jù)管理系統(tǒng)中,為了便于進行數(shù)據(jù)分析需要進行數(shù)據(jù)的集成。數(shù)據(jù)集成看起來并不是一個新的問題,但是大數(shù)據(jù)時代的數(shù)據(jù)集成卻有了新的需求,因此也面臨著新的挑戰(zhàn)。
1、廣泛的異構性。傳統(tǒng)的數(shù)據(jù)集成中也會面對數(shù)據(jù)異構的問題,但是在大數(shù)據(jù)時代這種異構性出現(xiàn)了新的變化。主要體現(xiàn)在:
1)數(shù)據(jù)類型從以結構化數(shù)據(jù)為主轉向結構化、半結構化、非結構化三者的融合。
2)數(shù)據(jù)產(chǎn)生方式的多樣性帶來的數(shù)據(jù)源變化。傳統(tǒng)的電子數(shù)據(jù)主要產(chǎn)生于服務器或者是個人電腦,這些設備位置相對固定。隨著移動終端的快速發(fā)展,手機、平板電腦、GPS 等產(chǎn)生的數(shù)據(jù)量呈現(xiàn)爆炸式增長,且產(chǎn)生的數(shù)據(jù)帶有很明顯的時空特性。
3)數(shù)據(jù)存儲方式的變化。傳統(tǒng)數(shù)據(jù)主要存儲在關系數(shù)據(jù)庫中,但越來越多的數(shù)據(jù)開始采用新的數(shù)據(jù)存儲方式來應對數(shù)據(jù)爆炸,比如存儲在Hadoop 的HDFS 中。這就必然要求在集成的過程中進行數(shù)據(jù)轉換,而這種轉換的過程是非常復雜和難以管理的。
2、數(shù)據(jù)質量。數(shù)據(jù)量大不一定就代表信息量或者數(shù)據(jù)價值的增大,相反很多時候意味著信息垃圾的泛濫。一方面很難有單個系統(tǒng)能夠容納下從不同數(shù)據(jù)源集成的海量數(shù)據(jù);另一方面如果在集成的過程中僅僅簡單的將所有數(shù)據(jù)聚集在一起而不做任何數(shù)據(jù)清洗,會使得過多的無用數(shù)據(jù)干擾后續(xù)的數(shù)據(jù)分析過程。大數(shù)據(jù)時代的數(shù)據(jù)清洗過程必須更加謹慎,因為相對細微的有用信息混雜在龐大的數(shù)據(jù)量中。如果信息清洗的粒度過細,很容易將有用的信息過濾掉。清洗粒度過粗,又無法達到真正的清洗效果,因此在質與量之間需要進行仔細的考量和權衡。
5.2 大數(shù)據(jù)分析(Analytics)
傳統(tǒng)意義上的數(shù)據(jù)分析(analysis)主要針對結構化數(shù)據(jù)展開,且已經(jīng)形成了一整套行之有效的分析體系。首先利用數(shù)據(jù)庫來存儲結構化數(shù)據(jù),在此基礎上構建數(shù)據(jù)倉庫,根據(jù)需要構建數(shù)據(jù)立方體進行聯(lián)機分析處理 (OLAP, Online Analytical Processing),可以進行多個維度的下鉆(Drill-down)或上卷(Roll-up)操作。對于從數(shù)據(jù)中提煉更深層次的知識的需求促使數(shù)據(jù)挖掘技術的產(chǎn)生,并發(fā)明了聚類、關聯(lián)分析等一系列在實踐中行之有效的方法。這一整套處理流程在處理相對較少的結構化數(shù)據(jù)時極為高效。但是隨著大數(shù)據(jù)時代的到來,半結構化和非結構化數(shù)據(jù)量的迅猛增長,給傳統(tǒng)的分析技術帶來了巨大的沖擊和挑戰(zhàn),主要體現(xiàn)在:
1、數(shù)據(jù)處理的實時性(Timeliness)。隨著時間的流逝數(shù)據(jù)中所蘊含的知識價值往往也在衰減,因此很多領域對于數(shù)據(jù)的實時處理有需求。隨著大數(shù)據(jù)時代的到來,更多應用場景的數(shù)據(jù)分析從離線(offline)轉向了在線(online),開始出現(xiàn)實時處理的需求,比如KDD 2012最佳論文所探討的實時廣告競價問題。大數(shù)據(jù)時代的數(shù)據(jù)實時處理面臨著一些新的挑戰(zhàn),主要體現(xiàn)在數(shù)據(jù)處理模式的選擇及改進。在實時處理的模式選擇中,主要有三種思路:即流處理模式、批處理模式以及二者的融合。相關研究成果在上一節(jié)已經(jīng)有詳細介紹。雖然已有的研究成果很多,但是仍未有一個通用的大數(shù)據(jù)實時處理框架。各種工具實現(xiàn)實時處理的方法不一,支持的應用類型都相對有限,這導致實際應用中往往需要根據(jù)自己的業(yè)務需求和應用場景對現(xiàn)有的這些技術和工具進行改造才能滿足要求。
2、動態(tài)變化環(huán)境中索引的設計。關系數(shù)據(jù)庫中的索引能夠加速查詢速率,但是傳統(tǒng)的數(shù)據(jù)管理中模式基本不會發(fā)生變化,因此在其上構建索引主要考慮的是索引創(chuàng)建、更新等的效率。大數(shù)據(jù)時代的數(shù)據(jù)模式隨著數(shù)據(jù)量的不斷變化可能會處于不斷的變化之中,這就要求索引結構的設計簡單、高效,能夠在數(shù)據(jù)模式發(fā)生變化時很快的進行調整來適應。前面也介紹了通過在NoSQL 數(shù)據(jù)庫上構建索引來應對大數(shù)據(jù)挑戰(zhàn)的一些方案,但總的來說,這些方案基本都有特定的應用場景,且這些場景的數(shù)據(jù)模式不太會發(fā)生變化。在數(shù)據(jù)模式變更的假設前提下設計新的索引方案將是大數(shù)據(jù)時代的主要挑戰(zhàn)之一。
3、先驗知識的缺乏。傳統(tǒng)分析主要針對結構化數(shù)據(jù)展開,這些數(shù)據(jù)在以關系模型進行存儲的同時就隱含了這些數(shù)據(jù)內部關系等先驗知識。比如我們知道所要分析的對象會有哪些屬性,通過屬性我們又能大致了解其可能的取值范圍等。這些知識使得我們在數(shù)據(jù)分析之前就已經(jīng)對數(shù)據(jù)有了一定的理解。而在面對大數(shù)據(jù)分析時,一方面是半結構化和非結構化數(shù)據(jù)的存在,這些數(shù)據(jù)很難以類似結構化數(shù)據(jù)的方式構建出其內部的正式關系;另一方面很多數(shù)據(jù)以流的形式源源不斷的到來,這些需要實時處理的數(shù)據(jù)很難有足夠的時間去建立先驗知識。
5.3 大數(shù)據(jù)隱私問題
隱私問題由來已久,計算機的出現(xiàn)使得越來越多的數(shù)據(jù)以數(shù)字化的形式存儲在電腦中,互聯(lián)網(wǎng)的發(fā)展則使數(shù)據(jù)更加容易產(chǎn)生和傳播,數(shù)據(jù)隱私問題越來越嚴重。
1、隱性的數(shù)據(jù)暴露。很多時候人們有意識的將自己的行為隱藏起來,試圖達到隱私保護的目的。但是互聯(lián)網(wǎng),尤其是社交網(wǎng)絡的出現(xiàn),使得人們在不同的地點產(chǎn)生越來越多的數(shù)據(jù)足跡。這種數(shù)據(jù)具有累積性和關聯(lián)性,單個地點的信息可能不會暴露用戶的隱私,但是如果有辦法將某個人的很多行為從不同的獨立地點聚集在一起時,他的隱私就很可能會暴露,因為有關他的信息已經(jīng)足夠多了,這種隱性的數(shù)據(jù)暴露往往是個人無法預知和控制的。從技術層面來說,可以通過數(shù)據(jù)抽取和集成來實現(xiàn)用戶隱私的獲取。而在現(xiàn)實中通過所謂的“人肉搜索”的方式往往能更快速、準確的得到結果,這種人肉搜索的方式實質就是眾包(Crowdsourcing)。大數(shù)據(jù)時代的隱私保護面臨著技術和人力層面的雙重考驗。
2、數(shù)據(jù)公開與隱私保護的矛盾。如果僅僅為了保護隱私就將所有的數(shù)據(jù)都加以隱藏,那么數(shù)據(jù)的價值根本無法體現(xiàn)。數(shù)據(jù)公開是非常有必要的,政府可以從公開的數(shù)據(jù)中來了解整個國民經(jīng)濟社會的運行,以便更好的指導社會的運轉。企業(yè)則可以從公開的數(shù)據(jù)中了解客戶的行為,從而推出針對性的產(chǎn)品和服務,最大化其利益。研究者則可以利用公開的數(shù)據(jù),從社會、經(jīng)濟、技術等不同的角度來進行研究。因此大數(shù)據(jù)時代的隱私性主要體現(xiàn)在不暴露用戶敏感信息的前提下進行有效的數(shù)據(jù)挖掘,這有別于傳統(tǒng)的信息安全領域更加關注文件的私密性等安全屬性。統(tǒng)計數(shù)據(jù)庫數(shù)據(jù)研究中最早開展數(shù)據(jù)隱私性技術方面的研究,近年來逐漸成為相關領域的研究熱點。Dwork 在2006 年提出了新的差分隱私(Differential Privacy)方法。差分隱私保護技術可能是解決大數(shù)據(jù)中隱私保護問題的一個方向,但是這項技術離實際應用還很遠。
3、數(shù)據(jù)動態(tài)性。大數(shù)據(jù)時代數(shù)據(jù)的快速變化除了要求有新的數(shù)據(jù)處理技術應對之外,也給隱私保護帶來了新的挑戰(zhàn),F(xiàn)有隱私保護技術主要基于靜態(tài)數(shù)據(jù)集,而在現(xiàn)實中數(shù)據(jù)模式和數(shù)據(jù)內容時刻都在發(fā)生著變化。因此在這種更加復雜的環(huán)境下實現(xiàn)對動態(tài)數(shù)據(jù)的利用和隱私保護將更具挑戰(zhàn)。
5.4 大數(shù)據(jù)能耗問題
在能源價格上漲、數(shù)據(jù)中心存儲規(guī)模不斷擴大的今天,高能耗已逐漸成為制約大數(shù)據(jù)快速發(fā)展的一個主要瓶頸。從小型集群到大規(guī)模數(shù)據(jù)中心都面臨著降低能耗的問題,但是尚未引起足夠多的重視,相關的研究成果也較少。在大數(shù)據(jù)管理系統(tǒng)中,能耗主要由兩大部分組成:硬件能耗和軟件能耗,二者之中又以硬件能耗為主。理想狀態(tài)下,整個大數(shù)據(jù)管理系統(tǒng)的能耗應該和系統(tǒng)利用率成正比。但是實際情況并不像預期情況,系統(tǒng)利用率為0的時候仍然有能量消耗。針對這個問題,《紐約時報》和麥肯錫經(jīng)過一年的聯(lián)合調查,最終在《紐約時報》上發(fā)表文章《Power, Pollution and the Internet》。調查顯示Google數(shù)據(jù)中心年耗電量約為300萬瓦,而Facebook則在60萬瓦左右。最令人驚訝的是在這些巨大的能耗中,只有6%-12%的能量被用來響應用戶的查詢并進行計算。絕大部分的電能用以確保服務器處于閑置狀態(tài),以應對突如其來的網(wǎng)絡流量高峰,這種類型的功耗最高可以占到數(shù)據(jù)中心所有能耗的80%。從已有的一些研究成果來看,可以考慮以下兩個方面來改善大數(shù)據(jù)能耗問題:
1、采用新型低功耗硬件。從紐約時報的調查中可以知道絕大部分的能量都耗費在磁盤上。在空閑的狀態(tài)下,傳統(tǒng)的磁盤仍然具有很高的能耗,并且隨著系統(tǒng)利用率的提高,能耗也在逐漸升高。新型非易失存儲器件的出現(xiàn),給大數(shù)據(jù)管理系統(tǒng)帶來的新的希望。閃存、PCM等新型存儲硬件具有低能耗的特性。雖然隨著系統(tǒng)利用率的提高,閃存、PCM等的能耗也有所升高,但是其總體能耗仍遠遠低于傳統(tǒng)磁盤。
2、引入可再生的新能源。數(shù)據(jù)中心所使用的電能絕大部分都是從不可再生的能源中產(chǎn)生的。如果能夠在大數(shù)據(jù)存儲和處理中引入諸如太陽能、風能之類的可再生能源,將在很大程度上緩解能耗問題。
5.5 大數(shù)據(jù)處理與硬件的協(xié)同
硬件的快速升級換代有力的促進了大數(shù)據(jù)的發(fā)展,但是這也在一定程度上造成了大量不同架構硬件共存的局面。日益復雜的硬件環(huán)境給大數(shù)據(jù)管理帶來的主要挑戰(zhàn)有:
1、硬件異構性帶來的大數(shù)據(jù)處理難題。整個數(shù)據(jù)中心(集群)內部不同機器之間的性能會存在著明顯的差別,因為不同時期購入的不同廠商的服務器在IOPS、CPU處理速度等性能方面會有很大的差異。這就導致了硬件環(huán)境的異構性(Heterogeneous),而這種異構性會給大數(shù)據(jù)的處理帶來諸多問題。一個典型的例子就是MapReduce任務過程中,其總的處理時間很大程度上取決于Map過程中處理時間最長的節(jié)點。如果集群中硬件的性能差異過大,則會導致大量的計算時間浪費在性能較好的服務器等待性能較差的服務器上。這種情況下服務器的線性增長并不一定會帶來計算能力的線性增長,因為“木桶效應”制約了整個集群的性能。一般的解決方案是考慮硬件異構的環(huán)境下將不同計算強度的任務智能的分配給計算能力不同的服務器,但是當這種異構環(huán)境的規(guī)模擴展到數(shù)以萬計的集群時問題將變得極為復雜。
2、新硬件給大數(shù)據(jù)處理帶來的變革。所有的軟件系統(tǒng)都是構建在傳統(tǒng)的計算機體系結構之上,即CPU-內存-硬盤三級結構。CPU的發(fā)展一直遵循著摩爾定律,且其架構已經(jīng)從單核轉入多核。因此需要深入研究如何讓軟件更好的利用CPU多核心之間的并發(fā)機制。由于機械特性的限制,基于磁性介質的硬盤(Hard Disk Drive, HDD)的讀寫速率在過去幾十年中提升不大,而且未來也不太可能出現(xiàn)革命性的提升;陂W存的固態(tài)硬盤(Solid State Disk,SSD)的出現(xiàn)從硬件層為存儲系統(tǒng)結構的革新提供了支持,為計算機存儲技術的發(fā)展和存儲能效的提高帶來了新的契機。SSD具有很多優(yōu)良特性,主要包括極高的讀寫性能、抗震性、低功耗、體積小等,因此正得到越來越廣泛的應用。但是直接將SSD應用到現(xiàn)有的軟件上并不一定會帶來軟件性能的大幅提升。Sang-Won Lee等人的研究表明雖然SSD的讀寫速率是HDD的60~150倍,基于SSD的數(shù)據(jù)庫系統(tǒng)的查詢時間卻僅僅提升了不到10倍。二者之間的巨大差距主要是由SSD的一些特性造成的,這些特性包括:SSD寫前擦除特性導致的讀寫操作代價不對稱、SSD存儲芯片的擦除次數(shù)有限等。軟件設計之時必須仔細考慮這些特性才能夠充分利用SSD的優(yōu)良特性。與大容量磁盤和磁盤陣列相比,固態(tài)硬盤的存儲容量相對較低,單位容量的價格遠高于磁盤。且不同類型的固態(tài)硬盤產(chǎn)品性能差異較大,將固態(tài)硬盤直接替換磁盤應用到現(xiàn)有的存儲體系中難以充分發(fā)揮其性能。因此現(xiàn)階段可以考慮通過構建HDD和SSD的混合存儲系統(tǒng)來解決大數(shù)據(jù)處理問題。當前混合存儲系統(tǒng)的實現(xiàn)主要有三種思路:
HDD作為內存的擴展充當SSD寫緩沖;HDD和SSD同做二級存儲;SSD用作內存的擴展充當HDD讀寫緩沖。國外的Google、Facebook,國內的百度、淘寶等公司已經(jīng)開始在實際運營環(huán)境中大規(guī)模的使用混合存儲系統(tǒng)來提升整體性能。在這三級結構之中,內存的發(fā)展處于一個相對緩慢的階段,一直沒有出現(xiàn)革命性的變化。構建任何一個軟件系統(tǒng)都會假設內存是一個容量有限的易失結構體。隨著以PCM為代表的SCM的出現(xiàn),未來的內存極有可能會兼具現(xiàn)在內存和磁盤的雙重特性,即處理速度極快且非易失。雖然PCM尚未有可以大規(guī)模量產(chǎn)的產(chǎn)品推出,但是各大主流廠商都對其非常重視,三星電子在2012年國際固態(tài)電路會議(ISSCC 2012)上發(fā)表了采用20nm工藝制程的容量為8G的PCM元件。一旦PCM能夠大規(guī)模的投入使用,必將給現(xiàn)有的大數(shù)據(jù)處理帶來一場根本性的變革。譬如前面提到的流處理模式就可以不再將內存的大小限制作為算法設計過程中的一個主要考慮因素。
5.6 大數(shù)據(jù)管理易用性(Usability)問題
從數(shù)據(jù)集成到數(shù)據(jù)分析,直到最后的數(shù)據(jù)解釋,易用性應當貫穿整個大數(shù)據(jù)的流程。易用性的挑戰(zhàn)突出體現(xiàn)在兩個方面:首先大數(shù)據(jù)時代的數(shù)據(jù)量大,分析更復雜,得到的結果形式更加的多樣化。其復雜程度已經(jīng)遠遠超出傳統(tǒng)的關系數(shù)據(jù)庫。其次大數(shù)據(jù)已經(jīng)廣泛滲透到人們生活的各個方面,很多行業(yè)都開始有了大數(shù)據(jù)分析的需求。但是這些行業(yè)的絕大部分從業(yè)者都不是數(shù)據(jù)分析的專家,在復雜的大數(shù)據(jù)工具面前,他們只是初級的使用者(NaïveUsers)。復雜的分析過程和難以理解的分析結果限制了他們從大數(shù)據(jù)中獲取知識的能力。這兩個原因導致易用性成為大數(shù)據(jù)時代軟件工具設計的一個巨大挑戰(zhàn)。關于大數(shù)據(jù)易用性的研究仍處于一個起步階段。從設計學的角度來看易用性表現(xiàn)為易見(Easy to discover)、易學(Easyto learn)和易用 (Easy to use)。要想達到易用性,需要關注以下三個基本原則[138]:
1、可視化原則(Visibility)。可視性要求用戶在見到產(chǎn)品時就能夠大致了解其初步的使用方法,最終的結果也要能夠清晰的展現(xiàn)出來。針對MapReduce 使用復雜的情況,未來如何實現(xiàn)更多大數(shù)據(jù)處理方法和工具的簡易化和自動化將是一個很大的挑戰(zhàn)。除了功能設計之外,最終結果的展示也要充分體現(xiàn)可視化的原則?梢暬夹g是最佳的結果展示方式之一,通過清晰的圖形圖像展示直觀的反映出最終結果。但是超大規(guī)模的可視化卻面臨著諸多挑戰(zhàn),主要有:原位分析;用戶界面與交互設計;大數(shù)據(jù)可視化;數(shù)據(jù)庫與存儲;算法;數(shù)據(jù)移動、傳輸和網(wǎng)絡架構;不確定性的量化;并行化;面向領域與開發(fā)的庫、框架以及工具;社會、社區(qū)以及政府參與。
2、匹配原則(Mapping)。人的認知中會利用現(xiàn)有的經(jīng)驗來考慮新的工具的使用。譬如一提到數(shù)據(jù)庫,了解的人都會想到使用SQL 語言來執(zhí)行數(shù)據(jù)查詢。在新工具的設計過程中盡可能將人們已有的經(jīng)驗知識考慮進去,會使得新工具非常便于使用,這就是所謂的匹配原則。MapReduce 模型雖然將復雜的大數(shù)據(jù)處理過程簡化為Map 和Reduce 的過程,但是具體的Map 和Reduce 函數(shù)仍需要用戶自己編寫,這對于絕大部分沒有編程經(jīng)驗的用戶而言仍過于復雜。如何將新的大數(shù)據(jù)處理技術和人們已經(jīng)習慣的處理技術和方法進行匹配將是未來大數(shù)據(jù)易用性的一個巨大挑戰(zhàn)。這方面現(xiàn)在已經(jīng)有了些初步的研究工作。針對 MapReduce 技術缺乏類似SQL 標準語言的弱點,研究人員開發(fā)出更高層的語言和系統(tǒng)。典型代表有Hadoop的HiveQL和Pig Latin、Google 的 Sawzall、微軟的SCOPE和DryadLINQ以及MRQL等。SQL 查詢有自動優(yōu)化的過程,而MapReduce 并沒有。針對這點,和實現(xiàn)了MapReduce 的查詢優(yōu)化器。通過調研發(fā)現(xiàn)系統(tǒng)I/O 冗余是由于查詢之間的關聯(lián)(correlations),為了解決這個問題,作者引入了BSP(Batched Stream Processing)模型,并在DryadLINQ 中實現(xiàn)了查詢優(yōu)化系統(tǒng)Comet。還有部分學者的工作集中在將SQL 語言自動轉化成MapReduce 任務。比較代表性的系統(tǒng)有YSmart、Tenzing等。還有一些其他的工作,比如S4Latin在S4 的基礎上實現(xiàn)了一個新的數(shù)據(jù)處理框架,使得用戶可以直接用類似查詢的方式而不是編程的方式創(chuàng)建新的流應用。這在很大程度上改善了大數(shù)據(jù)流處理平臺S4 的易用性。
3、反饋原則(Feedback)。帶有反饋的設計使得人們能夠隨時掌握自己的操作進程。進度條就是一個體現(xiàn)反饋原則的經(jīng)典例子。大數(shù)據(jù)領域關于這方面的工作較少,有部分學者開始關注MapReduce 程序執(zhí)行進程的估計。傳統(tǒng)的軟件工程領域,程序出現(xiàn)問題之后有比較成熟的調試工具可以對錯誤的程序進行交互式的調試,相對容易找到錯誤的根源。但是大數(shù)據(jù)時代很多工具其內部結構復雜,對于普通用戶而言這些工具近似于黑盒(black box),調試過程復雜,缺少反饋性。PerfXplain設計并實現(xiàn)了MapReduce 的簡便化調試系統(tǒng)。為了解決大數(shù)據(jù)云(Big Data Cloud)中程序部署和調試的問題,實現(xiàn)了一個可擴展的輕量級Hadoop 性能分析器HiTune。如果未來能夠在大數(shù)據(jù)的處理中大范圍的引入人機交互技術,使得人們能夠較完整的參與整個分析過程,會有效的提高用戶的反饋感,在很大程度上提高易用性。
滿足三個基本原則的設計就能夠達到良好的易用性。從技術層面來看,可視化、人機交互以及數(shù)據(jù)起源技術都可以有效的提升易用性。而在這些技術的背后,海量元數(shù)據(jù)管理的問題是需要我們特別關注的一個問題。元數(shù)據(jù)是關于數(shù)據(jù)的數(shù)據(jù),數(shù)據(jù)之間的關聯(lián)關系以及數(shù)據(jù)本身的一些屬性大都是靠元數(shù)據(jù)來表示的?梢暬夹g離不開元數(shù)據(jù)的支持,因為如果無法準確的表征出數(shù)據(jù)之間的關系,就無法對數(shù)據(jù)進行可視化的展示。數(shù)據(jù)起源技術更是離不開元數(shù)據(jù)管理技術。因為數(shù)據(jù)起源需要利用元數(shù)據(jù)來記錄數(shù)據(jù)之間包括因果關系在內的各種復雜關系,并通過這些信息來進行相關的推斷。如何在大規(guī)模存儲系統(tǒng)中實現(xiàn)海量元數(shù)據(jù)的高效管理將會對大數(shù)據(jù)的易用性產(chǎn)生重要影響。
5.7 性能的測試基準(Benchmark)
關系數(shù)據(jù)庫產(chǎn)品的成功離不開以TPC 系列為代表的測試基準的產(chǎn)生。正是有了這些測試基準,才能夠準確的衡量不同數(shù)據(jù)庫產(chǎn)品的性能,并對其存在的問題進行改進。目前尚未有針對大數(shù)據(jù)管理的測試基準,構建大數(shù)據(jù)測試基準面臨的主要挑戰(zhàn)有:
1、系統(tǒng)復雜度高。大數(shù)據(jù)管理系統(tǒng)的類型非常多,很多公司針對自己的應用場景設計了相應的數(shù)據(jù)庫產(chǎn)品。這些產(chǎn)品的功能模塊各異,很難用一個統(tǒng)一的模型來對所有的大數(shù)據(jù)產(chǎn)品進行建模。
2、用戶案例的多樣性。測試基準需要定義一系列具有代表性的用戶行為,但是大數(shù)據(jù)的數(shù)據(jù)類型廣泛,應用場景也不盡相同,很難從中提取出具有代表性的用戶行為。
3、數(shù)據(jù)規(guī)模龐大。這會帶來了兩方面的挑戰(zhàn)。首先數(shù)據(jù)規(guī)模過大使得數(shù)據(jù)重現(xiàn)非常困難,代價很大。其次在傳統(tǒng)的 TPC 系列測試中,測試系統(tǒng)的規(guī)模往往大于實際客戶使用的數(shù)據(jù)集,因此測試的結果可以準確的代表系統(tǒng)的實際性能。但是在大數(shù)據(jù)時代,用戶實際使用系統(tǒng)的數(shù)據(jù)規(guī)模往往大于測試系統(tǒng)的數(shù)據(jù)規(guī)模,因此能否用小規(guī)模數(shù)據(jù)的測試基準來代表實際產(chǎn)品的性能是目前面臨的一個挑戰(zhàn)。數(shù)據(jù)重現(xiàn)的問題可以嘗試利用一定的方法來去產(chǎn)生測試樣例,而不是選擇下載某個實際的測試數(shù)據(jù)集。但是這又涉及到如何使產(chǎn)生的數(shù)據(jù)集能真實反映原始數(shù)據(jù)集的問題。
4、系統(tǒng)的快速演變。傳統(tǒng)的關系數(shù)據(jù)庫其系統(tǒng)架構一般比較穩(wěn)定,但是大數(shù)據(jù)時代的系統(tǒng)為了適應數(shù)據(jù)規(guī)模的不斷增長和性能要求的不斷提升,必須不斷的進行升級,這使得測試基準得到的測試結果很快就不能反映系統(tǒng)當前的實際性能。
5、重新構建還是復用現(xiàn)有的測試基準。如果能夠在現(xiàn)有的測試基準中選擇合適的進行擴展的話,那么將極大減少構建新的大數(shù)據(jù)測試基準的工作量?赡艿暮蜻x測試標準有SWIM(Statistical Workload Injector for MapReduce)、MRBS、Hadoop 自帶的GridMix、TPC-DS、YCSB++等。
現(xiàn)在已經(jīng)開始有工作嘗試構建大數(shù)據(jù)的測試基準,比如一些針對大數(shù)據(jù)測試基準的會議WBDB 2012、TPCTC 2012 等。但是也有觀點認為當前討論大數(shù)據(jù)測試基準的構建為時尚早。Yanpei Chen 等通過對7 個應用MapReduce 技術的實際產(chǎn)品的負載進行了跟蹤和分析,認為現(xiàn)在根本無法確定大數(shù)據(jù)時代的典型用戶案例。因此從這個角度來看并不適合構建大數(shù)據(jù)的測試基準,還有很多基礎性的問題亟待解決。
總的來說,構建大數(shù)據(jù)的測試基準是有必要的。但是面臨的挑戰(zhàn)非常多,要想構建一個類似TPC 的公認的測試標準難度很大。
6、結論
隨著云計算、物聯(lián)網(wǎng)等的發(fā)展,數(shù)據(jù)呈現(xiàn)爆炸式的增長,人們正被數(shù)據(jù)洪流所包圍,大數(shù)據(jù)的時代已經(jīng)到來。正確利用大數(shù)據(jù)給人們的生活帶來了極大的便利,但于此同時也給傳統(tǒng)的數(shù)據(jù)管理方式帶來了極大的挑戰(zhàn)。本文對最近幾年國內外大數(shù)據(jù)相關的研究成果進行了全面的回顧和總結,介紹了大數(shù)據(jù)的基本概念,詳細分析了大數(shù)據(jù)管理的關鍵技術,主要是闡述云計算技術對于大數(shù)據(jù)管理的基礎性作用。本文還著重介紹了目前大數(shù)據(jù)研究面臨的新挑戰(zhàn)以及相應的一些研究成果?偟膩碚f,眼下對于大數(shù)據(jù)的研究仍處于一個非常初步的階段,還有很多基礎性的問題有待解決。大數(shù)據(jù)的幾個特征中究竟哪個最重要?面對大數(shù)據(jù)管理我們需要的是簡單的技術上的演變(Evolution)還是徹底的變革(Revolution)?不同學科的研究者之間怎樣協(xié)作才能更有利于大數(shù)據(jù)問題的解決?諸如此類的問題還有許多,要解決大數(shù)據(jù)問題仍有很長的路要走,期望本文的介紹能給大數(shù)據(jù)研究同行學者提供一定的參考。
核心關注:拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業(yè)務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理,全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域,是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題:大數(shù)據(jù)管理:概念、技術與挑戰(zhàn)(下)
本文網(wǎng)址:http://www.ezxoed.cn/html/support/1112189709.html