ビッグデータ活用における課題 ～ セルフサービスと IT部門の橋渡し: セルフサービスの先にあるもの ～

ビッグデータという用語が注目されるようになってかなり経ちましたが、現在では多くの企業で IoT やソーシャルデータ、また以前までは分析の対象としきれなかった大量のデータを利用してビジネス上の価値をもたらす新しい知見を求めようとしています。

以前、「日本のビッグデータ活用における課題とは」にて、日本でのビックデータ活用を取り巻く課題や、なぜビッグデータを活用することが困難なのかを取り上げました。そして、ビッグデータ活用において先行する企業では、「ビッグデータ活用の民主化」、つまり分析・業務ユーザーがセルフサービスでビッグデータを活用する環境を整備するというアプローチが取り入れられ始めているということをご紹介しました。

データカタログを利用することで Google 検索のような Web インターフェースから素早く効率的に適切なデータを見つけ出すことが可能になります。そして、使い慣れた表計算ソフトのような UI を持つデータプレパレーションを使用することで、分析・業務ユーザーは最終的に BI ツール等でビッグデータの分析を行う上で適したデータセットを自身の手で編集・加工することができるようになります。

この「 データプレパレーションを使用して分析に必要なデータセットを利用者自らが準備できる」ということは、どのような切り口から分析を行ったらいいのか試行錯誤をしているようなフェーズでは特に効果的かと思います。

例えばオンラインショップにおける商品の売上を分析の場面を想定してみたいとします。分析・業務ユーザーがまずソースとなるデータを見つけるためにカタログを検索してみると、購入者の年齢が ～10歳、～20歳、～30歳・・と世代ごとの粒度に置き換えられていたり、一部の個人情報関連の項目をマスクした社内共通の分析用データとして提供されているトランザクションデータを見つけました。さらにデータの中身を詳しく確認してみると、このデータは自分が分析したい項目がすべて網羅されていたので利用できそうだということで、このデータと別テーブルにあった商品マスタのデータを組み合わせてデータプレパレーションでデータセットを作成して分析を行うことにしました。こうして行った売上分析は、まず売上の全体的な傾向を把握するという観点で十分に有用で、当初の目的はほぼ達成することができましたが、さらに深堀り、もしくは別の角度から分析を行おうとするとデータの粒度の粗さがネックとなってきたので、さらに生のトランザクションデータに近いものを探して改めてデータセットを作成、そして分析を行うことにしました。。。

と、このようなケースは実際によくあるかと思います。分析を行っていく中で、その元となる "どのデータをソースとするか" や "どのようにデータを加工してデータセットを作るか" も一度で決まることは少なく、データソースを変えてまたデータを加工し、そのデータセットでまた分析して・・という工程を繰り替えすことが一般的な流れになります。

<セルフサービス分析=アドホックな分析ばかりではない>

さて、上記で取り上げたような売上分析のようなものは、多くの場合、週次や月次、年次といった形で定期レポートとして必要となるかと思います。このような場合、週次、月次など必要なタイミングで元となるデータソースから最新のデータをロードし、同じ加工を行ってデータセットが作成できれば定期レポートとしての運用が行えることになります。これはアドホック的な一度きりの分析ではなく繰り返し行われる定期ジョブの要素を持った分析なので自動化が求められるでしょう。

また、他の例として機械学習への利用を考えてみます。機械学習では、教師データを用いて最適な機械学習モデルを構築していくことがありますが、モデリングやスコアリングに必要な教師データの作成にもデータプレパレーションによるセルフサービスの手法の利用が考えられます。なぜならやはりモデルが完成するまでデータソースを入れ替えたり、加工方法を変えてみたり、と教師データのデータセットを作り変えては再度モデリングを行うような、より良いスコアが得られるまでの繰り返しが発生するからです。

そして一部例外はあるかと思いますが、多くの場合、構築した機械学習モデルを本番業務の運用に乗せるためにジョブ化することが目的になります。例えば、ローン審査における貸し倒れ予測を行うような場合、まず過去の取引データを用いてモデルを構築しますが、最終的に本番運用で新規のローン申請のデータをモデルで分析することが目的となります。つまりこれもまたアドホックな分析ではない一例と言えます。

この時、教師データのような分析用途のデータはいわゆるデータレイクなどに置かれていて、本番環境のデータベース等とは別の場所にあることが多いかと思います。ということは、機械学習モデルの構築時と、本番運用時ではソースとなるデータの所在が違っていることになります。そして、本番環境へのアクセスは厳しく管理されているので、機械学習モデルを本番環境に繋げてジョブ化する部分は IT 部門によって行われるというお話をよく伺います。さらに教師データの元となるテーブルと、本番運用時の新規ローン申請データが入ったテーブルが同じ構造、定義であれば、本番運用時でも教師データ用にデータセットを作成した時と同じ加工ロジックを使えるはずですが、加工 (ETL) 処理をジョブ化するのも同様の理由で IT 部門によって行われることになります。

分析のためのデータセットを作成するロジック、つまりどのようにデータを加工・変換すれば良いかは分析ユーザーが分かっています。一方、データソースとなるデータベースのテーブルであったり、ファイルであったりといったデータの所在については ほとんどの場合 IT 部門により管理、把握されているので、セルフサービスによって作成されたデータセットを運用に乗せるには、いかにスムーズにこのデータセットの加工ロジックを IT 部門へ受け渡すかが重要になります。

<セルフサービスからジョブ運用へ>

• インフォマティカでは、この課題に対してお互い密に連携したデータプレパレーションと Data Engineering Integration (旧製品名 BDM: Big Data Management) の製品により柔軟なソリューションを提供します。
• データプレパレーション上で行ったデータ加工処理はレシピという形で処理の内容が記録されます。
• レシピとして記録された一連のデータセットの加工ロジックは、マプレット/マッピングとして Data Engineering Integration に保存されます。

Data Engineering Integration に保存されたマプレットはパーツとして再利用可能なので、別のマッピングの中に組み込むことで任意の接続先のソースまたはターゲットを設定してジョブ化することができます。

また、前述の機械学習での活用のようなケースでは、

• Data Engineering Integration に用意されている Python トランスフォーメーション (パーツ) などを利用して、マッピングの中でモデルの API を呼び出すことができます。

これにより、分析・業務ユーザーが作成した加工ロジックをデータソースを本番環境データベースのテーブルに設定してそのまま使い、出来上がったデータセットを機械学習モデルの API をコールする Python トランスフォーメーションに渡し、モデルによる分析結果という最終的なデータを出力するようなジョブを容易に作成し、運用できることになります。 

分析・業務ユーザーが得意としているデータの加工ロジックと、IT 部門が得意としているジョブ化、運用をどのように連携させるかという難しい課題を、データプレパレーションと Data Engineering Integration で解決してみませんか。