你好，我是徐文浩。

在正式開始解讀一篇篇論文之前，我想先讓你來回答一個問題，那就是“大數據”技術到底是什麼呢？處理100GB數據算是大數據技術嗎？如果不算的話，那麼處理1TB數據算是大數據嗎？

“大數據”這個名字流行起來到現在，差不多已經有十年時間瞭。在這十年裡，不同的人都按照自己的需要給大數據編出瞭自己的解釋。有些解釋很具體，來自於一線寫Java代碼的工程師，說用Hadoop處理數據就是大數據；有些解釋很高大上，來自於市場上靠發明大詞兒為生的演說傢，說我們能采集和處理全量的數據就是大數據，如果隻能采集到部分數據，或者處理的時候要對數據進行采樣，那就不是大數據。

其實，要想學好大數據，我們需要先正本清源，弄清楚大數據在技術上到底涵蓋瞭些什麼。所以今天這節課，我就從大數據技術的核心理念和歷史脈絡這兩個角度，來帶你理解下什麼是大數據技術。

通過理解這兩點，你就會對大數據技術有一個全面的認識。而這個認識，一方面呢，能讓你始終圍繞著大數據技術的核心理念，去做好技術開發工作，不至於跑偏；而另一方面呢，它能幫你在學習後面每一個知識點的時候，都能和其他部分建立聯系，幫你加深對大數據技術的理解。

好瞭，那麼下面，我們就先來一起看看，大數據的核心理念是什麼。

大數據技術的核心理念

首先，讓我們來看看Wikipedia裡是怎麼定義它的。“大數據”是指傳統數據處理應用軟件時，不足以處理的大的或者復雜的數據集的術語。換句話說，就是技術上的老辦法行不通瞭，必須使用新辦法才能處理的數據就叫大數據。不過，這個定義似乎也是一個很模糊的描述性的定義，並沒有告訴我們到底哪些技術算是“大數據”技術的范疇。

那麼，在我看來，其實“大數據”技術的核心理念是非常清晰的，基本上可以被三個核心技術理念概括。

第一個，是能夠伸縮到一千臺服務器以上的分佈式數據處理集群的技術。

在“大數據”這個理念出現之前，傳統的並行數據庫技術就已經在嘗試處理海量的數據瞭。比如成立於1979年的Teradata公司，就是專門做數據倉庫的。從公司名字上，你也能看出來那個時候他們就想要處理TB級別的數據。但是，這些並行數據庫的單個集群往往也就是幾十個服務器。

而在2003年Google發表瞭GFS的論文之後，我們才第一次看到瞭單個集群裡就可以有上千個節點。集群規模有瞭數量級上的變化，也就把數據處理能力拉上瞭一個新的臺階。因為集群可以伸縮到上千，乃至上萬個節點，讓我們今天可以處理PB級別的數據，所以微信、Facebook這樣十億級別日活的應用，也能不慌不忙地處理好每天的數據。

當然，這個數量級上的變化，也給我們帶來瞭大量新的技術挑戰。而解決瞭這些挑戰的種種技術方案，就是我們的“大數據”技術。

第二個，是這個上千個節點的集群，是采用廉價的PC架構搭建起來的。

事實上，今天跑在數據中心裡的各個大數據集群，用的硬件設備和我拿來寫這節課的筆記本電腦本質上是一樣的。可能數據中心裡的CPU強一點、內存大一點、硬盤多一些，但是我完全可以用幾臺傢裡的電腦組一個一樣的集群出來。

在“大數據”技術裡，不需要使用“神威·太湖之光”這樣的超算，也不用IBM的大型機或者Sun公司的SPARC這樣的小型機，同樣也不需要EMC的專用存儲設備。“大數據”技術在硬件層面，是完全架設在開放的PC架構下的，這就讓任何一個新創的公司，都能夠很容易地搭建起自己的集群。

而且，由於不需要購買昂貴的專屬硬件或者存儲設備，所以大數據技術很容易地在大大小小的公司之間散播開來，任何一個有興趣的程序員都可以用自己的PC開發、測試貢獻代碼，使得整個技術的生態異常繁榮。

最後一個，則是“把數據中心當作是一臺計算機”（Datacenter as a Computer）。

要知道，“大數據”技術的目標，是希望對於開發者來說，TA意識不到自己面對的是一個一千臺服務器的集群，而是一臺虛擬的“計算機”。使用瞭部署好的大數據的各種框架之後，開發者能夠像面對單臺計算機編程一樣去寫自己的代碼，而不需要操心系統的可用性、數據的一致性之類的問題。

所有的“大數據”框架，都希望就算沒有“大數據”底層技術知識的工程師，也能很容易地處理海量數據。

