Silicon Soul -広告技術と広告のblog- » プログラミング

政策別に各政党のマニフェストをテキストマイニング

silicon_soul — Tue, 25 Aug 2009 19:28:23 +0000

前回に引き続き、マニフェストのテキストマイニングで遊んでみます。

今回は２相３元データに対する多次元尺度構成法という、あまり一般的でない解析手法を適用します。

多次元尺度構成法（多次元尺度法）とは。　たとえば、世界の都市を飛行機で移動するときの時間の情報だけをもとに、移動時間の短い都市同士を近くに、移動時間が長い都市は遠くに配置して移動時間ベースの地図をつくることができる方法で、各点間の距離や類似度の情報をもとに、各ポイントの位置を空間にプロットすることができます。簡単にいうとこんなところです。各都市のイメージの類似度をもとにバカ世界地図を構成するのにも似てなくも無いです。

　個人差多次元尺度法(Weighted MDS)と呼ばれる方法は、この多次元尺度法を個人間のイメージの違いも同時に分析できるようにした手法で、心理学関連の研究で使われています。w-mdsが各個人間の評価の違いをどう表現するのかというと、全員の共通項となる地図（共通布置空間）を１つ作り、各個人の差を、軸（緯度、経度）へのweightとして表現します。ある人にとっての地図は、共通項となる地図を緯度方向にちょっとだけ縮めたもので、ある人にとっての地図は経度方向に縮尺するとうまく当てはまる。みたいな。

説明むずかしいな。。。詳細はぐぐってください。
　
で、マニフェストにwmdsを適用して解析して、各政策別に政党間類似具合がうまく見えたら面白いなぁと。

wmdsの解析は、netlibで手に入るsindscalを使いました。
netlib/sindscal　
Fortranのソースですので、g77あたりでコンパイルできます。

※indscal/sindcalをより一般化したALSCALがGNU Rで使えたような気がするのですが、どのパッケージに含まれているかみつからなかったのでsindscalで解析しています。
　
　
では、プロセスです
１．類似度行列の算出
各党のマニフェストを前回同様ヤフーみんなの政治からこぴってきます。
各政策単位のマニフェストデータを各党ごとにコサイン類似度をとり、行列を作成し、
sindscalのデータフォーマットにおとしこみます。
２．sindscalで解析
コンパイルしたプログラムをsindscalのプログラムに標準入力から渡して解析修了です。
これで政党の共通布置空間と各政策の傾向を表すWeightを得ることができます。
３．GNU Rで作図
GNU Rにデータを引っ張って作図します。

sindscalのデータフォーマットはIntroduction to Multidimensional Scalingか、Three Way Scaling　という本に載っています。　Web上ではみあたらないので、欲しい方がいたら詳細upします。
　
　
結果です。
　VAF比の動きをみると5次くらいまでのデータを見たほうがよさそうなんですが、視覚化できないので２次までを求めました。

sindscalの解析結果は次のように出てきます。

sindscal output

weight_space

　
　
　この解析は、各党の”主張”が似ているかどうかを算出しているわけではなく、各党で”似たような単語”が使われているかどうかによって空間配置を行っているという点にご注意ください。
　
　
　
まず、共通布置空間(STIMULUS MATRIX)とWeight MatrixをPlotします。
　

stimulus matrix

Weight matrix

　
　Stimulus spaceが全体的な傾向の布置になり、自民・改革クラブ、社民・共産・民主党が近い距離にプロットされています。前回のクラスタ分析・MDSの結果とは若干違う傾向がでてますが、新党日本の位置はかわらないようです。
　
　Weight matrixは各政策に対し、各党ごとに特徴が出ているかどうかといった事をあらわしています。特に子育てに関する政策に関しては差が顕著に出ています。
　
　

次に、各政党の共通布置空間に、政策別のWeightをかけた政策の個別空間をつくっていきます。
　
　
　

子育て・教育

　
差が顕著にでている子育て政策ですが、y軸のばらつきに変化は少なくｘ軸方向につぶれたグラフになっています。自民⇔新党日本の差はすくなくなっていますが、社民⇔自民間の差は大きいようです。
　
　
　

年金制度

　
　
年金制度に関して、共通布置に近く、共通布置と同様の傾向なのではないでしょうか。
　
　
　

地方分権

これも固有の特徴がみられません。
　

政治・行政改革

y軸方向に圧縮された感じの布置で、保守、リベラルの違いのようなものがあまり見られないような布置ができあがりました。
　
　
　

安保

安保。政治・行革と同様の傾向でしょうか。

農業

農業政策は共通布置にちかいですね。
　
　
　

消費税・財源

財源・消費税。政治・行革政策の傾向に近く、保守< ->リベラル間の差がすくない印象です。
　
　
　
　
　
　
　
以上、各党のマニフェストのデータをもとに、計量的に各政策の違いをみてみました。当初想定していたより”差”がでておらず、解析結果をどう読んでいいのか良くわからないところが多かったのですが、次元をあげればもうちょっと面白い結果が見れるかもしれません。
　
　
　
　

