关于云计算:云上-OLAP-引擎查询性能评估框架设计与实现

作者：南京大学顾荣、吴侗雨

背景

私有云是一种为用户提供经济不便的计算资源的平台。随着云计算技术的疾速倒退，以及大数据查问需要的日益减少，很多私有云的云计算利用市场中，呈现了越来越多云上 OLAP 引擎服务。为了可能依据本人的业务需要抉择适合的 OLAP 引擎，并通过适合的配置使引擎在最佳状态运行，用户须要对以后应用的查问引擎性能进行评估。

以后 OLAP 引擎性能评估框架在云上部署应用时面临三个次要挑战：

1、对云环境适应能力弱。传统性能评估框架诞生时，尚未具备云上特有的 PaaS、IaaS、SaaS 个性，也不具备对存算拆散的适配反对。应用云上 OLAP 时，须要充分利用云计算个性剖析 OLAP 引擎性能。
2、不具备简单工作负载的复现能力。工作负载由数据集、查问集、查问序列组成。传统的性能评估框架通常采纳固定的数据集和查问级，查问序列也次要以线性序列为主。古代 OLAP 查问场景的复杂化，对特定场景下的数据集和查问集的特色刻画、高并发简单场景反对等，提出了更高的要求。
3、难以全面评估查问性能与上云老本。传统评估体系（如 TPC-H、TPC-DS）不体现老本因素，而在云上资源近乎有限的大环境里，不思考老本的评估会造成很大的偏见，甚至得出谬误的论断。云计算具备自定义租用服务器规模的个性，因而云上老本是可变、可设置的，其单价也随工夫稳定。用户既心愿 OLAP 查问能以最快的速度被执行，又心愿能尽可能节省成本，因而须要性能评估框架全面评估查问性能与上云老本，依据用户需要提供最具性价比的云服务器与 OLAP 引擎搭配形式。

针对上述问题，南京大学顾荣老师、吴侗雨博士等人与 Apache Kylin 社区团队联结钻研，设计开发一套云上 OLAP 引擎查问性能评估框架，名为 Raven。

Raven 被设计来帮忙用户答复一些 OLAP 引擎上云面临的理论而又重要的问题：

- 对于一份实在生产数据中的实在工作负载（数据载入 + 查问），哪个 OLAP 引擎在云上运行的 IT 老本更低？
- 给定一个查问速度的指标，在能达成的速度指标的前提下，哪个 OLAP 引擎在云上能给出更低的 IT 老本？
- 再加上思考数据载入速度的因素，状况又会如何？

本文将介绍本团队在设计与实现 Raven 时遇到的问题、对应的解决方案、以及以后的初步研究成果。

适应云架构的性能评估框架设计

OLAP 引擎查问性能评估框架适配云架构时，实际上是在适配云上的 PaaS、IaaS、SaaS 个性。具体而言，云服务器的很多性能都以服务的形式出现给用户，用户只须要调用对应服务的接口，即可实现不同的目标，如云服务器创立、文件操作、性能指标获取、应用程序执行等。在文件操作中，因为云服务器采纳计算存储拆散的架构，一些数据可能须要通过服务从近程的云存储服务上拉取。

联合上述需要，Raven 的框架如图 1 所示。其执行步骤如下：

1、用户输出性能测试配置信息，触发性能测试启动模块，该模块负责依据用户配置创立启动云上 OLAP 性能测试所需的云服务器和计算环境。
2、性能测试启动模块将工作负载、数据集、性能指标、引擎参数等信息传递给配置管制与散发模块，该模块负责将上述信息散发到对应的服务接口或模块上。
3、配置管制与散发模块触发工作负载执行模块，工作负载执行模块启动配置好的 OLAP 引擎，并依据工作负载设置随工夫向 OLAP 引擎发送查问申请。
4、OLAP 引擎向本地存储或云存储拉取数据集，执行查问。查问执行过程中，工作负载执行模块记录查问开始和完结的工夫戳，并启动资源管理服务，监控 OLAP 引擎查问期间的性能指标。查问完结时，工作负载执行模块将工夫戳和性能指标信息输入到云存储中。
5、启动性能剖析评分模块，从近程云存储中拉取工夫戳和性能指标信息，导入用户自定义的评分模型，失去最终的性能评估后果。

