データパイプラインの比較とは、自社のデータ活用に見合う仕組みを、どの観点で選ぶかを整理する作業です。製品ごとの機能表を並べても、自社の体制や扱うデータの性質に合っているかまでは判断できません。実装形態を決めないまま個別の製品を見比べ、導入後に運用が回らなくなる例も見受けられます。
本記事では、データパイプラインを比較するときに確認したい5つの項目を、データ基盤の構築や刷新を検討する企業のご担当者に向けて解説します。自社に合う仕組みを選ぶ材料としてお使いください。
データパイプラインそのものの定義や、ETL・ELT・リバースETLとの関係は、データパイプラインとは？仕組みや種類、ETLとの違いと構築のポイントを解説で解説しています。
データパイプラインの比較は、製品ごとの機能を並べるところから始めると迷いやすくなります。自社の体制や扱うデータの性質に合っているかどうかは、機能の一覧からは読み取れないためです。
比較の出発点になるのは実装形態です。どの形で構築するかによって、その後に検討すべき製品や体制の範囲が変わります。残る4項目は、実装形態を問わず共通して確認が必要な観点です。以下の順に解説します。
データパイプラインの実装形態は大きく4つに分かれ、初期の費用と運用の負担の配分がそれぞれ異なります。代表的な4つを順に紹介します。
専任のデータエンジニアを確保しにくい場合は、SaaS型のデータ連携サービスから検討しましょう。SaaS型は画面上の操作でデータの取得元と格納先を設定でき、接続部分の保守を提供側に任せられるのが特徴です。
コネクタと呼ばれる接続部品があらかじめ用意されており、社内システムとの連携を短期間で始められます。たとえば販売管理や顧客管理のクラウドサービスからデータを取り出す場合、接続用のプログラムを自社で書く必要はありません。接続先の仕様が変わったときの追従も、提供側でおこなわれる範囲が広くなります。
一方で、料金は処理するデータ量や接続数に応じて増えていきます。対応していないデータソースには別の手段が要るため、事前に接続先の一覧を洗い出しておくと安心です。
クラウドベンダーのマネージドサービスは、すでに特定のクラウド上にデータをためている企業に向いた形態です。同じ環境のなかで処理が完結するため、データの移動にかかる時間や通信の費用を抑えられます。
たとえば分析用のデータベースをクラウド上に置いている場合、同じベンダーの連携サービスを使えば、権限の管理や監視の仕組みをまとめられます。請求も既存の契約に含められるため、社内の承認を得やすい点も利点です。
ただし、複数のクラウドやオンプレミス環境が混在している企業では、対応できる範囲に偏りが出ます。自社のデータがどこに置かれているかを整理したうえで、対象となる範囲を確認してください。
オープンソースを組み合わせる構成は、処理の中身を自社の要件に合わせて細かく作り込みたい場合に適しています。ライセンスの費用がかからず、必要な機能だけを選んで組み立てられるためです。
一方で、動かし続けるための人手は自社でもつ形になります。処理の実行順序を管理する仕組み、失敗したときの通知、再実行の手順まで、すべて自前で整える必要があります。たとえば担当者が1名から2名の組織では、日々の障害対応に時間の多くを取られかねません。
オープンソースを選ぶ場合は、導入時の費用だけで判断せず、数年単位の運用工数まで含めて比べてください。
自社開発と外部委託は、既存のサービスでは要件を満たせない場合の選択肢です。独自の装置から出るデータや、社外に出せない情報を扱う場面で採用されます。
設計から運用までを外部の専門会社に委託すれば、社内に人員を置かずに構築を進められます。自社開発を選ぶ場合、処理の内容も運用の体制もすべて自社で抱える形になるため、人員の確保が前提です。たとえば要件定義と基盤の構築だけを委託し、運用開始後に社内へ引き継ぐ進め方もあります。
外部に委託する場合は、契約の範囲に運用と改善が含まれているかを確認してください。構築だけで終わる契約では、稼働後の変更に対応できない状態になりがちです。
データパイプラインが扱えるデータソースの範囲は、接続の方式によって変わります。代表的な4つの連携方式を紹介します。
業務システムのデータベースへの直接接続は、社内に蓄積された販売や生産の記録をまとめて取り出す場面で使われます。データベースの表をそのまま読み取れるため、取得できる項目の自由度が高くなります。
確認したいのは、稼働中のシステムに負荷をかけずに読み取れるかどうかです。日中に大量のデータを読み出すと、本来の業務処理が遅くなる場合があります。夜間の時間帯に実行する、複製した環境から読み取るといった回避の手段を、設計の段階で決めておいてください。
接続にあたっては、読み取り専用の権限を用意しておくと安心です。
SaaSやWebサービスのデータは、提供元が用意する接続の窓口を通じて取得します。販売管理や顧客管理、広告配信といったクラウドサービスに保管された情報を、自動で取り込める形です。
注意したいのは、取得できる件数や頻度に制限が設けられている点です。1日に取り出せる件数や、一定時間内の呼び出し回数に上限があると、想定した頻度でデータを更新できません。提供元の仕様変更で連携が止まる場合もあるため、告知を追う担当を決めておく必要があります。
比較の際は、必要なサービスに標準で対応しているかを一覧で確認してください。
ファイル転送による連携は、取引先や社外の組織からデータを受け取る場面で今も広く使われています。決められた場所に置かれた表形式のファイルを取り込み、加工したうえで蓄積する流れです。
古い方式に見えても、社外との受け渡しでは有力な選択肢になります。接続用の仕組みを相手側に用意してもらう必要がなく、合意も取りやすいためです。たとえば月次で届く実績データを取り込む用途なら、複雑な仕組みを組む必要はありません。
一方で、ファイルの列が予告なく増減すると処理が止まります。取り込みの時点で想定どおりの形式かを検査する仕組みを、あわせて用意してください。
IoT機器やセンサーからのデータ取得は、機器から送られる測定値を絶え間なく受け取り、蓄積していく形です。製造現場や設備の状態を継続して把握したい場合に選ばれます。
オンタイムでデータ取得ができるのはメリットですが、扱う量が他の連携方式とけた違いに大きくなる点に注意してください。1台あたりの測定値は小さくても、台数と頻度を掛け合わせると膨大な量になります。たとえば画像や音声を含む場合、保管の費用と転送にかかる時間が計画の前提を左右します。
データパイプラインは、データをいつ処理するかによって仕組みの複雑さと費用が変わります。代表的な3つの方式を、向く用途とあわせて紹介します。
| 方式 | 処理のタイミング | 向く用途 |
|---|---|---|
| バッチ処理 | 決めた時刻にまとめて処理する | 日次や月次の集計、実績のレポート |
| ストリーミング処理 | 発生の都度、数秒から数分で処理する | 設備の異常検知、不正な取引の検知 |
| CDC | 更新が発生した分だけ随時取り込む | 基幹データベースの準リアルタイム同期 |
処理するデータ量が前日分の数字のみ程度なら、バッチ処理から始めましょう。バッチ処理とは決めた時刻に一括で処理する方式であり、仕組みが単純なぶん構築と運用の負担を抑えられます。
費用の見積もりが立てやすい点も、バッチ処理の利点です。処理する時間帯と量があらかじめ決まっているため、必要な計算資源を見込みやすくなります。たとえば夜間にまとめて実行する設計なら、業務時間帯のシステム負荷も避けられます。
反対に、処理が失敗すると次の実行まで数字が古いまま残る点には注意が必要です。実行結果の確認と再実行の手順を、導入の時点で決めておいてください。
ストリーミング処理は、データが発生してから数秒から数分のうちに処理を終える方式です。設備の異常検知や不正な取引の検知など、遅れがそのまま損失につながるような取引において採用されます。
ストリーミング処理は都度の処理が必要なため、設計と運用の難度は、バッチ処理より一段上がります。処理が滞った場合に備えて順番待ちの仕組みを用意し、機器の停止や通信の途絶にも耐える構成が必要になるためです。そのため、担当できる人員がいるかどうかを、方式を決める前に確かめてください。
更新があった分だけを取り込みたい場合は、CDCと呼ばれる方式を検討してみてください。CDCとはデータベースの更新記録を読み取り、変更のあった行だけを送り出す仕組みです。
CDCは差分だけを読み直す形式なので、全件データを読み込み直す方式に比べればシステム負荷は軽減されます。いわば、バッチとストリーミングの中間にあたる選択肢です。
ただし、導入には対象データベースが更新記録の読み取りに対応している必要があります。導入前にデータベースの仕様を確認しておきましょう。
データパイプラインを比較するときは、運用や障害対応の人的コストも重要です。ここからは、コストが発生しやすい4つの場面を紹介します。
データパイプラインには処理の追加、設定の変更などの運用人員が必要です。この運用工数は実装の形態によって異なります。
たとえば、画面上の操作だけで設定を書き換えられる仕組みの場合は、業務部門の担当者が運用を兼ねることもできるでしょう。反対にプログラムを書いて処理を追加する仕組みの場合は、エンジニアが担当しなければなりません。
比較の段階で、月あたり何時間を運用に充てられるか、担当できる人員の人数まで見積もっておきましょう。
データパイプラインを比較する際は、異常値が発生した際の障害の検知と通知のシステムも確認しましょう。もしも検知や通知が自動でされる仕組みがなければ、人が毎日目視でデータが正常に取得されているか、またエラー検出後の監視もしなければなりません。
障害対応チームを別で立ち上げる必要が生まれると、人的なコストもかかります。システムにデフォルトで障害検知と通知、また復旧後の監視の仕組みがあるシステムを選ぶのがおすすめです。
復旧と再実行のしやすさは、障害が起きたあとの負担を左右します。同じ処理をもう一度動かしても結果が変わらない作りであれば、迷わず再実行に踏み切れるためです。
同じデータが二重に取り込まれる作りだと、復旧のたびに手作業での修正が発生します。たとえば売上の記録を追加していくだけの処理では、再実行によって金額が二重に計上されます。対象の期間をいったん消してから入れ直す、あるいは同じ鍵をもつ行は上書きする作りにしておくと、何度実行しても結果は同じです。
比較の際は、再実行の手順が用意されているかを実際の画面で確かめてください。
上流システムの仕様変更への追従は、運用を続けるうえで負担になりやすい部分です。連携元の項目が増減したり、接続の仕様が変わったりする出来事は、数年のうちに必ず起こるためです。
たとえば、変更を自動で検知して追従する機能があるかどうかで、担当者の手間が大きく変わります。項目の追加を自動で取り込む仕組みがあれば、設定を書き換える作業は要りません。
データパイプラインは、社内の重要な情報が集まる経路です。比較の段階で確認したい4つの観点を紹介します。
通信と保管データの暗号化は、比較の初期の段階で確認してください。データパイプラインは社外のネットワークを通る区間を含むことが多く、途中で内容を読み取られる危険があるためです。
保管時の暗号化にも対応しているかを、あわせて見てください。転送中だけを守っても、蓄積された先が保護されていなければ意味が薄れます。たとえば個人情報や設計に関わる情報を扱う場合、暗号化の方式や鍵の管理の方法まで資料で示せるかが判断の材料です。
外部の認証を取得しているかどうかも、確認の手がかりになります。
アクセス権限の設計は、誰がどのデータに触れられるかを決める作業です。部門をまたいでデータが集まるほど、見える範囲を絞る必要が増します。
導入前に権限を役割ごとにまとめて設定できる仕組みがあるかどうかを確認してください。利用者が増えるたびに個別に設定する方式では、設定の漏れや過剰な権限が残りやすくなります。たとえば人事や購買の情報を含む場合、表や列の単位で見える範囲を分けられるかまで確かめておくと安心です。
社内の認証基盤と連携できるかどうかも、運用の手間を左右します。
金融や医療、製造の領域などでは外部への説明を求められる場面があります。そのため、処理履歴の記録や監査対応の機能があるかも比較しましょう。
その際はどの記録がどれだけの期間残るかを、比較の段階で確認してください。たとえば設定の変更履歴まで残る仕組みなら、想定外の動きがあったときに原因を追いやすくなります。
記録の出力先を自社側で指定できるかどうかも、あわせて確かめてください。
オンプレミス環境や閉域ネットワークへの接続は、社外に出せない情報を扱う企業で確認が必要な項目です。生産の設備や検査の装置から出るデータは、外部と直接つながらない環境に置かれていることが多いためです。
比較の際には社内に設置する中継用の仕組みが用意されているかを確認してください。インターネットに直接つながらない環境からデータを取り出すには、社内側から通信を開始する形をとる必要があります。たとえば工場ごとにネットワークが分かれている場合、拠点の数だけ中継の設計が要ることもあるため、この点はしっかり確認すべきでしょう。
データパイプラインの比較は製品の機能を並べるのではなく、自社がどの形で構築した以下で比較しましょう。
SaaS型のサービス、クラウドベンダーのマネージドサービス、オープンソースの組み合わせ、自社開発と外部委託のいずれを選ぶかで、その後に確認すべき範囲が変わります。
実装形態が決まったあとは、接続できるデータソースと連携方式、実行タイミングと処理量、運用と障害対応にかかる工数、セキュリティとアクセス権限の管理という4つの項目を順に確かめてください。とくに運用と障害対応は、稼働してから差が表れる部分です。
弊社は、データパイプラインの設計から構築、運用と改善までを一貫して支援しています。対象は、自動車や製造、プラントといった現場から生まれる大量のデータです。目的を起点にしたデータの設計、品質を前提とした整備、繰り返し使えるデータ資産の蓄積までをまとめてお任せいただけます。
比較の途中で判断に迷う場合は、お気軽にご相談ください。
