Apache Trafodion技術架構介紹

Trafodion簡介

Trafodion是一個構建在Hadoop/HBase基礎之上的關係型數據庫，它徹底開源免費。Trafodion可以完整地支持ANSI SQL，而且提供ACID事務保證。和傳統關係數據庫不一樣的地方在於，Trafodion利用底層Hadoop的橫向擴展能力，能夠提供極高的擴展性。而傳統數據庫，好比MySQL，在數據量達到P級別的時候就很難處理。而Trafodion卻能夠藉助HBase的擴展性，僅經過增長普通Linux服務器就能夠增長計算和存儲能力，進而支持大數據應用。

好比原來使用MySQL的用戶，若是數據量持續增長，每每須要採用先後端cache，分庫分表，讀寫分離等技術。可是這些技術帶來的弊端也不少。好比分庫分表的構架下，不一樣分庫之間沒法執行join操做。採用這些複雜技術後，系統結構複雜，維護和開發成本提升。這是不少客戶正在面臨的問題。

而從使用開發的角度來看，Trafodion和MySQL是徹底同樣的，他們一樣是關係型數據庫，基本的功能徹底一致。所以一個經典的LAMP網絡應用也能夠輕鬆地用LATP(Linux, Apache, Trafodion, PHP) 搭建。而採用Trafodion，當業務擴展時，經過增長節點就能夠應付不斷增長的數據量，應用程序無需作任何修改，也無需考慮複雜的分庫分表，讀寫分離等技術。這樣就極大地下降了系統的複雜度。

這只是Trafodion的可能應用之一，Trafodion仍是一個很是適合的實時大數據分析平臺。由於它不只能夠支持實時分析，並且可以支持實時數據寫入，好比每秒上萬條的隨機數據插入。這是構建實時分析所必備的能力。Stinger或者Impala雖然能夠提供實時查詢，但去沒法支持實時的數據插入。

好比交通實時分析，利用Stinger/Impala等技術，雖然查詢和分析能夠在1分鐘內完成，可是數據卻只能按期載入，若是1小時一次，那麼分析的數據樣本是1小時前的數據，其分析結果也失去了時效性。好比，用戶已經在那裏堵車堵了了1個小時。

關於Trafodion的使用場景讀者能夠參閱其餘介紹Trafodion的系列文章。本文簡要介紹Trafodion的技術體系結構，幫助讀者基本瞭解Trafodion內部運做的原理。

讀者還能夠參考https://wiki.trafodion.org/wi...。

整體結構

Trafodion的體系結構能夠看做三層：ODBC接入層；SQL編譯執行層；數據訪問和存儲層。其整體結構以下所示：

客戶端應用經過JDBC/ODBC訪問Trafodion。客戶鏈接由Trafodion的接入層負責。接入層爲每個客戶端鏈接分配一個master執行器，master負責用戶鏈接全部query請求的執行和結果返回。對於簡單的Query，Master進程自己就充當SQL執行層；複雜的query，訪問大量數據和進行復雜運算的狀況下，Master會啓動一系列的ESP（Executor Server Processes）進程進行大規模併發執行。ESP進程是能夠常駐內存的，以免啓動開銷，但若是長期處於空閒狀態ESP進程會退出，釋放資源。每一個ESP將執行結果返回給Master，由Master彙總並將最終結果返回給客戶端。當Master或者ESP須要訪問數據層的時候，會經過DTM來進行事務管理，在DTM(分佈式事務管理器)的控制下調用HBase的客戶端API進行數據的讀寫。下面分別介紹每一層的更多細節。

Trafodion的接入層

接入層的主要組件有兩個：DCSMaster和MXOSRVR 。DCS Master進程運行在Trafodion集羣的單個節點上，負責監聽客戶端的鏈接請求。當收到請求後，DCSMaster根據集羣的工做負載平衡狀況，選定集羣中一個節點上的MXOSRVR 做爲客戶端的執行代理。DCS Master將選定的MXOSRVR信息返回客戶端，收到信息後，客戶端直接和MXOSRVR 進行鏈接，此後客戶端的全部請求都由該MXOSRVR 負責處理。相似Oracle的Dedicated 模式。

當多個客戶端請求鏈接時，DCSMaster會平均地將客戶端鏈接到不一樣的MXOSRVR ，從而均衡地利用集羣中的每一個計算節點。並且每一個客戶端都有一個單獨的MXOSRVR 負責其後續計算請求的執行，以保證快速的響應客戶query。一些數據庫系統只有單一的ODBC接入點，高併發的狀況下，就會出現排隊現象，而採用了以上的模型後，每一個客戶端都由一個接入點惟一負責，並且這些接入點平均分配在集羣的各個節點，能夠充分發揮每臺計算節點的能力。

