《雲數據管理：挑戰與機遇》　簡介

本節書摘來自華章出版社《雲數據管理：挑戰與機遇》一書中的第1章，第1節，作者迪衛艾肯特·阿格拉沃爾（Divyakant Agrawal） 蘇迪皮托·達斯（Sudipto Das）阿姆魯·埃爾·阿巴迪（Amr El Abbadi），更多章節內容可以訪問雲棲社區“華章計算機”公眾號查看。

簡　　介

當代技術的快速發展導致大規模數據中心（也稱為雲）中的用戶應用、服務和數據的數量急劇增加。雲計算已經使得計算基礎設施商品化，就像日常生活中的許多其他實用工具一樣，並且大大減少了創新型應用及其大規模部署之間的基礎設施障礙，從而可以支持分布在世界各地的大規模用戶。在雲計算出現之前，對一個擁有大規模用戶群的新應用的市場驗證，往往需要在計算基礎設施方麵進行大規模前期投資才能使得應用可用。由於雲基礎設施的即用即付收費機製和彈性特征，即根據工作負載動態地增加或減少服務器數量，大部分基礎設施風險都轉移到了雲基礎設施提供商身上，從而使得一個應用或服務能夠支持全球範圍內的用戶，影響更多人。例如Foursquare、Instagram、Pinterest以及很多其他應用，在全世界範圍內有數百萬用戶訪問，正是雲計算基礎設施才使得如此大規模的部署成為可能。

雖然雲平台簡化了應用程序的部署，但是服務提供商麵臨著前所未有的技術和研究挑戰，即，開發以服務器為中心的應用程序平台，能夠實現無限數量用戶的7×24小時的網絡訪問。過去10年，很多技術領先的網絡服務提供商（如Google、Amazon和Ebay）積累的經驗表明，雲環境下的應用程序基礎設施必須滿足高可靠性、高可用性和高可擴展性。可靠性是確保一個服務能夠連續訪問的關鍵。同樣，可用性是指一個給定係統能夠正常工作的時間百分比。可擴展性需求代表係統處理逐漸增加的負載的能力，或者隨著額外資源的增加（尤其是硬件資源），係統提高吞吐量的能力。可擴展性既是雲計算環境下的關鍵要求，同時也是一個重大挑戰。

一般來說，一個計算係統的硬件增加以後，如果其性能能夠隨增加的資源成比例提高的話，該係統就是一個可擴展的係統。係統有兩種典型的硬件擴展方式。第一種方式是垂直擴展（vertically，或稱scale-up），垂直擴展是指增加單個服務器的資源，或者用功能更強大的服務器進行替換，一般涉及更多的處理器、內存和服務器有更強的I/O能力。垂直擴展能夠有效地為現有的操作係統和應用模塊提供更多的資源，但是需要對硬件進行替換。此外，一旦超過一定規模以後，服務器能力的線性增加會導致開銷的超線性增加，從而導致基礎設施代價大幅度增加。另外一種係統擴展方式是水平增加硬件資源，又稱為橫向擴展（horizontally，或稱水平擴展，scale-out）。水平擴展意味著無縫地增加更多的服務器，並進行工作負載的分配。新服務器可以逐漸添加到係統當中，這樣可以保證基礎設施的開銷（幾乎）是線性增加的，從而可以很經濟地構建大規模的計算基礎設施。但是，水平擴展需要高效的軟件方法來無縫地管理這些分布式係統。

