大数据相关资料论文小结

前言

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