インジェストロジックとデータソースの構成を設計する

10 分

インジェストロジックを設計するには、ソースシステムから Azure Databricks へのデータの移動方法に関する重要な決定を行う必要があります。これらの決定は、データの鮮度、処理効率、およびシステムの信頼性に影響します。ツールを選択したりコードを記述したりする前に、データソースの特性を理解し、ビジネス要件に合った抽出戦略を定義する必要があります。

このユニットでは、Azure Databricks でのデータインジェストロジックとデータソース構成に関する主要な設計上の考慮事項について説明します。ここでは、概念ロジックと設計パターンに焦点を当てています。具体的なツールの選択と実装の詳細については、後のユニットで説明します。

抽出の種類を理解する

抽出の種類 は、ソースシステムからデータをキャプチャする方法を決定し、データパイプラインの タイムライン と効率の両方に影響します。 Azure Databricks では、それぞれ異なるシナリオに適した 3 つの主要な抽出パターンがサポートされています。

完全抽出

完全抽出 では、各インジェストの実行中にソースシステムからデータセット全体が読み取られます。

この方法は、次の場合に適しています。

ソースシステムは変更の追跡をサポートしていません
データボリュームは、効率的に再処理するのに十分なサイズです
コピー先テーブルを定期的に最初から再構築する必要がある
データリレーションシップは複雑であり、増分ロジックはエラーが発生しやすい

データ量が増えると、完全な抽出は実用的ではありません。数千件しか変更されていない場合に何百万ものレコードを再処理すると、コンピューティングリソースが無駄になり、ダウンストリームコンシューマーが遅延します。

増分抽出

増分抽出 では、前回のインジェスト実行以降に新しいレコードまたは変更されたレコードのみが処理されます。エンジンは、処理されたデータを追跡し、更新プログラムに対してのみクエリを実行します。

このパターンでは、次のものが必要です。

ソースデータの信頼できる 変更インジケーター (タイムスタンプ、シーケンス番号、またはバージョン列)
最後に処理された位置を追跡するための状態管理
到着が遅れたレコードまたは順序が外れたレコードを処理するロジック

増分抽出により、大規模なデータセットの効率が大幅に向上します。数百万行を読み取る代わりに、1 回の実行で数千の変更のみを処理できます。

ストリーミング抽出

ストリーミング抽出 では、連続処理による ほぼリアルタイムの データキャプチャが提供されます。ストリーミングジョブは、スケジュールに従って実行されるのではなく、アクティブなままであり、レコードが到着しても処理されます。

次の場合は、ストリーミングを検討してください。

ビジネスプロセスでは、秒単位または分単位で測定されたデータの鮮度が必要です
ソースシステムは、メッセージバスや変更フィードにイベントを発行する
発生したイベントに対応する必要がある

ストリーミング抽出には常時接続インフラストラクチャが必要ですが、データの可用性の待機時間は最も短くなります。

変更データキャプチャの設計

変更データキャプチャ (CDC) は、挿入、更新、削除など、個々の行レベルの変更をキャプチャする特殊な抽出パターンです。 CDC は、変更ごとに操作の種類を保持するため、単純な増分抽出とは異なります。

CDC 用に設計する場合は、ソースシステムが変更レコードを生成する方法を検討してください。

データベーストランザクションログ: SQL Server などのデータベースでは、トランザクションログベースの CDC 機能を使用して行レベルの変更を公開できます。 Azure Databricks などのダウンストリームシステムでは、これらの変更を読み取り、インジェストパイプラインの一部として処理できます。
変更データフィード: 差分テーブルと Azure Cosmos DB などの一部のデータベースでは、行の変更をメタデータで表示する組み込みの変更追跡が提供されます。
定期的なスナップショット: 一部のシステムでは継続的 CDC がサポートされていないため、スナップショットを比較して変更を判断する必要があります。

CDC を使用すると、単純な増分抽出ではサポートできないユースケースが可能になります。削除を正確にレプリケートし、監査証跡を維持し、キー列を変更する更新を処理することができます。

注

