杜小勇,盧 衛(wèi),張 峰

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

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

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

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

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

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

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

1 數(shù)據(jù)庫管理系統(tǒng)的發(fā)展歷史回顧

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

1.1 第1代:層次、網(wǎng)狀數(shù)據(jù)庫系統(tǒng)

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

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

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

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

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

1.2 第2代:關系數(shù)據(jù)庫系統(tǒng)

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

為什么能做到這一點呢?

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

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

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

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

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

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

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

1.3 第3代:數(shù)據(jù)倉庫系統(tǒng)

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

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

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

1.4 第4代:大數(shù)據(jù)管理系統(tǒng)

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

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

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

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

1.5 小 結

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

2 大數(shù)據(jù)管理系統(tǒng)的現(xiàn)狀

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

2.1 存儲系統(tǒng)

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

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

2.2 面向不同數(shù)據(jù)模型的NoSQL系統(tǒng)

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

2.3 計算系統(tǒng)

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

2.4 查詢處理引擎

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

2.5 小 結

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

3 大數(shù)據(jù)管理系統(tǒng)的特征

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

3.1 大數(shù)據(jù)管理系統(tǒng)的數(shù)據(jù)特征

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

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

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

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

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

3.2 大數(shù)據(jù)管理系統(tǒng)的系統(tǒng)特征

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

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

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

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

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

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

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

3.3 大數(shù)據(jù)管理系統(tǒng)的應用特征

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

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

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

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

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

3.4 小 結

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

4 大數(shù)據(jù)管理系統(tǒng)未來發(fā)展展望

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

4.1 多數(shù)據(jù)模型并存

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

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

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

(3) 對多數(shù)據(jù)模型混合的數(shù)據(jù)處理提供執(zhí)行優(yōu)化,通過統(tǒng)一的資源管理優(yōu)化任務調度,通過性能預估優(yōu)化計算和通信等.

4.2 多計算模式互相融合

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

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

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

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

4.3 可伸縮調整

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

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

4.4 新硬件驅動

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

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

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

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

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

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

4.5 自適應調優(yōu)

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

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

5 總 結

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