The Economist で企業対政府についての特集

The Economist の2月20日号で、企業対政府についての特集がありました。

以下、ざっと要約してみました。自分なりの解釈も入ってるので、原文にない情報が含まれている可能性があります。

正しく引用したい場合は原文を参照してください。

企業と政府の関係は敵対的になりつつある。しかし、両サイドとも互いを必要としている。


米国政府はセオドア・ルーズベルトの時代から、強くなっていく企業を制限していくような流れを作っていった。
こうした敵対的な雰囲気は増加の一方をたどるが、しかしあまりに強い制約は経済の活性化を阻害するため、政府は企業を必要以上に圧迫できない。
一方で企業も政府を必要としている。政府は、法システムや基本的な安全保障だけではなく、企業の根幹をなす労働者を教育したり、交通などの社会インフラを整えたりしてくれる。
それだけでなく、インターネットや人工衛星など、企業が商用製品を作るのに必要な多くの科学的研究を行ったりもする。
多くの業界において、政府は主要顧客でもある。防衛産業は典型例であるが、製薬業界なども国民厚生サービスなどが大手の顧客である。建設業界も政府の活動に強く依存している。


もしかすると、現在一番厄介な関係はハイテク産業と政府かもしれない。企業の顧客の一部が、政府がその企業のデータにアクセスしたり、企業のデータの使い方に制限をかけることに不安を感じている。
企業は顧客の側に立つのか、それとも政府の側に立つのか?


もう一つの複雑な問題は、企業と政府の両方によって市民に提供される福利厚生である。例えば、多くの政府は産休を拡大することを要求しているが、これは大企業には実現できても、中小企業にとっては実現がより困難なことである。有権者は税金の増加を嫌がるので、政治家は企業負担で福利厚生の向上を行おうとする。


大企業は政府とうまく付き合っていく必要があることを認める一方、政府は一部の大企業、例えば航空会社などを他国の買収から保護するなど優遇措置をとっている。


このレポートでは富裕国における企業と国家の関係について報告する。税金の役割、規制、競争についての政策、ハイテク産業がなぜ特別なのか、ロビー活動などについて議論する。


ここ最近、企業対政府という構図について特に興味を持っていたので、このレポートは非常に興味深いものでした。
多国籍企業は金銭的にも入手できる情報量も平均的な国家を上回っていて、しかも地理的制約が非常に緩いため、いずれ企業は国家を凌駕するのではと思っているのですが、やはりそう簡単にはいかないようですね。

Confluenceの稟議書機能を使う

Confluenceには稟議書というブループリントがあります。
何らかの意思決定をしなければいけないときに、議論をするためのページを作るためのテンプレートですが、地味に便利です。

意思決定に必要な情報が多い場合、チャットだけではそうした情報を正しく把握しながら議論するのが困難なので、私のチームでは稟議書ブループリントを活用しています。

以下のような情報を入力して作成しています。

  • ページタイトル
    • 「◯◯するかどうか」「◯◯の対処方法」など、意思決定に対する質問形式で作成する
  • 背景
    • 「◯◯するかどうかを決定するにはいくつかの問題について検討する必要がある」「◯◯の対処方法にはいくつかある」などの概要を書く
  • 選択肢とメリット・デメリット
    • 「選択肢1: 実行する」という形でいくつかの選択肢を並べ、それぞれについてメリット・デメリットを記載する。
  • 論点
    • 選択をするにあたって、どの部分が論点になるのかをまとめておく。


意思決定に参加する人はコメント欄で以下のような形式で入力していきます。

選択肢1に賛成。なぜなら、(以下論点についてのの主張を説明)


もちろん、議論の中で新たな選択肢や論点、それに既存の選択肢や論点の不備などが出てきますので、その都度説明を修正していきます。


注意点は2つ。

  • 意思決定するまでもないことについて、周囲からの承認を得るためだけにするような稟議は無駄なので上げない
  • 関係者以外は意思決定の場に呼ばない

2013年面白かった本

