Nhận Dạng Key Player trên Mạng Xã Hội Twitter

Dữ liệu này sẽ được lưu trữ xuống một cơ sở dữ liệu đồ thị, một loại cơ sở dữ liệu hết sức hữu dụng hiện nay đối với các dữ liệu có nhiều mối quan hệ như mạng xã hội.. - RDF Resource Des

CƠ SỞ DỮ LIỆU NÂNG CAO

Nhận Dạng Key Player trên Mạng Xã Hội Twitter

Giáng viên hướng dẫn PGS.TS Đỗ Phúc

ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

CƠ SỞ DỮ LIỆU NÂNG CAO

Nhận Dạng Key Player trên Mạng Xã Hội Twitter

Giáng viên hướng dẫn PGS.TS Đỗ Phúc

08 – 2012

GIỚI THIỆU 3

I NO SQL DATABASE 4

1 Xu Hướng Dữ Liệu 4

2 Các Loại NO SQL Database 7

2.1 Key Value Store 7

2.2 Wide Column Store / Column Families 8

2.3 Document Store 8

2.4 Graph Database 9

3 So Sánh các Mô Hình Database với Graph Database 9

3.1 Một Graph Database từ một RDBMS 9

3.2 Một Graph Database từ một Key-Value Store 10

3.3 Một Graph Database từ một Column-Family 11

3.4 Một Graph Database từ một Document Store 12

II KHÁI QUÁT GRAPH DATABASE VÀ NEO4J 13

1 Graph Database 13

1.1 Nút và Mối Quan Hệ 13

1.2 Truy Vấn Đồ Thị 14

1.3 Lập Chỉ Mục các Nút và Mối Quan Hệ 15

2 Neo4j 16

2.1 Nút 18

2.2 Mối Quan Hệ 18

2.3 Thuộc Tính 20

2.4 Đường Đi 21

2.5 Duyệt 23

III CHƯƠNG TRÌNH 24

1 Giới Thiệu Chương Trình 24

1.1 Thu Thập Dữ Liệu qua Twitter API 25

1.2 Lưu Trữ đến Neo4j 30

1.3 Tìm Key Player 31

2 Hướng Dẫn Sử Dụng 32

2.1 Yêu Cầu 32

2.2 Thực Thi 32

IV.TỔNG KẾT VÀ HƯỚNG PHÁT TRIỂN 40

TÀI LIỆU THAM KHẢO 41

GIỚI THIỆU

Hiện nay, mạng xã hội là một đề tài hết sức được quan tâm Thông qua mạng xã hội với hàng triệu người sử dụng thì các tin tức sự kiện được lan truyền đi rất nhanh Tất nhiên giới kinh doanh không thể nào bỏ qua cơ hội này, đặc biệt là việc marketing trên mạng xã hội Các công ty lớn như Dell, Starbucks hay Comcast đã tận dụng rất tốt Twitter để quảng bá sản phẩm và giải đáp thắc mắc khách hàng Nhưng hiện nay, trên các dịch vụ tiểu blog miễnphí, có thể thấy rằng số lượng các doạnh nghiệp nhỏ đã vượt trội so với các doanh nghiệp lớn Và xét trên nhiều phương diện, Twitter là công cụ rất hữu ích cho họ Các doanh nghiệp nhỏ có được hơn một nửa số khách hàng của mình chủ yếu nhờ truyền miệng, và Twitter là một minh chứng cho điều đó Vìvậy, nếu tìm ra được các key player trên mạng xã hội để “phóng thanh” thì sẽ rất là hiệu quả đối với các doanh nghiệp

Trong bài thu hoạch này sẽ thực hiện việc tìm các key player trên mạng xã hội Twitter Dữ liệu dùng để nhận ra các key player sẽ được thu thập thông quaAPI Twitter Qua API này ta có thể lấy được thông tin của người dùng và các mối quan hệ của họ Dữ liệu này sẽ được lưu trữ xuống một cơ sở dữ liệu đồ thị, một loại cơ sở dữ liệu hết sức hữu dụng hiện nay đối với các dữ liệu có nhiều mối quan hệ như mạng xã hội Do đó ta cùng tìm hiểu về các ưu điểm của loại cơ sở dữ liệu mới (NO SQL) so với cơ sở dữ liệu truyền thống (cơ sở

dữ liệu quan hệ) Cụ thể, sẽ đi vào tìm hiểu cơ sở dữ liệu đồ thị và một hiện thực của nó là Neo4j Sau cùng, sẽ là cách thực hiện chương trình để đạt được vấn đề đặt ra

