簡介

Trafodion是一個開源Apache專案。它提供了一個成熟的企業級SQL on HBase解決方案。Trafodion的主要設計思想是處理operational型別的工作負載，或者是傳統的OLTP應用。此外，對於需要保證資料一致性，需要標準SQL開發介面，或者需要實時資料讀寫分析的應用，Trafodion也是一個非常合適的解決方案。

首先，請允許筆者簡單介紹一下她的前世今生。

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

Trafodion的鼻祖是天騰(Tandem) 公司的NonStop SQL。天騰公司在NonStop SQL之前已經開發了一個關係型資料庫處理系統。在1970年代，SQL語言還未誕生，雖然IBM的E.F.Codd已經發表了“A Relational Model of Data for Large Shared Data Banks”。但是業界還未有一個標準的4GL語言。在當時，唯一的關係資料庫實現是IBM的System R。NonStop SQL的核心開發者 Jim Gray也是該專案的開發人員(關於Jim Gray，無需我多言)。有趣的是，那個時代的資料庫也是某種意義上的NoSQL，因為她不支援SQL語言訪問，而是提供API給應用程式直接呼叫。因此筆者將其比喻為SQL的史前時代。

1984年Jim Gray帶領天騰公司的研發人員開發了NonStop SQL，實現了SQL語言訪問。之後在1989年，天騰推出了NonStopSQL/MP。它是第一個MPP分散式資料庫，實現海量併發SQL執行，當時的歷史條件下，NonStopSQL/MP並開創性地提供了線性橫向擴充套件能力（我們如今耳熟能詳的scale out）。

1999年，在Graefe Goetz的幫助下，NonStopSQL/MX誕生了，她實現了基於成本的CBO SQL優化器和基於資料流的MPP SQL執行器。

2002年，惠普公司和康柏公司合併，已經被康柏公司收購的天騰公司也成為了惠普公司的一部分。2006年，NonStopSQL的OLAP分支Neoview誕生，而Trafodion直接繼承於Neoview和其後續產品SeaQuest。SeaQuest將Neoview從其專有的硬體，和專有的NonStopOS作業系統中移植到通用的x86伺服器和通用的Linux作業系統上。2014年，乘著大資料的浪潮，SeaQuest將底層的資料儲存和訪問引擎移植到HBase/Hadoop上，並創新地開發出HBase分散式事務處理等新技術，從而推出了Trafodion，並將全部程式碼開源，貢獻給Apache社群。

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

在介紹Trafodion的技術體系和細節之前，筆者佔用各位讀者的寶貴閱讀時間來了解了她的前世今生，並非個人的抒情。。。在今天這個技術百花齊放的時代，新的奇怪單詞不斷躍入人們的視線，Hadoop，Impala，Spark，MongoDB，Redis，Riak，Stinger，Presto，Dremel。。。幾乎每隔一兩個月就會有一個新的NoSQL或者Hadoop技術出現。從前只有IBM，Oracle，Microsoft等幾個巨頭把持的技術領地，如今卻似乎每一家有實力的公司，甚至是幾個有想法的資料愛好者都能夠迅速推出新的大資料資料庫產品。普通程式設計師們已經有點兒眼花繚亂，不知道該學習哪個。筆者今天在這裡要介紹一個更加奇怪的威爾士單詞Trafodion，心中惶恐。因此講一講Trafodion的身世，期望讀者可以生出些好奇，騰出些許寶貴時間來繼續閱讀本文。。。

Trafodion是一個建立在Hadoop/Hbase平臺上的關係型資料庫，她的Welsh原意是“事務”。Trafodion能夠完整地支援ANSISQL 99標準，並支援ACID事務。基於最新的HBase發行版，Trafodion能夠利用HBase的擴充套件性管理海量資料，並能夠提供極低的訪問延遲。這些特點使得Trafodion成為一個創新的大資料解決方案。

