APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > Datadog > Azure Databricksを使ってDatadogの「Data Observability」を試してみた

Azure Databricksを使ってDatadogの「Data Observability」を試してみた

Datadog Observability Azure Databricks

こんにちは。クラウド事業部の遠見です。

本記事は、Datadogの「Data Observability」を実際に検証したエンジニアが、内容をできる限り客観的に共有することを目的に作成しました。

近年、インフラの可観測性（Observability）と同じように、データの健全性を可観測にする「Data Observability」が注目されています。
今回は、Azure Databricksを使って、Datadogの「Data Observability」を試してみました。

セットアップからカタログ同期、そして意図的にデータを汚染させる「破壊検証」の結果までをレポートします。

はじめに：Datadog×APC共催ランチセミナー開催

本編に入る前に、Datadogにご興味のある方へお知らせです。

4/21(火)に、Datadog×APC共催ランチセミナーを開催いたします！

参加者を募集していますので、監視・運用環境の改善や効率化に関心がある方は、ぜひ以下のリンク（X、Linkedin）から詳細をチェックしてみてください。

www.linkedin.com

Data Observability（データ可観測性）とは

「Data Observability」という用語は、2019年に提唱・カテゴリ化されました。

データ可観測性プラットフォームを提供する「Monte Carlo」のCEOであるBarr Moses氏が提唱したもので、現在ではデータエンジニアリングにおける業界標準の概念として広く浸透しています。

www.montecarlodata.com

Moses氏は Data Observabilityを以下のように定義しています。

www.montecarlodata.com

"Data observability provides full visibility into the health of your data and systems so you are the first to know when the data is wrong, what broke, and how to fix it."

従来の「データ品質管理」が静的なチェック（期待した値かどうか）に留まっていたのに対し、Data Observabilityはデータの生成から消費に至るまでの「健康状態」を動的に、かつ継続的に可視化・検知する仕組みを指します。

この「健康状態」を構成する要素として、以下の 「5つの柱（5 Pillars）」を定義しています。

観点 内容
Freshness（鮮度） データが期待どおりのタイミングで更新されているか
Volume（量） 行数が多すぎたり、少なすぎたりしていないか
Distribution（分布） 値は正常な範囲内に収まっているか
Schema（スキーマ） データの構成（スキーマ）に変更はないか
Lineage（系譜） データ資産はデータスタックの上流から下流までどのように接続されているか

出典：The 5 pillars of data observability - Monte Carlo

「Distribution（分布）」は、より一般的で直感的に分かりやすい言葉として「Quality（品質）」と表現される場合もあります。

なぜ今、Datadogの「Data Observability」なのか

データ活用が進む組織において、「サイレントなデータ崩壊」は最も恐ろしいリスクの一つです。

リスク 具体的な事象
ビジネス側からの指摘 ダッシュボードの数字がおかしいと指摘され、調査したら数日前からデータが壊れていたことが判明する
「パイプライン正常終了」の罠 ジョブ自体は Success なのに、中身が空っぽ（Row Count 0）だったり、特定のカラムがすべて NULL になっている
原因特定の長期化 異常はわかったが、「いつから」「どの処理で」「なぜ」壊れたのか、ログを遡るだけで数時間を浪費する

これらは、データパイプラインの「中身」を継続的に見ていないことで起きる問題です。

こうした課題を解決するのが、Datadogの「Data Observability」です。

データ基盤のネイティブ監視機能との違い

多くのモダンなデータ基盤（データウェアハウスやレイクハウス）には、標準でデータ品質をチェックするネイティブ機能が備わっています。
これらは特定のテーブルの統計情報やスキーマの変化を追跡するのには非常に強力です。

しかし、実運用におけるトラブルは、データ基盤の中だけで完結しているとは限りません。
トラブルの原因は、以下のように「データ」の外側に潜んでいることが多々あります。

要因 具体的な事象
インフラ起因 クラスターの計算リソース不足やメモリ不足により、処理が途中でスキップされ、結果としてレコード数が激減した
外部要因 ソースとなる外部APIの疎通エラーや認証失敗により、データが更新されなかった
パイプライン起因 オーケストレーターのジョブは成功しているが、中間処理のバグで特定のカラムがすべてNULLになった

