データパイプラインアーキテクチャとは？

データパイプラインアーキテクチャとは、データがソースシステムから収集、処理、保存され、それを利用する人々、アプリケーション、モデルに配信されるまでのエンドツーエンドの設計のことです。「アーキテクチャ」という言葉は、パイプラインそのものではなく、設計図を指します。これには、データがどのように流れ、どこで変換され、どのツールが各ステップを処理するかについての選択が含まれます。

優れたアーキテクチャとは、既製品をそのまま選ぶのではなく、ユースケースに合わせて構築されるものです。リアルタイムの不正検知用に構築されたデータパイプラインは、どちらもデータをソースから送信先に移動するものであるにもかかわらず、毎晩の売上レポートを作成するものとは大きく異なります。この用語集ページでは、すべてのパイプラインに共通するコアレイヤー、一般的なステージモデル、主要なアーキテクチャパターン、そしてパイプラインのスケールに合わせて信頼性を維持するためのベストプラクティスについて解説します。

データパイプラインアーキテクチャはどのように機能するのか？

データパイプラインは一連のステージを通じてデータを移動させ、各ステージにはデータの収集、クリーンアップ、保存、利用可能な状態への変換といった特定の役割があります。アーキテクチャとは、これらのステージがどのように接続されるかの計画です。各ステップでデータに何が、どのような順序で、どのようなルールの下で起こるかを定義します。

アーキテクチャの決定には2つのレベルがあります。論理設計は、どのようなステージが存在し、それぞれが何を行うかを定義します。これが「何を（what）」にあたります。物理設計は、どの具体的なツールやインフラストラクチャが各ステージを実行するかを定義します。これが「どのように（how）」にあたります。オーケストレーション（各ステップの自動スケジューリングと調整）とモニタリングは、特定のステージだけに属するものではありません。パイプライン全体にわたって実行されます。最新のプラットフォームは、これまでの境界線も取り払いました。Databricksは、Lakeflowによってバッチパイプラインとストリーミングパイプラインを単一の基盤上に統合しているため、チームは2つの並行システムを構築して維持する必要がありません。

データパイプラインのコアレイヤー

チームがどのパターンを選択するかにかかわらず、すべてのデータパイプラインは同じ4つのレイヤーで構築されています。各レイヤーは、データがどのように取り込まれるか、どのように有用になるか、どこに保存されるか、誰がそれを利用するかという、データに関する異なる疑問に答えます。

インジェスチョン（データ取り込み）

インジェスチョンは、データベース、アプリケーション、API、クラウドストレージ内のファイル、イベントストリーム、センサーなどのソースシステムからパイプラインにデータを取り込みます。データインジェスチョンには2つのタイプがあります。バッチインジェスチョンは、1時間ごとや毎晩など、スケジュールに従ってデータを取り込みます。ストリーミングインジェスチョンは、イベントの発生に合わせて継続的にデータをキャプチャします。多くのパイプラインでは、ソースデータベースの行レベルの変更を追跡する手法であるCDC（Change Data Capture）も使用されており、すべてを再ロードする代わりに、新規または更新されたデータのみを移動します。

処理と変換

このレイヤーでは、生データがクリーンアップ、整形、エンリッチ（強化）され、利用できるように準備されます。一般的な作業には、欠損値の修正、フォーマットの標準化、データセットの結合、ビジネスロジックの適用などがあり、これらはETLの中核となるタスクと同じです。処理もインジェスチョンと同様に分かれています。バッチ処理は大量のデータをまとめて処理するのに対し、ストリーム処理はレコードが到着するたびに1つずつ、または極めて小さなマイクロバッチで処理します。

ストレージ

