云計算與大數據

TheEssentialCriteriaofBigData&CloudComputing第1章揭秘云計算第2章揭秘大數據第3章云計算與大數據體系架構剖析第4章云計算與大數據進階第5章大數據應用與云平臺實戰第一章揭秘云計算1.1云從哪里來首先，我們需要知道云從哪里來，搞清楚誰是云計算的提出者至關重要，這個大可上升到哲學的高度，可類比千百年來科學家乃至全人類最關心的問題的核心，就是知道人從哪里來。同理，知道云從哪里來可以更好地幫助我們預判云會朝哪個方向發展，會在何處融入、改變人們的工作與生活。1.1.1云計算科技史云計算是亞馬遜最早于2006年推出的AWS服務。AWS從早期的云計算服務EC2、存儲服務S3到今天發展為目前業界最為廣泛使用的各類計算、網絡、存儲、內容分發、數據庫、大數據管理與應用等五花八門的服務。也有人說云計算是SunMicrosystems在2006年3月推出的SunGrid，它是一種公有云網格計算服務，一美元一小時的CPU使用價格，和用電一樣的計費模式—Pay-Per-Use（按使用量計費）。

不過，按照MITTechnologyReview刨根問底的結果，Compaq（康柏）電腦公司1996年在內部商業計劃文檔（見圖1-1）中最早使用CloudComputing（云計算）這一字樣與圖標（遺憾的是，康柏在被惠普收購之后，除了繼續賣了幾年低端PC外與云計算再無瓜葛）。圖1-1康柏公司1996年商業計劃文檔ISDStrategyforCloudComputing云計算的三大要素以上可以算作對云計算“冠名權”歸屬的一番淺究，事實上云計算的起源比以上諸多論斷還要早，其發展歷程貫穿了過去半個世紀全人類的IT發展史，如圖1-2所示。云的起源及發展：1970-Now20世紀70年代–TimesharingRemoteJobEntrybyIBM/DEC20世紀70~80年代-ARPANETTCP/IPbyARPA/DOD&CSNET/NSF20世紀90年代–VPNVPNbyTelcos;DistributedComputing21世紀頭8年–EC2EC2byAmazon–2006;Azure-20082008~2010年-OpenXOpenNebulabyNASAOpenstack2010年-今眼花繚亂圖1-2云的起源及發展（從20世紀70年代至今）云的起源及發展：1970-Now20世紀70年代–TimesharingRemoteJobEntrybyIBM/DEC20世紀70~80年代-ARPANETTCP/IPbyARPA/DOD&CSNET/NSF20世紀90年代–VPNVPNbyTelcos;DistributedComputing21世紀頭8年–EC2EC2byAmazon–2006;Azure-20082008~2010年-OpenXOpenNebulabyNASAOpenstack2010年-今眼花繚亂云計算三大要素分時計算網絡互聯資源共享及網絡安全云計算的本質近幾年，云計算的發展讓人眼花繚亂，各種新興的技術、新興的公司風起云涌。其中值得一提的有兩樣東西。一個是容器計算。我們前面提過虛擬化，基于虛擬機（VirtualMachine，VM）的虛擬化可算是對Baremetal（裸機）這種形式的有效補充，而容器可算作是對基于VM技術的虛擬化的有效補充。容器的意義在于重新提高了因虛擬化帶來的計算效率的降低，后面的章節中我們會專門論述相關的問題。

另一個值得一提的是大數據。如果說2006年開始的云計算浪潮多少都是偏重于底層的平臺與服務，而真正尋找到的與之匹配的就是近三五年來聲名鵲起的大數據應用。兩者可算是一拍即合：云計算作為基礎架構來承載大數據，大數據通過云計算架構與模型來提供解決方案，如圖1-3所示。圖1-3當云計算遇上大數據

從技術角度來看，云計算是多種技術長期演變、融合的產物，諸如分布式計算、并行計算、網絡存儲、分布式存儲、虛擬化、裸機及容器計算、負載均衡等計算機及網絡技術，如圖1-4所示。圖1-4云計算的底層技術發展與融合

云計算的本質是多種技術的融合，它和很多其他技術頗有相通之處，例舉幾個。（1）C/S與B/S技術。（2）P2P技術。（3）并行計算（ParallelComputing）。云計算基本特征（1）共享資源池。（2）快速彈性。（3）可度量服務。（4）按需服務+自服務。（5）普遍的網絡訪問。

圖1-5展示了云計算的這些基本特征。圖1-5云計算基本特征示意圖

這里，我們套用IDC在2013年提出的“三個平臺”來作為總結，如圖1-6所示。圖1-6第一、第二、第三平臺1.1.2業務需求推動IT發展隨著過去幾十年間IT行業從大型主機（Mainframes）過渡到客戶端服務器（PCServers），再過渡到現如今的移動互聯時代（MobileInternet），IT可把控的資源和預算的大趨勢一直在下滑。在過去十幾年的時間里，對虛擬化技術的采納幫助IT實現了極大的效率飛躍，大幅提升了IT滿足業務預期的能力。不過，在當下的移動互聯時代，面對數以十億計的新移動消費者以及數以百萬計的新應用和服務，IT可謂是機遇和挑戰并存。業務預期呈現出了指數增長。

如果不在“我們如何做IT”方面做出根本性改變，沒有人能趕上行業發展的步伐。IT交付所面臨的問題如圖1-7所示。圖1-7業務預期vs.IT交付能力vs.IT預算（橫軸為時間軸）

大多數政企IT部門所采用的依然是傳統模型。在傳統IT流程中，每個新的解決方案都是一個需要進行采購、設計、配置、測試以及部署的項目，即便是做得很順利的話，新項目部署周期也要長達數周、數月甚至數年。這就很難實現高敏捷性和低投資，也就很難通過IT來增加收入。組織機構的目標就是增加敏捷性，減少運營支出，對未來進行更多投資，并不斷降低風險，但是這兩者之間存在著一個鴻溝，如圖1-8所示。圖1-8傳統應用vs.下一代云應用

如何讓IT的交付能力保持同步，甚至超越業務的預期是IT部門始終的使命（見圖1-9）。圖1-9與業務同步的IT交付能力敏捷性IT控制&安全（可集中管理）開發一次、可多地部署選擇權1.2云的多重形態1.2.1云計算的多重服務模式云計算在快速的發展過程中逐漸形成了不同的服務模式（ServiceModels）。目前我們熟知的主要有三大類：SaaS（SoftwareasaService，軟件即服務）、PaaS（平臺即服務）與IaaS（基礎架構即服務），也有人喜歡把它們統稱為XaaS或EaaS（EverythingasaService）。

類似的還有存儲即服務（StorageasaService）、容器即服務（ContainerasaService）等。從根源上講，*aaS模式都源自SOA（Service-OrientedArchitecture），SOA是一種架構設計模式（可類比面向對象編程語言中的設計模式），其核心就是一切以Service為中心，不同的應用之間通信協議都以某種服務的方式來定義和完成。今天我們經?？吹降奈⒎占軜嫞∕icro-ServiceArchitecture，MSA）的概念，在本質上也是由SOA演變而來。

為什么會形成不同的*aaS服務模式呢？主要原因在于最終服務交付的形態，如圖1-10所示。圖1-10傳統vs.*aaS1.2.2公有云vs.私有云vs.混合云從云架構部署、服務、應用以及訪問的方式來區分，我們一般把云分為四大類：私有云；公有云；混合云；社區云。

對私有云、公有云、混合云的定義與界定的關鍵是云的服務對象。如果被服務的對象是一個機構，那么我們稱之為私有云。如果服務開放給大眾，并通過互聯網可以訪問，則稱之為公有云?；旌显仆ǔＪ羌嬗兴接性坪凸性撇糠?，兩部分可相對獨立運作，但是也會協同工作，例如一些任務可能會橫跨公有云、私有云邊界。

