Trafodion值得放入工具箱，由於有如下優勢

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

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主要應用場景

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

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

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

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

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

各種解決方案漫談

對於NoSQL用戶

首先，使用傳統數據庫的主要限制之一在於數據量增大到必定程度時，數據庫在擴展性上遇到瓶頸。好比擴展的成本太大，添加計算和存儲節點以及軟件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，從各自所擁有的海量數據中挖掘出新的商業價值。

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放入你的工具箱，在須要時讓它試試身手。

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