Lời cảm ơn, em chân thành xin dành cho thầy Phúc vì những kiến thức của Thầy mang lại để giúp em có được cũng như hoàn thành tốt bài thu hoạch này

- Trong nội dung văn bản

- Trong HyperText – các đường dẫn liên kết nhau

- RSS (Really Simple Syndication)

- Các Blog – có chứa các pingback

- Tagging – nhóm các dữ liệu liên quan lại với nhau

- RDF (Resource Description Framework) – mô tả dữ liệu được kết nối như thế nào)

- GGG (Giant Global Graph) – nội dung + các liên kết + các mối quan hệ + mô tả

- …

Xu hướng kết nối dữ liệu

Dữ liệu trở nên bán cấu trúc (dữ liệu không được mô tả riêng biệt thành về kiểu và cấu trúc – không có lược đồ)

- Nếu bạn muốn thu thập tất cả dữ liệu cho mỗi bộ phim được sản xuất từ trước đến giờ, bạn sẽ phải mô hình nó như thế nào?

- Có quá nhiều thứ để bạn phải suy nghĩ như đạo diễn, nhân vật, địa điểm,ngày, chi phí, đánh giá, trình chiếu, giá vé, …

Hình trên cho thấy performance của cơ sở dữ liệu quan hệ giảm đáng kể khi

độ phức tạp dữ liệu (kết nối dữ liệu) ngày càng tăng

Vì thế đã có sự ra đời của NO SQL Ban đầu NO SQL có nghĩa là Relational (NoRel) - không ràng buộc Nhưng sau này người ta thường dịch

Non-NO SQL thành Not Only SQL, ám chỉ đến những cơ sở dữ liệu không dùng môhình dữ liệu quan hệ để quản lý dữ liệu trong lĩnh vực phần mềm

Với NO SQL là một thế hệ cơ sở dữ liệu non-relational (không ràng buộc), distributed (phân tán), open source, horizontal scalable (khả năng mở rộng theochiều ngang) có thể lưu trữ, xử lý từ một lượng rất nhỏ cho tới hàng petabytes

dữ liệu trong hệ thống có độ chịu tải, lỗi cao với những đòi hỏi về tài nguyên phần cứng thấp

Một số đặc điểm nhận dạng cho thế hệ database mới này bao gồm: free, hỗ trợ mở rộng dễ dàng, API đơn giản, eventual consistency (nhất quán

schema-cuối) và/hoặc transactions hạn chế trên các thành phần dữ liệu đơn lẻ, không giới hạn không gian dữ liệu,

Hiện nay có 4 loại cơ sở dữ liệu NO SQL như sau:

2. Các loại NO SQL Database

2.1 Key Value Store

Mô hình lưu trữ dữ liệu dưới cặp giá trị key-value trong đó việc truy xuất, xóa, cập nhật giá trị thực thông qua key tương ứng Với sự bổ trợ bởi các kỹ thuật BTree, B+Tree, Hash, dữ liệu có thể tồn tại trên RAM hoặc đĩa cứng, phân tán hoặc không phân tán Hầu hết các NoSQL database đều là key-value store Dưới đây là một số đặc tính có thể được hỗ trợ trong sản phẩm dạng này:

- Key/value được cache trong RAM: memcached, Citrusleaf database, Velocity, Redis, Tuple space,

- Key/value được lưu trên đĩa: Memcachedb, Berkeley DB, Tokyo

o Không thể tạo khóa ngoại

o Khó khăn trong dữ liệu phức tạp

2.2 Wide Column Store / Column Families