ストレージは、処理されたデータが格納される場所であり、クエリ、分析、またはモデルへの供給が行われます。送信先は通常、データレイク、データウェアハウス、またはその両方の強みを組み合わせた単一のシステムであるレイクハウスです。場所と同じくらいフォーマットも重要です。オープンフォーマットであるLakehouse StorageやApache Icebergを使用すると、システム間でデータをコピーすることなく、複数のツールが同じデータを読み取ることができます。Delta Lakeは、ACIDトランザクション（書き込みが完全に成功するか完全に失敗するかのいずれかを保証し、破損を防ぐ機能）やタイムトラベル（テーブルの古いバージョンをクエリする機能）などの信頼性機能も追加します。

サービングと利用

最後のレイヤーは、準備されたデータを必要とする人々やシステム（SQLクエリを実行するアナリスト、ダッシュボードを使用するビジネスユーザー、モデルをトレーニングするデータサイエンティスト、APIを呼び出すアプリケーションなど）に配信します。送信先はBIツールからMLプラットフォーム、業務システムまで多岐にわたり、多くの場合、分析ワークロードの中心にデータウェアハウスが位置します。4つのレイヤーすべてにおいて、オーケストレーションとオブザーバビリティが、ジョブのスケジューリング、データ品質の追跡、問題発生時のアラート発生など、連携作業を担います。

データパイプラインにはいくつかのステージがあるのか？（3 vs. 4 vs. 5）

データパイプラインには3つ、4つ、または5つのステージがあると説明するリソースがあり、混乱を招くことがよくあります。実際はもっとシンプルです。3つのモデルはすべて、異なる詳細レベルで同じ基本的な作業を説明しています。

ステージの数はラベルの付け方の違いにすぎません。パイプラインが実行する作業は同じです。

一般的なデータパイプラインアーキテクチャのパターン

アーキテクチャパターンとは、チームがパイプラインを構築する際に選択する、確立された設計のことです。適切なパターンは、レイテンシーの要件、データ量、およびデータがダウンストリームでどのように使用されるかによって異なります。

バッチアーキテクチャ

バッチアーキテクチャは、1時間ごと、毎晩、毎週など、スケジュールされたチャンク（塊）でデータを処理します。これは、レポート作成、履歴分析、MLのトレーニングデータ、および数分から数時間の遅延が許容されるユースケースに適しています。バッチパイプラインは、ストリーミングパイプラインに比べて構築がシンプルで、実行コストが低く、デバッグも容易です。トレードオフはデータの新しさ（フレッシュネス）です。数秒前に発生した出来事に基づいて意思決定を行う必要がある場合、バッチ処理では対応できません。

ストリーミングアーキテクチャ

ストリーミングアーキテクチャは、データが生成されるたびに、レコード単位で継続的に処理します。不正検知、リアルタイムのパーソナライズ、IoTモニタリングなど、1分未満の応答が重要となるユースケースに対応します。トレードオフはコストです。ストリーミングパイプラインは、常時稼働のインフラストラクチャを必要とするため、通常、バッチパイプラインよりも実行および運用コストが高くなります。

Lambdaアーキテクチャ

Lambdaアーキテクチャは、2つの並行するパスを実行します。バッチパスが正確な履歴データを提供し、ストリーミングパスが高速で最新のデータを提供し、サービングレイヤーがその結果をマージします。この設計は機能しますが、よく知られたデメリットがあります。2つのパイプラインを維持することは、コードやロジックの重複、および運用負荷の倍増を意味します。

Kappaアーキテクチャ

Kappaアーキテクチャは、すべてに単一のストリーミングパイプラインを使用することで、Lambdaを簡素化します。履歴分析が必要な場合は、ストリームが最初から再再生（リプレイ）されます。Kappaは、2つの並行システムを維持するコストをかけずに、ストリーミングレベルのデータの新しさを求めるチームに適しています。

メダリオンアーキテクチャ（レイクハウスパターン）

