BigSQL發(fā)動機的結(jié)構(gòu)和工作原理

---

BigSQL簡介

為了更好在Hadoop平臺上使用大家熟悉的SQL處理和分析大數(shù)據(jù)，減少開發(fā)人員使用MapReduce帶來的巨大工作量，及與大量成熟的數(shù)據(jù)處理工具和應(yīng)用的集成，IBM 推出的SQL on Hadoop的產(chǎn)品--BigSQL 。我們知道關(guān)系型數(shù)據(jù)技術(shù)源于 IBM，在過去的幾十年，IBM 在關(guān)系型數(shù)據(jù)庫領(lǐng)域累積了大量先進的技術(shù)和豐富的經(jīng)驗，也擁有很多優(yōu)秀的基于 RDBMS 技術(shù)的產(chǎn)品和工具。 IBM 將在RDBMS積累先進的技術(shù)運用到了 BigSQL 當(dāng)中，使得它無論從性能上、SQL 語法的支持上、與其他應(yīng)用的集成上、安全性等方面都有了非常強大的功能。

BigSQL的功能特點如下：

支持廣泛的、標(biāo)準(zhǔn)的SQL ，包括

– SELECT:查詢功能遵循 SQL 2011 語言標(biāo)準(zhǔn)的規(guī)范，支持Join、Union、Aggregate和子查詢等.

– GRANT/REVOKE,INSERT … INTO

– SQL PL:包括存儲過程、SQL 體函數(shù)、用戶自定義函數(shù)、及豐富的標(biāo)量函數(shù)、表函數(shù)和聯(lián)機分析處理 (OLAP) 函數(shù)

– JDBC 和 ODBC 驅(qū)動

基于成本的優(yōu)化、優(yōu)秀的數(shù)據(jù)處理性能

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

– 基于成本的優(yōu)化器，超過140個SQL語句重寫規(guī)則

– 持續(xù)運行的守護進程，避免啟動開銷

– 節(jié)點間數(shù)據(jù)流動以避免持久化中間結(jié)果

– 基于內(nèi)存的操作，同時具備在超過可用內(nèi)存時（匯總、排序等操作）將數(shù)據(jù)溢出到磁盤。

支持各種存儲格式

– 支持DFS、Hive、HBase 等數(shù)據(jù)存儲

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

通過 LOAD、聯(lián)邦查詢實現(xiàn)與RDBMS數(shù)據(jù)庫集成

BigSQL架構(gòu)

在描述BigSQL架構(gòu)之前，我們先回顧一下HDFS集群架構(gòu)。

一個HDFS集群是由一個Namenode和一定數(shù)目的Datanodes組成Namenode是一個中心服務(wù)器，負(fù)責(zé)管理文件系統(tǒng)的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節(jié)點一個，負(fù)責(zé)管理它所在節(jié)點上的存儲。HDFS暴露了文件系統(tǒng)的名字空間，用戶能夠以文件的形式在上面存儲數(shù)據(jù)。從內(nèi)部看，一個文件其實被分成一個或多個數(shù)據(jù)塊，這些塊存儲在一組Datanode上。Namenode執(zhí)行文件系統(tǒng)的名字空間操作，比如打開、關(guān)閉、重命名文件或目錄。它也負(fù)責(zé)確定數(shù)據(jù)塊到具體Datanode節(jié)點的映射。Datanode負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請求。在Namenode的統(tǒng)一調(diào)度下進行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制。HDFS架構(gòu)如下圖所示：

理解了HDFS的主從架構(gòu)，我們很自然地想到SQL on Hadoop的架構(gòu)也應(yīng)該很相似，因為這樣能更好的利用HDFS分布式數(shù)據(jù)存儲和處理的特點。事實上，BigSQL 也是一個主從的架構(gòu)，是一種Shared-Nothing架構(gòu)，它包含管理節(jié)點和工作節(jié)點。管理節(jié)點（也叫Head Node或Coordinator Node）負(fù)責(zé)接收客戶端發(fā)送的 SQL語句，經(jīng)過編譯和優(yōu)化生成并行的執(zhí)行計劃，然后將執(zhí)行計劃分發(fā)給多個工作節(jié)點（即Worker Node）。工作節(jié)點并行地執(zhí)行各自的子任務(wù)，對進行數(shù)據(jù)存取和計算。最后管理節(jié)點將各工作節(jié)點的結(jié)果匯總成最后的結(jié)果返回非客戶端。整個架構(gòu)如下圖所示：

