DataWorks:ノードの問題の診断とガバナンス

構成設定

プリファレンスに基づいて問題診断機能を構成します。すべての構成設定は、現在ログインしているアカウントにのみ適用されます。

1. DataWorks ワークスペースリストページに移動し、対象のワークスペースを見つけて、[操作] > [クイックアクセス] > [DataStudio] をクリックします。

2. 左側のナビゲーションウィンドウの下部にある > Setup をクリックし、Setup ページの User タブに移動します。

組み込みルールライブラリの管理

データ資産ガバナンスプラグインのチェック動作は、ルールライブラリによって駆動されます。ルールライブラリは、組み込みルールとカスタムルールに分かれています。必要に応じて特定のルールを有効または無効にできます。

1. DataStudio ページの左側のナビゲーションウィンドウで、ガバナンスアイコン をクリックして、データ資産ガバナンスプラグインの構成を開きます。

2. Data Asset Governance プラグインパネルの [組み込みルールライブラリ] セクションで、対象のガバナンスルールを見つけ、その横にあるトグルアイコンをクリックしてルールを有効化または無効化します。

   • 有効 (デフォルト)：ノードを保存する際にルールがチェックされます。

   • 無効：ノードを保存する際にルールはチェックされません。

カスタムルールライブラリ

組み込みルールがチームの特定のビジネスロジックやコーディング標準を満たせない場合、データ資産ガバナンスプラグインはカスタムルールライブラリを提供します。自然言語による説明と正常/異常例を使用して、新しいチェックルールを定義できます。

詳細スキャン

クイックスタートセクションで述べた単一ファイルのスキャンに加えて、バッチ詳細スキャンもサポートされています。

1. DataStudio ページの左側のナビゲーションウィンドウで、ガバナンスアイコン をクリックして、データ資産ガバナンスプラグインの構成を開きます。

2. Data Asset Governance プラグインパネルの [詳細検査] セクションで、バッチでスキャンするファイルと適用するルールを選択し、詳細スキャンを開始します。

   重要

   • バッチスキャンの範囲は、現在エディターで開いているファイルタブに限定されます。最大 5 つのファイルを選択できます。開いていないファイルは選択できません。

   • バッチスキャン中は、一度に 1 つの詳細スキャンしか実行できません。

   

3. [詳細検査] 結果ペインで、右上隅にある View Log をクリックすると、大規模言語モデルによるチェックルールの詳細な判定プロセスを表示できます。

パーティションテーブルのクエリにはパーティションフィルターを含める必要がある

• リスク説明：パーティションを指定せずに MaxCompute パーティションテーブルをクエリすると、フルテーブルスキャンがトリガーされ、大量の計算リソースを消費し、高額なコストが発生します。

• 不正なコード例：

  SELECT user_id, order_amount
  FROM user_orders
  WHERE status = 'paid';

• 正しいコード例：

  SELECT user_id, order_amount
  FROM user_orders
  WHERE status = 'paid'
  AND pt = '${bizdate}'; -- パーティションフィルター条件を追加

• 自動修正ロジック：クイック修正がサポートされています。システムは自動的に WHERE 句に AND pt = '${bizdate}' などのパーティション条件を追加します。

再実行が有効な INSERT INTO は許可されない

• リスク説明：SQL タスクに INSERT INTO ロジックのみが含まれ、スケジュール設定で再実行が許可されている場合、再実行のたびにターゲットテーブルにデータが追加され、データ重複が発生しやすく、データの精度が損なわれる可能性があります。

• 不正なコード例：

  -- タスクプロパティを「再実行可能」に設定
  INSERT INTO target_table SELECT * FROM source_table;

• 正しいコード例：

  -- タスクプロパティを「再実行可能」に設定
  INSERT OVERWRITE TABLE target_table SELECT * FROM source_table;

• 自動修正ロジック：クイック修正がサポートされています。システムは INSERT INTO を INSERT OVERWRITE に変更し、再実行時にデータが追加されるのではなく上書きされるようにします。

JOIN 列の型は一致する必要がある

• リスク説明：MaxCompute SQL では、JOIN 操作で列の型が一致しないと、暗黙的な型変換が発生し、計算エラー、パフォーマンスの低下、データ品質の問題につながる可能性があります。