從“物種起源”的角度上說公有云與私有云都是由早年的DC/IDC數據中心或互聯網數據中心發展而來。除了它們各自所可能側重的服務不同外，在技術本質上沒有高低優劣之分（見圖1-11）。圖1-11公有云vs.專有云vs.私有云

公有云側重于對新應用（如第三平臺應用）的支持，面向應用的彈性實現（如支持可橫跨多臺云主機的數據庫服務），在存儲角度上則大量使用對象存儲（如對多媒體文件檢索和瀏覽支持）；另外一個特點是，為了實現利益最大化和產生正向現金流，絕大多數的云部件都被封裝成商品的方式待價而沽。

私有云大抵是因為歷史的原因而不得不繼續支撐傳統的企業應用（如第二平臺的大量應用，從數據庫到ERP/CRM不一而足），因此私有云的存儲形態主要是File（文件）和Block（塊），并且側重于基礎設施的彈性（第二平臺應用的一個典型特點是獨占性或者說是緊耦合性，它們很難像第三平臺的那些為云而生的新應用能比較容易地遷移和水平可伸縮，因此業界的普遍做法是把這些應用封裝后在底層的基礎設施上實現彈性）。公有云私有云混合云第三方運維是一般不是硬件投資一般不是部分中小企業適用是不一定是大型企業適用一般不是是可定制硬件一般不是是合規支持（Compliance）不是是高安全性實現困難是是跨云支持一般不一般不是第三平臺應用較多是是第二平臺應用較少較多是存儲特征對象為主塊、文件皆有更多開源技術是不一定是表1-1 公有云、私有云、混合云比較

業界對云的認知中普遍存在的一個印象是公有云是云的多種形態中的主體。這句話其實只說對了一小部分，按照媒體廣告投入規模和曝光頻率，公有云的確是更多，但是在市場整體規模和真正承載的云計算任務量而言，私有云和專有云市場占據大半江山（大于85%），而真正的公有云市場份額不過15%。誤解一：公有云會是未來唯一可行的云服務形態。誤解二：公有云擁有核心技術。

還有一個知識點值得提到的是關于on-premise（場內）與off-premise（場外）的，所有的公有云對于其服務的客戶而言都是off-premise的，也就是說在云端、場外，而對于私有云而言多數都是on-premise（場內云）的本地云，除了一種特殊的專有云情形，就是在托管方地界運營的私有云是off-premise的，比較典型的例子是在線視頻公司Netflix，它已經把整個基礎架構都遷移到了亞馬遜云之上，而且使用的是不與任何第三方共享的基礎設施，從本質上說這是一種基礎架構即服務的外包。認知一：勝者全贏—這句話來自于英文的俗語WinnerTakesAll。在公有云領域尤其如此，從市場份額、營收規模上看，亞馬遜的AWS如日中天（見圖1-12），它一家的份額比第2到第100家IaaS服務提供商的總和還要高，而且據悉AWS也是唯一一家截至2015年年底有盈利的公有云運營商，其他云服務商看來還要水深火熱很久了。圖1-12AWSvs.其他認知二：規模經濟效益—這句話也是源自英文EconomiesofScale。當云計算的規模較小的時候，相對的虧損比例會很高，而盈利的能力難以體現，只有當規模越來越大的時候，才會逐漸降低虧損并最終實現正向盈利，而我們目前看到的情況是，市場上只有AWS做到了，其他家還在不斷探索和繼續增長規模，而在背后支撐我們具有這一信念的經濟學理論就是規模經濟效應。舉個簡單的例子，一個加工廠有1,000名工人一個月生產10,000雙襪子，那肯定是虧損的，只有達到1,000,000雙以上的規模才會扭虧為盈。云計算也是一樣的道理。分類特點、優勢成本降低了CapEX（云計算開銷一般計入OpEx）降低整體開銷、綠色、節能技術實現簡捷、部署方便、自動化高彈性（無限可擴展存儲空間、網絡帶寬）人員降低培訓開銷只需要很小的維護團隊商務QoS/SLA支持規模效應表1-2 云計算的優點1.2.3云的形態并非一成不變前面我們了解了不同形態的云所具有的特點，并列出了一些規則來幫助人們決策到底要選擇哪種云可能最適應各自的業務需求。在擁抱云的過程中，大量的東西需要做出改變，從人的思維方式，到團隊的合作方式，到客戶的接洽方式，甚至是整個社會的運作方式都在逐步產生巨大的變化。這一小節我們就來談一談變化中的云、變化中的IT。云計算帶來的三大變革（1）基礎設施。（2）運營模式。（3）應用。圖1-13IT變革的三步走

換一個維度來看上面提到的三大變革，如圖1-14所示。圖1-14云的三大變革第一變化是基礎設施（Infrastructure）。第二變化是運營模式。第三變化就是應用。運營模式變革中的5+1+1運營模式的變革是為了更好地服務基礎設施與應用的變革，其主要的變化可以用如下的5+1+1來表達。需求設計實現驗證維護圖1-15瀑布流開發模式設計開發配置測試發布評估輕監管（比起瀑布流開發需要更少項目監管）重互信（聽起來像是社會主義高級階段）喜變更（即便在開發的晚期階段）強交流（強化商務與開發交流頻率）快迭代（高頻迭代-從年月周天…）評估項目進展的金標準是–可運轉的軟件圖1-18新IT角色出現圖1-17瀑布式敏捷開發圖1-16敏捷開發流程圖云遷移越來越多的初創型公司在早期階段可能會因為初始化投入成本較低而選擇公有云服務，最常見的是從云主機入手，逐漸延伸到云存儲、云數據庫、云加速器等服務，但是隨著業務的發展，到達某一個階段的時候，就會出現以其他云形態來補充或者是從一個云服務提供商遷移到另外一家提供商的需求，如圖1-19所示。圖1-19不同形態云之間的轉換

云遷移的誘發因素多種多樣，可歸納為如下幾種。性價比：客戶永遠在追尋更高的性價比，僅此而已。功能導向：A云不能完成的功能如B云可以就會遷移到B。策略導向：如compliance（合規）要求變化在原有云無法達到。

云遷移的方向可以是在任何兩朵云之間雙向或單向的遷移。遷移從應用到數據、到基礎架構，都可能被涵蓋。有的遷移像搬家一樣是一次性的（One-off），有的遷移是具有隨機性和重復性的。最典型的例子有云爆發（Cloud-Bursting，指當在私有云中運行的應用在訪問爆炸式增長后會臨時使用公有云服務來保證服務不間斷）以及混合云（見圖1-20）等。圖1-20混合云架構中負載的分配與遷移

圖1-20中描繪的是一幅典型的混合云架構場景，我們用一張表（見表1-3）來說明公有云和私有云在一個混合云框架下各自的側重點如何。混合云架構公有云私有云負載新應用、基礎工作高性能應用、關鍵任務硬件商品化硬件、DAS（直連）存儲存儲陣列、定制化、高端硬件虛擬化虛擬機、容器裸機、虛擬機、容器應用Web類為主大數據分析類、傳統應用表1-3 混合云架構中公有云vs.私有云

我們在這里也給大家介紹一些逐漸形成潮流的云遷移和云間數據交換的場景。場景一：云間數據交換。互聯網公司在業務發展初期大量使用公有云服務早已形成了一種定式，但是，隨著業務的發展，特別是需要處理的數據量的爆發式增長，有一些例如大數據分析的業務由于公有云服務商品化硬件的限制（如單機的CPU和內存限制），不得不考慮自建數據中心（私有云）來完成，那么就涉及在公有云與私有云間的數據傳輸成本與效率問題，通常最高效的方式是在兩朵云之間拉設光纖專線（中美之間的網絡成本存在很大的差異，美國的網絡寬帶成本遠低于中國，所以還要評估拉專線方式是否適合具體的業務需求），當然如果兩朵云所處的數據中心在物理網絡上距離越近效果越好。

