信頼性に関するベスト プラクティス

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

1. 失敗に備えた設計

Delta Lakeを使用する

Delta Lake は、データレイクに信頼性をもたらすオープンソースのストレージ形式です。 Delta Lake は、ACIDトランザクション、スキーマ強制、スケーラブルなメタデータ処理を提供し、ストリーミングとバッチのデータ処理を統合します。 Delta Lake は既存のデータレイク上で実行され、Apache Spark APIsと完全に互換性があります。 Databricks のDelta Lake を使用すると、ワークロード パターンに基づいて Delta Lake を構成できます。「 Delta Lakeとは」を参照してください。

Apache Spark または Photon を分散コンピュートに使用する

Apache Spark は、Databricks レイクハウスのコンピュート エンジンとして、復元力のある分散データ処理に基づいています。 内部 Spark タスクが期待どおりの結果を返さない場合、Apache Spark は不足しているタスクを自動的に再スケジュールし、ジョブ全体の実行を続行します。 これは、短いネットワークの問題やスポット VM の失効など、コード外のエラーに役立ちます。 SQL API と Spark DataFrame API の両方を操作するには、この回復力がエンジンに組み込まれています。

Databricks レイクハウスでは、完全に C++ で記述されたネイティブのベクトル化エンジンであるPhoton は、Apache Spark APIsと互換性のある高性能コンピュートです。

無効または不適合なデータを自動的にレスキュー

無効または不適合なデータは、確立されたデータ形式に依存するワークロードのクラッシュにつながる可能性があります。 プロセス全体のエンドツーエンドの回復性を高めるには、インジェスト時に無効で不適合なデータを除外することをお勧めします。 レスキューされたデータをサポートすることで、取り込みまたは ETL 中にデータが失われたり見逃されたりすることはありません。 レスキューされたデータ列には、指定されたスキーマに存在しないか、型の不一致があったか、レコードまたはファイルの列の大文字と小文字がスキーマ内の列の大文字と小文字と一致しなかったために解析されなかったデータが含まれます。

• Databricks Auto Loader: Auto Loader は、ファイルの取り込みをストリーミングするための理想的なツールです。JSONおよびCSVの レスキューデータ をサポートしています。 たとえば、JSON の場合、レスキューされたデータ列には、指定されたスキーマに存在しないか、型の不一致があったか、列の大文字と小文字が一致しなかったために、解析されなかったデータが含まれます。 レスキューされたデータ列は、スキーマが推論されているときに Auto Loader によって _rescued_data デフォルトによって返されるスキーマの一部です。

• Delta Live Tables: レジリエンスのためのワークフローを構築する別のオプションは、品質制約のある Delta Live Tables を使用することです。 Delta Live Tablesを使用したデータ品質の管理を参照してください。Delta Live Tables は、保持、削除、無効なレコードの失敗という 3 つのモードをすぐにサポートしています。識別された無効なレコードを検疫するには、無効なレコードが別のテーブルに格納 ("検疫") されるように、特定の方法で期待ルールを定義できます。 無効なデータの検疫を参照してください。

自動再試行と自動終了のためのジョブの構成

分散システムは複雑であり、ある時点での障害がシステム全体に連鎖する可能性があります。

• Databricks ジョブは、失敗した実行をいつ、何回再試行するかを決定する 自動再試行ポリシー をサポートしています。

• またDelta Live Tables では、再試行のエスカレーションを使用して速度と信頼性のバランスを取ることで、障害復旧を自動化します。開発モードと本番モードを参照してください。

一方、ハングするタスクは、ジョブ全体の完了を妨げる可能性があり、したがって、高コストが発生します。 Databricks ジョブは、予想よりも時間がかかるジョブを終了するためのタイムアウト構成をサポートしています。

スケーラブルで実稼働グレードのモデルを提供するインフラストラクチャを使用する

バッチ推論とストリーミング推論の場合は、Databricks ジョブと MLflow を使用してモデルを Apache Spark UDF としてデプロイし、ジョブのスケジュール設定、再試行、オートスケールなどを活用します。 「 モデル推論に MLflow を使用する」を参照してください。

モデル サービングは、スケーラブルで実稼働グレードのモデル リアルタイム サービング インフラストラクチャを提供します。MLflow を使用して機械学習モデルを処理し、REST API エンドポイントとして公開します。 この機能はサーバレス コンピュートを使用するため、エンドポイントと関連するコンピュート リソースは Databricks クラウド アカウントで管理および実行されます。

可能な場合はマネージドサービスを使用する

可能な場合は 、Delta Live Tables サーバレス コンピュート、モデルサービング 、 などの Data Intelligence Platform のマネージド サービスを活用します。Databricksこれらのサービスは、顧客による追加の労力なしに、Databricks によって信頼性が高くスケーラブルな方法で運用され、ワークロードの信頼性が向上します。

2. データ品質を管理する

階層型ストレージアーキテクチャを使用する

階層化されたアーキテクチャを作成し、データがレイヤー内を移動するときにデータ品質が向上するようにすることで、データをキュレーションします。 一般的な階層化アプローチは次のとおりです。

