spark

spark和map-reduce(有时候hadoop会指这个，我还是叫hadoop是个整体设计)，flink这三个都是并行计算的方式。map-reduce只支持批处理，另外两个都支持。

官方：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

计算模式

基于内存迭代（对比与map-reduce输出落盘再下一轮），超出也会溢出到磁盘，但尽量不要，资源限制主要是内存和网络，可以序列化，评估内存，减少RDD的大爱小，（OutOfMemoryError，不是因为你的RDD不适合内存，而是因为你的一个任务的工作集，例如其中一个reduce任务groupByKey，太大了。最简单的解决方法是 增加并行度，以便每个任务的输入集更小。Spark可以有效地支持短至200毫秒的任务，因为它在许多任务中重用了一个执行程序JVM，并且它具有较低的任务启动成本，因此您可以安全地将并行度提高到超过群集中的核心数。）

job=>stage=>DAG。RDD的分区。感觉就是RDD的转化分区发到不同节点上

Stage: 每个Job会被拆分成多组Task， 作为一个TaskSet， 其名称为Stage，Stage的划分和调度是有DAGScheduler来负责的，Stage有非最终的Stage（Shuffle Map Stage）和最终的Stage（Result Stage）两种，Stage的边界就是发生shuffle的地方

DAGScheduler: 根据Job构建基于Stage的DAG（Directed Acyclic Graph有向无环图)，并提交Stage给TASkScheduler。 其划分Stage的依据是RDD之间的依赖的关系找出开销最小的调度方法，如下图

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经过操作变成中间结果保存在内存中。整个流式计算根据业务的需求可以对中间的结果进行叠加或者存储到外部设备

窗口

如该图所示，每一个窗口时间的幻灯片在源DSTREAM，落入窗口内的源RDDS被组合及操作，以产生加窗DSTREAM的RDDS。在这种特定情况下，操作应用于最后3个时间单位的数据，并按2个时间单位滑动。这表明任何窗口操作都需要指定两个参数。

希望通过每隔10秒生成最后30秒数据的字数来扩展

窗口长度 - 窗口的持续时间（图中的3）。

滑动间隔 - 执行窗口操作的间隔（图中的2）。

这两个参数必须是源DStream的批处理间隔的倍数（图中的1）。

执行流程：

容错

1.数据库流：重新读

2.网络流：

预写日志功能的流程是：

1）一个SparkStreaming应用开始时（也就是driver开始时），相关的StreamingContext使用SparkContext启动接收器成为长驻运行任务。这些接收器接收并保存流数据到Spark内存中以供处理。

2）接收器通知driver。

3）接收块中的元数据（metadata）被发送到driver的StreamingContext。这个元数据包括：（a）定位其在executor内存中数据的块referenceid，（b）块数据在日志中的偏移信息（如果启用了）

每个DStream拷贝两份打到其他机器

checkpoint:元数据、数据Dstream(每次计算的RDD集合),

背压

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

简单看下storm. zeromq发送消息，容错是靠消息的ACK和重试。只保证至少一次完整处理，不保证只处理一次。

要用户提交拓扑而非自己生成