比如一家地處硅谷MountainView的公司，它在AWS的EC2主機位于馬路對面的數據中心，而其自建的Cassandra集群就在其隔壁的ISP數據中心里面，那么建立一條連接彼此的10Gbit/s的專線，則專線傳輸幾乎是在高速局域網里進行數據傳輸的節奏。當然，前面的這個例子是比較理想的場景，只需要關心數據如何在兩個數據中心之間進行交換，這個問題可以進一步降解為四步。（1）源數據傳輸準備（Staging）：提取、去重、壓縮、加密等。（2）數據分發與傳輸（Transform）。（3）接收源數據（Receive）：解密、解壓、重建。（4）數據重構（Apply）。

圖1-21展示的是一個典型的從源數據中心向目標數據中心通過分布式、P2P公共網絡來傳輸數據的架構，該架構意圖達到高效、可靠、分布式數據傳輸的效果，它同樣適用于基礎架構遷移的場景。圖1-21云遷移場景一、二場景二：跨云的基礎架構遷移?；A架構的遷移是指要把IaaS以及之上所有的平臺、服務、應用及數據完全遷移。這其中最大的挑戰是對業務可持續性的要求。如果對在線業務的下線時間（Downtime）是零容忍，那么這就是一個經典的第三平臺無縫銜接大數據遷移場景。參考圖1-21，我們來簡單描述一下如何實現無縫、無損數據遷移（為簡化設計起見，假設源與目標數據中心具有相同、類似的硬件配置）。對源數據中心進行元數據提取（Metadata）。在目標數據中心重構基礎架構（IaaSReplication）。非實時數據的大規模遷移（Non-real-timeDataTransferring）。在目標數據中心啟動服務、應用進入備用狀態（Standby）。以迭代、遞增的方式在源、目標數據中心進行實時數據同步。目標數據中心調整為主服務集群（Cut-Off/Switch-Over）。持續數據同步、狀態監控（ContinuousMonitoring）。源數據中心下線或作為備用基礎架構（Offline/Online）。1.3關于云計算效率的討論1.3.1公有云效率更高？誤解：公有云具有更高的效率。首先我們需要知道到底效率指的是什么。這是個亟需澄清的概念。在這里效率是指云數據中心中的IT設備的資源利用率，其中最具有指標性的就是綜合CPU利用率。

我們在本小節著重討論CPU的資源利用率［在數據中心中我們習慣用PUE（PowerUtilizationEfficiency）來表示電力資源的利用率，它的計算公式：PUE=，其中C表示制冷、取暖等為保持機房環境溫度而耗費的電量，P表示為機房非IT設備供電所耗費的電量，I為IT設備耗電量，顯然PUE值不可能小于等于1，事實上全球范圍內的各種云機房平均PUE>2，而最先進的機房如谷歌和Facebook幾乎可以達到PUE=1.1甚至1.06，相當驚人的高效電能利用。

有鑒于此，中國2013年開始要求新建的數據中心PUE<1.5，原有改造的數據中心PUE<2。圖1-22中列出的是2012年中國數據中心的平均能耗分配，在PUE=2.0的情況下，IT設備與其他設施耗電各占50%，其中服務器在IT設備中為大頭，占比50%，存儲其次，最小的是網絡——這一數據也從另一個角度驗證了為什么我們要把服務器CPU的利用率作為主要指標來衡量資源利用率］。圖1-22數據中心能耗分配

圖1-23列出了目前市場上主流的公有云、私有云的平均服務器主機CPU利用率比較。圖1-23公有云、私有云CPU利用效率比較

圖中的數據可以清晰地說明公有云的CPU平均利用率遠低于私有云，甚至業界翹楚亞馬遜的AWS和微軟的Azure都只有10%上下，相當于每10臺服務器只有一臺在滿負荷運轉而另外9臺在空轉，而同比私有云環境下的谷歌可以達到30%利用率，更有甚者EMC旗下的Virtustream甚至能達到驚人的70%。

究其原因，公有云較低的IT資源利用率的成因是公有云業務場景的多樣化與負載高度不可預知性。當CPU資源在被分配給某用戶后，如果沒有被該用戶充分利用，就會存在CPU空轉，進而造成事實上的浪費。同樣的問題也存在于其他資源分配上，例如網絡帶寬、磁盤空間等。這是基于時間共享（Time-Sharing）“虛擬化”的必然結果。類似的基于時間共享的技術應用還有很多，比如蜂窩電話網絡。時間共享的原本設計原則就是“公平分配”以確保給服務對象平均分配資源，每個被服務對象在單位時間內可獲取同樣多的資源，但平均主義也會造成在均分資源后因資源被閑置、空轉而形成的事實浪費。

那么如何提高云數據中心的資源利用率呢？從數據中心能耗分布整體而言，每在云主機服務器組件（尤其是CPU）消耗1W，在不間斷電源、空調制冷以及配電箱、變壓器等其他設備就會連帶消耗1.84W。反之，如果能讓CPU少消耗1W，會為整個數據中心節能2.84W（圖1-24是Emerson網絡能源的統計數據）。這種瀑布流式的“級聯”的效應我們稱之為CascadeEffect5（葉柵效應、級聯效應）。服務器組件1.0WDC-DCAC-DC0.49W電力分布UPS0.18W制冷1.07W變壓器、開關設備0.1W圖1-24數據中心能耗級聯效應（CascadeEffect）

數據中心里市電是先通過交流到直流轉換來對儲能系統充電，儲能系統最常見的是UPS電池（或飛輪。圖1-25中列出了儲能系統的三大類，最常見的是電化學儲能方式，即我們常說的UPS電池系統，機械儲能系統也經常被用到，電磁儲能較少見，但未來如果相關技術有所突破，在儲能效率上也會相應提高），UPS再把直流電轉換為交流電對電源分配單元（PDU）供電，在這個二元連續（AC→DC→AC）的轉換過程中電力存在損耗以及生成大量廢熱需要制冷系統工作來降溫，結合圖1-22與圖1-24可知在供電與制冷環節耗費的電力占整個數據中心能耗的10%～47%之多。圖1-25IDC儲能技術分類

如何提高UPS系統效率甚至是找到UPS替代方案是業界的主要努力方向。谷歌的經驗是采用分布式UPS及電池系統直接對服務器機柜進行交流供電，在此過程中僅需要一次交流到直流轉換，由此達到了99.9%的UPS效率，遠高于業界平均的80%～90%。其他常見的做法還有提高UPS到PDU電壓、更新升級UPS電池系統或直接對服務器進行高壓直流輸電等。

UPS替代方式也越來越受到業界的重視。例如使用燃料電池技術或智能電源虛擬化技術等，它們的一個共性是在整個供電過程中不再需要UPS、PDU和變壓器單元，開關設備也變得簡單。圖1-26展示了使用軟件定義的電源技術前后數據中心配電系統的變化。圖1-26軟件定義的電源控制技術