CDCでは、順序が狂ったイベントを正しく処理するために、シーケンス情報が必要です。ソースデータには、正しい変更順序を確立する列 (タイムスタンプやシーケンス番号など) が必要です。

ソースファイルの種類の特性を特定する

データがトランザクションシステムからではなくファイルとして到着すると、ファイル形式がインジェストの設計に影響します。各形式には、処理に影響を与える個別の特性があります。

テキストベースの形式

CSV ファイルと JSON ファイルは、人間が判読でき、広くサポートされているため、一般的なソース形式です。ただし、効率的な処理には次の課題があります。

スキーマの可変性: ファイルの列の順序、フィールドの欠落、またはデータ型のバリエーションに一貫性がない可能性があります
圧縮効率なし: テキスト形式では、通常、バイナリの代替手段よりも多くのストレージが消費されます
解析オーバーヘッド: すべての値には、読み取り中にテキストから型への変換が必要です

ソースシステムでこれらの形式のみを生成できる場合、または効率の問題が適用されないほどデータボリュームが小さい場合は、テキストベースの形式を使用します。

列形式

Parquet ファイルと ORC ファイルは列形式でデータを格納するため、効率的な分析クエリが可能になります。次の形式が提供されます。

圧縮: Columnar Storage は、類似した値をグループ化することで、より優れた圧縮率を実現します
列の排除: クエリは必要な列のみを読み取り、I/O を減らします
埋め込みスキーマ: ファイルには、列名と型を記述するメタデータが含まれています

アップストリームシステムがデータをエクスポートする方法を制御できる場合に、列形式のソース形式を優先するようにインジェストを設計します。

半構造化形式

XML ファイルと入れ子になった JSON ファイルは、フラットな表形式の構造に適合しない階層データを表します。半構造化データを取り込む場合:

スキーマの抽出または定義を計画します。
構造をフラット化するか、入れ子を保持するかを決定します。
同じソース内のさまざまなドキュメント構造を考慮します。

データソース接続に関する考慮事項

データソース構成では、Azure Databricks がソースシステムに接続して認証する方法を定義します。設計では、接続のセキュリティ、資格情報の管理、およびアクセスパターンに対処する必要があります。

クラウドオブジェクトストレージソース

クラウドストレージ (Azure Data Lake Storage、Amazon S3、または Google Cloud Storage) は、インジェストの最も一般的なランディングゾーンとして機能します。ストレージ接続を構成する場合:

Unity カタログの外部の場所を使用して、ストレージパスへのアクセスを管理します。
適切な認証方法 (マネージド ID、サービスプリンシパル、またはストレージ資格情報) を構成します。
効率的な増分処理をサポートするフォルダー構造を設計します。

フォルダー構造は、Azure Databricks が新しいファイルを識別して処理する効率に大きく影響します。次のパターンについて考えてみましょう。

日付ベースのパーティション分割: 増分読み取りの間にパーティションの排除を有効にするために、日付階層別にファイルを整理します。

/data/sales/year=2025/month=11/day=28/
/data/sales/year=2025/month=11/day=29/

この構造により、クエリはすべてのファイルを一覧表示するのではなく、関連する日付パーティションのみをスキャンできます。

ソースベースの組織: 複数のソースから取り込む場合は、処理ロジックを簡略化するためにソースシステムによってデータを分離します。

/landing/erp/orders/
/landing/crm/customers/
/landing/web/clickstream/

処理状態フォルダー: 別のフォルダーを使用して、ファイル処理の状態を追跡します。

/incoming/     # New files arrive here
/processing/   # Files currently being processed
/archive/      # Successfully processed files
/failed/       # Files that failed processing

フォルダー構造を設計する場合は、次の点を考慮してください。

ファイル検出のオーバーヘッド: 何千ものファイルを含むフラットな構造では、リストの操作が遅くなります。パーティション構造は、Azure Databricks が列挙する必要があるファイルを減らします。
自動ローダーの互換性: Azure Databricks 自動ローダーは 、クラウドストレージ内の新しいファイルを効率的に追跡します。自動ローダーによるファイルの検出とチェックポイントの方法に合わせてフォルダーを構成します。
パーティション列の抽出: Hive スタイルのパーティション分割 (key=value) を使用して、Azure Databricks がファイルの内容を解析せずにパーティション値を列として自動的に抽出できるようにします。

