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

 

 

导读：大数据计算发展至今，已经形成了一个百花齐放的大数据生态，通用计算、定制开发，批量处理、实时计算，关系查询、图遍历以及机器学习等等，我们都可以找到各种对应的计算引擎来协助我们处理这些任务。本系列文章拟以大数据平台从低到高的层次为主线，梳理整个大数据计算生态组件及其功能。

在[大数据计算生态之数据计算（一）]中介绍了批处理和流处理中的各个存储组件的分类及功能。本文将详细介绍计算层的另外两种场景的计算引擎--即席查询和图查询。

本文经授权转自公众号DLab数据实验室

作者 | 小舰

出品 | DLab数据实验室（ID：rucdlab）

 

 

 

 

 

即席（Ad-Hoc）查询指的是介于实时和批处理之间的一种查询处理，如一些交互式的数据探查任务，需要秒级或分钟级的较快的响应时间。图查询是基于图模型进行的数据查询，图查询涉及到更多的是迭代类的操作，常见的图算法如路径搜索算法、中心性算法以及社群发现算法等，这些算法在公安系统和银行金融领域中的打击犯罪团伙、金融欺诈、信用卡盗刷等领域有着重要的应用。

 

 

一

即席查询（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，不影响我们去理解和学习这些组件。

 

DLab数据实验室 发起了一个读者讨论讨论角

 

 

●大数据计算生态之数据计算（一）

●大数据计算生态之数据存储

●Spark训练营（一）-- 开发环境搭建及wordCount实战

●Spark训练营（二）-- SparkStreaming流计算组件wordCount实战

●Spark训练营（三）-- GraphX图计算组件最短路算法实战

●一文纵览大数据计算生态

●原创|带你厘清分布式、数据库的那些一致性

●深入浅出大数据组件之Kafka消息队列

●一个故事让你理解什么是区块链

●实时数据流计算引擎Flink和Spark剖析

●自定义Hadoop的输入格式