データ収集・取り込み

5.1 データ収集の複雑さと課題

データ分析基盤の構築において最も困難な工程がデータ収集です。前章で説明したデータレイクに生のデータを保存する前段階として様々なシステムからデータを取り込むのがこの工程です。

現代の企業では様々なシステムが連携して稼働しています。顧客管理システム、マーケティングツール、在庫管理システム、受発注管理システム、アクセス解析…などです。これらのシステムはそれぞれ異なる技術で構築されておりデータの形式・更新頻度・アクセス方法など全く違うことがほとんどでしょう。

データを取り込む工程が複雑な理由は大きく4つあります。

• データ形式の多様性：CSV・JSON・XML・固定長テキスト・バイナリファイルなど様々な形式が混在
• アクセス方法の違い：データベース直接接続・REST API・FTPサーバー・メール添付など多様な取得経路
• 更新スケジュールの違い：リアルタイム更新から月次更新まで時間軸が大きく異なる
• データ量の違い：数MBの小規模なファイルから数TBまでデータ量が段違い

従来は各システムの担当者が個別にデータを抽出し手動でやり取りしていました。しかしこの方法では人為的なミス・作業の遅延・データの不整合が頻発します。データ分析基盤では全てのデータソースを自動的かつ確実に取り込むための仕組みが必要不可欠です。

5.2 データソースの種類と特徴

データを取り込むという観点から、企業内で扱うデータソースは大きく4つのカテゴリに分類して紹介します。それぞれ異なる取り込み方法と注意点があります。

社内業務システム

社内の基幹システムは最も重要なデータソースです。販売管理、在庫管理、会計、人事そして自社ITサービスのデータベースなどが該当します。

これらのシステムの特徴は高い信頼性と一定の更新パターンです。たとえば在庫データであれば出荷処理後に比較的リアルタイムに更新されることが多いでしょう。一方で営業のデータは営業時間中リアルタイムに更新されるよりも営業時間終了後にまとめて確定・更新されることは珍しくありません。さらに会計データであれば月末月初に処理が集中しやくすく締め処理もこのタイミングです。このような更新タイミングを理解してデータ取り込みスケジュールを設計することが重要です。

取り込み方法はシステムによって異なります。データベースへの直接接続できたり専用のAPIが用意されていればやりやすいケースです。データベースからCSVファイルを出力して転送するというケースも珍しくありません。業務システムは古いことも多く、現代ではあまり使われないファイル形式や文字コードを扱う必要や互換性の確保が課題となります。

外部Webサービス・API

SaaSや広告配信プラットフォームなど外部のサービスから提供されるデータです。現代の企業運営では多くの外部サービスを連携して使うことも多いため、小さい企業でも複数の外部サービスを利用することは珍しくありません。

外部サービスからデータを取得するには方法や形式、制限を調査する必要があります。最近のサービスであればREST API形式でアクセスできることが多いですが、GUI上からしかアクセスできない場合は自動化が難しいケースもあるでしょう。そもそもまとめてデータの取得ができないということもあります。

またAPIだとしてもほとんどの場合で制約事項が存在します。APIの呼び出し回数の上限や、データ取得量の制限、認証トークンの更新、サービス停止時の対応などを考慮する必要があります。また外部サービスの仕様変更により突然データ取得ができなくなるリスクもあります。

このような多様な接続形式や仕様の変更に対応できるような柔軟な仕組みと体制が必要になります。自分たちで接続するシステムを開発するだけでなく、データ分析基盤が用意しているコネクターを利用したり外部サービスと連携するサービスの利用を検討してもよいでしょう。

ファイルデータ

PDFや画像、動画などのファイル形式で提供されるデータです。請求書など外部から送られてきたPDFファイル、経費の精算に使うレシートの画像データ、議事録の録画ファイルなどがさまざまなものがあります。

ファイルのデータはさまざまな経路から発生するうえデータの性質に応じて個別の対応が求められます。特に保存する場所や形式には注意が必要です。動画などデータのサイズが大きい場合はストレージがすぐに満杯になってしまったり、従量課金制の場合は気がついたらストレージだけで予算を使い切ってしまいます。

ファイル形式の場合はデータベースのように構造化されたデータをもっていないため、何らかの処理を通して構造化されたデータをデータウェアハウスに保存することが多くあります。たとえば、音声から文字起こししたり画像からOCRするようなパターンです。この場合は処理の内容があとから変更されることも少なくないのでなるべく元データを保存することが望ましいでしょう。

リアルタイムストリームデータ

IoTセンサー・Webサイトのログデータ・金融取引データなど連続的に生成されるデータです。

ストリームデータの特徴は高頻度・小容量・時系列性です。常にデータが連続的に流れ込みます。データの順序や時刻情報が重要でありネットワーク遅延や重複配信への対応が必要です。