マニフェストをクラスタ分析

silicon_soul — Sun, 23 Aug 2009 19:33:32 +0000

もう少しで選挙なんで各党のマニフェストを眺めていたのですが、『どの党とどの党の内容が似てるのか』という非常にどうでもいい事が気になって、クラスタ分析してデンドログラムを書いてみました。

処理は

1. 『Yahoo! JAPAN > みんなの政治 >政党別マニフェスト』のデータをコピペで収集
2. MeCabで形態素解析（記号、助詞を除く)
3. 各政党のマニフェスト間のコサイン類似度を計算
4. 距離行列をつくる
5. クラスタ分析(ward法)

です。
　
　こんなのでマニフェストの単語とその出現数が似ている政党のグループが作れるはずです。
　
　形態素解析→距離行列まではPerlで、クラスタ分析はGNU Rで処理してます。
　
　
　
　
　
　結果。
　
　
　

クラスタ分析(ward法)

　
　
　
　２群に分けるとすると、”自民・公明・国民新党・改革クラブ”のクラスタと”社民・共産・民主・みんなの党・新党日本”になりますね。”保守”クラスタと”革新”クラスタ？
　
　自民と公明は出てくる単語の傾向がとても似ているようです。さすが与党。
　共産・社民も同様に単語の出現傾向が近いみたい。
　
　新党日本は他の政党の主張とは離れているんですかね？どの政党からも遠いですね。
　
　
　
　
　距離行列を作ったので、ついでに多次元尺度法で2次元にマッピングしてみました。
　
　

MDS

　
　ward法のクラスタ分析の結果とずいぶん違うものができました。
　
　今度は公明党・国民新党、民主・社民の距離が近くなりましたが、新党日本はどの政党からも離れています。
　
　
　
　以上、なんの役にも立たない結果ですが、coLinuxの環境を再構築した勢いでつくってみました。
　

HadoopDBのアーキテクチャ

silicon_soul — Mon, 27 Jul 2009 16:25:29 +0000

7/24にpostした「HadoopDB」の続きです。

■HadoopDBのアーキテクチャについて

HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads. Azza Abouzeid, Kamil Bajda-Pawlikowski, Daniel J. Abadi, Avi Silberschatz, Alex Rasin. In Proceedings of VLDB, 2009.

より、
HadoopDBのアーキテクチャに関する章から、Hadoopに追加された４つのコンポーネントについて順に読んできます。

The Architecture of HadoopDB

　

　
　
▼Database Connector

Database Connectorは、クラスタの各ノードにある個別のデータベースとTaskTrackerの間のインタフェースで、
HadoopのInputFormatクラスを拡張することによって実装されています。MySQLとPostgreSQLのConnectorが実装済みで、MonetDBやInfoBrightといったオープンソースのcolumn-storeデータベースについても実装の計画があるそうです。
InputFormatを拡張することによって、データベースをHDFS上のデータブロックと同じように扱うことができると説明しています。
　
　
　
▼Catalog

Catalogは、データベースのメタ情報を管理するコンポーネントで、以下の情報を持ちます。
１．データベースの場所、ドライバクラス、証明書等のパラメータ
２．クラスタ、レプリカの場所やデータパーテショニング情報等のメタデータ
現在の実装では、これらのメタデータをHDFS上にXMLファイルとして保持します。
　
　
　
▼Data Loader

Data Loaderは、以下の３項目について管理を行います。

１．ロードされているパーティショニングkeyに対するデータの再配分を実行します。
２．単一ノードに格納されてるデータを複数の同じパーティションやチャンクに分割します。
３．最後に、ある単一ノードのDBにチャンクをBulk-Loadingします。

Data LoaderはGlobal HasherとLocalHasherの大きく２つのコンポーネントからなっています。

Global Hasherは、Hadoop上で動くMapReduceのカスタムモードJobとして実行され、HDFSに格納されているrawデータを読み込み、再分割を行います。
Local Hasherは、HDFSから、各ノードのローカルファイルシステムにデータのコピーを行い、Maxチャンクサイズ設定に基づき、ファイルサイズが同一になるよう分割します。

チャンクが同一サイズになるようにするため、Global Hasher, Local Hasherでは異なるHash関数を使用しています。
　
　
　
▼SQL to MapReduce to SQL (SMS) Planner

HadoopDBは並列DBにSQLで問い合わせをするインタフェースを提供します。
SMS　PlannerはHiveを拡張したもので、HiveはHiveQLというSQLの一種をMapReduceのジョブに変換し、
HDFSに格納されたテーブルを操作します。

(a) MapReduce job generated by Hive (b) MapReduce job generated by SMS assuming sales is partitioned by YEAR(saleDate). This feature is still unsupported (c) MapReduce job generated by SMS assuming no partitioning of sales

　
　
上図の(a)がHiveでのデータ処理、(b)がHadoopDBでの処理で、論文ではHiveとの処理の違いが詳細に述べられています。
　
　

