Samza是由LinkedIn开源的一个分布式流处理系统。近日，LinkedIn资深SRE Jon Bringhurst发表了一篇博文，揭秘LinkedIn是如何利用Samza与Yarn、Kafka进行扩展的。

Samza是由LinkedIn开源的一个分布式流处理系统，与之配合使用的是开源分布式消息处理系统Apache Kafka。很多人会将Samza与Twitter Storm相媲美。近日，LinkedIn资深SRE（网站可靠性工程师）Jon Bringhurst发表了这篇博文，阐述LinkedIn是如何利用Samza与Yarn、Kafka进行扩展的。

Samza是什么

Apache Samza是一个开源框架，可以帮助开发者进行高速消息处理同时具有良好的容错能力。Samza可从Kafka中获取消息并进行处理，处理完毕后把结果返回Kafka（LinkedIn自家的分布式消息系统Kafka）。一个简易的Samza处理过程如下图所示：

尽管Samza的设计初衷为不同类型的流处理系统服务，在LinkedIn中我们对消息流的处理主要使用的还是Kafka。所以接下来会先讲述Kafka然后再探讨Samza。

Kafka简述

每天经由Kafka进行处理的数据量多达500TB。或许你会想象有个大规模集群来对付如此庞大的数据，实际上不是的。我们实际上使用的是集群图，每个集群图负责处理特定类型的消息。我们透过对不同集群图进行消息镜像处理从而控制集群到集群的消息流向。

针对数据中心可能出现的宕机情况，我们为集群提供了一个拓扑结构，以便数据中心出错离线后继续保持消息的正常流动。每一个数据中心里，我们都会配备一个本地的集群和一个聚合的Kafka集群。每个本地集群会穿越数据中心被镜像复制到聚合集群。所以一旦某个数据中心出现异常，我们会转移去另一个数据中心而不造成重大影响。

我们把拓扑结构中的每一个水平层叫做“tier(层)”，tier由各个不同数据中心具相同功能的集群组成。例如在上图中，有一个本地tier和一个聚合tier。

本地tier是所有数据中心中的本地集群的集合，聚合tier是所有数据中心的聚合集群的集合。

此外还有一个离线聚合tier(offline aggregate tier)。Production聚合tier会被镜像复制到离线聚合tier进行批处理作业(例如，在Hadoop上进行map-reduce作业)。我们可利用它来分离production集群并在不同数据中心里进行批处理作业。

若只配置单个本地集群或单个聚合集群，无疑会置整个集群结构于风险之中；所以我们会把本地集群分割为多个子集群，每个子集群承载不同类型的数据。例如，程序指标和事件追踪数据会被放入不同的集群，不同集群都会有自己的本地集群和聚合集群。尽管Kafka能够处理来自单个大型集群所有类型的消息，但是对此进行更细致的划分无疑会减少差错处理的复杂度。

我们还有“pipeline(管道)”的概念。一个pipeline表示的是一个消息从源地址到目的地传输的路径。不同消息会共享公共的pipeline，所以很容易去找出消息的源地址和目的地址。

Samza在其中发挥什么作用呢？我们配置了另外的Kafka 集群集合为Samza作业服务，该集合是从聚合tier镜像复制过来的。每个这样的Kafka集群会与一个能运行Apache  Yarn的集群相连以处理Samza作业。

从上图可知Kafka和Samza使用的是不同的硬件。因为在过去尝试使用同一硬件时，发现Samza作业会对Kafka的页缓存造成影响。

资源管理

每执行作业时，每个Samza作业会连接到Yarn的Application Master API。透过该API，Samza可与Yarn一起申请资源(容器)为Samza作业服务。一旦任务失败，Samza作业会与Yarn进行协商从而寻找其它的替代资源。

那么该如何在Yarn下开启一个 Samza作业呢？

首先创建一个Samza工程。LinkedIn有一个对版本进行管理的仓库工具。每当提交工程到该仓库时，LinkedIn自动化工具会使用Hudson来创建新的工程并生成一个Samza作业包。一旦作业包在作业仓库服务器工具Artifactory上就绪，其它工具会在 同一主机上进行Yarn 资源管理器安装。安装文件中的一个脚本会通知Yarn从Artifactory上下载作业包，并提取文件放入作业的工作目录中，然后启动Samza Application Master。

性能监控

我们使用inGraphs工具来进行性能监控。inGraphs与开源工具Graphite非常类似，它有个基于RRD，Whisper或InfluxDB的后端。其性能监视页面如下所示：

由于Samza作业关联的性能指标数量庞大，我们会在工具上进行指标的筛选，排除冗余的干扰信息，除非工程师有特殊要求。此外，我们还配有历史数据访问工具和指标警示工具。

多数警示信息都设有上限和下限阀值。如下图所示，如果发现每秒消息数量低于下限100，会触发相应的处理动作(自动调节或发出警示通知)。

我们针对不同的警示信息设定有相应的升级处理机制。例如针对非紧急情况会先通过邮件进行通知，针对重大问题会马上通知网络运营中心。除了Samza，我们对硬盘，CPU，内存，网络使用情况都会进行监控。

硬件配置

当我们为Kafka代理加入新硬件时，我们会采用标准的LinkedIn Kafka配置进行设置。从目前来看，内存是作业运行中较易出问题的环节。所以对于执行Samza作业的服务器节点来说，我们主要关注的是根据核心频率配备合适的RAM。下一步我们计划会对网络硬件进行升级。在存储方面，我们基本上采用的是PCI-E接口、TB级别的SSD配置。

下一步计划

尽管目前Samza运作正常，我们仍不断为规模与稳定两者之间的平衡而努力。其中一个方向是如何对作业和任务进行更好的划分。以上就是我们在LinkedIn中进行Samza部署的回顾与总结。将来我们会不断深化Samza的应用，为用户带来更好的用户体验。