大型集群讓處理海量數據變得“可能”；基於開放的PC架構，讓處理海量數據變得“便宜”；而優秀的封裝和抽象，則是讓處理海量數據變得“容易”。這也是現在誰都能用上大數據技術的基礎。可以說，這三個核心技術理念，真正引爆瞭整個“大數據”技術，讓整個技術生態異常繁榮。

大數據技術的來龍與去脈

看到這裡，你可能要問瞭，這三個核心技術理念是從哪裡來的呢？這些理念當然不是“機械降神”，憑空出現的。

事實上，可以說整個“大數據”領域的蓬勃發展，都來自於Google這傢公司遇到的真實需求。我們今天看到的“大數據”技術，十有八九，都來自於Google公開發表的論文，然後再演變成一個個開源系統，讓整個行業受益。可以說，Google是“大數據”領域的普羅米休斯。

而在這個過程中，整個技術的發展也並不是一個直線上升的狀態：

• 有爭論，比如MapReduce的論文發表之後，數據庫領域知名的科學傢大衛·德維特（David DeWitt）就發表過一篇論文“MapReduce：A major step backwards”，抨擊MapReduce相比於並行數據庫是一種倒退；
• 有妥協，比如，Bigtable不支持單行事務也不支持SQL，就是一個明證。直到5年後發表的MegaStore，他們才開始著手解決這兩個問題；
• 更有不成功的嘗試，典型的就是Sawzall和Pig，Google在發表MapReduce論文之前，就發表瞭Sawzall這個用來撰寫MapReduce任務的DSL，Yahoo也很早就完成瞭對應的開源實現Apache Pig。但是10年後的今天，我們的主流選擇是用SQL或者DataFrame，Pig的用戶已經不多瞭，而Sawzall也沒有再聽Google提起過。

所以可以說，大數據技術的發展是一個非常典型的技術工程的發展過程，跟隨這個脈絡，我們可以看到工程師們對於技術的探索、選擇過程，以及最終歷史告訴我們什麼是正確的選擇。

那麼接下來，我們就一起來看看整個“大數據技術”的歷史脈絡，一起來看看這一篇篇論文、一個個開源系統都是為什麼會出現。

需求起源

我認為，Google能成為散播大數據火種的人，是有著歷史的必然性的。

作為一個搜索引擎，Google在數據層面，面臨著比任何一個互聯網公司都更大的挑戰。無論是Amazon這樣的電商公司，還是Yahoo這樣的門戶網站，都隻需要存儲自己網站相關的數據。而Google，則是需要抓取所有網站的網頁數據並存下來。

而且光存下來還不夠，早在1999年，兩個創始人就發表瞭PageRank的論文，也就是說，Google不隻是簡單地根據網頁裡面的關鍵字來排序搜索結果，而是要通過網頁之間的反向鏈接關系，進行很多輪的迭代計算，才能最終確認排序。而不斷增長的搜索請求量，讓Google還需要有響應迅速的在線服務。

三駕馬車和基礎設施

由此一來，面對存儲、計算和在線服務這三個需求，Google就在2003、2004以及2006年，分別拋出瞭三篇重磅論文。也就是我們常說的“大數據”的三駕馬車：GFS、MapReduce和Bigtable。

GFS的論文發表於2003年，它主要是解決瞭數據的存儲問題。作為一個上千節點的分佈式文件系統，Google可以把所有需要的數據都能很容易地存儲下來。

然後，光存下來還不夠，我們還要基於這些數據進行各種計算。這個時候，就輪到2004年發表的MapReduce出場瞭。通過借鑒Lisp，Google利用簡單的Map和Reduce兩個函數，對於海量數據計算做瞭一次抽象，這就讓“處理”數據的人，不再需要深入掌握分佈式系統的開發瞭。而且他們推出的PageRank算法，也可以通過多輪的MapReduce的迭代來實現。

這樣，無論是GFS存儲數據，還是MapReduce處理數據，系統的吞吐量都沒有問題瞭，因為所有的數據都是順序讀寫。但是這兩個，其實都沒有辦法解決好數據的高性能隨機讀寫問題。

因此，面對這個問題，2006年發表的Bigtable就站上瞭歷史舞臺瞭。它是直接使用GFS作為底層存儲，來做好集群的分片調度，以及利用MemTable+SSTable的底層存儲格式，來解決大集群、機械硬盤下的高性能的隨機讀寫問題。

下圖就展示瞭Google的三駕馬車針對這三類問題的技術優缺點，你可以參考下。

