摘要：而支持事務(wù)處理，尤其是分布式情況下的事務(wù)和數(shù)據(jù)一致性是很復(fù)雜的事情。

Trafodion是Apache基金會(huì)的一個(gè)開(kāi)源項(xiàng)目，提供了一個(gè)成熟的企業(yè)級(jí)SQL-on-HBase解決方案。Trafodion的主要設(shè)計(jì)思想是處理operational類型的工作負(fù)載，或者是傳統(tǒng)的OLTP應(yīng)用。此外，對(duì)于需要保證數(shù)據(jù)一致性、需要標(biāo)準(zhǔn)SQL開(kāi)發(fā)接口，或者需要實(shí)時(shí)數(shù)據(jù)讀寫(xiě)分析的應(yīng)用，Trafodion也是一個(gè)十分合適的解決方案。

Trafodion的淵源可以追溯到數(shù)據(jù)庫(kù)技術(shù)的“史前時(shí)代”。

Trafodion的鼻祖是天騰 (Tandem) 公司的NonStop SQL。之后在1989年，天騰推出了NonStop SQL/MP，它是第一個(gè)MPP分布式數(shù)據(jù)庫(kù)，實(shí)現(xiàn)海量并發(fā)SQL執(zhí)行。在當(dāng)時(shí)的歷史條件下，NonStop SQL/MP開(kāi)創(chuàng)性地提供了線性橫向擴(kuò)展能力（我們?nèi)缃穸炷茉數(shù)膕cale out）。

1999年，在Graefe Goetz的幫助下，NonStop SQL/MX誕生了，它實(shí)現(xiàn)了基于成本的CBO SQL優(yōu)化器和基于數(shù)據(jù)流的MPP SQL執(zhí)行器。2002年，惠普公司和康柏公司合并，已被康柏收購(gòu)的天騰也成為了惠普的一部分。2006年，NonStop SQL的OLAP分支Neoview誕生，而Trafodion直接繼承于Neoview和其后續(xù)產(chǎn)品SeaQuest。SeaQuest將Neoview從其專有的硬件，和專有的NonStop OS操作系統(tǒng)中移植到通用的x86服務(wù)器和通用的Linux操作系統(tǒng)上。

2014年，乘著大數(shù)據(jù)的浪潮，SeaQuest將底層的數(shù)據(jù)存儲(chǔ)和訪問(wèn)引擎移植到HBase/Hadoop上，并創(chuàng)新地開(kāi)發(fā)出HBase分布式事務(wù)處理等新技術(shù)，從而推出了Trafodion，并將全部代碼開(kāi)源，貢獻(xiàn)給社區(qū)。

因此Trafodion是秉承了超過(guò)20年的技術(shù)積累而誕生的。其成熟的SQL引擎和各種Utility并不是幾個(gè)技術(shù)天才在Google論文的啟發(fā)下一揮而就，而是經(jīng)過(guò)多年的團(tuán)隊(duì)努力和不斷創(chuàng)新才得以完成。

Trafodion是一個(gè)建立在Hadoop/HBase平臺(tái)上的關(guān)系型數(shù)據(jù)庫(kù)，它的Welsh原意是“事務(wù)”。Trafodion能夠完整地支持ANSI SQL 99標(biāo)準(zhǔn)，并支持ACID事務(wù)。基于最新的HBase發(fā)行版，Trafodion能夠利用HBase的擴(kuò)展性管理海量數(shù)據(jù)，并能提供極低的訪問(wèn)延遲。這些特點(diǎn)使得Trafodion成為了一個(gè)創(chuàng)新的大數(shù)據(jù)解決方案。

傳統(tǒng)的RDBMS在擴(kuò)展性上存在瓶頸，無(wú)法處理PB級(jí)別的海量數(shù)據(jù)，因此催生了大量的NoSQL數(shù)據(jù)庫(kù)。但是NoSQL方案不提供方便的SQL接口，并且放棄了ACID支持。對(duì)于需要嚴(yán)格數(shù)據(jù)一致性的應(yīng)用，NoSQL一般都無(wú)法滿足需求。

