Spark Streaming 架构及实践

一、流式计算的特点 如何定义流式数据？数据随着时间的推移而动态变化并且不断有新的数据产生，这样的数据就是流式数据，绝大多数的数据都是流式数据，静态数据是相对较少的。 特点： 1、实时性：整体上要求较低的处理延时，绝大多数要求秒级别，甚至毫秒级别。 2、数据无边界： 数据不会停，对于数据的计算也不会停。 3、容错要求：对 driver 和 executor 的要求 4、处理次数：针对每一条数据,主要分为三种。如图。 1541488186512296.gif 5、数据洪峰：特别重要的事情，特别是对于电商行业来说。预估、压测、合理分配、参数调优。 6、数据源复杂性：实际上，绝大多数都是如下的架构。 二、Spark Streaming 的运行模式及架构解析 运行模式分为四种： 1、Local:就是本地模式，经常用于本地开发测试。 2、Standalone：集群由 Master （负责资源管理和调度，存在单点故障）和 Worker （执行业务逻辑）节点组成。 3、Yam/Mesos：前者在生产环境中最常用的；后者在国内并没有火起来，以前者为例。优点如下：生态足够好；分布式资源调度的框架可以做到资源隔离，适度调度等。 Cluster 和 client 的区别： 1541488293889272.jpg 4、Kubemetes：新模式，社区还在探索阶段，是未来的趋势。 好处是：版本很灵活；扩容十分简单 未来趋势——容器化；弹性化的优点；节省资源；

Spark Streaming 架构解析 1541488364941581.jpg 1541488384650873.jpg

三、Spark Streaming 实践 tips Checkpoint 为什么需要 Checkpoint ？ 1、7*24 小时的应用是需要抵御意外或者恢复计算能力的； 2、依赖关系过于长，成本大 3、功能有限，容错性不高 什么时候做 Checkpoint ？ 1、希望能从意外中恢复 driver 2、存储中间数据状态 两种类型的 Checkpoint 1、metadata 元数据，定义了计算逻辑的不要信息 2、Data 类型的 Checkpoint Checkpoint 有什么局限性？ 如果应用挂了，发现应用程序有问题，可能之前的数据难以恢复 应用场景 Spark+kafka 是通用的场景。 Direct 方式的优点： 1、简化并行读取 2、高效 3、恰好一次语义 关于消费 kafka 并行： 通过扩上游的 partition 数量来提高消费并行度是可以的，但是利好程度有限。 在生产过程中往往会开背压机制（系统具备了根据系统的实际处理能力来进行自我调节的能力）和限速，这两个特性是结合起来用的，特别重要。 Foreach RDD 输出操作里最常用的一个编程范式 需要注意的点：把跟外部系统创建连接这样的实例的极点 ，否则容易出现异常。

四、Spark Streaming 应用分类以及示例 1、实时计算及展现类 对用户的行为或者其他行为进行是实时化的分析，并且结合可视化的展现，换句话说就是实时报表类的应用。比如说，每年电商 618、双十一都会有大屏类的展现。 后台架构图 1541488742716848.jpg SLB、ECS 左边是线上的 web 系统，用来埋点，直接到 RDS。 DTS 是阿里做数据传输的一个东西，实时高效的抓取操作往下游发。 datahub 理解成 kafka，是一个消息队列。 下游是熟悉的模块，一个计算引擎，最后输入到数据库里。 1541488799949732.jpg 下面这个例子，是后台登录系统的截图。典型的实时报表场景，描点的图实际上就是流计算。 2、实时监测及推荐类 对用户、业务、系统做实时监控。 应用在全栈交易检测、大促实时监控、实时欺诈检测（风控）、实施推荐或广告系统 两个例子； 1541488877226080.jpg 典型的推荐系统架构。 1541488907937539.jpg 风控系统 3、streaming ETL ETL 就是抽取、转化、夹带，数据仓库里面的一个概念。 做数据过滤，数据转化，甚至数据清洗。 对数据做分区，提高效率。 源端和目标端一般都会挂 kafka 五、流式计算引擎技术选型 常见的：storm、spark、samza、flink、heron …… 1541488559228849.jpg 对比三种引擎 Storm、spark、flink，总的来说，后两个都是不错的选择。 如何选？ 1、适用性最好。 2、没有差武器，只有用不好武器的人。选一个引擎去深入了解。 3、历史包袱。初创公司不需要包袱就可以选择最流行的。发展很久的话，就需要考虑历史的原因。