上述设计的长处在于：

1、充分利用可自定义的云服务器数量和配置，容许用户自定义其心愿创立的集群环境。
2、反对向近程的云存储服务读写数据，适应云环境的存算拆散架构。
3、应用云服务提供商的资源管理服务，得以获取大量系统资源应用情况的信息。
4、反对可插拔的引擎接口，用户可任意指定其所需测试的 OLAP 引擎及其配置。

理论应用时，用户的输出以一个.yaml 文件出现，可仿照如下格局：

engine: kylin
workload: tpc-h
test_plan: one-pass
metrics: all

用户须要的云服务器数量、每台机器的配置、不同的引擎等，均可通过 JSON 文件配置。

基于事件和工夫戳的工作负载设计

传统的 OLAP 查问引擎通常采纳固定的数据集和查问集，并执行一系列的查问，查看 OLAP 引擎的查问性能。然而，以后很多行业的工作负载正更加简单。

1、越来越多的企业意识到本身数据及业务具备鲜明特征，心愿可能在给定的数据特色下获得最佳的 OLAP 查问计划。
2、除了传统的 OLAP 查问外，越来越多的预计算技术，如 ETL、索引、Kylin 的 Cube 等，亟待纳入到 OLAP 引擎性能的考查中。
3、数据量的快速增长使得高并发查问、QPS 可变查问的场景越来越多，传统的线性查询方法很难上述新场景进行精确评估。

Raven 应用了一种基于工夫线的事件机制形容简单的 OLAP 工作场景。该机制下，一个工作负载由多个阶段形成，一个阶段由多个事件形成。在工夫线上，一个工作负载被形容为若干个阶段的程序执行。每个阶段分为线上阶段和线下阶段两种：线上阶段执行理论的查问申请，线下阶段执行预计算等操作。事件是对工作负载中每一个原子执行单元的形象，能够是查问申请、shell 命令，或用 Python 等编程语言编写的脚本。

Raven 的工作负载如图 2 所示。其执行步骤如下：

1、启动第一个阶段，加载工作负载配置、引擎配置等；
2、当事件的计时器被触发时，将工夫事件生成控制器，读取该事件对应的查问语句或脚本内容，进入事件执行队列，期待执行。
3、出事件执行队列后，进入事件执行控制器，开启线程执行钩子函数，与 OLAP 引擎或命令行执行交互操作，并期待响应，失去响应后将事件插入到资源收集队列中。
4、出资源收集队列后，进入事件资源收集控制器，将操作的工夫戳信息输入到云存储服务上。
5、当该阶段内所有工夫实现后，启动下一个阶段，而后按程序执行每个阶段，直到整个工作负载完结。

上述设计的长处在于：

1、反对自定义数据集和查问集，容许用户充分利用其业务特点进行性能评估。
2、反对预计算，容许用户评估预计算和理论查问的整体性能。
3、带工夫戳的执行办法和线程管理策略，反对高并发查问，容许模仿 QPS 随工夫稳定的工作负载。

举个例子，能够应用如下的 .yaml 配置文件，在 AWS 上启动一主四从的 EC2 集群，并部署 Presto 引擎，指定数据集为 SSB（SF=100）且工作负载满足泊松散布（
），工作负载持续时间为 600 秒：

Cloud:
Name: AWS
Description: Amazon Web Service.
Properties:

Region: ap-southeast-1
Ec2KeyName: key_raven
MasterInstaceCount: 1
MasterInstanceType: m5.xlarge
CoreInstanceCount: 4
CoreInstanceType: m5.4xlarge

Engine:
Name: presto
Description: Presto.
Properties:

host: localhost
port: 8080
user: hive
catalog: hive
concurrency: 1

