ETL | Think and Write

データ分析基盤を構築するとき避けて通れないのが「どうやってデータを取得するか」という問題です。 SaaSのETLツールを使うのか、APIを自前で叩くのか、手動でCSVを取り込むのか。データを取得する手法は選択肢が多く状況に応じて最適な手法は変化します。また、技術的な問題だけではなく分析する側であるビジネス上の要求も考える必要があります。本記事では技術選定の判断基準を整理し、筆者の経験をもとに実際によくある検討のパターンを解説します。データの鮮度・更新頻度更新頻度は技術選定に最も直接的な影響を与える要素です。一般にデータを更新する頻度が上がるほど自動化の設計は複雑になります。日次であれば夜間バッチで全件更新というシンプルな仕組みで済みますが、これが数時間おきとなるとAPIのレートリミットを意識した設計が必要になるかもしれません。更にリアルタイムになれば差分検知やリトライの仕組みまで求められます。つまり更新頻度は「どの程度の仕組みを作る必要があるか」を決める起点であり実装・運用コストに直結します。逆にいえば「どれくらいの頻度でデータを更新する必要があるか」を最初に固めることで選択の幅が大きく絞り込むことができます。低頻度低頻度とは年に数回くらいの想定です。こういったデータの場合は手動で全件を更新するというケースが多くなります。データソースと分析上の要求として増分・差分をわざわざ検知する必要がないため全件更新で問題がないこと、そして頻度が低いため自動化のメリットを享受しにくいこと多いためです。更新頻度が低いデータの場合はそもそもデータの形式や用途が安定しないこともあり処理の内容を毎回検討する必要が多いことも自動化の優先度が下がる要因の1つです。自動化を選ばないケースでいうと、たとえば特定のプロジェクトや顧客で単発で発生するようなケースがあります。プロジェクトで単発的にデータが発生したり、顧客ごとにデータの形式にばらつきがあったりという状況です。このような不定期でデータの形式も完全に固まっていない場合は自動化のコストが高くなりがちです。担当者がその都度手動で取り込む運用でも十分でしょう。逆に頻度が低いとはいえデータの形式が固まっており処理が複雑という場合は自動化のメリットが上回ります。エクスポートしたデータをエクセルなどで細々と整理してからアップロードするようなプロセスが必要だとしたら手間もかかりますしミスも起きやすいので自動化が望ましいでしょう。たとえば、年に数回しか更新されないマスタデータがありながらインポートにひと手間必要という場合はこのケースに該当します。完全に自動化する必要もないので無理にワークフローに載せずにスクリプトとして保存しておくなどの対処もありえます。月次・週次月次・週次で更新する場合は全件更新するケースが多くなります。データソースの特性として月次・週次で更新するデータは何らかの作業がひととおり終わったものを保存するというケースが多く、そのため増分・差分を検知して保存するというよりも全件を保存したいことが多いからです。たとえば締め作業が終わって確定した会計データや、週次で棚卸し作業をしている在庫情報などが挙げられます。月次・週次くらいの頻度で恒常的に発生するとなると自動化による作業コストが削減できるメリットが大きくなるため多くの場合で自動化を検討します。 1つ2つくらいのデータソースであればなんとかなりますがデータ分析基盤には多くのデータソースを結合していくことになりますので自動化することを前提に設計するべきでしょう。また、作業ミスによるリスクも考慮に入れるべきです。それなりの頻度で作業することになりますから必然的にミスも発生します。作業ミスはそのままデータ品質の問題に、そして誤った意思決定へと繋がります。より確かな意思決定という観点からも週次・月次くらいの更新頻度が定常的に発生するようであれば自動化が前提という意識でいるのがよいでしょう。日次更新最も一般的な更新頻度です。毎晩にバッチ処理を走らせ朝出社したときには最新のデータが見られるようになっている、というサイクルは多くのビジネスの意思決定に十分なサイクルです。日次の更新ではデータ量がよほど大きくない限り全件を取得してそのまま更新するシンプルな設計をベースに検討します。この頻度になると自動化は原則です。毎日の作業となると手動では作業の負担が大きくなります。あわせて作業頻度が増えることでミスも起きやすくなるため担当者の業務を圧迫します。スケジュール実行で毎日自動的に動くように設計しておくことで安定した運用が実現できます。基本は全件更新ですがデータ量が多い場合は全件更新が難しくなるため増分・差分更新を検討する必要も出てきます。ただし増分・差分更新は実装が複雑になるため、まずは全件更新でシンプルに作り必要に応じて改善するアプローチを取るほうが無難です。現代ではデータの保存・処理コストは非常に安いので実装が複雑になることのデメリットの回避を優先したほうがよいケースは多いでしょう。数時間に一度日次よりも高い頻度で更新したいがリアルタイムだと工数が高すぎるという場合にとる選択肢です。ログデータのような量が多く変化を素早く検知したいようなケースです。もしくは日次だとデータ量が多くなるため分割したいという場合です。数時間おきに更新するときは同時に増分・差分更新が要件となることが増えます。差分を検知して変更があった分だけを取得する設計が取れるか検討しましょう。増分・差分更新が求められがちな理由はいくつかあります。数時間ごとに更新したいデータはログデータのようにデータ量が多く変更よりも追記が多いデータであるため増分・差分更新が要件になりがちです。そうでなくとも数時間ごとに実行すると日次の数倍の処理量になるためさすがにコストが無視できない状況になってきます。合わせてAPIの実行頻度が増えるため毎回全件更新するとAPIのレートリミットに引っかかるリスクも高まります。このような理由の組み合わせから増分・差分更新になりやすくなります。もちろん全件更新で要件として十分なのであればそのほうが望ましいことは言うまでもありません。注意点として、増分・差分更新の実装には「どのレコードがいつ変更されたか」を追うことが必須です。そのためのタイムスタンプや連番IDがデータソース側に存在することが前提になります。これが整備されていない場合は差分の検知自体が難しくなるためデータソースの特性を事前に確認することが重要です。即時〜数分のリアルタイム連携リアルタイム連携はデータソースの変更が即時もしくは数分程度の遅延で反映されるような設計です。ユーザーの行動ログデータや広告データなどデータ量が非常に多く、同時に変化を検知したいという場面で求められることが多いです。リアルタイム連携は更新頻度としては理想ではありますが一方で他の更新頻度に比べて実装・運用コストが高くなります。リアルタイム連携には大きく2つのアプローチがあります。一つはデータソース側で変更が発生した時点でイベントとして通知を受け取るイベント駆動型で、もう一つは数分おきに差分だけを取得するミニバッチ形式です。どちらも「変更をほぼリアルタイムで検知して取り込む」という点では共通しており日次のバッチ処理とは設計の考え方が大きく異なります。どちらのアプローチが現実的かはデータソースの特性やAPIなどのインターフェイスによって変わります。リアルタイムにデータを連携しようとすると要求される技術的な難易度が一気に上がります。単純なAPI連携で全件更新するバッチ処理に比べると差分の検知に加えてリトライ設計や運用の監視など考えるべき要素が増えるためです。障害発生時も全件更新であれば再度実行すれば簡単に復旧することが可能ですがリアルタイム連携の場合はどこまでデータが取れているのか確認する必要があるなど復旧のコストと難易度が高くなります。一方で、リアルタイム連携が求められやすいデータソースは公式や外部SaaSにリアルタイム連携のコネクタが用意されていることもあるのでその場合は比較的実現しやすくなります。 ...