接下來我們對這個架構(gòu)中的每個組件進行描述，讓讀者更好的理解BigSQL組件的作用。

管理節(jié)點

BigSQL的管理節(jié)點是整個架構(gòu)中的“大腦”，它負(fù)責(zé)建立和監(jiān)聽JDBC/ODBC連接、接收SQL語句、編譯和優(yōu)化查詢、生成并行執(zhí)行計劃和子任務(wù)、將子任務(wù)推送給工作節(jié)點并協(xié)調(diào)查詢的執(zhí)行，匯總子任務(wù)返回的結(jié)果等。同時，管理節(jié)點還可以使用傳統(tǒng)的RDBMS表存儲用戶數(shù)據(jù)（數(shù)據(jù)量較小的參考數(shù)據(jù)），以便在關(guān)聯(lián)查詢中使用。管理節(jié)點包含三個模塊，Coordinator、Catalog和Scheduler 。

Coordinator

Coordinator線程負(fù)責(zé)建立建立和監(jiān)聽客戶端連接，接收SQL，對SQL 進行解析、編譯、優(yōu)化，生成一個分布式的執(zhí)行計劃并推送到各個工作節(jié)點。

Catalog

在DB2里，Catalog記錄做表和索引的統(tǒng)計信息，為優(yōu)化器在進行成本計算是提供參考信息。同理，BigSQL 做了類似的事情，將這些統(tǒng)計信息存儲在自己的 Catalog 里面，以幫助優(yōu)化查詢。BigSQL 提供了一條 ANALYZE 命令，運行該命令既能收集統(tǒng)計信息并更新到 Catalog中。

我們要注意區(qū)分 BigSQL Catalog和Hive Metastore （也叫HCatalog）概念。Hive Metastore是一個存儲元數(shù)據(jù)信息的地方，這些元數(shù)據(jù)包括表定義相關(guān)的數(shù)據(jù)，比如位置、列名和類型、分區(qū)信息、讀寫table 涉及的類名等等。只要在 Hive Metastore 中定義了數(shù)據(jù)并且可在 Hadoop 集群中訪問該數(shù)據(jù)，那么 Big SQL 就可訪問該數(shù)據(jù)。

Scheduler

Scheduler是幫助執(zhí)行查詢的服務(wù)線程，它負(fù)責(zé)查詢 Hive Metastore，得到表的元數(shù)據(jù)信息，這個元數(shù)據(jù)信息其中就包含了每一塊數(shù)據(jù)的存放位置，從而幫助Coordinator將子任務(wù)推送到合適的點上，盡量保證計算和數(shù)據(jù)在同一個節(jié)點上，以減少節(jié)點間的數(shù)據(jù)傳輸。

工作節(jié)點

工作節(jié)點（也是HDFS的Data Node）是實際執(zhí)行子任務(wù)的地方。它有包含一個Worker進程（又含 Reader/Writer多線程），用于讀取和處理HDFS 上的數(shù)據(jù)。這些 Reader/Writer 大部分都是由 C++寫的，運行速度非?？臁Ｔ诠ぷ鞴?jié)點上，Reader/Writer可能會用到臨時表，比如在涉及到多個表的連接查詢中會產(chǎn)生臨時數(shù)據(jù)并保存到臨時表。這些臨時表通常情況下會被盡量地保存在內(nèi)存中，以提升查詢速度。如果計算時內(nèi)存不夠用，Worker也會將數(shù)據(jù)溢出到磁盤上。

BigSQL執(zhí)行查詢的過程

理解BigSQL所包含的組件之后，我們來看看BigSQL引擎是如何執(zhí)行查詢的。SQL查詢語句的執(zhí)行過程如圖所示：

