一、引言

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/...)：