Crawl API vs Web Scraper API vs Proxies: Rốt cuộc nên chọn cái nào?

Nói thật, chọn giải pháp crawler đúng là khá đau đầu.

Trên thị trường hiện có ba phương án phổ biến: tự xây proxy pool, dùng Crawl API và dùng Web Scraper API. Mỗi cách đều có lý do riêng, nhưng cũng có những cái bẫy riêng. Với tư cách là một developer đã lăn lộn trong lĩnh vực thu thập dữ liệu nhiều năm, hôm nay tôi sẽ nói thẳng với mọi người về tình hình thực tế của ba phương án này, không nói chuyện sáo rỗng.

Nói thẳng kết luận trước: chọn thế nào

Nếu lười đọc bài dài phía sau, tôi đưa luôn một gợi ý thực dụng.

Nếu có đội ngũ chuyên trách trên 5 người, khối lượng dữ liệu ở mức TB và dự định làm lâu dài, thì tự làm (DIY) là hợp lý. Trong các trường hợp cần phân tích dữ liệu linh hoạt, có chút năng lực kỹ thuật nhưng không muốn quá vất vả, Crawl API là phương án dung hòa. Nếu cần dữ liệu nhanh, không muốn quản lý chi tiết kỹ thuật, và đội chỉ có 1-2 người, thì Web Scraper API là lựa chọn nhàn nhất.

Trong đa số trường hợp, tôi khuyên nên bắt đầu với Web Scraper API. Trước tiên hãy chạy dữ liệu lên, xác minh giá trị kinh doanh rồi mới tính đến tối ưu hóa. Đừng vừa bắt đầu đã nghĩ đến chuyện tự xây lại từ đầu, tôi từng trả giá vì điều đó. Hồi đó tôi nghĩ tự xây hệ thống sẽ trông chuyên nghiệp hơn, kết quả là mất ba tháng làm xong rồi mới phát hiện mô hình kinh doanh còn chưa kiểm chứng được, công cốc.

Tự xây dựng pool proxy (DIY)

Tự làm phương án này cũng giống như mua linh kiện về tự lắp máy tính: kiểm soát hoàn toàn, nhưng phải hiểu kỹ thuật.

Nói ngắn gọn, bạn phải tự xử lý những việc này.

Luân chuyển proxy là nền tảng, nếu không thì IP bị chặn đến mức nghi ngờ cuộc đời. Việc này không phải chỉ cần mua một danh sách IP proxy là xong, bạn cần có chiến lược luân chuyển, kiểm tra sức khỏe và thử lại khi thất bại. Proxy dân cư, proxy trung tâm dữ liệu, proxy di động, mỗi loại phù hợp với những kịch bản khác nhau và giá cũng chênh nhau vài lần.

Nhận diện captcha có thể khiến người ta phát điên. Những kiểu thử thách như Cloudflare, hCaptcha, reCAPTCHA v2, đủ mọi biến thể. Bạn phải tích hợp dịch vụ bên thứ ba hoặc tự huấn luyện mô hình. Tôi từng thấy có người dùng 2Captcha, cũng có người dùng Anti-Captcha, nhưng cả hai đều có vấn đề về độ trễ và chi phí.

Việc ngụy trang dấu vân tay trình duyệt còn phức tạp hơn. Website hiện nay không chỉ nhìn IP mà còn kiểm tra dấu vân tay trình duyệt của bạn. User-Agent, dấu vân tay Canvas, dấu vân tay WebGL, danh sách font, thông tin plugin, cả một đống thứ. Bạn phải dùng Puppeteer hoặc Playwright để mô phỏng trình duyệt thật, đồng thời còn phải liên tục nâng cấp theo chiến lược chống crawler của website.

Render JavaScript là một cái bẫy không thể tránh. Hiện nay nhiều website là SPA, không dùng trình duyệt thì gần như không lấy được dữ liệu. Nhưng điều đó cũng có nghĩa là bạn phải duy trì một cụm trình duyệt headless, mức tiêu thụ tài nguyên rất lớn. Một instance trình duyệt tốn vài trăm MB bộ nhớ, khi mức độ đồng thời tăng cao thì chi phí máy chủ cũng tăng theo.

Việc bảo trì bộ phân tích là một hố không đáy. Chỉ cần website thay đổi giao diện là selector của bạn có thể hỏng ngay. Các sàn thương mại điện tử như Taobao, JD thường thay đổi giao diện vài lần mỗi năm. Bạn phải có cơ chế giám sát để phát hiện kịp thời khi việc phân tích thất bại, rồi sửa nhanh. Trước đây tôi gần như tuần nào cũng phải dành vài tiếng để sửa bộ phân tích.

Khi khối lượng tăng, điều phối phân tán là thứ bắt buộc phải làm. Đồng thời trên một máy có giới hạn, nên cần nhiều máy phối hợp với nhau. Hàng đợi Redis, điều phối tác vụ Celery, cân bằng tải, triển khai cả bộ này xong thì lại thành nửa hệ thống nữa.

Mấy thứ này, một người làm một mình cũng mất ít nhất 2-4 tháng mới xong. Dù có đội ngũ thì cũng không phải dự án nhỏ. Tôi từng dẫn ba người làm một bộ, mất tròn bốn tháng mới ổn định.

• Khi nào đáng để tự làm

Nói thật, trong đa số trường hợp thì không đáng. Nhưng có vài trường hợp ngoại lệ như sau.

