大數據相關資料論文小結

前言

不知不覺，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