データ分析基盤を構築するとき避けて通れないのが「どうやってデータを取得するか」という問題です。

SaaSのETLツールを使うのか、APIを自前で叩くのか、手動でCSVを取り込むのか。
データを取得する手法は選択肢が多く状況に応じて最適な手法は変化します。
また、技術的な問題だけではなく分析する側であるビジネス上の要求も考える必要があります。

本記事では技術選定の判断基準を整理し、筆者の経験をもとに実際によくある検討のパターンを解説します。

データの鮮度・更新頻度

更新頻度は技術選定に最も直接的な影響を与える要素です。

一般にデータを更新する頻度が上がるほど自動化の設計は複雑になります。
日次であれば夜間バッチで全件更新というシンプルな仕組みで済みますが、これが数時間おきとなるとAPIのレートリミットを意識した設計が必要になるかもしれません。
更にリアルタイムになれば差分検知やリトライの仕組みまで求められます。

つまり更新頻度は「どの程度の仕組みを作る必要があるか」を決める起点であり実装・運用コストに直結します。
逆にいえば「どれくらいの頻度でデータを更新する必要があるか」を最初に固めることで選択の幅が大きく絞り込むことができます。

低頻度

低頻度とは年に数回くらいの想定です。
こういったデータの場合は手動で全件を更新するというケースが多くなります。
データソースと分析上の要求として増分・差分をわざわざ検知する必要がないため全件更新で問題がないこと、そして頻度が低いため自動化のメリットを享受しにくいこと多いためです。
更新頻度が低いデータの場合はそもそもデータの形式や用途が安定しないこともあり処理の内容を毎回検討する必要が多いことも自動化の優先度が下がる要因の1つです。

自動化を選ばないケースでいうと、たとえば特定のプロジェクトや顧客で単発で発生するようなケースがあります。
プロジェクトで単発的にデータが発生したり、顧客ごとにデータの形式にばらつきがあったりという状況です。
このような不定期でデータの形式も完全に固まっていない場合は自動化のコストが高くなりがちです。
担当者がその都度手動で取り込む運用でも十分でしょう。

逆に頻度が低いとはいえデータの形式が固まっており処理が複雑という場合は自動化のメリットが上回ります。
エクスポートしたデータをエクセルなどで細々と整理してからアップロードするようなプロセスが必要だとしたら手間もかかりますしミスも起きやすいので自動化が望ましいでしょう。
たとえば、年に数回しか更新されないマスタデータがありながらインポートにひと手間必要という場合はこのケースに該当します。
完全に自動化する必要もないので無理にワークフローに載せずにスクリプトとして保存しておくなどの対処もありえます。

月次・週次

月次・週次で更新する場合は全件更新するケースが多くなります。
データソースの特性として月次・週次で更新するデータは何らかの作業がひととおり終わったものを保存するというケースが多く、そのため増分・差分を検知して保存するというよりも全件を保存したいことが多いからです。
たとえば締め作業が終わって確定した会計データや、週次で棚卸し作業をしている在庫情報などが挙げられます。

月次・週次くらいの頻度で恒常的に発生するとなると自動化による作業コストが削減できるメリットが大きくなるため多くの場合で自動化を検討します。
1つ2つくらいのデータソースであればなんとかなりますがデータ分析基盤には多くのデータソースを結合していくことになりますので自動化することを前提に設計するべきでしょう。

また、作業ミスによるリスクも考慮に入れるべきです。
それなりの頻度で作業することになりますから必然的にミスも発生します。
作業ミスはそのままデータ品質の問題に、そして誤った意思決定へと繋がります。
より確かな意思決定という観点からも週次・月次くらいの更新頻度が定常的に発生するようであれば自動化が前提という意識でいるのがよいでしょう。

日次更新

最も一般的な更新頻度です。
毎晩にバッチ処理を走らせ朝出社したときには最新のデータが見られるようになっている、というサイクルは多くのビジネスの意思決定に十分なサイクルです。
日次の更新ではデータ量がよほど大きくない限り全件を取得してそのまま更新するシンプルな設計をベースに検討します。

