DWHは統計的文脈のDBな気がした

この記事は2017年08月09日に公開されました。 情報が古い可能性があります。

こんにちは、殿内(@tonoccho)です

今期の学校では、データサイエンスとDWHを学びます。統計とエンジニアリングを学んでおけばあとはビジネスの視点さえあればどうにかなる、素晴らしいですね。
さて、DWHについては(統計についても)全く明るくないばかりか、そういえばDBも明るくない自分としては、DWHはいわゆる巨大なデータベースというふうにしか捉えていませんでした。ですが、講義資料を読んでいくうちに「DBとしてDWHを捉えるとドツボだな」というのが感想でした。
 

データ自体はDBに格納

このポイントだけ見ていると、単なるログDBだろう、という感じになるかもしれませんが、このデータが後々解析されてビジネスに役立てられる、という文脈で見るならば、DBの設計、例えば、保存したあとは解析され、レポートとして出力されるから、SELECTとINSERTのパフォーマンスを上げるにはどうするか、とか、どういうビューが必要か、とか、そういうのが必要です。
そういうわけで「ERDとしての美しさ」<「解析時の効率」という考えにならないと行けなさそうです。

データはきちんと選別される

DWHに蓄積されるデータは、きちんと選別されないとダメです。何でもかんでも放り込んだところで、ただ日々ストレージを圧迫していくだけのデータならばそれは単なるノイズです。
また、「この情報を取ろう」とだけ決めてしまうと、例えば「取ると決めたが解析の上で意味をなさないもの」というのも出てくるかもしれません。例えば、「販売動向を取得する」というような場合に、「年に10個も売れない商品の販売動向」を取得するのか、「毎日1000個売れる商品の販売動向」を取得するのか、というのも大事です。

既存システムを変える?変えない?

DWHを導入するにあたり、DWHにデータを供給する既存のシステムをどうしましょうか、というのがありますね。例えば、ログの出し方とか、そう行ったものです。
既存のシステムも柔軟に変えられるなら変えても良いかもしれませんが、うまく動いているシステムはできるだけ変えない方向で考えた方が予算の面からも、スコープの面からもいいような気がしますので、個人的には「変えない」方向で考えて、「ETLで頑張る」のが良いような気もします。既存システムが本来出すべき情報を全く出していなかった、というなら出すようにした方がいいんでしょうけど。

データを貯めるだけでなくアウトプットも大事

DWHに蓄積されたデータは、日々ビジネスに役立つレポートとしてアウトプットされます。そして、そのアウトプットされるデータは、「その場限りでいいのか」とか「どのレベルまで詳細化するのか」とかとにかく数多あるビジネス要件次第でいくらでも変わってきます、
なので、アウトプットをどのようにするか、データマートを作るのはいいが、どうやってドリルダウンするか、最終的なレポートをどう出力するか、データマートはインメモリでいいのか、別途ストレージを用意するのか、ということが大事だなという感想です。
 

要件重要だが柔軟性も重要

DWHをやるにあたっては、ビジネス要件がとても大事ですが、「DWHそのものの要件」と「ビジネス要件」は分けて考えた方が良さそうです。DWHそのものの要件はインプットの要件、ビジネス要件はアウトプットの要件だと思ったからです。
また、どんなデータも無差別に入れていけばDWHでできることは増えていくでしょうが、そういうわけにも行かなそうです。そういうわけで、この辺の変更に対する柔軟性は、ETLツールで吸収する形になるのでしょう。
また、データマートはアウトプットの仕組みもきちんと考えておかないと、ビジネス要件の変更についていくのも大変そうです。データマートを新規に追加するのか、とか、ある程度の要件をカバーできるデータマートを用意しておいて、ダッシュボード側で発行されるクエリで頑張るのかとか、その辺も決めた方がいいのかもしれませんね。

DWHのDBまでは仕方ない

DWHは、ビジネスの競争力に直結するものであるがゆえに、いかに迅速に導入して利用開始できるか、というのが鍵になりそうです。なので、DWHのDBまではさっさと用意してMSのPower BIと繋いでしまう、とかそう行ったことから始めてもいいのかもしれませんね。
 

ニュージーランドの最新記事

移住の最新記事

勉強の最新記事