自動データ品質の概要

Knowledge Catalog（旧称 Dataplex Universal Catalog）を使用すると、BigQuery と Iceberg REST Catalog のテーブル内のデータの品質を定義して測定できます。データスキャンを自動化して、定義済みルールに照らしてデータを検証し、データが品質要件を満たしていない場合はアラートを記録できます。自動データ品質を使用すると、データ品質ルールとデプロイメントをコードとして管理することで、データ プロダクション パイプラインの完全性を向上させることができます。

データの異常をスキャンするには、Knowledge Catalog データ プロファイル スキャンをご覧ください。スキャンでデータ品質ルールを生成できます。組み込みの品質ルールを使用することも、カスタムルールを作成することもできます。

Knowledge Catalog には、自動データ品質と統合されたモニタリング、トラブルシューティング、Cloud Logging アラートが用意されています。

概念モデル

データ品質のスキャンでは、テーブルデータに品質ルールを適用し、結果を報告します。

データ品質スキャンは、一連の組み込みルールに対してデータを検証する Knowledge Catalog データスキャンの一種です。データ スキャンは、BigQuery と Cloud Storage（BigQuery 外部テーブル経由）からデータをサンプリングして、さまざまなタイプのメタデータを推測する Knowledge Catalog ジョブです。自動データ品質を使用してテーブルの品質を測定するには、data quality タイプの DataScan オブジェクトを作成します。スキャンは 1 つの BigQuery テーブルでのみ実行されます。スキャンでは Google のテナント プロジェクトのリソースを使用するため、独自のインフラストラクチャを設定する必要はありません。

データ品質スキャンの作成と使用は、次の手順から成ります。

  1. データ品質ルールを定義する
  2. ルールの実行を構成する
  3. データ品質スキャンの結果を分析する
  4. モニタリングとアラートを設定する
  5. データ品質エラーのトラブルシューティング

ルールの定義

データ品質スキャンに関連付けられたデータ品質ルールは、データの期待値を定義します。データ品質ルールは次の方法で作成できます。

組み込みルール

Knowledge Catalog は、次のカテゴリの組み込みルールをサポートしています。

行レベル

行レベルのカテゴリルールの場合、期待値は各データ行に対して適用されます。各行は独立して条件に合格または不合格になります（例: column_A_value < 1）。

行レベルのチェックでは、合格のしきい値を指定する必要があります。ルールに合格する行の割合がしきい値を下回ると、ルールは不合格となります。

集計

集計ルールの場合、データ全体で集計された単一の値に対して期待値が適用されます（例: Avg(someCol) >= 10）。合格するには、チェックの評価がブール値 true になる必要があります。集計ルールは、行ごとに独立して合格や不合格の回数を示すものではありません。

どちらのルールカテゴリでも、次のパラメータを設定できます。

次の表では、サポートされている行レベルと集計ルールの種類を示します。

ルールタイプ
（ Google Cloud コンソールでの名前）		 行レベルルールまたは集計ルール 説明 サポートされている列の型 ルール固有のパラメータ
RangeExpectation
（範囲チェック）		 行レベル 値が min と max の範囲内にあるかどうかを確認します。 すべての数値型、日付型、タイムスタンプ型の列。 必須:
  • しきい値に合格する割合
  • min または max の値: 少なくとも 1 つの値を指定します。
省略可:
  • strict min を有効にする: 有効にすると、ルールチェックで「>=」ではなく「>」が使用されます。
  • strict max を有効にする: 有効にすると、ルールチェックで「<=」ではなく「<」が使用されます。
  • ignore null を有効にする: 有効にすると、ルールチェックで null 値が無視されます。
NonNullExpectation
（NULL チェック）		 行レベル 列の値が NULL でないことを確認します。 サポートされているすべての列の型。 必須:
  • しきい値に合格する割合。
SetExpectation
（セットのチェック）		 行レベル 列の値が、セット内の指定された値のいずれかであるかどうかを確認します。 サポートされているすべての列の型（Record と Struct を除く）。 必須:
  • 照合する文字列値のセット。
  • しきい値に合格する割合。
省略可:
  • ignore null を有効にする: 有効にすると、ルールチェックで null 値が無視されます。
