BigSQL发动机的结构和工作原理

---

BigSQL简介

为了更好在Hadoop平台上使用大家熟悉的SQL处理和分析，减少开发人员使用MapReduce带来的巨大工作量，及与大量成熟的数据处理工具和应用的集成，IBM 推出的SQL on Hadoop的产品--BigSQL 。我们知道关系型数据技术源于 IBM，在过去的几十年，IBM 在关系型数据库领域累积了大量先进的技术和丰富的经验，也拥有很多优秀的基于 RDBMS 技术的产品和工具。 IBM 将在RDBMS积累先进的技术运用到了 BigSQL 当中，使得它无论从性能上、SQL 语法的支持上、与其他应用的集成上、安全性等方面都有了非常强大的功能。

BigSQL的功能特点如下：

支持广泛的、标准的SQL ，包括

– SELECT:查询功能遵循 SQL 2011 语言标准的规范，支持Join、Union、Aggregate和子查询等.

– GRANT/REVOKE,INSERT … INTO

– SQL PL:包括存储过程、SQL 体函数、用户自定义函数、及丰富的标量函数、表函数和联机分析处理 (OLAP) 函数

– JDBC 和 ODBC 驱动

基于成本的优化、优秀的数据处理性能

– 采用 MPP 引擎 (C++) 代替 Java MapReduce

– 基于成本的优化器，超过140个SQL语句重写规则

– 持续运行的守护进程，避免启动开销

– 节点间数据流动以避免持久化中间结果

– 基于内存的操作，同时具备在超过可用内存时（汇总、排序等操作）将数据溢出到磁盘。

支持各种存储格式

– 支持DFS、Hive、HBase 等数据存储

– 文本 (带分隔符)、顺序文件、RCFile、ORC、Avro、Parquet 等格式

通过 LOAD、联邦查询实现与RDBMS数据库集成

BigSQL架构

在描述BigSQL架构之前，我们先回顾一下HDFS集群架构。

一个HDFS集群是由一个Namenode和一定数目的Datanodes组成Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。HDFS架构如下图所示：

理解了HDFS的主从架构，我们很自然地想到SQL on Hadoop的架构也应该很相似，因为这样能更好的利用HDFS分布式数据存储和处理的特点。事实上，BigSQL 也是一个主从的架构，是一种Shared-Nothing架构，它包含管理节点和工作节点。管理节点（也叫Head Node或Coordinator Node）负责接收客户端发送的 SQL语句，经过编译和优化生成并行的执行计划，然后将执行计划分发给多个工作节点（即Worker Node）。工作节点并行地执行各自的子任务，对进行数据存取和计算。最后管理节点将各工作节点的结果汇总成最后的结果返回非客户端。整个架构如下图所示：

接下来我们对这个架构中的每个组件进行描述，让读者更好的理解BigSQL组件的作用。

管理节点

BigSQL的管理节点是整个架构中的“大脑”，它负责建立和监听JDBC/ODBC连接、接收SQL语句、编译和优化查询、生成并行执行计划和子任务、将子任务推送给工作节点并协调查询的执行，汇总子任务返回的结果等。同时，管理节点还可以使用传统的RDBMS表存储用户数据（数据量较小的参考数据），以便在关联查询中使用。管理节点包含三个模块，Coordinator、Catalog和Scheduler 。

Coordinator

Coordinator线程负责建立建立和监听客户端连接，接收SQL，对SQL 进行解析、编译、优化，生成一个分布式的执行计划并推送到各个工作节点。

Catalog

在DB2里，Catalog记录做表和索引的统计信息，为优化器在进行成本计算是提供参考信息。同理，BigSQL 做了类似的事情，将这些统计信息存储在自己的 Catalog 里面，以帮助优化查询。BigSQL 提供了一条 ANALYZE 命令，运行该命令既能收集统计信息并更新到 Catalog中。

