大數據管理系統的歷史、現狀與未來*

杜小勇,盧 衛,張 峰

1(數據工程與知識工程教育部重點實驗室(中國人民大學),北京 100872)

2(中國人民大學 信息學院,北京 100872)

近年來,大數據的重要性凸顯,世界上的許多國家都把大數據上升到國家戰略的高度.實施國家大數據戰略,離不開大數據技術的研究.回顧信息技術的發展歷史,數據管理技術是信息應用技術的基礎.與其他計算機學科相比,數據管理是整個領域為數不多的既有基礎理論研究、又有系統軟件研制、還有產業支撐的學科.專門從事數據管理系統軟件和應用軟件研制的甲骨文公司于2013年超越IBM,成為繼微軟公司之后全球第二大軟件公司.如今,歷史似乎又正在重演,大數據管理在大數據技術中表現得越來越重要.

大數據管理系統正在經歷以軟件為中心到以數據為中心的計算平臺的變遷.計算機的研制最初是為了滿足軍事和科學計算的需要,應用軟件的開發和系統軟件的研制均以硬件為中心開展,且依賴于特定的計算機硬件環境.自微軟公司1980年推出MS DOS(MicroSoft Disk Operating System)磁盤操作系統以來,MSDOS作為當時IBM的PC和兼容機的基本軟件,成為了個人計算機中最普遍的操作系統.隨后,微軟推出的首個帶有圖形界面的個人電腦操作系統Windows 1.0,逐漸成為PC機的預裝軟件.微軟操作系統成功推動了底層要素的標準化,即底層硬件的可替代性.具體來說,操作系統統一將硬件標準化為設備,使用同樣的接口,這樣,操作系統就可以運行在不同的硬件平臺,使得底層硬件的可替代性得到了增強.與此同時,微軟操作系統也成為新的中心,即,應用軟件的開發和系統軟件的研制此后均以操作系統軟件為中心展開.

隨著信息技術的發展,特別是以互聯網為代表的大數據應用每天產生巨大的數據量,大數據管理系統也發生了以軟件為中心到以數據為中心的計算平臺的遷移.例如,谷歌、百度等搜索引擎公司存儲的網頁數據越來越多,逐漸成為網絡數據的集中存放倉庫,并以這些數據為中心開展各項服務.據統計,2013年,谷歌大約存儲了10EB(Exabyte,1018bytes)的磁盤數據.如何存儲和管理如此巨量的數據,是目前研究的熱點.不僅限于搜索引擎公司,其他信息技術公司也都面臨同樣的大數據管理需求.例如:阿里巴巴集團旗下的螞蟻金服存儲著巨量的交易數據,同時,以此為基礎提供征信服務[1,2];騰訊公司的社交數據中心存有大量的用戶會話、朋友圈等信息[3],并基于這些信息開發新型應用.總之,這些數據不可避免地成為了一個新平臺,大數據時代要求我們在以數據為中心的平臺上去開發新型數據管理系統和相應的應用系統.

大數據管理系統正在經歷的另一個趨勢是基礎設施化,基礎設施是指人們生活中不可或缺的設施服務,例如水電等公共服務、飛機公路等交通設施等.基礎設施必須具備3個基本特征:第一,基礎性,即社會運行不可缺少的東西;第二,規模性,只有達到了與社會經濟狀況相適應的規模才能提供有效的服務;第三,可靠性,不能經常出錯,要能提供持續穩定的服務.我們正在步入數字經濟和數字社會時代,軟件作為一種使能技術,在數字社會中具有不可替代的作用,軟件基礎設施化的趨勢也越來越明顯,并具有其獨特的表現:第一,基礎性,計算作為數字社會中最重要、最基礎的服務,需要通過軟件來提供,計算能力通過軟件的定義,可以呈現為豐富多彩的服務形態;第二,規模性,整個社會的計算能力,或通過軟件重定義的服務能力,必須互聯互通作為一個整體才能成為社會的基礎設施;第三,可靠性.基礎設施化的軟件必須能夠提供穩定的、持續的、高效的在線服務.大數據管理系統正在經歷軟件的基礎設施化進程.軟件服務的種類很多,其中最重要的服務就是數據服務.云計算不僅是計算資源的匯聚,更是數據資源的匯聚.這些數據資源之間通過數據庫軟件實現互聯、互通,并向公眾提供數據的存儲與組織以及查詢、分析、維護、安全性等管理服務.這樣的數據庫軟件我們稱其為大數據管理系統.大數據時代要求我們根據軟件的基礎設施化去開發大數據管理系統和相應的應用系統.

結合大數據時代所處的兩個趨勢特征,本文首先回顧數據管理技術的發展歷史(見第 1節).之后,從數據存儲、組織模型、計算模式和分析引擎等維度深入剖析大數據管理系統的現狀(見第2節),并指出大數據管理系統應具備的數據特征、系統特征和應用特征(見第3節).隨后,本文進一步對大數據管理系統的未來發展趨勢進行展望(見第4節).最后對全文進行總結(見第5節).

1 數據庫管理系統的發展歷史回顧

數據庫管理系統的功能是伴隨著對數據的組織和管理以及應用的需求而不斷發展起來的.第 1代系統的功能主要集中在數據的組織與存儲,數據的組織以層次和網狀模型為代表,多種鏈表結構作為存儲方式.這個時期的數據庫系統可以看作是一種數據組織與存取的工具.第2代系統主要圍繞OLTP應用展開,在關系模型和存儲技術的基礎上,重點發展了事務處理子系統、查詢優化子系統、數據訪問控制子系統.第 3代系統主要圍繞OLAP應用展開,重點在于提出高效支持OLAP復雜查詢的新型數據組織技術,包括CUBE和列存儲等技術以及OLAP分析前端工具.第4代系統主要圍繞大數據應用展開,重點在分布式可擴展、異地多備份高可用架構、多數據模型支持以及多應用負載類型支持等特性.

1.1 第1代:層次、網狀數據庫系統

數據庫管理系統的發展可以上溯到 20世紀 60年代出現的層次數據庫技術,當時,計算機已經開始在商業上獲得應用,文件作為數據存儲的主要設施,已經無法滿足對商業應用(如銀行業務)中數據項之間的復雜關系進行管理的需求,主要表現在以下幾個方面:第一,文件系統是面向單一應用的,也就是說,根據每一個應用的需要,有針對性地設計文件的數據結構,因此,不同的應用要使用同一個文件結構會顯得效率低下;第二,文件之間的數據是獨立的,如果兩個文件的數據存在內在的邏輯關系,要維護這種關系就非常困難甚至是不可能的;第三,文件的組織方式單一,難以滿足不同的訪問模式對數據高效率訪問的需求.