この頻度になると自動化は原則です。
毎日の作業となると手動では作業の負担が大きくなります。
あわせて作業頻度が増えることでミスも起きやすくなるため担当者の業務を圧迫します。
スケジュール実行で毎日自動的に動くように設計しておくことで安定した運用が実現できます。

基本は全件更新ですがデータ量が多い場合は全件更新が難しくなるため増分・差分更新を検討する必要も出てきます。
ただし増分・差分更新は実装が複雑になるため、まずは全件更新でシンプルに作り必要に応じて改善するアプローチを取るほうが無難です。
現代ではデータの保存・処理コストは非常に安いので実装が複雑になることのデメリットの回避を優先したほうがよいケースは多いでしょう。

数時間に一度

日次よりも高い頻度で更新したいがリアルタイムだと工数が高すぎるという場合にとる選択肢です。
ログデータのような量が多く変化を素早く検知したいようなケースです。
もしくは日次だとデータ量が多くなるため分割したいという場合です。
数時間おきに更新するときは同時に増分・差分更新が要件となることが増えます。
差分を検知して変更があった分だけを取得する設計が取れるか検討しましょう。

増分・差分更新が求められがちな理由はいくつかあります。
数時間ごとに更新したいデータはログデータのようにデータ量が多く変更よりも追記が多いデータであるため増分・差分更新が要件になりがちです。
そうでなくとも数時間ごとに実行すると日次の数倍の処理量になるためさすがにコストが無視できない状況になってきます。
合わせてAPIの実行頻度が増えるため毎回全件更新するとAPIのレートリミットに引っかかるリスクも高まります。
このような理由の組み合わせから増分・差分更新になりやすくなります。
もちろん全件更新で要件として十分なのであればそのほうが望ましいことは言うまでもありません。

注意点として、増分・差分更新の実装には「どのレコードがいつ変更されたか」を追うことが必須です。
そのためのタイムスタンプや連番IDがデータソース側に存在することが前提になります。
これが整備されていない場合は差分の検知自体が難しくなるためデータソースの特性を事前に確認することが重要です。

即時〜数分のリアルタイム連携

リアルタイム連携はデータソースの変更が即時もしくは数分程度の遅延で反映されるような設計です。
ユーザーの行動ログデータや広告データなどデータ量が非常に多く、同時に変化を検知したいという場面で求められることが多いです。
リアルタイム連携は更新頻度としては理想ではありますが一方で他の更新頻度に比べて実装・運用コストが高くなります。

リアルタイム連携には大きく2つのアプローチがあります。
一つはデータソース側で変更が発生した時点でイベントとして通知を受け取るイベント駆動型で、もう一つは数分おきに差分だけを取得するミニバッチ形式です。
どちらも「変更をほぼリアルタイムで検知して取り込む」という点では共通しており日次のバッチ処理とは設計の考え方が大きく異なります。
どちらのアプローチが現実的かはデータソースの特性やAPIなどのインターフェイスによって変わります。

リアルタイムにデータを連携しようとすると要求される技術的な難易度が一気に上がります。
単純なAPI連携で全件更新するバッチ処理に比べると差分の検知に加えてリトライ設計や運用の監視など考えるべき要素が増えるためです。
障害発生時も全件更新であれば再度実行すれば簡単に復旧することが可能ですがリアルタイム連携の場合はどこまでデータが取れているのか確認する必要があるなど復旧のコストと難易度が高くなります。
一方で、リアルタイム連携が求められやすいデータソースは公式や外部SaaSにリアルタイム連携のコネクタが用意されていることもあるのでその場合は比較的実現しやすくなります。

