クローリングデータをデータウェアハウスに統合する――外部Web収集をパイプラインに組み込む視点

「競合他社データも自社ダッシュボードで見たい」がデータチームに届いたら

社内ソースは安定しています。スキーマは自社で管理し、変更はリリースノートで予告され、失敗しても再処理の手順があります。しかし、経営陣や現場が「競合他社の価格、レビュー、市場データも同じダッシュボードで見たい」と求めた瞬間、管理権限の及ばないソースをパイプラインに接続する問題が生じます。

外部Webのスキーマは自社で所有できません。対象サイトは予告なく画面構造を変更し、ブロックポリシーも随時強化されます。昨日の収集に欠損があれば、今日のダッシュボードには穴が空き、Excelで受け取ったデータはDAGに接続できません。この記事では、外部Web収集をどのように社内DW・データレイクのパイプラインへ統合するか — その統合方法を扱います。前提は一つです。収集そのものは委託し、データチームはロード・モデリング・活用に集中する構造です。外部Webを「適切に管理されたソースシステム」のように扱うには、そのソースがデータチームの言語で契約を結べる必要があるためです。

1. 外部Webデータは社内ソースとどこが異なるか

接続する前に何が異なるのかを理解してこそ、統合設計ができます。社内テーブルのカラム変更は自社のリリース手順内で行われますが、外部Webはソースサイトが自由に変更します。昨日まであったフィールドが今日消え、同じ「価格」でも12,900ウォンと12900が混在して入ってきます。更新もトランザクションではなく、決められた周期で動く定期バッチであるため、DAGスケジュールとダッシュボードの鮮度SLAをその周期に連動させる必要があります。

最も危険な違いは失敗モードです。社内ジョブは失敗すれば例外を投げて停止しますが、外部クローラーで最悪なのは壊れているのに成功したように空の値を蓄積するケースです。サイト構造が変わってセレクターが外れると、ジョブは正常終了してもレコードは0件、または欠損だらけになります。件数だけを見る検証では検知できず、過去のWeb画面は再収集できないため、その穴は永続的です。したがって外部データ統合は「ロードだけ」で終わりではなく、ロード後の検証までが一組です。

2. 配信形式別の統合パターン — 正解はなく、仕様に合わせる

外部収集をパイプラインへ接続する方法は、配信形式によって分かれます。大きく三つのパターンがあり、どれが正しいというより、データチームのパイプライン仕様に合わせて選びます。

APIポーリング型は、収集データをAPIで受け取り、DAGが最後のウォーターマーク以降の増分だけを照会してランディングゾーンにロードします。すでに受け取った期間を再取得しないよう、増分カーソルをデータチームが管理することが核心です。DB・S3直接ロード型は、収集側がDW・レイクへ直接ロードし、DAGは到着を検知して後続処理のみを行います。ここでは、半分しか到着していないデータを処理しないよう、完了マーカー(manifest・_SUCCESS)の規約を事前に合意しておきます。ファイル受信型は、標準の場所に規格化されたファイルが配置されたらパースしてロードする方式で、Excel中心の運用をパイプラインへ移す過渡期に適しています。

3パターンすべてにおいて、当社（収集側）とデータチームがインターフェース仕様を先に合わせることが前提です。APIレスポンスの形式・DBテーブル/S3プレフィックス・ファイル規約をデータチームのパイプラインに合わせて協議し、どの形式で提供するかもその仕様から逆算して決めます。配信形式がExcelだけでなく、API・直接ロード・S3ドロップまで開かれていてこそ、この協議が成立します。

3. ランディングゾーン — 外部ソースが変わっても下流を壊さない緩衝装置

外部データを直接モデリングレイヤーに入れると、ソースが変更された日に下流(dbt・ダッシュボード)が丸ごと壊れます。緩衝装置となるのがランディングゾーンであり、ここで三つのことを処理します。

第一に、raw原本の保存です。受け取ったままの状態で(APIレスポンス原文、元ファイル)手を加えずに一式を残します。パースロジックが誤っていた場合や、後から別のフィールドが必要になった際、再収集せず原本から再パースするためです。過去のWeb画面は復元不可能なため、この原本保存が事実上のセーフティネットです。

第二に、スキーマバージョニングです。当社がデータチームと連携する際の標準は以下の通りです。スキーマ変更は事前通知(deprecation期間)を設け、その期間中は旧・新バージョンを並行提供し、下流が自身のペースで移行できるようにします。例えば、price_daily.v1を引き続き提供しながら、currencyカラムが追加されたv2も同時に提供します。下流のdbtは準備ができた時点で参照先を移し、deprecation終了後にv1を廃止します。これにより、「ソースが昨日改修されて今日ダッシュボードが停止した」という状態を、「次四半期まで並行運用し、その間に移行する」状態へ変えられます。変更責任と緩衝期間が契約に含まれるため、データチームが突然の火消し役として呼び出されることはありません。