メダリオンアーキテクチャは、データをブロンズ（取り込まれたままの生データ）、シルバー（クリーンアップおよび適合済み）、ゴールド（精選されたビジネス対応データ）の3つの品質層に整理する、レイクハウスプラットフォームで一般的なパターンです。Databricksのドキュメントにあるように、「メダリオンアーキテクチャは、ブロンズ、シルバー、ゴールドの3つのレイヤーを使用し、それぞれがパイプラインにおいて明確な目的を果たします」。各層は独自のパイプラインとして実行できるため、スケジューリング、モニタリング、トラブルシューティングが容易になり、問題が単一のレイヤーに分離された状態に保たれます。

ETL vs. ELT：変換の順序がアーキテクチャをどのように形成するか

ETLとELTは、データがいつ変換されるかが異なります。ETL（抽出、変換、ロード）は、データをストレージにロードする前に変換します。ELT（抽出、ロード、変換）は、最初に生データをロードし、送信先の中で変換します。Databricks、Snowflake、BigQueryなどの最新のクラウドプラットフォームでは、クラウドストレージとコンピューティングが十分に安価で弾力性があり、その場でデータを変換できるようになったため、ELTが主流のパターンとなっています。詳細な比較については、ETL vs. ELTをご覧ください。

ETLはデータパイプラインと同じですか？

いいえ。ETLはデータパイプラインの一種ですが、すべてのデータパイプラインがETLであるわけではありません。データパイプラインは、データをある場所から別の場所に移動するすべてのシステムを指す、より広いカテゴリです。ETLはそのカテゴリにおける特定のアプローチであり、データがストレージに格納される前に変換を行うことが特徴です。パイプラインには、ELT、ストリーミング、レプリケーションのみ（変換をまったく行わずにデータを移動する）、またはリバースETL（ウェアハウスのデータをオペレーショナルシステムに送り返す）などもあります。

データパイプラインアーキテクチャのベストプラクティス

これら10個の設計原則により、拡張可能なパイプラインと、途中で破綻してしまうパイプラインを分けることができます。

1. 取り込みと変換を分離する。生データの格納とデータのクリーニングを異なるステージに分けることで、一方の問題が他方に連鎖しないようにします。
2. べき等性を考慮して設計する。重複レコードを作成したり結果を破損したりすることなく、安全に再実行できるパイプラインにする必要があります。これは、障害対応やバックフィルにおいて極めて重要です。
3. データ品質チェックを組み込む。強力なデータ品質チェックにより、各ステージでスキーマ、値の範囲、null数、鮮度を検証します。また、不具合がある場合は、不正なデータを下流に流すのではなく、明確にエラーを発生させます。
4. スキーマドリフトを想定する。ソースシステムは変化します。パイプラインは、列の追加、削除、または名前変更を検出し、処理を中断するのではなく、その変更を適切に処理できるようにする必要があります。
5. オープンストレージフォーマットを使用する。Delta LakeやApache Icebergのようなフォーマットは、ベンダーロックインを防ぎ、複数のツールがコピーを作成することなく同じデータを読み取れるようにします。
6. パイプラインレイヤーを切り離す。メダリオン層（Bronze、Silver、Gold）を個別のパイプラインに分割することで、それぞれのスケジュール設定、監視、トラブルシューティングを独立して行いやすくなります。
7. すべてをバージョン管理する。パイプラインのコードと設定をGitに保存することで、変更のレビュー、追跡、およびロールバックを可能にします。
8. ガバナンスを最優先事項として扱う。最後に急いで追加するのではなく、Unity Catalogのようなツールを使用して、すべてのステージで一貫した権限、リネージ追跡、監査コントロールを適用します。
9. ストリーミングとバッチを適切に使い分ける。ストリーミングはデータの鮮度が本当に重要な場合にのみ使用し、それ以外はコストを抑えるためにデフォルトでバッチを使用します。
10. エンドツーエンドで監視する。データの鮮度、量、品質、およびパイプラインの実行時間を追跡し、下流のユーザーが気づく前に問題を特定できるようにします。

なぜデータパイプラインアーキテクチャが重要なのか

パイプラインアーキテクチャは、チームがデータを信頼できるか、意思決定が最新の情報に基づいているか、そしてAIやMLのプロジェクトがプロトタイプから本番環境に移行できるかを左右します。それは、価値を複利的に高めていくデータプラットフォームと、サポートチケットを量産するだけのプラットフォームとの違いです。