我们要注意区分 BigSQL Catalog和Hive Metastore （也叫HCatalog）概念。Hive Metastore是一个存储元数据信息的地方，这些元数据包括表定义相关的数据，比如位置、列名和类型、分区信息、读写table 涉及的类名等等。只要在 Hive Metastore 中定义了数据并且可在 Hadoop 集群中访问该数据，那么 Big SQL 就可访问该数据。

Scheduler

Scheduler是帮助执行查询的服务线程，它负责查询 Hive Metastore，得到表的元数据信息，这个元数据信息其中就包含了每一块数据的存放位置，从而帮助Coordinator将子任务推送到合适的点上，尽量保证计算和数据在同一个节点上，以减少节点间的数据传输。

工作节点

工作节点（也是HDFS的Data Node）是实际执行子任务的地方。它有包含一个Worker进程（又含 Reader/Writer多线程），用于读取和处理HDFS 上的数据。这些 Reader/Writer 大部分都是由 C++写的，运行速度非常快。在工作节点上，Reader/Writer可能会用到临时表，比如在涉及到多个表的连接查询中会产生临时数据并保存到临时表。这些临时表通常情况下会被尽量地保存在内存中，以提升查询速度。如果计算时内存不够用，Worker也会将数据溢出到磁盘上。

BigSQL执行查询的过程

理解BigSQL所包含的组件之后，我们来看看BigSQL引擎是如何执行查询的。SQL查询语句的执行过程如图所示：

o 应用程序根据用户配置，通过JDBC/ODBC连接到BigSQL管理节点。

o 管理节点的Coordinator线程会访问Hive Metastore和自己的Catalog，获取数据存储的元数据和统计信息。

o Coordinator结合元数据和统计信息对SQL语句进行编译和优化，生成并行执行计划。

o 运行时引擎根据数据分布的元数据信息将并行执行计划分发到各个工作节点。

o 工作节点接收到查询计划，分派给专门的线程（Reader/Writer)，这些线程知道如何读写HDFS数据。运行时引擎将会将谓词下压，使查询和投影靠近数据进行处理，避免数据搬迁。

o 如果处理过程中产生临时数据，如排序数据，则会将临时数据Cache到临时表。

o 工作节点将处理结果返回给管理节点，管理节点的Coordinator汇总所有子任务的结果后返回给应用。

BigSQL 高可用

管理节点是BigSQL的大脑，它不但要指挥工作节点如何干活，还要存储Catalog数据、连接信息、当前查询任务等信息。因此，管理节点实现高可用是重要的，也是必要的。工作节点不需要高可用，因为数据本身是高可用的，而Worker又没有状态需要保存。然而，当工作节点发生故障（如因为磁盘故障导致数据无法访问），BigSQL的Scheduler会将故障节点加入到“黑名单”，并自动在其他工作节点重新提交查询。注意，BigSQL HA为BigSQL的元数据存储（Catalog）和Scheduler提供高可用，而Hadoop Name Node和Hive Matestore的高可用不是该方案的内容。

BigSQL HA 采用 “log-shipping” 机制保持Primary管理节点和Standby管理节点同步。这里用的两个关键技术：DB2 HADR和TSAMP。DB2 HADR技术用于将Primary节点的交易日志实时传输给Standby节点，Standby节点则持续回访所受到的日志，以保持BigSQL Catalog数据实时同步。TSAMP则对Primary和Standby节点的状态进行监控，并自动执行故障切换动作。

小结

o BigSQL架构参考了博大精深的DB2数据库引擎技术。

o 实现大量并行的SQL引擎以代替低效、复杂的MR。

o Shared-nothing架构消除扩展性和网络瓶颈问题。

o 计算推送到数据本地，而不是将数据搬到到计算节点。

o 采用C++实现，性能更优。

o 节点间（多个工作节点）和节点内（多个Reader/Writer线程）并行处理。

BigSQL的基础介绍请参考另一篇文章《BigInsights金刚钻之首：BigSQL - SQL onHadoop》。

详情请咨询！

客服热线：023-66090381