Hệ cơ sở dữ liệu phân tán cho phép truy xuất ngẫu nhiên/tức thời với khả năng lưu trữ một lượng cực lớn data có cấu trúc Dữ liệu có thể tồn tại dạng bảng với hàng tỷ bản ghi và mỗi bản ghi có thể chứa hàng triệu cột Một triển khai từ vài trăm cho tới hàng nghìn commodity hardware dẫn đến khả năng lưutrữ hàng petabytes nhưng vẫn đảm bảo high performance Dưới đây là một số sản phẩm thông dụng: Hadoop/HBase – Apache, BigTable – Google,

Cassandra - Facebook/Apache, Hypertable - Zvents Inc/Baidu, Cloudera, SciDB, Mnesia, Tablets,…

MongoDB, Terrastore, ThruDB, OrientDB, RavenDB,

 Điểm mạnh:

o Đơn giản, mô hình dữ liệu mạnh mẽ

o Khả năng mở rộng cao

 Điểm yếu:

o Khó khăn trong interconnected data

o Mô hình truy vấn bị giới hạn các khóa và chỉ mục

o Thiếu map reduct cho các truy vấn lớn

2.4 Graph Database

Graph database là một dạng cơ sở dữ liệu được thiết kế riêng cho việc lưu trữ thông tin trong đồ thị như cạnh, nút, thuộc tính Một số sản phẩm tiêu biểu: Neo4J, Sones, AllegroGraph, Core Data, DEX, FlockDB, InfoGrid, OpenLink Virtuoso,

 Điểm mạnh:

o mô hình dữ liệu đầy sức mạnh

o Truy vấn nhanh cho các dữ liệu có kết nối

 Điểm yếu:

o Khó khăn trong việc sharding, đang chờ sự phát triển

o Phải thay đổi cách nghĩ, khái niệm về cơ sở dữ liệu đồ thị

3. So sánh các mô hình database với graph database

3.1. Một graph database từ một RDBMS

Tách các record trong các stack trong một cơ sở dữ liệu quan hệ trong khi vẫn giữ các mối quan hệ giữa chúng, ta sẽ được một đồ thị Ở đây, RDBMS thìđược tối ưu cho dữ liệu được gom lại thành kiểu (nhóm) trong khi graph database được tối ưu cho dữ liệu được kết nối Nhìn hình sau đây:

Graph database từ RDBMS

3.2. Một graph database từ một Key-Value Store

Một mô hình key-value thì tối ưu cho việc tìm kiếm các giá trị đơn giản haydanh sách Còn graph database tối ưu cho việc duyệt dữ liệu có kết nối Xem hình sau:

Key-Value Store (K*biểu diễn một key, V* biểu diễn một value Chú ý một

vài key trỏ tới các key khác chỉ là giá trị đơn giản)

Graph Database từ Key-Value Store

3.3. Một graph database từ một Column-Family

Cơ sở dữ liệu Column Family là một bước tiến của key-value, sử dụng các

“family” để nhóm các dòng Lưu trữ trong một đồ thị, family trở nên có tính phân cấp và mối quan hệ giữa các dữ liệu trở nên rõ ràng

3.4. Một graph database từ một Document Store

Hệ thống phân cấp của một document database chứa dữ liệu có schema-free

do đó có thể dễ dàng biểu diễn trong cây Với graph database, thì các mối quan

hệ giữa các document dễ dàng được duyệt hơn Như hình sau:

D=Document, S=Subdocument, V=Value, D2/S2 = tham chiếu tới

subdocument trong document khác

Graph database từ Document Store

Ta đã thấy được ưu điểm của graph database trong dữ liệu phức tạp có kết nối, xem phần sau để tìm hiểu kỹ hơn về graph database và neo4j, một hiện thực của graph database mà ta sẽ sử dụng cho chương trình

II Khái quát graph database và Neo4j

1 Graph database

1.1 Nút và mối quan hệ

Một graph lưu trữ record trong các nút (đỉnh) và các nút có các thuộc tính.Một graph đơn giản nhất là một nút đơn lẻ, một record mà có các giá trị (được đặt tên) thì được xem như là các thuộc tính Một nút có thể bắt đầu với một thuộc tính và phát triển dần thành vài triệu thuộc tính Tuy nhiên, vài triệu thuộc tính có thể bất tiện, do đó, nó có thể được phân tán thành nhiều nút, với các mối quan hệ (cạnh) với nhau

