データパイプラインは、分析のためにソースシステムから宛先にデータを移動する自動化されたシステムです。これにより、データを利用するビジネスにとって一般的な課題である、多くの異なるシステムに分散している有用な情報をどのように処理および分析するかという問題が解決されます。パイプラインにより、確実に繰り返しデータを移動できます。

以下では、データパイプラインとは何か、その仕組み、バッチアプローチとストリーミングアプローチの違い、決済データがパイプラインの構築にどのように組み込まれるかについて説明します。

主なポイント

• データパイプラインは、負荷がかかると失敗する手動のエクスポートやアドホックなプロセスに代わるものです。

• バッチパイプラインとストリーミングパイプラインのどちらを選択するかは、データにどの程度の最新性が求められるかによって異なります。通常、財務および分析のワークロードは、バッチで問題なく実行できます。

• 決済データは、パイプラインの構築において特に注意が必要です。決済代行業者からのネイティブ同期により、セキュリティと信頼性が向上します。

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

データパイプラインは、1 つ以上のソースからデータを抽出し、必要に応じて変換し、分析や運用に使用できる宛先に読み込む一連の自動化されたステップです。宛先は通常、データウェアハウス、データレイク、またはクラウドストレージです。

レポート作成や意思決定においてデータパイプラインが重要である理由

データパイプラインの価値は、データを利用可能な場所に置くことで実現できることにあります。データパイプラインには以下の利点があります。

• データのサイロ化の軽減: データが複数のシステムに分散している場合 (たとえば、収益データは決済代行業者、顧客データは 顧客関係管理 (CRM) システム、サポートデータはヘルプデスクに保存されている場合)、システム間の境界を越える質問に簡単に答えることはできません。これらのソースを一元化するパイプラインにより、部門横断的な分析が可能になります。

• 一貫した定義: パイプラインは構造を強化します。すべてのチームが同じように計算された同じウェアハウステーブルからデータを取得する場合、月間経常収益 (MRR) などの指標はレポート全体で一貫して定義され、どの数値が正しいかについての議論は発生しません。

• 反復可能で監査可能なプロセス: パイプラインにより、日々比較可能な結果が生成されます。この反復可能性により、長期にわたって指標を追跡し、異常が発生したときに調査できます。

• レポート作成サイクルの短縮: 以前はデータの抽出と照合に何日も費やしていた財務チームは、データがすでにウェアハウスにあり、クリーンアップされ、構造化されていれば、サイクルを大幅に短縮できます。

データパイプラインの主な構成要素とは？

多くのパイプラインは、複雑さに関係なく、同じ構成要素のセットから構築されています。重要な要素は次のとおりです。

• ソース: データベース、Software as a Service (SaaS) アプリケーションプログラミングインターフェース (API)、イベントストリーム、フラットファイルなどのデータの発生源です。パイプラインがデータを取得するソースが多いほど、各ソースのスキーマと信頼性、およびソースが変更される頻度を追跡することが重要になります。

• 取り込み: ソースからパイプラインにデータを抽出するメカニズム。これには、スケジュールされたデータベースクエリ、Webhook ストリームのサブスク、サードパーティのコネクターなどが含まれます。取り込みの段階はパイプラインが機能しなくなる (API の変更、認証情報の期限切れ、ソースの障害など) ことが多いため、優れた取り込みレイヤーは障害を検出して復旧できるように構築されています。

• 変換: 生データを分析に役立つ形式に再構成するステップ。たとえば、変換により、レコードのクリーンアップや重複の排除、複数のソースからのデータの結合、派生フィールドの計算を行ったり、ネイティブに共有していないシステム間で一貫したスキーマを適用したりします。

• オーケストレーション: 依存関係とスケジュールを管理するレイヤー。Table B が Table A の完全な読み込みに依存している場合、オーケストレーションレイヤーはそれを認識し、順序を適用する必要があります。Apache Airflow、Prefect、data build tool (dbt) などのツールは、このような依存関係の管理を処理できます。

• 宛先: 処理されたデータが格納される場所。通常、これは Snowflake や Redshift などのクラウドデータウェアハウス、または S3 や Google Cloud Storage (GCS) などのクラウドストレージです。宛先の選択により、ダウンストリームでどのような分析が可能かが決まります。

バッチパイプラインとストリーミングパイプラインの違いは？

