信頼性のためのベストプラクティス

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

1. 失敗を想定した設計

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

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

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

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

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

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

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

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

• Databricks Auto Loader: Auto Loader は、ファイル インジェストをストリーミングするための理想的なツールです。 JSONおよびCSVの レスキューされたデータ をサポートします。 たとえば、JSON の場合、救出されたデータ列には、指定されたスキーマに欠落していた、型の不一致があった、または列の大文字と小文字が一致しなかったなどの理由で解析されなかったデータが含まれます。 レスキューされたデータ列は、スキーマが推論されているときに Auto Loader によって返されるスキーマの一部_rescued_data デフォルトによって返されます。
• DLT: レジリエンスのためのワークフローを構築する別のオプションは、品質制約のある DLT を使用することです。「パイプラインのエクスペクテーションを使用してデータ品質を管理する」を参照してください。DLT は、デフォルトで 3 つのモード (無効なレコードの保持、削除、失敗) をサポートしています。識別された無効なレコードを検疫するために、特定の方法で期待ルールを定義して、無効なレコードを別のテーブルに格納 (検疫) することができます。「無効なレコードの検疫」を参照してください。

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

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

• Databricks ジョブは、失敗した実行を再試行するタイミングと回数を決定するタスクの再試行ポリシーをサポートしています。 再試行 ポリシーの設定を参照してください。
• タスクの予想 完了時間 やタスクの最大完了時間など、タスクの期間のしきい値をオプションで構成できます。
• また、DLT は、速度と信頼性のバランスを取るために、再試行をエスカレートすることで障害復旧を自動化します。開発モードと本番運用モードを参照してください。

一方、ハング タスクは、ジョブ全体を完了させず、コストが高くなる可能性があります。 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 の制約」を参照してください。

この処理をさらに改善するために、DLT はエクスペクテーションをサポートしています: エクスペクテーションは、データセットの内容に対するデータ品質制約を定義します。エクスペクテーションは、説明、不変式、およびレコードが不変式に違反した場合に実行するアクションで構成されます。クエリのエクスペクテーションは、Python デコレータまたは SQL 制約句を使用します。「パイプラインのエクスペクテーションを使用してデータ品質を管理する」を参照してください。

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

Databricks Data Intelligence Platform の AI ビジョンの中核をなす指針となるのは、機械学習に対するデータ中心のアプローチです。 生成AI が普及するにつれ、この視点は依然として重要です。

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

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

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

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

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

Enable オートスケール for SQLウェアハウス

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

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

4。回復手順をテストします

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

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

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

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

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

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

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

ディザスタリカバリパターンを構成する

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

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

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

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

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

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

「オペレーショナル・エクセレンス - モニタリング、アラート、ロギングの設定」を参照してください。