DATN Nguyen Minh Quang 20184303

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
ĐỒ ÁN TỐT NGHIỆP
Một số mô hình khuyến nghị sản phẩm cho người
dùng trên trang Thương mại điện tử Shopee sử dụng
Graph Database
NGUYỄN MINH QUANG
quag.nm184303@sis.hust.edu.vn
Ngành Khoa Học Máy Tính

Chuyên ngành Hệ thống thông tin và truyền thông Việt Pháp
Giảng viên hướng dẫn: PGS.TS Cao Tuấn Dũng
Chữ kí GVHD
Khoa: Khoa Học Máy Tính
Trường: Đại Học Bách Khoa Hà Nội
HÀ NỘI, 01/2024
LỜI CẢM ƠN
Lời đầu tiên, em xin gửi lời cảm ơn sâu sắc đến PGS.TS. Cao Tuấn Dũng. Thầy
là người đã hướng dẫn, định hướng cho giúp em vượt qua khoảng thời gian khó
khăn ban đầu để xác định mục tiêu ĐATN, thầy giúp đỡ em rất nhiều trong quá
trình nghiên cứu, thực hiện và hoàn thiện ĐATN này. Em cũng xin cảm ơn tới tất
cả thầy cô đã chỉ dạy cho em những kiến thức quý báu trong suốt quá trình học tập
tại Đại học Bách khoa Hà Nội, cung cấp một hành trang kiến thức thiết thực cho
tương lai sắp tới. Em cũng xin cảm ơn tới tất cả các anh đồng nghiệp trong công ty
BNH - những người luôn tận tình giúp đỡ, chỉ dạy em từ những ngày đầu vào công
ty và trong quá trình thực hiện ĐATN, các anh cũng giúp đỡ em rất nhiều về phần
kiến thức cũng như hỗ trợ phần hạ tầng server để em thực hiện Đồ án. Cuối cùng,
em xin cảm ơn tới người thân, gia đình, bạn bè - những người luôn ở bên cạnh, tin
tưởng, động viên tinh thần, giúp em vượt qua những khó khăn trong suốt quá trình
học tập tại đại học Bách Khoa Hà Nội. Do thời gian có hạn, cũng như kiến thức
chuyên môn còn cần cải thiện, ĐATN của em sẽ không tránh khỏi những thiết sót
và hạn chế. Em rất mong nhận được những đánh giá, nhận xét, góp ý từ thầy cô,
để bản thân có thể hoàn thiện hơn, rút ra những bài học quý giá, là hành trang giúp
em vững vàng hơn cho hành trình tương lai. Em xin chân thành cảm ơn!
i
TÓM TẮT NỘI DUNG ĐỒ ÁN
Mua sắm trực tuyến là một ngày càng len lỏi trong cuộc sống và là một phần thiết
yếu không thể thiếu trong cuộc sống hàng ngày. Truy cập một trang web mua sắm
trưc tuyến như Shopee hoặc Lazada để mua hàng hóa cần thiết - đã trở thành một
thực tế mà không khó có thể bắt gặp.
Thật vậy, thương mại điện tử đã đi một chặng đường dài từ khái niệm mới lạ đến
người khổng lồ thay đổi toàn bộ cách thức mua bán trên toàn thế giới. Sự kết hợp
giữa sự tiện lợi và hiệu quả về mặt chi phí của nó đã cách mạng hóa cách chúng ta
nghĩ về các giao dịch bán lẻ và tiền tệ. Cục điều tra dân số Hoa Kỳ (U.S. Census
Bureau ) tiến hành ước tính doanh số thương mại điện tử bán lẻ tại Hoa Kỳ, trong
quý I/2023, thương mại điện tử bán lẻ chiếm 15,1 % tổng doanh thu cả nước, tổng
cộng khoảng 272,6 tỷ USD cho thấy phần nào sự phát triển của ngành thương mại
điện tử là xu hướng tất yếu, đặc biệt trong những năm Thế giới chịu ảnh hưởng bởi
đại dịch Covid-19, việc hạn chế ra đường làm cho nhu cầu mua hàng online phát
triển chóng mặt, và sau khi đại dịch đã được kiểm soát, thói quen của người tiêu
dùng dường như vẫn không đổi, số lượng giao dịch thương mại điện tử vẫn không
có dấu hiệu suy giảm.
Ngành thương mại điện tử đã có sự tăng trưởng vượt bậc trong những năm gần
đây, với việc mua sắm trực tuyến trở thành phương thức mua hàng hóa và dịch vụ
ưa thích của hàng triệu người tiêu dùng trên toàn thế giới. Sự tăng trưởng này được
thúc đẩy bởi những tiến bộ trong công nghệ, cho phép các nhà bán lẻ cung cấp trải
nghiệm mua sắm liền mạch và cá nhân hóa cho từng khách hàng của mình. Một
trong những công nghệ đang làm thay đổi bối cảnh thương mại điện tử là cơ sở dữ
liệu đồ thị (Graph Database). Cơ sở dữ liệu đồ thị là một loại cơ sở dữ liệu NoSQL
lưu trữ dữ liệu dưới định dạng đồ thị, với các nút (node) biểu thị các thực thể và
các cạnh (edge) biểu thị mối quan hệ giữa các thực thể đó. Cấu trúc dữ liệu này
cho phép truy vấn và phân tích hiệu quả các mối quan hệ phức tạp, khiến nó đặc
biệt phù hợp với các ứng dụng yêu cầu hiểu biết sâu sắc về dữ liệu được kết nối với
nhau. Trong bối cảnh thương mại điện tử, điều này có nghĩa là cơ sở dữ liệu đồ thị
có thể được sử dụng để lập mô hình và phân tích mạng lưới phức tạp về mối quan
hệ giữa khách hàng, sản phẩm và các thuộc tính khác nhau của chúng.
Một trong những lợi ích chính của việc sử dụng cơ sở dữ liệu đồ thị trong thương
mại điện tử là khả năng cung cấp các đề xuất và cá nhân hóa nâng cao cho khách
hàng. Cơ sở dữ liệu quan hệ truyền thống gặp khó khăn trong việc xử lý hiệu quả
ii
các mối quan hệ phức tạp đang tồn tại giữa khách hàng và sản phẩm, gây khó khăn
cho việc đưa ra các đề xuất chính xác và kịp thời. Ngược lại, cơ sở dữ liệu đồ thị
vượt trội trong việc quản lý các mối quan hệ này, cho phép các nhà bán lẻ hiểu rõ
hơn về sở thích của khách hàng và đưa ra các đề xuất sản phẩm phù hợp.
Tuy nhiên, trong thực tế, các tổ chức thương mại điện tử vẫn hầu hết vẫn đang sử
dụng hệ thống các cơ sở dữ liệu quan hệ (RDBMS) để xử lý các giao dịch thương
mại điện tử. Việc chuyển đổi từ Hệ quản trị cơ sở dữ liệu quan hệ sang Cơ sở dữ
liệu Đồ thị là một bài toán lâu dài, không thể thực hiện trong một sớm một chiều.
Việc bỏ đi các hệ thống đã chạy ổn định và lâu dài trong một tổ chức doanh nghiệp
là không thể xảy ra. Mặt khác, do đặc thù lưu trữ dữ liệu, Cơ sở dữ liệu quan hệ
từ lâu đã chứng minh được khả năng xử lý các giao dịch với số lượng lớn OLTP
(Online Transaction Processing) hơn hẳn Cơ sở dữ liệu Đồ thị do trong quá trình
Insert, các RDBMS sẽ ghi liên tục các bản ghi thành các dòng (row), còn Graph
Database phải kiểm tra xem các node đã có chưa rồi tạo cách edge nối giữa các
node đó nên Graph Database sẽ phù hợp để xử lý phân tích dữ liệu OLAP (Online
Transaction Processing). Chính vì những lý do trên, các doanh nghiệp thường sẽ
xây dựng cả 2 hệ thống cơ sở dữ liệu RDBMS và Graph Database chạy song song,
từ đó phát sinh nhu cầu cần có một hệ thống trung gian, chuyên biệt để thực hiện
nhiệm vụ đồng bộ dữ liệu liên tục, tự động giữa 2 hệ thống, và hiện nay, Kafka
đang là một trong những nền tảng stream dữ liệu phân tán (Distributed Streaming
Platform) giúp hỗ trợ giải quyết vấn đề đồng bộ này.
iii
MỤC LỤC
CHƯƠNG 1. GIỚI THIỆU ĐỀ TÀI ĐỒ ÁN ............................................ 1
1.1 Đặt vấn đề............................................................................................ 1
1.2 Mục tiêu và phạm vi đề tài..................................................................... 1
1.3 Định hướng giải pháp............................................................................ 2
1.4 Bố cục đồ án ........................................................................................ 2
CHƯƠNG 2. CÁC CÔNG NGHỆ SỬ DỤNG ........................................... 3
2.1 Cơ sở dữ liệu MariaDB ......................................................................... 3
2.2 Cơ sở dữ liệu Neo4j .............................................................................. 5
2.3 Confluent Platform ............................................................................... 12
CHƯƠNG 3. CÀI ĐẶT ............................................................................ 24
3.1 Thiết kế kiến trúc.................................................................................. 24
3.1.1 Sơ đồ Logic hệ thống ................................................................. 24
3.1.2 Mô hình server........................................................................... 25
3.1.3 Thiết kế Cơ sở dữ liệu................................................................. 26
3.2 Cài đặt................................................................................................. 29
3.2.1 Cài đặt MariaDB........................................................................ 29
3.2.2 Cài đặt Neo4J ............................................................................ 32
3.2.3 Cài đặt Confluent Platform ......................................................... 35
CHƯƠNG 4. KẾT QUẢ THỰC NGHIỆM............................................... 51
4.1 Đồng bộ realtime, tự động từ MariaDB sang Neo4j thông qua Confluent
Platform .................................................................................................... 51
4.2 Các mô hình khuyến nghị thời gian thực sử dụng Neo4j ........................... 67
CHƯƠNG 5. CÁC GIẢI PHÁP VÀ ĐÓNG GÓP NỔI BẬT...................... 69
5.1 Hiệu suất của MariaDB ......................................................................... 69
5.1.1 Vấn đề....................................................................................... 69
5.1.2 Giải pháp .................................................................................. 69
5.2 Vấn đề bảo mật của Confluent ............................................................... 70
5.2.1 Vấn đề....................................................................................... 70
5.2.2 Giải pháp .................................................................................. 70
CHƯƠNG 6. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN TƯƠNG LAI........ 73
6.1 Kết luận ............................................................................................... 73

DANH MỤC HÌNH VẼ
Hình 2.1 Logo của hãng MariaDB . . . . . . . . . . . . . . . . . . . . . 3

Hình 2.2 Dữ liệu được ghi trong binlog sau khi sử dụng công cụ của
MariaDB để đọc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Hình 2.3 Logo của Neo4j . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Hình 2.4 Truy vấn trên Native Graph . . . . . . . . . . . . . . . . . . . . 11
Hình 2.5 Truy vấn trên Non-Native Graph . . . . . . . . . . . . . . . . . 11
Hình 2.6 Confluent Platform Component . . . . . . . . . . . . . . . . . 12
Hình 2.7 Log trên Kafka . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hình 2.8 Nhiều hệ thống có thể đọc cùng một dữ liệu . . . . . . . . . . 14
Hình 2.9 Cơ chế replication . . . . . . . . . . . . . . . . . . . . . . . . . 14
Hình 2.10 Cách phân bổ của Topic, Partition và Segment . . . . . . . . . 15
Hình 2.11 Dữ liệu được lưu trên broker - các folder có định dạng Topic-
Parition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Hình 2.12 Các file segment trong một Topic . . . . . . . . . . . . . . . . 16
Hình 2.13 Các Kafka Client . . . . . . . . . . . . . . . . . . . . . . . . . 17
Hình 2.14 Dữ liệu được đọc/ghi trên Partition Leader . . . . . . . . . . . 18
Hình 2.15 Các Partition Leader được phân bổ trên các Broker khác nhau 18
Hình 2.16 ZooKeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Hình 2.17 Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Hình 2.18 Schema Registry . . . . . . . . . . . . . . . . . . . . . . . . . 21
Hình 2.19 Kafka Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Hình 2.20 Debezium MySQL Connector . . . . . . . . . . . . . . . . . . 22
Hình 3.1 Sơ đồ Logic hệ thống . . . . . . . . . . . . . . . . . . . . . . . 24

Hình 3.2 Sơ đồ server Hệ thống . . . . . . . . . . . . . . . . . . . . . . 26
Hình 3.3 Thiết kế cơ sở dữ liệu MariaDB . . . . . . . . . . . . . . . . . 26
Hình 3.4 Thiết kế cơ sở dữ liệu Neo4j . . . . . . . . . . . . . . . . . . . 27
Hình 3.5 Trạng thái MariaDB đang hoạt động . . . . . . . . . . . . . . . 30
Hình 3.6 Binlog đã được bật thành công . . . . . . . . . . . . . . . . . . 31
Hình 3.7 Service Neo4j đang hoạt động . . . . . . . . . . . . . . . . . . 34
Hình 3.8 Cypher Shell của Neo4J khởi chạy thành công . . . . . . . . . 34
Hình 3.9 Giao diện web Neo4j sau khi khởi động . . . . . . . . . . . . . 34
Hình 3.10 Thư mục đã được trao quyền thành công . . . . . . . . . . . . 36
Hình 3.11 Cấu hình thư mục Log đã được thay đổi . . . . . . . . . . . . . 37
Hình 3.12 Service ZooKeeper đã khởi động thành công . . . . . . . . . . 38
vi
Hình 3.15 Service Broker đã khởi động thành công . . . . . . . . . . . . 40
Hình 3.18 Service Schema Registry đã khởi động thành công . . . . . . . 42
Hình 3.20 Thư mục lưu log đã được thay đổi . . . . . . . . . . . . . . . . 43
Hình 3.21 Service Kafka Connect đã khởi động thành công . . . . . . . . 44
Hình 3.22 Debezium MySQL Connector đã có trong danh sách plugin
của Kafka Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Hình 3.23 Neo4j Sink Connector đã có trong danh sách plugin của Kafka
Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Hình 3.25 Thư mục lưu log đã được thay đổi . . . . . . . . . . . . . . . . 46
Hình 3.26 Service Confluent Control Center đã khởi động thành công . . 47
Hình 3.27 Giao diện màn hình đăng nhập của Confluent Control Center . 48
Hình 3.28 Giao diện trang chủ của Control Center - Số broker là 3 . . . . 48
Hình 3.29 Control Center đã kết nối tới ZooKeeper . . . . . . . . . . . . 49
Hình 3.30 Control Center đã kết nối tới Kafka Connect . . . . . . . . . . 49
Hình 3.31 Giao diện quản lý Topic trên Control Center . . . . . . . . . . 50
Hình 3.32 Giao diện schema của Topic trên Control Center . . . . . . . . 50
Hình 4.1 Dữ liệu cần đồng bộ trên MariaDB . . . . . . . . . . . . . . . 51