在數據中心中有嚴格的溫度與濕度控制來保證IT設備在最優環境下發揮性能。最新的數據中心以及改造的數據中心中通常都會對冷熱氣流管理（見圖1-27），例如冷通道、熱通道交替排列（見圖1-28）、規范布線（見圖1-29）。圖1-27IDC冷熱氣流管理圖1-28服務器機柜冷熱通道交替排列圖1-29IDC布線管理1.3.2云計算優化要論云數據中心需求側優化的核心是提高IT設備的利用率。提高過程通常分兩步走：（1）IT設備、資源虛擬化（Virtualization）；（2）數據中心云平臺化（CloudPlatformization）。1．IT資源虛擬化云數據中心的基本特點是多租戶（Multi-tenancy），對多租戶場景最好的支持是資源虛擬化。虛擬化的進程業界最早是從服務器虛擬化開始的，緊隨其后的是網絡虛擬化，再之后的是存儲虛擬化，相關的詳細討論可參考筆者的另一部專著《軟件定義數據中心：技術與實踐》。值得指出的是虛擬化是個宏觀的概念，它包括硬件虛擬化，也包括軟件虛擬化，但最終是通過軟件接口與用戶層應用對接，這也是為什么我們稱之為軟件定義的數據中心。

此前我們一直把計算、網絡與存儲稱之為軟件定義數據中心的三大支柱，現在看來應該是四大支柱，還有電源、電力的虛擬化（見圖1-30）。從虛擬化進程完善程度來看四大支柱也是按照計算→網絡→存儲→電源降序排列，越往后挑戰越大，但是市場的機遇也越大。圖1-30軟件定義的數據中心四象限2．IT資源效率優化圍繞著數據中心IT資源的效率優化，特別是提高CPU利用率（或降低CPU能耗）我們可以分為四類技術（見1-31）：動態電壓、頻率調控技術；負載調度技術；服務器集中、能耗狀態轉換技術；熱感知技術。圖1-31IDC節能技術分類（1）動態電壓、頻率調控技術。動態調頻、調壓技術是常見的能耗管理技術，特別是在對多核處理器、DRAM內存管理上，基于CMOS電路的能耗方程如下：

P=Pstatic+CFVV（2）負載調度技術。負載調度技術在所有大型云數據中心的效率博弈中可能是貢獻最大的。它的基本原理非常簡單，但實現起來一點都不簡單——最差的效率當然就是把所有IT設備都打開但是每個設備都處于空轉或低負載運轉的狀態，最優的情況就是讓每個運轉中的設備都達到滿負荷、全速運轉，而其他設備都處于下線、不供電狀態——參考圖1-23。（3）服務器集中與能耗轉換技術。服務器集中與能耗狀態轉換技術通常會與前兩項技術共用來幫助提高資源利用率或降低能耗。一種典型的實踐是在數據中心中使用異構的硬件平臺，也就是說在低負載情況下使用低功耗、低性能系統，當負載增長后再通過任務調度把負載移向高性能系統，這么做的好處很顯然，但是如果發生頻繁的負載、任務遷移，遷移成本也是需要考量的因素；另一類做法會通過智能硬件來監控系統負載，只保留部分IT組件在線而讓其他組件進入睡眠或掉電狀態，比如有些操作只需要內存，那么CPU、硬盤、網絡可以休眠，由此達到節省能耗的目的。（4）熱感知技術。第四類是熱感知技術。在圖1-24中我們介紹過服務器CPU能耗的關聯效應。當CPU運轉時會產生熱能，而機房中的主要熱源來自于運轉的IT設備，為了保證機房的溫度，空調制冷等系統又要耗費更多的電力。如何智能分配負載來保證整體能耗降低是這一類技術的核心理念。一種做法是在刀片機機柜中通過把新增負載加載到現有活躍刀片機而非新啟動一個刀片機柜（刀片機組會共享電源與風扇，啟動新的刀片機組能耗需求會相對更高）來實現低的熱散逸；另一種做法是針對機房當中熱點分布與空調制冷溫度傳感器的相對位置來定向調節在不同位置的服務器的負載以達到節能的目的。3．數據中心云平臺化數據中心云平臺化是資源虛擬化后的為了實現資源管理、調度高度協同的一個必然發展方向，在云的多重形態一節中我們已經介紹了不同的*aaS平臺，在下一節我們會介紹業界建設云平臺的一些最佳實踐，在此就不再贅述。1.4業界如何建云兵法云“知己知彼，百戰不殆”，進入任何陌生領域前了解行業的現狀與趨勢，分析自身的需求、能力與不足，謀定而后動應該是常識。在本節我們會就業界的云計算最佳實踐原則、云計算服務與產品的演進歷程、開源vs.閉源以及云架構與應用間的互動關系等議題展開論述，希望能撥開迷霧，讓讀者對云計算不再陌生，對如何解讀不同云計算流派與實踐不再疑惑。1.4.1云計算最佳實踐五原則擁抱云計算有沒有一些基本原則可以遵循或參考呢？這個問題可以細微到任何一種具體技術的篩選，也可以升華到哲學思考，在起始階段就跳入細枝末節的技術環節討論只會讓人無所適從，過于宏觀的哲學討論又難免不落地，筆者在多年的實踐中總結了五條基本原則與大家分享（見圖1-32），這五條原則互相之間相輔相成，在實踐中可形成閉環。

云計算最佳實踐五原則：結合業務需求來制定云戰略（長期）；避免重蹈業界失敗的經歷；把安全放在第一位；確保性能與數據可用性；定期評估業務發展，調整云戰略+策略。制定戰略借鑒教訓安全第一性能+數據定期評估圖1-32云計算最佳實踐五原則（1）結合需求、制定戰略。任何戰略離不開三件事情：方向（目標）、人（隊伍）、資源（錢、物、關系網、技術儲備），把這三樣東西映射到云計算戰略與最佳實踐上就是人員、流程與技術三寶（見圖1-33）。人員IT部門vs.業務部門云技能培訓服務驅動的文化流程企業云架構管理與規劃端到端服務管理云流程標準化管理技術基礎架構階段性負載承載部署策略、自動化等圖1-33云計算戰略三項指標（2）博采眾長、以史為鑒。（3）安全第一。（4）性能保障與數據可用性。（5）定期評估業務發展并相應調整云發展戰略。圖1-34中把數據按照訪問需要的頻繁性與迫切性分為四類：熱數據、暖數據、冷數據與備份數據。圖1-34數據熱度：熱、暖、冷、備份Hot熱數據Warm暖數據Cold冷數據Archive備份數據1.4.2云服務與產品的演進了解云計算服務、產品與解決方案的演進歷程可以從服務提供方或需求方入手。以服務需求方為例，業務需求出發點的不同導致選擇云計算解決方案的切入點不同，我們以不同類型的XaaS作為切入點（見圖1-35），對于某些用戶而言提供遠程桌面、瘦客戶端（取代現有PC主機、筆記本電腦）是日常辦公云化的第一步，而其他用戶，特別是一些對于流程較注重的公司可能會從購買SaaS化的辦公自動化系統、CRM或ERP系統入手。IaaS資源虛擬化數據服務遠程桌面、瘦客戶端PaaS服務集成CI/CDDevopsSaaS最終應用OA/CRM/ERP/科研云圖1-35云服務、云產品的演進

研發型機構或IT公司接入云的方式則更有可能是直接購買虛擬化的IaaS資源，如云主機、云數據庫服務等（當然，對于部門內、部門間協同工作要求較高的機構，也可能會從類似于白板、通信錄、日歷、庫存、訂單管理、共享桌面等服務切入。這一類服務都被冠以“科研云”的名頭，實質上是不折不扣的SaaS服務）。DevOps無論是從底層的IaaS還是從上層的SaaS接入云，它們都會向中間層的PaaS平臺演進。PaaS提供的核心服務可以分為兩大類：集成化的服務（部署、維護、升級、兼容性管理、服務目錄等）；一體化開發+運維（DevOps）、持續集成、持續部署（CI/CD）。

如果從云的基本屬性角度出發，云服務提供商（建設者）與云的客戶（使用者）的訴求有不同的演進階段。前者通常把基礎架構、平臺、服務與應用的彈性放到第一位，而后系統健壯性，再之后是各項性能指標的提高，最后會提高安全性；而對于后者通常在進入云初期，低成本是第一考量，彈性、敏捷性、可伸縮性緊隨其后，再之后是健壯性與安全性。兩者的優先級看似有很大差異，實則對立統一（見圖1-37）。開發測試運維圖1-36DevOps的三位一體