難易度と工数を考えるとリアルタイム連携という選択肢は公式や外部SaaSのコネクタがある場合はともかく自分たちで実装する場合は本当に必要なときだけ選ぶべきです。
分析する側としては可能な限り遅延の少ないデータの更新を求めてしまいがちですがリアルタイムで連携が必要なケースというのは実のところそこまで多くありません。
大概の分析は日次更新で問題ないことが多く、更新頻度を高めるにしても数時間ごとの更新で十分なケースがほとんどです。
まずは日次の全件更新で実装してみて足りなければ数時間ごとに更新頻度を増やし、それでもリアルタイム連携が必要かを検討するのがベターでしょう。

データ量

1日あたりに処理するデータ量も技術選定を左右する重要な軸です。

データ量が多くなるほど設計上の制約が増えます。
たとえば、処理時間が長くなれば夜間バッチが翌朝までに終わらないという問題が生じます。
他にもメモリに乗りきらないデータはそのまま読み込もうとするとエラーになるため分割処理の仕組みが必要になります。
データ量が非常に大きくなるとそもそもバッチ処理の枠組みでは対応しきれなくなりスループットを重視した技術の選択が求められるようになります。

また現時点のデータ量だけで判断するのは危険です。
分析のためには過去のデータも蓄積していく必要があるため雪だるま式にデータ量は増えていきます。
更に事業が成長するにつれて扱うデータ量は加速的に増えていきます。
今は問題なく動いていても1〜2年後に設計が破綻するということは珍しくないため将来のデータ量を見越した設計が重要です。

少量（数GB）

数千〜数万件程度のデータで商品などのマスターデータや小規模なプロダクトのデータなどがこれに当たります。
この程度のデータ量であれば処理時間も短くデータ全体がメモリに乗りきるためツール側の制約を意識せずに設計できます。
そのためデータ量が技術選定の制約になることはほとんどありません。

全件更新が素直に機能するサイズです。
差分検知などの最適化を行わず毎回全件を取得してそのまま上書きするという設計がそのまま成り立ちます。
APIを1回〜数回呼び出すだけで全データを取得でき処理時間も数秒〜数分程度で完了します。
分割処理を意識する必要も少なく実装がシンプルに保てます。

差分管理のロジックが不要になることは設計上の大きなメリットです。
「どのレコードがいつ変更されたか」を追う必要がないため実装コードが少なくなりバグも入りにくくなります。
データソース側の仕様が変わったときのスキーマ変更への追従も容易で長期的なメンテナンスコストが低く抑えられます。
データ量が許す限り全件更新を選ぶのが最もシンプルで堅牢な設計であり増分・差分更新は本当に必要になったときに初めて検討すれば十分です。

中程度（数十〜数百GB）

それなりの規模のサービスのプロダクトのデータやトランザクションデータ、行動ログなどがこれに当たります。
このサイズになるとデータ量が技術選定に影響を与える要因として浮上してきます。

まず全件取得するたびにメモリに乗りきらないケースが出てきます。
大きなメモリを持ったインスタンスなどももちろんありますが実行の安定性や時間を考えると現実的な選択肢とは言い難いでしょう。
その場合はページネーションを使ってAPIを複数回呼び出しながら分割して取得するような設計が必要になります。

データ量増加に伴う処理時間の問題も無視できなくなってきます。
数GBのうちは数分で終わっていた処理が数十から数百GBになると30分〜1時間またはそれ以上かかることもあります。
これが1つや2つであれば良いですが実際はこのレベルの大きな処理を組み合わせて実行スケジュールを管理する必要があり、これは簡単ではありません。
更に処理時間が長くなるとネットワークの寸断や一時的なAPIエラーによる失敗のリスクも高まるためリトライの仕組みも考慮に入れることになります。

このサイズになると増分・差分更新を検討する価値も出てきます。
毎回全件を取得するのではなく前回取得以降に更新されたデータだけを取得する設計にすることで処理時間とAPIへの負荷を大幅に削減できます。
ただし差分更新の実装は複雑になるためまず全件更新で動くものを作ってから処理時間が問題になった段階で差分更新に切り替えるというアプローチが現実的です。

大量（数TB以上）

