• 通用問題

  • 如何選擇導入方式？

  • 影響導入性能的因素都有哪些？

  • 報錯“close index channel failed“或“too many tablet versions”，該如何處理？

  • 報錯“Label Already Exists”，該如何處理？

  • 報錯“ETL_QUALITY_UNSATISFIED; msg:quality not good enough to cancel”，該如何處理？

  • 數(shù)據(jù)導入過程中，發(fā)生遠程過程調(diào)用（Remote Procedure Call，簡稱RPC）超時問題，該如何處理？

  • 報錯“Value count does not match column count”，該如何處理？

  • 報錯“ERROR 1064 (HY000): Failed to find enough host in all backends. need: 3”，該如何處理？

  • 導入數(shù)據(jù)時發(fā)現(xiàn)BE服務日志中出現(xiàn)Too many open files問題，該如何處理？

  • 報錯“increase config load_process_max_memory_limit_percent”，該如何處理？

  • 為什么在導入數(shù)據(jù)時磁盤空間使用率會異常上升？

  • 使用JindoSdk讀取OSS外表數(shù)據(jù)時報錯，該如何解決？

  • 導入數(shù)據(jù)時報錯“transmit chunk rpc failed”，該如何解決？

  • 在進行數(shù)據(jù)導入時，若主鍵索引占用的內(nèi)存超過限制，應如何處理？

  • 為什么通過Spark Connector讀取數(shù)據(jù)時出現(xiàn)被取消報錯？

  • 使用Spark Connector導入任務時事務處理慢，該如何解決？

• Stream Load

  • Stream Load是否支持識別文本文件中首行的列名？或者是否支持指定不讀取第一行？

  • 當前業(yè)務的分區(qū)鍵對應的數(shù)據(jù)不是標準的DATE和INT類型，使用Stream Load導入數(shù)據(jù)到StarRocks時，需要轉(zhuǎn)換數(shù)據(jù)嗎？

  • 報錯“body exceed max size: 10737418240, limit: 10737418240”，該如何處理？

  • 執(zhí)行Stream Load時報錯“Cancelled because of runtime state is cancelled”，該如何解決？

• Routine Load

  • 如何提高導入性能？

  • 執(zhí)行SHOW ROUTINE LOAD命令后，導入作業(yè)狀態(tài)變?yōu)镻AUSED或CANCELLED，該如何處理？

  • 使用Routine Load消費Kafka寫入StarRocks是否能保證一致性語義？

  • 報錯“Broker: Offset out of range”，該如何處理？

• Broker Load

  • Broker Load是否支持再次執(zhí)行已經(jīng)執(zhí)行成功、且處于FINISHED狀態(tài)的導入作業(yè)？

  • Broker Load導入時出現(xiàn)內(nèi)容亂碼，該如何處理？

  • Broker Load導入HDFS數(shù)據(jù)時，數(shù)據(jù)的導入日期字段出現(xiàn)異常，比正確的日期時間多加了8小時，該如何處理？

  • Broker Load導入ORC格式的數(shù)據(jù)時，報錯“ErrorMsg: type:ETL_RUN_FAIL; msg:Cannot cast '' from VARCHAR to ARRAY”，該如何處理？

  • 為什么Broker Load導入作業(yè)沒報錯，但是卻查詢不到數(shù)據(jù)？

  • 報錯“failed to send batch或TabletWriter add batch with unknown id”，該如何處理？

  • 報錯“LOAD-RUN-FAIL; msg:OrcScannerAdapter::init_include_columns. col name = xxx not found”，該如何處理？

  • 導入作業(yè)長時間沒有結束等問題應該如何處理？

  • 如何配置以訪問高可用 (HA) 模式下的Apache HDFS集群？

  • 如何配置Hadoop ViewFS Federation？

  • 訪問Kerberos認證的集群時，報錯“Can't get Kerberos realm”，該如何處理？

• INSERT INTO

  • 使用INSERT INTO語句導入數(shù)據(jù)時，SQL每插入一條數(shù)據(jù)大約耗時50~100ms，能否優(yōu)化執(zhí)行效率？

  • 使用INSERT INTO SELECT語句導入數(shù)據(jù)時，系統(tǒng)報錯“index channel has intoleralbe failure”，該如何解決？

  • 使用INSERT INTO SELECT語句導入大量數(shù)據(jù)時會執(zhí)行失敗，報錯“execute timeout”，該如何解決？

• MySQL實時同步至StarRocks

  • 執(zhí)行Flink job，報錯“Could not execute SQL statement. Reason:org.apache.flink.table.api.ValidationException: One or more required options are missing”，該如何解決？

  • Flink如何自動重啟失敗的Task？

  • 如何手動停止Flink job，并且恢復Flink job至停止前的狀態(tài)？

