You need to enable JavaScript to run this app.
导航
Serverless StarRocks集群资源规划
最近更新时间:2024.05.13 11:31:32首次发布时间:2024.05.13 11:31:32

集群资源规划是指在企业或组织中,通过合理配置和管理计算、存储、网络等资源,以提高系统的可靠性、可用性和效率,满足业务需求的过程。在进行集群资源规划时,需要考虑以下几个方面:

  1. 业务需求:根据业务的特点和需求,确定集群资源的规模和配置。

  2. 可用性:集群资源需要具有高可用性,以确保业务的连续性和稳定性。

  3. 性能:集群资源需要具有高性能,以满足业务的需求。

  4. 成本:集群资源的成本需要在企业或组织的预算范围内。

  5. 可扩展性:集群资源需要具有可扩展性,以满足业务的发展需求。

  6. 跟进写根据数据量和查询要求配置多少资源,多少fe,多少be

1 架构组件说明

  • FE: StarRocks的前端接入节点,集群元数据存储在FE中的Catalog中,FE负责接收SQL,解析SQL,进行优化,并产生对应的执行计划,提交执行计划给BE,由BE负责任务的具体执行。

  • BE: StarRocks的后端执行节点,负责具体SQL任务执行,BE节点会在本地存储数据。

StarRocks 主要由两种类型的组件组成:FE 节点和 BE 节点。每个节点必须单独部署在物理机或虚拟机上。

对于存算分离的情况,会使用CN节点,替代BE节点,可参考存算分离最佳实践 创建湖仓版本的集群。存算分离的湖仓版本架构如图所示。

1.1 FE 节点数量

FE 节点主要负责元数据管理、客户端连接管理、查询计划和查询调度。
对于 StarRocks 生产集群,建议您至少部署三个 Follower FE 节点,以防止单点故障。
StarRocks 通过 BDB JE 协议跨 FE 节点管理元数据。StarRocks 从所有 Follower FE 节点中选出一个 Leader FE 节点。只有 Leader FE 节点可以写入元数据,其他 Follower FE 节点只能根据 Leader FE 节点的日志更新元数据。如果 Leader FE 节点掉线,只要超过半数的 Follower FE 节点存活,StarRocks 就会重新选举出一个新的 Leader FE 节点。
如果您的应用程序会产生高并发查询请求,您可以在集群中添加 Observer FE 节点。Observer FE 节点只负责处理查询请求,不会参与 Leader FE 节点的选举。

1.2 BE 节点数量

BE 节点负责数据存储和 SQL 执行。
对于 StarRocks 生产集群,建议您至少部署三个 BE 节点,这些节点会自动形成一个 BE 高可用集群,避免由于发生单点故障而影响数据可靠性和服务可用性。
您可以通过增加 BE 节点的数量来实现查询的高并发。

1.3 CN 节点数量

CN 节点是 StarRocks 的可选组件,仅负责 SQL 执行。参考存算分离最佳实践 创建湖仓版本的集群。您可以通过增加 CN 节点数量以弹性扩展计算资源,而无需改变集群中的数据分布。

2 CPU 和内存

通常,FE 服务不会消耗大量的 CPU 和内存资源。建议您为每个 FE 节点分配 8 个 CPU 内核和 16 GB RAM。
与 FE 服务不同,如果您的应用程序需要在大型数据集上处理高度并发或复杂的查询,BE 服务可能会使用大量 CPU 和内存资源。因此,建议您为每个 BE 节点分配 16 个 CPU 内核和 64 GB RAM。BE推荐16核64 GB以上。

2.1 基于数据量的资源评估基准

根据社区实践,一般情况下,1T的数据量qps不高的情况下,FE节点配置 8C-16G 200G*3,BE节点配置 16C-64G 800G*3,作为最小参考,还是需要根据实际业务场景测试下再估计的。

数据量FE节点CPU-MemoryBE节点CPU-Memory
1TB8C - 16GB * 316C -64GB * 3

2.2 FE节点资源配置原则

