大規模web情報処理 - naist · 概要 29/10/2015 2 1. ビッグデータとしてweb 2....

大規模Web情報処理

岩爪道昭（独）情報通信研究機構

ユニバーサルコミュニケーション研究所サイバー攻撃対策総合研究センター

[email protected]

ビッグデータアナリティクス第4回

概要

29/10/2015 2

1. ビッグデータとしてWeb2. Webクローリング

3. Webリンク解析

4. 大規模Web情報処理の実例

5. Webの未来

6. 演習およびレポート課題について

Michiaki Iwazume, NICT, all right reserved.

1. ビッグデータとしてのWeb

11/13/2013 Michiaki Iwazume, NICT, all right reserved. 3

• 2006年全世界のWebページ総数537億と予測(by 山名）• 2008年 Googleが把握するURL数が1兆を突破（by Google)• 2010年全世界のWebの情報量は、800EB (0.8ZB)（by IDC）• 現在？？？ (もはや誰も正確な数を把握できていない）


Webは、我々とって最も身近で、社会・経済にとって欠くことのできない『ビッグデータ』のひとつ

ビッグデータとしてのWeb

Webは何故ここまで発展したのか？

Michiaki Iwazume, NICT, all right reserved. 5

Webとは？


•Webの起源 Invented by Tim Berners‐Lee in 1989 First Web Browser – October 1990 First Web Server – November 1990T.B. Lee presents the W3 in CERN ‐ 1993W3C ‐ 1993

• Tim Berners Lee’s Vision (T.B.Lee, 1998):

“The dream behind the Web is of a common “The dream behind the Web is of a common information space in which we communicate by sharing information. Its universality is essential: the fact that a hypertext link can point to anything, be it personal, local or global, be it draft or highly polished. .

Webとは？ [T.B.L et al 1994]


• A system of interlinked hypertext documents accessed via the Internet.

• With a web browser a user views web pages that may contain text, images, videos, and other multimedia and navigates between them using hyperlinks.

Webの基本アーキテクチャ

[T.B.Lee et at al 1994]


The Web is an information space in which the items of interest, referred to as resources, are marked up by a set of rules (i.e. HTML),identified by global identifiers called Uniform Resource Identifiers (URI) using the Hypertext Transfer Protocol (HTTP).

世界初のWebページ

http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html


世界初のWeb検索ディレクトリ

http://www.w3.org/History/19921103-hypertext/hypertext/DataSources/bySubject/Overview.html


Web検索システムの歴史（90年代）• Characterised by large indexes but crude retrieval techniques

• World Wide Web Worm (WWWW), 1993– First Search Engine– Indexed titles and headers only

• Yahoo, 1994– Human edited directory (still is!)

• WebCrawler, 1994– First search engine to search the text of the web page

• AltaVista, 1995– Natural language querying with Boolean operators– Huge index


20/11/2012 12

初期のGoogle


13

初期のGoogleの構造

[L.Page and S. Bring 1998]


1414

初期のGoogleの構造

[L.Page and S. Bring 1998]

20/11/2012 Michiaki Iwazume, NICT, all right reserved.


何故グーグルはここまで成功したのか？

何故Webはここまで成功したのか？

• 単純（simple）• ネットワーク（networked）• 拡張性（extensible）• 頑健性（tolerant）• オープンスタンダード（open

standards)• 無料・安価（free or cheap）• 面白い（fun）

：


2. Webクローリング


Webクローラはどのように動くのか？


シンプルなクローリング手順• Initialize queue with URLs of known seed pages（初期化）

• Repeat（繰り返し）

– Take URL from a queue– Fetch and parse a page–extract URLs from the page–Add URLs to the queue (URL frontier)

※ちゃんとリンクが張られているという仮定


シンプルなクローラのイメージ

Web

URLs frontier

Unseen Web

Seedpages

URLs crawledand parsed

20


シンプルなクローラの問題• 1プロセス、１台のマシンでは間に合わない

– 全ての処理を並列化する必要がある

• 悪意のあるページへの対応

– スパムページ

– スパイダートラップ（動的生成ページ）

