评估HTAP选项

本报告涵盖了为了支持工作负载（涵盖OLTP、运营、BI和分析），查询引擎面临的挑战的细节，这些细节也可以作为访问数据库引擎、查询引擎和存储引擎组合以及满足事务、运营、分析或混合工作负载需求的指南。以下评估选项实际上也是面临的挑战：

• 为了满足您的工作负载需求，查询引擎需要具备哪些功能？
• 为了满足您的工作负载需求，存储引擎需要具备哪些功能？查询引擎能与这些存储引擎进行良好集成吗？
• 对于您的应用程序而言，哪些数据模型至关重要？哪些存储引擎支持这些模型？单个查询引擎支持这些存储引擎吗？
• 哪些企业级能力对您来说很重要？查询引擎和存储引擎如何满足这些需求？

查询引擎的功能

工作负载的类型决定查询引擎需要哪些能力。本报告论述的是支持混合HTAP工作负载，以下为相关考虑事项：

数据结构 – 键支持、聚集、分区

• 查询引擎如何使用存储引擎提供的键入访问？
• 即使存储引擎仅支持单个键值，查询引擎支持多列键吗？
• 访问数据时，存储引擎支持按键对数据进行聚集、部分键入访问和前导键列谓词吗？
• 查询引擎如何处理谓词不在前导列的情况？

统计

• 查询引擎维护数据的统计信息吗？
• 查询引擎收集每列、多个键或连接列的基数吗？
• 统计为查询引擎提供有关数据倾斜的信息吗？
• 更新大表的统计信息需要多久？
• 添加新数据或旧数据老化时，查询引擎是否可以增量更新统计信息？

非前导或非键列谓词

• 即使键或索引的前导列没有谓词，查询引擎是否能有效地访问表格中的相关行？或总是需要全表扫描？
• 查询引擎如何确定跳跃扫描（skip scan）或MDAM比全表扫描更高效？
• 为了生成与一个数据访问、连接、聚合和并行度策略相关的有效计划，查询引擎如何使用键列、多键或连接列，以及非键列上的统计数据？
• 查询引擎支持列式存储引擎吗？
• 访问列式存储引擎时，为了尽快获取符合条件的行，查询引擎是否根据谓词基数的顺序访问列？

索引和物化视图

• 引擎支持哪些索引？如何应用这些索引？
• 索引可以是唯一的吗？
• 索引始终与基表一致吗？
• 支持唯一索引扫描（只访问索引，不访问源表）吗？
• 这些索引对更新有什么影响（尤其是添加了更多索引时）？
• 这些索引如何通过批量加载不断地进行更新？
• 支持物化视图吗？
• 能同步和异步维护物化视图吗？
• 维护物化视图的开销是多少？
• 在可行的情况下，查询引擎是否会自动重写查询以使用物化视图？
• 用户定义的物化视图是否支持查询重写？

并行度

• 查询引擎如何访问跨节点分区和节点上不同磁盘的数据？
• 查询引擎是否依赖于存储引擎进行分区？或为了并行访问这些分区，查询引擎提供并行基础架构吗？
• 如果查询引擎考虑串行和并行计划，它如何确定所需的并行度？
• 查询引擎能根据并行度仅使用所需的节点吗？

减少搜索空间

• 查询引擎使用哪些优化器技术？
• 它能为较大复杂的BI查询生成良好的计划、同时为较短运营查询进行快速编译吗？
• 运营查询使用了哪些查询计划缓存技术？
• 如何管理查询计划缓存？
• 优化器如何随着工作负载的变化而发展？
• 优化器能检测查询模式吗？

连接类型

• 支持的连接类型有哪些？
• 如何将连接用于不同的工作负载？
• 使用错误的连接类型有什么影响？如何避免这种影响？

数据流和访问

• 查询引擎如何处理复杂分析查询的大量并行数据流，同时提供对运营工作负载数据的直接快速访问？
• 哪些功能提高了分析工作负载和运营工作负载的效率（例如，预取数据）？

混合工作负载

• 能确定工作负载执行的优先级吗？
• 确定工作负载优先级的标准是什么？
• 能为不同服务级别的工作负载分配不同的资源吗？
• 查询优先级随着其占用更多资源而降低吗？
• 是否有防止饥饿机制，或是否有一种方式，能在恢复低优先级查询之前切换执行高优先级查询？