Hình 4.2 Giao diện tab Connector . . . . . . . . . . . . . . . . . . . . . 52
Hình 4.3 Chọn Source Connector . . . . . . . . . . . . . . . . . . . . . 52
Hình 4.4 Cấu hình Source Connector . . . . . . . . . . . . . . . . . . . 53
Hình 4.5 Khởi chạy Source Connector . . . . . . . . . . . . . . . . . . . 53
Hình 4.6 Cấu hình Connector . . . . . . . . . . . . . . . . . . . . . . . . 54
Hình 4.7 Tổng quan Topic . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Hình 4.8 Dữ liệu trên topic . . . . . . . . . . . . . . . . . . . . . . . . . 56
Hình 4.9 Các trường của topic tương ứng với 12 trường trong bảng trên
MariaDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Hình 4.10 Tổng số row trên MariaDB . . . . . . . . . . . . . . . . . . . . 57
Hình 4.11 Tổng số message trên Topic bằng so với số bản ghi trên Mari-
aDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Hình 4.12 Tổng số row trên MariaDB sau khi cập nhật . . . . . . . . . . 57
vii
Hình 4.13 Tổng số message trên Topic tăng lên bằng so với số bản ghi
trên MariaDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Hình 4.14 Metric của Topic khi cập nhật bảng trên MariaDB . . . . . . . 58
Hình 4.15 Giao diện tab Connector . . . . . . . . . . . . . . . . . . . . . 59
Hình 4.16 Chọn Sink Connector . . . . . . . . . . . . . . . . . . . . . . . 59
Hình 4.17 Cấu hình Sink Connector . . . . . . . . . . . . . . . . . . . . . 60
Hình 4.18 Khởi chạy Sink Connector . . . . . . . . . . . . . . . . . . . . 60
Hình 4.19 Cấu hình Connector . . . . . . . . . . . . . . . . . . . . . . . . 61
Hình 4.20 Tổng số node trên Neo4j . . . . . . . . . . . . . . . . . . . . . 63
Hình 4.21 Tổng số node không ngừng tăng trong quá trình chạy Connector 63
Hình 4.22 Tổng số cạnh trên Neo4j . . . . . . . . . . . . . . . . . . . . . 64
Hình 4.23 Tổng số cạnh tăng lên trong quá trình chạy Connector . . . . . 64
Hình 4.24 Dữ liệu đỉnh User . . . . . . . . . . . . . . . . . . . . . . . . . 65
Hình 4.25 Dữ liệu đỉnh Product . . . . . . . . . . . . . . . . . . . . . . . 65
Hình 4.26 Dữ liệu đỉnh Category . . . . . . . . . . . . . . . . . . . . . . 66
Hình 4.27 Dữ liệu cạnh ACTION . . . . . . . . . . . . . . . . . . . . . . 66
Hình 4.28 Dữ liệu cạnh BELONG_TO . . . . . . . . . . . . . . . . . . . 67
Hình 5.1 Các hình thức bảo mật của Confluent . . . . . . . . . . . . . . 71

Hình 5.2 Cơ chế hoạt động của ACL trong Confluent . . . . . . . . . . 71
Hình 5.3 Các cơ chế xác thực của Confluent . . . . . . . . . . . . . . . 72
viii
DANH MỤC BẢNG BIỂU
Bảng 2.1 So sánh RDF và PG . . . . . . . . . . . . . . . . . . . . . . . . 7
Bảng 3.1 Mô tả chi tiết bảng ecommerce trong MariaDB . . . . . . . . 27

Bảng 3.2 Mô tả chi tiết bảng ecommerce trong MariaDB . . . . . . . . 28
ix
DANH MỤC TỪ VIẾT TẮT
Viết tắt Tên tiếng Anh Tên tiếng Việt

DB Database Cơ sở dữ liệu
RDBMS Relational Database Manage- Hệ quản trị cơ sở dữ liệu quan hệ
ment System
UC Use case Ca sử dụng
HTML HyperText Markup Language Ngôn ngữ đánh dấu siêu văn bản
CNTT Công nghệ thông tin
ĐATN Đồ án tốt nghiệp
OLTP Online Transaction Processing Xử lý giao dịch trực tuyến
OLAP Online Analytical Processing Xử lý phân tích trực tuyến
Web UI Web User Interface Giao diện người dùng trên nền
tảng web
UX User Experience Trải nghiệm người dùng
x
DANH MỤC THUẬT NGỮ
Thuật ngữ Ý nghĩa

RDBMS Cơ sở dữ liệu quan hệ
Graph Database Cơ sở dữ liệu đồ thị
Server Máy chủ
Node (Nút) Các nút là các đỉnh lưu trữ dữ liệu của đối tượng. Mỗi nút có
thể có số lượng và loại mối quan hệ không giới hạn.
Edge (Đỉnh) Các cạnh thể hiện mối quan hệ giữa các nút
Property (Thuộc tính) Mỗi nút có các thuộc tính để mô tả nó. Trong một số trường
hợp, các cạnh cũng có thuộc tính.
Native Graph Cơ sở dữ liệu đồ thị xử lý và lưu trữ dữ liệu dưới dạng graph
Service Dịch vụ
Database Cơ sở dữ liệu
Data Dữ liệu
Component Thành phần
xi
CHƯƠNG 1. GIỚI THIỆU ĐỀ TÀI ĐỒ ÁN
Chương này giới thiệu các vấn đề dẫn tới việc em lựa chọn đề tài, tổng quan về
hệ thống và nêu ra mục tiêu và phạm vi đề tài, định hướng giải pháp và bố cục của
đồ án.
1.1 Đặt vấn đề
Cơ sở dữ liệu đồ thị đang đóng một vai trò ngày càng quan trọng trong ngành
thương mại điện tử, cho phép các nhà bán lẻ hiểu rõ hơn và đem lại dịch vụ tốt hơn
cho khách hàng của họ thông qua các đề xuất mang tính cá nhân hóa cao. Bằng
cách tận dụng sức mạnh của cơ sở dữ liệu đồ thị, các doanh nghiệp thương mại điện
tử có thể đạt được lợi thế cạnh tranh trên thị trường trực tuyến đông đúc, mang lại
trải nghiệm mua sắm vượt trội giúp thu hút khách hàng quay trở lại nhiều hơn.
Tuy nhiên, việc phát triển cần phải gắn liền với những cái đã có, từ lâu cơ sở
dữ liệu quan hệ đã và đang chiếm một phần không hề nhỏ trong hệ thống cơ sở dữ
liệu, chính vì vậy cần có một hệ thống trung gian chịu trách nhiệm đồng bộ dữ liệu
truyền thống sang hệ thống cơ sở dữ liệu mới
Từ những nhu cầu thực tế và tiềm năng của việc phát triển một Hệ khuyến nghị
sử dụng Graph Database, en đã thực hiện đề tài “Một số mô hình khuyến nghị
sản phẩm cho người dùng trên trang Thương mại điện tử Shopee sử dụng Graph
Database”. Mục đích của đề tài là phát triển hệ thống có thể giúp đồng bộ dữ liệu
thời gian thực từ cơ sở dữ liệu quan hệ sang cơ sở dữ liệu đồ thị và trên cơ sở dữ
liệu đồ thị, xây dựng một số khuyến nghị sản phẩm dựa trên dữ liệu lịch sử thao tác
của người dùng.
1.2 Mục tiêu và phạm vi đề tài
Với những vấn đề đã trình bày trong mục 1.1, trong đồ án này, em đặt ra mục
tiêu trong ĐATN là cài đặt một cơ sở dữ liệu quan hệ, một cơ sở dữ liệu đồ thị, cài
đặt và tích hợp các component cần thiết trong nền tảng streaming dữ liệu; sau khi
cài đặt xong các thành phần, em sử dụng nền tảng streaming dữ liệu để đồng bộ
dữ liệu từ Cơ sở dữ liệu quan hệ sang Cơ sở dữ liệu Đồ thị. Khi dữ liệu đã được
đồng bộ sang Cơ sở dữ liệu Đồ thị, thực hiện xây dựng một số câu lệnh để gợi ý sản
phẩm cho người dùng dựa theo dữ liệu lịch sử thao tác của người dùng trên trang
thương mại điện tử. Dữ liệu trên sàn thương mại điện tử bao gồm nhiều sản phẩm
thuộc nhiều lĩnh vực khác nhau như Đồ điện tử,...
Phần cơ sở dữ liệu quan hệ, em sẽ sử dụng cơ sở dữ liệu miễn phí và phổ biến
là MariaDB để xây dụng một cơ sở dữ liệu đơn giản giúp lưu trữ lịch sử thao tác
1
CHƯƠNG 1. GIỚI THIỆU ĐỀ TÀI ĐỒ ÁN
người dùng trên sàn thương mại điện tử.

