Nằm trong chuỗi Technical Event Series được tổ chức bởi Gambaru, buổi chia sẻ thứ 2 về Distributed Crawling System (hệ thống thu thập dữ liệu phân tán) đã diễn ra với sự tham gia của hơn 50 người đăng ký đến từ nhiều lĩnh vực chuyên môn khác nhau nhưng có mối quan tâm chung về Dữ liệu phân tán.

Buổi chia sẻ với sự tham gia của 2 speaker là anh Đạt Hồ (CTO) và anh Tín Đặng (Data Engineer đến từ startup VietMoney.

Hai anh đã chia sẻ hết sức nhiệt tình những hiểu biết cũng như kinh nghiệm triển khai crawling system cho VietMoney, cũng như trả lời rất hào hứng các câu hỏi đến từ các anh, chị tham gia.

Nói qua một chút về VietMoney (VM), đây là công ty thuộc lĩnh vực tài chính, chuyên cung cấp các khoản vay ngắn hạn trên 63 tỉnh thành, hiện nay hệ thống của VietMoney đã lên đến 40 chi nhánh. Anh Đạt chia sẻ, ngay từ những ngày đầu hoạt động, VietMoney đã chú trọng sử dụng công nghệ và data để hỗ trợ doanh nghiệp vận hành theo mô hình chuỗi thuận lợi nhất.

Nội dung bài viết tóm lược các ý chính từ buổi chia sẻ, để nắm bắt đầy đủ hơn, bạn có thể xem video bên dưới bài viết.

Ngoài ra, bạn có thể tham gia group cộng đồng của Gambaru trên Telegram để theo dõi các sự kiện tiếp theo nhé.

Thách thức trước khi làm Distributed Crawling System

Thách thức kinh doanh trong lĩnh vực tài chính tín dụng được anh Đạt tóm lại trong một câu: Càng bán nhiều hàng đồng nghĩa với rủi ro càng tăng.

Điều đó bắt buộc VM phải sử dụng công nghệ để tối thiểu hóa rủi ro này.

Vậy họ làm việc đó như thế nào?

Điều đầu tiên cần nói VM là mô hình cho vay cầm đồ, nghĩa là sẽ thanh toán dựa trên tài sản của khách hàng (không giống như FE Credit).

Đối với một doanh nghiệp thời đại chuyển đổi số, VM đã trang sẽ có các nền tảng về công nghệ sau đây:

ERP
Core product
CRM/CDP: Để quản lý và hỗ trợ khách hàng tốt nhất
HRM & Culture
Cloud computing
Data driven: giúp cho độ giàu về dữ liệu và tài nguyên ngày càng lớn, dựa vào dữ liệu đưa ra quyết định kinh doanh
Big data/ML/DL/AI: ML để định giá tài sản, cung cấp real time report để ra quyết định nhanh nhất

*Các thành phần công nghệ VietMoney xây dựng*

Trong đó, Data Driven là phần anh Đạt cho rằng bản thân và team đang làm tốt và đó cũng chính là trọng tâm của buổi chia sẻ.

Các bước triển khai Data Driven

Câu hỏi đặt ra đối với vấn đề dữ liệu từ những ngày đầu khi doanh nghiệp chưa có gì đó là:

Thu thập dữ liệu từ bao nhiêu nguồn?
Những nguồn nào?
Làm thế nào doanh nghiệp có thể tin tưởng những dữ liệu này.

Để trả lời những câu hỏi này, VM đã thực hiện các bước sau:

Thu thập dữ liệu
Xử lý dữ liệu
Phân tích dữ liệu
Làm data modeling
Ứng dụng model
Ứng dụng machine learning để định giá tài sản

Đây là những bước ai cũng muốn làm và hướng tới, nhưng ở thời điểm 2017, VM không thể thực hiện 2 bước là Data Modeling và Apply Model, chỉ có thể làm 4 bước còn lại, tức là chưa thể dùng Machine Learning.

Đến hiện tại, VM đã triển khai tương đối thành công 6 bước trong toàn bộ quy trình (ứng dụng Machine Learning). Trong đó, web scraping (hay web crawling) một lần nữa, lại là trọng tâm của những chia sẻ tiếp theo.

Web scraping (web crawling) hoạt động như thế nào?

Năm 2017, VM sử dụng những công nghệ (tech-stack)dưới đây để làm web crawling:

Spiders: Scrapy, ngôn ngữ Python
Data lake: Elasticsearch
Database (mysql)

*Tech stack được sử dụng làm Web crawling của VietMoney vào năm 2017*

Lúc này, anh Đạt xem Elasticsearch như một data lake có thể lưu mọi dữ liệu, và giúp ‘nhảy cóc’ từ bước Data Analyze sang Valuation (mà không làm 2 bước Data Modeling và Apply Model) nhờ khả năng visualize, thống kê dữ liệu của công cụ này.

Tuy nhiên sau khi vận hành 1 thời gian, VM gặp phải một số thách thức khi làm Data Analyze với Elasticsearch

Scrapy chạy single-threaded (đơn luồng), dẫn đến performance, cách hoạt động bị hạn chế
Luôn phải thay đổi Spider khi muốn thêm data source, hoặc website muốn thu thập thay đổi cấu trúc thường xuyên.
Gặp trở ngại khi viết dữ liệu xuống Elasticsearch
Thu thập, xuất và làm đẹp dữ liệu tại cùng 1 chỗ (mô hình Monolith), mô hình này hỗ trợ làm nhanh nhưng gặp rủi ro khi vận hành như chạy thất bại hoặc không chạy được trên một số môi trường phần cứng.
Không biết phải làm sao khi website bị chặn, không vào được nữa và cũng không có cơ chế retry.

Giải pháp cho những thách thức

Với những thách thức, trở ngại như trên.

Đầu tiên, VM cần phải thay đổi khái niệm spider đã xây dựng từ ban đầu.

Thứ 2 là mỗi bước trong quy trình web scraping đều phải có service, module riêng để vận hành độc lập, không liên quan gì đến nhau.

Lúc này có 3 sự lựa chọn:

Sử dụng Saas (software as a service) như Scrapping hub; Import.io. Vấn đề với lựa chọn này là làm sao đồng bộ giữa dữ liệu đang lưu sẵn trên Elasticsearch và dịch vụ SaaS để tiếp tục sử dụng, ngoài ra chi phí vận hành của các dịch vụ này khá cao.
Tự xây dựng: sửa lại từ open source, hoặc làm từ đầu. Team VM tìm được Frontera, 1 open source xây dựng trên mô hình Distributed Crawling System. Hiện tại Frontera không còn được phát triển nữa và đây là điều đáng tiếc vì nó 1 open source nổi tiếng và có chất lượng rất tốt.
Mua phần mềm bên ngoài

Sau khi cân nhắc các lựa chọn, VM quyết định xây Distributed Crawling System (hệ thống thu thập dữ liệu phân tán) từ con số 0. Việc xây dựng này là dựa trên kiến trúc và cảm hứng từ Frontera.

Vậy VM đã làm gì?

Distributed Crawling System do VietMoney xây dựng

Đây là mô hình Distributed Crawling System được VietMoney xây dựng:

*Mô hình Distributed Crawling System do VietMoney xây dựng*

Việc xây dựng hệ thống phải giải quyết được những thách thức đưa ra bên trên.

Giải quyết hạn chế của Spider

Đầu tiên là có thể linh hoạt trong việc sửa spider mà không cần xây lại source hoặc thay đổi crawler, từ đó phân tán spider chạy được nhiều chỗ.

Điều này bắt buộc phải nghĩ đến là spider chỉ làm nhiệm vụ duy nhất là đưa URL để thực hiện lấy dữ liệu website và trả về.

Nhưng để quản lý các URL này, phải cần đến URL service, nơi quản lý tất cả tài nguyên thu thập được và đưa các URL vào URL Pool dựa trên nền tảng Google Cloud Pub Sub.

Những spider sẽ lắng nghe tất cả các url cần được thu thập => phân tán chạy ở những nơi nào có hỗ trợ chạy container

Sau khi thu thập xong một tài nguyên, đẩy kết quả vào lại google cloud pub/sub. URL Service lắng nghe và đánh dấu vào db là url đó đã được thu thập và vào giờ nào. Các metadata, dung lượng website, title hoặc các thứ liên quan được lưu vào Google Cloud Storage (Data Lake).

Tách biệt Data crawling và Data processing

Trước đây VM gom chung thực hiện Data crawling và process ở 1 chỗ và việc này rất rủi ro. Vì vậy sự điều chỉnh bắt buộc là phải tách biệt 2 bước này.

VM bắt đầu xây dựng Extract Service (chạy và quản lý bởi AirFlow). Nhiệm vụ của ES là ETL (extract, transform, load) và lưu vào data warehouse sau khi có được dữ liệu.

Các thành phần chính trong Distributed Crawling System

URL Service

Phần này giải thích vì sao URL service có thể linh hoạt như vậy.

Với các website public (sitemap), thường thông qua sitemap.xml để tăng độ search của bot google. Vietmoney dựa vào sitemap của website đó để biết những url cần thu thập và độ sâu của mỗi sitemap.

Với những website không hỗ trợ sitemap thì sẽ đi theo cơ chế html dom. Nghĩa là bóc tách dữ liệu dựa trên cấu trúc Dom của website và dựa trên xpath (đường dẫn vào dữ liệu muốn lấy).

Sau khi nhận được cấu trúc dữ liệu về data source, sẽ lưu vào Source URL Manager (lưu lại bộ cấu hình của 1 website) và dựa vào đó Source URL Manager thực hiện lấy dữ liệu từ sitemap để tìm URL cần thiết)

