1.2 大數據

云計算是個概念清晰的新技術，相比之下，大數據則是在量變到質變的過程中突然火爆起來的。大數據可以看作是一系列技術和商業實踐的集合，因此業界對于大數據的定義可謂豐富。如同在《Cloud Foundry：從數字化戰略到實現》一書中解讀云計算那樣，作者仍將通過剖析技術背后產業變遷的驅動力的方式來解讀大數據。

知名咨詢公司Gartner指出，數字宇宙在不斷膨脹。谷歌首席經濟學家范里安也指出：“從人類文明誕生到2003年，一共創造了5ET的數據，而現在幾乎每兩天就能創造這么多數據?！?img alt="來源：https://www.eetimes.com/author.asp?doc_id=1330462。" class="qqreader-footnote" src="https://epubservercos.yuewen.com/F7CF49/14571070005927006/epubprivate/OEBPS/Images/note.png?sign=1755221061-06kcuNNxHS9g1Q8pNOmIKZ0nk13UTQi1-0-04fb25c2e59f6f58ae23a33ad3e443a7">早在2012年，作者和易安信（EMC）聯邦的大數據產品領導人討論PC時代如何向云計算時代跨越時，就談及大數據產業發展趨勢以及我們應該建立怎樣的技術。

1.2.1 從CRUD到CRAP

在PC時代，計算機主要用于流程的自動化，因為在流程的各個環節都會產生大量事務（Transaction），計算機的數據系統主要用于對這些事務記錄進行操作。假設我們要為一所學校創建一個學生管理系統。當一個學生被錄取，系統就需要記錄這樣一個事務，為此需要創建（Create）一條學生記錄，記錄學生的一些信息，例如身份證號、性別、年齡、籍貫和錄取分數等。當該名學生到學校報到的時候，我們可能需要更新（Update）相關的記錄（比如，學籍管理字段用于記錄學生報到時間，此時就需要把這條字段更新到最新的報到日期）。如果報到后有人獲得授權查詢該學生的錄取分數，則可以從數據庫系統中獲取（Retrieve）該學生的記錄。因為系統的存儲容量有限，所以當系統飽和的時候，就會刪除（Delete）一些過去的記錄。簡言之，記錄的上述操作可歸結為創建（Create）、獲?。≧etrieve）、更新（Update）和刪除（Delete）的組合，取英文首字母的縮寫叫作CRUD。關系數據庫管理系統（RDBMS）的關鍵就是保證事務操作的原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability），取四個英文單詞的首字母叫作ACID屬性（我們會在后面詳細介紹ACID屬性）。目前，讀者只要記住ACID是保證記錄的CRUD操作不出現任何錯誤的重要性質即可。這個工作聽上去容易，但考慮到多個用戶產生的事務同時操作一條記錄，以及像銀行這樣要確保任何一筆事務都實現零差錯（不然用戶賬戶余額可能出現差錯）的情況，事情就不那么簡單了。Oracle數據庫、IBM的DB2數據庫和微軟的SQL Server數據庫就是靠卓越的ACID能力成為PC時代偉大的產品。