• 生の層(ブロンズ): ソース データはレイクハウスの最初のレイヤーに取り込まれ、そこで永続化する必要があります。 すべてのダウンストリーム データが生のレイヤーから作成されると、必要に応じてこのレイヤーから後続のレイヤーを再構築できます。

• キュレーションレイヤー(シルバー): 2番目のレイヤーの目的は、クレンジング、絞り込み、フィルタリング、および集計されたデータを保持することです。 このレイヤーの目標は、すべての役割と機能にわたる分析とレポートのための健全で信頼性の高い基盤を提供することです。

• 最終層(ゴールド): 3番目のレイヤーは、ビジネスまたはプロジェクトのニーズを中心に作成されます。 データ製品として他の事業単位やプロジェクトとは異なるビューを提供し、セキュリティ ニーズに関するデータ (匿名化されたデータなど) を準備したり、パフォーマンスを最適化したりします (事前集計ビューなど)。 このレイヤーのデータ製品は、ビジネスにとって真実と見なされています。

最後のレイヤーには高品質のデータのみを含める必要があり、ビジネスの観点からは完全に信頼できます。

データの冗長性を低減することでデータ完全性を改善

データをコピーまたは複製すると、データの冗長性が生まれ、整合性が失われ、データリネージが失われ、多くの場合、アクセス許可が異なります。 これにより、レイクハウスのデータの品質が低下します。 データの一時的または使い捨てのコピーは、それ自体では有害ではなく、俊敏性、実験、イノベーションを促進するために必要な場合があります。 ただし、これらのコピーが運用可能になり、ビジネス上の意思決定に定期的に使用されるようになると、データサイロになります。 これらのデータサイロが同期しなくなると、データ完全性と品質に大きな悪影響を及ぼし、「どのデータセットがマスターですか?」や「データは最新のデータセットですか?」などの疑問が生じます。

スキーマを積極的に管理する

制御されていないスキーマの変更は、無効なデータや、これらのデータ・セットを使用するジョブの失敗につながる可能性があります。 Databricks には、スキーマを検証および適用するためのいくつかの方法があります。

• Delta Lake は、スキーマのバリエーションを自動的に処理して、インジェスト中に不正なレコードが挿入されないようにすることで、スキーマ 検証とスキーマ強制 をサポートします。

• Auto Loaderは、 データの処理中に新しい列の追加を検出します。デフォルトでは、新しい列を追加すると、ストリームは UnknownFieldExceptionで停止します。 Auto Loader では、 スキーマ進化のためのいくつかのモードがサポートされています。

制約とデータのエクスペクテーションを使用する

Delta テーブルは、テーブルに追加されたデータの品質と整合性が自動的に検証されることを保証する標準の SQL 制約管理句をサポートしています。 制約に違反すると、Delta Lake は新しいデータを追加できないことを示す InvariantViolationException エラーをスローします。 Databricksの制約を参照してください。

この処理をさらに改善するために、 Delta Live Tables では、データ セットの内容に対するデータ品質の制約を定義します。 期待値は、説明、不変式、およびレコードが不変式に失敗したときに実行するアクションで構成されます。 クエリーへの期待は、PythonデコレータまたはSQL制約句を使用します。 Delta Live Tablesを使用したデータ品質の管理を参照してください。

機械学習にデータ中心のアプローチを採用する

特徴量エンジニアリング、トレーニング、推論、監視パイプラインはデータ パイプラインです。 これらは、他の本番運用データエンジニアリング プロセスと同じくらい堅牢である必要があります。 データ品質は機械学習アプリケーションにおいて非常に重要であるため、機械学習データパイプラインはデータ品質の問題をモニタリングし軽減するための体系的なアプローチを採用する必要があります。 機械学習の予測やモデルモニタリングなどのデータを残りのデータと結合することを困難にするツールは避けてください。 これを実現する最も簡単な方法は、本番運用データの管理に使用されるのと同じプラットフォーム上で機械学習アプリケーションを開発することです。 たとえば、結果を管理して再現するのが難しいトレーニング データをラップトップにダウンロードする代わりに、データをクラウド ストレージに保護し、そのストレージをトレーニング プロセスで利用できるようにします。

3. オートスケールの設計

バッチワークロードのオートスケールを有効にする

オートスケールにより、クラスターはワークロードに基づいて自動的にサイズを変更できます。 オートスケールは、コストとパフォーマンスの両方の観点から、多くのユースケースとシナリオにメリットをもたらします。 このドキュメントでは、オートスケールを使用するかどうか、またそのメリットを最大限に得る方法を決定するための考慮事項について説明します。

ストリーミング ワークロードの場合、Databricks ではオートスケールで Delta Live Tables を使用することをお勧めします。 オートスケールを使用して効率を高め、リソース使用量を削減するを参照してください。

SQLウェアハウスのオートスケールを有効化する

SQLクエリーウェアハウスのスケーリング・パラメーターは、ウェアハウスに送信されるクラスターの最小数と最大数を分散するように設定します。 デフォルトは、最小値は 1 つ、最大値は 1 つのクラスターです。