Sau khi thực hiện thu thập dữ liệu thì sẽ lưu đường dẫn vào 1 Database (MongoDB).

Sau đó đẩy các URL này vào URL Pool. Trước khi đưa vào sẽ thực hiện thuật toán random choice để không xảy ra tình trạng có quá nhiều URL liên quan tới 1 website trong 1 thời điểm.

Splash spider

Sau khi URL Service thực hiện công việc nhận vào đường dẫn, cấu hình, tìm và lưu URL, URL sẽ publish lên Google Cloud Pub Sub để Splash Spider làm việc.

Scrapy lắng nghe message từ URL full, sau đó thực hiện request, qua 1 lớp middleware, middleware hỗ trợ crawler đóng vai trò như 1 người truy cập website bình thường. Sau đó sẽ thực hiện request url, web render. Crawler thu thập dữ liệu xong sẽ trả response (chỉ lưu dữ liệu trả về, không làm gì)

Sau khi có dữ liệu, các response worker (luôn lắng nghe các response message). Response work có 2 nhiệm vụ chính:

Lưu vào record manager: website này đã được crawl vào thời điểm nào
Lưu meta data và nén nội dung kết quả dưới dạng .zip để đẩy lên Google Cloud Storage.

Tới đây đã hoàn thành xong phần về Distributed Web Crawler.