1.3 Định hướng giải pháp
Hệ thống bao gồm các thành phần:
Phần cơ sở dữ liệu quan hệ, em sẽ sử dụng cơ sở dữ liệu miễn phí và phổ biến
là MariaDB để xây dụng một cơ sở dữ liệu đơn giản giúp lưu trữ lịch sử thao tác
người dùng trên sàn thương mại điện tử.
Về phần cơ sở dữ liệu đồ thị, em sẽ sử dụng cơ sở dữ liệu Neo4j - là một cơ sở
dữ liệu đồ thị lâu đời, miễn phí, có hệ sinh thái đa dạng bao gồm nhiều Công cụ,
Ứng dụng, Thư viện có thể tích hợp một cách dễ dàng.
Với phần Nền tảng Streaming Dữ liệu, do thời gian thực hiện ĐATN còn hạn
chế, em lựa chọn sử dụng Confluent Platform - sản phẩm được xây dựng trên nền
tảng mã nguồn mở Apache Kafka, cung cấp khả năng đồng bộ dữ liệu một cách
liền mạch và tự động.
Về phần backend để xây dựng API cho Neo4j, em sử dụng PHP và OpenAPI
để xây dựng tập các API trả về cho người dùng tập các sản phẩm gợi ý cho người
dùng.
1.4 Bố cục đồ án
Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau.
Chương 2 em sẽ trình bày về các công nghệ và công cụ được sử dụng xuyên suốt
quá trình thực hiện đồ án.
Chương 3, em sẽ trình bày về cách cài đặt và tích hợp các thành phần trong hệ
thống.
Chương 4, em sẽ trình bày phân tích chi tiết về kết quả đạt được trong quá trình
thực hiện.
Chương 5, em sẽ đưa ra các đóng góp và giải pháp nổi bật mà em thấy ấn tượng
trong đồ án khi thực hiện.
Chương 6, em sẽ kết luận và hướng phát triển của hệ thống: trình bày về các kết
quả đạt được,chưa đạt được và các định hướng phát triển hệ thống trong tương lai.
2
CHƯƠNG 2. CÁC CÔNG NGHỆ SỬ DỤNG
Chương 3 em sẽ mô tả các công nghệ sẽ được sử dụng trong ĐATN này, một số
công nghệ sẽ được mô tả cách rõ cách thức hoạt động.
2.1 Cơ sở dữ liệu MariaDB
Giới thiệu
MariaDB là một nhánh do cộng đồng phát triển, được hỗ trợ về mặt thương mại
của hệ quản trị cơ sở dữ liệu quan hệ MySQL (RDBMS) nhằm duy trì phần mềm
nguồn mở và miễn phí theo Giấy phép Công cộng GNU (General Public License).
Nhà phát triển dự định nó sẽ là một sự thay thế cho MySQL và thường được coi là
DB đi kèm cho các bản phân phối Linux phổ biến như CentOS. API và các giao
thức được sử dụng trong MySQL cũng có trong MariaDB. MariaDB thường được
sử dụng cho những việc như quản lý giao dịch, thông tin khách hàng,...
Hình 2.1: Logo của hãng MariaDB
MariaDB có nhiều tính năng và lợi ích khác biệt với MySQL và RDBMS nguồn
mở khác, năm tính năng sau khiến MariaDB trở nên nổi bật.
• InnoDB: InnoDB là một công cụ lưu trữ (storage engine) được biết đến với
3
khả năng cân bằng giữa độ tin cậy và hiệu suất. Đây là công cụ lưu trữ mặc
định trong MySQL và là lựa chọn phổ biến để sử dụng với MariaDB. Nó cung
cấp các tính năng giao dịch tuân thủ ACID tiêu chuẩn và có hỗ trợ khóa ngoại
(foreign key). ACID là viết tắt của tính nguyên tử (atomicity), tính nhất quán
(consistency), sự cô lập (isolation) và duy trì (durability). Điều đó đảm bảo
rằng mỗi giao dịch trong MariaDB được coi là một đơn vị duy nhất. Nếu một
phần của giao dịch đó không hoàn thành thì toàn bộ giao dịch sẽ không thành
công và cơ sở dữ liệu không bị ảnh hưởng. Trong phạm vi ĐATN, InnoDB sẽ
được lựa chọn là Storage Engine của MariaDB.
• XtraDB: Từng là lựa chọn phổ biến hơn InnoDB, XtraDB được thiết kế như
một công cụ lưu trữ cho MariaDB. XtraDB là sự kết hợp tuân thủ tính ACID
của InnoDB và kiến trúc MVCC (Multiversion concurrency control). MVCC
nhằm mục đích giải quyết vấn đề bằng cách giữ nhiều bản sao của dữ liệu.
Bằng cách này, mỗi người dùng được kết nối với cơ sở dữ liệu sẽ thấy snapshot
của cơ sở dữ liệu tại một thời điểm cụ thể. Bất kỳ thay đổi nào do người thực
hiện sẽ không được người dùng cơ sở dữ liệu khác nhìn thấy cho đến khi các
thay đổi đó được hoàn thành. MVCC đảm bảo tính nhất quán của dữ liệu khi
triển trên các hệ phân tán. Tính năng XtraDB này đã có trong các phiên bản
trước 10.1. Kể từ phiên bản 10.2 của MariaDB, InnoDB đã trở thành công cụ
lưu trữ mặc định cho MariaDB.
• MyRocks / RocksDB: MyRocks là một phần mềm nguồn mở được phát triển
bởi nhóm kỹ sư cơ sở dữ liệu tại Facebook và hiện tại vẫn được duy trì. Được
coi là công cụ lưu trữ đang giai đoạn alpha, nó được tối ưu hóa để lưu trữ
nhanh, độ trễ thấp. Mục tiêu chính là giúp tiết kiệm dung lượng lưu trữ một
cách hiệu quả. Bằng cách tập trung vào hiệu suất, RocksDB giúp tiết kiệm
dung lượng ổ SSD, dung lượng lưu trữ thực tế được sử dụng và giảm lượng
IO để quản lý truy vấn. RocksDB được hỗ trợ chính thức trên CentOS 6.8 và
7.2.X.
• Galera Cluster: Cụm Galera là “Multi-Master Cluster” (nhiều các server database
đóng vai trò là Master có vai trò đọc và ghi, phân biệt với Slave - là server
database chỉ có chức năng đọc) dựa trên tính năng synchronous replication.
Mục đích chính là cung cấp tính sẵn sàng cao, hạn chế thời gian dừng dịch
vụ (downtime), ngăn ngừa mất dữ liệu và có thể mở rộng để phát triển. Syn-
chronous replication có nghĩa là server Slave không có độ trễ và không bị mất
dữ liệu nếu nút (server) gặp sự cố. Nó có khả năng đọc và ghi vào bất kỳ nút
nào vào bất kỳ lúc nào và xử lý đa luồng cho Slave để có hiệu suất tốt hơn.
4
Nó có một tính năng được gọi là Chế độ Hot Standby, nghĩa là không có thời
gian ngừng hoạt động trong quá trình failover giữa các node Master (quá trình
một node Master khi bị dừng dịch vụ, một node Slave sẽ được bầu và thay thế
node Master đó).
• Sequence Storage Engine: cho phép tạo các chuỗi số tăng dần hoặc giảm dần
so với giá trị bắt đầu, giá trị kết thúc và giá trị gia tăng nhất định. Điều này tạo
ra các bảng tạm thời ảo khi cần thiết. Không có cách nào để tạo bảng tuần tự
một cách rõ ràng và chúng không được ghi vào đĩa hoặc tạo tệp .frm.
Binary log (Binlog) Binlog là một tính năng của MariaDB, nó là bản ghi chứa
tất cả, ghi lại các thay đổi đối với cơ sở dữ liệu, kể cả dữ liệu và cấu trúc dữ liệu,
cũng như thời gian thực hiện mỗi câu lệnh. Nó bao gồm một tập hợp các tệp file
log lưu dưới dạng nhị phân và một chỉ mục (index).
Điều này có nghĩa là khi thực thi các câu lệnh như CREATE, ALTER, IN-
SERT, UPDATE và DELETE, các câu lệnh sẽ được ghi lại, nhưng các câu lệnh
không làm thay đổi đến dữ liệu, chẳng hạn như SELECT và SHOW, sẽ không
được binlog ghi lại.
Hình 2.2: Dữ liệu được ghi trong binlog sau khi sử dụng công cụ của MariaDB để đọc
Mục đích của binlog là cho phép sao chép, trong đó dữ liệu được gửi từ một hoặc
nhiều máy chủ đến một hoặc nhiều máy chủ Slave dựa trên nội dung của binary
log, cũng như hỗ trợ các hoạt động sao lưu. Máy chủ MariaDB sử dụng binary log
sẽ làm ảnh hưởng đôi chút tới hiệu năng của Database.
2.2 Cơ sở dữ liệu Neo4j
Giới thiệu
5
Neo4J là hệ quản trị cơ sở dữ liệu đồ thị được giới thiệu đầu tiên vào năm 2007
và công bố phiên bản 1.0 vào năm 2010. Neo4J là một trong những hệ quản trị cơ
sở dữ liệu đồ thị được sử dụng nhiều nhất trên thế giới hiện nay, trong suốt nhiều
năm, Neo4j luôn đứng đầu trong danh sách các Cơ sở dữ liệu Đồ thị phổ biến nhất.
Hình 2.3: Logo của Neo4j
Resource Description Framework (RDF) và Property Graph (LPG) Model

Một cách để phân loại các cơ sở dữ liệu đồ thị là xem xét các mô hình đồ thị được
sử dụng bởi các công nghệ khác nhau. Có 2 graph data model thường được biết đến
là Resource Description Framework (RDF) triple và property graph. Neo4j hiện
đang sử dụng data model Property Graph:
6
Bảng 2.1: So sánh RDF và PG
Title RDF PG
Concept Cốt lõi của RDF là khái niệm bộ Trong Property Graph, các đỉnh
ba, bao gồm ba phần tử đại diện được gọi là các node, có ID có
cho hai đỉnh được nối với nhau thể nhận dạng duy nhất và một
bằng một cạnh. Nó được gọi tập hợp các cặp key-value hoặc
là chủ subject-predicate-object. thuộc tính đặc trưng cho chúng.
Subject sẽ là một nguồn, hoặc Theo cùng một cách, các cạnh
một nút trong biểu đồ, predicate hoặc kết nối giữa các node cũng
sẽ đại diện cho một cạnh - một có ID. Điều quan trọng là chúng
mối quan hệ - và object sẽ là ta có thể xác định chúng một
một nút khác. Điều này có nghĩa cách duy nhất và chúng cũng có
là cả nút và cạnh đều không có một loại và một tập hợp các giá
cấu trúc bên trong, mỗi đỉnh hoặc trị chính của các cặp - hoặc các
cạnh được xác định bởi 1 URI, thuộc tính đặc trưng cho các kết
mỗi URI là 1 giá trị độc nhất. nối. Điểm khác biệt của PG so
với RDF là thay vì các cạnh hoặc
các node chỉ có các giá trị URI,
chúng có các cấu trúc bên trong
gồm các thuộc tính, điều này sẽ
giúp đồ thị được gọn gàng hơn,
không phải sinh thêm các node
cho mỗi thuộc tính.
Truy vấn liên Với đặc trưng về cấu trúc, do Việc thay thế các node và cạnh
kết giữa các số lượng các node lớn việc tìm bằng các thuộc tính sẽ giúp giảm
node kiếm mối quan hệ giữa 2 node là lượng lớn số lượng node.
vô cùng khó khăn: khi muốn tìm
kiếm 2 node có mối quan hệ với
nhau hay không thì cần phải quét
số lượng node và cạnh khổng lồ.
7
Các mối quan RDF không thể xác định cùng Để xác định các mối quan hệ lặp
hệ trùng lặp mối quan hệ. Không thể có các lại nhiều lần giữa 2 node, trong
kết nối cùng loại giữa cùng một PG, giữa 2 node sẽ có thêm các
cặp node vì điều đó sẽ đại diện cạnh để biểu diễn số lần mối
chính xác cho cùng một bộ ba và quan hệ đó được xảy ra. Ngoài
không có thông tin bổ sung. Điều ra nếu không muốn sinh thêm
này sẽ gây ra sự hạn chế ví dụ: các cạnh, có thể thêm thuộc tính
nếu node A với B có cùng mối count trên mối quan hệ đó, với
quan hệ C và mối quan hệ C giữa mỗi lần thay đổi số lượng mối
node A và B xuất hiện nhiều lần quan hệ chỉ cần cập nhật giá trị
thì ở RDF chỉ xác định được giữa thuộc tính count, việc này sẽ làm
A và B chỉ có duy nhất 1 liên kết giảm số lượng các cạnh của đồ
C do đặc tính mỗi định và cạnh thị.
chỉ được xác định bởi 1 URI duy
nhất, bên cạnh đó không có thuộc
tính nên sẽ không biểu diễn được
liên kết C được lặp lại 3 lần.
Hiệu suất - Gặp khó khăn với những tệp dữ - PG được tối ưu hóa cho hiệu
liệu có quy mô lớn do sự phức tạp suất và có thể xử lý các đồ thị có
của truy vấn và phân tích dữ liệu quy mô lớn.
được liên kết. - PG sử dụng các kỹ thuật in-
- RDF sử dụng kỹ thuật indexing dexing và caching để tăng tốc độ
để tăng tốc độ truy vấn và giảm truy vấn và giảm thời gian phản
thời gian phản hồi truy vấn. hồi truy vấn.
- RDF không được thiết kế cho - PG được thiết kế cho môi
môi trường high-concurrency và trường high-concurrency và có
có thể gặp khó khăn với nhiều thể xử lý nhiều truy vấn đồng
truy vấn đồng thời. thời.
8
Ưu điểm - Tiêu chuẩn hóa: tất cả các biểu - Đơn giản: Property graph được
đồ RDF đều sử dụng cùng một thiết lập và sử dụng đơn giản và
khung tiêu chuẩn và ngữ nghĩa nhanh chóng. Dễ dàng sử dụng
chính thức để lưu trữ và biểu diễn với hầu hết các người dùng.
dữ liệu cùng với một ngôn ngữ - Điều hướng dễ dàng: LPG dễ
truy vấn tiêu chuẩn. dàng duyệt qua mà không có giới
- Khả năng tương tác: RDF hạn hoặc ngôn ngữ truy vấn tiêu
Triple Store tuân theo tiêu chuẩn chuẩn.
được W3C hỗ trợ cho phép khả - Chi tiết: Các thuộc tính được
năng tương tác giữa các knowl- liên kết với các mối quan hệ
edge graph. Khả năng tương tác trong property graph cung cấp
này cho phép các biểu đồ dựa thêm nhiều thông tin chi tiết về
trên RDF tích hợp và trao đổi các thực thể dữ liệu và mối quan
thông tin với nhau. hệ của chúng mà không cần phải
- Khả năng mở rộng: đồ thị RDF tạo thêm các node bổ sung cho
cho phép người dùng thêm các từng chi tiết. Cho phép người
node và mối quan hệ mới hoặc dùng lưu bất kỳ thuộc tính nào
thậm chí các substructure mà trên các node và cạnh.
không yêu cầu xây dựng lại mô
hình.
Hạn chế - Độ phức tạp của tìm kiếm sâu - Thiếu khả năng tương tác: việc
(deep search): thực hiện tìm kiếm Thiếu tiêu chuẩn hóa trong PG
sâu trong các biểu đồ RDF lớn là khiến cho việc chia sẻ hoặc trao
một nhiệm vụ phức tạp vì nó yêu đổi dữ liệu trở nên khó khăn.
cầu duyệt qua mọi mối quan hệ.
- Tuân thủ nghiêm ngặt các tiêu
chuẩn: tất cả thông tin được lưu
trữ trong RDF phải ở dạng bộ ba,
nghĩa là chỉ có 2 đối tượng có thể
được liên kết tại một thời điểm,
điều này có thể hạn chế đối với
nhiều usecase.
Native Graph
Có hai yếu tố chính giúp phân biệt công nghệ native graph: xử lý và lưu trữ. Cơ
sở dữ liệu đồ thị native được thiết kế để vừa lưu trữ vừa xử lý dữ liệu dưới dạng
biểu đồ, đảm nhiệm việc biểu diễn các phần tử đồ thị giống với định dạng lưu trữ
9
và truy cập chúng một cách hiệu quả trong quá trình xử lý.
Cơ sở dữ liệu đồ thị non-native sử dụng một số mô hình khác để lưu trữ và xử
lý. Thông thường, chúng là các cơ sở dữ liệu đang cố gắng thêm một lớp API lên
trên một mô hình như NoSQL, RDBMS,... điều này có thể gây ảnh hưởng đến hiệu
suất của Graph Database.
Native Graph Processing để nói đến cách cơ sở dữ liệu đồ thị native xử lý các
hoạt động của cơ sở dữ liệu, bao gồm cả lưu trữ và truy vấn. Khả năng chính của cơ
sở dữ liệu đồ thị navtive là khả năng điều hướng nhanh chóng các liên kết trong dữ
liệu mà không cần phải tra cứu chỉ mục (index) hoặc các chiến lược liên kết khác.
Non-native Grap Processing thường cần phải sử dụng chỉ mục để tra cứu đến
phần tử tiếp theo trong chuỗi nhằm hoàn thành một giao dịch đọc hoặc ghi; điều
này có thể không nảy sinh vấn để với chỉ một hoặc hai mối quan hệ, nhưng trong
các trường hợp sử dụng graph database ngày nay với hàng trăm hoặc hàng nghìn
mối quan hệ, việc truy vấn sẽ gặp khó khăn. Độ phức tạp của việc tra cứu chỉ mục
thường là O(log(n)), trong khi đó để theo dõi con trỏ trực tiếp của mối quan hệ tới
nút mục tiêu chỉ mất O(1).
Graph Storage đề cập đến cấu trúc lưu trữ dữ liệu của cơ sở dữ liệu đồ thị.
Database được xây dựng để lưu trữ dữ liệu dưới dạng đồ thị được gọi là bộ lưu trữ
đồ thị native. Cơ sở dữ liệu đồ thị với bộ lưu trữ đồ thị native được tối ưu hóa cho
đồ thị, đảm bảo dữ liệu được lưu trữ hiệu quả bằng cách sử dụng bố cục lưu trữ
cũng như đặt các nút và mối quan hệ gần nhau. Cũng giống như quá trình xử lý, bộ
lưu trữ đồ thị không phải native không đáp ứng được nhu cầu về hiệu suất và quy
mô của các ứng dụng hiện đại do trong quá trình lưu trữ, database không lưu các
node và các mối quan hệ một cách rời rạc.
Neo4j là một Native Graph Database sử dụng index-free adjacency, mỗi nút
tham chiếu trực tiếp đến các nút liền kề của nó, nghĩa là việc truy cập các mối quan
hệ liên quan giữa các node chỉ đơn giản là tra cứu con trỏ. Điều này làm cho thời
gian xử lý biểu đồ native tỷ lệ thuận với lượng dữ liệu được xử lý, không tăng theo
cấp số nhân với số lượng mối quan hệ được duyệt qua và số bước nhảy. Nếu không
có index-free adjacency, một tập dữ liệu lớn sẽ không thể đáp ứng vì các truy vấn
ngày càng mất nhiều thời gian hơn khi tập dữ liệu phát triển. Mặt khác, các truy
vấn biểu đồ native thực hiện ở tốc độ không đổi dựa trên lượng dữ liệu duyệt qua
bất kể tổng kích thước dữ liệu ngày càng tăng.
Hình ảnh dưới đây là ví dụ về truy vấn trên native graph dữ liệu mạng xã hội mà
không cần sử dụng bất kỳ index nào để hỗ trợ:
10
Hình 2.4: Truy vấn trên Native Graph
Còn hình ảnh bên dưới minh họa một ví dụ về truy vấn trên non-native graph
chỉ tìm kiếm một cặp quan hệ trực tiếp (trong mối quan hệ nhiều-nhiều), khi muốn
tìm kiếm mối quan hệ, cần phải duyệt qua 2 index, việc này sẽ tiêu tốn rất nhiều tài
nguyên, đặc biệt khi giữa 2 node không có mối quan hệ trực tiếp:
Hình 2.5: Truy vấn trên Non-Native Graph
11
2.3 Confluent Platform