它們是云計算發展過程中，從早期階段到逐漸成熟過程中必然經歷的，本節開始引用的Gartner對2018年安全性成為云計算考量的首要因素正是云逐漸趨于成熟的標志之一。在性價比、彈性、敏捷性、健壯性、性能這些難題都已經被攻克后，安全問題一定會被提上議事日程。彈性健壯性性能安全性成本彈性/安全健壯性……圖1-37云建設的演進歷程：提供方vs.需求方

對于云的彈性（Elasticity）有幾個重要的衡量指標。提供資源所需的時間（ProvisioningTime）。提供可伸縮資源的全面性—左右水平、上下垂直、計算、網絡、存儲、服務及應用等。對于彈性資源的監控粒度。傳統的監控方式的顆粒度是基于物理機或虛擬機的資源組件（如Nagios、Ganglia等），但是在云計算框架下對于一個可能跨越了多個物理機、虛機或容器的應用或服務而言，對其監控的復雜度大增，需要在對整個應用或服務的各項指標做綜合甚至是加權計算后呈現給用戶。

資源供應的準確性，避免過度供應（Over-Provisioning）或供應不足（Under-Provisioning）。云的性能評測（PerformanceBenchmark）可以從多個維度展開。傳統指標的評測：CPU/VCPU、網絡、磁盤吞吐率指標。云化工作負載（Workloads）性能評測：如數據庫、大數據或某個具體應用的性能（吞吐率、啟動速度等）評測。其他功能的支持及指標：如是否支持實時的塊數據復制（SANReplication）、系統的IOPS（每秒讀寫操作次數）、對傳統應用向云遷移的支持、云內及跨云數據遷移速度等。云原生應用云原生應用（CloudNativeApplications）又被稱為云本地應用，具有五大特點（如圖1-38所示）。（1）MSA（Micro-ServiceArchitecture，微服務架構）。MSA微服務架構云應用十二要素自服務敏捷架構基于API的協作面向故障的設計圖1-38云本地（原生）應用的五大特點

MSA是云本地應用的最重要的特點，它源自于SOA（ServiceOrientedArchitecture，面向服務的架構），可以認為是SOA整體框架中的一部分，在云化的過程中逐漸演變為各個云組件之間通過可獨立部署的服務接口來實現通信。圖1-39形象地展示了傳統獨立應用與微服務架構應用間的差異。獨立應用是一個“大包大攬”的整體，每一個應用進程（Process）會把多個功能集成在一起，獨立應用的擴展也是以應用進程為單位擴展到多臺主機上；而微服務的最大區別在于把每一個功能元素作為一個獨立的服務，這些服務可以部署在不同的主機上，每個服務只要保證通信接口不變，它們可以各自獨立進化。圖1-39Monolithicvs.Mirco-Service（2）云應用12要素。12-FactorApplication（云應用12要素）是業界被廣泛引用的CNA類型應用的通用特點，由AdamWiggins在2012年提出。他總結了CNA的12要素：單代碼庫多次部署、明確定義依賴關系、在環境中存儲配置、后端服務作為附加資源、建設發布及上線運行分段、以無狀態進程來運行應用、通過端口綁定來暴露服務、通過進程模型擴展來實現并發、通過快速啟動與優雅終止來實現最大化健壯性、開發環境=線上環境、日志=事件流、后臺管理任務=一次性進程。以上12要素在業界被廣泛引用，有些人甚至稱之為建設與運行云應用最佳實踐的金標準。（3）自服務敏捷基礎架構。自服務敏捷基礎架構（Self-ServiceAgileInfrastructure）的概念最早由筆者的同事MattStine在他2015年的MigratingtoCloud-NativeApplicationArchitectures11一書中提出，自服務敏捷架構的另一個叫法是PaaS（平臺即服務），它幫助程序員完成四件事情：自動化、按需的應用實例伸縮（Automated&On-demandScaling）；應用程序健康管理（HealthManagement）；對應用實例訪問的自動路由與負載均衡（Routing&Load-Balancing）；對日志與度量數據的集結（Aggregation）。（4）面向API的協作模式。面向API的協作模式是在完成向微服務架構、12要素應用建設、自服務敏捷基礎架構三大模式轉變過程中必然出現的新型協同工作模式。傳統的協同開發模式是基于應用部件間的方法調用（MethodCalls），而在云架構中，更多的是通過調用某種APIs的方式來實現組件間的通信，而API版本之間的兼容關系通過版本號來定義與協調，RESTAPIs12就是一種非常流行的方式——它也是整個WWW的軟件架構標志性風格——無獨有偶，REST的作者RoyFielding在他的博士答辯論文中對RESTfulAPI進行了定義，而他同時也是HTTP/1.113的主要作者。（5）面向故障。面向故障（Anti-fragile-DesignforFailure）是云計算彈性與敏捷性的終極體現，在遵循微服務架構、12要素、自服務、面向API的設計原則下，云本地應用可以做到零下線時間，也就是說在故障甚至災難發生時系統有足夠的冗余來確保服務保持在線。業界最著名的面向故障的實踐案例是Netflix工程師為了測試他們在亞馬遜AWS上的服務的健壯性而開發的一套叫作ChaosMonkey14的開源軟件——它會發現并隨機終止系統中的云服務，以此來測試系統的自我恢復能力。

云的發展過程就像一次旅程（見圖1-40）。為了提供云服務，就需要改造現有的數據中心（傳統數據中心，ConventionalData-Center）。在傳統數據中心內，計算、網絡和存儲等資源通常專供各個業務單元或應用程序使用，這會導致管理復雜以及資源非充分利用。圖1-40云之旅：從傳統DC到SDDC

在本小節最后，我們再從云的形態入手來分析云的演變歷程，通常一條完整的進化曲線（見圖1-41）是：從數據中心（無論是場內還是場外）到私有云，再到公有云，最終演化為混合云。不同的機構和組織進入云的切入點可能會因需求與能力的差異而不同，無論是從相對原始的傳統數據中心開始還是從私有云或公有云服務切入，獲取云服務通常不會以一種單一的云形態來獲得，個中原因值得深思。圖1-41云的演進歷程：私有→公有→混合1.4.3開源開源技術棧所謂LAMP是B/S（Browser/Server）和C/S（Client/Server）技術的四大代表性開源技術的首字母連寫，鑒于LAMP技術是如此重要，我們在此要對它們做個概覽。圖1-42全球Web服務器市場份額Jan2016圖1-43數據庫流行趨勢：商業vs.開源圖1-44編程語言流行趨勢（2004—2016年）圖1-45LAMP體系架構概覽圖1-46AWSEC2的十年增速發展歷程開源vs.閉源自打亞馬遜在2006年打開了云計算的“潘多拉之盒”，整個IT行業過去十年的發展可以用風起云涌來概括，大到行業巨頭，小到初創公司太多人投身其中。筆者梳理了云計算的十年旅程，發現由開源與閉源（商業）兩大陣營的博弈貫穿始終，對兩大陣營的廠家與云產品按照“神奇四象限”（MagicQuadrant）的分類把它們放置于商業+巨頭、商業+小散（中小企業）、開源+小散以及開源+巨頭四個象限之內，如圖1-47所示。這張圖囊括了云計算領域里產品非常具有代表性的廠家。圖1-47云計算廠家（及產品）魔力四象限