• 不正なコード例：

  -- a.user_id は BIGINT、b.uid は STRING
  SELECT * FROM table_a a JOIN table_b b ON a.user_id = b.uid;

• 正しいコード例:

  -- a.user_id は BIGINT、b.uid は STRING です
  SELECT * FROM table_a a JOIN table_b b ON a.user_id = CAST(b.uid AS BIGINT);

• 自動修正ロジック：クイック修正がサポートされています。システムは自動的に検出し、CAST 関数を使用して一方の列に明示的な型変換を適用し、もう一方の列の型と一致させます。

現在のプロジェクト外のテーブルへの INSERT

• リスク説明：プロジェクト A のタスクからプロジェクト B のテーブルにデータを書き込むことは、高リスク操作です。これにより、プロジェクトの分離が損なわれ、不正なデータアクセスやデータ漏洩につながる可能性があります。

• 不正なコード例：

  -- project_A 内のタスクで実行
  INSERT INTO project_B.some_table SELECT * FROM my_table;

• 正しいコード例：

  -- 推奨されるアプローチ：データはテーブルの所有プロジェクト (project_B) に属するタスクによって書き込まれるべきです。
  -- project_A でこの操作を避けてください。

• 自動修正ロジック：自動修正はサポートされていません。ビジネス要件に基づいてデータ同期パイプラインを調整し、データがターゲットプロジェクト自身のタスクによって書き込まれるようにする必要があります。

定期タスクは開発環境のテーブルに書き込んではならない

• リスク説明：本番環境の定期タスクが開発環境のテーブルにデータを書き込むと、データ保護レベルが低下し、データセキュリティリスクが生じます。

• 不正なコード例：

  -- 本番環境 (PROD) のタスクで実行
  INSERT OVERWRITE TABLE user_dev.temp_data SELECT * FROM user_prod.source_data;

• 正しいコード例：

  -- 本番タスクは本番環境のテーブルに書き込むべきです
  INSERT OVERWRITE TABLE user_prod.result_data SELECT * FROM user_prod.source_data;

• 自動修正ロジック：自動修正はサポートされていません。データフローが環境分離基準に準拠するように、ターゲットテーブルを手動で変更する必要があります。

SQL での CREATE TABLE は許可されない

• リスク説明：定期 SQL タスクで CREATE TABLE を直接使用すると、テーブルの所有権が不明確になり (通常、テーブルはプライマリアカウントまたはスケジューリングアカウントによって所有されます)、管理コストが増加し、偶発的なデータ削除のリスクが生じます。

• 不正なコード例：

  CREATE TABLE my_temp_table (id INT);
  INSERT INTO my_temp_table VALUES (1);

• 正しいコード例：

  -- テーブルは DataWorks のテーブル管理モジュールで事前に作成し、SQL タスクで直接使用する必要があります。
  INSERT INTO my_temp_table VALUES (1);

• 自動修正ロジック：自動修正はサポートされていません。DataWorks のメタデータ管理でテーブルを作成するか、特定のシナリオでエラーを回避するために CREATE TABLE IF NOT EXISTS を使用することを推奨します。

スケジューリングパラメーターの欠落チェッカー

• リスク説明：定期スケジューリングタスクの主な目的は、時間ディメンションによってデータを増分処理することです。WHERE 条件にスケジューリングパラメーター (例：${bizdate}) が欠落している場合、タスクは毎日全データを処理したり、誤った日付範囲を処理したりする可能性があり、データの欠落、不整合、および大幅なリソースの浪費につながります。

• 不正なコード例：

  -- エラー：スケジューリングパラメーターが欠落しており、日次増分処理ができない
  INSERT OVERWRITE TABLE users_active_today PARTITION (pt = '${bizdate}')
  SELECT    user_id  FROM    login_log; -- WHERE pt = '...' が欠落

• 正しいコード例：

  -- 正しい：スケジューリングパラメーターをフィルター条件として使用し、日次増分処理を実現
  INSERT OVERWRITE TABLE users_active_today PARTITION (pt = '${bizdate}')
  SELECT    user_id FROM    login_log
  WHERE    pt = '${bizdate}';

• 自動修正ロジック：自動修正は完全にはサポートされていません。プラグインは欠落している可能性のあるスケジューリングパラメーターフィルターをハイライトしますが、ビジネスロジックの複雑さのため、実際の要件に基づいて正しいフィルター条件を手動で追加することを推奨します。