您的位置: 首页 > 办公那些事 >

基于Apache Samza,揭秘LinkedIn架构背后的技术

时间:2014-12-02 整理:docExcel.net

  英文原文:Operating Apache Samza at Scale

  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 的应用,为用户带来更好的用户体验。