由圖1-47還可以看出云計算的玩家主要集中在右上角的第一象限—它們的產品與服務的形態以大公司推出的商業化產品+服務（無論是否依賴開源項目）為主；而第二、三、四象限則略顯冷清（稍后我們來分析為什么開源與中小企業在云計算領域往往流于雷聲大雨點?。?。如果我們再換個維度來看云計算生態系統的演變，會發現業界的收購與聯盟從來沒有停止過（見圖1-48）。圖1-48云計算生態系統演變：收購、聯盟

結構化PaaS-CloudFoundry非結構化PaaS–Kubernetes典型用戶群體大中型企業、機構互聯網、創業型企業云形態公有或私有云公有或私有云ServiceBroker（服務經紀人）平臺內置需要定制開發可直接訪問容器工具容器被平臺抽象化容器服務可直接訪問應用感知與工作臺（Awareness/Staging）平臺內置需要定制開發內置負載均衡是不是可替換組件很少很多日志與監控平臺內置需定制開發、第三方提供平臺管理工具是，通過Bosh部分繼承用戶管理是不是對Windows平臺支持是不是網絡限流支持不是是鏡像支持（ImageSupport）是是應用為單位的擴展是-容器為單位的擴展-是架構比較平臺組件–Garden,Converger,BBS,Router,Buildpack,Loggregator等第三方提供–Docker,Mesos,etcd,cAdvisor等表1-4 結構化PaaSvs.非結構化PaaSL.A.M.PAWSEC2（Amazon）Eucalyptus（HP）CloudStack（Citrix/ASF）OpenStack（Rackspace）OpenShift（RedHat）CloudFoundry（EMC）Docker（dotCloud）CoreOSMesos（Mesosphere/ASF）Kubernetes（Google）Unikernels（Docker）圖1-49云計算發展歷程LAMP→IaaS→PaaS→CaaS云計算與大數據

TheEssentialCriteriaofBigData&CloudComputing第二章揭秘大數據2.1大數據從何而來？2.1.1大數據的催化劑催化劑有三—社交媒體、移動互聯網與物聯網（見圖2-1）。社交媒體移動互聯網物聯網圖2-1大數據的三大催化劑（1）社交媒體。社交媒體（SNS，SocialNetworkingService或SocialNetworkingSite）的雛形應該是BBS（BulletinBoardSystem，電子公告牌系統），最早的BBS是1973年在美國加州舊金山灣區出現的CommunityMemory系統，當時的網絡連接是通過Modem遠程接入一款叫作SDS940的分時處理大型機來實現的。中國最早的BBS系統經歷了從1992年的長城站，到后來的惠多網（據說惠多網的用戶中有中國最早一批本土互聯網創業者—馬化騰、求伯君、丁磊等）到1994年中科院網絡上建立的真正意義上的基于互聯網的BBS系統—曙光站，而同時在線超過100人的第一個國內大型BBS論壇則是長盛不衰的水木清華，而它的起因大抵是因為清華的同學們對于連接隔壁中科院的曙光站竟然要先從中國教育網跑到太平洋彼岸的美國再折返回中科院網絡表示憤懣，于是自立門戶成立的水木清華站—它最早是在一臺386PC上提供互聯網接入服務的。

表2-1列出了常見的社交媒體與互聯網服務的每秒鐘交易（或服務完成）數量。每秒鐘社交媒體所提供服務數量數目2016春節期間微信紅包120,000Tweets7,112Instagram圖片上傳數1,132Tumblr發貼數目1,500Skype通話數2,027互聯網流量（GB）33,000谷歌搜索次數53,000YouTube視頻觀看次數116,950電子郵件發送數2,466,550表2-1 全球互聯網流量分析與預測（2）移動互聯網。移動互聯網是互聯網的高級發展階段，也是互聯網發展的必然。移動互聯網是以移動設備，特別是智能手機、平板電腦等移動終端設備全面進入我們的生活、工作為標志的。最早的具備聯網功能的移動終端設備是1990年代中期開始流行的PDA（PersonalDigitalAssistant）。遺憾的是市場更新迭代的速度如此之快，在短短10年后，PDA操作系統三大巨頭Palm、BlackBerry與MicrosoftWindowsCE，外加最早的手機巨頭Nokia就已經讓位于真正的智能手機操作系統后起之秀—AppleiOS與Android。

據統計從1992年開始到2019年，整個互聯網數據流量的增長將達到驚人的四千五百萬倍（見圖2-2）—從1992年的每天100GB（1992年是硬盤剛進入1GB的時代，每天100GB的互聯網數據流量就相當于全世界每天交換了100塊硬盤之多的數據）；1997年這一數據增長24倍，平均每小時100塊1GB硬盤，而同一時期的硬盤容量增長到了16～17GB；1997—2002年，是互聯網猛烈增長的5年，迅速達到了100GB/s的水平，而同一年硬盤尋址空間剛剛突破137GB的限制；2007年又增長了20倍到達了2,000GB/s的水平，同年Hitachi也推出了第一塊1TB（1,000GB）容量的硬盤；2014年的互聯網流量已經突破16TB/s，無獨有偶，Seagate也在同年發布了業界第一款8TB的硬盤，預計2019年的網絡流量則會達到52TB/s—從任何一個角度看，網絡流量的增速都超過了單塊硬盤的擴容速度，這也從另一個側面解釋了為什么我們的IT基礎架構一直處于不斷的升級、擴容中—大（量）數據聯網交換的需求推動所致！（3）物聯網。物聯網（InternetofThings，IoT）5的起源可以追溯到1999年，當時在P&G工作的英國人KevinAshton最早冠名使用了IoT字樣，同一年他在MIT成立了一個旨在推廣RFID技術的Auto-ID中心，而對于P&G來說最直接的效益就是利用RFID技術與無線傳感器的結合可以對其供應鏈系統進行有效的跟蹤與管理。中國人對物聯網的熟知應當是2009年，先是國務院總理對無錫物聯網科技產業園區的考察而后是總理的一篇面向首都科技界《讓科技引領中國可持續發展》的講話。

有一種提法認為繼移動互聯網之后，IT行業最高速的增長會在物聯網領域，有一些統計數據表明到2019年超過2/3的IP數據會從非PC端設備產生，如互聯網電視、平板電腦、智能手機以及M2M（Machine-to-Machine）傳感器。IDC預測到2020年會有300億物聯網設備，而整個生態系統會是一個17,000億美元的巨大市場。Cisco預測到2020年物聯網設備會有500億之多，而Intel、IDC與聯合國的另一預測則樂觀地估計屆時會有超過2,000億物聯網設備。圖2-2CiscoVNI全球互聯網流量分析與預測