Giới thiệu
Confluent là nền tảng streaming dữ liệu cho phép bạn dễ dàng truy cập, lưu trữ
và quản lý dữ liệu dưới dạng các luồng dữ liệu liên tục và theo thời gian thực. Được
xây dựng bởi những người sáng tạo ban đầu của Apache Kafka, Confluent mở rộng
các tính năng của Kafka đảm bảo yêu cầu đối với doanh nghiệp đồng thời loại
bỏ gánh nặng quản lý hoặc giám sát Kafka (Confluent Control Center - công cụ
Web UI quản lý tập trung của Confluent). Confluent mở rộng khả năng của Kafka
bằng cách thêm vào một số tính năng như đảm bảo về bảo mật, tính năng Cluster
Linking (đồng bộ giữa 2 cụm Kafka), tính năng Tiered Storage (Lưu trữ dữ liệu
trên tủ Object Storage).
Hình 2.6: Confluent Platform Component
Cơ chế hoạt động

Cơ chế hoạt động của Confluent cũng như Apache Kafka dựa trên các dòng sự
kiện (event streaming), dòng sự kiện là phương pháp thu thập dữ liệu theo thời gian
thực từ các nguồn sự kiện như cơ sở dữ liệu, các cảm biến, thiết bị di động, dịch
vụ đám mây và ứng dụng phần mềm dưới dạng luồng sự kiện; lưu trữ các luồng sự
kiện này một cách lâu dài để truy xuất sau này; thao tác, xử lý và phản ứng với các
luồng sự kiện trong thời gian thực ; định tuyến các luồng sự kiện đến các hệ thống
đích khác nhau nếu cần.
Một số các usecase trong thực tế của dòng sự kiện:
12
• Xử lý thanh toán và giao dịch tài chính trong thời gian thực, chẳng hạn như
trên sàn giao dịch chứng khoán, ngân hàng và bảo hiểm.
• Để theo dõi và giám sát ô tô, xe tải, đội xe và lô hàng trong thời gian thực,
chẳng hạn như trong ngành hậu cần và ngành ô tô.
• Để liên tục thu thập và phân tích dữ liệu cảm biến từ các thiết bị IoT hoặc thiết
bị khác, chẳng hạn như trong các nhà máy.
• Để thu thập và phản hồi ngay lập tức các tương tác và đơn đặt hàng của khách
hàng, chẳng hạn như trong ngành bán lẻ, khách sạn và du lịch, các ứng dụng
di động.
• Để lưu trữ và cung cấp dữ liệu có sẵn do các bộ phận khác nhau của công ty
tạo ra.
Các thao tác xử lý các luồng sự kiện bao gồm:
• Publish (Ghi) và Subcribe (Đọc) các dòng sự kiện,
• Các luồng sự kiện được lưu trữ với tính chịu lỗi cao và lâu dài.
• Xử lý dữ liệu được sinh ra trong thời gian thực
Commit Log:
Hình 2.7: Log trên Kafka
• Một yếu tố trung tâm cho phép Kafka và xử lý luồng được gọi là "log"; trong
Kafka, nó còn được gọi là "Log Commit".
• Log là một cấu trúc dữ liệu giống như một stack các phần tử. Các phần tử mới
luôn được thêm vào cuối ngăn xếp và sau khi được ghi, chúng sẽ không bao
giờ bị thay đổi.
• Các phần tử mới thêm vào log được sắp xếp theo thứ tự thời gian. Phần tử đầu
13
tiên được thêm vào ngăn xếp cũ hơn phần tử thứ hai, phần tử này cũ hơn phần
tử thứ ba.
• Nhiều hệ thống đích có thể sử dụng log một cách độc lập, mỗi hệ thống có thể
đọc dữ liệu từ các vị trí khác nhau cùng một lúc.
Hình 2.8: Nhiều hệ thống có thể đọc cùng một dữ liệu
Cơ chế Replication của Log:
Hình 2.9: Cơ chế replication
• Để đảm bảo tính sẵn sàng cao, Kafka giữ nhiều hơn một bản sao của log.
• Một bản sao log sẽ được bầu làm leader, các bản sao còn lại được gọi là
14
follower.
• Leader sẽ chịu trách nhiệm ghi và giữ bản sao chính của log. Các follower đọc
dữ liệu log từ leader và cập nhật bản sao cục bộ của mình.
• Nhiều hệ thống đích có thể sử dụng log một cách độc lập, mỗi hệ thống có thể
đọc dữ liệu từ các vị trí khác nhau cùng một lúc.
Các khái niệm Topic, Partition và Segment:
Hình 2.10: Cách phân bổ của Topic, Partition và Segment
• Topic: Một Topic là đơn vị logic của Kafka, đại diện cho tất cả các message
(đơn vị lưu trữ nhỏ nhất trong Kafka). Ví dụ topic "Mariadb_data" bao gồm
các message, mỗi message là một bản ghi trong một bảng nào đó của Cơ sở
dữ liệu MariaDB.
• Partition: Để song song hoá việc đọc, ghi dữ liệu vào topic và tăng thông
lượng, Kafka có thể chia một Topic thành nhiều Partition. Các message của
Topic sau đó sẽ được phân bổ trên nhiều Partition. Thuật toán mặc định được
sử dụng để quyết định một message sẽ nằm trong Partiton của Topic nào là sử
dụng hàm băm key của message. Một Partition nằm hoàn toàn trên một Kafka
Broker (tức là toàn bộ message của một Partition sẽ nằm cùng trên một server
Kafka Broker).
15
Hình 2.11: Dữ liệu được lưu trên broker - các folder có định dạng Topic-Parition
• Segment: Các server Kafka Broker lưu trữ các message trong một tệp vật
lý. Các Broker sử dụng chiến lược "rolling-file". Các file lưu trữ được gọi là
segment. Khi segment đã đầy (hoặc thời gian của mỗi segment đã hết hạn),
segment tiếp theo sẽ được Broker sinh ra và các message tiếp theo sẽ được lưu
trữ tiếp tục trên segment mới.
Hình 2.12: Các file segment trong một Topic
Các Kafka Client:
16
Hình 2.13: Các Kafka Client
• Producer: Các ứng dụng ghi dữ liệu vào một hoặc nhiều topic.
• Consumer và Consumer Group: Các Consumer là các ứng dụng dùng để
đọc dữ liệu từ Topic, các Consumer sẽ được tổ chức lại thành các Consumer
Group. Các Consumer trong Consumer Group phối hợp để đọc dữ liệu một
cách song song.
• Nói cách khác, Kafka là một hệ thống pub-sub message với các Producer có
nhiệm vụ bắt các event, các event được gửi và lưu trữ trên các máy chủ Broker.
Các Consumer subcribe các topic và khai thác các dữ liệu. Việc Produce và
Consume được thực hiện liên tục, liền mạch và realtime.
Confluent Kafka Broker
Confluent Kafka Broker là các máy chủ, container chạy tiến trình của Kafka.
Các Broker có vai trò là lưu trữ và xử lý các topic, partition, message. Nó là thành
phần cốt lõi của cụm Confluent Platform. Để đảm bảo tránh single point failure,
các Broker thường được cài đặt thành Cluster (cụm) gồm nhiều Broker khác nhau.
Số lượng các broker thường là số lẻ và số lượng lớn hay nhỏ tuỳ thuộc vào khối
lượng công việc cần xử lý.
Để giải quyết vấn đề single point failure, các Partition sẽ có các bản replication
nằm trên các Broker khác nhau, khi đó nếu một server Broker down, các bản sao
Partition sẵn sàng để thay thế.
Các Parition Replication sẽ có một Leader và các Follower, các ứng dụng muốn
đọc hay ghi dữ liệu của Partition sẽ thực hiện trên Partition Leader. Các Parition
Follower sẽ đọc dữ liệu từ Partition Leader và ghi vào bản ghi cục bộ của mình.
17
Khi một Partition Leader bị lỗi, một Parition Follower sẽ được bầu làm Leader, các
Client đọc và ghi sẽ chuyển sang làm việc với Partition Leader mới.
Hình 2.14: Dữ liệu được đọc/ghi trên Partition Leader
Với topic có nhiều partition có các bản replication, mỗi partition sẽ có leader
partition riêng. Partition Leader phải phục vụ lưu lượng truy cập lớn hơn rất nhiều
so với các Follower vì nó phải xử lý tất cả các yêu cầu produce và consume). Để
cân bằng tải, Kafka sẽ chia các Leader trên khắp các Broker.
Hình 2.15: Các Partition Leader được phân bổ trên các Broker khác nhau
Cả Producer và Consumer đều cần phải biết Broker nào đang nắm giữ Partition
Leader cần, chính vì vậy cần có một tiến trình có nhiệm vụ lưu trữ và cung cấp
18
metadata thông tin về các Broker và Partition, Partition Leader nằm trên Broker
nào. Khi Client khởi chạy, Client không biết Broker nào chứa Partition Leader nào
nên nó đưa ra yêu cầu để lấy metadata với Broker bất kỳ. Chín vì vậy metadata
thông tin các Partition được cache trên toàn bộ các Brokerm bất kỳ Broker nào
cũng có thể phản hồi yêu cầu lấy metadata. Sau khi nhận được thông tin metadata,
Client sẽ biết và giao tiếp với Broker thích hợp. Một Broker trong Cluster sẽ được
bầu làm Controller, có nhiệm vụ duy trì và gửi thông tin cập nhật metadata đến các
Broker còn lại, khi có một Partition Leader bị lỗi, Controller có nhiệm vụ bầu một
Partition khác lên làm Partition Leader.
Confluent ZooKeeper
Confluent ZooKeeper là tiến trình gắn liền với Confluent Kafka Broker, quản lý
chung tất cả các thông tin. ZooKeeper lưu trữ tất cả các thông tin về Broker, Topic,
Partition, Partition Leader,... Đối với một hệ thống phân tán, cần có tiến trình điều
phối các task đến các thành phần, ZooKeeper được thiết kế để làm công việc điều
phối này.
Hình 2.16: ZooKeeper
ZooKeeper có một số chức năng chính sau:

• Bầu Controller: Controller có nhiệm vụ bầu một Partition lên làm Partition
Leader khi một Partition Leader không thể sử dụng. Nhưng khi Controller
down, ZooKeeper sẽ có trách nhiệm bầu một Broker khác lên làm Controller.
• Quản lý Metadata: Zookeeper cũng giữ thông tin về Cluster.
• Cấu hình Topic: ZooKeeper duy trì thông tin cấu hình của toàn bộ các Topic,
bao gồm tất cả các Topic hiện tại, số Partition của mỗi Topic, vị trí của các
bản sao Partition, Leader Partition, các cấu hình của Topic,...
• Access Control List (ACL): ZooKeeper cũng duy trì ACL cho tất cả các Topic.
19
Đó là thông tin user nào được đọc/ghi tới topic nào