流式数据

• 查询引擎能直接处理流式数据吗？
• 针对流式数据需要支持哪些功能？例如，基于行和/或基于时间窗口功能？
• 处理流式数据的语法或API有哪些？这会将您锁定到这个查询引擎吗？

功能支持

• 数据库为运营、分析和所有其他工作负载提供了哪些功能？

集成查询引擎和存储引擎

在集成查询引擎和存储引擎之前，首先您要确定存储引擎需要提供哪些功能。然后，您需要评估查询引擎能否支持和扩展这些功能，以及查询引擎能否与存储引擎进行良好集成。以下问题不仅能确定它们（查询引擎或存储引擎，或它们的组合）是否能提供支持，而且确定它们能提供什么水平的支持。

统计

• 存储引擎维护数据的哪些统计信息？
• 通过这些统计信息，查询引擎能更快地生成直方图吗？
• 为了避免全表扫描来计算统计信息，存储引擎支持抽样吗？
• 为了统计信息的增量更新，存储引擎提供访问最近变动数据的方法吗？
• 为了设置更新数据的间隔时间，存储引擎为查询引擎维护更新计数器吗？

键结构

• 存储引擎支持键入访问吗？
• 如果它不是多列键，查询引擎会将它映射到多列键吗？
• 它能用于前导键列的范围访问吗？

分区

• 存储引擎如何跨磁盘和节点对数据进行分区？它支持哈希和/或范围分区、或这些分区的组合吗？
• 为了跨分区平衡负载、避免性能瓶颈，查询引擎需要对数据进行加盐（salt data）吗？
• 如何添加一个加盐键作为表格键最左边的列、并且避免全表扫描？
• 集群扩展或收缩时，存储引擎会重新分区吗？或由查询引擎执行？
• 达到重新平衡时，会对数据进行完全的读/写访问吗？
• 查询引擎如何将数据访问本地化，并避免节点之间的数据乱序？

数据类型支持

• 查询引擎和存储引擎支持哪些数据类型？它们如何映射？
• 可以对这些类型实施数值约束吗？
• 哪个引擎实施引用约束？
• 支持哪些字符集？
• 支持排序规则吗？
• 提供哪些压缩类型？
• 支持加密吗？

投影和选择

• 存储引擎或查询引擎完成投影？查询引擎和存储引擎对哪些谓词求值？
• 在哪对多列谓词、IN列表和具有ORs和ANDs的多个谓词求值？
• IN列表长度是多少？
• 存储引擎根据过滤效果的顺序对谓词求值吗？
• 谓词如何比较同一表格的不同列？
• 在哪对谓词中的复杂表达式（可能带有函数）求值？
• 存储引擎如何处理缺省值或缺失值？
• 为了提高性能，能使用技术（例如，矢量化、CPU LI、L2、L3缓存）减少串行化开销吗？

可扩展性

• 存储引擎是否支持操作的服务器端下推，例如，HBase的协处理器、或Cassandra的前触发器和后触发器？
• 查询引擎如何使用以上存储引擎提供的功能？

安全执行

• 查询引擎和存储引擎的安全框架是什么？它们如何映射到ANSI SQL安全执行？
• 查询引擎与底层Hadoop Kerberos安全模型集成吗？
• 查询引擎与安全框架（例如，Sentry或Ranger）集成吗？
• 查询引擎如何与安全日志、以及底层存储引擎和平台安全的SIEM功能集成？

事务管理

• 是否完全由存储引擎提供高可用复制、备份和恢复、以及多数据中心支持？或由查询引擎确保所有操作的一致性和完整性？
• 实施了什么级别的ACID或BASE事务支持？
• 事务支持如何在查询引擎和存储引擎之间进行集成，例如，预写日志和使用协处理器？事务是否具有良好的扩展性 – 所有事务工作负载跨多个事务管理器分配吗？
• 提供了多数据中心支持吗？
• 支持双活单主机复制或多主机复制吗？
• 事务处理的开销有多大？
• 提供在线备份和时间点恢复吗？

**元数据支持