大規模なアクセスログ、IoTセンサーのデータ、ソーシャルメディアの投稿データなどがこれに当たります。
このサイズになるとデータ量そのものが技術選定の重要な要因になります。
単純なバッチ処理では処理時間や安定性の面で対応しきれなくなりデータをさばけるかどうかがまず技術選定の基準になります。

全件更新はほぼ現実的ではありません。
夜間に処理を回しても翌朝までに終わらない、処理の途中でメモリやディスクが枯渇して失敗するといった問題が起きます。
このサイズになると差分更新は必須となりデータを並列処理できるアーキテクチャが求められます。
処理の負荷を分散するためリアルタイムな連携も視野に入ります。

障害時の対応設計も重要になります。
数TBの処理が途中で失敗した場合にどこから再開するかというリカバリー設計がないと最初からやり直すのは現実的ではありません。
処理をチェックポイントで区切って途中から再開できる仕組みや処理の冪等性を担保した設計が必要になります。
このサイズのデータを扱う場合は専門知識が求められることが多くデータエンジニアの関与が不可欠です。

コスト

コストは実装コスト・運用コスト・障害対応コストの3つに分けて考えます。
技術選定の場面ではツールのライセンス料や計算リソース代といった目に見えやすいコストに注目しがちですが実際にはエンジニアの工数が最も大きなコスト要因になりがちです。
原則としてシンプルな設計を選ぶほど初期の実装コストは低く抑えられます。

運用や障害対応のコストはデータソースの数に比例して雪だるま式に増加します。
そのためデータソースの数が見込まれるときは特にこれらのコストをなるべく下げるように心がける必要があるでしょう。
そうしなければいつの間にか運用で人手が払底し新たな実装ができなくなるような状況になってしまいます。

実装コスト

データの自動取り込み・更新するシステムを動かし始めるまでに必要なコストです。
手動で更新すればほぼゼロですが自動化するとなるとエンジニアが必要になり、その工数は求めるものに応じて変化します。

たとえば全件更新はAPIを呼び出してデータを保存するだけなので実装はシンプルで比較的工数は少なめになります。
増分更新になると差分を検知するロジックや前回の取得状態を管理する仕組みが必要になりその仕様の整理と実装に工数が増えます。
リアルタイム連携はさらにその上にリトライや監視の仕組みが加わるため実装コストは段違いに高くなります。

加えて、データの取り込みについて要件整理に時間がかかることも忘れてはいけません。
エンジニアが手を動かしてコードを書くことに作業時間がかかることはイメージしやすいですが、実際のところ実装と同じかそれ以上に要件整理に時間がかかります。
データソースの仕様の調査だけでなく、どのようにデータが入力されているのか現場のオペレーションを確認したり、分析の用途に不足がないか検討するなどの作業が発生します。
これはエンジニアが一人でやれることではなくステークホルダーへ確認・調整する必要があるため思っている以上に時間が必要です。

運用コスト

自動化されたデータ取り込みの仕組みを動かし続けるためにかかるコストとしてわかりやすいものはまず計算リソース代やツールのライセンス料があります。
クラウドサービスやSaaSのETLツールは処理するデータ量や実行回数に応じて従量課金されるものが多くデータ量が増えるにつれてコストも増加します。
BIツールは権限ごとのID単位で課金されるので将来的に利用するユーザーや必要な権限を整理して試算する必要があるでしょう。
現時点の情報だけで試算すると将来的に予算を大きく超えるということが起きるため設計の段階で将来を見越したコスト試算を行っておくことが大切です。

さらに、保守・運用のエンジニアコストも忘れずに見ておく必要があります。
パイプラインを日々監視し問題が起きたときに対応するための工数はデータソースの数と設計の複雑さに比例して大きくなります。

特に見落とされがちなのがデータソース側の仕様変更への対応コストです。
ほとんどの場合でAPIの仕様やスキーマが変わるたびに改修が必要になります。
この改修コストは設計の複雑さによって大きく変わります。
全件更新に比べると差分更新やリアルタイム連携は対応コストが増えることになります。
データを取り込む処理はなるべくシンプルに保つことが仕様変更への追従コストを下げるうえで重要です。

