メインコンテンツまでスキップ

本番運用ワークロードの Auto Loader を構成する

Databricksでは、本番運用でAuto Loader を実行するための ストリーミングのベスト プラクティスに従うことをお勧めします。

Databricks では、DLT で Auto Loader を使用して増分データ取り込みを行うことをお勧めします。 DLTは Apache Spark 構造化ストリーミングの機能を拡張し、数行の宣言型 Python または SQL を記述するだけで、本番運用品質のデータパイプラインをデプロイできます。

Auto Loaderのモニタリング​

Auto Loader によって検出されたファイルのクエリ​

注記

cloud_files_state 関数は、Databricks Runtime 11.3 LTS 以降で使用できます。

Auto Loader は、ストリームの状態を検査するための SQL API を提供します。 cloud_files_state 関数を使用すると、 Auto Loader ストリームによって検出されたファイルに関するメタデータを検索できます。 cloud_files_stateからクエリを実行するだけで、 Auto Loader ストリームに関連付けられたチェックポイントの場所を指定できます。

SQL
SELECT * FROM cloud_files_state('path/to/checkpoint');

ストリームの更新を聞く​

Auto Loaderストリームをさらに監視するには、DatabricksApache Sparkのストリーミング Query Listener インターフェイスを使用することをお勧めします。

Auto Loader は、バッチごとにストリーミング Query Listener にメトリクスを報告します。 バックログに存在するファイルの数と、 numFilesOutstanding および numBytesOutstanding メトリクスのバックログの大きさは、ストリーミング クエリ進行状況ダッシュボードの 生データ タブで確認できます。

JSON
{
  "sources": [
    {
      "description": "CloudFilesSource[/path/to/source]",
      "metrics": {
        "numFilesOutstanding": "238",
        "numBytesOutstanding": "163939124006"
      }
    }
  ]
}

Databricks Runtime 10.4 LTS 以降では、ファイル通知モードを使用すると、AWS と Azureの approximateQueueSize としてクラウド上でキューに入れられるファイル イベントのおおよその数もメトリクスに含まれます。

コストに関する考慮事項​

Auto Loaderを実行する場合、コストの主なソースは、コンピュート リソースとファイル検出のコストになります。

コンピュートのコストを削減するために、 Databricks では、低レイテンシ要件がない限り、 Databricks ジョブを使用して Auto Loader を Trigger.AvailableNow を使用してバッチジョブとしてスケジュールすることをお勧めします。 構造化ストリーミングのトリガー間隔の設定を参照してください。

ファイル検出のコストは、ディレクトリ一覧モードのストレージ アカウントに対する LIST 操作、サブスクリプション サービスでの API 要求、およびファイル通知モードのキュー サービスの形式で発生する可能性があります。 ファイル検出のコストを削減するために、Databricks では次のことをお勧めします。

  • ディレクトリ一覧モードで Auto Loader 連続して実行する場合のProcessingTimeトリガーの提供
  • ストレージ アカウントへのファイルのアップロードを字句順で設計し、可能な場合は 増分リスト (非推奨) を活用する
  • インクリメンタルリストが不可能な場合のファイル通知の活用
  • リソース タグを使用して、Auto Loader によって作成されたリソースにタグを付け、コストを追跡する

トリガーを使用する。今すぐ利用可能、レート制限あり​

注記

Databricks Runtime 10.4 LTS 以降で使用できます。

Auto Loader は、Trigger.AvailableNow を使用して、 Databricks ジョブでバッチジョブとして実行するようにスケジュールできます。 AvailableNowトリガーは、クエリの開始時刻Auto Loader より前に 到着したすべてのファイルを処理するように に指示します。ストリームの開始後にアップロードされた新しいファイルは、次のトリガーまで無視されます。