傳統的RDBMS在擴充套件性上存在瓶頸，無法處理P級別的海量資料，因此催生了大量的NoSQL資料庫。但是NoSQL方案不提供方便的SQL介面，並且放棄了ACID支援。對於需要嚴格資料一致性的應用，NoSQL一般都無法滿足需求。

Hive等SQL on Hadoop專案提供了類似SQL的訪問介面，又構建在極具橫向擴充套件能力的Hadoop平臺上，即解決了大資料的擴充套件能力，又提供了使用者熟悉的SQL介面。但是他們也存在幾方面的問題。首先Hive等專案的SQL支援並不完整；其次，Hive等方案在訪問資料時，有比較大的延遲，不能支援OLTP或者operational型別的應用。而Impala，Stinger等實時SQLon Hadoop方案則關注於大資料分析，適用於資料只寫入一次而多次讀取的場景。這類方案一般都無法提供實時修改和寫入資料的功能，比如Impala就不支援UPDATE和DELETE語句。

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

· 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專案完全開源。使用者可以直接從www.trafodion.org下載使用，無需任何License費用。Trafodion和底層的Linux版本無關，也支援各種Hadoop發行版，因此使用Trafodion，使用者可以避免採用商業軟體帶來的供應商鎖定問題。

Trafodion主要的應用場景，各類解決方案漫談

可以將Trafodion看作是一個構建在可擴充套件Hadoop平臺上的傳統資料庫。基於此，Trafodion可以有多種適合的應用場景。

您在使用NoSQL?

首先，使用傳統資料庫的主要限制之一在於資料量增大到一定程度時，資料庫在擴充套件性上遇到瓶頸。比如擴充套件的成本太大，新增計算和儲存節點以及軟體License的費用驚人。

因此為了應對快速增加的資料量，很多應用不得不採用前後端cache快取，讀寫分離，分庫分表等技術，導致應用程式編寫難度增加，維護成本提高，當公司業務蒸蒸日上，資料繼續增加的情況下，這些技術手段已經用到了極限，然而應用的效能提升卻依然無法跟上資料增長的速度。這正是催生大量NoSQL資料庫的主要原因。但是多數NoSQL資料庫為了擴充套件性而犧牲了SQL的易用性，使用者需要使用各種不同的程式語言，學習各種NoSQL的程式設計方式，比如MongoDB，使用者需要學習JavaScript，Ruby或者Python；Riak採用了十分不易書寫的REST介面；Cassandra，Redis。。。不一而足。

即使程式語言對很多程式設計師並不是問題，但是多數NoSQL資料庫僅僅提供非常底層的資料讀寫功能。比如MongoDB不支援Join；key-value資料庫不支援聚集操作；等等，不忍一一列舉了。因此使用這些簡單API的應用開發人員需要花很多的精力來完成那些原本是資料庫開發人員的任務：比如做join，可以採用HashJoin，Nest Loop Join或者sortmerge join等不同方法，實現這些方法並不是非常簡單的事情，而應用程式開發人員必須需要投入很多的精力來實現這些和應用無關的功能，無法專注於更加有價值和創新意義的應用開發。況且每一個NoSQL的開發都不是隨便看幾天就可以開始使用的，需要一定的學習曲線。我覺得學習SQL語言比學習mongoDB的開發要簡單一點兒。

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

當您面對類似的困擾時，就可以考慮使用Trafodion來解決您的問題。

對於正在使用關係資料庫的使用者

另一方面，很多正在使用傳統關係資料庫的公司和組織，往往已經投入了很多的人力物力，開發了大量基於SQL的應用程式。在面對資料量不斷增加的情況下，如果遷移到NoSQL，則需要大量的投入將原有程式碼拋棄而從新開發，如此就勢必遇到前面描述的種種困難。並且過去的投資全都白白浪費了。

而Trafodion本身就是一個關係型資料庫，因此從傳統資料庫應用遷移的成本極低。Trafodion關注於幫助客戶解決遷移問題，比如在支援客戶的過程中，Trafodion開發團隊特意為相容客戶原有的Oracle應用而對Trafodion現有的標準SQL做了很多擴充套件，來相容Oracle。比如一些SQL擴充套件：

