Trafodion标准体系结构.docx

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内部运作原理。
读者还能够参考了解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 负责处理。类似OracleDedicated 模式。
当多个用户端请求连接时，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技术确保用户端能够继续实施连接。整个过程对用户端完全透明。
TrafodionHA机制很复杂，需要一篇单独文章来具体介绍，这里就不再展开叙述。

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采取自顶向下搜索策略，能够很方便地利用branchand-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到磁盘上，所以Trafodionquery实施不受物理内存大小限制。

并发实施
Trafodion实施器最大优点是极佳并发能力。多数SQL操作算子全部有并发实施能力，包含GROUPBY，JOIN，INSERT全部支持并发实施。
这里举一个小例子来说明Trafodion怎样并发实施一个简单sum(col1)聚集操作：master会在集群每个节点开启一个ESP进程，该进程负责对存放在该节点上数据分区进行sum聚集操作。多个ESP同时并发实施，将最终止果发还给master，由master汇总。对于聚集，Trafodion还能够将该操作下推到数据访问层实施，而不需要将数据分区每一行数据返回给ESP，由ESP逐一统计，而是由底层数据访问层进行统计操作，仅仅将聚集结果发给ESP，ESP再返回给master。

再看看TrafodionJoin。Trafodion支持全部join类型，内连接，外连接，non-equijoin，semi-join，全连接等等。在Join实现方法上，支持nestloop join，merge join和hashjoin。不管哪一个join算法，全部有并发实施能力。Trafodion支持多个并发join方法，由优化器选择最优一个。
首先介绍大家最熟悉两种并发join算法，即broadcast和repartition。
broadcast parallel join(hash join)
broadcast类型join中，一个表比较小，能够完全放入单个节点内存中。在这种情况下Trafodion会将小表广播到全部节点上。该并发实施方法用于hashjoin。每个节点上ESP将小表放入内存并建立hash表，然后次序读入本节点上大表分区，实施hashjoin操作。

repartition parallel join
repartition类型join中，两个表全部很大，无法放入单机内存。这种情况下，优化器生成实施计划会自动派生两层ESP，第一层读取数据后根据join column进行repartition操作，将两个Join表数据重新分区，将join column值相同数据聚集到同一个第二层ESP中实施join操作。然后，全部第二层ESP将Join结果返回master进行汇总。
以上两种在Hadoop应用中常常被使用到，被称为mapper join和reducer join。这两种并发join方法全部需要很大网络开销和内存开销。Trafodion优化器能够智能地在可能情况下选择以下多个并发join方法：

Matching PartitionsJoin
假如参与join两张表全部是根据join column分区，那么直接能够在各个节点ESP中实施当地join，因为肯定不需要其它节点上数据。这是最理想情况。

Inner Child ParallelAccess (for Nested Join)
这种方法只适适用于Nest Loop Join。TblA作为outer table；TblB作为inner table。TblA有两个分区，所以开启2个ESP，ESP1从TblA分区1逐行读取数据，然后逐一从TblB读取对应数据行进行连接操作；同理ESP2也做一样工作。这种类型join比broadcast方法节省内存开销，但多个ESP可能会竞争读取outer table。但能够支持非等值join。

TrafodionMPP并发实施器还有很多其它优异技术，比如HP专利MDAM，Adaptive Segmentation，Skewbuster等全部能够显著加速query实施效率降低延迟，从而达成subsecond实时响应。限于篇幅，MDAM等技术在这里就不展开叙述，Trafodion团体将陆续推出专题技术文章来单独介绍这些专利技术。

数据访问层
当实施器对底层数据库表进行读写时，就需要调用数据访问层服务。Trafodion数据全部存放在HBaseTable中。HBase本身支持对数据随机读写，不过不支持ACID事务处理。所以数据访问层必需和DTM(分布式事务管理器)相互配合，实现有事务保护读写。事务处理在下一个小结具体介绍。
DTM对HBaseAPI进行了封装，添加了必需事务处理支持。其它读写逻辑和原生HBase读写是一样。所以假如不考虑事务，数据访问层就是一个标准HBase用户端，经过HBaseclient API访问HBase。HBase是Trafodion数据访问和存放层关键。也是Trafodion区分于传统数据库最关键地方。借助于HBase，Trafodion也能够提供极佳水平扩展能力，同时含有很强可靠性，而这些能力是传统数据库所不含有。

Trafodion支持三种底层数据库表：Trafodion表，Hive表和HBase表。数据访问层需要负责对这三种存放类型访问控制。
Trafodion表
Trafodion表是用户用TrafodionDDL语句直接创建数据库表。在底层是一张HBase表，所以从Trafodion表到HBaseTable需要一定映射和编码。
映射
即怎样将Trafodion数据库表映射到HBase Table。我们考虑以下这个DDL创建Trafodion表：
create table sales.item(item_id int not null,
                          item_name char(10) ,
                          primary key (item_id));
