Data Warehouse について考える:

前はなんとなく DW の ETL というのはログからゴミをとってクリーンにするくらいなのかと思っていたが、いま仕事で触ってるデータはそれより随分色々やっている。

たとえば食堂にアクセスログがあるとしたら、店に入って席について注文して飯食ってデザートは断ってチェックして帰る、コーヒーは二回足してもらった・・・という「来店」のような単位がきちんとモデル化されている。一方、素のログは個々のアクションがフラットに入っているだけである。

SQL マスターであればそういうフラットなログからモデル化されたビューを作ることはできるかもしれないが、素人が正しくやるのはかなりムリである。なのでビューなのかマテリアライズするのかはともかく組織として統一されたモデルが必要。でないとエンドユーザである機能開発者や PM ちゃんが雑なクエリを書いてデータを読み間違えたりする。

たとえばトイレをきれいにするにあたり改築前と改築後でトイレの利用頻度や滞在時間の違いを調べたい、統一さえた「来店」モデルがあれば、そこにしかるべき形でトイレ情報を足すのはわりかし簡単である。つまり ETL のコードを git blame して一つ前の変更を特定し、それをインテリジェントにコピペすればよい。

クエリするときも、整備されたモデルがあれば SQL はシンプルで、PM ちゃんが適当にコピペ SQL しても大きな問題はない。一方で素のログしかないと、昔データサイエンティストにもらった SQL を適当にコピペ改変して使う、しかしその SQL は古すぎてデータバグの回避コードが抜けている、みたいなダサい失敗がおこる。

データサイエンティストから貰った SQL で素のログをクエリしていたのは(PM ちゃんではなく)何年か前の自分なわけだが、よくなかったね。ある種のレイテンシの調査が目的でカネが絡んでいなかったからいい（だから適当にやっていた）けど、やはりゴミの除去とかは必要で、正しいモデルがあってしかるべきだった。が、なかった。

その後、できるチームメイトが DW をつくってくれたのでその手の仕事はラクになった一方、今思うと採用されていたモデルはそんなに良くなかったね。だから統一モデルのを持つ良さには思いが至らなかった。最近仕事で触っている DW はモデルよくできており、なるほどなと思う。

つまり DW にはデータのクリーンアップというミクロな役割とモデル化というマクロな役割がある。自分は前者は理解していたが、後者の有り難みをわかっていなかった。

ところで勤務先の DW は protobuf-based でモデル化されており、めちゃデータがネストしている。前のチームの DW はモデルを proto にべったり寄せるのに慣れていない人がモデルした感じで、それが（相対的な）イマイチさにつながっていたのだろうな。ネストしてると JOIN とかしなくていいのでクエリ書くのもスキーマ足すのもちょうラク。

こういうフラットでない OLAP は、曖昧な記憶によれば Multidimensional OLAP というような名前で呼ばれていた気がする。こういうののモデリングって何を読めば勉強できるのだろうね。なんとなく伝統的な OLAP の教科書ではない気がするんだけれど、そうでもないのかな。

このシラバスからはこの book chapter? が参照されている。が、あまりニッチを攻めようとふつうに data warehouse / olap の data modeling の教科書を探すのがいいのだろうね。DW について勉強したい気持ちは何年かに一回やってくるので、そのうちやる気の波に乗りたい。今は心の奥に積読いたします。