ネイティブ機能は「データがおかしい」ことは教えてくれますが、「なぜおかしくなったのか」というインフラや外部要因との因果関係を特定するには、別の監視ツールを行き来する必要があります。

一方Datadogであれば、インフラのメトリクスやジョブの実行ログ、データ品質の異常を、同一のタイムライン・同一のダッシュボードで横断的に確認できます。

「いつ、どのインフラの問題がデータ品質に波及したか」という因果関係を一目で特定できる点は、統合プラットフォームであるDatadogの圧倒的な利点です。

Azure Databricksとは

Azure上で動作するApache Sparkベースの強力なデータ分析プラットフォームです。

Data Observabilityを実現する上で、Databricks（特にUnity Catalog）は単なるデータ置き場ではなく、「情報の供給源」として極めて重要な役割を担っています。

機能 特徴
Lakehouseアーキテクチャ データレイクの柔軟性とデータウェアハウスの信頼性を両立した基盤。あらゆるデータが一箇所に集約されるため、Observabilityツールが監視すべき「データの入り口から出口まで」を一つのプラットフォームでカバーできる
Unity Catalog データ資産のガバナンスとLineage（どのテーブルがどこから作られたか）を一元管理する機能。通常、データのLineageを把握するには複雑な解析が必要だが、Unity Catalogはこれを自動で記録している

今回は、このUnity Catalogが一元管理する膨大なメタデータに対し、Datadogがどこまで深く、そして簡単に観測できるのかを確認します。

公式ドキュメント：
Azure Databricks とは - Azure Databricks | Microsoft Learn
Data Lakehouse とは - Azure Databricks | Microsoft Learn
Unity Catalog とは - Azure Databricks | Microsoft Learn

今回の検証範囲

本記事では、まずは「つながる」ことと、Data Observabilityの核心である「品質監視」と「Lineage」の動作確認にフォーカスします。

  • Azure Databricksワークスペースの構築とDatadogとの接続
  • Catalog機能によるデータ資産の自動検出
  • Quality MonitoringによるNULL混入の検知（破壊検証）
  • Lineage（系譜）機能によるテーブル間依存関係の可視化

検証環境の構成

項目 設定・内容 備考
プラットフォーム Azure Databricks Premiumプラン（Unity Catalog有効）
コピー元テーブル orders samples.tpch.orders より全件コピー
監視対象テーブル orders_source orders より 1,000行抽出（破壊検証の対象）
監視対象カラム o_totalprice 今回のNULL混入監視対象カラム
カタログ / スキーマ dd_data_o11y_test.default Unity Catalog管理下の検証用スキーマ
ツール Datadog「Data Observability」 14日間無料トライアル

samples.tpch.ordersは、Azure Databricksに組み込みのsamplesカタログに収録されているサンプルデータです。

構成図にすると以下のイメージです。

検証環境の構築

Azure Databricks

Microsoft公式ドキュメント「Azure Databricks に無料でサインアップする」を参考に構築します。

learn.microsoft.com

Azure Portalで[リソースの作成] >[Databricks] > [Azure Databricks]を選択します。

以下の項目を入力して「確認と作成」>「作成」をクリックします。

項目 設定値
ワークスペース名 dd-data-o11y-test（任意）
サブスクリプション 任意
リソースグループ rg-azure-databricks（新規作成）
場所（リージョン） 任意（後から変更不可）
価格レベル Premium（Unity Catalogの利用に必要）
ワークスペースの種類 ハイブリッド（クラスターでSQL実行するため）
マネージドリソースグループ名 空欄のまま（Azureが自動生成）

他のタブ（ネットワーク・暗号化など）はデフォルトでOKです。

「確認と作成」タブへ進んで、検証が成功したら「作成」をクリックします。

ワークスペースの作成には数分かかります。
作成が完了すると、操作したユーザーが自動的に管理者としてワークスペースに追加されます。

「ワークスペースの起動」をクリックすると、自動的にログインが走り、Databricksワークスペースが表示されます。

Datadog（Databricksのインテグレーション）

