Apache Hadoop™生态系统的优势之一就是能够整合不同的技术，解决各种大数据问题。要实现良好的整合，就要注意易用性以及数据交换的速度和效率。

EsgynDB™是Esgyn公司的web-scale企业级SQL-on- Apache Hadoop™解决方案，现已支持与Apache ORC™文件的紧密集成。在本文中，我将介绍结合EsgynDB和ORC文件所带来的好处，然后探讨该集成解决的两个重要用例。

EsgynDB™是基于Apache TrafodionTM（正在孵化）的高可扩展SQL引擎。Apache TrafodionTM是高可扩展的企业级数据库引擎，HP在2014年将其开源。Apache TrafodionTM承载了联机事务处理和数据仓库20多年的研发成果，具有非常成熟的查询优化和运行时技术。

所有的数据库引擎都依赖于存储表的存储引擎层。自2015年诞生以来，EsgynDB就使用Apache HBaseTM作为存储引擎。同时，逐渐增加对其他存储引擎的支持（例如，Apache HiveTM TextFile和SequenceFile）。现在，还新增了对ORC文件的支持。

ORC是Hive项目的一个产物。由于通过编写Java程序执行MapReduce无法高效地进行即席查询处理（从开发者或用户的角度），Hive应运而生。Hive通过自己的方式执行SQL语言，消除了Java编程的繁琐性。

最初，Hive使用简单的文本文件作为其存储层。但很快就发现，创建优化格式的文件可以提高性能。然后，产生了RC文件，接着进一步优化为ORC。

ORC旨在进行分析型查询处理，是一种列式存储。一个ORC文件分为各个stripe，每个stripe都包含一个行集。在一个stripe中，各列分开存储。每列都根据适合其数据类型的技术进行压缩。例如，整型列使用行程长度（run-length）编码压缩，字符串列使用字典技术（dictionary）。通过索引结构，可以跳过某些值。每个stripe都知道各列的最小值和最大值，因此某些查询可以跳过一些stripe。

连接ORC文件的库支持谓词下推，这是一项长期用于高效查询处理的技术，使逻辑尽可能地靠近数据。

ORC还支持分区，分区计划与其他的Hive文件格式相同：将一个或多个列定义为“PARTITIONED BY”列。为分区列每个不同的值创建一个ORC文件。列值存储在文件名为给定分区的文件中。

这些功能（列式存储、row striping、复杂压缩、谓词下推、分区）都使分析型查询处理变得高效：成熟的查询引擎可以快速地仅读取需要的行和列。

EsgynDB就是这样的查询引擎。EsgynDB继承了很多支持先进并行查询的数据库引擎，可以处理分区（例如，HBase存储引擎）。通过对ORC的支持，添加了代码，利用ORC分区结构在编译和运行时消除不必要的分区访问。此外，EsgynDB还可以并行处理其余的分区。EsgynDB的前身产品支持具有谓词下推的存储引擎。因此，向ORC添加谓词下推是Esgyn架构的简单扩展。EsgynDB已经具有了只选择需要的列的概念，所以利用ORC的列式结构可以很容易地将信息传递到ORC层。压缩是EsgynDB可以利用的功能；ORC客户只需考虑受压缩影响的ORC访问成本计算。

简而言之，EsgynDB和ORC文件可以实现自然、轻松的集成。

您可能会问：为什么不使用Hive查询引擎？您当然可以使用Hive查询引擎，但是EsgynDB引擎的成熟性更高。其一，Hive不是标准的SQL实现。其语法是非标准的，会显示很多成熟引擎不应显示的细节，降低了可移植性。而且，其语法是不完善的，缺少很多ANSI功能。其二，Hive的运行时引擎和优化器的性能还有很大的改进空间。

最近，Esgyn运行了一个内部的基准测试，使用TPC-DS数据库和查询集测试基准，比较EsgynDB和Hive在ORC文件上的性能。EsgynDB可以运行所有的99个查询，只需进行ANSI和TPC-DS都允许的少量修改，甚至无需修改。Hive只能运行65个查询。在这65个查询的性能上，EsgynDB的速度是Hive的5倍。

