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