社交媒體、移動互聯網、物聯網三大催化劑讓數據量在過去幾十年間呈指數級增長，除此以外數據的產生速率以及數據的多樣性與復雜性都在隨之增長—數據的這三大特性—數量（Volume）、速率（Velocity）與多樣性（Variety），我們通常稱之為大數據的3V。如果再考慮到數據來源的可靠性與真實性（Veracity）以及數據的價值（Value），可以把3V擴展到5V，不過通常業界對于數據的價值的定義有很多主觀因素在里面，因此業界通常都習慣引用IBM最早提出的大數據的4V—TheFourV’sofBigData7，如圖2-3所示。圖2-3大數據的四大特征（4V'sofBigData）2.1.2Data→BigData→Data在本小節讓我們來回顧一下大數據從何而來，大數據作為一門技術有哪些分支與流派?？v觀人類發展史，圍繞著信息的記錄、整合、處理與分析的方式、手段與規模，筆者按圖2-4所示分為六個階段。上古時代–十八世紀結繩記事、古典統計學、人口統計學、流行病學十九世紀中葉最早的眾包WWII-1980年代Enigma,電子計算機，數據庫1990-2004PC時代，商務智能，數據倉庫2004-2014移動互聯時代，GFSHADOOP;NOSQL/NewSQL2014-?物聯網時代，機器學習、深度學習、人工智能圖2-4數據到大數據再到數據的發展歷程（1）上古時代—18世紀。漢朝人鄭玄在《周易注》中說：“古者無文字，結繩為約，事大，大結其繩；事小，小結其繩?！痹谟〖游幕斨幸灿薪Y繩記數的實例，并且有學者發現印加繩的穿系方法與中國結驚人的一致，或為兩種文明存在傳承關系的證據之一（見圖2-5）。圖2-5中國古代結繩記事與文字vs.印加Khipu（記簿）繩（2）19世紀中葉人類采集數據，處理數據，分析數據，從中獲得信息并升華為知識的實踐從來沒有停止過，只是在形式上從早期人類的原始會計學，發展到3個世紀前的古典統計學。時光再向前走到19世紀中葉—出現了最早的眾包（Crowdsourcing）—1848年到1861年間美國海軍海洋學家、天文學家MatthewF.Maury通過不斷地向遠航的海員們提供數以十萬張計的免費的季風與洋流圖紙并以海員們返回后提供詳細的標準化的航海日記作為交換條件整理出了一整套詳盡的大西洋-太平洋洋流與季風的圖紙（見圖2-6）。圖2-6MatthewF.Maury繪制的大西洋-太平洋洋流與季風圖（1841）局部（3）第二次世界大戰—20世紀80年代。19世紀的眾籌的力量雖然巨大，但在數據處理的方式上還限于手工整理，真正的電子數字可編程計算機是第二次世界大戰后期在英國被發明的，盟軍為了破解以德國為首的軸心國的軍用電報密碼—尤為著名的是EnigmaMachines—一款典型的民用轉軍用密碼生成設備，在一個有6根引線的接線板上一對字母的可互換可能性有1,000億次，而10根引線的可能性則高達150萬億次。對于如此規模的海量數據組合可能性，使用人工排序來暴力破解的方式顯然不會成功，甚至是使用電動機械設備（ElectromagneticalDevice，電子計算機的前身）效率也遠遠不夠。

英國數學家圖靈（AlanTuring）在1939—1940年通過他設計的電動機械設備Bombe來破解納粹不斷升級優化的Enigma密碼時意識到了這一點，于是在1943年找到了另一位英國人TommyFlowers，僅用了11個月的時間，1944年年初Flowers設計的Colossus計算機面世并成功破解了最新的德軍的密碼（見圖2-7，從左到右分別是：Enigma機器的接線板，圖靈設計的Bombe解密設備，Flowers設計的Colossus真空管電子計算機）。每臺Colossus計算機的數據處理是每秒鐘5,000個字符，送紙帶（PaperTape）以12.2m/s的速度高速移動，并且多臺Colossus可以并行操作—我們今天稱之為“并行計算”。圖2-7Enigmavs.Bombevs.Colossus

20世紀50—70年代是計算機技術飛速發展的20年，從50年代中期開始出現的基于晶體管（Transistor）技術的晶體管計算機到60年代的大型主機（Mainframes）到70年代的小型機（Minicomputers）的出現，我們對數據的綜合處理能力、分析能力以及存儲能力都得到了指數級的增長。而數據分析能力的提高是與對應的數據存儲能力的提升對應的，在軟件層面，最值得一提的是數據庫的出現。數據庫可以算作計算機軟件系統中最為復雜的系統，數據庫的發展從時間軸上看大體可分為四大類：

NavigationalDatabase（導航型數據庫）；RelationalDatabase（關系型數據庫）；ObjectDatabase（面向對象型數據庫）；NoSQL/NewSQL/Hadoop（大數據類新型數據存儲與處理方式）。

Navigational數據庫是20世紀60年代隨著計算機技術的快速發展而興起的，主要關聯了兩種數據庫接口模式—NetworkModel和HierarchicalModel。關系型數據庫（RDBMS）自20世紀70年代誕生以來在過去四十幾年中方興未艾，也是我們今天最為熟知的數據庫系統類型。

對象數據庫的興起滯后于關系數據庫大約10年。對象數據庫的核心是面向對象，它的誕生是借鑒了面向對象的編程語言的OO特性來對復雜的數據類型及數據之間的關系進行建模，對象之間的關系是多對多，訪問通過指針或引用來實現。通常而言OO類語言與OO型數據庫結合得更完美，以醫療行業為例Object數據庫的使用不在少數，合理使用的話也會效率更高（例如InterSystems的Caché數據庫）。

大數據類新型數據庫確切地說是在數據爆炸性增長（數量、速率、多樣性）條件下為了高效處理數據而出現的多種新的數據處理架構及生態系統，簡單而言有三大類：NoSQL；Hadoop；NewSQL。（4）20世紀90年代。20世紀90年代初，PC與互聯網進入了全方位高速發展階段。1977年到2007年的三十年間，PC銷售量增長到最初的2,600倍（從1977年的5萬臺，增長到2007年的1.25億臺）。（5）21世紀第一個10年。過去的十年則讓我們見證了移動互聯時代的到來，以谷歌、Facebook、Twitter、BAT為代表的新互聯網公司的興起。這些新型的互聯網企業在搭建技術堆棧的時候有兩個共通之處：LAMP+PC-Cluster。（6）當下，移動互聯時代。移動互聯時代的自然延伸就是我們今天所處在的萬物互聯時代（InternetofThings或InternetofEverything）。十幾年前被學術界宣判已經走入死胡同的人工智能（ArtificialIntelligence）在機器學習（MachineLearning）、深度學習（DeepLearning）等技術的推動下又在諸如圖像視頻、自然語言處理、數據挖掘、物流、游戲、無人駕駛汽車、自動導航、機器人、輿情監控等很多不同的領域獲得了突破性的進展，其中值得一提的是谷歌的一款AI程序AlphaGo在2015年年底和2016年年初分別擊敗了歐洲圍棋冠軍職業二段選手樊麾以及韓國著名棋手李世石。這也標志著人工智能正在大步幅逼近甚至在不遠的未來超越人類大腦的海量信息處理與預判能力。

數據的完整生命周期可分為五個階段，如圖2-8所示。通過對雜亂無章的數據整理得到信息，對信息提煉而成為知識，知識升華后成為（人類）可傳承的智慧，人類又把智慧、知識與信息演變為可以賦予機器的智能。圖2-8從數據到智能

我們回顧一下人類的發展史可以說是圍繞著信息整合、處理的方式與手段在不斷發展，我們一步步走向大數據，而當大數據成為常態的時候，大數據已經無處不在融入了我們的生活（見圖2-9）。圖2-9中列出了已經或正式應用的大數據行業。這也是我們常說的（Big）Data-DrivenBusinesses（數據驅動的商業）。圖2-9大數據無處不在2.1.3大數據不只是Hadoop認知誤區：大數據就是Hadoop。這種論調似乎在業界頗有市場，因為Hadoop真的很火爆，盡管許多人并不清楚Hadoop到底是什么，可以用來做什么，但是如果某種大數據技術不和Hadoop沾邊兒，客戶、投資人甚至自己的團隊可能都會對該技術的前景持遲疑的態度。首先我們需要了解大數據處理的發展歷程中形成了哪些主要的流派與生態系統。從20世紀90年代到今天，面向海量數據的處理與分析經歷了如下的3個主要階段。關系型數據庫一統天下的時代（1990—現今）。Hadoop與NoSQL并駕齊驅的時代（2006—現今）。NewSQL橫空出世的時代（2010—現今）。圖2-10展示了這四大類大數據技術沿時間橫軸的發展歷程。（1）關系型數據庫時代。（2）Hadoopvs.NoSQL時代。（3）NewSQL時代。圖2-10大數據技術三大流派NoSQL、Hadoop、NewSQL2.2大數據的五大問題當傳統的方法已無法應對大數據的規模、分布性、多樣性以及時效性所帶來的挑戰時，我們需要新的技術體系架構以及分析方法來從大數據中獲得新的價值。McKinseyGlobalInstitute在一份報告中9認為大數據會在如下幾個方面創造巨大的經濟價值。