Datadog公式ドキュメントを参考にインテグレーションします。

docs.datadoghq.com

Datadogの[Integrations]から、検索窓で「Databricks」と入力し、結果に出力された「Databricks」をクリックします。

[Configure]タブから設定をします。

① Connect a new Databricks Workspace

設定は以下の通りです。

項目 設定値
Workspace Name dd-data-o11y-test（任意）
Workspace URL https://adb-xxxxxxxxx.azuredatabricks.net
Account ID DatabricksアカウントID
Client ID サービスプリンシパルのアプリケーションID
Client Secret サービスプリンシパルのシークレット
System Tables SQL Warehouse ID SQL WarehouseのID

Workspace URL

Azure Portalの[Azure Databricksサービス] > [概要]の「URL」をコピーします。

Account ID

Databricksアカウントコンソール（accounts.azuredatabricks.net）の右上プロフィールから確認します。

Databricksワークスペースには表示されないため、注意が必要です。

learn.microsoft.com

You must be in the account console to retrieve the account ID. The ID will not display inside a workspace.

Client ID / Client Secret

サービスプリンシパルを新規作成し、両者を取得します。

[Databricksワークスペース] > [右上のアイコン] > [設定]を開きます。

[IDとアクセス] > [サービスプリンシパル] > [管理] をクリックします。

「Service Principalを追加」をクリックします。

「新規追加」をクリックします。

「管理」は「Databricksが管理」のままでOKです。

今回の連携に必要な「Databricks上のデータ（Unity Catalog）を読み取る権限」は、これだけで十分確保できます。
Azure全体の管理ポリシー等で制約がない限り、こちらの方がセットアップが簡単です。

サービスプリンシパル名（例：datadog-integration）を入力し、「追加」をクリックします。

作成したサービスプリンシパルをクリックします。

「シークレット」タブに移動し、「シークレットを生成」をクリックします。

「OAuthシークレットを生成」で存続期間を設定し「生成」をクリックします。
今回は最大値の730日に設定しました。

表示される「Client ID」と「Secret」をコピーします（Secretはこの画面でしか確認できません）。

SQL Warehouse ID

Databricksワークスペースの左メニューから、「SQL ウェアハウス」をクリックします。
既存のウェアハウスがあるので、それをクリックします。

[概要]タブの「名前」にあるIDをコピーします。

② Select products to set up integration

今回のハンズオンに合わせた設定にしています。

機能 設定
Jobs Monitoring Disabledに変更
Cloud Cost Management Disabledのまま（変更不可）
Reference Tables そのまま（設定不要）
Quality Monitoring Enabledに変更

③ Select resources to set up collection

今回のハンズオンではスコープ外のため、Disabledにします。

機能 設定
Metrics - Model Serving Disabledに変更

すべての入力が完了したら「Save Databricks Workspace」をクリックします。

インテグレーションの画面に遷移し、緑のチェックが入っていればOKです。

サンプルデータの準備

Azure Databricksに組み込みのsamplesカタログに収録されているsamples.tpch.ordersをサンプルデータとして使用します。

learn.microsoft.com

テーブルの主なカラムは以下のとおりです。

カラム名 内容
o_orderkey 注文ID
o_custkey 顧客ID
o_orderstatus 注文ステータス
o_totalprice 注文金額
o_orderdate 注文日
o_orderpriority 優先度

Databricksワークスペースで、以下のSQLを実行して内容を確認してみます。

[SQLエディタ] > [SQLクエリー]をクリックします。

ここで、クエリを実行していきます。

  • テーブル一覧の確認
SHOW TABLES IN samples.tpch;

  • データの中身を確認
SELECT * FROM samples.tpch.orders LIMIT 10;

検証ではsamples.tpch.ordersを、自分のカタログにコピーして使用します。
元のsamplesカタログは読み取り専用のため、データの書き換え（破壊検証）が行えるよう、自環境にテーブルを複製しておきます。

  • 自分のカタログにコピー
CREATE TABLE dd_data_o11y_test.default.orders
AS SELECT * FROM samples.tpch.orders;