· Sequence Numbers

· NEXTVAL and CURRVAL oracle syntax

· PIVOT functionality

· ROWNUM() function to return sequential numbersfor returned

· 此處略過100行。。。

因此當您的應用本身基於關係型資料庫，又面臨資料量不斷增大的困境，不妨可以考慮採用Trafodion來重用過去的應用，保護過往投資，並節約新的投入。

使用Hadoop怎麼樣？

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

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

利用HBase，使用者可以在HDFS上進行隨機的資料訪問。Trafodion正是基於HBase的這種能力而構建。然而HBase功能相對簡單，基於其上進行開發需要學習HBase的專業知識；HBase不支援跨行跨表的ACID事務；HBase不支援二級索引；HBase不支援Join操作；HBase不支援聚集。凡此種種卻都是資料應用中非常需要的功能，意味著必須由應用層來自己負責。Trafodion將以上這些特性一一實現，開發人員可以使用描述性語言SQL，也無需考慮事務一致性，從而可以專心於自身的商業價值開發。因此使用HBase的很多應用場景都可以考慮使用Trafodion來解放開發人員，無需再去實現本應由資料庫提供的服務。

再來看看Hive。利用Hive，使用者可以使用熟悉的SQL語言來進行Hadoop上的大資料分析。然而傳統的Hive僅僅是將SQL語言翻譯為MapReduce，因此還是更加適合批處理任務。主要的問題在於MapReducejob的啟動成本，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不適應的場景

除了擴充套件性限制，關係型資料庫的另一個限制在於嚴格的schema定義，而NoSQL往往是schema-less的構架，非常靈活。在這一點上，使用面向文件的NoSQL資料庫往往更加合適。不過類似Drill，SQL on Hadoop生態圈也在試圖整合對半結構化、schema-less資料的處理需求，而同時保留SQL的易用性。Trafodion也完全可以採用類似的方式，即提供JSON資料型別，並內建JSON解析能力，來提供對於半結構化資料和schemaless的應用需求。

Trafodion有很強的OLAP分析能力，但是更偏重OLTP。Trafodion的底層資料儲存採用HBase。雖然HBase也號稱是列式儲存，但是和Parquet等列式儲存結構相比，其效率還是比較低下。並且在當前的Trafodion版本中，所有的列資料都儲存在同一個ColumnFamily中。不過隨著HBase本身的發展，以及Trafodion後續的持續進步，這個問題也一定可以得到解決。在Trafodion的藍圖中，已經將多ColumnFamily的計劃提出，相信在不久的將來也一定可以實現。

基於這種非最優的列式儲存現狀，Trafodion在進行分析類查詢時，無法獲得最好的IO。無法和Impalaon Parquet或者Vertica等純列式資料庫相比。因此對於要求極高的分析類需求，Trafodion尚不能很好地滿足需要。

Trafodion對於非結構化資料的支援尚未完善，對於完全的非結構化資料，比如log分析等，還是HadoopMapReduce的強項。

最後，對於不適合用關係代數和簡單的OLAP視窗函式可以解決的分析問題，比如複雜的機器學習應用，Trafodion不是一個合適的選擇。還是Spark更加適合。

結束語

Trafodion是一個集中了多年技術積澱的產品，歷史悠久。但是技術總是日新月異，DOS的歷史也很悠久，來頭很大，但是卻不會再有人使用，如果微軟不與時俱進，開發Windows作業系統，那麼今天還有誰知道BillGates呢。同樣，Trafodion的生命力來自其團隊的不斷求索和創新。

在大資料時代，Trafodion還是一個新產品，一定還很不完善。本文中提到的其他技術，各個都很優秀，沒有任何一個產品可以替代其他。正如<7周7資料庫>的作者所說，一個好的木匠不會只有一種工具。通過本文的膚淺介紹，希望讀者的工具箱可以放下Trafodion，在需要的時候讓她也試試身手。