• Flink Connector

  • 使用事務接口的exactly-once時，導入失敗，該如何解決？

  • flink-connector-jdbc_2.11 Sink到StarRocks時間落后8小時，該如何處理？

  • 為什么沒有查詢時BE內(nèi)存處于打滿狀態(tài)，且CPU也是打滿狀態(tài)？

  • 為什么BE申請的內(nèi)存不會釋放給操作系統(tǒng)？

  • 為什么無法解析Flink Connector依賴？

  • Flink-connector-StarRocks中sink.buffer-flush.interval-ms參數(shù)是否生效？

  • Flink作業(yè)寫入StarRocks時報錯 "Caused by: Could not resolve host for client socket"

• DataX Writer

  • 使用DataX導入支持更新數(shù)據(jù)嗎？

  • 使用DataX同步數(shù)據(jù)時，如何處理命名中使用的關鍵字，防止報錯？

• Spark Load

  • 報錯“When running with master 'yarn' either HADOOP-CONF-DIR or YARN-CONF-DIR must be set in the environment”，該如何解決？

  • 提交Spark job時用到spark-submit命令，報錯“Cannot run program "xxx/bin/spark-submit": error=2, No such file or directory”，該如何解決？

  • 報錯“File xxx/jars/spark-2x.zip does not exist”，該如何解決？

  • 報錯“yarn client does not exist in path: xxx/yarn-client/hadoop/bin/yarn”，該如何解決？

報錯“close index channel failed“或“too many tablet versions”，該如何處理？

• 報錯原因

  該問題主要是數(shù)據(jù)導入頻率太快，數(shù)據(jù)沒能及時合并（Compaction），從而導致版本數(shù)超過支持的最大未合并版本數(shù)。

• 解決方案

  默認支持的最大未合并版本數(shù)為1000。您可以通過以下方法解決上述報錯：

  • 增大單次導入的數(shù)據(jù)量，降低導入頻率。

  • 在BE的配置文件be.conf中修改以下配置，通過調(diào)整合并策略實現(xiàn)加快合并的目的。

    cumulative_compaction_num_threads_per_disk = 4
    base_compaction_num_threads_per_disk = 2
    cumulative_compaction_check_interval_seconds = 2

報錯“Label Already Exists”，該如何處理？

• 問題描述

  StarRocks集群中同一個數(shù)據(jù)庫內(nèi)已經(jīng)有一個相同Label的導入作業(yè)導入成功或者正在執(zhí)行。

• 報錯原因

  由于Stream Load是采用HTTP協(xié)議提交導入作業(yè)的請求，通常各個語言的HTTP客戶端均會自帶請求重試邏輯。StarRocks集群在接收到第一個請求后，已經(jīng)開始操作Stream Load，但是由于沒有及時向客戶端返回結果，會出現(xiàn)客戶端再次重試發(fā)送相同請求的情況。這時候，StarRocks集群由于已經(jīng)在操作第一個請求，所以第二個請求會返回Label Already Exists的狀態(tài)提示。

• 解決方案

  需要檢查不同導入方式之間是否有標簽沖突、或是有重復提交的導入作業(yè)。排查方法如下：

  • 使用標簽搜索主FE的日志，查看是否存在同一個標簽出現(xiàn)了兩次的情況。如果有，則說明客戶端重復提交了該請求。

    說明

    StarRocks集群中導入作業(yè)的標簽不區(qū)分導入方式。因此，可能存在不同的導入作業(yè)使用了相同標簽的問題。

  • 運行SHOW LOAD WHERE LABEL = "xxx"語句，查看是否已經(jīng)存在具有相同標簽且處于FINISHED狀態(tài)的導入作業(yè)。其中xxx為待檢查的標簽字符串。

  建議根據(jù)當前請求導入的數(shù)據(jù)量，計算出大致的導入耗時，并根據(jù)導入超時時間來適當?shù)卣{(diào)大客戶端的請求超時時間，從而避免客戶端多次提交該請求。

報錯“ETL_QUALITY_UNSATISFIED; msg:quality not good enough to cancel”，該如何處理？

報錯“ERROR 1064 (HY000): Failed to find enough host in all backends. need: 3”，該如何處理？

您可以在建表屬性中添加"replication_num" = "1"信息。

導入數(shù)據(jù)時發(fā)現(xiàn)BE服務日志中出現(xiàn)Too many open files問題，該如何處理？

報錯“increase config load_process_max_memory_limit_percent”，該如何處理？

數(shù)據(jù)導入過程中，發(fā)生遠程過程調(diào)用（Remote Procedure Call，簡稱RPC）超時問題，該如何處理？

檢查BE配置文件中write_buffer_size參數(shù)的設置。該參數(shù)用于控制BE上內(nèi)存塊的大小閾值，默認閾值為100 MB。如果閾值過大，可能會導致遠程過程調(diào)用超時，此時需要配合BE配置文件中的tablet_writer_rpc_timeout_sec參數(shù)來適當?shù)卣{(diào)整write_buffer_size參數(shù)的取值。BE配置項的更多信息，請參見參數(shù)配置。

報錯“Value count does not match column count”，該如何處理？

• 問題描述

  導入作業(yè)失敗，通過查看錯誤詳情URL發(fā)現(xiàn)返回“Value count does not match column count”錯誤，提示解析源數(shù)據(jù)得到的列數(shù)與目標表的列數(shù)不匹配。

• 報錯原因

  發(fā)生該錯誤的原因是導入命令或?qū)胝Z句中指定的列分隔符與源數(shù)據(jù)中的列分隔符不一致。例如，上面示例中，源數(shù)據(jù)為CSV格式，包括三列，列分隔符為逗號（,），但是導入命令或?qū)胝Z句中卻指定制表符（\t）作為列分隔符，最終導致源數(shù)據(jù)的三列數(shù)據(jù)解析成了一列數(shù)據(jù)。

