[StreamCDR] 通信業界用標準ベンチマーク策定に向けて

携帯通信業界におけるデータストリーム処理の標準ベンチマークの策定を考えていきたいと思っています.

SPEC （Standard Performance Evaluation Corporation) が定めるWeb の標準ベンチマークSPECWeb 2005 では、E-commerce (楽天などのWeb ショッピングサイト, SSL あり、なしミックス）、Banking (SSL オンライン銀行サイト、SSL あり), そして Support (企業のドライバダウンロード。ファイル転送中心で動的スクリプト実行部分は少ない、ＳＳＬなし）の3つのシナリオが用意されています。各シナリオはそれぞれ異なる処理パターンを持っており、世の中の大部分のウェブアプリケーションの特徴をカバーしようとしています。

これに習って、携帯通信業界における代表的なシナリオを考えていきましょう。

１．課金計算の前処理

• バイナリデータから ASCII データへの変換
• Filtering : 課金計算に必要な項目のみを抽出する
• Data Schema Validation: Filtering によって抽出した項目に対するデータ妥当性検証。例えば、パケット数がある範囲を超えていないか、数値データであるのに文字列が入っていないか、など
• 遅延データ：　末端の機器の故障などで CDR / XDR が遅れて到着する場合があり、そのデータに関しては別途ファイルに退避する必要がある。
• 計算：　後続の課金処理に必要な基本的な計算（足し算、引き算など）
• Aggregate 処理：　ある ユーザーID に対して、一定時間における使用パケット数、使用通話時間。ユーザー数は膨大であるため、この処理はメモリインテンシブとなる。

2. 顧客属性に応じた課金計算

• データベースからのユーザー属性付与：　CDR には顧客 ID のみが格納されており、課金計算に必要な情報が格納されていない。それらの情報はデータベースに格納されているため、そこから課金情報に必要な様々な情報を抽出して、データに付与する。属性情報としては、企業情報（法人契約で契約している場合があり、その場合は課金形態が異なってくる）、契約時のキャンペーンＩＤ（ダブル定額、学生割引、家族割引、指定ユーザー割引など）などが含まれている
• CDR のユーザーが契約期間内かどうかのチェック (Fraud Detection)
• ユーザー属性に応じた課金計算（契約形態に応じて様々な課金計算パターンがある）
• 携帯会社にとって重要な1契約あたりの平均売り上げ APRU (Average Revenue Per User)のリアルタイム計算（上記と同じ）

3. マーケティング用大規模ネットワークグラフ構築

• CDR グラフの 誰 (From) が誰 (To) にかけたかをグラフのエッジとし、大規模なネットワークグラフをインクリメンタルに構築する。エッジの属性としては、量的なもの（通話時間）、ノード間の関係（家族）などの質的な関係などを付加する
• インクリメンタルに構築されるネットワークグラフに対して、各ノードの次数を求め、より多くのエッジが集中するノード（ユーザー）の Top-K を計算する。これらは、マーケティング分析に使用する
• グラフが巨大になるため、グラフのデータ構造とメモリ使用量などの指標となる

　使用する CDR/XDR データは標準的なデータ形式がないため、これに関しては独自に定めていくしかありません。ベンチマーク策定団体では、SPEC のほかに、TPC (Ｔransaction Processing Performance Council） などがありますが、SPEC では実装 (Java や PHP) を提供していますが、TPC ではアプリケーションシナリオを記述したドキュメントのみを提供しており、実装は提供していません。

我々自身は、SPEC が提供する形態ではなく、 TPC のような形でドキュメント化し、その一実装形態として、System S およびその他の 分散処理システムで実装し、定性的および定量的な評価をすれば、ひとつの研究論文として仕上がると思います。データストリーム処理だけでなく、Hadoop などと比較するのも良いでしょう。