前言
不知不覺，2020年已經過去一半了，最近突然反應過來自己也看了不少文獻資料了，就想著把看過的文獻和覺得比較好的書籍做一個總結，基本都是大資料分散式領域的，回顧自己學識的同時，也給想從事或這個領域的小夥伴一些參考 ?。最後順便把接下來要看的東西列個列表，也會將自己學習的心得和經驗分享出來，有需要的童鞋可以參考參考。
另外有些文獻看完我會進行整理和輸出，這部分連結我一併附在文獻的介紹後面，後面看的書或是文獻也會保持這種習慣，如果覺得有興趣歡迎各位大佬交流，順便也可以點波關注~~
論文總結
MapReduce 《MapReduce Simplified Data Processing on Large Clusters》
從現在的眼光來看，Mapreduce可以說可圈可點。但在那個年代，這個思想可以說是相當先進的。不得不說Google一直引領技術潮流，包括近幾年流行的k8s也是Google主導。
這篇文章主要介紹了Mapreduce的流程還有一些細節方面的介紹，如果已經有使用過Mapreduce程式設計的小夥伴應該看一遍就能懂。另外，看完如果想加以鞏固的話，推薦做MIT6.824的Lab1，用go實現一個Mapreduce。至於什麼是Mit6.824，百度一下就知道喔。我以前也有寫過一篇介紹MR，有興趣的童鞋不妨看看：從分治演算法到 Hadoop MapReduce。
地址：MapReduce: Simplified Data Processing on Large Cluster
GFS 《The Google File System》
GFS和Mapreduce這兩篇論文直接催生了Hadoop的誕生。不同於Mapreduce，Hadoop的hdfs到今天依舊是工業界主流是海量資料儲存方案，這證明了這一儲存方案的優越性。
這篇文章介紹了Google內部儲存方案GFS的實現，namenode儲存哪些後設資料資訊，datanode如何儲存數（問題可見這篇部落格），帶著問題閱讀這篇論文。
不過熟悉Hdfs的童鞋讀過後應該會發現，GFS和Hdfs其實是有些不一樣的。比如上傳的流程，namenode儲存後設資料的方式，至於為什麼，等待各位童鞋挖掘答案啦。
另外在Hadoop之前用於儲存“大資料”的是RAID，對這塊有興趣的童鞋可以看看這篇：從 RAID 到 Hadoop Hdfs 『大資料儲存的進化史』。
Bigtabble 《Bigtable A Distributed Storage System for Structured Data》
Bigtable，目前業內聞名的Nodel元件Hbase就是它的開源實現。這篇文章主要介紹了Google內部基於GFS的分散式結構化資料儲存系統。
GFS本身是適合追加資料而不適合隨機寫，文章介紹Bigdata為了適配這種特點而使用的LSM-tree儲存結構，而後又闡述一些優化的方案，諸如布隆過濾器。關於LSM-tree有興趣的小夥伴可以看看這篇：資料的儲存結構淺析LSM-Tree和B-tree。
論文地址：Bigtable: A Distributed Storage System for Structured Data
Spark RDD 《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing》
Spark RDD的論文，RDD的全名叫彈性分散式資料集。當初MapReduce模型興起的時候，大家都以為已經迎來了曙光，但一段時間後才發現這東西其實也不是萬能，尤其是在機器學習等需要迭代計算的地方。而究其原因，其實是MapReduce在計算過程中，中間資料需要多次落盤，導致增加許多磁碟IO。
相比之下，RDD使用的DAG計算模型則更加優越。一方面是它將多個計算邏輯梳理為一個DAG有向無環圖，可以一定程度減少不必要的shuffle等耗時操作。另一方面，更加側重於使用記憶體進行計算，減少磁碟開銷。
讀這篇論文會收穫到有關RDD的設計細節。
論文地址：Resilient Distributed Datasets: A Fault-Tolerant Abstraction for
In-Memory Cluster Computing
Spark SQL 《Spark SQL: Relational Data Processing in Spark》
在Spark SQL模組中，提出了DataFrame API，方便使用者進行關係型操作（join，group by）等，而其底層使用的還是RDD。
另外一條SQL語句的執行邏輯，包括解析，驗證，優化，生成物理執行計劃，執行過程中的優化邏輯等等，這裡內容都可以在這篇文章找到。
對SQL解析感興趣的小夥伴，這篇不要錯過，還有下面會介紹到的Calcite的論文，都是跟SQL解析相關的，不過Calcite側重於適配多個資料來源和內部元件的可插拔，上手難度會更高些。
我以前有結合這篇文章，寫了Spark SQL的原始碼解析系列，有興趣的童鞋可以看看Spark SQL原始碼剖析（一）SQL解析框架Catalyst流程概述。
論文地址：Discretized Streams: Fault-Tolerant Streaming Computation at Scale
Spark Streaming《Discretized Streams: Fault-Tolerant Streaming Computation at Scale》
流式處理被譽為大資料技術的未來，Spark Streaming在現在看來有些落後了（跟Flink相比）。
在流處理領域中，由於資料是源源不斷的，但系統通常無法保證一直是健康狀態，資料也有可能出現落後的情況，所以容錯是很重要的點。Spark Streaming主要通過備份和上游重放結合的方式來儲存資料和狀態資訊實現容錯，而一切的核心是微批的處理思想，這裡就不展開太多了。
另一個點是延遲，Spark streaming由於使用了微批，延遲只能做到亞秒級，可以說成也微批，敗也微批。現在Spark的流處理模組改用Flink一樣的演算法重寫，不過好像還沒完全實現完成。
通過這篇文章可以瞭解到Spark streaming的設計思想，對錯誤處理的實現機制，還有落後節點的處理。
論文地址：Discretized Streams: Fault-Tolerant Streaming Computation at Scale
Raft共識《In Search of an Understandable Consensus Algorithm》
共識，可以說是分散式時代的基石，很多系統的基礎功能都是在共識的基礎上實現的。按我的理解，共識是瞭解分散式系統理論原理的一把鑰匙。
最早的時候，分散式系統一致性共識一直是Paxos演算法的天下。就是說其分散式一致性就會想到Paxos，但Paxos演算法太過複雜難以理解和工程化。所以就有了Raft演算法。
這篇文章主要講述Raft演算法的具體流程，包括領導者選舉，日誌複製等內容，看完你會發現，原來分散式共識演算法就跟個小玩具一樣。
有興趣深入的童鞋可以再接著做MIT6.824的Lab2，算是一個很有挑戰是實驗了。
對了，看的時候可以搭配我以前的這篇部落格喔分散式系統一致性問題與Raft演算法（上）
論文地址：In Search of an Understandable Consensus Algorithm
Calcite《Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources》
Calcite也提供了通過SQL管理資料的功能，但是它本身並不負責管理資料來源和後設資料資訊。
它設計出來的目標，是因為在後來在各個領域，流處理，批處理，文字檢索等等都有各自專長的工具，這些工具通常都需要用到SQL解析模組。如果每個工具，比如Flink，ElasticSearch等自己開發一套SQL解析工具那無疑是在重複造輪子。
Calcite就是為了專門解決這個問題，所以它的主要考慮目標是通用性和可插拔。它裡面用到的parser，validate，optimizer模組都可以單獨拿出來使用。比如Hive就是自己直線parser和validate，使用了Calcite的optimizer來對SQL優化。
相對而言，Calcite的門檻會更高一些，但通用性更好，如果對SQL解析這塊業務有需求的人可以考慮瞭解看看。
AnalyticDB《AnalyticDB: Real-time OLAP Database System at Alibaba Cloud》
AnalyticDB是阿里巴巴剛發表不久的一篇系統論文，它的一個可以實時分析的OLAP資料庫。
目前業界開源的支援流式的OLAP資料庫，包括預計算的Kylin streaming，偏向時間資料的Apache Druid，還有Clickhouse等。
但很難有系統可以做到盡善盡美，即很難同時兼顧海量資料，靈活性，效能都較為優秀。
而AnalyticDB可以說是較為成功的一個系統，它確實在很多方面都做的比較好，在設計上也有不少創新的點。對OLAP這塊內容有研究的小夥伴可以看看文章。當然這個目前還不是開源的，僅有論文可以參考。
我之前寫過一篇博文，AnalyticDB實現和特點淺析，裡面根據論文介紹了AnalyticDB的實現，一些特點還與當前業界開源系統做了對比，有興趣可以看看。
論文地址：AnalyticDB: Real-time OLAP Database System at AlibabaCloud
S4（Storm）《S4: Distributed Stream Computing Platform》
S4是比較早期的流處理方面的論文，在那個時代的創新點在於，可以讓使用者自定義計算邏輯而非僅使用運算元進行計算。
當然它的缺陷也比較明顯，比如對落後資料直接忽視，對資料exactly once語義支援的不完善等等。
論文地址：S4: Distributed Stream Computing Platform
ZooKeeper《ZooKeeper: Wait-free coordination for Internet-scale systems》
Zookeeper是一個比較知名的開源分散式共識元件。論文中有說到它底層使用的是ZAB協議（但具體的細節也沒說明），但其實自己觀察就會發現，ZAB協議跟Raft演算法是很像的，只是對一些細節部分做了一定的修改。
論文更偏向其對這樣一個共識系統的功能和系統設計實現，對底層的演算法介紹偏少。推薦先看Raft演算法那篇，然後再看這篇Zookeeper的會好很多。
論文地址：ZooKeeper: Wait-free coordination for Internet-scale systems
Yarn《Apache Hadoop YARN: Yet Another Resource Negotiator》
yarn是一個排程管理系統。最早的時候，Hadoop的資源管理功能是由JobTracker負責的。但它同時還負責了很多功能，這樣就容易出錯並且有單點故障問題，而後yarn就獨立出來。後面發現yarn越來越受到歡迎，就逐漸開放，然後發展到一個可以讓大家都接入的資源排程系統。
這篇論文主要講述yarn的設計結構，裡面的各個模組，工作原理等等。我以前也有寫過yarn的博文，可以結合看看Hadoop Yarn框架原理解析。
論文地址：Apache Hadoop YARN: Yet Another Resource Negotiator
DDIA
這其實是一本書來著，中文全程是《據密集型應用系統設計》。
可以說是講述分散式系統中”道“那一部分的書籍，它並非純理論的書籍，而是很好得和工業界的一些實戰結合起來。真心覺得每一個從事分散式系統相關工作的開發人員都應該讀一讀這本書。
其實一直有打算嘗試寫一篇文章串起這本書的內容，不過工程有些浩大，導致一拖再拖，汗 = =! 。
後續待讀列表
順便貼下我後面打算看的一些文獻，把簡介也附上，給各位童鞋一個參考:)。
容器技術《Large-scale cluster management at Google with Borg》
容器和編排技術應該算這幾年比較熱門的一個板塊，這篇講述的是Google內部的容器Borg。
地址：Large-scale cluster management at Google with Borg
Lambda 架構《Lambda Architecture for Cost-effective Batch and Speed Big Data processing》
地址：Lambda Architecture for Cost-effective Batch and Speed Big Data processing
資料模型已經從最開始的離線T+1處理模式，轉變Lambda架構，現在還有新的純實時的Kappa架構。
這篇文章主要就是介紹Lambda架構的。
分散式快照演算法《Distributed Snapshots: Determining Global States of Distributed Systems》
文中介紹的Chandy-Lamport，基本是當前主流分散式計算系統的標配，包括Spark，Flink等等。
主要介紹分散式系統中如何保證快照一致性。
地址：Distributed Snapshots: Determining Global States of Distributed Systems
SQL優化器模型Volcano The Volcano Optimizer Generator: Extensibility and Efficient Search
Volcano 模型的經典論文，因為最近在看SQL解析優化相關內容，這部分可能會優先順序比較高。
The Volcano Optimizer Generator: Extensibility and Efficient Search
SQL優化器Cascades The Cascades Framework for Query Optimization
和上面一篇Cascades模型是一脈相承之作。
The Cascades Framework for Query Optimization
Dataflow 《The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing (VLDB)》
來自 Google 的將 stream processing 模型和 batch processing 模型統一的嘗試。在 Dataflow model 下，底層依賴 FlumeJava 支援 batch processing，依賴 MillWheel 支援 stream processing。Dataflow model 的開源實現是 Apache Beam 專案。
Flink 《Apache Flink: Stream and Batch Processing in a Single Engine》
Apache Flink 是一個處理 streaming data 和 batch data 的開源系統。Flink 的設計哲學是，包括實時分析 (real-time analytics)、持續資料處理 (continuous data pipelines)、歷史資料處理 (historic data processing / batch)、迭代式演算法 (iterative algorithms - machine learning, graph analysis) 等的很多類資料處理應用，都能用 pipelined fault-tolerant 的 dataflows 執行模型來表達。
地址：Apache Flink: Stream and Batch Processing in a Single Engine
MillWheel 《MillWheel: Fault-Tolerant Stream Processing at Internet Scale》
MillWheel 是 Google 內部研發的實時流資料處理系統，具有分散式、低延遲、高可用、支援 exactly-once 語義的特點。不出意外，MillWheel 是 Google 強大 infra structure 和強大 engeering 能力的綜合體現 —— 利用 Bigtable/Spanner 作為後備狀態儲存、保證 exactly-once 特性等等。另外，MillWheel 將 watermark 機制發揚光大，對 event time 有著非常好的支援。推薦對 streaming system 感興趣的朋友一定多讀幾遍此篇論文 —— 雖然此篇已經發表了幾年，但工業界開源的系統尚未完全達到 MillWheel 的水平。
地址：MillWheel: Fault-Tolerant Stream Processing at Internet Scale
END-TO-END ARGUMENTS IN SYSTEM DESIGN
這篇講述的是分散式理論方面的只是，論證了這樣一個觀點：端到端的可靠通訊，只能通過通訊兩端的application層來保證，而中介軟體(比如SQS, Kinesis, ActiveMQ, 到更低層Netty乃至TCP)只能提高效率，而無法保證通訊的可靠性。
這篇論文發表的時間是在1984年，算是比較老的文獻，不過其中的觀點到如今依舊不算過時。想看這篇文章是受到知乎一個大神的安利。
不過這種關於設計原則的論文一般都會寫得比較抽象，比較難啃。
地址：END-TO-END ARGUMENTS IN SYSTEM DESIGN
Rethinking the Design of the Internet- The end to end arguments vs. the brave new world
《Streaming System》
Streaming System是一本介紹流計算相關概念的書，該書沒有介紹很多實際的用例以及流計算的實現的具體方法，但是從理念上介紹了流計算相關的思想以及實現的特點，有助於提高對流計算的理解。
怎麼讀論文
每個人都有自己的學習方法，一些方法沒有好壞之分，只有適合不適合自己。所以這裡我也只說明我自己閱讀文獻的一些方法，希望能給各位小夥伴一點參考。
工具
工欲善其事必先利其器，好的pdf閱讀工具是必不可少的。我目前用過比較合適的是mac下的Adobe Acrobat DC for mac，免費的。而windows下的Adobe家的pdf沒用過不做評價。windows下用的是Gaaiho Reader。
我個人覺得讀檔案比較需要用到的兩個功能，一個是新增附註，一個是文字高亮。
上述兩個工具，都可以直接選擇文字標識高亮，還有右鍵新增附註，相對而言比較輕巧且均免費。
新增附註是可以讓你隨時對自己看的內容記錄下來，後面再看的時候按照自己附註的線索閱讀就行，否則過一陣子再看論文會有一種陌生感。
高亮則可以將重點部分高亮起來，起到突出重點的作用。
閱讀方法
我一直信奉輸出倒逼輸入，看我上面的論文介紹應該也發現了，很多東西我看完都會輸出。所以我學習東西的核心思想就是輸入倒逼輸出。
好處什麼的就不介紹了，見仁見智。只說一些點，首先，論文通常看一遍是不夠的，基本上都是兩三遍起步（一些發現沒價值的除外），一些關鍵點的論述更是應該多閱讀幾遍。
第一遍的時候可以先通篇泛讀，把握文獻的整體結構，這一遍我一般會先側重與論文出現的背景，它要解決的問題是什麼，與當前一些方案相比有什麼優勢（劣勢一般論文中不會說= =）。再看看解決方案的大概內容，有沒有比較感興趣或可能用的到的點。必要的地方做一做筆記，主要是為了後面回顧的時候快速明白看過的內容。
第二遍重點了解論文中解決方案的整體實現流程。其中肯定有些不懂的地方，還有精彩的，以後可能用的到的地方，這些內容都先記錄下來。一般第二遍後起碼會對論文的整體內容有比較清晰的瞭解。
第三遍主要是針對一些技術點的深入，可以與當前業界的一些方案相互比較，或者是查閱一下其他資料深入瞭解一些點的原理。甚至可以找到論文對應實現的系統，查閱對應的原始碼瞭解具體的實現過程。
如果還是覺得有不明白的地方，可以重複上述流程。
最後如果覺得論文有價值或者對論文方向感興趣，可以找一個點與論文結合起來輸出一篇文章。當然單純論文解讀也是可以，但那樣有點重複造輪子的感覺。
更好的做法，應該是尋找對應領域的文章，相互比對分析然後再產出。比如說看了Spark Streaming，可以結合Flink等系統的資料，輸出流處理方面的文章，不過這個最大的問題就是太耗時間了（哭笑），僅適用於想深入鑽研的領域且有足夠的時間。
以上~
PS：由於本人水平有限，部分闡述可能存在失誤，如果有發現問題歡迎在評論區指正。