データは第二の石油
「うちもデータ利活用するぞ」という上司の一言でデータ分析を任されたシステム部の人を想定して、
本記事では「どうデータを持つか」「実際に構築するモノが何か」を考えてみたいと思います。
「データを使って何かするのはなんとなく分かるけど、何を用意したらいいの？」
という疑問解決の一助となればと思います。
注意書き
個人の意見です。経験不足はご指摘ください。
データはどこにあるのか
もちろん、あなたの会社の屋台骨となるシステムにデータは眠っています。
顧客の購買履歴であったり、ユーザの属性情報であったり。
これを都度、本番サーバルームに入って参照できるならそれでも・・・色々とよくないですよね。
データをどこに保持するのか
分析ツールを直接本番データに接続するわけにはいきません。
一度データをどこかに出力して保持する必要があります。
ここでは、以下の２パターンを比較することにします。
分析作業者の作業PC
主システムに高度なAPIやcsv出力などデータ出力機能を実装して、「欲しいデータを欲しい時にダウンロードする」ケースです。
ここでは主システムのDBを、OracleやPostgreSQLなど、RDBMSの前提で話を進めます。
データ分析システム(NoSQL)
主システムから特定の形式で定期的にデータ出力し、別にデータ分析システムを構築して、そこにデータを投入して保持するケースです。
ここではjson形式とし、データ分析システムのDBはそれを扱えるNoSQLの前提で話を進めます。
※すみません、本記事では分析方法については解説しません。オススメは「Elastic Stack」というツールです。興味があれば調べてみてください。
メリデメ比較
有利な方が○です。
|比較観点|分析作業者の作業PC|データ解析システム(NoSQL)|
|:-----:|-----|-----|-----|
|データの自由度|○：取得するデータを選択できるなど、提供API/csv機能を高度化すれば好きなデータをいつでも引っこ抜ける|△：扱えるデータは定義した提供API機能のインターフェースの範囲に限られる|
|分析作業の自由度|△：膨大な長期間のデータを保持し続けられない。また未取得のデータが必要になるたび、当該期間の当該データを本番サーバから都度引っこ抜く必要がある。データを引っこ抜く処理(SQL)が主システムに負荷を与える|○：予め解析対象となりそうなデータを全て引っこ抜くことで、必要なときに迅速に分析作業が行える。分析作業が主システムに影響を与えない|
|セキュリティ対策|△：引っこ抜けるデータに制限(APIに厳密なセキュリティ対策)をしないと引っこ抜いたデータをSR(セキュリティルーム)でしか扱えない|○：APIでセキュリティレベルをハンドリングすれば引っこ抜いたデータを執務室で扱える|
|主システム改修コスト|△：高度なデータ出力機能を主システムに手を加えて実装する必要があるためリリース調整や障害リスクをハンドリングをする必要がある|○：定義したインターフェースだけ開発する|
|データ分析システムの開発コスト|○：不要|×：開発が必要|
|データ分析環境の維持コスト|○：作業PCがあれば分析可能|×：物理または仮想サーバを構築して維持する必要がある|
比べてみていかがでしょうか。私はNoSQL派ですが、所変われば品変わる（？）、どちらを選ぶかは環境次第と思います。
ご参考の一つにでもなれば、と思います。