一。
spark 是一个快速且通用的集群计算平台
基于内存的运算
通用性；降低维护成本
Spack的设计容纳了其它分布式系统拥有的功能
批处理，迭代式计算，交互查询和流处理等
spark是高度开放的；Python Java scala haddoop
二。
spark core:
包含spark的基本功能，任务调度，内存管理，容错机制
内部定义了RDDs，弹性分布式数据集
spark sql:
是spark处理结构化数据的库
spark streaming：
实时数据流处理组件，类似Storm
Spaek Streaming提供了API来提供操作实时流数据。
应用场景，企业中用来从Kafka接收数据做实时统计。
milb:
包含通用机器学习功能的包，分类，聚类，回归
支持起集群上的横向扩展
机器学习
graphx:
处理图的库，并进行图的并行计算
cluster managers：
集群管理，Spark自带一个集群管理是单独调度器。
常见的集群管理包括Hadoop YARN，Apache Mesos
紧密集成的优点
1.spark底层优化了，基于spark的底层组件也会得到相应的优化。
2.紧密继承节省了各个组价组合使用时的部署，测试等时间
3.向spark增加新的组件时，其他组件，可立刻享用新组建的功能。
三。
spark与Hadoop的比较
Hadoop的应用场景：离线处理，对时效性要求不高（数据储存在硬盘中，执行时间一般在几分钟，几个小时）
spark的应用场景：对时效性要求高，机器学习领域（spark中间的数据尽量储存在内存中大大加快了Spark任务的计算速度一般几秒钟或者几分钟，在迭代方面很适合）
kafka（流处理平台）
生活中无时无刻都在生产着数据，数据产生到存档会产生日志（存储模式）
有了数据，就有了数据的生产者，同时只有数据流动起来才能产生真正的价值
于是就有了数据流，既然有了数据流就有了数据的消费者。（消费模式）
特性：
1它是可以发布，订阅，记录数据的流 类似一个消息队列
2它是一个数据流存储的一个平台 并且有错误容忍的
3数据产生的时候就进行消息处理
应用场景
1.构建实时数据流管道 处理的数据有很强的数据依赖关系的时候（数据的传输上）
2.构建一个实时的数据处理应用程序 它能转换或者响应这个数据流 (数据的处理上)
负载均衡：ngaix lvs
1.监控：主机通过Kafka发送与系统和应用程序健康相关的指标，然后这些信息会被收集和处理从而创建监控仪表盘并发送警告。
2.消息队列： 应用程度使用Kafka作为传统的消息系统实现标准的队列和消息的发布—订阅，例如搜索和内容提要（Content Feed）。比起大多数的消息系统来说，Kafka有更好的吞吐量，内置的分区，冗余及容错性，这让Kafka成为了一个很好的大规模消息处理应用的解决方案。消息系统 一般吞吐量相对较低，但是需要更小的端到端延时，并尝尝依赖于Kafka提供的强大的持久性保障。在这个领域，Kafka足以媲美传统消息系统，如ActiveMR或RabbitMQ
3.站点的用户活动追踪: 为了更好地理解用户行为，改善用户体验，将用户查看了哪个页面、点击了哪些内容等信息发送到每个数据中心的Kafka集群上，并通过Hadoop进行分析、生成日常报告。
4.流处理：保存收集流数据，以提供之后对接的Storm或其他流式计算框架进行处理。很多用户会将那些从原始topic来的数据进行 阶段性处理，汇总，扩充或者以其他的方式转换到新的topic下再继续后面的处理。例如一个文章推荐的处理流程，可能是先从RSS数据源中抓取文章的内 容，然后将其丢入一个叫做“文章”的topic中；后续操作可能是需要对这个内容进行清理，比如回复正常数据或者删除重复数据，最后再将内容匹配的结果返 还给用户。这就在一个独立的topic之外，产生了一系列的实时数据处理的流程。
5.日志聚合。使用Kafka代替日志聚合（log aggregation）。日志聚合一般来说是从服务器上收集日志文件，然后放到一个集中的位置（文件服务器或HDFS）进行处理。然而Kafka忽略掉 文件的细节，将其更清晰地抽象成一个个日志或事件的消息流。这就让Kafka处理过程延迟更低，更容易支持多数据源和分布式数据处理。比起以日志为中心的 系统比如Scribe或者Flume来说，Kafka提供同样高效的性能和因为复制导致的更高的耐用性保证，以及更低的端到端延迟
6.持久性日志：Kafka可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据回复提供一种重新同步的机制。Kafka中日志压缩功能为这种用法提供了条件。在这种用法中，Kafka类似于Apache BookKeeper项目。
如果你做即时通讯，可以多看看网络编程，其中netty应该可以解决你的问题
kafka 基础知识梳理
一、kafka 简介
kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。
1.1 kafka名词解释
producer：生产者。
consumer：消费者。
topic: 消息以topic为类别记录,Kafka将消息种子(Feed)分门别类,每一类的消息称之为一个主题(Topic)。
broker：以集群的方式运行,可以由一个或多个服务组成，每个服务叫做一个broker;消费者可以订阅一个或多个主题(topic),并从Broker拉数据,从而消费这些已发布的消息。
每个消息（也叫作record记录,也被称为消息）是由一个key，一个value和时间戳构成。
1.2 kafka有四个核心API介绍
应用程序使用producer API发布消息到1个或多个topic中。
应用程序使用consumer API来订阅一个或多个topic,并处理产生的消息。
应用程序使用streams API充当一个流处理器,从1个或多个topic消费输入流,并产生一个输出流到1个或多个topic,有效地将输入流转换到输出流。
connector API允许构建或运行可重复使用的生产者或消费者,将topic链接到现有的应用程序或数据系统。
1.3 kafka基基原理
通常来讲，消息模型可以分为两种：队列和发布-订阅式。队列的处理方式是一组消费者从服务器读取消息，一条消息只有其中的一个消费者来处理。在发布-订阅模型中，消息被广播给所有的消费者，接收到消息的消费者都可以处理此消息。Kafka为这两种模型提供了单一的消费者抽象模型： 消费者组(consumer group)。消费者用一个消费者组名标记自己。
一个发布在Topic上消息被分发给此消费者组中的一个消费者。假如所有的消费者都在一个组中，那么这就变成了queue模型。假如所有的消费者都在不同的组中，那么就完全变成了发布-订阅模型。更通用的， 我们可以创建一些消费者组作为逻辑上的订阅者。每个组包含数目不等的消费者，一个组内多个消费者可以用来扩展性能和容错。
并且，kafka能够保证生产者发送到一个特定的Topic的分区上，消息将会按照它们发送的顺序依次加入，也就是说，如果一个消息M1和M2使用相同的producer发送，M1先发送，那么M1将比M2的offset低，并且优先的出现在日志中。消费者收到的消息也是此顺序。如果一个Topic配置了复制因子（replication facto）为N,那么可以允许N-1服务器宕机而不丢失任何已经提交（committed）的消息。此特性说明kafka有比传统的消息系统更强的顺序保证。但是，相同的消费者组中不能有比分区更多的消费者，否则多出的消费者一直处于空等待，不会收到消息。
1.4 kafka应用场景
构建实时的流数据管道，可靠地获取系统和应用程序之间的数据。
构建实时流的应用程序，对数据流进行转换或反应。
1.5 主题和日志 (Topic和Log)
每一个分区(partition)都是一个顺序的、不可变的消息队列,并且可以持续的添加。分区中的消息都被分了一个序列号,称之为偏移量(offset),在每个分区中此偏移量都是唯一的。Kafka集群保持所有的消息,直到它们过期,无论消息是否被消费了。实际上消费者所持有的仅有的元数据就是这个偏移量，也就是消费者在这个log中的位置。 这个偏移量由消费者控制：正常情况当消费者消费消息的时候，偏移量也线性的的增加。但是实际偏移量由消费者控制，消费者可以将偏移量重置为更老的一个偏移量，重新读取消息。 可以看到这种设计对消费者来说操作自如， 一个消费者的操作不会影响其它消费者对此log的处理。 再说说分区。Kafka中采用分区的设计有几个目的。一是可以处理更多的消息，不受单台服务器的限制。Topic拥有多个分区意味着它可以不受限的处理更多的数据。第二，分区可以作为并行处理的单元，稍后会谈到这一点。
1.6 分布式(Distribution)
Log的分区被分布到集群中的多个服务器上。每个服务器处理它分到的分区。根据配置每个分区还可以复制到其它服务器作为备份容错。 每个分区有一个leader，零或多个follower。Leader处理此分区的所有的读写请求，而follower被动的复制数据。如果leader宕机，其它的一个follower会被推举为新的leader。 一台服务器可能同时是一个分区的leader，另一个分区的follower。 这样可以平衡负载，避免所有的请求都只让一台或者某几台服务器处理。