Databricksシステムテーブルがデータエンジニアの高度なオブザーバビリティ達成にどのように役立つか

午前3時の問題

午前3時、何かが壊れました。ダッシュボードは古く、SLA を遵守できず、プラットフォームのどの部分が正常な状態から逸脱したのか誰もが推測しています。ジョブがタイムアウトなしで何時間も実行されていたのかもしれません。パイプラインが、何か月も誰も読み取っていないテーブルを更新したのかもしれません。クラスターがまだ古いランタイムを使用しているのかもしれません。ジョブの所有者を知っている唯一の担当者が休暇中なのかもしれません。

これらはデータチームを疲弊させるパターンです。未使用のパイプラインによる無駄なコンピュート、健全性ルールの欠如による信頼性のギャップ、老朽化したランタイムによる衛生上の問題、そして不明確な所有権によって引き起こされる遅延などです。それらは静かに現れ、ゆっくりと成長し、そして突然、オンコールエンジニアを悩ませる原因となります。

Databricks システムテーブルは、ジョブのメタデータ、タスクのタイムライン、実行動作、構成履歴、リネージ、コストシグナル、所有権を 1 か所で公開することで、これらの問題を早期に発見するための一貫したレイヤーを提供します。

このたび新たにリリースされたLakeflow Jobs用システムテーブルにより、より豊富な実行詳細とメタデータシグナルを提供する拡張スキーマにアクセスし、高度な可観測性を実現できるようになりました。

システムテーブルにより、すべてのデータに対するより深く、一元化された可視性を簡単に実現

システムテーブルとは

Databricks システムテーブルは、systemカタログにある、Databricksが管理する読み取り専用のテーブルセットで、アカウントの運用データと可観測性データを提供します。標準で提供されており、ジョブ、パイプライン、クラスター、課金、リネージなど、幅広いデータを網羅しています。

オブザーバビリティにとってシステムテーブルが重要な理由

システムテーブルはリージョン内のワークスペース横断分析をサポートしており、データエンジニアリングチームは、単一のクエリ可能なインターフェースから、あらゆるワークロードの動作や運用パターンを大規模に簡単に分析できます。これらのテーブルを使用することで、データ実務者はすべてのパイプラインの健全性を一元的に監視し、コスト削減の機会を明らかにし、障害を迅速に特定して信頼性を向上させることができます。

一部のシステムテーブルでは SCD Type 2 セマンティクスが使用されており、更新ごとに新しい行を挿入することで完全な変更履歴が保持されます。これにより、構成の監査や、プラットフォームの状態の経時的な履歴分析が可能になります。

Lakeflowシステムテーブル

Lakeflow システムテーブルは、過去 365 日間のデータを保持し、以下のテーブルで構成されています。

システムテーブルとその関係の完全なリストについては、ドキュメントを参照してください。

ジョブ可観測性テーブル (一般提供)

• system.lakeflow.jobs – 設定やタグを含む、ジョブのSCD2メタデータ。インベントリ、ガバナンス、設定ドリフト分析に役立ちます。
• system.lakeflow.job_tasks – すべてのジョブタスク、その定義、依存関係を記述する SCD2 テーブルです。大規模なタスク構造を理解するのに役立ちます。
• system.lakeflow.job_run_timeline – ステータス、コンピュート、タイミングを含むジョブ実行の不変のタイムライン。SLA とパフォーマンスの傾向分析に最適です。
• system.lakeflow.job_task_run_timeline – 各ジョブ内の個々のタスク実行のタイムライン。ボトルネックやタスクレベルの問題の特定に役立ちます。

パイプライン可観測性テーブル (パブリックプレビュー)

• system.lakeflow.pipelines – SDP パイプライン用の SCD2 メタデータ テーブル。ワークスペース間のパイプラインの可視性と変更追跡を可能にします。
• system.lakeflow.pipeline_update_timeline – パイプライン更新用の不変の実行logs。履歴のデバッグと最適化をサポートします。  
   

Lakeflowシステムテーブルの人気は急速に高まっており、毎日数千万件のクエリーが実行され、前年比で17倍の増加を記録しています。この急増は、データエンジニアがLakeflowシステムテーブルから得られる価値を裏付けており、多くのDatabricks Lakeflowの顧客にとって、日々の可観測性に不可欠なコンポーネントとなっています。

最近拡張され、一般提供が開始されたジョブシステムテーブルによって可能になったユースケースを見ていきましょう。

システムテーブルの実践活用: Lakeflowジョブのオペレーショナルヘルス

中央プラットフォーム チームのデータ エンジニアとして、あなたは複数のチームにまたがる何百ものジョブを管理する責任があります。あなたの目標は、チームがガバナンスと運用のベストプラクティスを確実に順守するようにしながら、データ プラットフォームのコスト効率、信頼性、パフォーマンスを維持することです。

これを行うために、4つの中核的な目標に沿ってLakeflowのジョブとパイプラインの監査に着手します。

1. コストを最適化:ダウンストリームでまったく使用されていないデータセットを更新する、スケジュールされたジョブを特定します。
2. 信頼性を確保: タイムアウトとランタイムのしきい値を適用して、ジョブの暴走や SLA 違反を防止します。
3. 健全性の維持: 一貫したランタイムバージョンと設定標準を確認します。
4. 説明責任の割り当て: ジョブの所有者を特定し、フォローアップと修正を効率化します。

パターン1: 未使用のデータを生成しているジョブの検索