Testplan:
Name: Timeline template.
Properties:

Type: Timeline
Path: config/testplan/template/timeline_template.yaml

Workload:
Name: SSB
Type: QPS
Parameters:

database: ssb_100
distribution: poisson
duration: 600
lam: 3.0

Raven 预置了一些常见工作负载供用户应用，如均匀分布、突发高并发散布等。

基于自定义多元函数的性能评估模型

在性能评估方面，云上机器的一个特点是大小、配置可自定义调节。因而，如果只思考查问性能，实践上能够通过租用大量的高性能设施晋升性能。然而，这样也会造成云上计算成本飙升。因而，须要一套机制实现性能和老本的均衡和综合思考。

Raven 的性能评估办法是高度自定义的，容许用户依据能够获取的参数指标，应用函数表达式组合起来，失去一个评估分数。

Raven 中可获取的参数指标次要有以下几类：

1、查问质量指标：包含所有查问的总查问工夫、均匀查问工夫、查问工夫 95% 分位数、最大查问工夫；
2、资源应用效率：内存和 CPU 的均匀使用率、负载平衡、资源占用率超过 90% 的工夫占总工夫的比例；
3、云上金钱老本：可间接通过云服务商提供的应用服务获取，次要蕴含四个局部的开销：存储、计算、服务调用、网络传输。

Raven 给出的评分是绝对的，只能在雷同模型的评分之间进行比拟。性能评估得分是云上老本和云上开销的乘积，评分越低，OLAP 引擎的性能越好。云上开销可应用线性模型，对上述参数赋予权重计算；也可应用非线性模型，将上述参数代入到一个函数表达式中。

Raven 也为用户提供了一系列模板函数：

这里咱们联合回顾下前文提出用户须要关注的几个际问题，不难看出，估算优先模型次要用于评估和答复：哪个 OLAP 引擎在云上运行的 IT 老本更低？速度优先模型、查问效率模型、查问阻塞模型次要用于评估和答复：在满足不同查问响应等束缚的状况下，哪个 OLAP 引擎的云上运行老本更低？综合模型则是通过设置不同权重来综合思考老本估算和查问响应效率的评估 OLAP 引擎的云上性能模型。

实现与成果验证

咱们在亚马逊 AWS 上实现了 Raven 的上述设计，并应用该性能评估框架执行 OLAP 引擎，查看不同引擎的查问成果。

图 3：不同引擎在不同评分模型下，运行平均查问 10 分钟的性能评分

图 4：在 Presto 和 Kylin 上运行突发高并发散布的性能评分

从图 3 中能够看出，运行平均查问时，Athena 和 Kylin 是较好的解决方案。然而，应用不同模型会失去不同的评估论断。当综合思考查问速度的云上老本时，因为 Athena 间接通过调用服务执行查问，因而云上老本较低，评分也更低。然而，当优先思考速度时，因为 Kylin 应用预计算技术实现了高速查问，因而应用速度优先模型时，Kylin 的评分更低。

从图 4 能够看出，运行突发高并发散布时，若采纳查问阻塞模型，随着同时输出的查问数量减少，Presto 的性能评分随查问数量减少线性增长；然而，Kylin 并未受到查问数量减少的影响，性能评分保持稳定。这是因为 Kylin 的预计算技术晋升了计算效率，当查问大量涌入时，Kylin 能以更高的效率解决这些查问，缩小查问在队列中的阻塞，使性能评分更为杰出。当然，如果用户集中的查问数量不大，Presto 的性能评分更有劣势，因为其没有预计算的相干开销。

将来瞻望

将来的钻研次要思考以下方面：

1、利用实现更多引擎，尝试兼容云原生引擎，以进行性能评估。
2、优化工作负载的表达形式，使用户能够依据本人的业务需要，更容易地开发出多样化、具代表性的工作负载。
3、造成更多标准化的评分模型，供不同工作负载之间的横向比照。
4、联合以后评分后果，进一步剖析不同 OLAP 引擎的性能优劣。