運用環境のワークロード 用に Auto Loader を構成する

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

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

  • コンピュートインフラストラクチャのオートスケーリングによるコスト削減

  • 期待値によるデータ品質チェック

  • 自動スキーマ進化処理

  • モニタリング via メトリクス in the event log

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 ストリームに関連付けられたチェックポイントの場所を指定できます。

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

ストリームの更新のリッスン

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

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

{
  "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 が作成したリソースにタグを付けてコストを追跡する

Trigger.AvailableNow とレート制限の使用

注：

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 つに達するために必要な数のファイルを処理します。

イベントの保持

Auto Loader は、RocksDB を使用してチェックポイントの場所で検出されたファイルを追跡し、厳密に 1 回のインジェストを保証します。 Databricks では、すべての大量または有効期間の長いインジェスト ストリームに cloudFiles.maxFileAge オプションを使用することを強くお勧めします。 このオプションでは、チェックポイントの場所からイベントが期限切れになるため、 Auto Loader の起動時間が短縮されます。 起動時間は 1 Auto Loader 実行あたりの分数に増加する可能性があり、ソース ディレクトリに格納されるファイルの最大経過時間に上限がある場合、不要なコストが増加します。 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 を使用して定期的なバックフィルをトリガーする

Auto Loader 、特定の間隔 (たとえば、1 日 1 日に 1 回バックフィルする、1 週間に 1 週間に 1 回バックフィルするなど) で非同期バックフィルをトリガーできます。 ファイルイベント通知システムは、アップロードされたすべてのファイルの100%配信を保証するものではなく、ファイルイベントの遅延に関する厳格なSLAを提供しません。 Databricks では、cloudFiles.backfillInterval オプションを使用して Auto Loader で定期的なバックフィルをトリガーし、データの完全性が要件である場合は、特定の SLA 内のすべてのファイルが検出されるようにすることをお勧めします。 通常のバックフィルをトリガーしても、重複は発生しません。