データの移動において、ストリーミングとバッチの両方に正当な用途があります。どちらを選択するかは、データがどの程度古くなると実際の問題が発生するかによって決まります。

バッチパイプライン

これらはスケジュール (1 時間ごと、毎晩、毎週など) に従ってデータを移動します。月次の財務レポート、毎週の顧客コホート分析、データウェアハウスへの毎晩の同期など、レイテンシが重要ではないワークロードに適しています。バッチ処理は一般に、構築と運用が簡単です。多くの分析のユースケースでは、まさにこれが求められます。

ストリーミングパイプライン

これらは、イベントが発生するたびに継続的にデータを処理し、レイテンシは数時間ではなく数秒または数ミリ秒単位で測定されます。これらは、不正利用の検出、リアルタイムの在庫追跡、リアルタイムダッシュボードなど、古いデータに基づいて行動することが実際のコストにつながるユースケース向けに構築されています。

データの移動にこのルートを選択する前に、チームのキャパシティを判断してください。ストリーミングインフラストラクチャはコストが高く、デバッグが困難です。データチームが小規模な場合、ストリーミングパイプラインのオーバーヘッドがレイテンシのメリットを上回る可能性があります。

データパイプライン、ETL、ELT の関係は？

データパイプラインがソースから宛先にデータを移動する自動化されたシステムであるのに対し、抽出・変換・読み込み (ETL) と抽出・読み込み・変換 (ELT) は、その移動を構造化する 2 つのパターンです。それぞれの仕組みは以下のとおりです。

ETL

ETL とは、データが宛先に読み込まれる前に変換されることを意味します。変換は中間レイヤーで行われるため、クリーンアップされ、整形された出力のみがウェアハウスに到達します。これは、ストレージが高価であり、ウェアハウスが生データを大規模に処理するのに適していなかった時期の主流のパターンでした。

ELT

ELT では、後半のステップが逆になります。生データが抽出されてウェアハウスに読み込まれ、そこで構造化照会言語 (SQL) または dbt などのツールを使用して変換が行われます。最新のクラウドウェアハウスは、生データを保存できるほど低コストであり、クエリ時またはスケジュールされたジョブとしてデータを変換できるほど強力です。生データを再処理用に保存し、変換の監査、バージョン管理、変更を容易にできることもあり、ELT は分析ワークロードにおいてより一般的なパターンになっています。

すべてのパイプラインがどちらかのカテゴリにきれいに収まるわけではありません。ほとんど変換を行わずにデータを移動するものもあります。API からの未加工のイベントログをクラウドストレージに同期して、後で処理します。この用語は、厳密な分類としてではなく、アーキテクチャの意図を示す簡略表現として役立ちます。

データパイプラインの構築において決済代行業者はどのような役割を果たすか？

決済データは、企業のウェアハウスの中で最も価値が高く、複雑なデータの一つです。このデータを管理する際、一般的にどのチームも同じようなプロセスをたどります。

カンマ区切り (CSV) のエクスポート

多くのチームは CSV のエクスポートから始めます。レポートをダウンロードしてクリーンアップし、ウェアハウスにアップロードします。しかし、エクスポートが失敗したり、スキーマが変更されたり、プロセスの実行を忘れたりすることがあります。その結果、過去のデータが欠落したり、一貫性がなくなったりすることがよくあります。

サードパーティの ETL コネクター

次に、決済 API からデータを取得し、スケジュールに従ってウェアハウスに読み込むツールが利用されます。これらはある程度信頼できますが、機密性の高いデータフローにベンダーを介在させることになります。財務データが別のサードパーティシステムを通過する場合、攻撃対象領域が拡大し、コンプライアンス上の懸念が生じます。さらに、決済代行業者が保持するデータと微妙に異なるデータが生成される可能性があります。

Stripe Data Pipeline を介したネイティブ同期

Stripe Data Pipeline を使用すると Stripe と直接同期でき、サードパーティのコネクターなしでデータをウェアハウスやクラウドストレージの宛先に移動できます。数回のクリックで設定でき、ノーコードで利用できます。さらに、パイプラインにはユーザーの Stripe アカウントの過去のデータが含まれます。構造化された財務サマリーや、MRR や不正利用などを分析するための分析対応テーブルなど、厳選された統合レポートやデータセットも含まれています。これらは Stripe 独自のシステムで生成されるため、汎用のコネクターで複製することはできません。