ストリームデータの取り扱いは他のケースに比べて技術的に難易度が高くなります。取り込みには専用のメッセージングシステムが使用されることが一般的です。AWSのKinesisやGoogle CloudのPub/Subなどが挙げられます。

他のデータの形式と違ってリアルタイムに取得されたデータが常に網羅的であるとは限らないという点が厄介です。例えば、スマホアプリのログデータであれば端末がネットワークにつながっていないときはログが送信されてこないため後からログが到着するという事象が起きます。データの取得に遅延がなくとも、分析にすぐさま使えるかどうかは別の問題となります。

5.3 バッチ処理とストリーミング処理

データの収集にあたってどのようなデータがあるのか俯瞰したところで、次はどのようにしてデータを取り込むのか？という観点からいくつか重要なポイントを紹介します。

データ取り込み方式には大きく分けてバッチ処理とストリーミング処理があります。どちらを選択するかはデータの性質と業務要件によって決まります。

バッチ処理

バッチ処理は決められた時間にまとまったデータを一括で処理する方式です。「毎日午前3時に前日分の売上データを取り込む」とか「月末に1ヶ月分の会計データを取得する」といったように決まった時間や間隔で定期に処理をおこないます

バッチ処理の利点はシンプルな設計と処理効率の高さです。まとまった処理ロジックを構築できるため比較的実装をシンプルにしやすく運用管理も容易になります。エラーが発生した場合の再実行やリトライも簡単に実装できます。また、大量のデータを一度に処理するため処理の効率も向上します。

一方でバッチ処理の欠点はリアルタイム性です。決まった時間に実行されるため、その時間までは最新のデータが反映されません。更新頻度を高めることでこの問題はある程度解決することはできますが高いリアルタイム性が求められる場合はバッチ処理だと限界があるでしょう。

また、データ量が非常に大きい場合もバッチ処理が難しい場合があります。バッチ処理のためには一度にデータを取り込む必要があるためメモリに乗らないデータ量となると途端に処理が難しくなります。スケールできるシステムであればある程度は解決しますが実装が複雑になるためストリーミング処理をおこなったほうが便利な場面もでてきます。

ストリーミング処理

ストリーミング処理はデータの追加や変更をリアルタイムかつ連続的に処理する方式です。WebサイトのアクセスログやIoTセンサーデータなど刻一刻と変化するデータに適しています。

ストリーミング処理の一番のメリットはリアルタイム性です。発生したデータをリアルタイムに分析結果へと反映させることができます。広告やリリースの効果検証のように施策を実行したあと素早くデータを取得して分析したいときに有用です。

加えて、継続的に処理するという点もメリットがあります。小さなデータを連続処理するためシステム負荷が平準化されます。バッチ処理でデータが大きすぎて処理が詰まるような事態を解消することができます。

一方でストリーミング処理の欠点は設計・運用の複雑さです。データの順序や重複処理の回避、障害時の復旧など考慮すべき点が多数あります。処理中断によるデータ欠損のリスクもあります。

また、リアルタイムといっても完全にデータの発生から瞬時にデータが得られるわけではありません。システムの構成にもよりますが数秒から数分の遅延があることが一般的です。

適切な選択基準

どちらを選択するかは以下の観点で判断します。

1つはデータの鮮度です。リアルタイムな分析が必要ならストリーミングが必要になりますが、日次や週次レポートで十分ならバッチを選択します。

2つ目はシステムの運用のしやすさです。処理のわかりやすさや障害発生時の対応のしやすさを重視するならバッチが適しています。

3つ目はデータの量です。センサーやアクセスログのようにデータ量が非常に大きく継続的に更新されている場合はバッチよりもストリーミング処理したほうが効率がよいでしょう。

実際の運用では両方を組み合わせることが一般的です。顧客データなど日次で十分なデータはバッチで処理し、日次よりもリアルタイム性が求められるデータや連続的かつ大量に発生するログデータはストリーミング処理にするといったハイブリッド構成になります。

5.4 データ取り込みパターン（全件 vs 増分・CDC）

効率的なデータ取り込みのために適切な取り込みパターンを選択することが重要です。主要なパターンを3つ紹介します。

全件取り込み

毎回データソースから全てのデータを取り込む最もシンプルな方式です。「毎日商品マスタの全件を取り込む」「毎月CRMの全データをコピーする」といった処理が該当します。

全件取り込みの利点は実装の簡単さと確実性です。すべてのデータを丸ごと取得して保存するだけなので複雑な差分処理が不要で過去データの修正や削除も確実に反映されます。また障害からの復旧時も最新の全件データを取り込むだけで完全に復元できます。

