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

Nhận dạng Key Player trên Twitter
ĐẠ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
Học viên: Huỳnh Lê Quốc Vương MHV: CH1101158
08 – 2012
ĐẠ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
Học viên: Huỳnh Lê Quốc Vương MHV: CH1101158
08 – 2012
Nhận dạng Key Player trên Twitter
MỤC LỤC
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ễn
phí, 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 qua
API 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.
Nhận dạng Key Player trên Twitter
I. NO SQL Database
1. Xu hướng dữ liệu
Theo Eric Schmidt của Google thì “mỗi 2 ngày chúng ta đã tạo ra một
lượng thông tin bằng cả năm 2003” (năm 2010).
Và tổng dữ liệu được tạo ra trên toàn thế giới trong năm 2011 đã đạt đến
1.8ZB và lượng dữ liệu sẽ tăng hơn gấp đôi qua 2 năm.
Trong khi dữ liệu càng ngày càng lớn rất nhanh thì chúng cũng ngày một
được kết nối hơn như
- 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é, …
Nhận dạng Key Player trên Twitter
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à Non-
Relational (NoRel) - không ràng buộc. Nhưng sau này người ta thường dịch
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 theo
chiề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: schema-
free, hỗ trợ mở rộng dễ dàng, API đơn giản, eventual consistency (nhất quán
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
Cabinet, Redis,
- Key/value được lưu trữ nhất quán: Amazon Dynamo, Voldemort,
Dynomite, KAI, Cassandra, Hibari, Project Voldemort,…
- Key/value được lưu trữ có thứ tự: NMDB, Memcachedb, Berkeley
DB,
- Key/value với phân tán: Apache River, MEMBASE, Azure Table
Storage, Amazon Dynamo,.
• Điểm mạnh:
o Mô hình dữ liệu đơn giản
o Khả năng mở rộng cao
• Điểm yếu:
o Không thể tạo khóa ngoại
o Khó khăn trong dữ liệu phức tạp
Nhận dạng Key Player trên Twitter
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ưu
trữ 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,…
• Điểm mạnh:
o Hỗ trợ dữ liệu nửa cấu trúc
o Đánh chỉ mục tự động theo cột
o Khả năng mở rộng cao
• Điểm yếu:
o Khó khăn trong interconnected data
2.3. Document Store
Thực chất là các document-oriented database - một thiết kế riêng biệt cho
việc lưu trữ document. Các cài đặt có thể là giả lập tương tác trên relational
database, object database hay key-value store. Một số sản phẩm tiêu biểu:
Apache Jackrabbit, CouchDB, IBM Lotus Notes Storage Format (NSF),
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:
RDBMS
Nhận dạng Key Player trên Twitter
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 hay
danh 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
Nhận dạng Key Player trên Twitter
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
Nhận dạng Key Player trên Twitter
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”
Nhận dạng Key Player trên Twitter
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ằng
ngô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 Neo4j
Cá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.
Nhận dạng Key Player trên Twitter
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ác mố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”
2.2. Mối quan hệ

Các mối quan hệ giữa các nút là một phần quan trọng của một cơ sở dữ liệu
đồ thị.
Chúng cho phép tìm dữ liệu có liên quan nhau. Cũng giống như nút, các
mối quan hệ có thể có các thuộc tính
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ó
Nhận dạng Key Player trên Twitter
Để 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ị.
Nhận dạng Key Player trên Twitter
Đườ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:
/>Nhận dạng Key Player trên Twitter
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ệu
ngườ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