开源组件系列（13）：交互式计算引擎

概述

产生背景

  在开源大数据领域，交互式引擎并不是从一开始就出现的。起初，大数据领域数据处理引擎以MapReduce为主，但MapReduce引擎采用了批处理的理念，数据处理能力低效：

• IO密集型：Map阶段中间结果写磁盘，Reduce阶段写HDFS，多个MapReduce作业之间通过共享存储系统HDFS交换数据。
• 任务调度和启动开销大，大量任务需要分布式调度到各个节点上，且每个任务需启动一个Java虚拟机运行。
• 无法充分利用内存，MapReduce是十多年前提出的分布式技术，当时内存价格昂贵，所以设计的理念是充分使用磁盘，而如今内存的价格越来越便宜，新型计算引擎可以尝试通过内存加速。
• Map端和Reduce端均需要排序：这是MapReduce设计理念决定的，使得MapReduce无法很好的应对交互式处理场景。
    为了克服MapReduce的性能缺点，Google提出了新型交互式计算引擎Dremel，它构建于Google的GFS等系统之上，支撑了Google的数据分析服务BigQuery等诸多服务。Dremel的技术两点主要有两个：一是采用了MPP架构，使用了多层查询树，使得任务可以在数千个节点上并行执行和聚合结果；二是实现了嵌套型数据的列存储，避免了读取不必要的数据，大大减少网络和磁盘IO。
    受Google Dremel的启发，Cloudera等公司开发了Impala、Facebook开发了Presto，并将之开源。

交互式查询引擎的分类

  交互式查询引擎常用语OLAP场景，根据存储数据方式的不同可以分为ROLAP、MOLAP和HOLAP：

• ROLAP：基于关系数据库OLAP实现（Relational OLAP），它以关系数据库为核心，以关系型结构进行多维数据的表示和存储。它将多维结构划分成两类表：一类是事实表，迎来存储数据和维度关键字；另一类是维度表，即对每个维度至少使用一个表来存放维度层次、成员类别等维度描述信息。ROLAP的最大好处是可以实时地从源数据中获得最新数据更新，以保持数据实时性，缺点在于运算效率比较低，用户等待时间比较长。
• MOLAP：基于多维数据组织的OLAP实现（Multidimensional OLAP），它以多维数据组织方式为核心，使用多维数组存储数据。多维数据在存储系统中形成“数据立方体（Cube）”结构，此结构是高度优化的，可以最大程度提高查询性能。MOLAP的有事在于借助数据多位预处理显著提高运算效率，主要缺陷在于占用存储空间大和数据更新有一定延迟。
• HOLAP：基于混合数据组织的OLAP实现（Hybrid OLAP），用户可以根据自己的业务需求，选择哪些模型采用ROLAP、哪些采用MOLAP。一般来说，将不常用或需要灵活定义的分析使用ROLAP，而常用、常规模型采用MOLAP实现。

常见的开源实现

  在大数据生态圈中，主流的应用于ROLAP场景的交互式计算引擎包括Impala和Presto，它们的特点如下：

• Hadoop Native：跟Hadoop生态系统有完好的结合。
• 计算与存储分析：仅仅是查询引擎，不提供数据存储服务，所有要处理的数据都存储在第三方系统中，比如Hive、HDFS和HBase等。
• MPP架构：采用经典的MPP架构，具有良好的扩展性，能够应对TB甚至PB级数据的交互式查询需求。
• 嵌套式数据存储：支持常见的列式存储格式，比如ORC和Parquet等。

ROLAP

Impala

  Impala最初由Cloudera公司开发，设计的动机是充分结合传统数据库与大数据系统Hadoop的有事，构造一个全新的、支持SQL与多租户、并具备良好的灵活性和扩展性的高性能查询引擎。传统数据库与大数据系统Hadoop各有优缺点：

