#今回は知財ではなく純粋にITの話です。なお、SoftbankのCMとも関係ありません。
データウェアハウスを構築する上で重要な処理にETL（Extract Transformation Load）があります。文字通り、データソースのシステムからデータを「抽出」し、「変換」し、データウェアハウスに「ロード」する処理のことです。
「変換」処理では、複数ソースのデータを統合して、データの形式をそろえたり、不正データを排除したりします。いわゆるデータ・クレンジング（洗浄）と呼ばれる処理です。これによってデータウェアハウスにロードされるデータの品質を向上できます。
しかし、ビッグデータの世界ではこのデータ洗浄をしてからロードするという考え方が必ずしも適切ではなくなってきます。データ品質とは一義的に決まるものではなく、分析の文脈によって変わってくるからです。データ管理者ではなくデータサイエンティストがデータ品質、そして、データ洗浄の主導権を握るということもできます。
この考え方の変化をわかりやすく説明できる例を思いついたのでここでご紹介します（この例は先日のTeradata Universeの講演でも使いました）。
大昔にZDNetにも書きましたが、Google等のサーチエンジンでは「もしかして機能」が一般的になっています。たとえば、「初音ミク」と入力したいところ、間違えて「蓮根ミク」と入力してしまうと、Google様は「もしかして「初音ミク」ですよね？」とちゃんとわかってくれます。これは、内部的に入力ミスを修正する辞書を持っているからです。ではどうやってそのような辞書を作っているかというと、過去の検索キーワードの膨大なログを解析して、「蓮根ミク」と入力した短時間後に同じIPから「初音ミク」と入れ直す人がある程度の数いると、「蓮根ミク」は「初音ミク」の入力ミスの１パターンであろうと判断して辞書に加えるという仕組みになっていると思われます。データ収集時には想定されなかった新たな使い方が考案された例だと思います（Googleの中の人は最初から想定していたのかもしれませんが）。
もちろん、検索キーワードのログの使い方としては、たとえば、Google Trendsのようにキーワードの入力件数の変化を時系列でレポートするという、もっとストレートなものもあります。
重要なポイントは「誤入力辞書を作る」という用途と「キーワード件数のレポートを作る」という用途ではデータ品質に対する考え方が正反対ということです。
前者は入力ミスこそが重要です、後者は入力ミスはノイズとして排除すべきです。従来型のデータ品質の考え方で入力ミスのデータを「洗浄」してしまうともう前者の目的には使えません。
つまり、データは洗浄しないで「汚い」ままで保存しておき、使う時になってダイナミックにどう洗浄するかを決めるべきということです。「変換」処理をぎりぎりになってから行なう、ETLからELTへのパラダイムシフトが必要ということです。
幸いなことに、RDBMSとHadoop/MapReduceの統合ソリューションの登場により、動的にデータをフィルタリング（洗浄）するのも比較的容易になってきました。もちろん、ETLが不要になるわけではないですが、今後はELT的な発想の重要性がどんどん増してくると思います。
なお、さらに一歩進んで、TeradataのCTO Stpehan Brobstは「ビッグデータの世界ではデータと構造はlate binding（遅延束縛）すべきである」と講演で言っていました。要は、データの構造すらも事前的に決まっているものではなく、使用時に用途に応じて決定されるべきものであるということです。
投稿のフィード