障害対応コスト

パイプラインが止まったときの調査・修復・再実行にかかるコストです。
全件更新であればやり直しは「再度全件取得して上書き」するだけなので復旧が簡単です。
ワークフローをリトライするだけで復旧することも多いでしょう。

差分更新やリアルタイム連携は「どこから失敗したか」「欠損データはないか」「重複して取り込んでいないか」を調べる必要があり復旧の難易度が上がります。
特にリアルタイム連携はトランザクション単位で調査が必要ですし、欠損データを別途保管するような仕組みが必要になることもあり障害対応には手間がかかります。

設計が複雑になるほど障害時の調査工数は増えるため運用体制と照らし合わせて許容できる複雑さを判断することが重要です。

セキュリティとプライバシー

データを扱うにあたってセキュリティとプライバシーは重要な要件です。
これらは会社としてポリシーが決まっていることが一般的でしょう。
社内のポリシーを調査し自分たちの選択肢が使えるのか事前にすり合わせることが重要です。
設計と実装が進んでから「使いたいツールが社内ポリシーで使えないので大きな変更が必要になった」といった悲劇を産まないようにしましょう。

インフラ（データの保管場所とネットワーク）

社外のサービスにデータや認証情報を置くことが許容されるかどうかは最初に確認すべき点です。
情報セキュリティのポリシーはIT部門や法務・コンプライアンス部門が管轄していることが多くデータエンジニアリングチームの裁量で動かせる話ではないため選択肢の検討を始める前に確認しておく必要があります。
特に問題になりやすいのはデータの保管場所や分析基盤そのもの、そしてETLツールです。

まず、データを保管するストレージや分析基盤そのものについての確認が必要です。
BigQueryのようなパブリッククラウドのサービスは多くの企業で広く使われており適切な設定をすれば高いセキュリティ水準を確保できます。
しかし、社内規則などでクラウドサービス自体が禁止されている場合はオンプレミスの構成を選ぶことになり、運用コストや実装の工数は大幅に増えることを覚悟する必要があります。
また、クラウドの利用自体は問題がなくてもサービスがAWSにある状態でBigQueryを使いたいといったマルチクラウド構成をする場合はクラウドサービスを跨いで利用することの是非について検討する必要があります。

他にも、SaaS型のETLツールの利用を検討している場合は確認したほうがよいでしょう。
SaaS型のETLツールはデータをSaaS側の環境を経由して転送・処理する構成が多くあります。
つまりデータをベンダーのサーバ上で一時的に処理するため「社外にデータが出る」という扱いになります。
社内ポリシーによってはこのような扱いが禁止されているケースがあります。
ポリシー上これが許容されない場合はこれらのツールは選択肢から外れ自前でETLを実装するか、OSS型のETLツールを構築して社内環境に閉じた構成を取る必要があるでしょう。

個人情報・機密データの扱い

取り込むデータに個人情報や機密データが含まれる場合は技術選定やアーキテクチャに注意が必要です。
氏名・メールアドレス・電話番号・住所といった個人を特定できる情報や財務情報や医療情報・営業秘密など機密データは慎重な取り扱いが求められます。
これらのデータは個人情報保護法やGDPRといった法規制の対象になるだけでなく漏洩した場合のビジネスリスクも大きいため分析基盤に取り込む場合には適切な対応が必要です。

SaaS型のETLツールを使う場合はデータが一時的にベンダー側のサーバを経由するためベンダーのサーバ上でログなどに記録する可能性があります。
たとえばデバッグのためにエラーログに生のデータが書き込まれるケースや一時的なステージング領域に保存されるケースなどがありえます。
ベンダーのインフラ上に個人情報や機密情報が残ることが法規制や社内ポリシー上許容されない場合はSaaSツールの採用は慎重になる必要があるでしょう。
個人情報や機密情報を含むデータソースだけ自前の実装に切り分けてSaaSツールと組み合わせるという設計を取るケースもありますがパイプラインの構成が複雑になるためトレードオフを考慮する必要があります。