• 传统关系型数据库对SQL这种最主流的数据分析语言有完好的支持，且支持多租户，能很好的应对高并发场景，但灵活性和扩展性较差。
• 大数据系统Hadoop具备很好的灵活性（支持各种数据存储格式、各种存储系统等）和扩展性（数据规模和计算规模均可以现行扩展），但对SQL及并发的支持较弱。
  Cloudera结合传统数据库与大数据系统Hadoop各自有点，利用C++构造了一个全新的高性能查询引擎Impala。在Cloudera的测试中，Impala的查询效率比Hadoop生态系统中的SQL引擎Hive有数量级的提升。从技术角度上来看，Impala之所以能有好的性能，主要有以下几方面的原因：
• Impala完全抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想，采用了全服务进程的设计架构，所有计算均在预先启动的一组服务中进行，可支持更好的并发，同时省掉不必要的shuffle、sort等开销。
• Impala采用全内存实现，不需要把中间结果写入磁盘，省掉了大量I/O的开销。
• 充分利用本地读，尽可能地将数据和计算分配在同一台机器，减少了网络开销。
• 用C++实现，做了很多针对底层硬件的优化，例如使用SSE指令。
    Impala的基本架构采用了对等式架构，所有角色之间是对等的，没有主从之分。如下图所示，由三类服务组件构成，分别为Catalogd、Statestored和Impalad，接下来依次介绍这几个组件。
  
• Catalogd：元信息管理服务。它从hive metastore中同步表信息，并将任何元信息的改变通过catalogd广播给各个Impalad服务。需要注意的是，在一个大型数据仓库中，元数据一般很大，不同数据表的访问频度不同，为此，Catalogd仅仅载入每张表的概略信息，更为详细的信息将由后台进程从第三方存储中延迟载入。
• Statestored：状态管理服务器。元数据订阅-发布服务，它是单一实例（存放单点故障问题），将集群元数据传播到所有的Impalad进程。MPP数据库设计的一大挑战是实现节点间协调和元数据同步，Impala对称的节点架构要求所有的节点必须都能够接收并执行查询，因此所有节点必须有系统目录结构的最新版本和集群成员关系的当前视图，而Statestored正是负责以上这些功能，即将所有元信息及其修改同步到各个Impalad。
• Impalad，同时承担协调者和执行者双重角色。首先，对于某一查询，作为协调者，接收客户端查询请求并对其进行词法分析、语法分析、生成逻辑查询计划以及物理查询计划，之后将各个执行片段调度到Impalad上执行；其次，接收从其他Impalad发过来的单个执行片段，利用本地资源（CPU、内存等）处理这些片段，并进一步将查询结果返回给协调者。Impalad一般部署在及群众运行Datanode进程的所有机器上，进而利用数据本地化的特点而不必通过网络传输，即可在文件系统中读取数据块。
    Impala前端负责将SQL编译为可执行的查询计划，它由SQL解析器、基于成本的优化器组成。它的查询编译阶段遵循经典的实现方式：分为查询解析、语义分析、查询计划/优化等几个模块。最大挑战来自查询计划器，它将执行计划分为两个阶段：
• 第一阶段：将解析树转换为单点计划树，这包括如下内容：HDFS/HBase扫描、hashjoin、crossjoin、union、hash聚集、sort、top-n和分析评估等。它基于分析评估结果，进行谓词下推、相关列投影、分区剪枝、设置限制并完成一些基于成本的优化比如排序、合并分析窗口函数和join重排序等。
• 第二阶段：将单个节点的计划转换为分布式的执行计划，基本目标在于最小化数据移动和最大化本地数据扫描，它通过在计划节点间增加必要的交换节点实现分布式，通过增加额外的费交换节点最小化网络间的数据移动，在此阶段，生成物理的join策略。Impala支持两种分布式join放肆，表广播（broadcast）和哈希重分布（partittioned）：表广播方式保持一个表的数据不动，将另一个表广播到所有相关节点；哈希重分布的原理是根据join字段哈希值重新分布两张表数据。
    Impala定位是为用户提供一套能与商业智能场景结合的查询引擎，它与其他查询引擎类似，支持多种商业标准：通过JDBC/ODBC访问，通过Kerberos或LADP进行认证，遵循标准SQL的角色授权等。为了更好地与Hive Metastore结合，它支持绝大部分HQL语法。Impala支持几乎所有主流的数据存储格式，包括文本格式、SequenceFile、RCFile以及Parquent等。但需要注意的是，Impala目前不支持ORCFile。

