cc_rag_tutorial

第 13 章：Common Crawl 数据全解——格式、索引与下载策略

1. 开篇：面对 PB 级数据的“恐惧”与“贪婪”

在构建外挂 RAG 时，Common Crawl (CC) 代表了“贪婪”的极致——它几乎就是互联网本身。它是目前地球上最大的、免费开放的网页存档，每个月新增数以亿计的页面，总数据量达到 PB（拍字节）级别。

对于 RAG 开发者而言，CC 既是宝库也是沼泽。

宝库：它包含了长尾知识、多语言语料、历史快照，这是封闭的 LLM 训练数据无法覆盖的盲区。
沼泽：如果你试图“下载下来再看”，你的带宽、存储和计算预算会在几小时内耗尽。其中 90% 的内容可能是 SEO 垃圾、重复页面、导航栏碎片或无法解析的乱码。

本章的任务是教你“戴着手套解剖”。我们将深入 CC 的底层文件协议（WARC/WAT/WET），揭示如何利用高效的索引机制（CDX/Parquet）在不下载文件的情况下透视数据，并制定一套符合经济效益的获取策略。

2. CC 的数据解剖学：WARC, WAT, 与 WET

Common Crawl 的数据分发采用了一种标准化的分层结构。理解这种结构，是你决定“该请求哪个文件”的关键。

2.1 数据金字塔与转换流

CC 的处理流程是一个从“全量原始数据”到“高密度文本数据”的蒸馏过程。

[ 原始互联网 (The Live Web) ]
       |
       v (Nutch/Browsertrix 爬虫)
       |
+-----------------------------------------------------------+
| 1. WARC (Web ARChive) - "母带"                            |
| --------------------------------------------------------- |
| 格式：ISO 28500 标准                                      |
| 内容：HTTP Request + HTTP Response (Header + Body)        |
| 体积：100% (压缩前极大)                                   |
| 特征：二进制安全，包含图片、PDF、HTML 源码、服务器指纹    |
+-----------------------------------------------------------+
       |
       +----------------------------+
       | (Java 提取程序)            | (Java 提取程序)
       v                            v
+-----------------------+    +-----------------------+
| 2. WAT (Metadata)     |    | 3. WET (Text Only)    |
| --------------------- |    | --------------------- |
| 格式：JSON-in-WARC    |    | 格式：纯文本-in-WARC  |
| 内容：计算后的元数据  |    | 内容：提取后的正文    |
|       链接图谱        |    |       去标签、去脚本  |
|       HTML 结构统计   |    |       按视觉块分段    |
| 体积：~25%            |    | 体积：~15-20%         |
| 用途：分类、筛选      |    | 用途：RAG 核心语料    |
+-----------------------+    +-----------------------+

2.2 深度解析：三种格式的内部细节

A. WARC (Web ARChive) —— 互联网的数字琥珀

WARC 文件是多个 Record (记录) 的拼接。每个 Record 都有标准化的 Header。

典型结构：
- WARC-Type: warcinfo (文件头), response (服务器响应), request (爬虫请求), metadata (爬虫元数据)。
- WARC-Target-URI: 抓取的原始 URL。
- Content-Type: application/http; msgtype=response。
- Payload: 紧接着 Header 的就是原始的 HTTP 响应流（包含 HTTP/1.1 200 OK、Server: Apache 等头信息，以及 <html>...</html> 正文）。
RAG 场景下的价值：
- 高精度解析：当 WET 的文本提取逻辑破坏了关键格式（如代码块缩进、表格结构、数学公式 LaTeX）时，必须回溯 WARC 自行解析 HTML。
- 多模态 RAG：如果你需要提取图片 (<img> src) 或 PDF 文件，必须用 WARC。

B. WAT (Web Archive Transformation) —— 数据的 X 光片

WAT 是从 WARC 中提取的元数据，封装在 JSON 格式中，但仍然包裹在 WARC 容器里。

核心字段 (Payload)：
- Envelope: 包含 WARC 头信息。
- Payload-Metadata:
  - HTTP-Response-Metadata: 包含 Header (Content-Length, Content-Type, ETag)。
  - HTML-Metadata: 及其重要！包含 Head (Title, Meta Keywords, OpenGraph Tags), Links (页面内所有外链的列表), Structure (HTML 标签的层级分布)。
