帶你讀《Greenplum：從大資料戰略到實作》之三：資料處理平台的演進

點選檢視第一章 點選檢視第二章

第3章 資料處理平台的演進

在上一章中，我們回顧了雲原生應用的數字化戰略，進而提出大資料和機器學習是未來企業構築競争優勢和壁壘的高地，最後從人才和技術角度介紹如何建立合适的資料平台。本章将着重介紹資料處理平台的發展曆程，根據其演進的内在動力、外在環境和目前趨勢，提出內建資料處理和分析平台是未來發展的方向。最後從技術層面介紹大資料平台選型時需要考慮的因素。

3.1　前資料處理時代

Data（資料）一詞最早出現于17世紀40年代，而使用“資料”表示“可傳輸和可存儲的計算機資訊”始于1946年。Data Processing（資料處理）一詞的使用則始于1954年前後，泛指收集和處理資料以生成有意義的資訊。

在“資料處理”一詞出現之前，資料處理任務和行為一直存在，這可追溯到上古時期的結繩記事。之後常用的資料處理工具是算盤，基于算盤發展而來的珠心算至今仍深受國人喜愛。

人工資料處理持續使用了數千年。19世紀末，人們開始使用稱為單元記錄裝置（Unit Record Equipment）、電算機（Electric Accounting Machine）或制表機（Tabulating Machines）的機電裝置進行自動資料處理。由于可以較快速地處理一些複雜的資料處理任務，是以這類裝置在政府和企業中變得非常流行。但整個資料處理流程需要精心策劃，以便各種單元記錄裝置可以正确處理表示各種資訊的打孔卡片。這些機器每分鐘可以處理100～2000個打孔卡。打孔卡是一塊紙闆，通過在固定的位置打孔或者不打孔來表示資料。在錄音帶出現之前，它是一種非常流行的存儲器，現在很多學校使用的答題卡就是基于類似原理。

人類曾經發明過很多存儲資料的媒體，包括上古用于計數的繩子、壁畫、甲骨、碑刻、竹簡、帛書及後來的紙。然而，這些資料或資訊隻有人類可以識别。工業革命時期，人們發明了可以控制機器的絲織機，同樣的原理後來用于自動鋼琴演奏。這些機器可以解讀存儲在媒體上的指令。19世紀80年代，霍爾瑞斯發明了打孔卡，這是一種可以被機器解讀的存儲資料而非指令的媒體。他還發明了鍵控穿孔機、分揀機和制表機等單元記錄機器，這些發明奠定了自動資料處理行業的基礎。霍爾瑞斯發明的方法被用于1890年的美國人口普查。1896年，他建立了制表機公司（TMC），後來該公司和其他三家公司合并組建了計算制表記錄公司。1924年，計算制表記錄公司改名為國際商業機器公司（IBM）。

IBM是當時最大的單元記錄裝置供應商，是以這種打孔卡又稱為IBM卡，因其發明者為霍爾瑞斯，也被稱為霍爾瑞斯式卡。圖3-1顯示了80列、矩形孔的IBM打孔卡片。

自動資料處理大大提高了效率，并節約了成本。1880年的美國人口普查資料的統計工作耗時7、8年之久，使用了自動資料處理裝置之後，僅用時不到2年（統計制表工作用時不到2個月，後進行了大量的驗證工作）就完成了1890年的人口普查資料的統計工作。盡管工作量是之前的2倍，但成本卻節省了大約500萬美元。

同時期比較流行的其他裝置還有打字機、加法機和收銀機等。雷明頓（Remington）公司自1873年開始就是主要的打字機制造商，推出了第一台量産打字機和QWERTY鍵盤。1894年，國家收銀公司（NCR）公司發明了電動收銀機，1922年銷售了200萬台。1925年，底特律的伯勞斯公司推出一款便攜加法機。到了20世紀20年代，大多數公司裝備了雷明頓的打字機、伯勞斯的加法機、IBM的制表機、NCR的收銀機。其主要客戶包括政府、保險公司和鐵路公司等。

電子計算機出現之後，代替了多個獨立的單元記錄裝置，資料處理進入電子資料處理（Electric Data Processing，EDP）時代。美國人口普查局于20世紀50年代首次使用電子計算機進行人口普查工作，當時使用的是UNIVAC I系統。

若非特殊說明，之後内容中提到的“資料處理”指使用計算機的電子資料處理。

3.2　早期的電子資料處理

3.2.1　電子計算機的出現

前面說過，在電子計算機出現之前，人類就發明了各種計算工具和機器，早期的人工計算工具有算籌和算盤。1642年，法國哲學家和數學家帕斯卡（Blaise Pascal）發明了世界上第一台加減法計算機。它利用齒輪轉動原理進行機械式計算，通過手搖方式操作運算。1671年，德國數學家萊布尼茲（G.W. Leibnitz）制造出第一台能夠進行加減乘除四則運算的機械式計算機。1833年，英國科學家巴貝奇（Charles Babbage）提出了制造自動化計算機的設想，他所設計的分析機引進了程式控制的概念。盡管該機器未能實作，但其設計思想和方案成為現代計算機的雛形。1886年，巴貝奇發明了差分機，使用齒輪進行數值計算。1925年，美國麻省理工學院制造了第一台機械模拟式計算機，1942年又研制出采用了速度更快的繼電器的模拟式計算機。1944年，艾肯（Howard Aiken）在IBM的資助下成功研制出世界上第一台數字式自動計算機Mark I，實作了當年巴貝奇的設想。這台機器使用了三千多個繼電器，可以進行全自動運算，代表着當時人類制造機械式電動計算機的最高水準。

随着電子技術的發展，美國賓夕法尼亞大學在美國軍方的資助下于1946年研制出第一台電子數字積分機和計算機（ENIAC），這是世界上第一台通用電子數字計算機。它使用了18000多個電子管、1500個繼電器，重30噸，占地約170平方米，運算速度達到每秒5000次，比Mark I快1000倍以上。

但ENIAC有一個緻命的缺點—程式和資料分離，即資料存儲在存儲器中，而程式存儲在機器外部的電路裡。運算之前，先要按照程式手工把相應的電路接通或通過讀卡機讀卡以執行各個指令，費時費力，無法發揮它的運算速度。馮·諾依曼（Von Neumann）和賓夕法尼亞大學的莫爾電機系小組提出了“存儲程式”的概念，确立了計算機由輸入、存儲、運算、控制和輸出五個基本部件組成的結構，将指令像資料一樣進行存儲和處理。按照此原則制成的第一台存儲程式、順序控制的電子離散變量自動計算機（EDVAC）于1949年在英國的劍橋大學投入使用。EDVAC也是第一台使用錄音帶的計算機，可以多次在錄音帶上存儲程式。至今，計算機仍遵循此存儲程式原則。

3.2.2　軟體

早期的計算機通過重新布線等方式進行程式設計，多為專門的資訊處理任務而定制。後來，阿蘭·圖靈和馮·諾依曼提出的存儲程式思想為解決通用問題提供了思路，可程式設計性開始受到關注。

軟體（Software）一詞最早指軟制品，如毛織物或者棉織物，也指相對易腐爛的消費品。20世紀50年代，硬體（Hardware）一詞已經廣泛使用，但是軟體還沒有出現。直到1960年前後，“軟體”一詞在計算機領域才開始使用，用于描述計算機制造商提供的除了硬體之外的所有東西，包括程式和服務等。軟體的概念一直在變遷，到20世紀70年代中期，開始用于表示計算機使用的程式和其他操作資訊。此時，軟體成為計算機程式的同義詞。

早期基于電子計算機的電子資料處理基本上直接繼承自基于單元記錄裝置的資料處理方式，計算機使用也是獨占式的。之後，随着計算能力的提升，開始出現批處理模式和分時共享模式，逐漸演變出軟體和作業系統。

早期的計算機沒有作業系統，每個使用者在預定的時段獨占整個計算機，包括外設（例如列印機和讀卡器）。在指定的時間段，使用者帶着程式和資料來運作其程式。程式和資料存儲在打孔卡、紙袋或者錄音帶上。通過輸入裝置加載程式和資料後，一直獨占機器運作，直至程式運作結束或者出現錯誤。通常，可以通過控制台調試程式（控制台常使用撥号盤、切換開關或者面闆燈）。

早期的代碼使用機器碼編寫。為了提高程式設計效率，出現了符号語言。彙編器和編譯器将符号程式編譯成機器碼。之後出現了操作打孔卡或者錄音帶的庫代碼，用以協助常用的輸入和輸出操作，這些代碼可以連結到使用者的程式，避免了重複開發。這是現代作業系統的起源。但此時，機器仍然一次隻能運作一個作業。