今年面白かった本をあげてみました。
専門書は省いています。
あとここに紹介してない本でも面白い本はたくさんあったのですが、さすがに全部は書ききれないので一部にとどめます。

果て無き渇望

本当にいい本でした。私が果て無き渇望アドベントカレンダーに参加したことからも、どれだけこの本に感銘を受けたか分かるでしょう。(アドベントカレンダーの記事)

文庫 果てなき渇望 (草思社文庫)

文庫 果てなき渇望 (草思社文庫)

カラシニコフ

先日亡くなったばかりのカラシニコフですが、製作者ではなくAK-47カラシニコフ銃によって引き起こされている様々な問題(アフリカの少年兵など)を書いたノンフィクション。
カラシニコフがなぜ広まったのか、広まったことでどういう問題が起きているのかなどが書かれています。
実はこの本を読むまで、カラシニコフって第二次大戦中に開発された銃だと思ってました……。

カラシニコフ

カラシニコフ

なぜデザインなのか?

デザインとは何か、ものづくりとは何かということについて語る、原研哉と阿部雅世の対談。
こう書くと芸術の話ばかりにように思うかもしれませんが、ほぼ全ての仕事してる人に役に立つ話だと思います。
大抵の人は、何らかの成果物を出すことを仕事に求められますからね。

頭の中にあるイメージを外に出す、感じたことを外に出すということを、抵抗なくスムーズにできるのがドローイングでありスケッチなんです。
「自分がしでかしてしまうこと」に対して、平気になれること。
(p.23)

なぜデザインなのか。

なぜデザインなのか。

東京至極のレストラン2013年版

やはりこれは外せません。とにかく私のツイートまとめを読んでください。

東京 至極のレストラン 2013年版 (SEIBIDO MOOK)

東京 至極のレストラン 2013年版 (SEIBIDO MOOK)

ロボット兵士の戦争

単に「ロボットが戦争で使われているんですよ」で終わるのではなく、ロボットが戦争に必要とされるようになった経緯、ロボットの投入によりどう戦争が変わるか、それも戦場だけでなく戦争を行う政府、戦争を「観戦」する一般市民などがどう変わるか、ロボット兵団の指揮官に求められるスキル、戦時国際法の変化などについて書かれています。
分厚いですが読み応えはあります。

ロボット兵士の戦争

ロボット兵士の戦争



援デリの少女たち

現代の援助交際「援デリ」についてのノンフィクション。こういう話が苦手な人は読まない方がいいです。
拠点を持たずにマクドナルドなどにたむろし、足のつかない携帯電話一つで組織的に「援助交際」を行う人達の話。社会の闇が描かれています。

援デリの少女たち

援デリの少女たち

ビッグデータの正体

仕事に関係のある本を紹介するつもりはなかったのですが、この本だけは例外。
著者は 2010年2月 に The Economist でビッグデータ特集を書いた人です。
この特集こそ、世界にビッグデータブームの火をつけた特集であり、私がこの業界に足を踏み入れることになったきっかけの特集です。その時の感想記事はこちら

本の中身も素晴らしく、きちんと本質をとらえた内容でした。
「ビッグデータって何?」って人はまずこの本を読みましょう。

ビッグデータの正体 情報の産業革命が世界のすべてを変える

ビッグデータの正体 情報の産業革命が世界のすべてを変える

鬱ごはん

今年のベストコミックです。
このマンガがすごい!2014」の第9位にオンノジがランクインした施川ユウキですが、私はこちらの作品の方が好きです。

就職浪人兼フリーターの鬱野たけしが、日々食べる食事について語っていくという話。こう書くと孤独のグルメに似ているように聞こえますが、孤独のグルメはどことなくかっこよさが見えるのに対し、こちらはひたすら孤独。また、出てくる食べ物が基本的にまずそうです。色々な意味で食べ物系の常識を覆してます。鬱野自身「何を食べてもおいしく感じない」と言っています。


表現が非常に秀逸で、この描写は一度クセになったらやめられません。