首先是怎样将关系数据库schame+table_name映射到HBaseTable。这个映射标准很简单，即一个trafodion表在HBase中存放表名为。例子中item表在HBase中被映射为TRAFODION.SALES.ITEM这个HBaseTable。
其次是Trafodion表各个column怎样映射到HBase存放模式中。HBase表内部有ColumnFamily，每个ColumnFamily中能够有任意多ColumnQualifier，每一个行有一个rowkey，和一个timestamp。这四个维度定义了一个数据Cell。那么Trafodion二维表怎样映射到HBase这么存放模型中呢？
Trafodion将表主键列组合起来作为HBaserowkey。Column映射到HBasecolumnqualifier，而timestamp被用作事务管理时间戳。在现在release中，全部列数据全部存放在同一个ColumnFamily中，支持多ColumnFamily已经在Trafodion蓝图中，所以未来这个映射会有所改变。
编码
HBase存放数据是没有数据类型。Trafodion表却支持不一样SQL数据类型，比如CHAR型，即按字符串进行存放，”1”被编码为ASCII码0x41。假如SQL数据类型为INTEGER，在存放到HBase中时，Trafodion会直接写入二进制数0x00,0x00,0x00,0x01，占用4个byte；对应LONG型占8个byte。
Trafodion会自动进行类型处理，无需应用程序自己进行编解码工作。
数据分区
HBase会自动经过split技术对数据进行分区，不过一些情况下，比如时间序列数据次序插入情况下，大量数据读写会集中在某个单一Region上，从而使得单台RegionServer负载高于其它RegionServer。Trafodion支持slatedpartition功效，在创建表时候经过指定SALT关键字，Trafodion会自动为rowkey加入hash前缀，对表进行pre-split，确保平均地将数据分布在集群中。用户也能够不指定SALT关键字，而依靠底层HBase自动进行数据分区。

访问原生HBase表
Trafodion也能够直接访问原生HBase表，提供两种访问方法: Cell-Per-Row和Rowwise Per-Row。
经过Cell-Per-Row方法访问HBase表，每一个HBaseCell会作为SQL结果集中一行数据。经过Rowwise Per-Row模式访问，每一行HBase数据作为SQL结果集一行数据。
假设Table1有2行数据，每行两个Cell:[(row1, CF1:Col1, v1), (row1,CF1:Col2, v2) , (row2, CF1:Col1, d1), (row2,CF1:Col2, d2)]。
Cell-Per-Row访问：
select * from hbase.”_CELL_”.”table1”       
返回4行数据
value
(row1, CF1:Col1, v1)
(row1,CF1:Col2, v2)
(row2, CF1:Col1, d1)
(row2, CF1:Col2, d2)

经过Rowwise-Per-Row方法访问：
select * from hbase.”_ROW_”.”table1”;
返回两行数据
rowkey
value
row1
CF1:Col1:v1 CF1:Col2:v2
row2
CF1:Col1:d1 CF1:Col2:d2

具体使用方法能够参考TrafodionSQL Manual。

访问原生Hive表
Trafodion能够直接访问原生Hive表。采取特殊schema “hive”，用户直接使用SQL语句即可访问。比如
select * fromhive.hive.table1;
SQL引擎会识别”hive.hive”这个特殊schema，读取Hivemetastore获取table1元数据，然后直接经过libhdfs访问HDFS上Hive表数据。所以绕过了DTM。所以，对于原生Hive表访问，Trafodion不提供事务保护。

相关事务
Trafodion威尔士本意即事务，所以事务处理是Trafodion很关键一个方面。事务是一系列query组合。一个事务由若干操作组成，并由begin开始，由commit或abort结束。
Trafodion采取两阶段提交协议来确保分布式事务完整性。每个节点均运行TM进程，全部TM全部是peerto peer对等，而避免了单一事务管理器扩展性问题和SinglePoint of Failure问题。高并发情况下，全部活跃事务由不一样节点上TM分别管理，提供了很高扩展能力。
原生HBase本身仅支持单行ACID事务确保，Trafodion基于开源项目hbase-trx（）开发了现在版本Transactionon HBase机制。提供了跨行跨表ACID确保。hbase-trx采取MVCC机制，提供SnapShotIsolation事务隔离等级。原生hbase-trx仅支持HBase0.94，且采取了侵入式开发方法，大量修改了HBase基础代码。Trafodion团体吸收了hbase-trx基础思绪，利用HBase协处理器重新开发了hbase-trx，并支持HBase0.98版本。并改善了日志实现，能够确保多种failure情况下数据安全性。
现在TrafodionDTM团体正在和中国科学院计算所合作开发新Transactionon HBase算法Stateful-stateless Concurrency Control (SSCC)。相关SSCC原理，读者能够深入参考开源项目Domino:，估计将于TrafodionR1.2版本开始提供产品使用。SSCC提供比SnapShot Isolation更高级隔离等级，同时对无状态写操作有很高效支持，提供更高并发度。无状态写在web应用中很普遍，采取这一机制，Trafodion能够高效地为相关web应用提供强大支持。

小结
Trafodion是一个复杂大系统，一篇短文不管怎样也不可能完全说明其内部运作原理。笔者仅期望用最简单描述给各位读者一个大致概念，作为一个开源项目，Trafodion欢迎各位研读源代码，并共同改善。
经过本文，期望读者认同以下多个关键点：
·        Trafodion有一个成熟SQL编译器，能够进行基于成本优化
·        Trafodion有一个优异MPP并发实施引擎
·        Trafodion有一个创新Transaction实现
·        Trafodion有一个成熟ODBC/JDBC接入层
·        Trafodion构架在HBase之上，继承了全部HBase优点。为用户提供极佳水平扩展性
本文没有包含到技术话题还有很多，比如TrafodionHA实现，安全体系，NoSQL支持等。Trafodion团体会努力完善文档，也欢迎各位读者能够下载Trafodion源代码进行使用和学习，并贡献您了解和分析。