关于大数据:技术分享-Presto性能对比测试Kubernetes部署-VS-物理机部署

一、引言

Presto 是开源分布式 SQL 查问引擎，能够对从 GB 到 PB 级大小的数据源进行交互式剖析查问。Presto 反对 Hive、Cassandra、关系型数据库甚至专有数据存储等多种数据源，容许跨源查问。（详见参考 [1]）

图 1 Presto 档次架构图（图源 Presto 官网）

无处不在的 Presto
当今大规模的互联网公司都在应用 Presto。

Uber 将 Presto 用于 SQL 数据湖，每周有超过 7000 名沉闷用户，每天在超过 50PB 的 HDFS（Hadoop Distributed File System）数据上运行 50 万次查问。字节跳动对 Presto 进行了宽泛的利用，例如数据仓库、BI 工具、广告等。

字节跳动的 Presto 集群领有上万个计算外围，每天解决约 100 万次查问，涵盖 90% 以上的交互式查问。这极大地缩小了查问提早并节俭了大量计算资源。

Meta 公司（Facebook）应用 Presto 对多个外部数据存储进行交互式查问，包含 300PB 数据湖。每天有超过 1,000 名 Facebook 员工应用 Presto 运行 30,000 多个查问，均匀每个查问扫描超过 1 PB。

腾讯将 Presto 利用于外部的不同业务场景，包含微信领取、QQ、游戏等要害业务。日均解决数据量 PB 级，P90 查问耗时为 50s，全面晋升各业务数据实时剖析性能，无效助力业务增长。

阿里数据湖剖析集成了 Presto 的联结查问引擎能力，不仅让阿里云泛滥用户体验了大规模的 Serverless 云服务，也积攒了许多胜利的业务用例，比方日志数据分析和基因数据分析等，这些案例表明了 Presto 利用宽泛，剖析能力弱小。

图 2 各大互联网公司 Presto 性能展现数据局部起源 Presto 官网

Presto 零碎架构

Presto 集群由一个 Coordinator 和一个或多个 Worker 组成。Coordinator 负责接收、解析、布局和优化查问以及查问编排，Worker 负责查询处理。Presto 通过 Connector 适应底层不同类型的数据源，以便拜访各种数据源中的数据。如图 3 显示了 Presto 架构的简化视图（详见参考 [2]）。

图 3 Presto 架构图

传统形式部署 Presto 存在的问题

作为一个分布式架构的零碎，Presto 为数据查问和解决提供了高效便捷的办法。随着数据量增大，为了保证数据查询处理的效率，Presto 集群规模也要扩充。例如上文提到的 Uber、字节跳动和 Meta 等公司每天查问的数据量是 PB 级别，一个 Presto 集群的节点数量曾经上千。当数据量远超单机解决能力时，分布式架构相比于集中式架构的劣势就体现进去了，然而对于一个规模宏大的分布式集群，继续高效地解决数据，将会面临一系列的问题：

对于一个规模宏大、节点数量上千的 Presto 集群，如果没有自动化部署工具，采纳传统形式一个一个部署 Presto 节点，消耗的工夫是难以想象的。此外对于部署好的 Presto 集群依据业务进行调优，须要一直批改 Presto 节点的配置信息，依照传统形式一一批改配置信息，消耗的人力和工夫老本也是难以忍受的。
传统部署 Presto 集群，当其中某个节点产生故障时，无奈做到主动重启或者动静退出新的节点以维持集群数量，此时如果正好产生故障的是 Coordinator 节点，则整个集群将陷入瘫痪，导致服务不可用。
Presto 次要利用场景是即席查问，比方 Uber 和滴滴等网约车公司，查问业务顶峰时段次要在白天，早晨根本没有查问。如果早晨闲置的资源不能加以回收利用，将会产生很大的资源节约。此外，当业务高峰期的查问负载超过以后集群的承载能力时，如果不对集群立即按需扩容，也会对业务产生很大的影响。

