大数据计算生态之数据计算（二）

前面我们讲了数据计算的两类引擎，接下来我们再讲两类：

三、即席查询（Ad-Hoc)

1.Impala

Impala 是用于处理存储在 Hadoop 集群中的大量数据的 MPP（大规模并行处理）SQL 查询引擎。与其他 Hadoop 的 SQL 引擎相比，它提供了查询的高性能和低延迟。它提供了访问存储在 Hadoop 分布式文件系统中的数据的最快方法。与 Hive 依赖于 MapReduce 计算不同，Impala 采用的是基于内存的计算，因此可以更快地完成计算任务。

上图是 Impala 的结构图，Impala 主要包括三大核心组件：

• Impala Daemon：impalad 是 Impala 的核心进程，运行在所有的数据节点上，可以读写数据，并接收客户端的查询请求，并行执行来自集群中其他节点的查询请求，将中间结果返回给调度节点。调用节点将结果返回给客户端。用户在 impala 集群上的某个节点提交数据处理请求 则该节点称为 coordinator node（协调器节点）,其他的集群节点传输其中的处理的部分数据到该 coordinator node，coordinator node 负责构建最终的结果数据返回给用户；impala 支持在提交任务的时候(采用 JDBC ,ODBC 方式) 采用 round-robin 算法来实现负载均衡,将任务提交到不同的节点上；impalad 进程通过持续的和 statestore 通信来确认自己所在的节点是否健康 和是否可以接受新的任务请求

• Impala Statestore（主要优化点，线程数）：状态管理进程，定时检查 The Impala Daemon 的健康状况，协调各个运行 impalad 的实例之间的信息关系，Impala 正是通过这些信息去定位查询请求所要的数据，进程名叫做 statestored，在集群中只需要启动一个这样的进程，如果 Impala 节点由于物理原因、网络原因、软件原因或者其他原因而下线，Statestore 会通知其他节点，避免查询任务分发到不可用的节点上。

• Impala Catalog Service（元数据管理和元存储）：元数据管理服务，进程名叫做 catalogd，将数据表变化的信息分发给各个进程。接收来自 statestore 的所有请求，每个 Impala 节点在本地缓存所有元数据。当处理极大量的数据和/或许多分区时，获得表特定的元数据可能需要大量的时间。 因此，本地存储的元数据缓存有助于立即提供这样的信息。当表定义或表数据更新时，其他 Impala 后台进程必须通过检索最新元数据来更新其元数据缓存，然后对相关表发出新查询。

Impala 的优点是支持 JDBC/ODBC 远程访问，支持 SQL 查询，快速查询大数据，无需转换为 MR，直接读取 HDFS 数据，支持列式存储，多种存储格式可以选择，可以与 Hive 配合使用,兼容 HiveSQL，基于内存进行计算，能够对 PB 级数据进行交互式实时查询、分析；缺点是不支持用户定义函数 UDF，不支持 text 域的全文搜索，不支持 Transforms，不支持查询期的容错，对内存要求高，完全依赖于 Hive 等。

2.Presto

Presto 是一个 Facebook 开源的分布式 SQL 查询引擎，适用于交互式分析查询，数据量支持 GB 到 PB 字节。Presto 的架构由关系型数据库的架构演化而来。Presto 之所以能在各个内存计算型数据库中脱颖而出，在于以下几点：

（1） 清晰的架构，是一个能够独立运行的系统，不依赖于任何其他外部系统。例如调度，Presto 自身提供了对集群的监控，可以根据监控信息完成调度。

（2）简单的数据结构，列式存储，逻辑行，大部分数据都可以轻易的转化成 presto 所需要的这种数据结构。

（3）丰富的插件接口，完美对接外部存储系统，或者添加自定义的函数。

上图为 Presto 的架构图，Presto 采用典型的 master-slave 模型：

（1）coordinator(master)负责 meta 管理,worker 管理，query 的解析和调度；

（2）worker 则负责计算和读写；

（3）discovery server， 通常内嵌于 coordinator 节点中，也可以单独部署，用于节点心跳。在下文中，默认 discovery 和 coordinator 共享一台机器；

