Google論文、開源與雲端計算
文章目錄
一.Google論文與開源
自1998年成立，至今Google已走過20個年頭。在這20年裡，Google不斷地發表一些對於自己來說已經過時甚至不再使用的技術的論文，但是發表之後總會有類似系統被業界實現出來，也足以說明google的技術至少領先業界數年。在Amazon不斷引領全球雲端計算浪潮開發出一系列面向普羅大眾的雲產品的同時；Google也在不斷引領構建著滿足網際網路時代海量資料的儲存計算和查詢分析需求的軟硬體基礎設施。
本文對Google在這20年中發表的論文進行了一個簡單的總結和整理，主要選擇了分散式系統和平行計算領域相關的論文，其中內容涉及資料中心/計算/儲存/網路/資料庫/排程/大資料處理等多個方向。通過這樣的一個總結，一方面可以一窺Google強大的軟硬體基礎設施，另一方面也可以為不同領域的開發人員提供一個學習的參考。可以通過這些文章去了解上層應用的架構設計和實現，進而可以更好的理解和服務於上層應用。同時這些系統中所採用的架構/演算法/設計/權衡，本身也可以為我們的系統設計和實現提供重要的參考。
二.Google論文簡介
下面來簡要介紹下”那些年我們追過的Google論文”，由於篇幅有限主要講下每篇論文的主要思路，另外可能還會介紹下論文作者及論文字身的一些八卦。深入閱讀的話，可以直接根據下面的連結檢視原文，另外很多文章網上已經有中文譯文，也可以作為閱讀參考。
2.1 起源
1.The anatomy of a large-scale hypertextual Web search engine(1998).Google創始人Sergey Brin和Larry Page於1998年發表的奠定Google搜尋引擎理論基礎的原始論文。在上圖中我們把它放到了最底層，在這篇論文裡他們描述了最初構建的Google搜尋引擎基礎架構，可以說所有其他文章都是以此文為起點。此文對於搜尋引擎的基本架構，尤其是Google使用的PageRank演算法進行了描述，可以作為了解搜尋引擎的入門文章。
2.WEB SEARCH FOR A PLANET: THE GOOGLE CLUSTER ARCHITECTURE(IEEE Micro03).描述Google叢集架構最早的一篇文章，同時也應該是最被忽略的一篇文章，此文不像GFS MapReduce Bigtable那幾篇文章為人所熟知，但是其重要性絲毫不亞於那幾篇。這篇文章體現了Google在硬體方面的一個革命性的選擇：在資料中心中使用廉價的PC硬體取代高階伺服器。這一選擇的出發點主要基於價效比，實際的需求是源於網際網路資料規模之大已經不能用傳統方法解決，但是這個選擇導致了上層的軟體也要針對性地進行重新的設計和調整。由於硬體可靠性的降低及數量的上升，意味著要在軟體層面實現可靠性，需要採用多個副本，需要更加自動化的叢集管理和監控。也是從這個時候開始，Google開始著眼於自己設計伺服器以及資料中心相關的其他硬體，逐步從託管資料中心向自建資料中心轉變。而Google之後實現的各種分散式系統，都可以看做是基於這一硬體選擇做出的軟體層面的設計權衡。
3.The Google File System(SOSP03).Google在分散式系統領域發表的最早的一篇論文。關於GFS相信很多人都有所瞭解，此處不再贅言。今天Google內部已經進化到第二代GFS：Colossus，而關於Colossus目前為止還沒有相關的論文，網上只有一些零散介紹：Colossus。簡要介紹下本文第一作者Sanjay Ghemawat，在加入Google之前他也是在DEC工作，主要從事Java編譯器和Profiling相關工作。同時在DEC時代他與Jeff Dean就有很多合作，而他加入Google也是Jeff Dean先加入後推薦他加入的，此後的很多工作都是他和Jeff Dean一塊完成的，像後來的MapReduce/BigTable/Spanner/TensorFlow，在做完Spanner之後，Jeff Dean和Sanjay開始轉向構建AI領域的大規模分散式系統。2012年，Jeff Dean和Sanjay共同獲得了ACM-Infosys Foundation Award。此外Google的一些開源專案像LevelDB/GPerftools/TCMalloc等，都可以看到Sanjay的身影。
4.MapReduce: Simplified Data Processing on Large Clusters(OSDI04).該文作者是Jeff Dean和Sanjay Ghemawat，受Lisp語言中的Map Reduce原語啟發，在大規模分散式系統中提供類似的操作原語。在框架層面遮蔽底層分散式系統實現，讓使用者只需要關注如何編寫自己的Mapper和Reducer實現，從而大大簡化分散式程式設計。時至今日MapReduce已經成為大規模資料處理中廣泛應用的一種程式設計模型，雖然之後有很多新的程式設計模型不斷被實現出來，但是在很多場景MapReduce依然發揮著不可替代的作用。
而自2004年提出之後，中間也出現過很多關於MapReduce的爭論，最著名的應該是2008年1月8號David J. DeWitt和Michael Stonebraker發表的一篇文章<< MapReduce: A major step backwards>>，該文發表後引起了廣泛的爭論。首先介紹下這兩位都是資料庫領域的著名科學家，David J. DeWitt，ACM Fellow，2008年以前一直在大學裡搞研究，在並行資料庫領域建樹頗多，之後去了微軟在威斯康辛的Jim Gray系統實驗室。Michael Stonebraker(2014圖靈獎得主)，名頭要更大一些，在1992 年提出物件關係資料庫。在加州伯克利分校計算機教授達25年，在此期間他創作了Ingres, Illustra, Cohera, StreamBase Systems和Vertica等系統。其中Ingres是很多現代RDBMS的基礎，比如Sybase、Microsoft SQL Server、NonStop SQL、Informix 和許多其他的系統。Stonebraker曾擔任過Informix的CEO，自己還經常出來創個業，每次還都成功了。關於這個爭論，Jeff Dean和Sanjay Ghemawat在2010年1月份的<<Communication of the ACM>>上發表了這篇<<MapReduce-A Flexible Data Processing Tool>>進行迴應，同一期上還刊了Michael Stonebraker等人的<<MapReduce and Parallel DBMSs-Friends or Foes >>。
5.Bigtable: A Distributed Storage System for Structured Data(OSDI06).Bigtable基於GFS構建，提供了結構化資料的可擴充套件分散式儲存。自Bigtable論文發表之後，很快開源的HBase被實現出來，此後更是與Amazon的Dynamo一塊引領了NoSQL系統的潮流，之後各種NoSQL系統如雨後春筍般出現在各大網際網路公司及開源領域。此外在tablet-server中採用的LSM-Tree儲存結構，使得這種在1996年就被提出的模型被重新認識，並廣泛應用於各種新的儲存系統實現中，成為與傳統關係資料庫中的B樹並駕齊驅的兩大模型。
如果說MapReduce代表著新的分散式計算模型的開端的話，Bigtable則代表著新的分散式儲存系統的開端。自此之後在分散式計算儲存領域，Google不斷地推陳出新，發表了很多新的計算和儲存系統，如上圖中所示。在繼續介紹這些新的計算儲存系統之前，我們回到圖的底層，關注下基礎設施方面的一些系統。
2.2 基礎設施
6.The Chubby lock service for loosely-coupled distributed systems(OSDI06).以檔案系統介面形式提供的分散式鎖服務，幫助開發者簡化分散式系統中的同步和協調工作，比如進行Leader選舉。除此之外，這篇文章一個很大的貢獻應該是將Paxos應用於工業實踐，並極大地促進了Paxos的流行，從這個時候開始Paxos逐漸被更多地工業界人士所熟知並應用在自己的分散式系統中。此後Google發表的其他論文中也不止一次地提到Paxos，像MegaStore/Spanner/Mesa都有提及。此文作者Mike Burrows加入Google之前也是在DEC工作，在DEC的時候他還是AltaVista搜尋引擎的主要設計者。
7.Borg(Eurosys15) Omega(Eurosys13) Kubernetes.Borg是Google內部的叢集資源管理系統，大概誕生在2003-2004年，在Borg之前Google通過兩個系統Babysitter和Global Work Queue來分別管理它的線上服務和離線作業，而Borg實現了兩者的統一管理。直到15年Google才公佈了Borg論文，在此之前對外界來說Borg一直都是很神祕的存在。而Omega主要是幾個博士生在Google做的研究型專案，最終並沒有實際大規模上線，其中的一些理念被應用到Borg系統中。（注：Borg這個名字源自於<<星際迷航>>裡的博格人，博格人生活在銀河系的德爾塔象限，是半有機物半機械的生化人。博格個體的身體上裝配有大量人造器官及機械，大腦為人造的處理器。博格人是嚴格奉行集體意識的種族，從生理上完全剝奪了個體的自由意識。博格人的社會系統由“博格集合體”組成，每個集合體中的個體成員被稱為“Drone”。集合體內的博格個體通過某種複雜的子空間通訊網路相互連線。在博格集合體中，博格個體沒有自我意識，而是通過一個被稱為博格女皇（Borg Queen）的程式對整個集合體進行控制。）
在2014年中的時候，Google啟動了Kubernetes(Borg的開源版本)。2015年，Kubernetes 1.0 release，同時Google與Linux基金會共同發起了CNCF。2016年，Kubernates逐漸成為容器編排管理領域的主流。提到Kubernates，需要介紹下著名的分散式系統專家Eric Brewer，伯克利教授&Google infrastructure VP，網際網路服務系統早期研究者。早在1995年他就和Paul Gauthier創立了Inktomi搜尋引擎(2003年被Yahoo!收購，李彥巨集曾在這家公司工作)，此時距離Google創立還有3年。之後在2000年的PODC上他首次提出了CAP理論，2012年又對CAP進行了回顧。2011年他加入了Google，目前在負責推動Kubernetes的發展。
8.CPI2: CPU performance isolation for shared compute clusters(Eurosys13).通過監控CPI(Cycles-Per-Instruction)指標，結合歷史執行資料進行分析預測找到影響系統性能的可疑程式，限制其CPU使用或進行隔離/下線，避免影響其他關鍵應用。本文也從一個側面反映出，為了實現離線線上混布Google在多方面所做的努力和探索，尤其是在資源隔離方面。具體實現中，每臺機器上有一個守護程序負責採集本機上執行的各個Job的CPI資料(通過採用計數模式/取樣等方法降低開銷，實際CPU開銷小於0.1%)，然後傳送到一箇中央的伺服器進行聚合，由於叢集可能是異構的，每個Job還會根據不同的CPU型別進行單獨聚合，最後把計算出來的CPI資料的平均值和標準差作為CPI spec。結合CPI歷史記錄建立CPI預測模型，一旦出現取樣值偏離預測值的異常情況，就會記錄下來，如果異常次數超過一定閾值就啟動相關性分析尋找干擾源，找到之後進行相應地處理(限制批處理作業的CPU使用/排程到單獨機器上等)。講到這裡，不僅讓我們聯想到今天大火的AIOPS概念，而很久之前Google已經在生產系統上使用類似技術。不過在論文發表時，Google只是打開了CPI2的監控功能，實際的自動化處理還未在生產系統中開啟。
9.GOOGLE-WIDE PROFILING:A CONTINUOUS PROFILING INFRASTRUCTURE FOR DATA CENTERS(IEEE Micro10).Google的分散式Profiling基礎設施，通過收集資料中心的機器上的各種硬體事件/核心事件/呼叫棧/鎖競爭/堆記憶體分配/應用效能指標等資訊，通過這些資訊可以為程式效能優化/Job排程提供參考。為了降低開銷，取樣是在兩個維度上進行，首先是在整個叢集的機器集合上取樣同一時刻只對很少一部分機器進行profiling，然後在每臺機器上再進行基於事件的取樣。底層通過OProfile採集系統硬體監控指標(比如CPU週期/L1 L2 Cache Miss/分支預測失敗情況等)，通過GPerfTools採集應用程式程序級的執行指標(比如堆記憶體分配/鎖競爭/CPU開銷等)。收集後的原始取樣資訊會儲存在GFS上，但是這些資訊還未與原始碼關聯上，而部署的binary通常都是去掉了debug和符號表資訊，採用的解決方法是為每個binary還會儲存一個包含debug資訊的未被strip的原始binary，然後通過執行MapReduce Job完成原始取樣資訊與原始碼的關聯。為了方便使用者查詢，歷史Profiling資料還會被載入到一個分散式資料庫中。通過這些Profiling資料，除了可以幫助應用理解程式的資源消耗和效能演化歷史，還可以實現資料驅動的資料中心設計/構建/運維。
10.Dapper, a Large-Scale Distributed Systems Tracing Infrastructure(Google TR10).Google的分散式Tracing基礎設施。Dapper最初是為了追蹤線上服務系統的請求處理過程。比如在搜尋系統中，使用者的一個請求在系統中會經過多個子系統的處理，而且這些處理是發生在不同機器甚至是不同叢集上的，當請求處理髮生異常時，需要快速發現問題，並準確定位到是哪個環節出了問題，這是非常重要的，Dapper就是為了解決這樣的問題。對系統行為進行跟蹤必須是持續進行的，因為異常的發生是無法預料的，而且可能是難以重現的。同時跟蹤需要是無所不在，遍佈各處的，否則可能會遺漏某些重要的點。基於此Dapper有如下三個最重要的設計目標：低的額外開銷，對應用的透明性，可擴充套件。同時產生的跟蹤資料需要可以被快速分析，這樣可以幫助使用者實時獲取線上服務狀態。
11.B4: Experience with a Globally-Deployed Software Defined WAN(Sigcomm13).Google在全球有幾十個資料中心，這些資料中心之間通常通過2-3條專線與其他資料中心進行連線。本文描述了Google如何通過SDN/OpenFlow對資料中心間的網路進行改造，通過對跨資料中心的流量進行智慧排程，最大化資料中心網路鏈路的利用率。Google通過強大的網路基礎設施，使得它的跨越全球的資料中心就像一個區域網，從而為後續很多系統實現跨資料中心的同步複製提供了網路層面的保障。
2.3 計算分析系統
自MapReduce之後，Google又不斷地開發出新的分散式計算系統，一方面是為了提供更易用的程式設計介面(比如新的DSL/SQL語言支援)，另一方面是為了適應不同場景(圖計算/流計算/即席查詢/記憶體計算/互動式報表等)的需求。
12.Interpreting the Data: Parallel Analysis with Sawzall(Scientific Programming05).Google為了簡化MapReduce程式的編寫，而提出的一種新的DSL。後來Google又推出了Tenzing/Dremel等資料分析系統，到了2010年就把Sawzall給開源了，專案主頁：http://code.google.com/p/szl/。雖然與Tenzing/Dremel相比， Sawzall所能做的事情還是比較有限，但是它是最早的，同時作為一種DSL畢竟還是要比直接寫MapReduce job要更易用些。
本文第一作者Rob Pike，當今世界上最著名的程式設計師之一，<<Unix程式設計環境>> <<程式設計實踐>>作者。70年代就加入貝爾實驗室，跟隨Ken Thompson&DMR(二人因為發明Unix和C語言共同獲得1983年圖靈獎)參與開發了Unix，後來又跟Ken一塊設計了UTF-8。2002年起加入Google，之後搞了Sawzall，目前跟Ken Thompson一塊在Google設計開發Go語言。
13.FlumeJava: Easy, Efficient Data-Parallel Pipelines(PLDI10).由於實際的資料處理中，通常都不是單個的MapReduce Job，而是多個MapReduce Job組成的Pipeline。為了簡化Pipleline的管理和程式設計，提出了FlumeJava框架。由框架負責MapReduce Job的提交/中間資料管理，同時還會對執行過程進行優化，使用者可以方便地對Pipeline進行開發/測試/執行。另外FlumeJava沒有采用新的DSL，而是以Java類庫的方式提供給使用者，使用者只需要使用Java語言編寫即可。
14.Pregel: A System for Large-Scale Graph Processing(SIGMOD10).Google的圖處理框架。Pregel這個名稱是為了紀念尤拉，在他提出的格尼斯堡七橋問題中，那些橋所在的河就叫Pregel，而正是格尼斯堡七橋問題導致了圖論的誕生。最初是為了解決PageRank計算問題，由於MapReduce並不適於這種場景，所以需要發展新的計算模型去完成這項計算任務，在這個過程中逐步提煉出一個通用的圖計算框架，並用來解決更多的問題。核心思想源自BSP模型，這個就更早了，是在上世紀80年代由Leslie Valiant(2010年圖靈獎得主)提出，之後在1990的Communications of the ACM 上，正式發表了題為A bridging model for parallel computation的文章。
15.Dremel: Interactive Analysis of Web-Scale Datasets(VLDB10).由於MapReduce的延遲太大，無法滿足互動式查詢的需求，Google開發了Dremel系統。Dremel主要做了三件事：將巢狀記錄轉換為列式儲存，並提供快速的反向組裝；類sql的查詢語言；類搜尋系統的查詢執行樹。通過列式儲存降低io，將速度提高一個數量級，這類似於諸如Vertica這樣的列存式資料庫，與傳統行式儲存不同，它們只需要讀取查詢語句中真正必需的那些欄位資料；通過類搜尋系統的查詢執行系統取代mr(MapReduce)，再提高一個數量級。它類似於Hive，應該說查詢層像Hive，都具有類似於SQL的查詢語言，都可以用來做資料探勘和分析；但hive是基於mr，所以實時性要差，Dremel則由於它的查詢執行引擎類似於搜尋服務系統，因此非常適合於互動式的資料分析方式，具有較低的延遲，但是通常資料規模要小於mr；而與傳統資料庫的區別是，它具有更高的可擴充套件性和容錯性，結構相對簡單，可以支援更多的底層儲存方式。其中的資料轉化與儲存方式，巧妙地將Protobuf格式的巢狀記錄轉換成了列式儲存，同時還能夠快速的進行重組，是其比較獨特的一點。
16.Tenzing A SQL Implementation On The MapReduce Framework(VLDB11).Tenzing是一個建立在MapReduce之上的用於Google資料的ad hoc分析的SQL查詢引擎。Tenzing提供了一個具有如下關鍵特徵的完整SQL實現(還具有幾個擴充套件)：異構性，高效能，可擴充套件性，可靠性，元資料感知，低延時，支援列式儲存和結構化資料，容易擴充套件。Tenzing的發表算是很晚的了，與之相比Facebook在VLDB09上就發表了Hive的論文。與開源系統Hive的優勢在於它跟底層所依賴的MapReduce系統都是一個公司內的產品，因此它可以對MapReduce做很多改動，以滿足Tenzing某些特殊性的需求，最大化Tenzing的效能。
17.PowerDrill：Processing a Trillion Cells per Mouse Click(VLDB12).Google推出的基於記憶體的列存資料庫，該系統在2008年就已經在Google內部上線。與Dremel相比雖然都是面向分析場景，但是PowerDrill主要面向的是少量核心資料集上的多維分析，由於資料集相對少同時分析需求多所以可以放到記憶體，在把資料載入到記憶體分析之前會進行復雜的預處理以儘量減少記憶體佔用。而Dremel則更加適合面向大量資料集的分析，不需要把資料載入到記憶體。
主要採用瞭如下技術進行加速和記憶體優化：1)匯入時對資料進行分割槽，然後查詢時根據分割槽進行過濾儘量避免進行全量掃描 2)底層資料採用列式儲存，可以跳過不需要的列 3)採用全域性/chunk兩級字典對列值進行編碼，一方面可以加速計算(chunk級的字典可以用來進行鍼對使用者查詢的chunk過濾，編碼後的value變成了更短的int型別與原始值相比可以更快速的進行相關運算)，另一方面還可以達到資料壓縮的目的，與通用壓縮演算法相比採用這種編碼方式的優點是：讀取時不需要進行解壓這樣的預處理，同時支援隨機讀取 4)編碼後的資料進行壓縮還可以達到1.4-2倍的壓縮比，為了避免壓縮帶來的效能降低，採用了壓縮與編碼的混合策略，對資料進行分層，最熱的資料是解壓後的編碼資料，然後稍冷的資料也還會進行壓縮 5)對資料行根據partition key進行重排序，提高壓縮比 6)查詢分散式執行，對於同一個查詢會分成多個子查詢併發給多個機器執行，同時同一個子查詢會發給兩臺機器同時執行，只要有一個返回即可，但是另一個最終也要執行完以進行資料預熱。
18.MillWheel: Fault-Tolerant Stream Processing at Internet Scale(VLDB13).Google的流計算系統，被廣泛應用於構建低延遲資料處理應用的框架。使用者只需要描述好關於計算的有向圖，編寫每個節點的應用程式程式碼。系統負責管理持久化狀態和連續的記錄流，同時將一切置於框架提供的容錯性保證之下。雖然釋出的比較晚，但是其中的一些機制(比如Low Watermark)被借鑑到開源的Flink系統中。
19.Mesa: Geo-Replicated, Near Real-Time, Scalable Data Warehousing(VLDB14).Google的跨資料中心資料倉庫系統，主要是為了滿足廣告業務的場景需求，隨著廣告平臺的不斷髮展，客戶對各自的廣告活動的視覺化提出了更高的要求。對於更具體和更細粒度的資訊需求，直接導致了資料規模的急速增長。雖然Google已經把核心廣告資料遷移到了Spanner+F1上，但是對於這種廣告效果實時統計需求來言，由於涉及非常多的指標這些指標可能是儲存在成百上千張表中，同時這些指標與使用者點選日誌相關通常對應著非常大的峰值訪問量，超過了Spanner+F1這樣的OLTP系統的處理能力。為此Google構建了Mesa從而能處理持續增長的資料量，同時它還提供了一致性和近實時查詢資料的能力。具體實現方法是：將增量更新進行batch，提交者負責為增量資料分配版本號，利用Paxos對跨資料中心的版本資料庫進行更新，基於MVCC機制提供一致性訪問。底層通過Bigtable儲存元資料，通過Colossus來儲存資料檔案，此外還利用MapReduce來對連續增量資料進行合併，而為Mesa提供增量更新的上游應用通常是一個流計算系統。可以看到Mesa系統本身結合了批量處理與實時計算，還要滿足OLTP+OLAP的場景需求，同時採用了分層架構實現儲存計算的分離。既像一個分散式資料庫，又像一個大資料準實時處理系統。
20.Shasta: Interactive Reporting At Scale(SIGMOD16).Google的互動式報表系統，也主要是為了滿足廣告業務的場景需求，與Mesa的區別在於Shasta是構建於Mesa之上的更上層封裝。主要為了解決如下挑戰：1)使用者查詢請求的低延遲要求 2)底層事務型資料庫的schema與實際展現給使用者的檢視不友好，報表系統的開發人員需要進行復雜的轉換，一個查詢檢視底層可能涉及多種資料來源(比如F1/Mesa/Bigtable等) 3)資料實時性需求，使用者修改了廣告預算後希望可以在新的報表結果中可以馬上體現出來。為了解決這些問題，在F1和Mesa系統之上構建了Shasta。主要從兩個層面進行解決：語言層面，在SQL之上設計了一種新的語言RVL(Relational View Language)，通過該語言提供的機制(自動聚合/子句引用/檢視模板/文字替換等)可以比SQL更加方便地描述使用者的查詢檢視，RVL編譯器會把RVL語句翻譯成SQL，在這個過程中還會進行查詢優化；系統層面，直接利用了F1的分散式查詢引擎，但是進行了一些擴充套件比如增加單獨的UDF server讓UDF的執行更加安全，為了確保實時性需要直接訪問F1，但是為了降低延遲在F1之上增加了一個只讀的分散式Cache層。
21.Goods: Organizing Google’s Datasets(SIGMOD16).Google的元資料倉庫Goods(Google DataSet Search)。Google內部積累了大量的資料集，而這些資料散落在各種不同的儲存系統中(GFS/Bigtable/Spanner等)。面臨的問題就是如何組織管理這些資料，使得公司內部工程師可以方便地找到他們需要的資料，實現資料價值的最大化。Google的做法很多方面都更像一個小型的搜尋引擎，不過在這個系統裡被索引的資料由網頁變成了Google內部生產系統產生的各種資料，使用者變成了內部的資料開發人員。整個做法看起來要費勁很多，很大程度上是因為內部系統眾多但是沒有一個統一的入口平臺，只能採用更加自動化(不依賴人和其他系統)的做法：要爬取各個系統的日誌，通過日誌解析資料的元資訊(這個過程中還是比較費勁的，比如為了確定資料的Schema，要把Google中央程式碼庫裡的所有protobuf定義拿過來試看哪個能匹配上)，然後把這些資訊(大小/owner/訪問許可權/時間戳/檔案格式/上下游/依賴關係/Schema/內容摘要等)儲存一箇中央的資料字典中(儲存在Bigtable中目前已經索引了260億條資料集資訊)，提供給內部使用者查詢。這中間解決了如下一些問題和挑戰：Schema探測/資料自動摘要/血緣分析/聚類/搜尋結果ranking/過期資料管理/資料備份等。本文可以讓我們一窺Google是如何管理內部資料資產的，有哪些地方可以借鑑。
2.4 儲存&資料庫
22.Percalator:Large-scale Incremental Processing Using Distributed Transactions and Notifications(OSDI10).基於Bigtable的增量索引更新系統，Google新一代索引系統”咖啡因“實時性提升的關鍵。此前Google的索引構建是基於MapReduce，全量索引更新一次可能需要幾天才能完成，為了提高索引更新的實時性Google構建了增量更新系統。Bigtable只支援單行的原子更新，但是一個網頁的更新通常涉及到其他多個網頁(網頁間存在連結關係比如更新的這個網頁上就有其他網頁的錨文字)的更新。為了解決這個問題，Percolator在Bigtable之上通過兩階段提交實現了跨行事務。同時網頁更新後還要觸發一系列的處理流程，Percolator又實現了類似於資料庫裡面的觸發器機制，當Percolator中的某個cell資料發生變化，就觸發應用開發者指定的Observer程式。此外開源分散式資料庫TiDB就參考了Percalator的事務模型。
23.Megastore: Providing Scalable, Highly Available Storage for Interactive Services(CIDR11).Google在2008年的SIGMOD上就介紹了Megastore，但是直到2011年才發表完整論文。Megastore本身基於Bigtable，在保留可擴充套件/高效能/低延遲/高可用等優點的前提下，引入了傳統關係資料庫中的很多概念比如關係資料模型/事務/索引，同時基於Paxos實現了全球化同步複製，可以說是最早的分散式資料庫實現了。它本身也提供了分散式事務支援，但是論文中並沒有描述相關實現細節，猜測應該跟Percalator類似。雖然此後被Spanner所替代，但是它的繼任者Spanner很多特性都是受它影響。
24.Spanner: Google’s Globally-Distributed Database(OSDI12).2009年Jeff Dean的一次分享(Designs, Lessons and Advice from Building Large Distributed)中首次提到Spanner，也是過了3年到了2012年才發表完整論文。做為Megastore的繼任者，它主要解決了Megastore存在的幾個問題：效能、查詢語言支援弱、分割槽不靈活。另外一個重要的創新是基於原子鐘和GPS硬體實現了TrueTime API，並基於這個API實現了更強的一致性保證。除此之外其他部分則與Megastore非常類似，但是在文中對其分散式事務的實現細節進行了描述。
25.F1: A Distributed SQL Database That Scales(VLDB13).基於Spanner實現的分散式SQL資料庫，主要實現了一個分散式並行查詢引擎，支援一致性索引和非阻塞的線上Schema變更。與Spanner配合替換掉了Google核心廣告系統中的MySQL資料庫。F1這個名字來自生物遺傳學，代指雜交一代，表示它結合了傳統關係資料庫和NoSQL系統兩者的特性。
2.5 AI
26.TensorFlow: A System for Large-Scale Machine Learning(OSDI16)。
27.In-Datacenter Performance Analysis of a Tensor Processing Unit(SIGARCH17).Google TPU。與往常一樣，在Google公佈此文的時候，新一代更強大的TPU已經開發完成。由於本文更偏重硬體，具體內容沒有看。但是其中的第四作者David Patterson還是值得特別來介紹一下，因為在體系結構領域的貢獻(RISC、RAID、體系結構的量化研究方法)，他和John Hennessy共同獲得了2017年的圖靈獎：相關新聞。2016年加入Google就是去做TPU的；2018年，與他共同獲得圖靈獎的John Hennessy(斯坦福第十任校長、MIPS公司創始人)被任命為Google母公司Alphabet的新任主席。
三.總結
在前面兩節我們對過去20年Google在分散式系統領域的經典論文進行了系統地梳理和介紹，通過這個過程我們可以看到：
每當Google發表一篇相關論文，通常都會產生一個與之對應的開源系統。比如GFS/HDFS，MapReduce/Hadoop MapReduce，BigTable/HBase，Chubby/ZooKeeper，FlumeJava/Plume，Dapper/Zipkin等等。如果把資料中心看做一臺計算機的話，在資料中心之上的各種分散式系統就像當年的Unix和C語言，Hadoop及各種開源系統就像當年的Linux，而開啟這個時代的人們尤其是Jeff Dean/Sanjay Ghemawat就像當年的Ken Thompson/Dennis M. Ritche，Hadoop創始人Doug Cutting就像當年的Linus Torvalds。Ken Thompson/Dennis M. Ritche因為Unix和C方面的貢獻獲得1983年圖靈獎，或許在將來的某一天Jeff Dean/Sanjay Ghemawat也能摘得桂冠。
觀察上圖，我們還可以看到隨著時間的推進，Google自底向上地逐步構建出一個龐大的軟硬體基礎設施Stack，同時每個系統內部也在不斷地自我進化。而不同的系統之間，可能是互補關係，可能是繼承關係，可能是替換關係。通過對這個演化過程的觀察，我們也總結出一些內在的趨勢和規律。論文字身固然重要，但是這些趨勢和規律也很有意義。
參考文獻
https://www.gcppodcast.com/post/episode-46-borg-and-k8s-with-john-wilkes/
https://blog.risingstack.com/the-history-of-kubernetes/
Borg, Omega, and Kubernetes
http://www.wired. com/2015/09/google-2-billion-lines-codeand-one-place/
https://en.wikipedia.org/wiki/Eric_Brewer_(scientist)
如何看待谷歌工程師透露谷歌有20億行程式碼，相當於寫40遍Windows？
Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon
http://www.infoq.com/cn/news/2014/08/google-data-warehouse-mesa
https://en.wikipedia.org/wiki/Amazon_Web_Services
https://en.wikipedia.org/wiki/Thomas_J._Watson