【4.分布式计算】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和对应的做业。
读取保存在日志中的块数据（蓝色箭头）——在这些做业执行时，块数据直接从预写日志中读出。这将恢复在日志中可靠地保存的全部必要数据。
重发还没有确认的数据（紫色箭头）——失败时没有保存到日志中的缓存数据将由数据源再次发送。由于接收器还没有对其确认。

总体：