应用 Kubernetes 部署 Presto 集群，将云原生与 Presto 相结合，借助 Kubernetes 便捷部署、自动化运维和弹性伸缩等长处，解决上述提到的一系列问题。

二、应用 Kubernetes 部署 Presto

Kubernetes，也被称为 K8s，是一个用于自动化部署、扩大和治理容器化应用程序的开源零碎，目前已被业界宽泛承受并失去了大规模的利用。Kubernetes 集群由管制立体和 node 组成。其中 node 上运行由 Kubernetes 所治理的容器化利用，也就是 Pod。管制立体治理集群中的 node 和 Pod，为集群提供故障转移和高可用性，而集群也会跨多个主机运行（详见参考 [3]）。

图 4 Kubernetes 部署 Presto 集群计划

如图 4 所示为本次测试所部署计划，Deployment 负责创立、更新、保护其所治理的所有 Pods。Presto Coordinator 和 Worker 过程别离运行在 Pod 中，针对 Presto 集群内 Coordinator 和 Worker 别离配置不同类型的 Deployment 来进行治理。Deployment 能够保障集群内可用 Pod 的数量，实现弹性伸缩，维持集群可用性和稳定性。

Configmap 用来存储配置文件，Coordinator 和 Worker 的配置信息别离通过 Configmap 进行存储，每次进行配置更改，只须要批改 Configmap 外面的配置信息，Coordinator 和 Worker 就会更新相应的配置信息。

Service 会对同一个服务的多个 Pod 进行聚合，向集群提供一个对立的入口地址，通过拜访 Service 的入口地址就能拜访到前面的 Pod 服务，实现负载平衡和服务发现。在 Kubernetes 部署的 Presto 集群中，Coordinator 将本人的地址注册到 Service，Worker 通过 Service 中的域名地址与 Coordinator 连贯，从而实现 Presto 集群的服务注册与发现。

在 Kubernetes 部署 Presto 计划中，Deployment 负责创立和治理 Pods，Configmap 负责存储配置信息，Service 负责服务注册与发现。Deployment、Configmap 和 Service 三类资源相互配合，保障了 Presto 集群继续高效工作。

Kubernetes 部署计划的长处

通过正当设置 Deployment、Configmap 和 Service 等资源对象，应用 Kubernetes 部署 Presto 集群，将 Kubernetes 的经营劣势与 Presto 技术劣势相结合：

• 便捷部署：在 Deployment 中设置 Coordinator 和 Worker 的正本数量，Configmap 设置配置信息，Service 设置 Presto 集群提供服务的入口地址。将上述三类资源对象提交到 Kubernetes 中即可实现 Presto 集群配置，比方设置 Worker 正本数量为 1000，提交之后即可创立 1000 个 Worker Pod，每一个节点的配置信息从 Configmap 文件中读取。只须要编写好资源对象文件，提交到 Kubernetes，即可创立 Presto 集群，后续能够通过批改 Configmap 文件更新各个节点的配置信息。通过 Kubernetes 部署 Presto 集群加重了配置、部署、治理和监控容器化 Presto 应用程序的累赘和复杂性。
  * 自动化运维：能够更不便地和 Prometheus 联合，通过 Prometheus 能够实现对整个集群的监控数据采集、存储、剖析以及可视化。无效监控 Presto 集群，当产生故障时能够针对性修复，从而维持集群稳固，保障高可用性。
• 弹性伸缩：当业务量激增，主动扩容 Presto Worker 节点，满足业务需要；当业务量处于低谷，主动缩容 Presto Worker 节点，节俭运行老本。

• Kubernetes 部署计划的问题

传统形式部署 Presto 集群是以物理机的形式运行，相比之下，在 Kubernetes 上部署 Presto 集群是以容器的形式运行。只管 Kubernetes 部署形式带来了很多长处，然而容器形式和物理机形式的性能差别依然未知，上面的测试将重点比照剖析两种不同部署形式的性能差别。