Khi khối lượng dữ liệu thực sự lớn, tự làm sẽ kinh tế hơn. Nếu lưu lượng request hàng tháng lên đến vài triệu trở lên, phí API tính ra mỗi năm là vài chục vạn, tự triển khai sẽ tiết kiệm hơn. Tôi có một khách hàng trước đây chi 200.000/năm để mua dịch vụ API, sau đó tự làm thì chi phí hạ tầng giảm xuống còn 20.000/năm. Nhưng giai đoạn đầu họ đã đổ vào 150.000 chi phí phát triển và mất nửa năm thời gian. Kiểu đầu tư này phải tính toán kỹ, không phải ai cũng đủ sức theo.

Với những tình huống cần kiểm soát hoàn toàn thì không có lựa chọn nào khác. Ngành tài chính, dữ liệu nhạy cảm, hoặc các tình huống không thể dùng dịch vụ bên thứ ba thì buộc phải tự làm. Tôi từng thấy một công ty giao dịch định lượng vì yêu cầu tuân thủ dữ liệu mà toàn bộ hệ thống crawler phải triển khai trong mạng nội bộ, chỉ có thể DIY.

Khi có đội ngũ chuyên trách thì tự làm là hợp lý. Nếu công ty bạn có hơn 5 kỹ sư chuyên làm thu thập dữ liệu, thì tự xây hệ thống là có giá trị. Nuôi 5 kỹ sư trong một năm cũng phải tốn tới mức hàng triệu, công ty nhỏ không kham nổi. Nhưng công ty lớn đã có cấu hình nhân lực như vậy thì tại sao không tận dụng?

• Cạm bẫy thực tế

Tôi đã thấy quá nhiều cái bẫy, nói vài ví dụ điển hình.

Có một ông tự dựng cả một hệ thống proxy pool, mua proxy dân cư từ một nhà cung cấp proxy nào đó, kết quả là nhà cung cấp bỏ chạy, toàn bộ IP proxy đều thành phế. Không chỉ mất trắng mấy nghìn đồng, mà hệ thống còn phải thiết kế lại logic của proxy pool. Chuyện kiểu này trong ngành proxy không hề hiếm, các nhà cung cấp nhỏ đóng cửa rồi biến mất là chuyện thường.

Có một đội khác đã tốn rất nhiều công sức xây dựng chiến lược chống chống bot, tìm đủ cách vượt qua cho một trang thương mại điện tử nào đó. Kết quả là trang đó nâng cấp hệ thống chống bot, hai tháng làm việc đổ sông đổ biển. Tệ hơn nữa, họ phát hiện chiến lược chống bot mới còn phức tạp hơn, lại phải nghiên cứu lại từ đầu.

Tệ nhất là những trường hợp mất nửa năm xây xong hệ thống, cuối cùng mới phát hiện giá trị kinh doanh không lớn, dự án bị cắt, toàn bộ thời gian coi như lãng phí. Tôi đã thấy tình huống này không chỉ một lần. Đội kỹ thuật cảm thấy tự xây hệ thống rất có cảm giác thành tựu, nhưng bộ phận kinh doanh cần dữ liệu, không phải để xem kỹ thuật của bạn giỏi đến mức nào.

Chi phí bảo trì rất cao. Bạn phải liên tục chạy theo các chiến lược chống bot của website, gần như tuần nào cũng phải vá víu. Hôm nay một site đổi cấu trúc HTML, ngày mai một site khác thêm captcha mới, ngày kia lại có vấn đề với pool proxy. Đạt tỷ lệ thành công 80% đã là ổn rồi, còn muốn vượt 95% thì phải đầu tư liên tục.

Nợ kỹ thuật tích lũy rất nhanh. Giai đoạn đầu để lên sản phẩm nhanh, nhiều chỗ được viết khá qua loa. Ba tháng sau code đã trở nên khó bảo trì. Refactor thì lại tốn thời gian, nhưng không refactor còn khó bảo trì hơn. Đây là một vòng luẩn quẩn.

• Tính chi phí thế nào

Để tôi tính cho bạn một bài toán chi phí thực tế, đừng để mấy người nói "tự xây chi phí thấp" đánh lừa.

Về chi phí phát triển, một kỹ sư cấp cao lương tháng 30.000, làm 3 tháng thì khoảng 100.000. Nếu quy mô đội ngũ lớn hơn một chút, rất dễ vượt 200.000. Đó vẫn là trong trường hợp thuận lợi, tôi từng thấy có dự án làm nửa năm mà vẫn chưa ổn định.

Chi phí vận hành cũng không hề thấp. Proxy dân cư cho 50.000 request thường khoảng 100-300 tệ, dùng số lượng lớn thì có thể thương lượng giá, nhưng vẫn không rẻ. Proxy datacenter rẻ hơn nhưng tỷ lệ thành công thấp, có website còn không dùng được. Dịch vụ captcha 1.000 mã xác thực khoảng 10-20 tệ, làm với khối lượng lớn thì chi phí cũng không nhỏ. Máy chủ mỗi tháng từ vài trăm đến hơn nghìn tệ, tùy vào mức độ đồng thời.

Tổng chi phí năm đầu, thực tế phải bắt đầu từ khoảng 150.000-300.000. Đó còn là trong trường hợp bạn tìm được đội ngũ đáng tin cậy và không vấp phải hố lớn. Nếu gặp tình huống đặc biệt, chẳng hạn một website mục tiêu nào đó cực kỳ khó xử lý, thì chi phí còn phải đội lên thêm.