一方で欠点は処理時間と負荷の大きさです。データ量が増加すると1回あたりの処理に必要な計算資源や処理時間が増えますしネットワーク帯域なども大量に消費します。また、毎回同じデータを転送するため効率は悪くなります。

増分・差分取り込み

新しく追加されたり更新されたデータのみを取り込む方式です。「前回取り込みをおこなった昨日の17時以降に追加・更新された注文データのみ取得する」といった処理が該当します。

増分取り込みの利点は処理効率とリソース節約です。前に取得したときとの差分しか処理しないので転送するデータ量と処理時間を大幅に削減できます。そのため頻繁な取り込み処理も可能になりデータの鮮度を向上させやすくなります。

しかし、増分・差分取り込みは管理が複雑になりがちです。どのデータが更新されたかを判定する仕組み・処理済みデータの管理・取り込み失敗時の差分データの処理などを考慮する必要があります。要件が複雑になるためデータ更新の定義の誤りで過去データの修正や削除を見落とすというケースは珍しくありません。

CDC + ストリーミング

CDCとはChange Data Captureの略でデータベースの変更をリアルタイムで検知する技術です。CDCで検知した変更内容をそのままストリーミングで取り込むのがこの方式です。データベースのトランザクションログを監視して挿入・更新・削除の操作を即座に反映します。

CDCの利点はリアルタイム性と完全性です。データ変更から素早く分析基盤に反映でき、変更・削除も含めて完全に同期されます。差分更新とは異なりトランザクションを監視しているためデータの修正や削除を見落とす可能性が低くなります。

一方で、CDCの欠点は技術的複雑さと運用の難易度です。データベース固有の仕組みを理解する必要があり全件更新などに比べると実装が複雑ですしシステム障害時の原因や影響範囲の特定が難しくなります。また、全てのデータベースがCDCに対応しているわけではありません。

適切なパターンの選択

パターン選択はデータの特性と要件によって決まります。マスタデータのような更新頻度が低いデータは全件取り込み、トランザクションデータのような大容量データを増分取り込み、リアルタイムな分析が必要なデータはCDCと使い分けることが必要です。実際の運用では複数パターンを組み合わせて各データソースと利用目的に応じて適した方式を適用します。

5.5 データ収集アーキテクチャの設計指針

データ収集システムを効率的かつ安定的に運用するためにアーキテクチャの設計についていくつかの指針を紹介します。

シンプルな取得方法の優先

データ収集システムでは複雑な処理を避けシンプルな取得方法を優先することが重要です。技術的に高度な仕組みよりも理解しやすく保守しやすいアプローチを選択することで長期的な運用コストを削減できます。

例えばリアルタイム性が必須でない場合はストリーミング処理ではなくバッチ処理を選択します。データ量などに問題がなければCDCや増分・差分更新よりも全件取得のほうがロジックがシンプルで楽になります。

また、データソースからデータを取得する手法はAPIが用意されているならばAPIを利用することが望ましいでしょう。RPAツールやクローリングなどは動作も安定しないためなるべく避けるべきです。外部サービスの場合は用意された方法以外だと規約違反になる可能性もあります。

スケーラビリティへの対応

基本的に取得するデータは増えていくという前提のもと設計する必要があります。増加速度は場合によりますが減ることはふつうありません。データが増えたときにスケールできる設計になっていることが重要です。

また、データ量の増加だけでなく接続するデータソースの数と多様性の拡大にも柔軟に対応できる設計が必要です。水平スケーリングにより処理サーバー数を増やすことでデータソースの増加に対応できるアーキテクチャを採用します。

データソースの多様性に対しては機能を追加しやすいアーキテクチャが有効です。新しいデータソースが追加されても既存システムに影響を与えることなくコネクタやアダプターを追加できる仕組みを構築します。APIの変更や新しいファイル形式にも迅速に対応できる拡張性を確保することが重要です。

監視と運用性の考慮

データ収集の成功・失敗・処理時間・データ品質を常時監視する仕組みが不可欠です。各処理段階でメトリクスを収集しダッシュボードでリアルタイム監視できる環境を構築します。

異常検知の自動化により処理失敗やデータ品質悪化を即座に検出しアラート通知を行います。また処理ログの詳細記録により問題発生時の原因調査を迅速に実行できるようにします。運用手順書とトラブルシューティングガイドも整備し属人化を防ぎます。

セキュリティとコンプライアンス

データ収集過程で個人情報や機密情報を適切に保護する仕組みが必要です。データ転送時の暗号化・アクセス権限管理・監査ログ取得を徹底し情報漏洩リスクを最小化します。

また法的要件への対応も重要です。GDPR・個人情報保護法などの規制に応じてデータ保持期間・削除手順・同意管理を適切に実装します。定期的なセキュリティ監査により継続的な改善を図ることも必要です。