Mở rộng việc thu thập dữ liệu từ Web từ 1K đến 100M trang
TL;DR
Chuyển từ 1.000 đến 100 triệu trang là thay đổi về lịch trình, lưu trữ, kiểm soát chất lượng và quản trị nguồn, không chỉ là cài đặt độ đồng thời lớn hơn.
Giữ một biên giới URL bền vững với việc chuẩn hóa, ngân sách theo máy chủ, trạng thái thử lại và điểm dừng; một danh sách cục bộ không thể phục hồi một lần thu thập dài.
Tách việc thu thập trang khỏi phân tích, xác thực và lập chỉ mục để một giai đoạn hạ nguồn chậm có thể áp dụng áp lực ngược thay vì mất dữ liệu.
Đo lường số hồ sơ được chấp nhận trên mỗi đô la và mỗi giờ, cộng với độ tươi và tỷ lệ lỗi theo miền; số yêu cầu thô che giấu chất lượng dữ liệu kém.
Nstdata Crawl có thể xử lý việc phát hiện trang web đã được phê duyệt, thu thập đệ quy, kết xuất JavaScript và định tuyến proxy. Một chương trình 100 triệu trang vẫn cần một bộ lập lịch bên ngoài, lưu trữ, quản trị và lập kế hoạch năng lực.
Những gì thay đổi khi thu thập dữ liệu web tăng từ 1K đến 100M?
Thay đổi chính là những thất bại trở thành sự kiện vận hành bình thường. Ở 1.000 trang, một nhà phát triển có thể thử lại một kịch bản và kiểm tra đầu ra của nó. Ở 100 triệu trang, các máy chủ thay đổi định dạng, URL bị trùng lặp, công nhân khởi động lại, một số công việc vẫn chưa hoàn thành, và các hồ sơ phải được sửa chữa hoặc xóa sau đó. Hệ thống phải làm cho trạng thái của từng trang có thể quan sát và phục hồi được. Sản phẩm Nstdata Crawl là một tùy chọn được quản lý cho các bước thu thập và chuyển đổi được thảo luận ở đây.
Xem 100 triệu như một quy mô lập kế hoạch, không phải là một hạn ngạch yêu cầu của bất kỳ API hoặc công việc đơn lẻ nào. Ngay cả ở mức 100 trang được chấp nhận mỗi giây, 100 triệu trang được chấp nhận mất khoảng 11.6 ngày trước khi thu thập lại, tạm dừng và các trang bị từ chối. Phép toán là pages / accepted_pages_per_second / 86,400. Năng lực phải được mô hình hóa dựa trên sự pha trộn thực tế của trang web và giới hạn hiện tại của nhà cung cấp.
Hướng dẫn thu thập tự động bao gồm quá trình chuyển đổi từ kịch bản sang công việc định kỳ.
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Bạn nên xây dựng gì trước khi tăng độ đồng thời?
Xây dựng một biên giới bền vững và một hợp đồng hồ sơ ổn định. Biên giới lưu trữ mỗi URL được chuẩn hóa, nguồn, cha mẹ phát hiện, độ ưu tiên, thời gian lấy eligible sớm nhất, số lần thử, trạng thái và lỗi cuối cùng. Một khóa duy nhất nên ngăn không cho cùng một URL được đưa vào hàng đợi nhiều lần. Chỉ chuẩn hóa những gì bạn có thể bảo vệ: việc xóa một phân đoạn thường là an toàn cho điều hướng HTML thông thường, trong khi việc thu gọn các tham số truy vấn có thể xóa các trang sản phẩm hoặc tìm kiếm khác biệt.
Xác định hồ sơ đầu ra trước khi bạn mở rộng lớp lấy dữ liệu. Một hồ sơ trang được chấp nhận tối thiểu có source_url, canonical_url, fetched_at, status_code, content_hash, parser_version, content, và quality_status. Lưu trữ các hiện vật thu thập thô tách biệt với văn bản đã phát sinh để sửa lỗi trình phân tích không yêu cầu lấy lại mọi nguồn một lần nữa. Bảo tồn một liên kết từ mỗi hồ sơ phát sinh đến hiện vật thô và quyết định chính sách cho nguồn đó.
The Robots Exclusion Protocol thuộc về bộ lập lịch cụ thể nguồn, bên cạnh các ràng buộc hợp đồng và tỷ lệ.
Làm thế nào để bạn mở rộng một cuộc thu thập theo từng giai đoạn?
Sử dụng bốn giai đoạn, mỗi giai đoạn có một tiêu chí thoát có thể đo lường.
Phương pháp 1: Xác thực một chương trình thử nghiệm 1K trang
Tốt nhất cho: Chứng minh chất lượng trích xuất và quyền truy cập nguồn trước khi thêm cơ sở hạ tầng.
Bước 1. Chọn một mẫu phân tầng giữa các miền, mẫu, ngôn ngữ và hành vi JavaScript. Xác nhận rằng mỗi nguồn đã được phê duyệt cho mục đích sử dụng đã định.
Bước 2. Lấy mẫu với một cài đặt độ đồng thời hạn chế và một khoảng thời gian chờ. Lưu trữ các phản hồi thô hoặc hiện vật đã kết xuất với một URL nguồn và dấu thời gian.
Bước 3. Xem xét đầu ra được chấp nhận so với các trang nguồn. Ghi lại tỷ lệ trùng lặp, các trường thiếu, các trang bị chặn hoặc lỗi, byte mỗi trang, và các trang được chấp nhận mỗi giây.
Cổng quyết định: Nếu một mẫu quan trọng thất bại, sửa chữa trình phân tích hoặc chọn một con đường kết xuất trước khi nhân lên khối lượng. Tốc độ lấy cao hơn khiến một trình phân tích kém trở nên tốn kém hơn.
Phương pháp 2: Thêm một biên giới bền vững cho 100K đến 1M trang
Tốt nhất cho: Nhiều công nhân, khởi động lại và thu thập lại có chọn lọc.
Bước 1. Đưa các URL đang chờ vào một cơ sở dữ liệu hoặc hàng đợi với một khóa chuẩn hóa duy nhất, thời gian hết hạn, next_fetch_at, và số lần thử.
Bước 2. Cung cấp cho mỗi công nhân một lô hạn chế. Đánh dấu một URL hoàn thành chỉ sau khi hiện vật và kết quả trích xuất của nó đã bền vững. Các thuê đã hết hạn nên trở về hàng đợi.
Bước 3. Phân vị lập lịch theo máy chủ hoặc nguồn và thực thi ngân sách yêu cầu theo máy chủ. Tôn trọng các chính sách thu thập áp dụng và giảm tốc độ trên 429, 503, thời gian chờ và tỷ lệ lỗi đang tăng.
Cổng quyết định: Khởi động lại các công nhân một cách có chủ đích. Số hồ sơ đã chấp nhận bị mất hoặc trùng lặp nên có thể đo lường và nằm trong khả năng chịu đựng của bạn.
Phương pháp 3: Tách thu thập và chuyển đổi ở 10M trang
Tốt nhất cho: Các trang tĩnh và đã kết xuất hỗn hợp với nhiều người tiêu thụ đầu ra.
Bước 1. Gửi các tác vụ fetch đến một cấp độ thu thập. Đưa HTML thô hoặc đầu ra đã được hiển thị vào kho lưu trữ đối tượng với các định danh không thể thay đổi và kiểm tra.
Bước 2. Chạy quá trình trích xuất, chuẩn hóa, lọc chính sách, và xác minh chất lượng như các người tiêu dùng riêng biệt. Phiên bản trình phân tích và bảo tồn lý do từ chối.
Bước 3. Áp dụng áp lực ngược từ kho lưu trữ và hàng đợi trích xuất. Tạm dừng việc phát hiện hoặc giảm tỷ lệ yêu cầu khi mục đã xếp hàng cũ nhất hoặc độ trễ lưu trữ vượt quá mục tiêu dịch vụ.
Cổng quyết định: Việc triển khai trình phân tích nên xử lý lại các tác phẩm đã lưu trữ mà không cần phải thu thập lại toàn bộ tập hợp.
Phương pháp 4: Quản lý chương trình 100 triệu trang
Tốt nhất cho: Thu thập liên tục, đa nguồn với một nhóm sở hữu các hoạt động.
Bước 1. Phân bổ ngân sách thu thập cụ thể cho nguồn và mục tiêu độ tươi. Ưu tiên các trang đã thay đổi có giá trị cao hơn là thu thập lại toàn bộ mỗi URL.
Bước 2. Giám sát thông lượng các trang được chấp nhận, độ tuổi phần trăm 95, tỷ lệ thử lại, tỷ lệ lỗi ở cấp độ nguồn, tỷ lệ trùng lặp, sự tăng trưởng lưu trữ, và chi phí đơn vị.
Bước 3. Đối chiếu các kho lưu trữ nguồn, yêu cầu xóa, trạng thái công việc, và chỉ mục hạ nguồn. Lấy mẫu chất lượng sau mỗi lần thay đổi trình phân tích hoặc mẫu trang.
Cổng quyết định: Chương trình có thể giải thích nguồn gốc của mỗi bản ghi, thời điểm nó được thu thập, liệu nó có hiện tại hay không, và cách để xóa nó.
Nstdata Crawl phù hợp như thế nào trong kiến trúc này?
Nstdata Crawl là lớp thu thập được quản lý cho các trang đã chọn. Crawl API chấp nhận các công việc trang với maxDepth, maxPages, includeUrls, và excludeUrls, và hỗ trợ phát hiện trang và thu thập đệ quy. Nó có thể hiển thị JavaScript và trả về Markdown, HTML, dữ liệu thô, liên kết, ảnh chụp màn hình, hoặc PDF. Định tuyến proxy tích hợp loại bỏ nhu cầu cấu hình các trường Proxy Host, Port, Username, Password, và Protocol riêng biệt cho một cuộc gọi quản lý tiêu chuẩn.
Ứng dụng vẫn sở hữu ranh giới giữa các trang, hợp đồng hàng đợi, quy tắc chất lượng, kho lưu trữ đối tượng, báo cáo chi phí, và phát tán xóa. Các điểm cuối công việc được tài liệu của Nstdata có thể được kiểm tra để lấy trạng thái và các trang. Đừng hiểu maxPages như một lời hứa rằng một công việc duy nhất có thể xử lý toàn bộ tập hợp 100 triệu trang; xác minh giới hạn và thông lượng trong tài khoản của bạn trước khi thiết lập kế hoạch sản xuất.
Tài liệu Playwright Python là điểm khởi đầu khi một nhóm quyết định vận hành lớp trình duyệt của riêng mình.
Làm thế nào để bạn ngăn chặn việc thu thập khối lượng lớn thất bại một cách im lặng?
Theo dõi trạng thái, không chỉ là kết quả HTTP. Một trang 200 có thể chứa tường đăng nhập, giao diện trống, bảng cookie, hoặc một mẫu lặp lại. Xác minh tiêu đề trang, độ dài nội dung, các trường cần thiết, ngôn ngữ, và miền mong đợi. Lưu trữ các giá trị rejected_reason như access_page, empty_render, duplicate, schema_mismatch, và policy_excluded. Xem xét một mẫu của cả các trang được chấp nhận và bị từ chối.
Sử dụng các ghi viết idempotent được khóa bằng URL tiêu chuẩn cộng với nội dung hoặc phiên bản fetch. Đảm bảo các thử lại an toàn sau khi một worker bị lỗi. Giữ một ngân sách lỗi cho mỗi miền; tỷ lệ thành công toàn cầu có thể ẩn đi một nguồn giá trị cao bị hỏng. Khi một máy chủ không khỏe, tạm dừng nguồn đó và bảo toàn tiến độ của các nguồn khác. Tài liệu Scrapy architecture documentation cho thấy lý do tại sao việc lập lịch, tải xuống, và xử lý mục là những trách nhiệm riêng biệt.
Hướng dẫn phát hiện trang web giúp khi biên giới URL bắt đầu với vùng phủ sóng không đầy đủ.
Làm thế nào để bạn ước lượng khả năng mà không có mục tiêu yêu cầu trên mỗi giây gây hiểu nhầm?
Mô hình mỗi loại nguồn riêng biệt. Bắt đầu với các URL đã được phê duyệt, số byte trung bình cho mỗi trang thô và đã được lấy, phân số yêu cầu hiển thị, tỷ lệ chấp nhận mong đợi, tần suất xem lại, và ngân sách yêu cầu cho phép. Một trang với các trang tĩnh nhỏ có thể bị ràng buộc bởi mạng; một trang đã được hiển thị có thể bị ràng buộc bởi trình duyệt hoặc chi phí; khối lượng công việc trích xuất bảng có thể bị ràng buộc bởi trình phân tích. Một giá trị trung bình trên tất cả các miền che giấu nút thắt cổ chai.
Ước lượng ba khối lượng: thu nhận, hồ sơ được chấp nhận và số byte lưu trữ. Nếu 100 triệu hồ sơ được chấp nhận yêu cầu tỷ lệ chấp nhận 70%, quy trình phải thu nhận khoảng 143 triệu ứng viên, trước khi thực hiện lại việc thu thập. Đó là phép toán minh họa, không phải dự đoán. Sử dụng năng suất thí nghiệm đo lường và một khoảng tự tin. Nhân ước lượng lưu trữ với tài liệu thô, các phiên bản phát sinh và thời gian lưu giữ; việc phiên bản hóa có thể làm cho lưu trữ phát triển nhanh hơn so với số lượng URL.
Đặt ngân sách hàng ngày cho mỗi miền và một ngân sách toàn cầu cho việc chi tiêu và độ tuổi hàng đợi downstream. Nếu bộ trích xuất không thể tiêu thụ tài liệu mới nhanh chóng như bộ thu thập sản xuất chúng, hãy tăng khả năng trích xuất hoặc làm chậm việc thu nhận. Việc thêm công nhân thu thập trong trạng thái đó chỉ làm lớn thêm lượng tồn đọng và đẩy độ mới xa hơn.
Làm Thế Nào Để Thiết Kế Các Lần Thu Thuật Lại Mà Không Phải Bắt Đầu Lại?
Cung cấp cho mỗi URL được chấp nhận một last_fetched_at, băm nội dung, điểm thay đổi và next_fetch_at. Nhớ lại các trang thay đổi thường xuyên sớm hơn và các trang ổn định sau đó, trong chính sách nguồn. Các liên kết mới phát hiện từ một trang thay đổi có thể vào biên giới với ưu tiên cao hơn các trang cũ không thay đổi. Điều này hỗ trợ việc bao phủ liên tục mà không cần phải khởi động lại danh sách 100 triệu URL.
Phân biệt một trang bị thiếu với một lỗi tạm thời. Một 404 có thể có nghĩa là bị xóa vĩnh viễn, một URL đã được di chuyển, hoặc một lỗi nguồn tạm thời. Ghi lại phản hồi và kiểm tra lại theo chính sách trước khi xóa một hồ sơ có giá trị. Nếu một trang thay đổi URL chuẩn, hãy bảo tồn danh tính cũ và mối quan hệ chuyển hướng để các chỉ mục downstream có thể được cập nhật và các tài liệu trùng lặp bị xóa bỏ.
Việc thu thập lại cũng phải bao gồm các thay đổi của bộ phân tích. Khi các tài liệu thô được giữ lại và quyền cho phép điều đó, một phiên bản bộ phân tích mới có thể xử lý lại các bản ghi cũ mà không cần yêu cầu mạng. Điều này đặc biệt hữu ích cho việc sửa lỗi ánh xạ trường trong một tập hợp lớn. Nó không làm cho nội dung hiện tại; một lần thu thập riêng biệt là cần thiết cho sự tươi mới.
Q: Tôi có thể mở rộng việc thu thập dữ liệu bằng cách đặt độ đồng thời là 1.000 không?
Không. Độ đồng thời không cung cấp trạng thái công việc bền vững, tốc độ theo máy chủ, lưu trữ hoặc kiểm tra chất lượng dữ liệu. Tăng nó chỉ sau khi một thí nghiệm thiết lập ngân sách an toàn cho từng nguồn cụ thể.
Q: Nstdata Crawl có thay thế quy trình dữ liệu của tôi không?
Nstdata Crawl xử lý việc thu nhận và chuyển đổi. Ứng dụng của bạn vẫn cần lập kế hoạch qua các nguồn, xác thực, lưu trữ, lập chỉ mục và quản trị.
Q: Chỉ số thông lượng nào là hữu ích nhất?
Số hồ sơ được chấp nhận, được phê duyệt theo chính sách trên mỗi đơn vị thời gian và chi phí hữu ích hơn so với các yêu cầu HTTP đã hoàn thành.
Hướng dẫn Python này di chuyển từ một trang tĩnh đến các bản ghi đã được xác thực và việc quản lý việc hiển thị. Nó bao gồm các ví dụ có thể chạy, chẩn đoán lỗi, kiểm soát nguồn và một hợp đồng dữ liệu sẵn sàng cho AI.
Marcus Chen
Oct. 29th 2026
Thu thập toàn bộ trang web chỉ với một yêu cầu API
Tỷ lệ thành công 99,8% với kết xuất JavaScript
Nhận dữ liệu sạch, sẵn sàng cho LLM ở nhiều định dạng
Chuyển mọi trang web thành Markdown, HTML, JSON, liên kết, PDF và hơn thế nữa mà không cần quản lý hạ tầng thu thập dữ liệu.