私が好きな話は、松屋の豚焼肉定食の話です。
就職浪人の状態を「毎朝、堕ちていく飛行機の中で目が覚める気分だ」と思いながら松屋に入り、豚焼肉定食を頼みます。そして出されてきた料理を「堕ちていく飛行機で出される機内食だ」と表現します。

初めて読んだときは本当にすごい表現だなと思いました。

興味があれば是非読んでほしい一冊です。

声に出して読みたい「果て無き渇望」名文10選

果て無き渇望アドベントカレンダー、15日目担当の shiumachi です。
本書の概要についてはymotongpooの素晴らしい記事があるのでそちらに譲ります。
ここでは、私が個人的に気に入っているフレーズをピックアップして紹介します。
トレーニング前に読むと元気が出る、そんな名文を拾ってきました。


「だれだって、トレーニングさえすればこんな身体になれます」
(果て無き渇望 p.11)

「いいですか、僕の言いつけを守ってください。ひとつは本気になってやること。ふたつは継続すること。三つ目は合理的に正しいトレーニングをすること。これさえ守れば、たとえ週二回でも必ず筋肉はつきます。あなたもいつかはこうなります」
(果て無き渇望 p.13)

運動生理学には「ルーの三原則」と呼ばれるものがある。筋肉は使うと発達する、使わないと衰える、使い過ぎても衰えるというものだ。
(果て無き渇望 p.346)

「いつも、トレーニングしている自分と別の自分がいるんです。そいつが、もう一回できるだろう、もう一回挙げてみろって応援してくれるんですよ」
(果て無き渇望 p.81)

ボディビルダーにとって減量や家族の犠牲、食事の苦労、社会性のなさなどは、それだけ自分がトレーニングに没頭しているという勲章ですよ。突き詰めれば自慢話なんです
(果てなき渇望 p.65)

「ボディビルダーにとって、筋肉がもたらしてくれる最大の意義は、自信ではないでしょうか」
(果て無き渇望 p.69)

自分の将来がどうこうとか、そんな先のことは考えてもいないし、考えられない。考えちゃうような人は、その時点で負けね
(果て無き渇望 p.134)

ボディビルにとってステロイド剤というのは、原爆みたいなものなんです
(果て無き渇望 p.257)

ボディビルは数学の方程式を解くのに似ている。正しいやりかたで順序だてて解析すると、必ず正解にたどりつく。
(果て無き渇望 p.246)

「自分はただひたすらに大きくなりたい。天から与えられた身体を、自分の意志の力で変えていく。筋肉を一センチ肥大させることで自分が神に近づけるわけではありませんが、少なくとも自分の肉体という小宇宙を創造することができる。たとえ後遺症が襲ってきてもかまわない。どんな手段を使っても、限りなく肥大した筋肉を手に入れたい。ただ、それだけなんです」
(果て無き渇望 p.229)

文庫 果てなき渇望 (草思社文庫)

文庫 果てなき渇望 (草思社文庫)

HBase 0.96 で導入される新しいコンパクション「Exploring Compaction」

Hadoopアドベントカレンダー2013、3日目を担当する @shiumachi です。
今回は HBase 0.96 の新機能を一つ紹介します。

要約


HBase 0.96 は賢くなったのでみんな使おう。

コンパクションのおさらい


HBase では、Log Structured-Merge tree (LSM-tree) というデータ構造を使っています。
LSM-tree を簡単に説明すると、入力されたデータをログとメモリ上のデータストア(Memstore、メモリストア) に書き込みます。
メモリストアがいっぱいになると、まとめてディスクにフラッシュし、新しいストアファイルを生成します。
このストアファイルがたまってきたときに、少しづつ一まとめにしてなるべくファイル数を少なくするようにします。これがコンパクションです。


コンパクションを実行することにより、ファイルは一つにまとまります。これにより、ディスク上の連続した領域にデータをまとめることができ、ディスクシークの回数を少なく保った上で予測可能にできます(最大でストアファイルの数と同回数だけ)