以上，我介绍了集成EsgynDB和ORC的一些好处。现在，我想要介绍两个相关的用例：混合事务/分析处理（HTAP）和多温度数据。

维基百科将HTAP定义为“单个数据库同时支持OLTP和OLAP的能力”。HTAP的想法是要在分析型处理的平台上同时支持事务型工作负载。这个问题的棘手之处在于存储引擎或数据库引擎本身。

在存储引擎方面，要支持这样的混合型工作负载，就要为不同的工作选择合适的工具。

对于事务型工作负载，您需要一个在小型访问方面（一次几行）高度优化的存储引擎。您要能够从一个或多个大表中插入、修改或获取几行数据，这就需要有一种高效的索引结构。您还要能够使用ACID事务完成此类操作，因此还需要一个集成了事务引擎的键值存储。EsgynDB基于的Apache Trafodion就可以做到这一点：Trafodion表存储于HBase，Trafodion事务引擎通过HBase协处理器集成于HBase Region Server进程。

对于分析型工作负载，您需要一个能够根据行或列，有效地访问大表中大量数据的存储引擎。正如我之前所述，ORC可以满足这一条件。

需要注意的是，在多合一存储引擎方面，已经有了一些尝试。目前，这些尝试在事务和/或分析的效率方面都有所下降。如果出现了成功的方法，EsgynDB将随时利用这种引擎。

在数据库引擎自身，如果只有几行被直接访问，则需要一个支持快速路径的查询引擎以及能够有效处理大量行的分析路径。此外，还需要一个查询优化器，用于根据查询特征选择合适的路径。得益于20多年的研发和前期产品，EsgynDB可以非常好地支持这些方面。

因此，可以将事务型数据存储于HBase，将分析型数据存储于ORC，并使用EsgynDB对这两种数据进行查询和管理。另外，EsgynDB可以将两者结合起来：查询既可以引用Trafodion（和本地HBase）表，也可以引用ORC表。

“多温度数据”是指，既有“热数据”（被频繁访问的数据）也有“冷数据”（很少被访问的数据）的数据集。通常，“冷数据”的数据量会大大超过热数据。例如，会随着时间的推移逐渐累积的事务型数据。如果是当天销售数据的SALES表，则该表可能就是“热”的；如果是上周、上个月甚至去年销售数据的SALES表，则该表可能就是“冷”的。另一个例子是log数据。最近事件的log数据会被频繁引用，而过去事件的log数据仅用于说明或展现长期趋势的查询。

如果要支持“热数据”，就需要一个能够将“热数据”缓存在内存中的存储引擎。HBase能够做到这一点，如果要支持“冷数据”，就需要一个能够根据“温度”（通常使用日期字段）存储大量数据的存储引擎。如果要同时支持这两种数据，就需要一种有效的机制，将变冷的数据增量迁移至另一个存储引擎；还需要一个能够识别“温度”的查询引擎，根据数据的“温度”，以优化的方式访问数据。

HBase存储引擎非常适合存储“热数据”。HBase将最新和被频繁访问的数据存储在内存memstore中。随着数据逐渐变冷，HBase将变冷的数据作为排序的日志文件写出，并通过后台处理进行结合和压缩。随着数据进一步变冷，可以通过EsgynDB将这些数据从HBase迁移至ORC（可以使用INSERT/SELECT语句，或使用UPSERT USING LOAD等变量）。EsgynDB引擎生成具有适当并行度的计划，快速、有效地迁移数据。

从应用程序的角度来看，可以在EsgynDB中定义一个同时包含“热数据”和“冷数据”的视图。这样，终端用户可以无需考虑数据的存储引擎，简便地查询数据。

Apache Hadoop的成功是由于为不同的工作集成了适当的工具。EsgynDB紧密集成了HBase和ORC，成为了Apache Hadoop中事务型和分析型工作负载的首选查询引擎。

若要了解更多信息，请随时与我取得联系。