確認のSQLを実行して、データが入っているか確認してみます。

  • データの中身を確認
SELECT * FROM dd_data_o11y_test.default.orders LIMIT 10;

アクセス権の付与

Datadog公式ドキュメントは以下です。

docs.datadoghq.com

「Lineage」を表示するため、Databricksのsystemカタログへのアクセス権を付与します。
<application_id>は、インテグレーション時に確認した「Client ID（サービスプリンシパルのアプリケーションID）」になります。

GRANT USE CATALOG ON CATALOG system TO `<application_id>`;
GRANT USE SCHEMA ON CATALOG system TO `<application_id>`;
GRANT SELECT ON CATALOG system TO `<application_id>`;

次に、監視したいデータの範囲に対して、読み取り専用アクセス権限を付与します。
<application_id>は、インテグレーション時に確認した「Client ID（サービスプリンシパルのアプリケーションID）」になります。
<catalog_name>は今回の場合、先ほどサンプルデータをコピーしたdd_data_o11y_testになります。

GRANT USE_CATALOG ON CATALOG <catalog_name> TO `<application_id>`;
GRANT USE_SCHEMA ON CATALOG <catalog_name> TO `<application_id>`;
GRANT SELECT ON CATALOG <catalog_name> TO `<application_id>`;

こちらもコマンドを実行すると、以下のようにOKと出ます。

【トラブルシューティング】systemカタログへのGRANT実行時に「権限不足」のエラー

設定自体はDatadog公式ドキュメントの指示に従うだけですが、Azure側に権限に関する注意点がありました。
結果的には個人の検証環境の問題でしたが、参考までに記載します。

  • systemカタログへのGRANT実行時に「権限不足」のエラー

PERMISSION DENIED: User does not have MANAGE on Catalog 'system'.

「診断エラー」を実施し、右側に以下の調査結果が出力されました。

This error cannot be fixed by editing the code — the SQL syntax is correct. The root cause is an infrastructure/permission issue:

The GRANT statement on the system catalog requires the MANAGE privilege (or metastore admin role) on that catalog. Your current user does not have this privilege, so no code change will resolve it.

To fix this, a metastore admin needs to either:

Grant you MANAGE on the system catalog so you can issue these GRANT statements yourself
Execute these three GRANT statements on your behalf, granting USE CATALOG, USE SCHEMA, and SELECT on the system catalog to principal <application-id>

要約すると、SQL文には問題ないがこの設定には「メタストア管理者権限」が必要で、作業ユーザーに十分な権限が付与されておらずエラーとなったとのことです。

解決策としては、Azure Entra IDで、Azure Databricksを作成したユーザーに「グローバル管理者」ロールを付与し、Databricksアカウントコンソール（accounts.azuredatabricks.net）から該当ユーザーにメタストアの権限を与えることでした。

個人の検証環境などで試す際は、自身に適切な権限があるか事前に確認することをおすすめします。

  • Azure Entra IDで「グローバル管理者」ロールを付与

  • Databricksアカウントコンソールから、作成済みのメタストアをクリックし、メタストア管理者を変更する

なお、グローバル管理者付与後も、Databricksのアカウントコンソールに入れない事象が続きましたが、数分待って再アクセスすることでアカウントコンソールにログインすることができました。

また、このトラブルシューティングの過程で、datadog-integrationをDatabricksのadminsグループへ追加し、ワークスペース管理者権限を付与する作業を行いました。

ただ今回の検証（Quality Monitoring）においては、この作業は必須ではなかった可能性が高いです。

Datadogが必要としているのは「データの閲覧権限（GRANT）」であり、公式ドキュメントにもワークスペース自体の管理権限では不要との記載があります。

docs.datadoghq.com

Note: Workspace Admin permissions are not required for Quality Monitoring.

今回は、後続の作業でdatadog-integrationをDatabricksのadminsグループに追加した状態で進めているため、念のため記載しています。
もしこれから設定される方は、まずは公式ドキュメント通りに最小限の権限付与から進めることをおすすめします。

どうしても上手くいかない場合の策として、参考の一つになれば幸いです。

【検証】データ資産の自動検出（Catalog機能）

