StarRocks 存算分离最佳实践，让降本增效更简单
StarRocks 存算分离自版本 3.0.0 开放使用，已经历过多个大版本迭代，在众多客户生产环境中得到验证。但在用户使用过程中也反馈了一些问题，大多源自对新能力不够熟悉导致无法达到最佳效果。因而，本文提供 StarRocks 存算分离最佳实践，建议测试前仔细阅读，并按照最佳实践的指导来实施，以达到事半功倍的效果。
部署
用户在部署时需要在部署模式上二选一，存算一体或者存算分离，目前尚不支持在一个集群中同时支持两种运行模式。
StarRocks 目前支持各种类型对象存储，如所有兼容 AWS S3 协议的对象存储（如 S3、OSS、COS、OBS、GCP、Ceph-S3 等），Azure Blob Storage、Google GCP 以及传统的 HDFS 等，用户可以根据实际情况自由选择。
StarRocks 集群内添加了众多的监控指标，且可以被 Prometheus 采集并通过 Grafana 展示，借助这些指标，可以实时观察集群运行情况。因此，对于所有的用户，我们建议您在实际使用 StarRocks 存算分离集群前，先配置好监控，详细可参考文档 StarRocks 存算分离监控部署[1]。
建表
在存算分离集群中，用户建表时需要关注分桶数的设置，要想获得最佳性能，合理的分桶数选择必不可少。如果分桶数设置的过少，可能会导致计算时无法充分利用硬件资源，如果分桶数设置过多，在存算分离集群中可能会产生大量的小文件导致 I/O 效率低下。在实践中，我们建议按照数据量来决定分桶数，一般建议每个分桶容纳的数据规模在 1 ~ 5GB 左右较为合适。
另外，自 3.1.0 版本后，StarRocks 支持为每个表指定不同的存储桶（对象存储中的概念，存储容器），用户可以为不同的表设定不同的存储桶以实现物理资源的隔离，具体可以通过创建 Storage Volume 来配置不同的存储桶[2]；创建表时，通过 Storage Volume PROPERTIES 指定存储桶[3]。
Tips
1，根据表实际数据量合理选择分桶数量
2，对于分桶数较多的表，创建可能耗时较长，此时可适当调整参数来观察是否有改善
3，使用 Storage Volume 能让您的建表更为灵活，强烈推荐
导入
当前 StarRocks 存算分离表支持存算一体模式中的所有数据导入方式，离线数据推荐 Broker Load，实时数据同步推荐 DataX，Flink Connector 等，用法与存算一体保持一致。
为了保证数据可靠性，存算分离中数据写入使用同步模式，即保证数据完整写入后端对象存储后方才给用户返回成功。考虑到对象存储的延迟（高出本地磁盘 1 ~ 2 个数量级），用户可能会观察到单一任务导入延迟相比存算一体表有所增加（增加的比例取决于多种因素），这属于正常现象。因此，在存算分离表中，我们建议，如果条件允许，尽量攒批大一点，一次性导入更多的数据量，以更好地利用对象存储高吞吐特性，对于部分存储系统（如 HDFS），过多的小文件也会给元数据服务带来极大压力。
其次，在实践中我们推荐增大 flush memtable 的线程数（flush_thread_num_per_store），多线程并发写数据可以充分利用对象存储的高吞吐特性。
具体的导入参数调优可参考 StarRocks 存算分离 3.1 性能调优手册[4]。
Tips
1，攒批大一点可以获得更好的吞吐，同时也能减少对象存储小文件数量
2，提高 flush memtable 线程数，可以充分利用对象存储的高吞吐特性，取得更好的写入性能
查询
经过我们实际测试和众多用户实践，在缓存命中（Local Disk and Page Cache）情况下，StarRocks 存算分离表的查询性能与存算一体基本一致，因此，我们推荐，条件允许情况下建议开启 Data Cache 以获得更好的查询性能。
对于直接查询位于远端对象存储的数据，取决于实际的查询类型，相比缓存命中情况下，可能有 3 ~ 5 倍左右的性能差距，目前社区正在不断优化该场景下的查询性能，期望能不断缩小这种差距。
即使开启了 Data Cache，在某些场景下依然可能会出现 Cache Miss 情况（例如升降级导致了 Tablet 迁移），我们需要尽量保证不触发 Tablet 迁移。
如果出现查询性能超出预期范围，用户可选择通过自主分析 Profile 来定位具体原因。
具体的查询参数调优可参考 StarRocks 存算分离 3.1 性能调优手册[4]。
Tips
1，如果可以，尽量为所有的表开启 Data Cache（建表时默认行为）
2，在 BE/CN 常规重启或者版本升级时，关闭 Tablet Balance（在 Leader FE 上执行 admin set frontend config("disable_balance"="true")）避免触发 Tablet 迁移，避免造成 Cache Miss，影响查询性能
3，冷数据查询社区正在积极优化，如果您遇到这种问题，请及时反馈
4，学会自主分析 Profile，快速定位性能问题
Cache
Cache 是提升查询效率的主要方式，我们也推荐为所有的表开启 Data Cache（指的是基于计算节点本地磁盘的作为数据缓存），将热数据缓存在磁盘上，提升 I/O 效率。
StarRocks 存算分离建表时默认会开启 Data Cache，当然您也可以通过参数关闭。开启 Cache 后，导入时，数据会同时写入本地缓存与后端对象存储，只有两者都写入成功后方才给用户返回成功。
StarRocks 支持自动的 LRU 淘汰，当缓存磁盘接近满时会自动将最冷的数据淘汰掉，原则上您无需担心磁盘写满造成写入失败的情况，但某些极端场景下可能也会出现淘汰不及时造成了磁盘满情况，建议您配置磁盘监控报警，关注磁盘容量。
StarRocks 支持多块盘作为缓存，目前的策略是会将不同的 Partition 数据打散放置到多个缓存盘上（3.1.4 版本后），因而，基本上多块缓存盘磁盘空间使用应该是比较均衡的，建议您也适当关注。
StarRocks 当前版本采用 File 级别 Cache，即一旦查询出现 Cache Miss，计算节点会将单个数据文件全部拉回本地磁盘（即使计算节点可能只访问文件中的某些数据页面），可能会造成网络流量较大，使用的计算和 I/O 资源较多以及缓存拉取较慢的问题，建议多加关注。从 3.2 版本后，StarRocks 将使用更细粒度的缓存机制来彻底解决该问题。 StarRocks 社区目前正在设计缓存预热方案，敬请期待。具体的 Cache 调优可参考 StarRocks 存算分离 3.1 性能调优手册[4]。
Tips
1，关注缓存磁盘的容量，并配置监控报警应对异常
2，如果计算节点使用多块缓存磁盘，建议关注缓存磁盘使用是否均衡
3，使用 File Cache 机制在 Cache Miss 时可能会有大量拉缓存的情况，将在 3.2.0 版本彻底解决
4，缓存预热正在设计中，敬请期待
Compaction
Compaction 是 StarRocks 的后台任务（存算一体与存算分离均存在），目的是将小文件合并成为大文件，以减少 I/O 次数，加速查询性能。
作为后台任务，用户一般情况下无需感知 Compaction 任务的执行情况，但当出现查询较慢时，我们建议您优先关注下慢查询涉及的表的 Compaction Score 情况，排除是 Compaction 不及时造成的慢查询。
StarRocks 存算分离集群中，系统会根据 Partition 下的文件数量来决定是否发起 Compaction 任务，系统会自动根据当前计算节点规模来决定同时执行的 Compaction 任务数，基本能做到自适应。但 Compaction 本质上也需要消耗系统资源（CPU、Memory、I/O 等），当系统资源紧张时，需要适当降低 Compaction 的频率来减少对正常业务请求的影响。
具体的 Compaction 运维可参考 StarRocks 存算分离 Compaction 运维手册[5]。
Tips
1，关注 Partition 的 Compaction Score 非常重要，尤其是在出现慢查询时
2，Compaction 会消耗系统资源，如果资源紧张，建议降低 Compaction 频率
GC
同 Compaction 一样，GC 也是 StarRocks 的后台任务（存算一体与存算分离均存在），目的是删除那些不再需要的文件版本，降低存储容量与成本（对象存储会根据存储容量收费）。
作为后台任务，用户一般情况下无需感知 GC 任务的执行情况，但我们建议您定期关注后端对象存储容量以确定 GC 任务正确运行。
如果您观察到对象存储容量远超表实际数据容量，此时可以观察监控指标来观察是否有 GC 任务积压等现象，如果有，可以参照 StarRocks 存算分离垃圾回收运维手册[6]调整部分参数值来加速 GC 任务回收。
Tips
1，关注表的容量和实际对象存储容量，如果后者超出太多，建议仔细分析 如果存在大查询，建议适当延长文件回收时间，避免查询失败
Primary Key 表
StarRocks 存算分离自版本 3.1.0 后开始支持 Primary Key 表模型，其使用方式与存算一体模式下完全一致，用户可以放心使用。
自 3.1.4 版本后，Primary key 表开始支持索引持久化能力，但仅限持久化至本地缓存磁盘，因此，如果想使用持久化索引，需要配置本地磁盘。 如果未开启索引持久化，可能会存在使用内存较多的问题，请及时关注内存使用情况，如有必要，使用 3.1.4 以及之后的版本来开启索引持久化。
Tips
1，未开启索引持久化时可能会消耗较多内存，请及时监控内存使用，如果内存不足，可以开启索引持久化
数据迁移
当前 StarRocks 存算一体与存算分离无法在同集群共存，用户需要将存算一体集群数据迁移至存算分离集群，存在如下几种方案：
1，将存算一体集群数据通过 export 导出至 S3、HDFS 等系统，然后再通过 Broker Load 等方式导入至存算分离集群
2，在存算分离集群配置 StarRocks 外表并指向存算一体集群，然后通过 insert into select 方式从外表中向存算分离集群内表导入数据，但要求存算一体集群版本在 3.0.0 以上
3，利用社区提供的迁移工具完成一键式迁移，简单且高效（预计 12 月中旬发布）
弹性
StarRocks 存算分离的一个核心优势在于可以快速弹性，我们实测也显示弹性效果非常优秀且避免了存算一体在弹性时存在的数据迁移导致弹性时间过长的问题，弹性测试可参考 StarRocks 存算分离弹性能力测试[7]。 StarRocks 存算分离支持快速弹性，节点的上下线会触发 Tablet 迁移，这会导致部分查询出现 Cache Miss，不过只要经过第一次查询冷数据后，第二次即可命中 Cache，性能也会相应恢复。
Tips
1，增加节点可相应提升性能
2，弹性时由于 Tablet 迁移会存在首次查询 Cache Miss，但第二次就会恢复
相关链接：
[1]https://starrocks.feishu.cn/docx/ZwkcdCl00oHMMFxNwK7cg20Bnje
[4]https://starrocks.feishu.cn/docx/GEZpdCPchoVL67xTMOPcKjCrneg
[5]https://starrocks.feishu.cn/docx/GvgmdyK03olcFoxCs7rcHjKVnod
[6]https://starrocks.feishu.cn/docx/XZ8edURRvoDbOnxigCocsLzNnyh
[7]https://starrocks.feishu.cn/docx/Dd3AdQ9ujoYKHsxXxeNcB8oBn9d
新一代极速全场景MPP数据库 2020-08-08 加入
StarRocks一直致力于打造世界顶级的新一代极速全场景MPP数据库，帮助企业建立“极速统一”的数据分析新范式，助力企业数字化经营。当前已帮助腾讯、携程、顺丰、Airbnb等超过110家大型用户构建全新的数据分析能力。
评论