我所了解的大數據的歷史（2）
- 2020 年 2 月 19 日
- 筆記
接著說Google，上篇文章提到了 GFS 。那麼Google為什麼要硬著頭皮去啃分散式系統這塊硬骨頭呢？首先，我們要知道Google剛開始成立時是一家搜索公司，方便用戶查詢互聯網上的資訊。因此Google必須要存儲整個互聯網上的資訊，那這個數據量是龐大的。對於這個需求，傳統的資料庫或者更深入地說，單機是遠遠不夠的，必須要使用分散式系統搭建集群；但是那個時候要搭建集群，可供選擇的方案大多像 Oracle 的 RAC 一樣，需要昂貴的機器。因此Google必須要自行去解決這個問題：
- 必須是集群，多台機器組合在一起，可以不斷擴展
- 不能是高端機器，一般的商用電腦就可以
如果選擇了海量的廉價電腦組成集群，那勢必意味著集群內部會遇見不可知的錯誤導致其中一台或者多台機器宕機，而且這宕機還是經常性的、不可預知的。除此以外，Google需要存儲的是互聯網數據，這個數據主要是由爬蟲進行爬取的，基於這個事實，Google認為 GFS 只要負責好 TB 或者 PB 級別的大文件，並且這個文件只能增加，無需進行更新操作。明白這些前提，再去看 GFS 這篇論文會輕鬆很多，比如對數據進行三副本存儲，而元數據使用 Paxos 演算法。
Google有了 GFS 這樣牛逼的存儲，那麼還需要倒排索引。所謂的倒排索引，是「被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射」。因此有了 MapReduce 去構建倒排索引（MapReduce入門程式也是一個 WordCount 程式，統計一段話里每個單詞對應的數量是多少）。MapReduce 借用了函數式編程里的 map 和 reduce 思想，當然這不是重點，重點是 MapReduce 的可容錯性，它創新性的使用文件系統作為中間計算結果的快取層，當然這個文件系統不能因為單機的故障而宕機，另外需要一個調度層去分配資源和重試失敗任務，這自然就是 Yarn 了（不過Google內部使用的是 Borg 作為資源管理系統，Hadoop 剛開始的時候還沒有類似的資源關係系統，後面到 2.0 才開始引入 Yarn）。
MapReduce 的一切都建立在 GFS （開源實現是 HDFS ）和 Borg （開源實現是 Docker ）的前提上，其本身倒是沒有可值得一提的。有了這兩個東西，再結合傳統資料庫理論完全能做出更好的東西，比如 Spark 。大家有空的話可以參考下資料庫領域的 Michael Stonebraker 和Google的 Jeff Dean 的論戰，相關論文是MapReduce ：a major step backwards，吃下瓜也是挺好的。
MapReduce 構建倒排索引時有個大問題，那就是每一次構建都需要重頭開始跑整個系統的數據，代價太高了，且互聯網上的實時熱點數據更新非常快，那就需要一個只更新熱點網站的工具，這個工具類似於 Key-Value 存儲，每一次倒排索引更新主鍵即可，更新時最好有時間戳記錄，但是呢，不需要像傳統資料庫一樣支援全局事務，單行事務即可。這就是 BigTable ，開源實現是 Hbase 。
有了這個東西，Google只需要更新網站發生變化的網址就行了，用戶也就可以實時地查詢到熱點新聞了。BigTable 還只是一個半成品，事務這東西如果上推到應用層去做會複雜的要命，因此後來Google做了一個 Spanner 的東西，引領了 NewSQL 的風潮。後面會簡要翻譯下 Spanner 的相關論文，做一個介紹。
好了，GFS 、MapReduce 和 BigTable 的介紹到此結束了，Google發表了這三篇論文，給大數據時代的到來奠定了基石，雖然 MapReduce 已成昨日黃花，Spark 和 Flink 正冉冉新起，BigTable 也有很多相關替代品出現，但是我們依然不能忘記Google做出的貢獻。
