メタ・ビッグデータ
すごく抽象的だけど面白い話。
いわゆるデータ爆発の時代に、データをどう管理するかはIT産業における大きな問題です。Hadoopをはじめとするビッグデータの蓄積保存と分析のためのツールも普及が進んでいますが、いっぽうでデータの検索や管理についてはまだまだ人手でカバーしている場面が多いのではないかと思います。
例えば、あなたはWebマーケティングマネージャでとあるWebキャンペーンのディレクションをしたとします。キャンペーン期間は1か月あり、キャンペーン後に告知サイトのWebアクセスログがエンジニアリングチームから渡されました。圧縮して100ギガ、展開して500ギガになり、圧縮状態と展開状態がそれぞれ社内のHadoop（HDFS）においてあります、とhdfs URIスキーマ形式でのアドレスが担当エンジニアからのメールに記載されています。
あなたはキャンペーンの目的に照らして、効果検証の項目を列挙し、部下に検証作業を依頼します。もろもろのレポートが出来上がり、経営層へのプレゼンを終えてプロジェクトは終了します。
さてこのとき、次のような課題が浮上すると思われます。
- このキャンペーンの生ログはこの後もHDFSにずっととっておくのか？
- 生ログは圧縮状態で保管するのか？それとも展開状態か？前処理は？
- 効果検証に使ったプログラムはログのデータとは別にコードリポジトリで管理されているが、両者の対応（どのプログラムがどのデータに適用可能か、もしくは適用したのか）については誰が覚えておくのか？
- 同様に、分析結果はどこにどのように保管するのか？
- キャンペーンは繰り返し色んな対象物で行れていくが、過去の事例からデータや分析結果や分析プログラムを引っ張ってきて再利用するためのプロセスは人手で頑張るのか？
いまビッグデータと言われている話は、分析の手法や扱うデータの大きさへの対処を特に意識して語られることが多いと思われますが、実務上はこうした「管理」の側面がバカになりません。
上記の事例はある企業の「社内データ」において発生する課題についてのものですが、社外のデータにおいても、同様の課題は企業横断的に発生すると思います。とくに昨今のアドテクにおいては、メディアやテクノロジベンダやエージェンシーなどの各プレイヤがそれぞれ持つデータを統合するところに大きな付加価値があると思われるためです。とりあえずここではその話は置いといて、本記事では社内データについて考えます。
この課題への対処としてメジャーな手段として、「情報の一元化」がまず第一に挙げられます。つまり、「常にそこに集約される場所」を用意しておけば「何かあったらそこを見る」という対応が可能になるからです。分析プログラムとデータの対応関係等も、社内ポータルのようなものを立ててドキュメント化しておくわけです。するとこうした運用は、どの会社でも似たような構造になるのでテクノロジベンダーが登場し共通サービス（蓄積・管理・照会などの機能を提供）を提供する流れになりそうです。その代表格がトレジャーデータ社ではないでしょうか。
さて、上記課題は第二の対処方法も挙げられます。それは、Web2.0がブームとなった時代にさんざん研究された「メタ情報」を扱うという手段です。例えば、上記の例でしたら生ログに関して「xxというキャンペーンの、告知サイトでの、yyからxxまでにおける、Apache Log形式で書かれたWebアクセスログファイルを、zip圧縮したもの」というメタ情報を考慮することが出来るでしょう。分析プログラムや結果情報についても同様です。そのメタ情報を系統的に管理しておけば、データ分析をはじめとするさまざまなデータ利活用において利便性を飛躍的に高められると思います。
ここでメタ情報に含まれる「告知サイト」「Apache」といった知識情報は共通に利用できるため、知識表現のテクノロジをうまく使うことでシステムをどんどん賢くしていけそうです。そして知識表現のテクノロジは、ブームを終えた感のあるWeb2.0の時代にさんざん研究されて技術資産がパブリックに蓄積されています。
そう思って私はそんなメタ情報管理のWeb2.0標準技術について調べていたのですが、今ビッグデータ関連のコンテキストであまり語られない面白い視点があることに気づきました。それは何かというと（標準仕様書において直接述べられていない私の造語的な概念ですが）「名前」と「実体」の分離です。もう少し突っ込んで英語でいえば「mentionability（言及可能性）」と「accessibility（アクセス可能性）」の分離です。
簡単に言うと、「そういうデータが『ある』という知識」と「それを入手するための知識」は別々に管理したほうが色々と嬉しいことがある、ということです。たとえば、発生したデータや分析プログラムや分析結果に「名前」をつけることによって、まずそういうものの存在を意識することが出来ます。hadoopに入れるまでもない小さなデータや、かき捨てのスクリプトプログラムだとしても、何らかの社内リソースを投入して得られた成果物なので、「どっかのメールにそういうものが埋もれてるっていうことくらいは覚えといてもいいのではないか」みたいな落としどころがデータの管理コスト的にちょうどバランスのとれた話になってくると思うわけです。
なので「そりゃあきっちりと蓄積保管したほうがいいけどさ、面倒くさいしコスト的に見合わないからビッグデータだけは何とかしようよ」みたいな話で終始してるんじゃないかと思います。名前の管理と実体の管理を分離するビジネス的なメリットは、前者は後者よりもはるかに低コストで出来ることです。Web2.0関連仕様書には全然そんなこと書いてないけど、僕はそう感じます。
そういう意味でWeb2.0の技術はよく考えられていると思います。そういう面白いことは他にもあります。例えばXMLはWeb2.0技術の根幹ですが、XMLとJSONの大きな違いは何かといえば、XMLには「名前空間」があるということです。例えば次のメタ情報を見てください。
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xml:lang="ja"> <rdf:Description rdf:about="http://www.kanzaki.com/docs/sw/"> <dc:creator>神崎正英</dc:creator> <dc:date>2001-09-04</dc:date> </rdf:Description> </rdf:RDF>
(出典元：Dublin Core: メタデータを記述するボキャブラリ)
これはWebページ（ページじゃなくてもURIが付与できるものなら何でもいい。O2O的なURI、例えば「どこどこのイタリアンレストランの水曜日の日替わりランチ」みたいなものでもOK.）に意味を付与するRDFという仕様で使われる語彙を定義するDublin Coreという仕様ですが、XML全体はrdfという名前空間が付与されていますがそこで叙述されている名前や日付にはdcという名前空間のものが適用されています。つまり「ボキャブラリ」と「メタ情報」は別々の名前空間に属するというわけです。このあたりのセマンティクスの強さがWeb2.0関連仕様の特長だと思います。残念ながら流行ってないのはこれを使ったアプリケーションがあまりないからだと思われますが、上で検討したことに照らせば、こうした技術はうまく最新のビジネスに応用可能ではないかと思います。
データのメタ情報を管理することで出来ることはいっぱいあります。例えば、機械学習の世界では「Bag Of Words」というデータ表現方法がありますが、もしそのデータがBag Of Wordsだということをシステムが把握できていれば、機械学習タスクをシステムが暗黙裡に実行し、何らかの経営面への影響が見えた時だけユーザにアラートするという機能が実現できます。そしてそういった暗黙裡に行われるタスクについてもメタ情報を付与することによって、マーケティング担当者ドリブンで分析作業を行う場合にも似た分析が既に実行済みかどうかを簡単にバックトレース出来るようになります。新しい機械学習手法をシステムにアドインしたときも、即時に活用出来る状態まで持っていけそうです。
そうした諸々のことを、考えたので書いてみた次第です。
