分布式计算技术（下）：Impala、Apache Flink、星环 Slipstream

实时计算的发展历史只有十几年，它与基于数据库的计算模型有本质区别，实时计算是固定的计算任务加上流动的数据，而数据库大多是固定的数据和流动的计算任务，因此实时计算平台对数据抽象、延时性、容错性、数据语义等的要求与数据库明显不同，面向实时计算的数据架构也就发展起来。本篇我们介绍面向交互式分析的计算引擎 Impala、实时计算引擎 Apache Flink 和星环实时计算引擎 Slipstream。

— 面向交互式分析的计算引擎 Impala—

Apache Impala 是由 Cloudera 开发的 SQL on Hadoop 计算引擎，架构上仿照 Google Dremel，其最终的目标是作为 Hive 的高性能替代方案。Impala 可以分析存储在 HDFS 和 HBase 中的数据，并直接重用 Hive 的元数据服务，自研了分布式计算引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分组成）来解决 Hive 的数据计算性能慢的问题。与传统 MPP 系统不太相同的地方在于，Impala 实现了计算引擎与存储引擎的分离，数据的计算与文件存储系统并不是强耦合关系。

Impala 支持通过 ODBC/JDBC 驱动程序和 SQL 语句与 Impala 进行交互，用户可以使用类 SQL 语句进行数据查询操作。Impala 架构具有四个主要组件，分别是：Impalad（Impala 守护程序）、Impala Metastore（元数据存储服务）、Impala Statestore（状态管理服务）和 Impala Catalog。

Impalad 是在每个节点的 Impala 守护进程，用于接收并处理从客户端发送来的请求。Impalad 包括三种组件：Query Planner、Query Coordinator 和 Query Executor。接收到 SQL 查询的节点会成为 Coordinator 节点，Coordinator 节点通过 Query Planner 将查询转为执行计划并转给 Query Coordinator，由其将任务分配给其他 Impala 节点的 Query Executor 进行并行化处理。每个工作节点的 Query Executor 在处理完自己负责的查询部分后，会各自将结果上报给协调节点的 Query Coordinator，由 Coordinator 节点进行汇总并返回给用户。

Metastore 用于存储表结构、位置等以及与查询相关的元数据信息，通常采用 MySQL 和 PostgreSQL 作为数据库实例。每个 Impala 节点都会在本地缓存元数据，当访问大数据量时先在本地查找元数据信息，如果没有命中再去 Metastore 中查找，以节省开销。Statestore 负责收集每个 Impalad 的健康状况。如果节点故障，Statestore 会将故障信息通知集群所有的 Impalad，Coordinator 不会再向受影响的节点分配任何作业。Catalog 负责从 Metastore 中同步元数据，并将元数据信息通过 Statestore 分发到各个 Impalad 中，使得集群中所有 Impalad 都有元数据的缓存信息。

Impalad 一般部署在 DataNode 上，使用 HDFS 提供的 Short-Circuit Local Reads 机制，使得数据的访问过程能够直接访问 DataNode。Impala 支持 SQL、Java 等进行查询，在 Client 提交查询后，查询会分配到 Impala 集群中的某一个节点上，该节点便作为本次查询的协调节点。协调节点的 Impalad 会与集群中 NameNode 进行通信，确定本次查询数据所在的 DataNode。在对 SQL 语句进行解析后，将查询的解析树变成若干分支，发送到本节点 Query Coordinator，由 Coordinator 把查询任务分配给所有存储这个查询相关数据的 Impala 节点的 Query Executor。各 Query Executor 根据自己分配到的任务，直接访问文件系统的 DataNode 进行数据查询，在处理完成后 Query Executor 将结果上报给协调节点的 Query Coordinator 进行汇总，由协调节点把汇总后的结果返回给客户端。

