ソーシャル・ニュースリーダー「crowsnest」におけるtwitterのリアルタイム解析と情報整理の未来...
TRANSCRIPT
ソーシャル・ニュースリーダー「Crowsnest」におけるTwitterのリアルタイム解析と情報整理の未来
浜本 階生
12年1月30日月曜日
自己紹介• 浜本 階生（はまもと かいせい）
• @kaiseh
• ブログ解析系サービスなどを開発TopHatenar, Blogopolis
12年1月30日月曜日
今日主張したいこと
• ソーシャルWebにも、情報整理のアーキテクチャが必要である
• そのアーキテクチャを実装するのは、人を暗黙的タームとする検索エンジンである
12年1月30日月曜日
前提
• 今日のプレゼンでは、情報＝Webページとする。Twitterにおいては、URLをツイートする行為によって情報への言及がなされる
12年1月30日月曜日
改めて提起
• 「Twitterには、情報整理のアーキテクチャが必要である」
• Twitterに溢れる大量の情報の中から、個人の興味・関心に合致する情報を抽出、配信する仕組み
12年1月30日月曜日
考え得る反論
• Twitterの機能自体が情報整理のアーキテクチャなのでは？
• フォロー（サブスクリプション）
• RT（伝播）
12年1月30日月曜日
僕の考え• 非対称フォローやRTといったTwitterの仕組みは、 確かに、 情報整理の素地として非常に優秀。しかし、あくまでも素地である
• ハイパーリンクを素地としてGoogleが生まれたように、Twitterにも新たなレイヤーが必要
12年1月30日月曜日
その考えをもとに
• 情報整理のためのサービスを開発
• 大量のツイートからURLを収集
• 重要度を計算
• パーソナライズして配信
12年1月30日月曜日
ここで提起
• 「Crowsnestは検索エンジンである」
• 検索エンジンと見なすことで、情報整理アーキテクチャとしての把握が（思想的にも技術的にも）容易になる
12年1月30日月曜日
比較: URLの発見✴検索エンジン
• ハイパーリンク（ページからURLへのリンク）
✴Crowsnest
• ツイート（人からURLへのリンク）
12年1月30日月曜日
比較: 転置インデックス
✴検索エンジン
• <形態素, その形態素を含む文書IDの一覧>
✴Crowsnest
• <ユーザID, そのユーザがツイートした文書IDの一覧>
12年1月30日月曜日
比較: クエリ✴検索エンジン
• キーワード（形態素に分解）• 明示的✴Crowsnest
• ソーシャルグラフ（ユーザIDに分解）
• 暗黙的
12年1月30日月曜日
比較: 結果のソート✴検索エンジン
• 良質なページから多くリンクされるURLが高いスコアを獲得
✴Crowsnest
• 良質なユーザ（例: 自分のフォロー先）から多くリンクされるURLが高いスコアを獲得
12年1月30日月曜日
考察
• 検索エンジンとCrowsnestには、その構造に多くの共通点が見られる
• ただし、Crowsnestでは一貫して人がキーになっている
• ソーシャルWebにおいて、新形態の検索エンジンが出現することは必然の流れでは？
12年1月30日月曜日
他サービスの動向
• 新はてなブックマーク（マイホットエントリー）
• Flipboard（Cover Stories）
• Summify
12年1月30日月曜日
新はてなブックマーク
12年1月30日月曜日
12年1月30日月曜日
• ここから、Crowsnestの技術背景の説明に移ります
12年1月30日月曜日
URL付きツイートの収集
• Search API (search.json)
• “http”で検索
• Streaming API (statuses/filter.json)
• “http”でフィルタリング
• Timelines API (statuses/home_timeline.json)
• 登録ユーザのタイムラインを収集
12年1月30日月曜日
収集データ量• 80 distinct URLs / sec
• 6.9M distinct URLs / day
• 2.3 Tweets / URL
• 15.9M Tweets / day
• 初出から72時間経過したURLはアーカイブに移動（インデックスから破棄）
12年1月30日月曜日
Crowsnestの特性と求められるパフォーマンス (1)
• 通常の検索エンジンでは、文書をインデックスに登録する時点で、文書の持つターム（＝形態素）が確定している
• これに対して、Crowsnestでは文書の登録後にターム（＝文書への言及ユーザ）がどんどん増えていく
• Apache Solrなど既存の検索エンジン実装は、この特性にマッチしない
12年1月30日月曜日
• 通常の検索エンジンでは、クエリが高々数個～数十個のタームに分解される
• 「情報整理の未来」→ 情,情報,報整,整理,理,の,未,未来,来（bigramの場合）
• Crowsnestではソーシャルグラフがクエリとなるため、ターム数が跳ね上がる
• 1000人をフォロー → ID1, ID2, ... , ID1000
Crowsnestの特性と求められるパフォーマンス (2)
12年1月30日月曜日
エンジンの独自開発
• Javaで実装
• インメモリ型インデックス• 分散検索• コミット不要、即時検索可能
12年1月30日月曜日
何をメモリに載せているか
• URL→文書IDの辞書
• URLのタイトル
• URLにリンクしているツイート一覧
• 転置インデックス• （プロセス再起動時のロストを避けるため、一定頻度で永続化）
12年1月30日月曜日
メモリ使用量の削減
• 徹底的なプリミティブ型の使用
• データ圧縮
• 文書IDの32ビット化
• etc
12年1月30日月曜日
徹底的なプリミティブ型の使用
• fastutil（プリミティブコレクションライブラリ）を使う
• Map<Integer, Integer>ではなくInt2IntMapを
• オブジェクト配列を1つの巨大なバイトブロックにエンコード
• オブジェクト毎のオーバーヘッドを削減
12年1月30日月曜日
データ圧縮• ツイート本文の圧縮
• URLタイトルとの共通部分文字列抽出
• 言語別に事前サンプリングしたツイート本文からハフマンテーブルを構築しておき、その固定テーブルを使ってハフマン圧縮
• 整数列の圧縮（Simple9）
• MessagePackによるシリアライズ
12年1月30日月曜日
文書IDの32ビット化
• 本来、64ビットなければユニーク性を保証できないが...
• 初出から一定時間経過した文書はインデックスから削除するため、32ビットでも事実上ユニークなIDとして扱える
12年1月30日月曜日
Fetcher
Indexer
In-MemoryIndex
Fetcher
Indexer
In-MemoryIndex
Fetcher
Indexer
In-MemoryIndex
MySQL
Web
12年1月30日月曜日
Crowsnestの今後
• iOSアプリ
• クリックログからの学習• ツイートしたURLの伝播の統計から、ユーザの情報発信者としての信頼度を分野別に算出
• インタレストベースのソーシャルグラフ形成を支援
12年1月30日月曜日
まとめ• ソーシャルWebに、情報整理のレイヤーを乗せたい
• そのアーキテクチャは、「人」をベースとしながら、奇しくも検索エンジンと類似している
• サービスも出揃い、これから面白くなるはず！
12年1月30日月曜日