隨著數據記錄的數量與日俱增，一些企業開始對歷史記錄進行數據挖掘，以獲取有價值的信息。比如，美國的學校非常關心自己的生源和學生就業之間的關系。如果說GRE分數越高的學生就業越好，那么是否應該提高錄取的GRE分數？反之，是否可以在錄取條件中降低GRE的錄取分數？這些帶著預設問題的報表操作就叫作商業智能（Business Intelligence, BI），它其實和人工智能開始接近。在BI上嘗到甜頭的企業，在清理事務數據系統的記錄的時候會把它們導入到另外一個叫作數據倉庫（Data Warehousing）的數據管理系統，以備后續BI操作之用。此外，如果在事務數據系統中運行BI操作，會導致事務數據系統性能急劇下降，進而影響正常業務應用。舉個例子，一個學生入學的時候，教務處希望更新該學生學籍，而前面一個BI操作正在生成所有畢業生的GRE成績和就業單位起薪的報表，那么更新學籍的操作就會等待很長時間才能執行。所以，需要建立一個專門針對BI的數據倉庫系統以便讓事務系統的運行不受干擾。當事務系統接近存儲極限的時候，可以把部分老數據導入到數據倉庫，以免丟失有價值的歷史數據。由此，數據倉庫系統出現了兩個很有意思的操作：歷史數據追加（Append）操作和報表處理（Process）操作。當然，數據倉庫系統依然需要創建（Create）和獲?。≧etrieve）操作。但是，因為數據倉庫中的數據記錄都是有價值的，所以數據倉庫中的刪除（Delete）操作會減少，即使執行刪除，記錄也會被備份到更加低速、廉價的存儲介質上而不是真正被刪除。此外，更新（Update）操作在數據倉庫里面也被減少，因為歷史記錄是有價值的，所以當一條記錄被更新時候，系統只是追加了一條新的記錄，而不是將原記錄替換為新記錄。例如，用戶每次更新密碼的時候，系統會在數據倉庫系統里面追加老密碼的記錄，以備后續檢查（預防用戶重設密碼或者在用戶忘記新密碼的時候作為額外途徑進行認證）。因為歷史記錄的價值在BI系統中被逐步發現，所以數據系統的創建（Create）、獲?。≧etrieve）、更新（Update）和刪除（Delete）為主的CRUD操作慢慢轉為創建（Create）、獲取（Retrieve）、追加（Append）和處理（Process）為主的CRAP操作（CRAP是四個操作的英文首字母）。伴隨著數據倉庫技術的發展帶來數據量的上升和數據處理速度提升的要求，工業界對于數據處理技術的要求也不斷提升，于是大規模并行計算(Massively Parallel Processing, MPP）技術應運而生。

1.2.2 MPP（大規模并行計算）

原來專注于事務的數據庫管理系統主要涉及針對單條記錄的CRUD操作。因為數據倉庫的出現，BI（甚至早期的AI）算法開始整表整表地掃描所有數據。為了提高數據的處理速度，在PC時代人們不再挑戰單個大型機的性能極限，取而代之的是利用一個PC集群來提高計算性能。人類面臨復雜問題的時候，分而治之是常用策略，MPP是典型的分而治之策略的產物。為了幫助讀者理解分而治之的策略，我們來解析一個快速排序算法的設計，無論讀者是否有計算機專業背景，理解這種方法背后的設計原則都是有益的。

快速排序算法問題陳述：假設給定任意一組無序的和不定數量的數，例如{0,50,24,9,23,7,35,17}，我們要讓計算機找到一個步驟（算法）將這堆數從小到大依次排列。

快速排序算法描述：采用分而治之策略的快速排序算法就是在中間位置挑選一個數（即樞數，英文為Pivot），比樞數小的數移到其左邊，比樞數大的數則移到其右邊。然后，依次對左邊的一組數和右邊的一組數分別再進行快速排序。如果我們挑選23作為第一趟排序的樞數，那么第一趟排序后的結果為：

{0,9,7,17},23, {54,24,35}

讀者可以自己嘗試對左右兩組數繼續做第二趟排序。注意，這時，本來對一堆數排序變成了對兩堆數分別排序，第二趟排序后就有四堆數需要排序，這就是一個不斷分而治之的過程。

同樣地，并行計算也不是新理論，只是在BI業務場景下它有獨特的適用之處。隨著數據量越來越大，BI業務的結果返回速度越來越慢。作者從幾個世界級公司的大數據團隊那里了解到，得出一個市場活動的報表常常需要幾天乃至數周?？梢?，提高處理（Process）的速度已成為關鍵。MPP的分而治之策略就是把數據均勻分布到一群PC上，然后讓每臺機器同時工作進行處理。舉個簡單的例子，我們要找出雙十一活動中消費金額最高的顧客給予獎勵。假設我們把雙十一的消費記錄導入數據倉庫并均勻分布在數據倉庫的10臺PC服務器上。只要同時對這10臺服務器上的數據進行掃描，每臺服務器分別返回消費金額最高的顧客記錄，然后對比這10臺服務器各自返回的消費金額最高的顧客記錄，最終找到獲獎的顧客。這種方式的掃描速度接近單臺服務器速度的10倍。如果企業還是覺得這個速度不夠快，那么可以把數據倉庫擴大到100臺等同的PC服務器，速度可以再快10倍。當然，實際情況沒有這么簡單，因為在這個例子中，10臺服務器只要交換一次數據就可以解決問題。喜歡挑戰的讀者可以考慮一下如何計算消費記錄的中數，就會發現10臺服務器之間交換的數據量要大很多。當然，現在Greenplum中有大量的技術可以用于處理這些復雜場景下的系統性能。熱愛技術的讀者可以在后續章節領略到Greenplum中大量體現匠人精神的性能設計方式。一個技術產品是一系列設計藝術的集合，它需要人才、時間和組織文化的沉淀。

隨著大數據的爆發，產業趨勢拉動數據倉庫技術朝大數據平臺的方向發展。產業需要數據倉庫產品擁抱開源、云計算和人工智能等新趨勢。Greenplum和Teradata等伙伴們一直在演進，Greenplum因為Pivotal的第三平臺戰略的要求，演進速度非?？?，這些將在后續章節闡述。值得一提的是，市場迫切需要一個數據倉庫以外的MPP數據引擎，以處理數據倉庫結構化數據以外的半結構化數據。典型的場景是Google的搜索，它需要處理大量半結構化的Web文本。為此，Google提出了MapReduce并行計算和Google文件系統（Google File System, GFS）。Google雖然發表了論文，但是并沒有提供軟件和源代碼。于是，社區里熱心的粉絲們啟動了一個Hadoop項目，實現了類似的Hadoop MapReduce和Hadoop文件系統（Hadoop File System, HDFS）。Greenplum為了支持Hadoop社區，把Greenplum的并行SQL執行引擎和HDFS結合，創建了Hadoop生態內的HAWQ項目。HAWQ的研發工作主要在Pivotal中國研發中心內部完成，并且在2018年成為Apache的頂級開源項目。

除了結構化數據和半結構化數據的MPP, Pivotal中國研發中心還對其他特定場景數據的并行計算進行了探索。Pivotal上海研發團隊曾發起Open-MPI項目，探索基于開放高速消息傳遞接口的并行化以計算社交網絡圖譜數據。這樣的探索最終不一定都會取得商業上的成功，但是對于一個意圖成為MPP計算行業意見領袖的機構來說是必須的?；谶@種探索精神，Greenplum和HAWQ產品創造了行業中很多從無到有的創新點。

1.2.3 大數據系統

在Greenplum和Hadoop出現之前，數據倉庫和BI有兩大局限性：一是系統的成本太高；二是BI需要結合人為判斷才能產生商業意義。

首先來說成本的問題。假設一個四年制高校每年有8萬名在校生（即每年有2萬名新生），那么事務系統只要存儲8萬個學生相關的記錄。但是，為了保留過去20年間所有學生的記錄，數據倉庫系統需要保留過去16年畢業生的32萬個記錄。在存儲價格昂貴的PC時代（讀者可以回憶一下，當時容量為32MB的可以下載8首MP3的U盤要賣200多元），成本數倍于業務系統但又不是剛需的數據倉庫系統對于大部分企業來說是高階玩家的裝備。更為糟糕的是，不少早期的數據產品建立在封閉的硬件和軟件之上。硬件方面，數據倉庫都有專用存儲系統，這些存儲的價格是通用磁盤或者快閃存儲價格的數倍到十余倍。同時，軟件系統也是封閉的，圍繞軟件系統開發更多BI工具或者高階的AI算法非常困難。加上當時BI應用普遍被認為非剛需應用，使得大部分企業很難看到投入產出比（ROI），導致進一步禁錮了大數據的價值。

其次來看BI需要人為判斷的問題。BI生成了很多報表，但是這些報表要靠公司的決策者來解讀。依靠直覺的人為判斷會浪費決策者大量時間。盡管決策者擅長分析解讀數據并工作勤奮，但BI的真正問題在于只有在決策者提出一個問題后才會生成報表。例如，一名校董提出希望了解學生的GRE成績和就業薪水的關系，數據倉庫工程部門才會生成相應的報表。但是，決策者們更希望計算機的數據系統能夠覆蓋他們的盲點。如果一個計算機系統能夠自動發現GRE分數高和就業起薪高的人群在二維空間分布圖上聚集度高的規律并能自動提醒決策者，那么這樣的數據倉庫系統才能真正幫助到決策者（實際上，這里隱含了一個叫作聚類的非監督學習的人工智能算法）。所以，產業界開始由BI向AI遷移，但是AI比起BI需要更多的算力、更多的廉價數據存儲和更開放的軟件系統。

開源Hadoop和Greenplum解決了這兩個進入大數據時代的絆腳石。首先，Hadoop和Greenplum是開放源代碼的，這使得專用的數據倉庫可以接受更多高階算法的改進。例如，技術人員在Greenplum上面建立了一套叫作MADLib的人工智能和機器學習的庫函數，企業可以在自己的數據上面應用很多高階的機器學習算法，其中包括我們上面提到的非監督學習的算法，這意味著大數據系統可以找出更多靠人類直覺無法發現的智能和關聯關系。MADLib最早是由Greenplum和加州伯克利大學聯合開發的，Pivotal成立以后，將MADLib完全開源給Apache，使其于2017年成為Apache的頂級開源項目。同樣，Hadoop也建立了一套機器學習的庫函數Spark ML，它的邏輯和MADLib幾乎是平行的。

其次，Hadoop和Greenplum都建立在通用的服務器存儲上，也就是說，大數據系統的存儲和讀者家用電腦的存儲是一樣的。那么，Hadoop和Greenplum是如何利用普通硬盤達到專用存儲的可靠性和性能的？無論是普通硬盤還是專用存儲設備，其本質都是通過相關的軟件和硬件冗余來實現存儲的性能和可靠性的。Hadoop和Greenplum只是把這些軟件的邏輯上移到服務器層次（Tier）。因為大數據系統需要對數據整遍整遍地讀取，硬盤很容易損壞，所以Hadoop和Greenplum采用冗余方式解決這個問題，即把一個數據塊同時拷貝在2～3臺服務器上（有些沒有安全感的公司甚至拷貝到5～7臺服務器上）。如圖1-2所示，文件塊1、2、3同時在三臺服務器上存有兩個拷貝。服務器A上有文件塊1和3，服務器B上有文件塊2和3，服務器C上有文件塊1和2。這樣做的好處是，任何一臺服務器損壞時都不必擔心，因為它上面的文件塊必然在其他兩臺服務器上有備份。假設服務器C損壞，其硬盤上的文件塊1和2丟失，此時插入一臺新的服務器D，就可以從服務器A上恢復文件塊1，從服務器B上恢復文件塊2，最終服務器D重構了文件塊1和文件塊2，從而完美取代了原來的服務器C。

數據冗余的另一個好處就是可以實現數據本地性（Data Locality）。并行計算的一個關鍵瓶頸是數據移動，而通過數據冗余可以實現在本地移動數據的效果。仍以圖1-2為例，如果一個計算任務需要掃描文件塊1，而服務器A正忙于其他任務。這時候因為服務器C上有文件塊1的冗余，就可以把這個計算任務分派到服務器C。假設沒有服務器C上的冗余備份，那么只能從服務器A上拷貝數據塊1，在這種情況下，有大量時間不是用于計算文件塊1，而是等待數據塊1從服務器A拷貝C，造成大量的時間浪費。

因為Hadoop系統和Greenplum系統的開源和開放以及使用通用硬件構建大數據系統，從而極大降低了大數據系統建設和使用的門檻。加之很多學術機構和頂級公司已經用它們的專用系統通過大數據在機器學習和人工智能上取得成功，強烈的示范效應使大數據風靡全球。大部分中大型企業都開始考慮通過大數據系統增強自己的競爭力。

1.2.4 當大數據遇到云計算

前面談到，大數據系統云上北向遷移的趨勢很難阻擋。云計算除了帶來更低的運營成本，也帶來了更低的存儲價格和可以伸縮的計算資源。這一趨勢的推動力來自第三代平臺，而第三代平臺是CPU、存儲和網絡的產能不斷升級過程中由量變到質變的產物。但是，大數據系統上云也有兩個核心的技術問題要解決：1）提供適應于云計算的運維環境；2）按照云上存儲環境進行適配。

首先，我們來看云計算對于大數據運維的影響。一個軟件系統運維的簡便性與否會極大影響軟件的推廣。公有云的一個優勢就是把系統運維的復雜性留給了云廠商，而給用戶提供了一個不需要專業人員即可運維的環境。以淘寶網為例，淘寶店主不需要太多培訓就可以在淘寶網上開設并運營自己的網店。相比之下，傳統線下的企業大數據系統則需要專業團隊來維護，而Hadoop系統的運維尤其復雜。對于500強企業來說，可以招聘一個運維團隊來運維這個系統；但對于中小企業來說，運維復雜性帶來的成本增加遠大于軟件許可費下降帶來的成本節省。Gartner在2017年發布的技術成熟度曲線指出，Hadoop系統運維的復雜性將使得Hadoop系統在到達“生產成熟期”之前直接過時。當大數據遇到云計算以后，獲得了一個新的契機，那就是可以通過云上可運維性的改善讓中小企業像運維淘寶網店一樣運維自己的大數據系統。類似于Snowf lake的一批數據產品開始朝云上可維護性這個方向發力，開源Greenplum在阿里云等公有云平臺上的發布也降低了產品部署和運維的復雜性。

其次，我們再看云計算存儲對于大數據的影響。云上的存儲分為塊（Block）存儲和對象（Object）存儲。前者通常依賴Dell EMC這樣的存儲系統保障，它的優點是快速和可靠，缺點是成本高昂。對象存儲（例如亞馬遜的S3）的特點是價格低廉，但計算訪問速度相對較慢。在《Cloud Foundry：從數字化戰略到實現》中我們說過，云計算通過軟件和硬件的分離實現了軟件的永生能力，而傳統的大數據系統可以直接訪問本地的存儲。因此，云上的共享塊存儲環境與傳統大數據系統的本地存儲環境存在一定矛盾。大數據系統上云需要解決計算主體和存儲主體分離的問題。另外，云上的對象存儲因為廉價、可靠等優勢存放了各種不同的數據源。除了半結構化的文本數據，也有大量的圖片、音頻和視頻數據。因此，大數據系統上云也要支持對更多數據源的處理。在云上，Greenplum提供了新技術來訪問S3文件系統內的半結構化數據，在后面的章節中將討論這一點。對于云上的圖片和視頻等數據，因為存儲和計算系統需要對相應的機器學習算法進行特殊調優，所以催生了Google的TensorFlow等產品。