今回のブログは、情報系データ基盤(DWH:DataWareHouse)の整備に当たって最初に立ちはだかるオペレーショナルデータと分析用データのセマンティクスギャップ(意味のギャップ)についてお話したい。このギャップは、小規模でシンプルな事業体ではあまり考慮する必要がないが、大規模かつ複雑な事業になればなるほど大きく、地味な話ではあるが情報系システムを構築する際はぜひとも念頭においておきたいことである。
DWHの構築に際して、物の本ではDWH格納前にクレンジング処理が必要と書かれている。そしてこの“データクレンジング”という言葉から想像するものは、ノイズを除去したり不完全なデータを整えたりすることをイメージする。しかし実際に情報系DWHの設計に携さわると、データの整理整頓だけでなくODS(オペレーショナルデータストア)のデータを、業績内容の分析やビジネス戦略の立案に使えるようにする為の様々な変換プロセスまでが必要となることがわかる。
そこでは、名寄せ作業で決定された顧客や商品の統一コードの付与をはじめ、戦略立案の為のサービス種別の付与、粒度の異なるコストの明細レベルへの配賦&付与といったようなODSには含まれない分析情報が加味されている。ちなみにマスターデータの名寄せ作業は、属性値の整頓(左詰め、(株)の位置、スペース詰めなど)が前提となり、はじめて同一かどうかの判断がなされる。そして、名寄せの結果は個別コードと統一コードの対応テーブルがその成果物となる。このように可能な限りの”クレンジング&変換”を施してはじめて、ODSのトランザクションデータは再利用たり得るものになる。図1に、そのイメージを表したので参照されたい。
ここでさらに重要な事は、これらの付加価値を付与するプロセスを繰り返し自動実行できるように、その分析情報の付与ロジックを変換マスター化しておく事である。DWHを継続運用する為には、担当者が絶えずこの分析情報付与マスター群を最新状態にメンテナンスし続ける必要がある。ちなみに図1を物理実装レベルで補足すると、リレーショナルモデルでは画面からメンテされた変換マスタによって明細レコードに新たな分析軸が付与され、スタースキーマモデルでは各種ディメンジョンテーブルの項目が画面からメンテされ、ファクトテーブルとスターJOINされることになる。さらに、変換マスタのメンテは手動で行なわれるとして、DWHを作る作業はHadoop等を用いた高速自動処理になっていたい。
さて、ここで一つの疑問が湧いてくる。図1のようなクレンジング&変換処理は果たして、どんなケースでも必要なのだろうか?たまたまODS内のデータが汚れていたからであり、そこがきちんとしていたら不要なのではないか?という疑問である。答えは否(必要)である。ODS側でどんなに高いデータ品質が保証されていても、DWHで必要とするデータと(たとえ呼び名が同じでも)意味するところが合致するケースは極めて少ない。もしもDWHの都合でデータの意味(粒度や範囲も含む)や形式を変える事態となれば、安定的な稼働を続けている基幹系システムを改修するリスクを負う事になる。データコンテキストの拡大はシステムの大幅な改修をもたらすことになるからだ。
分かり易い具体例を示そう。受注システムで扱う(取引実績のある)顧客マスタを新設のDWHで扱う(顧客予備軍も含むマーケティング対象の)顧客マスタに変更してもいいものだろうか。答えは否である。両者は同じ”顧客”と呼ばれるものだが、その意味する範囲も粒度も異なる場合、「メタデータが異なる」と解釈すべきである。この場合の対処は、従来の顧客マスタとN:1の関係にある統合顧客マスタを新設して両者を共存させるのが自然である。
えーそんなの当たり前じゃないの?とお考えの読者も多いと思われるが、(メタ)データ管理の意識が薄い企業では、似たような状況でマスタを新設せずに既存のマスタデータを無理やり拡大利用しているケースがあるのではないだろうか。このようなメタデータの意味拡大を繰り返してゆけば、企業システムがブラックBOXのカオスと化して行く日はそう遠くない。ましてやこの意味拡大を施した証跡(XXXX年XX月XX日に誰が何の目的で実施)が残されていなければなおさらである。
如何であろうか。エンタープライズDWHの構築には新たな分析情報の付与が必要な事がお分かりだろうか。そしてメタデータに拘ることはDWHの構築に必要不可欠であるばかりか、システムのアンチエイジングにも役立つことになるのだ。