到這裡，GFS、MapReduce和Bigtable這三駕馬車的論文，就完成瞭“存儲”“計算”“實時服務”這三個核心架構的設計。不過你還要知道，這三篇論文其實還依賴瞭兩個基礎設施。

第一個是為瞭保障數據一致性的分佈式鎖。對於這個問題，Google在發表Bigtable的同一年，就發表瞭實現瞭Paxos算法的Chubby鎖服務的論文（我會在基礎知識篇“分佈式鎖Chubby”這一講中為你詳細解讀這篇論文）。

第二個是數據怎麼序列化以及分佈式系統之間怎麼通信。Google在前面的論文裡都沒有提到這一點，所以在基礎知識篇的“通過Thrift序列化：我們要預知未來才能向後兼容嗎？”我們會一起來看看Facebook在2007年發表的Thrift的相關論文。

OLAP和OLTP數據庫

可以說，GFS、MapReduce和Bigtable這三駕馬車是為整個業界帶來瞭火種，但是整個大數據領域的進化才剛剛開始。事實上，不管是GFS也好，MapReduce也好，還是Bigtable也好，在那個時候，它們都還是很糙的系統設計。

這裡，我們先來看下MapReduce，作為一個“計算”引擎，它開始朝著以下方式進化。

首先是編程模型。MapReduce的編程模型還是需要工程師去寫程序的，所以它進化的方向就是通過一門DSL，進一步降低寫MapReduce的門檻。

雖然Google發表瞭Sawzall，Yahoo實現瞭Pig，但是在這個領域的第一階段最終勝出的，是Facebook在2009年發表的Hive。Hive通過一門基本上和SQL差不多的HQL，大大降低瞭數據處理的門檻，從而成為瞭大數據數據倉庫的事實標準。

其次是執行引擎。Hive雖然披上瞭一個SQL的皮，但是它的底層仍然是一個個MapReduce的任務，所以延時很高，沒法當成一個交互式系統來給數據分析師使用。於是Google又在2010年，發表瞭Dremel這個交互式查詢引擎的論文，采用數據列存儲+並行數據庫的方式。這樣一來，Dremel不僅有瞭一個SQL的皮，還進一步把MapReduce這個執行引擎給替換掉瞭。

最後是多輪迭代問題。在MapReduce這個模型裡，一個MapReduce就要讀寫一次硬盤，而且Map和Reduce之間的數據通信，也是先要落到硬盤上的。這樣，無論是復雜一點的Hive SQL，還是需要進行上百輪迭代的機器學習算法，都會浪費非常多的硬盤讀寫。

於是和Dremel論文發表的同一年，來自Berkeley的博士生馬泰·紮哈裡亞（Matei Zaharia），就發表瞭Spark的論文，通過把數據放在內存而不是硬盤裡，大大提升瞭分佈式數據計算性能。

所以到這裡，你可以看到，圍繞MapReduce，整個技術圈都在不斷優化和迭代計算性能，Hive、Dremel和Spark分別從“更容易寫程序”“查詢響應更快”“更快的單輪和多輪迭代”的角度，完成瞭對MapReduce的徹底進化。

好瞭，花開兩朵，各表一枝。看完瞭MapReduce這頭，我們再來看看Bigtable那一頭。

作為一個“在線服務”的數據庫，Bigtable的進化是這樣的：

• 首先是事務問題和Schema問題。Google先是在2011年發表瞭MegaStore的論文，在Bigtable之上，實現瞭類SQL的接口，提供瞭Schema，以及簡單的跨行事務。如果說Bigtable為瞭伸縮性，放棄瞭關系型數據庫的種種特性。那麼MegaStore就是開始在Bigtable上逐步彌補關系型數據庫的特性。
• 其次是異地多活和跨數據中心問題。Google在2012年發表的Spanner，能夠做到“全局一致性”。這樣，就算是基本解決瞭這兩個問題，第一次讓我們有一個“全球數據庫”。

我在這裡放瞭一張圖，你可以看到在大數據領域裡，MapReduce和Bigtable是怎麼通過前面說的節點一步步進化下去的。實際上，如果說MapReduce對應的迭代進行，是在不斷優化OLAP類型的數據處理性能，那麼Bigtable對應的進化，則是在保障伸縮性的前提下，獲得瞭更多的關系型數據庫的能力。

實時數據處理的抽象進化

這樣，從MapReduce到Dremel，我們查詢數據的響應時間就大大縮短瞭。但是計算的數據仍然是固定的、預先確定的數據，這樣系統往往有著大到數小時、小到幾分鐘的數據延時。

所以，為瞭解決好這個問題，流式數據處理就走上瞭舞臺。

