相比于其他的SQL-on-Hadoop解决方案,Trafodion具有怎样的优势?“在Hadoop上运行运营型工作负载”一文中,我指出了Trafodion专注于运营型工作负载(OLTP、ODS)。本文介绍了Trafodion和其他SQL-on-Hadoop解决方案在技术上的差异。

本文中,我探讨了造就一流数据库的四个关键要素,介绍了Trafodion是如何实现这些要素的。您可以将Trafodion与其他数据库做一个对比。

时间、金钱、人才

Oracle、SQL Server、DB2、Teradata等各种优秀的RDBMS付出了数十年的努力、投入了数百万美元、拥有众多数据库的人才,致力于构建数据库引擎。而Trafodion的鼻祖是Tandem的NonStop SQL/MX,并直接继承了NonStop SQL/MX的分支Neoview(超过3亿美元的投资以及超过20年的研发投入)。

我们的数据库开发团队成员累计具有超过300年的数据库研发经验,了解如何构建高可用、可扩展的数据库引擎。我们的数据库构建在大规模并行的无共享架构上,具有并行性、可扩展性、关键任务高可用性的特点。我们的开发团队重写了NonStop SQL,使其不仅能够处理OLTP工作负载,还能处理BI工作负载,从而构建强大的企业级MPP数据库。我们凭借领先于NoSQL和Hadoop的意识,使HP将无共享的MPP架构开源,获得了得天独厚的竞争优势。

无论是产品对ANSI语言、ANSI/非ANSI函数的支持,还是在性能、可扩展性、并发、吞吐量、稳定性、高可用性、事务型以及跨工作负载的其他功能,都蕴含了大量时间、金钱、人才的投入。

在我们的产品背后,离不开这支强大的团队

一流的查询优化器

好的数据库一定要有强大的优化器,否则即使是最简单的查询也可能损害整个集群。不仅要构建一个好的优化器,还要让优化器处理各种企业级的工作负载,然后再进行调整。这样,才能适应不同工作负载的复杂性和差异。我们参加过关于优化器的各类会议,Trafodion的优化器绝对是行业中的佼佼者。

我们的优化器基于Cascades的优化框架。Cascades是基于成本、规则驱动的优化器,获得过多项专利。在此基础上,我们添加了Large Scope Rules。通过识别星型连接,优化器可以减少优化计划的搜索空间。这样,立即清除了大量计划并对维度表进行笛卡尔乘积,再对笛卡尔积与事实表执行嵌套join。

编译器为工作负载选择合适的连接策略,倾向于为运营型工作负载选择嵌套连接或probe cache,为BI/分析型查询选择merge连接或hash连接。它会根据基数,选择串行计划和并行计划。我们拥有专利技术Skew Buster。通过使用等高直方图(擅长检测倾斜)、计算在执行树所有层的基数,消除执行树所有层的倾斜。一个节点的倾斜可能会影响到集群中运行的所有查询。当倾斜的节点执行查询时,其他完成任务的节点会处于闲置状态。而Skew Buster就解决了这一问题。

优化器可以:

  • 解嵌套子查询
  • 将相关子查询转换为连接
  • 将谓词下推到执行树的最低点(Hadoop中称为LLAP)
  • 优化内部连接、左连接、右连接、全外连接
  • 在必要时使用专利的MDAM
  • 执行Eager Aggregation,减少消息流量
  • 执行hash Group By,避免排序
  • 考虑避免排序的策略
  • 利用专利的查询计划缓存技术,避免查询的再编译
  • 更多其他的功能

Trafodion优化器和数据库引擎处理过不同的企业级工作负载,并进行了相应的调整。如果优化器可以处理各种棘手的工作负载,就说明这是一个强大的优化器(棘手的工作负载不是指TPC基准的查询,因为所有的数据库都运行此类查询,其优化器也一定能够处理这些查询)。在为各种工作负载生成有效的计划方面,Trafodion优化器可以匹敌任何一流的RDBMS。

一流的并行数据流执行引擎

无论是多么有效的计划,都要有成熟、有效的执行引擎的支持。近年来,Spark、Tez、Flink创建了DAG等各种数据流执行引擎。而我们的数据流执行引擎继承于上世纪90年代的NonStop SQL/MX。Trafodion的实现不同于MapReduce,数据流通过内存队列连接的所有运算符。每个运算符都是一个独立的任务(运算符并行性),队列中前一个运算符的输出作为后一个运算符的输入(管道并行)。Trafodion还支持分区并行,通过将数据分布到不同region的salting,实现平衡的I/O。除了阻塞运算符(例如,sort),不会物化其他的中间结果。如果内存中可以完成sort,数据不会写出到磁盘。如果hash连接遇到必须处理的非常大的数据集并且内存溢出到磁盘,数据也会溢出到磁盘。