• 解決方案

  修改導入命令或?qū)胝Z句中的列分隔符為逗號（,），然后再次嘗試執(zhí)行導入。

如何選擇導入方式？

導入方式的選擇可以參見導入概述。

影響導入性能的因素都有哪些？

Stream Load是否支持識別文本文件中首行的列名？或者是否支持指定不讀取第一行？

當前業(yè)務的分區(qū)鍵對應的數(shù)據(jù)不是標準的DATE和INT類型，使用Stream Load導入數(shù)據(jù)到StarRocks時，需要轉(zhuǎn)換數(shù)據(jù)嗎？

StarRocks支持在導入過程中進行數(shù)據(jù)轉(zhuǎn)換。

-H "columns: NO,DATE_1, VERSION, PRICE, DATE=LEFT(DATE_1,6)"

DATE_1可以簡單地看成先占位進行取數(shù)，然后通過LEFT()函數(shù)進行轉(zhuǎn)換，賦值給StarRocks表中的DATE列。需要注意的是，必須先列出CSV文件中所有列的臨時名稱，然后再使用函數(shù)進行轉(zhuǎn)換。支持列轉(zhuǎn)換的函數(shù)為標量函數(shù)，包括非聚合函數(shù)和窗口函數(shù)。

報錯“body exceed max size: 10737418240, limit: 10737418240”，該如何處理？

• 報錯原因

  源數(shù)據(jù)文件大小超過10 GB，超出了Stream Load所能支持的文件大小的上限。

• 解決方案

  • 通過seq -w 0 n拆分數(shù)據(jù)文件。

  • 通過curl -XPOST http://be_host:http_port/api/update_config?streaming_load_max_mb=<file_size>調(diào)整BE配置項中streaming_load_max_mb的取值來擴大文件大小上限。BE配置項的更多信息，請參見參數(shù)配置。

如何提高導入性能？

方式一：增加實際任務并行度

min(alive_be_number, partition_number, desired_concurrent_number, max_routine_load_task_concurrent_num)

因此當消費分區(qū)和BE節(jié)點數(shù)量較多，并且大于desired_concurrent_number和max_routine_load_task_concurrent_num參數(shù)時，如果您需要增加實際任務并行度，則可以提高desired_concurrent_number和max_routine_load_task_concurrent_num參數(shù)。

例如，消費分區(qū)數(shù)量為7，存活BE數(shù)量為5，max_routine_load_task_concurrent_num為默認值5。此時如果需要增加實際任務并發(fā)度至上限，則需要將desired_concurrent_number設置為5（默認值為3），則計算實際任務并行度min(5,7,5,5)為5。

方式二：增大單個導入任務消費分區(qū)的數(shù)據(jù)量

單個Routine Load導入任務消費消息的上限由參數(shù)max_routine_load_batch_size，或者參數(shù)routine_load_task_consume_second決定。當導入任務消費數(shù)據(jù)并達到上述要求后，則完成消費。上述兩個參數(shù)為FE配置項，更多說明和設置方式，請參見參數(shù)配置。

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

正常情況下，該日志的left_bytes >=0，表示在routine_load_task_consume_second時間內(nèi)一次讀取的數(shù)據(jù)量還未超過max_routine_load_batch_size，說明調(diào)度的一批導入任務都可以消費完Kafka的數(shù)據(jù)，不存在消費延遲，則此時您可以通過提高routine_load_task_consume_second的參數(shù)值，增大單個導入任務消費分區(qū)的數(shù)據(jù)量 。

如果left_bytes < 0，則表示未在routine_load_task_consume_second規(guī)定時間，一次讀取的數(shù)據(jù)量已經(jīng)達到max_routine_load_batch_size，每次Kafka的數(shù)據(jù)都會把調(diào)度的一批導入任務填滿，因此極有可能Kafka還有剩余數(shù)據(jù)沒有消費完，存在消費積壓，則可以提高max_routine_load_batch_size的參數(shù)值。

執(zhí)行SHOW ROUTINE LOAD命令后，導入作業(yè)狀態(tài)變?yōu)镻AUSED或CANCELLED，該如何處理？