Trường hợp quá đáng nhất mà tôi từng thấy là có một công ty bỏ ra 800 nghìn để tự xây hệ thống, huy động ba kỹ sư làm suốt nửa năm. Kết quả là một năm sau lại phát hiện dùng API vẫn nhàn hơn, rồi chuyển ngược lại. 800 nghìn coi như đổ sông đổ biển, thời gian cũng bị lãng phí. Sếp thì tức điên, còn đội kỹ thuật cũng rất tủi thân.

• Phân tích sâu chi tiết kỹ thuật

Nói cụ thể về cách triển khai kỹ thuật đi, đừng nghĩ mua proxy là dùng được ngay.

Quản lý pool proxy không phải chuyện đơn giản. Bạn cần có cơ chế kiểm tra tình trạng, định kỳ test proxy còn dùng được hay không. Những proxy có tỷ lệ lỗi cao phải bị loại bỏ, còn proxy mới thì phải được bổ sung vào. Cũng cần có phân bố theo khu vực địa lý, vì một số website mục tiêu yêu cầu IP của quốc gia cụ thể. Việc chọn loại proxy cũng rất quan trọng: có website chỉ cần dùng proxy datacenter là bị chặn ngay, bắt buộc phải dùng proxy residential.

Việc quản lý phiên phức tạp hơn. Một số thao tác phải giữ cùng một phiên, chẳng hạn như chuỗi thao tác sau khi đăng nhập. Điều này có nghĩa là nhiều yêu cầu của bạn phải dùng cùng một IP proxy, đồng thời còn phải quản lý Cookie và Session. Việc lưu trữ và đồng bộ các thông tin trạng thái này đều là vấn đề.

Kiểm soát tần suất request rất dễ bị bỏ qua. Bạn nghĩ request được phân tán trên nhiều IP khác nhau thì sẽ an toàn sao? Không, cùng một mẫu hành vi người dùng, cùng một khung thời gian mà gửi request dày đặc thì vẫn bị nhận diện là bot. Bạn phải mô phỏng hành vi người dùng thật, có độ trễ ngẫu nhiên, có phân bố theo khung thời gian. Nếu làm không tốt những chi tiết này, vẫn sẽ bị chặn.

Lưu trữ và làm sạch dữ liệu cũng là một khối lượng công việc. Dữ liệu crawl về có thể bị trùng lặp, sai sót hoặc thiếu hụt. Bạn cần có cơ chế loại trùng, xác thực dữ liệu và xử lý ngoại lệ. Những việc này nhìn thì nhỏ, nhưng khi quy mô lớn lên sẽ thành vấn đề lớn. Tôi từng xử lý một sự cố dữ liệu crawler mà dữ liệu trùng chiếm tới 30%, suýt làm nổ tung cơ sở dữ liệu.

Giám sát và cảnh báo là bắt buộc. Bạn cần biết trạng thái sức khỏe của từng instance crawler, tình hình phản hồi của từng website mục tiêu, và tính khả dụng của pool proxy. Nếu một website mục tiêu bắt đầu chặn IP trên diện rộng, bạn phải biết ngay để điều chỉnh chiến lược. Không có giám sát thì khi phát hiện vấn đề đã muộn, chất lượng dữ liệu đã bị ảnh hưởng.

Crawl API: Lựa chọn dung hòa

Nói thẳng ra, Crawl API là thứ giúp bạn xử lý mấy việc bẩn và nặng nhọc, trả HTML cho bạn, còn bạn tự phân tích. Đây là phương án tôi đang dùng cho phần lớn dự án hiện nay.

• Nó thực sự giúp bạn làm gì

IP xoay vòng tự động là tính năng cơ bản. Bao gồm proxy dân cư, proxy datacenter, proxy di động, nhà cung cấp thường sẽ tự động chọn theo độ khó của website mục tiêu. Bạn không cần lo quản lý pool proxy, kiểm tra tình trạng, chiến lược xoay vòng, API đã xử lý hết.

Xử lý CAPTCHA bằng dịch vụ sẽ nhàn hơn rất nhiều. Với Cloudflare, hCaptcha, reCAPTCHA và các loại này, các nhà cung cấp API đều có giải pháp chuyên biệt. Có bên dùng mô hình machine learning để nhận diện, có bên tích hợp dịch vụ bên thứ ba, cũng có bên dùng nền tảng nhập mã thủ công. Dù là cách nào, tỷ lệ thành công cũng cao hơn tự làm.

Việc render JavaScript không cần bạn tự làm. Những công cụ như Puppeteer, Playwright không cần bạn cài đặt hay tự bảo trì, nhà cung cấp dịch vụ API đã có cụm render chuyên dụng. Bạn chỉ cần đặt Thông số render_js, còn lại cứ để họ xử lý.

Ngụy trang browser fingerprint giúp tránh bị nhận diện là bot. Những thứ như User-Agent, Canvas fingerprint, WebGL fingerprint, phía nhà cung cấp API đều sẽ mô phỏng như trình duyệt thật. Họ có đội ngũ chuyên nghiên cứu chiến lược chống crawler, tần suất cập nhật chắc chắn cũng cao hơn bạn.