問題点: スケジュールされたジョブは忠実に実行され、下流のコンシューマーが誰も読み取ることのないテーブルを更新します。これらは、見つけることができれば、最も簡単にコストを削減できる部分であることがよくあります。

アプローチ: Lakeflow Jobs テーブルをリネージテーブルおよび請求テーブルと結合し、コンシューマーのいないプロデューサーをコスト順に特定します。

次にすべきこと: 最も問題のある項目をその所有者とともにレビューします。すぐに一時停止しても安全なものもあれば、Databricks外部のシステムが依存している場合は非推奨化計画が必要なものもあります。

パターン 2: タイムアウトまたは期間のしきい値がないジョブを見つける

課題: タイムアウトのないジョブは無期限に実行される可能性があります。スタックしたタスクは、誰にも気づかれることなく、何時間、場合によっては何日間もコンピュートを浪費します。これはコストの増加に加えて、SLA 違反を引き起こす可能性もあるため、締め切りやダウンストリームのプロセスに影響が及ぶ前に、実行時間の超過を早期に発見して対処する必要があります。

アプローチ: 現在のジョブ設定にクエリーし、欠落しているタイムアウトと期間のしきい値設定を確認します。

次にすべきこと: job_run_timeline の過去のランタイムと相互参照して、現実的な threshold を設定します。通常 20 分で実行されるジョブには、1 時間のタイムアウトと 30 分の期間 threshold が妥当な場合があります。実行時間にばらつきが大きいジョブは、まず調査が必要になることがあります。

パターン3: レガシーランタイムバージョンを検出する

問題: 非推奨のランタイムには、セキュリティパッチやパフォーマンス改善が適用されず、間近に迫ったEOL（サポート終了）期限の対象となります。しかし、何百ものジョブがある中で、誰がまだ古いバージョンを使っているかを追跡するのは面倒な作業です。

アプローチ: ジョブタスクの設定にクエリーを実行してランタイムバージョンを確認し、thresholdを下回るものにフラグを立てます。

次のステップ: EOL のタイムラインに基づいてアップグレードに優先順位を付けます。このリストをジョブの所有者と共有し、フォローアップ クエリーで進捗状況を追跡します。

パターン4: 修正のためにジョブの所有者を特定する

課題： ジョブが失敗した場合や正しく構成されていない場合、問題を解決するために誰に連絡すべきかを知る必要があります。 

アプローチ：システムテーブルにクエリを実行して、実行する必要がある各アクションのジョブ所有者を簡単に特定します。

次のステップ：アクションが必要な問題の所有権を割り当てるには、ジョブのオーナーに連絡してください。

これらのパターンを組み合わせることで、コストを最適化し、データを最新の状態に保ち、信頼性のガードレールを徹底し、修正のための明確な所有権を割り当てることができます。これらは、運用上の可観測性の基盤を形成します。

まとめ: ダッシュボードで知見を運用化する

これらのクエリーをアドホックに実行すると便利です。しかし、日常業務では、チーム全体が参照できる共有ビューが必要です。

「Lakeflow のダッシュボードは、すべてのワークスペースにわたるジョブの全体像を把握させてくれます。コストの観点だけでなく、パイプラインの健全性や運用の観点からも、支出の追跡、古いパイプラインの特定、エラーのモニタリング、最適化の機会の発見が可能です」― Zoe Van Noppen、データソリューションアーキテクト、Cubigo

開始するには、ダッシュボードをワークスペースにインポートします。詳細な手順については、公式のドキュメントを参照してください。

ダッシュボードには、以下のような、いくつかの主要な運用シグナルが表示されます:

• 障害の傾向 - 最も頻繁に失敗するジョブ、全体的なエラーの傾向、一般的なエラーメッセージを確認できます。 

• 高コストのジョブ - 過去30日間または一定期間にわたって最もコストの高いジョブと個々のジョブのランを特定できます。以下のテーブルは、選択した期間で最もコストの高いジョブ順に並べ替えられており、時間経過に伴うコストの傾向を示しています。

• コストと再試行のパターン - コストの傾向や、再試行または修復のランが総支出に与える影響を追跡するのに役立ちます。

• 構成に関する知見 - 運用の健全性のために、クラスターの効率、健全性ルール、タイムアウト、ランタイムのバージョンを確認できます。
  
• 所有権の詳細 - 連絡先を把握するために、「ラン-as」ユーザーとジョブ作成者を簡単に見つけることができます。
  

要するに、Databricks システムテーブル を使用すると、Lakeflow ジョブを大規模かつ複数のワークスペースにわたって効率的に監視、監査、トラブルシューティングすることが容易になります。ダッシュボード テンプレートで利用できるジョブとパイプラインの明確でシンプル、かつアクセスしやすいビジュアルにより、Lakeflow を使用するすべてのデータエンジニアは高度な可観測性を実現し、本番環境に対応したコスト効率の高い信頼性のあるパイプラインを一貫して確保できます。

システムテーブル は、プラットフォームのテレメトリーをクエリ可能なアセットに変換します。5つの異なるツールからのシグナルを繋ぎ合わせる代わりに、統合されたスキーマに対してSQLを記述し、数秒で答えを得ることができます。

午前3時のあなたも、きっと感謝するはずです。

システムテーブルの詳細については、次のリソースをご覧ください: 

• Databricksシステムテーブル
• Lakeflowシステムテーブル ダッシュボードテンプレート 

Databricksを初めてご利用ですか？ 今すぐDatabricksを無料でお試しください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事