使用Routine Load消費Kafka寫入StarRocks是否能保證一致性語義？

Routine Load能夠保證一致性（Exactly-once）語義。

一個導入任務是一個單獨的事務，如果該事務在執(zhí)行過程中出現(xiàn)錯誤，則事務會中止，F(xiàn)E不會更新該導入任務相關分區(qū)的消費進度。FE在下一次調(diào)度任務執(zhí)行隊列中的導入任務時，從上次保存的分區(qū)消費位點發(fā)起消費請求，保證Exactly once語義。

報錯“Broker: Offset out of range”，該如何處理？

Broker Load是否支持再次執(zhí)行已經(jīng)執(zhí)行成功、且處于FINISHED狀態(tài)的導入作業(yè)？

Broker Load不支持再次執(zhí)行已經(jīng)成功執(zhí)行且處于FINISHED狀態(tài)的導入作業(yè)。而且，為了保證導入作業(yè)的不丟不重，每個執(zhí)行成功的導入作業(yè)的標簽（Label）均不可復用。可以使用SHOW LOAD命令查看歷史的導入記錄，找到想要再次執(zhí)行的導入作業(yè)，復制作業(yè)信息，并修改作業(yè)標簽后，重新創(chuàng)建一個導入作業(yè)并執(zhí)行。

Broker Load導入時出現(xiàn)內(nèi)容亂碼，該如何處理？

