全部产品
Search
文档中心

实时数仓Hologres:Table Group设置最佳实践

更新时间:Dec 26, 2023

本文为您介绍Hologres中Table Group和Shard Count选定的基本原则、适用场景、设置策略以及常见问题,以助您获取更优的查询性能。

实例规格推荐

在实践过程中存在数据量可预估,最适宜的Shard数区间应该设置为多少的问题,由于最适宜Shard数不仅和数据存储量有关,还和实际访问频率、实际数据访问量、计算负载的类型(点查、分析等)、写入吞吐、Table Group上表的个数等因素有关,该问题无法给出准确答案。您可参见下表中根据数据量估算的所需Shard数和实例规格的推荐数,选择适合您的参数配置。

数据总规模

推荐Shard数

推荐规格

4000万行以下

10~20

32Core以上

4000万行~4亿行

20~40

64Core以上

4亿行~40亿行

40~80

128Core以上

40亿行~400亿行

80~240

256Core以上,考虑创建新的Table Group

400亿行~4000亿行

160~400

512Core以上,通常配置多个Table Group

说明
  • 上表根据数据量估算的所需Shard数和实例规格的推荐数不是唯一标准,小数据量的表也可以放在多的Shard Count之上,大数据量的表也可以放在单个Shard上。请您根据实际业务场景选择一个合适的Shard Count,既满足有较高的并发度,带来更高计算效率,又满足数据较集中,从而避免不必要的Shuffle开销。

  • 建议一个Table Group下不要超过10000张表(包括分区子表,不包括外部表),同一个Table Group中的表数量过多,会导致元数据堆积,从而降低DDL操作的执行速度。

您可以根据以下Table Group规划的最佳实践,来决定是否需要新建以及如何放置Table Group。

  • 规划一:使用默认Table Group

    如果您使用Hologres满足下列条件,建议您直接使用默认Table Group即可。Hologres实例升配或降配后,默认Table Group的Shard数不会变,因此可以通过如下命令语句,查看Table Group的Shard数。

    SELECT * FROM hologres.hg_table_group_properties;
    
    --结果示例 
     tablegroup_name | property_key  | property_value
    -----------------+---------------+----------------
     test_tg_default | is_default_tg | 1
     test_tg_default | shard_count   | 40
     test_tg_default | tg_version    | 1
     test_tg_default | table_num     | 1
    (4 rows)
    • 数据量:

      当前默认Table Group的Shard数,符合目前数据量大小的需求。可以使用默认Table Group直接建表。

    • 总体规模:

      全部表的数据量规模总和可控,可预估,使用方式没有大的变化。

    • Local Join:

      需要与已在默认Table Group的表,进行高效的Local Join。

  • 规划二:新建Table Group

    如果默认Table Group不能满足您的需求,那么您可能需要多个Table Group。通常在如下条件下,在您的实例中可能需要多个Table Group:

    • 数据量

      已有Table Group的Shard数不适合当前表的预估数据量,例如,数据量小的表一般不适合放在大Table Group中,会造成小文件太多,IO开销变大,数据量大的表一般也不适合放在小Table Group中,造成查询并发度下降。这是最常见的需要划分多个Table Group的原因。

    • 负载分离

      已有的Table Group容纳的表数量很多,且大多数表需要同时写入,导致实例的负载很高,而即将创建的新表又需要较高的查询和写入吞吐,这时多个Table Group可以实现写入和查询一定程度上的独立,不受其他表写入查询影响(更准确的负载分离请参考计算资源隔离章节)。或者经过问题排查,确定是已有Table Group无法满足写入和查询需求时,也需要多个Table Group。

    • 表的相关性

      业务上有一系列具有独特写入或者查询模式的表,且这一系列表之间具有(或未来具有)Local Join的需求(Local Join需要左右表同在一个Table Group才能实现,并且Join Key是各自的分布列),同时这些表和其他Table Group的表具有很浅的联系或根本没有联系。这种情况下可以创建多个独立的Table Group。也就是说,如果您有一组表之间相关性很强的表,而这组表与其他表相关性很低、联合查询的概率很低,可以考虑创建多个Table Group。

    • 实例资源扩缩容

      如果实例进行过扩、缩容超过5倍以上,原来定的Shard数很可能不再满足需求,可以考虑更换默认Table Group。Shard数应大于计算节点数,小于实例总Core数的60%(即计算总Core数)。

  • 规划三:多个Table Group放置

    如果需要规划多个Table Group,那么最好是能够在压测和生产之前,提前规划好多个Table Group的作用与意义,以及每个表所属的Table Group。规划时可以考虑如下因素:

    • 数据量

      首先应该考虑的是数据量,也就是大表放更多的Shard,中小表放更少的Shard。

    • 写入性能需求

      Shard数和数据写入性能呈一定的正相关性,单个Shard的写入能力是有上限的。Shard越多,写入的并发越多,写入的吞吐越高。因此,如果表有较高RPS的写入需求,那么可能需要增大shard数。Hologres单Shard将单core打满时,写入RPS为3000-5000条/秒(1KB/条),可以据此估算所需Shard数。考虑到每个shard还需要进行查询等读操作,一般不能使写入打满CPU,因此可以说,使用1/3core的shard,写入RPS为1000条/秒(每条1KB)。因此,举例而言,如果您要求写入RPS 6W/s,每条1KB,则应该选择的Shard数约在60Shard之上,视情况增减。

    • Table Group负载

      在建立一个新的Table Group时,需要考虑当前Table Group需要承载的表数量。例如,如果未来放在此Table Group的表很多,并且多数表都需要经常访问,那么Shard数很小将会存在并发不够的风险。

