検索

データウェアハウスの今後


1.非構造化データの取り込み

現在のデータウェアハウスが格納しているデータのほとんどは「構造化されたデータ」と呼ばれるものです。構造化されたデータとは、「顧客番号」「取引日」「取引金額」「顧客氏名」「商品番号」のようにあらかじめ概念ごとに分解、仕分けされたデータです。

一方、非構造化データというのは、電子メールのテキスト文とか画像データ、コールセンターで受けた顧客の声を入力したデータ、というような種類のデータです。一説によると、企業に存在するデータのうち、80% ないし 85% は構造化されていないデータなのだそうです。しかしデータウェアハウスの多くは構造化されていないデータの扱いは苦手です。非構造化データは、たいてい専用のサーバーやストレージに格納されていて、それを他のデータと連携させた使い方はあまりされていません。

非構造化データは、そのままでは、コンピュータでデータの中身を仕分けたり集計することが困難です。人間ならばメールを読んで、その中に登場する「1200000」という文字列が「商品A の販売価格」を意味していると簡単に理解できますが、コンピュータにはそういうことがわかりません。

テキストデータから意味を抽出するテキストマイニングツールと連携

そこで、非構造化データである自由テキスト文を活用するひとつの方法として、テキストマイニングツールでテキストデータを分解、整理して、それをデータウェアハウスに統合するという形態があります。

テキストマイニングツールというのは、

(1) まず文章を単語単位に区切る

(2) 辞書データと突合して登場する単語の品詞や意味を判定

(3) 単語が登場する頻度や前後関係等を解析する

という処理を行います。こうすることで、単語を切り出すだけでなく、文章の内容が苦情なのか、商品への質問なのか、故障への問い合わせなのかという判定もできるようになります。テキストマイニングはデータウェアハウスとは別の独立したテクノロジーとして発展してきたのですが、一部のテキストマイニングツールベンダーは、RDBMS や XML DB と連携させた使い方をアピールし始めています。

保険金の不正請求を見破る

テキストマイニングツールとデータウェアハウスの連携例として、米国の健康保険における保険金の不正請求監視というのがあります。米国では公的な社会保険がないため、多数の民間企業が医療保険や労災保険を提供していますが、水増し請求や偽装請求を企む輩が多く、毎年日本円換算で数10億円を超える金額の被害を受けています。

そのため保険会社は早くから不正請求判定システムを導入して効率的に不正を見抜こうと工夫しました。しかし、従来の不正検知システムは構造化データしか見なかったため、精度の高い検出はできず、提出された保険金請求のうち 1% から 1.5% 程度が、審査員の目視による確認作業が必要と判定されてしまいます。結局本当に怪しい請求を見破るためには、書類に記載された状況説明文の矛盾点やあいまいさを、人間がチェックしないとダメなのです。

例えば、労働災害保険の支払い請求書には、次のような記載欄があります。「どのような状況下で負傷しましたか。実際に負傷するまでの前後のようすを詳細に記述してください」「負傷した部位、ケガの種類、状態について記してください」「どのような工具や機械、装置、OA機器などによる事故か説明してください」という質問です。

この記述内容に対して審査員は次のようにチェックします。

怪我や事故の説明があいまいでないか、警察からの報告との食い違いがないか、当該企業の業種や職種から見て事故内容、発生時間に不自然さがないか、MRI検査を実施したことになっている場合、そのタイミングが通常の医療検査として妥当か、以前にも名前が出たことのある場所、人物が関与したことになっていないか、その土地柄、季節、気候にそぐわない事故内容ではないか、…など。

ところが、保険会社では審査員が不足していて、一件あたりに十分な時間を割けないのが実情でした。また、担当者の熟練度によって、不正を見抜く能力に大きな差があるのも悩みだったそうです。

そこでこの問題を解決するために、請求書類上の文章をテキストマイニングツールで解析、これをデータウェアハウス上でその他のデータと融合させて不正請求を判定する、新たな審査モデルを構築しました。

