オペレーショナル エクセレン スのベスト プラクティス

この記事では、次のセクションに示すアーキテクチャの原則別に整理された 、オペレーショナル エクセレンスのベスト プラクティスについて説明します。

1. ビルドとリリースのプロセス を最適化する

レイクハウス専用の運営チームを作る

一般的なベスト プラクティスは、プラットフォーム運用チームを用意して、データ チームが 1 つ以上のデータ プラットフォームで作業できるようにすることです。 このチームは、社内で青写真とベストプラクティスを考え出す責任があります。 インフラストラクチャ の自動化 やセルフサービスアクセスなどのツールを提供し、セキュリティとコンプライアンスのニーズが満たされるようにします。 このように、プラットフォームデータを保護する負担は中央チームにあるため、分散したチームはデータの操作と新しい知見の生成に集中できます。

Databricks Git フォルダーを使用してコードを Git に保存する

Databricks Git フォルダーを使用すると、ユーザーはノートブックやその他のファイルを Git リポジトリに保存でき、リポジトリのクローン作成、コミットとプッシュ、プル、ブランチ管理、ファイルの差分表示などの機能を提供できます。 コードの可視性と追跡を向上させるには、Git フォルダーを使用します。 「Databricks Git フォルダーと Git の統合」を参照してください。

DevOps プロセスの標準化 (CI/CD)

継続的インテグレーションと継続的デリバリー (CI/CD) は、自動化パイプラインを使用して、短期間で頻繁なサイクルでソフトウェアを開発および配信することを指します。 これは決して新しいプロセスではなく、従来のソフトウェア エンジニアリングでは何十年も前から広く普及していましたが、データエンジニアリング チームやデータサイエンス チームにとってはますます必要なプロセスになりつつあります。 データ製品に価値があるためには、タイムリーに配信される必要があります。 さらに、消費者はこれらの製品の結果の正当性を確信する必要があります。 コードの構築、テスト、デプロイメントを自動化することで、開発チームは、多くのデータエンジニアリング チームやデータ サイエンス チームで依然として普及している手動プロセスよりも、より頻繁かつ確実にリリースを提供できます。 「Databricks の CI/CD とは何ですか?」を参照してください。 。

Databricks Git フォルダーを使用したコード開発のベスト プラクティスの詳細については、「Git を使用した CI/CD テクニック」および「Databricks Git フォルダー (Repos)」を参照してください。 これを Databricks REST API と組み合わせることで、GitHub Actions、Azure DevOps パイプライン、または Jenkins ジョブを使用した自動デプロイ プロセスを構築できます。

MLOps プロセスの 標準化

機械学習モデルの構築とデプロイは複雑です。 これを実現するためのオプションはたくさんありますが、明確に定義された標準はほとんどありません。 その結果、ここ数年、機械学習運用 (MLOps) の出現が見られました。 MLOps は、モデル、データ、コードを管理して、機械学習システムのパフォーマンスの安定性と長期的な効率を向上させるための一連のプロセスと自動化です。 データ準備、探索的データ分析 (EDA)、特徴エンジニアリング、モデル トレーニング、モデルの検証、デプロイ、モニタリングについて説明します。 「Databricks の MLOps ワークフロー」を参照してください。

  • ビジネス目標を常に念頭に置いてください。 ビジネスにおける Computational の主な目的がデータドリブンな意思決定と製品を可能にすることであるのと同様に、Simulation Ops の主な目的は、これらのデータドリブンなアプリケーションの安定性を保ち、最新の状態に保ち、ビジネスにプラスの影響を与え続けることです。 MLOps の技術的な作業に優先順位を付けるときは、ビジネスへの影響を考慮してください。 新しいビジネスユースケースが可能になりますか? データチームの生産性が向上しますか? 運用コストやリスクを軽減しますか?

  • 専門的でオープンなツールで機械学習モデルを管理します。 機械学習モデルのライフサイクルを念頭に置いて設計された MLflow を使用して、機械学習モデルを追跡して管理することをお勧めします。 「 MLflow を使用した機械学習ライフサイクル管理」を参照してください。

  • 機械学習 Ops をモジュール方式で実装する: 他のソフトウェアアプリケーションと同様に、コード品質は機械学習アプリケーションにとって最も重要です。 モジュール化されたコードにより、個々のコンポーネントのテストが可能になり、将来のコードリファクタリングの問題が軽減されます。 明確なステップ (トレーニング、評価、デプロイなど)、スーパーステップ (トレーニングからデプロイまでのパイプラインなど)、責任を定義して、機械学習アプリケーションのモジュール構造を明確にします。