因此,這個時期的信息系統對數據管理的核心需求是提供一種面向系統整體的數據組織與訪問功能,簡單來說就是存儲和訪問這兩件事情.受制于當時的計算機技術水平,第 1代的數據庫管理系統是層次型的,之后又進一步擴展為網狀型數據庫.這里所謂的層次型或者網狀型指的是系統中的數據組織方式是按照樹或者(受限)圖來組織的.樹由于其每一個節點最多只有一個父節點,因此可以采用更加有效的手段(例如按照樹遍歷的順序)來存儲數據.網狀模型則通過引入“基本層次聯系”的概念,將圖分解為一組基本層次聯系的集合.而基本層次聯系實際上就是一個命名的層次聯系.因此,這兩類數據庫本質上還是一樣的,都可以用“樹”結構來表達和存儲數據.盡管這個時期數據管理的功能集中在數據存儲組織和數據訪問等,但這是第 1次將數據管理的功能從具體的應用邏輯中分離并獨立出來,在數據管理系統的發展歷史上是一件里程碑的事情.

對于層次/網狀數據庫,數據訪問的最常見的模式就是根據某一個父節點的值檢索子節點的全部或者部分值.例如,查詢信息學院計算機系教師張麗的情況,數據的訪問就需要從學院到系再到教師這樣的路徑進行.為了數據訪問的高效率,最有效的數據存儲方式就是按照樹遍歷(例如中序遍歷)方式訪問樹節點,并將這些節點的數據鄰近存儲,兄弟節點之間則用指針進行鏈接.因此,這個時期的數據庫看起來就是“玩”各種數據結構,指針、鏈表被大量使用.

分層結構最大的好處就是底層系統的穩定性,即,將變化盡可能地限制在單層內部,這會使得系統的穩定性大大增加,減少了系統的維護代價.這是非常重要的一個特征.舉例來說,數據庫應用由于有了三級模式結構,當外模式結構發生了變化,例如數據項的增減,可以通過重新定義外模式和模式之間的對應關系,而保持下層模式以及內模式不變,從而使數據庫的數據存儲組織也不需要變化.反過來,當管理員想重新調整數據的存儲組織方式時(提高效率),可以通過重新定義模式到內模式的映射,而保持模式不變,從而外模式也無需變化.自然,基于外模式寫的應用程序也無需改變.這就是所謂的程序對于數據的透明性,或者說數據對于程序的獨立性.

總的來說,第1代系統的主要貢獻就是首次將數據的存儲與訪問功能從應用程序中分離出來.

1.2 第2代:關系數據庫系統

20世紀70年代是關系數據庫形成并實現產品化的年代,主要的代表人物就是IBM的埃德加·科德(Edgar F.Codd).1970年,科德發表題為“大型共享數據庫的關系模型”的論文,文中首次提出了數據庫的關系模型[4]這一概念.由于關系模型簡單明了、具有堅實的數學理論基礎,操作語言是描述性的,不用像層次網狀模型那樣需要描述存取路徑(即先訪問哪個數據再訪問哪個數據)這樣的細節,給提高信息系統開發的生產率提供了極大的空間,所以一經提出就受到了學術界和產業界的高度重視和廣泛響應.盡管一開始產業界還充斥了對關系數據庫系統性能的懷疑,但是經過科德所開發的 System R系統的驗證,證明關系數據庫系統的性能是可以有保障的.這一結論極大地推動了關系數據庫技術的發展,關系數據庫產品化的活動進入一個高潮,IBM 公司自己也在System R系統的基礎上推出了DB2產品,其他最著名的要數ORACLE公司的同名數據庫產品了.可以說,20世紀80年代以來,關系數據庫迅速取代層次和網狀數據庫而占領市場.數據庫的研究工作也是圍繞關系數據庫展開的,1975年召開了第1屆超大規模數據庫大會(very large data bases Conf.,簡稱VLDB),在會議錄的前言中就曾提到,當今產業屆已經出現了一張關系表中有100萬條記錄的“大表”,如何才能確保對這樣大表的訪問效率?由于科德杰出的貢獻,1981年的圖靈獎很自然地授予了這位“關系數據庫之父”.他的圖靈演講題目就是“關系數據庫:提高生產率的實際基礎”,說到了關系數據庫成功的關鍵,那就是這項技術提高了生產率!這正是數據庫技術成功背后的“看不見的手”.

為什么能做到這一點呢?

· 第一,描述性的關系數據語言功不可沒.SQL語言的基本結構由 3個子句構成,分別用于指定關系表、行和列.FROM 子句指定表;WHERE子句指定對行的選擇條件,也就是哪些行符合查詢要求,是對行的約束;SELECT子句指定需要呈現的列,可以看作是對列的限制.從本質上來講,一個查詢就是從一張表中選擇出需要的行和列.關系數據庫采用了SQL語言,是提高信息系統開發效率的重要因素之一;

· 第二,關系數據庫系統有完善的確保數據正確的功能,能夠避免各種錯誤可能帶來的數據庫損害.例如,為了應對各種可能的故障,從程序運行錯誤,到停電,到存儲介質損害等等,故障發生以后,如何使得數據不受到破壞,這是任何一個應用系統都需要考慮的問題,如果需要為每一個應用系統自己去完成這些代碼,可想而知,應用的開發效率不可能高.如果數據庫系統能以一定的方式確保數據庫中的數據不會被各種故障所損害,那么開發應用的時候就可以不用關心這個問題.事實上,在數據庫管理系統的代碼中,真正用于處理SQL語句的部分并不多,大部分的代碼都用于處理各種異常;

· 第三,有各種應用開發工具.一個數據庫應用從設計到實施有復雜的過程,需要了解信息需求和功能需求,需要進行數據庫模式設計,需要編寫SQL語句等等,如果有各種開發工具,甚至是數據庫模式的自動生成工具,以及SQL語句的自動生成工具,那么應用開發的效率自然就能成倍地提高.

在關系數據庫的關鍵技術中,最為核心的有查詢優化技術和事務管理兩個方面,這是關系數據庫走向實用必須首先要解決的難題.由于關系數據庫語言是基于集合的描述性語言,典型代表就是 SQL,其查詢的結果也是一個集合.如何將一個 SQL語句轉換為可以執行的程序(有點類似程序自動生成器),而且要在所有可能的執行計劃(程序)中選擇出一個效率足夠好的加以執行,這就是查詢優化器的作用.

