Thử thách khi đi cào dữ liệu ở quy mô lớn – Web Scraping at Scale

Gần đây chủ đi cào dữ liệu hay còn gọi là Web Scraping rất được quan tâm với các bạn developer mới vào nghề lẫn các nhà làm nghiên cứu thị trường hay mỹ miều hơn là làm về khoa học dữ liệu, dữ liệu lớn Big Data, hay thậm chí là Machine Learning, Trí tuệ nhân tạo (ML/AI). Ở bài trước mình đã chia sẻ về ngôn ngữ / framework nào thông thường dùng để cào dữ liệu, bài này mình sẽ chia sẻ về những thử thách khi cào dữ liệu ở quy mô lớn, 300-500 trang web cùng một lúc thì có những thử thách nào. Mong nhận được chia sẻ kinh nghiệm của các bạn để bài viết thêm phong phú nhé.

1/ Vấn đề nơi nào lưu trữ khối lượng dữ liệu lớn như thế?

Do bài này mình chia sẻ quản lý dữ liệu ở quy mô lớn có thể hàng chục tỷ trang web ở 300-500 website hàng tháng. Thông thường các hệ thống này, chúng ta cần xây dựng một hệ thống để lưu trữ dữ liệu gọi là Data Warehouse (DWH).

Việc xây dựng một hạ tầng DWH lưu trữ đảm bảo:

  1. Tính mở rộng (Scalability & Secure) – dữ liệu đổ về hàng ngày rất lớn, người ta thông thường xây dựng các ETL (Extract Transform Load) để đổ dữ liệu về vào cuối ngày, người ta gọi đó là EoD (End of Day).
  2. Tính sẵn sàng (Availability & Durability) – Dữ liệu sau cùng là tài sản quý nhất của một tổ chức, việc mất mát dữ liệu hay gián đoạn truy cập đều gây ảnh hưởng.
  3. Tính tiện lợi (Easy of use) – Và cuối cùng khi tổ chức dữ liệu thành công, cần một số công cụ / dịch vụ để tìm kiếm, lọc, trích xuất, thể hiện dữ liệu này.

Để xây dựng việc này dễ dàng và nhanh chóng, ta có thể sử dụng các dịch vụ của AWS để lưu trữ:

  1. RDS Aurora để lưu trữ dữ liệu có quan hệ.
  2. Dynamo DB để lưu trữ dữ liệu phi cấu trúc.
  3. S3 để lưu trữ dữ liệu thô dùng để phân tích sau này và S3 cũng ngon rẻ. Mình recommend tận dụng tối đa dịch vụ này khi làm DWH.

Lợi ích lớn nhất của bộ 03 Aurora, Dynamo và S3 là sự sẵn sàng và fully managed services bởi AWS, đây cũng là các dịch vụ native cloud có lợi khi sử dụng về lâu dài. Vd: S3 không có giới hạn về lưu trữ trong 1 bucket, mỗi object trong bucket hiện có file size tối đa 5TB, nếu dùng PUT request có thể tới 5GB (với object lớn hơn 100MB mình nên sử dụng tính năng MultiPart Upload của S3).

2/ Vấn đề thay đổi Pattern ở trang web

