自動ローダーについてよく寄せられる質問

Databricks 自動ローダーに関してよく寄せられる質問とその回答を紹介します。

ファイルにデータが追加されるか上書きされる場合、自動ローダーはファイルを再び処理しますか?

既定の設定 (cloudFiles.allowOverwrites = false) では、ファイルは 1 回だけ処理されます。 ファイルが追加または上書きされると、自動ローダーは処理されるファイルバージョンを保証できません。 自動ローダーが追加または上書きされたときにファイルを再び処理できるようにするには、 cloudFiles.allowOverwrites を true に設定します。 この場合、自動ローダーは、ファイルの最新バージョンを処理することが保証されます。 ただし、自動ローダーでは、どの中間バージョンが処理されているかを保証できません。

ファイル通知モードで cloudFiles.allowOverwrites を有効にする場合は注意が必要です。 ファイル通知モードでは、自動ローダーは、ファイル通知とディレクトリ一覧の両方を使用して新しいファイルを識別できます。 ファイル通知イベント時間とファイル変更時間が異なる場合があるため、自動ローダーは 2 つの異なるタイムスタンプを受信し、ファイルが更新されていない場合でも同じファイルを 2 回取り込むことができます。

cloudFiles.allowOverwrites有効になっている場合は、重複するレコードを自分で処理する必要があります。 自動ローダーは、ファイルが追加または部分的に更新された場合でも、ファイル全体を再処理します。 一般に、Azure Databricks では、自動ローダーを使用して変更できないファイルのみを取り込み、既定の設定 cloudFiles.allowOverwrites = false使用することをお勧めします。 さらに質問がある場合は、Azure Databricks アカウント チームにお問い合わせください。

自動ローダーは、ファイルが取り込まれたかどうかをどのように判断しますか?

自動ローダーは通常、ファイル パスに基づいて各ファイルを 1 回だけ取り込みます。 ただし、 allowOverwrites オプションを trueに設定した場合、自動ローダーでは、ファイルの最終変更タイムスタンプを使用して、ファイルが新しいか更新されたか、再取り込みする必要があるかを判断します。 「自動ローダーは、ファイルが追加または上書きされたときに、ファイルを再び処理しますか?」を参照してください。

データ ファイルが継続的ではなく、一定の間隔 (たとえば、1 日に 1 回) で到着する場合でも、このソースを使用する必要がありますか? また、ベネフィットはありますか?

この場合は、 Trigger.AvailableNow (Databricks Runtime 10.4 LTS 以降で使用可能) 構造化ストリーミング ジョブとスケジュールを、予想されるファイル到着時刻の後に実行するように設定できます。 自動ローダーは、頻繁でない更新と頻繁な更新の両方でうまく機能します。 最終的な更新が非常に大きい場合でも、自動ローダーは入力サイズに合わせてスケーリングします。 自動ローダーの効率的なファイル検出手法とスキーマ進化機能により、自動ローダーは増分データ インジェストの推奨される方法になります。

自動ローダーでスキーマを推論する方法

DataFrame が最初に定義されると、自動ローダーによってソース ディレクトリが一覧表示され、最新の (ファイル変更時間によって) 50 GB のデータまたは 1000 個のファイルが選択され、データ スキーマを推測するために使用されます。

自動ローダーは、ソース ディレクトリ構造を調べてパーティション列を推論し、 /key=value/ 構造を含むファイル パスを探します。 次のように、ソース ディレクトリの構造に一貫性がない場合、

base/path/partition=1/date=2020-12-31/file1.json
// inconsistent because date and partition directories are in different orders
base/path/date=2020-12-31/partition=2/file2.json
// inconsistent because the date directory is missing
base/path/partition=3/file3.json

自動ローダーは、パーティション列を空と見なします。 cloudFiles.partitionColumnsを使用して、ディレクトリ構造の列を明示的に解析します。

ソース フォルダーが空の場合、自動ローダーはどのように動作しますか?

ソース ディレクトリが空の場合、自動ローダーでは、推論を実行するデータがないため、スキーマを指定する必要があります。

自動ローダーがスキーマを推論するタイミング マイクロバッチが実行されるたびに、スキーマは自動的に展開されるのですか?

スキーマは、コードで DataFrame が最初に定義されたときに推論されます。 マイクロバッチのたびに、スキーマの変更は即座に評価されます。そのため、パフォーマンス ヒットについて心配する必要はありません。 ストリームが再起動すると、スキーマの場所から進化したスキーマが取得され、推論によるオーバーヘッドなしで実行が開始されます。

自動ローダー スキーマ推論を使用する場合のデータの取り込みにおけるパフォーマンスへの影響は何ですか?

スキーマの最初の推論中に、非常に大きなソース ディレクトリに対してスキーマ推論に数分かかることが予想されます。 ストリームの実行中に通常、大きなパフォーマンス低下を経験することはないはずです。 Azure Databricks ノートブックでコードを実行すると、自動ローダーがサンプリングとデータ スキーマの推論のためにディレクトリを一覧表示するタイミングを指定する状態の更新を確認できます。

バグが原因で、不適切なファイルがスキーマを大幅に変更しました。 スキーマの変更をロールバックするには、どうすればよいですか?

Databricks サポートにお問い合わせください。

ストリームの再起動時にチェックポイントの場所を変更すると、どうなりますか?

チェックポイントの場所は、ストリームの重要な識別情報を保持します。 チェックポイントの場所を変更することは、実質的には、前のストリームを破棄して、新しいストリームを開始することを意味します。

事前にイベント通知サービスを作成する必要がありますか?

