Xây dựng hệ thống khảo duyệt web phân tán và thu thập dữ liệu phục vụ các hệ hỗ trợ quyết định luận văn ths công nghệ thông tin (chương trình đào tạo thí điểm)

Trong phạm vi luận văn tôi giới thiệu quy trình khảo sát, phân tích, thiết kế,phát triển và thử nghiệm một hệ thống khảo duyệt web và thu thập dữ liệu - một hệthống mạnh mẽ thu thập dữ l

ĐẠI HỌC QUỐC GIA HÀ NỘI

ĐẠI HỌC QUỐC GIA HÀ NỘI

Ngành: Công nghệ thông tin

Chuyên ngành: Truyền dữ liệu và mạng máy tính

Mã số: Chương trình đào tạo thí điểm

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS NGUYỄN ĐẠI THỌ

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng cánhân tôi, không sao chép lại của người khác Trong toàn bộ nội dung của luậnvăn những điều được trình bày hoặc là của cá nhân hoặc là được tổng hợp từnhiều nguồn tài liệu Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng vàđược trích dẫn hợp pháp

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quyđịnh cho lời cam đoan của mình

Hà Nội, ngày 19 tháng 10 năm 2015

Trịnh Việt Dũng

MỤC LỤC

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

DANH MỤC CÁC HÌNH VẼ

DANH MỤC CÁC BẢNG

LỜI CẢM ƠN

MỞ ĐẦU 1

CHƯƠNG 1 TỔNG QUAN VỀ HỆ HỖ TRỢ QUYẾT ĐỊNH 3

1.1 Thế nào là ra quyết định 3

1.2 Quá trình ra quyết định 3

1.3.1 Phân loại quyết định 3

1.3.2 Các giai đoạn của quá trình ra quyết định 3

1.3 Hệ hỗ trợ ra quyết định 4

1.3.1 Khái niệm hệ hỗ trợ ra quyết định 4

1.3.2 Các thành phần của hệ hỗ trợ ra quyết định 5

1.3.3 Mô hình ra quyết định 6

1.3.4 Phân loại hệ hỗ trợ ra quyết định 7

1.4 Một trường hợp sử dụng hệ hỗ trợ quyết định trong việc dự đoán giá sản phẩm được bán đấu giá trên eBay 8

1.4.1 Thu thập dữ liệu từ website eBay 9

1.4.2 Tiền xử lý dữ liệu 9

1.4.3 Dự đoán giá 11

1.5 Kết luận 12

CHƯƠNG 2 MỘT SỐ HỆ THỐNG THU THẬP DỮ LIỆU 13

2.1 Kiến trúc chung của hệ thống Web Crawler 13

2.1.1 Kho chứa URL 16

2.1.2 Lịch sử viếng thăm và kho chứa các trang web 17

2.1.3 Tải các trang web 18

2.1.4 Duyệt và phân tích nội dung 19

2.2 Hệ thống thu thập dữ liệu Mercator 22

2.3 Hệ thống thu thập dữ liệu từ Twitter - TwitterEcho 24

2.4 Tìm hiểu về công cụ HTTrack 25

2.5 Kết luận 29

CHƯƠNG 3 THIẾT KẾ HỆ THỐNG KHẢO DUYỆT WEB VÀ THU THẬP DỮ LIỆU 30

3.1 Kiến trúc hệ thống Web Crawler 31

3.1.1 Sơ đồ tổng quan 32

3.1.2 Các thành phần của Web Crawler 33

3.1.3 Thiết kế 33

3.2 Kiến trúc hệ thống Twitter Crawler 36

3.2.1 Sơ đồ tổng quan 36

3.2.2 Sử dụng RestAPI v1.1 để thu thập dữ liệu 37

3.2.3 Request Limits 41

3.2.4 Thiết kế 41

3.3 MongoDB cho việc lưu trữ cơ sở dữ liệu 45

3.3.1 Ưu điểm và nhược điểm 45

3.3.2 Cơ chế phân quyền vào bảo mật 46

3.3.3 Chỉ mục trong MongoDB 47

3.3.4 Phân mảnh trong MongoDB 47

3.4 Kết luận 50

CHƯƠNG 4 ĐÁNH GIÁ KẾT QUẢ 51

4.1 Triển khai 51

4.2 Mô hình triển khai 53

4.3 Phần mềm và thông số máy chủ 54

4.3.1 Phần mềm 54

4.3.2 Cấu hình máy chủ 54

4.4 Đánh giá hệ thống 55

4.4.1 Đánh giá hệ thống Web Crawler 55

4.4.2 Đánh giá hệ thống Twitter Crawler 55

4.4.3 Một số giao diện sau khi chạy hệ thống 56

4.5 Kết luận 57

CHƯƠNG 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 58

5.2 Hướng phát triển 58

TÀI LIỆU THAM KHẢO 59

PHỤ LỤC 1 60

PHỤ LỤC 2 61

PHỤ LỤC 3 62

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

DE Data Extraction - một hệ thống bóc tách dữ liệu từ

website theo luật người sử dụng tạo

WC Web Crawler - một hệ thống thu thập dữ liệu

RSS Crawler Một hệ thống thu thập dữ liệu thông qua RSS - Rich Site

Summary

MS Crawler Metasearch - một hệ thống thu thập dữ liệu thông qua các

máy tìm kiếm như Google, Bing, Yahoo, Daum

FB Crawler Một hệ thống thu thập dữ liệu từ mạng xã hội Facebook

TW Crawler Một hệ thống thu thập dữ liệu từ mạng xã hội Twitter

WB Crawler Một hệ thống thu thập dữ liệu từ mạng xã hội Weibo

IS Crawler Một hệ thống thu thập dữ liệu từ mạng xã hội Instagram.Crawling Quá trình thu thập dữ liệu

Spider Trap Bẫy các hệ thống thu thập dữ liệu tự động làm cho hệ

thống thu thập dữ liệu rơi vào vòng lặp vô hạn

Robot Exclusion Giao thức loại trừ robot

Protocol

TOA Twitter Open Authentication dùng để xác thực mỗi yêu

cầu gửi lên server

Task Một công việc mà hệ thống cần thực hiện

DANH MỤC CÁC HÌNH VẼ

Hình 1-1 Các giai đoạn của quá trình ra quyết định 4

Hình 1-2 Ưu điểm của hệ hỗ trợ quyết định 5

Hình 1-3 Các thành phần của hệ hỗ trợ quyết định 6

Hình 1-4 Sản phẩm đấu giá trên eBay 9

Hình 1-5 Nội dung HTML của sản phẩm 10

Hình 1-6 Vector đại diện của văn bản mẫu 11

Hình 1-7 Cây quyết định hồi quy 11

Hình 2-1 Kiến trúc chung của một Web Crawler 15

Hình 2-2 Trang HTML và cấu trúc cây của hệ thống tương ứng 22

Hình 2-3 Các thành phần chính của Mercator 23

Hình 2-4 Kiến trúc của TwitterEcho 25

Hình 2-5 Kéo thả một vài địa chỉ web 26

Hình 2-6 Cấu hình HTTrack 26

Hình 2-7 Lọc liên kết 27

Hình 2-8 Đặt lịch tự động download 27

Hình 2-9 Giao diện thu thập dữ liệu 28

Hình 2-10 Màn hình kết thúc quá trình thu thập dữ liệu 28

Hình 3-1 Mô hình hệ thống thu thập dữ liệu công ty Saltlux 31

Hình 3-2 Kiến trúc phân tán hệ thống khảo duyệt web 32

Hình 3-3 Các thành phần bên trong của Web Crawler 33

Hình 3-4 Tạo mới Web Crawler task 34

Hình 3-5 Cập nhật thông tin cho Web Crawler task 34

Hình 3-6 Xoá Web Crawler task 35

Hình 3-7 Xem dữ liệu download 35

Hình 3-8 Kiến trúc phân tán của Twitter Crawler 36

Hình 3-9 Danh sách các địa điểm được hỗ trợ bởi Twitter

LỜI CẢM ƠN

Để hoàn thành nội dung luận văn này tôi đã nhận được rất nhiều sự giúp đỡ

từ thầy giáo hướng dẫn, gia đình, cơ quan, bạn học và cá nhân