FE是按节点算的,如果设定了高可用,就等于是三节点,每个节点都会占用相同的内存。文档只是设定了一个参考值,通常情况一千万个 Tablet的FE 内存使用在 20 GB左右除了元数据外,还需要考虑 SQL Session 的连接数对内存的占用,对SQL 处理过程对内存的占用。
当数据量翻倍时,或者其它情况qps上涨时,可以根据监控进行动态的调整。

2.3 BE/CN 节点资源配置原则

  1. BE 节点的总内存:

    1. 应该根据服务器的总物理内存来决定 BE 节点可用内存的上限。

    2. 留出足够的内存给操作系统和其他进程,通常建议至少保留 20%-30% 的系统内存给操作系统。

  2. BE 节点配置:

    1. BE 节点的相关内存配置在 be.conf(BE 配置文件)中设置。

    2. 关键配置项包括 mem_limitstorage_page_cache_limit

    3. mem_limit 是 BE 进程可以使用的最大内存。

    4. storage_page_cache_limit 负责表数据的页缓存。

  3. 数据量估计:

    1. 需要评估你的数据量大小以及预期增长,来设置足够的内存以适应数据量。

    2. 对于非常大的数据集,你可能需要更多的内存或者增加 BE 节点。

  4. 查询特性:

    1. 如果查询非常复杂,例如涉及大量的中间结果计算,或者需要高并发查询,内存的需求会更高。

    2. 对于同时需要处理大量写入操作的场景,也需要更多内存以保证查询性能。

  5. 监控与调优:

    1. 使用 StarRocks 提供的监控工具来分析BE节点的性能。

    2. 根据监控结果和系统日志来调整内存配置。

3 存储空间

3.1 FE 存储

由于 FE 节点仅在其存储中维护 StarRocks 的元数据,因此在大多数场景下,每个 FE 节点只需要 128 GB 的 HDD/SDD 存储。

3.2 BE 存储

StarRocks 集群需要的总存储空间同时受到原始数据大小、数据副本数以及使用的数据压缩算法的压缩比的影响。
您可以通过以下公式估算所有 BE 节点所需的总存储空间:

BE 节点所需的总存储空间 = 原始数据大小 * 数据副本数/数据压缩算法压缩比

原始数据大小 = 单行数据大小 * 总数据行数

在 StarRocks 中,一个表中的数据首先被划分为多个分区(Partition),然后进一步被划分为多个 Tablet。Tablet 是 StarRocks 中基本数据管理逻辑单元。为保证数据的高可靠性,您可以为每个 Tablet 维护多个副本,存储于不同的 BE 节点。StarRocks 默认维护三个副本。
目前,StarRocks 支持四种数据压缩算法:zlib、Zstandard(或 zstd)、LZ4 和 Snappy(按压缩比从高至低排列)。这些数据压缩算法可以提供 3:1 到 5:1 的压缩比。
通过计算得到总存储空间后,你可以简单地将之除以集群中的 BE 节点数,估算出每个 BE 节点所需的平均存储空间。

4 存算分离的集群配置建议

StarRocks 存算分离集群采用了存储计算分离架构,特别为云存储设计。您可以参考存算分离最佳实践 创建湖仓版本的集群。在存算分离的模式下,StarRocks 将数据存储在兼容 S3 协议的对象存储TOS中,而本地盘作为热数据缓存,用以加速查询。通过存储计算分离架构,您可以降低存储成本并且优化资源隔离。除此之外,集群的弹性扩展能力也得以加强。在查询命中缓存的情况下,存算分离集群的查询性能与存算一体集群性能一致。
相对存算一体架构,StarRocks 的存储计算分离架构提供以下优势:

  • 廉价且可无缝扩展的存储。

  • 弹性可扩展的计算能力。由于数据不存储在 CN 节点中,因此集群无需进行跨节点数据迁移或 Shuffle 即可完成扩缩容。

  • 热数据的本地磁盘缓存,用以提高查询性能。

  • 可选异步导入数据至对象存储,提高导入效率。

您可以参考StarRocks存算分离集群配置建议 进行配置调整。