Trafodion体系结构
Trafodion体系结构Trafodion简介Trafodion是一个构建在Hadoop/HBase基础之上的关系型数据库，它完全开源免费。Trafodion能够完整地支持ANSI SQL，并且提供ACID事务保证。和传统关系数据库不同的地方在于，Trafodion利用底层Hadoop的横向扩展能力，可以提供极高的扩展性。而传统数据库，比如MySQL，在数据量达到P级别的时候就很难处理。而Trafodion却可以借助HBase的扩展性，仅通过增加普通Linux服务器就可以增加计算和存储能力，进而支持大数据应用。比如原来使用MySQL的用户，如果数据量持续增加，往往需要采用前后端cache，分库分表，读写分离等技术。但是这些技术带来的弊端也很多。比如分库分表的构架下，不同分库之间无法执行join操作。采用这些复杂技术后，系统结构复杂，维护和开发成本提高。这是很多客户正在面临的问题。而从使用开发的角度来看，Trafodion和MySQL是完全一样的，他们同样是关系型数据库，基本的功能完全一致。因此一个经典的LAMP网络应用也可以轻松地用LATP(Linux, Apache, Trafodion, PHP) 搭建。而采用Trafodion，当业务扩展时，通过增加节点就可以应付不断增加的数据量，应用程序无需做任何修改，也无需考虑复杂的分库分表，读写分离等技术。这样就极大地降低了系统的复杂度。这只是Trafodion的可能应用之一，Trafodion还是一个非常适合的实时大数据分析平台。因为它不仅可以支持实时分析，而且能够支持实时数据写入，比如每秒上万条的随机数据插入。这是构建实时分析所必备的能力。Stinger或者Impala虽然可以提供实时查询，但去无法支持实时的数据插入。比如交通实时分析，利用Stinger/Impala等技术，虽然查询和分析可以在1分钟内完成，但是数据却只能定期载入，如果1小时一次，那么分析的数据样本是1小时前的数据，其分析结果也失去了时效性。比如，用户已经在那里堵车堵了了1个小时。关于Trafodion的使用场景读者可以参阅其他介绍Trafodion的系列文章。本文简要介绍Trafodion的技术体系结构，帮助读者基本了解Trafodion内部运作的原理。读者还可以参考https:/wiki.trafodion.org/wiki/index.php/Architecture了解Trafodion的技术构架。 总体结构Trafodion的体系结构可以看作三层：ODBC接入层；SQL编译执行层；数据访问和存储层。其总体结构如下所示：客户端应用通过JDBC/ODBC访问Trafodion。客户连接由Trafodion的接入层负责。接入层为每一个客户端连接分配一个master执行器，master负责用户连接所有query请求的执行和结果返回。对于简单的Query，Master进程本身就充当SQL执行层；复杂的query，访问大量数据和进行复杂运算的情况下，Master会启动一系列的ESP（Executor Server Processes）进程进行大规模并发执行。ESP进程是可以常驻内存的，以避免启动开销，但如果长期处于空闲状态ESP进程会退出，释放资源。每个ESP将执行结果返回给Master，由Master汇总并将最终结果返回给客户端。当Master或者ESP需要访问数据层的时候，会通过DTM来进行事务管理，在DTM(分布式事务管理器)的控制下调用HBase的客户端API进行数据的读写。下面分别介绍每一层的更多细节。Trafodion的接入层接入层的主要组件有两个：DCSMaster和MXOSRVR 。DCS Master进程运行在Trafodion集群的单个节点上，负责监听客户端的连接请求。当收到请求后，DCSMaster根据集群的工作负载平衡情况，选定集群中一个节点上的MXOSRVR 作为客户端的执行代理。DCS Master将选定的MXOSRVR信息返回客户端，收到信息后，客户端直接和MXOSRVR 进行连接，此后客户端的所有请求都由该MXOSRVR 负责处理。类似Oracle的Dedicated 模式。当多个客户端请求连接时，DCSMaster会平均地将客户端连接到不同的MXOSRVR ，从而均衡地利用集群中的每个计算节点。而且每个客户端都有一个单独的MXOSRVR 负责其后续计算请求的执行，以保证快速的响应客户query。一些数据库系统只有单一的ODBC接入点，高并发的情况下，就会出现排队现象，而采用了以上的模型后，每个客户端都由一个接入点唯一负责，而且这些接入点平均分配在集群的各个节点，可以充分发挥每台计算节点的能力。为了降低延迟，Trafodion启动的时候会预先在每个节点启动一定数量的MXOSRVR 进程。这样客户端连接请求被处理时，就不需要启动新MXOSRVR 进程的开销。但是Trafodion也不会预先启动非常多的MXOSRVR ，以免在连接请求不多的情况下浪费资源。当客户请求数量大于预先启动的MXOSRVR 进程数目时，DCS Master再为新的连接请求启动新的MXOSRVR ，以便满足高并发的客户连接。DCS Master是所有客户端的唯一接入点，因此Trafodion为其提供了HA保护。当DCS Master故障退出，或者其所在节点崩溃时，Trafodion会在集群的其他健康节点上重新启动一个新的DCS Master，并利用floating IP的技术保证客户端可以继续执行连接。整个过程对客户端完全透明。Trafodion的HA机制非常复杂，需要一篇单独的文章来详细介绍，这里就不再展开叙述。 SQL编译执行层客户请求被接受后，每个ODBC客户端都有一个单独的MXOSRVR 负责。该MXOSRVR 就是master进程，负责用户query的执行。一条用户query的执行流程大致如下：首先，MXOSRVR 会调用compiler模块对SQL语句进行编译和优化。Trafodion拥有一个非常成熟的SQL编译器，经过了20年的不断增强和改进，形成了一个强大的基于成本的优化器，能够生成用户SQL的最佳执行计划，比如最优的join表顺序。此外，编译器拥有一个执行计划缓存，如果SQL的执行计划已经在缓存中，则立即返回该计划，节省了编译的开销。执行计划会指导Master如何执行用户query。对于简单的query，执行计划仅仅需要master本身即可完成。对于复杂的query，master根据计划会启动多个ESP进程，并发地执行query。Trafodion的执行器是一个MPP构架的并发处理模型。它的多数执行操作符都支持并发，比如并发join，并发aggregation等等。 Trafodion编译器Trafodion编译器的主要职责就是将SQL文本解析为一个最优的执行计划。它主要包括以下几部分：Parser：parser采用bison对SQL文本进行文法分析，生成语法树。Parser也负责维护执行计划缓存。如果能够在这一步决定输入的SQL文本在缓存中，则直接返回执行计划。Binder：Binder对语法树进一步进行分析，类似程序编译器的语义分析，对语法合格的SQL进一步进行检查。比如检查Table是否存在，column数据类型是否匹配等。Binder还维护执行计划缓存。Normalizer：Normalizer对Binder生成的语法树进行逻辑优化。实施传统意义上的基于规则的优化，比如将查询条件下推；将子查询修改为semi-join；将DISTINCT转换为groupby等等。Analyzer：Analyzer对语法树进行一些补充，以帮助优化器判断是否可以运用某些规则。比如对于底层数据分区的访问可以有多种方式，可以直接从base table访问，或者从索引访问。Analyzer收集数据表的索引情况，添加进语法树，以便优化器做选择。Optimizer：可以说这是Trafodion最值得骄傲和关注的一个核心技术。优化器采用Cascades框架，是一个基于成本的优化器，而且Cascades框架非常易于扩展，开发人员可以添加新的规则来扩展新的优化方法。优化器实际上可以看作一个对问题空间的搜索过程，对于同一条query，通过规则，可以生成很多等价的执行计划。举一个例子：简单的规则，比如Ajoin B => B join A，应用该规则就会生成两个不同的等价计划。优化器对语法树应用各种规则，生成不同的执行计划，形成一个搜索空间。然后在这个搜索空间内通过比较每个计划的成本，来找出最优的方案。由于规则众多，等价的执行计划数量会指数级增长，导致搜索空间非常巨大，因此采用穷举法一条一条的进行比较是不现实的。传统的优化器框架比如 Dynamic programming是自底向上的策略，很难缩小搜索空间，而Cascades采用自顶向下的搜索策略，可以很方便地利用branch-and-bound算法，将一些分支进行裁剪，即不需要再深入分支进行优化。比如某分支的cost已经超出当前的总cost，则对于该分支就不再进行进一步搜索。Cascades还拥有MEMO数据结构，能够记忆曾经搜索过的分支，这进一步增加了搜索的效率。此外Trafodion优化器还在多年的实践中总结出了很多的经验式规则(heuristics )，能够进一步减小搜索空间。最后优化器支持multi-pass的模式，对于简单的query，先enable非常少量的规则，将搜索空间限定在很小范围，因此可以高效地找到最优解；对于复杂query，进入第二个pass，enable所有的规则，进一步找出更好的执行计划。Pre-Code generator：optimizer选出了最优的执行计划，在生成物理执行计划之前，pre-codegenerator再应用一些物理优化策略，比如常数折叠，举例如下：假设Where条件为a=5 and b=a。 可以将b=a进一步替换为b=5。Generator：最后Generator将执行计划翻译为可以被Trafodion执行器执行的物理执行计划。这里有一个重要步骤，优化标量表达式。所谓标量表达式，即其解析结果为标量的表达式，比如a+b+c等。Trafodion利用LLVM将多数标量表达式编译成运行时的机器代码，从而进一步提高了执行速度，类似JIT将部分javabytecode编译为机器指令以便加速java程序的执行。成本模块：Trafodion编译器还有一个经过长期调节和校准的cost成本模块，对各种SQL operator的成本进行估计。成本计算需要对存放在表内数据的分布情况有所了解，这是依赖对表数据进行扫描和采样统计计算出的直方图来支持。成本模块从直方图中得到数据的分布情况，计算出Cardinality。它还综合考虑了CPU，内存消耗，消息通讯和磁盘IO等条件为各个SQL操作算子计算出一个cost vector，提供比较准确的成本估计。以上各个系统组件协同工作，如上图所示，SQL语句经过parser和Normalizer的分析之后，输入优化器进行基于成本的优化；成本估计模块通过直方图获得数据分布，然后根据每个操作符自身的特点，进行成本估计，将成本输入优化器。根据这些输入，优化器最终生成一个最优的执行计划。 Trafodion执行器Trafodion的执行器是一个MPP构架的并发执行器。它的工作模式是数据驱动，因此一旦有数据就绪，就可以返回用户，而无需等待整个query完全结束执行，提高了用户响应速度。执行器由不同的SQL操作符组成，数据在各个操作符之间通过IPC流动，无需将中间计算结果保存到磁盘。如果中间数据太大，超过了RAM的容量，操作符会将数据overflow到磁盘上，因此Trafodion的query执行不受物理内存大小限制。 并发执