Cơ chế tự động thử lại rất thực dụng. Nếu thất bại thì đổi proxy, đổi fingerprint trình duyệt, đổi chiến lược rồi thử lại lần nữa. Bạn không cần tự viết logic retry, vì bên trong API đã xử lý sẵn. Một số nhà cung cấp còn hỗ trợ retry thông minh, chọn chiến lược thử lại khác nhau dựa trên nguyên nhân thất bại.

Những thứ này, tự làm thì ít nhất mất 2 tháng. Dùng API thì chỉ là chuyện gọi một endpoint.

• Khi nào tôi dùng nó

Nói thật, hiện giờ tôi dùng cái này cho phần lớn dự án, trừ khi nguồn dữ liệu được chuẩn hóa rất cao.

Khi cấu trúc website phức tạp, Crawl API rất phù hợp. Ví dụ như website thương mại điện tử, cấu trúc của mỗi site đều khác nhau, nên phải tự viết logic phân tích. Dùng Crawl API để lấy HTML, rồi tự phân tích bằng BeautifulSoup hoặc Cheerio, độ linh hoạt rất cao. Bạn có thể thực hiện nhiều xử lý tùy chỉnh ở tầng phân tích, như làm sạch dữ liệu, chuyển đổi định dạng, ánh xạ trường.

Khi cần kiểm soát quá trình phân tích, tính linh hoạt của nó rất hữu ích. Đôi khi bạn cần chờ một phần tử tải xong rồi mới thu thập, hoặc cần thực thi một số JavaScript tùy chỉnh, trong những trường hợp như vậy thì tính linh hoạt của Crawl API rất có giá trị. Bạn có thể đặt Thông số wait_for để chờ phần tử cụ thể, cũng có thể đặt timeout để kiểm soát thời gian chờ.

Phù hợp nhất khi năng lực kỹ thuật của đội ngũ ở mức khá. Kỹ sư của bạn cần biết một chút về crawler, hiểu cách parse HTML và xử lý ngoại lệ. Nhưng không cần nắm những chi tiết tầng thấp về chống bot, vì API đã lo phần đó. Mức ngưỡng kỹ thuật này vừa đẹp với đa số đội phát triển: không quá đơn giản, cũng không quá khó.

• Trải nghiệm thực tế

Tôi đã dùng Crawl API của khá nhiều bên, trải nghiệm đều gần giống nhau, mỗi bên có ưu và nhược điểm riêng.

Tích hợp cực nhanh, về cơ bản chỉ mất nửa ngày đến một ngày là có thể chạy được. Lượng code cũng chỉ vài chục dòng, đơn giản hơn rất nhiều so với tự xây hệ thống. Điều khiến tôi ấn tượng nhất là lần đầu dùng, chiều bắt đầu tích hợp, tối đã có dữ liệu. Nếu là hệ thống tự xây, riêng việc cấu hình ổn proxy pool cũng mất một tuần.

Ví dụ mã rất đơn giản, nhưng khi dùng thực tế có nhiều chi tiết cần chú ý. Ví dụ có website cần headers cụ thể, có website cần cookies, có website phải đặt Thông số country để chỉ định khu vực. Nếu xử lý các chi tiết này không tốt, tỷ lệ thành công sẽ bị ảnh hưởng. Tôi thường để đội ngũ chạy thử trước với vài URL test, xác nhận cấu hình Thông số chính xác rồi mới dùng ở quy mô lớn.

Tỷ lệ thành công đúng là cao hơn tự làm. Nếu tự làm, tỷ lệ thành công của tôi khoảng 70-80%, còn dùng API có thể lên hơn 95%. Khác biệt chủ yếu nằm ở khâu xử lý chống bot; bên họ có cả đội ngũ chuyên nghiên cứu mảng này nên mức đầu tư chắc chắn lớn hơn chúng ta. Hơn nữa, nhà cung cấp API có quy mô lớn, nên có thể lấy được tài nguyên proxy tốt hơn từ nhiều kênh khác nhau.

Độ ổn định cũng tốt hơn. Hệ thống tự xây thường xuyên gặp đủ kiểu vấn đề lạ, ví dụ một nút proxy nào đó đột nhiên ngừng hoạt động, hoặc một website mục tiêu nào đó nâng cấp chiến lược chống crawl. Nhà cung cấp dịch vụ API có đội ngũ giám sát và phản ứng khẩn cấp chuyên trách, nên họ có thể phát hiện và xử lý các vấn đề này nhanh hơn.

• Phân tích chi phí

Cho bạn tham khảo giá thực tế, đây đều là mức giá tôi đã dùng thật.

Gói cơ bản thường có phí hàng tháng 50-100 tệ, 10.000 request. Phù hợp cho dự án nhỏ, kiểm chứng MVP. Gói tầm trung có phí hàng tháng 200-500 tệ, 100.000 request. Phần lớn dự án vừa và nhỏ dùng mức này là đủ. Gói doanh nghiệp có phí hàng tháng từ 1000+ tệ, không giới hạn số request. Chỉ khi dữ liệu rất lớn mới cần cân nhắc mức này.

Tôi từng làm một bản so sánh rất chi tiết. Nếu tự xây proxy pool, cộng thêm phần phân bổ chi phí phát triển, thì phải đến khoảng hơn 500.000 request mỗi tháng mới rẻ hơn API. Phần lớn dự án không đạt tới mức đó. Đa số dự án của tôi có lượng request hàng tháng trong khoảng 50.000-200.000, dùng API một năm tốn vài nghìn đến một vạn tệ, còn tự làm thì riêng chi phí phát triển đã lên đến hơn mười vạn tệ.