Hive等SQL on Hadoop項(xiàng)目提供了類似SQL的訪問(wèn)接口，又構(gòu)建在極具橫向擴(kuò)展能力的Hadoop平臺(tái)上，既解決了大數(shù)據(jù)的擴(kuò)展能力，又提供了用戶熟悉的SQL接口。但是它們也存在幾方面的問(wèn)題。

首先，Hive等項(xiàng)目的SQL支持并不完整；其次，Hive等方案在訪問(wèn)數(shù)據(jù)時(shí)，有比較大的延遲，不能支持OLTP或者operational類型的應(yīng)用。而Impala、Stinger等實(shí)時(shí)SQL on Hadoop方案則關(guān)注于大數(shù)據(jù)分析，適用于數(shù)據(jù)只寫(xiě)入一次而多次讀取的場(chǎng)景。這類方案一般都無(wú)法提供實(shí)時(shí)修改和寫(xiě)入數(shù)據(jù)的功能，比如Impala就不支持UPDATE和DELETE語(yǔ)句。

Trafodion結(jié)合了傳統(tǒng)RDBMS和NoSQL HBase各自的優(yōu)點(diǎn)，提供了一種全新的數(shù)據(jù)訪問(wèn)方式。它的主要特性如下：

Trafodion是一個(gè)企業(yè)級(jí)的SQL DBMS，能提供所有傳統(tǒng)商業(yè)RDBMS為用戶提供的服務(wù)。和傳統(tǒng)數(shù)據(jù)庫(kù)的區(qū)別在于，Trafodion基于Hadoop/HBase構(gòu)建，能夠提供極佳的水平擴(kuò)展能力。當(dāng)用戶數(shù)據(jù)量增加時(shí)，只需增加普通的計(jì)算機(jī)節(jié)點(diǎn)即可橫向擴(kuò)展存儲(chǔ)和計(jì)算能力。

Trafodion提供完整的ANSI SQL語(yǔ)言支持，包括DDL、DML、事務(wù)控制語(yǔ)句，而不是類似HQL等提供的SQL語(yǔ)言的子集。Trafodion還提供常見(jiàn)的商業(yè)數(shù)據(jù)庫(kù)才提供的utility，比如數(shù)據(jù)庫(kù)備份和恢復(fù)。

Trafodion支持UDF和存儲(chǔ)過(guò)程。

Trafodion提供Linux和Windows版本的ODBC/JDBC驅(qū)動(dòng)?；贠DBC/JDBC的應(yīng)用可以方便地移植到Trafodion平臺(tái)上來(lái)。

Trafodion采用分布式事務(wù)處理算法提供嚴(yán)格的ACID事務(wù)一致性保護(hù)，采用日志技術(shù)保護(hù)用戶數(shù)據(jù)在軟硬件故障情況下依然可以得到恢復(fù)。

Trafodion擁有一個(gè)非常成熟的基于成本的SQL優(yōu)化器 ，針對(duì)operational類型的工作負(fù)載進(jìn)行了很多優(yōu)化。

Trafodion擁有一個(gè)MPP并發(fā)執(zhí)行引擎，采用數(shù)據(jù)流驅(qū)動(dòng)構(gòu)架，中間數(shù)據(jù)保存在內(nèi)存中，不需要將中間數(shù)據(jù)保存在HDFS上；也不需要MapReduce等模型的啟動(dòng)開(kāi)銷；Trafodion利用LLVM的JIT方式生成運(yùn)行時(shí)代碼來(lái)解析表達(dá)式；利用這些執(zhí)行器的先進(jìn)技術(shù)，Trafodion保證了毫秒級(jí)別的查詢響應(yīng)時(shí)間。