しかし、このコンパクション操作は非常に重い処理になります。
コンパクションを単純に説明すると、ディスク上のストアファイルを読込み、新しいストアファイルに書き出してマージしていくというものです。これだけで多大なディスクの負荷がかかることが分かるでしょう。
また、HBaseは普通HDFSを始めとした分散ファイルシステムをストレージとするため、ネットワーク転送も発生します。
かといってコンパクションを実行しなければ、ストアファイルが多くなり、一度のキーのルックアップに必要なディスクシークの回数が増え、やはり性能が劣化します。
現在のディスクIOと将来のディスクIOのトレードオフを考えることが、コンパクション戦略に必要となります。しかし、将来どれだけのディスクシークが発生するかは誰にもわかりません。そのため、ヒューリスティックな手法で現実解を求めていくことになります。

HBase 0.94 までのコンパクションアルゴリズム


コンパクションには2種類あります。メジャーコンパクションとマイナーコンパクションです。
メジャーコンパクションは、全ストアファイルを読み込んで一つのストアファイルに書き出していく(まとめる)処理です。このとき、以下の条件に当てはまるキーバリューのみを書き出します。

  • tombstone マーカーがついていない ( delete されたときに付与される、論理削除のマーカー)
  • TTL (生存時間) が残っている
  • バージョンが最大バージョン数を超えていない。例えばバージョン保持数が3のとき、4つ前のバージョンのセルはこのタイミングで物理削除される


もう一つはマイナーコンパクションです。今回の記事ではこちらの方に注目します。
マイナーコンパクションは、たくさんあるストアファイルのうち、あるアルゴリズムに基づいて抽出されたファイル群のみを一つにまとめます。このとき「なるべく小さいファイルを(ディスクIO低減のため)、なるべく多くの数(将来のディスクシーク数低減のため)コンパクションする」ことが重要となります。

まず、ストアファイルが一列に並んでいるとします。左のファイルの作成時刻が一番古く、右に行くにしたがって新しくなるとします。

  1. 1番左のストアファイルを選択する( F0 とする )。F0 のファイルサイズを S0 とする。
  2. F0 より右の全ストアファイルのサイズの和 S(1_N) を求める。
  3. もし S0 > S(1_N) * hbase.hstore.compaction.ratio (デフォルト 1.2) なら、選択ストアファイルを1つ右にずらし、同様の手順を実行する。
  4. もし S0 < S(1_N) * hbase.hstore.compaction.ratio (デフォルト 1.2) なら、F0 の一つ右のファイルから最大 hbase.hstore.compaction.max 個(デフォルト10) のストアファイルをコンパクション対象とする。
  5. もしコンパクション対象数が hbase.hstore.compaction.min 個 (デフォルト 3) より少なかったら何もせずに終了。
  6. コンパクション対象のファイル群をコンパクションして終了。


具体例が hbase bookのコンパクションのページ に載っています。


たとえばストアファイルのサイズが 100、50、23、12、12 と並んでいる場合、23、12、12 がコンパクションされます。
ここで注意しなければいけないのは、ファイルのソートはあくまで「作成日時」です。サイズではありません。
このアルゴリズムは、「ほとんどの新しいファイルは古いファイルより小さい」という前提に基づいています。


ストアファイルはメモリストアのフラッシュによって作成されます。このフラッシュ上限は決まっていて、hbase.hregion.memstore.flush.size (デフォルト64MB) * hbase.hregion.memstore.block.multiplier (デフォルト2) = 128MB となります。
古いファイルはコンパクションされていて大きくなっているはずなので、この前提は多くのケースにおいて成り立ちます。


しかし、当然成り立たないケースもあります。
例えば HBase のバルクロードは、ストアファイルを直接 HBase のリージョン内に配置する方法で、非常に高速にデータをロードできるのですが、新しいファイルなのに非常に大きいストアファイルをロードすることになり、上記の前提を崩してしまいます。
先程紹介したアルゴリズムは、あくまでコンパクション対象の最初の一つしか判定を行いません。アルゴリズム内で条件を満たしたストアファイルがあれば、そこから一定数のファイルを自動的に取り込みます。
これにより、この大きなストアファイルがあると、より古いファイルはコンパクション対象として判定されてしまいます。こうして大きいファイルがマイナーコンパクションの対象になってしまう可能性が高くなるわけです。