联邦查询：Presto 另外一个非常重要的优点是可以兼容不同的数据源，上图详细展示了 Presto 用于数据源扩展的 Connector 模块的逻辑架构。逻辑架构中展示了进行自定义数据源开发的三个主要的 API，分别是元数据提取、数据存储位置获得和读数据，只要实现了对应的接口便可以进行新的数据源的接入。通过这一特定，可以支持跨数据源的数据探查、即席查询，从而减少传统 OLAP 分析过程中的数据搬家等步骤。

3.ClickHouse

ClickHouse 是一个面向联机分析处理(OLAP)的开源的面向列式存储的 DBMS，与 Hadoop 和 Spark 相比，ClickHouse 很轻量级,由俄罗斯第一大搜索引擎 Yandex 于 2016 年 6 月发布。

ClickHouse 的特点:

（1）开源的列存储数据库管理系统，支持线性扩展，简单方便，高可靠性；

（2）容错跑分快：比 Vertica 快 5 倍，比 Hive 快 279 倍，比 MySQL 快 800 倍,其可处理的数据级别已达到 10 亿级别；

（3）功能多：支持数据统计分析各种场景，支持类 SQL 查询，异地复制部署；

ClickHouse 最近也是比较火，很多公司用它来进行即时查询任务，如字节、携程等。ClickHouse 有如下特色；

• 列式存储：牛逼的 OLAP，列式存储已经是标配，使得数据压缩也有了用武之地。直接效果就是减少数据扫描范围，让 I/O 更高效。

• MPP 架构：多主架构，角色对等，数据分片（Shard）和副本（Replica）的结合，既保证了扩展能力，也增强可数据冗余保护，坏几块硬盘，宕几台服务器都能扛得住。

• CPU 计算：支持 CPU 向量运算，将单体循环变为并行处理，充分利用硬件和算法，提升计算效率，所以彪悍的快。

• 存储引擎：我感觉是过于繁杂了。从 ClickHouse 的发展历史看，明显受到 MySQL 的影响。在数据库和表层面都需要规划存储引擎。有人说通用，意味着平庸。像 ClickHouse 这样，繁杂代表着专业和场景定制。

• MergeTree 系列表引擎，与 ZooKeeper 配合支撑 Distributed 表。另外，ClickHouse 的数据类型也是别具一格，对负责设计的架构师有很高的要求。

总之，ClickHoue 是个小巧玲珑，性能极佳的数据库管理系统。这一点与我印象中的俄式米格战斗机相去甚远。

四、图计算

图计算主要将客观世界中事物间关系完整地刻画、计算和分析的一门技术。它可以用于银行对于不良贷款的预测，也可以用于网站大数据分析推荐等功能。图算法有很多种，每一种算法都有其实际的应用场景。常见的图算法有 PageRank、最短路径、社群发现等算法。

图计算有两种模型的计算框架，分别是基于同步的 BSP 模型（Bulk Synchronous Parallel Computing Model，整体同步并行计算模型）的 GraphX 和 Giraph，这样的优势在于可以提升数据处理的吞吐量和规模，但在速度会稍逊一筹。另一种是基于 MPI 模型的异步图计算模型 GraphLab。

1. GraphX

与 GraphX 可以组合使用的有图数据库 Neo4j、Titan。Titan 是一个分布式的图形数据库，特别为存储和处理大数据图形而优化，它们都可以作为 GraphX 的持久层，存储大规模图数据。

Spark 的每一个模块，都有自己的抽象数据结构，GraphX 的核心抽象是弹性分布式属性图（resilient distribute property graph）,一种点和边都带有属性的有向多重图。它同时拥有 Table 和 Graph 两种视图，而只需一种物理存储，这两种操作符都有自己独有的操作符，从而获得灵活的操作和较高的执行效率。

在工业级的应用中，图的规模很大，为了提高处理的速度和数据量，我们希望使用分布式的方式来存储，处理图数据。图的分布式存储大致有两种方式，边分割（Edge Cut），点分割（Vertex Cut），在早期的图计算框架中，使用的是边分割的存储方式，后期考虑到真实世界中大规模图大多是边多于点的图，所以采用点分割方式来存储。点分割能减少网络传输和存储开销，底层实现是将边放到各个节点存储，而进行数据交换的时候将点在各个机器之间广播进行传输。

GraphX 的整体架构可以分为三个部分：

存储层和原语层：Graph 类是图计算的核心类，内部含有 VertexRDD、EdgeRDD 和 RDD[EdgeTriplet]引用。GraphImpl 是 Graph 类的子类，实现了图操作。

