メインコンテンツまでスキップ

Data loading

データのロード

1. "close index channel failed" または "too many tablet versions" エラーが発生した場合はどうすればよいですか？​

頻繁にロードジョブを実行しており、データが適切なタイミングで整理されていません。その結果、ロード中に生成されるデータバージョンの数が、許容される最大数（デフォルトで1000）を超えています。以下のいずれかの方法を使用して、この問題を解決します。

  • 各個別のジョブでロードされるデータ量を増やし、ロード頻度を減らすことで、データの整理時間を短縮します。
  • 各バックエンド（BE）のBE設定ファイル be.conf の設定項目を以下のように変更し、データの整理を高速化します： 
    cumulative_compaction_num_threads_per_disk = 4
    base_compaction_num_threads_per_disk = 2
    cumulative_compaction_check_interval_seconds = 2
    上記の設定項目を変更した後は、メモリとI/Oが正常であることを確認するため、監視する必要があります。

2. "Label Already Exists" エラーが発生した場合はどうすればよいですか？​

このエラーは、同じラベルを持つロードジョブが、同じStarRocksデータベース内で既に正常に実行されているか、実行中であるために発生します。

StreamロードジョブはHTTPによって送信されます。一般的に、プログラム言語のHTTPクライアントにはリクエストの再試行ロジックが組み込まれています。StarRocksクラスタがHTTPクライアントからのロードジョブリクエストを受け取ると、すぐにリクエストを処理するが、HTTPクライアントに対してジョブの結果を適時に返さないため、HTTPクライアントは同じロードジョブリクエストを再度送信します。しかし、StarRocksクラスタは既に最初のリクエストを処理しているため、2番目のリクエストに対して Label Already Exists エラーを返します。

異なるロード方法を使用して送信されたロードジョブが同じラベルを持ち、繰り返し送信されていないことを確認するために、次の手順を実行します：

  • FEログを表示し、失敗したロードジョブのラベルが2回記録されていないか確認します。ラベルが2回記録されている場合、クライアントがロードジョブリクエストを2回送信しています。

    注意

    StarRocksクラスタは、ロードジョブのラベルをロード方法に基づいて区別しません。したがって、異なるロード方法を使用して送信されたロードジョブは、同じラベルを持つ場合があります。

  • SHOW LOAD WHERE LABEL = "xxx" を実行して、同じラベルを持つ状態が FINISHED にあるロードジョブを確認します。

    注意

    xxx は確認したいラベルです。

ロードジョブを送信する前に、データのロードに必要な時間の概算を行い、クライアント側のリクエストタイムアウト期間を適切に調整することをおすすめします。これにより、クライアントがロードジョブリクエストを複数回送信することを防ぐことができます。

3. "ETL_QUALITY_UNSATISFIED; msg:quality not good enough to cancel" エラーが発生した場合はどうすればよいですか？​

SHOW LOAD を実行し、返された実行結果のエラーURLを使用してエラーの詳細を表示します。

一般的なデータ品質エラーは以下の通りです：

  • "convert csv string to INT failed."（CSV文字列をINTに変換できませんでした）ソースカラムの文字列が、一致する宛先カラムのデータ型に変換できませんでした。たとえば、abc が数値に変換できませんでした。
  • "the length of input is too long than schema."（入力の長さがスキーマよりも長いです）ソースカラムの値が、テーブル作成時に指定された宛先カラムの最大長を超えた長さです。たとえば、CHARデータ型のソースカラムの値が、指定された最大長を超えている場合、またはINTデータ型のソースカラムの値が4バイトを超える場合などです。
  • "actual column number is less than schema column number."（実際のカラム数がスキーマのカラム数よりも少ないです）指定されたカラムセパレータを基にソース行が解析されると、取得されるカラム数が宛先テーブルのカラム数よりも少ないです。ロードコマンドやステートメントで指定されたカラムセパレータが、実際にその行で使用されたカラムセパレータと異なる場合があります。
  • "actual column number is more than schema column number."（実際のカラム数がスキーマのカラム数よりも多いです）指定されたカラムセパレータを基にソース行が解析されると、取得されるカラム数が宛先テーブルのカラム数よりも多いです。ロードコマンドやステートメントで指定されたカラムセパレータが、実際にその行で使用されたカラムセパレータと異なる場合があります。
  • "the frac part length longer than schema scale."（小数部の長さがスキーマのスケールよりも長いです）DECIMAL型のソースカラムの小数部分の桁数が指定された長さを超えています。
  • "the int part length longer than schema precision."（整数部の長さがスキーマの精度よりも長いです）DECIMAL型のソースカラムの整数部分の桁数が指定された長さを超えています。
  • "there is no corresponding partition for this key."（このキーに対応するパーティションがありません）ソース行のパーティション列の値がパーティション範囲に含まれていません。

4. RPCのタイムアウトが発生した場合はどうすればよいですか？​

各バックエンド（BE）のBE設定ファイル be.conf の write_buffer_size 設定項目を確認してください。この設定項目は、BEごとのメモリブロックあたりの最大サイズを制御するために使用されます。デフォルトの最大サイズは100 MBです。最大サイズが非常に大きい場合、Remote Procedure Call（RPC）がタイムアウトする可能性があります。この問題を解決するには、BE設定ファイルの write_buffer_size と tablet_writer_rpc_timeout_sec 設定項目の設定を調整します。詳細については、BE configurations を参照してください。

5. "Value count does not match column count" エラーが発生した場合はどうすればよいですか？​

ロードジョブが失敗した後、ジョブ結果で返されたエラーURLを使用してエラーの詳細を取得しましたが、「Value count does not match column count」というエラーが発生しました。これは、ソースデータファイルの列数と、宛先のStarRocksテーブルの列数が一致しないことを示しています：

Error: Value count does not match column count. Expect 3, but got 1. Row: 2023-01-01T18:29:00Z,cpu0,80.99
Error: Value count does not match column count. Expect 3, but got 1. Row: 2023-01-01T18:29:10Z,cpu1,75.23
Error: Value count does not match column count. Expect 3, but got 1. Row: 2023-01-01T18:29:20Z,cpu2,59.44

この問題の原因は次のとおりです：

ロードコマンドやステートメントで指定されたカラムセパレータが、ソースデータファイルで実際に使用されているカラムセパレータと異なります。前述の例では、CSV形式のデータファイルは3つの列から構成されており、カンマ（,）で区切られています。しかし、ロードコマンドやステートメントでカラムセパレータとして \t が指定されています。その結果、ソースデータファイルから取得された3つの列が誤って1つの列に解析されました。

ロードコマンドやステートメントでカンマ（,）をカラムセパレータとして指定し、ロードジョブを再度送信してください。