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

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

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 ジョブは、予想よりも時間がかかるジョブを強制終了するためのタイムアウト構成をサポートしています。

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

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

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

可能な場合は、サーバレス 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 Enhanced オートスケールは、ワークロードの量に基づいてクラスターリソースを自動的に割り当てることで、パイプラインのデータ処理レイテンシへの影響を最小限に抑えながら、クラスターの使用率を最適化します。

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

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

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

4.テスト回復手順

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

構造化ストリーミングは、ストリーミングクエリのフォールトトレランスとデータの一貫性を提供します。 Databricks ジョブを使用すると、失敗時に自動的に再起動するように構造化ストリーミングクエリを簡単に構成できます。ストリーミングクエリのチェックポイント設定を有効にすると、失敗後にクエリを再起動できます。再開されたクエリは、失敗したクエリが中断したところから続行されます。構造化ストリーミングについては、構造化ストリーミングチェックポイントおよび本番運用に関する考慮事項を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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