爲了下降延遲，Trafodion啓動的時候會預先在每一個節點啓動必定數量的MXOSRVR 進程。這樣客戶端鏈接請求被處理時，就不須要啓動新MXOSRVR 進程的開銷。可是Trafodion也不會預先啓動很是多的MXOSRVR ，以避免在鏈接請求很少的狀況下浪費資源。當客戶請求數量大於預先啓動的MXOSRVR 進程數目時，DCS Master再爲新的鏈接請求啓動新的MXOSRVR ，以便知足高併發的客戶鏈接。

DCS Master是全部客戶端的惟一接入點，所以Trafodion爲其提供了HA保護。當DCS Master故障退出，或者其所在節點崩潰時，Trafodion會在集羣的其餘健康節點上從新啓動一個新的DCS Master，並利用floating IP的技術保證客戶端能夠繼續執行鏈接。整個過程對客戶端徹底透明。

Trafodion的HA機制很是複雜，須要一篇單獨的文章來詳細介紹，這裏就再也不展開敘述。

SQL編譯執行層

客戶請求被接受後，每一個ODBC客戶端都有一個單獨的MXOSRVR 負責。該MXOSRVR 就是master進程，負責用戶query的執行。一條用戶query的執行流程大體以下：

首先，MXOSRVR 會調用compiler模塊對SQL語句進行編譯和優化。Trafodion擁有一個很是成熟的SQL編譯器，通過了20年的不斷加強和改進，造成了一個強大的基於成本的優化器，可以生成用戶SQL的最佳執行計劃，好比最優的join表順序。此外，編譯器擁有一個執行計劃緩存，若是SQL的執行計劃已經在緩存中，則當即返回該計劃，節省了編譯的開銷。

執行計劃會指導Master如何執行用戶query。對於簡單的query，執行計劃僅僅須要master自己便可完成。對於複雜的query，master根據計劃會啓動多個ESP進程，併發地執行query。Trafodion的執行器是一個MPP構架的併發處理模型。它的多數執行操做符都支持併發，好比並發join，併發aggregation等等。

Trafodion編譯器

Trafodion編譯器的主要職責就是將SQL文本解析爲一個最優的執行計劃。它主要包括如下幾部分：

Parser：parser採用bison對SQL文本進行文法分析，生成語法樹。Parser也負責維護執行計劃緩存。若是可以在這一步決定輸入的SQL文本在緩存中，則直接返回執行計劃。

Binder：Binder對語法樹進一步進行分析，相似程序編譯器的語義分析，對語法合格的SQL進一步進行檢查。好比檢查Table是否存在，column數據類型是否匹配等。Binder還維護執行計劃緩存。

Normalizer：Normalizer對Binder生成的語法樹進行邏輯優化。實施傳統意義上的基於規則的優化，好比將查詢條件下推；將子查詢修改成semi-join；將DISTINCT轉換爲groupby等等。

Analyzer：Analyzer對語法樹進行一些補充，以幫助優化器判斷是否能夠運用某些規則。好比對於底層數據分區的訪問能夠有多種方式，能夠直接從base table訪問，或者從索引訪問。Analyzer收集數據表的索引狀況，添加進語法樹，以便優化器作選擇。

Optimizer：能夠說這是Trafodion最值得驕傲和關注的一個核心技術。優化器採用Cascades框架，是一個基於成本的優化器，並且Cascades框架很是易於擴展，開發人員能夠添加新的規則來擴展新的優化方法。優化器實際上能夠看做一個對問題空間的搜索過程，對於同一條query，經過規則，能夠生成不少等價的執行計劃。舉一個例子：簡單的規則，好比Ajoin B => B join A，應用該規則就會生成兩個不一樣的等價計劃。

優化器對語法樹應用各類規則，生成不一樣的執行計劃，造成一個搜索空間。而後在這個搜索空間內經過比較每一個計劃的成本，來找出最優的方案。因爲規則衆多，等價的執行計劃數量會指數級增加，致使搜索空間很是巨大，所以採用窮舉法一條一條的進行比較是不現實的。傳統的優化器框架好比 Dynamic programming是自底向上的策略，很難縮小搜索空間，而Cascades採用自頂向下的搜索策略，能夠很方便地利用branch-and-bound算法，將一些分支進行裁剪，即不須要再深刻分支進行優化。好比某分支的cost已經超出當前的總cost，則對於該分支就再也不進行進一步搜索。

Cascades還擁有MEMO數據結構，可以記憶曾經搜索過的分支，這進一步增長了搜索的效率。