Trước hết tôi xin bày tỏ lòng biết ơn sâu sắc đến Tiến sĩ Nguyễn Đại Thọ –Người thầy đã trực tiếp hướng dẫn, tận tình giúp đỡ tôi trong quá trình xâydựng và hoàn thành luận văn này

Tôi xin gửi lời cảm ơn đến các đồng nghiệp trong công ty Saltlux đã hỗ trợtôi trong quá trình phát triển hệ thống và hoàn thiện luận văn

Tôi xin chân thành cảm ơn các thầy giáo, cô giáo trong Khoa Công nghệthông tin, trường Đại học Công nghệ, Đại học Quốc gia Hà Nội cũng như cácthầy giáo, cô giáo trong các viện nghiên cứu, các trường đại học khác tham giagiảng dạy ở trường đã tận tình hướng dẫn, trang bị cho tôi những kiến thức quýbáu trong suốt quá trình học tập tại trường

Do có nhiều hạn chế về thời gian và kiến thức ne n luạ n va n kho ng tránh khỏi những thiếu sót, rất mong nhạ n đu ợc những kiến đóng góp qu báu của qu thầy co và các bạn cùng quan ta m

Cuối cùng tôi xin bày tỏ lòng biết ơn chân thành đến bố mẹ, vợ, gia đình,

và bạn bè những người luôn tạo điều kiện, động viên, giúp đỡ tôi rất nhiệt tình

để hoàn thành luận văn

Hà Nội, ngày 19 tháng 10 năm 2015

Học viên

Trịnh Việt Dũng

MỞ ĐẦU

Đi cùng với sự phát triển mạnh mẽ của mạng Internet trong những thập kỷgần đây trên toàn cầu, nguồn dữ liệu web trở thành kho dữ liệu khổng lồ để khaithác thông tin hữu ích (theo thống kê của NetCraft vào tháng 10 năm 2015, cókhoảng 878.269.546 site trên toàn thế giới [9]) Nguồn dữ liệu mà Internet manglại ngày càng trở nên đồ sộ, đa dạng, bao phủ lên tất cả mọi mặt của cuộc sống,

từ văn hoá, kinh tế, chính trị, du lịch, học tập, nghiên cứu v.v Với sự phong phú

về tài nguyên như vậy, nhu cầu về tìm kiếm và xử lý thông tin, cùng với yêu cầu

về khả năng khai thác chúng một cách hiệu quả để giúp cho con người dễ dàng

và chính xác hơn trong việc đưa ra quyết định, chiến lược kinh doanh, phân tíchrủi ro (trong kinh doanh), trong việc makerting và quảng bá sản phẩm, hay trongviệc điểu tra tâm lý và ý kiến của khách hàng, đã trở nên cần thiết trong xã hộihiện đại Nhưng vấn đề tìm kiếm và sử dụng nguồn tài nguyên đó như thế nào

để phục vụ cho công việc của mình lại là một vấn đề khó khăn đối với người sửdụng, nhất là đối với những người đóng vai trò điều hành, ra quyết định ở cáccông ty, doanh nghiệp

Để thoả mãn yêu cầu trên Công ty Saltlux - một công ty chuyên về lĩnhvực tìm kiếm ngữ nghĩa và big data - đã giới thiệu một dịch vụ, một giải pháptổng thể giúp chúng ta sử dụng nguồn tài nguyên đó dễ dàng hơn, tập trung hơn

và hiệu quả hơn, qua đó nâng cao được chất lượng công việc và tiết kiệm đượcthời gian, đóng góp vào sự phát triển của các doanh nghiệp, công ty Giải phápđược giới thiệu bao gồm các quá trình thu thập dữ liệu từ Internet, phân loại vàphân cụm dữ liệu thu thập được, phân tích dữ liệu, tìm kiếm dữ liệu và trựcquan hoá dữ liệu - sử dụng các biểu đồ, đồ thị để biểu diễn dữ liệu

Trong phạm vi luận văn tôi giới thiệu quy trình khảo sát, phân tích, thiết kế,phát triển và thử nghiệm một hệ thống khảo duyệt web và thu thập dữ liệu - một hệthống mạnh mẽ thu thập dữ liệu từ nhiều nguồn khác nhau (trang tin tức, diễn đàn,blog, mạng xã hội Twitter), thu thập nhiều loại dữ liệu khác nhau như html, text(.doc, docx, pdf, ), images (.png, gif, jpg, ), videos, và các loại file phổ biếnkhác như (.zip, rar, xls, xlsx , cvs, hwp, ) Hệ thống được xây dựng có khảnăng chạy trên nhiều môi trường hệ điều hành khác nhau như Unix-based,Windows Với việc thiết kế hệ thống chạy đa luồng đồng thời, số lượng luồngđược cấu hình động giúp cho hệ thống dễ dàng tuỳ chỉnh một cách linh hoạt tậndụng tối đa nguồn tài nguyên của máy chủ cũng như băng thông mạng Ngoài ravới kiến trúc phân tán công việc linh hoạt, giúp hệ thống có khả năng được mởrộng trên nhiều máy, tính năng mà các công cụ thu thập dữ liệu phổ

biến khác chưa làm được như HTTrack, WebSPHINX, Web ApplicationAttack and Audit Framework, OWASP Zed Attack Proxy,.v.v Sử dụng cơ sở dữliệu NoSQL - MongoDB để lưu trữ dữ liệu giúp hệ thống đảm bảo lưu trữ được

dữ liệu rất lớn, tốc độ đọc/ghi dữ liệu nhanh, dễ dàng tích hợp với các hệ thốngkhác Đây cũng là ưu điểm vượt trội so với các công cụ HTTrack,WebSPHINX,.v.v chỉ cho phép lưu trữ dữ liệu thu thập được dưới dạng file

Hệ thống thu thập dữ liệu này cũng là hệ thống mà tôi tham gia thiết kế và pháttriển tại công ty nơi tôi đang làm việc

Hệ thống thu thập dữ liệu được trình bày trong luận văn đã góp phần đáng

kể vào việc thúc đẩy sự phát triển của công ty, và đã được triển khai tới kháchhàng là cơ quan nhà nước (Văn phòng chính phủ, Bộ nội vụ, Bộ quốc phòng )

ở Hàn Quốc và doanh nghiệp ở Nhật Bản (Samuraiz) Phụ Lục 1 liệt kê danh sách các đơn vị đã triển khai hệ thống

Nội dung của luận văn được tổ chức thành 5 chương như sau:

Chương 1: Trình bày lý thuyết chung về hệ hỗ trợ quyết định Đây là kiến thức

nền tảng về hệ thống hỗ trợ ra quyết định như quá trình ra quyết định, các thànhphần cơ bản của hệ hỗ trợ ra quyết định

Chương 2: Tìm hiểu và khảo sát một số hệ thống thu thập dữ liệu được giới

thiệu trong các bài báo khoa học như Mercator và TwitterEcho; đồng thời tiếnhành khảo sát hệ thống đã được triển khai thực tế như HTTrack Giải pháp choviệc lưu trữ dữ liệu lớn cũng được trình bày trong chương này

Chương 3: Trình bày chi tiết thiết kế hai hệ thống khảo duyệt web và thu thập

dữ liệu Hệ thống thứ nhất là hệ thống thu thập dữ liệu từ website chung như cácdiễn đàn, blog, tin tức,.v.v Hệ thống thứ hai là hệ thống chuyên thu thập dữ liệu

từ mạng xã hội Twitter

Chương 4: Cài đặt, triển khai và đánh giá: chương này trình bày chi tiết việc

cài đặt, triển khai hệ thống, và đánh giá kết quả dựa trên yêu cầu thực lấy được

từ phía khách hàng

Chương 5: Kết luận và hướng phát triển

CHƯƠNG 1 TỔNG QUAN VỀ HỆ HỖ TRỢ QUYẾT ĐỊNH

Sự phát triển nhanh chóng của mạng Internet trong những thập kỷ gần đây