Extract service

Sau khi đã có dữ liệu trong Google Cloud Service, làm thế nào để trích xuất dữ liệu này, lúc này cần tới Extract service.

Xử lý dữ liệu tại Extract service bao gồm:

Host Aggregator: Trích xuất nội dung dữ liệu mong muốn (không lấy tất cả)
Extract config: Định nghĩa các field và cách trích xuất dữ liệu qua sự hỗ trợ của các Extractor (XPATH, CSS, JMES…)
Transformer: chuyển đổi, thay đổi dữ liệu thành dữ liệu sử dụng được.

Nhờ thiết kế như thế này nên chỉ cần thay đổi Extract config là ra được dữ liệu mong muốn, không cần thay đổi service.

Minh họa việc mapping giữa dữ liệu mình cần và web page được thu thập dữ liệu

*Minh họa việc mapping giữa dữ liệu cần thu thập và dữ liệu có trên web page*

Sau khi trích xuất, dữ liệu sẽ được lưu vào Data warehouse để phục vụ

Kết quả sau khi triển khai Distributed Crawling System

Việc đi từ hệ thống Monolith lên Distributed Crawling System thì độ khó và độ phức tạp cũng tăng lên. Vì vậy vẫn cần 1 đội ngũ (số lượng, chất lượng) để quản trị được hệ thống sau khi triển khai thành công.

Dưới đây là những kết quả VietMoney nhận được từ khi có Distributed Crawling System.

Quản trị được crawling làm gì, chạy giờ nào, ở đâu, bao nhiêu thất bại, bao nhiêu thành công (sử dụng hệ thống monitoring)
Linh hoạt khi website muốn thu thập data thay đổi cấu trúc
Các thành phần chạy hoàn toàn độc lập, làm tốt nhất nhiệm vụ của mình, sự phụ thuộc giữa các service ở mức tối thiểu.
Spider tinh gọn, ít thay đổi cấu trúc
Hỗ trợ được nhiều web render engine như Selenium webdriver, Puppeteer, Chrome Remote Interface…_
Tất cả các service đều được container hóa để mở rộng lên các môi trường K8S hoặc Cloud native
Tất cả dịch vụ giao tiếp với nhau qua message queue system (Google Cloud Pub/Sub)

Video buổi chia sẻ về Distributed Crawling System

Nguồn: Gambaru

undefined undefined

1 Result monolith found