本文匯總了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 | 是否開啟strict 模式，預設為開啟。如果開啟後，非空未經處理資料的列類型變換為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/
為什麼Task節點擴容後未參與計算？
問題描述
對StarRocks叢集進行了彈性擴容，添加三個Task節點後，這些節點被分配到了Compute Node（CN），未能自動執行計算任務。儘管現有BE節點承受高負載，新加入的Task節點卻未得到充分利用，監控資料顯示它們的負載一直很低。
原因分析
在存算一體的架構下，StarRocks叢集的CN節點僅支援對外部表格的查詢。因此，如果應用情境主要涉及到內表查詢，這些查詢任務通常由BE節點處理，導致新增的CN節點未得到充分利用。
解決方案
在查詢任務執行前，通過執行以下SQL命令來設定CN節點優先執行。
SET GLOBAL prefer_compute_node=true;