đã mang lại nguồn dữ liệu to lớn Lượng dữ liệu được chia sẻ trên mạng là rấtlớn với nội dung phong phú, đa dạng đến từ nhiều nguồn cung cấp dữ liệu khácnhau như: các site tin tức (cung cấp thông tin liên quan đến mọi mặt trong cuộcsống như giáo dục, kinh tế, chính trị, ngoại giao, thể , giải trí, v.v.), các diễnđàn, các kênh truyền hình trực tuyến, mạng xã hội, v.v Nguồn dữ liệu phongphú, nhưng việc sử dụng chúng một cách hiệu quả để giúp ích cho con ngườiđặc biệt những người có vai trò ra quyết định trong các tổ chức, các công tyđang là một thách thức lớn Ý tưởng của luận văn là xây dựng hệ thống thu thập

dữ liệu trên web, trên các mạng xã hội Dữ liệu thu thập được dùng cho các hệthống phân tích, tìm kiếm sau này Dưới đây học viên trình bày lý thuyết chung

và một trường hợp sử dụng thực tế hệ hỗ trợ ra quyết

1.1 Thế nào là ra quyết định

Viẹ c đu a ra quyết định đối với mọ t vấn đề xuất hiẹ n trong khắpcác lĩnh vực, hoạt đọ ng của đời sống mà đôi khi chúng ta không nhạ n ra Từnhững viẹ c đo n giản nhu chọn mọ t bọ quần áo để đi dự tiẹ c cho đếncác viẹ c lớn lao nhu phân bổ ngân sách vào các chu o ng trình của quốcgia đều là các công viẹ c đu a ra quyết định

Vạ y đu a ra quyết định chính là chọn ra trong các giải pháp khả thi

mọ t giải pháp mà theo ngu ời đu a ra quyết định là phù hợp nhất

1.2 Quá trình ra quyết định

1.3.1 Phân loại quyết định

Có thể phân ra bốn loại quyết định như sau:

- Quyết định có cấu trúc (Structured Decision): Các quyết định mà ngu ời ra

quyết định biết là chắc chắn đúng

- Quyết định không cấu trúc (Nonstructured Decision): Các quyết định mà

ngu ời ra quyết định biết là có nhiều câu trả lời gần đúng và không có cách nào

để tìm ra câu trả lời chính xác nhất

- Quyết định đẹ quy (Recurring Decision): Các quyết định lạ p đi, lạ p lại

- Quyết định không đẹ quy (Nonrecurring Decision): Các quyết định khôngxảy ra thu ờng xuyên

1.3.2 Các giai đoạn của quá trình ra quyết định

Theo Simon, các giai đoạn của quá trình ra quyết định bao gồm các pha:

- Nhạ n định (Intelligence): Tìm kiếm các tình huống dẫn đến viẹ c phải ra

- Thiết kế (Design): Phân tích các hu ớng tiếp cạ n để giải quyết vấn đề, đápứng các nhu cầu, tạ n dụng các co họ i , hạn chế các rủi ro v.v

- Lựa chọn (Choice): Cân nhắc và đánh giá từng giải pháp, đo lu ờng hạu quảcủa từng giải pháp và chọn giải pháp tối u u

- Tiến hành ra quyết định (Implementation): Thực hiẹ n giải pháp đu ợc chọn, theo d i kết quả và điều chỉnh khi thấy cần thiết

Hình 1-1 Các giai đoạn của quá trình ra quyết định 1.3 Hệ hỗ trợ ra quyết định

1.3.1 Khái niệm hệ hỗ trợ ra quyết định

Trong thạ p niên 1970, Scott Morton đu a ra những khái niẹ tiên

về Hẹ hỗ trợ ra quyết định (Decision Support Systems-DSS)

m đầu

ng định

nghĩa DSS nhu là những hẹ thống máy tính tu o ng tác nh m giúp những ngu ời

ra quyết định sử dụng dữ liẹ u và mô hình để giải quyết các vấn đề không có cấutrúc 7]

Hình 1-2 Ưu điểm của hệ hỗ trợ quyết định

Cho đến nay chu a có mọ t định nghĩa thống nhất về DSS Tuy nhiên tất

cả đều đồng mục đích co bản nhất của DSS là để hỗ trợ và cải tiến viẹ c ra quyếtđịnh

1.3.2 Các thành phần của hệ hỗ trợ ra quyết định

Mọ t hẹ hỗ trợ ra quyết định gồm có ba thành phần chính:

- Quản lý mô hình

- Quản lý dữ liệu

- Quản lý giao diện người dùng

Quản lý mô hình (Model Management) bao gồm các mô hình ra quyết định

(DSS models) và viẹ c quản lí các mô hình này Mọ t số ví dụ của các mô hình

ra quyết định như: mô hình nếu thì, mô hình tối u u, mô hình tìm kiếm mụcđích, mô hình thống kê.

Quản lý dữ liệu (Data Management) thực hiẹ n công viẹ c lu u trữ các thông tin

của hẹ và phục vụ cho việc cạ p nhạ t, truy vấn thông tin.

Quản lý giao diện người dùng (User Interface Management) quản lí viẹ c giao

tiếp giữa ngu ời dùng cuối và Hẹ ra quyết định.

Hình 1-3 Các thành phần của hệ hỗ

trợ quyết định

1.3.3 Mô hình ra quyết định

Mọ t đạ c tru ng co bản của Hẹ hỗ trợ ra quyết định là phải có ít nhất mọ t

mô hình hỗ trợ ra quyết định Viẹ c chọn lựa và xây dựng mô hình n m tronggiai đoạn thứ hai (Design Phase) của quá trình ra quyết định

Mọ t mô hình là mọ t khái quát hóa hay trừu tu ợng hóa của thực tế

Mô hình hóa là viẹ c khái quát hóa và trừu tu ợng hóa các vấn đề thực tế thànhcác mô hình định tính hay định lu ợng Đó là mọ t quy trình kết hợp cả khoa học(sự chính xác, logic) và nghẹ thuạ t (sự sáng tạo)

Mọ t mô hình thu ờng bao gồm ba thành phần co bản:

Ch ng hạn trong bài toán quyết định đầu tu thì đây là số tiền đầu tu , no i đầu tu ,thời gian đầu tu v.v

ngu ời ra quyết định (bị tác đọ ng bởi các yếu tố bên ngoài) Ch ng hạn trong bài toán trên thì đây là tốc đọ lạm phát, lãi suất ngân hàng v.v

toán trên thì đây là tỉ số lợi nhuạ n

Khi lựa chọn quyết định cuối cùng, ngu ời ra quyết định có thể muốn có

mọ t quyết định tối u u (optimal) hay mọ t quyết định thỏa đáng, gần tối u u(good enough) Do vạ y có thể chia ra hai loại mô hình hỗ trợ ra quyết định

Mô hình quy chuẩn (Normative Model): Mô hình này xem x t tất cả cácphu o ng án và chọn ra phu o ng án tối u u

Mô hình mô tả (Descriptive Model): Mô hình này xem x t mọ t tạ p hợpcác điều kiẹ n theo ngu ời dùng và xem x t các phu o ng án theo hu ớng các điềukiẹ n này và đu a ra mọ t kết quả thỏa đáng Vì mô hình này không xem x t hếttất cả các phu o ng án nên kết quả cuối cùng có thể chỉ gần tối u u

Mô hình quy chuẩn thu ờng đu ợc sử dụng trong bài toán tối u u hóa mọ tmục tiêu Mô hình mô tả thu ờng đu ợc sử dụng trong bài toán tối u u hóa đamục tiêu khi các mục tiêu này có thể mâu thuẫn nhau

1.3.4 Phân loại hệ hỗ trợ ra quyết định