マスキングや匿名化をどのタイミング・どのツールで行うかという問いも技術選定に影響します。
データを取り込む処理の中で個人情報や機密情報をマスキングしてから分析基盤に保存するのか、それとも生データをそのまま取り込んでから分析基盤側で制御するのかによって必要な機能と設計が変わります。
SaaSのETLツールにマスキング機能が備わっており要件として十分であればそれを活用できますが対応していない場合は変換処理を自前で実装する工数が必要です。
「そもそも分析に不要なカラムは取り込まない」という判断が最もシンプルなリスク低減策であり最初にデータの範囲を絞っておくことで後続の設計がシンプルになります。

よくある検討のパターン

ここまでさまざまな技術選定をおこなうときのさまざまな観点を紹介しました。
考えることが多いように思えるかもしれませんが、実際のところすべてを網羅的に検討する必要はありません。
筆者の経験から、現場でどのように選択肢を絞っていくのかよくある流れを紹介します。

1. 動かせない前提条件を確認する

まず最初に後から覆せない制約を洗い出しておきます。
技術的な検討を始める前にこのステップを踏まないと、実装が進んだ後で「そのツールはポリシー上使えない」「そのデータは社外に出せない」という事態になりかねません。
このような手戻りのコストは大きいため最初に確認する習慣が重要です。

セキュリティとプライバシーに関する制約が代表的です。
たとえば社外へのデータ持ち出しが禁止されている場合はSaaS型のETLツールが選択肢から外れます。
取り込むデータに個人情報や機密情報が含まれている場合はベンダーのサーバ上での処理が許容されるかどうかを確認しなければなりません。
これらは情報システム部門や法務・コンプライアンス部門が判断する領域であり技術チームだけで決められる話ではないため早めに関係者を巻き込むことが欠かせません。

ビジネス側の制約としてデータ鮮度の要件も確認しておきます。
「翌朝9時までに前日のデータが見えれば十分」なのか「数時間以内に反映されていないと困る」なのかによって技術の選択肢が大きく変わります。
技術的な問題を考えなければ分析側としてはデータの更新頻度は高ければ高いほどよいものです。
現場の担当者が「リアルタイムな更新が必要」と言っている場合でも実際の意思決定のサイクルを確認するとそこまでの鮮度は不要だったというケースは少なくありません。
また「リアルタイム連携が必要なのは一部の分析」で「まずは全件更新があるだけでも大きなメリットがある」という場合は素早く日次更新を実装しあとからリアルタイム連携へと改修するという選択肢もあります。

実務上どの程度の頻度であれば問題がないのか、そして技術上どの程度までであれば効率よく実装・運用ができるのかすり合わせることが必要です。
前提条件を固める段階でビジネス上の真の要件を把握しておくことが素早い実装と意思決定の改善に繋がります。

2. 公式コネクタ・SaaSツールを確認する

前提条件をクリアできたらデータソースの公式コネクタが使えるかを確認します。
これが使える場合は技術選定としてほぼ決まりです。
ほかの選択肢と比較検討するまでもなく最優先で採用します。

コネクタを使う最大のメリットは実装工数の削減です。
APIの認証処理やページネーション・スキーマの変換といった定型的な作業がすでに実装されているため自前でゼロから実装する場合に比べて初期の開発工数が大幅に減ります。
加えてデータソース側でAPIの仕様が変わったときにベンダーがコネクタを更新してくれることが多く長期的な保守コストも低く抑えられます。

公式のコネクタがなくてもSaaS型のETLツール上にコネクタが用意されているかを確認します。
ツール上のコネクタがあれば利用を検討しましょう。
コネクタが用意されていてもすべての機能要件を満たすとは限りません。
対応している更新頻度・データの取得範囲・フィルタリング条件などの要件と合致するか確認しておく必要があります。
また、前ステップで確認したセキュリティ要件をここで照らし合わせてSaaS型ツールの利用自体が許容されるかどうかを再確認します。

3. 日次全件更新を検討する