• Quotas: ZooKeeper truy cập lượng dữ liệu mà mỗi client được phép đọc/ghi.
Để tránh single-point failure, Zookeeper cũng được triển khai thành cluster số
lượng node là số lẻ là 3, 5 hoặc 7 để có dễ dàng thực hiện các công việc bầu chọn.
Confluent Schema Registry Serializtion:
Kafka lưu trữ dữ liệu theo các byte array. Điều đó có nghĩa là Producer phải
chuyển đổi dữ liệu từ định dạng gốc thành byte array trước khi gửi tới Kafka. Quá
trình chuyển đổi này được gọi là serialization. Ngược lại, dữ liệu Consumer đọc từ
Kafka có dạng byte array phải được deserialized để có thể đọc được.
Hình 2.17: Serialization
Schema Registry cung cấp một kho lưu trữ tập trung để quản lý và xác thực các
schema cho dữ liệu message của topic để serialization và deserialization dữ liệu.
Producer và Consumer tương tác với Kafka Topic có thể sử schema để đảm bảo
tính nhất quán và tương thích của dữ liệu kể cả khi schema được thay đổi. Schema
Registry là thành phần quan trọng để quản trị dữ liệu, giúp đảm bảo chất lượng dữ
liệu, tuân thủ các tiêu chuẩn, khả năng hiển thị dữ liệu, khả năng kiểm tra.
20
Hình 2.18: Schema Registry
Confluent Kafka Connect

Kafka Connect là một công cụ streaming dữ liệu có quy mô và độ tin cậy cao
giữa Apache Kafka và các hệ thống dữ liệu khác. Việc xác định các connector giúp
dễ dàng tạo các ứng dụng dụng để Produce/Consume lượng lớn dữ liệu của Kafka.
Kafka Connect có thể thu thập dữ liệu từ cơ sở dữ liệu hoặc thu thập số liệu từ tất
cả máy chủ ứng dụng vào các topic Kafka, giúp dữ liệu có sẵn để xử lý streaming
với độ trễ thấp. Có thể sử dụng Kafka Connect để tích hợp dữ liệu từ nhiều Cơ sở
dữ liệu khác nhau với số lượng Connector đa dạng.
Hình 2.19: Kafka Connect
Các khái niệm trong Kafka Connect:

• Connector: Khái niệm cơ sở của Kafka Connect, có nhiệm vụ điều phối các
tác vụ để xử lý luồng dữ liệu, có thể hiểu là một ứng dụng để đọc hoặc ghi dữ
21
liệu của Kafka.

• Task: Các luồng xử lý của Connector để đọc/ghi dữ liệu Kafka.
• Worker: Các tiến trình đang thực thi các Connector và Task
• Converter: Mã dùng để dịch dữ liệu giữa Kafka Connect và hệ thống gửi hoặc
nhận dữ liệu (định dạng dữ liệu).
• Transform: Biến đổi logic đơn giản các message theo nhu cầu của người dùng.
• Dead Letter Queue: Lưu trữ các message bị lỗi để tiện cho việc cô lập và xử
lý lỗi.
• Source Connector: Là connector thu thập dữ liệu từ các hệ thống bên ngoài để
ghi vào hệ thống Kafka.
• Sink Connector: Là connector lấy dữ liệu từ các topic của hệ thống Kafka để
truyền tới các Hệ thống khác.
Debezium MySQL Source Connector:
• Debezium MySQL connector là một Connector miễn phí được phát triển bởi
Debezium, cho phép kết nối tới các server MySQL, đọc binlog, tạo các các
event thay đổi cho từng row với các thao tác INSERT, UPDATE, và DELETE
trên database, và đẩy các event đó vào trong Kafka topic. Khi một bảng trên
MySQL hoặc MariaDB được cập nhật, các thay đổi sẽ tự động tạo thành các
message trên trên Kafka Topic.
Hình 2.20: Debezium MySQL Connector
Neo4j Sink Connector:

• Neo4j Sink Connector được phát triển bởi Neo4j, cho phép streaming dữ liệu
từ hệ thống Kafka tới Database Neo4j, dữ liệu được ánh xạ thành các node,
22
edge trong Neo4j bằng các câu lệnh được viết bằng Cypher (Ngôn ngữ truy
vấn dữ liệu của Neo4j).
23
CHƯƠNG 3. CÀI ĐẶT
Ở chương 3, em sẽ mô tả kiến trúc tích hợp các công nghệ và cách cài đặt các
component.
3.1 Thiết kế kiến trúc
3.1.1 Sơ đồ Logic hệ thống
Sơ đồ logic hệ thống thể hiện tầng logic của hệ thống, các vật thể thể hiện các
thành phần service mang chức năng riêng.
Hình 3.1: Sơ đồ Logic hệ thống
Hệ thống bao gồm các thành phần:

• MariaDB Database: Cơ sở dữ liệu quan hệ, có nhiệm vụ xử lý và lưu trữ dữ
liệu giao dịch.
• Confluent Kafka Broker: là thành phần chính của Confluent Platform, có
nhiệm vụ lưu trữ các message của các topic. Dữ liệu từ các topic có thể publish
hoặc subcribe giữa Confluent Platform sang các hệ thống khác là MariaDB
và Neo4j.
• Confluent ZooKeeper: ZooKeeper được sử dụng để quản lý và điều phối Con-
fluent Kafka Broker. ZooKeeper chủ yếu được sử dụng để thông báo cho pro-
ducer và consumer về tính sẵn sàng của bất kỳ Broker nào trong hệ thống
Confluent Kafka hoặc các Broker lỗi trong hệ thống cụm Confluent Kafka.
Từ các thông báo của Zookeeper về hiện trạng của các Broker, Producer hoặc
Consumer sẽ đưa ra quyết định và bắt đầu thực hiện các tác vụ tương ứng.
24
• Confluent ZooKeeper: ZooKeeper được sử dụng để quản lý và điều phối Con-

fluent Kafka Broker. ZooKeeper chủ yếu được sử dụng để thông báo cho pro-
ducer và consumer về tính sẵn sàng của bất kỳ Broker nào trong hệ thống
Confluent Kafka hoặc các Broker lỗi trong hệ thống cụm Confluent Kafka.
Từ các thông báo của Zookeeper về hiện trạng của các Broker, Producer hoặc
Consumer sẽ đưa ra quyết định và bắt đầu thực hiện các tác vụ tương ứng.
• Confluent Schema Registry: tiến trình cung cấp cơ sở dữ liệu cho các schema
được sử dụng trong cụm Confluent Kafka và xử lý việc phân phối và đồng bộ
hóa các schema cho các Producer và các Consumer bằng cách lưu trữ một bản
sao của schema trong bộ nhớ đệm cục bộ.
• Confluent Kafka Connect: là framework để streaming dữ liệu từ giữa hệ thống
Confluent Kafka với các hệ thống MariaDB và Neo4j.
• Confluent Control Center: là công cụ WebUI, giúp quản lý và giám sát Con-
fluent Platform, cung cấp giao diện người dùng cho phép theo dõi hiện trạng
Cluster, quản lý các topic, message, connector, pipeline streaming, ...
Cách thức hoạt động:
• Cơ sở dữ liệu MariaDB là hệ thống OLAP có nhiệm vụ lưu trữ lịch sử các thao
tác người dùng trên sàn thương mại điện tử.
• Dữ liệu từ MariaDB sẽ được streaming một cách tự động thành Topic trên
Confluent Broker thông qua MySQL CDC (Change Data Capture) Connector
- Debezium MySQL Connector.
• Dữ liệu lưu dưới Confluent Kafka dưới dạng Avro, Schema Registry sẽ có
nhiệm vụ tạo tự động và lưu trữ schema của Topic phục vụ cho các Consumer
có thể deserialization dữ liệu của Topic.
• Confluent ZooKeeper sẽ đảm bảo quản lý dữ liệu Metadata và điều phối các
Broker để cụm Kafka Cluster hoạt động bình thường.
• Dữ liệu từ Topic sẽ được đẩy vào Neo4j thông qua Kafka Connect (Neo4j Sink
Connector)
• Việc tạo Connector cũng như quản lý các Topic sẽ được thực hiện thông giao
giao diện web Confluent Control Center.
3.1.2 Mô hình server
Mô hình server thể hiện các component được cài đặt và phân bổ trên các server
khác nhau.
25
Hình 3.2: Sơ đồ server Hệ thống
3.1.3 Thiết kế Cơ sở dữ liệu
Hình 3.3: Thiết kế cơ sở dữ liệu MariaDB
26
Chi tiết cơ sở dữ liệu trong MariaDB trong được trình bày trong bảng sau:
Tên trường Kiểu dữ liệu Ý nghĩa

id int id sự kiện
date date ngày diễn ra sự kiện
weekday int ngày diễn ra sự kiện ứng với ngày
trong tuần
time varchar thời gian diễn ra sự kiện
event_type varchar thao tác người dùng
product_id varchar id sản phẩm
category_id varchar id loại sản phẩm
main_category varchar loại sản phẩm chính
sub_category varchar loại sản phẩm phụ
brand varchar nhãn hàng
price float giá sản phẩm
user_id varchar id người dùng
user_session varchar phiên người dùng
Bảng 3.1: Mô tả chi tiết bảng ecommerce trong MariaDB
Hình 3.4: Thiết kế cơ sở dữ liệu Neo4j
Chi tiết cơ sở dữ liệu trong Neo4j trong được trình bày trong bảng sau:
27
Tên Đỉnh/Cạnh Ý nghĩa

User Đỉnh Chứa thông tin id của người dùng
Product Đỉnh Chứa thông tin về sản phẩm mà người
dùng tương tác
Category Đỉnh Thông tin phân loại mặt hàng
Sub_Category Đỉnh Thông tin thêm về loại mặt hàng
ACTION Cạnh Thao tác người dùng
BELONG_TO Cạnh Sản phẩm thuộc loại mặt hàng nào
SUB_BELONG Cạnh Sub_Category thuộc Category nào
Bảng 3.2: Mô tả chi tiết bảng ecommerce trong MariaDB
28
3.2 Cài đặt

3.2.1 Cài đặt MariaDB
Cài đặt MariaDB Server
• Bước 1: Tạo file repoitory
$ s u d o echo " [ m a r i a d b ]
name = MariaDB
b a s e u r l = h t t p : / / yum . m a r i a d b . o r g / 1 0 . 9 / r h e l 7 −amd64
gpgkey = h t t p s : / / yum . m a r i a d b . o r g /RPM−GPG−KEY−MariaDB
g p g c h e c k =1 " > / e t c / yum . r e p o s . d / MariaDB . r e p o
$ s u d o yum c l e a n a l l
• Bước 2: Cài đặt MariaDB

$ s u d o yum i n s t a l l MariaDB − s e r v e r MariaDB − c l i e n t −y
• Bước 3: Thực hiện cấu hình

$ sudo mkdir −p / data / data
$ sudo chown −R mysql . / d a t a / d a t a
$ sudo mkdir −p / data / log
$ sudo chown −R mysql . / d a t a / l o g
$ sudo mkdir −p / data / log / binlog
$ s u d o chown −R mysql . / d a t a / b i n l o g
$ s u d o v i / e t c / my . c n f . d / s e r v e r . c n f
Listing 3.1: File /etc/my.cnf.d/server.cnf

1 [client]
2 socket = /var/lib/mysql/mysql.sock
3
4 [mysqld]
5 skip-networking=0
6 # System variables
7 session_track_system_variables=last_gtid,
autocommit,character_set_client,
character_set_connection,character_set_results,
time_zone
8 port=3306
9 max_connections = 500
29
10 bind-address=0.0.0.0
11 server_id=1
12 skip-external-locking
13 lower_case_table_names = 1
14 autocommit=1
15 interactive_timeout = 3600
16 wait_timeout = 3600
17 max_statement_time=300
18 symbolic-links=0
19
20 # Log and Data Location

21 datadir = /data/data
22 log-error = /data/log/mariadb-error.log
23 slow_query_log = ON
24 slow_query_log_file=/data/log/mariadb-slow.log
25 expire_logs_days=7
26
27 # Binlog Configuration
28 log_bin = mariadb-bin
29 log_bin_index = /data/log/binlog/mariadb-bin.index
30 gtid_strict_mode = 1
31 binlog_format = ROW
32 binlog_row_image = FULL
33 log_slave_updates=1
34 binlog-annotate-row-events=OFF
35 log-bin=/data/log/mariadb-binlog
36 binlog_ignore_db=testDB
• Bước 4: Khởi động MariaDB

$ sudo s y s t e m c t l s t a r t mariadb
$ sudo s y s t e m c t l s t a t u s mariadb
Hình 3.5: Trạng thái MariaDB đang hoạt động
30
• Bước 5: Kiểm tra binlog đã hoạt động hay chưa

Dùng MariaDB Client kết nối tới Database MariaDB
$ mariadb
1 SELECT variable_value as "BINARY LOGGING STATUS

2 (log-bin) ::" FROM information_schema.global_variables
3 WHERE variable_name=’log_bin’;
Hình 3.6: Binlog đã được bật thành công
31
3.2.2 Cài đặt Neo4J

Cài đặt Neo4j
• Bước 1: Cài đặt Java phiên bản mới
$ s u d o yum i n s t a l l h t t p s : / / d i s t . n e o 4 j . o r g / n e o 4 j −
j a v a 1 7 − a d a p t e r . n o a r c h . rpm
• Bước 2: Tạo yum repository
$ s u d o rpm −− i m p o r t h t t p s : / / d e b i a n . n e o 4 j . com /
n e o t e c h n o l o g y . gpg . key
$ s u d o c a t << EOF > / e t c / yum . r e p o s . d / n e o 4 j . r e p o
[ neo4j ]
name= Neo4j RPM R e p o s i t o r y
b a s e u r l = h t t p s : / / yum . n e o 4 j . com / s t a b l e / 5
e n a b l e d =1
g p g c h e c k =1
EOF
$ s u d o yum c l e a n a l l
• Bước 3: Cài đặt Neo4j
$ s u d o yum i n s t a l l n e o 4 j − 5 . 1 5 . 0
• Bước 4: Cấu hình cho Neo4j
$ sudo m k d i r −p / d a t a / n e o 4 j / d a t a
$ sudo chown −R n e o 4 j . / d a t a / n e o 4 j / d a t a
$ sudo m k d i r −p / d a t a / n e o 4 j / l o g
$ sudo chown −R n e o 4 j . / d a t a / n e o 4 j / l o g
$ sudo vi / etc / neo4j / neo4j . conf
Listing 3.2: File cấu hình /etc/neo4j/neo4j.conf