特定のウェアハウスでより多くのライナー ユーザーを処理するには、クラスター数を増やします。 Databricks がウェアハウスにクラスターを追加したり、ウェアハウスからクラスターを削除したりする方法については、 「 SQLウェアハウスのサイジング、スケーリング、およびキューの動作 」を参照してください。

拡張オートスケール Delta Live Tables の使用

Databricks Enhanced オートスケール は、パイプラインのデータ処理待機時間への影響を最小限に抑えながら、ワークロードの量に基づいてクラスター リソースを自動的に割り当てることで、クラスターの使用率を最適化します。

4.テスト回復手順

定期的なバックアップを作成する

障害から回復するには、定期的なバックアップが使用可能である必要があります。 Databricks Labs プロジェクトの移行により、ワークスペース管理者はワークスペースのほとんどの資産をエクスポートしてバックアップを作成できます (ツールはバックグラウンドで Databricks CLI/API を使用します)。 「 Databricks 移行ツール 」を参照してください。 バックアップは、ワークスペースを復元するため、または移行の場合に新しいワークスペースにインポートするために使用できます。

構造化ストリーミングからの復旧 クエリーの障害

構造化ストリーミングは、ストリーミングクエリーのフォールトトレランスとデータの一貫性を提供します。 Databricks ワークフローを使用すると、障害発生時に自動的に再起動するように構造化ストリーミング クエリーを簡単に構成できます。 再開されたクエリーは、失敗したクエリーが中断したところから続行されます。 「 構造化ストリーミングクエリーの失敗からのワークフローによる回復」を参照してください。

Delta タイムトラベルに基づくETLジョブの回復

徹底的なテストにもかかわらず、運用環境のジョブが失敗したり、予期しない、さらには無効なデータが生成されたりする可能性があります。 これは、問題の原因を理解し、最初に問題を引き起こしたパイプラインを修正した後、追加のジョブで修正できる場合があります。 ただし、多くの場合、これは単純ではなく、それぞれのジョブをロールバックする必要があります。 Delta Time Travelを使用すると、ユーザーは古いバージョンまたはタイムスタンプへの変更を簡単にロールバックし、パイプラインを修復し、固定パイプラインを再起動できます。タイム トラベル Delta Lake とはを参照してください。

これを行う便利な方法は、 RESTORE コマンドです。

Databricks Workflows と組み込みの回復を使用する

Databricks Workflows は回復のために構築されています。 マルチタスク ジョブのタスク (およびすべての依存タスク) が失敗した場合、 Databricks Workflows 実行のマトリックス ビューを提供し、失敗の原因となった問題を調べることができます。 「ジョブの実行の表示」を参照してください。それが短いネットワークの問題であろうと、データの実際の問題であろうと、あなたはそれを修正して修復の実行を開始することができます Databricks Workflows。 失敗したタスクと依存タスクのみを実行し、以前の実行から成功した結果を保持するため、時間とコストを節約できます。

障害復旧パターンを構成する

明確なディザスター リカバリー パターンは、Databricks のようなクラウドネイティブのデータ アナリティクス プラットフォームにとって重要です。 一部の企業では、ハリケーンや地震などの地域の災害など、地域のサービス全体のクラウド サービス プロバイダーが停止したまれなケースでも、データ チームが Databricks プラットフォームを使用できることが重要です。

Databricks は、多くの場合、アップストリーム データ取り込みサービス (バッチ/ストリーミング)、クラウドネイティブ ストレージ、ビジネスインテリジェンス アプリなどのダウンストリーム ツールとサービス、オーケストレーション ツールなど、多くのサービスを含むデータ エコシステム全体のコア部分です。 一部のユース ケースは、リージョン全体のサービス停止に特に敏感な場合があります。

ディザスタリカバリには、自然災害または人為的災害後の重要なテクノロジーインフラストラクチャとシステムのリカバリまたは継続を可能にする一連のポリシー、ツール、および手順が含まれます。 Azure、AWS、GCP などの大規模なクラウド サービスは、多くのお客様にサービスを提供し、1 つの障害に対する組み込みガードを備えています。 たとえば、リージョンは、1 つの電力損失によってリージョンがシャットダウンされないことを保証するために、異なる電源に接続された建物のグループです。 ただし、クラウド リージョンの障害が発生する可能性があり、中断の程度と組織への影響は異なる場合があります。 災害復旧を参照してください。

ディザスター リカバリー戦略の重要な部分は、戦略 (アクティブ/アクティブまたはアクティブ/パッシブ) の選択、適切なツールセットの選択、 フェールオーバー と 復元の両方のテストです。

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

オペレーショナル エクセレンスに関する記事では、「 オペレーショナル エクセレンス - デプロイとワークロードの自動化」を参照してください。

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

オペレーショナル エクセレンスのベスト プラクティスに関する記事の「 オペレーショナル エクセレンス - モニタリング、アラート、ログ記録の設定」を参照してください。