由于關系數據庫主要用于支撐各種業務系統,因此需要管理業務狀態的變化,將這類應用稱為OLTP(online transaction processing),即聯機事務處理.“事務”又稱為交易,體現的是現實世界的業務邏輯.典型的例子就是銀行的轉賬業務,如果某客戶希望將賬號A的錢轉到賬號B上去,那么必須保證賬號A和B的存款數之和在轉賬前后是一樣的,既不能多出來也不能少掉.這是數據庫系統必須保障的,否則數據庫就無法使用.對于單機系統,這種業務邏輯的維護還比較容易,但當數據庫系統是多用戶系統時,這件事情就變得非常復雜,需要認真對待和解決.這些問題如果不能圓滿解決,無論哪個公司的數據庫產品都無法進入實用,最終不能被用戶所接受.

事務管理(TM)是數據庫的重要部件,它提供對并發事務的調度控制和故障恢復,確保數據庫系統的正確運行.詹姆斯·尼古拉·格雷(James Nicholas Gray)在解決這些重大技術問題上發揮了十分關鍵的作用,為DBMS成熟并順利進入市場做出了重要貢獻.其成就匯聚成一部厚厚的專著《Transaction Processing:Conceptsand Techniques》[5],他也眾望所歸地獲得了1998年度的圖靈獎.

在關系數據庫時代,對于數據庫系統做出重要貢獻的還有一位學者——邁克爾·斯通布雷克(Michael Stonebraker).他在加州大學伯克利分校計算機科學系任教達 29年,在此期間,領導開發了關系數據庫系統Ingres、對象-關系數據庫系統Postgres、聯邦數據庫系統Mariposa,同時還創立了多家數據庫公司,包括Ingres、Illustra、Cohera、StreamBase Systems和Vertica等,將大量研究成果和原型系統實現商業化.他在“One size does not fit all”的思想指導下,開發了一系列的“專用”關系數據庫產品,例如流數據管理系統、內存數據庫管理系統、列存儲關系數據庫系統、科學數據庫管理系統等.因“對現代數據庫系統底層的概念與實踐所做出的基礎性貢獻”,他在2015年獲得了圖靈獎.

1.3 第3代:數據倉庫系統

這個階段也可以看成是關系數據庫的一個自然延伸.隨著數據庫技術的普及應用,越來越多的數據被存儲在數據庫中,除了支持業務處理以外,如何讓這些數據發揮更大的作用,則是一個亟待解決的問題.由于對這些數據而言,主要是分析,因此這類應用也稱為OLAP(online analytical processing)應用[6],即聯機分析處理應用.例如,對于電話詳單數據,因為是通話記錄,因此一旦發生就成為歷史的記錄,很少發生事后修改的情況.但是,許多業務員會對電話詳單數據感興趣.例如,按照時間軸去分析不同時間區間通話的數量變化情況,也可以按照區域去分析通話數量的情況等等.盡管關系數據庫也能實現上述要求,但是如何讓這樣的復雜分析高效地執行?需要有特殊的數據組織模式.

星型模型是最常用的數據倉庫的數據組織模型,特別適合于聯機分析類應用,即OLAP應用.所謂星型模型也稱為多維模型,就是選定一些屬性作為分析的維度,另一些屬性作為分析的對象.維屬性通常根據值的包含關系會形成一個層次,例如,時間屬性可以根據年月周日形成一個層次,地區屬性也可以形成街道-區-市這樣的層次.為了實現快速分析,可以預先計算出不同粒度的統計結果.例如,如果預先計算了按照周和區為單位某連鎖超市的銷售額,就可以快速、方便地分析展示各區按照周的順序的銷售額的變化情況.這種采用預先計算的方法可以獲得快速聯機分析的性能.

數據倉庫可以用關系數據庫實現(relational OLAP,簡稱 ROLAP),分別用事實表和維表來存儲統計結果和維度結構.也可以用特別的數據模型(CUBE)來實現(multidimensional OLAP,簡稱 MOLAP),列存儲的技術也在這個過程中被提出和應用.同時,支持OLAP的前端分析工具也很重要,使得普通用戶可以方便地使用數據倉庫.

1.4 第4代:大數據管理系統

關系數據庫成熟并得以廣泛應用后,數據庫研究和開發一度走入一段迷茫期.數據庫界一直無法打破關系數據庫的魔咒,被關系模型和系統的“完美”所陶醉,無法自我突破.提出的一些新概念,例如面向對象數據庫系統,很快就被關系數據庫所消化,未能形成氣候.整個20世紀90年代都是在這樣的氣氛中渡過的.斯通布雷克也不能免俗,也難以逃脫關系數據庫的束縛.MapReduce[7]出現之后,他曾經激烈地批判過 MapReduce,認為是對數據庫技術的巨大倒退(從某些方面來講,也確實是這樣的).所以,大數據處理平臺 MapReduce并不是數據庫學者首先提出來的,而是做系統的人提出來的,據說最早的論文是投到數據庫頂級會議上,被無情地拒了.這也是數據庫學術界需要認真反思的地方.

由于信息技術的高度發展,信息系統所積累的數據越來越多,數據類型也越來越豐富,而且產生的速度非常快.傳統的數據庫技術“存不下”、無法建模、無法及時入庫等問題凸顯出來,難以滿足應用的需要.在這樣的背景下,Google公司發展了GFS(Google file system)[8]、MapReduce和Bigtable[9].

Google的這3件“武器”后來在Apache基金會下面有一個對應的實現,這就是Hadoop生態系統.它包括實現了一個分布式文件系統HDFS(hadoop distributed file system)[10]、一個計算框架MapReduce和一個數據庫HBase[11].HDFS有高容錯性的特點,并且可部署在低廉的服務器上,適合那些有著超大數據規模的應用.MapReduce為海量的數據提供了一個可容錯的、高可擴展的、分布式的計算框架,HBase是一個基于鍵值對組織模型(邏輯上可以看成是寬表)的分布式數據庫,數據按行列混合模式存儲在HDFS上.MapReduce可以直接訪問HDFS上的數據進行數據分析,也可以通過HBase間接訪問HDFS上的數據,以提高分析性能.

很自然地,在HDFS上如何表達和管理數據?NoSQL[12]數據庫便應運而生.一開始確實是“No SQL”的含義,因為對大容量的非結構化數據的處理需求,都不是SQL所擅長的.NoSQL的重點在于如何表達和存儲非結構化數據,先后提出了Key-Value結構,也就是有一個Key,對于一個值(可以是很復雜的非結構化數據),XML描述的文檔、圖結構等.后來人們發現:無論從應用程序的繼承角度還是提高生產率的角度,SQL都是不可或缺的工具,因此,在上層提供SQL引擎,成為大數據管理系統的共識.

1.5 小 結

