DataWorks:ノード開発の問題のトラブルシューティングと管理

チェック方法の選択

• 入力中の構文エラー — リアルタイム構文診断 (LSP) がリアルタイムで指摘します。

• 組み込みのガバナンスルール — ライブスキャンは、ノードの保存時に、効率的な組み込みルールをアクティブなノードに適用します。

• すべてのルールを網羅 — 手動でディープチェックをトリガーして、カスタム AI ルールを含むすべてのルールを適用します。単一ファイルまたは開いている複数のファイルを一括でスキャンできます。

設定項目の有効化

開発ワークフローに合わせて問題診断の設定を調整できます。すべての設定項目は、現在の Alibaba Cloud アカウントに対してのみ有効です。

DataStudio Governance Check Module Enablement は、データアセットガバナンスプラグインのチェック機能を制御し、SyntaxErrorEnable はリアルタイムの構文診断を制御します。この 2 つのオプションは、異なるレイヤーでコード品質をチェックします。両方を有効にすると、問題診断を完全に網羅できます。

1. DataWorks ワークスペースリストページに移動し、ターゲットワークスペースを選択し、[操作] 列で [クイックスタート] > [DataStudio] を選択します。

2. 左側のナビゲーションペインの下部にある設定項目をクリックし、設定項目ページでユーザータブをクリックします。

   次の表に設定項目を示します。

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

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

ルールライブラリの管理は、現在の Alibaba Cloud アカウントに対してのみ有効です。

1. DataStudio ページの左側メニューで、ガバナンスアイコン をクリックして、データ資産ガバナンスプラグインの設定を開きます。

2. データ資産管理 プラグインパネルの [組み込みルールライブラリ] セクションで、対象のガバナンスルールの横にあるトグルをクリックして、ルールを有効または無効にします。

   • 有効 (デフォルト)：ノードの保存時にルールが適用されます。

   • 無効：ノードの保存時にルールは適用されません。

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

組み込みルールではチーム固有のビジネスロジックやコーディング標準をカバーできない場合、データ資産ガバナンスプラグインのカスタムルールライブラリを使用して新しいチェックルールを定義できます。各ルールは自然言語で記述し、正しい例と誤った例を提示してください。

サポートされているカスタムルールシナリオ

手順

1. DataStudio ページの左側メニューで、ガバナンスアイコン をクリックして、データ資産ガバナンスプラグインの設定を開きます。

2. データ資産管理 プラグインパネルの [カスタムルールライブラリ] セクションで、[+] をクリックしてルールを作成します。

   DataWorks Copilot でガバナンスルールを生成するには、AI 生成 をクリックします。

3. ルールフィールドを設定してください。この例では、次のカスタムルールを作成します。

   • [ルール名]：Fact table updates must include WHERE

   • 重要度：警告レベルでは、開発中にのみ警告が表示され、エラーレベルでは、アラートがトリガーされ、デプロイ前にリリースがブロックされます。この例では、Warning を選択します。

   • スコープ: MaxCompute > MaxCompute SQL など、ルールが適用されるノードスコープを選択します。

   • 有効範囲：ユーザーレベル、ワークスペースレベル、テナントレベルがサポートされています。テナント管理者はテナントレベルのみ、ワークスペース管理者はワークスペースレベルのみ、一般メンバーはユーザーレベルオプションのみ表示できます。

   • [ルールの説明]：MaxCompute SQL の UPDATE ステートメントをチェックします。ステートメントが、名前が _f で終わるファクトテーブルを更新しているが WHERE 句がない場合、高リスクの問題として検出します。

   • 有効な例：

     • UPDATE my_project.order_detail_f SET status='shipped' WHERE order_id='123';

     • UPDATE my_project.order_detail_dim SET status='shipped';

   • 無効な例：UPDATE my_project.order_detail_f SET status='expired';

4. 保存 をクリックします。ルールはディープチェックで有効になります。

   カスタムガバナンスルールの使用を停止するには、そのルールにカーソルを合わせ、表示される無効化アイコン をクリックします。

ディープチェック

ディープチェックは、手動でトリガーする包括的で時間のかかるチェックです。カスタム AI ルールを含むすべてのガバナンスルールを適用します。対照的に、ノードを保存するときに実行されるライブスキャンは、効率的な組み込みルールにのみ適用されます。完全なルールセットに対してコードをチェックするには、ディープチェックを実行します。

単一ファイルをスキャンするには

現在エディターで開いているファイルをスキャンするには、エディターの上にある [deep check] をクリックします。エディターはファイルを詳細にスキャンし、残っている問題を報告します。

