DataWorks:リアルタイム同期の高度なパラメーター

パラメーター

値

デフォルト

説明

スコープ

Auto-set Runtime Configuration

true/false

true

• true（デフォルト）：システムは、CU 数に基づいて Concurrency などのパラメーターを自動的に設定します。ただし、合計 Concurrency がソースシャード数の整数倍でない場合、読み取りスレッド間でシャードの分布が不均等になり、データスキューが発生してパフォーマンスが低下する可能性があります。

• false：手動でのパラメーター構成を許可します。パフォーマンスボトルネックやデータスキューが発生した場合は、false を選択し、データ分布を最適化するようパラメーターを調整してください。

General

Global Flush Interval (seconds)

5 ～ 1000 の整数

60

すべての書き込みスレッドがキャッシュデータを宛先にバッチフラッシュし、同期オフセットを進める間隔を設定します。

• 値を大きくするとスループットは向上しますが、データ可視性レイテンシも増加します。

• 値を小さくするとデータ可視性レイテンシは減少しますが、スループットが低下する可能性があります。

推奨事項：レイテンシが主要な懸念事項でない大容量データ同期シナリオでは、この値を増やすことを検討してください。高リアルタイム性が求められるユースケースでは、この値を小さくしてください。

General

Failover Restart Policy Time Window (minutes)

1 ～ 60 の整数

30

同期タスクが回復可能な例外に遭遇した場合、システムはこのタイムウィンドウ内で自動再起動をトリガーするかどうかをチェックします。具体的には、ウィンドウ内の失敗回数がしきい値を超えたかどうかを確認します。

• 失敗回数がしきい値を超えていない場合、タスクは再起動され、ウィンドウ内の失敗カウンターがインクリメントされます。

• 失敗回数がしきい値を超えている場合、タスクは失敗とマークされ、再起動されません。

このパラメーターは、失敗回数をカウントする時間枠を定義します。短いウィンドウにすると、一時的かつ断続的な問題に対してシステムがより寛容になります。

General

Failover Restart Policy Failure Count Threshold

1 ～ 100 の整数

3

設定されたタイムウィンドウ内でタスクが自動再起動できる最大回数を指定します。

• 値を大きくすると、頻繁かつ断続的なエラーに対する許容度が向上します。

• 値を小さくすると、持続的な問題をより迅速に失敗としてマークし、リソースの浪費を防ぐことができます。

推奨事項：フォールトトレランスと問題検出の迅速性のバランスを取るため、比較的小さな値を設定してください。

General

Partition Cache Queue Size

5 ～ 100 の整数

5

MaxCompute の非 Delta パーティションテーブルに書き込む際、データはパーティション単位でキャッシュされます。Global Flush Interval で設定された時間ウィンドウ内に、同期タスクは宛先パーティションごとに個別のキャッシュを割り当てる必要があります。このパラメーターは、同時にキャッシュできるパーティションの最大数を制限します。

1 回のフラッシュ間隔内で書き込むパーティション数がこのキューのサイズを超える場合、システムは早期にグローバルフラッシュをトリガーしてすべてのキャッシュデータをコミットします。早期フラッシュが頻発すると、書き込み効率および全体的な同期パフォーマンスが著しく低下します。

推奨事項：Partition Cache Queue Size は、1 回の Global Flush Interval 内に書き込むことが想定される最大の異なるパーティション数よりも大きい値に設定し、早期フラッシュを回避してください。

同期タスクが遅延し、ログに uploader map size has reached uploaderMapMaximumSize というメッセージが含まれている場合、パーティションキャッシュの上限に達しています。スループットを向上させるために、このパラメーターを増やすことを検討してください。

クラスターの利用可能なリソースに基づき、この値を慎重に設定し、メモリ不足 (OOM) エラーを防止してください。

Writes to MaxCompute

Async Write Thread Pool Size

1 ～ 100 の整数

1

同期タスクが遅延しており、書き込み先がパフォーマンスボトルネックであると特定された場合、このパラメーターを増やすことで書き込みスループットを向上できます。たとえば、Log Service (Loghub) からの読み取りは MaxCompute への書き込みよりも高速であることが多いため、このようなケースでは書き込みスレッド数を増やすことでパイプラインのバランスを改善できます。

Writes to MaxCompute

Oversized Field Handling Rule

Do Not Process/Truncate/Set to Null

Do Not Process

MaxCompute では、単一フィールドの最大長がデフォルトで 8 MB に制限されています。このパラメーターは、同期中にこの制限を超えるフィールドを処理する戦略を定義します。

• Do Not Process：タスクは、サイズ超過フィールドをそのまま書き込もうとします。フィールド長が MaxCompute の制限（デフォルト 8 MB）を超えており、かつその制限を変更していない場合、同期タスクは失敗します。

• Truncate：フィールドは、書き込み前に許容される最大長（8 MB）に切り捨てられます。

• Set to Null：サイズ超過フィールドの内容は破棄され、代わりに NULL 値が書き込まれます。

