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

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

1. 失敗に備えた設計

ACIDトランザクションをサポートするデータ形式を使用する

ACID認証は、データの完全性と一貫性を維持するための重要な機能です。 ACIDトランザクションをサポートするデータ形式を選択すると、よりシンプルで信頼性の高いパイプラインを構築できます。

Delta Lakeは、 ACIDトランザクションと、ストレージを強制するスケーラブルなメタデータ処理を提供し、ストリーミングとバッチ データ処理を統合するオープンソース ストレージ フレームワークです。 Delta Lake Apache Spark APIsと完全に互換性があり、構造化ストリーミングとの緊密な統合を実現するように設計されているため、バッチ操作とストリーミング操作の両方で単一のデータコピーを簡単に使用して、大規模な増分処理を提供できます。

すべてのワークロードに回復力のある分散データエンジンを使用

レイクハウスのコンピュート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:回復力のあるワークフローを構築するもう 1 つのオプションは、品質制約付きのDelta Live Tablesを使用することです。 「Delta Live Tables を使用したデータ品質の管理」を参照してください。 Delta Live Tables は、無効なレコードの保持、削除、失敗の 3 つのモードをすぐにサポートします。 識別された無効なレコードを隔離するには、無効なレコードが別のテーブルに格納 (「隔離」) されるように、特定の方法で期待値ルールを定義できます。 無効なデータの検疫を参照してください。

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

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

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

  • タスクの予想完了時間や最大完了時間など、タスクのオプションの期間しきい値を構成できます。

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

一方、タスクが滞留すると、ジョブ全体が完了しなくなり、コストが高額になる可能性があります。 Databricks ジョブは、予想よりも時間がかかるジョブを強制終了するためのタイムアウト構成をサポートしています。

スケーラブルで本番運用グレードのモデルサービングインフラストラクチャを使用する

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

可能な場合は、サーバレスSQLウェアハウスなどのマネージドサービスを活用します。 これらのサービスは、顧客に追加費用をかけずに、信頼性が高くスケーラブルな方法で 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 を使用したデータ品質の管理」を参照してください。

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

Databricks データ インテリジェンス プラットフォームの AI ビジョンの中核となる指針は、機械学習に対するデータ中心のアプローチです。 生成AIが普及するにつれて、この視点は同様に重要になります。

あらゆるMLプロジェクトのコア コンポーネントは、単純にデータ パイプラインと考えることができます。機能エンジニアリング、トレーニング、モデルのデプロイメント、推論、モニタリング パイプラインはすべてデータ パイプラインです。 そのため、 MLソリューションを運用化するには、予測、モニタリング、特徴量テーブルのデータを他の関連データとマージする必要があります。 基本的に、これを実現する最も簡単な方法は、本番運用データを管理するのと同じプラットフォーム上でAIを活用したソリューションを開発することです。 データ中心の MLOps と LLMOps をご覧ください

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

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

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

ストリーミング ワークロードの場合、 Databricksオートスケールを使用したDelta Live Tablesの使用を推奨しています。 Databricks拡張オートスケールは、パイプラインのデータ処理のレイテンシへの影響を最小限に抑えながら、ワークロード ボリュームに基づいてクラスター リソースを自動的に割り当てることで、クラスターの使用率を最適化します。

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

SQLウェアハウスのスケーリング は、ウェアハウスに送信されたクエリが分散されるクラスターの最小数と最大数を設定します。 デフォルトはオートスケール無しのクラスター1個です。

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

4.テスト回復手順

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

構造化ストリーミングは、ストリーミング クエリのフォールト トレランスとデータの一貫性を提供します。Databricks ワークフローを使用すると、障害発生時に自動的に再開するように構造化ストリーミング クエリを簡単に構成できます。 ストリーミング クエリのチェックポイントを有効にすると、失敗後にクエリを再開できます。 再開されたクエリは、失敗したクエリが中断したところから続行されます。

データタイムトラベル機能を使用してETLジョブを回復する

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

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

組み込みリカバリを備えたジョブ自動化フレームワークを活用する

Databricks Workflows回復用に設計されています。 複数タスクのジョブ内のタスク (およびすべての依存タスク) が失敗すると、 Databricks Workflowsは実行のマトリックス ビューが提供され、失敗の原因となった問題を調査できます。 ジョブの実行の表示に関するページを参照してください。 短いネットワークの問題であっても、データ内の実際の問題であっても、それを修正し、 Databricks Workflowsで修復実行を開始できます。 失敗したタスクと依存タスクのみを実行し、以前の実行からの成功した結果を保持するため、時間とコストを節約できます。 ジョブの失敗のトラブルシューティングと修復を参照してください。

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

Databricksのようなクラウドネイティブ データ分析プラットフォームでは、明確なディザスタリカバリ パターンが重要です。 ハリケーン、地震、その他の地域的災害などによってクラウド サービス プロバイダーが地域全体でサービス停止するといった稀な事態が発生した場合でも、データ チームがDatabricksプラットフォームを使用できることが重要です。

Databricks 、上流のデータ取り込みサービス (バッチ/ストリーミング)、Google Google Cloud Storageインテリジェント アプリなどの下流のツールとサービス、オーケストレーション ツールなど、多くのサービスを含む全体的なデータ エコシステムの中核となることがよくあります。 一部のユースケースは、地域全体のサービス停止の影響を特に受けやすい場合があります。

ディザスタリカバリには、自然災害または人為的災害が発生した後に重要な技術インフラストラクチャとシステムを復旧または継続できるようにする一連のポリシー、ツール、および手順が含まれます。 Google クラウドなどの大規模なクラウド サービスは、多くの顧客にサービスを提供しており、単一の障害に対しても保護機能を備えています。 たとえば、リージョンとは、単一の停電によってリージョンがダウンすることがないように、異なる電源に接続された建物のグループです。 ただし、クラウド リージョンの障害が発生する可能性があり、障害の重大度とビジネスへの影響はさまざまです。

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

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

6. システムとワークロードを監視する

「Operational Excellence - モニタリング、アラート、およびログ記録の設定」を参照してください。