随着計算機能力的提升，運作程式的時間逐漸減少，而将裝置交給下一個使用者的時間占比越來越大。之前根據牆上的時鐘核算機器使用賬單的方式開始轉變為由計算機自動記賬；運作隊列也由門口的人工排隊變成了工作台上的諸如打孔卡或者錄音帶之類的等待隊列。之後，自動記錄和檢測程式不僅需要記載CPU的使用情況，還需要計算列印頁數、打卡次數、讀卡次數、磁盤使用容量等資訊。慢慢地，這些功能融合為一個程式，它在第一個客戶的工作開始之前已經運作，可以讀取客戶作業、控制其執行情況、記錄客戶作業資源使用情況、在作業結束後重新配置設定資源，然後立即處理下一個作業。這些駐留的程式在作業系統這個術語出現前通常被稱為監控程式。

一個早期的用于實際工作的作業系統是通用汽車于1956年為其IBM 704研發的GM-NAA I/O。大多數早期IBM大型機作業系統也是由客戶研發的，每個供應商或者客戶都為其特定主機研發一個或者多個特定作業系統。即使是同一個供應商，其每個作業系統也可能具有完全不同的操作模式。這種情況一直持續到1964年IBM System/360和OS/360釋出，該項目緻力于為所有相容機提供相同的指令和輸入、輸出架構。

此時，樹形結構的分級檔案系統開始出現。1958年的東部聯合計算機會議介紹了早期的分級檔案系統。1965年釋出的Multics系統（一個早期的分時作業系統）對檔案系統的影響比較大。之後的Unix的檔案系統基于Multics，并支援任意級别的檔案目錄層級。

“檔案”（File）一詞早在1950年就被用來表示計算機存儲的内容。美國無線電公司（RCA）的廣告中指出：無數計算的結果可以儲存在檔案中，之後可以再次取出。在20世紀50年代，檔案通常指存儲在打孔卡上的資訊。圖3-2給出了當時常見的打孔卡照片。

在20世紀50年代到60年代，伴随着通用電子計算機、磁存儲媒體、作業系統、檔案系統等技術的發展，電子資料處理技術逐漸發展起來。到20世紀60年代中後期，資料處理應用基本還是使用檔案作為持久化資料的存儲方式，主要的存儲格式之一是衍生自打孔卡技術的稱為平面檔案的格式，即檔案由記錄組成，一個檔案的記錄由同一種類型的記錄組成，記錄類型由固定長度的字段組成。

支援分時共享的作業系統可以同時運作多個資料處理應用，它們各自有儲存資料的檔案，互相之間不能通路。一些通用的檔案操作被開發出來用以提高效率，包括排序、合并和報表等。

3.3　資料庫

随着硬體技術和應用的發展，基于檔案的資料管理顯現出其不足之處：

• 每個應用程式要自行定義底層資料格式，依賴程度高，維護代價昂貴。
• 檔案格式不相容，無法在不同應用間共享資料。

為了解決這些問題，人們開始研究能進行更高效、安全、快捷的資料處理的系統，于是造就了一個曆經半個多世紀仍然極具活力的領域—資料庫和資料庫管理。

1964年前後，計算機領域的文獻中出現了一個新詞—Data Base。這個詞由美國軍事情報系統的從業人員創造，表示分時共享計算機系統中的多使用者共享的資料集合。當時的資料處理技術正在經曆“內建資料處理”的陣痛，而Data Base很快成為描述內建不同應用程式的資料而形成的資料集的名詞。現在維基百科對于資料庫的定義是：按照一定方式組織起來的資料集合，通常使用資料庫管理系統通路這些資料。

資料庫管理系統的發展經曆了很多階段，有些資料庫管理系統已經淡出大衆視野，有些仍然在不斷演進。資料管理系統主要有以下幾個發展階段：

• 導航型資料庫
• 關系型資料庫
• 面向對象型資料庫
• 關系-對象型資料庫
• NoSQL
• 分布式資料庫
• NewSQL

本節将聚焦于NoSQL出現之前的資料庫技術的演進。

20世紀60年代早期的研究源自以下使用者需求：

1）資料整合：早期的資料處理應用程式使用主檔案（Master File）持久化儲存資料。主檔案是應用程式的一部分，企業内部不同應用的主檔案是獨立設計和維護的，資料重複和不一緻的問題很普遍。是以，整合不同應用的各種主檔案，實作資料共享和集中管理的需求越來越旺盛。此外，資訊管理應用程式也需要這種整合才能起效。

2）資料獨立性：早期的應用使用機器語言或者彙編語言編寫，效率低下，并且依賴于硬體。這種複雜度使不懂程式設計的人員難以通路資料。是以，提供更抽象的語言，使得應用程式獨立于底層資料存儲和管理成為一個重要需求。

3）資料保護：資料整合也帶來了新的挑戰，原來每個應用通路自己的主檔案，不會涉及權限管理的問題，而整合之後需要防止資料丢失和未授權的通路，是以需要通路控制和防止資料丢失的機制。

這些需求催生了相應技術的發展。

3.3.1　資料模型

資料庫系統的基石之一是資料結構以及對資料結構的操作方法，早期稱之為資料結構化方法。後來Edgar F. Codd提出關系理論時，使用資料模型來描述這一問題，這一概念沿用至今。

早期資料處理系統的資料模型衍生自打孔卡技術，是以比較簡單。常用的一種模型由檔案組成，檔案由記錄組成，一個檔案的記錄屬于同一類型，記錄類型由固定長度的字段定義。這種方式稱為平面檔案（Flat File）。檔案通常儲存在順序存儲媒體上，如打孔卡或者錄音帶（這個時候可随機通路的磁盤還沒有出現）。

當試圖對資料進行整合時，早期資料模型的局限性立刻顯現出來。最主要的問題是缺乏有效的表示實體之間關聯的方法，例如一對多或者多對多關系。處理這種實體之間關聯的操作和處理打孔卡不一樣，需要額外的排序和合并操作。為了解決這些問題，資料庫技術領域發展出了多種新的資料模型。

1. 層次模型

層次模型出現在20世紀60年代早期，它在一定程度上解決了實體關聯問題。基于層次模型的資料庫由連結在一起的記錄集合組成，一個記錄包含多個字段，每個字段隻有一個資料值。連結（Link）将兩個記錄關聯在一起。

層次模型可以友善地表示實體間一對一關系和一對多關系，但不适合表示多對多關系。多對多關系可以通過記錄複制之類的方式實作，這種方法有兩種主要缺點：1）更新記錄時容易造成資料不一緻；2）浪費空間。使用虛拟記錄（類似于檔案系統中的符号連結）方法可以在一定程度上解決這個問題。

使用樹形邏輯結構可以較好地描述層次模型。例如，有兩個記錄類型：

• 公司（company）：有公司名字、位址等字段。
• 員工（employee）：有員工名字、年齡等字段。

用樹形邏輯結構表示公司和員工記錄的資料模型如圖3-3所示。

層次模型最自然的存儲方式是使用父子指針方式存儲，如圖3-4所示。

這種方式造成的問題是：即使記錄類型本身是定長記錄，但由于子記錄個數可能不同，造成該記錄類型的存儲長度是不固定的。這種變長記錄不利于高效地存儲和處理。

一個常見的優化存儲結構是使用最左子指針和兄弟指針替代父子指針，如圖3-5所示。

實際存儲時，可以一個檔案存儲一種記錄類型，也可以一個檔案存儲多種記錄類型。

IBM的IMS資料庫就是一種層次模型資料庫，也是最古老的資料庫系統之一，至今仍然被廣泛使用。

2. 網狀模型

層次模型雖然在一定程度上解決了實體關聯的問題，但仍有一定的局限。更通用的方法直到20世紀60年代中期直接通路儲存設備（Direct Access Storage Device，DASD）普及後才出現，DASD使得網狀模型成為可能。