Datadogではインテグレーションが完了すると、バックグラウンドでメタデータの同期を開始します。

Datadogへの情報の反映については、公式ドキュメントでは「数時間かかる場合がある」とありました。

docs.datadoghq.com

After you configure the integration, Datadog begins syncing your metadata and column-level lineage in the background. Initial syncs can take several hours depending on the size of your Databricks deployment.

今回の小規模な検証環境では、10分程度で反映されました。

カタログの確認

[Data Observability] > [Catalog]を確認すると、Databricks側で定義したカタログが自動的に表示されます。
Datadogが同期したカタログの一覧で、samplesとdd_data_o11y_test が表示されていればOKです。

【検証】Lineageの自動生成を確認する

Lineageの自動生成を確認するには、Databricks側で実際に「テーブル間をまたぐクエリ（SQL）」を実行して、Lineageの「実績（ログ）」を作っておく必要があります。

Datadogは、Databricksのシステムテーブル（system.access.table_lineage など）に記録された「実行ログ」を読み取ってLineageを描画する仕組みと考えられます。
そのため、一度もデータが流れていない（クエリが走っていない）状態ではログが存在しないため、Datadog側も描画するデータがありません。

今回は3段構成のETLパイプラインを想定したSQLを実行し、ログを発生させます。

  • 上流テーブル（Source）の作成
CREATE TABLE IF NOT EXISTS dd_data_o11y_test.default.orders_source AS 
SELECT * FROM samples.tpch.orders LIMIT 1000;

  • 下流テーブル（Downstream）の作成（Create Table As SelectによるLineage発生）
CREATE TABLE IF NOT EXISTS dd_data_o11y_test.default.orders_tax_calc AS 
SELECT o_orderkey, o_totalprice, o_totalprice * 1.1 AS total_price_with_tax 
FROM dd_data_o11y_test.default.orders_source;

  • さらにもう一段階（Lineageを長くして見やすくするため）
CREATE TABLE IF NOT EXISTS dd_data_o11y_test.default.orders_summary AS 
SELECT count(*) as order_count, sum(total_price_with_tax) as grand_total
FROM dd_data_o11y_test.default.orders_tax_calc;

DatadogでLineageを確認します。
※実行後、Datadogにデータが反映されるまでに時間がかかる場合があります。
※今回は、翌日に確認しています。

Lineageの確認手順としては、1番最後に作ったテーブルから上流を辿るのがシンプルでわかりやすいので、その流れで確認します。

[Data Observability] > [Catalog]を開きます。
検索窓にorders_summary（一番下流のテーブル名）と入力します。
テーブル名をクリックして詳細画面を開き、[Lineage] タブをクリックします。

ここに表示されている内容から、データのLineageが確認できます。

項目 内容
Upstream 1 total_price_with_taxというカラムが表示されている
PATH その出所がdd_data_o11y_test.default.orders_tax_calcであると明記されている

Datadogが「orders_tax_calcを加工してorders_summaryが作られた」というSQLの実行ステップを理解していることが分かります。

さらに、右上にある [View Lineage Map]をクリックすると、より視覚的にわかりやすいマップでLineageを確認できます。

orders→orders_source→orders_tax_calc→orders_summary という「箱と矢印」の図が表示されます。
orders（元データ）からorders_summary (最終集計) までの、データのライフサイクルが一本の線で繋がっています。

一番右の orders_summary にANCHORと付いています。
ANCHORとは「今自分が見ている中心点」を表します。
調査したいテーブルをANCHORに設定することで、その「上流（何が原因か）」と「下流（どこに影響するか）」を瞬時に切り分けられるようになっています。

また、一番左だけがsamplesカタログで、それ以外がdd_data_o11y_testカタログです。
カタログの境界を越えてもLineageが途切れずに、繋がりを確認できています。

【検証】Quality Monitoringで異常を検知する

上流テーブルに汚染データを流し込み、Datadogがそれを自律的に検知できるかを試します。
今回は「20%を超えたら即アラート」という動作を確認します。

モニターを新規作成します。

[Data Observability] > [Quality Monitoring] > [Monitors]に移動し、「New Monitor」をクリックします。