從上述數據庫管理系統發展的簡史中,可以感受到以下幾點:第一,數據庫管理系統的功能是伴隨著應用的發展而不斷豐富起來的,因此任何時候,應用的需要才是技術發展的動力;第二,將數據管理的一些功能逐步從業務邏輯中分離出來,形成獨立的軟件系統,這是提高應用生產效率的有效手段和途徑;第三,系統分層是一個好主意,上層可以屏蔽下層的一些實現細節,為更上層提供更簡潔的服務;第四,語言或者說接口是定義一個系統的最有效的方法.

2 大數據管理系統的現狀

自 20世紀 70年代起,關系數據庫由于具備嚴格的關系理論輔助數據建模、數據獨立性高,查詢優化技術實現突破,逐漸成為數據管理中的主流技術.時至今日,關系數據庫仍然是數據管理,特別是涉及到人、財、物等需要精細管理應用的主流技術.關系數據庫信守的原則是one-size-fits-all,認為所有有關數據管理的任務都應該交由關系數據庫來解決.進入大數據時代,大數據的許多應用,特別是互聯網的應用,比如社交網絡、知識圖譜、搜索引擎、阿里的“雙十一”等數據管理問題,使用傳統的關系數據庫已經無法滿足應用處理的要求,人們開始嘗試研制適合自己應用場景的大數據系統.谷歌三件套,包括GFS、MapReduce計算框架以及BigTable的提出,以及以Hadoop為核心的開源生態系統的形成,人們意識到one-size-does-not-fit-all,即無法使用單一的數據管理系統來解決所有大數據應用的問題.在經歷相當長的一段時間的探索之后,人們對數據庫系統的各個模塊,包括存儲系統、數據組織模型、查詢處理引擎、查詢接口等,依托谷歌管理和分析大數據的設計思路進行了解耦,并從模型、可靠性、可伸縮性、性能等方面對各個模塊進行了重新的設計.可以發現:現階段主流的大數據管理系統具有了明顯的分層結構,自底向上分別為大數據存儲系統、NoSQL系統、大數據計算系統、大數據查詢處理引擎.各類系統獨立發展,并根據大數據應用的實際需要,通過采用松耦合的方式進行組裝,構建為完整的大數據管理系統,支撐各類大數據查詢、分析與類人智能應用.這實際上就是one-size-fits-a-bunch的設計理念.正如周傲英教授指出的:“如果說在數據庫時期,解決數據管理問題需要‘削足適履’來使用數據庫系統,那么到了大數據時代,人們開始根據每個不同的應用度身定制自己的系統,也就是‘量足制鞋’”[13].

2.1 存儲系統

在大數據存儲方面,以HDFS等為代表的開源系統目前已成為大數據存儲領域的標準之一.HDFS面向大文件(GB級別及以上)的存儲管理,因此在設計上,HDFS的存取單元數據塊(block)比一般單機文件系統的數據存取單元要大得多.較低版本的HDFS的數據塊默認為128MB,2.0版本后的數據塊默認大小為256MB.HDFS可以運行在數萬個基于普通 X86架構的商用機集群上,適合一次性寫入、多次讀取的應用場景.為了應對節點故障,HDFS引入多個數據備份和容錯機制,保證存儲系統的高可用性.一些大數據應用,例如淘寶、Facebook、微信等,需要管理海量的小文件(如圖片、用戶上傳文件等),這類應用如果使用HDFS的大數據存儲系統進行數據管理會產生大量的塊內空間浪費,同時產生大量文件到存儲節點映射等元數據,負責管理元數據的 Namenode會成為文件系統存取的性能瓶頸.淘寶的 TFS[14]就是為了管理海量小文件應運而生的分布式文件系統.其他常見的分布式文件系統還包括Ceph[15]、Amazon S3[16,17]、FastDFS[18]、GridFS[19]、MogileFS[20],這些系統可作為HDFS的重要補充.

HDFS是基于磁盤的分布式文件系統,數據的訪問需要頻繁的 I/O調用,這會對系統性能造成影響.大數據系統強調存儲和計算分離,不同的計算系統可以使用同一份存儲在底層 HDFS中的數據,同一計算系統也可使用不同的分布式文件系統.通過引入分布式緩沖區管理系統,可以屏蔽底層的分布式文件系統,將來自不同文件系統的熱點數據盡可能地維護在緩沖區中,減少上層計算訪問數據帶來的 I/O開銷.典型的分布式緩沖區管理系統包括Alluxio[21,22]、Redis[23]、Memcache[24].例如,Alluxio是開源的分布式內存文件系統,提供了與基于磁盤文件系統相同的訪問接口,并屏蔽了底層不同的文件系統.通過引入分層存儲特性,在高速內存與低速磁盤之間部署高性能SSD存儲設備,構建磁盤、SSD、內存三級數據存儲架構,并結合數據的新鮮度和訪問熱度,優化數據塊在內存、SSD、磁盤上的存儲策略,使得頻繁使用的數據優先緩存在高性能存儲介質中,從而減少磁盤訪問帶來的開銷.

2.2 面向不同數據模型的NoSQL系統

數據模型是數據管理系統的核心.大數據應用可以是結構化的關系數據、圖數據,也可以是半結構化的XML或JSON數據,還可以是非結構化的多媒體、網頁等數據.遵循one-size-does-not-fit-all的理念,NoSQL數據庫基于鍵值對、文檔、圖等不同數據模型,為管理不同類型的數據提供了有效的數據存儲服務.從歷史發展的角度看,Google BigTable[3]是較早提出的鍵值對模型,該模型使得對多列歷史數據的有序存取較為高效.數據進行層次范圍劃分后分布到多臺分片服務器上,采用嚴格一致性進行數據更新.Amazon Dynamo[25]采用另一種不同的鍵值對存儲方法,將鍵映射到某個特定的值,采用最終一致性方法進行數據更新.另一些流行的 NoSQL系統部分借鑒了這幾個系統的特征.如HBase的設計與BigTable非常類似,Voldemort[26]則復制了Dynamo的很多特征,Cassandra[27]則在數據模型方面借鑒了 BigTable,而在數據劃分和一致性方面借鑒了 Dynamo.由于鍵值對模型概念簡單且具有較高的存取效率和可擴展性,還有很多其他的系統,如Redis、RAMCloud[28]等,均以鍵值對為基礎進行模型的設計和實現.文檔是另一種數據類型,文檔數據庫主要用于存儲、檢索和管理面向文檔的信息.在NoSQL框架內,文檔可以看作是鍵值存儲的一個子類.不同之處在于數據處理的方式:在鍵值存儲中,數據對數據庫本身是不透明的,而面向文檔的系統則依賴于文檔中的內部結構.文檔數據庫與傳統的關系數據庫也有很大不同.關系數據庫將數據存儲在表中,單個對象可能分布在多個表中,而文檔數據庫則將給定對象的所有信息存儲在數據庫的單個對象中,并且每個數據庫對象內部結構可以各不相同.該方式簡化了外部對象到數據庫對象的映射,一定程度上方便了Web應用的開發和部署.圖數據管理技術起源于20世紀70年代,在這一階段,關系數據庫由于具備嚴格的關系理論輔助數據建模,操作接口簡單,數據獨立性高,查詢優化技術實現突破,逐漸成為數據管理中的主流技術;相反地,圖數據管理技術在數據建模、查詢表達等方面復雜度高,這一階段的圖數據管理技術發展緩慢.進入 21世紀,隨著語義網技術的發展以及社交網絡等真實大圖數據的迅猛增長,應用需求的驅動,使得圖數據管理的相關研究工作重新成為熱點.值得探討的是:與成熟的關系數據管理技術相比,圖數據管理仍然缺乏統一的數據模型和查詢語言,目前主流的圖數據庫包括 Neo4J[29]、OrientDB[30]、微軟的 Azure Cosmos DB[31,32]等,圖模型的常用數據結構為標簽圖(例如語義網中 RDF、部分知識圖譜)和屬性圖,圖的基本操作包括圖匹配、圖導航、圖與關系的復合操作等,常用的查詢語言為 SPARQL[33]、Cypher[34]和Gremlin[35]等,這些語言的語法都與關系結構化查詢語言 SQL相近.基于其他數據模型的開源系統可參見文獻[36].