Trafodion可以無(wú)縫地集成原生的HBase、Hive數(shù)據(jù)。比如用戶可以直接在Trafodion中進(jìn)行Hbase、Hive和Trafodion的多表join操作。或者利用Trafodion的SQL接口直接訪問(wèn)存放在Hive和HBase的原生數(shù)據(jù)，無(wú)需做數(shù)據(jù)移動(dòng)和轉(zhuǎn)換。

支持索引，約束等標(biāo)準(zhǔn)關(guān)系數(shù)據(jù)庫(kù)特性。提供數(shù)據(jù)的快速隨機(jī)訪問(wèn)，并在數(shù)據(jù)庫(kù)級(jí)別保證數(shù)據(jù)的一致性。

除了擁有以上介紹的這些技術(shù)特性，Trafodion項(xiàng)目完全開(kāi)源。用戶可以直接從 http://trafodion.apache.org 下載使用，無(wú)需任何License費(fèi)用。Trafodion和底層的Linux版本無(wú)關(guān)，也支持各種Hadoop發(fā)行版，因此使用Trafodion，用戶可以避免采用商業(yè)軟件帶來(lái)的供應(yīng)商鎖定問(wèn)題。

可以將Trafodion看作是一個(gè)構(gòu)建在可擴(kuò)展Hadoop平臺(tái)上的傳統(tǒng)數(shù)據(jù)庫(kù)。基于此，Trafodion可以有多種適合的應(yīng)用場(chǎng)景。

首先，Trafodion能夠處理海量的數(shù)據(jù)，數(shù)據(jù)量超過(guò)了傳統(tǒng)數(shù)據(jù)庫(kù)可以處理的范圍。而且Trafodion可以對(duì)數(shù)據(jù)進(jìn)行隨機(jī)的增刪改查，完整地支持ACID事務(wù)。比較適用的應(yīng)用場(chǎng)景就是物聯(lián)網(wǎng)應(yīng)用。

隨著道路運(yùn)輸業(yè)的飛速發(fā)展，道路交通安全事故逐年增加，同時(shí)還存在道路運(yùn)輸運(yùn)營(yíng)效率低、能耗高、效益產(chǎn)出低等問(wèn)題，與國(guó)外先進(jìn)水平相比，我國(guó)平均油耗要高10%-25%。目前我國(guó)絕大多數(shù)客運(yùn)及?；愤\(yùn)輸企業(yè)車輛運(yùn)營(yíng)與監(jiān)控調(diào)度管理水平偏低，設(shè)備和平臺(tái)的合規(guī)率比較低，既無(wú)法適應(yīng)政府管理部門相關(guān)管理要求，也無(wú)法滿足企業(yè)自身對(duì)車輛精細(xì)管理的要求。

車聯(lián)網(wǎng)企業(yè)利用大數(shù)據(jù)和物聯(lián)網(wǎng)技術(shù)，對(duì)道路上運(yùn)行車輛進(jìn)行實(shí)時(shí)數(shù)據(jù)采集和分析，對(duì)客運(yùn)車節(jié)能減排監(jiān)控和駕駛行為進(jìn)行監(jiān)測(cè)分析。

他們采用Trafodion作為底層數(shù)據(jù)庫(kù)，達(dá)到了良好的效果。車輛軌跡加載和查詢，表大小為133億。對(duì)該表數(shù)據(jù)的混合加載能力達(dá)到每秒8000條，在加載的同時(shí)，有300個(gè)并發(fā)連接查詢， 80%的用戶查詢最近7天內(nèi)的告警信息，20%用戶查詢15天內(nèi)的告警數(shù)據(jù)，所有查詢響應(yīng)時(shí)間均小于1秒。

首先，使用傳統(tǒng)數(shù)據(jù)庫(kù)的主要限制之一在于數(shù)據(jù)量增大到一定程度時(shí)，數(shù)據(jù)庫(kù)在擴(kuò)展性上遇到瓶頸。比如擴(kuò)展的成本太大，添加計(jì)算和存儲(chǔ)節(jié)點(diǎn)以及軟件License的費(fèi)用驚人。