RegexExpectation
（正規表現チェック）		 行レベル 指定された正規表現と値を照合します。 文字列 必須:
  • チェックに使用する正規表現パターン。
  • しきい値に合格する割合。
  • 注: GoogleSQL は、re2 ライブラリを使用した正規表現をサポートしています。正規表現の構文については、該当するドキュメントをご覧ください。
省略可:
  • ignore null を有効にする: 有効にすると、ルールチェックで null 値が無視されます。
Uniqueness
（一意性チェック）		 集計 列内のすべての値が一意かどうかを確認します。 サポートされているすべての列の型（Record と Struct を除く）。 必須:
  • サポートされているパラメータの列とディメンション。
省略可:
  • ignore null を有効にする: 有効にすると、ルールチェックで null 値が無視されます。
StatisticRangeExpectation
（統計情報のチェック）		 集計 指定された統計測定値が範囲の期待値と一致しているかどうかを確認します。 サポートされているすべての数値列の型。 必須:
  • mean、min、または max の値: 少なくとも 1 つの値を指定します。
省略可:
  • strict min を有効にする: 有効にすると、ルールチェックで「>=」ではなく「>」が使用されます。
  • strict max を有効にする: 有効にすると、ルールチェックで「<=」ではなく「<」が使用されます。

サポートされているカスタム SQL ルールの種類

SQL ルールを使用すると、カスタム ロジックで検証を柔軟に拡張できます。これらのルールには次の種類があります。

ルールの種類 行レベルルールまたは集計ルール 説明 サポートされている列の型 ルール固有のパラメータ 例
行の条件 行レベル WHERE 句で SQL 式を定義して、各行の期待値を指定します。SQL 式は、行ごとに true（合格）または false（不合格）を評価する必要があります。

Knowledge Catalog は、この期待値に合格した行の割合を計算し、この値を合格しきい値の割合と比較して、ルールの成功または失敗を決定します。

この式は、たとえば参照整合性チェックを行うために、別テーブルへの参照を含めることができます。		 すべての列 必須:
  • 使用する SQL 条件
  • しきい値に合格する割合
  • ディメンション
省略可:
  • このルールを関連付ける列。
 grossWeight <= netWeight
テーブル条件
（集計 SQL 式）		 集計 これらのルールはテーブルごとに 1 回実行されます。ブール値の true（合格）または false（不合格）と評価される SQL 式を指定します。

SQL 式には、式サブクエリを使用して別のテーブルへの参照を含めることができます。		 すべての列 必須:
  • 使用する SQL 条件
  • ディメンション
省略可:
  • このルールを関連付ける列
 簡単な集計の例:
avg(price) > 100
式サブクエリを使用して、別のテーブル全体で値を比較する:
(SELECT COUNT(*) FROM `example_project.example_dataset.different-table`) < COUNT(*)
SQL アサーション 集計 アサーション ルールは、データ品質クエリを使用して、クエリで指定された 1 つ以上の条件を満足しない行を見つけます。無効な状態に一致する行を返すように評価される SQL ステートメントを指定します。クエリで行が返された場合、ルールは不合格となります。

SQL ステートメントの末尾のセミコロンを省略します。SQL ステートメントには、式サブクエリを使用して別のテーブルへの参照を含めることができます。		 すべての列 必須:
  • 無効な状態を確認する SQL ステートメント
  • ディメンション
省略可:
  • このルールを関連付ける列。
 discount_pct が 100 より大きくならないようにする簡単な集計の例:
SELECT * FROM example_project.example_dataset.table WHERE discount_pct > 100

式サブクエリを使用して、別のテーブル全体で値を比較する:
SELECT * FROM `example_project.example_dataset.different-table` WHERE gross_weight > (SELECT avg(gross_weight) FROM `example_project.example_dataset.different-table`)

ルールの例については、自動データ品質のサンプルルールをご覧ください。

サポートされている SQL 関数については、GoogleSQL リファレンスをご覧ください。

データ品質ルールを再利用する

Knowledge Catalog のデータ品質ルールを再利用して、ルール テンプレートを使用することで、複数のデータ品質ルール間で複雑なビジネスルール定義や標準化されたビジネスルール定義を共有できます。たとえば、メールの検証や 2 つのテーブル間の外部キーの検証を行うルール テンプレートを作成し、それらのテンプレートをデータスキャン全体で再利用できます。

