データ・パイプラインとは

データがデータ・レポジトリーに取り込まれる前には、通常、何らかのデータ処理が行われます。これには、フィルタリング、マスキング、集計といったデータ変換処理が含まれており、適切なデータ統合と標準化を実現します。データセットの格納先がリレーショナル・データベースである場合、こうした処理が特に重要となります。この種のデータ・レポジトリーにはあらかじめ定義されたスキーマが存在しており、新しいデータで既存データを更新する際には、列やデータ型を一致させるといった整合性の確保が求められます。

その名が示すように、データ・パイプラインは、データサイエンス・プロジェクトまたはビジネス・インテリジェンス・ダッシュボードの「配管」として機能します。データは、API、SQLおよびNoSQLデータベース、ファイルなど、さまざまな場所から取得できますが、残念ながら、そのデータは通常、すぐに使用できる状態ではありません。ソーシング中に、データ・リネージュが追跡され、さまざまなビジネスおよびITアプリケーション内のエンタープライズ・データ間の関係が文書化されます。例えば、データが現在どこにあり、オンプレミス、データレイク、データウェアハウスなどの環境でどのように保存されているかなどが文書化されます。

データ準備の作業は通常、データサイエンティストやデータエンジニアの役割となっており、彼らはビジネス・ユース・ケースの要件に応じてデータを構造化し、膨大なデータ量を扱います。データ・パイプラインに必要なデータ処理の種類は、通常、探索的データ分析と明確に定義されたビジネス要件の組み合わせによって決定されます。データが適切にフィルタリング、統合、要約されると、保存されて活用できる状態になります。適切に整理されたデータ・パイプラインは、さまざまなデータ・プロジェクトの基盤となり、探索的データ分析やデータの可視化、機械学習のタスクなどにも活用されます。

データ・パイプラインにはいくつかの種類があり、それぞれ特定のプラットフォームやタスクに適しています。一般的な種類には、次のようなものがあります

• バッチ処理パイプライン
• ストリーミング・データ・パイプライン
• データ統合パイプライン
• クラウドネイティブ・パイプライン

バッチ処理の開発は、信頼性と拡張性のあるデータ・インフラストラクチャーを構築する上で重要なステップでした。2004年、バッチ処理アルゴリズムであるMapReduceが特許を取得し、その後、 Hadoop、CouchDB、MongoDBなどのオープンソース・システムに統合されました。

その名が示すように、バッチ処理は、設定された時間間隔でデータの「バッチ」をリポジトリーにロードします。通常、オフピークの営業時間内にスケジュールされます。こうすることで、バッチ処理ジョブは大量のデータを扱う傾向があり、システム全体に負担をかける可能性があるため、他のワークロードは影響を受けません。バッチ処理は通常、特定のデータセット（月次会計など）をすぐに分析する必要がない場合に、最適なデータ・パイプラインであり、「抽出、変換、ロード」を表すETLデータ統合プロセスとより関連しています。

バッチ処理ジョブは、連続したコマンドのワークフローを形成し、1つのコマンドの出力が次のコマンドの入力になります。例えば、1つのコマンドでデータ取り込みを開始し、次のコマンドで特定の列のフィルタリングをトリガーし、後続のコマンドで集計を処理するといったことが考えられます。この一連のコマンドは、データ品質が完全に変換され、データ・リポジトリーに書き換えられるまで継続されます。

バッチ処理とは異なり、ストリーミング・データ・パイプライン （イベント駆動型アーキテクチャーとも呼ばれます）は、センサーやアプリケーション内のユーザー操作など、さまざまなソースから生成されるイベントを継続的に処理します。イベントは処理・分析された後、データベースに保管されるか、さらなる分析のために下流のシステムへ送られます。

ストリーミング・データは、データを継続的に更新する必要がある場合に利用されます。例えば、アプリやPOSシステムでは、製品の在庫や販売履歴を更新するためにリアルタイムデータが必要です。そうすれば、売り手は商品の在庫があるかどうかを消費者に知らせることができます。商品の販売などの1つのアクションは「イベント」とみなされ、チェックアウトへのアイテムの追加などの関連イベントは、通常、「トピック」または「ストリーム」としてグループ化されます。これらのイベントは、オープンソースのApache Kafka などのメッセージング・システムまたはメッセージ・ブローカーを介して転送されます。

データ・イベントは発生後すぐに処理されるため、ストリーミング処理システムはバッチ・システムよりも待機時間が短くなりますが、メッセージが意図せずにドロップされたり、キューに長い時間を費やしたりする可能性があるため、バッチ処理システムほど信頼性が高いとはみなされません。メッセージ・ブローカーは、確認応答を通じてこの問題に対処するのに役立ちます。確認応答では、コンシューマーがブローカーに対してメッセージの処理を確認し、メッセージをキューから削除します。

データ統合パイプラインは、複数のソースからのデータを単一の統合ビューに融合することに重点を置いています。これらのパイプラインには、多くの場合、抽出、変換、ロード（ETL）プロセスが含まれます。これは、未加工データをデータウェアハウスやデータレイクなどの集中リポジトリーに保管する前に、クリーニング、強化、またはその他の方法で変更するものです。データ統合パイプラインは、互換性のない形式や構造を生成する異種のシステムの処理に不可欠です。例えば、Amazon S3（Amazon Simple Storage Service）に接続を追加できます。これは、Webサービスのインターフェースを通じてオブジェクト・ストレージを提供する、Amazon Web Services（AWS）が提供するサービスです。