これについては、Databricks MLOps ホワイトペーパーで詳しく説明されています。

2. デプロイとワークロード を自動化する

デプロイとメンテナンス のためのコードとしてのインフラストラクチャの使用

HashiCorp Terraformは、複数のクラウドプロバイダー間で安全で予測可能なクラウドインフラストラクチャを作成するための人気のあるオープンソースツールです。 Databricks Terraform プロバイダー は、柔軟で強力なツールを使用して、Databricks ワークスペースと関連するクラウド インフラストラクチャを管理します。Databricks Terraform プロバイダーの目標は、すべてのデータ REST APIsをサポートし、データ プラットフォームのデプロイと管理の最も複雑な側面の自動化をサポートすることです。 Databricks Terraform プロバイダーは、クラスターとジョブを確実にデプロイおよび管理し、Databricks ワークスペースをプロビジョニングし、データ アクセスを構成するために推奨されるツールです。

クラスターポリシー を使用する

Databricks ワークスペース管理者は、クラスターポリシーを使用して、使用可能なインスタンスタイプ、Databricks のバージョン、インスタンスのサイズなど、スピンアップされるクラスターの多くの側面を制御できます。 ワークスペース管理者は、一部の Spark 構成設定を適用し、複数のクラスター ポリシーを構成して、特定のユーザー グループが小規模クラスターまたはシングルユーザー クラスターを作成し、一部のユーザー グループが大規模なクラスターを作成し、他のグループが既存のクラスターのみを使用するようにすることができます。 「コンピュート ポリシーの作成と管理」を参照してください。

ジョブ に自動化されたワークフローを使用する

  • ジョブを含むワークフロー (内部オーケストレーション):

    ジョブでワークフローを使用して、スケーラブルなリソースを持つ Databricks クラスターでデータ処理タスクとデータ分析タスクをスケジュールすることをお勧めします。 ジョブは、単一のタスクまたは複雑な依存関係を持つ大規模なマルチタスク ワークフローで構成できます。 Databricks は、すべてのジョブのタスク オーケストレーション、クラスター管理、監視、エラー報告を管理します。 ジョブは、使いやすいスケジューリングシステムを使用して、すぐに実行することも定期的に実行することもできます。 ジョブ タスクは、ノートブック、JARS、Delta Live Tables パイプライン、または Python、Scala、Spark 送信、および Java アプリケーションを使用して実装できます。 Databricks Workflowsの概要を参照してください。

  • 外部オーケストレーター:

    包括的な Databricks REST API は、Databricks アセット、ノートブック、およびジョブを調整するために外部オーケストレーターによって使用されます。 Apache Airflowを参照してください。

Auto Loader を使用する

Auto Loader、 クラウドストレージに到着した新しいデータファイルを増分的かつ効率的に処理します。JSON、CSV、PARQUET、AVRO、ORC、TEXT、などの多くのファイル形式を取り込むことができます BINARYFILE。 クラウドストレージ上の入力フォルダーを使用すると、 Auto Loader は新しいファイルが到着すると自動的に処理します。

1 回限りの取り込みの場合は、代わりにコマンド COPY INTO の使用を検討してください。 「COPY INTO を使用したデータのロードの概要」を参照してください。

Delta Live Tables を使用する

Delta Live Tables は、信頼性が高く、保守しやすく、テストしやすいデータ処理パイプラインを構築するための宣言型フレームワークです。 データに対して実行する変換を定義すると、Delta Live Tables によってタスク オーケストレーション、クラスター管理、モニタリング、データ品質、およびエラー処理が管理されます。

Delta Live Tablesを使用すると、SQL または Python でエンドツーエンドのデータパイプラインを簡単に定義できます。 データの DATA、変換ロジック、および宛先の状態を指定します。Delta Live Tables 依存関係を維持し、ジョブを実行するインフラストラクチャを自動的に決定します。