Các website lớn có thể thay đổi cấu trúc về mặt tổ chức lẫn hiển thị, điều này khiến các setup trong spider bị lỗi thời và cần cập nhật hoặc sai. Với các site thiếu sự ổn định và hay thay đổi cấu trúc mình nên setup các quy trình BoD (Begin of Day( và EoD (End of Day).

  1. BoD: Khởi tạo crawler chạy lưu vào một chỗ tạm. Định kỳ inspection xem có lỗi ở crawler không.
  2. EoD: Xây dựng ETL để đẩy dữ liệu từ vùng tạm vào DWH.

Việc xây dựng quy trình này ngắn hay dài (1 ngày hay 1 tuần hay 1 giờ) tùy thuộc vào độ quan trọng của dữ liệu, mức sẵn sàng để trích xuất dữ liệu xử lý mong đợi.

Nếu có thời gian bạn nên viết test case và thực hiện Automation Testing tự động trong quá trình crawling dữ liệu. Ví dụ ở AWS bạn có thể sử dụng dịch CodePipeline (CodeBuild) hoặc Jenkins để xây dựng các kịch bản test tự động. Ngữ cảnh này nằm trong CI/CD mà mấy bạn DevOps hay làm, với quy mô nhỏ lẻ thì việc này ko quan trọng, nhưng khi nói đến “Scale” rồi thì không thể làm bằng “Cơm” thủ công được.

3/ Bị chặn cào dữ liệu

Việc này là hợp lý bởi việc bạn cào dữ liệu đồng nghĩa là website đó sẽ bị ảnh hưởng truy cập, làm tăng phần băng thông, ảnh hưởng với các user thật truy cập thời điểm đó. Nên cào dữ liệu cũng cần tuân theo luật và có đạo đức nghề nghiệp chút. Một số đạo đức nhập môn là:

  1. Không nên cào dữ liệu vào giờ cao điểm.
  2. Tuân thủ những rule đặt ra trong robots.txt cho phép cào và không cho phép cào chỗ nào.
  3. Cào dữ liệu có bản quyền như video, hình ảnh, bài viết
  4. Sử dụng dữ liệu cào được một cách phi pháp…
  5. Nói chung là cào ở Scale lớn cần phải rất cẩn thận

Rất nhiều website chặn cào, nổi tiếng nhất là Linkedin. Nếu crawler của bạn hit vào một trang với tuần suất cao thì có nguy cơ bạn sẽ bị block IP, hoặc một số trang thông minh sẽ offer ra Captcha ngay… Ở ngữ cảnh này bạn nên dùng một proxy để xoay vòng địa chỉ IP, tránh bị block. Scrapy framework hỗ trợ tích hợp một số dịch vụ xoay vòng địa chỉ IP, về mặt hiệu năng thì Scrapy cũng mạnh mẽ nhanh hơn nhièu so với BeautifulSoup, Selenium.

4/ Javascript render nội dụng đông 

Hiện nay các phương thức lập trình frontend sử dụng JS/AJax rất nhiều để render ra nội dung html, điều này khiến cho cào dữ liệu gặp nhiều khó khăn. Hiện tại các framework về Scraping chỉ hỗ trợ cào dữ liệu HTML. Ajax hay JS được thực thi lúc runtime, do đó không thể cào.

Để vượt qua điều này crawler của các bạn phải render ra một trang web thật, bạn có thể tìm hiểu thêm về Headless Chrome, bản chất framework này sẽ render ra một website thật ở môi trường runtime. Một số lựa chọn khác là PhantomJS.

5/ Chất lượng dữ liệu

Cuối cùng dữ liệu lấy về là mới chỉ là bắt đầu, có thể đưa vào các mô hình học máy, trí tuệ nhân tạo… Dữ liệu cần crawl trong thời gian thực nếu chất lượng không tốt việc rollback dữ liệu sẽ mất chi phí. Do đó, việc đảm bảo dữ liệu lấy về là tốt là cánh cửa cuối cùng trước khi dữ liệu này chuyển sang một giai đoạn khác cao cấp hơn.

6/ Thời gian 

Với dữ liệu lớn việc crawl dữ liệu sẽ mất rất nhiều thời gian. Việc crawl này vẫn phải đảm bảo đúng luật và ko bị block. Bạn có thể phải triển khai nhiều crawler trên từng hạng mục nhỏ. VD: Bạn chia crawl theo từng category sản phẩm của 1 trang web như thế make sense hơn. Hoặc một crawler bạn thiết lập nhiều tiến trình cùng lúc, với Python bạn có thể xem xét qua Frontera và Scrapy Redis.

  1. Frontera – bạn có thể hit nhiều website cùng lúc, mỗi một website hit 1 lần vào 1 thời điểm.
  2. Scrapy Redis – bạn có thể hit nhiều request đến cùng 1 website. vào một thời điểm.

Bạn nên kết hợp cả 02 để đạt tối đa hiệu quả.

7/ Triển khai Fleet of Crawlers

Đây thực sự là vấn đề nếu số lượng website bạn lên tới hàng ngàn website, thậm chí chục ngàn. Bạn có thể phải lo lắng về tài nguyên bất thường (lúc quá nhiều, lúc lại tải thấp). Với AWS, bạn có thể sử dụng auto scaling khi triển khai EC2 cơ bản (mình thì không thích sử dụng EC2 lắm), hoặc sử dụng AWS Fargate một dạng container serverless rất hay ho và xịn xò.

Kết bài

Việc crawl dữ liệu là một việc hay ho và dễ làm, nhưng crawl dữ liệu ở quy mô lớn là môt sự khác biệt. Nếu bạn xem đây là một việc nghiêm túc bạn cần nghiên cứu cả về mặt kỹ thuật triển khai, luật áp dụng và cách sử dụng dữ liệu một cách hợp lệ, hiệu quả.

Gud luck and have fun!

 

 

Topics #aws #beautifulsoup #crawler #ecs #fargate #scraping #scrapy #spider #web scraping