因此為了應(yīng)對(duì)快速增加的數(shù)據(jù)量，很多應(yīng)用不得不采用前后端Cache緩存、讀寫(xiě)分離、分庫(kù)分表等技術(shù)，導(dǎo)致應(yīng)用程序編寫(xiě)難度增加，維護(hù)成本提高。當(dāng)公司業(yè)務(wù)蒸蒸日上，數(shù)據(jù)持續(xù)增長(zhǎng)的情況下，這些技術(shù)手段已使用到了極限，然而應(yīng)用的性能提升卻無(wú)法跟上數(shù)據(jù)增長(zhǎng)的速度。

這正是催生大量NoSQL數(shù)據(jù)庫(kù)的主要原因。但多數(shù)NoSQL數(shù)據(jù)庫(kù)為了擴(kuò)展性而犧牲了SQL的易用性，用戶需要使用各種不同的編程語(yǔ)言，學(xué)習(xí)各種NoSQL的編程方式，比如MongoDB，用戶需要學(xué)習(xí)JavaScript、Ruby或者Python；Riak采用了十分不易書(shū)寫(xiě)的REST接口；Cassandra、Redis……不一而足。

即使編程語(yǔ)言對(duì)于很多程序員來(lái)說(shuō)并不是問(wèn)題，但多數(shù)NoSQL數(shù)據(jù)庫(kù)僅僅提供非常底層的數(shù)據(jù)讀寫(xiě)功能。比如MongoDB不支持Join、key-value數(shù)據(jù)庫(kù)不支持聚集操作等等。因此，使用這些簡(jiǎn)單API的應(yīng)用開(kāi)發(fā)人員需要花很多精力來(lái)完成那些原本是數(shù)據(jù)庫(kù)開(kāi)發(fā)人員的任務(wù)。

比如做join，可以采用Hash Join、Nest Loop Join或者sort merge join等不同方法，實(shí)現(xiàn)這些方法并不是非常簡(jiǎn)單的事情，而應(yīng)用程序開(kāi)發(fā)人員需要投入很多精力來(lái)實(shí)現(xiàn)這些和應(yīng)用無(wú)關(guān)的功能，無(wú)法專注于更有價(jià)值和創(chuàng)新意義的應(yīng)用開(kāi)發(fā)。況且每一個(gè)NoSQL的開(kāi)發(fā)都不是隨意學(xué)習(xí)一兩天就可以開(kāi)始使用的，需要一定的學(xué)習(xí)曲線。我覺(jué)得學(xué)習(xí)SQL語(yǔ)言比學(xué)習(xí)MongoDB的開(kāi)發(fā)要簡(jiǎn)單一點(diǎn)兒。

另外值得一提的是，NoSQL放棄了對(duì)ACID事務(wù)的支持，而將這些任務(wù)都交給應(yīng)用開(kāi)發(fā)人員處理。而支持事務(wù)處理，尤其是分布式情況下的事務(wù)和數(shù)據(jù)一致性是很復(fù)雜的事情。

如果你也有類似的困擾，不妨考慮使用Trafodion來(lái)解決。

很多正在使用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的公司和組織，往往已經(jīng)投入了很多人力物力，開(kāi)發(fā)了大量基于SQL的應(yīng)用程序。在面對(duì)數(shù)據(jù)量不斷增長(zhǎng)的情況下，如果遷移到NoSQL，則需要大量的投入，將原有代碼拋棄重新開(kāi)發(fā)。如此就勢(shì)必會(huì)遇到前面描述的種種困難，并且過(guò)去的投資全都白白浪費(fèi)了。