此外Trafodion優化器還在多年的實踐中總結出了不少的經驗式規則(heuristics )，可以進一步減少搜索空間。

最後優化器支持multi-pass的模式，對於簡單的query，先enable很是少許的規則，將搜索空間限定在很小範圍，所以能夠高效地找到最優解；對於複雜query，進入第二個pass，enable全部的規則，進一步找出更好的執行計劃。

Pre-Code generator：optimizer選出了最優的執行計劃，在生成物理執行計劃以前，pre-codegenerator再應用一些物理優化策略，好比常數摺疊，舉例以下：假設Where條件爲a=5 and b=a。 能夠將b=a進一步替換爲b=5。

Generator：最後Generator將執行計劃翻譯爲能夠被Trafodion執行器執行的物理執行計劃。這裏有一個重要步驟，優化標量表達式。所謂標量表達式，即其解析結果爲標量的表達式，好比a+b+c等。Trafodion利用LLVM將多數標量表達式編譯成運行時的機器代碼，從而進一步提升了執行速度，相似JIT將部分javabytecode編譯爲機器指令以便加速java程序的執行。

成本模塊：Trafodion編譯器還有一個通過長期調節和校準的cost成本模塊，對各類SQL operator的成本進行估計。成本計算須要對存放在表內數據的分佈狀況有所瞭解，這是依賴對錶數據進行掃描和採樣統計計算出的直方圖來支持。成本模塊從直方圖中獲得數據的分佈狀況，計算出Cardinality。它還綜合考慮了CPU，內存消耗，消息通信和磁盤IO等條件爲各個SQL操做算子計算出一個cost vector，提供比較準確的成本估計。

以上各個系統組件協同工做，如上圖所示，SQL語句通過parser和Normalizer的分析以後，輸入優化器進行基於成本的優化；成本估計模塊經過直方圖得到數據分佈，而後根據每一個操做符自身的特色，進行成本估計，將成本輸入優化器。根據這些輸入，優化器最終生成一個最優的執行計劃。

Trafodion執行器

Trafodion的執行器是一個MPP構架的併發執行器。它的工做模式是數據驅動，所以一旦有數據就緒，就能夠返回用戶，而無需等待整個query徹底結束執行，提升了用戶響應速度。執行器由不一樣的SQL操做符組成，數據在各個操做符之間經過IPC流動，無需將中間計算結果保存到磁盤。若是中間數據太大，超過了RAM的容量，操做符會將數據overflow到磁盤上，所以Trafodion的query執行不受物理內存大小限制。

併發執行

Trafodion執行器最大的優勢是極佳的併發能力。多數SQL操做算子都有併發執行的能力，包括GROUPBY，JOIN，INSERT都支持併發執行。

這裏舉一個小例子來講明Trafodion如何併發執行一個簡單的sum(col1)彙集操做：master會在集羣的每一個節點啓動一個ESP進程，該進程負責對存儲在該節點上的數據分區進行sum彙集操做。多個ESP同時併發執行，將最終結果發還給master，由master彙總。對於彙集，Trafodion還能夠將該操做下推到數據訪問層執行，而不須要將數據分區的每一行數據返回給ESP，由ESP逐一統計，而是由底層的數據訪問層進行統計操做，僅僅將彙集結果發給ESP，ESP再返回給master。

再看看Trafodion的Join。Trafodion支持全部的join類型，內鏈接，外鏈接，non-equijoin，semi-join，全鏈接等等。在Join的實現方式上，支持nestloop join，merge join和hashjoin。不管哪種join算法，都有併發執行的能力。Trafodion支持多種併發join方法，由優化器選擇最優的一種。

首先介紹你們最熟悉的兩種併發join算法，即broadcast和repartition。

broadcast parallel join(hash join)

broadcast類型的join中，一個表比較小，能夠徹底放入單個節點的內存中。在這種狀況下Trafodion會將小表廣播到全部節點上。該併發執行方法用於hashjoin。每一個節點上的ESP將小表放入內存並創建hash表，而後順序讀入本節點上的大表分區，執行hashjoin操做。

repartition parallel join

repartition類型的join中，兩個表都很大，沒法放入單機內存。這種狀況下，優化器生成的執行計劃會自動派生兩層ESP，第一層讀取數據後按照join column進行repartition操做，將兩個Join表的數據從新分區，將join column值相同的數據聚集到同一個第二層ESP中執行join操做。而後，全部的第二層ESP將Join結果返回master進行彙總。