ルールの再利用性には、次の主な機能があります。

  • データ品質ルール テンプレート: 複数のデータ品質ルールで共有できる複雑なビジネスルール定義や標準化されたビジネスルール定義を保存するカスタムルール テンプレートを作成します。data-quality-rule-template エントリを作成し、それに data-quality-rule-template アスペクトを追加して、テンプレート ロジックを定義します。
  • メタデータとしてのデータルール: BigQuery テーブルやビジネス用語集の用語などのエントリで、データ品質ルールを Knowledge Catalog のアスペクトとして宣言します。data-rules アスペクト タイプを使用して、これらのルールをエントリに適用します。
  • システムルール テンプレート: 一般的に使用されるルールには、システムルール テンプレートを使用します。

詳細については、データ品質ルールを再利用するをご覧ください。

ディメンション

ディメンションを使用すると、モニタリングとアラートに対する複数のデータ品質ルールの結果を集計できます。すべてのデータ品質ルールをディメンションに関連付ける必要があります。Knowledge Catalog には、次のディメンションが用意されています。

鮮度
鮮度は、データが最後に更新された日時を測定します。この情報は、データが有用なほど新しいかどうかを判断するのに役立ちます。
ボリューム
ボリュームは、想定されるデータがすべて存在するかどうかを測定します。
完全性
完全性では、データに目的に必要な情報がすべて含まれているかどうかを評価します。
有効性
有効性は、データが形式、許容範囲、その他の条件に関する組み込みの標準に準拠しているかどうかを評価します。たとえば、有効な日付の形式が YYYY/mm/dd である場合、08-12-2019 は無効なデータです。別の例として、商品の有効な販売価格が 10～20 ドルの場合、販売価格が 100 ドルは無効なデータです。
整合性
整合性とは、テーブルや列など、複数のインスタンスでデータの値が同じであることを指します。データの不整合は、たとえば、商品の収益が販売データベースまたは使用状況データベースから読み取られたときに異なる場合に発生します。
精度
精度はデータの正しさを表します。有効なデータは必ずしも正確であるとは限りません。たとえば、有効な髪の色が茶色だとして、ある人が茶色の髪を持っていない場合、不正確なデータとなります。
一意性
一意性は、データが重複なく一意かどうかを測定します。

ルールで入力された入力

すべての値パラメータは、文字列値として API に渡されます。Knowledge Catalog では、BigQuery で指定された形式に従った入力が必要です。

バイナリ型のパラメータは、base64 でエンコードされた文字列として渡すことができます。

タイプ サポートされている形式 例
バイナリ Base64 でエンコードされた値 YXBwbGU=
タイムスタンプ YYYY-[M]M-[D]D[( |T)[H]H:[M]M:[S]S[.F]] [time_zone]
または YYYY-[M]M-[D]D[( |T)[H]H:[M]M:[S]S[.F]][time_zone_offset]		 2014-09-27 12:30:00.45-08
日付 YYYY-M[M]-D[D] 2014-09-27
時間 [H]H:[M]M:[S]S[.DDDDDD] 12:30:00.45
日時 YYYY-[M]M-[D]D [[H]H:[M]M:[S]S[.DDDDDD]] 2014-09-27 12:30:00.45

データ参照パラメータ

カスタム SQL ルールを作成する場合、ソーステーブルとそのフィルタを明示的に記述する代わりに、ルールでデータ参照パラメータ ${data()} を使用することで、データソース テーブルとそのすべての前提条件フィルタを参照できます。Knowledge Catalog は、このパラメータをソーステーブルとそのフィルタへの参照として解釈します。前提条件フィルタの例としては、行フィルタ、サンプリング パーセンテージ、増分フィルタなどがあります。

たとえば、my_project_id.dim_dataset.dim_currency というデータソース テーブルがあるとします。新しい日次データに対してのみスキャンする増分データ品質スキャンを実行したいとします。テーブルに、今日のエントリをフィルタする行フィルタ transaction_timestamp >= current_date() が適用されています。

今日の discount_pct を使用して行を見つけるカスタム SQL ルールは、次のようになります。

discount_pct IN (SELECT discount_pct FROM my_project_id.dim_dataset.dim_currency WHERE transaction_timestamp >= current_date())

データ参照パラメータを使用すると、ルールを簡素化できます。テーブルとその前提条件フィルタの記述を ${data()} パラメータに置き換えます。