2.3 計算系統

大數據計算系統可以采用不同的計算模型,常見的計算模型包括批計算、流計算、迭代計算、交互式計算等.每一類計算系統可以抽象出基本訪問接口,例如:批計算系統MapReduce提供了Map和Reduce接口,流計算系統Storm[37]提供了Spout和Bolt接口以分別接收和處理數據,迭代計算系統Giraph提供了面向圖中頂點計算的compute接口,交互式計算系統Presto提供了SQL的訪問接口.開發者只需實現相應的接口函數,就可以調用平臺的分布式、可擴展、容錯的計算能力,完成復雜的分析、查詢任務.批計算面向批量、靜態數據集上的計算,特別適合海量數據的計算,其對查詢的響應延時沒有過高的要求.典型的批處理系統包括Hadoop、Spark等.流計算系統面向的是實時流入的數據,并對每個單獨數據項流入系統時作出實時的處理,流計算對查詢響應的實時性要求高.典型的流計算系統有 Spark Streaming[38]、Storm、Flink[39]、Yahoo的S4[40]、阿里的JStorm[41]和 Blink[42]、Facebook的 Puma[43]、IBM 的 StreamBase[44].迭代計算面向的是需要多輪計算的應用場景,其中,上一輪計算的輸出可作為下一輪計算的輸入,直至滿足一定條件時系統終止計算.典型的應用包括具有明顯迭代特征的數據挖掘算法,例如K-means、K-medoids、Semi-clustering等,迭代的圖計算,例如PageRank、最短路徑等.迭代計算的系統包括GraphX[45,46]、Giraph[47]、GraphLab[48]、Haloop[49]等.交互式計算類似于傳統關系數據庫,為了達到實時的交互式響應,很多交互式系統會把數據完全維護在內存中,如Presto[50],典型的交互式計算系統包括 Impala[51]、Presto、Drill[52]等.

2.4 查詢處理引擎

大數據的查詢處理引擎基于大數據計算系統,通過計算系統提供的通用接口,借助分布式查詢優化技術,實現數據的高性能查詢與分析.大數據的查詢處理引擎為用戶和開發者提供類SQL(有些甚至可以兼容SQL)的查詢語言,通過語法解析器,把查詢語句轉換成對計算層的作業調度,最后由計算層把結果返回給用戶.根據調用計算系統的不同,這些引擎可分為:(1) 基于 MapReduce的查詢分析引擎;(2) 基于內存式批計算系統的查詢分析引擎;(3) 基于 MPP的查詢分析引擎.早期的大數據查詢分析引擎基于 MapReduce,又稱為 SQL-on-Hadoop.Hive[53,54]是基于Hadoop的一個數據倉庫工具,提供類SQL的查詢語言HiveQL,通過把用戶提交的HiveQL語句轉化為MapReduce作業并提交到Hadoop集群中運行.MapReduce作業串行執行,Hadoop監控作業執行過程,所有作業完成后返回結果給用戶.其中,分布式查詢優化體現在從 HiveQL到轉化為 MapReduce的作業以及MapRedue的多作業調度.Hive適合面向大數據集的批處理作業,例如搜索引擎的日志分析.因為Hive基于高延時的MapReduce批計算模型,所以不適合那些需要低延遲的應用.Spark SQL[55]是基于內存的批計算系統Spark的查詢引擎,其原理與Hive類似.Presto是基于MPP的查詢分析引擎,具有較低的響應延時,可用作交互式查詢引擎.與Hive把HiveQL轉化成多個MapRedue作業不同,Presto使用了一個定制的操作符和查詢執行引擎來支持 SQL.除了改進的調度算法之外,所有的數據處理都是在內存中進行的,操作之間采用流水線處理方式,避免了不必要的磁盤讀寫和額外的延遲.

2.5 小 結

進入大數據時代,大數據從業者已不像數據庫時代那樣追求使用關系數據庫管理系統解決所有數據管理的問題,而是探索從數據存儲、數據組織、通用計算、查詢處理等維度對數據管理系統進行解藕,解藕后的系統各模塊彼此相對獨立而又各自發展.根據大數據應用的實際需要,各模塊可通過采用松耦合的方式進行組裝,構建完整的大數據管理系統.

3 大數據管理系統的特征

認識新生事物可行的辦法就是“瞎子摸象”,也就是試圖從多個不同的視角去刻畫,綜合起來就可以獲得立體豐滿的圖景了.為此,本節將從數據特征、系統特征以及應用特征這 3個角度認識大數據管理系統.數據特征描述系統管理對象的特點,系統特征描述系統應具備的功能,而應用特征描述如何在大數據管理系統中進行應用的開發.

3.1 大數據管理系統的數據特征

大數據的數據特征可以用 4V 來刻畫,就是大容量(volume)、多類型(variety)、快變化(volocity)和低質量(veracity).這既是對大數據特征的刻畫,也是對大數據管理系統提出的新的要求.

