spark

spark和map-reduce(有时候hadoop会指这个，我还是叫hadoop是个整体设计)，flink这三个都是并行计算的方式。map-reduce只支持批处理，另外两个都支持，其中spark的流处理基于批处理，flink见：https://segmentfault.com/a/11...，更多数据存储内容见：https://segmentfault.com/a/11...。
本文介绍spark的逻辑架构,分布式部署架构，计算模式/流处理/容错 等。
官方：batch是map-reduce的110倍，支持SQL and DataFrames, MLlib for machine learning, GraphX, and Spark Streaming.和map-reduce一样可应用于多种隔离（Spark using its standalone cluster mode, on EC2, on Hadoop YARN, on Mesos, or on Kubernetes）和存储（Access data in HDFS, Alluxio, Apache Cassandra, Apache HBase, Apache Hive, and hundreds of other data sources）之上

架构

逻辑架构

部署架构

部署在yarn中模式：
YARN-Cluster模式下，Driver运行在AM(Application Master)中，它负责向YARN申请资源，并监督作业的运行状况。当用户提交了作业之后，就可以关掉Client，作业会继续在YARN上运行，因而YARN-Cluster模式不适合运行交互类型的作业，用于生产环境
YARN-Client模式下，Application Master仅仅向YARN请求Executor，Client会和请求的Container通信来调度他们工作，也就是说Client不能离开。用于测试环境

一个可以申请多个container，每个coarseGrainedExecutorBackend中可以多线程执行多个task

cluster启动和执行流程：

启动为图中黄色部分，执行黑色部分。

计算模式

RDD resilient distributed dataset (RDD), which is a collection of elements partitioned across the nodes of the cluster that can be operated on in parallel.（which is a fault-tolerant collection of elements that can be operated on in parallel）不可变，可以分布式存储和缓存，利用Lineage（追踪RDD依赖）可以容错恢复。(与传统数据集对比https://databricks.com/blog/2...
基于内存迭代（对比与map-reduce输出落盘再下一轮），超出也会溢出到磁盘，但尽量不要，资源限制主要是内存和网络，可以序列化，评估内存，减少RDD的大小，（OutOfMemoryError，不是因为你的RDD不适合内存，而是因为你的一个任务的工作集，例如其中一个reduce任务groupByKey，太大了。最简单的解决方法是 增加并行度，以便每个任务的输入集更小。Spark可以有效地支持短至200毫秒的任务，因为它在许多任务中重用了一个执行程序JVM，并且它具有较低的任务启动成本，因此您可以安全地将并行度提高到超过群集中的核心数。）
RDD的执行会被转化为DAG，RDD在Lineage依赖方面分为两种Narrow Dependencies（父只被一个子引用）与Wide Dependencies，宽依赖(即shuffle操作)是stage划分的依据，窄依赖可以执行流水线(pipeline)操作
job=>stage=>DAG。
Stage: 每个Job会被拆分成多组Task， 作为一个TaskSet， 其名称为Stage，Stage的划分和调度是有DAGScheduler来负责的，Stage有非最终的Stage（Shuffle Map Stage）和最终的Stage（Result Stage）两种，Stage的边界就是发生shuffle的地方，每个stage每个分区一个task并行执行
DAGScheduler: 根据Job构建基于Stage的DAG（Directed Acyclic Graph有向无环图)，并提交Stage给TASkScheduler。 其划分Stage的依据是RDD之间的依赖的关系找出开销最小的调度方法，如下图

https://jaceklaskowski.gitboo...

spark streaming

https://spark.apache.org/docs...
接收的数据必须存储在内存中
Spark Streaming是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是Spark Core，也就是把Spark Streaming的输入数据按照batch size（如1秒）分成一段一段的数据（Discretized Stream），每一段数据都转换成Spark中的RDD（Resilient Distributed Dataset），然后将Spark Streaming中对DStream的Transformation操作变为针对Spark中对RDD的Transformation操作，将RDD经过操作变成中间结果保存在内存中。整个流式计算根据业务的需求可以对中间的结果进行叠加或者存储到外部设备

窗口

希望通过每隔10秒生成最后30秒数据的字数来扩展
窗口长度 - 窗口的持续时间（图中的3）。
滑动间隔 - 执行窗口操作的间隔（图中的2）。
这两个参数必须是源DStream的批处理间隔的倍数（图中的1）。

背压

估计处理速度。flink不需要，有空闲buffer才接受

简单看下storm. zeromq发送消息，容错是靠消息的ACK和重试。只保证至少一次完整处理，不保证只处理一次。
要用户提交拓扑而非自己生成

容错

1.数据库（HDFS/S3）流：
checkpoint+重新读，receiver失败恢复重启读取，driver失败恢复将从checkpoint恢复
checkpoint:元数据(配置，不完整的批次，操作)、数据Dstream(每次计算的RDD集合，是否提交标识),

2.网络流：
checkpoint+wal(从诸如Kafka和Flume的数据源接收到的所有数据，在它们处理完成之前，一直都缓存在executor的内存中。纵然driver重新启动，这些缓存的数据也不能被恢复)

接收数据（蓝色箭头）——接收器将数据流分成一系列小块，存储到executor内存中。另外，在启用以后，数据同时还写入到容错文件系统的预写日志。
通知driver（绿色箭头）——接收块中的元数据（metadata）被发送到driver的StreamingContext。这个元数据包括：（i）定位其在executor内存中数据位置的块reference id，（ii）块数据在日志中的偏移信息（如果启用了）。
处理数据（红色箭头）——每批数据的间隔，流上下文使用块信息产生弹性分布数据集RDD和它们的作业（job）。StreamingContext通过运行任务处理executor内存中的块来执行作业。
检查点计算（橙色箭头）——为了恢复的需要，流计算（换句话说，即 StreamingContext提供的DStreams ）周期性地设置检查点，并保存到同一个容错文件系统中另外的一组文件中。
恢复：

恢复计算（橙色箭头）——使用检查点信息重启driver，重新构造上下文并重启接收器。
恢复元数据块（绿色箭头）——为了保证能够继续下去所必备的全部元数据块都被恢复。
未完成作业的重新形成（红色箭头）——由于失败而没有处理完成的批处理，将使用恢复的元数据再次产生RDD和对应的作业。
读取保存在日志中的块数据（蓝色箭头）——在这些作业执行时，块数据直接从预写日志中读出。这将恢复在日志中可靠地保存的所有必要数据。
重发尚未确认的数据（紫色箭头）——失败时没有保存到日志中的缓存数据将由数据源再次发送。因为接收器尚未对其确认。

整体：