前言

不知不覺，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 『大資料存盤的進化史』，

論文地址：The Google File System

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決議這塊業務有需求的人可以考慮了解看看，

論文地址：Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources

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 專案，

地址：The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing (VLDB)

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：由于本人水平有限，部分闡述可能存在失誤，如果有發現問題歡迎在評論區指正，

參考：
Readings in Streaming Systems

標籤：Java

上一篇：Java比較器

下一篇：Java File類基礎決議 1