隨著服務器價格的下降以及性能需求的不斷增加，可以用低成本的係統來構建大規模的計算基礎設施，部署高性能的應用係統，如網絡搜索和其他基於網絡的服務。可以用數百台普通服務器構建一個集群係統，其計算能力往往可以超過很多強大的超級電腦。這種模型也得益於高性能連接器的出現。水平擴展模型還促使對高I/O性能的共享數據中心的需求日益增加，這種數據中心也是大規模數據處理所需要的。除了硬件和基礎設施的上述發展趨勢外，虛擬化（virtualization）也為大規模基礎設施的共享提供了優雅的解決方案，包括對單個服務器的共享。水平擴展模式是當今大規模數據中心的基礎，構成了雲計算的關鍵基礎設施。穀歌、亞馬遜和微軟等技術引領者都證明，由於很多應用能夠共享相同的基礎設施，因此數據中心能夠帶來前所未有的規模效應。這3家公司不僅對公司內部的應用實現共享，同時還在各自的數據中心中提供Amazon Web Services（AWS）、Google AppEngine和Microsoft Azure等框架來為第三方應用提供服務，這樣的數據中心稱為公有雲。

圖1-1展示了部署在雲基礎設施中的網絡應用的軟件棧示意圖。應用程序客戶端通過互聯網連接到應用程序（或服務）。應用程序接口往往是通過應用程序網關或者負載均衡服務器來把請求路由到網絡和應用服務器層的相應服務器上。網絡層主要負責處理訪問請求並對應用邏輯進行封裝。為了加快訪問速度，頻繁訪問的數據一般都存儲在由多個服務器構成的緩衝層上。這種類型的緩衝一般是分布式的，並且由應用層來負責顯式管理。應用程序的持久化數據存儲在一個或多個數據庫服務器中（這些服務器組成數據庫層）。存儲在數據庫管理係統（DBMS）中的數據構成了基準數據，即應用程序正常操作所依賴的數據。部署在大規模雲基礎設施中的大部分應用程序都是數據驅動的。數據和數據庫管理係統在整個雲軟件棧中都是不可或缺的組成部分。由於數據管理係統是整個軟件棧中的重要組成部分，所以數據往往被複製多份（參見圖中的虛線部分）。這種複製機製在一個DBMS服務器宕機的情況下也能夠提供高可用性。另外一個挑戰是如何應對日益增長的數據量和訪問請求。本書將主要關注雲軟件棧的數據庫層設計中麵臨的諸多挑戰。

雲計算領域中數據庫管理係統廣泛使用的主要原因在於DBMS的成功，尤其是關係型數據庫管理係統（RDBMS）的巨大成功能夠滿足不同類型應用程序在數據建模、存儲、檢索和查詢方麵的要求。DBMS成功的關鍵因素在於其所具備的諸多特性：完善的功能（用簡單、直觀的關係模型對不同類型應用程序進行建模），一致性（能有效地處理並發負載並保持同步），性能（高吞吐、低延遲和超過25年的工程應用經曆），以及可靠性（在各種失效情況下確保數據的安全性和持久性）。

 

 

圖1-1　雲基礎設施中典型的網絡應用程序軟件棧

雖然取得了巨大的成功，但是在過去10年間人們一直認為DBMS和RDBMS並不適合雲計算。主要原因在於，和雲服務中的網絡服務器、應用程序服務器等組件不同（網絡服務器、應用程序服務器可以很容易從少數服務器擴展到成百上千甚至上萬台服務器），DBMS不容易擴展。實際上，現有的DBMS技術無法提供足夠的工具和方法來對一個現有數據庫部署進行橫向擴展（從幾台機器擴展為很多機器）。

在雲計算平台中確保基於Web的應用程序具有可擴展性的基本要求是能夠支持無限數量的終端用戶。因為係統的可擴展性僅能保證係統能夠擴展到更多的服務器或用戶請求，所以可擴展性隻是一個靜態屬性。即，可擴展性無法確保係統的規模能隨著用戶負載的浮動而動態變化。相反，係統彈性則是動態屬性，因為彈性允許係統在不宕機的情況下通過增加服務器進行動態擴展或者通過減少服務器縮減規模。彈性是係統的一個重要屬性，其得益於底層雲基礎設施的彈性。