Chi phí không chỉ là phí API mà còn có chi phí ẩn. Ví dụ như chi phí học tập, đội ngũ của bạn phải học cách sử dụng API. Chi phí gỡ lỗi, khi gặp sự cố phải kiểm tra đó là vấn đề của API hay của mã nguồn của bạn. Chi phí di chuyển, nếu phải đổi nhà cung cấp thì phải sửa mã. Tất cả những điều này đều cần được tính đến.

• Mẹo nâng cao

Nói về một vài mẹo trong quá trình sử dụng thực tế.

Xử lý đồng thời bất đồng bộ có thể nâng hiệu suất lên đáng kể. Phần lớn API đều hỗ trợ request bất đồng bộ, bạn có thể gửi hàng chục request cùng lúc để xử lý song song. Nhưng cần chú ý giới hạn tốc độ, đừng làm quá tải API của nhà cung cấp. Tôi từng gặp trường hợp concurrency quá cao khiến API bị rate limit, kết quả lại chậm hơn.

Bộ nhớ đệm thông minh có thể tiết kiệm khá nhiều chi phí. Một số dữ liệu không thay đổi thường xuyên, như thông tin sản phẩm và hồ sơ công ty. Bạn có thể cache trong một khoảng thời gian để tránh yêu cầu lặp lại. Tôi thường lưu lần yêu cầu đầu tiên vào Redis, các lần sau sẽ kiểm tra cache trước, hết hạn rồi mới cập nhật. Cách này có thể giảm 30-50% số lần gọi API.

Xử lý lỗi phải đủ chi tiết. Không phải mọi thất bại đều cần thử lại, có những lỗi đến từ website mục tiêu, thử lại cũng vô ích. Bạn cần quyết định có thử lại hay không, thử lại bao nhiêu lần và khoảng cách bao lâu dựa trên loại lỗi. Tôi thường chỉ thử lại với lỗi HTTP 429 và 5xx, còn 4xx và 3xx thì không thử lại.

Giám sát và nhật ký rất quan trọng. Bạn cần ghi lại thông tin chi tiết của mỗi lần gọi API, bao gồm Thông số yêu cầu, thời gian phản hồi, tỷ lệ thành công và nguyên nhân thất bại. Những dữ liệu này có thể giúp bạn tối ưu chiến lược sử dụng. Tôi thường xem thống kê mỗi tuần một lần để kiểm tra những website mục tiêu nào có tỷ lệ thành công thấp và liệu có cần điều chỉnh Thông số hay không.

Web Scraper API: Cứu tinh cho người lười

Cái này đỡ tốn công nhất, cứ đưa thẳng cho bạn dữ liệu JSON. Lần đầu tôi dùng, thật sự hơi sốc - hóa ra crawler có thể đơn giản đến vậy.

• Nghĩa là gì

Nói đơn giản, bạn bảo nó cần lấy gì, nó sẽ trả về dữ liệu có cấu trúc.

Ví dụ như hồ sơ cá nhân LinkedIn, bạn gọi một API là nhận về dữ liệu JSON sạch. name, title, company, skills, experience, các trường đều đã được phân tích sẵn cho bạn. Không cần tự phân tích HTML, không cần xử lý selector, cũng không phải lo website thay đổi giao diện. Nhà cung cấp có đội ngũ chuyên trách bảo trì template, website vừa thay đổi là họ cập nhật ngay, bạn hoàn toàn không cần bận tâm.

Không chỉ LinkedIn, thông tin sản phẩm Amazon, hồ sơ người dùng Twitter, bài đăng Instagram, các nền tảng phổ biến này đều có template dựng sẵn. Thậm chí với một số website ngách, nhà cung cấp cũng có thể đã có template. Số lượng template là một chỉ số cạnh tranh quan trọng giữa các nhà cung cấp; những bên lớn có tới vài nghìn template.

Phải làm gì với những website không có mẫu? Phần lớn nhà cung cấp hỗ trợ schema tùy chỉnh. Bạn chỉ cần cho họ biết muốn lấy những trường nào và cách nhận diện các trường đó, họ sẽ giúp tạo quy tắc trích xuất. Có bên dùng machine learning để tự động nhận diện, có bên cho bạn cấu hình bộ chọn CSS. Dù theo cách nào thì vẫn đơn giản hơn nhiều so với tự viết parser.

• Trải nghiệm thực tế

Lần đầu tôi dùng, thật sự có chút choáng. Xong trong 10 phút, dữ liệu là có ngay.

Quy trình tích hợp cực kỳ đơn giản. Đăng ký tài khoản, lấy API Key, đọc tài liệu, viết vài dòng code rồi kiểm thử, toàn bộ quá trình chưa đến nửa giờ. Lần đầu tôi dùng, chiều đăng ký, tối đã có dữ liệu. Hiệu suất như vậy đặc biệt có giá trị cho việc kiểm chứng MVP và tạo prototype nhanh.

Với các website phổ biến như LinkedIn, Amazon, Twitter, Instagram, v.v., đều có sẵn template. Về cơ bản chỉ cần chỉ định template và URL, còn lại không cần lo. Định dạng dữ liệu trả về từ template là cố định, bạn dùng trực tiếp là được. Không giống hệ thống tự xây, mỗi website đều phải viết logic phân tích riêng.