データベースソース

トランザクションデータベースに接続するには、クラウドストレージとは異なる考慮事項が必要です。

Azure Databricks とデータベースサーバー間のネットワーク接続。
(ハードコーディングされた値ではなく シークレットを 使用して) 安全に保存された認証資格情報。
接続プール と クエリプッシュダウン 機能。
抽出中のソースシステムのパフォーマンスへの影響。

ストリーミングソース

メッセージバスとイベントストリーム (Azure Event Hubs やその他の一般的なメッセージングプラットフォームなど) には、次のものが必要です。

ブローカー接続の詳細と認証。
並列処理のためのコンシューマーグループ構成。
消費位置を追跡するためのオフセット管理。
メッセージ形式の検証のためのスキーマレジストリ統合。

SaaS アプリケーションソース

Salesforce、ServiceNow、SAP などのエンタープライズアプリケーションは、固有の特性を持つ API を介してデータを公開します。

抽出スループットを制限する API レート制限。
大規模な結果セットの改ページ戦略。
認証フロー (OAuth、API キー、または証明書ベース)。
使用可能な変更追跡または Webhook 機能。

要件に基づく設計フレームワークを適用する

効果的なインジェスト設計は、抽出の種類またはファイル形式を選択する前に要件を分析することから始まります。次の反復可能なフレームワークを使用して、設計上の決定を導きます。

手順 1: 要件を収集する

技術的な決定を行う前に、次の重要な質問に答えてください。

要件カテゴリ	回答する質問
データの量	ソースに存在するデータの量実行間の変更はどのくらいですか? 増加率は何ですか?
待機時間の要件	ダウンストリームコンシューマー向けのデータの更新はどのくらい必要ですか? 満たすべきサービスレベル契約 (SLA) はありますか?
ソース機能	ソースは、変更の追跡、CDC、または完全抽出のみをサポートしていますか? 生成できるファイル形式は何ですか?
データ品質	ソースデータの信頼性はどのくらいですか? どのような検証またはクレンジングが必要ですか?
ネットワークの制約	ソースと Azure Databricks の間に存在する帯域幅は何ですか? ファイアウォールまたは VPN の要件はありますか?
コストの見込み	さまざまなアプローチのコンピューティング、ストレージ、およびデータ転送のコストは何ですか?

手順 2: 抽出の種類に要件をマップする

要件分析を使用して、適切な抽出パターンを選択します。

要件が示す場合...	次に選択してください
小さなデータボリューム (< 100,000 行)、変更の追跡が利用できない、単純な再構築が可能	完全抽出
大きなデータ量、信頼性の高い変更インジケーター (タイムスタンプ/シーケンス)、時間単位または毎日の鮮度が十分に存在する	増分抽出
リアルタイムまたはほぼリアルタイムでの最新状態が求められ、データを発行するソースがあり、ストリーミングインフラストラクチャが利用可能です。	ストリーミング抽出
削除と操作の種類をキャプチャする必要がある、監査証跡が必要、ソースはトランザクションログキャプチャをサポートする	CDC 抽出

手順 3: ソースファイル形式を選択する

ソース形式を制御する場合、またはランディングゾーン形式を選択する必要がある場合は、ニーズに合わせて形式を一致させます。

あなたのシナリオが関係する場合...	次に優先するのは...
大規模な分析データセット、列形式のクエリ、圧縮が必要	Parquet
多くのシステムとの相互運用性、人間の読みやすさが必要	CSV または JSON
階層型または入れ子になったデータ構造	JSON または XML
スキーマの進化による高頻度ストリーミング	Avro とスキーマレジストリ

手順 4: 設計を検証する

実装する前に、設計が次の問題に対処されていることを確認します。

