本文来自 中国惠普大学

作者： 刘明

Trafodion的渊源可以追溯到数据库技术的“史前时代”。

Trafodion的鼻祖是天腾 (Tandem) 公司的NonStop SQL。天腾公司在NonStop SQL之前已经开发了一个关系型数据库处理系统。在1970年代，SQL语言还未诞生，虽然IBM的E.F.Codd已经发表了“A Relational Model of Data for Large Shared DataBanks”。但是业界还未有一个标准的4GL语言。在当时，的关系数据库实现是IBM的SystemR。NonStop SQL的核心开发者Jim Gray也是该项目的开发人员 (关于JimGray，无需我多言) 。有趣的是，那个时代的数据库也是某种意义上的NoSQL，因为她不支持SQL语言访问，而是提供API给应用程序直接调用。因此笔者将其比喻为SQL的史前时代。

SQL是在同一时期由System R项目的开发人员发明的。喜欢历史的读者可以阅读这篇有趣的文章（http://www.mcjones.org/System_R/SQL_Reunion_95/index.html）来怀旧SQL的那些早期岁月。

1984年Jim Gray带领天腾公司的研发人员开发了NonStop SQL，实现了SQL语言访问。之后在1989年，天腾推出了NonStop SQL/MP。它是个MPP分布式数据库，实现海量并发SQL执行，当时的历史条件下，NonStop SQL/MP并开创性地提供了线性横向扩展能力（我们如今耳熟能详的scale out）。

1999年，在Graefe Goetz的帮助下，NonStop SQL/MX诞生了，她实现了基于成本的CBO SQL优化器和基于数据流的MPP SQL执行器。大家非常熟悉的MS SQL Server也是采用同一个优化器代码，NonStop SQL/MX和SQL Server都是Goetz的Cascades优化器在商业上的应用。在为数不多的介绍SQL Server优化器的文章中，笔者看到两者代码中的数据结构命名都是一样的。

Trafodion依旧使用Cascades优化器，并且开源了全部源代码。各位想了解SQL Server的同行是否会感到心动？

2002年，惠普公司和康柏公司合并，已经被康柏公司收购的天腾公司也成为了惠普公司的一部分。2006年，NonStopSQL的OLAP分支Neoview诞生，而 Trafodion直接继承于Neoview和其后续产品SeaQuest。SeaQuest将Neoview从其专有的硬件，和专有的NonStop OS操作系统中移植到通用的x86服务器和通用的Linux操作系统上。2014年，乘着大数据的浪潮，SeaQuest将底层的数据存储和访问引擎移植到HBase/Hadoop上，并创新地开发出HBase分布式事务处理等新技术，从而推出了Trafodion，并将全部代码开源，贡献给社区。

因此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能够完整地支持ANSI SQL 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等实时SQL on Hadoop方案则关注于大数据分析，适用于数据只写入一次而多次读取的场景。这类方案一般都无法提供实时修改和写入数据的功能，比如Impala就不支持UPDATE和DELETE语句。

Trafodion结合了传统RDBMS和NoSQLHBase各自的优点，提供了一种全新的数据访问方式。它的主要特性如下：

• Trafodion是一个企业级的SQLDBMS，能提供所有传统商业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看作是一个构建在可扩展Hadoop平台上的传统数据库。基于此，Trafodion可以有多种适合的应用场景。

首先，使用传统数据库的主要限制之一在于数据量增大到一定程度时，数据库在扩展性上遇到瓶颈。比如扩展的成本太大，添加计算和存储节点以及软件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关注于帮助客户解决迁移问题，比如在支持客户的过程中，Trafodion开发团队特意为兼容客户原有的Oracle应用而对Trafodion现有的标准SQL做了很多扩展，来兼容Oracle。比如一些SQL扩展：

• Sequence Numbers

• NEXTVAL and CURRVAL oraclesyntax

• PIVOT functionality

• ROWNUM() function to returnsequential numbers for returned

• 此处略过100行...

因此当您的应用本身基于关系型数据库，又面临数据量不断增大的困境，不妨可以考虑采用Trafodion来重用过去的应用，保护过往投资，并节约新的投入。

后让我们看看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，因此还是更加适合批处理任务。主要的问题在于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来进行开发。

除了扩展性限制，关系型数据库的另一个限制在于严格的schema定义，而NoSQL往往是schema-less的构架，非常灵活。在这一点上，使用面向文档的NoSQL数据库往往更加合适。不过类似Drill，SQLon Hadoop生态圈也在试图整合对半结构化、schema-less数据的处理需求，而同时保留SQL的易用性。Trafodion也完全可以采用类似的方式来提供对于半结构化数据和schema less的应用需求。

Trafodion有很强的OLAP分析能力，但是更偏重OLTP。Trafodion的底层数据存储采用HBase。虽然HBase也号称是列式存储，但是和Parquet等列式存储结构相比，其效率还是比较低下。并且在当前的Trafodion版本中，所有的列数据都存储在同一个Column Family中。不过随着HBase本身的发展，以及Trafodion后续的持续进步，这个问题也一定可以得到解决。在Trafodion的蓝图中，已经将多Column Family的计划提出，相信在不久的将来也一定可以实现。

基于这种非优的列式存储现状，Trafodion在进行分析类查询时，无法获得好的IO。无法和Impala on Parquet或者Vertica等纯列式数据库相比。因此对于要求极高的分析类需求，Trafodion尚不能很好地满足需要。

Trafodion对于非结构化数据的支持尚未完善，对于完全的非结构化数据，比如log分析等，还是Hadoop MapReduce的强项。

后，对于不适合用关系代数和简单的OLAP窗口函数可以解决的分析问题，比如复杂的机器学习应用，Trafodion不是一个合适的选择。还是Spark更加适合。

来自：https://mp.weixin.qq.com/s/YQolkxyhGGpoMrVHIOGZPQ