Hadoopが出てきてから10年，ビッグデータという言葉が流行り始めてからでも5年以上が経ち，2016年現在では，Hadoopエコシステムを使ったデータ活用が当たり前のものとしてあります．とはいえ巷に出回っているビッグデータ活用事例というのは，綺麗な上澄みだけをすくい取っていたり，リリースしたてのピカピカのときに発表されていたり，というのが大半で，それが結構個人的に気に食わなかったりします．
ビッグデータが当たり前のものになっている現在においては，単に作っただけで価値があるというフェーズは過ぎ去っていて，継続的に運用しながら価値を生み出し続けることが，非常に重要な問題だと思います．特にビッグデータ界隈はミドルウェアやツールの陳腐化が激しく，またビジネス自体の変化速度も過去と比べてどんどん速くなっているわけで，そういった変化に対応していくためには，また別のスキルが必要とされるのではないでしょうか．このあたりについては，今年のHadoop conference JapanでされていたClouderaによるETLの概説，ドワンゴやDeNAの事例はまさにそういった問題を扱っています．みんな対外発表では綺麗なところを見せたいわけで，なかなかこうした実情が共有されることは少ないように感じています．
www.slideshare.net
www.slideshare.net
www.slideshare.net
でもこうした問題は，ビッグデータにより初めて起こったものではありません．データウェアハウス，ETLという言葉で，エンタープライズ業界では何十年も前から取り組まれており，ノウハウが積み上げられている分野でもあります*1．ビッグデータ活用自体がある程度成熟してきた今こそ，改めて長期的な運用を想定した，ETLの仕組み構築が注目されるべき時期に来ているのではないでしょうか*2．
データウェアハウスとETL
と，ちょっと挑発的な書き出しで始めましたが，要するに最近ラルフ・キンボールのThe Data Warehouse Toolkitを読んでいて，非常に感銘を受けたというお話です．このキンボール先生，スタースキーマで有名なディメンジョナルモデルを提唱した人で，データウェアハウスの分野ではビル・インモンと並び最も有名な人の一人です．このThe Data Warehouse Toolkitは第3版まで出ていて，初版は日本語訳も出版されています*3．私は両方読んだんですが，第3版のほうがはるかに体系化されて，様々なノウハウが整理されているので，英語に苦がなければ原書で読むことをお勧めします．
The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling
- 作者: Ralph Kimball,Margy Ross
- 出版社/メーカー: Wiley
- 発売日: 2013/07/01
- メディア: ペーパーバック
- この商品を含むブログを見る
- 作者: ラルフキンボール,Ralph Kimball,藤本康秀,岡田和美,下平学,伊藤磨瑳也,小畑喜一
- 出版社/メーカー: 日経BP社
- 発売日: 1998/05/14
- メディア: 単行本
- 購入: 2人 クリック: 68回
- この商品を含むブログ (8件) を見る
さて，では具体的な話に進みたいと思います．まずディメンジョナルモデルとは，スタースキーマとはなんぞや，というお話ですが，このあたりの概説については id:EulerDijkstra さんの以下の記事が非常にわかりやすいので，一読をお勧めします．
ぶっちゃけビッグデータ時代になっても，基本的なデータ設計というのはディメンジョナルモデルから大きく外れるものではありません．よくあるウェブサイトのアクセスログベースのユーザアクセス動向の分析についても，生のhttpdログをHDFSに突っ込んで，それを加工してユーザアクセスファクトテーブルを作ります．次にユーザマスタ，商品マスタを業務系のDBからSqoopで吸い出してきて，適当に加工整形してユーザディメンジョン，商品ディメンジョンテーブルを作ります．あとは，Hiveクエリでも書いてユーザセグメント毎の商品購入動向を集計するわけです．簡単ですね．
長期的な運用を前提とした仕組みづくり
ビッグデータ活用，みたいなプロジェクトが立ち上がる際，うちの会社でもログ解析ができるようにしたい，そこから何か有用な知見が得られるんじゃないか，みたいなフワッとした要件で始まることって割とあると思うんですけれども，これって結構つらい話です．キンボール先生が本の中で再三繰り返しているのは，データウェアハウス構築においては，ビジネス側の要件が一番大事で，それを達成するための仕組みづくりをしなければいけない，ということです．Hadoopがいくらコモディティサーバ使えばいいっていっても，またクラウドを使えば簡単に構築できるっていっても，それなりのデータ量でそれなりの分析をしようと思ったら，すぐに結構な金額が吹っ飛んでいきますし，費用対効果を考えないで立ち上げると，間違いなく長期的にドツボにはまっていきます．また，誰も使わないデータウェアハウスを作り続けることほど，エンジニアとして悲しいこともないですしね．
そんなわけで，プロジェクトをうまく進めるためには，必ずエンジニアサイドだけでなく，ビジネスサイドのキーパーソンを巻き込んで進めましょう，という話になります．その上で，ビジネスサイドの人たちが分析しやすいラベルをつけたディメンジョンテーブルを構築し，入り組んだ集計処理はあらかじめ行ったビューを作っておく，といった配慮が求められます．というのは，ややこしい集計作業をビジネスサイドの人が毎回正しく実行してくれると期待するのは，基本的に間違っていて，もし複数人の集計結果が異なっていたとしたら，問い合わせがくる先はデータウェアハウスの開発マネージャーのところだからです．そして正しい数字を担保しないと，せっかくデータウェアハウスを作っても，結局誰も使ってくれなくなってしまいます．
また，あらゆる基準は時とともに変化することを前提として，あらかじめ設計しておかなければいけません．特にディメンジョンテーブルについて，時間の経過とともにカラムの内容がゆるやかに変化していきます．これをキンボール先生はSlowly Changeng Dimension (SCD) と呼んで，本の中でも繰り返しその対処法を説明しています．例えばECサービスにおけるユーザ情報なんかがその典型で，ユーザの登録住所や電話番号なんて情報は，そう頻繁に変わるわけではないですが，数年とかのスパンではそれなりの変更があると考えられます．これをキチッとトレースできるようにしておかないと，過去に遡った分析を行うことができなくなります．
本の中ではこの問題に対して以下のような基本の4種類の対応法を示しています*4．
1. 上書きする
基本的に変更がなく，過去の情報を参照する必要がないような場合には，単純に上書きしてしまいます．
2. 新しい行を加える
これがベーシックかつ一番よく用いられる方法で，値が変わった場合には，別の行を追加します．ディメンジョンにはあらかじめ追加日と失効日の2カラムを持っておき，値が変わった場合に，既存の行に失効日を追記することで，その行が有効な期間を特定できるようにします．また最新フラグを示すカラムを追加しておくことで，簡単に最新状態の行だけを絞り込むことができるようにしておくと便利です．
3. 新しい属性を加える
最新の値と，その1個前の値を比べたい場合に，この手法を使います．やり方は簡単で，現在の値カラムと，直前の値カラムの2つをあらかじめ用意しておき，値が変更された場合には，既存の行を書き換えて対応します．
4. ミニディメンジョンを用いる
これは頻繁に変更が起こる場合に用いられます．ディメンジョンテーブルは，マスタとしてファクトテーブルと結合されるので，あまりにこのデータサイズが大きいと，パフォーマンスに影響が出ます．そのような場合には，変化する頻度の高いカラムだけを抜き出して，それら全ての組合せを網羅したディメンジョンテーブルをあらかじめ用意しておきます．それとは別に，変化する頻度の低いカラムは，従来のディメンジョンテーブルにまとめておきます．変更頻度によりディメンジョンテーブルをあらかじめ分割しておくことで，保守性が高い仕組みが構築できます．
またこの場合の結合キーですが，キンボール先生は，何の意味もない連番の数字か，ランダムハッシュを用いることを強く推奨しています．例えば商品ディメンジョンで考えるなら，もともと商品IDがあるのが普通なので，これを結合キーに使ってしまえば良いと考えがちですが，これだと商品IDに何がしかの変更が加わった際に，一気に窮地に陥ります．この手のナチュラルキーは，直感的である一方，サービスの統合やID体系の見直しといった，長期間の運用でたまに起こるイベントへの耐久性が皆無に近いわけです*5．
これら以外にも，ETLで必要とされるコンポーネントを34に分類して，その概要を述べていたり，典型的なシステム構成や事例に基づいたデータスキーマ，またデータウェアハウス構築プロジェクトの進め方といった多様な観点について述べられています．本のメイン部分は，Hadoop以前の時代に書かれているため，特にパフォーマンス的な部分では古いなーという部分があります．ただそれって，従来であれば3ヶ月ぶんしか扱えなかったデータが3年分扱えるようになった*6とか，集計軸を削減していたのがしなくてよくなったとかいう程度の違いしかなくて，データサイズが増える段階のどこかで，同じ問題にぶち当たります．いくらHadoopがスケールアウトするといっても，会社の予算は有限なので，サーバを無尽蔵に増やせるわけはありません．費用対効果のトレードオフを考えて，できる限りチューニングを行う必要があることには変わりがありません．
また，Hadoopで非構造化した生データを，加工整形する前に扱うことができるという点についても，使い所は絞らないといけないです．システム関連系では，生のデータをストリーム処理したり，ミニバッチ的に処理したりで，うまく活用してレコメンドだのに活かしたり，というのはあり得る使い方ですけど，それはあくまでデータサーエンティストやデータマイニングエンジニアみたいな，一部の専門家たちに限定されるべきです．特にビジネスサイドの人たちが触るデータについては，時間をかけて加工整形して，元データの変更部分をETLで吸収する必要があることに変わりはないし，そうしないと正しいデータ活用，データに基づいた意思決定にはつながっていかないんじゃないかなーと思っています．
そんなこんなで，とりとめなくETLについて書いてきましたが，The Data Warehouse Toolkitはとても良い本なので，みなさん読みましょう，ということが言いたかっただけのエントリでした．
*1:ただエンタープライズのこうしたノウハウって，あんまり世の中にシェアされることがないようには思っています．まぁB2Bの受託開発がメインだと，なかなかノウハウをシェアするメリットもありませんからね...
*2:ちなみにこのあたり，Treasure Dataとかのマネージドなデータウェアハウスサービスを使っていれば構築運用部分の悩みは解消されるにせよ，どうやってデータを持つ点は使う側が考えなければいけない以上，決してETLが必要ないわけではないです．
*3:すでに絶版ですが，Amazonなんかで中古を買うことはできます．表紙の古臭さが，時代の流れを感じさせますね．
*4:ほんとうは，それらを組み合わせた手法が3つ紹介されており，合計7つだったりはします
*5:このあたり，私自身も実務で実感しています．
*6:つまり，3年以上のデータを扱おうと思った場合には，結局パフォーマンス的な問題が現れてくる