早期的商業資料進行中的網狀模型起源于物料清單應用（BOM），這種應用常需要表示一對多和多對多關系。為了簡化物料清單應用的開發，IBM提出了一種稱為BOMP的通路方法，後又推出增強版的DBOMP。BOMP資料模型使用兩種類型的檔案：主檔案（Master File）和鍊檔案（Chain File）。每個記錄類型包含單個固定格式類型的記錄和一個稱為鍊的結構。鍊結構含有單個主檔案記錄和來自單個鍊檔案的可變數量的記錄。某個鍊檔案記錄可以出現在不同類型的不同鍊中，并關聯主檔案記錄到這些鍊的頭部。對于物料清單類型應用，“零件鍊”和“零件使用鍊”這兩種鍊足以表示多對多的零部件關聯關系。雖然最初是為物料清單應用而開發，但是BOMP被應用于各種各樣的應用程式中。CINCOM公司的TOTAL DBMS也是基于BOMP思想。

另一種非常成功的網狀模型資料庫是GE的IDS系統（Integrated Data Store）。在IDS中，一個資料庫由記錄和記錄鍊組成，沒有檔案的概念。記錄鍊和BOMP的鍊檔案相似，由一個所有者（owner）記錄和多個成員記錄組成。一個記錄可以是不同類型的不同鍊的成員。和BOMP不同的是，所有者記錄可以是其他鍊的成員。這樣就可以建立任意深度的層次模型，以及複雜的網狀模型。

網狀模型概念上也是由不同類型的記錄集合組成，記錄之間的關系通過連結（Link）來表示。20世紀60年代後期、70年代早期，CODASYL的資料庫工作組（Data Base Task Group）基于網狀模型的商業資料庫對網狀資料模型進行了标準化。

為了簡化實作和處理，在DBTG模型中，不允許使用多對多Link，因而兩個記錄類型之間的資料結構圖的形式都是A←B（記錄類型A可以有多個子記錄類型，記錄類型B隻能有一個父記錄類型），這稱為一個DBTG集合（set）。每個DBTG集合有且隻有一個記錄類型為該集合的所有者（owner），其他記錄類型為該集合的成員（member）。一個DBTG集合可以有任意數目的集合執行個體，一個集合執行個體可包含一個所有者記錄和多個成員記錄類型的記錄。

DBTG模型的實作技術充分利用了其模型對多對多關系的限制，通過為每個集合執行個體使用環結構，進而避免使用可變長度記錄。假設有如下3個記錄類型（如圖3-6所示）：

通過如下兩個鍊可以實作多對多關系：客戶購買鍊和商品出售鍊。客戶購買鍊将每個客戶與其購買記錄連結成一個環，而商品出售鍊将每個商品與其銷售記錄連結成一個環（如圖3-7所示）。

前面介紹的層次模型中的記錄類型可以組織成樹形結構，網狀模型中的記錄類型可組成圖結構。

3. 關系模型

20世紀60年代中期，研究者們開始不滿足于使用指針或者類似的方法實作實體之間的關聯，因為對于使用者而言，為了使用這些系統，他們需要了解這些關聯及其實作的細節，這種體驗是非常糟糕的。作為當時最令人矚目和最有動力研究這一難題的公司，在不同的時間和場合下，IBM有多位研究者提出了實體集合（Entity Set）或者類似的概念。也就是說，資料通過一組表來表示，一個表對應于一種類型的實體集，每個表的行對應于實體集中的單個實體，列則對應于實體集的屬性，行列交叉處對應某個實體的某個屬性的值。

實體之間的關聯也通過表來表示，這是最關鍵的改變，它統一了實體和實體關聯關系的表示方式。使用實體辨別符（ID）而不是指針或者其他硬體結構來表示實體關系，也為資料獨立性打下了基礎。

20世紀60年代後期，Ted Codd意識到可以用集合論來表示實體集，其中實體集為域（Domain）的集合D1，D2，…，Dn，每個域對應實體集的一個屬性。實體關聯也用類似的方法表示，每個域對應實體的辨別符。這奠定了關系模型的理論基礎。

使用關系模型，圖3-7中的客戶購買資訊可以用三張表表示：客戶表存儲客戶資訊，商品表存儲商品資訊，客戶購買商品表存儲客戶購買商品的資訊。如圖3-8所示。

關系模型與層次模型和網狀模型的最大差別是，記錄之間的關聯關系不再使用指針表示，而是通過記錄ID表示。另一個重大差別是，層次模型、網狀模型處理的基本單元是記錄，而關系模型處理的基本單元是記錄集合。

關系資料模型最常用的兩個通路方法（Access Method）是IBM的索引順序通路方法（Indexed Sequential Access Method，ISAM）和虛拟儲存通路方法（Virtual Storage Access Method，VSAM）。這兩種方法都同時支援随機通路和順序通路。ISAM是1966年作為OS/360的一個元件出現的，也是資料處理領域第一個廣泛使用的同時支援順序通路和随機通路的通路方法，它使用了DASD。VSAM是1972年提出的，它使用記錄分割政策解決了ISAM的長溢對外連結問題，此外也支援索引壓縮和索引複制。

4. 對象資料模型和關系對象模型

在關系模型之後，為了進一步抽象并适應程式設計語言的發展，提出了很多更複雜的模型，包括對象資料模型、對象關系模型、XML資料庫等。然而，這些資料模型随着時間的流逝，基本上已經淡出了大衆的視野。主要原因是這些模型過于複雜，其帶來的價值不足以補償實作的複雜性。關系模型則因簡單且有完備的理論支撐而經久不衰。

其中值得一提的是PostgreSQL。PostgreSQL官方稱其為最進階的對象關系資料庫，對象模型的概念在最新的版本中已經被淡化，其早期對象關系模型中保留至今仍有活力的是其抽象資料類型、自定義資料類型、自定義操作符和函數等。這為PostgreSQL的靈活性和可擴充性奠定了堅實的基礎。現在，鮮有使用者會提及PostgreSQL的面向對象的資料模型。

XML資料庫也曾風靡全球，然而，在圖靈獎獲得者Michael Stonebraker看來，這種資料庫隻不過是站在前人的腳趾而不是肩膀上的重複當年的網狀資料模型、期望解決卻未能解決問題。是以，XML資料庫隻是昙花一現就不足為奇了。

3.3.2　資料獨立性和進階資料處理語言

資料獨立性是早期資料庫系統追求的一個主要目标，它是指應用程式代碼和資料存儲結構、通路政策互相獨立。資料庫提供進階接口，使使用者可以處理資料，而不用考慮底層細節，例如二進制位、指針、數組、連結清單等。盡管底層還會使用這些基本資料結構來表示和處理資料，但資料庫可以選擇内部資料表示方法，并且可以改變這種存儲方式，而對使用者和應用完全透明。

早期處理資料的代碼内嵌在宿主程式設計語言中。宿主程式設計語言起源于通用資料處理例程，例如緩沖區處理、錯誤處理等。後來演變成I/O子例程工具包，之後又演變成I/O系統和通路方法（Access Method）。而DASD的出現大大擴充了這些通用操作工具的數量，包括空間配置設定、格式化、位址轉換、索引等。

随着資料庫管理系統的出現，通路方法（Access Method）接口被資料庫子語言取代，資料庫子語言比通路方法更強大，比如可以更新或者删除多個記錄，此外還可以執行資料庫獨有的操作，例如鎖和事務控制等。由于記憶體的限制一次無法處理過多的資料，為了處理大量記錄，有些資料庫子語言提供了遊标（Cursor）。

Edgar F. Codd提出的關系資料模型大大促進了資料獨立性的發展。他認為傳統資料庫主要存儲兩種資訊：1）資料庫記錄的内容；2）資料庫記錄之間的關系。不同的系統使用不同的方式存儲記錄之間的關系，例如links、sets、chains、parents等。

關系模型系統有三個重要的屬性：1）提供一個和底層實作無關的資料模型或者視圖，所有資訊都以資料值方式表示，不存儲任何連接配接資訊；2）系統提供進階語言執行資料處理操作，而不用關心其實作細節；3）進階語言以記錄集合為操作機關，一次處理多個記錄，而層次資料庫和網狀資料庫一次操作一個記錄。是以關系資料模型可以更好地解決資料獨立性問題。

正是有了資料獨立性，資料庫才能作為一個産品和使用資料庫的應用松散耦合在一起。資料庫産品可以不斷改進增加新功能，隻要提供向後相容的SQL支援，應用程式就可以直接在新版本上運作。另一方面，應用程式從資料存儲和通路方式上脫身而出，專注在業務邏輯上，将越來越多的業務建構在資料庫這一基礎軟體上，兩者互相促進。為了滿足來自應用的更好、更快地處理資料的需求，資料庫需要不斷改進更新，而每一次資料庫功能和性能的增強，又會帶動更多應用和更大規模的應用場景，推動資料庫技術進一步提升。

1. 關系模型及查詢語言

