web scrapingによるデータセット構築に関するガイドの多くは、「スクレイパーを書き、結果を保存する」で終わっている。それは簡単な20%にすぎない。難しい80%、つまりデータセットが実際に使えるかどうかを決める部分は、取得(fetch)の周辺にあるすべてのことだ。正しい行を収集できたか、それらが完全であるか、それらが最新であるか、そしてデータの欠落がランダムであってシステマティックではないか、を確認することである。
最後の点は、静かにデータセットを台無しにするものであり、ほとんど誰も書かない点でもある。スクレイプがページの30%で失敗するとき、あなたはランダムな30%のデータを失うわけではない。あなたは特定の30%を失う。より到達しにくく、より防御が固く、より地理的制限がかかっている部分だ。そして残ったものは、完全に見えるが偏ったサンプルである。それで訓練されたモデル、あるいはそれから下される意思決定は、誰にも気づかれないままそのバイアスを引き継ぐ。
これは、実際に通用するウェブスクレイピングによるデータセットを構築するための実践的なガイドだ。パイプラインの各段階、重要な品質の次元、そしてプロキシ層が代表的なデータセットと偏ったデータセットの違いを生む場所について扱う。
「良いデータセット」が実際に意味すること
コードを書く前に、何を最適化しようとしているのかを明確にしておこう。スクレイピングで構築されたデータセットは、次の5つの点で評価される。
完全性(Completeness)。 対象範囲のすべてを収集できたか、それとも反撃しなかった部分だけを収集したか。行の欠落は良くないが、システマティックに欠落しているのはさらに悪い。
代表性(Representativeness)。 サンプルは実際の母集団と一致しているか。製品価格をスクレイピングしていて、トラフィックの多い小売業者ではブロックされ、小規模な業者では通り抜けているなら、「平均価格」は、あなたには見えない方向に間違っている。
鮮度(Freshness)。 ウェブデータは劣化する。先月の価格データセットは今日のものとは別のデータセットだ。各行がどれだけ古いかを把握し、それを更新する計画を持つ必要がある。
一貫性(Consistency)。 すべての行は同じスキーマに従い、同じ単位、フォーマット、エンコーディングを持つべきだ。スクレイピングは乱雑なHTMLから抽出するため、正規化が作業の半分を占める。
来歴(Provenance)。 すべての行について、どこから来たか(ソースURL)、いつ取得したか、どこから取得したか(地理)を記録する。来歴がなければ、後でデータセットをデバッグ、重複排除、更新、あるいは弁護することができない。
これら5つを念頭に置いておこう。以下のパイプラインに関する判断はすべて、このいずれかに寄与するためのものだからだ。
パイプライン、段階ごとに
スクレイピングからデータセットへのパイプラインは6段階ある。それぞれを独自の検証を持つ個別のステップとして扱うべきで、1つの大きなスクリプトにすべきではない。
1. 発見(Discover)。 対象範囲のURLを列挙する。サイトマップ、検索/リスティングクロール、APIインデックス、既知のID範囲などから。この段階が意図した母集団を定義する。これを明示的に書き留めておくこと。それが後で完全性を測る基準になる。
2. 取得(Fetch)。 各URLを取得する。ここでブロック、地理リダイレクト、レート制限、タイムアウトが発生し、データセットのバイアスが生まれる。これについては後で詳しく述べる。品質にとって最も重要な段階だからだ。
3. 抽出(Extract)。 レスポンスを構造化されたフィールドに解析する。防御的であること。レイアウトは変わり、フィールドは欠落し、脆いセレクタは何千もの行にわたって静かにnullに変わる。
4. 正規化(Normalize)。 生の抽出値を一貫した型と単位に変換する。通貨は単一の単位に、日付はISO形式に、空白は除去し、エンコーディングは修正し、カテゴリカル変数は管理された語彙にマッピングする。
5. 重複排除(Deduplicate)。 同じエンティティが複数のURLに現れることが多い(正規版とバリエーション、ページ分割された重複、再掲載された項目)。URLではなく、安定したキーで重複排除すること。
6. 保存と更新(Store and refresh)。 完全な来歴とともに永続化し、その後、データセットが一度きりのスナップショットへと劣化するのではなく鮮度を保つよう、再クロールの頻度を決める。
品質を決める段階:取得
これがこの記事全体の核心的な主張だ。あなたのデータセットの品質は取得段階で上限が決まる。なぜなら、ブロックされたリクエストは単にデータを失うだけでなく、ランダムではないデータを失うからだ。
3つのメカニズムが、取得の失敗をデータセットのバイアスに変える。
ブロッキングバイアス。 対ボットシステム(Cloudflare、Akamai、DataDome)は、価値の高い、トラフィックの多いターゲットを最も積極的に保護する。あなたのスクレイパーがデータセンターIPから動作していて、そこでブロックされるなら、あなたのデータセットは最も重要な行を体系的に欠いたまま、簡単な行だけを保持することになる。結果は、より小規模で防御の薄いソースへと偏り、それでも何千もの行を得たため完全に見える。(仕組みについてはスクレイパーがブロックされる理由を参照。)
地理バイアス。 多くのサイトは、訪問者の位置に応じて異なるコンテンツ、価格、在庫状況を提供し、IPに基づいて静かにリダイレクトまたはローカライズする。すべてのリクエストが1つの地域から発信されている場合、あなたのデータセット内の地理によって変化するすべてのフィールドは、あなたが捉えたと思っているグローバルな現実ではなく、その単一の視点を反映している。「グローバルな製品在庫状況」を1つの国からスクレイピングすると、実際には1つの国の視点を捉えただけなのに、グローバルとラベル付けしてしまうことになる。
レート制限バイアス。 ターゲットがあなたをスロットリングするとき、素朴な対応は速度を落とすか、応答の遅いページ(多くの場合、重くデータの豊富なページ)を諦めることだ。結果として、速くて軽いページを過剰にサンプリングすることになる。
3つすべての解決策は同じだ。実際のユーザーのように見えるIPのプールを通して、適切な場所から取得することで、カバレッジが到達しやすいものに偏るのではなく、完全かつ均等になる。
プロキシ層がなぜ単なる配管ではなく、データ品質の判断であるのか
これが、データセット構築においてレジデンシャルプロキシネットワークが特に重要である理由だ。単に「ブロックされない」以上の意味を持つ。
完全なカバレッジ。 レジデンシャルIPは、実際の消費者接続の信頼プロファイルを持っているため、データセンターIPが到達できない防御されたターゲットも通り抜けられる。これがブロッキングバイアスのギャップを埋め、簡単な行だけでなく難しい行も収集できるようにする。
意図的な地理カバレッジ。 国、州、市レベルのターゲティングにより、各市場を意図的にサンプリングし、各行にどの視点から来たかをラベル付けできる。偶然の単一視点ではなく、地理が隠れた交絡因子ではなく列となる、制御された多地理データセットが得られる。これが「価格をスクレイピングした」と「12の特定市場から見た価格を、行ごとに記録してスクレイピングした」の違いだ。
規模に応じた均等なサンプリング。 大規模なプールを通じてローテーションすることで、リクエストが分散され、単一のIPがレート制限に引っかかることがなくなる。これにより、速いページを過剰にサンプリングし、遅くデータの豊富なページを過小にサンプリングすることを防げる。
端的に言えば、プロキシ層は、あなたのデータセットが代表的なサンプルなのか、それとも便宜的なサンプルなのかを決める場所だ。データセット構築においては、それは配管の詳細ではなく、方法論上の選択だ。(より広範なインフラの視点については、機械学習のためのプロキシインフラを参照。)
鮮度:データセットは名詞ではなく動詞である
一度きりのスクレイプはスナップショットであり、スナップショットは腐る。まず、静的なデータセットを構築しているのか(特定時点の調査には適している)、それとも生きているデータセットを構築しているのか(価格、在庫、リスティングなど、変化するものには必要)を事前に決めること。
生きているデータセットの場合:
- データの変化速度に合わせた再クロール頻度を設定する。 変動の激しい価格は毎時、カタログのメタデータは毎週、変化の遅い参照データは毎月といった具合に。
- 完全な再スクレイプではなく、増分更新を行う。 変化を検出し(ETag、last-modified、コンテンツハッシュ、リスティングの差分)、その部分だけを再取得する。より安価で、より速く、ターゲットへの負荷も軽い。
- すべての行に取得タイムスタンプを刻印する。 下流の利用者が鮮度でフィルタリングでき、あなたが古さを測定できるようにするため。
鮮度もまたカバレッジの問題である。更新クロールが毎回同じ防御されたページでブロックされる場合、それらの行は古くなったまま、簡単な行は最新のまま維持され、時間の経過とともにバイアスが再導入される。解決策は同じだ。
重複排除と正規化、データセットの成否が決まる場所
生のスクレイプデータは汚れている。2つの段階でそれをクリーンにする。
スキーマへの正規化。 まず目標のスキーマを決め、すべてのソースをそれにマッピングする。通貨は単一の単位に、日付はISO 8601に、「1,299 units」のような文字列から数値を解析し、テキストをトリムしてunicode正規化し、カテゴリカル変数は管理された語彙にスナップする。不整合な正規化は、スクレイプされたデータセットが技術的には完全でも分析的には使い物にならなくなる最も一般的な原因だ。
URLではなく、安定したキーで重複排除する。 同じ製品、人物、あるいはレコードが日常的に複数のURLに存在する。安定したアイデンティティ(SKU、ISBN、正規化された名前+場所、正規URL)から重複排除キーを構築し、重複を崩して最も新しい、あるいは最も完全なバージョンを保持する。生のURLだけで重複排除すると、水増しされたカウントと二重に重み付けされた行が残り、それが静かにあらゆる集計を歪めることになる。
来歴とともに保存する
すべての行について、最低限以下を保存すること。
- 由来するソースURL
- 取得タイムスタンプ(UTC)
- リクエストが使用した地理的視点(国/市)、データにとって地理が重要な場合
- 再クロール時に変化を検出できるようにするためのコンテンツハッシュまたはバージョン
- 解析されたフィールドとは別に生のペイロード(またはその参照)。抽出器が改善されたときに再スクレイピングせずに再解析できるようにするため
来歴は、誰かが「この数字はどこから来たのか」と初めて尋ねるまで、あるいは抽出器にバグがあって50万行をネットワークに再アクセスせずに再解析する必要が生じるまでは、余計な負担のように感じられる。初日から保存しておくこと。
信頼する前にデータセットを検証する
誰かがデータセットの上に何かを構築する前に、カバレッジと品質のチェックを実行する。これが、取得段階で発生しうるバイアスを捕捉する方法だ。
- カバレッジ監査。 収集した行を、発見段階で意図した母集団と比較する。92%の完了率は問題ないが、問題は欠落している8%がランダムかどうかだ。失敗をスポットチェックし、それらが1つのソース、1つの地理、1つのサイトタイプに集中している場合、単なるデータ欠落ではなく修正すべき体系的バイアスがある。
- フィールドごとのnull率チェック。 突然40%がnullになったフィールドは、通常、データが存在しないのではなく、セレクタが壊れていることを意味する。
- 分布の妥当性チェック。 価格分布、カテゴリの構成、地理的広がりは期待通りか。偏りは多くの場合、上流のサンプリング問題を明らかにする。
- 鮮度チェック。 行の年齢分布はどうなっているか。ある部分が常に古い場合、その部分の更新クロールがブロックされている。
これらのチェックは安価であり、データセットを出荷することと、自信を持って間違ったデータセットを出荷することの違いを生む。
責任を持って行うことについての注意
ウェブからデータセットを構築することには、現実的な義務が伴う。公開データのみを収集し、robots.txtが負荷制御に関わる場合はそれを尊重し、レート制限を守り、取得元のサイトを劣化させないようにし、正当な根拠がない限り個人データを避け、各ターゲットの利用規約に従うこと。プロキシはリクエストがどのIPから来るかを変えるだけであり、そのリクエストをすべきかどうかを変えるものではない。Shifterで許可されていることについての正式な情報源は、利用規約であり、規模を拡大する前に倫理的なデータ収集を読んでおく価値がある。
FAQ
ウェブスクレイピングによるデータセット構築で最も難しい部分は何か? スクレイピングそのものではなく、カバレッジだ。完全で偏りのないサンプルを得ることは、ページを取得することよりもはるかに難しい。失敗したリクエストはランダムではない部分のデータを取り除くのに、結果として得られるデータセットは完全に見えるからだ。データセット品質の問題の多くは、取得段階に起因する。
ブロックはどのようにスクレイプされたデータセットに偏りをもたらすのか? 対ボットシステムは価値の高いターゲットを最も積極的に保護するため、ブロックされるスクレイパーは、重要で防御の固い行を失い、簡単な行だけを保持することになる。データセットは防御の薄いソースへと偏り、それに基づいて構築されたあらゆる集計やモデルを損なう。
データセット構築にレジデンシャルプロキシは必要か? ターゲットがデータセンターIPをブロックするか、地理によってコンテンツが変わる場合にのみ必要だ。そして、価値のあるほとんどのターゲットはそうである。保護されておらず地理的に中立なソースについては、データセンターIPで問題ない。防御されたサイトやローカライズされたサイトの完全で代表的なカバレッジには、レジデンシャルプロキシがバイアスのギャップを埋める。
スクレイプされたデータセットをどのように鮮度を保つか? データの変化速度に合わせて再クロール頻度を設定し、増分更新を行い(完全な再スクレイプではなく、ETag/ハッシュ/差分で変化を検出する)、すべての行に取得タイムスタンプを刻印して古さを測定・フィルタリングできるようにすること。
スクレイプされたデータをどのように重複排除すべきか? 安定したアイデンティティキー(SKU、ISBN、正規URL、正規化された名前+場所)で行い、生のURLでは決して行わないこと。同じエンティティが多くのURLに現れるからだ。重複は最も新しい、あるいは最も完全なバージョンに崩す。
抽出されたフィールド以外に何を保存すべきか? 来歴だ。ソースURL、取得タイムスタンプ、地理的視点、変化検出のためのコンテンツハッシュ、そして理想的には、抽出器が改善されたときに再スクレイピングせずに再解析できるよう生のペイロードも保存する。
結論
ウェブスクレイピングによるデータセット構築は、スクレイピングという衣を着たデータ品質の問題だ。誰でもページを取得できる。仕事とは、正しいページを完全に、最新に、そして難しいターゲットがあるべき場所に体系的な穴を残さずに取得することを確実にすることだ。パイプライン、発見、取得、抽出、正規化、重複排除、保存、更新は単純明快だ。静かに品質の上限を決める唯一の段階は取得だ。なぜなら、そこでブロックと地理が、欠落データを偏ったデータへと変えるからだ。
取得層を正しく行えば、残りはエンジニアリングだ。ソースが防御されているか地理によって変化する場合、レジデンシャルプロキシネットワークが便宜的なサンプルを代表的なサンプルへと変える。難しいターゲットの完全なカバレッジ、意図的な多地理サンプリング、そして規模に応じた均等なローテーションだ。実装の準備ができたら、Pythonガイドが取得段階のコードを示しており、料金ページにはGB単位のプランが記載されている。まずカバレッジを構築すれば、データセットは自ずと形になる。