SELECT YEAR(saleDate), SUM(revenue)

FROM sales GROUP BY YEAR(saleDate);

　
　
上記SQLを実行する際、HadoopDBでは各データノードにあたる部分にDBMSが配置されているため、SQLを実行して、次に結果を出力するだけという非常にシンプルな実行プロセスになっています。Hiveの処理フローにくらべ相当簡単なのが図でわかります。
　
論文を読む限り、HadoopDBとは、Hadoopのもつ耐障害性、スケーラビリティを生かして超大規模データを格納・処理するための仕組みで、HadoopのMapReduceフレームワークにRDBMSをくっつけて並列DBにしてしまうというもののようです。
　
時間ができたら実際に試してみたいとおもいます。

HadoopDB

silicon_soul — Thu, 23 Jul 2009 17:59:43 +0000

HadoopDB

オレンジニュースさんでHadoopとRDBMSのそれぞれの特性をあわせた「HadoopDB」というProductが紹介されていました。

開発者によるリリースノートはこちらです。

Announcing release of HadoopDB (longer version)

HadoopDBの特徴は

1. DBMSとMapReduceのハイブリッドで、分析作業を対象にしている
2. 一般的なサーバで構築された、（メモリとかDiskとかの）共有無しのクラスタまたはクラウド上で動作するようデザインされている
3. フリー・オープンソース並列DBのマーケットのギャップを埋めることを意図している
4. 既存の並列DBシステムやDBMS/MapReduceハイブリッドシステムよりスケーラブル
5. Hadoopと同様のスケーラビリティで、構造化データ分析作業において、優れたパフォーマンスを発揮する。

といったところのようです。
　

　ちょうど今、仕事のデータ分析をHadoopと並列DB(某社のDWH製品)両方使って行っています。
　
　構造化されているdata sourceを使った分析は並列DBを使い、大量のraw dataを解析する場合にはHadoopクラスタと使い分けています。並列DBはSQLで記述でき、比較的高速に動いてくれるので便利ではありますが、DBに入っていないraw data処理では、自由に記述できて大量データを高速に捌けるHadoopが便利です。

　HadoopDBの目指しているのがDBMSとMapReduceのハイブリッドプロダクトとのことですし、Hadoop(HDFS)に入っているデータをより簡単に扱う仕組みとしてはPigやHiveがすでにあり、それらのプロダクトとの違いなど気になるところが多いです。

　そのようなわけで、HadoopDBのHPに掲載されている論文をPrintして帰りの電車の中で読んでいました。
　

　
　
　
半分くらい目を通したので、忘れないようメモにまとめます。
　
　

　

■概要
　
　HadoopDBは、Hadoopをタスクコーディネーションとネットワークの道具として使い、単一ノードのDBMSを複数結合するというコンセプトでできています。(HadoopDBで実行される)クエリはMapReduceフレームワークを使うことでノードを超えて並列化されます。HadoopDBは、Hadoopのスケジューリング、ジョブトラッキングを利用しているので、耐障害性、ヘテロジニアス環境での運用を可能としてます。
※実運用上、同一のHWでクラスタを組むことになるでしょうから、ヘテロジニアス環境で運用できるというアドバンテージはあまり感じません。。。

The basic idea behind HadoopDB is to connect multiple singlenode database systems using Hadoop as the task coordinator and network communication layer. Queries are parallelized across nodes using the MapReduce framework; however, as much of the single node query work as possible is pushed inside of the corresponding node databases. HadoopDB achieves fault tolerance and the ability to operate in heterogeneous environments by inheriting the scheduling and job tracking implementation from Hadoop, yet it achieves the performance of parallel databases by doing much of the query processing inside of the database engine.

　
　
■関連プロダクトとの違いについて
　
　PigやHiveとの違いは、まずそれらが(データ操作のための)言語やインタフェースの問題にフォーカスされているのに対して、HadoopDBはシステムレベルでの結合を目指しているところとあります。
　

2. RELATED WORK

There has been some recent work on bringing together ideas from MapReduce and database systems; however, this work focuses mainly on language and interface issues. The Pig project at Yahoo , the SCOPE project at Microsoft , and the open source Hive project aim to integrate declarative query constructs from the database community into MapReduce-like software to allow greater data independence, code reusability, and automatic query optimization.
Greenplum and Aster Data have added the ability to write MapReduce functions (instead of, or in addition to, SQL) over data stored in their parallel database products .
Although these five projects are without question an important step in the hybrid direction, there remains a need for a hybrid solution at the systems level in addition to at the language and interface levels. This paper focuses on such a systems-level hybrid.

　
　
■アーキテクチャについて
　以下は、明日postします。

The Architecture of HadoopDB

▼Database Connector
▼Catalog
▼Data Loader
▼SQL to MapReduce to SQL (SMS) Planner