Facebook 在许多利用场景采取了分布式流处理，包括推举系统、网站内容交互剖析等，这些运用的大规模实时运行须要达成严格的 SLO。为此，Facebook 构建了新的流处理做事管理平台 Turbine，并在生产系统中上线运行近三年，支配在由数万台机器构成的集群中，管理着数千条流水线，每秒实时处理数以 TB 的数据。在 Facebook 的生产履历证明，Turbine 很好地平衡了群集间的事情负载颠簸，可预测操持之外的负载峰值，持续高效地完成大规模处理。
近十年来，大规模分布式流处理得到广泛运用，并形成了多个成熟的生产系统，各自专注于不同领域的寻衅，例如故障容忍（Apache Storm）、低延迟（Apache Flink、Storm），可操作性（Twitter Heron）、直不雅观编程模型（Millwheel）、语义处理（Dataflow、Samza、Flink）、弹性伸缩（Millwheel），有效资源管理（Twitter Heron）和状态管理（Spark Streaming）等。
Facebook 也面临着同样的需求。该公司的许多运用采取分布式流处理，包括网站内容的低延迟剖析互动、搜索效果剖析和推举系统等运用处景。为了知足这些需求，Facebook 为开拓职员构建了利用类 SQL 声明式流处理开拓措辞和 C++/Python/PHP 命令式开拓 API 的框架，并利用该框架构建了大量无状态和有状态的流处理运用。这些运用须要一个可扩展的流处理做事管理平台实现方案、配置和支配，并确保运用的停机韶光和处理延迟等指标，即便在停机和负载颠簸的情形下也能知足严格的 SLO。FB 的很多流处理运用程序哀求 90 秒的端到端延迟阈值。
现有的通用集群管理系统，例如 Aurora、Mesos、Borg、Tupperware 和 Kubernetes 等，虽然可以在一定程度上知足跨多种负载的通用管理哀求，但并不适用于 Facebook 的流处理需求。个中，Borg 是由多个异构系统组成的生态，用户必须理解多种各不相同的配置措辞和流程，才能配置系统并与其交互。Kubernetes 基于 Borg 的履历，改进了分布式做事支配和管理体验。YARN 资源管理器得到了 Flink、Samza、Spark Streaming 和 StreamScope 等流处理系统的采取。这些管理系统虽然大都实现了有效的资源隔离和实行框架，但是须要提前确定所需的处理资源才能高效运作，这在流处理场景中是很难做到的。此外，这些系统并不能很好地支持资源的自动缩放。
本文阐述了 Turbine 的架构设计考量及实现，内容来自论文“ Turbine: Facebook’s Service Management Platform for Stream Processing ”。该论文已被 2020 ICDE 会议工业系列（Industry Track）任命，第一作者 Yuan Mei 本科毕业于北京大学，在 MIT 得到博士，现任 Flink 架构师。
概述Turbine 是 Facebook 的可扩展流处理做事做事管理平台，办理了现有通用集群管理框架难以适应 Facebook 流处理需求的问题。Turbine 已上线 Facebook 生产环境近三年，很好地支持了 Facebook 的浩瀚流处理运用。
Turbine 的创新之处在于实现了快速且可扩展的任务操持调度，支持自动缩放的资源有效预测机制，并供应知足容错、原子、同等、隔离和持久性（ACIDF，atomic，consistent，isolated，durable and fault-tolerant）的更新机制。详细而言：
调度机制利用两级调度机制，实现流处理任务的配置和管理。调度器首先利用 Facebook 的通用分片管理器将分片置于指定容器中，然后利用哈希机制将流处理任务分配给分片。每个分片会定期进行负载平衡，并且 Turbine 供应了负载平衡时重新操持流处理任务的安全调度机制。为确保故障不会导致数据破坏、丢失或重复处理，Turbine 实现了容错机制。自动缩放机制可自动调度 CPU，内存，磁盘等维度上的资源分配。为达成设定的 SLO 目标，自动缩放机制估算指定流处理作业所需的资源，然后按比例放大或缩小流处理任务的数量，以及每个任务所分配的资源。自动缩放机制还可根据这些资源缩放决策和历史事情负载，对原始资源估算情形迭代地做出调度。供应知足 ACIDF 的运用更新机制。对付流处理做事管理，更新机制非常主要，由于做事供应者、资源自动缩放和人工操作等处理参与者可能会同时更新同一流处理作业。系统必须确保所有更新相互隔离，并知足同等性。为此，Turbine 设计了分层作业配置架构，基于作业优先级对多个参与者的更新操作进行合并。Turbine 通过操持更新与实际更新的分离，供应了支持 ACDIF 的更新机制。更新机制利用状态同步做事，实现预期和运行作业配置间的同步，并支持更新失落败时做回滚和重试。Turbine 采取松耦合的微做事设计，实现作业管理、任务管理和资源管理，架构了一种高度可扩展且具有弹性的管理平台，知足运用的 SLO 需求，支持在无人工监督情形下的海量数据流处理。
Turbine 整体架构Turbine 的架构如图 1 所示。运用开拓职员利用 API 以声明式和命令式编程办法构建数据处理流水线运用，支持下至基本的过滤和投影操作、上至具有多个连接和聚合运算的繁芜图关联查询。查询在通过模式检讨等合规性检讨后，被编译为 Turbine 的内部表示形式，优化后发送给 Turbine 处理引擎。引擎卖力天生运行时配置文件，支持以批处理和流处理两种模式实行运用。批处理模式紧张适用于从数据仓库处理历史数据的运用处景，本文紧张先容流处理模式。
图 1 Turbine 整体架构图
Turbine 流处理系统包括作业管理、任务管理和资源管理三大紧张组件。处理流水线由多个作业组成，每个作业具有多个可并行实行的任务，每个任务独立处理部分流数据。作业管理存储作业的配置，并掩护作业的更新。任务管理将作业配置分解为独立任务，在集群上调度任务实行并掩护负载均衡。资源管理实时分配集群、作业和任务资源。Turbine 在设计上很好地解耦了各组件间的决策关联，任何组件产生的失落败均可通过处理降级模式得到办理，不会影响整体操作的连续实行。
在数据模型设计上，Turbine 作业间的通信采取 Facebook 自研的持久化总线 Scribe 实现。每个任务从 Scribe 读取一到多个数据独立分区，掩护自身的处理状态和检讨点，在处理失落败时从 Scribe 分区读取数据和检讨点信息以规复任务。这种数据模型设计简化了任务依赖，使得系统在任务调度、负载均衡和资源扩展中无需考虑任务间的依赖关系。
作业管理流处理中，每个运用都被编译并优化分解为一组独立实行的作业。作业实行所需的所有配置和信息由作业配置掩护。作业在实行期间，作业配置会由于用户操作以及内部其它做事的需求而发生变更。因此，作业管理的一个主要寻衅，便是如何确保配置变更符合 ACIDF 哀求。符合 ACIDF 对付作业变更而言非常主要，由于在运行环境中可同时存在上万个作业，变更可能会导致作业实行失落败，乃至是相互冲突。作业管理必须实现作业的自动变更、扩展和溯源。
基于此需求，Turbine 作业管理在设计上包括：实现配置管理的作业存储（Job store）、自动提交配置变动的作业做事（Job servie），以及实行作业配置变动的状态同步（state syncer）。
作业资源配置：出于对作业配置独立性和同等性的考虑，Turbine 采取了一种层次化的作业配置构造。配置管理利用 Thrift 实现编译时类型检讨，并由 Thrift JSON 序列化协议将配置转换为 JSON 表示。这样的层次化配置构造设计，支持整合来自不同做事的任意数量的配置需求，并通过 JSON 文件的归并实现统一逻辑的层次化叠加。
详细而言，Turbine 对需实行的作业定义了一个期望配置，基于此在作业实行时天生一个运行配置。在期望配置中，包括了定义作业基本资源的根本配置、定义更新资源的预定配置、定义自动扩展资源的扩增配置，以及定义用户手工操作作业所需资源的待定配置。层次化资源定义实现了上述四类配置的相互隔离，为作业实行供应同等的状态视图。
作业状态同步：为实现作业更新的原子性、持久性和容错性，Turbine 实现了期望配置和运行配置的独立存储，并通过状态同步实现二者间的同步。每一轮作业实行时，状态同步按配置优先级依次归并各个层级的期望配置，并将天生配置与运行配置比较。一旦存在差异就天生新的实行操持，并提交实行。在同时运行上万个任务的大规模集群中，任务出于负载均衡的考虑会在主机间迁移，上述同步操作机制可确保作业的原子性、容错性和持久性。
为提高同步操作的性能，状态同步会对基本的同步操作实行批处理，并对繁芜的同步操作做并行化处理。
任务管理任务管理紧张负任务务调度、负载均衡和故障处理。Turbine 通过集成 Facebook 自研的容器管理器 Tuppperware ，实现 Linux 容器的分配和编排。每个容器运行一个自身的任务管理器，卖力在当前容器中运行的流处理任务。
图 2 两层分布式任务调度和负载均衡
任务调度：Turbine 利用 Facebook 的分片管理器（类似于 Google Slicer ），实现对容器的均衡资源分片。Turbine 设计了两层资源调度机制，如图 2 所示。资源调度将打算资源物理分配给各个容器。图中的四个分片将被指派给三个容器，每个任务管理器从任务做事（Task Service）获取任务描述的完全快照，并调度分片所指派的任务。在任务调度实现中，需考虑任务与分片的映射关系掩护，以及分片的混洗和重新分配机制。
负载均衡：在任务调度完成初始的“分片 - 容器”指派后，任务管理器依据该指派启动任务。在任务运行期间，Turbine 周期性轮询分片负载情形，并根据情形由分片管理器做混洗和重新分配。详细而言，每个容器指定了内存、CPU 等资源数量，每个分片指定了可承担的负载量。分配算法根据二者匹配情形及总体资源利用情形，采取装箱类算法打算得到指派。这里的一个主要问题，是如何定义分片负载。Turbine 通过采集多种度量，综合定义多个层级的资源保障，以改进集群的整体资源利用效率。例如，对付 C/C++ 任务，系统采集固定时间窗内的均匀内存利用情形；而对付利用 cgroup 管理的 JVM 任务，则采集 xmx、cgroup 限额等峰值资源需求。度量采集利用一个后台的负载聚合线程，实现对当前资源利用情形的实时估算。
故障处理：故障处理的紧张目的是降落系统运行故障对任务运行的影响，确保任务失落败不会对数据本身产生毁坏。为此，Turbine 在分片管理器中引入了一种基于心跳的双向故障转移协议。一旦分片管理器在设定时间（默认为 60 秒）内没有吸收到来自任务管理器的心跳，就认为相应的容器已经停滞事情，进而为该容器中的分片重新进行指派，并启动上面先容的分片迁移机制。须要把稳的是，网络连接故障等情形也会导致心跳停滞。这时如果直接迁移分片，会导致重复的分片指派，进而导致重复的数据处理。针对此类问题，Turbine 进一步设计了一种主动超机遇制。一旦连接超过了设定的超时时间（常日小于心跳韶光，默认为 40 秒），那么 Turbine 容器就会重启，并在重启后重新连接分片管理器，规复故障转移前的分片状态。
综上，下列设计确保了 Turbine 实现任务高性能调度和任务的高可用性：
如图 2 所示的两层资源调度架构，实现了任务调度和资源调度的分离。任务管理器完备掌控任务列表，这样即便在任务做事和作业管理失落效的情形下，Turbine 依然可实行负载均衡和故障迁移。定期更新的任务管理，确保任务更新情形能及时反响给任务管理。在 Facebook 大规模集群的实际运行中，状态同步延迟均匀坚持在 1 至 2 分钟以内。一旦系统涌现故障，可在 60 秒内完成故障迁移。任务的均匀宕机韶光掌握在 2 分钟以内。弹性资源管理资源管理根据任务、作业和集群的负载情形，对资源利用做出动态调度。资源管理一方面可确保所有作业具有足够的资源以按时完成输入处理，另一方面确保有效利用全体集群中的资源。Turbine 资源管理在借鉴现有系统一些好的做法的同时，充分考虑了如何降落系统中无必要的资源花费，例如避免重启不须要重启的任务。
最初，资源管理器采取相应式机制，即通过监测任务滞后和积压、输入不平衡、任务运行内存不敷（OOM）等预设问题，并采纳相应资源管理操作。这种机制虽然在流处理系统中普遍利用，但在 Fcebook 生产环境中涌现了一些问题。首先，由于对作业所需资源缺少准确预估，一些时候会导致某一作业等待特定资源而耗时过长。其次，由于缺少对资源需求下限的剖断，因此无法担保作业每次都能康健运行，进而导致作业积压问题。第三，缺少对导致问题最根本缘故原由的洞察，会导致问题的进一步扩大。
基于 Facebook 的运行实践，大多数固界说务所需的资源数量常日是可预测的。只要运用的逻辑和配置不变，那么任务的资源占用情形也是具有固定模式的。基于这一不雅观察，Turbine 设计了一种主动预测机制。采取此机制的资源管理架构如图 3 所示。架构设计上由资源预估（Resource Estimator）、实行操持天生（Plan Generator）和模式剖析（Pattern Analyzer）组成。
图 3 Turbine 资源管理器架构
资源预估：对给定作业的资源利用情形作出预估。作业可根据处理状态看分为两类，即过滤、投影、转换等无状态作业，以及连接和聚合等有状态作业。无状态作业一样平常是 CPU 密集型操作，例如输入反序列化、数据处理和输出序列化等，CPU 的花费情形常日与数据输入输出的规模成正比。由此，可以通过对输入输出的度量，剖断单个线程的最大稳定处理率，进而预估 CPU 资源。有状态作业在 CPU 资源之外，还须要预估内存和磁盘的利用情形。个中，聚合运算的内存需求与输入数据的规模成正比，而连接运算的内存和磁盘需求与输入项的笛卡尔积规模以及结果的选择率干系。
模式剖析：任务在动态增加、移除或重启时，其初始化常日须要耗费大量 CPU 和 I/O 资源。资源管理器必需考虑此成分，以免初始化操作造玉成部集群运行不稳定。为此，Turbine 引入了模式剖析，根据现有的数据情形推测资源的占用模式，防止涌现可能导致集群不稳定的潜在隐患。模式剖析须要记录并剖析资源调度情形和历史事情负载模式，确保在资源扩展中不会发生频繁变动资源分配的情形。
容量管理：考虑到 Facebook 数据中央分布在环球范围，容量管理可临时授权不同的数据中央集群间进行资源交流，以达到环球范围内资源的有效利用。容量管理监测集群中作业的资源利用情形，确保在集群范围内各种型的资源得到合理分配。
生产环境实测本文以 Scuba Tailer 流处理运用为用例，展示 Turbine 生产系统的运行情形。 Facebook Scuba 供应时序数据的实时即席查询，紧张适用于实时性能问题诊断、处理构造改进影响剖析等场景。Scuba Tailer 流处理运用从 Scribe 读取输入数据、处理并将结果返回 Scuba 后端。该运用运行在一个专用的处理集群上。集群中包括位于三个备份区域的两千多台做事器，每台做事用具有 256GB 内存，48 至 56 个 CPU 内核。每个任务的 CPU 占用与数据量近乎成正比，内存占用与均匀大小近乎成正比。图 4 显示了近 12 万个任务的负载特性。可见约 80% 的任务占用不到一个 CPU 线程，而每个任务需占用近 400MB 存储资源，而 99% 的任务存储资源占用低于 2GB。
图 4 Scuba Trailer 任务的 CPU 和内存利用统计情形
负载均衡
如前所述，Turbine 监测所有运行中任务的资源占用情形，并将任务调度到所有可用的机器上。图 5（a）和（b）显示了 Tailer 集群一周韶光期内的 CPU 和内存利用情形。图 5（c）显示 Turbine 很好地在机器间分发任务，每个机器的任务数变革范围掌握在 150～230 小范围内。在 Turbine 上线前，每个 Scuba Tailer 利用独立的容器运行。Turbine 更好地利用了各容器中的碎片化资源，实现了整体资源占用降落约 33%。
图 5 在 600 多台机器的 Tailer 集群中，各机器的 CPU 和内存利用近乎均匀。每台机器坚持数百量级的任务运行，其预留资源足以应对输入数据流的突发尖峰。
负载变更相应
Turbine 自动实行资源扩展，确保所有作业具有足够资源，并且全体集群的资源得到有效利用。
图 6 显示了一个任务层面的变更用例。个中，Scuba Tailer 任务由于运用问题禁用了五天，导致数据积压。在运用重新上线后，须要尽快重新处理积压数据。图中紫色曲线显示资源管理将任务扩增到任务上限 32 个，并在手工移除上限后扩增到 128 个。与之相比拟，没有利用 Turbine 的 cluster2 集群在两天后才处理完所有积压任务。
图 6 Turbine 资源自动扩展有助于积压任务的快速规复
图 7 显示了一个集群层面的变更用例。Facebook 会定期演习训练灾害规复，将某个数据中央完备断开连接，该数据中央的所有流量会重定向到另一个数据中央。Turbine 在个中起到主要浸染，卖力扩展康健可用数据中央的作业资源。图 7 显示了集群任务总数在演习训练中的变革情形，数据中央断开拓生在第二天的清晨，图中紫色曲线全体集群流量比较正常情形峰值增加了约 16%，而总任务数增加了约 8%。这是由于 Turbine 优先考虑做垂直扩展，而非水平扩展。在演习训练期间及前后，约 99.9% 的作业能保持 SLO。
图 7 Turbine 在灾害规复演习训练期间的水平扩展情形
总结
近十年间，大规模分布式流处理在多个关键行业得到广泛运用。为办理迅速增长的流处理需求所提出的寻衅，须要实现高度可扩展且高度弹性的流处理架构。这也同样是 Facebook 在生产中面对的问题。Facebook 的许多用例采取分布式流处理来获取所需数据，包括推举系统、网站内容交互剖析等，这些运用的大规模实时运行须要达成严格的 SLO。
Turbine 已在生产系统中上线运行近三年，支配在由数万台机器构成的集群中，管理着数千条流水线，每秒实时处理数百 GB 的数据。在 Facebook 的生产履历证明，Turbine 很好地平衡了群集间的事情负载颠簸，可预测操持之外的负载峰值，持续高效地完成大规模处理。
