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

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

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

Trafodion的鼻祖是天騰 (Tandem) 公司的NonStop SQL。之后在1989年，天騰推出了NonStop SQL/MP，它是第一個MPP分布式數(shù)據(jù)庫，實(shí)現(xiàn)海量并發(fā)SQL執(zhí)行。在當(dāng)時的歷史條件下，NonStop SQL/MP開創(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年，惠普公司和康柏公司合并，已被康柏收購的天騰也成為了惠普的一部分。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ù)存儲和訪問引擎移植到HBase/Hadoop上，并創(chuàng)新地開發(fā)出HBase分布式事務(wù)處理等新技術(shù)，從而推出了Trafodion，并將全部代碼開源，貢獻(xiàn)給社區(qū)。

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

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

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

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

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

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

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

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

Trafodion支持UDF和存儲過程。

Trafodion提供Linux和Windows版本的ODBC/JDBC驅(qū)動。基于ODBC/JDBC的應(yīng)用可以方便地移植到Trafodion平臺上來。

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

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

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

Trafodion可以無縫地集成原生的HBase、Hive數(shù)據(jù)。比如用戶可以直接在Trafodion中進(jìn)行Hbase、Hive和Trafodion的多表join操作?；蛘呃肨rafodion的SQL接口直接訪問存放在Hive和HBase的原生數(shù)據(jù)，無需做數(shù)據(jù)移動和轉(zhuǎn)換。

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

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

可以將Trafodion看作是一個構(gòu)建在可擴(kuò)展Hadoop平臺上的傳統(tǒng)數(shù)據(jù)庫?；诖耍琓rafodion可以有多種適合的應(yīng)用場景。

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

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

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

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

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

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

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

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

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

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

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

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

而Trafodion本身就是一個關(guān)系型數(shù)據(jù)庫，因此從傳統(tǒng)數(shù)據(jù)庫應(yīng)用遷移的成本極低。Trafodion關(guān)注于幫助用戶解決遷移問題，比如啟其開發(fā)團(tuán)隊(duì)特意為兼容用戶原有的Oracle應(yīng)用而對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ù)庫，又面臨數(shù)據(jù)量不斷增長的困境，不妨考慮采用Trafodion來重用過去的應(yīng)用，保護(hù)過往投資，節(jié)約新的投入。

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

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

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

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

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

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

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

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

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

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

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