自動ローダーを使用する cloudFiles.useManagedFileEvents オプションを使用すると、効率的なファイル検出が可能になります。
ファイル イベントを使用した自動ローダーのしくみ
ファイル イベントを含む自動ローダーでは、クラウド ベンダーによって提供されるファイル イベント通知機能が使用されます。 新しいファイルの作成や変更などのファイル イベント時に通知を発行するようにクラウド ストレージ コンテナーを構成できます。 たとえば、 Amazon S3 イベント通知では、新しいファイル到着によって Amazon SNS トピックへの通知をトリガーできます (詳細については、 Amazon S3 通知コンテンツ構造 を参照してください)。 その後、Amazon SQS キューを SNS トピックにサブスクライブして、イベントの非同期処理を行うことができます。
Azure Databricks ファイル イベントは、ファイル イベントをリッスンするようにクラウド リソースを設定するサービスです。 または、クラウド リソースを自分で設定し、独自のストレージ キューを提供することもできます。
クラウド リソースを構成すると、サービスはファイル イベント通知を処理し、ファイル メタデータをキャッシュします。 自動ローダーは、 cloudFiles.useManagedFileEvents が true に設定された状態で実行されるときに、このキャッシュを使用してファイルを検出します。
cloudFiles.useManagedFileEventsがtrueに設定された状態でストリームを初めて実行すると、自動ローダーはロード パスの完全なディレクトリ 一覧を実行して、すべてのファイルを検出し、ファイル イベント キャッシュで最新の状態を取得します (キャッシュ内の有効な読み取り位置をセキュリティで保護し、ストリームのチェックポイントに格納します)。 自動ローダーの後続の実行では、格納されている読み取り位置を使用してファイル イベント キャッシュから直接読み取ることによって新しいファイルを検出し、ディレクトリの一覧を必要としません。
Databricks では、キャッシュからの増分ファイル検出を利用するために、自動ローダー ストリームを少なくとも 7 日に 1 回実行することをお勧めします。 自動ローダーを少なくとも頻繁に実行しない場合、格納されている読み取り位置は無効になり、自動ローダーはファイル イベント キャッシュと同期するために完全なディレクトリ 一覧を実行する必要があります。
ファイル イベント モードとクラシック ファイル通知モード
この図では、ファイル イベント モードとクラシック ファイル通知モードを比較します。
ファイル イベント モードでは、1 つのマネージド ファイル イベント サービスが顧客のクラウド ストレージに接続します。 自動ローダーやトリガーなど、複数のコンシューマーにサービスを提供する 1 つの共有 SNS トピック、SQS キュー、および SNS から SQS へのサブスクリプションが作成されます。 クラシック ファイル通知モードでは、各コンシューマーが独自のイベント サブスクリプションとキューを必要とするため、バケットごとに複数の個別の通知パイプラインが生成されます。
ファイル イベント モードには、クラシック ファイル通知モードと比較して、いくつかの利点があります。 主に、バケット上のすべての自動ローダー ストリームに必要なキューは 1 つだけであり、 バケットごとの通知の制限を回避するのに役立ちます。 詳細については、「 外部の場所でファイル イベントを有効にした場合と有効にしない場合のファイル通知モード」を参照してください。
ファイル イベントを含む自動ローダーでディレクトリ一覧を使用するタイミング
自動ローダーは、次の場合に完全なディレクトリ一覧を実行します。
- 新しいストリームを開始します。
- ディレクトリ一覧またはクラシック ファイル通知からのストリームの移行。
- ファイル イベントを含む自動ローダーは、7 日を超える間実行されません。
- 自動ローダーの読み取り位置を無効にする外部の場所を更新します。 たとえば、ファイル イベントをオフにしたりオンにしたり、外部の場所のパスを変更したり、外部の場所に別のキューを指定したりする場合などがあります。
自動ローダーは、 includeExistingFiles が false に設定されている場合でも、常に最初の実行時に完全な一覧を実行します。 このフラグを使用すると、ストリームの開始時刻後に作成されたすべてのファイルを取り込めます。 自動ローダーは、ディレクトリ全体を一覧表示して、ストリームの開始時刻後に作成されたすべてのファイルを検出し、ファイル イベント キャッシュに読み取り位置を確立し、チェックポイントに格納します。 後続の実行はファイル イベント キャッシュから直接読み取られ、ディレクトリの一覧は必要ありません。
また、Azure Databricks ファイル イベント サービスは、外部の場所で完全なディレクトリ一覧を実行して、ファイルが見落とされていないことを確認します (たとえば、指定されたキューが正しく構成されていない場合)。 最初の完全なディレクトリ一覧は、外部の場所でファイル イベントが有効になるとすぐに開始されます。 ファイル イベントを使用してデータを取り込む自動ローダー ストリームが少なくとも 1 つある限り、最後のフル スキャンの 24 時間後に、後続の各一覧が発生します。
ファイル イベントを使用した自動ローダーのベスト プラクティス
ファイル イベントで自動ローダーを使用する場合のパフォーマンスと信頼性を最適化するには、次のベスト プラクティスに従います。
最適なファイル検出にボリュームを使用する
パフォーマンスを向上させるために、Databricks では、自動ローダーがデータを読み込むパスまたはサブディレクトリごとに外部ボリュームを作成し、クラウド パス (/Volumes/someCatalog/someSchema/someVolume など) ではなくボリューム パス (s3://bucket/path/to/volume など) を自動ローダーに提供することをお勧めします。 これにより、自動ローダーは最適化されたデータ アクセス パターンを使用してボリュームを一覧表示できるため、ファイルの検出が最適化されます。
イベント ドリブン パイプラインのファイル到着トリガーを検討する
イベント ドリブンデータ処理の場合は、継続的パイプラインではなく ファイル到着トリガー を使用することを検討してください。 新しいファイルが到着すると、ファイル到着トリガーによってパイプラインが自動的に開始され、処理する新しいファイルがある場合にのみクラスターが実行されるため、リソース使用率とコスト効率が向上します。
連続トリガーを使用して適切な間隔を構成する
Databricks では、 ファイル到着トリガー を使用して、到着するとすぐにファイルを処理することをお勧めします。 ただし、 Trigger.ProcessingTimeなどの継続的トリガーを使用してユース ケースの待機時間を短縮する必要がある場合、Databricks ではトリガー間隔を 1 minute 以上に構成することをお勧めします。 Lakeflow Spark 宣言パイプラインで、 pipelines.trigger.intervalを使用してこの値を設定します。 これにより、新しいファイルが到着したかどうかを確認するポーリング頻度が低くなり、ワークスペースから同時に実行できるストリームの数が増えます。
待機時間が非常に短い要件については、代わりに クラシック ファイル通知モード を検討してください。 ファイル イベントでは、クラウド ストレージと自動ローダーの間にキャッシュ ホップが追加されます。これにより、クラウド キューから直接読み取る場合と比較して待機時間が長くなる可能性があります。
ファイル イベントを使用した自動ローダーの制限事項
自動ローダーでは、パスの書き換えはサポートされていません。 パスの書き換えは、DBFS の下に複数のバケットまたはコンテナーがマウントされている場合に適用されます。これは非推奨の使用パターンです。
ファイル イベントの制限事項の一般的な一覧については、「 ファイル イベントの制限事項」を参照してください。