(1) 大容量.多大的數據量可以稱為“大”?這沒有一個確定的標準,是與當時的技術水平和應用水平相關的,因此,大容量的挑戰是“與時俱進”的.1975年,著名的超大規模數據庫會議(VLDB)召開第1屆年會的時候,面臨的挑戰是管理100萬條記錄的商業數據.這在今天看來是很小的數據集了.在21世紀初,所謂數據密集型應用,數據量大約在1T左右,而今天所說的大數據,容量基本上在數百TB甚至PB級別,才會對現有的數據庫技術產生真正意義上的挑戰.1998年,圖靈獎獲得者Jim Gray曾提出數據量的增長符合“摩爾定律”,也就是說,每 18個月,新增的存儲量等于有史以來存儲量之和.以 BAT為例,百度的數據量已經超過1 000P,無疑是互聯網大數據的執牛耳者;

(2) 多類型.多類型是大數據顯著的特點,關系數據庫只能處理關系型數據,這是它的主要限制.現實世界中形形色色的應用并不能保證只有關系型數據,事實上,大數據就是要匯聚多個來源的數據,因此,數據種類既有結構化數據,也有各種非結構化數據.如何在一個系統平臺中處理多種類型的數據,是大數據的核心挑戰之一;

(3) 變化快.變化快的特征指的是產生、收集、分析大量數據的速度快,變化快的特點要求系統在數據產生的過程中分析數據,而不必將數據預先存入數據庫中.關于變化快這一點,我們感受得可能不夠深刻.舉一個例子,“雙十一”是淘寶搞的網上促銷活動,據公開數據顯示,2017年,支付峰值在11日凌晨5分鐘22秒時為25.6萬筆/秒,是2016年的2.1倍,這些交易給底層數據庫處理帶來的峰值是4 200萬次/秒.這還不是最高的要求,據說,某些網絡監控系統需要實現的數據入庫的要求超過100GB條記錄/秒.這就要求系統具有很高的吞吐量才行;

(4) 低質量.這是指大數據通常都是自動采集的,天然地具有噪音,如何在有噪音的情況下還能被有效地運用?這不是傳統的查詢操作所能做到的,需要發展更復雜的數據治理、數據分析和機器學習技術.

3.2 大數據管理系統的系統特征

目前,大數據管理技術還在快速進化之中,還遠沒有成型.管理好4V的數據,從大數據管理的功能定位出發,我們可以歸納出如下5個大數據管理的系統特征.

· 第一,大數據管理系統是一個開放的系統.大數據環境下,數據類型是開放的,系統面向的不能僅僅是事先定義好的數據類型,也需要支持各種非結構化的數據類型.其次,數據操作是開放的,系統面向的不能僅僅是確定的操作算子,需要支持用戶定義的操作的實施.因此,大數據管理系統不能僅僅是單一的處理引擎,需要有一個框架可以容納和支持多個不同類型數據處理引擎并存.需要說明的是:傳統的關系數據庫遵循封閉世界假設,即不在數據表中的記錄均為假.基于此假設,關系數據庫的查詢優化技術,包括查詢等價變換、查詢包含、物化視圖更新等操作,也均基于封閉世界假設.而大數據的開放性特征使得傳統關系數據庫的封閉世界假設不再適用.在此背景下,大數據系統中的查詢表達和查詢優化將是一個難點,特別是面對用戶定義的操作以及跨引擎的查詢等如何進行優化,是一個巨大的挑戰;

· 第二,大數據管理系統是一個多模型并存的系統.大數據的多類型特征,使得單一的關系模型無法為多樣化的大數據進行有效建模.在關系模型中,關系模式要求至少滿足第一范式.為了減少數據冗余和數據異常,往往要求關系模式滿足盡可能高的范式要求;在管理數據時,需要事先定義關系模式,由于模式的修改代價非常昂貴,往往在進行數據庫設計時,要求數據庫模式(關系模式等的集合)相對穩定.上述這幾個特性在大數據應用背景下均無法得到有效滿足.首先,大數據的應用主要面向分析型,數據以追加操作為主,數據冗余和數據異常不是主要矛盾.事實上,在實際的大數據應用中,性能往往是需要優先考慮的因素.為了提高分析性能,在數據建模時,往往通過引入數據冗余,降低關系模式滿足的范式要求(甚至都可以不滿足第一范式),減少甚至避免昂貴的連接操作.這種做法在寬表、面向社交網絡數據管理的文檔模型中得到了廣泛應用.從這一點上看,大數據應用的數據建模與傳統的關系數據庫設計理念是相違背的.其次,大數據應用中,特別是面向非結構化數據管理的互聯網應用,關系模式往往無法事先就完整地定義下來,并且隨著應用的深入開展,關系模式也是不斷變化的,這與關系數據庫建模中要求數據庫模式相對穩定的假設是相違背的.在同一個系統中,支持多數據模型混合并存并提供一種通用的數據建模方法,目前還沒有一個成熟的技術方案;

· 第三,大數據管理系統將是一個強調高可用性和分布式可擴展性的系統.大數據應用的多樣性特征弱化了傳統關系數據庫中事務的 ACID特性,強調數據的高可用和分布式可擴展,容許數據有最終一致性甚至弱一致性.傳統的數據庫面向的是涉及到人、財、物等需要精細管理的應用,特別是面向轉賬、記賬、訂票等核心業務的應用,事務在其中起著決定性的作用.而大數據應用的驅動,包括域名服務(DNS)、搜索、電子郵件等,已經不同于傳統的涉及到人、財、物等需要精細管理的應用,它不要求嚴格的數據一致性,甚至可以容許數據的部分不一致,強調的是服務的高可用性和分布式可擴展性;

· 第四,大數據管理系統將是一個量質融合的系統,不僅需要管理大容量的數據,還要管理帶噪音的數據.傳統的關系數據庫通過數據完整性約束的檢查與維護機制,在破壞數據庫完整性的操作發生時,通過拒絕等行為保護數據庫不受侵害.因此,傳統關系數據庫可以認為不關心數據質量問題.但是對于大數據管理系統,缺失數據、矛盾數據、不完整數據的存在是常態,因此,對數據的查詢要用對結果的排序來取代,對數據的統計建模要用機器學習模型來取代;

· 第五,大數據管理系統的中心將是知識管理.大數據的價值在于知識,如何支持從大數據中發現知識,是大數據管理系統不可或缺的功能.有兩種基本的方法:一種是知識圖譜,還有一種是深度學習.這都是目前大數據知識發現中最重要的方法.

大數據管理系統還沒有像關系數據庫那樣成型,我國在大數據與云計算重點研發計劃中,已經設立了面向領域的大數據管理系統的兩個項目:一個是支持工業大數據領域,一個是支持科學大數據領域.目標是結合領域應用的特點,探索大數據管理系統的基礎架構、核心功能和示范應用.

3.3 大數據管理系統的應用特征

大數據管理系統的應用到底長什么樣?如何進行開發?目前也許還看不清楚.但是,我們認為以下幾點值得關注.