第三に、backfillを標準手順として扱います。収集が数日欠損した場合や、新しいフィールドを過去期間にも補完する必要がある場合、当社が期間・条件を指定して再収集し、ランディングゾーンへ再ロードすれば、DAGはその期間だけを再モデリングします。同じ期間を再投入しても重複が蓄積しないよう、パーティション置換・upsertキーによって冪等に設計することが前提です。再収集の窓口は当社側にあるため、データチームは「どの期間を再処理するか」だけを指定すれば済みます。

4. ロード後の検証 — 静かな欠損をDAG内で検知する

第1節の「静かな欠損」は、ロード後の検証でしか検知できません。publishの前にDQゲートを設け、通過できなければ下流へ昇格させないようにします。壊れたデータがダッシュボードまで流れる代わりにランディングゾーンで止まり、アラートが発生します。ゲートが主に確認するのは四つです。レコード数が想定下限を下回って急減していないか（静かな欠損）、必須フィールドの欠損率が閾値以下か（部分収集）、パース異常フラグがないか（構造改修）、収集時刻がfreshness SLA内か（鮮度）です。

データチームがDQルールをゼロから作らなくて済むよう、当社はデータとともに検証用メタデータも提供します。収集時刻(freshness)、収集条件（どの検索語・カテゴリ・範囲か）、ソースURL（リネージ・監査）、レコード数（想定比での急減）、欠損/異常フラグなどです。監視はクローラー一か所ではなく、ソース（収集）とパイプライン（ロード）の両側に配置します。収集異常・遅延が検知された場合は、当社がデータチームのチャネル(Slack・Webhook)へ通知し、復旧見込み時刻も共有することで、「なぜ欠けているのか、いつ補完されるのか」に答えられる状態を作ります。

5. カタログ・リネージ — 「この数値はどこから来たのか」に答える

外部データがダッシュボードに載れば、いつか監査や経営会議で「この競合他社の価格は、どこが出所なのか」と問われます。答えるには、カタログとリネージに出所・周期メタデータが登録されている必要があります。当社はこの登録にすぐ利用できるよう、ソースドメイン/URL、収集周期、収集条件（対象範囲）、現在のスキーマバージョン、そしてこのソースが委託運用ソースであることを併せて提供します。検証用メタデータと重なりつつ、カタログ観点の項目が追加された形です。

このメタデータをデータセット登録時に入力しておけば、リネージグラフからダッシュボード指標をソースURLまで遡って追跡できます。「この数値はどこから来たのか」に数クリックで答えられる状態 — それが外部データを社内ソースと同等にガバナンスへ組み入れた状態です。スキーマ・backfill・メタデータをデータチームと合わせる理由は、ここに集約されます。外部ソースをカタログに正式登録できる形で渡してこそ、それが「管理されたソースシステム」になります。

最後は鮮度です。外部収集は決められた周期で動く定期バッチであるため、ダッシュボードSLAもそのバッチ周期に合わせて設定すべきです。バッチが1日1回であれば、ダッシュボードも「日次で更新される指標」として設計し、表記も「○時時点」のようにバッチ収集時刻を明記するほうが、運用とのずれを防げます。鮮度は「どれだけ新しいか」ではなく、「どのバッチ時点を基準にしているか」として伝えることが、データチームと現場の双方にとって安全です。

この統合がデータチームにもたらすもの

外部Web収集をパイプラインへ統合する要点は、制御不可能なソースを制御可能なインターフェースの背後に置くことです。スキーマはバージョン契約で、失敗はDQゲートで、出所はカタログメタデータで、再処理はbackfillの標準手順で包めば、外部データも社内ソースのように扱えます。

そのインターフェースの裏側にある常時運用 — ブロック対応、サイト改修の追跡、収集監視、修復 — を誰が担うかが最後の決定です。これをデータチームが担えば、DAG運用人員は外部収集のメンテナンスに消耗します。当社は開発・保守・ブロック対応・収集監視を月額定額に含めて受託し、データチームにはスキーマ契約・検証メタデータ・カタログメタデータを備えたソースとして提供します。収集→整備→AI分析までを経て、rawではなくロード可能な構造化データとして渡すため、ランディングゾーンの整備負荷も軽減されます。

結論は一つです。外部Web収集・保守は委託して適切に管理されたソースシステムのように扱い、データチームはロード・モデリング・活用に集中すること。実際に、ある規制機関の大規模オンラインモニタリングを定期パイプラインとして委託運用しており、大規模・複数部門の需要もこの方式で一つの窓口に集約されます。

関連記事

• クローリングデータが意思決定になるまで
• Excelで受け取るデータ vs ダッシュボードで見るデータ — 納品形式が変えるもの
• 部門ごとに別々にクローリングする会社 — 重複投資を終える全社データ収集ガバナンス

今すぐ始める

現在のパイプラインがどのような仕様か — Airflowオーケストレーションか、S3データレイクか、DW直接ロードか — をお知らせいただければ、外部Web収集をその仕様に合わせてどのように接続するか、インターフェースから一緒に設計いたします。スキーマ契約・検証メタデータ・カタログメタデータまで、データチームの言語に合わせます。

データ活用を相談する