通過讓信息更透明以及更頻繁被使用，解鎖大數據價值。通過交易信息的數字化存儲可以采集更多更準確、詳細的數據用于決策支撐。通過大數據來細分用戶群體，進行精細化產品、服務定位。深度的、復雜的數據分析（及預測）來提升決策準確率。通過大數據（反饋機制）來改善下一代產品、服務的開發。

規劃大數據戰略、構建大數據的解決方案與體系架構、解決大數據問題以及大數據發展歷程中通常會依次涉及大數據存儲、大數據管理、大數據分析、大數據科學與大數據應用等五大議題，如圖2-11所示。大數據存儲大數據管理大數據分析大數據科學大數據應用圖2-11大數據需要觸及的五大問題2.2.1大數據存儲從19世紀開始到今天的近200年間，按時間軸順序，數據存儲至少經歷了如下5大階段，并且這些技術直到今天依然在我們的生活中隨處可見。穿孔卡（PunchedCard）磁帶機（MagneticTape）磁盤（MagneticDisk）光盤（OpticalDisc）半導體內存（SemicoductorMemory）

傳統意義上，按照馮·諾依曼計算機體系架構（VonNeumannArchitecture）的分類方式，我們通常把CPU可以直接訪問的RAM類的半導體存儲稱為主存儲（PrimaryStorage）或一級存儲；把HDD、NVRAM類的稱為輔助存儲或二級存儲（AuxiliaryorSecondaryStorage）；而三級存儲（TertiaryStorage）則是通常由磁帶與低性能、低成本HDD構成；最后一類存儲則稱為Off-lineStorage（線下存儲），包括光盤、硬盤以及磁帶等可能組合方式。PunchedCards1952IBM711180bit/sMagneticTape1951UNIVAC12800bit/sHDD/FDD1956IBM350R6600B/sCD/DCD1979Philips/Sony1.17Mb/sFlash/SSD1991SanDisk100MB/s圖2-12數據存儲介質發展歷程

前面我們以時間軸為順序了解了存儲介質的發展歷程，在業界我們通常還會按照數據存儲的其他特性來對一種存儲介質進行定性、定量分析，例如數據的易失性、可變性、各項性能指標、可訪問性等（見圖2-13）。Addressability可訪問性地址訪問文件訪問內容訪問Performance性能延遲吞吐率（MB/s）故障率（MTBF）顆粒度（bit/page/block）Mutability可變性可讀寫（CD-RW）只讀（ROM,CD-R）快讀慢寫Volatility易失性易失性（RAM）非易失性（NVRAM）圖2-13數據存儲特性之四維度

另外，存儲逐漸由早期的單主機單硬盤存儲發展為單主機多硬盤、多主機多硬盤、網絡存儲、分布式存儲、云存儲、多級緩存+存儲以及軟件定義的存儲等形式。在存儲的發展過程中有大量為了提高數據可訪問性、可靠性、吞吐率以及節省存儲空間或成本的技術涌現：RAID（磁盤陣列）技術；NAS（網絡附屬存儲）技術；SAN（高速存儲網絡）技術；Dedup（去重）技術、壓縮、備份、鏡像、快照技術等；軟件定義存儲（SoftwareDefinedStorage，SDS）技術。RAID磁盤陣列技術RAID（RedundantArrayofInexpensiveDisks），顧名思義，是用多塊便宜的硬盤組建成存儲陣列來實現高性能或（和）高可靠性。從這一點上看，早在1987年由UCBerkeley的DavidPatterson教授（David也是RISC精簡指令集計算機概念的最早命名者）和他的同事們率先實現的RAID架構與十幾年后的互聯網公司推動的使用基于X86的商用硬件來顛覆IBM為首的大、小型機體系架構是如出一轍的—單塊硬盤性能與穩定性雖然可能不夠好，但是形成一個水平可擴展（scale-out）的分布式架構后可以做到線性提高系統綜合性能。

奇偶校驗位的計算使用的是布爾型異或（XOR）邏輯操作，如下所示。如果盤A或B因故下線，剩下的B或A盤與Parity數據做簡單的XOR操作就可以恢復A或B盤。

DriveA：

01011010XOR DriveB：

01110101 Parity：

00101111NAS與SAN網絡存儲技術如NAS、SAN是相對于非網絡存儲技術而言的。在NAS、SAN出現之后我們把先前的那種直接連接到主機的存儲方式稱為DAS（DirectlyAttachedStorage，直連存儲或內部存儲）。NAS與SAN先后在20世紀80年代中期與90年代中期由SunMicrosystems推出最早的商業產品，它們改變了之前那種以服務器為中心的存儲體系結構（例如各種RAID，盡管RAID系統也是采用塊存儲），形成了以信息為中心的分布式網絡存儲架構（見圖2-14），NAS與SAN的主要區別如下。NAS提供了存儲與文件系統。SAN提供了底層的塊存儲（上面可以疊加文件系統）。NAS的通信協議主要有NFS/CIFS/SMB/AFP/NCP，它們主要是在NAS發展過程中由不同廠家開發的協議：Sun開發并開源的NFS，微軟的SMB/CIFS，蘋果開發的AFP以及Novell開發的NCP。SAN在服務器與存儲硬件間的通信協議主要是SCSI，在網絡層面主要使用FibreChannel（光纖通道）、Ethernet（以太網）或InfiniBand（無限寬帶）協議堆棧來實現通信。

SAN的優勢如下。網絡部署容易，服務器只需要配備一塊適配卡（FCHBA）就可以通過FC交換機接入網絡，經過簡單的配置即可使用存儲。高速存儲服務。SAN采用了光纖通道技術，所以它具有更高的存儲帶寬，對存儲性能的提升更加明顯。SAN的光纖通道使用全雙工串行通信原理傳輸數據，傳輸速率高達8～16Gbit/s。良好的擴展能力。由于SAN采用了網絡結構，擴展能力更強。

NAS的優點如下。真正的即插即用：NAS是獨立的存儲節點存在于網絡之中，與用戶的操作系統平臺無關。存儲部署簡單：NAS不依賴通用的操作系統，而是采用一個面向用戶設計的、專門用于數據存儲的簡化操作系統，內置了與網絡連接所需要的協議、因此使整個系統的管理和設置較為簡單。共享的存儲訪問：NAS允許多臺服務器以共享的方式訪問同一存儲單元。管理容易且成本低（相對于SAN而言）。圖2-14本地存儲→網絡存儲對象存儲分布式存儲（DistributedStorage）架構中除了NAS與SAN兩大陣營，還有一大類叫作Object-basedStorage（基于對象的存儲）—對象存儲出道又比SAN大概晚了8～10年。與基于文件（File）的NAS和基于塊（Block）的SAN不同，對象存儲的基本要素是對存儲數據進行了抽象化分隔，將存儲數據分為源數據（Rawdata）與元數據（Metadata）。應用程序通過對象存儲提供的API訪問存儲數據實際上可看作是對源數據與元數據的訪問。

一種流行的觀點是對象存儲集合了NAS與SAN的優點，不過對象存儲具有NAS、SAN所不具有的如下3點優勢：應用可對接口直接編程；命名空間（尋址空間）可跨多硬件實體，每個對象具有唯一編號；數據管理顆粒細度為對象。軟件定義存儲技術在這樣的背景下，一種新的存儲管理模式開始出現，這就是軟件定義的存儲（SDS）。SDS不同于存儲虛擬化（StorageVirtualization），SDS的