三、比照测试评估

测试介绍

基准测试的目标是比拟物理机的 Presto 集群和部署在 Kubernetes 的 Presto 集群的性能差别。因而，测试计划分为物理机计划和 Kubernetes 计划。Presto 物理机集群的构造是 1 个 Coordinator 和 5 个 Worker；Kubernetes 集群是在 6 个 node 之间调配了 1 个 Coordinator 和 5 个 Worker。在物理机集群中，用户间接通过 Presto 客户端向 Coordinator 发动查问申请，Coordinator 将任务分配给 Worker；如图 5 所示，在 Kubernetes 集群中，首先利用 6 个 node 部署 Presto 集群，Presto 客户端向 Kubernetes 中的 Coordinator 发动 SQL 查问，Coordinator 将任务分配给 Worker。

图 5 基准测试零碎架构图

TPC-DS

沿用目前业内的广泛测评办法，本次测试采纳 TPC-DS 作为 benchmark，它在多个广泛实用的商业场景根底上进行了建模，包含查问和数据保护等场景（详见参考 [4]），同时提供了一系列可能代表零碎性能的评估指标。简略来说，TPC-DS 应用了一个实在的商品批发业务场景来测试零碎性能。它构建了一个大型跨国批发公司的业务模型，模型里不仅蕴含了多家专卖店，同时还蕴含了线上销售业务，以及库存管理系统和促销零碎（详见参考 [5]）。因为 TPC-DS 是以实在场景为原型，在业内可能起到比拟好的测评成果，从而成为了以后 SQL 引擎测试最罕用的 benchmark（详见参考 [6]）。

集群配置

四、测试后果

为了保障本次测试的后果具备更加宽泛的意义，别离选取了 TPC-DS 不同的查问类型进行测试，包含即席查问、报告查问和迭代 OLAP 查问三种类型：

• 即席查问：这类查问次要的利用场景是通过查问来答复即时和特定的业务问题。即席查问和报告查问之间的次要区别在于系统管理员在布局即席查问时可用的预知水平无限。图表中为 q19, q42, q52, q55, q63, q68, q73, q98。
• 报告查问：定期执行的查问，这类查问次要是定期获取到无关企业财务和经营情况。图表中为 q3, q7, q27, q43, q53, q89。
• 迭代 OLAP 查问：OLAP 查问通常用于摸索和剖析业务数据以发现新的和有意义的关联关系和趋势。图表中为 q34, q46, q59, q79, q96, q48。

图 6 Kubernetes VS 物理机查问工夫比照图

如图 6 所示，纵坐标为查问工夫，单位是毫秒；横坐标为查问工作分类，图表中所显示的每个查问工作的工夫理论为 4 次查问工夫的平均值。能够看出，在不同的查问分类中，Kubernetes 部署的 Presto 集群的均匀查问工夫略微短于物理机部署，两者时间差根本放弃在几秒之间，思考到本次测试环境部署在云服务器上，不同时段应用云服务器，性能会有不同水平的偏差，几秒之间的性能稳定是能够容忍的。排除本次测试应用的云服务器产生的稳定，能够阐明 Kubernetes 部署与物理机部署在性能和效率上简直相差无几。所以针对不同类型的查问，Kubernetes 部署的 Presto 集群相比物理机部署在查问速度上并没有损耗，性能与效率简直没有损失。

五、论断

Kubernetes 部署 Presto 集群的计划加重了配置、部署、治理和监控容器化 Presto 应用程序的累赘和复杂性。实现了 Presto 集群的主动配置以及工作节点主动扩大，保障了 Presto Coordinator 的高可用，通过与 Prometheus 集成能够更好地实现集群监控。在 Kubernetes 上部署 Presto 集群将这两种技术的架构劣势和运维劣势联合在一起，相比于传统计划，在没有性能损耗的状况下，实现了对 Presto 集群的动静扩大、便捷部署治理和稳固保护。