常见问题

  • 我有512Core规格实例,主要针对一张实时事件表进行OLAP分析,表规模约200~400亿,该怎么设计Table Group和Shard Count?

    计算负载比较单一,可以使用一个Table Group。512的默认Shard数为160,如果事件表列比较多,例如达到数百列,那么为了加强OLAP分析的并发度,可以适当增大Shard数。例如更改DB的默认Table Group的Shard数为200,或200以上,以放置事件表。

  • 我有256Core规格实例,有很多张列存表,主要进行毫秒级快速OLAP分析,每张表数据量千万条级别,主要场景为group by多个字段,以及按条件查明细,该怎么设计Table Group和Shard Count?

    计算负载比较单一,可以一个Table Group解决。256Core规格实例,默认Table Group的Shard数为120,而对于千万级别的表,我们的建议是10-20shard,尤其对于group by等聚合操作,shard越多会有更多的shuffle开销,无法应对毫秒级分析。因此,默认Table Group可能无法应对我们的需求,可以视具体情况,更改DB的默认Table Group的Shard Count为16~40之间,并进行压测,效果会更好。

  • 通过哪些手段排查慢Query是否为Shard Count不合适的原因?

    Shard数不合适分为过多和过少两种情况。

    • Shard数过多,一般会表现为:start query cost高,可以通过explain analyze后的start query cost行看出来;或者表现为shuffle开销大,这点可以通过explain analyze后,查看Redistribution Motion的Max_GetNext_Time的大小来判定。v0.10以上,可以通过慢查询日志查看历史Query的这些开销。

    • Shard数过少,一般会表现为:长时间计算时CPU也无法打满;或者scan数据的开销比较大(因为并发度不足),这点可以通过explain analyze后,查看Scan Node的Max_GetNext_Time大小来判定;或者数据写入的性能不足,上文提到Hologres单shard打满单core时,写入RPS为3000-5000,可据此估算Shard数是否过少。

  • 我是点查的服务场景,我的QPS还不够高,是不是Shard不够的原因?

    首先要判断是不是别的原因引起的,例如并非点查而是分析查询、未走索引、未做Shard裁剪以及CPU已经打满等原因。当排查完后,不属于上述情况,且单SQL性能达到极致后,如果QPS仍不满足要求,则考虑增大shard数,以增大点查的后端并发。

  • 如何排查Shard倾斜?

    Hologres提供了内部字段:hg_shard_id,即数据所在的Shard编号。可以通过SQL查看Shard倾斜情况。

    SELECT hg_shard_id, COUNT(1) FROM <Table_Name> GROUP BY hg_shard_id ORDER BY COUNT(1) DESC;

    如果有Shard上的数据量显著高于其他Shard,则存在数据倾斜,可能需要调整分布列。