大家应该听我在前言篇里扯皮后，迫不及待要来一看Samza究竟是何物了吧？先了解一下Samza的Background是必不可少的（至少官网上是放在第一个的），我们需要从哪些技术背景去了解呢？
什么是消息（Messaging）？
消息系统是一种实现近实时异步计算的流行方案。消息产生时可以被放入一个消息队列（ActiveMQ，RabbitMQ）、发布-订阅系统（Kestrel，Kafka）或者日志聚合系统（Flume、Scribe）。下游消费者从上述系统读取消息并且处理它们或者基于消息的内容产生进一步的动作。
假设你有一个网站，并且每次有人要加载一个页面，你发送一个“用户看了页面”的事件给一个消息系统。你可能会有一些做下面事情的消费者：
* 为了未来做数据分析，存储消息到hadoop；
* 对页面访问量进行计数并且更新到Dashboard
* 如果页面访问失败触发一个报警；
* 发送一封邮件通知另一个用户；
* 带着这个用户的相关信息加入页面展示事件，并且返回信息给消息系统；
总结一下，很显然，一个消息系统能解耦所有这些来自实际网页服务的工作。
那什么是流式计算（处理）？
大家知道消息系统是一个相当低层次的基础设施（被鄙视了--）——它存储消息等待消费者消费他们。当你开始写产生或者消费消息的代码时，你很快会发现在处理层会有很多恶心的问题需要你亲自处理。而Samza的目标就是帮助我们干掉这些恶心的家伙！
咱们那上面提到的（计算pv并更新到dashboard）例子来说吧，当你的正在跑的消费者机器突然挂掉了，并且你当前的计算的数值丢失了会发生什么？怎么恢复？当机器服务被重启时处理该从哪里开始？如果底层的消息系统重复发送了一条信息或者丢失了一条消息怎么办？或者你想根据url来分组统计pv？又或者一台机器处理的负载太大，你想分流到多台机器上进行统计在聚合？
流式计算为上述问题提供了一个很好的解决方案，它是基于消息系统更高层次的抽象。
Samza
Samza是一个流式计算框架，它有以下特性：
* 简单的API：和绝大多数低层次消息系统API不同，相比MapReduce，Samza提供了一个非常简单的“基于回调（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提供了一个非常简单的“基于回调（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用来处理隔离、安全和容错；
* 任务之间是解耦的：如果有一个任务慢了并且造成了消息的积压，系统其它部分不会受到影响；