新システムは、テキスト文の内容を判定ロジックに取り込んだことが功を奏して、審査精度が大きく向上。従来のシステムでは見逃していた疑わしい請求も発見できるようになりました。一方、真正請求なのに審査担当者にチェックを依頼してしまう誤判定も大幅に減ったおかげで、審査員は落ち着いてチェックできるようになり、審査員が不正を見破る率も向上しました。

その結果、詐欺による損失額を大きく抑制することができたそうです。

2.リアルタイム型データウェアハウスへの進化

もうひとつの動向は、データウェアハウスのデータ鮮度と、同時サポートユーザー数の拡大に関する進化です。

かつてのデータウェアハウスは、新しいデータをロードする頻度は、月一回とか一日に一回という方法が主流でした。たとえば銀行のデータウェアハウスでは月次データ、すなわち顧客の前月の月末の残高だけを保有することが多かったのです。取引ひとつひとつを示す取引明細データも保有しますが、これもリアルタイムに取り込むのではなくて、1か月分の入出金データを翌月にまとめてロードする、という方法をとっています。

データウェアハウスが企業の本部だけで使われていた時代の用途は、(1) 前月の成果レポート作成、(2) 本格的なデータ分析作業、の 2つが中心でした。本格的なデータ分析というのは、銀行の例であげると、ローン返済の延滞予測とか小口ローンの利用見込み先を探す、というような作業です。本格的なデータ分析では、ひとつの仕事に 1週間以上の時間をかけるので、あらかじめ分析するデータの期間を、例えば平成20年4月から平成21年3月までと決めて、そのデータを用います。作業中に、刻々と変わる新鮮なデータがほしいというニーズはありません。

初期のデータウェアハウスはこのような使い方が中心だったので、データの更新頻度は月一回でも実用に適していました。

営業現場や顧客が直接データウェアハウスを参照する時代へ

やがて、データウェアハウスが持つ情報を、もっと全社的に活用したいという要望が出てきます。特に営業現場でのデータ活用が望まれました。ただし営業現場では複雑な分析はしません。例えば銀行では、今、眼前にいる顧客の現在および過去の取引内容を素早く見たいのです。情報照会は DB にとって単純な処理ですが、何百人とか何千人(何万人という例もあります)という多数のユーザーが同時にアクセスしてきて、しかも数秒以内にレスポンスを返す必要があります。

もう一歩進んだニーズとして、顧客に伝えるべきメッセージや推奨商品も同時に表示させたいという要望も増えてきました。これは判定ロジックを通すので単純な情報照会よりも少し重い処理になります。

これらは、今まではデータウェアハウス向きとは考えられていなかったタイプの仕事です。むろんデータウェアハウスなのですから、複雑で重たい処理も同時にこなさなくてはなりません。こうしてデータウェアハウスは、性質の異なる負荷に耐える性能が要求されるようになりました。

データウェアハウスに求められる新たな 2つの性能

(1) データ鮮度 データウェアハウスも最新の情報が求められるようになりました。

(2) ミックスワークロード対応 重たい複雑な分析処理と、大量の単純な照会アクセス処理を両立させる必要があります。しかも (1) を実現するために、バックグラウンドで常に新しいデータを追加する処理も行なっていなくてはなりません。

かつては、データウェアハウスにリアルタイムにデータを反映させ、かつ多様なエンドユーザーがそこにアクセスするのは無謀と思われていたので、そのようなニーズに対してはリアルタイム参照用データマートと分析用のデータマートを別々に構築するのが常識でした。

ところが前回のコラムで書いたように、データマートを複数設置すること自体が、企業の ITコストを押し上げる要因になります。

今ではデータウェアハウス製品の性能が上がり、リアルタイム更新や大勢のユーザーが直接アクセスすることも可能になりました。このため、営業現場や顧客からの照会業務(オペレーショナルインテリジェンス)と、本部による複雑な分析業務(ストラテジックインテリジェンス)をひとつのデータウェアハウスに統合し、今までのデータマートを並べる方式と比べて低コストでサービスを提供できるようになったのです。


eventbanner.png