為了能夠水平擴展到數千台服務器、具備彈性、可以跨越多個地理區域和具備高可用性，很多技術引領者都開發了具有自主知識產權的數據管理技術。從曆史來看，由於需求的巨大不同，數據管理任務往往被寬泛地分成兩大類。第一類是在線事務處理（OLTP），或者是數據服務負載（主要側重於短小、簡單的讀/寫操作或事務）。另一類是決策支持係統（DSS），或者稱為數據分析負載（主要側重於長時間的、隻讀的、複雜的分析處理操作）。兩類不同的任務負載對係統有不同的要求，針對每種工作負載，曆史上出現不同的係統架構。因此，為了應對不同種類的工作負載，兩種技術路線共同得以發展。本書主要關注前一個問題（OLTP）在雲環境下是如何解決的。分析處理也得到了雲數據管理的重要推動，並且產生了很多重要的技術和係統。尤其是穀歌公司提出的MapReduce編程模型[Dean and Ghemawat, 2004]，該編程模型適合用來在計算機集群中對大規模數據集進行分析。簡單來說，MapReduce模式對大規模數據集進行劃分，並把每一塊映射到不同的服務器上。每個服務器負責處理一小塊數據，並把處理結果傳到一個reducer上，reducer負責收集來自不同mapper的所有結果，並對這些結果進行合並得到最終的輸出結果。由於穀歌公司的廣泛推廣以及開源係統Hadoop[Apache Hadoop]的大受歡迎，MapReduce模式成為雲時代最受關注的新興技術。然而關於MapReduce和RDBMS的爭論一直不斷[Dean and Ghemawat，2010，Stonebraker et al.,2010]，廣泛深入的研究也促進了MapReduce和基於Hadoop的分析平台的快速發展。本書的剩餘章節將主要關注雲環境的數據服務係統。

早期開發的可擴展的數據服務係統是一類稱為“鍵–值存儲”的係統。Bigtable [Chang et al., 2006]、Dynamo [DeCandia et al.,2007]和PNUTS [Cooper et al., 2008]等係統起到了引領作用，緊接著一係列開源係統湧現出來，這些開源係統或者是複製了這些內部（in-house）係統的設計思想，或者是受到這些內部係統的啟發。鍵–值存儲係統與RDBMS的主要區別在於，傳統RDMS數據庫中的所有數據都被視為是一個整體，DBMS的主要職責是確保所有數據的一致性。然而，在鍵–值存儲係統中，這種關係被分隔成主鍵和其相關的值，鍵–值對被視為獨立的數據單元或信息單元。應用程序的原子性和一致性以及用戶訪問僅僅在單個主鍵級別得以保證。這種細粒度的一致性允許鍵–值存儲係統對數據庫進行水平擴展，很方便地把數據從一台機器遷移到其他機器，能夠把數據分布到數千台服務器上，同時能避免繁重的分布式同步，在部分數據不可用的情況仍然能夠繼續為用戶提供服務。此外，鍵–值存儲係統設計的目的是具有彈性，而傳統的DBMS一般是用於具有靜態配置的企業基礎設施，其主要目的是對於給定的硬件和服務器設施實現最高的性能。

所有最初的內部係統都是根據良好的需求而定製的，能夠適應特定應用的特點。例如，Bigtable主要是用來進行索引結構的創建和維護，從而為穀歌搜索引擎服務。同樣，Dynamo的設計初衷是為亞馬遜電子商務網站的購物籃服務，雅虎的社交屬性促使了PNUTS的誕生。因此，雖然這些係統都屬於鍵–值存儲係統，但是每個係統也都有自己的獨特設計。在本書後麵的內容中，我們將詳細分析每一個係統，從而理解這些設計原則及其權衡。然而，可擴展性、係統彈性和高可用性等關鍵特點使得這些係統在各自的應用領域大受歡迎，在其他領域，HBase、Cassandra、Voldemort及其他開源係統也得到了廣泛使用。鍵–值係統的廣泛使用也預示著NoSQL運動的到來[NoSQL]。雖然單個鍵–值對粒度的原子性和一致性已經能夠滿足實際應用的需求，但是在很多其他應用場景下這種訪問模式還遠遠無法滿足實際要求。在這種情況下，需要由應用程序開發者來保證多個數據的原子性和一致性。這就導致在不同的應用棧中重複使用多實體同步機製。針對多個數據的訪問控製的實現機製在很多開發者博客[Obasanjo，2009]及相關論壇中都有所討論[Agrawal et al.，2010，Dean，2010，Hamilton，2010]。