Ví dụ mã rất đơn giản, nhưng khi dùng thực tế vẫn có một số điểm cần lưu ý. Chẳng hạn có những trường có thể để trống, bạn phải xử lý ngoại lệ cẩn thận. Có những trường là mảng, bạn cần duyệt qua để xử lý. Có những dữ liệu là cấu trúc lồng nhau, bạn phải phân tích qua nhiều tầng. Những chi tiết này đều có trong tài liệu, nhưng lần đầu dùng rất dễ bỏ sót.

• Tình huống phù hợp nhất

Rất phù hợp ở giai đoạn MVP. Bạn cần kiểm chứng ý tưởng kinh doanh và lấy dữ liệu với tốc độ nhanh nhất. Đừng lãng phí thời gian vào kỹ thuật, hãy chạy được bài toán kinh doanh trước. Sau khi dữ liệu xác thực được mô hình thương mại, rồi hãy tính đến việc tối ưu phương án kỹ thuật. Tôi đã thấy quá nhiều đội ngũ tốn quá nhiều thời gian cho công nghệ crawler, cuối cùng lại đi sai hướng kinh doanh, khiến toàn bộ đầu tư kỹ thuật đổ sông đổ biển.

Khi không có đội crawler chuyên trách thì dùng cái này là nhàn nhất. Công ty bạn chỉ có một hai lập trình viên, không ai hiểu về thu thập dữ liệu, cũng không muốn tuyển thêm người. Dùng Web Scraper API thì lập trình viên bình thường cũng làm được, không cần kỹ năng chuyên biệt. Điều này đặc biệt thân thiện với các đội nhỏ.

Phù hợp nhất với các nhu cầu tiêu chuẩn hóa. Nếu thứ bạn cần là dữ liệu tiêu chuẩn như hồ sơ LinkedIn cá nhân hay thông tin sản phẩm Amazon, thì đã có sẵn mẫu, không cần tự làm. Kiểu dữ liệu này có định dạng trường cố định, chất lượng mẫu cao, dùng rất nhàn.

Ưu tiên hàng đầu cho các dự án nhạy cảm về thời gian. Nếu khách hàng cần dữ liệu rất gấp, hoặc cơ hội thị trường trôi qua rất nhanh, bạn không thể mất vài tháng để xây hệ thống riêng. Dùng Web Scraper API thì chỉ vài ngày là có thể lên production. Tôi có một khách hàng, đối thủ của họ đang tự xây hệ thống, còn họ dùng API trực tiếp, vào thị trường sớm hơn hai tháng và giành được lợi thế trước.

• Những cạm bẫy thực tế

Cũng không phải hoàn hảo, có vài cái bẫy cần biết, đừng để vấp phải rồi mới biết.

Khả năng tùy chỉnh là một điểm đau. Nếu trường dữ liệu bạn cần không có trong template thì sẽ khá phiền. Một số nhà cung cấp hỗ trợ schema tùy chỉnh, nhưng không phải bên nào cũng có. Ngay cả khi có hỗ trợ, tùy chỉnh vẫn rắc rối hơn template dựng sẵn. Tôi từng gặp trường hợp như vậy: template không có trường cần lấy, cuối cùng chỉ còn cách tự viết quy tắc trích xuất, và rốt cuộc còn không bằng dùng Crawl API.

Chi phí đúng là cao hơn một chút. So với Crawl API, cùng số lượng request thì đắt hơn 30-50%. Bạn phải tính kỹ xem phần chi phí tăng thêm đó có đáng hay không. Nếu khối lượng dữ liệu lớn, chênh lệch chi phí sẽ rất rõ. Tôi có một khách hàng, lưu lượng request hàng tháng là 500.000, dùng Web Scraper API tốn 30.000 mỗi tháng, đổi sang Crawl API chỉ còn 20.000.

Phụ thuộc vào bên thứ ba có rủi ro. Nếu nhà cung cấp đóng cửa hoặc ngừng dịch vụ, bạn sẽ phải di chuyển. Tuy vậy, thông thường họ đều có chức năng xuất dữ liệu nên cũng không phải vấn đề quá lớn. Nhưng việc chuyển đổi vẫn cần thời gian, và trong thời gian đó hoạt động kinh doanh có thể bị ảnh hưởng. Tôi từng gặp một lần nhà cung cấp bị mua lại, chiến lược sản phẩm bị điều chỉnh, một số template không còn được duy trì nữa, buộc chúng tôi phải đổi nhà cung cấp.

Chất lượng dữ liệu đôi khi không hoàn hảo. Template dựng sẵn tuy tiện, nhưng không chính xác 100%. Tôi từng gặp template LinkedIn nhận diện sai tên công ty, template Amazon thì bỏ sót khi parse giá. Trong trường hợp đó, bạn phải nhờ bộ phận hỗ trợ của nhà cung cấp, hoặc tự xử lý lại lần hai. Dù không xảy ra thường xuyên, nhưng gặp phải thì rất đau đầu.

Việc cập nhật có độ trễ. Sau khi website thay đổi giao diện, việc cập nhật mẫu thường mất từ vài ngày đến một tuần. Trong những ngày đó, dữ liệu bạn thu thập có thể không chính xác. Nếu nghiệp vụ của bạn yêu cầu độ chính xác dữ liệu đặc biệt cao, đây là một vấn đề. Tôi thường chờ đến khi mẫu ổn định rồi mới dùng ở quy mô lớn, còn mẫu mới thì trước tiên kiểm thử với lưu lượng nhỏ.