• 如何将存储引擎的元数据（例如，表名、位置、分区、列和数据类型）映射到查询引擎的元数据？
• 如何通过查询引擎管理存储引擎的特定选项（例如，压缩、加密和列族）？
• 查询引擎为外部表提供事务支持、二级索引、视图、约束和物化视图吗？
• 如果能在查询引擎外部对外部表进行更改，那么查询引擎如何处理这些更改以及它们可能导致的差异？

性能、扩展和并发的注意事项

• 如果存储引擎有批量加载的能力，那么查询引擎如何保证多次加载数据的事务一致性？
• 存储引擎是否提供行集（rowset）插入和读取，来同时处理大量行？
• 存储引擎提供哪些类型的快速扫描选项 – 快照扫描、预取和其他类型？
• 存储引擎为查询引擎的并行操作提供了简单的集成方法吗？
• 存储引擎支持哪些级别的并发和混合工作负载能力？

错误处理

• 如何记录存储引擎和查询引擎的错误？
• 查询引擎如何将存储引擎中的错误映射到有用的错误信息和解决方法选项？

其他操作

• 为了最小化运营和性能影响，查询引擎如何处理存储引擎特定运营情况（例如，压缩或拆分）？

数据模型支持

以下为评估数据模型支持的注意事项：

运营与分析数据模型

• 规范化数据模型能很好地支持运营工作负载吗？
• 星型和雪花数据模型能很好地支持分析工作负载吗？

NoSQL数据模型

• 查询引擎支持哪些存储引擎数据模型 – 键值、有序键值、Bigtable、文档、全文检索、图形和关系型数据模型？
• 查询引擎API能在多大程度上覆盖存储引擎API？
• 为了支持存储引擎API，查询引擎能在多大程度上映射和/或扩展其API？

企业级能力

以下是评估企业级能力的考虑事项：

高可用性

• 提供多长的正常运行时间（99.99％-99.999％）？
• 能在线升级底层OS（有可用于读取和写入的数据）吗？
• 能在线升级底层文件系统（例如，Hadoop分布式文件系统）吗？
• 能在线升级底层存储引擎吗？
• 能在线升级查询引擎吗？
• 为了适应节点和/或磁盘的扩容和收缩，能在线重新分配数据吗？
• 能在线更改表格定义吗？例如，更改所有列数据类型，添加、删除、重命名列？
• 能在线创建和删除二级索引？
• 支持在线备份——完全备份和增量备份吗？

可管理性

• 支持哪些管理功能（更多信息，请参阅图1-9）？
• 支持混合负载的管理吗（即通过每秒的事务来分析运营性能，根据复杂的查询和其结果来衡量分析性能）？
• 与分析工作负载相反，在运营工作负载上收集指标的开销是多少？
• 能设置收集统计信息的间隔来减少开销吗？
• 能否根据工作负载的优先级和/或资源分配，使工作负载达到服务级别目标？
• 能否提供从应用到查询引擎、再到存储引擎的端到端的事务和查询的详细统计信息？
• 为查询提供操作符（执行计划）的度量信息吗？
• 为所有工作负载提供到分区级别的度量信息吗？
• 能否提供足够的信息来找出倾斜或瓶颈的位置？
• 如何与YARN或Mesos集成？

结论

本报告总结了一些使用单一查询引擎来同时满足运营和分析负载可能遇到的挑战。目前而言，即使未满足HTAP的所有要求，查询引擎也能够满足客户的混合工作负载需求。该报告还阐述了您应该寻找什么，以及在使用终极数据库处理所有工作负载（运营和分析）时，您可能需要做出的调整。
 

关于作者

Rohit Jain是Esgyn的联合创始人和首席技术官。Esgyn是一家开源数据库公司，致力于构建融合型分布式大数据平台。2015年，惠普将Apache Trafodion（企业级大数据MPP SQL数据库）捐赠给了Apache软件基金会。在Apache Trafodion的基础上，EsygnDB的愿景是建立一个能处理任何数据、任何大小和任何工作负载的融合型分布式大数据平台。在过去的28年中，作为一个资深数据库专家，Rohit在应用程序和数据库开发领域曾为Tandem、Compaq和Hewlett-Packard工作过。他经验丰富，主要涉及在线事务处理、运营数据存储、数据集市、企业数据仓库、BI和大规模分布式并行系统的高级分析。