实时数仓入门训练营：Hologres性能调优实践

简介： 《实时数仓入门训练营》由阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操应用，7 门精品课程帮助你 5 天时间从小白成长为大牛！

视频链接:https://developer.aliyun.com/learning/course/807/detail/13889

内容简要：

一、Hologres建表最佳实践
二、Hologres性能问题分析与优化

一、Hologres建表最佳实践

（一）建表优化的必要性

为什么Hologres建表优化非常重要？

首先，对于整个的查询性能以及写入性能来讲，一个好的建表跟一个比较差的建表，性能上面有非常大的区别。

其次，建表优化需要尽早做，是因为Hologres在改 DDL的同时，有可能需要用户重复进行一些数据导入，这种重复的工作使得我们希望尽早完成建表优化。

最后，一个好的建表对于用户的数据存储成本也有一定的帮助。如果建表做得不恰当，可能导致建一些不必要的Index，然后导致数据多了一些冗余的存储，从而提升了成本。

因此，建表优化是非常重要的，这也是把它作为本文第一部分的原因。

（二）业务建模是性能优化的前提

说完建表的重要性之后，我们再看建表优化之前要去做整个业务建模的优化。在考虑使用Hologres的同时，我们要知道通过Hologres能够解决什么样的业务问题，以及通过什么样的方式解决。

Hologres本身是一个HASP产品，在使用Hologres的同时就需要跟业务场景结合，我们要知道这个场景到底是分析场景还是在线服务场景。如果是一个分析型，就用Hologres的列存比较友好，如果是一个在线服务型场景，就用行存比较友好，这些是跟业务场景相关的。

第二个是要能够结合Hologres本身的产品优势。Hologres是一个在线服务以及交互式分析的产品，它并不适合ETL以及海量数据拖取的场景。因此，在把业务往Hologres上面搬的时候，不能搬所有的场景，否则可能导致Hologres做一些不太适合本身的事情，信任就会不太好。

第三个是需要做一些取舍。为了达到预期的性能，可能需要做一些类似预计算或者数据加工的提前操作，减少后续计算复杂度，加快计算速度。

以上这些都跟预先数据建模以及整个业务期望息息相关。

（三）存储方式的选择

做完以上准备工作之后，我们需要进行Hologres管理存储方式的选择。

Hologres本身支持两种存储方式，分别是行存和列存。

行存主要的应用场景是对主键进行高QPS查询，并且当我们表比较宽的时候，一次查询会读取大量列，这种场景适用Hologres是非常适合的。

除此之外， Blink的维表查询必须是用行存，因为一般情况下Blink的维表是高QPS、基于Key的查询，列存没有办法扛住这么高的压力。

列存适用于复杂的交互式分析查询，比如一个查询里面，它有关联、聚合等等各种各样的复杂计算。同时它覆盖的场景非常多，包括过滤、聚合等，列存是比较通用的存储方式。

行存主要适用于在线服务类的场景，列存主要适用于分析型的场景，这是两个存储方式的选择区别。

（四）优化Shard数

Shard_count: Shard实现了物理分表的效果，多个Shard并行服务查询。
增加Shard可以增加查询的分布式并行度，更多Shard不一定查询更快，也会带来并发查询的调度开销。

说完存储方式，接下来我们看Shard数。

Hologres在存储的时候，是把物理表分成一个个Shard存储，每个表会按照一定的分布方式分布到所有的物理节点上面，然后每个Shard可以去并发进行查询，Shard数越多，相当于整个查询的并发度越高。但是Shard数也不是越多越好，因为它本身有一些额外的开销，所以我们需要根据整个查表的数据量以及查询复杂度来设计每个表的Shard数。

在集群扩容的时候，比如我们原本是128 Core的实例，扩容到256 Core之后，我们需要对整个Shard数进行一定的调整，这样才能享受扩容带来的性能提升。

因为我们整个并发度是在Shard数上面，假如实例扩容了，但是Shard数没变，那么相当于整个计算的并发度没变，这种情况会导致虽然扩容了，但是查询性能没有提升。

一般情况下，我们会建议用户将Shard数设置成跟实例规格差不多的数量，比如一个64 Core的，Shard数设成40或64这种比较贴近于实例规格的数量。当规格往上涨之后，我们希望Shard数也能往上涨，从而提高整个查询的并发度。

（五）优化Distribution Key

然后说完Shard数之后，我们再看一下Hologres里面非常重要的Distribution Key，它主要是用来决定数据如何分到每个Shard上面。

Distribution_key:均衡地分发数据到多个Shard中，令查询负载更均衡，查询时直接定位到对应Shard。
如果创建了Primary Key索引（用于数据更新），默认为distribution_key， Distribution_key如果为空，默认是Random，Distribution_key需是Primary Key的子集。

一个好的Distribution Key设计，首先要求用户的数据在Distribution Key上划分比较均匀。

比如用户ID或者是商品宝贝ID，一般情况下Key只有一个，所以它是非常均匀的，是用来作为Distribution Key非常好的例子。但是像年龄或者性别这种就不太适合作为Distrib