首先是Yahoo在2010年發表瞭S4的論文，並在2011年開源瞭S4。而幾乎是在同一時間，Twitter工程師南森·馬茨（Nathan Marz）以一己之力開源瞭Storm，並且在很長一段時間成為瞭工業界的事實標準。和GFS一樣，Storm還支持“至少一次”（At-Least-Once）的數據處理。另外，基於Storm和MapReduce，南森更是提出瞭Lambda架構，它可以稱之為是第一個“流批協同”的大數據處理架構。

接著在2011年，Kafka的論文也發表瞭。最早的Kafka其實隻是一個“消息隊列”，看起來它更像是Scribe這樣進行數據傳輸組件的替代品。但是由於Kafka裡發送的消息可以做到“正好一次”（Exactly-Once），所以大傢就動起瞭在上面直接解決Storm解決不好的消息重復問題的念頭。於是，Kafka逐步進化出瞭Kafka Streams這樣的實時數據處理方案。而後在2014年，Kafka的作者Jay Krepson提出瞭Kappa架構，這個可以被稱之為第一代“流批一體”的大數據處理架構。

看到這裡，你會發現大數據的流式處理似乎沒有Google什麼事兒。的確，在流式數據處理領域，Google發表的FlumeJava和MillWheel的論文，並沒有像前面的三駕馬車或者Spanner的影響力那麼大。

但是在2015年，Google發表的Dataflow的模型，可以說是對於流式數據處理模型做出瞭最好的總結和抽象。一直到現在，Dataflow就成為瞭真正的“流批一體”的大數據處理架構。而後來開源的Flink和Apache Beam，則是完全按照Dataflow的模型實現的瞭。

這裡，我把這些論文的前後之間的脈絡聯系專門做瞭一張圖，放在瞭下面。當你對某一篇論文感到困惑的時候，就可以去翻看它前後對應的論文，找到對應問題的來龍去脈。

將所有服務器放在一起的資源調度

到瞭現在，隨著“大數據領域”本身的高速發展，數據中心裡面的服務器越來越多，我們對於數據一致性的要求也越來越高。

那麼，為瞭解決一致性問題，我們就有瞭基於Paxos協議的分佈式鎖。但是Paxos協議的性能很差，於是有瞭進一步的Multi-Paxos協議。

而接下來的問題就是，Paxos協議並不容易理解，於是就有瞭Raft這個更容易理解的算法的出現。Kubernetes依賴的etcd就是用Raft協議實現的，我們在後面的資源調度篇裡，會一起來看一下Raft協議到底是怎麼實現的，以及現代分佈式系統依賴的基礎設施是什麼樣子的。

然後，也正是因為數據中心裡面的服務器越來越多，我們會發現原有的系統部署方式越來越浪費。

原先我們一般是一個計算集群獨占一系列服務器，而往往很多時候，我們的服務器資源都是閑置的。這在服務器數量很少的時候確實不太要緊，但是，當我們有數百乃至數千臺服務器的時候，浪費的硬件和電力成本就成為不能承受之重瞭。

於是，盡可能用滿硬件資源成為瞭剛需。由此一來，我們對於整個分佈式系統的視角，也從虛擬機轉向瞭容器，這也是Kubernetes這個系統的由來。在後面的資源調度篇中，我們就會一起來深入看看，Kubernetes這個更加抽象、全面的資源管理和調度系統。

小結

最後，我把在這個課程中會解讀到的論文清單列在瞭下面，供你作為一個索引。

我在這節課裡提到的這十幾篇論文，其實隻是2003到2015年這12年的大數據發展的冰山一角。

還有許許多多值得一讀的論文，比如針對Bigtable，你就可以還去讀一下Cassandra和Dynamo，這樣思路略有不同的分佈式數據的論文；針對Borg和Kubernetes，你可以去看看Mesos這個調度系統的論文又是什麼樣的。網上更有“開源大數據架構的100篇論文”這樣的文章，如果你想深耕大數據領域，也可以有選擇地多讀一些其中的論文。

推薦閱讀

如果你覺得今天的這一講學完後還不夠過癮，我推薦你可以讀一下“Big Data: A Survey”這篇綜述文章，可以讓你更加深入“大數據”技術的全貌。另外，學完瞭這門課程之後，如果你還想更加深入地瞭解更多的大數據技術，你可以對著“Big Data: A Survey”這篇論文按圖索驥，研讀更多裡面引用到的論文。

課後思考

除瞭這些論文之外，你覺得還有哪些論文和開源框架，對於大數據領域的發展是有重要貢獻的呢？你覺得它們主要是解決瞭什麼樣的重要問題？

歡迎留言和我分享你的思考和疑惑，你也可以把今天的內容分享給你的朋友，和他一起學習進步。