(1) 以對象為中心進行數據組織,實現數據匯聚.不同于傳統的信息系統,傳統的信息系統是以業務為中心的,數據需求來自于業務系統,數據組織是為了業務處理的高效率;大數據則不同,大數據管理系統是以服務對象為核心,匯聚來自不同的業務系統的數據,包括不同種類、不同頻度的數據等,構成大數據以進行處理;

(2) 以第四范式為解決問題的新模式.第四范式的另一種叫法是基于數據的科學發現方法,是相對于其他3種范式而言的,即實驗觀察、理論推導和計算機模擬.實驗觀察是最古老的解決問題的方法,例如,通過實驗獲得經驗,總結規律,形成新知識;理論推導是以數學為工具的方法;計算機模擬可以用于研究核爆炸、天氣演化等.不同于上述3種模式,大數據方法是通過積累大數據,并開發大數據上的數據挖掘方法來發掘規律;

(3) 以機器學習為主要應用類型.也許,一種稱為OLML(online machine learning)的應用將大量出現,即在

同一個大數據集上,多個用戶都在訓練自己的機器學習模型,并進行預測.如果我們將機器模型訓練看成是大數據不同數據子集上的計算的話,一個OLML就類似于一次SQL查詢處理.

3.4 小 結

作為大數據管理的核心,大數據管理系統是一套面向大容量、多類型、快變化、低質量數據管理的系統軟件,該系統以量質融合的知識管理為中心,支持結構化、半結構化、非結構化等多類型數據的組織、存儲和管理,具備高可用和分布式可擴展的系統架構特征和不同級別的事務特征,提供類SQL的數據查詢語言定義、操縱、控制、可視化數據,支持快速的應用開發和系統運維.AsterixDB[56]是由學術界和工業界聯合開發的、探索面向大數據管理的一套開源系統.與NoSQL數據庫相比,AsterixDB提供了一套較為完整的類SQL語言來定義和操縱數據.但該系統目前只支持單記錄的事務,無法提供不同級別的事務一致性;系統的設計也不是面向知識管理的,因此,該系統距理想中的大數據管理系統還有很長的一段路要走.

4 大數據管理系統未來發展展望

結合大數據管理系統正在經歷以軟件為中心到以數據為中心的計算平臺的變遷以及軟件基礎設施化的大數據時代特征,本節從數據模型、計算模式、系統架構、新硬件、自適應優化這5個方面展望大數據管理系統的未來發展.

4.1 多數據模型并存

大數據應用的鮮明特征之一就是數據的多樣性,既有結構化的關系數據、圖數據、軌跡數據,也有非結構化的文本數據、圖片數據,甚至是視頻數據等.淘寶的“雙十一”就是這類典型的大數據應用.大數據管理系統的一個基本要求就是能夠支持結構化、半結構化、非結構化等多種數據類型的組織、存儲和管理,形成以量質相融合的知識管理為中心、并以此提供面向知識服務的快速應用開發接口.縱觀現有的大數據系統,特別是以NoSQL數據庫為主的大數據系統,走的仍然是一條一種數據模型解決一類數據的傳統道路.雖然也符合one-size-fits-a- bunch的設計理念,但應用的要求仍然希望這里的“bunch”盡可能地接近“all”.具體來說,圖數據庫支撐的是類似于社交網絡、知識圖譜、語義網等強關聯數據的管理;關系數據庫支撐的是人、財、物等需要精細數據管理的應用;鍵值對數據庫適合非結構化或寬表這類無需定義數據模式或模式高度變化的數據管理.在新型大數據應用背景下,把多種類型的數據用同一個大數據管理系統組織、存儲和管理起來,并提供統一的訪問接口,這是大數據管理系統的一條必經之路.多數據模型并存下的數據管理會存在很多的技術挑戰,具體包括:

(1) 數據如何建模?關系數據庫具有嚴格的關系數據理論,并從降低數據冗余度和數據異常兩個維度輔助數據建模.而在新的數據模型下,甚至是多數據模型下,如何進行數據建模是一個值得探索的課題;

(2) 數據的訪問提供統一的用戶接口.多模型之間的數據如何交互和協同以及提供與存儲層和計算層的統一交互接口;

(3) 對多數據模型混合的數據處理提供執行優化,通過統一的資源管理優化任務調度,通過性能預估優化計算和通信等.

4.2 多計算模式互相融合

未來的大數據管理系統具有多計算模式并存的特點.目前,Hadoop、Spark[57]及 Flink等主流大數據系統具有不同的計算模式,系統通常會偏重于批任務模式或流任務模式中的一種,這些系統提供的用戶接口也不統一.然而在實際應用中,經常存在同時需要批任務、流任務處理的需求,例如淘寶的“雙十一”就是批流融合的典型應用.因此,未來的大數據管理系統需要對批、流計算模式進行統一設計,實現統一的能夠進行批流融合的計算引擎.同時,需要設計能夠屏蔽底層不同計算模式差異的用戶接口,方便使用.

機器學習是大數據管理中另一類重要的計算模式.目前,學術界、工業界廣泛使用 TensorFlow[58]、Spark MLlib[59]、Caffe[60]等系統處理相應機器學習任務.TensorFlow能夠以數據流圖作為表示形式,在參數服務器開發、執行機器學習任務;Spark MLib基于MapReduce模型接口完成對大量數據的訓練.這些系統僅關注機器學習中的算法訓練,而實際應用中存在多種計算模式混合的情況,且參數模型可達百億維度,現有系統均無法解決.因此,能夠兼容高維機器學習計算模式,也是未來大數據管理系統的重要內容.

大數據管理系統也應兼容交互式計算模式,滿足日益增長的對交互式大數據分析應用的需求.現今,Hive等主流分析工具在易用性方面有較大的提升空間,目前主要由專業人員使用,普通分析人員較難掌握.同時,這些交互式系統在與操作人員交互的過程中還存在操作延遲長等問題,更高效的智能交互計算模式也是未來大數據管理系統需要考慮的方向之一.

總之,大數據存在對批計算、流計算、機器學習、交互式計算等多種計算模式的需求.同時,數據存儲量大,無法對任一計算模式均保留一份數據,未來的大數據系統需要在同樣存儲數據的基礎上支持多種計算模式.目前主流的大數據系統均基于開源軟件,各層開源軟件可相互兼容.未來的大數據管理系統需要兼容這些主流的大數據系統,同時,將存儲、通用計算、專用計算分層,明確各層的接口,并在各層設計、實現兼容多種計算模式,降低系統耦合性.

4.3 可伸縮調整