• Mẹo sử dụng chuyên sâu

Hãy nói về cách dùng nâng cao.

Tích hợp webhook đỡ tốn công hơn. Không phải bạn chủ động kéo dữ liệu, mà nhà cung cấp sẽ đẩy dữ liệu đã xử lý sang cho bạn. Bạn chỉ cần cung cấp một webhook URL, sau khi crawl xong họ sẽ POST dữ liệu cho bạn. Cách này có tính thời gian thực cao hơn và cũng bỏ được bước polling. Nhưng cần lưu ý dịch vụ của bạn phải có độ sẵn sàng cao, nếu không dữ liệu có thể bị mất.

Xử lý hàng loạt giúp tiết kiệm chi phí. Phần lớn nhà cung cấp hỗ trợ yêu cầu hàng loạt, một lần gọi API có thể xử lý nhiều URL. Cách này giảm chi phí mạng, đôi khi còn được hưởng ưu đãi theo lô. Tôi thường gom một loạt URL rồi gửi theo lô, nhanh hơn nhiều so với gửi từng yêu cầu riêng lẻ.

Cần chú ý khi chuyển đổi dữ liệu. Dữ liệu trả về từ các nhà cung cấp khác nhau có thể không giống nhau, từ cách đặt tên trường, kiểu dữ liệu đến cấu trúc lồng nhau đều có thể khác. Nếu bạn muốn đổi nhà cung cấp, sẽ phải làm ánh xạ dữ liệu. Tôi khuyên nên tạo một lớp trừu tượng ở tầng API để chuẩn hóa định dạng dữ liệu từ các nhà cung cấp khác nhau. Như vậy khi đổi nhà cung cấp, code ở tầng nghiệp vụ sẽ không cần sửa.

Theo dõi trạng thái mẫu. Dù việc bảo trì mẫu là của nhà cung cấp, bạn vẫn cần theo sát. Nếu một mẫu thường xuyên gặp lỗi hoặc có trường nào đó luôn phân tích không chính xác, có thể cần đổi mẫu hoặc đổi nhà cung cấp. Tôi đều xem tỷ lệ thành công và độ chính xác của từng mẫu hằng tuần, phát hiện vấn đề là điều chỉnh kịp thời.

Bảng so sánh 3 phương án

Bảng này được tổng hợp từ dữ liệu thực tế của nhiều dự án, đáng tin hơn mấy kiểu phân tích lý thuyết nhiều. Bạn có thể đối chiếu với tình hình của mình để xem phương án nào phù hợp hơn.

Khuyến nghị của tôi

Nói nhiều rồi, giờ đưa vài gợi ý thực tế, كلها được đúc kết từ kinh nghiệm chiến đấu thực tế.

• 90% trường hợp: bắt đầu từ API

Thật đấy, đừng vừa bắt đầu đã nghĩ tự làm. Trước tiên dùng API để chạy được nghiệp vụ, kiểm chứng giá trị dữ liệu, rồi hãy tính đến tối ưu.

Tôi đã thấy quá nhiều đội ngũ mắc kẹt trong việc chọn công nghệ suốt vài tháng, cuối cùng cơ hội kinh doanh cũng mất. Ở giai đoạn MVP, điều quan trọng nhất là tốc độ, không phải phương án kỹ thuật hoàn hảo. Bạn dùng API để xác thực nhanh, nếu thấy dữ liệu có giá trị thì sau đó cân nhắc tự xây cũng chưa muộn.

Web Scraper API là nhanh nhất, phù hợp để xác minh nhanh. Crawl API linh hoạt hơn một chút, phù hợp với các tình huống cần phân tích tùy chỉnh. Phần lớn MVP chỉ cần hai cái này là đủ.

Đợi đến khi khối lượng dữ liệu của bạn thực sự lớn đến mức không chịu nổi chi phí API rồi hẵng cân nhắc DIY. Nhưng nói thật, phần lớn dự án không đạt tới mức đó. Tôi đã làm rất nhiều dự án, chỉ có một dự án đạt tới mức hàng triệu request mỗi tháng, còn lại đều dưới vài trăm nghìn.

• Khi nào nên cân nhắc DIY

Chỉ cân nhắc khi đáp ứng đủ các điều kiện này, thiếu một cũng không được.

Thứ nhất, lượng yêu cầu hằng tháng trên 1 triệu. Ở quy mô này, chi phí API không rẻ, tự xây có cơ hội tiết kiệm hơn. Nhưng phải tính rõ tổng chi phí, đừng chỉ nhìn vào phí API.

Thứ hai, có đội ngũ chuyên trách. Nhóm kỹ sư từ 5 người trở lên, có kinh nghiệm crawler. Nếu không có cấu hình nhân lực này, đừng nghĩ đến DIY.

Thứ ba, bạn phải xác định làm lâu dài. Ít nhất trên 2 năm. Tự xây cho dự án ngắn hạn thì không đáng, còn chưa thu hồi nổi chi phí phát triển.

Thứ tư, nhạy cảm về chi phí. Không phải là thiếu tiền, mà là tính toán xong thì tự xây sẽ kinh tế hơn. Nếu phí API một năm chỉ vài chục nghìn, đừng lăn tăn nữa.

