分布式计算技术（下）：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。