在軟件基礎設施化的大數據時代特征背景下,未來的大數據管理系統應以云計算為平臺,具有更好的分布可擴展、可伸縮調整特點,能夠實現跨域的無縫融合.未來的大數據管理系統通過高速網絡將不同的硬件資源連接構成一個計算系統整體,互相配合,為終端用戶服務.云平臺上可以運行多類應用,不同的應用需要不同的服務資源,因此系統配有多種存儲與數據組織模塊,可滿足不同上層任務負載和計算模式的需求.系統面向多類終端用戶,用戶可以根據需求選擇、配置合適的存儲架構和數據組織方式,針對特定應用,選擇、組裝對應的功能模塊,并可根據任務負載的強弱實時調整系統的規模和負載的分配策略.同時,針對不同用戶的需求,對應用進行深入理解,提取特征進行模型構建,實現彈性可伸縮調整是未來大數據管理系統的核心技術之一.

目前的大數據管理系統通常使用分布式文件系統(例如HDFS和Ceph)或者直通式鍵值系統管理數據的存儲,并在此基礎上對鍵值、文檔、圖等進行組織,構成NoSQL系統,為用戶提供服務.NoSQL系統提供了更靈活的數據模型,但相對于傳統SQL技術不具有強一致性,且通常只用于執行簡單的分析任務.而未來的大數據管理系統應具有NewSQL[61]特性,可實現傳統SQL和NoSQL間的平衡,具體包括:(1) 具有傳統關系數據模型和傳統數據庫的事務 ACID一致性,用戶可以使用 SQL語句對系統進行操作;(2) 具有 NoSQL可擴展等靈活特性,能夠利用高速網絡和內存計算,實現對海量數據的存儲管理和分析等功能,系統可伸縮調整.

4.4 新硬件驅動

大數據管理系統由硬件和軟件兩方面構成,軟件技術可受益于硬件技術發展,同時也受硬件技術體系結構特征和局限性的約束.通過對不同硬件設計合適的數據結構和算法可提升硬件效率.目前,硬件體系結構正在經歷巨大變革,在向專用硬件的方向發展.同時,各類新型存儲、高速互聯設備的出現也在改變以往大數據管理系統中的設計與底層支持.

近些年,以GPU為代表的加速器件得到了迅猛發展[62],也有越來越多的大數據系統使用GPU、Xeon Phi[63]、FPGA[64]等新硬件加速大數據管理任務.相對于傳統管理系統,新硬件驅動的大數據管理系統可提供更快的負載處理速度和更好的實時可視化及處理效果.雖然新硬件驅動為大數據管理系統提供了新思路,但也帶來了一系列需要解決的挑戰.

(1) 新硬件分配任務.不同種類的加速設備具有完全不同的體系結構特征,它們適合處理的任務特征不同,因此在未來的大數據管理系統中,需要盡可能地使各加速設備處理合適的負載;

(2) 數據傳輸.由于各設備可能獨立接入系統,處理負載時需從主存復制數據到設備.因此,在進行任務分配時,應充分考慮數據傳輸時間;

(3) 新硬件下的數據結構和算法.傳統系統中適合 x86架構處理器的數據結構可能不適合 GPU、FPGA等新硬件,需要考慮新硬件的執行特點有針對性地設計新的數據結構和算法.

在存儲和數據傳輸方面,新硬件也可發揮新的作用.以非易失存儲器(non-volatile memory)[65]為代表的新介質可進一步加速數據處理過程,如,在故障恢復時減少恢復時間等.在大數據管理系統的存儲層級,有可能會有多種存儲類型,如何設計合適的數據存儲也是新硬件驅動下系統設計重要的考慮因素.在分布式系統中,網絡傳輸可能是性能瓶頸,更快速的數據傳輸速度和新的網絡技術,如RDMA[66]、Infiniband[67]等,可以緩解以往分布式系統中的數據傳輸瓶頸,如何利用這些新技術也是未來大數據管理系統設計的重要內容.

4.5 自適應調優

目前,大數據管理系統通常采用分布式文件系統和直通式鍵值存儲等開源存儲系統,并在這些開源系統的基礎上構建以鍵值對、文檔等為主要數據組織的NoSQL系統.雖然目前的系統能夠為大數據提供存儲服務,且能夠進行系統擴展,但系統功能相對單一,面向復雜的計算模型和負載任務通常顯得自適應能力不足,缺少必要的可伸縮調整.開發新型的能夠自適應多種計算模型和任務的可伸縮調優技術,是未來大數據管理系統的發展方向.未來大數據管理系統的存儲需要支持具有不同訪問特征的計算模型和任務,如何針對不同模型自適應地調整內部模塊、選擇合適的存儲以及如何對于不同任務按需分配不同的存儲資源進行自適應的彈性調優(例如,通過分析系統日志來優化軟件系統配置的方法[68]),是未來大數據管理系統在數據存儲方面需要重點考慮的內容.

未來的大數據管理系統應能夠基于不同的存儲介質和存儲架構有效地對數據進行組織,并根據上層計算模型的訪問模式自適應地選擇合適的模塊,同時能夠做到根據不同任務需求分配資源.具體可包括:(1) 支持多種類型存儲,如具有高并發、低延遲的直通式鍵值存儲和分布式存儲等;(2) 支持主流數據模型,能夠對數據進行高效組織,如對關系模型和圖模型的數據提供統一訪問接口,同時采用合適的數據劃分策略,通過預估減少系統在存儲層和計算層間的數據傳輸量;(3) 支持多種計算模式和混合任務的自適應調優,通過對不同存儲類型和數據類型進行組織,對混合計算模型和任務構建性能模型,自動選擇合適的存儲模塊并進行調優;(4) 支持大數據存儲的可伸縮調整和容錯,能夠根據數據和任務類型提升不同類型存儲的效率,并能面向不同任務準確地分配合適的資源.

5 總 結

本文回顧了數據管理的發展歷史,指出了大數據的開放性特征使得傳統關系數據庫中的三大核心技術——關系模型、查詢優化、事務處理技術均無法滿足大數據的管理要求.大數據時代背景下,數據管理技術的設計理念從原來關系數據庫的one-size-fits-all轉變到one-size-does-not-fit-all,人們開始嘗試研發適合自己應用的大數據系統.現階段,主流的大數據管理系統生態具有明顯的分層結構,各類子系統獨立發展,通過采用松耦合的方式進行組裝,構建為完整的大數據管理系統.通過對大數據管理系統應具備的數據特征、系統特征和應用特征的分析,指出大數據管理系統技術還在快速進化之中,并給出了大數據管理系統的概念說明.最后,本文從數據模型、計算模式、系統架構、新硬件、自適應優化這5個方面對大數據管理系統的未來發展趨勢作了預測.