----本节内容-------
1.流式处理系统背景
1.1 技术背景
1.2 Spark技术很火
2.流式处理技术介绍
2.1流式处理技术概念
2.2流式处理应用场景
2.3流式处理系统分类
3.流式处理技术关键技术
3.1流式处理系统管道构建
3.2流式处理系统关键技术
3.3用户行为分析系统介绍
4.问题答疑
5.参考资料
---------------------
1、流式处理技术
1.1 技术背景
业务驱动技术发展，脱了了业务的技术，最多就是一个研究性的东西，流式处理技术的火爆源于业内对计算速度的需求。目前互联网公司、运营商、物联网公司等对流式处理技术的需求来源是多方面的，一是企业确实每分每秒都在产生海量数据，二是管理层对数据的价值有更高的认识，三是技术的发展，尤其是Hadoop等技术，让数据变现成为可能【个人想法：关于大数据如何变现，其实是一个大大的课题】。
通过大数据技术，分析挖掘，产生有价值的结论，或者支撑公司日常运营，或者卖个用户或者第三方，完成数据到信息到利润的转变，而流式处理技术是大数据技术的一个非常重要的技术方向。流式处理技术被越来越多的企业应用到实践中，根据行业的不同，流式数据的来源也不一样，有如下几大类：
· 用户点击日志
在App或者网页中嵌入日志采集程序，埋点，跟踪用户的点击行为，这种以互联网公司为典型代表，有BAT等，比如京东购买东西，点击搜索的时候就产生一条日志，ip，浏览器，关键字等。
·机器日志
机器产生的日志信息，如CPU、内存日志等，（个人想法：这个也只有巨无霸公司才有这样的需求，一般的公司服务器不会产生如此多的数据，要用到Hadoop技术，一个不大不小的集群硬件、人才、运维也是不小的投资）
· 终端设备产生的数据
比如物联网和摄像头，确实物联网传感设备是能够产生海量数据的，尤其是做智慧城市项目的物联网公司，在各个城市部署窄带基站，通过传感设备，每分每秒都在产生数据，确实惊人。但是对于摄像头这块，还是有很多问题的，传统的摄像头采集到的数据都是非结构化数据，想利用大数据技术做分析，难度和成本都非常大，新型摄像头能采集结构化数据，比较容易做数据分析，但是成本昂贵。
1.2 Spark技术很火
1）Spark技术非常火
Spark火起来，第一是发展越来越成熟，并且不仅仅局限于做计算框架，第二是有一帮人在推Spark，时不时的去推，去组织峰会，举办论坛，好的技术很多，但是能被大家广泛知道的好技术并不多，背后有一只手在引导大家去认识他，认识之后发现确实还可以，那么久火了。火不火用数据说话，下面是谷歌12年至今关于spark和hadoop关键字的搜所量。
2）Spark组件谁更火
这个排名可以，董给出的这个可以调整自己的学习精力，先学哪个后学哪个，有个侧重，搜索量
saprk sql >spark streaming >mllib，而对于SparkR，GraphX这些就相对小众一些。
3）大数据人才的需求
这个就没有啥说的，鬼知道是神马行情，而且薪资和能力有关，招聘行情和季节有关，想切身了解，海投一轮简历就知道水深水浅了。下面的数据仅供参考。
2.流式处理应用场景
2.1流式处理技术概念
董先生将主要介绍是关于流式处理技术概念性的东西，不做介绍具体技术细节，用最简单的话将抽象、专业的东西表达出来。根据我的笔记，大意如下：
企业都有海量的数据，数据是怎么来的，如何形成海量的数据的？其实和流水是一样，都是通过日积月累，将数据慢慢积累，一点点跟流水一样积少成多，跟流水一样流进企业的数据库。
学院派一点描述流式数据：流式数据是大数据环境下的一种数据形态，其理论诞生于20世纪末，并在云计算和物联网发展下逐步成为当前的研究热点。流式数据与传统的数据是相对的。与静态、批处理和持久化的数据库相比，流式计算以连续、无边界和瞬时性为特征，适合高速并发和大规模数据实时处理的场景。
大数据环境下，流式数据作为一种新型的数据类型，是实时数据处理所面向的数据类型，其相关研究发展迅速。这种实时的流式数据，存在如下几个特征：
-
实时、高速：数据能以高并发的方式迅速到达，业务计算要求快速连续相应。数据处理的速度至少能够匹配数据到达的速度。
-
无边界：数据到达、处理和向后传递均是持续不断的。
-
瞬时性和有限持久性：通常情况下，原始数据在单遍扫描，处理后丢弃，并不进行保存；只有计算结果和部分中间数据在有限时间内被保存和向后传递。
-
价值的时间偏倚性：随着时间的流逝，数据中所蕴含的知识价值往往也在衰减，也即流中数据项的重要程度是不同的，最近到达的数据往往比早先到达的数据更有价值。
2.2 流式处理应用场景
在实际生产中，有 哪些场景带来实际价值，董先生介绍了以下几个方面：
1）. 社交网络趋势追踪
趋势追中，微信、微博数据，搜索量，点击量的追踪，某个时间段达到了顶峰，达到热门 ->新闻搞
2）.实时推荐系统
淘宝购买的时候的推荐，优酷土豆等中看完视频后，会列出视频中还有哪些人浏览了这个视频，哪些视频和你观看的视频相似等等，
3）网络指标实时统计
4）广告系统
5）信用卡欺诈
2.3 流式处理系统分类
我觉的这个图非常好，简单明了，结合董先生讲的东西，加上我自己的理解进一步阐述一下。流式处理系统主要分为三类：1）批处理，2）微批处理，3)流式处理
1).批处理
一次性处理，一批一批，高吞吐量，牺牲延迟，面向静态数据集，分钟或者小时级别，MR,SPARK都是批处理。
2).流式处理
面向行的和面向微批处理的 ,来一条处理一条，面向行级别，延迟低，毫秒级，如storm(毫秒级),Apache samza（亚秒级）.
3).微处理
介于1和2之间，处理每一批都足够快，模式上将批处理改成流处理，但是处理数据的粒度没有流处理那么小，流处理是行级别，微处理，是多行，一系列行积攒起来后处理，以spark streaming做为典型代表。link也是，来一条积攒一会再来处理。
其实对于实时性能要求非常非常高的需求场景，应该有但是不多，董先生介绍微处理，既能解决批处理解决的问题，又能解决流式处理的问题，在大部分企业就已经足够用了。所以融合了批处理和流式计算的引擎逐渐流行，充分结合批处理和流式计算殷勤的优势，而且更容易构建Lambda 架构。这种混合类型的计算引擎比较流行的有Apache Spark，Apache Flink，Apache Apex，后面2个不甚了解。
3.流式处理技术关键技术
3.1 流式处理系统管道构建
1) 流式处理思想
数据源：源源不断的产生数据。
数据缓存：数据源写数据到缓存系统，数据缓存作为缓冲层，完成数据初步汇聚。
流式引擎：引擎从缓存系统取数据 ，流式引擎实时分析。
结果存储：数据被引擎处理之后，存入特定数据库。
整个过程就是：数据源->数据缓存->流式引擎->结果存储。
为什么不直接写流式引擎呢？
原因数据源产生的数据量非常大，直接写入，流式引擎可能扛不住，若果数据源同时10万条数据，如果引擎只处理10条，分分钟冲跨掉，而有了数据缓存，先接纳数据，后处理，会比较靠谱。
这是一个伟大的指导思想，而这种指导思想从古到今被人广泛使用。军事上战略缓冲区就是这个指导思想，非接触作战。
上面这张图是从具体实现的角度来描述的。
数据源：数据的生产者，主要有APP，网站和物联网设备。这里想说一下我对物联网大数据的理解，因为物联网和手机终端设备不一样，终端通讯有专门的物联网通讯协议，并且会充分考要耗能问题、数据传输、窄带网络、设备与网关通讯等问题，因此需要有专门的物联网平台来处理高并发的设备连接和消息通讯，并且实际业务场景中，还有大量的设备相关指令的上报和下发，这种专门的物联网平台目前业内也有很多公司在做，但是成熟度，比如华为，浙江天地人科技等等，他们都有经过多年生产的物联网消息透传平台。因此，仅仅只用kafka这类的消息队列组件是有局限性的，通常在这之前还有一层物联网数据和消息接入平台来做预处理和解析，处理之后再交给kafka。（个人观点，仅供参考）
kafka：分布式消息队列，不断从消息队列取数据，根据数量的不同，选择不同的数据存储数据，关系型，内存，分布式的kv数据库等等。
Spark Streaming：微处理技术组件，介于流处理和批处理之间的组件。
Mysql/hbase/redis:数据结果存放，什么场景下选什么数据库，根据业务场景来选择。
mysql：不会很多的，要做进一步聚集
hbase：数据量非常大的，指标数据，仅仅做直观展示。
redis：少量的结果，使用内存，大内存就放不小，可以高效获取，如推荐系统，给其他模块获取
3.2 流式处理系统关键技术
1.流式处理管道的构建
1)流式数据收集
实时手机数据、网站数据、客户端生产数据，kafka集群做大数据的缓存，用户使用各种产品产生数据，各种视频产生的日志数据发到loadbalance(负载均衡器，软件或者硬件实现) ，负载均衡器将数据发到httpserver，简单的汇总，写入到kafka的汇总。
2）KAFKA
Kafka有三个组件produce、roker，consumer，采用生产者和消费者模式，是一款分布式数据缓存队列，可通过zk协调，以主题的方式组织在broker上（一般文件系统时采用目录或文件进行组织）
以topic来组织，consumer读完就删掉（也可以设置缓存几天），broker可以有多个副本
HttpServer相当于kafak的produecer,而Spark streaming相当于consumer，从broker上存放数据
3) Spark Streaming
将流式计算转为一批很小的、确定的批处理作业，以秒为单位将数据流切分成离散的作业，将每批数据看作RDD，使用RDD操作符处理，最终结果以RDD为单位返回，写入HDFS或者其他系统。
SparkStreaming将流式计算转为批处理问题，每一批都足够小，看上去像流式处理，将数据流切分成一段一段，切分成秒级，足够小，小到几秒钟就计算完了。另外Spark Streming优势提供了丰富的函数，表达丰富的表达算法。安装窗口10秒规约一次，还有带有状态的算子，非常多的算子，实现比storm要好很多很多，storm表达，groupbykey，reducebykey非常复杂。
4）数据存储
Mysql/hbase/redis:数据结果存放，什么场景下选什么数据库，根据业务场景来选择。
mysql：不会很多的，要做进一步聚集
hbase：数据量非常大的，指标数据，仅仅做直观展示。
redis：少量的结果，使用内存，大内存就放不小，可以高效获取，如推荐系统，给其他模块获取
3.3流式处理系统关键技术
1）.计算方式
关键技术，面试常用到，有几种计算方式和计算类型
（1） 固定窗口
每隔一分钟统计一次，1分钟内最火的关键字
（2） 滑动窗口
每隔5分钟统计一次，窗口之间有交叉，窗口内部的指标
（3） 会话计算
董先生举例说明什么是会话：app，ofo，首先打开app，从输入到使用自行车，到结束，这就是一个会话，在会话中进行一系列的动作，登录，搜索，购买，评论，退出，一段时间没访问，就自动退出。用会话为单位，进行分析，一系列的行为，行为有先后关系，按时序进行分析。
新版本的spark全都支持。
2）一致性语义
有且仅有一次：发一条接收一条，不多接收，也不少接收，假设有问题，spark streaming 任务挂掉了，重算，那也是保存了2次，推测执行，2个任务计算同一次结果，空间换时间，结果累加2次，会产生副作用。
最多一次： 发一条，最多一次，发了，就不发了
最少一次：发一条，收到了2次，有冗余数据发过去，比较容易实现，kafka，可能写2次，消息保留2次，主键允许冲虚，如银行的，有些被处理2次，后果严重，
监控和报警：至少一次，保证所有实现的函数都是无状态的，幂等的（执行1,2,3次结果都是一样的，累加就不是幂等的）。有些操作是，kv结果的存储，给定的主键唯一，将结果保存，key相同，后面会覆盖前面的计算结果。
累加转为幂等，将batch做一个和，在外部写一个sql，对某时间内的进行累加
3）乱序和延迟到达
乱序和延迟到达：各种日志数据到达系统的时间不一样，网络问题导致，到达的顺序都是不一样的，流式计算统计某段时间内访问量，乱序，延迟等，（1）延迟到达：5点半的，10点多到达，这就是延迟到达，（2）乱序问题：相同的时间，访问的服务到达顺序不一样，就是乱序问题。1点可能晚于1:05，产生的问题，这个问题就不好解决。
Spark2.0新版本，对此作了很好的解决。Apache beam，也作了很好的解决，乱序和到达的问题
3.4 用户行为分析系统
每个时间段，用户产生付费的量，营收等实时看到
1.嵌入代码，收集用户行为，放入kafka
2.spark streaming收集
3.写入redis
4.可视化
为什么用spark streaming和kafka来做，
· 如果数据量很大，分布式资源做高并发计算
· 如果目前数据量不大，但将来很大，提前上，可扩展性好
4.问题答疑总结
记录了一些具有参考价值的问题和回答
1）.先学习scala，是一个趋势，java是入行大数据的基本语言
2）.flume优势提供了各种嵌入式的数据源，kafka看做是消息总线
3）传统的.OLAP,spark sql可以做
4).spark R也比较小众，grahx比较小众，
5).实时去重如何做？
只能做某个时间窗口内的去重，实时去重还是比较难做的，把历史数据都放到kv库里面，来一条查一条。
6).hbase替代方案，尝试Cassandra
7).kafka如何做有序处理，
8)spark语言基础:java，提倡多谢scala
9)Spark2.0稳定版？
企业生产可以用 2.1.0
10).flink 比较小众
11)学习spark，只会python也可以，不会java的人，还是学习下
12).Spark立足于hdfs，spark只是计算引擎，比如说kafaka，hdfs等等
13）datafrme,dataset用的最多，spark core，rdd简单，效率高
14).随机存取修改，可用mongdb之类的
15）Spark sql调优，比较简单，暴露的东西并不多，Spark sql就是为简化用户调优而实现
16）内存越来越少原因？内存一直增长，可能资源有泄露，如插入到map一直不释放
17）关系型到spark sql的关键问题是什么？将关系型数据库迁移到 SparkSQL 的关键是什么？
sql重写，特殊的语法，写法要变动
18）.如果在spark streaming实时计算中需要读取关系型数据库中的历史数据，如何实现？
jdbc之类的东西，单机程序并行化来，odbc
19）kafka数据持久化到哪儿？hdfs?
会写到本地磁盘，自己处理分布式容错
20)spark支持四种语言： java，scala，python和r
21）kafka会存在磁盘上，kafka一般设计个副本，kafka 2个，一般保留1~3天的数据
22）hadoop生产集群搭建如何考虑磁盘raid，raid0和jbod如何选择，Hadoop生产集群系统盘分区如何规划的，以及周边配套服务器角色都有哪些，如何规划？【我的问题，董先生可能没看到，没有回答】
23）yarn：2.6.2.7,2.3.2.4都可以，spark都支持，
24）spark stream read kafka 如何存储offset，使用checkpoint？还是用额外的ZK或者RDB？那种比较好？，大部分在zookeeper里面
25）spark和hadoop哪个代码更好
spark更简洁，hadoop冗余
26）spark不一定非要运行在yarn，也可以mesos
27）streaming 是否必须要设置checkpoint？什么时候应该强制设置？
mapv的states时，就必须要，看场景，checkpoint大大降低性能
28）Druid在企业中应用的多么？应用的一般
29）kafka的partition怎么调优，kafka的partition会影响spark streaming的数据读取
会影响，尽可能的，调优也没有很多方法，将并发度提高，
30）不适合spark处理的尝尽
OLAP，sql在线实时分析，sparksql不是很适合，
31）apache上下载可以用与生产环境么？
可以，Spark用2.1.0
5.参考资料
1.http://blog.csdn.net/tagst/article/details/49642787-流式计算的理论与技术
2.http://blog.csdn.net/zhangzhaokun/article/details/8821385
3.http://www.cnblogs.com/panfeng412/archive/2011/10/28/2227195.html对互联网海量数据实时计算的理解
4.https://wenku.baidu.com/view/fd91e734cd7931b765ce0508763231126fdb775f.html流式处理框架storm-spark和samza的对比
5.董西成ppt