RAG 场景下的价值：
- 垃圾过滤：通过 Links 数量判断是否为“链接农场”；通过 HTML-Metadata 中的文本/标签比率判断是否为有效内容页。
- 去重依据：ETag 或 Payload 的哈希值。

C. WET (WARC Encrypted Text) —— RAG 的即食口粮

这是 99% 的 RAG 项目应该关注的格式。 它不仅去掉了 HTML 标签，还尝试根据 DOM 结构将文本还原为人类阅读顺序。

格式特征：
- 文件扩展名 .wetz (GZIP 压缩)。
- 内部依然是 WARC 记录结构，但 Payload 是纯文本。
- 分隔符：不同网页之间由 WARC/1.0 协议头分隔。
潜在缺陷 (Gotchas)：
- 导航栏残留：Home, About, Contact 等词汇经常出现在正文开头。
- 结构丢失：<h1> 和 <p> 在视觉上可能难以区分（取决于提取器版本）。
- 编码转换：虽然目标是 UTF-8，但源站的编码错误会被保留。

Rule of Thumb (选型法则)： 默认起手 WET。如果你的 RAG 需要处理 编程代码 (需要缩进)、科学论文 (需要公式) 或 复杂表格，请立即升级为 下载 WARC + 自研 HTML 解析器，不要试图修复 WET。

3. 索引与导航：不下载也能“看见”数据

CC 提供了两种索引机制，让你在下载之前就能精准定位到具体的字节片段。

3.1 索引机制 A：CDX (Capture Index)

这是一个基于 HTTP 的 API，允许你按 URL 模式进行行级查询。