以上兩種在Hadoop的應用中常常被使用到，被稱爲mapper join和reducer join。這兩種併發join方法都須要很是大的網絡開銷和內存開銷。Trafodion優化器可以智能地在可能的狀況下選擇如下幾種併發join方法：

Matching PartitionsJoin

若是參加join的兩張表都是按照join column分區的，那麼直接能夠在各個節點的ESP中執行本地join，由於確定不須要其餘節點上的數據。這是最理想的狀況。

Inner Child ParallelAccess (for Nested Join)

這種方法只適用於Nest Loop Join。TblA做爲outer table；TblB做爲inner table。TblA有兩個分區，所以啓動2個ESP，ESP1從TblA的分區1逐行讀取數據，而後逐一從TblB讀取相應的數據行進行鏈接操做；同理ESP2也作一樣的工做。這種類型的join比broadcast的方法節約內存開銷，但多個ESP可能會競爭讀取outer table。但能夠支持非等值join。

Trafodion的MPP併發執行器還有不少其餘的先進技術，好比HP的專利MDAM，Adaptive Segmentation，Skewbuster等均可以顯著加速query的執行效率下降延遲，從而達到sub-second的實時響應。限於篇幅，MDAM等技術在這裏就不展開敘述，Trafodion團隊將陸續推出專題技術文章來單獨介紹這些專利技術。

數據訪問層

當執行器對底層數據庫表進行讀寫時，就須要調用數據訪問層的服務。Trafodion的數據都存放在HBaseTable中。HBase自己支持對數據的隨機讀寫，可是不支持ACID事務處理。所以數據訪問層必須和DTM(分佈式事務管理器)相互配合，實現有事務保護的讀寫。事務處理在下一個小結詳細介紹。

DTM對HBase的API進行了封裝，添加了必要的事務處理支持。其他的讀寫邏輯和原生的HBase讀寫是同樣的。所以若是不考慮事務，數據訪問層就是一個標準的HBase客戶端，經過HBaseclient API訪問HBase。HBase是Trafodion數據訪問和存儲層的核心。也是Trafodion區別於傳統數據庫的最重要的地方。藉助於HBase，Trafodion也能夠提供極佳的水平擴展能力，同時具備很強的可靠性，而這些能力是傳統數據庫所不具有的。

Trafodion支持的三種底層數據庫表：Trafodion表，Hive表和HBase表。數據訪問層須要負責對這三種存儲類型的訪問控制。

Trafodion表

Trafodion表是用戶用Trafodion的DDL語句直接建立的數據庫表。在底層是一張HBase表，所以從Trafodion表到HBaseTable須要必定的映射和編碼。

映射

即如何將Trafodion數據庫表映射到HBase Table。咱們考慮以下這個DDL建立的Trafodion表：

create table sales.item(item_id int not null,

                          item_name char(10) ,

                          primary key (item_id));

首先是如何將關係數據庫的schame+table_name映射到HBaseTable。這個映射原則很是簡單，即一個trafodion表在HBase中存儲的表名爲。例子中的item表在HBase中被映射爲TRAFODION.SALES.ITEM這個HBaseTable。

其次是Trafodion表的各個column如何映射到HBase的存儲模式中。HBase的表內部有ColumnFamily，每一個ColumnFamily中能夠有任意多的ColumnQualifier，每個行有一個rowkey，和一個timestamp。這四個維度定義了一個數據Cell。那麼Trafodion的二維表如何映射到HBase這樣的存儲模型中呢？

Trafodion將表的主鍵列組合起來做爲HBase的rowkey。Column映射到HBase的columnqualifier，而timestamp被用做事務管理的時間戳。在目前的release中，全部列數據都存放在同一個ColumnFamily中，支持多ColumnFamily已經在Trafodion的藍圖中，所以將來這個映射會有所改變。

編碼

HBase存儲的數據是沒有數據類型的。Trafodion的表卻支持不一樣的SQL數據類型，好比CHAR型，即按字符串進行存儲，」1」被編碼爲ASCII碼0x41。若是SQL數據類型爲INTEGER，在存儲到HBase中時，Trafodion會直接寫入二進制數0x00,0x00,0x00,0x01，佔用4個byte；相應的LONG型佔8個byte。

Trafodion會自動進行類型處理，無需應用程序本身進行編解碼的工做。

數據分區

HBase會自動經過split技術對數據進行分區，可是某些狀況下，好比時間序列數據順序插入的狀況下，大量的數據讀寫會集中在某個單一Region上，從而使得單臺RegionServer的負載高於其餘的RegionServer。Trafodion支持slatedpartition功能，在建立表的時候經過指定SALT關鍵字，Trafodion會自動爲rowkey加入hash前綴，對錶進行pre-split，保證平均地將數據分佈在集羣中。用戶也能夠不指定SALT關鍵字，而依賴底層HBase自動進行數據分區。