いいえ。 ファイル通知モードを選択し、必要なアクセス許可を提供する場合、自動ローダーでファイル通知サービスを作成できます。 各自動ローダー ストリームのファイル通知キューを個別に管理する (クラシック) を参照してください。

Unity カタログの外部の場所でファイル イベントが有効になっている場合、ファイル イベント サービスはクラウド プロバイダーでファイル イベントを作成できます。また、ストリームごとに自動ローダーを作成するように構成する必要はありません。 ファイル イベントでのファイル通知モードの使用を参照してください

同じバケット/コンテナー上の異なる入力ディレクトリから複数のストリーミング クエリを実行できますか?

はい。それらが親子ディレクトリ (prod-logs/ など) でない限り可能です。prod-logs/usage/ は、/usage が /prod-logs の子ディレクトリであるため、機能しません。

バケットまたはコンテナーに既存のファイル通知があるときに、この機能を使用できますか?

はい。入力ディレクトリが既存の通知プレフィックス (上記の親子ディレクトリなど) と競合しない限り可能です。

自動ローダーと他のアプリケーションの間で SQS キューを共有できますか?

Databricks では、自動ローダーと他のアプリケーション間で SQS キューを共有することはお勧めしません。 代わりに、S3 イベント通知を SNS トピックに転送し、アプリケーションごとに個別の SQS キューをそのトピックにサブスクライブします。 SNS サブスクリプション・フィルター・ポリシーを使用して、関連するメッセージのみが各キューに確実に転送されるようにします。 次に、自動ローダーに専用キューを指定します。

ファイル イベントが正しく設定されていることを確認するにはどうすればよいですか?

[外部の場所] ページの [ 接続のテスト ] ボタンをクリックします。 ファイル イベントを正しく設定すると、[ファイル イベントの読み取り ] 項目に緑色のチェックマークが表示されます。 外部の場所を作成し、 Automatic モードでファイル イベントを有効にした場合、Azure Databricks が外部の場所の通知を設定している間、テストに Skipped が表示されます。 数分待ってから、[ 接続のテスト ] をもう一度クリックします。 Azure Databricks に、ファイル イベントを設定したりファイル イベントから読み取ったりするために必要なアクセス許可がない場合は、File Events Read 項目にエラーが表示されます。

初回実行時に完全なディレクトリ一覧を回避できますか?

いいえ。 includeExistingFilesが false に設定されている場合でも、自動ローダーは、ストリームの開始後に作成されたファイルを検出し、ファイル イベント キャッシュで最新の状態を取得するディレクトリ一覧を実行します (キャッシュ内の有効な読み取り位置をセキュリティで保護し、ストリームのチェックポイントに格納します)。

ファイルが見つからないのを防ぐために cloudFiles.backfillInterval を設定する必要がありますか?

いいえ。 Azure Databricks では、クラウド ストレージ通知システムによってファイルが見落とされたり、到着が遅れたりする可能性があるため、クラシック ファイル通知モードでこの設定を推奨していました。 これで、Azure Databricks は外部の場所で完全なディレクトリ一覧を実行します。 最初の完全なディレクトリ一覧は、外部の場所でファイル イベントが有効になるとすぐに開始されます。 ファイル イベントを使用してデータを取り込む自動ローダー ストリームが少なくとも 1 つある限り、最後のフル スキャンの 24 時間後に、後続の各一覧が発生します。

指定されたストレージ キューを使用してファイル イベントを設定しましたが、キューが正しく構成されておらず、ファイルが見つかりませんでした。 自動ローダーが、キューの構成が誤っていたために処理されなかったファイルを取り込むようにするにはどうすればよいですか?

まず、指定されたキューの構成ミスが修正されていることを確認します。 確認するには、外部の場所ページの [ テスト接続 ] ボタンをクリックします。 ファイル イベントを正しく設定すると、[ファイル イベントの読み取り ] 項目に緑色のチェックマークが表示されます。

Azure Databricks は、ファイル イベントが有効になっている外部の場所の完全なディレクトリ一覧を実行します。 このディレクトリ一覧では、構成ミスの期間中に見落とされたファイルが検出され、ファイル イベント キャッシュに格納されます。

構成ミスが修正され、Azure Databricks がディレクトリの一覧を完了すると、自動ローダーは引き続きファイル イベント キャッシュから読み取りを行い、誤った構成期間中に見落とされたすべてのファイルを自動的に取り込みます。

CF_MANAGED_FILE_EVENTS_INVALID_CONTINUATION_TOKEN エラーから回復するにはどうすればよいですか?

このエラーは、ファイル イベント サービスの自動ローダー チェックポイントに格納されている継続トークンが無効になった場合に発生します。

一般的な原因を次に示します。

  • cloudFiles.useManagedFileEvents がオフになってから、もう一度オンになりました。
  • ソースの外部の場所またはボリュームの変更。
  • 指定されたキューの変更。

回復するには:

  1. ストリーミング クエリに .option("cloudFiles.listOnStart", "true") と .option("cloudFiles.validateOptions", false) を設定します。
  2. ストリームを再起動します。 自動ローダーは、起動時に完全なディレクトリ 一覧を実行し、無効な継続トークンをバイパスします。
  3. マイクロバッチが正常に完了したら、両方のオプションを削除し、ストリームを再起動します。

cloudFiles.listOnStart オプションの詳細については、「ファイル通知」を参照してください。

自動ローダーによって作成されたイベント通知リソースをクリーンアップするにはどうすればよいですか?

クラウド リソース マネージャーを使用して、リソースの一覧表示と破棄を行うことができます。 これらのリソースは、クラウド プロバイダーの UI または API を使用して手動で削除することもできます。

  • Last updated on