たとえば、「クイックスタート」のサンプルコードで、「パーティションテーブルのクエリにはパーティションを含める必要があります」の問題のみを修正した場合、スキャンは未解決の 「SQL でのテーブル作成は許可されていません」の問題を報告します。

複数のファイルを一括でスキャンするには

一括スキャンを開始する前に、以下の制限に注意してください。

• 一括チェックは、現在エディターで開いているファイルタブのみを対象とします。開いていないファイルは選択できません。

• 最大 5 ファイルまで選択できます。

• 一括チェック中は、一度に 1 つのディープチェックしか実行できません。

1. DataStudio ページの左側メニューで、ガバナンスアイコン をクリックして、データ資産ガバナンスプラグインの設定を開きます。

2. データ資産管理 プラグインパネルの ディープチェック セクションで、バッチチェック用のファイルとルールを選択し、ディープチェックを開始します。

   ディープチェックが完了すると、下部にある [ディープチェック] タブに結果が表示されます。たとえば、ファイル testassetrule のチェックでは、SQL でのテーブル作成は許可されていません [my_partitioned_table] (ルール ForbidUseCreateTable、7 行目、28 列目) と パーティション化されたテーブルのクエリにはパーティションを含める必要があります (ルール MissPartitionKeyFilter、17 行目、18 列目) という 2 つの警告が返されます。ルール名をクリックすると、その詳細が表示されます。

大規模言語モデルが各チェックルールについてどのように推論したかを確認するには、ディープチェック result ペインの右上隅にあるログを表示をクリックします。

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

リスク：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);

自動修正ロジック： Quick Fix がサポートされています。システムは不一致を検出し、いずれかのフィールドに 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 でのテーブル作成は許可されていません

リスク: スケジュールされた SQL タスクで CREATE TABLE を直接使用すると、テーブルの所有権が不明確になります。これは、テーブルが通常 Alibaba Cloud アカウントまたはスケジューリングアカウントに属するためです。これにより、管理コストが増加し、誤ったデータ削除のリスクが生じます。

誤ったコード例：

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}';

自動修正ロジック：部分的にサポートされます。プラグインは、スケジューリングパラメータフィルターが欠落している可能性のある場所を強調表示します。ビジネスロジックはさまざまであるため、要件に基づいて正しいフィルターを手動で追加してください。

これらのチェックはエディターのパフォーマンスやタスクの保存時間に影響しますか？

リアルタイム構文診断 (LSP) は、エディターのパフォーマンスにわずかですが許容範囲内の影響を与えます。データ資産ガバナンスプラグインはノードの保存時に実行されるため、保存操作にわずかな時間が追加されます。正確な所要時間は、コードの複雑さとルールの数によって異なります。明らかな遅延に気付いた場合は、ネットワーク環境を確認するか、テクニカルサポートにお問い合わせください。

問題診断は別途請求されますか？ また、DataWorks Copilot は必須ですか？

問題診断は DataWorks の基本機能であり、別途料金は発生しません。ただし、DataWorks Copilot の修正提案を使用する場合、「Data Agent の概要」に記載されている課金ルールが適用されます。Copilot を使用せずに手動で問題を修正することもできます。

機能を有効にしましたが、コード内の問題が検出されません。なぜですか？

次のようにトラブルシューティングしてください。

• メインスイッチの確認: 設定項目 > ユーザー で DataStudio Governance Check Module Enablement と SyntaxErrorEnable が有効になっていることを確認します。ナビゲーションパスと有効な値については、「設定項目を有効にする」をご参照ください。

• ルールスイッチの確認：[組み込みルールライブラリ] に移動し、適用したいルールが有効になっていることを確認します。手順については、「組み込みルールライブラリの管理」をご参照ください。

• ノードタイプの確認：現在のノードタイプがターゲットルールの範囲内にあるかどうかを確認してください。

• ネットワークの確認：ブラウザの開発者ツールでネットワークリクエストが失敗していないか確認してください。ネットワークの問題により、LSP サービスまたはガバナンスサービスがロードに失敗している可能性があります。

LSP サービスまたはガバナンスプラグインサービスが利用できない場合はどうなりますか？

バックエンドサービスが一時的に利用できない場合、問題診断はサイレントに失敗します。保存時にリアルタイムの構文プロンプトやガバナンスの問題は表示されませんが、コードの編集と保存は通常どおり機能します。ページを更新し、再度チェックをトリガーしてください。