本文匯總了StarRocks使用時的常見問題。
業務測試評估
購買常見問題
常見使用問題
硬件資源有什么要求？
整體機器配置
BE推薦16核64 GB以上，FE推薦8核16 GB以上。
生產環境FE通常是16核，32 GB或64 GB內存，200~500 GB NVMe。
磁盤
HDD和SSD都可以。
磁盤容量評估，可以按照壓縮比3，磁盤利用率70%~75%作為上限來進行評估。
如果導入到SR的數據是Parquet或Orc的Hive數據，則壓縮比按照1：1來評估。
例如，Hive數據是3T，則導入StarRocks的數據也是3T。
CPU
CPU必須支持AVX2指令集，可以通過
cat /proc/cpuinfo |grep avx2命令判斷。向量化技術需要配合CPU指令集才能發揮更好地作用，所以沒有相關指令集的話建議更換機器。
網絡
建議選擇萬兆網卡和萬兆交換機。
軟件配置有什么要求？
軟件配置的詳細的信息，請參見參數配置。
生產環境下的副本數應該設置為多少？
通常生產環境下副本數2~3即可，建議設置為3。
如何分區？
合理的分區可以有效的裁剪scan的數據量。
通常是從業務本身對數據進行管理的角度來選擇分區鍵。例如選用時間或者區域作為分區鍵。
如果需要自動創建分區，則可以使用動態分區。
如何分桶？
選擇高基數的列來作為分桶鍵，避免Bucket之間數據傾斜。
如果有唯一ID，則建議使用唯一ID分桶。
如果碰到數據傾斜嚴重的，則可以使用多列作為分桶鍵，但通常不要使用太多列作為分桶鍵。
Tablet的最佳大小可以按下面進行評估，基于以下參數值和總數據量可以預估出Bucket的數目。
原始非壓縮數據，例如CSV格式，通常每個tablet設置為1 GB ~10 GB之間。
Parquet格式的數據，建議1 GB左右。
在機器比較少的情況下，如果想充分利用機器資源可以考慮使用
BE數量 * cpu core / 2來設置Bucket數量。
如何設計排序鍵？
排序鍵要根據查詢的特點來設計：
將經常作為過濾條件和Group BY的列作為排序鍵，可以加速查詢。
如果是有大量點查，建議把查詢點查的ID放到第一列。
例如，查詢命令為
select sum(revenue) from lineorder where user_id='aaa100';，并且有很高的并發，強烈推薦把user_id作為排序鍵的第一列。如果查詢的主要是聚合和scan比較多，建議把低基數的列放在前面。
例如，查詢命令為
select region, nation, count(*) from lineorder_flat group by region, nation，則建議把region作為第一列，nation作為第二列會更合適。
如何合理的選擇數據類型？
盡量使用精準的數據類型。例如，能夠使用整型就不要使用字符串類型，能夠使用int就不要使用bigint，精確的數據類型能夠更好的發揮數據庫的性能。
當Routine Load出現性能問題時，如何進行參數調優？
參數調優策略
當Routine Load出現性能問題時，您可以考慮從如下幾個維度來進行參數調優：
任務調度周期
您可以通過縮短任務調度周期（即修改參數max_batch_interval）加速數據消費。但是，縮短任務調度周期可能會帶來更多的CPU資源消耗。
重要任務調度周期最小值為5s。
任務并行度
在Partition數量和BE數量較多時，您可以調大以下參數來加速任務執行。但是，增加并行度可能會帶來更多的CPU資源消耗。
max_routine_load_task_concurrent_num
desired_concurrent_number
單個Routine Load任務會根據Kafka Topic Partition數和BE數等被拆分為若干個子任務，分發至多個BE執行。此處的任務并行度，實際上是指單個Routine Load拆分成的子任務個數。
實際的任務并行度參照如下的計算公式。
concurrent_num = Min( Min( partition_num, Min( desired_concurrent_num, alive_be_num ) ),Config.max_routine_load_task_concurrent_num )任務批量大小
routine_load_task_consume_second：通過增大單次讀取持續時間加速數據消費。
max_routine_load_batch_size：通過增大單次讀取的數據量加速數據消費。
您可以根據以下日志來判定當前的批量參數設置是否過小。正常情況下，該日志的
left_bytes字段應該>=0，表示一次讀取的數據量還未超過max_routine_load_batch_size上限。否則，說明max_routine_load_batch_size過小。I0325 20:27:50.410579 15259 data_consumer_group.cpp:131] consumer group done: 41448fb1a0ca59ad-30e34dabfa7e47a0. consume time(ms)=3261, received rows=179190, received bytes=9855450, eos: 1, left_time: -261, left_bytes: 514432550, blocking get time(us): 3065086, blocking put time(us): 24855 1
Routine Load參數
參數 | 類型 | 默認值 | 描述 |
max_routine_load_job_num | fe.conf | 100 | NEED_SCHEDULE、RUNNING、PAUSED狀態的routine load任務上限。 |
max_routine_load_task_concurrent_num | fe.conf | 5 | 單個Routine Load任務的最大并行度。 |
max_routine_load_task_num_per_be | fe.conf | 5 | 單個BE節點上調度分配的最大Routine Load任務數。 |
max_routine_load_batch_size | fe.conf | 500 MB | 最大單次批量讀取Kafka數據量。 |
routine_load_task_consume_second | fe.conf | 3 | 最大單次批量讀取Kafka數據時間。 |
routine_load_task_timeout_second | fe.conf | 15 | 單個Routine Load任務running超時時間。 |
max_consumer_num_per_group | be.conf | 3 | 單個consumer group最大consumer數。 |
desired_concurrent_number | properties | 3 | 期望Routine Load任務的并行度。實際的任務并行度參照如下的計算公式 |
max_batch_interval | properties | 10s | Routine Load任務調度周期。 |
max_batch_rows | properties | 200000 | 該參數只用于定義錯誤檢測窗口范圍，窗口的范圍是 |
max_error_number | properties | 0 | 采樣窗口內，允許的最大錯誤行數。必須大于等于0。默認是0，即不允許有錯誤行。 重要 被where條件過濾掉的行不算錯誤行。 |
strict_mode | properties | true | 是否開啟嚴格模式，默認為開啟。如果開啟后，非空原始數據的列類型變換為NULL，則會被過濾。 |
如何選擇數據模型？
StarRocks的數據模型主要有以下四種，您可以根據實際情況選擇。
數據模型 | 適用場景 |
duplicate key |
|
agg模型 |
|
uniq key | 適合于有更新和實時分析的場景。 |
primary key | 適合于有更新和實時分析的場景。 如果有部分列更新的場景建議列在200列以內。 |
StarRocks數據模型count的實現機制是怎么樣的？
StarRocks的數據模型主要有四種，分別為duplicate key、uniq key、agg模型和primary key模型，他們對于count的實現有比較大的區別。具體區別如下：
duplicate key：該模型不需要做merge操作，所以count比較快。
uniq key和agg模型：對count操作的實現涉及多版本merge的操作，所以相對要慢一些。
如果key是string類型，則理論上count操作會更慢。
primary key：在讀取數據的時候因為有內存中的索引和delete vector，不需要做merge操作，所以count操作比uniq key和agg模型會快些。
如果有更新操作，建議使用該模型。
如何減少/mnt/disk1/starrocks/storage/trash/目錄磁盤占用？
/mnt/disk1/starrocks/storage/trash/目錄中存儲的是刪除的數據。如果您想減少該目錄的磁盤占用，可以通過調小be.conf中的trash_file_expire_time_sec參數，控制trash目錄保留時間。默認值是259200（72小時）。
創建物化視圖時報錯，該如何處理？
問題現象：具體報錯如下圖所示。
解決方法：
執行命令
show proc "/cluster_balance";和show proc "/statistic";。查看是否有tablet正在進行rebalance：
如果有，則等待執行完成。
如果沒有，則可以執行命令
set disable_balance=true，然后發起創建物化視圖操作。
數據查詢緩慢，如何處理？
建議處理方法如下：
開啟Profile，之后在StarRocks UI上查看Profile信息。
執行命令
SET is_report_success = true;開啟Profile。基本排查方法：
調整并行度。
Pipeline
SET pipeline_dop = 8; SET enable_pipeline_engine = true;非Pipeline
SET enable_pipeline_engine=false; SET parallel_fragment_exec_instance_num=8;
查看tablet分布。
show data xxx;說明建議tablet大小在1 GB~10 GB。
查看建表。
通過Profile判斷iotime。如果很大，可以刪除一些不必要的索引，例如，刪除建得比較多的bitmap索引。
查看表數據模型，選擇合適的數據模型。例如，uniq key模型在compaction沒有做完的時候下推無法適用，容易導致查詢慢。
為什么8030、8040端口訪問失敗？
因為EMR Starrocks在EMR-5.8.0及以下版本、EMR-3.42.0及以下版本中load_url的端口號為8030，webserver_port為8040，但在EMR-5.9.0及以上版本、EMR-3.43.0及以上版本中load_url的端口號為18030，webserver_port為18040，所以請根據您的集群版本選擇訪問的端口。
您可以使用show frontends命令查看實際的端口。
EMR StarRocks支持哪些地域？
目前StarRocks已經全量發布在各個地域。
BE數據盤和數據分布的關系？
目前默認是掛載4塊ESSD PL1的云盤，StarRocks會根據負載和分桶機制等將數據均衡分布在各個節點。同一個tablet同一個副本的數據存儲在同一塊盤。
數據異常，如何重置集群進行恢復？
以下操作會清空集群數據，請慎重操作！
停止集群服務（FE、BE）。
清理FE元數據目錄。
查看
/opt/apps/STARROCKS/starrocks-current/fe/conf/下的fe.conf文件，獲取meta_dir的配置目錄。刪除上面配置目錄下的bdb文件夾。
清空上面配置目錄下的image文件夾。
清空BE數據和元數據。
查看
/opt/apps/STARROCKS/starrocks-current/be/conf/下的be.conf文件，獲取storage_root_path的配置目錄。刪除上面配置目錄下除data和meta之外的文件夾和文件。
清空上面配置目錄下的data和meta文件夾。
說明上面的配置可能會有多個路徑，需要在每個路徑下都進行操作。
重啟集群服務（FE、BE）。
如何查看日志？
日志目錄通常在以下路徑：
FE
/opt/apps/STARROCKS/starrocks-current/fe/log/
/mnt/disk1/log/starrocks/
BE
/opt/apps/STARROCKS/starrocks-current/be/log/
/mnt/disk1/log/starrocks/
如何使用StarRocks的存算分離模式？
EMR on ECS形態下的StarRocks不支持存算分離模式。如果您需要使用存算分離模式，請購買EMR Serverless StarRocks。有關存算分離的詳細信息，請參見快速使用存算分離版實例。
為什么Task節點擴容后未參與計算？
問題描述
對StarRocks集群進行了彈性擴容，添加三個Task節點后，這些節點被分配到了Compute Node（CN），未能自動執行計算任務。盡管現有BE節點承受高負載，新加入的Task節點卻未得到充分利用，監控數據顯示它們的負載一直很低。
原因分析
在存算一體的架構下，StarRocks集群的CN節點僅支持對外部表的查詢。因此，如果應用場景主要涉及到內表查詢，這些查詢任務通常由BE節點處理，導致新增的CN節點未得到充分利用。
解決方案
在查詢任務執行前，通過執行以下SQL命令來設置CN節點優先執行。
SET GLOBAL prefer_compute_node=true;