而Trafodion本身就是一個(gè)關(guān)系型數(shù)據(jù)庫(kù)，因此從傳統(tǒng)數(shù)據(jù)庫(kù)應(yīng)用遷移的成本極低。Trafodion關(guān)注于幫助用戶解決遷移問(wèn)題，比如啟其開(kāi)發(fā)團(tuán)隊(duì)特意為兼容用戶原有的Oracle應(yīng)用而對(duì)Trafodion現(xiàn)有的標(biāo)準(zhǔn)SQL做了很多擴(kuò)展：

Sequence Numbers

NEXTVAL and CURRVAL oracle syntax

PIVOT functionality

ROWNUM() function to return sequential numbers for returned

因此當(dāng)你的應(yīng)用本身基于關(guān)系型數(shù)據(jù)庫(kù)，又面臨數(shù)據(jù)量不斷增長(zhǎng)的困境，不妨考慮采用Trafodion來(lái)重用過(guò)去的應(yīng)用，保護(hù)過(guò)往投資，節(jié)約新的投入。

最后，讓我們看看Hadoop生態(tài)圈。Hadoop在大數(shù)據(jù)領(lǐng)域已經(jīng)成長(zhǎng)為最受矚目的明星，眾多公司已經(jīng)大量使用Hadoop，從各自所擁有的海量數(shù)據(jù)中挖掘出新的商業(yè)價(jià)值。

Hadoop的MapReduce非常強(qiáng)大，但其固有的缺點(diǎn)在于：MapReduce僅適于批處理任務(wù)，而且開(kāi)發(fā)難度很大。因此HBase、Hive得到了長(zhǎng)足的發(fā)展。

利用HBase，用戶可以在HDFS上進(jìn)行隨機(jī)的數(shù)據(jù)訪問(wèn)。Trafodion正是基于HBase的這種能力構(gòu)建起來(lái)的。然而HBase功能相對(duì)簡(jiǎn)單，基于其進(jìn)行開(kāi)發(fā)需要學(xué)習(xí)HBase的專業(yè)知識(shí)；HBase不支持跨行跨表的ACID事務(wù)、不支持二級(jí)索引、不支持Join操作、不支持聚集。凡此種種卻都是數(shù)據(jù)應(yīng)用中非常需要的功能，意味著必須由應(yīng)用層來(lái)自己負(fù)責(zé)。

Trafodion將以上這些特性一一實(shí)現(xiàn)，開(kāi)發(fā)人員可以使用描述性語(yǔ)言SQL，也無(wú)需考慮事務(wù)一致性，從而可以專心于自身的商業(yè)價(jià)值開(kāi)發(fā)。因此使用HBase的很多應(yīng)用場(chǎng)景都可以考慮使用Trafodion來(lái)解放開(kāi)發(fā)人員，無(wú)需再去實(shí)現(xiàn)本應(yīng)由數(shù)據(jù)庫(kù)提供的服務(wù)。

再來(lái)看看Hive。利用Hive，用戶可以使用熟悉的SQL語(yǔ)言來(lái)進(jìn)行Hadoop上的大數(shù)據(jù)分析。然而傳統(tǒng)的Hive僅僅是將SQL語(yǔ)言翻譯為MapReduce，因此還是更加適合批處理任務(wù)。主要的問(wèn)題在于MapReduce job的啟動(dòng)成本，Sort/Shuffle將中間計(jì)算結(jié)果存放在HDFS磁盤上等等，這些因素都限制了Hive查詢的響應(yīng)速度和延遲。

因此標(biāo)準(zhǔn)的Hive使用場(chǎng)景為：定期進(jìn)行數(shù)據(jù)的批量加載，再進(jìn)行批處理計(jì)算。這個(gè)數(shù)據(jù)加載周期短則一個(gè)小時(shí)，長(zhǎng)的甚至每天才加載一次數(shù)據(jù)。更糟糕的是，分析計(jì)算本身往往也需要數(shù)分鐘甚至數(shù)小時(shí)的時(shí)間。因此這種計(jì)算模式往往無(wú)法滿足結(jié)果的時(shí)效性，而越來(lái)越多的應(yīng)用希望能提供更加實(shí)時(shí)的計(jì)算。