Tôi đã thấy rất nhiều dự án chỉ đáp ứng một trong các điều kiện đó mà đã chọn DIY, kết cục đều rất tệ. Hoặc là đội ngũ không xử lý nổi, hoặc là nghiệp vụ thay đổi, hoặc là tính sai chi phí. Phải đáp ứng đủ cả bốn điều kiện thì DIY mới đáng làm.

• Phương án kết hợp thực ra là thực dụng nhất

Cách tôi làm hiện nay thường là dùng kết hợp, không phải chỉ chọn một trong hai.

Nghiệp vụ cốt lõi, khối lượng dữ liệu lớn thì dùng hệ thống tự xây. Ví dụ nếu bạn muốn theo dõi thứ hạng Google với hàng trăm nghìn yêu cầu mỗi ngày, cái này bắt buộc phải tự xây, vì chi phí API quá đắt.

Với nghiệp vụ hỗ trợ, dữ liệu nhỏ, dùng API. Ví dụ, crawl tin tức từ một số website ngành, mỗi ngày vài trăm request, dùng API là tiện nhất.

Chuẩn hóa nguồn dữ liệu bằng Web Scraper API. Với những nền tảng có sẵn mẫu như LinkedIn, Twitter, cứ dùng trực tiếp template, không cần tự phân tích.

Nguồn dữ liệu phức tạp thì dùng Crawl API. Với cấu trúc phức tạp, cần phân tích tùy chỉnh, hãy dùng Crawl API để lấy HTML rồi tự phân tích.

Làm vậy vừa kiểm soát được chi phí, vừa tránh đầu tư quá mức. Chỗ nào cần tiết kiệm thì tiết kiệm, chỗ nào cần đầu tư thì đầu tư. Đừng áp dụng một cách cứng nhắc, hãy linh hoạt lựa chọn theo tình hình thực tế.

• Cạm bẫy khi lựa chọn công nghệ

Cuối cùng, nói về những cái bẫy thường gặp để tránh dẫm phải.

Cái bẫy đầu tiên là thiết kế quá mức. Ngay ở giai đoạn MVP đã muốn làm một hệ thống hoàn hảo, nào là tính sẵn sàng cao, phân tán, microservices, kết quả là làm mấy tháng vẫn chưa lên sản phẩm. Hãy nhớ: chạy được trước, rồi mới tối ưu.

Cái bẫy thứ hai là tự say mê kỹ thuật. Cứ nghĩ tự xây hệ thống là có hàm lượng kỹ thuật, thể hiện trình độ, nhưng cuối cùng giá trị kinh doanh còn chưa được kiểm chứng, khoản đầu tư kỹ thuật coi như đổ sông đổ biển. Kỹ thuật phải phục vụ kinh doanh, không phải để phô diễn.

Cái bẫy thứ ba là đánh giá thấp việc bảo trì. Tưởng rằng xây xong hệ thống là xong, nhưng thực ra bảo trì mới chỉ vừa bắt đầu. Website thay đổi giao diện, chống bot nâng cấp, proxy hết hiệu lực, tuần nào cũng có vấn đề mới. Bạn phải chuẩn bị sẵn tâm lý cho việc đầu tư liên tục.

Cái bẫy thứ tư là chỉ nhìn đơn giá API. Thấy API đắt, nhưng không tính chi phí phát triển tự xây. Với 100.000 request, API tốn 500 tệ mỗi tháng, còn chi phí phát triển tự xây là 100.000 tệ, phải mất 20 năm mới hoàn vốn. Phải tính tổng chi phí, đừng chỉ nhìn đơn giá.

Cái bẫy thứ năm là bỏ qua chi phí cơ hội. Bạn dành 3 tháng để tự xây hệ thống, nhưng trong 3 tháng đó thị trường có thể đã thay đổi. Đôi khi lên sản phẩm nhanh còn quan trọng hơn tiết kiệm tiền; nếu tính cả chi phí cơ hội thì API có thể kinh tế hơn.

Tóm tắt

Làm nghề crawler này, đừng quá mê tín công nghệ. Mấu chốt là giá trị kinh doanh.

Nếu việc kinh doanh của bạn mỗi tháng chỉ kiếm được vài nghìn tệ mà lại bỏ 100.000 tệ để làm một hệ thống crawler, tính kiểu nào cũng không đáng. Dùng API thì mỗi tháng chỉ vài trăm tệ, mà chất lượng dữ liệu còn tốt hơn.

Nếu một tháng doanh nghiệp kiếm được vài triệu, thì bỏ ra vài trăm nghìn để xây một hệ thống cũng đáng. Lúc này chi phí không còn là vấn đề, tính ổn định và khả năng kiểm soát quan trọng hơn.

Vì vậy, hãy tính bài toán kinh doanh trước rồi mới tính bài toán kỹ thuật. Trong đa số trường hợp, dùng API là đủ, đừng nghĩ quá nhiều.

Trong các dự án tôi từng làm, 90% cuối cùng đều dùng API. Những trường hợp thực sự cần tự xây dựng đều là nghiệp vụ cốt lõi của các tập đoàn lớn. Nếu bạn là startup hoặc doanh nghiệp vừa và nhỏ, đừng nghĩ đến chuyện học theo giải pháp kỹ thuật của các ông lớn, vì nguồn lực của họ khác bạn.

Hãy nhớ câu này: dùng cách nhanh nhất để kiểm chứng ý tưởng, dùng cách rẻ nhất để lấy dữ liệu. Công nghệ là để giải quyết vấn đề, không phải tạo ra vấn đề.