接口层：在底层 RDD 的基础之上实现 Pragel 模型，BSP 模式的计算接口。

算法层：基于 Pregel 接口实现了常用的图算法。包含：PageRank、SVDPlusPlus、TriangleCount、ConnectedComponents、StronglyConnectedConponents 等算法。

2.Giraph

Google 提出了 Pregel 来解决图算法在 MapReduce 上运行低效的问题，但没有开源。Facebook 根据 Pregel 的思路发展了开源系统 Giraph，但 Giraph 有两个问题：一是 Giraph 的社区不是很活跃；二是现实生活中的图都是符合幂律分布的图，即有一小部分点的边数非常多，这些点在 Pregel 的计算模式下很容易拖慢整个计算任务。

计算模型

Giraph 的整个计算模型，主要由输入、一系列 Superstep 迭代计算、输出构成，其中这些 Superstep 被称之为 BSP(Bulk Synchronous Parallelism) 模型。

BSP 模型

BSP 模型是一个块同步并行模型，其由许多个 Superstep 组成。对于 BSP 模型而言，其在 Superstep 内的操作是并行的，但在两个 Superstep 之间则是由一个同步操作进行隔离的。也就是说 Superstep(N + 1) 会等待 Superstep(N) 执行完成之后才会开始。

上图显示了 Superstep 的结构图，一个 Superstep 由局部计算、通讯、栅栏同步 三个部分构成。可以看到即使有部分的计算比较快，但最终还是会在栅栏同步这里停下等待其余的计算完成。在图计算中应用这种模型的好处是：可以解决图计算的同步问题，同步模型有利于推断程序语义（即利于编程），并且消除了死锁和数据竞争的问题。

最后再简单介绍一下 Giraph 的整个运行流程：

Giraph 向 Hadoop 提交 Job 之后，Zookeeper 将会选出一个 MapTask 作为 Giraph 的 Master，其余的 MapTask 则作为 Worker。然后这些 Worker 会通过 Zookeeper 命名服务找到 Master，并向 Master 进行注册。

Master 将会对输入图进行分区，并发送分区信息给 Worker，Woker 会对分区进行读取，期间可能会发生 Worker 之间的分区交换。

之后 Master 会开始协调 Worker 迭代执行 Superstep，Worker 将会在 Superstep 中完成顶点的计算过程，直到所有的顶点处于不活跃状态之后结束计算。

在计算结束之后，Giraph 将会根据用户指定的格式输出结果。

3.GraphLab

GraphLab 是最早由卡耐基梅隆大学 SELECT 实验室于 Pregel 同时期推出的图计算系统。与 Pregel 的动机或者说目标不同，GraphLab 主要面向机器学习/数据挖掘问题：针对很多这类算法需要在稀疏数据上进行迭代式计算的特点，GraphLab 把输入/输出数据以图的形式进行表示，并将算法抽象为图上的计算过程。因此，尽管都采用了以顶点为中心的图计算模型，GraphLab 在一些设计决策上与 Pregel 有较大的不同：GraphLab 中的通信发生在各个顶点不同副本间的状态同步，而非 Pregel 中的消息传递；GraphLab 主要采用异步的计算模式，通过多种级别的一致性来保证算法的收敛效率，而 Pregel 是典型的同步计算模式。

GraphLab 的执行模型：每个顶点每一轮迭代经过 gather->apple->scatter 三个阶段。

（1）gather：从邻接顶点和自身收集数据，记为 gather_data_i，各个边的数据 graphlab 会求和，记为 sum_data。

（2）Mirror 将 gather 计算的结果 sum_data 发送给 master 顶点，master 进行汇总为 total。Master 利用 total 和上一步的顶点数据，按照业务需求进行进一步的计算，然后更新 master 的顶点数据，并同步 mirror。

（3）顶点更新完成之后，更新边上的数据，并通知对其有依赖的邻结顶点更新状态。

以上的介绍的图计算引擎都是大数据计算生态中用于图处理的计算框架，随着图数据的广泛应用，还有很多其他用于图数据存储和图计算的系统，例如 JanusGraph、HugeGraph、PowerGraph 等。

总结：以上就是大数据计算生态的计算引擎部分，从批处理、流处理、即席查询以及图查询四个方面进行了介绍。当然，不同的组件在功能范围上可能也有重叠，anyway，不影响我们去理解和学习这些组件。