1 # Server Config
2 server.directories.data=/data/neo4j/data
3 server.directories.plugins=/var/lib/neo4j/plugins
4 server.directories.logs=/data/neo4j/log
5 server.directories.lib=/usr/share/neo4j/lib
6 server.logs.config=/etc/neo4j/server-logs.xml
7 server.logs.user.config=/etc/neo4j/user-logs.xml
32
8 server.default_listen_address=0.0.0.0
9 server.bolt.listen_address=:7687
10 server.bolt.advertised_address=:7687
11 server.https.enabled=false
12 server.windows_service_name=neo4j
13
14 # Graph Data Science enable

15 dbms.security.procedures.unrestricted=gds.*
16 dbms.security.procedures.allowlist=gds.*
17
18 # Allow internal access

19 server.jvm.additional=--add-opens=java.base/java.
nio=ALL-UNNAMED
20 server.jvm.additional=--add-opens=java.base/java.io
=ALL-UNNAMED
21 server.jvm.additional=--add-opens=java.base/sun.nio
.ch=ALL-UNNAMED
22
23 # Increase the default flight recorder stack

sampling depth from 64 to 256, to avoid
truncating frames when profiling.
24 server.jvm.additional=-XX:FlightRecorderOptions=
stackdepth=256
25
26 # Allow profilers to sample between safepoints.

Without this, sampling profilers may produce
less accurate results.
27 server.jvm.additional=-XX:+
UnlockDiagnosticVMOptions
28 server.jvm.additional=-XX:+DebugNonSafepoints
• Bước 4: Khởi động Neo4j
$ s u d o yum s t a r t n e o 4 j
$ s u d o yum s t a t u s n e o 4 j
33
Hình 3.7: Service Neo4j đang hoạt động
Hình 3.8: Cypher Shell của Neo4J khởi chạy thành công
Hình 3.9: Giao diện web Neo4j sau khi khởi động
34
3.2.3 Cài đặt Confluent Platform

Workflow cài đặt Confluent Platform
• Cài đặt packages rpm Confluent trên toàn bộ server cài Confluent
• Cấu hình Confluent Zookeeper
• Khởi động Confluent Zookeeper
• Cấu hình Confluent Server (Broker)
• Khởi động Confluent Server (Broker)
• Cấu hình Confluent Schema Registry
• Khởi động Confluent Schema Registry
• Cấu hình Confluent Kafka Connect
• Khởi động Confluent Kafka Connect
• Cấu hình Confluent Control Center
• Khởi động Confluent Control Center
Cài đặt các gới cài đặt Confluent Platform trên toàn bộ server cài Confluent
Link để tải các bộ cài đặt của Confluent: https://packages.confluent.io/rpm/7.5
Sau khi tải về, kiểm tra gói cài đặt phải bao gồm 21 gói rpm sau:
Listing 3.3: Các gói cài đặt của Confluent

1 confluent-ce-kafka-http-server-7.5.0-1.noarch.rpm
2 confluent-cli-7.5.0-1.x86_64.rpm
3 confluent-cli-debuginfo-7.5.0-1.x86_64.rpm
4 confluent-common-7.5.0-1.noarch.rpm
5 confluent-control-center-7.5.0-1.noarch.rpm
6 confluent-hub-client-7.5.0-1.noarch.rpm
7 confluent-kafka-connect-replicator-7.5.0-1.noarch.rpm
8 confluent-kafka-mqtt-7.5.0-1.noarch.rpm
9 confluent-kafka-rest-7.5.0-1.noarch.rpm
10 confluent-ksqldb-7.5.0-1.noarch.rpm
11 confluent-metadata-service-7.5.0-1.noarch.rpm
12 confluent-platform-7.5.0-1.noarch.rpm
13 confluent-rebalancer-7.5.0-1.noarch.rpm
14 confluent-rest-utils-7.5.0-1.noarch.rpm
15 confluent-schema-registry-7.5.0-1.noarch.rpm
35
16 confluent-schema-registry-plugins-7.5.0-1.noarch.rpm
17 confluent-security-7.5.0-1.noarch.rpm
18 confluent-server-7.5.0-1.noarch.rpm
19 confluent-server-rest-7.5.0-1.noarch.rpm
20 confluent-telemetry-7.5.0-1.noarch.rpm
21 confluent-control-center-fe-7.5.0-1.noarch.rpm
Tạo thư mục lưu trữ và chuyển tất cả các gói cài đặt trên vào thư mục đó:
$ m k d i r −p / d a t a / s o f t w a r e / c o n f l u e n t
Thực hiện cài đặt:

$ rpm − i v h / d a t a / s o f t w a r e / c o n f l u e n t / * . rpm
Cấu hình Confluent ZooKeeper

Khai báo biến môi trường để tiến trình xác định được các thư mục chứa cấu hình
và thư mục để chứa dữ liệu:
$ ZOOKEEPER_ROOT_DIR= / d a t a / a p p s / z o o k e e p e r
$ ZOOKEEPER_ROOT_CONFIG_DIR = / e t c / k a f k a
$ BASE_DIR = / b i n
Chuẩn bị các thư mục lưu dữ liệu và log cho ZooKeeper, thực hiện thay đổi
quyền cho user cp-kafka (user chạy tiến trình ZooKeeper) với những thư mục này:
$ m k d i r −p $ZOOKEEPER_ROOT_DIR / d a t a
$ m k d i r −p $ZOOKEEPER_ROOT_DIR / l o g
$ chown −R cp − k a f k a : $ZOOKEEPER_ROOT_DIR
Hình 3.10: Thư mục đã được trao quyền thành công
Tạo file myid trong phân vùng chứa dữ liệu của Zookeeper để ZooKeeper xác
định được id của mình trong cụm, trong file chứa id của ZooKeeper, có 3 server
ZooKeeper, id của các server sẽ lần lượt là 1, 2, 3. Câu lệnh dưới đây dùng để ghi
giá trị id=1 với node ZooKeeper 1.
$ echo 1 > $ZOOKEEPER_ROOT_DIR / d a t a / myid
36
Cấu hình Log4j cho ZooKeeper để ghi mọi hoạt động của ZooKeeper trong thư
mục log, giúp thuận tiện hơn cho việc kiểm tra và xử lý lỗi:
$ echo " l o g 4 j . r o o t L o g g e r =INFO , z k A p p e n d e r
l o g 4 j . appender . zkAppender= org . apache . l o g 4 j .
DailyRollingFileAppender
l o g 4 j . a p p e n d e r . z k A p p e n d e r . D a t e P a t t e r n = ’ . ’ yyyy −MM−dd −HH
l o g 4 j . a p p e n d e r . z k A p p e n d e r . F i l e = "$ZOOKEEPER_ROOT_DIR" /
logs / zookeeper . log
l o g 4 j . appender . zkAppender . l a y o u t = org . apache . l o g 4 j .
PatternLayout
l o g 4 j . a p p e n d e r . z k A p p e n d e r . l a y o u t . C o n v e r s i o n P a t t e r n =[%d
] %p %m (%c )%n " > $ZOOKEEPR_CONFIG_ROOT_DIR /
zookeeper − l o g 4 j . p r o p e r t i e s
Chỉnh sửa tham số KAFKA_LOG4J_OPTS trong file kafka-run-class (File dùng

để khởi chạy của Broker và ZooKeeper) để khi chạy, tiến trình ZooKeeper trỏ tới
file config log4j vừa tạo.
$ s e d − i ’ s | KAFKA_LOG4J_OPTS = . * | KAFKA_LOG4J_OPTS=" −
D l o g 4 j . c o n f i g u r a t i o n = f i l e : ’$ZOOKEEPER_ROOT_DIR ’ /
l o g s / z o o k e e p e r − l o g 4 j . p r o p e r t i e s " | ’ / b i n / k a f k a − run −
class
$ c a t / b i n / k a f k a − run − c l a s s | g r e p KAFKA_LOG4J_OPTS
Hình 3.11: Cấu hình thư mục Log đã được thay đổi
Cấu hình file config của ZooKeeper

$ v i $ZOOKEEPER_ROOT_CONFIG_DIR / z o o k e e p e r . p r o p e r t i e s
Listing 3.4: File cấu hình của ZooKeeper

1 # Data Location
2 dataDir=/data/apps/zookeeper/data
3
4 # System Configs
5 clientPort=2181
37
6 maxClientCnxns=0
7 admin.enableServer=false
8 initLimit=5
9 syncLimit=2
10 autopurge.snapRetainCount=3
11 autopurge.purgeInterval=24
12
13 # ZooKeeper Servers
14 server.1=10.10.12.61:2888:3888
15 server.2=10.10.12.62:2888:3888
16 server.3=10.10.12.63:2888:3888
Khởi động Confluent ZooKeeper

Trên 3 server ZooKeeper, thực hiện chạy 2 câu lệnh sau để khởi chạy và kiểm
tra service đã lên chưa:
$ systemctl s t a r t confluent −zookeeper

$ systemctl s t a t u s confluent −zookeeper
Hình 3.12: Service ZooKeeper đã khởi động thành công
Cấu hình Confluent Server (Broker)

$ BROKER_ROOT_DIR= / d a t a / a p p s / k a f k a
$ BROKER_ROOT_CONFIG_DIR= / e t c / k a f k a
Chuẩn bị các thư mục lưu dữ liệu và log cho Broker, thực hiện thay đổi quyền
cho user cp-kafka (user chạy tiến trình Broker) với những thư mục này:
$ m k d i r −p $BROKER_ROOT_DIR / d a t a
$ m k d i r −p $BROKER_ROOT_DIR / l o g
$ chown −R cp − k a f k a : $BROKER_ROOT_DIR
38
Cấu hình Log4j cho Broker để ghi mọi hoạt động của Broker trong thư mục log,
giúp thuận tiện hơn cho việc kiểm tra và xử lý lỗi. Chỉnh sửa tham số LOG_DIR
trong file kafka-run-class (File dùng để khởi chạy của Broker và ZooKeeper) để
khi chạy, tiến trình Broker sẽ trỏ tới thư mục chỉ định để lưu log.
$ s e d − i ’ s | LOG_DIR = . * | LOG_DIR=" ’$BROKER_ROOT_DIR ’ /
l o g s " | ’ $BASE_DIR / k a f k a − run − c l a s s
$ c a t / b i n / k a f k a − run − c l a s s | g r e p ’LOG_DIR ’
Cấu hình file config của Broker, cấu hình broker.id là id của broker trong Cluster,
cấu hình dưới đây là cấu hình của Broker 1:
$ v i $BROKER_ROOT_DIR / s e r v e r . p r o p e r t i e s
Listing 3.5: File cấu hình của Broker

1 broker.id=1
2 listeners=SASL_PLAINTEXT://:9092
3
4 # config default
5 num.network.threads=3
6 num.io.threads=8
7 socket.send.buffer.bytes=102400
8 socket.receive.buffer.bytes=102400
9 socket.request.max.bytes=104857600
10 log.dirs=/data/apps/kafka/data
11 num.partitions=3
39
12 num.recovery.threads.per.data.dir=3
13 offsets.topic.replication.factor=3
14 transaction.state.log.replication.factor=3
15 transaction.state.log.min.isr=2
16 log.retention.hours=1680
17 log.segment.bytes=1073741824
18 log.retention.check.interval.ms=300000
19 default.replication.factor=3
20
21 # Cau hinh toi cac server ZooKeeper

22 zookeeper.connect=confluent-broker-01:2181,confluent-
broker-02:2181,confluent-broker-03:2181
23 zookeeper.connection.timeout.ms=18000
24 metric.reporters=io.confluent.metrics.reporter.
ConfluentMetricsReporter
25 confluent.metrics.reporter.bootstrap.servers=confluent
-broker-01:9092,confluent-broker-02:9092,confluent-
broker-03:9092
Khởi động Confluent Server (Broker)

Trên 3 server Broker thực hiện chạy 2 câu lệnh sau để khởi chạy và kiểm tra
service đã lên chưa:
$ systemctl s t a r t confluent −server
$ systemctl status confluent −server
Hình 3.15: Service Broker đã khởi động thành công
Cấu hình Confluent Schema Registry

$ SCHEMA_ROOT_DIR= / d a t a / a p p s / schema
$ SCHEMA_ROOT_CONFIG_DIR= / e t c / schema − r e g i s t r y
40
Chuẩn bị các thư mục lưu dữ liệu và log cho Schema Registry, thực hiện thay
đổi quyền cho user cp-schema-registry (user chạy tiến trình Schema Registry) với
những thư mục này:
$ m k d i r −p $SCHEMA_ROOT_DIR / l o g s
$ chown −R cp −schema − r e g i s t r y : $SCHEMA_ROOT_DIR
Chỉnh sửa tham số LOG_DIR trong file schema-registry-run-class (File dùng

để khởi chạy của Schema Registry) để lưu log trong thư mục chỉ định
$ s e d − i ’ s | LOG_DIR = . * | LOG_DIR=" ’$SCHEMA_ROOT_DIR ’ /
l o g s " | ’ $BASE_DIR / schema − r e g i s t r y − run − c l a s s
$ c a t / b i n / schema − r e g i s t r y − run − c l a s s | g r e p l o g s
Cấu hình file config của Schema Registry:

$ v i $SCHEMA_ROOT_CONFIG_DIR / schema − r e g i s t r y .
properties
Listing 3.6: File cấu hình của Schema Registry