コネクタが使えない場合は自前でAPIを呼び出す実装が必要になります。
このとき最初に検討するのが日次の全件更新です。
1日1回スケジュール実行してデータをすべて取得して上書きするというシンプルな設計を出発点にします。

全件更新を最初に選ぶ理由は設計のシンプルさです。
差分更新では「前回の取得以降に何が変わったか」を追跡する仕組みが必要になりますが全件更新にはそれが不要です。
実装コードが少なくなりバグが入りにくく障害時の復旧も「再実行するだけ」で済みます。
データ量が数GB~数十GBの範囲に収まるのであれば全件更新でほぼ問題は起きません。
まず動くものを作ることを優先して全件更新から始めるのが堅実な進め方です。

数百GB以上になると全件更新の処理時間が長くなりAPIのレートリミットに引っかかるリスクが出てきます。
それでもまずは全件更新で試してみて実際に問題になったときに初めて差分更新を検討するというアプローチが現実的です。
いきなり差分更新の設計に飛びつくと不要な複雑さを抱えることになりかねません。

逆に、APIすら用意されていない場合は自動更新が非常に難しくなります。
その場合は手動で更新するしかないというかもしれません。
その場合は分析上の更新頻度や優先度などの要求と運用負荷のバランスが必要です。
なるべくオペレーションが増えないように、ミスが起きないように運用を整理します。
場合によっては日次ではなく週次や月次へ頻度を落とすことも検討しましょう。

なお、APIが用意されていないからと言ってスクレイピングでデータを行うのは原則やめたほうがよいでしょう。
スクレイピングは規約などで禁止されていることが少なくないためです。
もし規約上問題なかったとしてもサービス側の仕様変更に弱いため運用コストが高くなりがちです。
スクレイピングの採用は慎重に検討しましょう。

4. 増分・差分更新やリアルタイム連携を検討する

日次の全件更新では要件が満たせないと判断できた場合に初めてこの選択肢に進みます。
「満たせない」という判断の根拠は主に2つです。
データ量が非常に多く全件取得に現実的でない時間がかかること、もしくはビジネス上の鮮度要件が日次では不足することです。

増分・差分更新を採用するにはデータソース側の仕様が対応していることが前提になります。
いつ更新されたデータか判別するためのタイムスタンプやIDがデータソースに存在していなければ差分の検知自体ができません。
採用前にデータソースの仕様を確認して条件が満たされているかを確かめる必要があります。

リアルタイム連携は本当に必要な場合に限って選ぶべき選択肢です。
技術的な難易度が上がり実装・運用コストも高くなります。
障害時の影響範囲も広くなるため設計の複雑さに見合うだけのビジネス上の価値があるかを慎重に判断することが重要です。
分析用途ではリアルタイムに連携することのメリットが見えにくいケースも多くあります。
実際には数時間ごとのバッチ処理で十分というケースも少なくありません。
リアルタイム連携がどうしても必要なユースケースを確認することが判断の出発点になります。

増分・差分更新もリアルタイム連携も最初から採用するよりも日次の全件更新で動かし始めてから段階的に高度化するアプローチのほうが多くの場合でうまくいきます。
実際に運用してみると「日次で十分だった」「思ったほどデータ量が増えなかった」ということも多く、最初から過剰な設計を作り込まずに済みます。

まとめ

データ取得の技術選定について一般化できそうな範囲で判断の基準を整理しました。
この領域は選択肢の多さゆえに迷いやすいですが判断の順序を決めておくと道筋が見えやすくなります。

全体としてシンプルで簡単な実装と設計を心がけることが重要です。
シンプルな設計から始めることは妥協ではなく合理的な選択だからです。
複雑な仕組みは必要になったときに追加できますが最初から複雑な設計を作り込むと実装・運用・障害対応のすべてのコストが上がります。
まず動くものを作り実際の運用を通じて本当に必要かを判断していくサイクルが現実的な改善につながります。

本記事がデータ分析基盤について技術選定をする方々への助けになれば幸いです。