• その他

– 収集先サイトのレイテンシ（遅延）／バンド幅変化

– Webサイト管理者側ポリシー問題

• どれくらいの深さまでクロールを許すか？

– ミラーサイトや重複ページの存在

• クローラのお行儀良さ（politeness)

21Michiaki Iwazume, NICT, all right reserved.

実際的なクローラに必要な機能• 行儀良さ: 許可されたページのみの収集robots.txt尊守

• ロバスト性：悪意のあるページへの対処

• 並列分散性：複数の計算機、プロセッサ上で並列分散化してクローリングプロセスを実行

• スケーラビリティ: 計算機資源を段階的に追

加することでより大規模な収集が可能なアーキテクチャ


実際的なクローラに必要な機能• パフォーマンス: 利用可能な計算機および

ネットワーク資源を大限に活用する

• 効率性：よいページを優先的に集める

• 継続性 : 更新ページ、新規ページの継続的な収集

• 拡張性: 新しいデータへの適用


より実際的なクローラ

URLs crawledand parsed

Unseen Web

SeedPages

URL frontier

Crawling thread

Sec. 20.1.1

24


修正されたクローリング手順1. Pick a URL from the frontier2. Fetch the document at the URL

– DNS resolution

3. Parse the URL– Extract links from it to other docs (URLs

4. Check if URL has content already seen– If not, add to indexes

5. For each extracted URL– Ensure it passes certain URL filter tests– Check if it is already in the frontier (duplicate

URL elimination)25Michiaki Iwazume, NICT, all right reserved.

修正されたクローラアーキテクチャ

WWW

DNS

Parse

Contentseen?

DocFP’s

DupURLelim

URLset

URL Frontier

URLfilter

robotsfilters

Fetch

Sec. 20.2.1

26Michiaki Iwazume, NICT, all right reserved.

Robots.txtの記述例“searchengine”という名前のクローラ以外、いかなるクローラも“/yoursite/temp/”で始まるURLにアクセスしてはならない

User-agent: *

Disallow: /yoursite/temp/

User-agent: searchengine

Disallow:


28

■ビッグデータとは？

Volume

VelocityVariety

サイズおよび数における⼤規模性サイズおよび数における⼤規模性

処理のリアルタイム性処理のリアルタイム性データの多様性データの多様性

ビッグデータを特徴付ける「３つのV」大サイズの動画から、小サイズだが無数のtwitterまで

高頻度で生成され続けるデータ

定型・非定型を問わない多種多様なデータ

ビッグデータについておさらい

29

ビッグデータをクロールするには？

ビッグデータ時代のクローラ

30

■ Volume大量（数）のデータを収集・格納

① 億を超える件数のURLを保存・管理し、高速に検索⇒クロール対象URLの抽出処理、収集済みURL

のチェック② 効率よくデータを収集するスケジューリング

⇒限られた時間・リソースの範囲内で、必要とするデータを収集

⇒特定のサーバにアクセスが集中しない制御③ Near Dupulicateなページを判別して除外

⇒不要ページの保存によるストレージ圧迫回避


31

■Velocity収集率（単位時間あたりの収集量）を向上

① 非同期で分散してクロール⇒shared nothingな構成とし、ノードの追加によ

りスケーラビリティを確保② 更新間隔を推定し、更新データのみを効率的に収集

⇒収集済みページに再アクセスして初めて更新の有無が判明するため、無用な更新前のアクセスは収集率の低下原因

③ ネットワーク帯域を大限に活用＆連続クロール

⇒しかし特定のサーバにアクセスが集中してはならない


32National Institute of Information and Communications Technology

■Variety多様な形式のデータを収集

① HTMLファイル以外のクロール⇒画像・音声・動画ファイル

ストリーミング系（動画）など② 独自API提供サービスのクロール

⇒Twitterなど、個別サービスに合わせてインタフェースを切り替え可能な仕組み

③ SNSなどのソーシャルネットワーク系のクロール⇒個人のアカウントを用いたクロール

なお、これらクロールに関しては、技術的な課題の他に、法的・制度的な問題（著作権やプライバシーなど）にも十分な配慮が必要


33

名称特徴

IRLbot[Lee 2007] サーバ1台構成で41日間63億ページをクロールKVSを利用した高速URL管理やスパム回避機能

UbiCrawler[Boldi 2004] 単一障害点のない完全分散アーキテクチャAgent数に比例するスループット

Mercator[Najork 2001] 分散構成で1日5,000万ページのクロール実績

Socio Senceのクローラ[田村 2008,2010]

更新頻度推定によるスケジューリング二次記憶管理技法について

e‐Societyのクローラ[詹 2010] [森本 2011]

特定言語Webページ収集のフォーカストクローラ時間計算量O(1)でのスケジューリング技法

以上の先行研究は、ビッグデータのクロールにとって有益な成果であるが、クローラ実装は非公開

クローラを扱った先⾏事例

34

項目 Heritrix Nutch

スケジューリング × ×

NearDuplicate × ×

分散クロール × ○

更新間隔推定 × ×

クロール対象 △ ×

拡張性 ○ ○

ドキュメント × ○

名称特徴

Heritrix モジュールの組み換えにより、処理内容を柔軟に変更可能。設定も細かく指定でき、利便性が高い。

Nutch 全文検索エンジンLucene用のインデックスを生成可能。Hadoopを用いた分散

処理によるスケーラビリティあり。

それぞれ完成度は高く、有益なアプリケーション高機能化のためには、コードの解析が必要

オープンソース系クローラ

３．Webリンク解析


Webはどんな構造をしているのか？

36

[B.Broder et al 2000]


• 基本的な考え方– Webのリンク構造に基づく– Webページは”ノード” 、

リンクは、”エッジ“– フォワードリンク（外に出るエッジ）– バックリンク（内に入ってくるエッジ）– ページA、Bは、ページCのバックリンク

（インエッジ）– ページCは、ページA, Bのフォワード

リンク（アウトエッジ）

• 仮定：– A から Cへのリンクを投票とみなす

– 沢山リンクされるページは重要

– ランキングの高いページからのバックリンクは、そうでないページからのリンクよりもスコアが高い

ページランク


ページランク[Bring and Page 1998]• ランダムサーフモデル

– 任意のページを起点

– ランダムウォーク：そのページから出ているリンクの中からランダムに選択、リンク先に移動

– ランダムジャンプ：Web上のあらゆるページの中から１つをランダムに選択肢、そこにジャンプ

– 長い時間が経過すると、サーファーが各ページに滞在する確率、一定の定常状態に収束

（マルコフ過程）

1/31/31/3


ページランクの計算（単純版）

1/Nj1/Nj1/Nj

)( jPr )( iPr

BpiPj j

ji

NPr

cPr

)()(

jN : ページのアウトリングの総数

iBp : ページのバックリンク集合

iPiP : Webページ

C : 正規化係数（定数）

jPiP


ページランクの計算（修正版）

n

cPcrPr ii1)1()()(́

n : 隣接行列の行数


nn

現実のWebグラフは、全てのページがリンクで相互に接続しているとは限らない！→ 単純化されたモデルは計算できない

５１

２

６

７

３

４

演習：Rによるページランク計算


１

２

３４

0 1 1 01 0 1 00 0 0 01 0 0 0隣接行列

有効グラフ（Webグラフ）

library(igraph) #igraphパッケージのセットdg <- matrix(c(+ 0, 1, 1, 0,+ 1, 0, 1, 0,+ 0, 0, 0, 0,+ 1, 0, 0, 0),+ nrow = 4, ncol = 4, byrow = TRUE)

①隣接行列の作成

以下の有効グラフ（Webグラフ）のページランクを計算してみよう

> install.packages(“igraph")【準備】グラフ解析パッケージ“igraph”のインストール



>dg[,1] [,2] [,3] [,4]

[1,] 0 1 1 0[2,] 1 0 1 0[3,] 0 0 0 0[4,] 1 0 0 0

②隣接行列（グラフネットワーク）の描画

>g <- graph.adjacency(dg, mode = “directed”)>plot(g)

#隣接行列dgが正しくセットされたかの確認

#グラフオブジェクトを生成

#plot()でグラフネットワークを描画



>dg[,1] [,2] [,3] [,4]

[1,] 0 1 1 0[2,] 1 0 1 0[3,] 0 0 0 0[4,] 1 0 0 0

> page.rank(g, directed = TRUE)$vector[1] 0.3063548 0.2405390 0.3427680 0.1103382

> page.rank(g, directed = TRUE, damping = 1.0)$vector[1] 0.30303030 0.24242424 0.36363636 0.09090909> page.rank(g, directed = TRUE, damping = 0.2)$vector[1] 0.2800517 0.2412753 0.2654028 0.2132701

③ページランクの計算

#隣接行列dgが正しくセットされたかの確認

#page.rank関数による計算

④正規化係数c(damping値）によるスコアの変化#c=1.0

#c=0.2

4. 大規模Web解析の実例


Web情報分析システム“WISDOM”

発信者の分析、評価情報の抽出、対立する情報の抽出などの分析が可能に

Web情報分析システムWISDOM： http://wisdom-nict.jp/

～ 10億を超える日本語Webページに対する情報分析～

世界初

45

WISDOM Demo


47

情報分析システムWISDOMを支える情報基盤

計算機

サーバ：252 ノード (1156 CPU) 4 コア, 8 GB メモリ, 1.5–2 TB ローカルストレージ

360TB ファイルサーバ (NAS + GPFS)

Webクローラ

クローリング速度: 大1000万ページ/日収集URL総数: 17億件以上

Web アーカイブ

HTML 文書: 10億ページ

検索インデクス: 1.2億ページ

情報分析システムWISDOMを支える情報基盤

情報分析システムＷＩＳＤＯＭを支える計算機基盤

49

WISDOMを支える計算機基盤・億単位の超大量データを並列高速処理するためのシステム構成

・現在世界大４位の日本が誇るスパコン・ＴＳＵＢＡＭＥ（東工大）にWISDOM

の分析エンジンを移植し、解析を試みたところ・・・

取り扱うファイル数が多過ぎて、ファイルシステムがダウン（松岡先生にお叱り

を受けた・・）

ファイル数を減らして実行してみたところ、ファイルのアップ／ダウンロード等

事前事後作業も含め１億ページの解析に約２ヵ月を要した（解析処理のみで

あれば２～３週間程度）

→民間のクラウドサービスではデータの送受信にコストがかかり過ぎ使いづらい

・CPUの演算速度を重視したスパコン（PCクラスタ）では、データの読み書き

による遅延（I/Oレイテンシ）ボトルネック

50

・クローラ出力のHTMLファイルを保存し、IDやクロール日時をキーとする管理DBを作成。

・リンク解析用のリンク情報ファイルを作成する。

・言語解析対象ページを選択し、キャッシュHTMLの形式で登録。

・登録した各ページから、言語解析済みデータとしてWeb標準フォーマット、及びInlink情報をまとめたアンカー情報ファイルを作成。

・Web標準フォーマットおよびアンカー情報ファイルから検索タームを取り出したTERMファイルを作成する。

・検索対象の1.2億ページを選択し、そのTERMファイルから検索インデックスを作成。

・1回のクロールで収集したWebページを1ファイルにまとめて出力。

・抽出されたリンクURLがURL DBに登録される。

・検索時はインデックスを検索し、適合する1000ページを分析対象として選択。

51

リソースの制約および検索結果の品質のためクローラに収集されたデータは段階的（バッチジョブ的）に検索対象として選択・解析

WISDOMにおけるデータ管理の現状と課題

現状のアーキテクチャではスケールアウトしない

52

• スケーラビリティ• クローラ、ＵＲＬＤＢ、クロールデータプールがスケールアウトしない

• データ冗長性

• データが冗長化されていないためハードウェア障害に弱い（貴重な情報資源を消失するリスク）→ 仮想分散ストレージの必要性

• リアルタイム性：• クローリングから分析サービスまで３日かかる• ＴＳＵＢＡＫＩのインデックス更新

（１ページ単位のインデックス更新ができない）• データ管理：インデックス更新

• 複数拠点による並列分散クローリング／データ管理• 通常のクローラで取得できないデータへの対応

• Twitterのようなストリームデータ（マイクロブログ）への対応（クローリング、解析）

• ＳＮＳサイトのクローリング• データ落ちしたスレッド系サイト

技術的課題・チャレンジ

リンク解析によるSPAMページ判定• 主に金銭的、経済的理由から検索エンジンの

ランキング上位にあげるために作成（主に自動生成）される悪意のあるページ

• SPAMページの種類

– コンテンツスパム

– リンクスパム

– なりすまし


これは何のページ！？

Wikipediaへのリンク

実は、Wikipediaからのコピペ

一見、文章はまとも？


Link Structure of the Site

55

対象ページ

対象ページ

全てが同様にコピペによる自動生成ページ


WikiPedia

リンク解析によるSPAMページ[Leon2010]• スパム判定: Webグラフ中の強連結構造を抽

出(Recall=90.9%, Precision=73.2%の精度)• ページランクによるランキング

クロール文書

Webグラフ作成

スパム判定ページランク

判定


5. 未来のWeb


There was a second part of the dream, too,

how we can better work together.”

There was a second part of the dream, too, dependent on the Web being so generally used that it became a realistic mirror (or in fact the primary embodiment) of the ways in which we work and play and socialize. That was that once the state of our interactions was on line, we could then use computers to help us analyse it, make sense of what we are doing, where we individually fit in, and how we can better work together.”

Webの未来は?[T.B.Lee1998]



Webの過去・現在・未来eras description Basic value resouce

Pre Web 1980’calculate

The desktop is the platform Computations(No network effect)

Web1.0: 90’sread

Surfing Web: The browser is the platform

Hyper‐linking ofdocuments

Web2.0: 00’swrite

Social Web: The web is the platform Social dimension of linkageproperties

Web3.0: 10’sdiscover

Semantic Web: The data is the platform

URI‐based semantic linkages and data

Web 4.0: 20’sExecute(cyber physical system)

Meta‐computing: The network is the platform web of things (embedded system, RDIF, sensor network)

Connection & production in a global computing system for everything

Web ∞combine all

Almost everything is a web service(?)

New inter‐creativity

新たなWeb：Linked Open Data


6．演習・レポート課題


課題１下記のようなWebグラフ（有効グラフ）のRageRankをRを用いて計算せよ．


５１

８

２

６

７

３

４

９

(a)隣接行列dgを求めよ(b) plot()関数で有効グラフ図を描画せよ(c) 隣接行列のPageRank値を計算せよ(d) damping = 0.2とした場合のPageRank

値を計算し、(c)の結果と比較検証せよ

課題２

urlqueue := (some carefully selected set of seed urls)while urlqueue is not empty:myurl := urlqueue.getlastanddelete()mypage := myurl.fetch()fetchedurls.add(myurl)newurls := mypage.extracturls()for myurl in newurls:if myurl not in fetchedurls and not in urlqueue:urlqueue.add(myurl)addtoinvertedindex(mypage)

以下のクローリングプログラムの問題点とその解決方法について論ぜよ(1000文字以内）


レポートの提出方法課題の記載項目：

–授業名 / 課題番号（“第4回目課題”） / 氏名/ 学籍番号/ 研究室名/ メールアドレス

課題1：(1)隣接行列dgの作成と確認結果, (2)plot(g)で生成したグラフネットワークの画像,(3)page.rank(g)の実行結果、(4)damping値を0.2に設定した際のpage.rank(g)の実行結果,および(3)との違いに関する考察

課題2：1000字以内の考察文

宛先：bda‐[email protected] 件名：BDA‐日付‐学籍番号‐名前 (例：BDA‐20151030‐1251079‐岩爪

道昭) ファイル形式：PDF ファイル名：件名と同じ

提出締切：11/06(金) 12:00 JST


講義日

大規模web情報処理 - naist · 概要 29/10/2015 2 1. ビッグデータとしてweb 2....

Documents