Reason: column count mismatch, expect=6 real=1. src line: [$交通]; zcI~跟團+v];   count mismatch, expect=6 real=2. src line: [租e?rD??食休閑娛樂

出現(xiàn)內(nèi)容亂碼是因為導入作業(yè)請求中的FORMAT AS參數(shù)指定錯誤。修改FORMAT AS參數(shù)取值，改為待導入數(shù)據(jù)文件對應的文件類型，然后重試導入作業(yè)。

Broker Load導入HDFS數(shù)據(jù)時，數(shù)據(jù)的導入日期字段出現(xiàn)異常，比正確的日期時間多加了8小時，該如何處理？

• 報錯原因

  StarRocks在建表時設置的timezone為中國時區(qū)，創(chuàng)建Broker Load導入作業(yè)時設置的timezone也是中國時區(qū)，而服務器設置的是UTC時區(qū)。因此，日期字段在導入時，比正確的日期時間多加了8小時。

• 解決方案

  建表時去掉timezone參數(shù)。

Broker Load導入ORC格式的數(shù)據(jù)時，報錯“ErrorMsg: type:ETL_RUN_FAIL; msg:Cannot cast '<slot 6>' from VARCHAR to ARRAY<VARCHAR(30)>”，該如何處理？

• 報錯原因

  待導入數(shù)據(jù)文件和Starrocks表兩側(cè)的列名不一致，執(zhí)行SET子句的時候系統(tǒng)內(nèi)部會有一個類型推斷，但是在調(diào)用cast函數(shù)執(zhí)行數(shù)據(jù)類型轉(zhuǎn)換的時候失敗了。

• 解決方案

  確保兩側(cè)的列名一致，這樣就不需要SET子句，也就不會調(diào)用cast函數(shù)執(zhí)行數(shù)據(jù)類型轉(zhuǎn)換，即可導入成功。

為什么Broker Load導入作業(yè)沒報錯，但是卻查詢不到數(shù)據(jù)？

Broker Load是一種異步的導入方式，創(chuàng)建導入作業(yè)的語句沒報錯，不代表導入作業(yè)成功了。您可以通過SHOW LOAD語句來查看導入作業(yè)的結果狀態(tài)和errmsg信息，然后修改導入作業(yè)的參數(shù)配置后，再重試導入作業(yè)。

報錯“failed to send batch或TabletWriter add batch with unknown id”，該如何處理？

該錯誤由數(shù)據(jù)寫入超時而引起。需要修改系統(tǒng)變量query_timeout和BE配置項streaming_load_rpc_max_alive_time_sec的參數(shù)值。BE配置項的更多信息，請參見參數(shù)配置。

報錯“LOAD-RUN-FAIL; msg:OrcScannerAdapter::init_include_columns. col name = xxx not found”，該如何處理？

如果導入的是Parquet或ORC格式的數(shù)據(jù)，則需要檢查文件頭的列名是否與StarRocks表中的列名一致。

(tmp_c1,tmp_c2)
SET
(
   id=tmp_c2,
   name=tmp_c1
)

如果導入的是Apache Hive版本直接生成的ORC文件，并且ORC文件中的表頭是 (_col0, _col1, _col2, ...)，則可能導致"Invalid Column Name"錯誤。此時需要使用SET子句設置列轉(zhuǎn)換規(guī)則。

導入作業(yè)長時間沒有結束等問題應該如何處理？

在FE上的日志文件fe.log中，根據(jù)導入作業(yè)的標簽來搜索導入作業(yè)的ID。然后，在BE上的日志文件be.INFO中，根據(jù)導入作業(yè)的ID來搜索上下文日志，進而查看具體原因。

如何配置以訪問高可用 (HA) 模式下的Apache HDFS集群？

(
    "username"="user",
    "password"="passwd",
    "dfs.nameservices" = "my-ha",
    "dfs.ha.namenodes.my-ha" = "my_namenode1,my_namenode2",
    "dfs.namenode.rpc-address.my-ha.my-namenode1" = "nn1-host:rpc_port",
    "dfs.namenode.rpc-address.my-ha.my-namenode2" = "nn2-host:rpc_port",
    "dfs.client.failover.proxy.provider" = "org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider"
)

HDFS集群的配置可以寫入hdfs-site.xml文件中，您使用Broker進程讀取HDFS集群的信息時，只需要填寫集群的文件路徑名和認證信息即可。

如何配置Hadoop ViewFS Federation？

需要將ViewFs相關的配置文件core-site.xml和hdfs-site.xml拷貝到broker/conf目錄中。

如果有自定義的文件系統(tǒng)，還需要將文件系統(tǒng)相關的.jar文件拷貝到broker/lib目錄中。

訪問Kerberos認證的集群時，報錯“Can't get Kerberos realm”，該如何處理？

1. 首先檢查是否所有的Broker所在的機器都配置了/etc/krb5.conf文件。

2. 如果配置了仍然報錯，則需要在Broker的啟動腳本中JAVA_OPTS變量的最后，加上-Djava.security.krb5.conf:/etc/krb5.conf。

使用INSERT INTO語句導入數(shù)據(jù)時，SQL每插入一條數(shù)據(jù)大約耗時50~100ms，能否優(yōu)化執(zhí)行效率？

因為INSERT INTO導入方式為批量寫入，所以單條寫入和批量寫入的耗時相同。因此OLAP場景下不建議使用INSERT INTO語句單條寫入數(shù)據(jù)。

使用INSERT INTO SELECT語句導入數(shù)據(jù)時，系統(tǒng)報錯“index channel has intoleralbe failure”，該如何解決？

該報錯是因為流式導入RPC超時導致。您可以通過在配置文件中調(diào)節(jié)RPC超時相關參數(shù)解決。

使用INSERT INTO SELECT語句導入大量數(shù)據(jù)時會執(zhí)行失敗，報錯“execute timeout”，該如何解決？

該報錯是因為Query超時導致。您可以通過調(diào)節(jié)Session變量query_timeout解決。該參數(shù)默認為600，單位為秒。

set query_timeout =xx;

執(zhí)行Flink job，報錯“Could not execute SQL statement. Reason:org.apache.flink.table.api.ValidationException: One or more required options are missing”，該如何解決？

• 報錯原因

  在StarRocks-migrate-tools（簡稱SMT）配置文件config_prod.conf中設置了多組規(guī)則[table-rule.1]、[table-rule.2]等，但是缺失必要的配置信息。

• 解決方案

  檢查是否給每組規(guī)則[table-rule.1]、[table-rule.2]等配置了database，table和Flink Connector信息。

Flink如何自動重啟失敗的Task？

Flink通過Checkpointing機制和重啟策略，自動重啟失敗的Task。

# unit: ms
execution.checkpointing.interval: 300000
state.backend: filesystem
state.checkpoints.dir: file:///tmp/flink-checkpoints-directory

如何手動停止Flink job，并且恢復Flink job至停止前的狀態(tài)？

您可以在停止Flink job時手動觸發(fā)Savepoint（Savepoint是依據(jù)Checkpointing機制所創(chuàng)建的流作業(yè)執(zhí)行狀態(tài)的一致鏡像），后續(xù)可以從指定Savepoint中恢復Flink job。

使用Savepoint停止作業(yè)。自動觸發(fā)Flink job ID的Savepoint，并停止該job。此外，您可以指定一個目標文件系統(tǒng)目錄來存儲Savepoint 。

bin/flink stop --type [native/canonical] --savepointPath [:targetDirectory] :jobId

./flink run -c com.starrocks.connector.flink.tools.ExecuteSQL -s savepoints_dir/savepoints-xxxxxxxx flink-connector-starrocks-xxxx.jar -f flink-create.all.sql

使用事務接口的exactly-once時，導入失敗，該如何解決？

• 問題描述：報錯信息如下。

  com.starrocks.data.load.stream.exception.StreamLoadFailException: {
      "TxnId": 3382****,
      "Label": "502c2770-cd48-423d-b6b7-9d8f9a59****",
      "Status": "Fail",
      "Message": "timeout by txn manager",--具體報錯信息
      "NumberTotalRows": 1637,
      "NumberLoadedRows": 1637,
      "NumberFilteredRows": 0,
      "NumberUnselectedRows": 0,
      "LoadBytes": 4284214,
      "LoadTimeMs": 120294,
      "BeginTxnTimeMs": 0,
      "StreamLoadPlanTimeMs": 7,
      "ReadDataTimeMs": 9,
      "WriteDataTimeMs": 120278,
      "CommitAndPublishTimeMs": 0
  }

• 原因分析：sink.properties.timeout小于Flink checkpoint interval，導致事務超時。

• 解決方式：需要調(diào)整該參數(shù)值大于Flink checkpoint interval。

flink-connector-jdbc_2.11 Sink到StarRocks時間落后8小時，該如何處理？

• 問題描述：Flink中l(wèi)ocalTimestamp函數(shù)生成的時間，在Flink中時間正常，Sink到StarRocks后發(fā)現(xiàn)時間落后8小時。已確認Flink所在服務器與StarRocks所在服務器時區(qū)均為Asia/ShangHai東八區(qū)。Flink版本為1.12，驅(qū)動為flink-connector-jdbc_2.11。

• 解決方式：可以在Flink sink表中配置時區(qū)參數(shù)'server-time-zone' = 'Asia/Shanghai'，同時在url參數(shù)里添加&serverTimezone=Asia/Shanghai。示例如下。

  CREATE TABLE sk (
      sid int,
      local_dtm TIMESTAMP,
      curr_dtm TIMESTAMP
  )
  WITH (
      'connector' = 'jdbc',
      'url' = 'jdbc:mysql://192.168.**.**:9030/sys_device?characterEncoding=utf-8&serverTimezone=Asia/Shanghai',
      'table-name' = 'sink',
      'driver' = 'com.mysql.jdbc.Driver',
      'username' = 'sr',
      'password' = 'sr123',
      'server-time-zone' = 'Asia/Shanghai'
  );

為什么沒有查詢時BE內(nèi)存處于打滿狀態(tài)，且CPU也是打滿狀態(tài)？

因為BE會定期收集統(tǒng)計信息，不會長期占用CPU，10 GB以內(nèi)的內(nèi)存使用完不會釋放，BE會自己管理，您可以通過tc_use_memory_min參數(shù)限制大小。

tc_use_memory_min，TCmalloc最小保留內(nèi)存。默認值10737418240，只有超過該值，StarRocks才將空閑內(nèi)存返還給操作系統(tǒng)。您可以在EMR控制臺StarRocks服務配置頁簽的be.conf中配置。BE配置項的更多信息，請參見參數(shù)配置。

為什么BE申請的內(nèi)存不會釋放給操作系統(tǒng)？

因為數(shù)據(jù)庫從操作系統(tǒng)獲得的大塊的內(nèi)存分配，在分配的時候會多預留，釋放時候會延后，為了重復利用，大塊內(nèi)存的分配的代價比較大。建議測試環(huán)境驗證時，對內(nèi)存使用進行監(jiān)控，在較長的周期內(nèi)觀察內(nèi)存是否能夠完成釋放。

為什么無法解析Flink Connector依賴？

• 原因分析：Flink Connector依賴需要通過阿里云鏡像地址來獲取。/etc/maven/settings.xml的mirror部分未配置全部通過阿里云鏡像獲取。

• 解決方式：修改阿里云公共倉庫地址為https://maven.aliyun.com/repository/public。

Flink-connector-StarRocks中sink.buffer-flush.interval-ms參數(shù)是否生效？

• 問題描述：sink.buffer-flush.interval-ms參數(shù)設置為15s，但是checkpoint interval=5mins，設置的sink.buffer-flush.interval-ms參數(shù)還生效嗎？

  +----------------------+--------------------------------------------------------------+
  |         Option       | Required |  Default   | Type   |       Description           |
  +-------------------------------------------------------------------------------------+
  |  sink.buffer-flush.  |  NO      |   300000   | String | the flushing time interval, |
  |  interval-ms         |          |            |        | range: [1000ms, 3600000ms]  |
  +----------------------+--------------------------------------------------------------+

• 解決方式：以下三個參數(shù)哪個先達到閾值，即觸發(fā)flush，和checkpoint interval設置的值沒關系，checkpoint interval對于Exactly once語義才有效，At Least Once語義用的是sink.buffer-flush.interval-ms。

  sink.buffer-flush.max-rows
  sink.buffer-flush.max-bytes
  sink.buffer-flush.interval-ms

使用DataX導入支持更新數(shù)據(jù)嗎？

當前版本中，主鍵模型已支持通過DataX更新數(shù)據(jù)。您需要在JSON配置文件的reader部分添加_op字段配置該功能。

使用DataX同步數(shù)據(jù)時，如何處理命名中使用的關鍵字，防止報錯？

您需要使用反引號（``）包圍相應的字段。

報錯“When running with master 'yarn' either HADOOP-CONF-DIR or YARN-CONF-DIR must be set in the environment”，該如何解決？

使用Spark Load時沒有在Spark客戶端的spark-env.sh中配置HADOOP-CONF-DIR環(huán)境變量。

提交Spark job時用到spark-submit命令，報錯“Cannot run program "xxx/bin/spark-submit": error=2, No such file or directory”，該如何解決？

使用Spark Load時spark_home_default_dir配置項沒有指定或者指定了錯誤的Spark客戶端根目錄。

報錯“File xxx/jars/spark-2x.zip does not exist”，該如何解決？

使用Spark Load時spark-resource-path配置項沒有指向打包好的ZIP文件，檢查指向文件路徑和文件名詞是否一致。

報錯“yarn client does not exist in path: xxx/yarn-client/hadoop/bin/yarn”，該如何解決？

使用Spark Load時yarn-client-path配置項沒有指定YARN的可執(zhí)行文件。

磁盤使用率超80%會進入安全模式，從而出現(xiàn)數(shù)據(jù)寫入報錯嗎？

• 問題描述：當集群中BE節(jié)點的磁盤使用率超過80%時，系統(tǒng)會自動進入安全模式，從而阻止新的數(shù)據(jù)寫入操作。此情況常見于進行大量刪除或更新操作后，由于trash目錄占用的空間過大而引發(fā)。

• 原因分析：

  • 執(zhí)行了大量的DELETE、DROP或INSERT OVERWRITE操作，導致產(chǎn)生了垃圾數(shù)據(jù)。而INSERT INTO操作不會直接導致trash目錄膨脹。

  • BE節(jié)點上的某個或某些磁盤使用率超過了預設的最大值（默認為80%）。

• 解決方式：

  1. 在實例配置頁面，搜索并修改以下兩個參數(shù)。

     說明

     如果沒有找到以下參數(shù)，請聯(lián)系售后支持以獲取幫助，他們可以幫助您開啟相應的設置權限。

     • safe_mode_check_disk_ratio：調(diào)整安全模式檢查閾值。將其從默認的0.8調(diào)整至0.9，即允許更高的磁盤使用率而不觸發(fā)安全模式。

     • trash_file_expire_time_sec：調(diào)整垃圾文件清理周期。將其從默認值調(diào)整為21600秒（等于6小時）。這樣可以更頻繁地清理不再需要的數(shù)據(jù)碎片。

  2. 若上述調(diào)整后情況仍未改善，考慮繼續(xù)提高safe_mode_check_disk_ratio的值或是擴大存儲容量。評估是否可以通過優(yōu)化查詢語句減少不必要的刪除和重寫動作，從而從根本上解決問題。

為什么通過Spark Connector讀取數(shù)據(jù)時出現(xiàn)被取消報錯？

• 問題描述：在使用Spark Connector讀取StarRocks數(shù)據(jù)時，出現(xiàn)了取消操作的錯誤。該錯誤通常是由于查詢時間過長，導致過期版本的數(shù)據(jù)被刪除。

• 原因分析：當查詢的執(zhí)行時間超過了系統(tǒng)設定的過期版本數(shù)據(jù)保留時間，涉及到的版本數(shù)據(jù)可能會被自動清理。因此，您在查詢過程中可能會因為缺少必要的數(shù)據(jù)而導致任務被取消。

• 解決方式：建議在實例配置頁面，調(diào)整參數(shù) lake_autovacuum_grace_period_minutes。該參數(shù)的默認值為30分鐘，可以根據(jù)實際查詢需求適當增大。例如，您可以將其設置為60分鐘或更長，以保證在長時間查詢時所需的數(shù)據(jù)不會被意外刪除。

Flink作業(yè)寫入StarRocks時報錯 "Caused by: Could not resolve host for client socket"

請嘗試在Flink作業(yè)中配置 sink.version=V1。如果未設置此參數(shù)，系統(tǒng)將默認使用V2版本，而V2當前存在一些不穩(wěn)定性和適配性問題。使用V1版本將能夠提供更為穩(wěn)定的性能。有關更多信息，請參見開源StarRocks相關文檔：Apache Flink。

在進行數(shù)據(jù)導入時，若主鍵索引占用的內(nèi)存超過限制，應如何處理？

您可以考慮以下優(yōu)化方案：

• 創(chuàng)建分區(qū)表：為主鍵模型的表設置分區(qū)，這樣在寫入數(shù)據(jù)時，可以避免全表的主鍵索引同時加載到內(nèi)存中，從而減小內(nèi)存的壓力。

• 開啟持久化主鍵索引：這將使主鍵索引在磁盤上持久化，減少內(nèi)存消耗。執(zhí)行以下SQL命令來開啟持久化主鍵索引。

       ALTER TABLE xxx SET ("enable_persistent_index"="true");

使用JindoSdk讀取OSS外表數(shù)據(jù)時報錯，該如何解決？

• 問題描述：在使用JindoSdk從OSS讀取StarRocks外表數(shù)據(jù)時遇到報錯。

• 原因分析：這通常是因為JindoSdk的pread實現(xiàn)與預期不符，導致讀取數(shù)據(jù)時出現(xiàn)問題。

• 解決方式：針對該問題，可以通過在實例配置頁面，調(diào)整配置文件jindosdk.cfg中的配置來優(yōu)化內(nèi)存緩沖區(qū)，減少錯誤的發(fā)生幾率。

  • fs.oss.memory.buffer.size.watermark：調(diào)大內(nèi)存緩沖區(qū)的水位線。建議將該值調(diào)整為0.6（默認值為0.3）。

  • fs.oss.memory.buffer.size.max.mb：增大最大內(nèi)存緩沖區(qū)。建議將該值設為6144（即6 GB，默認值為6144 MB）。

為什么在導入數(shù)據(jù)時磁盤空間使用率會異常上升？

• 問題描述：在使用StarRocks進行數(shù)據(jù)導入的過程中，發(fā)現(xiàn)磁盤空間使用率（尤其是標記為"other"的分區(qū)）出現(xiàn)異常增長。這種情況可能會影響系統(tǒng)的正常運行和性能。

• 可能原因：這種現(xiàn)象通常是由于導入過程中產(chǎn)生的臨時文件或廢棄文件未被及時清理所導致的，其中最常見的原因是回收站（trash）機制中的文件累積過多。

• 解決方式：建議調(diào)整trash_file_expire_time_sec參數(shù)來加速對回收站中不再需要文件的清理速度。此參數(shù)定義了文件在被徹底刪除前將在回收站中保留的時間長度（以秒為單位）。減小該值可以更快地釋放磁盤空間。

使用Spark Connector導入任務時事務處理慢，該如何解決？

• 問題描述：在使用阿里云EMR全托管StarRocks集群配合Spark Connector執(zhí)行數(shù)據(jù)導入任務時，如果遇到事務處理速度緩慢的情況，這通常是因為待處理的事務堆積到了系統(tǒng)默認設置的上限。這種情況會導致后續(xù)的數(shù)據(jù)導入操作效率大幅下降。

• 解決方式：可以通過將lake_enable_batch_publish_version的參數(shù)值設置為true來優(yōu)化性能。

導入數(shù)據(jù)時報錯“transmit chunk rpc failed”，該如何解決？

• 問題描述：導入數(shù)據(jù)時遇到如下錯誤信息。

  transmit chunk rpc failed [dest_instance_id=5a2489c6-f0d8-11ee-abf6-061aec******] [dest=172.17.**.**:8060]
  detail: brpc failed, error=Host is down, error_text=[E112]Not connected to 172.17.**.**:8060 yet,
  server_id=904 [R1][E112]Not connected to 172.17.**.**:8060 yet, server_id=904 [R2][E112]Not connected to 172.17.**.**:8060 yet, server_id=904 [R3][E112]Not connected to 172.17.**.**:8060 yet, server_id=904
  

• 可能原因：此錯誤通常表明RPC通信過程中出現(xiàn)了擁塞現(xiàn)象。

• 解決方式：您可以根據(jù)以下兩種方法來解決。

  • 調(diào)整未發(fā)送數(shù)據(jù)閾值 當前情況可能處于OVER CROWDED狀態(tài)，表示RPC源端有大量未發(fā)送的數(shù)據(jù)，超出了默認閾值。默認的 brpc_socket_max_unwritten_bytes 為 1GB，若未發(fā)送數(shù)據(jù)超過此值，則可能發(fā)生該錯誤。建議適當提高該值，以避免 OVER CROWDED 錯誤。

  • 增加RPC消息包大小 另一種情況是RPC的包大小超出了brpc_max_body_size的限制，默認值為2 GB。如果查詢中含有超大字符串或位圖類型數(shù)據(jù)，可能會導致此問題。建議通過增大BE參數(shù) brpc_max_body_size 來解決此問題。

執(zhí)行Stream Load時報錯“Cancelled because of runtime state is cancelled”，該如何解決？

• 問題描述：在不設置sink.buffer-flush.interval-ms參數(shù)的情況下執(zhí)行Stream Load時時，報錯“Cancelled because of runtime state is cancelled”。

• 可能原因：該問題通常出現(xiàn)在使用StarRocks進行數(shù)據(jù)加載的過程中。sink.buffer-flush.interval-ms參數(shù)定義了數(shù)據(jù)緩沖區(qū)刷新的時間間隔，即多久將累積的數(shù)據(jù)一次性寫入目標存儲中。如果不顯式地設置此參數(shù)，系統(tǒng)將采用其默認值。然而，默認值可能相對較大，這會導致數(shù)據(jù)在內(nèi)存中積累時間過長而沒有被及時處理或刷新到目的地，進而可能導致運行時狀態(tài)取消（如由于超時或其他資源限制），從而引發(fā)上述錯誤信息。

• 解決方式：建議您根據(jù)實際應用場景的需求，在代碼中明確指定sink.buffer-flush.interval-ms的值來覆蓋默認設置。這樣可以根據(jù)具體情況調(diào)整緩沖區(qū)刷新頻率，以確保更高效、穩(wěn)定的數(shù)據(jù)傳輸過程。