事务型和分析型完美统一的SQL-on-Hadoop，Apache Trafodion的前世今生

Posted 2021-04-13 易鲸捷大数据库

在大数据已成为时尚的时代，新技术的涌现百花齐放，新奇单词不断跃入人们的视线，Hadoop，Impala，Spark，MongoDB，Redis，Riak，Stinger，Presto，Dremel……几乎每隔一两个月就会有一个新的NoSQL或者Hadoop技术出现。从前只有IBM，Oracle，Microsoft等几个巨头把持的技术领地，如今却似乎每一家有实力的公司，甚至是几个有想法的数据爱好者都能够迅速推出新的大数据数据库概念和产品。让人眼花缭乱，不知道该学习哪个。今天在这里要介绍一个成熟而年轻的技术：Trafodion。

 

Trafodion是一个真正厚积薄发的，拥有20多年积累的开源Apache项目，提供了一个成熟的企业级SQL on Hadoop解决方案。它是为了处理运营型工作负载而生，非常适合Mission Critical的OLTP场景。此外，对于需要保证数据一致性，习惯标准SQL开发，或在高速数据输入同时，进行OLAP查询或报表，Trafodion也是一个非常合适的解决方案。

如何看待Trafodion？

首先，了解下Trafodion的前世今生。Trafodion的渊源可以追溯到数据库技术的“史前时代”。

Trafodion的鼻祖是天腾(Tandem) 公司的NonStop SQL。天腾公司在NonStop SQL之前已经开发了一个关系型数据库处理系统。在1970年代，SQL语言还未诞生，虽然IBM的E.F. Codd已经发表了“A Relational Model ofData for Large Shared DataBanks”。但是业界还未有一个标准的4GL语言。唯一的关系数据库实现是IBM的System R。

 

NonStop SQL的核心开发者Jim Gray也是该项目的开发人员(关于Jim Gray，无需我多言) 。有趣的是，那个时代的数据库也是某种意义上的NoSQL--不支持SQL，而是提供API给应用程序直接调用。

 

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

1999年，在Graefe Goetz的帮助下，NonStopSQL/MX诞生了，实现了基于成本的CBO SQL优化器和基于数据流的MPP SQL执行器。

 

2002年，惠普和康柏合并，已被康柏收购的天腾也成了惠普的一部分。2006年，NonStop SQL的OLAP分支Neoview诞生，而Trafodion直接继承于Neoview和后续产品SeaQuest。SeaQuest将Neoview从其专有的硬件，和专有的NonStop OS操作系统中，移植到通用的x86服务器和通用的Linux操作系统上。SeaQuest目前还担负着给惠普全公司上千亿营业额的全部报表处理，每晚从300多个分布在全球各地的数据库，调取超过0.8T的数据量进行处理。

整个系统采用三个互为备份的同步数据库满足了7x24，全年365天无间断的高可用性。并支撑着惠普全球每月6500多个独立用户的混合负载需求，包括每天超过1600个表的数据加载，3千多ETL Rollup脚本的并发执行，以及上百的复杂报表生成，和数以千计的即席查询，并全部达到了公司要求的SLA。

 

2014年，乘着大数据的浪潮，SeaQuest将底层的数据存储和访问引擎移植到HBase/Hadoop上，并创新地开发出HBase分布式事务处理等新技术，从而推出了Trafodion，并将全部代码开源，贡献给社区。

 

因此Trafodion是秉承了超过20年的技术积累而诞生的。其成熟的SQL引擎和各种Utility并不是几个技术天才在Google论文的启发下一挥而就，而是经过20多年的团队努力，公司超过3亿多美元的投入，和不断创新才得以完成。

Trafodion其实是关系型数据库

Trafodion是一个建立在Hadoop/Hbase平台上的关系型数据库，能够完整地支持ANSI SQL 99标准，并支持ACID事务。基于最新的HBase发行版，Trafodion利用HBase的扩展性，管理海量数据，并能够提供极低的访问延迟。

 

传统的RDBMS在扩展性上存在瓶颈，无法处理PB级别的海量数据，因此催生了大量的NoSQL数据库。但是NoSQL方案不仅不提供方便的SQL接口，并且放弃了ACID支持。对于需要严格数据一致性的应用，NoSQL一般都无法满足需求。

 

Hive等SQL-on-Hadoop项目提供了类似SQL的访问接口，又构建在极具横向扩展能力的Hadoop平台上，即解决了大数据的扩展能力，又提供了用户熟悉的SQL接口。但是他们也存在几方面的问题。首先Hive等项目的SQL支持并不完整；其次，Hive等方案在访问数据时，有比较大的延迟，不能支持OLTP或者实时运营类的应用。而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优化器，针对运营型复杂混合的工作负载进行了很多优化。