總體來說，所麵臨的關鍵挑戰是如何在保證較高性能、可擴展性和係統彈性的同時實現針對數據庫中多個數據片段訪問的原子性。因此，在大規模數據中心中也要支持經典的事務[Eswaran et al.，1976，Gray，1978]概念。分布式事務已經有很多研究成果[通常是服務器的大集群）性能。這些基本的設計原則和各種設計方案是本書剩餘章節的主要討論內容。特別是我們會分析各種各樣的係統和方法，其中有些是學術中的原型係統，有些是工業級的產品。這些方法經常利用一些巧妙的特性和應用程序的訪問模式，或者對提供給應用層的功能加以限製。關鍵挑戰在於如何在增強鍵–值存儲係統功能的同時不降低係統性能、彈性和可擴展性。實際上，雲平台成功的主要原因在於其能夠在雲環境下保證數據管理的簡潔性、可擴展性、一致性和係統彈性。

把DBMS擴展到具有大規模並發訪問用戶的大型應用尚存在一些挑戰，很多雲平台在為大量小規模應用提供服務時也麵臨諸多挑戰。例如，Microsoft Windows Azure、Google AppEngine和Salesforce.com等雲平台一般都要為成千上萬個應用提供服務，但是大部分應用可能隻占用一小部分存儲空間，並發請求的數量也隻占整個雲平台的很小比例。關鍵的挑戰在於如何以一種高性價比的方式來為這些應用提供服務。這就導致了多租戶技術的出現，多個租戶可以共享資源並在一個係統中共存。多租戶數據庫已經成為雲平台軟件棧中重要且關鍵的組成部分。這些租戶數據庫一般不是很大，因此可以在單個服務器中運行。因此，DBMS的全部功能都可以得到實現，包括SQL操作和事務。然而，係統彈性、資源的有效共享和大量小租戶的統一管理等問題也非常重要。為了滿足這些需求，在數據庫層已經產生了多種虛擬化方法。硬件和係統軟件的虛擬化主要用於對大規模數據中心基礎設施進行共享和管理。然而，數據庫內部的虛擬化可以支持和隔離多個獨立的租戶數據庫，該技術引起了數據庫學術界和工業界的廣泛關注。本書後麵的部分將主要討論設計靈活的多租戶數據庫係統麵臨的諸多挑戰。

雲計算和大規模數據中心的數據管理主要建立在基礎的計算機科學研究之上，包括分布式係統和數據庫管理。第2章中，我們主要提供分布式計算和數據庫的一些基本背景資料，尤其是分布式數據庫。第2章中涉及的很多主題都非常重要，有助於理解後麵章節中的一些高級概念。但是對這些領域的文獻資料比較熟悉的讀者可以直接跳到第3章，第3章介紹雲環境下關於數據管理的早期研究工作，特別介紹了基本的技術發展趨勢以及取得的經驗教訓，並對一些特定的係統進行了重點講述。接下來討論了如何在雲環境下支持原子操作（事務）。第4章討論了一些新的嚐試，試圖將所需要的數據托管到一個地方，這樣就可以避免複雜的分布式同步協議，也能夠確保訪問操作的原子性。第5章針對分布式事務和跨站點甚至跨數據中心的數據訪問提供了通用的解決方案。第6章討論多租戶的問題，並對雲環境下的實時遷移方法進行了探討。第7章對相關經驗教訓進行了總結，並指出了未來的研究方案。