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

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

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

オートスケールコンピュートコスト削減のためのインフラストラクチャ
期待に沿ったデータ品質チェック
スキーマ進化の自動処理
モニタリング via メトリクスイベントログの

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 ストリームをさらに監視するには、Databricks Apache Spark のストリーミングクエリーリスナーインターフェイスを使用することをお勧めします。

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

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

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

コストに関する考慮事項

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

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

ファイル検出のコストは、ディレクトリ一覧モードのストレージアカウントに対する 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 DEFAULTは、マイクロバッチごとに最大1000ファイルを処理します。 cloudFiles.maxFilesPerTrigger と cloudFiles.maxBytesPerTrigger を設定して、マイクロバッチで処理するファイル数またはバイト数を設定できます。ファイル制限はハード制限ですが、バイト制限はソフト制限であり、指定された maxBytesPerTriggerよりも多くのバイトを処理できることを意味します。両方のオプションが一緒に提供される場合、 Auto Loader は制限の 1 つに達するために必要な数のファイルを処理します。

イベントの保持

Auto Loader は、RocksDB を使用してチェックポイントの場所で検出されたファイルを追跡し、一度だけインジェストを保証します。 Databricks では、すべての大量または有効期間の長いインジェストストリームに対して cloudFiles.maxFileAge オプションを使用することを強くお勧めします。このオプションでは、チェックポイントの場所からのイベントの有効期限が切れるため、起動時間が短縮 Auto Loader 。起動時間は Auto Loader 実行あたりの分数に増加する可能性があり、ソースディレクトリに格納されるファイルの最大保存期間に上限が設定されている場合、不要なコストが追加されます。 cloudFiles.maxFileAge に設定できる最小値は "14 days"です。RocksDB での削除は廃棄エントリとして表示されるため、イベントが横ばいになる前に有効期限が切れると、ストレージ使用量が一時的に増加することを期待する必要があります。

警告

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

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 内で検出されるようにすることをお勧めします。通常のバックフィルをトリガーしても、重複は発生しません。

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