新しいコンパクションアルゴリズム


そこで 0.96 からは、Exploring コンパクションポリシーという新しいアルゴリズムをデフォルトアルゴリズムに採用しました。(HBASE-7842)



基本方針は単純で、「可能性のある組み合わせ全部計算して最適なものを選ぶ」です。
コンパクション対象を検索するところまでは既存のアルゴリズムと変わりません。
検索した後、以下のようなアルゴリズムで最適解を選んでいきます。

  1. コンパクション対象となった最初のストアファイルを F1 とする。
  2. F1から右に min 個以上 max 以下の連続したストアファイルを全て吟味していく。(デフォルトだと3〜10個) つまり、F1〜F3の組み合わせ、F1〜F4の組み合わせ、……というように吟味していく。
  3. このうち以下の条件に当てはまるものを選択する。
    1. 最も対象ストアファイル数が多い
    2. もしストアファイル数が同じものが複数ある場合、最もファイルサイズが小さい


これにより、バルクロードを用いている環境でも無駄なIOを生じることなくマイナーコンパクションを行うことができるようになりました。
この機能は、プラガブルコンパクションポリシーという HBase 0.96 から導入された新しい機能を前提として実装されています。(HBASE-7516)


今後、より効率のいい、あるいは特殊な状態に特化したコンパクションポリシーなどが実装されていくことでしょう。

おまけ: CDH の話


CDH5 では HBase 0.96 ベースになると思われますので、Exploring Compaction はデフォルトでオンになっています。
実は CDH4 でも使用することができます。CDH4.4 で、HBase 0.94 に Exploring Compaction をバックポートするパッチが入っています。(HBASE-8283)

githubのコミットログ


HBase 0.94 にはプラガブルコンパクションポリシーがないため、コンパクションのコードにそのまま追加しています。
デフォルトはもちろんオフです。
hbase.hstore.useExploringCompation を true にすると使うことができるため、興味のある人は試してみてください。

2013年夏のプログラミング・シンポジウム ビューティフルデータ(3) 午後2 #spro2013

関連リンク


(講演者の方は敬称略)

並列データ処理基盤を用いた並行バグ並列検査方式の検討 荒堀喜貴(東京工業大学)


目的: 並行バグ検査の高速化(並列化)

背景

前提とするプログラム実行モデル

  • 複数スレッドが共有メモリを並行アクセス
    • 並行 = 並列 + 擬似並列
    • スレッド操作は fork/join, lock/unlock, wait/notify
    • メモリモデルは Sequencial Consistency を仮定しない
事例
  • MozillaApacheのケース
    • Concurrency 並行処理のバグは、Mem メモリ操作のバグや Sem 意味依存のバグに比べて遥かに少ない

並行バグの検査に特化した専用ツール

競合解析を基にきわどいスレッドインタリーブを合成
Maple: Active Scheduling


イベント履歴に基づく競合解析
アクセスイベントeを5つ組として定義
メモリオブジェクト
スレッドIDロック集合



この方式の問題

  • イベント履歴に基づく競合解析の問題
    • 複数スレッドによるイベント履歴操作衝突で高オーバヘッド
    • 大規模分散データ処理技術の適用可能性が不明


マルチコアMapReduceによる競合解析

「リアルストレージワークロード特徴抽出のためのデータ収集蓄積技術」大江和一(富士通研究所)


ストレージのワークロードを自分たちで収集
2007.10 〜 2010.12
継続してログ収集ができたのは、最後の1.5年間


収集を行ったストレージシステム
スケールアウト型分散ストレージシステム
ワークロード収集を行った主なストレージシステム
Samba + backup : 35TB 数ヶ月単位のワークロードを収集
Samba 4.4TB (連続1.5年分)
生トレースの保存はあきらめ、1GB / min 単位で統計情報を抽出し、圧縮・保存