Các nút được tổ chức bởi các mối quan hệ, các mối quan hệ này cũng có các thuộc tính

Các mối quan hệ tổ chức các nút thành các cấu trúc bất kỳ, cho phép một graph giống như một List, một Tree, một Map, một Entity hỗn hợp nào đó – bất kỳ cái nào có thể kết hợp thành phức tạp hơn, đa dạng về cấu trúc liên kết

Sự tương quan giữa độ phức tạp của dữ liệu

và kích thước trong các loại NO SQL

Ta có thể hình dung một graph database như thế này

Tổng quan một graph database

1.2 Truy vấn đồ thị

Một truy vấn đồ thị được thực hiện với một traversal Một Traversal điều hướng trên một Graph, nó xác định các Path giữa các nút

Một Traversal biểu diễn cách truy vấn một đồ thị như thế nào, điều hướng

từ nút bắt đầu đến các nút khác theo một thuật toán, tìm các câu trả lời cho các câu hỏi như “thể loại nhạc mà người yêu bạn yêu thích là gì”, “vợ của sếp bạn làm việc ở đâu”

Tổ chức của Traversal

1.3 Lập chỉ mục các nút và mối quan hệ

Thông thường, người ta muốn tìm một nút cụ thể hay mối quan hệ dựa vào một thuộc tính nào đó của nút hay của mối quan hệ mà nó có Với trường hợp Traversal này thì được tối ưu bằng cách lập một bảng chỉ mục dựa trên thuộc tính cho các nút và mối quan hệ, cho các câu hỏi ví dụ như “tìm tài khoản có tên là Peter”

Cách thức đánh chỉ mục của graph database

Phần tiếp theo sẽ đi vào tìm hiểu Neo4j, một hiện thực graph database bằngngôn ngữ Java

2 Neo4j

Cách tổ chức của Neo4j tương tự như phần trên, ta sẽ mô hình hóa chúng bằng hình sau:

Tổ chức trong Neo4jCác đơn vị cơ bản hình thành nên một cơ sở dữ liệu đồ thị là nút và mối quan hệ Trong Neo4j, cả nút và mối quan hệ đều có thể chứa các thuộc tính.

2.1 Nút

Các nút thường được sử dụng để biểu diễn các thực thể, chúng có thể có cácmối quan hệ và thuộc tính

Một nút có các thuộc tính và mối quan hệ

Ví dụ một nút chỉ chứa một thuộc tính “name”

Nút với một thuộc tính “name”

Tổ chức của một mối quan hệMột mối quan hệ kết nối giữa hai nút, một nút bắt đầu và một nút kết thúc.

Một mối quan hệ luôn luôn có hướng, chúng có thể được xem như là một mối quan hệ “đi” hoặc “đến” tới một nút, được sử dụng để duyệt đồ thị:

Trong Neo4j hướng của mối quan hệ có thể được lờ đi nếu nó không hữu ích trong ứng dụng

Một nút có thể có mối quan hệ với chính bản thân nó

Để nâng cao việc duyệt đồ thị, các mối quan hệ đều có kiểu hay gọi cách khác là được gán nhãn Ví dụ dưới đây là một mạng xã hội đơn giản với hai kiểu mối quan hệ.

Để tìm một người theo sau thì duyệt theo mối quan hệ có kiểu “follows”, còn nếu tìm một người chặn một người khác thì duyệt theo mối quan hệ có kiểu “blocks”

2.3 Thuộc tính

Cả nút và mối quan hệ đều có thể có thuộc tính

Các thuộc tính là các cặp key-value với key là kiểu string Các giá trị thuộc tính có thể là kiểu cơ bản (integer, long, float, …) hay một mảng của một kiểu

cơ bản Ví dụ String, int và int[] là các giá trị hợp lệ cho thuộc tính

2.4 Đường đi

Một đường đi là một hay nhiều nút với các mối quan hệ kết nối, thường được truy hồi như là một kết quả truy vấn hay duyệt đồ thị

Đường đi ngắn nhất có chiều dài là 0 giống như sau:

Một đường đi có chiều dài là 1

2.5 Duyệt

Duyệt một đồ thị có nghĩa là viếng thăm các nút của đồ thị, theo các mối quan hệ với một vài luật Trong hầu hết các trường hợp, chỉ một đồ thị con được viếng thăm khi đã biết trong đó có các nút và mối quan hệ cần tìm.Neo4j với API cho phép duyệt chọn một cách duyệt cụ thể Với mức cơ bản, có thể chọn cách duyệt theo chiều sâu hay chiều rộng

Về chi tiết kỹ thuật lập trình với Neo4j, tham khảo tại đây:

http://docs.neo4j.org/chunked/milestone/tutorials.html

III Chương trình

1 Giới thiệu chương trình

Ta đã biết lợi ích như thế nào trong việc marketing trên mạng xã hội cũng như tầm quan trọng của các key player (“loa phóng thanh”) trên mạng xã hội đối với việc marketing Do đó, vấn đề là phải nhận dạng, tìm ra được các key player này

Chương trình sẽ thông qua API của mạng xã hội Twitter để thu thập dữ liệungười dùng Twitter liên tục 24/24 (nếu không tắt chương trình) và mối quan hệgiữa họ, cụ thể là mối quan hệ follower Dữ liệu này sẽ ta được lưu trữ xuống Neo4j Cuối cùng ta có thể tìm ra được các key player với dữ liệu này Cụ thể các bước như sau

1.1 Thu thập dữ liệu qua Twitter API

Thông qua API của Twitter https://dev.twitter.com/ ta thu thập dữ liệu của các người dùng và các mối quan hệ giữa chúng (ở đây ta quan tâm mối quan hệ

Tham số user_id hoặc screen_name phải được cung cấp

screen_name (optional) tên của user

include_entities (optional) giá trị là true/false, tùy chọn này dùng để

hiển thị thêm một số thông tin (https://dev.twitter.com/docs/tweet-entities)

Ví dụ với request

https://api.twitter.com/1/users/show.json?

screen_name=TwitterAPI&include_entities=true

an answer? It's on my website.",

29 "time_zone": "Pacific Time (US & Canada)",

30 "profile_background_image_url":

background-new.png",

 API: GET followers/ids

o Resource URL

http://api.twitter.com/1/followers/ids.format

o Các tham số

Tham số user_id hoặc screen_name phải được cung cấp

cursor (optional) Mỗi lần kết quả trả về chỉ giới hạn 5000

người theo sau Nếu có hơn 5000 ngườitheo sau thì dựa vào cursor này để truy vấn những người theo sau kế tiếp

Ví dụ với request

https://api.twitter.com/1/followers/ids.json?cursor=-1&screen_name=twitterapi

Thì response sẽ là

1 {

Screen_name tên truy cập Twitter của user

Profile_image_url Đường dẫn ảnh đại diện của user

View_Status trạng thái truy cập đến user

Is_Vietnamese có phải là người Việt Nam hay không

Last_updated thời gian lần cuối cập nhật thông tin user

Với mối quan hệ giữa các user là “IS_FOLLOWED”

1.3 Tìm Key Player

Với cơ sở dữ liệu trên, ta có thể tìm ra được các key player theo các độ đo:

 Degree Centrality

C D (v) là độ đo degree centrality của nút (đỉnh) v

deg(v) là số cạnh liên thuộc với nút v

n là số cạnh

 Betweenness Centrality

C B (v) là độ đo betweenness centrality của nút (đỉnh) v

s,v,t ∈V (tập đỉnh của đồ thị)

σ st = là tổng shortest path từ đỉnh s đến đỉnh t của toàn network

σ st(v) = tổng shortest path từ đỉnh s đến đỉnh t đi qua đỉnh v

C C (v) là độ đo closeness centrality của nút (đỉnh) v

d G (v,t) là số bước đi nhỏ nhất từ đỉnh v tới đỉnh t.

2.2 Thực thi

Đọc file READ_ME.txt trong thư mục Program để chạy chương trình.Giao diện chương trình được chia thành 3 phần chính:

- Connect to Graph Database

- Collect Data from Twitter

- Find Key Players