§  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可以有多种适合的应用场景。在此仅提供几个场景来加以分析。

 

1. 假如您在使用NoSQL?

 

首先，使用传统数据库的主要限制之一在于数据量增大到一定程度时，数据库在扩展性上遇到瓶颈。比如扩展的成本太大，添加计算和存储节点以及软件授权费用惊人。

 

因此为了应对快速增加的数据量，很多应用不得不采用前后端cache缓存，读写分离，分库分表等技术，导致应用程序编写难度增加，维护成本提高，当公司业务蒸蒸日上，数据继续增加的情况下，这些技术手段已经用到了极限，然而应用的性能提升却依然无法跟上数据增长的速度。这正是催生大量NoSQL数据库的主要原因。但是多数NoSQL数据库为了扩展性而牺牲了SQL的易用性，用户需要使用各种不同的编程语言，学习各种NoSQL的编程方式，比如MongoDB，用户需要学习javascript，Ruby或者Python；Riak采用了十分不易书写的REST接口；Cassandra，Redis……不一而足。

 

即使编程语言不是问题，但是多数NoSQL数据库仅仅提供非常底层的数据读写功能。比如MongoDB不支持Join；key-value数据库不支持聚集操作等等，不忍一一列举了。因此使用这些简单API的应用开发人员需要花很多的精力来完成那些原本是数据库开发人员的任务：比如做Join，可以采用Hash Join，Nested Loop Join或者sort merge join等不同方法，实现这些并不是非常简单的事情，应用程序开发人员必须需要投入很多的精力来实现这些和应用无关的功能，无法专注于更加有价值和创新意义的应用开发。况且每一个NoSQL的开发都不是随便看几天就可以开始使用的，需要一定的学习曲线。学习SQL语言比学习MongoDB的开发要简单一点儿。

 

另外值得一提的是，NoSQL放弃了对ACID事务的支持，而将这些任务都交给应用开发人员处理。而支持事务处理，尤其是分布式情况下的事务和数据一致性是很复杂的事情。

 

当您面对类似的困扰时，就可以考虑使用Trafodion来解决您的问题。

 

2. 假如您在使用传统关系数据库

 

很多正在使用传统关系数据库的公司和组织，往往已经投入了很多的人力物力，开发了大量基于SQL的应用程序。在面对数据量不断增加的情况下，传统关系数据库不堪重负。如果迁移到NoSQL，则需要大量的投入将原有代码抛弃而从新开发，如此就势必遇到前面描述的种种困难。并且过去的投资全都白白浪费了。

 

而Trafodion本身就是一个关系型数据库，因此从传统数据库应用迁移的成本极低。比如Trafodion开发团队特意为兼容客户原有的Oracle应用而对Trafodion现有的标准SQL做了很多扩展，来兼容Oracle。比如一些SQL扩展：

o    Sequence Numbers

o    NEXTVAL and CURRVALoraclesyntax

o    PIVOT functionality

o    ROWNUM() function toreturnsequential numbers for returned

o    ……

 

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

 

3. 假如您在使用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中。因此还是仅仅能够提供准实时的响应。

 

而Trafodion就是一个兼备实时加载和实时分析的解决方案。比如用Flume，Storm等对在线数据进行收集和流式处理，将处理后的数据实时加载到Trafodion数据库中，然后利用标准SQL对数据进行实时分析处理。近年来，一些技术能力强大的公司利用Storm+HBase来实现流式、实时计算，效果良好。在这类场景下也可以使用Trafodion替换HBase以便更加高效地使用SQL而不是HBase Java API来进行开发。

NoSQL的优势

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

 

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

〖结束语〗

Trafodion是一个集中了多年技术积淀的产品，历史悠久。但是技术总是日新月异，DOS的历史也很悠久，来头很大，但是却不会再有人使用，如果微软不与时俱进，开发Windows操作系统，那么今天还有谁知道Bill Gates呢。同样，Trafodion的生命力来自其团队的不断求索和创新。

 

在大数据时代，Trafodion还是一个新产品，一定还有许多有待完善的领域。本文中提到的其他技术，每个都很有特点，都有自己的应用领域。正如《7周7数据库》的作者所说，一个好的木匠不会只有一种工具。通过本文的肤浅介绍，希望读者的工具箱可以放下Trafodion，在需要的时候让她也试试身手。

---