統計データの最大サイズ kb / 回 150 50
統計データの最大サイズ gb / 月 6.2 2.1
平均ユーザ数 1000 3000
最大IOPS 1500 2000


平均ドロップ率1%未満
全IOの7割が特定のブロックに集中


「ソーシャルデータを分析・可視化することで見えてくる人間行動」本郷寛(ユーザーローカル)

Twitter: バースト現象。ニュースの拡散性は指数的に減少していく


「単車の虎」に於けるアクセスログ収集・解析手法 今井陽太(Donuts)


データ量

  • 3GB / day
  • 3min 400GB
  • 年間 4.8TB
  • Bzip2 圧縮


なぜBzip2か
お金がないのでストレージ買いたくないから

2013年夏のプログラミング・シンポジウム ビューティフルデータ(2) 午後1 #spro2013

長いので複数記事に分けました。

[招待講演] 製鉄所における大量品質管理データの解析事例と課題 茂森弘靖(JFEスチール)

15年ぐらい製鉄所の新しい設備を作ってた
5年前に研究所に移ってデータ解析しはじめた

  • JFEスチール
    • 東日本製鉄所
    • 西日本製鉄所
      • 福山・倉敷
    • 知多製鉄所


今日は倉敷地区




高炉→転炉→連鋳
これで圧延向けの半製品を作る
そこから各種工程に分かれて様々な製品を作る

  • 顧客数2万社→製品8万種→80万件/月オーダー
  • 設備数 140
  • 通貨工程 5600
  • 生産量 3000万トン / 年
  • 清算業務管理用計算機 Level4
  • 創業間利用計算機 Level3
  • 製鉄所基幹LAN プロセス計算機 Level2
  • 計装DCS LAN ・ 電気PLC LAN
  • デジタル制御装置 Level1
    • 10us 周期など


プロセス計算機ソフト量
2000年ぐらいで 800万ステップ


実装されるモデルの数が飛躍的に増大
蓄積されるデータの量は飛躍的に増大


鉄鋼製品の特性
引張強度 200 - 1500 MPa
すごい幅が広い


鉄鋼製造プロセスの特長
巨大装置産業
注文に基づく清算が基本
多品種・少ロット清算へ対応可能
多くの工場・プロセスを経由
etc.




鉄鋼製品の品質指標

  • 材質
    • 最も重要な品質指標
    • 強度
      • 引張強度
      • 降伏点
      • 伸び
    • 靭性
      • 吸収エネルギー
      • 遷移温度
    • 磁気特性
      • 鉄損
  • 寸法
  • 形状
    • 板クラウン
    • 平坦度
    • 平面形状
  • 表面品質


品質管理業務フロー

  • お客様から注文
    • 要求材質
      • 強度
      • 靭性
  • 品質検討
  • 受注可否判断
  • 製造条件
    • 化学成分
    • 加熱条件
    • 圧延条件
    • 冷却条件


製造条件から品質(材質)を精度良く予測する手段が必要

材質予測モデルの概要
  • 冶金プロセスと製造プロセス
  • 金属組織の変化をオンラインで解析するのは非常に困難


局所回帰モデル
要求点に近い事例で回帰分析


材質予測モデルのデータセット 約10,000
生産サイクルに合わせる
FIFOで更新


微量金属の強度への寄与
局所回帰モデルによって、偏回帰係数の変化を計算
飽和現象がうまく表現できた

  • 従来手法とその問題点
    • 近い事例での検索
    • 線形回帰式で材質予測
    • 設計負荷が高い
    • 精度が悪い


品質設計問題の定式化
2次計画問題を逐次解く
多目的最適化問題


データマイニングツールのビジュアルプログラミングを利用
数理システムの Visual Mining Studio



多変量統計敵プロセス管理


各操業条件の実績値が互いに相関をもって連動することに着目
各操業条件データを連動する方向をもとに整理(主成分分析)し、2つの変数を監視


相関しているはずが、逆相関の結果を検出する
単に元の変数だけ見てるとわからない

T2統計量
製造仕様の変更、実験材投入など
人為的バラつき