データ品質を管理するために、Delta Live Tables は時間の経過に伴うデータ品質の傾向を監視し、事前定義されたエラーポリシーを使用した検証と整合性チェックを通じて不正なデータがテーブルに流れ込むのを防ぎます。 「 Delta Live Tablesとは」を参照してください。

機械学習ワークロード のデプロイコードアプローチに従う

デプロイ コードのアプローチは、次のステップに従います。

  • トレーニング環境: トレーニング コードと補助コードを開発します。 次に、コードをステージングに昇格させます。

  • ステージング環境:データサブセットのトレーニングモデルと補助コードのテスト。 次に、コードを運用環境に昇格させます。

  • 本番環境:本番データとテストモデルのトレーニングするモデル。 次に、モデルと補助パイプラインをデプロイします。

「 モデルのデプロイ パターン」を参照してください。

このモデルの主な利点は次のとおりです。

  • これは、Git や CI/CD システムなどの使い慣れたツールを使用する従来のソフトウェア エンジニアリング ワークフローに適合します。

  • ロックダウン環境での自動再トレーニングをサポートします。

  • 本番環境のみが本番トレーニングデータへの読み取りアクセス権を必要とします。

  • トレーニング環境を完全に制御し、再現性を簡素化します。

  • これにより、データサイエンスチームはモジュラーコードと反復テストを使用できるため、大規模なプロジェクトでの調整と開発に役立ちます。

これについては、 MLOps ホワイトペーパーで詳しく説明されています。

モデルレジストリを使用してコードとモデルのライフサイクル を分離する

モデルのライフサイクルはコードのライフサイクルと 1 対 1 で対応していないため、モデル管理が独自のサービスを持つことは理にかなっています。 MLflow とそのモデルレジストリでは、UI と APIsを使用してモデル成果物を直接管理できます。 モデルアーティファクトとコードの疎結合により、コードを変更せずに本番モデルを更新する柔軟性が提供され、多くの場合、デプロイプロセスが合理化されます。 モデル成果物は、MLflow アクセス制御またはクラウド ストレージのアクセス許可を使用してセキュリティで保護されます。 Unity Catalogでのモデルのライフサイクルの管理を参照してください。

MLflow 自動ログ を使用する

Databricks 自動ログは、MLflow 自動ログを拡張して、Databricks での機械学習トレーニング セッションの自動エクスペリメント追跡を提供するコードなしのソリューションです。 Databricks 自動ログは、MLflow 追跡の実行として記録されたトレーニングの実行を使用してモデルをトレーニングするときに、モデル パラメーター、メトリクス、ファイル、および系列情報を自動的にキャプチャします。

同じインフラストラクチャを再利用して機械学習パイプライン を管理する

機械学習パイプラインは、他のデータパイプラインと同じ手法の多くを使用して自動化する必要があります。 Databricks Terraform プロバイダー を使用してデプロイを自動化します。機械学習では、推論ジョブ、エンドポイントの提供、特徴量化ジョブなどのインフラストラクチャをデプロイする必要があります。 すべての機械学習パイプラインはジョブ を使用したワークフローとして自動化でき、多くのデータ中心の機械学習パイプラインは、より専門的な Auto Loader を使用して、画像やその他のデータを取り込み、コンピュート機能に Delta Live Tables したり、メトリクスを監視したりできます。

3. モニタリング、アラート、ログ記録 を設定する

クラウドウォッチ を使用したプラットフォームのモニタリング

Databricks を CloudWatch と統合すると、ログとアラートから派生したメトリクスが有効になります。 CloudWatch Application 知見は、ログに含まれるフィールドを自動的に検出するのに役立ち、 CloudWatch Logs 知見 は、デバッグと分析を高速化するための専用のクエリー言語を提供します。

「 Amazon CloudWatch で Databricks をモニタリングする方法」を参照してください。

Ganglia 経由のクラスターモニタリング

クラスターの監視を支援するために、Databricks ではクラスターの詳細ページから Ganglia メトリクスへのアクセスが提供されており、これらには GPU メトリクスが含まれます。 「 Ganglia メトリクス」を参照してください。