Trigger.AvailableNowを使用すると、ファイル検出はデータ処理と非同期に行われ、レート制限を使用して複数のマイクロバッチ間でデータを処理できます。Auto Loader by デフォルトは、マイクロバッチごとに最大 1000 個のファイルを処理します。 cloudFiles.maxFilesPerTrigger と cloudFiles.maxBytesPerTrigger を構成して、マイクロバッチで処理するファイルの数またはバイト数を構成できます。ファイル制限はハード制限ですが、バイト制限はソフト制限であり、指定された maxBytesPerTriggerよりも多くのバイトを処理できます。 両方のオプションが一緒に提供されると、 Auto Loader は制限の 1 つに達するために必要な数のファイルを処理します。

チェックポイントの場所​

チェックポイントの場所は、ストリームの状態と進行状況の情報を格納するために使用されます。Databricks では、チェックポイントの場所をクラウド オブジェクト ライフサイクル ポリシーのない場所に設定することをお勧めします。チェックポイントの場所にあるファイルがポリシーに従ってクリーンアップされた場合、ストリームの状態は破損します。これが発生した場合は、ストリームを最初から再起動する必要があります。

ファイルイベントの追跡​

Auto Loader は、RocksDB を使用してチェックポイントの場所で検出されたファイルを追跡し、厳密に 1 回のインジェストを保証します。大量または有効期間の長いインジェスト ストリームの場合、Databricks では Databricks Runtime 15.4 LTS 以降にアップグレードすることをお勧めします。これらのバージョンでは、 Auto Loader はストリームが開始される前に RocksDB 状態全体がダウンロードされるのを待たないため、ストリームの起動時間を短縮できます。ファイルの状態が無制限に大きくなるのを防ぐ場合は、 cloudFiles.maxFileAge オプションを使用して、特定の経過時間より古いファイル イベントを期限切れにすることも検討できます。cloudFiles.maxFileAgeに設定できる最小値は "14 days"です。RocksDB での削除は、ツームストーンエントリとして表示されます。そのため、イベントの有効期限が切れると、ストレージの使用量が一時的に増加してから、横ばいになることがあります。

警告

cloudFiles.maxFileAge は、大量のデータセットのコスト管理メカニズムとして提供されます。 cloudFiles.maxFileAgeを積極的に調整しすぎると、重複インジェストやファイルの欠落など、データ品質の問題が発生する可能性があります。したがって、 Databricks では、cloudFiles.maxFileAge に対して 90 日間などの保守的な設定を推奨します。これは、同等のデータ取り込みソリューションが推奨する設定と似ています。

cloudFiles.maxFileAgeオプションを調整しようとすると、未処理のファイルが Auto Loader によって無視されたり、既に処理済みのファイルの有効期限が切れて再処理されたりして、データが重複する可能性があります。 cloudFiles.maxFileAgeを選択する際に考慮すべき点は次のとおりです。

  • ストリームが長時間後に再起動すると、キューからプルされたファイル通知イベントのうち cloudFiles.maxFileAge より古いものは無視されます。 同様に、ディレクトリ一覧を使用する場合、ダウンタイム中に表示された可能性のある cloudFiles.maxFileAge より古いファイルは無視されます。
  • ディレクトリリストモードを使用し、 cloudFiles.maxFileAgeを使用する場合 (たとえば、 "1 month"に設定されている場合は、ストリームを停止し、 cloudFiles.maxFileAge を "2 months"に設定してストリームを再開します。1 か月以上経過し、2 か月以上経過したファイルは再処理されます。

ストリームを初めて開始するときにこのオプションを設定すると、 cloudFiles.maxFileAgeより古いデータは取り込まれなくなるため、古いデータを取り込む場合は、ストリームを初めて開始するときにこのオプションを設定しないでください。 ただし、このオプションは後続の実行で設定する必要があります。

cloudFiles.backfillInterval を使用して定期的なバックフィルをトリガーします。​

まれに、通知メッセージの保持制限に達した場合など、通知システムのみに依存している場合に、ファイルが見落とされたり遅延したりすることがあります。データの完全性と SLA に厳しい要件がある場合は、指定した間隔で非同期バックフィルをトリガーするように cloudFiles.backfillInterval を設定することを検討してください。たとえば、毎日のバックフィルの場合は 1 日、毎週のバックフィルの場合は 1 週間に設定します。通常のバックフィルをトリガーしても、重複は発生しません。

に最終更新