Theo Holsapple và Whinston (1996) [8 phân ra 6 lọai hẹ hỗ trợ ra quyết định:

Hướng văn bản - Thông tin (bao gồm dữ liẹ u và kiến thức) đu ợc lu u trữ

du ới dạng va n bản Vì vạ y hẹ thống đòi hỏi lu u trữ và xử lí các va nbản mọ t cách hiẹ u quả Các công nghẹ mới nhu Hẹ quản lí va n bảndựa trên web, Intelligent Agents có thể đu ợc sử dụng cùng với hẹ này

Hu ớng co sở dữ i

này.Thông tin trong co

rõ ràng Hẹ này cho ph

về báo cáo.

u - Co sở dữ liẹ u đóng vai trò chủ yếu trong hẹ sở dữ

liẹ u thu ờng có cấu trúc chạ t chẽ, có mô tả p ngu ời dùng truy vấn thông tin dễ dàng và rất mạnh

dùng thực hiẹ n viẹ c phân tích tru ớc khi ra quyết định Bản tính có thể baogồm nhiều mọ hình thống kê, lạ p trình tuyến tính, mọ hình tài chính v.v.Bản tính phổ biến nhất đó là Microsoft Excel Hẹ này thu ờng đu ợc dùngrông rãi trong các hẹ liên quan tới ngu ời dùng cuối

chu o ng trình để giải quyết mọ t vấn đề cụ thể ch ng hạn nhu tính toán giábán ra của sản phẩm hay tính toán xu hu ớng bán hàng Mọ t số trợ giúp khácphức tạp nhu là tối u u hóa đa mục tiêu Hẹ này bao gồm nhiều trợ giúpnhư vậy

tục hay lí lẽ Hẹ này còn đựoc gọi là hẹ chuyên gia Các quy luật này có thể

là định tính hay định lu ợng Các ví dụ của hẹ này nhu là hu ớng dẫnkhông lu u, hu ớng dẫn giao thông trên biển, trên bọ , v.v

trong số na m hẹ hỗ trợ quyết định kể trên

1.4 Một trường hợp sử dụng hệ hỗ trợ quyết định trong việc dự đoán giá sản phẩm được bán đấu giá trên eBay.

Đấu giá trực tuyến đang rất phổ biến Theo báo cáo của website bán đấugiá trực tuyến lớn nhất thế giới eBay trong qu tài chính đầu tiên năm 2006 lợinhuận thuần (net revenue) là 1.39 tỉ đô, dự đoán mức tăng trưởng 35% trongnhững năm tới Việc thu được lợi nhuận lớn từ việc đấu giá sản phẩm đã thu hútnhững nhà nghiên cứu quan tâm đến lĩnh vực đấu giá trực tuyến, và hệ thống hỗtrợ dự đoán giá sản phẩm đấu giá ra đời là cần thiết

Hệ hỗ trợ dự đoán giá hỗ trợ cả người bán và người mua Người bán cóthể sử dụng hệ hỗ trợ này đưa ra giá ban đầu và gợi đưa ra mô tả sản phầm

Người mua sử dụng hệ hỗ trợ để đặt giá một cách hợp l Để dự đoán giá cuối của sản phẩm đấu giá, hệ hỗ trợ thực hiện các công việc sau:

- Thu thập dữ liệu từ website eBay

- Tiền xử lý dữ liệu

- Dự đoán giá

1.4.1 Thu thập dữ liệu từ website eBay

Có một số cách để thu thập dữ liệu đấu giá từ website eBay: sử dụng eBayAPI (Application Programers Interface), sử dụng Web Crawler, hoặc mua tập dữliệu do từ nhà cung cấp khác Hệ hỗ trợ được trình bày trong ví dụ này sử dụngmột Web Crawler HarvEX (http://www.xellsoft.com/HarvEX.html) đểdownload HTML của các trang đấu giá Mỗi một sản phẩm đấu giá được gắnmột ID để phân biệt Hình 1-4 mô tả trang sản phẩm đấu giá trên eBay

Hình 1-4 Sản phẩm đấu giá trên eBay

1.4.2 Tiền xử lý dữ liệu

Hệ hỗ trợ dự đoán giá dựa trên những đặc trưng sau: tỉ lệ phản hồi(feedback rating) - đây là tỉ lệ phản hồi tích cực trên tổng số phản hồi về sảnphẩm đấu giá, số lượng hình ảnh của sản phẩm đấu giá, và mô tả sản phẩm đấugiá

Đặc trưng đầu tiên là tỉ lệ phản hồi eBay có một hệ thống lưu trữ cácphản hồi của người mua đối với người bán trong các giao dịch trước đó gọi làFeedback Forum Người bán có tỉ lệ feedback cao hơn sẽ có độ tin cậy cao hơn.

Có một số nghiên cứu chỉ ra r ng có mối liên hệ giữa người bán và giá đấu giámong đợi của sản phẩm Người mua thường muốn biết thông tin về sản phẩmđấu giá càng nhiều càng tốt Những thông tin này giúp họ làm giảm được sựkhông chắc chắn về chất lượng sản phẩm thay cho việc chỉ quan tâm đến tỉ lệphản hồi Nhưng có một số thông tin khó có thể mô tả trong dạng văn bản Ví

dụ, mô tả sản phẩm về một đôi giày bán đấu giá 'giày hơi mòn' (slightly wornshoes) có thể là mòn nghiêm trọng hoặc vẫn trong điều kiện sử dụng được.Trong trường hợp này, số lượng hình ảnh mô tả được sử dụng để dự đoán giá.Một cách khác để bên bán có thể thuyết phục bên mua b ng cách đưa ra cácthông tin thêm về sản phẩm bán Thông tin này được viết b ng ngôn ngữ tựnhiên trong đó chứa các thông tin về giao dịch, chính sách hoàn trả sản phẩm,hay chi phí cho vận chuyển hàng Vì thông tin thêm là hữu ích đối với ngườimua nên thông tin này được sử dụng như một đặc trưng để dự đoán giá

Việc trích xuất ba đặc trưng từ trang HTML gốc của sản phẩm đấu hệ thốngthực hiện như sau Trích xuất giá và tỉ lệ phản hồi dựa vào tìm kiếm nội dung'Winning bid' và 'Feedback' Số lượng hình ảnh sản phẩm đấu giá được tìm

b ng cách đếm số tag <img> trong phần mô tả sản phẩm Hình 1-5 là ví dụ nội dung HTML của sản phẩm đấu giá

Hình 1-5 Nội dung HTML của sản phẩm

Đối với đặc trưng mô tả sản phầm, hệ thống sẽ xây dựng vector đại diện (vector representation) cho đặc trưng này Hình 1-6 đưa ra ví dụ của vector đại diện

Hình 1-6 Vector đại diện của văn bản mẫu

Để xây dựng vector hệ thống sử dụng 2 phương thức BOW (bag-of-word) vàthuật toán xác định từ gốc Porter

1.4.3 Dự đoán giá

Để dự đoán giá của sản phẩm đấu giá, hệ thống sử dụng CART(Classification and Regression Trees) - cây quyết định phân lớp và cây quyếtđịnh hồi quy Hình 1-7 mô tả cây quyết định hồi quy

Hình 1-7 Cây quyết định hồi quy

Cây hồi quy bao gồm các decision node và leaf node Mỗi một decisionnode có hai node con, node con có thể là decision node hoặc leaf node Root củacây n m ở trên cùng không có node cha

Chi tiết của việc dự đoán giá dựa vào CART như thế nào tôi không trìnhbày chi tiết bởi vì đây là một lĩnh vực khác vượt ngoài phạm vi luân văn tôiđang nghiên cứu

1.5 Kết luận

Chương 1 trình bày lý thuyết chung về hệ hỗ trợ quyết định Đây là kiếnthức nền tảng về hệ thống hỗ trợ ra quyết định như quá trình ra quyết định, cácthành phần cơ bản của hệ hỗ trợ ra quyết định

CHƯƠNG 2 MỘT SỐ HỆ THỐNG THU THẬP DỮ LIỆU

Chương này trình bày kiến trúc chung của Web Crawler Tìm hiểu một số

hệ thống thu thập dữ liệu được trình bày trong các bài báo khoa học và nghiêncứu sản phẩm đã được triển khai thực tế Đây cũng là cơ sở để xây dựng hệthống khảo duyệt web và thu thập dữ liệu của tôi

2.1 Kiến trúc chung của hệ thống Web Crawler

Web Crawler (hay còn được gọi với tên khác như Web Spider hoặc WebRobot) là một chương trình máy tính có thể “duyệt web” một cách tự động theomột phương thức nào đó được xác định trước Vì là một chương trình nên quátrình “duyệt web” của các Web Crawler không hoàn toàn giống với quá trìnhduyệt web của con người (Web Crawler phải sử dụng các phương thức dựa trênHTTP trực tiếp chứ không thông qua Web Browser như con người)

Động cơ ban đầu thúc đẩy việc thiết kế Web Crawler là việc lấy nội dungtrang web và lưu trữ chúng ở các kho chứa cục bộ sau đó sẽ được sử dụng chocác ứng dụng khác như phân tích dữ liệu, search engine v.v Các Web Crawlerthường bắt đầu từ một trang web hoặc một danh sách các trang web nào đó, sửdụng các liên kết ngoài trong trang web đó để mở rộng ra các trang tiếp theo.Quá trình này tiếp tục với các trang web mới, các trang này lại cung cấp các liênkết ngoài khác để đi theo Cứ như vậy cho tới khi đạt tới một số lượng trangweb xác định hoặc thoả mãn một điều kiện nào đó

Môi trường web là thực thể động, với các không gian con thay đổi theocác xu hướng khác nhau và thường thay đổi với tốc độ rất nhanh Do đó chúng

ta luôn cần sử dụng các crawler để giúp các ứng dụng đu ợc cạ p nhạ t b ngcách cạ p nhạ t nọ i dung mới của các trang web, xóa bỏ hoạ c sửa đổi nọ idung cũ Các hẹ thống tìm kiếm thu ờng cố gắng thu thạ p đu ợc càngnhiều trang web càng tốt Các hẹ thống này thu ờng sử dụng Web Crawler đểbảo trì co sở dữ liẹ u đu ợc đánh chỉ mục của chúng, cân b ng cái giá củaquá trình crawling và đánh chỉ mục với hàng triẹ u truy vấn mà hẹ thốngnhạ n đu ợc Module crawler của các hẹ thống này thu ờng có xu hu ớng

và mục tiêu chính là download hết các trang web mà nó gạ p Ngu ợc lại, cáccrawler khác lại chỉ chọn mọ t số trang web để tải và duyẹ t trong số rất nhiềucác trang web nó gạ p, các crawler này đu ợc gọi là các crawler có lựa chọn

preferential crawler hoạ c crawler dựa trên kinh nghiẹ m Chúng đu ợc sửdụng để xây dựng các kho dữ liẹ u có chủ điểm, tự đọ ng hóa các nguồn lựckhai phá và đáp ứng cho các đại l phần mềm Các crawler có lựa chọn đu ợcxây dựng để lấy ra các trang web theo mọ t chủ đề xác định đu ợc gọi là các

crawler theo chủ đề topic crawler hoạ c crawler tạ p trung focused crawler.

Có mọ t số khía cạnh của các topic crawler, đang đu ợc tạ p trung nghiêncứu Mọ t câu hỏi then chốt đã đang thu hút sự quan tâm của các nhà nghiên cứulà: Làm thế nào để đạt đu ợc tính chất lựa chọn của crawler Các

vấn đề phụ thuọ c nhiều vào ngữ cảnh nhu mục tiêu của ứng dụng cha (màcrawler là mọ t thành phần) hoạ c các tín hiẹ u ngữ nghĩa trong trang webcũng nhu những đạ c tru ng (features) của các lu ợc đồ đu ợc xây dựng từcác trang web cũng đã đu ợc xem x t Thêm vào đó, các crawler cũng sử dụngcác co chế khác nhau trong viẹ c xử l các yếu tố này

Mọ t khía cạnh quan trọng thứ hai cần xem x t khi nghiên cứu cáccrawler, đạ c biẹ t là các topical crawler, đó là bản chất của nhiẹ m vụ crawl(duyẹ t web) Các tính chất của viẹ c crawl nhu là các truy vấn hay là các từkhóa đu ợc cung cấp nhu là các đầu vào cho các crawler, các hồ so ngu ờidùng user-profile, hay các thuọ c tính của trang web cần tải (các trang

tu o ng tự, các trang web phổ biến, v.v.) có thể dẫn tới các thay đổi đáng kểtrong viẹ c thiết kế và thực thi các crawler Các tác vụ có thể bị ràng buọ c bởicác tham số nhu số lu ợng cực đại các trang web cần nạp hay dung lu ợng

bọ nhớ có thể v.v Do đó, mọ t nhiẹ m vụ crawling có thể đu ợc xemnhu mọ t bài toán tìm kiếm bị ràng buọ c bởi nhiều mụctiêu (multi-objective) Tuy nhiên, do sự đa dạng của các hàm mục tiêu cọ ng với sự thiếucác hiểu biết chính xác về không gian tìm kiếm làm cho vấn đề càng trở nênphức tạp Ho n nữa, mọ t chu o ng trình crawler có thể sẽ phải giải quyết các vấn

đề về tối u u hóa nhu tối u u toàn cục và tối u u cục bọ

Về cơ bản một Web Crawler có kiến trúc chung như được mô tả

trong hình 2-1 dưới đây

Hình 2-1 Kiến trúc chung của một Web Crawler

Một crawler bao gồm một danh sách các URL chưa được thăm gọi làfrontier Danh sách này được tạo ra bởi các URL hạt nhân (Seed URL) đượccung cấp bởi người dùng và các chương trình khác Mỗi vòng lạ p crawling baogồm: lấy ra URL cần đu ợc download tiếp theo từ frontier, nạp trang web tu o ngứng với URL đó b ng giao thức HTTP, bóc tách trang web vừa tải về để lấy racác URL và các thông tin mà ứng dụng cần, và cuối cùng là thêm các

trang URL chu a đu ợc tha m vào frontier Tru ớc khi các URL đu ợc thêm vàofrontier chúng sẽ đu ợc gán cho mọ t đọ đo thể hiẹ n đánh giá hiẹ u quả khi tha

m trang web tu o ng ứng với URL đó Quá trình crawling

có thể kết thúc khi mọ t số lu ợng nhất định các trang web đã đu ợc tải Nếuchu o ng trình crawler đã s n sàng để duyẹ t mọ t trang web khác và trạngthái của frontier là rỗng, mọ t tín hiẹ u trạng thái kết thúc (dead-end) sẽ

đu ợc gửi cho crawler Chu o ng trình crawler sẽ không có trang web mới đểtải và dừng lại

Công viẹ c crawling có thể đu ợc xem nhu mọ t bài toán duyẹ t đồthị Toàn bọ thế giới web đu ợc xem nhu mọ t đồ thị lớn với các nút là các

mọ t vài nút hạt nhân và sau đó đi theo các cạnh để tới các nút khác Quá trìnhtải mọ t trang web và trích ra các liên kết trong nó tu o ng tự nhu viẹ c

mở rọ ng mọ t nút trong bài toán tìm kiếm trên đồ thị Mọ t crawler có chủđiểm cố gắng đi theo các cạnh mà đu ợc kỳ vọng là dẫn tới các vị trí trong đồthị là hợp lẹ với chủ điểm đó

2.1.1 Kho chứa URL

Frontier là danh sách các công viẹ c cần làm của mọ t crawler, nó chứacác URL của các trang web chu a đu ợc tha m Trong thuạ t ngữ tìm kiếm

đồ thị, frontier là mọ t danh sách mở các nút chu a đu ợc mở rọ ng (chu a

đu ợc tha m) Mạ c dù có thể có nhu cầu phải lu u các frontier lên đĩa đốivới các crawler rất lớn, ở đây để đo n giản hóa chúng tôi chỉ giới thiẹ ufrontier nhu là các cấu trúc dữ liẹ u trong bọ nhớ trong Dựa trên dung

lu ợng bọ nhớ có thể, ta có thể quyết định kích thu ớc cực đại của frontier.Dựa vào dung lu ợng lớn của bọ nhớ máy tính ngày nay, kích thu ớc mọ tfrontier vào khoảng 100,000 url không phải là hiếm Do các frontier chỉ có kíchthu ớc giới hạn ta cần có mọ t co chế để quyết định URL nào cần bị bỏ quakhi số lu ợng URL trên frontier đạt tới giới hạn đó Cần phải lu u r ngfrontier có thể bị đầy nhanh ho n nhiều so với số lu ợng trang web đu ợcduyẹ t Ta có thể có tới khoảng 60,000 url trong frontier khi mới duyẹ t

đu ợc khoảng 10,000 trang web do trung bình có khoảng 7 liên kết trong mọ ttrang web

Frontier có thể đu ợc thực thi nhu mọ t hàng đợi FIFO nếu ta muốnxây dựng mọ t crawler theo duyẹ t chiều rọ ng (breadth-first) để duyẹ t webtheo chiến lu ợc mù (blindly) URL cần đu ợc duyẹ t tiếp theo đu ợc lấy từđỉnh của hàng đợi và các URL mới đu ợc thêm vào cuối hàng đợi Do kíchthu ớc hạn chế của frontier, chúng ta cần phải đảm bảo là không thêm các URL

lạ p lại vào hàng đợi Do vạ y mọ t co chế tìm kiếm tuyến tính để tìm ra

mọ t URL mới đu ợc trích ra từ nọ i dung của url đang đu ợc duyẹ t có

n m trên frontier chu a là rất cần thiết Mọ t giải pháp đu ợc đu a ra là định

vị mọ t lu ợng bọ nhớ cần thiết để duy trì mọ t bảng ba m riêng (với khóa

là URL) để lu u giữ mỗi mọ t URL của frontier để thuạ n lợi cho viẹ c tìmkiếm Bảng ba m này phải đu ợc giữ đồng bọ với frontier thực sự Mọ tgiải pháp khác tốn nhiều thời gian ho n là duy trì bản thân hàng đợi đó nhu

mọ t bảng ba m (cũng với khóa là URL) Điều này cung cấp mọ t cách tìmkiếm nhanh chóng để tránh viẹ c lu u lạ p lại các URL Tuy nhiên, mỗi lầncrawler cần mọ t URL để duyẹ t, nó cần phải tìm kiếm và lấy ra URL mới

đu ợc đu a vào frontier gần đây nhất Nếu bọ nhớ không phải là vấn đề nổi

cọ m, giải pháp thứ nhất có thể sẽ tốt ho n Mọ t khi frontier đạt tới kích

thu ớc tối đa, thì crawler theo chiều rọ ng chỉ có thể thêm duy nhất mọ t URL chu a đu ợc tha m từ mỗi trang web đã đu ợc duyẹ t.

Nếu phần frontier đu ợc thực thi nhu mọ t hàng đợi u u tiên chúng ta

có mọ t crawler u u tiên hay còn gọi là crawler tốt nhất đầu tiên (best-firstcrawler) Hàng đợi u u tiên có thể là mọ t mảng đọ ng luôn đu ợc sắp xếptheo đọ đo đu ợc đánh giá của các URL chu a đu ợc tha m Tại mỗi

bu ớc, URL tốt nhất đu ợc lấy ra ở đầu hàng đợi Mọ t khi trang web

tu o ng ứng đu ợc nạp, các url liên kết từ nó đu ợc lấy ra và đu ợc đánhgiá dựa trên mọ t số kinh nghiẹ m Sau đó chúng lại đu ợc thêm vào frontiertại các vị trí phụ thuọ c vào đọ đo đó Chúng ta có thể tránh viẹ c thêm

mọ t cách lạ p lại các URL trong frontier b ng cách giữ mọ t bảng ba mriêng biẹ t để tìm kiếm Khi frontier đạt tới kích thu ớc tối đa là max, chỉ cómax URL tốt nhất đu ợc giữ lại trong frontier

Nếu chu o ng trình crawler nhạ n thấy frontier là rỗng trong khi nó cầnURL tiếp theo để duyẹ t, quá trình crawling sẽ ngừng lại Với mọ t giá trị maxlớn và mọ t vài URL hạt nhân thu ờng frontier rất hiếm khi đạt tới trạng tháirỗng

Tại mọ t số thời điểm, mọ t crawler có thể gạ p mọ t bẫy nhẹ n(spider trap) mà dẫn nó tới mọ t số lu ợng lớn các URL khác nhau cùng trỏ tới

mọ t trang web Ta có thể hạn chế điều này b ng cách hạn chế số lu ợng cáctrang web mà crawler truy cạ p tới từ mọ t tên miền xác định Đoạn mã lẹ nhliên quan tới frontier có thể đảm bảo r ng mọi chuỗi k URL liên tiếp (thu ờngk=100), đu ợc lấy ra bởi crawler, chỉ chứa duy nhất mọ t địa chỉ URL chuẩnhóa Điều này sẽ tránh đu ợc viẹ c crawler phải truy cạ p cùng mọ t website quá nhiều lần, và nọ i dung các trang web tải đu ợc sẽ có xu hu ớng khácbiẹ t nhiều ho n

2.1.2 Lịch sử viếng thăm và kho chứa các trang web

Phần lịch sử viếng thăm của crawler là mọ t danh sách đọ ng các URL

đã đu ợc nạp bởi crawler Nó chứa các đu ờng dẫn mà crawler đã đi qua bắtđầu từ trang hạt nhân Mọ t URL đầu vào chỉ đu ợc tạo trong phần lịch sử saukhi trang web tu o ng ứng đã đu ợc nạp Phần này đu ợc sử dụng cho viẹ cphân tích và đánh giá các trang web sau này Ví dụ, chúng ta có thể gắn cho mỗitrang web mọ t giá trị trên đu ờng dẫn và xác định các sự kiẹ n có nghĩa (ví

dụ nhu viẹ c khám phá ra mọ t nguồn lực quan trọng) Trong mọ t sốtru ờng hợp phần lịch sử đu ợc lu u trữ ở bọ nhớ ngoài, nhu ng nó cũng

có thể đu ợc duy trì nhu mọ t cấu trúc dữ liẹ u trong bọ nhớ trong Điều

đu ợc duyẹ t hay chu a Viẹ c kiểm tra này là rất quan trọng để tránh đitha m lại các trang web, và do đó tránh viẹ c thêm các URL đã đu ợc duyẹ tvào trong frontier có kích thu ớc giới hạn Cũng với l do tu o ng tự, viẹ cchuẩn hóa các URL tru ớc khi thêm chúng vào lịch sử cũng rất quan trọng.

Khi trang web đã đu ợc tải, nó có thể đu ợc lu u trữ, đánh chỉ số đểphục vụ cho ứng dụng chính (ví dụ mọ t máy tìm kiếm) Ở dạng đo n giảnnhất, mọ t kho chứa các trang web có thể có thể lu u các trang web đã đu ợccrawl nhu các file riêng biẹ t Trong tru ờng hợp đó, mỗi trang phải đu ợcánh xạ tới mọ t tên file duy nhất Mọ t cách để thực hiẹ n điều này là ánh xạURL của mỗi trang tới mọ t chuỗi n n b ng cách sử dụng mọ t dạng hàm

ba m với xác xuất xung đọ t thấp (để đảm bảo tính duy nhất của tên file) Cácgiá trị ba m đu ợc sử dụng làm các tên file Ví dụ có thể sử dụng hàm ba m

mọ t chiều MD5 để cung cấp mã ba m 128 bit cho mỗi URL Giá trị ba m

128 bit sau đó đu ợc chuyển thành 32 k tự ở dạng co số 16 tu o ng ứng.Theo cách này ta sẽ có các tên file có chiều dài cố định cho các URL có đọ dàibất kỳ Các kho chứa nọ i dung trang web có thể đu ợc sử dụng để kiểm traliẹ u mọ t URL đã đu ợc crawl tru ớc đó hay chu a b ng cách chuyển

URL đó sang 32 k tự thạ p lục phân và kiểm tra sự tồn tại của nó trong khochứa Trong mọ t số tru ờng hợp, điều này có thể dẫn tới sự không cần thiết củacấu trúc dữ liẹ u lịch sử trong bọ nhớ trong

2.1.3 Tải các trang web

Để nạp mọ t trang web, ta cần mọ t HTTP client để gửi mọ t yêu cầuHTTP tới mọ t trang web và đọc các đáp ứng Phía client cần có mọ t thời giantimeout để đảm bảo r ng nó không lãng phí quá nhiều thời gian để giao tiếp với

mọ t server quá chạ m hoạ c đọc mọ t trang web quá lớn Trên thực tế, thu ờnggiới hạn client chỉ download các trang web có kích thu ớc nhỏ ho n 10-20KB.Phía client cần duyẹ t các đáp ứng header để lấy các mã trạng thái và

các sự định hu ớng lại (redirection) Chúng cũng duyẹ t header và lu u thời giansửa đổi (last-modify) để xác định đọ cạ p nhạ t của trang web Viẹ c kiểm tra cáclỗi và ngoại lẹ là rất quan trọng trong quá trình tải trang web do

chúng ta sẽ phải liên hẹ tới hàng triẹ u server ở xa b ng cùng mọ t đoạn mã

lẹ nh Thêm vào đó, viẹ c thu thạ p các thống kê về thời gian timeout và các

mã trạng thái cũng rất hữu ích trong viẹ c xác định các vấn đề nảy sinh hoạ c

để thay đổi tự đọ ng giá trị timeout Các ngôn ngữ lạ p trình hiẹ n đại nhuJava hoạ c Perl cung cấp các co chế đo n giản cùng nhiều giao diẹ n lạ ptrình để tải các trang web Tuy nhiên, ta cũng cần phải cẩn thạ n trong viẹ c sửdụng các giao diẹ n bạ c cao do có thể sẽ khó tìm ra các lỗi ở bạ c thấp

Chúng ta không thể kết thúc viẹ c nói về quá trình crawling mà không đề

cạ p tới giao thức loại trừ robot - Robot Exclusion Protocol Giao thức nàycung cấp mọ t co chế cho các nhà quản trị web server để thông báo về cácquyền truy nhạ p file trên server, đạ c biẹ t là để chỉ định các file không

đu ợc truy cạ p bởi mọ t crawler Điều này đu ợc thực hiẹ n b ng cách

lu u mọ t file có tên robots.txt du ới thu mục chủ của web server (ch nghạn http: www.biz.uiowa.edu robots.txt) File này cung cấp các chính sách truy

cạ p các cho agents khác nhau (robots hoạ c crawler) Mọ t giá trị agent „*‟ biểu diễn mọ t chính sách mạ c định cho bất kỳ crawler nào khôngkhớp (match) các giá trị User-agent khác trong file Mọ t số các đầu vào bị cấmDisallow đu ợc đề ra cho mọ t User-agent Bất kỳ URL nào bắt đầu với giá trịtru ờng disallow đu ợc đạ t sẽ không đu ợc truy xuất bởi các crawler ứng với cácgiá trị User-agent đã chỉ định Khi mọ t crawler muốn lấy ra mọ t trang web từweb server, đầu tiên nó phải nạp file robots.txt và đảm bảo

User-r ng URL cần nạp là không bị cấm Các thông tin chi tiết về giao thức loại trừnày có thể tìm thấy ở http: www.robotstxt.org wc norobots.html Viẹ c lu u cachecác chính sách truy nhạ p của mọ t số server đu ợc truy nhạ p gần đây là khá hiẹ uquả Điều này cho ph p tránh phải truy nhạ p mọ t file

robots.txt mỗi khi cần nạp mọ t URL Tuy nhiên, ta cần phải đảm bảo r ng cácthông tin trong cache là đủ cạ p nhạ t

Disallow: /private/ private

2.1.4 Duyệt và phân tích nội dung

Sau khi trang web đã đu ợc tải về, chúng ta cần duyẹ t nọ i dung của

nó để lấy ra các thông tin sẽ đu ợc nạp trở lại và giúp định hu ớng viẹ c đitheo các đu ờng dẫn tiếp theo của crawler Viẹ c duyẹ t nọ i dung có thể

đo n giản chỉ bao hàm viẹ c trích ra các URL liên kết mà trang web liên kết tớihay nó có thể bao hàm các xử l phức tạp nhu làm sạch các nọ i dung HTML đểphân tích cấu trúc cây của các thẻ Viẹ c duyẹ t có thể bao gồm các

bu ớc để chuẩn hóa các URL đu ợc lấy ra, loại bỏ các từ dừng khỏi nọ i dungtrang web v.v Các thành phần của bọ duyẹ t đu ợc mô tả ở phần sau.3.2.4.1 Quá trình lấy và chuẩn hoá các URL

Bọ duyẹ t HTML đã đu ợc xây dựng s n trong rất nhiều ngôn ngữ.Chúng cung cấp các tính na ng để dễ dàng xác định các thẻ HTML và liên kếtgiá trị các cạ p thuọ c tính trong mọ t va n bản HTML cho tru ớc Để lấy

ra đu ợc các URL hyperlink từ mọ t trang web, ta có thể sử dụng các bọduyẹ t ở trên để tìm các thẻ anchor và lấy ra các giá trị của thuọ c tính href

tu o ng ứng Tuy nhiên, chúng ta cần chuyển các URL tu o ng đối sang cácđịa chỉ URL tuyẹ t đối sử dụng URL co sở của trang web no i chúng đu ợctrích ra

Các URL khác nhau tu o ng ứng với cùng mọ t trang web có thể đu ợc ánh

xạ vào mọ t dạng chuẩn đo n nhất Điều này rất quan trọng nh m tránh đu ợcviẹ c nạp cùng mọ t trang web nhiều lần Sau đây là các bu ớc đu ợc sử dụngtrong các hàm chuẩn hóa thông dụng:

- Chuyển giao thức và tên máy chủ sang dạng chữ thu ờng.Ví dụ:

HTTP: www.UIOWA.edu đu ợc chuyển thành http: www.uiowa.edu

- Loại bỏ phần anchor hoạ c reference của URL Do đó:

http: spiders.uiowa.edu faq.htm đu ợc thu gọn thành

http://spiders.uiowa.edu/faq.htm

- Thực hiẹ n viẹ c mã hóa URL b ng các k tự thông dụng nhu „ ‟ Điều

http://dollar.biz.uiowa.edu/~pant/ là mọ t URL khác vớihttp://dollar.biz.uiowa.edu/%7Epant/

- Đối với mọ t số URL, thêm vào dấu „ ‟ http: dollar.biz.uiowa.edu vàhttp: dollar.biz.uiowa.edu phải cùng ánh xạ vào cùng mọ t dạng chuẩn Viẹ cthêm vào dấu „ ‟ hay không trong nhiều tru ờng hợp đòi hỏi kinh nghiẹ m

- Sử dụng các kinh nghiẹ m để nhạ n ra các trang web mạ c định Các tên filenhu index.html hay index.htm có thể bị loại khỏi URL bởi chúng vẫn đu ợccoi là các file mạ c định Nếu điều này là đúng, chúng có thể đu ợc lấy ra b ngcách chỉ sử dụng URL co sở

- Loại bỏ k tự „ ‟ và thu mục cha khỏi đu ờng dẫn URL Do đó, địa chỉ

URL 7epant Bizlntel Seeds ODPSeeds.dat đu ợc đo n giản hóa thành

/%7Epant/Bizlnel/ODPSeeds.dat

- Để lại các số hiẹ u cổng trong các URL ngoại trừ đó là cổng 80 Mọ t cáchkhác là để lại các số hiẹ u cổng trong URL và thêm cổng 80 nếu số hiẹ

không đu ợc chỉ định

u cổng

3.2.4.2 Loại bỏ các từ dừng và chuyển các dạng thức của từ sang dạng gốc Khi

duyẹ t mọ t trang web để trích ra các thông tin nọ i dung hoạ c

để tính điểm các URL mà trang đó trỏ tới, thông thu ờng ta nên loại bỏ các từ đu

ợc dùng thu ờng xuyên hay từ dừng (stopwords) nhu „it‟ hay „can‟ trong TiếngAnh Tiến trình xử l viẹ c loại bỏ các từ dừng khỏi va n bản đu ợc gọi làstoplisting Ngoài viẹ c xử l các từ dừng, ta cũng cần lấy ra từ gốc của các từ cótrong va n bản Quá trình stemming chuẩn hóa các từ b ng cách đúc

kết các hình thái của các từ thành mọ t từ ở dạng gốc hay stem Ví dụ: từ

connect, connected hay connection đều đu ợc đu a về dạng connect

3.2.4.3 Xây dựng các thẻ HTML

Các chu o ng trình crawler có thể đánh giá giá trị của mọ t URLhoạ c mọ t từ trong nọ i dung trang web b ng cách xem x t ngữ cảnh của cácthẻ HTML mà nó thuọ c vào Để làm đu ợc điều này, mọ t crawler cần sử dụngcây các thẻ hoạ c cấu trúc DOM của trang HTML Hình 2-2 chỉ ra cấu trúc câycủa các thẻ tu o ng ứng với va n bản HTML nguồn Thẻ <html> đu ợc lấy làmgốc của cây các thẻ khác và text tạo thành các nút của cây Đáng tiếc là, rấtnhiều trang web có cấu trúc HTML không chuẩn Ví dụ, mọ t thẻ bắt đầu có thểkhông có thẻ đóng, hoạ c các thẻ không đu ợc lồng nhau mọ t cách hợp l Trongnhiều tru ờng hợp, thẻ <html> hoạ c <body> đều bị thiếu trong trang HTML Do

đó các tiêu chuẩn dựa trên cấu trúc (structure-based criteria) thu ờng cần có mọ t

bu ớc tiền xử l để chuẩn hóa mọ t va n bản HTML có cấu trúc không chuẩn, quátrình xử l này gọi là làm sạch (tidying) các trang HTML Nó bao gồm cả viẹ c ch

n thêm các thẻ bị thiếu và sắp xếp lại thứ tự các thẻ trong trang Viẹ c làm sạch

mọ t trang HTML là cần thiết để ánh xạ nọ i dung của trang vào trong mọ t cấutrúc cây để đảm bảo tính toàn vẹn, mỗi nút có mọ t cha duy nhất, từ đó phân tíchnên cấu trúc cây của các thẻ

Chú r ng viẹ c phân tích cấu trúc DOM chỉ cần thiết nếu crawler theo chủ điểm

có định sử dụng cấu trúc của trang HTML cho những phân tích phức tạp Còn

hiẹ n của chúng trong trang web thì chỉ cần sử dụng các bọ duyẹ t HTML thôngthu ờng Các bọ duyẹ t này rất s n trong nhiều ngôn ngữ lạ p trình.

21

Hình 2-2 Trang HTML và cấu trúc cây của hệ thống tương ứng

Phần đầu của chương này giới thiệu cấu trúc cơ bản của một WebCrawler Tiếp theo, tôi sẽ giới thiệu hai hệ thống thu thập dữ liệu được trình bàytrong các bài báo khoa học và một hệ thống đã được triển khai trên thực tế

2.2 Hệ thống thu thập dữ liệu Mercator

Vào năm 1999 hai tác giả Allan Heydon và Marc Najork đã đề xuất mộtkiến trúc cho hệ thống thu thập dữ liệu Web có khả năng mở rộng trong bài báo

có tên "Mercator - A Scalable, Extensible Web Crawler" Trong bài báo này, haitác giả đưa ra một số thành phần yêu cầu cần có đối với hệ thống thu thập dữliệu Web có khả năng mở rộng, đó là:

- Thành phần được gọi là URL Frontier cho việc lưu trữ danh sách các URL

cần download

- Thành phần cho việc giải quyết tên miền và địa chỉ IP

- Thành phần cho việc download trang sử dụng giao thức HTTP

- Thành phần cho việc trích rút liên kết từ tài liệu HTML

- Thành phần cho việc kiểm tra URL nào đó đã được viếng thăm hay chưa

Hình 2-3 Các thành phần chính của Mercator (1) lấy 1 URL đầy đủ (absolute URL) ra khỏi Froniter cho việc download MộtURL đầy đủ bắt đầu với định dạng cái mà chỉ rõ giao thức mạng, ví dụ: http TrongMercator, giao thức mạng được cài đặt trong "Protocol Modules" Các moduletrong "Protocol Module" được cầu hình trong file được định nghĩa bởi ngườidùng, và được load động khi hệ thống bắt đầu tiến trình duyệt dữ liệu Cấu hìnhmặc định bao gồm các giao thức: HTTP, FTP, Gopher Dựa vào cấu trúc URL, hệthống sẽ lựa chọn giao thức thích hợp cho việc download Sau đó nó sử dụng chức

năng fetch trong "Protocol Modules" để download trang từ Internet (2) và ghi dữ

liệu download được vào trong RIS

(3) sử dụng "Content Seen" để kiểm tra nội dung trang (gắn với URL khác) đã

được viếng thăm trước đó hay chưa (4).

Nếu đã được viếng thăm, hệ thống sẽ không xử lý thêm nữa, đồng thời xoá URLkhỏi Frontier Dựa vào MIME type trong trang download được, các module

thích hợp sẽ được chọn để xử lý tiếp theo (5).

Ví dụ, "Link Extractor" và "Tag Counter" sử dụng cho MIME text/html, và GIFStats xử lý các trang có MIME là image/gif Với MIME là text/html hệ thống sẽtrích rút tất cả các liên kết bên trong nó, mỗi liên kết được chuyển đổi thành

URL đầy đủ, qua "URL Filter" để kiểm tra (6).

Các URL sau khi qua "URL Filter" sẽ được "URL Seen" (7) kiểm tra xem URL

đã được viếng thăm hay chưa, hoặc URL có n m trong Frontier hay không Nếu

không sẻ bổ xung URL mới vào Frontier (8).

Thông tin trên cũng là cơ sở lý thuyết cho việc xây dựng hệ thống khảo duyệtweb của tôi được trình bày trong luận văn này

2.3 Hệ thống thu thập dữ liệu từ Twitter - TwitterEcho

Các dịch vụ truyền thông đa phương tiện xã hội (social media) đã nổi lêntrong vài thập kỷ gần đây, thay đổi cách mà chúng ta thông tin với nhau Do đó,chúng trở thành đối tượng nghiên cứu trong một vài lĩnh vực bao gồm thu thậpthông tin, phân tích mạng xã hội Việc thu thập dữ liệu cho dịch vụ này thường

là vấn đề phức tạp vì các dịch vụ thường không kết nối trực tiếp tới nơi mà dữliệu đó được sinh ra, thậm chí cho mục đích nghiên cứu Do đó, những nhànghiên cứu cần xây dựng hệ thống cho việc thu thập dữ liệu đó hoặc là sử dụngcác API được cung cấp bởi mạng xã hội, hoặc là thu thập dữ liệu thông quaWeb Crawler

Đặc biệt mạng xã hội Twitter chứa đựng nguồn thông tin cho việcnghiên cứu, từ việc phân tích tương tác của người sử dụng, phân tích việc sửdụng hashtag, và trích dẫn URL, phân tích nội dung cụ thể nào đó (ví dụ: phântích sự lan truyền của dịch cúm, điều tra số lượng người nước ngoài nói tiếng

Bồ Đào Nha)

Yêu cầu kỹ thuật trong TwitterEcho:

- Tôn trọng giới hạn (Adhering to limitations)

- Vận hành liên tục (Continuous Operation)

- Khả năng mở rộng thời gian thực (Run-time expandability)

- Đầy đủ dữ liệu (Data completeness)

- Tha thứ lỗi (Fault tolerance)

- Module hoá (Modularity)

Hình 2-4 dưới đây mô tả kiến trúc phân tán tập trung của TwitterEcho của ba tác giả Masko Bosnjak, Eduardo Oliveira, Jose Martins

Hình 2-4 Kiến trúc của TwitterEcho

- "Client": b ng việc sử dụng nhiều Client, chúng ta có thể tạo được hệ thống

mở rộng để tăng lượng request tới Twitter API

- "Server": nhiệm vụ chính của Server là: (1) điều phối quá trình thu thập dữ liệuthông qua việc cấp phát dánh sách các người dùng tới Client, và (2) lưu trữ dữ liệu

đã được download

2.4 Tìm hiểu về công cụ HTTrack

HTTrack là một công cụ miễn phí cho phép bạn download World WideWeb từ Internet tới thư mục n m trên máy tính của bạn HTTrack sắp xếp cấutrúc liên kết của site gốc Dưới đây là một vài hình ảnh mô tả giao diện củaHTTrack

Hình 2-5 Kéo thả một vài địa chỉ web

Hình 2-6 mô tả giao diện cấu hình HTTrack

Hình 2-6 Cấu hình HTTrack

Hình 2-7 mô tả sử dụng bộ filter để lọc các liên kết mà HTTrack cần viếng