某人视频中提到的 Spark Streaming 优化的几点事项

某人，并未提他的名字，是因为看的视频是1年前的，视频里他吹得厉害。我看视频时，查了一下他在视频里说的要做到的东西，结果上网一查，就看到了很多人说他骗了钱后，就不管交了学费的人了。真假无从查起。但是无风不起浪。也真没查到他说的要做出来的东西发布出来。所以这里不那人的名字了。只把他说的知识拿过来，做些笔记。

一。Batch中Task处理时间大

Spark Streaming 的处理模式是按照 Batch Duration 进行 Micro Batch Computation 的，且如果上一批数据没有处理完的话是不会处理下一批数据的！！ 这会导致几个结果：

1. 如果前面一个 Batch 数据量突然间特别大的话，就会导致计算的高度延迟，使得当前的 Batch 不能够得得到及时的计算

2. 在一个 Batch 处理的时候，如果 Task 处理的时间波动比较大（例如说：数据倾斜、数据的峰值，出错等），其它的 Task都已经处理完了，所以整个 Batch 处理就只是在等待这个Task处理完成，却不能够使用 Memory 和 Cores 等资源处理下一个 Batch 任务，会形成资源浪费。

3. JVM GC的巨大负担

解决方法： 不要等待。意思就是：无论 Batch Duration数据大小和处理的复杂度，都会立即完成当前 Batch的处理，然后立即去处理下一个 Batch的任务。

怎么做：Spark Streaming 的业务处理逻辑放在线程池中。Spark Streaming程序执行的时候业务逻辑就是以 Task 的方式放在线程池中的，所以可以最大化地复用线程，从而最佳化的使用硬件资源。模拟代码：

dstream.foreachRDD(rdd => {

rdd.foreachPartition( item => {

//业务逻辑处理部分，使用线程池。需要注意的是：线程数受限于物理硬件，所以需要根据实际情况设定线程池中的并发 Task 的个数

})

})

二。zookeeper 的 connection timeout 时间和Session timeout 的时间

在处理大数据量的情况下，GC 的时间很有可能要十几秒，这时，如果设置的 timeout 时间比较短的话（默认的connection timeout 是10秒，Session timeout 时间是6秒），就会出问题。

三。Spark on YARN

大的公司一般采用这种方式，因为还有其它的框架运行在YARN上，YARN 统一管理计算资源的分配。为了确保 Spark 能分配到足够的资源，推荐 https://mapr.com/blog/label-based-scheduling-hadoop-clusters/

四。Backpressure

设置限流器，每次Job结束后，计算吞吐量，更新限流器的值。可以看 JobScheduler， ReceiverInputDStream，RateController, RateLimiter，ReceiverTracker中的源码

五。在 End to End 的流处理程序中，把流处理的结果放入 Hbase。

往 HBase 中存储数据的过程如下： 对于每一次的数据插入操作都会放在内存的缓存 MemStore 中，MemStore达到上限的时候，HBase会将其中的数据输出到本地的名称为 StoreFile 的文件中。在HBase中是通过 Column Family 来组织数据的（其数据结构为 Store），也就是说每个 Column Family 中有一个Store， 而一个 Store 中有很多来自 StoreFile的文件，HBase的工作机制是当StoreFile达到一定上限的时候会使用线程对这些小的 StoreFile 合并成为大的 File。这就导致 HBase 插入数据非常高效。所以 HBase在生产环境下是；Streaming外部存储的一种非常理想的选择，尤其是在数据量特别大的时候且J2ee或者移动端要实时查询海量的 Spark Streaming处理结果就特别适合。

操作 HBase 的时候每次都是基于 Table 进行操作的，HTable 是 HBase 的客户端， HTable 的弊端在于适合单表操作，但是在多线程的读写操作下不是线程安全的。执行 Put 操作，如果是多个线程共享一个 HTable 实例的话，由于不是线程安全的，这会导致写到缓存区数据冲突。其实匀们在这里已经使用了线程池来维护 HTable，这个问题基本已经不存在了，但其实还是有一个非常重要的性能消耗点可以优化。在内部创建 HTable 的时候需要 HConnection，这个实例对象的创建是非常耗时的（其实 HTable是轻量级的消耗），此时此时我们可以做以下的考虑: 1. 只有一个 HConnection 实例对象，所有的 HTable 都基于穿上实例对象； 2. 基于 HConnection 对象实例，让所有的线程来共享。

六。 Spark Streaming 的几个意见

1. Duration 设置大一点值

2. 开启2~5个Receiver

3. Spark Streaming 使用的Cores的数量 = concurrentJob的数量 * Receiver的数量 * BatchDuration / blockInterval

七。防DDos攻击

在处理DDos攻击的时候，肯定会使用到 Windows 窗口操作，updateStateByKey等。选定的窗口大小和滑动时间，以前的项目中设定的窗口大小是一个小时，滑动窗口是5分钟。  如何面对网络风暴？这个时候因为数量流量不稳定，所以要开启BackPressure机制。

随着服务的运行历史数据越来越多，此时如何高速地读写数据成为一个非常大的瓶颈。客户采用的是Redis，当时从长久服务的角度来看，个人建议采用HBase或者Canssandra。