1970年，Edgar F. Codd發表了論文《A Relational Model of Data for Large Data Banks》。

在這篇論文中，他首次提出了關系模型，奠定了關系資料庫的理論基礎。這個模型通過一種簡單、進階的查詢語言通路資料。這種思維模式使得開發人員能夠一次對一個資料集執行操作，而不是像之前那樣一次操作一個記錄。

Codd在關系資料模型理論中提出了兩種關系查詢語言：一種是關系代數，一種是關系演算（Relational Calculus）。

假設有一張如圖3-9所示的員工表（Employee），我們希望從中找到“比老闆薪水高的員工”。

使用關系代數，查詢語言如圖3-10所示：

使用關系演算，查詢語言如下所示：

RANGE employee e;
RANGE employee m;
GET w(e.name):m((e.manager = m.name) ∧(e.salary > m.salary)           

2. SQL

SQL衍生自System R的資料庫子語言，這是對資料庫發展極為重要的一種進階語言。SQL來源于如下一些早期IBM對關系語言的研究。

• Alpha語言：嘗試使用過程語言代替關系演算。

假設有如下兩張表，從中找出學習課程Math的成績為A的所有學生。

Student (Number, Name)
Enroll (Course, Date, StuNum, Grade)           

如果用關系演算，則解決方法如下：

{x[Name]∈Student:
(y∈Enroll)    (y[Course] ="Math" &
                              y[Grade] = "A" &
                  y[StuNum] = x[Number]) }           

如果使用Alpha資料庫子語言，則解決方法為：

Range Student X
Range Enroll Y Some
Get W X.Name:
        Y((Y.Course = "Math") & (Y.Grade = "A") & (Y.StuNum = X.Number)           

這個Alpha語言程式傳回滿足條件的學生的名字，并用表W表示，宿主語言的語句可以通路并操作W。

• GAMMO-0：低級關系語言，試圖實作關系代數和查詢語言。
• SQUARE：使用圖形化方式，進而避免使用關系演算中的數學符号。
• SEQUEL：基于SQUARE，但是使用類自然語言。SEQUEL借鑒了已有查詢語言的某些結構，如GIS（GIS and File Management, J.H. Bryant，1966）的SELECT-FROM-WHERE，并擴充使之滿足關系完整性。很重要的一個突破是，它能夠支援子查詢。System R的SQL基于增強版的SEQUEL，在程式中使用SQL時，SQL語句可以使用宿主語言的變量。

1972年，在Edgar F. Codd組織的一個計算研讨會上，SQL的發明者Raymond Boyce和Donald Chamberlin接觸到了關系資料模型。他們發現，用幾行關系語言代碼就可以實作複雜的DBTG語言程式才能實作的功能，因而被Codd的關系語言的表達能力所震撼。不過，他們也感到該語言的門檻很高，需要具備一定的數學基礎才能駕馭。他們認為影響該語言流行的主要障礙有兩個：第一個障礙是普通鍵盤很難輸入數學符号。這個障礙比較容易解決，如使用“project”代替數學符号π；另一個更大的障礙來自語義級别，Codd的關系語言的基本概念來自于集合論和符号邏輯理論，普通使用者很難了解。于是在1973年，他們設計了一種類似自然語言的查詢語言，稱為SEQUEL。該語言流暢地描述了需要查詢什麼資訊，但是不涉及任何實作細節，是以SEQUEL是一種聲明式語言。1974年，他們發表了論文“SEQUEL: A Structured English Query Language”。之後，SEQUEL語言随着System R項目持續演進，根據早期使用者的回報，于1976年釋出了更完整的SEQUEL語言設計。1977年由于商标問題，SEQUEL改為SQL。

解決“比老闆薪水高的員工”這個問題的SQL查詢如下，可以看到，查詢語句非常簡潔易懂。

SELECT e.name
FROM employee e, employee m
WHERE e.manager = m.name AND e.salary > m.salary           

SQL的成功主要得益于關系模型的突破性創新，很好地抽象了使用者和存儲的資料之間的互動。此外，還有其他因素推動了SQL的發展：

• 從早期相關研究和實作中受益匪淺。
• 同時支援DDL和DML，為使用者提供了一個統一的接口來使用和管理資料庫，進而提高了應用開發人員的效率。
• SQL标準催生了一個完整的生态，不再被單個廠商鎖定。1986年，ANSI和ISO标準工作組定義了SQL的标準。此後，SQL釋出了多個後續标準版本，包括1992、1996、1999、2003、2006、2008、2016。經過多年的發展，SQL标準修正了最初版本中的不足，并增加了很多新的特性，包括外連接配接、表表達式、遞歸、觸發器、自定義類型和自定義函數、OLAP擴充、JSON等。

3.3.3　資料保護

資料保護方面兩個出色的早期産品是IMS和System R。IMS提供了資料一緻性保護，而System R則提供了更全面的資料保護措施，包括并發通路控制、故障恢複、資料恢複、權限管理等。很多經典資料庫書籍對這些内容進行了詳盡的分析，這裡不再贅述。

3.3.4　資料庫早期發展過程中的困境

資料庫技術的發展不是一蹴而就的，現在看似很自然的技術，當初也經曆了很多争論才持續發展起來。其中最大的争論來自關系模型和CODSYAL的DBTG模型，直到IBM釋出DB2後形成雙資料庫戰略（IMS和DB2），才終結了這場長達十年的争論。

20世紀60年代，資料庫技術初現，使用資料庫管理資料比使用檔案系統管理資料面臨更多挑戰：

• 由于需要消耗更多計算資源，資料庫系統比檔案系統處理速度慢；而當時硬體性能較弱，使得這個缺點更為明顯。
• 作為新生事物，資料庫系統的穩定性不如檔案系統。
• 相關技術人才匮乏。

這些挑戰在資料庫技術發展了近10年後才基本得到解決。

20世紀70年代出現的關系模型，雖然具有簡單靈活的優點，但在當時也經曆了很大的争論：

• 相比層次和網狀資料模型，關系模型需要更多的系統資源，因而速度更慢。
• 關系模型依賴優化技術生成高效查詢計劃，當時人們對優化技術能否實作期待的優化效果存疑。
• 作為新生事物，相關技術人才匮乏。

經過十多年的關系理論發展、原型疊代和産品打磨，到了20世紀80年代，随着Oracle、IBM等商業資料庫的成功，關系資料庫才真正發展起來。

但關系資料庫仍然存在很多問題，其中最突出的問題是資料模型不比對，也稱為阻抗不比對（Impedance Mismatch），是指關系資料模型和應用程式内部使用的資料結構不比對。關系資料模型使用表或者關系（Relation）和記錄或者元組（Tuple）組織資料，元組是一組名字-值對，關系是元組集合。這種資料模型優雅而簡潔，然而也有明顯的局限性—無法表示嵌套資料結構，而應用程式記憶體中的資料結構通常包含非常複雜的嵌套資料結構。為解決這個問題，必須在關系資料模型和應用記憶體資料結構之間進行雙向轉換，是以需要很多轉換代碼。對象關系映射（Object Relational Mapping）架構在一定程度上解決了這個問題，比較知名的架構包括Hibernate、iBATIS。

3.4　NoSQL資料庫

NoSQL一詞最早出現于1998年，用于命名一個輕量級關系資料庫。該資料庫使用文本檔案存儲資料，每個元組由制表鍵分割的字段組成，使用shell腳本通路資料，不支援SQL接口，但仍然是關系資料庫。2009年，NoSQL一詞出現于一個技術大會上，用于表示當時出現的大量非關系型分布式資料存儲系統，這也是目前NoSQL一詞的含義。然而，NoSQL一詞沒有廣為接受的官方定義，它在不同的場合被解釋為不同的意思，包括“No to SQL”“NOSQL/Not Only SQL”“No，SQL”等，現在廣泛使用的含義為Not Only SQL，即SQL資料庫的一種補充，而非替代關系資料庫。

3.4.1　NoSQL出現的背景

在新千年的第一個十年，資料處理領域最令人矚目的變化是各種NoSQL資料庫如雨後春筍般湧現，呈現出百花齊放、百家争鳴的局面。根據nosql-database.org在2018年的統計資料，共有超過225個NoSQL産品，這種情況的出現有鮮明的時代背景。

始于1969年的網際網路（Internet）改變了人類的方方面面，其影響仍然在進一步深化，甚至可以說其影響才剛剛開始。網際網路出現不久，電子郵件就成為深受人們喜愛的高效、便捷的溝通方式之一，電子布告闆（BBS）成為便捷的資訊釋出平台。1989誕生的網際網路（WWW）則徹底改變了資訊的連結方式。随後海量網站出現，資訊呈爆炸式增長，擷取資料變得非常容易，而從大量網絡資料中找到需要的資訊變得越來越困難，這催生了網際網路巨頭。Yahoo從黃頁起步快速成為流行的門戶網站，Google開始提供高品質搜尋服務。1999年出現、2004年開始流行的Web 2.0标志着網際網路進入新時代：使用者生成内容提高了服務的粘性，更好的互動性大大提高了使用者體驗，粘性和體驗的提升又進一步帶來更多的通路量和更長的通路時間。這個時期常用的服務包括社交平台、電商平台、網絡社群、部落格等。

快速增長的資料量給年輕的網際網路巨頭帶來了巨大的技術挑戰：現有的資料處理技術無法适應資料量的快速增長。傳統的企業（如銀行）也有大量的資料，但由于其核心業務是交易，是以他們可以通過控制資料量（特别是曆史資料量）使現有的資料處理技術能夠滿足其業務需求。對于網際網路公司，資料是核心資産，是以隻能努力前進，解決這些他人還未遇到的難題，而不能退縮。網際網路公司面臨兩種選擇：垂直擴充（Scale Up）或者水準擴充（Scale Out）。垂直擴充指采購功能更強大的機器解決問題，這也意味着要有更大的資金投入，且這種投入增長不是線性的，另外，垂直擴充總是有上限的。是以，很多網際網路公司采用水準擴充的方案，通過購買更多的商用硬體組建叢集來解決擴充問題。

水準擴充方案也帶來了一個新的問題：雖然從20世紀80年代開始，學術界和企業界就對分布式資料庫進行研究和開發，但當時還沒有可以很好地支援叢集的商用事務型關系資料庫。Oracle RAC和微軟的SQL Server雖然支援叢集，但仍然基于共享磁盤，擴充能力有限。這種關系資料庫和分布式叢集的不比對，使得網際網路巨頭和大企業不得不考慮其他存儲方案。早期的嘗試之一是使用基于中間件的方案，包括eBay的基于Oracle的叢集和谷歌的基于MySQL的叢集。中間件方案的底層大多使用某種關系資料庫，而關系資料庫自身的特性（如ACID）限制了性能和可用性，使用關系資料庫做底層存儲代價過高。于是，某些公司開始嘗試改變這一狀況，很多新技術和産品應運而生。這些新産品放棄了ACID、模式（Schema）和跨節點關聯等關鍵SQL特性，以獲得對海量資料的高速處理能力、高擴充性和高可用性等。谷歌于2003年發表了GFS論文、2004年發表了MapReduce論文、2006年發表了BigTable論文；亞馬遜于2007年發表了Dynamo論文；雅虎于2006年開源了Hadoop；Facebook于2008年開源了Cassandra。這些研究和技術為NoSQL的發展奠定了良好的基礎。其他很多知名NoSQL産品也是在這一時期開始研發或者釋出的，包括CouchDB（2005）、MongoDB（2007）、Hypertable（2008）、Cassandra（2008）、Redis（2009）、MongoDB（2009）、ElasticSearch（2010）等。

NoSQL是一次由開發人員主導的技術趨勢。大型網際網路公司在發展過程中吸引了大量優秀人才，積蓄了強大的技術實力，具備開發新型系統的能力。同時，來自業務的需求給他們帶來了開發新型系統的動力。開發全新系統是機遇也是挑戰。很多系統的開發者希望借此機會解決長期困擾開發效率的某些問題，其中之一就是資料處理領域自關系模型出現以來就存在的對象和關系模型不比對（Object Relational Impedance Mismatch）問題。存儲和處理資料的關系模型本質上是一個扁平的二維資料結構，不支援靈活的嵌套，而程式設計語言在記憶體中的資料結構通常是具有多級嵌套的結構體或者對象。這種記憶體和外存資料模型的不比對使得開發人員不得不實作大量煩瑣的代碼進行轉換，不但影響開發效率，而且容易出錯。另一個問題是修改應用資料結構之前通常需要修改資料庫的模式，這在需要頻繁更新資料結構的場景下非常不友善。

圖3-11顯示了這種内外存資料模型不比對的問題，左邊是記憶體中的資料結構，右邊是資料庫中的存儲結構，記憶體中的資料結構是嵌套型，而關系資料庫的資料模型是扁平的。很多NoSQL産品解決或避免了這個問題，如文檔資料庫使用支援嵌套的JSON格式存儲資料，而鍵值資料庫則忽略資料的内部格式，把記憶體中的資料序列化為二進制串存儲，讀取的時候再進行反序列化。

3.4.2　NoSQL産品的共性

NoSQL産品數量衆多，出現時機和原因各不相同，應用場景也多種多樣，但這些産品之間存在一些共性。

1）顧名思義，NoSQL資料庫（開始時）不提供SQL接口。某些NoSQL資料庫提供了類SQL接口，然而都沒有達到SQL标準的能力。

2）叢集基因。NoSQL資料庫大多具備良好的叢集管理能力，有的NoSQL最初就是為叢集而設計，因而具備很好的線性擴充性和高可用性。

3）追求高性能和高吞吐量。NoSQL資料庫大多以追求高性能、高吞吐量和高可用性為目标，因而放棄了某些關系資料庫的特性，如事務、強一緻性、關聯（JOIN）等。

4）NoSQL資料庫的資料模型都是非關系型的，常見的資料模型有鍵值、列族、文檔類型和圖類型。

5）NoSQL資料庫不使用模式（Schemaless）或者使用靈活的模式。是以，NoSQL資料庫不需要事先設計完善的模式即可操作資料，并允許動态添加新資料類型或者修改已有資料類型。這為程式設計人員提供了很大的靈活性和便利性。然而，通路資料必須知道其模式，否則資料就是0和1組成的一堆無意義的二進制字元，是以需要有隐式模式，即對所存儲資料的結構和類型的假設。這些隐式模式通常隐藏在應用代碼中，NoSQL資料庫本身不用關心，資料的使用者仍然需要了解這些隐式模式才能操作資料，所謂的無模式資料庫不過是把模式從資料庫移到了應用程式内部。

6）大多數NoSQL資料庫以不同協定開放源代碼。

3.4.3　NoSQL的分類

NoSQL資料庫根據資料模式的不同分為四種類型：鍵值資料庫、文檔型資料庫、列族型資料庫和圖資料庫。

1. 鍵值資料庫

鍵值資料庫以鍵/值對形式存儲資料，鍵必須唯一，這和哈希表的存儲/操作方式類似。主鍵對應的值可以是任意二進制資料（包括文本資料），NoSQL資料庫不知道資料内部細節，應用程式負責解析其語義。應用程式設計接口非常簡單，支援讀、寫和删除鍵值對。有些鍵值資料庫支援主鍵排序和範圍（Range）操作。鍵值資料庫性能出色，擴充性很好。流行的鍵值資料庫包括Riak、Redis（由于可以存儲集合、清單等，也稱為資料結構伺服器）、Memcached等。

2. 文檔型資料庫

文檔型資料庫的核心資料模型是文檔（半結構化資料），以鍵/文檔對存儲。文檔可以是XML、JSON、BSON等格式。文檔多為樹形結構，可以包含數組、子文檔等。不同的文檔可以有不同的字段，相同的字段可以有不同的資料類型。和鍵值資料庫相比，文檔内容對資料庫可見，因而支援對文檔的特定字段建立索引以實作高效檢索。常見的文檔型資料庫包括MongoDB、CouchDB等。

3. 列族型資料庫

列族型（Column-family）資料庫支援定義多個列族，每個列族内允許定義可變數量的列，支援動态定義新列。通常将邏輯上相關、經常同時通路的資料放在一個列族内。和關系資料模型相比，可以把列族看成關系模型的一個列，列對應的值是一個複雜結構。常見的列族型資料庫有Cassandra、HBase、Hypertable等。

4. 圖資料庫

圖資料庫支援非常靈活的實體關系，實體稱為頂點，實體間的關系稱為邊。在圖資料庫中，邊是内嵌的概念。常見的圖資料庫有Neo4J、OrientDB等。

3.5　SQL資料庫的回歸

3.5.1　NoSQL與SQL的融合

2017年，谷歌發表了一篇名為《Spanner: Becoming a SQL System》的論文，引發了關于SQL回歸的熱議。

圖靈獎得主Michael Stonebraker和David J. DeWitt早在2008年就曾指出MapReduce是技術倒退。他們認為，MapReduce的基本思路很簡單，開發人員隻需實作兩類函數：map函數和reduce函數。map函數對輸入記錄執行過濾或變形處理，通過split函數（通常是哈希）将map的結果分成多個分區，每個分區對應一個檔案，具有相同split結果的記錄都在同一個檔案中；reduce函數對map的結果進行進一步處理，結果也以檔案方式儲存。MapReduce架構會自動并行運作這些程式進行計算。若用SQL術語類比，map類似于聚集語句的group-by；而reduce類似于聚集函數，對每個分組的所有元組進行聚集計算。他們指出：

• 作為一種資料處理模式，MapReduce是一種倒退。自1968年IBM釋出IMS後的40年裡，資料庫社群吸取了三個教訓：1）模式（Schema）很有價值，它描述了資料的元資訊，防止垃圾資料污染資料集，沒有模式的資料是沒有意義的1和0的數字串，很快會變成垃圾；2）從應用程式中抽離出模式很好，資料是符合模式的高品質資料，可以在不同應用間共享，否則資料會變成單個應用的私有資料；3）進階通路語言很有價值，20世紀70年代關系陣營和CODASYL陣營就曾因為是否使用進階語言進行過長達數年的辯論，最終CODASYL淡出了視野。使用進階語言可以友善地描述要做什麼而不是怎麼做，程式易于實作、易于修改，也易于了解和維護。MapReduce丢掉了這些經驗，是以倒退到了20世紀60年代。
• MapReduce是次優實作。資料庫社群從20世紀60年代就支援不同的資料通路方法（Access Method），包括基于索引的方式和順序掃描方式，優化器可以根據代價選擇最佳路徑。MapReduce僅僅支援順序掃描。作為一個并行執行引擎，MapReduce也過于簡單，如不能處理資料傾斜、基于檔案的資料交換效率低下等。
• MapReduce本身也不是資料處理新模式，20年前就有大量關于高效并行處理大資料集的研究和商業實作，很多開源或者商業資料庫也支援使用者自定義類似map或者reduce的函數。
• MapReduce無法支援很多資料庫管理系統提供的特性，包括高速加載、索引、更新、事務、完整性限制、參照完整性和視圖等。
• MapReduce和廣為使用的工具不相容，如報表工具、BI工具、資料挖掘工具等。

當時，這些觀點受到了MapReduce擁護者的反對。但十年之後的2018年，事實證明他們的觀點是有道理的。

大量開發人員群組織最初采用各種NoSQL産品時，體驗到了其優勢。然而，随着時間推移，他們開始發現其中存在的問題，包括NoSQL的首倡者谷歌。（實際上，所有問題都是50年前在資料處理進入電子資料處理時代就已經深入讨論和研究過的。）這些問題包括：

• 不支援SQL，計算遠離資料，開發人員需要自己實作複雜的代碼并進行聚集分析等。
• 使用低級查詢語言，資料實體獨立性和邏輯獨立性差、靈活性差、維護代價高。
• 不支援ACID和事務，開發人員需要自己寫代碼處理資料不一緻造成的問題。
• 不支援關聯，隻能使用寬表，會引起資料備援，維護代價高。
• 缺少标準接口，學習代價高、應用使用代價高，需要大量的膠水代碼和轉換代碼。
• 多種NoSQL産品的引入導緻資料整合代價高。
• 缺少生态，從資料遷移、ETL、報表、BI到可視化都要從頭開發，難以進行資料分析。
• 人才缺乏，企業積累的大量SQL人才和資産無用武之地，造成浪費。

盡管如此，NoSQL産品仍然繼續演進，其中一個趨勢是支援更多關系資料庫的優秀特性，如SQL标準。目前Apache社群有多個SQL-on-Hadoop項目，包括HAWQ、Impala、Presto等。此外，Kafka也開始提供SQL接口KSQL。

傳統的關系資料庫也開始支援越來越多的NoSQL特性，如2012年釋出的PostgreSQL 9.2開始支援JSON。

由于NoSQL開始提供更多SQL特性，SQL資料庫也開始支援更多NoSQL特性，NoSQL

與SQL的融合越來越深入。

3.5.2　Hadoop不等于大資料

過去，很多人認為Hadoop =大資料，一談大資料必談Hadoop。然而，這是一種誤解。

Gartner在2015年釋出報告《Survey Analysis: Hadoop Adoption Drivers and Challenges》，

該報告指出：盡管Hadoop被大量炒作，并有早期采用者的成功案例，但超過一半的受訪者目前沒有計劃投資。此外，隻有18％的使用者計劃在未來兩年内投資Hadoop。

Gartner在2017年釋出的資料管理産品周期圖（如圖3-12所示）中指出，Hadoop發行版在達到生産高峰期前已經過時。整個Hadoop技術棧的複雜性和可用性令許多組織重新考慮其在資訊基礎架構中的角色。

谷歌的發展經曆也說明，SQL資料庫更适合作為大資料的基礎處理平台。這對很多組織都具有借鑒意義。

3.5.3　SQL從未離開

如前文所述，NoSQL出現和發展的主要推動力來自大資料引起的叢集化需求和希望通過線性擴充能力獲得更高的性能和可用性的需求。分布式、叢集式SQL資料庫的研究可以追溯到20世紀80年代中期，當時有多個組織和公司開始了分布式并行資料庫的研發，包括Gamma、Teradata、Bubba和Tandem等。Teradata至今仍然是資料倉庫市場的主力軍之一。

目前主流的分布式SQL和NoSQL資料庫都采用無共享架構（Shared-Nothing），威斯康星大學1984年啟動的Gamma資料庫項目首先提出了該架構。該項目研究人員1990年在IEEE上發表論文《The Gamma Database Machine Project》，其中詳細介紹了設計和評測報告。其中提到的無共享架構、分布表（原文是Partitioned Table，Partition一詞後來多用于表示單機上的分區表，如根據日期分區，因而此處使用分布表一詞）、副本、Interconnect、資料流（Dataf?low）、哈希關聯（Hash Join）等至今仍是很多分布式資料庫系統的核心。

2000年後，在NoSQL流行前夕，一批新的分布式資料庫廠商湧現出來。和NoSQL資料庫放棄SQL和事務等技術方向不同，這些廠商實作了支援SQL、事務、ACID等特性的分布式大資料處理系統，主要以聯機分析處理（OLAP）場景為主，包括2003年釋出的Netezza、2005年釋出的Greenplum（當時叫Bizgres，其Postgres基因一看便知）、2005年成立的Vertica、2008年提出的SAP HANA（HANA的早期前身系統更早）等。

針對聯機事務處理（OLTP）業務的分布式SQL資料庫系統也開始浮現。2007年提出的H-Store便是這種系統。作為一個學術型資料庫，其開發團隊成員來自于布朗大學、卡内基·梅隆大學、麻省理工學院和耶魯大學，系統設計由Michael Stonebraker、Sam Madden、Andy Pavlo和Daniel Abadi操刀，陣容堪稱豪華。H-Store的架構和傳統RDMBS架構差別很大，它基于記憶體、隻有undo沒有redo日志且undo日志不落盤、單線程處理、不使用行級鎖和latch等。然而，這種系統也有其限制，如需要預先對事務進行分類和編譯、不支援互動式事務等。基于H-Store的商業公司VoltDB于2010年成立，提供企業級産品和服務。其他類似的産品還有ClustrixDB、CockroachDB等。

3.6　內建資料處理和分析平台

使用者對資料整合的需求在20世紀60年代造就了資料庫，進入21世紀的第二個十年，資料整合需求再現其強大的影響力，這次将催生內建資料處理和分析平台。

3.6.1　資料類型

早期資料庫主要面對業務資料處理（Business Data Processing）場景。這種場景下的資料具有良好的結構，資料類型以定長數值類型和定長字元串為主。随着業務的發展，逐漸産生了對非結構化資料的處理需求。

最早的非結構化資料為可變長度文本資料。盡管SQL标準支援LIKE操作符，但是其性能很差。十年前常用的方案為，應用程式內建資料庫和文字檢索兩類産品：應用資料存儲到資料庫，文本資料存儲到Solr或ElasticSearch之類的文字檢索伺服器上，儲存資料時将其中的文本資料定期或者實時地發送給文字檢索伺服器建立索引，查詢時則需要在應用中對兩種系統的查詢結果進行關聯處理。這種方式複雜、易錯、性能不高、資料獨立性差。

為了解決這個問題，很多資料庫（例如Oracle、PostgreSQL）實作了文字檢索産品中常用的反向索引技術，大大提高了文字檢索的效率。近幾年，有些資料庫開始支援一些進階的文字檢索特性，如PostgreSQL支援停用詞、短語搜尋、多種詞幹庫和高亮顯示等。Greenplum的GPText産品元件則整合了Greenplum MPP資料庫的特性和Solr豐富的文字檢索特性，應用程式使用标準的SQL（而不用寫代碼）即可對文本資料進行高效的索引和查詢，并且支援關聯（JOIN）。

另一種常見的非結構化資料是地理空間資料。該領域知名的産品之一是ArcGIS。其早期産品使用shapef?ile格式的檔案儲存資料，後來改用稱為geodatabase的對象關系型資料庫存儲空間資料，這是一種專為空間資料而優化的資料庫。傳統的關系型資料庫也開始支援地理空間資料處理，如PostgreSQL的PostGIS擴充提供了非常強大的空間資料處理能力，支援點、線、面等基本要素，支援幾何地理資料、經緯度資料、栅格資料和拓撲資料等，支援索引，還提供了200多個空間資料處理函數。此外，文字檢索産品Solr和Elasticsearch等也支援地理空間資料處理。

自20世紀60年代後期至今，工業界和學術界一直在研究如何支援嵌套資料或半結構化資料，包括層級資料、網狀資料、對象資料、XML和JSON等。XML資料庫一度是最熱門的研究課題。然而，基于XML資料模型的資料庫沒有普及，最終變成了關系資料模型的一種資料類型。基于JSON的文檔資料庫（例如MongoDB）是最受開發人員歡迎的NoSQL資料庫之一。JSON作為資料互動格式和資料存儲格式逐漸流行後，關系資料庫也開始支援JSON作為一種資料類型，使得開發人員不但可以享受關系資料庫的所有優勢，還能利用JSON這種半結構化資料結構的靈活性。如，PostgreSQL 9.2開始支援JSON資料格式，2014年釋出的9.4引入了增強型的JSONB，功能更強大、效率更高。

資料庫還在持續加入更多的資料類型，如圖（Graph）資料、多媒體資料等。Oracle 12c包括了對地理空間資料、圖資料和多媒體資料的支援。

與此同時，使用者開始厭倦為不同的資料處理采用不同的資料處理系統，更傾向于采用內建資料處理平台來處理企業的各種資料類型，包括結構化資料、半結構化（JSON、XML等）資料、文本資料、地理空間資料、圖資料、音視訊資料等。

3.6.2　業務場景

目前，資料庫市場主要的兩種應用場景為聯機事務處理（OLTP）和聯機分析處理（OLAP）。聯機事務處理場景下，隻查詢處理少量資料，時間很短；在聯機分析處理場景下，要查詢處理大量資料，以讀為主，通常時間較長，從幾分鐘到幾個小時不等。為應對這兩種不同的場景，需要使用兩種不同的資料庫産品。企業通常使用OLTP資料庫支撐交易型業務；使用ETL（抽取、轉換、加載）工具将事務型資料庫的資料導入OLAP資料庫進行商務智能分析，再根據分析後的結果調整交易業務。

2014年，Gartner的一份報告中使用混合事務分析處理（HTAP）一詞描述新型的應用程式架構，以打破OLTP和OLAP之間的隔閡，實作實時業務決策。這種架構具備顯而易見的優勢：不但避免了煩瑣且昂貴的ETL操作，而且可以更快地對最新資料進行分析。這種快速分析資料的能力将成為未來企業的核心競争力之一。

移動網際網路、物聯網和傳感器的發展導緻大量的流式資料産生，相應地出現了專有的流式資料處理平台，如Apache Storm、Apache Kafka等。近年來，很多資料庫開始支援流式資料處理，如MemSQL、PipelineDB。有些專有流式資料處理平台開始提供SQL接口，如KSQL基于Kafka提供了流式SQL處理引擎。

傳統的進階資料分析工作使用SAS之類的專業産品完成。這些産品通常需要從資料庫或者其他資料存儲系統中讀取資料，然後進行計算（資料貼近計算）。這種方式效率不高，而且由于記憶體的限制，資料量大時隻能使用采樣資料，準确度較低。為了解決這個問題，有些資料庫内建了機器學習、統計分析和模式識别等算法庫，可以在資料庫内對存儲的資料進行高效的全量資料分析。例如，Greenplum資料庫的MADlib元件提供了超過50種資料分析算法，包括回歸、神經網絡、支援向量機、決策樹、主題模組化、聚類、PageRank和最短路徑等算法。

3.6.3　集中還是分散

Michael Stonebraker認為，單個資料庫不能處理各種應用場景（one size does not f?it all），不同的場景應該使用不同的資料處理技術。他指出，聯機分析處理、文本處理、流資料處理、科學計算等具有不同的特點，專有系統的性能将比通用系統性能高一到兩個數量級，因而不同的業務應采用不同的系統，類似圖3-13所示（他在一篇文章中提到，OLTP、OLAP和其他場景市場佔有率大約各占1/3，“其他”部分包含很多細分領域，由于場景差别很大，每種場景需要專有的系統）。

就目前的使用者需求和軟硬體技術發展狀況來看，內建資料平台将能滿足絕大多數使用者的場景，隻有極少數企業需要使用專有系統以實作其特殊的需求。比如，PostgeSQL的性能在使用英特爾至強處理器E7-8890的單機系統上可達百萬TPS（Transaction Per Second，每秒事務處理量），盡管某些專為OLTP優化的記憶體資料庫可能達到更快的TPS，然而有如此大業務量的公司非常少。大多數使用者将采用內建資料平台，如圖3-14所示。

內建資料平台有以下優勢：

• 通過資料整合避免資訊孤島，便于共享和統一資料管理。
• 基于SQL的資料內建平台可提供良好的資料獨立性，使應用能專注于業務邏輯，不用關心資料的底層操作細節。
• 內建資料平台能提供更好的實時性和更全的資料，為業務提供更快更準的分析和決策。
• 能夠避免各種系統之間的膠合，企業總體技術架構簡單，不需要複雜的資料導入/導出等，易于管理和維護。
• 便于人才培養和知識共享，無須為各種專有系統培養開發、運維和管理人才。

內建資料平台也有其不足之處：

• 性能比專有系統遜色。
• 內建資料平台多是分布式資料庫系統，出現問題時，分析原因較複雜。
• 資料集中存儲和處理，權限管理複雜。

古人說“天下大勢，分久必合、合久必分”，這句話用在資料處理領域也不為過。需求和技術是一對沖突，當這對沖突緩和時，資料處理領域将更趨向于整合；而當這對沖突尖銳時，資料處理領域将趨于分散。就軟硬體技術發展現狀和目前需求來看，未來整合的趨勢更為明顯。

3.7　資料平台的選型

前面我們介紹了資料平台的演進曆程和發展趨勢，了解其發展過程和趨勢可以幫助我們更好地選擇适合自身的資料平台。

選型時首先需弄清楚企業自身的業務需求和未來的發展趨勢，避免殺雞用牛刀或者螞蟻撼大象的情況。之後，對候選資料平台進行多元度考量。下面從技術角度列出一些大資料處理平台選型的因素或原則以供參考。

• 産品成熟度：成熟的産品可以避免使用者走彎路，避免企業做小白鼠、浪費各種資源和時間。衡量一個産品的成熟度可以參考其付費企業級客戶的數量和體量。通常，經曆過金融等高壓/高要求行業核心業務驗證的産品，其成熟度更可靠。另一個參考名額是産品在本行業内的普及度。
• 開發和運維的複雜度：開發和運維在整個大資料平台生命周期中占有很大的比重，其投入通常大于初期産品采購的投入。大資料處理平台越大，這一趨勢越明顯。對于開發人員而言，寫SQL等類自然語言通常比寫分布式Java、Python代碼更快、更易維護。對于運維人員而言，良好的監控和管理工具必不可少。此外，自動化智能運維工具開始出現，也越來越有吸引力。
• 标準相容度：SQL标準逐漸成為大資料系統的主要标準之一。SQL标準有很多版本，對不同SQL版本的相容度是衡量大資料系統的一個重要名額。很多大資料系統支援一些簡單的SQL，但不支援很多進階SQL特性，如跨節點關聯查詢、子查詢、視窗函數、資料立方格（CUBE）、通用表表達式（Common Table Expression，CTE）等。如果系統不支援這些特性，應用開發人員隻能自己實作，既費時費力，又不利于重用和維護。良好的标準相容度也可以降低資料和産品遷移的代價。
• 核心技術特性：列出平台支援的核心技術特性，根據自身需求進行評估。對于一個大資料處理系統，可以考量其ACID支援能力、資料水準分布能力、并行查詢執行能力、查詢優化能力、線性擴充能力、多态存儲能力、資源管理能力、資料加載能力等。
• 跨硬體平台：是指大資料系統可以運作在各種硬體平台之上，不管是裸機、私有雲、公有雲還是容器環境。由于不受限于硬體環境和平台，使用者便可以保留選擇适合自己的硬體環境的權利，未來的遷移代價低，開發和運維人員不需要學習新的資料庫處理技術。硬體環境的普适性可以避免硬體平台的制約和鎖定，為客戶解決後顧之憂。
• 開放源代碼：開源意味着透明，使用者可以了解甚至評估代碼風格、代碼品質、代碼稽核嚴謹度、開發人員的素質、項目進度、合作方式、社群活躍度等各個方面。了解這些細節比僅僅聽取銷售的推銷而購買一張刻錄了代碼的CD光牒更讓人有信心。此外，采用開源方案，不用擔心後門問題，也不用擔心被鎖定。優秀的開源産品更容易吸納新使用者，進而促進開源項目的發展。相對于封閉系統，圍繞開源系統進行開發更容易，同時有利于建構更好的生态。
• 完善生态系統：完善的生态一方面可以降低使用者端到端的部署代價，另一方面有助于生态内的各個産品的健康發展。
• 資料源和資料格式：如果企業群組織内部存在多種資料源和資料格式，則應考慮選擇支援這些資料源和資料格式的大資料平台。常見的資料源包括各種關系資料庫、Kafka、ElasticSearch、Redis、MongoDB、Hadoop、HIVE、HBase、S3、檔案等。常見的資料格式包括結構化資料、半結構化（XML、JSON、KV等）資料、非結構化資料（文本資料、GIS資料、圖資料等）。
• 進階分析能力：如果項目有進階資料分析或者機器學習的需求，則優先考慮内建了進階資料分析和機器學習能力的平台。通過内建進階分析算法到平台之中，而不是抽取資料到業務應用或者第三方應用中再作分析，可以大大簡化業務的複雜度，提高開發效率，同時提高分析模型精度。從基于大資料的高階數字化戰略（詳見第2章）高度出發，内建的進階分析能力更為重要。
• 擴充能力：當産品提供的特性不能滿足使用者的特定需求時，則要對産品進行擴充，可擴充性是具有此類需求的使用者考慮的一個因素。建立了基于大資料的高階數字化戰略的企業對平台擴充能力要求更高。

在資料經濟時代，資料處理和分析的能力與效率是企業的核心競争力，是以選擇合适的內建平台至關重要。讀者可以參考以上方面選擇出适合自己的大資料處理基礎平台。

經過15年的發展，Greenplum在以上各個方面做了非常精心的考量，成為一款值得信賴的大資料處理基礎平台。後面各章将會對Greenplum進行詳細的介紹。

3.8　小結

本章以資料處理平台的演進曆史和未來趨勢為主題，着重介紹了三次整合的背景及影響：

• 機器整合：第一次資料處理的大整合是硬體上的整合。在電子計算機出現之前，企業使用各種專用機器實作不同目的的資料處理，如使用加法機進行算術計算、使用制表機生成報表等。電子計算機出現後，電子資料處理（EDP）逐漸取代之前使用的各種專用機器，實作了硬體上的整合。
• 資料整合：第二次資料處理的大整合是資料的整合。在資料庫出現之前，各個應用程式存儲和管理各自的資料，造成資料共享困難和資料獨立性差等問題。資料庫實作了資料的整合，各個應用程式通過資料庫存儲和通路資料，解決了資料共享和獨立性的問題。
• 處理整合：第三次資料處理的大整合是處理的整合，其結果是內建資料處理和分析平台。在資料平台出現之前，企業為不同的場景使用不同類型的資料庫，造成了資料孤島。資料平台将提供內建資料處理和分析能力，滿足不同場景的需求，避免資料孤島及其帶來的各種問題。

現在，第三次整合快速發展。我們正處于這一整合的關鍵發展階段，湧現出很多新産品。企業決策者應考慮各種影響因素以選擇适合自己的平台。

進一步閱讀

為了更好地了解本章内容，推薦有興趣的讀者進一步閱讀以下書籍、論文或網上資源。

• A History and Evaluation of System R，作者Donald D. Chamberlin等。
• A General-Purpose File System For Secondary Storage，參見 http://www.multicians.org/fjcc4.html 。
• A Study of SQL-on-Hadoop Systems，作者Yueguo Chen等。
• Batch Processing，參見 https://en.wikipedia.org/wiki/Batch_processing
• Computer File，參見 https://en.wikipedia.org/wiki/Computer_file
• Data，參見 https://en.wikipedia.org/wiki/Data
• Data Base Technology，參見 https://dl.acm.org/citation.cfm?id=1664865
• Data processing，參見 https://en.wikipedia.org/wiki/Data_processing
• Data Processing Technology and Accounting: A Historical Perspective，作者Robert Kee。
• Database，參見 https://en.wikipedia.org/wiki/Database
• Database System Concepts（第6版），作者Avi Silberschatz、Henry F. Korth、S. Sudarshan。
• Early History of SQL，作者Donald D. Chamberlin。
• Jim Gray at IBM The Transaction Processing Revolution，作者Bruce G. Lindsay。
• File system，參見 https://en.wikipedia.org/wiki/File_system
• History of Operating systems，參見 https://en.wikipedia.org/wiki/History_of_operating_systems
• H-Store: A High-Performance, Distributed Main Memory Transaction Processing System。
• IMS Then and Today。
• Ingres: Can you Ever Go Back?，參見 https://kellblog.com/2006/04/08/ingres-can-you-ever-go-back/
• MapReduce: A major step backwards，作者David J. DeWitt and Michael Stonebraker，參見 https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html
• Multics（Multiplexed information and computing service），參見 https://en.wikipedia.org/wiki/Multics
• NoSQL，參見 https://en.wikipedia.org/wiki/NoSQL
• NoSQL Distilled: A brief guide to the emerging world of polyglot persistence，作者Pramod J. Sadalage, Martin Fowler。
• NoSQL for Mere Mortals，作者Dan Sullivan。
• OLTP Through the Looking Glass, and What We Found There，作者Stavros Harizo-poulos等。
• “One Size Fits All”: An Idea Whose Time Has Come and Gone。
• Organization and Retrieval of Records Generated in a Large-Scale Engineering Project，參見 https://www.computer.org/csdl/proceedings/af?ips/1958/5053/00/50530059-abs.html
• PostgreSQL Scalability: Towards Millions TPS，參見 http://akorotkov.github.io/blog/2016/05/09/scalability-towards-millions-tps/
• Readings in Database Systems（5th Edition），參見 http://www.redbook.io/
• Relational databases and beyond，作者MF Worboys。
• Software in the 1960s as Concept, Service, and Product，作者Thomas Haigh。
• Spanner: Becoming a SQL System，作者David F. Bacon、Andrew Fikes等。
• System R: Relational Approach to Database Management。
• The Commercialization of Database Management Systems，1969-1983。
• The Design and Implementation of INGRES。
• The Design of Postgres。
• The end of an architectural era，作者Michael Stonebraker等。
• The evolution of the filesystems，參見 http://cs-exhibitions.uni-klu.ac.at/index.php?id=188
• The Gamma Database Machine Project, DeWitt, et. al., IEEE Transactions on Knowledge and Data Engineering, Vol. 2, No. 1, March 1990。
• The U.S. Software Industry: An Analysis and Interpretive History W.Edward Steinmueller。
• https://royal.pingdom.com/2008/04/08/the-history-of-computer-data-storage-in-pictures/
• The History of Storage Systems，作者Kazuo Goda, Masaru Kitsuregawa。
• The History of The History of Software，作者Martin Campbell-Kelly。
• Timeline of operating systems，參見 https://en.wikipedia.org/wiki/Timeline_of_operating_systems
• Tutorial: SQL-on-Hadoop Systems，作者Daniel Abadi等。
• What Goes Around Comes Around，作者Michael Stonebraker, Joseph M. Hellerstein。
• What’s Really New with NewSQL?，作者Andrew Pavlo, Matthew Aslett。