Presto

  Presto是Facebook开源的交互式计算引擎，能够处理TB级数据量。由于Presto能够与Hive无缝集成，因此已经成为了非常主流的OLAP引擎。
  Presto查询引擎是一个Master-Slave的架构，由一个Coordinator服务，一个Discovery Server服务，多个Worker服务组成，它们的职责如下：

• Coordinator：协调者，接收客户端查询请求SQL，将各个任务调度到各个Worker上执行，并在Worker返回结果之后对其进一步汇总。在一个Presto及群众，可以同时存在多个Coordinator，以防止单点故障。
• Discovery Server：服务发现组件，各个Worker启动时会向Discovery Server注册，并将状态信息定期汇报给Discovery Server，这样，Coordinator可随时从Discovery Server中获取活跃的Worker列表。Discovery Server是一个轻量级的服务，通常内嵌于Coordinator节点中。
• Worker：任务执行者，接收来自Coordinator任务，利用多线程方式并行执行，并将结果发送给Coordinator。
    Presto是一个分布式查询引擎，并不提供数据的存储服务。为此，Presto采用了插件化设计思路，支持多种数据源，包括Hive、HDFS、MySQL、HBase、Redis等。Presto架构如下：
  
    Presto是插件式架构，通过连接器接入外部数据源。为了区分各个数据源中的数据，它在数据库之上又引入了一层命名空间：catalog，前面提到的Hive、Cassandra和MySQL等在Presto中均以catalog方式存在。不同的catalog中可以有多个数据库，每个数据库中进一步可以同时存在多张数据表。

Impala与Presto的对比

MOLAP

  MOLAP是一种通过预计算cube方式加速查询的OLAP引擎，它的核心思想是“空间换时间”，典型的代表包括Druid和Kylin。

Druid

  Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式OLAP系统，旨在快速处理大规模数据，并能够实现快速查询和分析。
  Druid是基于列存储的，其设计之初主要目的是存储时间序列数据，因此数据强制按照时间分割成不同的数据段。除了时间戳以外，一个数据段中还有维度和度量两种类型的列。Driud能够快速对数据进行过滤和聚合，它常用来给一些面向分析人员的应用提供查询引擎。有些大规模的Druid集群每秒钟能够插入数十亿条事件并提供上千次的查询。

  Druid整个架构由实时线和批处理线两部分构成，本质上是对Lambda架构的一种实现。Druid系统主要有三个外部依赖：用于分布式协调的ZooKeeper；存储集群数据信息和相关规则的Metadata Storage；存放备份数据的Deep Storage。Druid节点类型比较多，可以从三个方面了解系统架构：首先从外部看，提供查询接口的节点是Broker节点，它根据具体的情况可能会将查询分发到实时节点或者历史节点，前者存放实时数据，后者存放历史数据；其次，从集群内部看，负责协调数据存储的是Coordinator节点，它读取Metadata，通过ZooKeeper通知不同的Historical节点应当载入或者丢弃哪些数据段；最后，从数据Ingest来看，可以将实时数据交给Real-time节点进行处理，也可以直接将数据建好索引放到Deep Storage中，然后更新Metadata，现在Druid提倡用Indexing Service来统一处理两种数据Ingest的情况。

Kylin

  Kylin是Hadoop生态圈下的一个MOLAP系统，是ebay大数据部门从2014年开始研发的支持TB到PB级别数据量的分布式OLAP引擎。其特点包括：

• 可扩展的超快OLAP引擎。
• 提供ANSI-SQL接口。
• 交互式查询能力。
• 引入MOLAP Cube的概念以加速数据分析过程。
• 支持JDBC/RESTful等访问方式，与BI工具可无缝整合。
    Kylin的核心思想是利用空间换时间，通过预计算，将查询结果预先存储到HBase上，以加快数据的处理效率。如下图所示：
  

Druid与Kylin的对比