OI
OI是一个告警系统。用flume收集OC client上传的数据，然后传到spark，spark再对数据进行分析，生成一些metrics键值对，然后发到graphite做显示，seyren定期去graphite查询metrics键值对，当某个metrics超过伐值的时候报警给分析人员，分析人员再对相应的日志进行分析，找出异常的原因。
拓扑框架：
Performance调优环境：
一台机器部署了log server，收集OC client上传的日志。同时部署了一个flume agent将log日志传给spark的executor
两台机器部署spark的worker，运行的时候每个worker会启动一个executor，用于启动avro flume receiver和运行driver提交的task。Flume receiver用于接收flume agent的传递过来的数据。
一台机器部署master，上面还会运行driver，graphite和seyren。Driver用于spark task，提交到executor运行。
软件架构：
OI系统的主要分为三层
1.Spark层：调用spark的相应函数，如果map，flatmap，reduce等，spark会按照这些函数生成相应的task，提交给spark executor
2.业务层：用于处理log日志，将log转换成相应的metrics
3.数据库层：将top10的异常日志存储到数据库，方便分析人员查看
4.Graphite交互层：用于将metrics发送给graphite
遇到的问题：
1.在运行大概5，6个小时左右，driver或者work会抛出Stackoverflow的错误
分析的步骤：
（1）查看栈信息，发现一直在做scala list的序列化，开始怀疑是不是scala list序列化会导致栈溢出的问题，网上查看相关资料发现确实有某个版本的scala list会导致堆溢出问题，但spark不是用那个版本，排除这个可能性
（2）查看日志上下文，发现是在序列化或反序列化task的时候抛出这个错误的。查看源代码，定位到相应的代码，然后修改源代码，让在出错的时候，把需要反序列化的byte数组写到文件。
（3）写测试代码，解析byte数组，查看到底反序列化了那些对象。发现RDD的依赖过长，Duration 3的RDD会依赖Duration 2的RDD，Duration 2的RDD会依赖Duration 1的RDD
（4）查看源代码，发现UpdateStateByKey方法，会生成一个StateDStream（保持状态的DStream），这个DStream在计算RDD的时候会获取前一个Duration的RDD，然后和parent RDD做一个cogroupe，这样当前计算的RDD就会依赖前一个Duration。如果这个依赖一直存在的话就会发生StackOverFlow。
解决方案：
减少UpdateStateByKey方法的调用次数，程序中只调用一次（只调用一次的时候会将RDD的关联切断，如果调用两次，只有最后一个UpdateStateByKey生成的RDD的依赖关系会被切断）
2.Flume死锁的问题
在Flume运行一段时间后，发现flume agent不再tail log日志了。
分析的步骤：
（1）查看日志，发现某个线程在运行一段时间后没有相应的日志打出，猜测线程可能死了，或者被死锁
（2）用Jstack工具打出thread dump，发现有两个线程死锁了
（3）分析源代码发现了死锁
线程1
While（queue.size() == 0）{
Syncronized(takeLock){
takeLock.wait()
}
}
线程2
While（queue.size() == capacity）{
Syncronized(putLock){
putLock.wait()
}
}
对项目提出的优化：
1.写了专门用来监控performance相关参数的软件OI-Performance,在graphite上能够很好的展示这些属性，便于观察，监控的属性有SystemCpuLoad，ProcessCpuLoad，HeapMemoryUsage，GC的时间，disk util，network，以及一些业务属性
2.修改了spark中的storage level，减少了内存占用量
3.调整了JVM中new-ratio的比例，延长变量在新生代中存活的时间，减少full GC的时间
4.减少了collector这部环节，让agent直接发送数据到flume，让压缩过的数据直接传输到spark，减少了磁盘的读写以及内存的开销
5.减少了Avro格式转换成Seven自定义对象的环节，OI直接从generic record获取数据
6.替换flume的channel类型，让flume使用Memory Channel，减少磁盘的读写
为甚么选择flumehttp://www.kankanews.com/ICkengine/archives/89351.shtml
1.原来有一个系统叫lsps，做log日志收集，存储到hdfs中，然后做数据挖掘的，为了和这套系统兼容，保证数据收集部分功能和代码的一致性，重用了那套机制。那套机制就是用flume做的
2.Flume有高可靠性，扩展性，能够保证日志不丢失
3.Flume的配置和部署都很简单，修改配置后，可以自动加载
4.Flume提供了丰富的sink和source，对不同格式的日志可以很方便的切换，只支持thrift client向scribe发送数据。
为什么选择spark
Spark streaming和storm的区别是（两者都是分布式流处理框架）http://www.jdon.com/46591 ：
1.Spark支持保持状态
2.Spark有数据平滑窗口（sliding window），而后者需要自己去维护这个窗口
3.Spark是需要到一个duration才开始处理数据，storm是实时处理数据，有数据就处理。Storm只有秒内的延迟
4. 在Storm中,每个单独的记录当它通过系统时必须被跟踪，所以Storm能够至少保证每个记录将被处理一次，但是在从错误中恢复过来时候允许出现重复记录。这意味着可变状态可能不正确地被更新两次。另一方面，Spark Streaming只需要在批级别进行跟踪处理，因此可以有效地保证每个mini-batch将完全被处理一次，即便一个节点发生故障。简而言之,如果你需要秒内的延迟，Storm是一个不错的选择，而且没有数据丢失。如果你需要有状态的计算，而且要完全保证每个事件只被处理一次，Spark Streaming则更好。Spark Streaming编程逻辑也可能更容易，因为它类似于批处理程序(Hadoop)，特别是在你使用批次(尽管是很小的)时
5. Spark Streaming一个好的特性是其运行在Spark上. 这样你能够你编写批处理的同样代码，这就不需要编写单独的代码来处理实时流数据和历史数据
整套环境的failover机制
1.logserver那台机器的故障
（1）宕机 oc client会连接到其他log server，上传的数据可能会有部分丢失
（2）Flume 的source或者sink线程挂掉的话，不会重新启动
（3）当网络出现问题的时候，sink数据发送会失败，但会不断重试
2.Worker宕机
Receiver不会在其他地方启动
会重新在另外一个executor上启动task
3.master宕机
利用zookeeper来保证另一个master可以接着继续运行