工作原理：数据库存储了 (URL, Timestamp) -> (File_Path, Offset, Length, Digest) 的映射。
查询能力：
- 精确匹配：查 example.com/foo。
- 前缀匹配：查 *.example.com/* (所有子域名和路径)。
返回字段详解：
- urlkey: 规范化后的 URL（忽略 http/https，翻转域名 com,example 以便于排序）。
- timestamp: 抓取时间（YYYYMMDDHHMMSS）。
- digest: 内容指纹 (SHA-1)。这是 RAG 去重的核心字段。
- filename: S3 上的相对路径 (e.g., crawl-data/CC-MAIN-2023-50/...).
- offset / length: 文件中的位置和大小。

3.2 索引机制 B：Columnar Index (Parquet)

对于复杂的分析查询，CDX 力不从心。CC 提供了存储在 S3 上的 Parquet 格式索引，支持 SQL 查询（通过 AWS Athena 或 Spark）。

适用场景：
- “给我所有 .jp 结尾的、HTTP 状态码为 200 的、内容语言被标记为日文的页面列表。”
- “统计过去一年哪个域名的页面更新最频繁。”
RAG 筛选策略：利用 Parquet 索引进行粗筛 (例如：只保留特定的 TLDs 或 mime-type 为 text/html 的记录)，生成一份目标 URL 清单，然后再去下载数据。

4. 下载与访问策略：Range Request 与 S3

有了索引（位置信息），下一步是获取数据。切记：不要下载整个文件。

4.1 字节级切片 (Byte Serving)

CC 的文件（WARC/WET）虽然被压缩为 .gz，但它们是 Concatenated Gzip 格式。

这意味着：多个 Gzip 块拼在一起。你可以解压文件的 中间部分，而不需要从头解压。
操作方法：使用 HTTP Range 头。例如，索引告诉你数据在 offset=1048576, length=5000。
```
GET /crawl-data/.../segment.warc.gz.wetz HTTP/1.1
Host: data.commoncrawl.org
Range: bytes=1048576-1053575
```
你将只收到这 5KB 的压缩数据。解压后即为该网页的完整内容。

4.2 物理位置与成本控制 (AWS S3)

CC 数据托管在 AWS 公共数据集桶中 (s3://commoncrawl/)。

区域 (Region): us-east-1 (N. Virginia)。
免费的定义：
- 存储：你不需要付 S3 存储费。
- GET 请求：如果你直接用 S3 API，请求费可能由请求者承担（量大时要注意）。如果是 HTTP 下载，CC 承担了部分费用，但有限制。
- 流量 (Data Transfer)：最关键的成本项。
  - EC2 (us-east-1) -> S3 (us-east-1): 流量免费。
  - Internet / 其他 Region -> S3: 按 AWS 标准流出费率计费 (非常贵，$0.09/GB 起)。

Rule of Thumb (架构建议)： 计算跟着数据走。

在 AWS us-east-1 开一台 Spot 实例（如 c7g.medium）。

在实例上运行脚本：查询索引 -> Range Download -> 解析清洗 -> 提取 Chunk。

只将最终清洗好的 JSONL（可能只有原大小的 1%）传回你的本地服务器或向量库。严禁：在本地笔记本上直接遍历下载 CC 数据。

5. 本章小结

数据分层：WARC 是全息原始数据，WAT 是结构化元数据，WET 是 RAG 专用的纯文本。
索引为王：利用 CDX API 查单点，利用 Parquet + Athena 查批量。永远不要遍历文件列表。
精准手术：利用 Concatenated Gzip 和 HTTP Range 请求，只下载你需要的那个网页的几 KB 数据。
地理围栏：所有高带宽操作必须锁定在 AWS us-east-1 区域内进行，否则流量费会让你破产。
去重关键：利用索引中的 digest 字段，在下载前就剔除重复内容。

6. 练习题

基础题

Q1: 格式选择 你的 RAG 系统需要专门回答关于“网页加载速度优化”的问题，你需要分析每个网页的 HTTP 响应头中的 Cache-Control 和 Server 字段，以及页面 HTML 的压缩比。你应该使用哪种 CC 文件格式？

点击查看参考答案

**答案：WAT (推荐) 或 WARC。** * **提示**：WET 文件已经丢弃了 HTTP 响应头，无法获取 `Cache-Control`。 * **WAT**：包含了 `HTTP-Response-Metadata` (含 Headers) 和 Payload 的元数据 (含长度信息)，体积小，解析快，足以完成此分析。 * **WARC**：包含所有信息，但下载体积大得多，如果是为了统计分析，WAT 性价比更高。

Q2: 索引解读 CDX 索引返回一条记录，其中 status 字段为 301。这代表什么？你在构建 RAG 语料时应该如何处理这条记录？

点击查看参考答案

**答案：代表永久重定向 (Moved Permanently)。** * **处理策略**： 1. **跳过**：通常 301 响应的 Body 是空的或只有一行跳转提示，没有实际知识价值。 2. **追踪 (高级)**：如果你的系统非常完善，可以读取其 `Location` 头，去抓取重定向后的新 URL。但在简单的 RAG 管道中，直接过滤掉非 200 状态码的记录是最安全的做法。

Q3: 范围下载 为什么 Common Crawl 的 Gzip 文件可以从中间解压？这依赖于什么特性？

点击查看参考答案

**答案：Concatenated Gzip (串联 Gzip) 特性。** * 标准 Gzip 是一个整体流。但 CC 将每个网页单独压缩成一个 Gzip 块，然后直接将这些二进制块首尾相连拼成一个大文件（`.warc.gz`）。 * Gzip 规范允许解压器处理这种串联流。因此，只要你知道某个块的起始字节，就可以将其视为一个独立的 Gzip 文件开始解压，而无需读取前面的字节。

挑战题

Q4: 增量更新设计 (开放性) 假设你已经基于 CC-MAIN-2023-50 构建了一个 RAG 知识库。现在 CC-MAIN-2024-01 发布了。请设计一个流程，将新数据合入知识库，要求：1. 不重复索引已有的网页内容；2. 能够更新那些内容发生了变化的旧网页。

点击查看参考答案

**答案思路：** 1. **准备指纹库**：维护一个本地 KV 数据库 (如 Redis/RocksDB)，存储已索引的 `URL -> Digest` 映射。 2. **遍历新索引**：查询 2024-01 的 Parquet/CDX 索引。 3. **比对策略**： * **URL 不存在**：新网页 -> **下载并索引**。 * **URL 存在，但 Digest 不同**：网页内容已更新 -> **下载并索引** (并在向量库中删除旧版本的 chunk，或标记版本)。 * **URL 存在，且 Digest 相同**：网页未变 -> **直接跳过** (Zero Cost)。 4. **注意事项**：Digest 通常基于 SHA-1。虽然极低概率碰撞，但在 PB 级数据下是安全的。

Q5: 跨语言清洗 (陷阱探测) 你下载了一个标记为“中文”的 WET 文件片段，但解压后发现里面是乱码且穿插着日文片假名。可能的原因是什么？除了 CC 提供的 languages 字段，你还应该加什么检测手段？

点击查看参考答案

**答案：** * **原因**： 1. **编码误判**：源网页可能是 GBK 或 Shift-JIS，但服务器声明是 UTF-8，或者 CC 的转换流程未能正确识别非 UTF-8 编码，导致 "Mojibake" (乱码)。 2. **内容混合**：页面可能是“多语言列表”或机器翻译生成的垃圾页。 * **补充检测手段**： 1. **cld2 / cld3 / fasttext**：在本地对提取后的文本再次运行语言检测模型。 2. **ftfy (Fix Text For You)**：使用 Python 的 `ftfy` 库尝试自动修复常见的编码错误（如将 UTF-8 字节解释为 Latin-1 导致的乱码）。 3. **Unicode 范围过滤**：统计中文字符 (CJK Unified Ideographs) 的占比，如果低于阈值（如 50%），则丢弃该段落。

7. 常见陷阱与错误 (Gotchas)

1. 信 `Content-Length`

陷阱：HTTP Header 里的 Content-Length 经常是错的，或者是压缩前的大小，或者是压缩后的大小，很不统一。
对策：永远以 CDX 索引中提供的 length 字段为准来设定 Range Request 的范围。

2. “软 404” (Soft 404)

陷阱：HTTP 状态码是 200，但页面内容是“您访问的页面不存在，请返回首页”。
影响：你的 RAG 检索结果里会出现大量这种无意义的废话。
对策：在清洗阶段建立“垃圾话术黑名单”（如 “Page not found”, “404 Error”, “您访问的…“），如果页面正文极短且包含这些词，直接丢弃。

3. DNS 腐烂与域名抢注

陷阱：你索引了 2015 年的数据。用户检索时，CC 给出了引用链接。用户点击链接，却跳转到了博彩网站。
原因：原域名过期，被黑灰产抢注。
对策：外挂 RAG 必须明确标注“数据来源时间”。在展示引用链接时，最好链接到 web.archive.org (Wayback Machine) 的对应快照，而不是原始链接，以保证安全性。

4. JSON 解析错误 (WET 并非 JSON)

陷阱：很多新手写代码试图用 json.load() 读取 WET 文件。
现实：WET 是纯文本格式，只有 WAT 是 JSON。WET 需要按行读取，或者按 WARC/1.0 标头进行正则分割。

< 第 12 章：安全、权限与合规 | 第 14 章：用 Common Crawl 做外挂语料 >

cc_rag_tutorial

第 13 章：Common Crawl 数据全解——格式、索引与下载策略

1. 开篇：面对 PB 级数据的“恐惧”与“贪婪”

2. CC 的数据解剖学：WARC, WAT, 与 WET

2.1 数据金字塔与转换流

2.2 深度解析：三种格式的内部细节

A. WARC (Web ARChive) —— 互联网的数字琥珀

B. WAT (Web Archive Transformation) —— 数据的 X 光片

C. WET (WARC Encrypted Text) —— RAG 的即食口粮

3. 索引与导航：不下载也能“看见”数据

3.1 索引机制 A：CDX (Capture Index)

3.2 索引机制 B：Columnar Index (Parquet)

4. 下载与访问策略：Range Request 与 S3

4.1 字节级切片 (Byte Serving)

4.2 物理位置与成本控制 (AWS S3)

5. 本章小结

6. 练习题

基础题

挑战题

7. 常见陷阱与错误 (Gotchas)

1. 信 Content-Length

2. “软 404” (Soft 404)

3. DNS 腐烂与域名抢注

4. JSON 解析错误 (WET 并非 JSON)

1. 信 `Content-Length`