更新日：2024年6月14日
寄稿者： Cole Stryker
データ・パイプラインは、さまざまなデータ・ソースから未加工データを取り込み、変換してから、データレイクやデータウェアハウスなどのデータ・ストアに移植して分析する方法です。
データがデータ・リポジトリーに流入する前に、通常は何らかのデータ処理が行われます。これには、フィルタリング、マスキング、集計などのデータ変換が含まれており、適切なデータ統合と標準化が保証されます。これは、データセットの保存先がリレーショナル データベースである場合に特に重要です。このタイプのデータ・リポジトリーには、既存のデータを新しいデータで更新するための調整（つまり、データ列とタイプを一致させる）を必要とする定義済みのスキーマがあります。
その名が示すように、データ・パイプラインは、データサイエンス・プロジェクトまたはビジネス・インテリジェンス・ダッシュボードの「パイピング」として機能します。データは、API、SQL およびNoSQLデータベース、ファイルなど、さまざまな場所から取得できますが、残念ながら、そのデータは通常、そのまま使用できる状態ではありません。ソーシング中に、データ系統が追跡され、さまざまなビジネスおよびITアプリケーション内のエンタープライズ・データ間の関係が文書化されます。例えば、データが現在どこにあり、オンプレミス、データレイク、データウェアハウスなどの環境でどのように保存されているかなどが文書化されます。
データ準備作業は通常、データサイエンティストまたはデータエンジニアが担当します。データサイエンティストやデータエンジニアは、ビジネス・ユースケースのニーズに合わせてデータを構造化させ、膨大な量のデータを処理します。データパイプラインに必要なデータ処理の種類は、通常、探索的なデータ分析と定義されたビジネス要件を組み合わせて決定されます。データを適切にフィルタリング、結合、要約したら、保存して表示して使用することができます。よく整理されたデータパイプラインは、探索的データ分析、データ視覚化、機械学習タスクなど、さまざまなデータプロジェクトの基盤となります。
あらゆるデータをどこでもAIワークロードに拡張できます
データパイプラインには主にいくつかのタイプがあり、それぞれが特定のプラットフォームでの特定のタスクに適しています。
バッチ処理の開発は、信頼性と拡張性のあるデータ・インフラストラクチャーを構築する上で重要なステップでした。2004年、バッチ処理アルゴリズムである MapReduceが特許を取得し、その後、 Hadoop、CouchDB、MongoDBなどのオープンソース・システムに統合されました。
その名が示すように、バッチ処理は、設定された時間間隔でデータの「バッチ」をリポジトリーにロードします。通常、オフピークの営業時間内にスケジュールされます。こうすることで、バッチ処理ジョブは大量のデータを扱う傾向があり、システム全体に負担をかける可能性があるため、他のワークロードは影響を受けません。バッチ処理は通常、特定のデータセット（月次会計など）をすぐに分析する必要がない場合に、最適なデータ・パイプラインであり、「抽出、変換、ロード」を表すETLデータ統合プロセスとより関連しています。
バッチ処理ジョブは、連続したコマンドのワークフローを形成し、1つのコマンドの出力が次のコマンドの入力になります。例えば、1つのコマンドでデータの取り込みを開始し、次のコマンドで特定の列のフィルタリングをトリガーし、後続のコマンドで集計を処理するといったことが考えられます。この一連のコマンドは、データ品質が完全に変換され、データ・リポジトリーに書き換えられるまで継続されます。
バッチ処理とは異なり、ストリーミング・データ・パイプライン（イベント駆動型アーキテクチャーとも呼ばれます）は、センサーやアプリケーション内のユーザー操作など、さまざまなソースによって生成されたイベントを継続的に処理します。イベントは処理および分析され、データベースに保存されるか、さらなる分析のために下流に送信されます。
ストリーミング・データは、データを継続的に更新する必要がある場合に利用されます。例えば、アプリやPOSシステムでは、製品の在庫や販売履歴を更新するためにリアルタイムデータが必要です。そうすれば、売り手は商品の在庫があるかどうかを消費者に知らせることができます。商品の販売などの1つのアクションは「イベント」とみなされ、チェックアウトへのアイテムの追加などの関連イベントは、通常、「トピック」または「ストリーム」としてグループ化されます。これらのイベントは、オープンソースのApache Kafkaなどのメッセージング・システムまたはメッセージ・ブローカーを介して転送されます。
データ・イベントは発生後すぐに処理されるため、ストリーミング処理システムはバッチ・システムよりも待機時間が短くなりますが、メッセージが意図せずにドロップされたり、キューに長い時間を費やしたりする可能性があるため、バッチ処理システムほど信頼性が高いとはみなされません。メッセージ・ブローカーは、確認応答を通じてこの問題に対処するのに役立ちます。確認応答では、コンシューマーがブローカーに対してメッセージの処理を確認し、メッセージをキューから削除します。
データ統合パイプラインは、複数のソースからのデータを単一の統合ビューに統合することに重点を置いています。これらのパイプラインには、多くの場合、未加工データをデータウェアハウスやデータレイクなどの集中リポジトリに保管する前に、未加工データをクリーンアップ、強化、またはその他の方法で変更する抽出、変換、ロード（ETL）プロセスが含まれます。データ統合パイプラインは、互換性のない形式や構造を生成する異種のシステムを処理するために不可欠です。例えば、Amazon S3（Amazon Simpleストレージ・サービス）に接続を追加できます。これは、Webサービスのインターフェースを通じてObject Storageを提供する、Amazon Web Services（AWS）が提供するサービスです。
最新のデータ・プラットフォームには、組織のデータの収集、クレンジング、変換、分析を行いより良い意思決定ができるよう促す、クラウドファーストのクラウドネイティブ・ソフトウェア製品スイートが含まれています。今日のデータ・パイプラインはますます複雑化していると同時に、データの分析やデータ主導の意思決定を行う上でもより一層重要になっています。最新のデータ・プラットフォームは、正確かつタイムリーな情報の確保、データ・サイロの削減、セルフサービスの有効化、そしてデータ品質の向上を実現させる方法によるデータの取り込み、保管、処理、変換を行うことで、組織が保有するデータに対する信頼性を構築します。
データ・パイプラインのアーキテクチャーは、3つの主要ステップで構成されます。
1. データ取り込み：データは、SaaS（ソフトウェア・アズ・ア・サービス）プラットフォーム、モノのインターネット（IoT）デバイス、モバイル・デバイスなどのさまざまなソース、および構造化データと非構造化データの両方のさまざまなデータ構造から収集されます。ストリーミング・データ内では、これらの未加工データのデータ・ソースは通常、プロデューサー、パブリッシャー、または送信者と呼ばれます。企業は、処理する準備ができたときにのみデータを抽出することもできますが、最初に未加工データをクラウド・データウェアハウス・プロバイダーに格納することがベスト・プラクティスです。このようにして、企業はデータ処理ジョブを調整する必要がある場合に、履歴データを更新できます。このデータ取り込みプロセス中に、データの一貫性と正確性を確保するためにさまざまな検証とチェックを実行できます。
2. データ変換：このステップでは、一連のジョブが実行され、移行先のデータ・リポジトリーで必要な形式にデータを処理します。これらのジョブには、ビジネス・レポートなどの反復的なワークストリームの自動化とガバナンスが組み込まれており、データが一貫してクレンジングされ、変換されることが保証されます。例えば、データ・ストリームはネストされたJSON形式で提供される場合、データ変換ステージではそのJSONをデプロイして分析用の主要フィールドを抽出することが目的となります。
3. データ・ストレージ：変換されたデータはデータ・リポジトリー内に保管され、さまざまな関係者に公開される可能性があります。ストリーミング・データ内では、この変換されたデータは通常、コンシューマー、サブスクライバー、または受信者と呼ばれます。
データ・パイプラインやETLパイプラインなどの一部の用語は、同じ意味で使用される場合があります。ただし、ETLパイプラインはデータ・パイプラインのサブカテゴリーとして考える必要があります。2種類のパイプラインは、次の3つの主要機能によって区別されます。
- ETLパイプラインは特定のシーケンスに従います。略語が示すように、データを抽出し、データを変換し、データリポジトリにデータをロードして保管します。すべてのデータ・パイプラインがこの順序に従う必要はありません。実際、複数のソースとプラットフォームにわたってデータを生成して保存できるクラウドネイティブ・ツールの登場により、ELT（抽出、ロード、変換）パイプラインの人気が高まっています。このタイプのパイプラインでは、データの取り込みは最初に行われ、データがクラウドベースのデータ・ウェアハウスにロードされた後に変換されます。
- ETLパイプラインもバッチ処理の使用を意味する傾向がありますが、前述のように、データ・パイプラインの範囲はより広範囲で、ストリーム処理を含めることもできます。
- 最後に、可能性は低いですが、ETL パイプラインのように、データ・パイプライン全体で必ずしもデータ変換を行う必要はありません。データ分析を容易にするために変換を利用していないデータ・パイプラインを見ることはほとんどありません。
ビッグデータが増加するにつれて、データ管理の重要度はますます高まります。データ・パイプラインはさまざまな機能を果たす一方で、ビジネス・アプリケーション向けの機能は次のとおりです。
- 探索的データ分析：データ・サイエンティストは探索的データ分析（EDA）を使用してデータ・セットを分析および調査し、その主な特性を要約します。多くの場合、データの可視化手法が使用されます。これは、必要な答えを得るためにデータ・ソースを操作する最適な方法を決定する際に役立つため、データサイエンティストはパターンの発見、異常の特定、仮説の検証、仮定の確認を容易に行うことができます。
- データの可視化：一般的なグラフィックVIAデータを表現するために、チャート、プロット、インフォグラフィック、さらにはアニメーションなどのデータの可視化を実現できます。これらの視覚的な情報表示により、複雑なデータ関係とデータ駆動型の洞察がわかりやすい方法で伝えられます。
- 機械学習：人工知能（AI）とコンピューター・サイエンスの一分野である 機械学習は、データとアルゴリズムを使用して人間の学習方法を模倣し、その精度を徐々に向上させることに重点を置いています。統計的手法を使用することで、アルゴリズムは分類や予測を行うようにトレーニングされ、データ・マイニング・プロジェクト内で重要な洞察が明らかになります。
- データ・オブザーバビリティー：使用されているデータの正確性と安全性を検証するために、データ・オブザーバビリティーは、予想されるイベントと異常の両方を監視、追跡、およびアラートするためのさまざまなツールを適用します。
IBM® DataStage は、業界最高レベルのデータ統合ツールで、データを移動および変換するジョブの設計、開発、実行を支援します。
IBM Data Replicationは、複数のデータ・ストアをほぼリアルタイムで同期させるデータ同期ソフトウェアです。IBM Data Replicationは、影響を抑えながらログによって取り込まれたデータ変更のみを追跡するソリューションです。
IBM® Databandは、メタデータを自動的に収集して履歴ベースラインを構築し、異常を検知し、アラートをトリアージし、 Apache Airflow有向非巡回グラフ（DAG）の健全性と信頼性を監視する、データ・パイプラインおよびウェアハウス向けのオブザーバビリティー用ソフトウェアです。
IBM® watsonx.dataは、オープンデータ・レイクハウス・アーキテクチャー上に構築された、目的に適したデータ・ストアで、あらゆる場所に保管されているあらゆるデータに対して、分析とAI作業を行うことができます。
アクセス、ガバナンス、プライバシーとコンプライアンスの3つの主要なデータ管理領域に焦点を当てて、AI 用の堅牢なデータ基盤を作成する方法については、スマートペーパーをお読みください。
State Bank of India社がいくつかのIBMソリューションとIBM Garage方法論を使用して包括的なオンライン・バンキング・プラットフォームをどのように開発したかを学びましょう。