訪問原生HBase表

Trafodion也能夠直接訪問原生HBase表，提供兩種訪問方式: Cell-Per-Row和Rowwise Per-Row。

經過Cell-Per-Row方式訪問HBase表，每個HBase的Cell會做爲SQL結果集中的一行數據。經過Rowwise Per-Row模式訪問，每一行HBase數據做爲SQL結果集的一行數據。

假設Table1有2行數據，每行兩個Cell:[(row1, CF1:Col1, v1), (row1,CF1:Col2, v2) , (row2, CF1:Col1, d1), (row2,CF1:Col2, d2)]。

Cell-Per-Row訪問：

select * from hbase.」_CELL_」.」table1」

返回4行數據

value
(row1, CF1:Col1, v1)
(row1,CF1:Col2, v2)
(row2, CF1:Col1, d1)
(row2, CF1:Col2, d2)

經過Rowwise-Per-Row方式訪問：

select * from hbase.」_ROW_」.」table1」;

返回兩行數據

rowkey	value
row1	CF1:Col1:v1 CF1:Col2:v2
row2	CF1:Col1:d1 CF1:Col2:d2

訪問原生Hive表

Trafodion能夠直接訪問原生Hive表。採用特殊的schema 「hive」，用戶直接使用SQL語句便可訪問。好比

select * fromhive.hive.table1;

SQL引擎會識別」hive.hive」這個特殊的schema，讀取Hive的metastore獲取table1的元數據，而後直接經過libhdfs訪問HDFS上的Hive表數據。所以繞過了DTM。因此，對於原生Hive表的訪問，Trafodion不提供事務保護

關於事務

Trafodion的威爾士本意即事務，所以事務處理是Trafodion很是重要的一個方面。事務是一系列query的組合。一個事務由若干操做構成，並由begin開始，由commit或者abort結束。

Trafodion採用兩階段提交協議來保證分佈式事務的完整性。每一個節點均運行TM進程，全部的TM都是peerto peer對等的，而避免了單一的事務管理器的擴展性問題和SinglePoint of Failure問題。高併發狀況下，全部的活躍事務由不一樣節點上的TM分別管理，提供了很高的擴展能力。

原生的HBase自己僅支持單行的ACID事務保證，Trafodion基於開源項目hbase-trx（https://github.com/hbase-trx/...）開發了目前版本的Transactionon HBase機制。提供了跨行跨表的ACID保證。hbase-trx採用MVCC機制，提供SnapShotIsolation事務隔離級別。原生的hbase-trx僅支持HBase0.94，且採用了侵入式的開發方法，大量修改了HBase的基本代碼。Trafodion團隊吸收了hbase-trx的基本思路，利用HBase協處理器從新開發了hbase-trx，並支持HBase0.98版本。並改進了日誌實現，可以保證各類failure狀況下數據的安全性。

目前TrafodionDTM團隊正在和中國科學院計算所合做開發新的Transactionon HBase算法Stateful-stateless Concurrency Control (SSCC)。關於SSCC的原理，讀者能夠進一步參考開源項目Domino:https://github.com/domino-suc...，預計將於TrafodionR1.2版本開始提供產品使用。SSCC提供比SnapShot Isolation更高級的隔離級別，同時對無狀態寫操做有很高效的支持，提供更高的併發度。無狀態寫在web應用中很是廣泛，採用這一機制，Trafodion能夠高效地爲相關的web應用提供強大的支持。

小結

Trafodion是一個複雜的大系統，一篇短文不管如何也不可能徹底說明其內部運做原理。筆者僅但願用最簡單的描述給各位讀者一個大致的概念，做爲一個開源項目，Trafodion歡迎各位研讀源代碼，並共同改進。

經過本文，但願讀者認同如下幾個關鍵點：

• Trafodion有一個成熟的SQL編譯器，可以進行基於成本的優化
• Trafodion有一個先進的MPP併發執行引擎
• Trafodion有一個創新的Transaction實現
• Trafodion有一個成熟的ODBC/JDBC接入層

Trafodion構架在HBase之上，繼承了全部HBase的優勢。爲用戶提供極佳的水平擴展性

本文沒有涉及到的技術話題還有不少，好比Trafodion的HA實現，安全體系，NoSQL支持等。Trafodion團隊會努力完善文檔，也歡迎各位讀者可以下載Trafodion源代碼進行使用和學習，並貢獻您的理解和分析。

做者：劉明-易鯨捷首席架構師