抽出の種類は待機時間の要件を満たしています。 そうでない場合、ダウンストリームコンシューマーは古いデータを受け取り、不適切なビジネス上の決定や SLA 違反を引き起こす可能性があります。
このアプローチは、予想されるデータの増加に対応するためにスケーリングされます。 そうでない場合、現在動作するパイプラインは、データボリュームの増加に伴って失敗したり、非常に遅くなったりする可能性があります。
ソースシステムの機能は、選択したパターンをサポートします。 そうでない場合は、実行時にパイプラインが失敗するか、複雑さを増すコストのかかる回避策が必要です。
コスト見積もりは予算の制約内にあります。 そうでない場合、ソリューションは技術的には健全ですが、運用環境では経済的に持続できない可能性があります。
パイプラインのデータ品質チェックが計画されています。 そうでない場合は、無効なデータまたは破損したデータがダウンストリームシステムに伝達され、エラーや不適切な分析が発生します。

フレームワークの適用: 実際の例

eコマースプラットフォームでは、注文データを取り込む必要があります。注文は PostgreSQL データベースに格納され、ビジネスには時間単位のレポートが必要です。

手順 1 - 要件を収集する:

ボリューム: 1 日あたり 50,000 件の新規注文、合計 200 万行、年間 15% の増加。
待機時間: レポートに許容される 1 時間の鮮度。
ソース: PostgreSQL はタイムスタンプベースのクエリをサポートしますが、ネイティブ CDC はサポートしません。
品質: ソースデータは入力時に検証されます。最小限のクレンジングが必要です。
ネットワーク: Azure Private Link 経由の直接接続。
コスト: コンピューティング使用量を最小限に抑えます。ストレージコストはセカンダリです。

手順 2 - 抽出の種類にマップする:

信頼性の高いタイムスタンプ列と時間単位の待機時間の要件がある大容量のデータの場合、増分抽出を行います。

なぜ他の人ではないのですか?

完全な抽出: 1 時間あたり約 2,000 件の注文のみが変更された場合に、200 万行を毎時再処理するとコンピューティングが無駄になります。
ストリーミング: 1 時間の待機時間は、常時接続ストリーミングインフラストラクチャのコストを正当化するものではありません。
CDC: PostgreSQL はネイティブトランザクションログ CDC を公開せず、ユースケースでは削除や操作の種類を追跡する必要はありません。

手順 3 - ファイル形式を選択します。

データは、効率的な列ストレージのために Parquet →処理するために Azure Data Lake Storage に格納されます。増分探索のための日付パーティションレイアウト→ /landing/orders/year=2025/month=11/day=28/。

なぜ他の人ではないのですか?

CSV/JSON: ファイルサイズが大きく、圧縮の利点がなく、分析ワークロードのクエリパフォーマンスが低下します。
Avro: スキーマの進化によるストリーミングに適しています。バッチインジェストでは、ストリーミング指向の機能は必要ありません。
XML: 構造化された表形式の順序データの利点を得ることなく、解析の複雑さを追加します。

手順 4 - 設計を検証する:

✓ 時間単位の増分は、1 時間の待機時間の要件を満たします。
✓処理の変更のみが成長に応じて効率的にスケールします。
✓ PostgreSQL order_updated_at 列では、増分クエリが有効になります。
✓ 数千行と数百万行を処理すると、コンピューティングコストが削減されます。

最終的な決定: order_updated_at タイムスタンプ列を使用した増分抽出。時間単位でスケジュールされ、Azure Data Lake Storage の Parquet ファイルとしてデータがランディングされます。

ヒント

設計上の決定事項とその背後にある根拠を文書化します。要件の変更や問題が発生した場合、このドキュメントは、現在のアプローチが選択された理由と、どのようなトレードオフが行われたかを理解するのに役立ちます。主要なパイプラインごとに設計決定レコードを作成することを検討してください。

この要件に基づく基盤に基づいて、インジェスト設計を実装する特定のツールと読み込み方法を評価する準備が整いました。

フィードバック

このページはお役に立ちましたか?

インジェスト ロジックとデータ ソースの構成を設計する