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