Q統計量
センサー異常、機器故障など
突発的バラつき


従来の監視者の業務
管理データ 1000超
データ抽出・編集作業 2時間/工場

MSPCによる解析
基準データ(異常のない通常操業のデータ)
実績・評価用のデータ

それを解析してT2やQ統計量を出す

MSPCにより原因候補を抽出


10年前は懐疑的な人が多かったが、そういう人は10年間で会社辞めてってるので……

Q. どれくらいきれいなデータでやってるのか?(PFI 比戸さん)
A. 欠損データは除くようにしている
このデータはこの範囲にないといけないはずだというテーブルを持っている
3σより外れたものは削除している
試行錯誤の中で導入している

「コロケーション・パーチェスビッグデータの対応分析クラスタリングによる類似地域推薦システム」大槻明(東京工業大学)


Twitterから位置情報(コロケーション情報)その中でも市区町村の情報と「どこで何を買ったか」(パーチェス情報)を取得
これを2部グラフとしてとらえ、対応正を類似尺度としたクラスタリングを行う

クラスタリングの結果生成される類似地域を可視化
未完成


先行研究
計量書誌学とModularity
約3万件のデータマイニング系論文データを可視化したイメージ
計量書誌学: 論文引用の研究
http://ja.wikipedia.org/wiki/%E8%A8%88%E9%87%8F%E6%9B%B8%E8%AA%8C%E5%AD%A6


Modularity Qによるクラスタリング
モジュラリティ: コミュニティ分割時の評価関数
モジュラリティ値が高いときにグループ分割をすれば、
グループ(モジュール)内でのつながりが密な状態で、グループ外とのつながりが疎な状態ができる

Modularity はリンク無制限のネットワークには使うことができるが、2部グラフには使うことができない

Modularity Qの2部グラフへの応用(先行研究)
Barber のQb、村田のQm、etc.


Twitterからのデータ取得
対象期間: クリスマス
2012/12/22 - 25

取得件数: 1,083

使える情報: 731

パーチェス情報
どこで買ったか
@つきなどで位置情報があるものは自動抽出、ないものは手動抽出

何を買ったか
Chasen係り受け抽出

Uppertail法による階層クラスタリング
→x-means法へ

kmeans をつかて2分割を繰り返すが
BIC(ベイズ情報推定)を使う










ストリーム解析処理再訪〜HPCの観点から〜 秋岡明香(明治大学)


研究の目的

  • ストリーム解析処理の挙動解析とモデル化
    • データインテンシブとは根本的に何が違うか
  • ストリーム解析処理のベンチマーク


データインテンシブは write once read many
ストリーム解析は write once read once


データインテンシブ
データアクセスの高速化がアプリケーション高速化の鍵!


ストリーム解析処理
データアクセス高速化してもちっともうれしくない
高速化戦略を見直さないといけない


ストリーム解析処理の一班モデル(1)
「流れてくるデータをフェッチする。余す所なくフェッチする」


流れてくるデータ→処理1→スケッチ
処理1: 非常に軽い処理じゃないとダメ
スケッチ: キャッシュのような記憶領域
処理2: スケッチからデータをとって解析する。DBなどに叩き込む
処理3: DBなどから取り出して解析する。


処理1〜スケッチ〜処理2 の高速化が課題
スケッチはデータ依存・処理依存


ストリーム解析処理の一般モデル(2)
データフェッチ + スケッチ read → 処理1 → スケッチ write → スケッチ read → 処理2

n番目のデータを処理するプロセスと同時に、n + 1 番目のデータを処理するプロセスも必要


タスクグラフ
アプリケーションのデータ依存や制御依存、計算コストなどを模式化した有向グラフ
スケジューリングアルゴリズムの評価時など対象アプリケーションとして擬似的に使用


実行時間見積もりに関して
計算対象のデータ量等で実行時間の大きな変動が起こりうる
Min-Summaryのしきい値再計算など
平均値による実行コストの見積もりは意味なくなるかもしれない


too many cores の時代到来?