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

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

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

Trafodion的鼻祖是天騰 (Tandem) 公司的NonStop SQL。之后在1989年，天騰推出了NonStop SQL/MP，它是第一個MPP分布式數據庫，實現海量并發SQL執行。在當時的歷史條件下，NonStop SQL/MP開創性地提供了線性橫向擴展能力（我們如今耳熟能詳的scale out）。

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

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

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

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

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

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

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

Trafodion結合了傳統RDBMS和NoSQL HBase各自的優點，提供了一種全新的數據訪問方式。它的主要特性如下：

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

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

Trafodion支持UDF和存儲過程。

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

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

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

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

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

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

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

可以將Trafodion看作是一個構建在可擴展Hadoop平臺上的傳統數據庫。基于此，Trafodion可以有多種適合的應用場景。

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

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

車聯網企業利用大數據和物聯網技術，對道路上運行車輛進行實時數據采集和分析，對客運車節能減排監控和駕駛行為進行監測分析。

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

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

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

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

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

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

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

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

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

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

Sequence Numbers

NEXTVAL and CURRVAL oracle syntax

PIVOT functionality

ROWNUM() function to return sequential numbers for returned

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

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

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

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

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

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

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

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

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

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

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

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