脆弱なアーキテクチャは、ダッシュボードの陳腐化、指標の不一致、MLデプロイの失敗、そして構築よりもトラブル対応に追われるエンジニアなど、実質的なコストを生み出します。モダンなレイクハウスアプローチは、この根本原因に対処します。バッチとストリーミング、アナリティクスとAI、そしてガバナンスをDatabricksプラットフォームのような単一のプラットフォームに統合することで、従来のアーキテクチャを破綻させていたシステム間の脆弱なデータの受け渡しを排除できます。

Databricksにおけるデータパイプラインアーキテクチャ

Databricksは、パイプラインアーキテクチャのすべてのレイヤーを単一のプラットフォームで提供します。Lakeflow Connectは、データベース、SaaSアプリケーション、ファイルソース、イベントストリームからの取り込みを処理します。Lakeflow Spark Declarative Pipelinesは、データ品質チェックが組み込まれたバッチおよびストリーミングのETLパイプラインを構築し、Lakeflow Jobsがプラットフォーム全体でパイプライン実行のオーケストレーションとスケジュール設定を行います。その基盤として、Delta Lakeがオープンストレージフォーマットを提供するとともに、ACIDトランザクションやタイムトラベルなどの信頼性機能を提供し、Unity Catalogがすべてのステージでガバナンス、リネージ、アクセス制御を適用します。

バッチパイプラインとストリーミングパイプラインは同じエンジンで動作し、同じストレージに書き込むため、Lambdaスタイルの並列システムを維持する必要はありません。1つのパイプライン定義で、夜間レポートとリアルタイムダッシュボードの両方に対応できます。

よくある質問

データパイプラインアーキテクチャとは、簡単に言うと何ですか？

それは、データが作成された場所から、役立つ場所へと届くまでの計画です。この計画には、データの収集方法、クリーニングと準備の方法、保存場所、およびそれを必要とする人々やアプリケーションへの配信方法が含まれます。

LambdaアーキテクチャとKappaアーキテクチャの違いは何ですか？

Lambdaは、バッチとストリーミングの2つの並列パイプラインを実行し、それらの結果をサービングレイヤーでマージします。Kappaは、すべてに単一のストリーミングパイプラインを使用し、履歴分析が必要な場合はストリームを再再生（リプレイ）します。Kappaは運用がよりシンプルですが、Lambdaはバッチパスとストリーミングパスが個別に進化した環境で根強く使われています。

バッチパイプラインとストリーミングパイプラインはどのように使い分けるべきですか？

不正検知、ライブパーソナライズ、機器監視などのように、データの価値が数秒から数分で低下する場合は、ストリーミングを使用します。レポート作成、履歴分析、MLトレーニングデータなど、それ以外はすべてバッチを使用します。バッチはよりシンプルでコストも低いため、リアルタイムデータが必要であることがユースケースで証明されるまでは、賢明なデフォルトの選択肢となります。

論理パイプラインアーキテクチャと物理パイプラインアーキテクチャの違いは何ですか？

論理アーキテクチャは、ツールに依存せず、パイプラインのステージとそれぞれの役割を定義します。物理アーキテクチャは、それらのステージを特定のテクノロジーやインフラストラクチャにマッピングします。通常、チームは最初に論理設計を決定し、次にそれを実装するプラットフォームを選択します。

業務に適したアーキテクチャの選択

データパイプラインアーキテクチャは、データがどのように移動し、役立つようになるかを支える設計です。適切なアーキテクチャとは、夜間の売上レポートであれ、ミリ秒単位で実行される不正チェックであれ、目の前の特定の業務に対して鮮度、コスト、信頼性のバランスが取れているものです。

Databricksがバッチとストリーミングのパイプライン、ストレージ、ガバナンスを単一のプラットフォームにどのように統合しているかをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事