① Choose data to monitor

Column を指定し、検索窓にo_totalpriceを入力します。
出力されるリストから、今回検証しているパスdd_data_o11y_test > default > orders_sourceが含まれているものを選びます。

右に指定したパスのカラムが表示されていればOKです。

② Select your metric type

「Select your metrics」のプルダウンをクリックします。
「Integrity」を選択します。

「Nullness」を選択します。

Nullnessのダイアログが表示されるので、以下を入力します。

項目 設定値 内容
Detection method Thresholds 固定のしきい値で判定するモードを選択
Alert threshold 0.1 10%以上のデータがNULLになったら「赤（Alert）」
Warning threshold 0.05 5%以上のデータがNULLになったら「黄（Warning）」

段階的な通知設定にすることで、致命的なデータ崩壊が起きる前の「予兆」を捉えられるようになります。

③Configure notification & automations

項目 設定値
モニター名 [Data O11y] NULL Check for orders_source (o_totalprice)
通知先（1 Email） Add Mention で自身のメールアドレスを選択

通知メッセージ（Editタブ）には、異常検知時と復旧時に状況がひと目でわかるメッセージを設定しました。

{{#is_alert}}
### 🚨 【異常検知】上流テーブルで大量のNULLを検出しました
{{/is_alert}}
{{#is_recovery}}
### ✅ 【復旧】NULL率は正常範囲に戻りました
{{/is_recovery}}

対象テーブル: `dd_data_o11y_test.default.orders_source`
対象カラム: `o_totalprice`
現在のNULL率: {{value}} 

影響範囲:
このテーブルは `orders_summary` のソースとなっています。
Lineageマップを確認し、集計データへの影響を調査してください。

その他はデフォルトのまま、[Create and Publish] をクリックして保存します。

正常が記録されるのを待つ

モニターを保存した後、チャートに最初のデータポイントが表示されるまで待機します。
私の場合、モニター作成（10:26 Created）から初回データが反映されるまで（10:40 Nullness）、15分弱の待ち時間が発生しました。

【検証】「破壊SQL」の実行

Databricksで以下SQLを実行して、データを意図的に汚染させます。

  • o_totalpriceの約20%をNULLに書き換える
UPDATE dd_data_o11y_test.default.orders_source
SET o_totalprice = NULL
WHERE o_orderkey % 5 = 0;

num_affected_rowsが200となっており、予定通りorders_sourceテーブルのデータが破壊されています。

Datadogのモニターに反映されるのを待つ間に、先にSQLで現在のNULL数と比率を確認してみます。

SELECT 
    count(*) AS total_rows,
    sum(case when o_totalprice is null then 1 else 0 end) AS null_count,
    sum(case when o_totalprice is null then 1 else 0 end) / count(*) * 100 AS null_percentage
FROM dd_data_o11y_test.default.orders_source;

項目 数値 備考
total_rows 1,000 全レコード数
null_count 200 NULLが含まれる行数
null_percentage 20% 現在のNULL率

想定通りnull_percentageが20%と表示されています。
設定したしきい値は 10%（0.1）なので、Datadog側がこの「1,000行中200行がNULL」という情報を得た瞬間、アラートのしきい値を超えることになります。

【検証】結果確認

結果については、モニター作成時の「Nullnessのダイアログ」でHourlyと設定しているため、1時間間隔の検知になります。

今回の検証では、10:40から検知が開始されたため、1時間後の11:40にアラートを検知しました。

メールでは、以下のアラートが通知されます。

アラート画面からLineageへ遷移すると、異常が発生したorders_sourceが赤くハイライトされていました。

これにより、「この上流の欠損が、最終集計であるorders_summaryの精度を狂わせている」 という根本原因が、SQLを1行も書かずに視覚的な情報として得られました。

【検証】アラートの復旧

データを正常値に戻すSQLを実行します。

UPDATE dd_data_o11y_test.default.orders_source
SET o_totalprice = 100.0
WHERE o_totalprice IS NULL;

先ほどと同様に、Datadogが検知する情報を先に確認してみます。

SELECT 
    count(*) AS total_rows,
    sum(case when o_totalprice is null then 1 else 0 end) AS null_count,
    sum(case when o_totalprice is null then 1 else 0 end) / count(*) * 100 AS null_percentage
FROM dd_data_o11y_test.default.orders_source;

null_percentageが0になっています。

1時間後、メールで復旧通知が届きました。

Lineageのマップの赤も消えています。

以上で、アラートの復旧まで反映されたことが確認できました。

検証環境の削除

Azure側

Azure Portalから、今回作成したリソースグループを削除します。
今回は「NetworkWatcherRG」もこの検証で作成されたものだったので、合わせて削除しています。

Datadog側

[Data Observability] > [Settings] > [Integrations]からDatabricksのインテグレーションを削除します。

下部の「Delete Account」をクリックします。

作成したモニターを削除します。

検証コスト

Azure

今回の2日間の検証で、Azureの利用料が合計で17,134円発生しました。

当初は「作業時のみの稼働で数百円程度」と予想していましたが、なぜここまで差が出たのか、その技術的な要因をまとめました。

要因 内容
SQL Warehouseの自動起動 DatadogはメタデータやLineageを取得するため、バックグラウンドで定期的にクエリを実行する。この際、停止中のSQL Warehouseが自動で再起動され、意図せず稼働時間が延びた
Premium プランの単価 Unity Catalogの利用にはAzure Databricksの「Premiumプラン」が必須。標準プランよりもDBU単価が高いため、Serverless SQL（SQL Warehouse）の稼働時間がそのまま大きな金額となった

Azureのコスト内訳でServerless SQL DBUが大きなウエイトを占めています。
このことから、作業時間外にもサービスプリンシパル（datadog-integration）による定期的なクエリ実行が行われていたと考えられます。

Azure Databricksの公式ドキュメントには、SQL Warehouseの仕様として「停止中のWarehouseに対してクエリを実行すると自動起動する」旨が記載されています。

learn.microsoft.com

Running a query against a stopped warehouse starts it automatically if you have access to the warehouse.

Datadogが品質監視のためにバックグラウンドでクエリを定期的に発行し、このクエリをAzure Databricksが受け取った瞬間、上記の仕様によってSQL Warehouseが自動的に起動し、課金が継続してしまったと考えられます。

もしこれから検証を始める方は、コストを最小限に抑えつつ検証を継続するために、以下を注意しましょう。

対策 具体的な内容
SQL Warehouseのサイズ縮小 1,000行程度のサンプルデータであれば、最小の「2X-Small」や「X-Small」で十分動作する
手動での停止実行 サーバーレスタイプであれば再起動も早いため、作業を離れる際は自動停止を待たずに手動で「Stop」をクリックする

公式ドキュメント：
SQL ウェアハウスのサイズ設定、スケーリング、およびキューの動作 - Azure Databricks | Microsoft Learn

Datadog

トライアル期間のためコストは発生していません。

まとめ

今回の検証を通じて、Datadogの「Data Observability」の凄さに触れることができました。

項目 具体的な内容
セットアップの手軽さ インテグレーションと数行のGRANT文だけで、複雑なLineageと品質監視が手に入る
中身を追う力 パイプラインの成功や失敗という外側の情報だけでなく、カラム内のNULL率という中身の劣化を確実に捉えられる

「ビジネス側から指摘されてからデータ崩壊に気づく」という、データエンジニアにとって最悪のシナリオを回避するために、このツールは非常に強力な武器になると思いました。

お知らせ

弊社では、Datadogの導入支援から運用サポートまでをトータルでご支援するサービスを提供しています。
初期設計・エージェント展開・モニタリング設定・ダッシュボード構築まで、お客様のニーズに合わせた支援が可能です。
「自社だけでの導入が不安」「もっと効率的に監視環境を整えたい」という方は、ぜひお気軽にご相談ください。

www.ap-com.co.jp

Databricksを用いたデータ分析基盤の導入から内製化支援まで幅広く支援をしています。
もしご興味がある方は、お問い合わせ頂ければ幸いです。

www.ap-com.co.jp

一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。 www.ap-com.co.jp

本記事の投稿者: s_tomi