o 應(yīng)用程序根據(jù)用戶配置，通過JDBC/ODBC連接到BigSQL管理節(jié)點。

o 管理節(jié)點的Coordinator線程會訪問Hive Metastore和自己的Catalog，獲取數(shù)據(jù)存儲的元數(shù)據(jù)和統(tǒng)計信息。

o Coordinator結(jié)合元數(shù)據(jù)和統(tǒng)計信息對SQL語句進行編譯和優(yōu)化，生成并行執(zhí)行計劃。

o 運行時引擎根據(jù)數(shù)據(jù)分布的元數(shù)據(jù)信息將并行執(zhí)行計劃分發(fā)到各個工作節(jié)點。

o 工作節(jié)點接收到查詢計劃，分派給專門的線程（Reader/Writer)，這些線程知道如何讀寫HDFS數(shù)據(jù)。運行時引擎將會將謂詞下壓，使查詢和投影靠近數(shù)據(jù)進行處理，避免數(shù)據(jù)搬遷。

o 如果處理過程中產(chǎn)生臨時數(shù)據(jù)，如排序數(shù)據(jù)，則會將臨時數(shù)據(jù)Cache到臨時表。

o 工作節(jié)點將處理結(jié)果返回給管理節(jié)點，管理節(jié)點的Coordinator匯總所有子任務(wù)的結(jié)果后返回給應(yīng)用。

BigSQL 高可用

管理節(jié)點是BigSQL的大腦，它不但要指揮工作節(jié)點如何干活，還要存儲Catalog數(shù)據(jù)、連接信息、當(dāng)前查詢?nèi)蝿?wù)等信息。因此，管理節(jié)點實現(xiàn)高可用是重要的，也是必要的。工作節(jié)點不需要高可用，因為數(shù)據(jù)本身是高可用的，而Worker又沒有狀態(tài)需要保存。然而，當(dāng)工作節(jié)點發(fā)生故障（如因為磁盤故障導(dǎo)致數(shù)據(jù)無法訪問），BigSQL的Scheduler會將故障節(jié)點加入到“黑名單”，并自動在其他工作節(jié)點重新提交查詢。注意，BigSQL HA為BigSQL的元數(shù)據(jù)存儲（Catalog）和Scheduler提供高可用，而Hadoop Name Node和Hive Matestore的高可用不是該方案的內(nèi)容。

BigSQL HA 采用 “log-shipping” 機制保持Primary管理節(jié)點和Standby管理節(jié)點同步。這里用的兩個關(guān)鍵技術(shù)：DB2 HADR和TSAMP。DB2 HADR技術(shù)用于將Primary節(jié)點的交易日志實時傳輸給Standby節(jié)點，Standby節(jié)點則持續(xù)回訪所受到的日志，以保持BigSQL Catalog數(shù)據(jù)實時同步。TSAMP則對Primary和Standby節(jié)點的狀態(tài)進行監(jiān)控，并自動執(zhí)行故障切換動作。

小結(jié)

o BigSQL架構(gòu)參考了博大精深的DB2數(shù)據(jù)庫引擎技術(shù)。

o 實現(xiàn)大量并行的SQL引擎以代替低效、復(fù)雜的MR。

o Shared-nothing架構(gòu)消除擴展性和網(wǎng)絡(luò)瓶頸問題。

o 計算推送到數(shù)據(jù)本地，而不是將數(shù)據(jù)搬到到計算節(jié)點。

o 采用C++實現(xiàn)，性能更優(yōu)。

o 節(jié)點間（多個工作節(jié)點）和節(jié)點內(nèi)（多個Reader/Writer線程）并行處理。

BigSQL的基礎(chǔ)介紹請參考另一篇文章《BigInsights金剛鉆之首：BigSQL - SQL onHadoop》。

更多大數(shù)據(jù)與分析相關(guān)行業(yè)資訊、解決方案、案例、教程等請點擊查看>>>

詳情請咨詢在線客服！

客服熱線：023-66090381