Hive 计算过程中，所有数据处理的中间过程的结果都会通过磁盘保存下来，这样的设计能够实现更好的可伸缩性和容错能力。而 Impala 设计之初旨在通过内存进行并行处理和任务计算，只负责处理过程中间结果的传输，减少了把中间结果写入磁盘的步骤，由 DataNode 的 Impalad 进程直接读取 HDFS 及 HBase 数据,从而大大降低了延迟。不过这个最终带来的问题是 Impala 对一些特殊场景的容错性（如数据倾斜场景下）不如 Hive，在生产中的表现就是稳定性不足，因此其并没有像 Hive 一样取得广泛的落地。从国内项目的落地效果看，Impala 属于较为失败的项目，落地案例非常稀少，另外社区核心的开发人员也陆续转其他项目，短期上不太会有很好的起色。2017 年开始 Cloudera 推动基于其自研的分布式存储 Kudu 配合 Impala 的交互式分析方案，以解决 HDFS 不能支持快速数据写入和不能利用索引等问题，不过这个方案没有很好的深度优化，而 Kudu 的主要作者 Todd Lipcon 转投 Google 研发 Spanner 数据库，也事实上宣告了这个技术尝试以失败而终结。

— 实时计算引擎 Apache Flink —

Apache Flink 在 2014 年 8 月正式发布了第一个版本，并于 14 年底成为 Apache 顶级项目，是一个同时面向数据流处理和批量数据处理的开源框架和分布式处理引擎，具有高吞吐、低延迟、高扩展、支持容错等特性。Flink 以数据并行和流水线方式进行高吞吐量、低延迟的数据流计算程序，流水线运行时系统可以执行批处理或实时流处理。此外，Flink runtime 也支持迭代算法的执行，因此可以在流上运行机器学习算法。Flink 可以被应用与实时 ETL、流批一体数据分析以及事件驱动的应用中（如实时风控、反欺诈、异常检查、实时规则引擎等）。

Flink 是一个支持在有界和无界数据流上做有状态计算的大数据引擎。它以事件为单位，并且支持 SQL、State、WaterMark 等特性。它支持"exactly once"，即事件投递保证只有一次，不多也不少，这样数据的准确性能得到提升。比起 Storm，它的吞吐量更高，延迟更低，准确性能得到保障；比起 Spark Streaming，它以事件为单位，达到真正意义上的实时计算，且所需计算资源相对更少。Flink runtime 是 Flink 的核心计算结构，这是一个分布式系统，它接受流数据流程序，并在一台或多台机器上以容错的方式执行这些数据流程序。

• Flink 逻辑架构

Flink 的技术架构如下图所示，分为 Kernel 层、API 层、存储层与资源管理层，其主要组成部分和功能如下：

• Runtime 是 Flink 中核心计算框架，采用了标准 master-slave 的结构，master 负责管理整个集群中的资源和作业；Slave 负责提供具体的资源并实际执行作业。runtime 用于将框架中的 job 进行拆分并构建 DAG 图，通过单线程或多线程的方式对拆分后的 job 进行分布式作业，提高运行速度。

• DataSet API 和 DataStream API 表示 Flink 中的分布式数据集，分别用于 Flink 批处理和流处理。DataStream 为流处理提供了支持，包括逐条记录的转换操作和在处理事件时进行外部数据库查询等；DataSet API 支持批数据处理，将输入数据转换成 DataSet 数据集，并行分布在集群的每个节点上；然后将 DataSet 数据集进行各种转换操作(map、filter 等)，最后通过 DataSink 操作将结果数据集输出到外部系统。

• Flink ML 是 Flink 的机器学习库，提供了可扩展的 ML 算法，直观的 API 和工具，支持监督学习、无监督学习、数据预处理等，帮助用户在 flink 框架中便捷的使用机器学习模型。

• Table API 是一种类 SQL 的关系型 API，用户可以像操作表一样地操作数据，非常的直观和方便。通过类 SQL 语句，系统会自动化决定如何高效计算。Table & SQL API 实现了流处理和批处理统一的 API 层，批数据的查询会随着输入数据的结束生成有限结果集，流数据的查询会一直运行并生成结果流。Table & SQL API 支持数据批与流查询的同样语法，使用代码编写规则就能同时在批和流上跑。