discount_pct IN (SELECT discount_pct FROM ${data()})

Knowledge Catalog は、${data()} パラメータを、今日のエントリ my_project_id.dim_dataset.dim_currency WHERE transaction_timestamp >= current_date() を含むデータソース テーブルへの参照として解釈します。この例では、データ参照パラメータは増分データのみを参照します。

${data()} パラメータでは大文字と小文字が区別されます。

サブクエリ内でエイリアスを使用して参照元テーブルの列を参照する場合は、データ参照パラメータを使用して参照元テーブルを参照するか、テーブル参照を省略します。WHERE 句で直接テーブル参照を使用して、参照元テーブルの列を参照しないでください。

推奨:

  • データ参照パラメータを使用して参照元テーブルを参照します。

    discount_pct IN (
SELECT discount_pct FROM
`my_project_id.dim_dataset.dim_currency` AS temp-table
WHERE
temp-table.transaction_timestamp = ${data()}.timestamp
)

  • テーブル参照を省略します。

    discount_pct IN (
SELECT discount_pct FROM
`another_project.another_dataset.another_table` AS temp-table
WHERE
temp-table.transaction_timestamp = timestamp

非推奨:

  • 直接テーブル参照を使用して、参照元テーブルの列を参照しないでください。

    discount_pct IN (
SELECT discount_pct FROM
`my_project_id.dim_dataset.dim_currency` AS temp-table
WHERE
temp-table.transaction_timestamp = `my_project_id.dim_dataset.dim_currency`.timestamp
)

異なるテーブルの有効な使用例:

  • 異なるテーブルの列を比較する場合は、直接テーブル参照を使用できます。

    discount_pct IN (
SELECT discount_pct FROM
`my_project_id.dim_dataset.dim_currency` AS temp-table
WHERE
temp-table.transaction_timestamp = `another_project.another_dataset.another_table`.timestamp
)

クエリをデバッグする

ルールを作成する際に、必要に応じてデバッグクエリを含めて、ルールとともに実行できます。デバッグクエリは、最大 10 個のスカラー値を返す SQL ステートメントです。これらの値は、ルールが失敗した場合に原因を診断するのに役立ちます。ルールごとにデバッグクエリを 1 つ追加できます。長さは 1, 024 文字を超えないようにしてください。

example_project.example_dataset.table テーブルに対する次の SQL アサーション ルールについて考えてみます。このルールは、アイテムあたりの平均収益が 100 を超えているかどうかを確認します。

SELECT
  *
FROM
  `example_project.example_dataset.table`
WHERE
  SUM(revenue) / COUNT(DISTINCT item_id) > 100

上記のルールが失敗した場合は、総収益、個別のアイテム数、アイテムあたりの平均収益などの指標を表示して、問題を診断できます。次のデバッグクエリは、これらの指標を返します。

SELECT
  SUM(revenue),
  COUNT(DISTINCT item_id),
  SUM(revenue) / COUNT(DISTINCT item_id)
FROM `example_project.example_dataset.table`

ルールの実行

データ品質スキャンを特定の間隔で実行するようにスケジュール設定することも、スキャンをオンデマンドで実行することもできます。

実行 ID

デフォルトでは、Knowledge Catalog は一元化されたサービス エージェント（service-PROJECT_NUMBER@gcp-sa-dataplex.）を使用してデータ品質スキャンを実行します。

このデフォルトの実行 ID をオーバーライドするには、カスタム サービス アカウントを指定するか、独自のエンドユーザー認証情報（EUC）を使用します。これには次のような特典があります。

  • 最小権限の原則: 特定のデータ品質タスクに必要な IAM 権限のみを専用サービス アカウントに付与し、過剰なアクセスを最小限に抑えます。
  • きめ細かいアクセス制御: 権限を特定のリソースにスコープ設定し、BigQuery の行レベルと列レベルのアクセス ポリシーとの統合を可能にします。
  • 監査可能性の向上: カスタム サービス アカウントまたはユーザー認証情報を特定のスキャンに割り当てることで、監査ログでのアクティビティの追跡とロギングがより明確になります。
  • 課金の統合: カスタム実行 ID を使用すると、処理料金とストレージ料金が BigQuery に直接一元化されます（Knowledge Catalog Premium SKU はバイパスされます）。これにより、BigQuery の企業割引とスロット コミットメントを利用できます。

カスタム実行 ID の構成方法については、実行 ID を構成するをご覧ください。

ネットワーキングの要件

スキャンを実行するには、スキャンに使用する VPC サブネットでプライベート Google アクセスを有効にする必要があります。サブネットを指定しない場合は、デフォルトのサブネットで限定公開の Google アクセスが有効になっていることを確認してください。

データ品質スキャンを実行すると、Knowledge Catalog によってジョブが作成されます。ジョブの構成が誤っている場合や、ジョブの実行時間が予想よりも長い場合は、ジョブをキャンセルできます。

データ品質スキャンの仕様の一部として、ジョブの範囲を次のいずれかに指定できます。

テーブル全体
それぞれのジョブでテーブル全体が検証されます。
増分
それぞれのジョブで増分データが検証されます。増分を定めるには、テーブル内にマーカーとして使用可能な Date / Timestamp 列を用意します。通常、これはテーブルが分割される列です。

データをフィルタする

行フィルタを使用してデータ品質のためにスキャンされるデータをフィルタリングできます。行フィルタを作成すると、特定の期間内や特定のセグメント（特定のリージョンなど）のデータにフォーカスできます。フィルタを使用すると、実行時間とコストを削減できます。たとえば、特定の日付より前のタイムスタンプを持つデータを除外できます。

サンプルデータ

データ品質スキャンを実行するために、データからサンプリングするレコードの割合を指定できます。より少ないサンプルのデータでデータ品質スキャンを作成すると、実行時間とデータセット全体のクエリにかかる費用を削減できます。

フィルタルール

データ品質スキャンを実行するときに、AIP-160 フィルタ構文を使用して、特定のルールを選択的に実行できます。Knowledge Catalog は、スキャンで定義されたルールのメタデータ、または data-rules アスペクトを介してカタログ エントリに添付されたルールに対してフィルタリングを行います。

フィルタの構文

フィルタの構文は AIP-160 のガイドラインに沿っています。標準の AIP-160 演算子（=、!=、>、<、=~ など）を使用し、AND または OR を使用して複数の条件を組み合わせることができます。

AIP-160 フィルタ文字列を使用する場合は、次の操作を行います。

  • Google Cloud コンソール: AIP-160 構文を使用してフィルタを直接入力します（例: name = "critical_check"）。
  • API 呼び出しの場合: フィルタ文字列は、別の JSON 文字列リテラル内の値であることがよくあります。これには、AIP-160 文字列内の二重引用符をエスケープする必要があります。例: "filter": "name = \"critical_check\""

フィルタリング可能なフィールド

ルール定義で使用可能なほとんどのフィールドでフィルタできます。

  • name: ルールの表示名。
  • dimension: データ品質のディメンション（例: VALIDITY）。
  • column: ルールが適用される列の名前。
  • threshold: ルールの合格しきい値。
  • ignore_null: ブール値。true、NULL 行が合格とみなされる場合。
  • attributes: ルールに割り当てられたカスタム Key-Value ペア。

次の例は、一般的なフィルタ パターンを示しています。数値とブール値は引用符で囲まれません。

名前でフィルタする

  • 完全一致: name = "critical_check"
  • パターンに一致する: name =~ "temp_.*"

ディメンションでフィルタする

  • 特定のディメンションと照合する: dimension = "COMPLETENESS"
  • 複数のディメンションを照合: dimension = "VALIDITY" OR dimension = "ACCURACY"

列としきい値でフィルタする

  • 特定の列を照合する: column = "user_id"
  • しきい値と一致する: threshold > 0.95
  • 範囲を照合する: threshold >= 0.8 AND threshold < 0.9

ignore_null でフィルタする

  • 一致ブール値: ignore_null = true

カスタム属性でフィルタする

  • キーの存在を確認する: attributes:environment
  • キーと値が一致する: attributes.environment = "prod"
  • 正規表現を使用して一致させる: attributes.tag =~ "prio-.*"
  • 一致する組み合わせ: attributes.environment = "prod" AND attributes.criticality = "high"

データ品質スキャンの結果

データ品質スキャンの結果は、Knowledge Catalog と BigQuery で確認できます。次の方法でスキャン結果を確認して分析することもできます。

  • 結果を BigQuery にエクスポートする

    スキャン結果を BigQuery テーブルにエクスポートして、さらに分析を行うことができます。レポートをカスタマイズするには、BigQuery テーブルデータを Looker ダッシュボードに接続します。複数のスキャンで同じ結果テーブルを使用することで、集計レポートを作成できます。

  • 結果を Knowledge Catalog のメタデータとして公開する

    データ品質スキャンの結果は、Knowledge Catalog のメタデータとして公開できます。最新の結果は、ソーステーブルを表す Knowledge Catalog エントリに data-quality-scorecard システム アスペクト タイプで保存されます。結果は、 Google Cloud コンソールのソーステーブルの BigQuery ページと Knowledge Catalog ページにある [データ品質] タブで確認できます。API を使用して結果を取得することもできます。

    Knowledge Catalog のメタデータの詳細については、Knowledge Catalog のメタデータ管理についてをご覧ください。

  • データ品質スコアを確認する

    各スキャン結果には、合格したルールの割合を示すデータ品質スコアが表示されます。スコアは、ジョブ全体レベル、列レベル（ルールが列に対して評価される場合）、ディメンション レベルで報告されます。データ品質スコアを使用して、テーブルまたは列全体でデータ品質を正規化し、傾向を追跡することで、品質要件を満たしていないデータを特定します。

詳細については、データ品質スキャンの結果を表示するをご覧ください。

モニタリングとアラート

データ品質スキャンをモニタリングしてアラートを取得するには、次の方法を使用します。

  • Cloud Logging でアラートを設定する

    ログ エクスプローラの data_scan ログと data_quality_scan_rule_result ログを使用して、データ品質ジョブをモニタリングできます。

    データ品質ジョブごとに、data_scan_type フィールドが DATA_QUALITY に設定された data_scan ログに次の情報が含まれます。

    • データスキャンに使用されるデータソース。
    • ジョブの実行の詳細（作成時間、開始時間、終了時間、ジョブの状態など）。
    • データ品質ジョブの結果: 合格または不合格。
    • ディメンション レベルの合格または不合格。

    成功したすべてのジョブには、data_quality_scan_rule_result ログが含まれています。このログには、そのジョブ内の各ルールに関する詳細情報が含まれています。

    • ルール情報、ルールタイプ、評価タイプ、ディメンションなどの構成情報
    • 合格または不合格、合計行数、合格行数、null 行数、評価された行数などの結果情報。

    ログの情報は、API とGoogle Cloud コンソールで確認できます。この情報を使用して、アラートを設定できます。詳細については、Cloud Logging でアラートを設定するをご覧ください。

  • メール通知レポートを送信する

    データ品質スキャンジョブのステータスと結果に関するアラートを送信するメール通知レポートを送信できます。通知レポートは、次のシナリオで利用できます。

    • データ品質スコアが指定した目標スコアより低い
    • ジョブが失敗した
    • ジョブが完了した

    通知レポートは、データ品質スキャンを作成するときに構成します。

  • Cloud Billing で DCU のコンピューティング費用をモニタリングする

    データ品質スキャンのサーバーレス コンピューティングは、時系列指標を Cloud Monitoring に出力しません。プロジェクト、スキャン ID、テーブル別にデータ品質 DCU の費用を追跡して割り当てるには、goog-dataplex-datascan-* システムラベルを使用して BigQuery で Cloud Billing エクスポートをクエリします。詳細については、Cloud Billing エクスポートを使用して Dataplex DCU の費用をモニタリングして属性を設定するをご覧ください。

データ品質エラーのトラブルシューティング

ルールの実行が失敗すると、Knowledge Catalog は失敗したレコードを取得するクエリを提供します。このクエリを実行して、ルールと一致しなかったレコードを確認できます。詳細については、データ品質エラーのトラブルシューティングをご覧ください。

制限事項

  • ルールの推奨事項は gcloud CLI ではサポートされていません。
  • ディメンションの選択は、事前定義された 7 つのディメンションのいずれかに固定されます。
  • データ品質スキャンあたりのルール数は 1,000 に制限されています。
  • 列レベルでレポートされるデータ品質スコアは、API でのみサポートされています。
  • データ品質ルールは、BigQuery、Iceberg REST Catalog テーブル、SAP Business Data Cloud Delta Lake テーブル、Apache Hive テーブルでのみ実行できます。

料金

次のステップ