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

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

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

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

1999年，在Graefe Goetz的幫助下，NonStop SQL/MX誕生了，它實現(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服務器和通用的Linux操作系統(tǒng)上。

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

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

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

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

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

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

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

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

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

Trafodion支持UDF和存儲過程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sequence Numbers

NEXTVAL and CURRVAL oracle syntax

PIVOT functionality

ROWNUM() function to return sequential numbers for returned

因此當你的應用本身基于關系型數(shù)據(jù)庫，又面臨數(shù)據(jù)量不斷增長的困境，不妨考慮采用Trafodion來重用過去的應用，保護過往投資，節(jié)約新的投入。

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

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

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

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

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

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

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

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

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

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

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