• Flink CEP 是在 flink 上实现复杂事件处理(CEP)的库，允许在事件流中对事件进行检测，方便用户掌握数据中重要的事项。

• Gelly 是 Flink 的图 API 库，它包含了一组旨在简化 Flink 中图形分析应用程序开发的方法。在 Gelly 中，可以使用类似于批处理 API 提供的高级函数来转换和修改图。Gelly 提供了创建、转换和修改图的方法，以及图算法库，可以方便用户进行大型图分析。

• Fink 系统架构

在系统模块构成上，如下图所示，Flink 主要由 Client、JobManager、TaskManager 和 Dispatcher 组成，各个模块的主要功能包括：

• Client：Flink 作业在哪台机器上面提交，那么当前机器称之为 Client。由用户 Program 所构建出 DataFlow Graph 会以 Job 形式通过 Client 提交给 JobManager。

• JobManager：主节点，相当于 YARN 里面的 REsourceManager，生成环境中一般可以做 HA 高可用。JobManager 会将任务进行拆分，调度到 TaskManager 上面执行。

• TaskManager：是从节点，TaskManager 才是真正实现 task 的部分。

• Dispatcher ：提供了一个 REST 接口，用于提交 application 执行。

在提交 job 时，Flink 会启动一个 Client 进程负责对 job 进行编译，将用户编写的代码编译为 StreamGraph 图并进行检查和优化等工作，以 Job Graph 形式提交给 Dispatcher。当 job 到 Dispatcher 后，Dispatcher 会首先启动一个 Job Manager 组件，然后 Job Manager 会向 Resource Manager 申请资源，根据 job graph 来启动 job 中具体的 task。在 flink 中资源以 slot 形式存在，在 Resource Manager 选到空闲的 Slot 后，会通知 Task 节点的 Manager，由 Task Manager 进行相应的记录后向 Job Manager 进行注册。Job Manager 收到 Task Manager 注册上来的 Slot 后提交 Task ，由 Task Manager 启动一个新线程来执行该 Task，进行预先指定的计算，计算中所有的 metadata 从集群的存储中获得，并通过数据 Shuffle 模块互相交换数据。

— 星环实时计算引擎 Slipstream—

Transwarp Slipstream 是一款通用的实时计算引擎，使用事件驱动和批处理统一的模型，在保证毫秒级别延迟的同时，帮助用户更高效、准确的进行数据集成，同时提供更复杂的分析功能，以帮助企业挖掘实时数据的价值。作为商业版的企业级流处理产品，Slipstream 在安全和可用性方面也下了很大功夫，主要包括：

• Exactly Once 语义保证：通过分布式的 Checkpoint 机制，对应用操作的状态进行 Checkpoint，可以在不影响应用整体运行性能的同时，保证 Exactly Once 语义。

• 自动故障恢复：实时应用通常需要 7*24 小时不间断运行，Slipstream 提供了自动故障恢复机制，当 Worker 或者 Server 发生故障时，实现秒级别的任务自动恢复。

• 用户登陆安全认证：提供基于 LDAP 和 Kerberos 的认证方式，确保授权用户可以访问。

• 操作审计：对于登陆用户的操作都会记录日志，方便监控告警，以及事后日志审计。

• 细粒度的权限访问控制：提供对应用的查看、修改、启动、停止、删除等多种操作权限进行细粒度的控制，保证应用的安全性。

• 智能资源隔离调度：通过应用的抽象，和资源队列，可以实现不同应用之间的资源隔离和管理，通过应用优先级，可以保证在资源紧张时，保证高优先级的应用不受影响。

— 小结—

本篇我们介绍了面向交互式分析的计算引擎 Impala、实时计算引擎 Apache Flink 和星环实时计算引擎 Slipstream。那么随着任务增多，资源有限，分布式系统需要对资源和任务做有效的调度管理，因此有了分布式资源管理技术，下一篇我们将介绍集中式调度器 YARN 和容器管理技术 Kubernetes。