SQLウェアハウス モニタリング

SQL ウェアハウスを監視することは、時間の経過に伴う負荷プロファイルを理解し、SQL ウェアハウスを効率的に管理するために不可欠です。 SQLウェアハウスモニタリングでは、ウェアハウスが処理したクエリ数やウェアハウスに割り当てられたクラスター数などの情報を確認できます。

Auto Loader モニタリング

Auto Loader には、ストリームの状態を検査するための SQL API が用意されています。 SQL 関数を使用すると、 Auto Loader ストリームによってディスカバーされたファイルに関するメタデータを検索できます。 詳しくは、 モニタリング Auto Loaderを参照してください。

Apache Spark ストリーミング クエリー リスナー インターフェイスを使用すると、 Auto Loader ストリームをさらに監視できます。

Delta Live Tables モニタリング

イベント ログは、 Delta Live Tables パイプラインごとに作成および管理されます。 イベント ログには、監査ログ、データ品質チェック、パイプラインの進行状況、データリネージなど、パイプラインに関連するすべての情報が含まれます。 イベント ログを使用して、データパイプラインの状態を追跡、理解、および監視できます。 「 Delta Live Tables パイプラインの監視」を参照してください。

ストリーミングモニタリング

ストリーミングは、取り込みと分析のための最も重要なデータ処理手法の 1 つです。 これにより、ユーザーと開発者は、アナリティクスとトリガーアクションのための低遅延とリアルタイムデータ処理機能を利用できます。 Databricksデータインテリジェンスプラットフォームを使用すると、構造化ストリーミング クエリーを簡単に監視できます。 「 モニタリング Structured Streaming クエリー on Databricks」を参照してください。

追加情報は、リアルタイムのメトリクスと統計を備えた専用UIにあります。 詳細については、「 Apache Spark 3.0 の新しい構造化ストリーミング UI の概要」を参照してください。

セキュリティ モニタリング

Security, Compliance & privacy - Security Monitoring を参照してください。

コストモニタリング

「コストの最適化 - コストの監視と制御」を参照してください。

4. 容量とクォータ を管理する

マネージドサービスの制限とクォータ

クラウド上で起動されるすべてのサービスは、アクセス速度制限、インスタンス数、ユーザー数、メモリ要件などの制限をアカウントに組み込む必要があります。 クラウド プロバイダーについては、 クラウドの制限を確認してください。 ソリューションを設計する前に、これらの制限を理解する必要があります。

具体的には、Databricks プラットフォームには、さまざまな種類の制限があります。

Databricks プラットフォームの制限:これらは Databricks リソースに固有の制限です。 プラットフォーム全体の制限については、 「リソース制限」に記載されています。

Unity Catalog 制限: Unity Catalog リソース クォータ

サブスクリプション/アカウント クォータ: Databricks はサービスにクラウド リソースを活用します。 たとえば、Databricks 上のワークロードはクラスター上で実行され、Databricks プラットフォームはクラウド プロバイダーの仮想マシン (VM) を起動します。 クラウド プロバイダーは、同時に起動できる VM の数についてデフォルトのクォータを設定します。 必要に応じて、これらのクォータを調整する必要があります。

詳細については、「 Amazon EC2 サービスクォータ」を参照してください。

同様に、ストレージ、ネットワーク、その他のクラウド サービスにも制限があるため、理解し、考慮する必要があります。

キャパシティ プランニング への投資

突然のビジネス変更や世界の出来事など、いくつかの理由で発生する可能性のある予想される負荷の変動を計画します。 予期しないものも含めて負荷の変動をテストして、ワークロードをスケーリングできることを確認します。 リージョンに障害が発生した場合に、すべてのリージョンが合計負荷をサポートするように適切にスケーリングできることを確認します。 考慮すべきこと:

  • クラウドのテクノロジーとサービスの制限と制限。 「 容量とクォータの管理」を参照してください。

  • 設計で使用するサービスを決定する際の SLA。

  • コストが増加した場合にアプリケーションでどの程度の改善が実現されるかを判断するためのコスト分析。 価格が投資する価値があるかどうかを評価します。