1 # Rest API Schema Registry
2 listeners=http://0.0.0.0:8081
3
4 # Connect to broker
41
5 kafkastore.bootstrap.servers=confluent-broker-01:9091,
confluent-broker-02:9091,confluent-broker-03:9091
6 confluent.metadata.bootstrap.server.urls=http://
confluent-broker-01:8091,http://confluent-broker
-02:8091,http://confluent-broker-03:8091
7
8 # Topic store Schema

9 kafkastore.topic=_schemas
10 debug=false
Khởi động Confluent Schema Registry

Trên server Broker thực hiện chạy 2 câu lệnh sau để khởi chạy và kiểm tra
service đã lên chưa:
$ systemctl s t a r t confluent −server

$ systemctl status confluent −server
Hình 3.18: Service Schema Registry đã khởi động thành công
Cấu hình Confluent Kafka Connect

$ CONNECT_ROOT_DIR= / d a t a / a p p s / c o n n e c t
$ CONNECT_ROOT_CONFIG_DIR= / e t c / k a f k a
Chuẩn bị các thư mục lưu connector và log cho Kafka Connect, thực hiện thay
đổi quyền cho user cp-kafka-connect (user chạy tiến trình Kafka Connect) với
$ m k d i r −p $CONNECT_ROOT_DIR / c o n n e c t o r
$ m k d i r −p $CONNECT_ROOT_DIR / l o g s
$ chown −R cp − k a f k a − c o n n e c t : $CONNECT_ROOT_DIR
42
Chỉnh sửa tham số LOG_DIR trong file kafka-run-class (File dùng để khởi chạy
của Kafka Connect) để lưu log trong thư mục chỉ định
$ s e d − i ’ s | LOG_DIR = . * | LOG_DIR=" ’$CONNECT_ROOT_DIR ’ /

l o g s " | ’ $BASE_DIR / k a f k a − run − c l a s s
Hình 3.20: Thư mục lưu log đã được thay đổi
Cấu hình file config của Kafka Connect:
$ v i $CONNECT_ROOT_CONFIG_DIR / c o n n e c t − d i s t r i b u t e d .
properties
Listing 3.7: File cấu hình của Kafka Connect

1 # Configure to Kafka Broker
2 bootstrap.servers=confluent-broker-01:9092,confluent-
3
4 # ID of Kafka Connect Cluster

5 group.id=connect-cluster
6
7 # Default configs
8 key.converter=org.apache.kafka.connect.json.
JsonConverter
9 value.converter=org.apache.kafka.connect.json.
JsonConverter
10 key.converter.schemas.enable=true value.converter.
schemas.enable=true
11 offset.storage.topic=connect-offsets
43
12 offset.storage.replication.factor=3
13 config.storage.topic=connect-configs
14 config.storage.replication.factor=3
15 status.storage.topic=connect-status
16 status.storage.replication.factor=3 offset.flush.
interval.ms=10000
17 plugin.path=/usr/share/java,/data/apps/connect/
connectors
Khởi động Confluent Kafka Connect

Trên server Kafka Connect thực hiện chạy 2 câu lệnh sau để khởi chạy và kiểm
$ s y s t e m c t l s t a r t c o n f l u e n t −kafka − connect
$ s y s t e m c t l s t a t u s c o n f l u e n t −kafka − connect
Hình 3.21: Service Kafka Connect đã khởi động thành công
Cài đặt connector Debezium MySQL Connector:

$ c o n f l u e n t −hub i n s t a l l d e b e z i u m / debezium − c o n n e c t o r −
mysql : l a t e s t
Hình 3.22: Debezium MySQL Connector đã có trong danh sách plugin của Kafka Connect
44
Cài đặt connector Neo4j Sink Connector:
$ c o n f l u e n t −hub i n s t a l l n e o 4 j / k a f k a − c o n n e c t − n e o 4 j
:5.0.3
Hình 3.23: Neo4j Sink Connector đã có trong danh sách plugin của Kafka Connect
Cấu hình Confluent Control Center

$ C3_ROOT_DIR = / d a t a / a p p s / c o n t r o l − c e n t e r
$ C3_ROOT_CONFIG_DIR = / e t c / c o n f l u e n t − c o n t r o l − c e n t e r
Chuẩn bị các thư mục lưu connector và log cho Control Center, thực hiện thay
đổi quyền cho user cp-control-center (user chạy tiến trình Control Center) với
$ m k d i r −p $C3_ROOT_DIR / d a t a
$ m k d i r −p $C3_ROOT_DIR / l o g s
$ chown −R cp − k a f k a − c o n n e c t : $C3_ROOT_DIR
45
Chỉnh sửa tham số LOG_DIR trong file control-center-run-class (File dùng để

khởi chạy của Confluent Control Center) để lưu log trong thư mục chỉ định
$ s e d − i ’ s | LOG_DIR = . * | LOG_DIR=" ’$C3_ROOT_DIR ’ / l o g s
" | ’ $BASE_DIR / c o n t r o l − c e n t e r − run − c l a s s
$ c a t $ / BASE_DIR / c o n t r o l − c e n t e r − run − c l a s s | g r e p
LOG_DIR
Hình 3.25: Thư mục lưu log đã được thay đổi
Cấu hình file config của Confluent Control Center:

$ v i $$C3_ROOT_CONFIG_DIR / c o n t r o l − c e n t e r − p r o d u c t i o n
. properties
Listing 3.8: File cấu hình của Confluent Control Center

1 # Control Center id
2 confluent.controlcenter.id=1
3
4 # Configure to Kafka Broker

5 bootstrap.servers=confluent-broker-01:9092,confluent-
6 confluent.metadata.bootstrap.server.urls=http://
confluent-broker-01:8091,http://confluent-broker
-02:8091,http://confluent-broker-03:8091
7
8 # Configure to ZooKeeper
9 zookeeper.connect=confluent-broker-01:2181,confluent-
10
11 # Configure to Kafka Connect

12 confluent.controlcenter.connect.connect-cluster.
cluster=http://confluent-kafka-connect:8083
13
14 # Configure to Schema Registry
46
15 confluent.controlcenter.schema.registry.url=http://
monitoring:8081
16
17
18 # Default configs
19 confluent.controlcenter.command.topic.partitions=3
20 confluent.controlcenter.command.topic.replication=3
21 confluent.controlcenter.data.dir=/data/apps/control-
center/data
22 confluent.controlcenter.internal.topics.partitions=3
23 confluent.controlcenter.internal.topics.replication=3
24 confluent.metrics.topic.partitions=3
25 confluent.metrics.topic.replication=3
26 confluent.metrics.topic=_confluent-metrics
27 confluent.telemetry.enabled=false
28 confluent.controlcenter.ui.autoupdate.enable=false
29 confluent.controlcenter.usage.data.collection.enable=
false
Khởi động Confluent Control Center

Trên server Kafka Connect thực hiện chạy 2 câu lệnh sau để khởi chạy và kiểm
$ systemctl s t a r t confluent −control −center

$ systemctl status confluent −control −center
Hình 3.26: Service Confluent Control Center đã khởi động thành công
Giao diện Confluent Control Center:
47
Hình 3.27: Giao diện màn hình đăng nhập của Confluent Control Center
Confluent Control Center đã kết nối thành công tới các Broker, trên giao diện
có thể thấy số Broker được hiển thị là 3:
Hình 3.28: Giao diện trang chủ của Control Center - Số broker là 3
Confluent Control Center đã kết nối thành công tới các ZooKeeper, trên giao
diện hiển thị đã kết nối tới ZooKeeper:
48
Hình 3.29: Control Center đã kết nối tới ZooKeeper
Confluent Control Center đã kết nối thành công tới Kafka Connect, trên Control
Center có thể quản lý các Connector:
Hình 3.30: Control Center đã kết nối tới Kafka Connect
Confluent Control Center có thể hiển thị các thông tin của một topic:
49
Hình 3.31: Giao diện quản lý Topic trên Control Center
Confluent Control Center có thể hiển thị thông tin schema của Schema Registry:
Hình 3.32: Giao diện schema của Topic trên Control Center
50
CHƯƠNG 4. KẾT QUẢ THỰC NGHIỆM
Trong chương này, em sẽ trình bày cách thức thực hiện và những kết quả đã đạt
được trong trong quá trình thực hiện Đồ án.
4.1 Đồng bộ realtime, tự động từ MariaDB sang Neo4j thông qua Confluent
Platform
a, Kiểm tra dữ liệu trên MariaDB
Để thực hiện lấy dữ liệu từ MariaDB, kiểm tra dữ liệu cần lấy nằm trong bảng
ecommerce.
Hình 4.1: Dữ liệu cần đồng bộ trên MariaDB
b, Tạo Connector Source trên Kafka Connect

Sau khi có được thông tin bảng cần đồng bộ, thực hiện tạo Connector Source để
lấy dữ liệu từ MariaDB lên Confluent Platform.
Các bước tạo MySQL CDC Connector trên Control Center
• Trên tab Connector, nhấn nút Add Connector
51
Hình 4.2: Giao diện tab Connector
• Chọn Connector MySQLConnector
Hình 4.3: Chọn Source Connector
• Thực hiện cấu hình Source Connector MySQLConnector
52
Hình 4.4: Cấu hình Source Connector
• Thực hiện khởi chạy Source Connector MySQLConnector, khi các task của
Connector hiển thị running tức là Connector đã chạy thành công:
Hình 4.5: Khởi chạy Source Connector
Cấu hình Connector Source MySQL
53
Hình 4.6: Cấu hình Connector
Các tham số cần lưu ý:

• name: Tên connector, trong một cụm Kafka Connect, tên connector là duy
nhất.
• schema.history.internal.kafka.topic: Topic kafka để lưu các thay đổi của schema,
khi cấu trúc bảng trong MariaDB thay đổi, các phiên bản schema của bảng sẽ
được lưu trên topic này.
• transforms.unwrap.type: khi đẩy dữ liệu từ MariaDB lên Kafka, dữ liệu của
bảng được nằm trong trường "after", chính vì vậy để thuận tiện hơn cho việc
xử lý, em sử dụng class io.debezium.transforms.ExtractNewRecordState để
chỉ lấy những giá trị bên trong trường "after", từ đó sẽ được giá trị tương ứng
54
với các trường trong bảng trên MariaDB.

• value.converter.schema.registry.url: Thông tin kết nối tới Schema Registry để
lấy thông tin schema.
• connector.class: Class Connector, ở đây là Debeziumg MySQL Connector.
• value.converter: Class dùng để deserialization các giá trị của message. Ở đây
em dùng định dạng Avro, là định dạng có khả năng nén tốt hơn định dạng
json, tuy nhiên để đọc được định dạng Avro thì cần phải có Schema để Dese-
rialization.
• topic.prefix: Tiền tố của Topic. Tên của topic sẽ được ghép từ tiền tố và tên
của bảng trong MariaDB.
• database.hostname: Địa chỉ ip server Database MariaDB.
• database.port: Port của Database MariaDB, giá trị mặc định là 3306.
• database.user: Tên user trong Database MariaDB.
• database.password: Mật khẩu của Database.
• table.include.list: Tên bảng trên MariaDB cần lấy dữ liệu.
c, Kiểm tra dữ liệu trên Confluent Kafka
Trên Confluent Control Center, kiểm tra topic vừa mới được tạo ra từ Connector:
Hình 4.7: Tổng quan Topic
Kiểm tra dữ liệu được tạo ra trên Topic, dữ liệu đường đồng bộ với dữ liệu trên
MariaDB:
55
Hình 4.8: Dữ liệu trên topic
Hình 4.9: Các trường của topic tương ứng với 12 trường trong bảng trên MariaDB
Kiểm tra số lượng bản ghi giữa MariaDB và Confluent:
56
Hình 4.10: Tổng số row trên MariaDB
Hình 4.11: Tổng số message trên Topic bằng so với số bản ghi trên MariaDB
Sau khi thực hiện INSERT một số bản ghi trên MariaDB, thực hiện kiểm tra lại
trên Confluent:
Hình 4.12: Tổng số row trên MariaDB sau khi cập nhật
57
Hình 4.13: Tổng số message trên Topic tăng lên bằng so với số bản ghi trên MariaDB
Trên Confluent cho phép theo dõi lượng dữ liệu được Produce vào Topic, có thể
thấy dữ liệu đã được đẩy vào Topic trong quá trình thực hiện TNSERT dữ liệu vào
MariaDB.
Hình 4.14: Metric của Topic khi cập nhật bảng trên MariaDB
Nhận xét: Sử dụng Debezium MySQL Connector hoàn toàn có thể đồng bộ dữ
liệu từ MariaDB sang Confluent, dữ liệu được cập nhật trên MariaDB cũng sẽ được
tự động được sinh ra trên Confluent, đảm bảo dữ liệu trên Confluent và MariaDB
là như nhau, qua đó có thể đảm bảo dữ liệu đồng bộ từ MariaDB sang Neo4j có thể
sử dụng qua Confluent.
d, Tạo Connector Sink Neo4j
Các bước tạo Neo4j Connector Sink trên Control Center
58
• Trên tab Connector, nhấn nút Add Connector
Hình 4.15: Giao diện tab Connector
• Chọn Connector Neo4jSinkConnector
Hình 4.16: Chọn Sink Connector
• Thực hiện cấu hình Sink Connector Neo4j
59
Hình 4.17: Cấu hình Sink Connector
• Thực hiện khởi chạy Sink Connector Neo4j, khi các task của Connector hiển
thị running tức là Connector đã chạy thành công:
Hình 4.18: Khởi chạy Sink Connector
Cấu hình Connector Sink Neo4j
60
Hình 4.19: Cấu hình Connector
Các tham số cần lưu ý:

• name: Tên connector, trong một cụm Kafka Connect, tên connector là duy
nhất.
• neo4j.topic.cypher.MariaDB..ecommerce.ecommerce: Câu lệnh Cypher để ánh
xạ các trường trong message của Topic thành dữ liệu Đồ thị trong Neo4j
• value.converter.schema.registry.url: Thông tin kết nối tới Schema Registry để
lấy thông tin schema.
• connector.class: Class Connector, ở đây là streams.kafka.connect.sink.Neo4jSinkConnector.
• value.converter: Class dùng để deserialization các giá trị của message, do
Topic được lưu trữ dưới định dạng Avro nên khi deserialization cũng cần phải
dùng Avro.
• topics: Tên topic lưu trữ dữ liệu cần đẩy xuống Neo4j.
• neo4j.authentication.basic.username: Thông tin username của Neo4j
• neo4j.authentication.basic.password: Mật khảu của Database Neo4j
• neo4j.server.uri: Chuỗi kết nối tới Database Neo4j
• neo4j.database": Tên của Database trong Neo4j.
Các câu lênh Cypher để ánh xạ giữa message trên Confluent thành dữ liệu đồ
thị trên Neo4j:
• Ánh xạ tới Node User:
1 MERGE (u:User {user_id: event.user_id});
• Ánh xạ tới Node Product:

1 MERGE (p:Product {product_id: event.product_id,
price: event.price})
61
2 SET p.brand = CASE trim(event.brand) WHEN "" THEN

null ELSE event.brand END;
• Ánh xạ tới Node Category:
1 WITH event WHERE event.main_category IS NOT NULL

2 MERGE (c:Category {categorey_id: event.category_id,
name: event.main_category });
• Ánh xạ tới Node Sub_Category:
1 WITH event WHERE event.sub_category IS NOT NULL

2 MERGE (sc:Sub_Category {sub_category: event.
sub_category});
• Ánh xạ tới cạnh ACTION:
1 MATCH (u:User {user_id: event.user_id})

2 MATCH (p:Product {product_id: event.product_id})
3 MERGE (u)-[a:ACTION {type: event.event_type}]->(p);
• Ánh xạ tới cạnh BELONG_TO:
1 MATCH (c:Category {categorey_id: event.category_id

})
2 MATCH (p:Product {product_id: event.product_id})
3 MERGE (p)-[a:BELONG_TO]->(c);
• Ánh xạ tới cạnh SUB_BELONG:
1 MATCH (sc:Sub_Category {sub_category: event.

sub_category})
2 MATCH (c:Category {name: event.name})
3 MERGE (sc)-[sb:SUB_BELONG]->(c);
Kiểm tra dữ liệu trên Neo4j

Tổng số Node tăng trong quá trình chạy Connector Sink Neo4j:
62
Hình 4.20: Tổng số node trên Neo4j
Hình 4.21: Tổng số node không ngừng tăng trong quá trình chạy Connector
Tổng số Cạnh tăng trong quá trình chạy Connector Sink Neo4j:
63
Hình 4.22: Tổng số cạnh trên Neo4j
Hình 4.23: Tổng số cạnh tăng lên trong quá trình chạy Connector
Kiểm tra dữ liệu trên một số đỉnh vả cạnh:
64
Hình 4.24: Dữ liệu đỉnh User
Hình 4.25: Dữ liệu đỉnh Product
65
Hình 4.26: Dữ liệu đỉnh Category
Hình 4.27: Dữ liệu cạnh ACTION
66
Hình 4.28: Dữ liệu cạnh BELONG_TO
Nhận xét: Sử dụng Connector Sink Neo4j hoàn toàn có thể đồng bộ dữ liệu từ
Confluent sang Neo4j, khi có dữ liệu mới được ghi vào trong Topic, dữ liệu đó
cũng sẽ được tự động cập nhật vào trong Neo4j.
e, Kết luận
Confluent Platform là công cụ chuyên biệt, hoàn toàn có thể xử lý bài toán
streaming dữ liệu realtime từ MariaDB sang Confluent, dữ liệu đồng bộ hoàn toàn
được tự động một cách chuyên nghiệp.
4.2 Các mô hình khuyến nghị thời gian thực sử dụng Neo4j
a, Kỹ thuật Content-based Filtering
Kỹ thuật Content-based filtering được sử dụng để phân tích một tập hợp các item
được người dùng hoặc những người dùng khác quan tâm xếp hạng trước đó để đưa
ra dự đoán. Kỹ thuật này thường được ứng dụng trong trang web, tin tức để đưa ra
một số khuyến nghị cho người dùng. Những khuyến nghị này được thực hiện dựa
trên đánh giá của người dùng với một số mặt hàng trong quá khứ. Để tạo ra một đề
xuất đầy đủ có ý nghĩa sẽ sử dụng các loại mô hình khác nhau để tìm ra điểm tương
đồng giữa các tài liệu như Mô hình không gian vectơ, mô hình xác suất và Mạng
thần kinh (Neural Network). Khi sử dụng đề xuất dựa trên kỹ thuật này, không cần
hồ sơ người dùng vì nó được thực hiện bằng cách sử dụng học mát hoặc phân tích
thống kê. Ưu điểm của kỹ thuật này là:
• 1. Đảm bảo quyền riêng tư vì không cần chia sẻ hồ sơ người dùng
• 2. Các khuyến nghị đã được thực hiện trong một thời gian ngắn do chỉ cần
thực hiện các câu truy vấn bằng ngôn ngữ truy vấn.
67
• 3. Có thể đề xuất các mặt hàng mới ngay cả khi không có tỷ lệ nào trong đó.
Đối với tập dữ liệu em đang sử dụng trên Neo4j, đầu vào để ứng dụng kỹ thuật
Content-based filtering bao gồm User (Người dùng), Product (Các sản phẩm
người dùng tương tác trên sàn thương mại điện tử) và các ACTION (tương ứng
với phản hồi của người dùng, người dùng thực hiện các thao tác xem, đặt vào
giỏ hàng và mua sản phẩm).
1. Đảm bảo quyền riêng tư nghĩa là không cần chia sẻ hồ sơ người dùng. 2. Khuyến
nghị đã được thực hiện trong một thời gian ngắn. 3. Đề xuất các mặt hàng mới ngay
cả khi không có tỷ lệ nào trong đó.
68
CHƯƠNG 5. CÁC GIẢI PHÁP VÀ ĐÓNG GÓP NỔI BẬT
5.1 Hiệu suất của MariaDB

5.1.1 Vấn đề
Do MariaDB chỉ cài đặt trên 1 server, nếu trong hệ thống thực tế, việc quá tải
hoàn toàn có thể xảy ra.
Đối với các hệ thống của doanh nghiệp hiện thương mại điện tử hiện nay, lượng
giao dịch cũng như các thao tác người dùng trên các trang web mua hàng là vô
cùng lớn, chính vì vậy việc sử dụng chỉ 1 server MariaDB sẽ gây ảnh hưởng lớn tới
hiệu suất sử dụng và cũng gây nhiều rủi ro nếu server MariaDB bị down sẽ không
có phương án thay thế dẫn tới thiệt hại rất lớn.
5.1.2 Giải pháp
MariaDB cho phép triển khai theo mô hình Cluster Master-Slave.
Như hình bên trên ta thấy 1 cụm MariaDB có 4 Node (1 Node Master và 3 Node
Slave). Dữ liệu chỉ được ghi bởi Node Master, các Node Slave sẽ đọc binlog của
Node Master và sao chép dữ liệu về ổ đĩa cục bộ. Dữ liệu hoàn toàn có thể được
truy vấn trên toàn bộ các Node, tuy nhiên Node Master là Node duy nhất thực hiện
ghi dữ liệu và duy trì các tiến trình đọc binlog của các Node Slave, chính vì vậy để
giảm tải cũng như tránh rủi ro quá tải dẫn đến dừng dịch vụ, Node Master chỉ nên
làm nhiệm vụ ghi dữ liệu, khi muốn truy vấn thì các ứng dụng/người dùng truy vấn
trên các node Slave.
69
Đối với quy mô doanh nghiệp, việc có một lớp Proxy ở phía trước các node
MariaDB để điều hướng các yêu cầu từ ứng dụng tới các Node là vô cùng cần thiết.
Khi có một Node down, lớp Proxy đó có nhiệm vụ điều hướng các request sang các
Node còn lại.
MariaDB phát triển công cụ để giải quyết vấn đề đó là Maxscale.
Maxscale là công cụ tối ưu giúp điều hướng các hàng ngàn request từ các ứng
dụng. Maxscale cũng là một bộ cân bằng tải, giúp điều hướng một cách cân bằng
số lượng request tới đều tất cả các node, qua đó làm giảm hiện tượng quá tải của
các Node.
5.2 Vấn đề bảo mật của Confluent
5.2.1 Vấn đề
Bảo mật dữ liệu luôn là vấn đề ưu tiên của doanh nghiệp, việc rò rỉ thông tin
cũng là một thảm hoạ đối với doanh nghiệp.
Với thời gian thực hiện Đồ án còn hạn chế, em chưa tích hợp được các tính năng
bảo mật đối với Confluent, dữ liệu hoàn toàn có thể đọc được từ bất kỳ server nào
mà không có biện pháp bảo mật.
5.2.2 Giải pháp
Confluent là sản phẩm thương mại, chính vì vậy Confluent hiện tại đang có
những tính năng bảo mật.
70
Hình 5.1: Các hình thức bảo mật của Confluent
• Confluent hỗ trợ các biện pháp xác thực như SSL, SASL.
• Confluent hỗ trợ các biện pháp uỷ quyền như tích hợp với Lightweight Direc-
tory Access Protoco - LDAP (Tính năng độc quyền của Confluent) và Access
Control List - ACL.
Hình 5.2: Cơ chế hoạt động của ACL trong Confluent
71
• Trên đường truyền mạng, Confluent cũng hỗ trợ bảo mật SSL trên đường
truyền,
Hình 5.3: Các cơ chế xác thực của Confluent
72
CHƯƠNG 6. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN TƯƠNG LAI
6.1 Kết luận
73

DATN Nguyen Minh Quang 20184303

Uploaded by

Copyright:

Available Formats

You might also like

DATN Nguyen Minh Quang 20184303

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DATN Nguyen Minh Quang 20184303

Uploaded by

Copyright:

Available Formats

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

Ngành Khoa Học Máy Tính

Giảng viên hướng dẫn: PGS.TS Cao Tuấn Dũng

Khoa: Khoa Học Máy Tính

Trường: Đại Học Bách Khoa Hà Nội

CHƯƠNG 1. GIỚI THIỆU ĐỀ TÀI ĐỒ ÁN ............................................ 1

1.1 Đặt vấn đề............................................................................................ 1

1.2 Mục tiêu và phạm vi đề tài..................................................................... 1

1.3 Định hướng giải pháp............................................................................ 2

1.4 Bố cục đồ án ........................................................................................ 2

CHƯƠNG 2. CÁC CÔNG NGHỆ SỬ DỤNG ........................................... 3

2.1 Cơ sở dữ liệu MariaDB ......................................................................... 3

2.2 Cơ sở dữ liệu Neo4j .............................................................................. 5

2.3 Confluent Platform ............................................................................... 12

CHƯƠNG 3. CÀI ĐẶT ............................................................................ 24

3.1 Thiết kế kiến trúc.................................................................................. 24

3.1.1 Sơ đồ Logic hệ thống ................................................................. 24

3.1.2 Mô hình server........................................................................... 25

3.1.3 Thiết kế Cơ sở dữ liệu................................................................. 26

3.2 Cài đặt................................................................................................. 29

3.2.1 Cài đặt MariaDB........................................................................ 29

3.2.2 Cài đặt Neo4J ............................................................................ 32

3.2.3 Cài đặt Confluent Platform ......................................................... 35

CHƯƠNG 4. KẾT QUẢ THỰC NGHIỆM............................................... 51

5.1 Hiệu suất của MariaDB ......................................................................... 69

5.1.1 Vấn đề....................................................................................... 69

5.1.2 Giải pháp .................................................................................. 69

5.2 Vấn đề bảo mật của Confluent ............................................................... 70

5.2.1 Vấn đề....................................................................................... 70

5.2.2 Giải pháp .................................................................................. 70

CHƯƠNG 6. KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN TƯƠNG LAI........ 73

6.1 Kết luận ............................................................................................... 73

Hình 2.1 Logo của hãng MariaDB . . . . . . . . . . . . . . . . . . . . . 3

Hình 3.1 Sơ đồ Logic hệ thống . . . . . . . . . . . . . . . . . . . . . . . 24

Hình 4.1 Dữ liệu cần đồng bộ trên MariaDB . . . . . . . . . . . . . . . 51

Hình 5.1 Các hình thức bảo mật của Confluent . . . . . . . . . . . . . . 71

Bảng 2.1 So sánh RDF và PG . . . . . . . . . . . . . . . . . . . . . . . . 7

Bảng 3.1 Mô tả chi tiết bảng ecommerce trong MariaDB . . . . . . . . 27

Viết tắt Tên tiếng Anh Tên tiếng Việt

Thuật ngữ Ý nghĩa

người dùng trên sàn thương mại điện tử.

Hình 2.1: Logo của hãng MariaDB

Hình 2.3: Logo của Neo4j

Resource Description Framework (RDF) và Property Graph (LPG) Model

Bảng 2.1: So sánh RDF và PG

Hình 2.4: Truy vấn trên Native Graph

Hình 2.5: Truy vấn trên Non-Native Graph

2.3 Confluent Platform

Hình 2.6: Confluent Platform Component

Cơ chế hoạt động

Hình 2.7: Log trên Kafka

Hình 2.8: Nhiều hệ thống có thể đọc cùng một dữ liệu

Cơ chế Replication của Log:

Hình 2.9: Cơ chế replication

Hình 2.10: Cách phân bổ của Topic, Partition và Segment

Hình 2.12: Các file segment trong một Topic

Các Kafka Client:

Hình 2.13: Các Kafka Client