Databricks 自動ローダーについてよく寄せられる質問です。
ファイルにデータが追加されるか上書きされる場合、自動ローダーはファイルを再び処理しますか?
既定の設定 (cloudFiles.allowOverwrites = false) では、ファイルは 1 回だけ処理されます。 ファイルが追加または上書きされると、自動ローダーは処理されるファイルバージョンを保証できません。
自動ローダーが追加または上書きされたときにファイルを再び処理できるようにするには、 cloudFiles.allowOverwrites を true に設定します。 この場合、自動ローダーは、ファイルの最新バージョンを処理することが保証されます。 ただし、自動ローダーでは、どの中間バージョンが処理されているかを保証できません。
ファイル通知モードで cloudFiles.allowOverwrites を有効にする場合は注意が必要です。 ファイル通知モードでは、自動ローダーは、ファイル通知とディレクトリ一覧の両方を使用して新しいファイルを識別できます。 ファイル通知イベント時間とファイル変更時間が異なる場合があるため、自動ローダーは 2 つの異なるタイムスタンプを受信し、ファイルが更新されていない場合でも同じファイルを 2 回取り込むことができます。
cloudFiles.allowOverwrites有効になっている場合は、重複するレコードを自分で処理する必要があります。 自動ローダーは、ファイルが追加または部分的に更新された場合でも、ファイル全体を再処理します。 一般に、Azure Databricks では、自動ローダーを使用して変更できないファイルのみを取り込み、既定の設定 cloudFiles.allowOverwrites = false使用することをお勧めします。 さらに質問がある場合は、Azure Databricks アカウント チームにお問い合わせください。
データ ファイルが継続的ではなく、一定の間隔 (たとえば、1 日に 1 回) で到着する場合でも、このソースを使用する必要がありますか? また、ベネフィットはありますか?
この場合は、 Trigger.AvailableNow (Databricks Runtime 10.4 LTS 以降で使用可能) 構造化ストリーミング ジョブとスケジュールを、予想されるファイル到着時刻の後に実行するように設定できます。 自動ローダーは、頻繁でない更新と頻繁な更新の両方でうまく機能します。 最終的な更新が非常に大きい場合でも、自動ローダーは入力サイズに合わせてスケーリングします。 自動ローダーの効率的なファイル検出手法とスキーマ進化機能により、自動ローダーは増分データ インジェストの推奨される方法になります。
ストリームの再起動時にチェックポイントの場所を変更すると、どうなりますか?
チェックポイントの場所は、ストリームの重要な識別情報を保持します。 チェックポイントの場所を変更することは、実質的には、前のストリームを破棄して、新しいストリームを開始することを意味します。
イベント通知サービスを事前に作成する必要がありますか?
いいえ。 ファイル通知モードを選択し、必要なアクセス許可を提供する場合、自動ローダーでファイル通知サービスを作成できます。 各自動ローダー ストリームのファイル通知キューを個別に管理する (レガシ) を参照してください。
Unity カタログの外部の場所でファイル イベントが有効になっている場合、ファイル イベント サービスはクラウド プロバイダーでファイル イベントを作成できます。また、ストリームごとに自動ローダーを作成するように構成する必要はありません。 ファイル イベントでのファイル通知モードの使用を参照してください
自動ローダーによって作成されたイベント通知リソースをクリーンアップするにはどうすればよいですか?
クラウド リソース マネージャーを使用して、リソースの一覧表示と破棄を行うことができます。 これらのリソースは、クラウド プロバイダーの UI または API を使用して手動で削除することもできます。
同じバケット/コンテナー上の異なる入力ディレクトリから複数のストリーミング クエリを実行できますか?
はい。それらが親子ディレクトリ (prod-logs/ など) でない限り可能です。prod-logs/usage/ は、/usage が /prod-logs の子ディレクトリであるため、機能しません。
バケットまたはコンテナーに既存のファイル通知があるときに、この機能を使用できますか?
はい。入力ディレクトリが既存の通知プレフィックス (上記の親子ディレクトリなど) と競合しない限り可能です。
自動ローダーでスキーマを推論する方法
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を使用して、ディレクトリ構造の列を明示的に解析します。
ソース フォルダーが空の場合、自動ローダーはどのように動作しますか?
ソース ディレクトリが空の場合、自動ローダーでは、推論を実行するデータがないため、スキーマを指定する必要があります。
Autoloader がスキーマを推論するタイミング マイクロバッチが実行されるたびに、スキーマは自動的に展開されるのですか?
スキーマは、コードで DataFrame が最初に定義されたときに推論されます。 マイクロバッチのたびに、スキーマの変更は即座に評価されます。そのため、パフォーマンス ヒットについて心配する必要はありません。 ストリームが再起動すると、スキーマの場所から進化したスキーマが取得され、推論によるオーバーヘッドなしで実行が開始されます。
自動ローダー スキーマ推論を使用する場合のデータの取り込みにおけるパフォーマンスへの影響は何ですか?
スキーマの最初の推論中に、非常に大きなソース ディレクトリに対してスキーマ推論に数分かかることが予想されます。 ストリームの実行中に通常、大きなパフォーマンス低下を経験することはないはずです。 Azure Databricks ノートブックでコードを実行すると、自動ローダーがサンプリングとデータ スキーマの推論のためにディレクトリを一覧表示するタイミングを指定する状態の更新を確認できます。
バグが原因で、不適切なファイルがスキーマを大幅に変更しました。 スキーマの変更をロールバックするには、どうすればよいですか?
Databricks サポートにお問い合わせください。