在線廣告投放、實(shí)時(shí)交通狀況分析等場(chǎng)景下，1小時(shí)前的數(shù)據(jù)已經(jīng)降低了分析的可用性，更多的期望是分鐘級(jí)別甚至秒級(jí)的實(shí)時(shí)性。比如為駕駛員提供道路信息的系統(tǒng)，如果每隔1小時(shí)才可以進(jìn)行分析，那么即使分析計(jì)算可以在1秒內(nèi)完成，其分析的數(shù)據(jù)卻是1小時(shí)前的，那么駕駛員已經(jīng)堵車堵了一小時(shí)，這樣的系統(tǒng)就失去了意義。

為了滿足實(shí)時(shí)性，一些新的實(shí)時(shí)分析系統(tǒng)涌現(xiàn)出來(lái)。比如Hortonworks的Stinger，采用Tez DAG型計(jì)算模型，極大地提高了響應(yīng)速度，Stinger開(kāi)發(fā)團(tuán)隊(duì)聲稱已經(jīng)有100倍的性能提高。與此同時(shí)，其他的實(shí)時(shí)解決方案，比如Impala應(yīng)聲而出。Impala不再采用Map Reduce計(jì)算模型，而是采用和Trafodion相同的MPP并發(fā)執(zhí)行引擎直接讀取HDFS，以此獲得極低的數(shù)據(jù)響應(yīng)延遲，進(jìn)而支持實(shí)時(shí)數(shù)據(jù)分析。然而Stinger、Impala的底層數(shù)據(jù)存儲(chǔ)，比如ORCFile，Parquet等都無(wú)法支持隨機(jī)寫(xiě)入修改功能。因此即便Stinger和Impala可以提供秒級(jí)別的分析響應(yīng)能力，實(shí)時(shí)的數(shù)據(jù)依舊無(wú)法立即加載到Stinger和Impala的數(shù)據(jù)集中，所以Stinger/Impala還是僅僅能夠提供準(zhǔn)實(shí)時(shí)的分析能力。

用戶期望能夠?qū)υ诰€數(shù)據(jù)進(jìn)行實(shí)時(shí)加載、實(shí)時(shí)分析。而Stinger、Impala雖然可以提供實(shí)時(shí)分析能力，但無(wú)法提供實(shí)時(shí)加載能力。在這種情況下，Trafodion就是一個(gè)十分適合的解決方案。比如用Flume、Storm等對(duì)在線數(shù)據(jù)進(jìn)行收集和流式處理，將處理后的數(shù)據(jù)實(shí)時(shí)加載到Trafodion數(shù)據(jù)庫(kù)中，然后利用標(biāo)準(zhǔn)SQL對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)分析處理。近年來(lái)，一些技術(shù)能力強(qiáng)大的公司利用Storm+HBase來(lái)實(shí)現(xiàn)流式、實(shí)時(shí)計(jì)算，效果良好。在這類場(chǎng)景下也可以使用Trafodion替換HBase以便更加高效地使用SQL，而不是HBase Java API來(lái)進(jìn)行開(kāi)發(fā)。

在大數(shù)據(jù)時(shí)代，歷史悠久的Trafodion還只是一個(gè)新產(chǎn)品，還有很多功能需要逐步完善。本文中提及到的其他技術(shù)，各自都很優(yōu)秀，沒(méi)有任何一個(gè)產(chǎn)品可以替代其他。正如《七周七數(shù)據(jù)庫(kù)》的作者所說(shuō)，一個(gè)好的木匠不會(huì)只有一種工具。通過(guò)本文的簡(jiǎn)淺介紹，不妨把Trafodion放入你的工具箱，在需要時(shí)讓它試試身手。

作者：劉明-易鯨捷首席架構(gòu)師