Audrey Watters「大規模データのスクレイピング、クリーニング、マネタイズ」

o'reilly radar 2011.5.11のエントリ

Scraping, cleaning, and selling big data - O'Reilly Radar

スクレイピングで金を稼ぐことを模索してる会社infochimpsのCEO、CTO、ビジネス開発マネージャを呼んだ
このビジネスモデルの法的なリスクと技術的な面について突っ込んでみました
という主旨のエントリ
スクレイピングで稼ぐモデルとしては、技術を大企業に買ってもらうパターン（ex. Yahoo inc.によるDapper買収）しか知らなかった自分には勉強になった
- あと、まるごとrssのfeedのようにアフィリエイト広告入れるとかもあるが
scraperwikiの存在を知ることできてよかった
- ruby/python/phpのスクレイピングコードをブラウザ上で実行してviewで結果確認したり、出力をcsvでDLしたりコードのver.管理とか他ユーザのコードをforkしたりできるサービス
最後の方はセールストークが多い

以下斜め読んだ内容

Infochimps
- Austinのスタートアップ
- 2008年にtwitterからスクレイピングした大規模データを販売しようとしてた。が物言い入って頓挫
- scrape of Twitter data
infochinpsが最近マーケットプレースをオープン
- 10,000セット以上の大規模データの販売を始めた
- データの出典は色々。スクレイピングして作ったデータとそうでないデータはある
infochinpsがやっているデータのスクレイピング・クリーニングおよび大規模データの販売は面白いトピック
- 法的にも技術的にも
infochimpsのCTOとCEO呼んで質問ぶつけてみた

Ｑ：データをスクレイピングすることの法的な意味合い

CEO曰く
- ３つの領域に分けれる。copyright、利用規約(term of use)、trespass to chattels（動産への不法侵害）
- copyright
  - アメリカの法律だと。
  - オリジナルな著作物を許可なくコピーすることは禁止されてる
  - 事実・アイディアに著作権はない
  - ある事実の表現やレイアウトそれ自体には著作権は発生する可能あり
  - オリジナリティがあれば著作権は発生しうる
  - 例えば晩飯のレシピ。これは著作権を主張できない
    - レシピ本。あるテーマに基づいてセレクトされたレシピ本なら著作権が発生しうる
  - もっとスクレイピングに結び付いた例。今度はNYタイムズのブログ記事
    - 投票率が降順でパーセント単位で確認できる表が記事に入っているとする
    - 投票率のデータ自体は自由にスクレイピングできる
    - この記事全体をスクレイピングする場合は、フェアユースの範囲内であることを守らないといけない
- 利用規約
  - たいていのウェブサイトは利用規約ページがある
  - ウェブサイトのコンテンツの利用可能なケースが書かれてる
  - youbtubeの利用規約だと、著作権持ってないコンテンツのアップロードはNGになってる
  - 利用規約は契約法がベースだが強制力は米国法のグレーゾーン
  - スクレイピングする側にとっての利用規約の存在がもたらすリスク
    - 利用規約はサイトごとにバラバラ過ぎる。
    - 利用規約は予告なしにコロコロ変わる。
    - twitterの最近の利用規約変更は第三者がtweetを外部にため込むことがどういう理由であれ難しくなった
    - What has Twitter become
- trespass to chattels
  - スクレイピング業者が対象サイトへ与える負荷がもたらすリスク
  - 短時間に無数のアクセスをして更新データを取得しようとするのは、DoS攻撃と同じになる
  - スクレイピング業者がサイト側から彼らの財産侵害（trespass to chattels）をしてるとして訴えられるリスク
  - この辺のリスクは、巡回頻度をコントロールすることで回避できる

Ｑ：スクレイピングでデータ収集することの技術的な困難

CTO（Flip Kromer）曰く
- スケーリング、メタデータ、歴史的経緯の３つの問題に分かれる
- スケーリング
  - 大規模のデータを抱えるということに付きまとう問題
  - １つのディレクトリに数千万ファイルをあるという状況がもたらす問題
- メタデータ
  - メタデータがデータ・プログラム双方で普及していない
  - 社内でメタデータを記述する言語を開発してる。成長したらオープンソース化する予定
- 歴史的経緯
  - 統計学者はSPSSラブ
  - ウェブ屋ならRDF/XML
  - クォンツならMathematicaラブ
  - みんながこれだっと言えるフォーマットがない
目立たないが最大の技術的問題
- 例えばエンジニアが「1998年8月6日のAustinの午後の気温」を知りたいとき
- 明白な答えは「超暑い」。当然この答はNG
- 気温を測定してる機関はAustin内部にはたくさんあり公表してる
- それぞれが出すデータにはある頻度で間違いがある
- 記録されたデータも時間的空間的バラつきがあるので均したりしないといけない
- 時間を測定する正しい方法はダース単位でありそれぞれの間で互換性がない
  - うるう秒leap secondの扱い、自転速度と1日の長さの影響の加味、とか

Q：大規模データのmarketplaceが大規模データを扱うスタートアップの方向性をどう変えるか

ビジネス開発マネージャNick Ducoff曰く
- 「古い」と言われるだろうが学校で学んだ比較優位の法則が関係してくる
- Michael Jordanは才能を放置せずバスケに力注いで大金を手にした
- ウェブサーバのフロントエンドの開発してるエンジニアがデータベースをチマチマ触ってるのはもったいない
- そういったエンジニアがもっとも注力すべき領域であるアプリ開発へ専念できるようにする。これがinfochimpsが提供してるもの
  - エンジニアがデータを見つけやすく・使いやすい形で提供する
- infochimpsのターゲットにしてるスタートアップは、開発スタックのいくつかに注力してるタイプのスタートアップ
  - こういうスタートアップにはクラウドサービスやってる大企業にかれらの保有する開発スタックの１つとして買収してもらえるはず
  - 例えば。HerokuはSalesforceに買収。CloudkickはRackspaceに買収。
- スクレイピングツールを提供するタイプのスタートアップ
  - ScraperWiki
  - Junar
  - これらのサービスを利用してスクレイピングからデータ抽出・整形まで行える
- APIをホスティングできるサービス
  - Mashery
  - Apigee
  - 3scale
- この手のサービスをinfochimpsはエンジニアが見つけやすく利用しやすくできる
- エンジニアはinfochimpsやこの手のサービスを使ってアイディアが浮かんだら数時間で（数日とか数週間とかではなく）ローンチまでこぎつけることができる