六、问题排查

在性能比照测试的过程中，并非一帆风顺，后期测试中呈现了一些问题，导致 Kubernetes 部署的 Presto 集群性能无奈齐全开释，与物理机部署的 Presto 集群性能相差很多。现将测试过程中遇到的一系列问题以及相应的解决办法单开一节进行总结，不便读者在理论部署过程中遇到相似问题时能够失去借鉴与参考。

节点调配不均

Kubernetes 部署 Presto Pod（Master 或 Worker）时，如果应用了 Deployment 而非 DaemonSet 进行部署，会集中在几台物理机上（多个 Presto Pod 会同时运行在一台物理机上），有些物理机没有 Pod 运行。

图 7 Presto Pod 散布状况

解决办法：呈现这种景象的起因是 Presto Pod 所需的 CPU 和内存远远小于主机的下限，因而能够在一台物理机上运行多个 Presto Pod。造成的影响包含同一主机中的 Pod 相互抢占资源，导致效率降落，以及局部主机（没有 Presto Pod）闲置，造成资源节约。解决方案是能够通过 resources requests 和 limits 正当设置 Presto Pod 运行所需的资源，使其均匀分布到各个主机上。

资源利用率过低

与物理机相比，Kubernetes 部署的 Presto 无奈应用所有 CPU，只应用一个 CPU 核，每个节点的吞吐量无限，导致查问工夫显著变慢。

图 8 Kubernetes vs 物理机资源利用状况

解决办法：呈现这种景象的起因是没有设置 Presto Pod 调用主机资源的最大限度。最大限度可能是默认值，无奈达到主机的现实资源配额。影响是 Presto Pod 应用的资源重大受限，导致查问工作执行效率低下。解决的方法是正当设置 Presto Pod 能够调用的宿主机的最大资源限度。

针对上述两个问题，在 Kubernetes 中采纳 requests 和 limits 两种限度类型来对资源进行容器粒度的调配。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。requests 定义了对应容器须要的最小资源量。limits 定义了这个容器最大能够耗费的资源下限，避免适量耗费资源导致资源短缺甚至宕机。设置为 0 示意对应用的资源不做限度。如下图所示，设置 request 的 cpu 为 3，memory 为 6Gi，这样保障一个 pod 运行在一个节点上，解决了 Pod 在节点上调配不均的问题；设置 limit 的 cpu 为 8，memory 为 8Gi，为节点的最大资源配置，解决了性能受限的问题，同时也防止了应用资源超过节点最大资源引起的 Pod 解体重启问题。

图 9 资源配置

Presto 性能如何调优

解决办法：对于 Kubernetes 部署集群，须要设置 CpuCoreRequests、CpuCoreLimits、MemoryRequests 和 MemoryLimits。CpuCoreLimits 和 MemoryLimits 须要设置为宿主机配置的最大值，这样在执行工作时就不会受到限制。在此基础上，在 Presto 利用层面还须要设置一个正当的 query.max-memory-per-node。query.max-memory-per-node：查问能够在任何一台机器上应用的最大用户内存量，如果不进行设置，默认值为 jvm * 0.1。在本次测试中，如果单个查问在节点上的应用内存最大值过小，会导致查问无奈实现，倡议将内存值设置足够大，以防止查问失败的状况。

七、参考

[1] https://prestodb.io/
[2] R. Sethi et al., “Presto: SQL on Everything,” 2019 IEEE 35th International Conference on Data Engineering (ICDE), 2019, pp. 1802-1813, doi: 10.1109/ICDE.2019.00196.
[3] https://kubernetes.io/
[4] https://www.tpc.org/tpcds/
[5] https://zhuanlan.zhihu.com/p/…
[6] https://bbs.huaweicloud.com/b…

想要获取更多乏味有料的【流动信息】【技术文章】【大咖观点】，请关注 [[Alluxio 智库]](https://page.ma.scrmtech.com/…)：