大家应该听我在前言篇里扯皮后，迫不及待要来一看Samza到底是何物了吧？先了解一下Samza的Background是不可缺少的（至少官网上是放在第一个的），我们须要从哪些技术背景去了解呢？
什么是消息（Messaging）？
消息系统是一种实现近实时异步计算的流行方案。
消息产生时能够被放入一个消息队列（ActiveMQ，RabbitMQ）、公布-订阅系统（Kestrel，Kafka）或者日志聚合系统（Flume、Scribe）。下游消费者从上述系统读取消息而且处理它们或者基于消息的内容产生进一步的动作。
如果你有一个站点，而且每次有人要载入一个页面，你发送一个“用户看了页面”的事件给一个消息系统。你可能会有一些做以下事情的消费者：
* 为了未来做数据分析，存储消息到hadoop。
* 对页面訪问量进行计数而且更新到Dashboard
* 假设页面訪问失败触发一个报警。
* 发送一封邮件通知还有一个用户；
* 带着这个用户的相关信息增加页面展示事件，而且返回信息给消息系统；
总结一下。非常显然。一个消息系统能解耦全部这些来自实际网页服务的工作。
那什么是流式计算（处理）？
大家知道消息系统是一个相当低层次的基础设施（被歧视了--）——它存储消息等待消费者消费他们。当你開始写产生或者消费消息的代码时，你非常快会发如今处理层会有非常多恶心的问题须要你亲自处理。而Samza的目标就是帮助我们干掉这些恶心的家伙。
咱们那上面提到的（计算pv并更新到dashboard）样例来说吧。当你的正在跑的消费者机器突然挂掉了，而且你当前的计算的数值丢失了会发生什么？怎么恢复？当机器服务被重新启动时处理该从哪里開始？假设底层的消息系统反复发送了一条信息或者丢失了一条消息怎么办？或者你想依据url来分组统计pv？又或者一台机器处理的负载太大。你想分流到多台机器上进行统计在聚合？
流式计算为上述问题提供了一个非常好的解决方式，它是基于消息系统更高层次的抽象。
Samza
Samza是一个流式计算框架，它有下面特性：
* 简单的API：和绝大多数低层次消息系统API不同，相比MapReduce，Samza提供了一个很easy的“基于回调（callback-based）”的消息处理API；
*管理状态：samza管理快照和流处理器的状态恢复。当处理器重新启动，samza恢复其状态一致的快照。samza的建立是为了处理大量的状态。
* 容错性：当集群中有一台机器宕机了。基于Yarn管理的Samza会马上将你的任务导向还有一台机器。
* 持久性：Samza通过kafka保证消息按顺序写入相应分区。而且不会丢失消息；
* 扩展性：Samza在每一层都做了分区和分布。kafka提供了顺序的、分区、可复制的、容错的流。Yarn则为Samza的执行提供了一个分布式环境。
*可插拔：尽管Samza在Kafka和YARN的外部工作，可是Samza提供了能够让你在其他消息系统和执行环境里执行的可插拔的API；
*处理器隔离：执行在YARN上的Samza相同支持Hadoop安全模型以及通过linux CGroups进行资源隔离
供选方案：
眼下流行的开源流式计算方案都非常年轻。而且没有一个单一系统能提供一个全面的解决方式。
在这个领域面临的新难题包含例如以下几个：1.一个流式计算的状态应该如何管理；2.流是否应该被缓冲到远程机器的磁盘上；3.当反复的信息被接受或者信息丢失该做什么；4.如何建立底层消息传递系统；
Samza的主要差别在于下面几个方面：
* Samza支持局部状态的容错。
状态自己作为一个流被构造。
假设由于机器宕机本地状态丢失，那么状态流会回放又一次存储它。
* 流是有序、分区的、可回放的而且是容错的。
* YARN用来处理隔离、安全和容错；
* 任务之间是解耦的：假设有一个任务慢了而且造成了消息的积压，系统其他部分不会受到影响；
好的，背景就介绍到这里，下一篇咱们一起了解一些概念，方便兴许深入学习吧。大家继续加油。
大家应该听我在前言篇里扯皮后，迫不及待要来一看Samza到底是何物了吧？先了解一下Samza的Background是不可缺少的（至少官网上是放在第一个的），我们须要从哪些技术背景去了解呢？
什么是消息（Messaging）？
消息系统是一种实现近实时异步计算的流行方案。
消息产生时能够被放入一个消息队列（ActiveMQ，RabbitMQ）、公布-订阅系统（Kestrel，Kafka）或者日志聚合系统（Flume、Scribe）。下游消费者从上述系统读取消息而且处理它们或者基于消息的内容产生进一步的动作。
如果你有一个站点，而且每次有人要载入一个页面，你发送一个“用户看了页面”的事件给一个消息系统。
你可能会有一些做以下事情的消费者：
* 为了未来做数据分析，存储消息到hadoop；
* 对页面訪问量进行计数而且更新到Dashboard
* 假设页面訪问失败触发一个报警；
* 发送一封邮件通知还有一个用户；
* 带着这个用户的相关信息增加页面展示事件，而且返回信息给消息系统；
总结一下。非常显然。一个消息系统能解耦全部这些来自实际网页服务的工作。
那什么是流式计算（处理）？
大家知道消息系统是一个相当低层次的基础设施（被歧视了--）——它存储消息等待消费者消费他们。当你開始写产生或者消费消息的代码时，你非常快会发如今处理层会有非常多恶心的问题须要你亲自处理。而Samza的目标就是帮助我们干掉这些恶心的家伙！
咱们那上面提到的（计算pv并更新到dashboard）样例来说吧。当你的正在跑的消费者机器突然挂掉了。而且你当前的计算的数值丢失了会发生什么？怎么恢复？当机器服务被重新启动时处理该从哪里開始？假设底层的消息系统反复发送了一条信息或者丢失了一条消息怎么办？或者你想依据url来分组统计pv？又或者一台机器处理的负载太大，你想分流到多台机器上进行统计在聚合？
流式计算为上述问题提供了一个非常好的解决方式，它是基于消息系统更高层次的抽象。
Samza
Samza是一个流式计算框架。它有下面特性：
* 简单的API：和绝大多数低层次消息系统API不同，相比MapReduce，Samza提供了一个很easy的“基于回调（callback-based）”的消息处理API。
*管理状态：samza管理快照和流处理器的状态恢复。当处理器重新启动，samza恢复其状态一致的快照。samza的建立是为了处理大量的状态。
* 容错性：当集群中有一台机器宕机了。基于Yarn管理的Samza会马上将你的任务导向还有一台机器；
* 持久性：Samza通过kafka保证消息按顺序写入相应分区，而且不会丢失消息；
* 扩展性：Samza在每一层都做了分区和分布。kafka提供了顺序的、分区、可复制的、容错的流。Yarn则为Samza的执行提供了一个分布式环境。
*可插拔：尽管Samza在Kafka和YARN的外部工作，可是Samza提供了能够让你在其他消息系统和执行环境里执行的可插拔的API；
*处理器隔离：执行在YARN上的Samza相同支持Hadoop安全模型以及通过linux CGroups进行资源隔离
供选方案：
眼下流行的开源流式计算方案都非常年轻。而且没有一个单一系统能提供一个全面的解决方式。在这个领域面临的新难题包含例如以下几个：1.一个流式计算的状态应该如何管理；2.流是否应该被缓冲到远程机器的磁盘上；3.当反复的信息被接受或者信息丢失该做什么；4.如何建立底层消息传递系统；
Samza的主要差别在于下面几个方面：
* Samza支持局部状态的容错。状态自己作为一个流被构造。
假设由于机器宕机本地状态丢失，那么状态流会回放又一次存储它。
* 流是有序、分区的、可回放的而且是容错的；
* YARN用来处理隔离、安全和容错。
* 任务之间是解耦的：假设有一个任务慢了而且造成了消息的积压。系统其他部分不会受到影响。