Writes to MaxCompute

Real-time Task Session Cache Size (bytes)

正の整数

67108864 (64 MB)

MaxCompute Delta テーブルにデータを書き込む際、宛先パーティションごとにセッションが作成されます。非パーティションテーブルの場合は、1 つのグローバルセッションが作成されます。各セッションには複数のバケットが含まれ、その数はテーブル作成時に定義されます。同期タスクは、各バケットのデータをキャッシュします。1 つのセッション内のすべてのバケットにわたるキャッシュデータの合計サイズがこの値（バイト単位）を超えると、システムはそのセッションから MaxCompute サーバーへの全データのバッチコミットをトリガーします。

Writes to MaxCompute

Real-time Task Bucket Cache Size (bytes)

正の整数

1048576 (1 MB)

MaxCompute Delta テーブルにデータを書き込む際、宛先パーティションごとにセッションが作成されます（非パーティションテーブルの場合は 1 つのグローバルセッション）。各セッションは複数のバケットに分割されます。同期タスクは、各バケットに独立したキャッシュを割り当てます。1 つのバケット内のキャッシュデータ量がこの値（バイト単位）を超えると、その特定のバケットのデータが MaxCompute サーバーにコミットされます。

Writes to MaxCompute

Dynamic Disk Write Threshold

正の整数

None

このパラメーターは、MaxCompute Delta テーブルにデータを書き込む際に適用されます。保留中のデータを持つ宛先パーティション数がこのしきい値を超えると、バケットキャッシュがメモリからディスクにオフロードされ、メモリ消費量が削減されます。この機能を有効にすると同期パフォーマンスが低下するため、タスクが非常に多数のパーティションに書き込む必要があり、メモリ負荷が過剰になる場合にのみ使用してください。

Writes to MaxCompute

Single-table Flush Concurrency

正の整数

2

MaxCompute Delta テーブルにデータを書き込む際、このパラメーターは 1 つのセッションから MaxCompute サーバーに同時にフラッシュできるバケット数を決定します。ほとんどのケースで、このパラメーターを変更する必要はありません。

Writes to MaxCompute

Data Partitioning Strategy

Primary key value/Table partition field value

Primary key value

書き込み Concurrency が 1 より大きい状態で MaxCompute Delta テーブルにデータを書き込む場合、データ整合性を確保するために Data Partitioning Strategy を構成する必要があります。この戦略は、ソースレコードを並列ライターインスタンス間にどのように分散するかを決定します。

• Primary key value による分散：同じプライマリキーを持つレコードは常に同じライターインスタンスにルーティングされます。

  • 利点：プライマリキーは多くの場合均等に分布しているため、データスキューを防ぎ、インスタンス間の書き込み負荷を均等に保つのに役立ちます。

  • 欠点：各ライターは宛先パーティションごとに独立したキャッシュを維持する必要があります。このアプローチはメモリを多く消費し、メモリ ≈ Concurrency × パーティション数 × キャッシュオーバーヘッド で計算され、OOM エラーを引き起こす可能性があります。

• Table partition field value による分散：同じ宛先パーティションに属するレコードは、同じライターインスタンスによって処理されます。

  • 利点：ライターインスタンスは特定のパーティションのキャッシュを共有できるため、全体的なメモリ使用量を大幅に削減できます。

  • 欠点：データがパーティション間で不均等に分布している場合（例：ホットパーティションがある場合）、一部のインスタンスが過負荷になり、他のインスタンスがアイドル状態になるライターデータスキューが発生する可能性があります。

構成に関する推奨事項：

1. ほとんどのシナリオで最適なパフォーマンスと負荷分散を実現するため、Primary key value 戦略を優先してください。同期タスクがキャッシュサイズ過大による OOM エラーで失敗する場合は、メモリ負荷を軽減するために Table partition field value 戦略に切り替えてください。

2. 戦略を切り替える前に、パーティション間のデータ分布を評価し、新たなパフォーマンスボトルネックを導入しないようにしてください。

Writes to MaxCompute

Concurrency per Worker

1 ～ 100 の整数

CU 数に応じて変動

同期タスクの合計 Concurrency は、Worker あたりの Concurrency × Worker 数 で計算されます。この値を調整することでデータスキューに対処できます。たとえば、ソースが Log Service (Loghub) Logstore の場合、合計 Concurrency は理想的には (最高シャード ID - 最低シャード ID) + 1 と等しくなるべきです。

Worker 内でのスレッドスケジューリングによるオーバーヘッドを軽減するため、Worker あたりの Concurrency は 10 未満に設定することを推奨します。

General

Number of Workers

1 ～ 100 の整数

CU 数に応じて変動

同期タスクの合計 Concurrency は、Worker あたりの Concurrency × Worker 数 で計算されます。1 つの Worker に過剰な CU を割り当てると、リソーススケジューリングの遅延が長くなる可能性があります。各 Worker に 10 CU 以下が割り当てられるように Worker 数を構成することを推奨します。

General