最新のデータ・プラットフォームには、組織のデータの収集、クレンジング、変換、分析を行ってより良い意思決定ができるよう支援する、クラウド・ファーストのクラウドネイティブ・ソフトウェア製品スイートが含まれています。今日のデータ・パイプラインはますます複雑化していると同時に、データの分析やデータ駆動型の意思決定を行う上でもより一層重要になっています。最新のデータ・プラットフォームは、正確かつタイムリーな情報の確保、データ・サイロの削減、セルフサービスの有効化、そしてデータ品質の向上を実現させる方法でのデータの取り込み、保管、処理、変換を行うことで、このデータに対する信頼性を構築します。

データ・パイプラインのアーキテクチャーは、3つの主要ステップで構成されます。

1. データ取り込み：データは、SaaS（サービスとしてのソフトウェア）プラットフォーム、モノのインターネット（IoT）デバイス、モバイル・デバイスなどのさまざまなソース、および構造化データと非構造化データ両方のさまざまなデータ構造から収集されます。ストリーミング・データ内では、これらの未加工データのデータ・ソースは通常、プロデューサー、パブリッシャー、または送信者と呼ばれます。企業は、処理する準備ができたときにのみデータを抽出することもできますが、最初に未加工データをクラウド・データウェアハウス・プロバイダーに格納することがベスト・プラクティスです。このようにして、企業はデータ処理ジョブを調整する必要がある場合に、履歴データを更新できます。このデータ取り込みプロセス中に、データの一貫性と正確性を確保するためにさまざまな検証とチェックを実行できます。

2. データ変換：このステップでは、一連のジョブが実行され、移行先のデータ・リポジトリーで必要な形式にデータを処理します。これらのジョブには、反復的なワークストリーム（ビジネス・レポートなど）に自動化とガバナンスを組み込んでおり、データが一貫してクレンジング・トランスフォーマーされることを確実にしています。例えば、データ・ストリームはネストされたJSON形式で提供される場合、データ変換ステージではそのJSONをデプロイして分析用の主要フィールドを抽出することが目的となります。

3. データ・ストレージ：変換されたデータはデータ・リポジトリー内に保管され、さまざまな関係者に公開される可能性があります。ストリーミング・データ内では、この変換されたデータは通常、コンシューマー、サブスクライバー、または受信者と呼ばれます。

会話では、データ・パイプラインやETLパイプラインなどの一部の用語は、同じ意味で使用される場合があります。ただし、ETLパイプラインはデータ・パイプラインのサブカテゴリーとして考える必要があります。2種類のパイプラインは、次の3つの主要機能によって区別されます。

• ETLパイプラインは特定のシーケンスに従います。略語が示すように、データを抽出し、データを変換し、データリポジトリにデータをロードして保管します。すべてのデータ・パイプラインがこの順序に従う必要はありません。実際、複数のソースとプラットフォームにわたってデータを生成して保存できるクラウドネイティブ・ツールの登場により、ELT（抽出、ロード、変換）パイプラインの人気が高まっています。このタイプのパイプラインでも、データの取り込みは最初に行われ、データがクラウドベースのデータ・ウェアハウスにロードされた後に変換されます。
  
  
• ETLパイプラインもバッチ処理の使用を意味する傾向がありますが、前述のように、データ・パイプラインの範囲はより広範囲で、ストリーム処理を含めることもできます。
  
  
• 最後に、可能性は低いですが、ETL パイプラインのように、データ・パイプライン全体で必ずしもデータ変換を行う必要はありません。データ分析を容易にするために変換を利用していないデータ・パイプラインを見ることはほとんどありません。

ビッグデータが増加するにつれて、データ管理の重要度はますます高まります。データ・パイプラインはさまざまな機能を果たす一方で、ビジネス・アプリケーション向けの機能は次のとおりです。

• 探索的データ分析：データ・サイエンティストは探索的データ分析（EDA）を使用してデータ・セットを分析および調査し、その主な特性を要約します。多くの場合、データの可視化手法が使用されます。これは、必要な答えを得るためにデータ・ソースを操作する最適な方法を決定する際に役立つため、データサイエンティストはパターンの発見、異常の特定、仮説の検証、仮定の確認を容易に行うことができます。
  
  
• データの可視化：データを一般的なグラフィックを使用して表現するために、チャート、プロット、インフォグラフィック、さらにはアニメーションなどでデータの可視化を作成します。これらの視覚的な情報表示により、複雑なデータ関係とデータ駆動型の洞察がわかりやすい方法で伝えられます。
  
  
• 機械学習：人工知能（AI）とコンピューター・サイエンスの一分野である機械学習は、データとアルゴリズムを使用して人間の学習方法を模倣し、その精度を徐々に向上させることに重点を置いています。統計的手法を使用することで、アルゴリズムは分類や予測を行うようにトレーニングされ、データ・マイニング・プロジェクト内の重要な洞察が明らかになります。
  
  
• データ・オブザーバビリティー：使用されているデータの正確性と安全性を検証するために、データ・オブザーバビリティーは、予想されるイベントと異常の両方を監視、追跡、およびアラートするためのさまざまなツールを適用します。