执行器可以使用串行计划,执行单行访问的OLTP查询(通过键访问,或通过单个region中的行组)。如果预计的行基数很小,甚至可能使用串行计划访问跨多个region server的多个region。即使有大量要跨region处理的行(谓词和/或聚合下推到协处理器),master执行器也会与各个region server并行通信,以执行查询。但如果在非collocated的列上有多个join(例如,连接的一个或两个表的主键与连接键不同)并且有大量数据要处理,则会启动多个ESP,以便并行执行查询。各ESP都是并行的,分别处理表中的一部分数据。根据表的聚集键和join列以及查询的join数量,可能会涉及多层的ESP。

执行器会选择不同的策略,以便在ESP之间交换数据(shuffle)。它可以对内表或外表进行hash或随机repartition或broadcasting,以执行连接。

用于执行操作的ESP数量和并行度是每个操作的预期基数的功能。因此,优化器选择最节省资源的策略,以执行查询中的各个操作。事实上,根据预期的总体基数,优化器可能会为整个查询确定一个最大的并行度。这就是专利技术Adaptive Segmentation。仅使用执行查询所需的节点数量,而不会使用所有节点来执行各个查询和操作。这不仅降低了内存资源的消耗,还大大提高了并发性。集群上可以并发运行更多查询,也提高了发生故障时的恢复能力。相比于使用所有节点执行所有的并行查询,这会大大降低节点故障影响的查询集数量。也就是说,它能有效地利用您的硬件资源。

Trafodion引擎不仅能实现上文所述,还能:

  • 在更新期间强制数据类型和引用、唯一和检查约束,确保数据的一致性
  • 强制Grant/Revoke安全性,仅限授权的用户更新或访问数据
  • 为OLTP和报表工作负载执行快速路径
  • 检测到大扫描时,预先获取数据,以便提高数据访问与引擎处理数据之间的并行度
  • 使用pcode和LLVM有效评估表达式,以提高处理速度
  • 其他

您不仅需要一流的数据库引擎,还需要一个类似于上述ESP的并行基础设施。如今,OLTP和报表工作负载的界限越来越模糊,大多数的应用程序需要Trafodion这样广泛的功能,以处理混合的工作负载。

一流的分布式事务管理系统

Trafodion使用完全分布式事务管理系统。OMID以及其他类似的HBase事务管理器都具有用于协调事务的单个事务管理器,并且与事务相关的所有数据上下文分布在整个集群中。这不仅仅是在可弹性扩展的Hadoop集群上实现的可扩展架构。这意味着region和事务管理器之间有大量的消息流量,管理整个上下文的单个节点存在性能瓶颈。如果事务管理器或运行的节点发生故障,这会影响到集群中的所有事务。同时,该架构无法扩展到能够处理成百上千的节点或处理较长的更新。

另一方面,我们利用了已有技术和尚未使用过的HBase代码,实现完全可扩展的分布式事务管理系统。每个节点上都有一个事务管理器,将事务协调到发起事务的节点(平衡节点之间的工作负载)。如果在一个100节点的集群上,就会有100个事务管理器处理并行的事务协调工作负载。单个事务管理器将不会管理这100节点之间的事务。HBase的协处理器管理事务上下文。每个region管理自身的事务更新和数据冲突解决。region之间的所有事务更新不会发给单个事务管理器解决冲突。

综上所述,时间、金钱、人才、成熟的优化器、并行数据流引擎、分布式事务管理是构建一流数据库的必要条件。在这些条件的基础上,我们还扩展了很多功能。我们已经在专注于运营型工作负载的最初版本中启用了很多功能。今后,我们还将推出更多功能。

开源

Trafodion是开源的。开源的最大好处是社区参与了开发。客户和供应商可以使用Trafodion,加速开发。用户可以根据自己的需要,定制解决方案,而无需等待我们或社区提供他们需要的功能。用户也可以在社区中发表对产品的看法。

其次,开源产品根据开源模式进行定价(例如,Cloudera和Hortonwork),无需支付许可费用。易鲸捷将使用企业版的Trafodion(将经过全面测试,与各种OS和发行版本集成),结合QA,实现高可用性并提高性能。相关的修复都将贡献到Trafodion。易鲸捷会根据对节点的支持以及客户需要的服务和培训,收取一定的费用。

当然,您还可以在Google中搜索“benefits of open source”,自行判断开源软件的优势和缺点。