LỜI CẢM ƠN

Trước hết, em xin bày tỏ tình cảm và lòng biết ơn của em tới cô giáo TS.Nguyễn
Thị Thu Hiên. Người đã từng bước hướng dẫn, giúp đỡ em trong quá trình thực hiện đồ
án tốt nghiệp của mình.

Em xin chân thành cảm ơn các thầy cô giáo khoa Viễn Thông 1 – Học viện Công
Nghệ Bưu Chính Viễn Thông đã dìu dắt, dạy dỗ em cả về kiến thức chuyên môn và tinh
thần học tập để em có được những kiến thức thực hiện đồ án tốt nghiệp của mình.

Em xin chân thành cảm ơn PGS.TS. Đặng Hoài Bắc – Hiệu trưởng Học viện Công
Nghệ Bưu Chính Viễn Thông, ban giám hiệu nhà trường, các phòng ban đã giúp đỡ tạo
điều kiện tốt nhất cho em trong suốt thời gian học tập tại trường.

Tuy có nhiều cố gắng trong quá trình học tập, cũng như trong quá trình làm đồ án
tốt nghiệp không thể tránh khỏi những thiếu sót, em rất mong được sự góp ý quý báu của
tất cả các thầy cô giáo cũng như tất cả các bạn để kết quả của em được hoàn thiện hơn.

Một lần nữa em xin chân thành cảm ơn.

Hà Nội, Ngày Tháng Năm

Sinh viên
MỤC LỤC
DANH MỤC HÌNH
THUẬT NGỮ VIẾT TẮT
 LỜI MỞ ĐẦU

Big Data là công nghệ được giới thiệu từ năm 2005, vốn được sử dụng để mô tả
việc khai thác các thông tin trọng yếu từ nhiều hệ thống khác nhau, sau đó tập hợp các
thông tin này lại để phân tích. Sự thật là có rất nhiều doanh nghiệp đã bỏ quên tầm quan
trọng của Big Data. Trước hết, ta cần lưu ý rằng, dữ liệu – đặc biệt là dữ liệu “đúng” và
đủ chính là nguồn sống của doanh nghiệp. Dữ liệu là thứ giúp đo lường đa phần các tham
số chủ chốt cho doanh nghiệp.Ngoài ra, ở thế giới “siêu kết nối” hiện tại, dữ liệu đại diện
cho khách hàng – không phải dữ liệu khách hàng nào cũng đến từ các hệ thống ERP, mà
đôi khi doanh nghiệp phải cân nhắc cả những phản hồi và khảo sát khách hàng, cũng như
các bình luận trên mạng xã hội của họ. Chính vì vậy, việc vận dụng được các nguồn dữ
liệu, dù là dữ liệu cấu trúc hay phi cấu trúc cũng sẽ phần nào giúp giải tỏa áp lực cho
doanh nghiệp.

Hãy nghĩ về 15 năm trước, khi các doanh nghiệp liên tục bỏ qua Big Data, để xem
xét lại vị thế của công nghệ này ở hiện tại.Cụ thể, trong vòng 15 năm, dữ liệu đã dần
chuyển dịch sang Cloud, theo sau đó là hàng loạt các chiến thuật phần mềm mới, cũng
như các hệ thống chuyên biệt dần trở nên mở hơn, liên tục trao đổi các dữ liệu “có cấu
trúc”.Tuy nhiên, các hệ thống này vẫn chưa hoàn thiện khả năng tổng hợp dữ liệu cho
việc phân tích và ra quyết định, nhưng điều này hoàn toàn có thể xảy ra trong tương lai.
Cùng với sự hỗ trợ của các công nghệ như AI và Machine Learning, các doanh nghiệp sẽ
đạt được thứ mà chúng ta thường gọi là “lợi thế cạnh tranh.”

Được sự đồng ý của Học viện Công Nghệ Bưu Chính Viễn Thông khoa Viễn
Thông 1, cùng sự ủng hộ nhiệt tình và sự động viên giúp đỡ rất tận tình của cô Nguyễn
Thị Thu Hiên, em đã chọn đề tài:“ Nghiên cứu xây dựng Spark Streaming lưu trữ trên
HDFS ”.

Ngoài phần mở đầu và kết luận , nội dung báo cáo của em được chia làm 3
chương:

Chương 1: Giới thiệu chung về Hadoop.

Chương 2: Tổng quan về Spark Streaming.

Chương 3: Xây dựng luồng Spark Streaming lưu trữ trên HDFS.

Em rất mong nhận được các ý kiến đóng góp phê bình của các thầy cô trong
trường và của các bạn để chương trình được ngày càng hoàn thiện hơn.

Em xin chân thành cảm ơn.

 CHƯƠNG 1

GIỚI THIỆU HADOOP

1.1 Giới thiệu Framework Hadoop

1.1.1 Hadoop là gì ?
Apache Hadoop là Framework mã nguồn mở, nó cho phép phát triển các ứng dụng
phân tán có cường độ dữ liệu lớn một cách miễn phí. Hadoop được phát triển dựa trên
ý tưởng từ các công bố của Google về mô hình MapReduce và hệ thống file phân tán
Google File System (GFS). Hadoop cung cấp một hệ thống file phân tán (HDFS) cho
phép lưu trữ dữ liệu dựa lên trên nhiều Node. Cả Map/Reduce và HDFS đều được
thiết kế sao cho framework sẽ tự động quản lý được các lỗi, các hư hỏng về phần
cứng của các node.
Hadoop được viết bằng Java tuy nhiên nhờ cơ chế streaming , Hadoop cho phép phát
triển các ứng dụng phân tán bằng cả Java lẫn một số ngôn ngữ lập trình khác như
Python, Scala. Hadoop chỉ có thể chạy trên môi trường Linux-based.

1.1.2 Lịch sử phát triển của Hadoop

Hadoop bắt đầu vào năm 2002 với dự án Apache Nutch. Hadoop được tạo ra bởi
Dough Cutting, người tạo ra Apache Lucene, thư viện tìm kiếm văn bản được sử dụng
rộng rãi. Hadoop có nguồn gốc từ Apache Nutch, một công cụ tìm kiếm web mã
nguồn mở, bản thân nó là một phần của Dự án Lucene.
Nutch được khởi xướng từ năm 2002, và một hệ thống search engine (gồm crawler và
tìm kiếm) nhanh chóng ra đời. Tuy nhiên, các nhà kiến trúc sư của Nutch nhanh
chóng nhận ra rằng Nutch sẽ không thể mở rộng ra để có thể thực hiện vai trò searcher
engine của mình trên tập dữ liệu hàng tỷ trang web (lúc khả năng của Nutch chỉ có thể
crawl tối đa 100 triệu trang). Nguyên nhân chính của giới hạn này là do Nutch lúc này
chỉ chạy trên một máy đơn (stand alone) nên gặp phải các khuyết điểm như tốc độ
truy xuất chậm , khả năng lưu trữ bị giới hạn.
Năm 2003, Google công bố kiến trúc của hệ thống file phân tán GFS (viết tắt từ
Google File System) của họ. Các nhà kiến trúc sư của Nutch thấy rằng GFS sẽ giải
quyết được nhu cầu lưu trữ các file rất lớn từ quá trình crawl và index. Năm 2004, họ
bắt tay vào việc ứng dụng kiến trúc của GFS vào cài đặt một hệ thống file phân tán
nguồn mở có tên Nutch Distributed File System (NDFS).
Năm 2004, Google lại công bố bài báo giới thiệu MapReduce. Vào đầu năm 2005, các
nhà phát triển Nutch đã xây dựng được phiên bản MapReduce trên Nutch, và vào giữa
năm 2005, tất cả các thuật toán chính của Nutch đều được cải tiến lại để chạy trên nền
NDFS và MapReduce. NDFS và MapRecude trong Nutch đã nhanh chóng tìm được
các ứng dụng của mình bên ngoài lĩnh vực search engine, và vào tháng hai 2006
Dough Cutting đã tách riêng NDFS và MapReduce ra để hình thành một dự án độc
lập có tên Hadoop. Cùng thời gian này, Dough Cutting gia nhập vào Yahoo!. Tại đây
ông được tạo một môi trường tuyệt vời để phát triển Hadoop và vào tháng 2 năm 2008
Yahoo đã công bố sản phẩm search engine của họ được xây dựng trên một Hadoop
cluster có kích thước 10.000 nhân vi xử lý.
Năm 2008, Apache đã đưa Hadoop lên thành dự án ở top-level Apache Software
Foundation, nhằm xác nhận sự thành công và các áp dụng rộng rãi của Hadoop. Vào
12
thời gian này, Hadoop được sử dụng bởi rất nhiều công ty ngoài Yahoo! như Last.fm,
Facebook, New York Times.
Năm 2008, Hadoop đã phá kỷ lục thế giới về sắp xếp một terabyte dữ liệu. Chạy trên
một cluster gồm 910 node, Hadoop đã sắp xếp một terabyte dữ liệu trong vòng 209
giây, phá kỷ lục cũ là 297 giây. Sau đó ít lâu, Google công bố ứng dụng chạy trên
MapReduce của họ đã sắp xếp được một terabyte dữ liệu trong 68 giây. Vào tháng 5
năm 2009, một đội các nhà phát triển của Yahoo! đã dùng Hadoop để sắp xếp một
terabyte dữ liệu trong vòng 62 giây.
Năm 2009, Hadoop đã được thử nghiệm thành công để sắp xếp PB (PetaByte) dữ liệu
trong vòng chưa đầy 17 giờ để xử lý hàng tỷ tìm kiếm và lập chỉ mục hàng triệu trang
web. Và Doug Cutting rời Yahoo và gia nhập Cloudera để thực hiện thách thức đưa
Hadoop sang các ngành công nghiệp khác. Vào tháng 12 năm 2011, Apache Software
Foundation đã phát hành Apache Hadoop phiên bản 1.0. Sau đó vào tháng 8 năm
2013, Phiên bản 2.0.6 đã có sẵn.Và hiện tại, Apache Hadoop phiên bản 3.3.4 được
phát hành vào tháng 8 năm 2022.

1.1.3 Kiến trúc của Hadoop

Trong phần này sẽ trình bày kiến trúc tổng quan của Hadoop . Hadoop bao gồm các
thành phần :

Hình 1-1 Các thành phần của Hadoop

● Core: cung cấp các công cụ và giao diện cho hệ thống phân tán. Đây là phần lõi để
xây dựng nên HDFS và MapReduce.
● MapReduce: giúp phát triển các ứng dụng phân tán theo mô hình MapReduce một
cách dễ dàng và mạnh mẽ , Framework này có thể chạy trên một cluster lớn với
nhiều node.
● HDFS: đây là hệ thống file phân tán cung cấp khả năng lưu trữ dữ liệu lớn và truy
cập với hiệu suất cao.
● HBase: đây là một cơ sở dữ liệu phân tán , sử dụng HDFS làm hạ tầng cho việc
lưu trữ dữ liệu bên dưới và cung cấp khả năng tính song song dựa trên
MapReduce.
● Hive: đây là một Data WareHouse phân tán. Nó quản lý dữ liệu được lưu trữ trên
HDFS và cung cấp một ngôn ngữ truy vấn dựa trên SQL.
● Chukwa: một hệ thống tập hợp và phân tích dữ liệu. Chukwa chạy các collector ,
các collector này lưu trữ dữ liệu trên HDFS và sử dụng MapReduce để phát sinh
các báo cáo.
● Pig: ngôn ngữ luồng dữ liệu cấp cao và thực thi cho việc tính toán song song.

1.1.4 Ứng dụng của Hadoop trong một số công ty

Ngày nay, ngoài Yahoo!, có nhiều công ty sử dụng Hadoop như là một công cụ để lưu
trữ và phân tích dữ liệu trên các khối dữ liệu lớn như:
● Expedia: sử dụng các cụm Hadoop bằng Amazon Elastic MapReduce (Amazon
EMR) để phân tích khối lượng lớn dữ liệu đến từ mạng lưới trang web toàn cầu
của Expedia. Chúng bao gồm dòng nhấp chuột, tương tác người dùng và dữ liệu
cung cấp. Có giá trị cao trong việc phân bổ chi tiêu tiếp thị, dữ liệu này được hợp
nhất từ các lượt đặt trước trên web, bộ phận tiếp thị và nhật ký chi tiêu tiếp thị để
phân tích xem liệu chi tiêu có tương đương với việc tăng lượt đặt trước hay không.
● Royal Bank of Scotland: Là người thúc đẩy trải nghiệm khách hàng được nâng
cao, Ngân hàng Hoàng gia Scotland (RBS) đã quyết định sử dụng Hadoop
(Cloudera Enterprise) để thu thập thông tin từ các cuộc trò chuyện khách hàng
trực tuyến của mình.RBS xử lý khoảng 250.000 nhật ký trò chuyện và siêu dữ liệu
liên quan mỗi tháng, lưu trữ dữ liệu phi cấu trúc này trong Hadoop. Bằng cách sử
dụng trung tâm phân tích và quản lý dữ liệu lớn được xây dựng trên Hadoop,
doanh nghiệp sử dụng công nghệ máy học cũng như xử lý dữ liệu để lập bản đồ và
hiểu hành trình của khách hàng.Ngân hàng cao cấp cũng đang sử dụng phân tích
dữ liệu lớn để đi sâu vào dữ liệu giao dịch nhằm phân tích và xác định nơi khách
hàng đang trả gấp đôi cho các sản phẩm tài chính và mang lại trải nghiệm khách
hàng nâng cao.
Và còn rất nhiều công ty hiện đang sử dụng Hadoop vào việc lưu trữ và xử lý dữ
liệu, đặc biệt cho các nguồn dữ liệu lớn với kích thước lên tới hàng petabyte.
1.1.5 Tổng quan của một Hadoop Cluster
Cluster là một tập hợp các máy tính được kết nối hoạt động cùng nhau như một hệ
thống duy nhất . Tương tự cụm Hadoop chỉ là một cụm máy tính mà được sử dụng để
xử lý phân tán khối lượng dữ liệu khổng lồ. Về cơ bản với mục đích lưu trữ dữ cũng
như phân tích một lượng lớn dữ liệu phi cấu trúc , một loại cụm tính toán đặc biệt
được thiết kế được gọi là Hadoop Cluster.

Hình 1-2: Kiến trúc tổng quan của một Hadoop Cluster
Hadoop cluster có kiến trúc master-slave, có một namnode và một node chạy
JobTracker((NameNode và JobTracker có thể nằm trên cùng một máy vật lý, tuy
nhiên trên các cluster thật sự với hàng trăm, hàng nghìn node thì thường phải tách
riêng NameNode và JobTracker ra các máy vật lý khác nhau). Có nhiều node slave,
mỗi node slave thường đóng 2 vai trò: một là DataNode, hai là TaskTracker.
NameNode và DataNode chịu trách nhiệm vận hành hệ thống file phân tán HDFS với
vai trò cụ thể được phân chia như sau:
 ● Namenode đóng vai trò là master, chịu trách nhiệm duy trì thông tin về cấu trúc
cây phân cấp các tệp, thư mục của hệ thống tệp, các metadata khác của hệ thống
tệp và tình trạng hoạt động của các DataNode thông qua các hearbeat, điều hướng
quá trình đọc ghi dữ liệu từ client lên các DataNode.
● DataNode nơi trực tiếp lưu trữ dữ liệu , mỗi Datanode chịu trách nhiệm lưu trữ
một phần dữ liệu của hệ thống , đáp ứng các yêu cầu đọc ghi dữ liệu từ client , tạo
xóa các block dữ liệu từ NameNode. Nó luôn cập nhật gửi trạng thái của nó đến
NameNode sau mỗi 3 giây.
● Ngoài ra còn có Secondary NameNode, là một nút chuyên dụng đặc biệt trong
cụm Hadoop có chức năng chính là nhận các điểm checkpoints của hệ thống file
metadata có trên NameNode, liên tục kiểm tra tính chính xác của các tệp tin lưu
trữ trên các DataNode và không thể thay thế nút chính .

JobTracker và TaskTracker chịu trách nhiệm duy trì bộ máy MapReduce, nhận và
thực thi các MapReduce Job :
● JobTracker: tiếp nhận các yêu cầu thực thi các MapReduce job, phân chia job này
thành các task và phân công cho các TaskTracker thực hiện, quản lý tình trạng
thực hiện các task của TaskTracker và phân công lại nếu cần. JobTracker cũng
quản lý danh sách các node TaskTracker và tình trạng của từng node thông qua
hearbeat.
● TaskTracker: nhận các task từ JobTracker và thực hiện task.

1.2 Hadoop Distributed File System(HDFS)

Khi tập dữ liệu vượt quá khả năng lưu trữ của một máy, thì bắt buộc phải phân vùng
tập dữ liệu trên một số máy riêng biệt. Hệ thống tệp quản lý dữ liệu trên mạng máy
được gọi là hệ thống tệp phân tán HDFS (Hadoop Distributed File System). Hệ thống
này cho phép chúng ta lưu trữ dữ liệu trên nhiều máy hoặc nhiều nút trong một cụm
và cho phép nhiều người dùng truy cập dữ liệu đồng thời cung cấp khả năng chịu lỗi
và tính sẵn sàng cao.
1.2.1 Giới thiệu
Trong thế giới CNTT ngày nay, gần 75% dữ liệu trên thế giới nằm trong Hadoop
HDFS.Đó là do các lý do sau:
● HDFS lưu trữ dữ liệu trên toàn bộ phần cứng nên không cần các máy cao cấp để
lưu trữ dữ liệu siêu lớn. Do đó cung cấp dung lượng lưu trữ tiết kiệm cho dữ liệu
lớn.
● HDFS tuân theo mô hình xử lý dữ liệu hiệu quả nhất Write - Once - Read - Many -
Times. Dữ liệu có thể được truy cập nhiều lần mà không gặp bất kỳ vấn đề gì liên
quan đến sự kết hợp dữ liệu. Tập dữ liệu được tạo từ nhiều nguồn khác nhau được
sao chép và sau đó các phân tích khác nhau được thực hiện trên tập dữ liệu đó theo
thời gian. Vì vậy tốt nhất là xử lý hàng loạt việc và append dữ liệu vào file sẽ trở
thành điểm chính để tối ưu hoá hiệu suất.
● HDFS có thể lưu trữ dữ liệu ở bất kỳ kích thước nào được tạo từ bất kỳ từ nguồn
nào ở bất kỳ định dạng nào , có cấu trúc hoặc không có cấu trúc.
Đã có rất nhiều Hadoop cluster chạy HDFS trên thế giới. Trong đó nổi bật nhất là
của Yahoo với một cluster lên đến 1100 node với dung lượng HDFS 12 PB. Các
công ty khác như Facebook, Adode, Amazon cũng đã xây dựng các cluster chạy
HDFS với dung lượng hàng trăm, hàng nghìn TB.

1.2.2 Kiến trúc của HDFS

HDFS được thiết kế dựa trên mô hình master/slave trong đó master là NameNode và
slave là DataNode.
NameNode là nơi lưu trữ thông tin metadata của cụm, bao gồm các thông tin như vị
trí, số lượng block của file, quyền truy cập vào file đó,… NameNode là nơi tiếp nhận
các yêu cầu đọc ghi từ client và điều phối hoạt động của cụm.
 Hình 1-3 Kiến trúc HDFS

Metadata trong NameNode được lưu trữ dưới dang 2 file:

● FSImage: Filesystem image lưu trữ metadata của NameNode từ khi khởi tạo.
● EditLogs: Chứa thông tin các thay đổi gần đây nhất của cụm chưa có trong
FSImage.
DataNode là nơi lưu trữ dữ liệu vật lý, đây là nơi lưu trữ block của file. Các
DataNode có nhiệm vụ báo cáo tình trạng đến NameNode, thông báo về danh sách
các block mà nó quản lý. Nếu 1 DataNode chết, NameNode sẽ thực hiện replicate các
block của DataNode này đến các DataNode khác để đảm bảo dữ liệu luôn sẵn sàng.
Dựa theo sự điều phối của NameNode mà DataNode là nơi thực hiện các yêu cầu
đọc, ghi file của người dùng.

1.2.2.1 Qúa trình tương tác giữa client và HDFS

Việc tồn tại duy nhất một NameNode trên một hệ thống HDFS đã làm đơn giản hoá
thiết kế của hệ thống và cho phép NameNode ra những quyết định thông minh trong
việc sắp xếp các block dữ liệu lên trên các DataNode. Tuy nhiên, cần phải tối thiểu
hoá sự tham gia của NameNode vào các quá trình đọc/ghi dữ liệu lên hệ thống để
tránh tình trạng nút thắt cổ chai (bottle neck). Client sẽ không bao giờ đọc hay ghi dữ
liệu lên hệ thống thông qua NameNode. Thay vào đó, client sẽ giao tiếp với
NameNode xem nên liên lạc với DataNode nào để truy xuất dữ liệu. Sau đó, client sẽ
cache thông tin này lại và kết nối trực tiếp với các DataNode để thực hiện các thao
tác truy xuất dữ liệu.
1.2.2.1.1 Qúa trình đọc file

Hình 1-4 Quá trình đọc file trên HDFS

Đầu tiên client sẽ mở file cần đọc bằng cách gửi yêu cầu đọc file đến NameNode.
Sau đó NameNode sẽ thực hiện kiểm tra xem file yêu cầu đọc có tồn tại hay không
hoặc xem tình trạng file là như thế nào. Nếu mọi thứ bình thường thì NameNode sẽ
gửi danh sách các block của file với cùng địa chỉ các DataNode chứa các bản sao của
block này.
Tiếp theo client sẽ mở các kết nối tới DataNode , thực hiện một RPC để yêu cầu nhận
block cần đọc và đóng kết nối với Datanode. Lưu ý: với mỗi block ta có thể có nhiều
DataNode lưu trữ các bản sao của block đó. Client sẽ chỉ đọc bản sao của block từ
DataNode gần nhất. Việc tính khoảng cách giữa 2 node trên cluster sẽ được trình bày
sau.
Cuối cùng Client sẽ thực hiện việc đọc các block lặp đi lặp lại cho đến khi block cuối
cùng của file được đọc xong. Quá trình client đọc dữ liệu từ HDFS sẽ transparent với
người dùng hoặc chương trình của ứng dụng client, người dùng sẽ dùng 1 tập API
của Hadoop để tương tác với HDFS, các API này che giấu đi quá trình liên lạc với
Namenode và kết nối các DataNode để nhận dữ liệu.
Chú ý: trong quá trình một client đọc 1 file trên HDFS, client sẽ trực tiếp kết nối với
Datanode để lấy dữ liệu chứ không cần thực hiện gián tiếp qua Namenode. Điều này
sẽ làm giảm đi rất nhiều việc trao đổi dữ liệu giữa client NameNode, khối lượng luân
chuyển dữ liệu sẽ được trải đều khắp cluster, tình trạng nghẽn cổ chai sẽ không xảy
ra. Do đó, cluster chạy HDFS có thể đáp ứng đồng thời nhiều client cùng thao tác tại
một thời điểm.

1.2.2.1.2 Ghi File

 Hình 1-5 Quá trình ghi file trên HDFS

Bước 1: Client sẽ gửi yêu cầu đến NameNode tạo một file entry lên File System
Namespace. File mới được tạo sẽ rỗng, tức chưa có một block nào. Sau đó,
Namenode sẽ quyết định danh sách các DataNode sẽ chứa các bản sao của file cần gì
và gửi lại cho client.
Bước 2: Client sẽ chia file cần gì ra thành các block, và với mỗi block client sẽ đóng
gói thành một packet. Lưu ý, mỗi block sẽ được lưu ra thành nhiều bản sao trên các
DataNode khác nhau (tuy vào chỉ số độ nhân bản của file).
Bước 3: Client gửi gói tin cho DataNode thứ nhất, DataNode thứ nhất sau khi nhận
được gói tin sẽ tiến hành lưu lại bản sao thứ nhất của block. Tiếp theo DataNode thứ
nhất sẽ gửi gói tin này cho Datanode thứ 2 để lưu ra bản sao thứ 2 của block, cứ như
vậy cho đến Datanode cuối cùng.
Bước 4: Datanode cuối cùng sẽ gửi lại cho các Datanode trước đó xác nhận tình trạng
thành công. Nếu có bất ký một DataNode nào bị lỗi trong quá trình ghi dữ liệu, client
sẽ tiến hành xác nhận lại các DataNode đã lưu thành công bản sao của block và thực
hiện hành vi ghi lại block bị lỗi trên DataNode.
Bước 5: Sau khi tất cả các block của file đều được ghi lên các Datanode, client sẽ
thực hiện một thông điệp báo cho NameNode nhằm cập nhật lại danh sách các block
của file vừa tạo. Thông tin Mapping từ Block Id sang danh sách các Data Node lưu
trữ sẽ được NameNode tự động cập nhật bằng các định kỳ các Datanode sẽ gửi báo
cáo cho NameNode danh sách các block mà nó quản lý.
Nhận xét: cũng giống như trong quá trình đọc, client sẽ trực tiếp ghi dữ liệu lên các
DataNode mà không cần phải thông qua NameNode. Một đặc điểm nổi trội nữa là khi
client ghi một block với chỉ số replication là n, tức nó cần ghi block lên n DataNode,
nhờ cơ chế luân chuyển block dữ liệu qua ống dẫn (pipe) nên lưu lượng dữ liệu cần
write từ client sẽ giảm đi n lần, phân đều ra các DataNode trên cluster.

1.2.2.2 Block size

Hình 1-6 Kích thước Blocks trong HDFS

 HDFS cũng chia file ra thành các block, và mỗi block này sẽ được lưu trữ trên
Datanode thành một file riêng biệt trên hệ thống file local của nó. Đây cũng sẽ là đơn
vị trao đổi dữ liệu nhỏ nhất giữa HDFS và client của nó. Block size là một trong
những điểm quan trọng trong thiết kế HDFS. Block size mặc định của HDFS là
64MB, nhưng thông thường trên các hệ thống lớn người ta dùng block size là 128
MB, lớn hơn block size của các hệ thống file truyền thống rất nhiều.
Việc sử dụng block size lớn, tức sẽ giảm số lượng block của một file, mang lại
một số thuận lợi. Đầu tiên, nó sẽ làm giảm nhu cầu tương tác với NameNode của
client vì việc đọc/ghi trên một block chỉ cần một lần tương tác với NameNode để lấy
Block ID và nơi lưu block đó.
Thứ hai là việc cung cấp bản sao cho các khối dữ liệu rất đơn giản, do đó có thể
đạt được khả năng chịu lỗi và tính sẵn sàng cao trong cụm Hadoop. Theo mặc định,
mỗi khối dữ liệu được sao chép ba lần trên các máy vật lý có sẵn trong cụm. Trong
trường hợp nếu khối dữ liệu không có sẵn bằng cách nào đó, bản sao của cùng một
khối dữ liệu cũng có thể được cung cấp từ một số nút khác có sẵn trong cụm của nơi
tạo bản sao. Một khối bị hỏng được sao chép sang một số máy trực tiếp khác chỉ để
duy trì hệ số sao chép ở trạng thái bình thường. Một số ứng dụng quan trọng có thể
yêu cầu sao chép cao để cung cấp tính khả dụng cao hơn và phân bổ tải đọc trên cụm.
Thứ ba, việc giảm số lượng block của một file sẽ làm giảm khối lượng metadata
trên NameNode. Điều này giúp chúng ta có thể đưa toàn bộ metadata vào bộ nhớ
chính.
1.2.2.3 Metadata
Metadata hay còn gọi là siêu dữ liệu, được hiểu là dạng dữ liệu mô tả chi tiết thông
tin về dữ liệu. Siêu dữ liệu tóm tắt thông tin cơ bản về dữ liệu, điều này có thể giúp
việc tìm kiếm, sử dụng và tái sử dụng các phiên bản dữ liệu cụ thể dễ dàng hơn.
Trong Hadoop , Namenode gồm có 2 loại metadata:
- File System Metadata: Nó có tất cả thông tin về tệp , tức là quyền đối với
tệp cụ thể, kích thước, thời gian, hệ số sao chép và nó tiếp tục phần chia
thành hai loại. Thứ nhất Fsimage: chứa tất cả các thuộc tính hệ thống tệp và
 thông tin về các khối dữ liệu được ánh xạ. Thứ hai là Edit-logs: bất kỳ thao
tác như viết , xóa, cập nhật, v,v.. tất cả đều được lưu trữ trong nhật ký của
hệ thống file local của Namenode.
- Bitmap: Nó có thông tin về tất cả ánh xạ giữa blocks và Datanode, tức là
block nào sẽ trên Datanode nào. Metadata này sẽ không bao giờ tồn tại trên
Disk.
1.2.3 Khả năng chịu và sửa lỗi của HDFS
1.2.3.1 Khả năng tự phục hồi nhanh chóng
Các NameNode và DataNode đều được thiết kế để có thể phục hồi nhanh chóng.
Trong trường hợp NameNode bị ngừng hoạt động, chỉ cần phục hồi lại NameNode mà
không cần phải restart tất cả các DataNode. Sau khi NameNode phục hồi nó sẽ tự
động liên lạc lại với các DataNode và hệ thống lại phục hồi. Nếu một DataNode bất
kỳ bị ngừng hoạt động, ta chỉ cần khởi động lại DataNode này và nó sẽ tự động liên
lạc với NameNode thông qua các HeartBeat để cập nhật lại tình trạng của mình trên
NameNode.
1.2.3.2 Nhân bản các block
Như đã trình bày ở các phần trên, mỗi block dữ liệu trên HDFS được lưu trữ trùng
lặp trên các DataNode khác nhau thuộc các Rack khác nhau. Người dùng (hoặc ứng
dụng) có thể gán các chỉ số mức độ nhân bản (replication level) khác nhau cho các file
khác nhau, tuỳ vào mức độ quan trọng của file đó, chỉ số mặc định là ba. Nhờ vậy, khi
một hay một số DataNode bị ngừng hoạt động, ta vẫn còn ít nhất một bản sao của
block.
1.2.3.3 Nhân bản các Metata
Khi Namenode gặp phải sự cố gì đó (cả phần cứng hay phần mềm) thì tất cả các
file trên hệ thống HDFS đều sẽ bị mất, vì ta không có cách nào để tái cấu trúc lại các
file từ các block được lưu trên các DataNode. Đó là lý do có sự tồn tại của
SecondaryNamenode. SecondaryNamenode là một node duy nhất trên Hadoop
cluster. SecondaryNamenode không đóng vai trò như một NameNode, nhiệm vụ của
SecondaryNamenode là lưu trữ lại checkpoint (trạng thái thống nhất của metadata)
mới nhất trên NameNode. Khi NameNode gặp sự cố, thì checkpoint mới nhất này sẽ
được import vào NameNode và NameNode sẽ trở lại hoạt động như thời điểm
SecondaryNamenode tạo checkpoint. SecondaryNamenode thực hiện nhiệm vụ của nó
thông qua một daemon tên secondarynamenode. SecondaryNamenode không cập nhật
checkpoint bằng cách tải toàn bộ metadata trên NameNode về. Thực chất,
SecondaryNamenode chỉ tải phần EditLog từ NameNode về và thực hiện việc “trộn”
EditLog này vào trong phiên bản metadata trước đó. Cấu trúc của metadata trên
SecondaryNamenode cũng giống như cấu trúc metadata trên NameNode.
1.2.3.4 Toàn vẹn dữ liệu trên HDFS
HDSF đảm bảo tính toàn vẹn của dữ liệu bằng cách thực hiện tạo checksum tất cả
dữ liệu ghi lên nó và sẽ kiểm tra lại checksum mỗi khi đọc dữ liệu. DataNode chịu
trách nhiệm kiểm tra tính toàn vẹn dữ liệu bằng cách kiểm tra checksum trước khi lưu
trữ dữ liệu và checksum của nó. Điều này được thực hiện khi DataNode nhận được dữ
liệu từ client hay từ các DataNode khác trong quá trình nhân bản các block thông qua
data pile.
1.2.4 Lập lịch trong Hadoop
1.2.4.1 FIFO Scheduler
FIFO nghĩa là First In First Out, các job submit trước sẽ thực hiện trước, giống
như trong hàng đợi. Hình dưới mô tả scheduler này:
 Hình 1-7 FIFO Scheduler
Như chúng ta thấy thì job1 được submit trước và ngay lập tức chạy luôn, đồng thời
chiếm toàn bộ tài nguyên của cụm, job2 submit ngay sau đó nhưng nó phải chờ đến
khi job1 chạy xong thì mới có tài nguyên để chạy. Điều này khó có thể áp dụng trong
thực tế, đối với các cụm dữ liệu lớn chia sẻ tài nguyên, Capacity hoặc Fair Scheduler
thường được dùng hơn là dạng FIFO đơn giản này. Cả 2 policies trên cho phép người
dùng chạy nhiều long-running jobs cũng như thực hiện các query khác đồng thời.

1.2.4.2 Capacity Scheduler

Capacity Scheduler chia tài nguyên trong YARN thành các queue, ứng dụng sẽ
submit job lên các queue này trong YARN, các queue sẽ được cấu hình một lượng tài
nguyên nhất định và có thể sử dụng nhiều hơn up-to max cấu hình nếu có nhiều tài
nguyên đang free.
 Hình 1-8 Capacity Scheduler
Như trong hình cụm chia làm hai queue A và B, có 2 job submit tương ứng 2 queue
này, và chạy ngay khi được submit, điều này khắc phục tồn tại ở FIFO Scheduler, các
job có thể chạy song song đồng thời, cả job lớn lẫn job nhỏ. Tuy nhiên chúng ta sẽ
phải cân đối tài nguyên giữa các queue, phân chia hợp lý để đảm bảo các queue đủ tài
nguyên chạy job của mình, vì tài nguyên là hữu hạn nên khi tăng queue này đồng
nghĩa với việc phải giảm tài nguyên của queue khác.
Vì thực tế có thể tại một thời điểm một queue dùng nhiều hơn lượng tài nguyên được
cấp phát (có nhiều job lớn, dữ liệu về nhiều,…) nên Capacity Scheduler có cấu hình
min và max capacity cho một queue, min là lượng tài nguyên đảm bảo chắc chắn
queue này được có, max là lượng tài nguyên queue có thể tăng thêm trong trường hợp
các queue khác không sử dụng đến. Tổng cấu hình min capacity của các queue là
100% tài nguyên cụm.

1.2.4.3 Fair Scheduler

 Nếu như Capacity Scheduler yêu cầu bạn phải dự trữ trước 1 lượng tài nguyên cho
các queue thì Fair Scheduler không như vậy. Fair Scheduler sẽ tự động cân bằng tài
nguyên giữa các queue running. Nếu job đầu tiên submit, nó sẽ chiếm toàn bộ tài
nguyên trong cụm, đến khi có job 2 submit, tài nguyên sẽ dần cân bằng lại 50% giữa 2
queue.

Hình 1-9 Capacity Scheduler

Như mình mô tả thì cụm của bạn có 2 queue là queue A và queue B cấu hình 50% tài
nguyên cụm, sử dụng fair scheduler. Job 1 đầu tiên được submit vào queue A và sử
dụng toàn bộ tài nguyên trong cụm, sau đó job 2 submit vào queue B, lúc này job 1
đang chạy chiếm full tài nguyên cụm, YARN sẽ phải chờ đến khi một số container
nhỏ của job1 finished rồi cấp container free đó cho job 2 chạy. Sau một khoảng thời
gian thì job 1 và job 2 đều chiếm 50% tài nguyên cụm, tương ứng full tài nguyên của
queue A và B. Tiếp đó job 3 được submit lên queue B, lúc này job 3 cũng chờ job 2
free tài nguyên để sử dụng, sau đó job 2 và 3 chia nhau 50% tài nguyên của queueB.
 Cơ chế Fair Scheduler cho phép các queue đều được chia sẻ tài nguyên một cách
công bằng, các queue running luôn được cấp tài nguyên đảm bảo theo như cấu hình
nhỏ nhất. Các queue đều có thuộc tính weights, ví dụ queue A và queue B ở trên có tỉ
lệ là 50:50 nếu như weights không được xác định từ đầu, weight chỉ ra tương quan tỷ
lệ tài nguyên giữa các queue chứ không phải là tỷ lệ phần trăm, nếu queue A có
weight là 2 và queue B có weight 3 thì tỷ lệ tài nguyên sử dụng đồng thời giữa 2
queue là 2:3.

1.3 MapReduce
1.3.1 Giới thiệu
MapReduce là một mô hình hoặc mẫu lập trình trong khuôn khổ Hadoop được sử
dụng để truy cập dữ liệu lớn được lưu trữ trong Hệ thống tệp Hadoop (HDFS). Nó là
một thành phần cốt lõi, không thể thiếu đối với hoạt động của khung Hadoop.
MapReduce hỗ trợ xử lý đồng thời bằng cách chia petabyte dữ liệu thành các phần
nhỏ hơn và xử lý chúng song song trên các máy chủ Hadoop. Cuối cùng, nó tổng hợp
tất cả dữ liệu từ nhiều máy chủ để trả lại đầu ra hợp nhất cho ứng dụng.
Ví dụ: một cụm Hadoop với 20.000 máy chủ hàng hóa rẻ tiền và khối dữ liệu 256 MB
trong mỗi máy chủ, có thể xử lý khoảng 5 TB dữ liệu cùng một lúc. Điều này làm
giảm thời gian xử lý so với xử lý tuần tự một tập dữ liệu lớn như vậy.Với
MapReduce, thay vì gửi dữ liệu đến nơi ứng dụng, logic được thực thi trên máy chủ
nơi dữ liệu đã lưu trữ, để đẩy nhanh quá trình xử lý. Truy cập và lưu trữ dữ liệu dựa
trên disk-based, thường được lưu trữ dưới dạng tệp chứa dữ liệu có cấu trúc, bán cấu
trúc hoặc phi cấu trúc và đầu ra cũng được lưu trữ trong tệp.
MapReduce đã từng là phương pháp duy nhất mà qua đó dữ liệu được lưu trữ trong
HDFS có thể được truy xuất, nhưng điều đó không còn đúng nữa. Ngày nay, có các hệ
thống dựa trên truy vấn khác như Hive và Pig được sử dụng để truy xuất dữ liệu từ
HDFS bằng cách sử dụng các câu lệnh giống như SQL. Tuy nhiên, chúng thường
chạy cùng với các công việc được viết bằng mô hình MapReduce. Đó là bởi vì
MapReduce có những lợi thế độc đáo.
1.3.2 Kiến trúc và cơ chế của MapReduce

Hình 1-7 Kiến trúc của MapReduce

MapReduce là một khung lập trình cho phép chúng ta thực hiện xử lý song song và
phân tán trên các tập dữ liệu lớn trong môi trường phân tán.
● MapReduce gồm hai nhiệm vụ chính và riêng biệt: Map và Reduce
● Như cái tên MapReduce gợi ý, giai đoạn Reduce diễn ra sau khi giai đoạn ánh xạ
đã hoàn thành.
● Vì vậy, đầu tiên là công việc Map, trong đó một block dữ liệu được đọc và xử lý
để tạo ra các cặp key-value làm đầu ra trung gian.
● Đầu ra của Mapper hoặc công việc ánh xạ (cặp key-value) là đầu vào cho Reducer.
● Reducer nhận cặp key-value từ nhiều công việc của Map.
● Sau đó, bộ reducer tổng hợp các bộ dữ liệu trung gian đó (cặp key-value trung
gian) thành một tập hợp các bộ dữ liệu hoặc cặp key-value nhỏ hơn, đây là đầu ra
cuối cùng.
MapReduce chủ yếu gồm 3 lớp sau:
● Mapper Class
Giai đoạn đầu tiên trong xử lý dữ liệu bằng MapReduce là Lớp ánh xạ. Tại đây,
RecordReader xử lý từng bản ghi đầu vào và tạo cặp key-value tương ứng. Mapper
của Hadoop lưu dữ liệu trung gian này vào local disk. Input Split là biểu diễn logic
của dữ liệu, nó đại diện cho một khối công việc chứa một tác vụ duy nhất của Map
 trong chương trình MapReduce. RecordReader tương tác với phần input split và
chuyển đổi dữ liệu thu được dưới dạng cặp key-value.
● Reducer Class
Đầu ra Intermediate được tạo ra từ trình ánh xạ được đưa lên bộ Reducer và tạo
đầu ra cuối cùng sau đó được lưu trữ trong HDFS.
● Driver Class
Thành phần chính trong công việc MapReduce là Driver class. Nó chịu trách
nhiệm thiết lập Công việc MapReduce để chạy Hadoop. Chúng ta chỉ định tên của
các Lớp Mapper và Reducer với các loại dữ liệu và tên công việc tương ứng của
chúng.
1.3.3 MapReduce với bài toán Word Count

Hình 1-7 MapReduce xử lý bài toán Word Count

● Đầu tiên, chúng ta chia đầu vào thành ba phần như trong hình. Điều này sẽ phân
phối công việc giữa tất cả các map Nodes.
● Sau đó, chúng ta mã hóa các từ trong mỗi trình ánh xạ và cung cấp giá trị mã hóa
cứng (1) cho từng mã thông báo hoặc từ, đưa ra giá trị mã hóa cứng bằng 1 là mỗi
từ tự nó sẽ xuất hiện một lần.
● Bây giờ, một danh sách cặp key-value sẽ được tạo. Vì vậy, đối với dòng đầu tiên
(Dear Bear River), chúng ta có 3 cặp key-value – Dear, 1; Gấu, 1; River, 1. Quá
trình xử lý mapping vẫn giống nhau trên tất cả các nút.
 ● Sau giai đoạn ánh xạ, một quá trình phân vùng diễn ra trong đó sắp xếp và xáo
trộn xảy ra để tất cả các bộ dữ liệu có cùng key được gửi đến bộ reducer tương
ứng.
● Vì vậy, sau giai đoạn sắp xếp và xáo trộn, mỗi bộ reducer sẽ có một keyduy nhất
và danh sách các giá trị tương ứng với chính key đó. Ví dụ: Gấu, [1,1]; Ô tô,
[1,1,1].., v.v.
● Bây giờ, mỗi Reducer đếm các giá trị có trong danh sách giá trị đó. Như thể hiện
trong hình, bộ reducer nhận danh sách các giá trị [1,1] cho key Bear. Sau đó, nó
đếm số cái trong chính danh sách và đưa ra kết quả cuối cùng là – Bear, 2.
● Cuối cùng, tất cả các cặp key/value đầu ra sẽ được thu thập và ghi vào tệp đầu ra.

1.3.4 Ưu điểm của MapReduce

1.3.4.1 Xử lý song song

Trong MapReduce, chúng ta đang phân chia công việc cho nhiều nút và mỗi nút
làm việc đồng thời với một phần của công việc. Vì vậy, MapReduce dựa trên mô
hình chia để trị giúp chúng ta xử lý dữ liệu bằng các máy khác nhau. Vì dữ liệu
được xử lý bởi nhiều máy thay vì một máy song song, thời gian xử lý dữ liệu sẽ
giảm đi rất nhiều như trong hình bên dưới.
 Hình 1-8 Cách xử lý Traditional và MapReduce

1.3.4.2 Vị trí dữ liệu

Thay vì di chuyển dữ liệu đến đơn vị xử lý, chúng ta đang di chuyển đơn vị xử lý đến
dữ liệu trong MapReduce Framework. Trong hệ thống truyền thống, chúng ta thường
mang dữ liệu đến bộ xử lý và xử lý nó. Tuy nhiên, khi dữ liệu tăng lên và trở nên rất
lớn, việc mang lượng dữ liệu khổng lồ này đến bộ xử lý đã đặt ra các vấn đề sau:

● Di chuyển dữ liệu khổng lồ để xử lý rất tốn kém và làm giảm hiệu suất mạng.
● Quá trình xử lý mất thời gian vì dữ liệu được xử lý bởi một đơn vị duy nhất trở
thành nút cổ chai.
● Nút chính có thể bị quá tải và có thể bị lỗi.

Giờ đây, MapReduce cho phép chúng ta khắc phục các vấn đề trên bằng cách đưa đơn
vị xử lý dữ liệu vào. Vì vậy, như bạn có thể thấy trong hình trên, dữ liệu được phân
phối giữa nhiều nút trong đó mỗi nút xử lý một phần dữ liệu nằm trên đó. Điều này
cho phép chúng ta có những lợi thế sau:

● Việc chuyển đơn vị xử lý sang dữ liệu rất hiệu quả về chi phí.
● Thời gian xử lý giảm xuống do tất cả các nút đang làm việc song song với phần dữ
liệu của chúng.
● Mỗi nút nhận một phần dữ liệu để xử lý và do đó, không có khả năng nút bị quá
tải.
 CHƯƠNG 2

TỔNG QUAN VỀ SPARK STREAMING

2.1 Giới thiệu về Spark

Apache Spark bắt đầu như một dự án nghiên cứu tại UC Berkeley AMPLab vào
năm 2009 và được mã nguồn mở vào đầu năm 2010. Nhiều ý tưởng đằng sau hệ thống
này đã được trình bày trong các tài liệu nghiên cứu khác nhau trong nhiều năm.Sau khi
được phát hành, Spark đã phát triển thành một cộng đồng nhà phát triển rộng lớn và
chuyển sang Quỹ phần mềm Apache vào năm 2013. Ngày nay, dự án được cộng tác phát
triển bởi một cộng đồng gồm hàng trăm nhà phát triển từ hàng trăm tổ chức. Apache
Spark đã trở nên phổ biến nhờ có sự tham gia của hơn 500 lập trình viên từ khắp các công
ty lớn nhất thế giới và hơn 225.000 thành viên của cơ sở người dùng Apache Spark.
Alibaba, Tencent và Baidu chỉ là một vài ví dụ nổi tiếng về các công ty thương mại điện
tử sử dụng Apache Spark để điều hành doanh nghiệp của họ nói chung.

Apache Spark là một hệ thống xử lý phân tán, nguồn mở được sử dụng cho khối lượng
công việc dữ liệu lớn. Nó sử dụng bộ nhớ đệm trong bộ nhớ đệm và thực thi truy vấn
được tối ưu hóa để truy vấn nhanh đối với dữ liệu có kích thước bất kỳ. Nói một cách đơn
giản, Spark là một công cụ nhanh và chung để xử lý dữ liệu quy mô lớn .Phần nhanh có
nghĩa là nó nhanh hơn các phương pháp trước đây để làm việc với Dữ liệu lớn như
MapReduce cổ điển . Bí quyết để nhanh hơn là Spark chạy trên bộ nhớ (RAM) và điều đó
làm cho quá trình xử lý nhanh hơn nhiều so với trên ổ đĩa.Phần chung có nghĩa là nó có
thể được sử dụng cho nhiều thứ như chạy SQL phân tán, tạo đường dẫn dữ liệu, nhập dữ
liệu vào cơ sở dữ liệu, chạy thuật toán Machine Learning, làm việc với biểu đồ hoặc
luồng dữ liệu, v.v.

2.2 Các thành phần của Spark

 Hình 2-1 Các thành phần của Spark

2.2.1 Apache Spark Core

Spark Core là công cụ thực thi chung cơ bản cho nền tảng Spark mà tất cả các chức năng
khác được xây dựng trên đó. Nó cung cấp bộ dữ liệu tham chiếu và tính toán trong bộ
nhớ trong các hệ thống lưu trữ bên ngoài. Là công cụ cơ sở để xử lý dữ liệu phân tán và
song song với quy mô lớn. Nó chịu trách nhiệm về:

- Quản lý bộ nhớ và phục hồi lỗi.

- Lập lịch , phân phối và giám sát công việc trên một cụm.

- Tương tác với hệ thống lưu trữ.

Spark giới thiệu một khái niệm về RDD(Resilient Distributed Datasets) có khả năng chịu
lỗi không thay đổi và vận hành song song. RDD có thể chứa bất kỳ loại đối tượng nào và
được tạo bằng cách tải tập dữ liệu bên ngoài hoặc phân phối bộ dữ liệu từ chương trình
điều khiển. Mỗi và mọi tập dữ liệu trong Spark RDD được phân vùng hợp lý trên nhiều
máy chủ để chúng có thể được tính toán trên các nút khác nhau của cụm.
RDD hỗ trợ hai loại hoạt động:
- Transformations: là các hoạt động (chẳng hạn như map, filter, union, v.v.) được
thực hiện trên một RDD và tạo ra một RDD mới chứa kết quả.

Hình 2-2 Spark RDD - Narrow Transformation

Đó là kết quả của map, filter và sao cho dữ liệu chỉ từ một phân vùng duy nhất. Một RDD
đầu ra có các phân vùng với các bản ghi bắt nguồn từ một phân vùng duy nhất trong
RDD chính. Chỉ một tập hợp con giới hạn của các phân vùng được sử dụng để tính toán
kết quả.
 Hình 2-3 Spark RDD - Wide Transformation

Nó là kết quả của các hàm giống như groupByKey() và reduceByKey(). Dữ liệu cần thiết
để tính toán các bản ghi trong một phân vùng có thể nằm trong nhiều phân vùng của
RDD gốc. Phép biến đổi này còn được gọi là phép biến đổi shuffle vì chúng có thể hoặc
không phụ thuộc vào phép shuffle.

- Actions: là các hoạt động (chẳng hạn như reduce, count, v.v.) trả về một giá trị
sau khi chạy tính toán trên RDD. Nó thực thi bằng Lineage graph để tải dữ liệu vào RDD
gốc, thực hiện tất cả các phép biến đổi trung gian và trả về kết quả cuối cùng cho chương
trình. Trình điều khiển hoặc ghi dữ liệu đó ra hệ thống tệp.

Các phép biến đổi trong Spark rất trễ nghĩa là chúng không tính toán kết quả ngay lập
tức. Thay vào đó họ chỉ nhớ thao tác sẽ được thực hiện và tập dữ liệu mà thao tác được
thực hiện. Các phép biến đổi chỉ được thực sự được tính toán khi một hành động được
gọi và kết quả được trả về chương trình điều khiển. Thiết kế này cho phép Spark chạy
hiệu quả hơn.Spark RDD cũng có thể được lưu trữ và phân vùng thủ công . Bộ nhớ đệm
có lợi khi chúng ta sử dụng RDD nhiều lần. Và phân vùng thủ công là rất quan trọng để
cân bằng chính xác các phân vùng. Nói chung, các phân vùng nhỏ hơn cho phép phân
phối dữ liệu RDD đồng đều hơn, giữa nhiều người thực thi hơn. Do đó, ít phân vùng hơn
giúp công việc trở nên dễ dàng.

Các tính năng của Spark RDD:

- Phân vùng là đơn vị cơ bản của song song trong Spark RDD. Mỗi phân vùng là
một bộ phận hợp lý của dữ liệu có thể thay đổi. Người ta có thể tạo một phân vùng
thông qua một số phép biến đổi trên các phân vùng hiện có.
- Tính bất biến:Dữ liệu an toàn để chia sẻ trên các quy trình. Nó cũng có thể được
tạo hoặc truy xuất bất cứ lúc nào, giúp dễ dàng lưu vào bộ đệm, chia sẻ và sao
chép. Vì vậy, đó là một cách để đạt được sự nhất quán trong tính toán.
- Tính toán trong bộ nhớ :Spark RDD có một cung cấp về tính toán trong bộ nhớ .
Nó lưu trữ các kết quả trung gian trong bộ nhớ phân tán (RAM) thay vì bộ nhớ ổn
định (DISK).

- Khả năng chịu lỗi :Spark RDD có khả năng chịu lỗi vì chúng theo dõi thông tin
dòng dữ liệu để tự động xây dựng lại dữ liệu bị mất khi gặp sự cố. Họ xây dựng lại
dữ liệu bị mất do lỗi bằng cách sử dụng dòng, mỗi RDD nhớ cách nó được tạo từ
các bộ dữ liệu khác (bằng các phép biến đổi như map, join hoặc groupBy) để tự
tạo lại.

Một số hạn chế của Spark RDD:

 Hình 2-4 Hạn chế của Apache Spark RDD

- Khi làm việc với dữ liệu có cấu trúc, RDD không thể tận dụng lợi thế của trình
tối ưu hóa nâng cao của Spark bao gồm trình tối ưu hóa Catalyst và công cụ thực thi
Tungsten . Các nhà phát triển cần tối ưu hóa từng RDD dựa trên các thuộc tính của nó.
- Giới hạn về hiệu suất: Là các đối tượng JVM trong bộ nhớ, RDD liên quan đến
chi phí chung của Garbage Collection và Java Serialization rất tốn kém khi dữ liệu tăng
lên.
- Giới hạn về lưu trữ : RDD xuống cấp khi không có đủ bộ nhớ để lưu trữ chúng.
Người ta cũng có thể lưu trữ phân vùng RDD đó trên disk khi hết dung lượng trên RAM.
Kết quả là, nó sẽ cung cấp hiệu suất tương tự như các hệ thống song song dữ liệu hiện tại.

2.2.2 Spark SQL

Spark SQL tập trung vào việc xử lý dữ liệu có cấu trúc, sử dụng phương pháp tiếp
cận khung dữ liệu được mượn từ các ngôn ngữ R và Python (trong Pandas). Như tên gọi,
Spark SQL cũng cung cấp giao diện với cú pháp SQL để truy vấn dữ liệu, mang sức
mạnh của Apache Spark đến các nhà phân tích dữ liệu cũng như các nhà phát triển.

Bên cạnh khả năng hỗ trợ SQL, Spark SQL cung cấp một giao diện tiêu chuẩn để đọc và
ghi vào các kho dữ liệu khác bao gồm JSON, HDFS, Apache Hive, JDBC, Apache ORC
và Apache Parquet, tất cả đều được hỗ trợ trực tiếp. Các cơ sở dữ liệu phổ biến khác như
Apache Cassandra, MongoDB, Apache Hbase,… cũng được hỗ trợ thông qua các trình
kết nối riêng biệt từ hệ sinh thái Spark Packages. Cung cấp một kiểu data abstraction mới
(SchemaRDD) nhằm hỗ trợ cho cả kiểu dữ liệu có cấu trúc (structured data) và dữ liệu
nửa cấu trúc (semi-structured data – thường là dữ liệu dữ liệu có cấu trúc nhưng không
đồng nhất và cấu trúc của dữ liệu phụ thuộc vào chính nội dung của dữ liệu ấy). Spark
SQL hỗ trợ DSL (Domain-specific language) để thực hiện các thao tác trên DataFrames
bằng ngôn ngữ Scala, Java hoặc Python và nó cũng hỗ trợ cả ngôn ngữ SQL với giao diện
command-line và ODBC/JDBC server
2.2.3 Spark Streaming
 Spark Streaming đã được thêm vào Apache Spark vào năm 2013, một phần mở
rộng của API Spark cung cấp khả năng xử lý luồng dữ liệu trực tiếp có thể mở rộng,
thông lượng cao và chịu lỗi. Việc nhập dữ liệu có thể được thực hiện từ nhiều nguồn như
Kafka, Apache Flume , Amazon Kinesis hoặc ổ cắm TCP và quá trình xử lý có thể được
thực hiện bằng các thuật toán phức tạp được thể hiện bằng các hàm cấp cao như
map,reduce, join. Cuối cùng, dữ liệu đã xử lý có thể được đẩy ra hệ thống tệp, cơ sở dữ
liệu và bảng điều khiển trực tiếp

Spark Streaming được sử dụng để thực hiện việc phân tích stream bằng việc coi
stream là các mini-batches và thực hiệc kỹ thuật RDD transformation đối với các dữ liệu
mini-batches này. Qua đó cho phép các đoạn code được viết cho xử lý batch có thể được
tận dụng lại vào trong việc xử lý stream, làm cho việc phát triển lambda architecture
được dễ dàng hơn. Tuy nhiên điều này lại tạo ra độ trễ trong xử lý dữ liệu (độ trễ chính
bằng mini-batch duration) và do đó nhiều chuyên gia cho rằng Spark Streaming không
thực sự là công cụ xử lý streaming giống như Storm hoặc Flink.Thành phần này cho phép
Spark xử lý dữ liệu truyền phát theo thời gian thực. Dữ liệu có thể được nhập từ nhiều
nguồn như Kafka, Flume và HDFS (Hệ thống tệp phân tán Hadoop). Sau đó, dữ liệu có
thể được xử lý bằng các thuật toán phức tạp và được đẩy ra hệ thống tệp, cơ sở dữ liệu và
bảng điều khiển trực tiếp.

2.2.3.1 Nhu cầu Streaming trong Apache Spark

Để xử lý dữ liệu, hầu hết các hệ thống xử lý luồng truyền thống được thiết kế với mô
hình toán tử liên tục, hoạt động như sau
- Dữ liệu truyền trực tuyến được nhận từ các nguồn dữ liệu (ví dụ:dữ liệu đo từ xa
của hệ thống, dữ liệu thiết bị IoT, v.v.) vào một số hệ thống nhập dữ liệu như Apache
Kafka, Amazon Kinesis, v.v.
- Dữ liệu sau đó được xử lý song song trên một cụm.
- Kết quả được gửi cho các hệ thống bên dưới như HBase , Cassandra, v.v.
 Hình 2-5 Luồng xử lý của Spark Streaming

Kiến trúc truyền thống này cũng đã gặp phải một số thách thức với xu hướng ngày nay
hướng tới quy mô lớn hơn và phân tích thời gian thực phức tạp hơn:

- Phục hồi chậm trễ và thất bại một cách nhanh chóng:Trong thời gian thực, hệ
thống phải có khả năng phục hồi nhanh chóng và tự động sau các sự cố và sự chậm trễ để
cung cấp kết quả vốn là thách thức trong các hệ thống truyền thống do sự phân bổ tĩnh
của các toán tử liên tục cho các nút worker.
- Cân bằng tải: Trong một hệ thống vận hành liên tục, việc phân bổ tải xử lý không
đồng đều giữa các worker có thể gây ra tắc nghẽn. Hệ thống cần có khả năng tự động
điều chỉnh việc phân bổ tài nguyên dựa trên khối lượng công việc.

Tuy nhiên với kiến trúc Spark Streaming đã giải quyết những khó khăn trên :
- Việc chia dữ liệu thành các micro-batches nhỏ cho phép phân bổ tính toán chi
tiết cho các tài nguyên. Các nhiệm vụ của công việc sẽ được cân bằng tải một cách tự
nhiên giữa các workers, trong đó một số workers sẽ xử lý một số nhiệm vụ dài hơn trong
khi những workers khác sẽ xử lý nhiều nhiệm vụ ngắn hơn trong Spark Streaming.
- Trong Spark, tính toán rời rạc thành các tác vụ nhỏ có thể chạy ở mọi nơi mà
không ảnh hưởng đến tính chính xác. Vì vậy, các tác vụ bị lỗi, chúng ta có thể phân phối
đồng đều trên tất cả các nút khác trong cụm để thực hiện tính toán lại và phục hồi sau lỗi
nhanh hơn so với phương pháp truyền thống.
- Khả năng của Spark Streaming để xử lý hàng loạt dữ liệu và tận dụng công cụ
Spark dẫn đến thông lượng gần như cao hơn cho các hệ thống phát trực tuyến khác.
Spark Streaming có thể đạt được độ trễ thấp tới vài trăm milliseconds.
2.2.4 MLlib (Machine Learning Library)
Apache Spark được trang bị một thư viện phong phú được gọi là MLlib. Thư viện
này chứa một loạt các thuật toán học máy - phân loại, hồi quy, phân cụm. Nó cũng bao
gồm các công cụ khác để xây dựng, đánh giá và điều chỉnh ML Pipelines. Tất cả các
chức năng này giúp Spark mở rộng quy mô trên một cụm. Theo các so sánh benchmark
Spark MLlib nhanh hơn 9 lần so với phiên bản chạy trên Hadoop (Apache Mahout).

2.2.5 GraphX

Graphx là nền tảng xử lý đồ thị dựa trên Spark. Nó cung cấp các Api để diễn tả
các tính toán trong đồ thị bằng cách sử dụng Pregel Api. Việc sử dụng Graphx có thể
được nhìn thấy trong bạn bè của Facebook, kết nối của LinkedIn, bộ định tuyến internet.
Mặc dù khái niệm tính toán Graphx có vẻ rất đơn giản, nhưng các ứng dụng của Graphx
thực sự là vô hạn với các trường hợp sử dụng trong phát hiện ngân hàng, thị trường
chứng khoán.

Hình 2-6 Property Graph

GraphX mở rộng Spark RDD bằng Property Graph phân tán đàn hồi. Property Graph là
một đồ thị đa hướng có thể có nhiều cạnh song song. Mỗi cạnh và đỉnh có các thuộc tính
do người dùng xác định được liên kết với nó. Các cạnh song song cho phép nhiều quan
hệ giữa các đỉnh giống nhau

Các trường hợp sử dụng Graph Computation:

- Hệ thống phát hiện thảm họa:

Hình 2-7 Hệ thống phát hiện thảm họa

Graph có thể được sử dụng để phát hiện các thảm họa như bão, động đất, sóng thần, cháy
rừng và núi lửa để đưa ra các cảnh báo cảnh báo cho mọi người.

- Phát hiện gian lận tài chính:

Hình 2-8 Hệ thống phát hiện gian lận trong tài chính

Phân tích biểu đồ có thể được sử dụng để giám sát giao dịch tài chính và phát hiện những
người liên quan đến gian lận tài chính và rửa tiền.

- Phân tích kinh doanh:

Hình 2-9 Hệ thống phân tích kinh doanh

Biểu đồ, khi được sử dụng cùng với Machine Learning, sẽ giúp hiểu được xu hướng mua
hàng của khách hàng. Ví dụ: Uber, McDonald's, v.v.

- Hệ thống thông tin địa lý:

Hình 2-10 Hệ thống thông tin địa lý

Đồ thị được sử dụng nhiều để phát triển các chức năng trên hệ thống thông tin địa lý như
phân định lưu vực sông và dự báo thời tiết.

- Google Pregel

Hình 2-11 Hệ thống Google Pregel

Pregel là nền tảng có khả năng mở rộng và chịu lỗi của Google với API đủ linh hoạt để
thể hiện biểu đồ tùy ý thuật toán

Các tính năng của Spark Graphx:

- Tính linh hoat: Spark GraphX hoạt động với cả biểu đồ và tính toán. GraphX hợp
nhất ETL (Extract, Transform & Load), phân tích thăm dò và tính toán biểu đồ lặp trong
một hệ thống duy nhất. Chúng ta có thể xem cùng một dữ liệu dưới dạng cả biểu đồ,
chuyển đổi và nối các biểu đồ với RDD một cách hiệu quả và viết các thuật toán biểu đồ
lặp tùy chỉnh bằng cách sử dụng API Pregel.
 - Tốc độ: Spark GraphX cung cấp hiệu suất tương đương với các hệ thống xử lý đồ
thị chuyên dụng nhanh nhất. Nó có thể so sánh với các hệ thống đồ thị nhanh nhất trong
khi vẫn giữ được tính linh hoạt, khả năng chịu lỗi và dễ sử dụng của Spark.

- Phát triển thư viện thuật toán: Chúng ta có thể chọn từ thư viện thuật toán đồ thị
đang phát triển mà Spark GraphX cung cấp. Một số thuật toán phổ biến là page rank,
connected components, label propagation, SVD++.
2.3 Kiến trúc Spark

Hình 2-12 Kiến trúc của Apache Spark

Khi Driver Program trong kiến trúc Apache Spark thực thi, nó gọi chương trình thực của
một ứng dụng và tạo một SparkContext. SparkContext chứa tất cả các chức năng cơ bản.
Spark Driver bao gồm một số thành phần khác, bao gồm DAG Scheduler, Task
Scheduler, Backend Scheduler, and Block Manager, tất cả đều chịu trách nhiệm dịch mã
do người dùng viết thành các công việc thực sự được thực thi trên cụm.
Cluster Manager quản lý thực hiện các công việc khác nhau trong cụm. Spark Driver hoạt
động cùng với Cluster Manager để kiểm soát việc thực hiện nhiều công việc khác. Cluster
Manager làm nhiệm vụ phân bổ tài nguyên cho công việc. Khi công việc đã được chia
thành các công việc nhỏ hơn, sau đó được phân phối cho các nút worker, Spark Driver sẽ
kiểm soát quá trình thực thi.Nhiều workers node có thể được sử dụng để xử lý RDD được
tạo trong SparkContext và kết quả cũng có thể được lưu vào bộ đệm.

SparkContext nhận thông tin tác vụ từ Cluster Manager và đưa nó vào hàng đợi trên các
workers node.Chúng ta có thể tăng số lượng worker nếu chúng ta muốn cải thiện hiệu
suất của hệ thống. Bằng cách này, chúng ta có thể chia công việc thành các phần mạch
lạc hơn.

2.3.1 Spark Driver

Master Node xử lý trong trình điều khiển điều phối các workers và giám sát các nhiệm
vụ. Spark được chia thành các công việc và được lên lịch để thực thi trên các bộ thực thi
theo cụm. Spark contexts được trình điều khiển tạo để giám sát công việc đang hoạt động
trong một cụm cụ thể và để kết nối với cụm Spark. Trong sơ đồ, các chương trình trình
điều khiển gọi ứng dụng chính và tạo spark contexts(hoạt động như gateway) cùng giám
sát công việc đang hoạt động trong cụm và kết nối với Spark cluster. Mọi thứ được thực
hiện bằng spark contexts.

Mỗi Spark session có một mục trong Spark contexts. Spark drives bao gồm nhiều thành
phần hơn để thực hiện các công việc trong clusters, cũng như cluster managers. Khi một
quy trình được thực thi trong clusters, công việc được chia thành các giai đoạn với các
giai đoạn đạt được thành các tác vụ theo lịch trình.
2.3.2 Spark Executors

Người thực thi chịu trách nhiệm thực hiện một công việc và lưu trữ dữ liệu trong bộ đệm
ngay từ đầu. Người thi hành đăng ký đầu tiên với chương trình trình điều khiển ngay từ
đầu. Những người thực thi này có một số khe thời gian để chạy ứng dụng đồng thời.
Người thực thi chạy tác vụ khi nó đã tải dữ liệu và chúng được loại bỏ ở chế độ không
tải. Trình thực thi chạy trong quy trình Java khi dữ liệu được tải và xóa trong quá trình
thực thi tác vụ. Nhiệm vụ của người dùng được thực hiện trong quy trình Java.
2.3.3 Cluster Manager

Một chương trình trình điều khiển kiểm soát việc thực hiện các công việc và lưu trữ dữ
liệu trong bộ đệm. Ngay từ đầu, người thi hành đăng ký với trình điều khiển. Trình thực
thi này có một số khe thời gian để chạy ứng dụng đồng thời. Người thực thi đọc và ghi dữ
liệu bên ngoài ngoài việc phục vụ các yêu cầu của khách hàng. Một công việc được thực
hiện khi người thi hành đã tải dữ liệu và chúng đã được gỡ bỏ ở trạng thái nhàn rỗi. Trình
thực thi được phân bổ động và nó liên tục được thêm và xóa tùy thuộc vào thời gian sử
dụng. Chương trình trình điều khiển giám sát người thi hành khi họ thực hiện các tác vụ
của người dùng.
2.3.4 Worker Nodes

Các slave nodes hoạt động như những người thực thi, xử lý các tác vụ và trả kết quả trở
lại spark context. Master node đưa ra các nhiệm vụ cho Spark context và các worker
nodes thực hiện chúng. Chúng làm cho quy trình trở nên đơn giản hơn bằng cách tăng các
worker nodes (1 đến n) để xử lý song song càng nhiều công việc càng tốt bằng cách chia
công việc thành các công việc phụ trên nhiều máy. Một Spark worker giám sát các
worker nodes để đảm bảo rằng việc tính toán được thực hiện một cách đơn giản. Mỗi
worker node xử lý một tác vụ Spark. Trong Spark, một phân vùng là một đơn vị công
việc và được chỉ định cho một người thực thi cho mỗi người.
2.3.5 Phương thức thực hiện

Chúng ta có ba chế độ thực thi khác nhau: local, shares và dedicated. Những điều này xác
định vị trí thực tế của tài nguyên ứng dụng của bạn khi bạn chạy ứng dụng của mình.
Chúng ta có thể quyết định nơi lưu trữ resources locally, ở vị trí được shared hoặc ở vị trí
dedicated.

Cluster mode: là cách chạy ứng dụng Spark thường xuyên nhất. Ở chế độ cluster mode,
người dùng cung cấp tập lệnh JAR, tập lệnh Python hoặc tập lệnh R được biên dịch sẵn
cho người quản lý cụm. Sau khi trình quản lý cụm nhận được tập lệnh JAR, Python hoặc
R được biên dịch trước, quy trình trình điều khiển sẽ được khởi chạy trên một nút worker
bên trong cụm, ngoài các quy trình của trình thực thi. Điều này có nghĩa là trình quản lý
cụm phụ trách tất cả các quy trình liên quan đến ứng dụng Spark.

Client mode: Trái ngược với chế độ cluster mode, trong đó Spark driver vẫn còn trên
máy khách đã gửi ứng dụng, Spark driver bị xóa ở chế độ client mode và do đó chịu trách
nhiệm duy trì quy trình Spark driver trên máy khách. Các máy này, thường được gọi là
edge nodes hoặc maintained , được duy trì trên máy khách.

Local mode: Chế độ local mode chạy toàn bộ Spark Application trên một máy, trái
ngược với hai chế độ trước đó, chế độ này song song hóa Spark Application thông qua
các luồng trên máy đó. Do đó, chế độ local mode sử dụng các luồng thay vì các luồng
song song. Đây là một cách phổ biến để thử nghiệm với Spark.

2.4 Các tính năng của Spark

Apache Spark, một khung tính toán cụm phổ biến, được tạo ra để tăng tốc các ứng
dụng xử lý dữ liệu. Spark, cho phép các ứng dụng chạy nhanh hơn bằng cách sử dụng
điện toán cụm trong bộ nhớ, là một khung mã nguồn mở phổ biến. Cluster là tập hợp các
nút giao tiếp với nhau và chia sẻ dữ liệu. Do tính song song dữ liệu ẩn và khả năng chịu
lỗi, Spark có thể được áp dụng cho nhiều nhu cầu xử lý tuần tự và tương tác
 Hình 2-13 Tính năng của Apache Spark

● Speed: Spark hoạt động nhanh hơn tới 100 lần so với MapReduce để xử lý lượng
lớn dữ liệu. Nó cũng có thể chia dữ liệu thành các khối theo cách được kiểm soát.
● Powerful Caching: Khả năng lưu trữ bộ nhớ đệm và ổ cứng mạnh mẽ được cung
cấp bởi một lớp lập trình đơn giản.
● Deployment: Mesos, Hadoop thông qua YARN hoặc trình quản lý cụm riêng của
Spark đều có thể được sử dụng để triển khai nó.
● Real-Time: Do xử lý trong bộ nhớ, nó cung cấp khả năng tính toán thời gian thực
và độ trễ thấp.
● Polyglot: Ngoài Java, Scala, Python và R, Spark cũng hỗ trợ cả bốn ngôn ngữ này.
Bạn có thể viết mã Spark bằng bất kỳ ngôn ngữ nào trong số này. Spark cũng cung
cấp giao diện dòng lệnh trong Scala và Python.
 Chương 3

Xây dựng luồng Spark Streaming lưu trữ trên HDFS

3.1 Mô tả chung bài toán

Việc có một mô hình phân tích dữ liệu cũng đang là vấn đề được nhiều nhà thống
kê học quan tâm và thiết kế đặc biệt xây dựng mô hình phân tích cho một đối tượng cụ
thể. Chính vì vậy thông qua sử dụng các công cụ trong bigdata, từ đó sẽ xây dựng luồng
lưu trữ dữ liệu trên HDFS và phân tích dữ liệu về bệnh tim mạch dựa trên bộ dữ liệu có
trên Kaggle. Sau khi xử lý dữ liệu bằng python và lưu trữ trên HDFS, chúng ta sẽ dùng
Hive connect tới HDFS, dùng Superset để vẽ Dashboard phân tích về bệnh tim mạch qua
từng năm theo từng chỉ số.

3.1.1 Mô tả chi tiết bài toán

- Ưng dụng sẽ xử lý luồng dữ liệu sau:

 Dữ liệu sẽ được lấy trên Kaggle và sử dụng python để làm sạch dữ liệu.
 Spark streaming sẽ lấy dữ liệu trong Kafka ra, tiến hành trích xuất, biến đổi dữ
liệu bằng Spark SQL thành đúng định dạng và đẩy vào HDFS.
 Tiếp đó Hive sẽ connect tới HDFS để lấy dữ liệu đổ vào Superset để vẽ
Dashboard, từ đó sẽ được phân tích đánh giá thông qua các biểu đồ.
 Hình 3-1 Luồng xử lý dữ liệu Piperline

 Các công nghệ được sử dụng:

 Queue Store : Apache Kafka ( version 2.7.0 ).
 Data processing : Apache Spark–Spark Streaming (version 3.3.0).
 Backup File : Apache Hadoop-HDFS (version 3.3.3).
 Data Visualize : Superset (version 2.0.1).
 Programing Languages : Python , Java.

3.1.2 Một số ứng dụng liên quan

3.1.2.1 Kafka

Kafka ban đầu được phát triển tại LinkedIn và đã trở thành một dự án cấp cao nhất của
Apache trong năm 2011. Mục tiêu chính của Apache Kafka là trở thành một nền tảng
thống nhất có khả năng mở rộng để xử lý các luồng dữ liệu thời gian thực.

Kafka là một hệ thống message theo cơ chế Pub-Sub. Nó cho phép các nhà sản xuất (gọi
là producer) viết các message vào Kafka mà một, hoặc nhiều người tiêu dùng (gọi là
consumer) có thể đọc, xử lý được những message đó. Các message được gửi tới Kafka
theo Topic, các Topic giống như là các kênh lưu trữ message từ Producer gửi đến Kafka,
người tiêu dùng (Consumer) đăng kí một hoặc nhiều Topic để tiêu thụ những message đó.

Kafka thường được sử dụng cho 2 mục đích chính sau:

 Xây dựng các pipeline stream dữ liệu theo thời gian thực để nhận dữ liệu giữa các
hệ thống hoặc ứng dụng một cách đáng tin cậy.
 Xây dựng các ứng dụng stream theo thời gian thực để biến đổi hoặc ánh xạ đến
các stream của dữ liệu.

3.1.2.1.1 Kiến trúc của Kafka

 Hình 3-2 Kiến trúc Kafka

 Producer : producer sẽ gửi hoặc ghi data/messages đến topic trong cluster. Sau
đó, khi dữ liệu được gửi đến partition của topic được lưu trữ tại Broker. Để lưu trữ
một lượng dữ liệu khổng lồ, các producer khác nhau trong một ứng dụng sẽ gửi dữ
liệu đến cụm Kafka.
 Messages: Messages đơn thuần là byte array và developer có thể sử dụng chúng
để lưu bất kì object với bất kì format nào - thông thường là String, JSON và Avro.
 Topic: Một topic là một category hoặc feed name nơi mà record được publish.
Trong Apache Kafka, có thể có nhiều topics trong một cluster Mỗi topic sẽ quy
định các loại thông điệp khác nhau.
 Partitions: Data hoặc message được chia thành các phần nhỏ, được gọi là
partitions. Mỗi partition chứa dữ liệu bên trong nó có giá trị offset. Dữ liệu luôn
được ghi một cách tuần tự. Chúng ta có thể có vô số partition với giá trị offset vô
hạn. Tuy nhiên, không đảm bảo rằng thông báo sẽ được ghi vào partition nào.
 Consumers : Consumer là người đọc hoặc sử dụng message từ Kafka cluster. Một
consumer có thể là bất kì ứng dụng nào có chức năng subscribe vào một topic và
 sử dụng các message. Cái hay của Kafka là mỗi consumer sẽ biết nơi chúng cần sử
dụng dữ liệu.
 Broker: Kafka cluster là một set các server mỗi một set này được gọi là 1 broker.
Broker là cầu nối giữa consumer và producer. Nếu một producer muốn ghi dữ liệu
vào cụm, nó sẽ được gửi đến máy chủ Kafka. Tất cả các broker nằm trong một
cụm Kafka. Ngoài ra, có thể có nhiều nhà broker.
 Zookeeper: ZooKeeper được sử dụng để lưu trữ thông tin về cụm Kafka và thông
tin chi tiết về consumer. Nó quản lý các broker bằng cách duy trì một danh sách
của họ. Ngoài ra, ZooKeeper chịu trách nhiệm chọn người dẫn đầu cho các
partition. Nếu xảy ra bất kỳ thay đổi nào như nhà broker chết, topic mới, v.v.,
ZooKeeper sẽ gửi thông báo tới Apache Kafka. ZooKeeper được thiết kế để hoạt
động với số lượng máy chủ Kafka lẻ. Zookeeper có một máy chủ dẫn đầu xử lý tất
cả các lần ghi và các máy chủ còn lại là những người theo dõi xử lý tất cả các lần
đọc. Tuy nhiên, người dùng không tương tác trực tiếp với Zookeeper mà thông
qua broker. Không có máy chủ Kafka nào có thể chạy mà không có máy chủ
ZooKeeper. Bắt buộc phải chạy máy chủ ZooKeeper.

3.1.2.1.1 Ưu nhược điểm của của Kafka

Ưu điểm:

 Open-source.
 High-throughput: Có khả năng xử lý một lượng lớn thông tin một cách liên tục,
gần như không có thời gian chờ.
 High-frequency: Có thể xử lý cùng lúc nhiều message và nhiều thể loại topic.
 Scalability: Dễ dàng mở rộng khi có nhu cầu.
 Tự động lưu trữ message, dễ dàng kiểm tra lại.
 Cộng đồng người dùng đông đảo, được hỗ trợ nhanh chóng khi cần.

Nhược điểm:
  Chưa có bộ công cụ giám sát hoàn chỉnh: Có nhiều tool khác nhau nhưng mỗi tool
chỉ đáp ứng một tính năng quản lý nhất định, chẳng hạn như: Kafka tool (offset
manager) GUI tool - quản lý topic và consumer, Lense - hỗ trợ query message,
Akhq - toolbox quản lý Kafka và view data bên trong Kafka.
 Không chọn được topic theo wildcard: Người dùng sẽ cần phải sử dụng chính xác
tên topic để xử lý message.
 Giảm hiệu suất: Kích thước message tăng khiến cho consumer và producer phải
compress và decompress message, từ đó làm bộ nhớ bị chậm đi, ảnh hưởng đến
throughput và hiệu suất.
 Xử lý chậm: Đôi khi số lượng queues trong Kafka cluster tăng đột biến khiến
Kafka xử lý chậm hơn.

3.1.2.1.1 Ứng dụng của Kafka

Nhờ khả năng xử lý hiệu quả và lưu trữ dữ liệu lớn theo thời gian thực, Kafka được các
doanh nghiệp thuộc nhiều lĩnh vực khác nhau tin tưởng để sử dụng cho hệ thống của họ.

 Đóng vai trò như message broker: Người dùng có thể sử dụng Kafka để thay thế
cho các Message broker, ví dụ như ActiveMQ hoặc RabbitMQ.
 Quản lý hoạt động website: Đây là cách thức truyền thống để sử dụng Kafka, được
dùng để xây dựng website và đăng tải nội dung theo thời gian thực. Các dữ liệu
như lượt xem trang, hoạt động tìm kiếm… đều được tạo thành các topic. Việc
quản lý hoạt động này giúp bạn phân tích hành vi của người dùng trên trang tốt
hơn, từ đó thu hút được nhiều người đọc hơn.
 Đo lường: Kafka cũng có thể được dùng để xây dựng dữ liệu giám sát các hoạt
động. Điều này đồng nghĩa với việc tập hợp số liệu thống kê từ nhiều nguồn phân
tán trên trang để tạo ra một nguồn dữ liệu tổng hợp.
 Tạo log: Kafka hỗ trợ tổng hợp log hoặc nhật ký hoạt động, tóm tắt các chi tiết và
cung cấp bản ghi cụ thể về dữ liệu sự kiện nhằm phục vụ cho việc xử lý trong
tương lai.
  Stream processing: Đây là cách sử dụng phổ biến hiện nay của Kafka, đó là hệ
thống được phát triển để xử lý dữ liệu theo thời gian thực. Mỗi khi dữ liệu mới
được thêm vào topic, thì sẽ được ghi vào hệ thống ngay lập tức và truyền đến bên
nhận dữ liệu. Hơn nữa, thư viện Kafka Streams được tích hợp từ phiên bản
0.10.0.0 có tính năng xử lý stream nhẹ nhưng rất mạnh mẽ.

3.1.2.2 Superset

Apache SuperSet là một công cụ trực quan hóa dữ liệu Nguồn mở có thể được sử
dụng để biểu diễn dữ liệu bằng đồ họa. Superset ban đầu được tạo ra bởi AirBnB và sau
đó được phát hành cho cộng đồng Apache. Apache Superset được phát triển bằng ngôn
ngữ Python và sử dụng Flask Framework cho tất cả các tương tác web. Superset hỗ trợ
phần lớn RDMBS thông qua SQL Alchemy.

Hình 3-3 Giao diện vẽ Dashboard của Superset

Superset cung cấp:

* Giao diện trực quan để khám phá và trực quan hóa bộ dữ liệu và tạo bảng điều
khiển tương tác.
 * Một loạt các hình ảnh trực quan đẹp để hiển thị dữ liệu của bạn.

* Dễ dàng, không có mã, người dùng chảy vào để xem chi tiết và cắt xén dữ liệu
bên dưới bảng điều khiển được hiển thị. Bảng điều khiển và biểu đồ hoạt động như một
điểm khởi đầu để phân tích sâu hơn.

* Một trình soạn thảo / IDE hiện đại của SQL trình bày một trình duyệt siêu dữ
liệu phong phú và một quy trình làm việc dễ dàng để tạo trực quan hóa từ bất kỳ tập kết
quả nào.

* Một mô hình bảo mật có độ chi tiết cao, có thể mở rộng cho phép các quy tắc
phức tạp về việc ai có thể truy cập vào các tính năng và bộ dữ liệu của sản phẩm nào.
Tích hợp với các phụ trợ xác thực chính (cơ sở dữ liệu, OpenID, LDAP, OAuth,
REMOTE_USER, ...).

* Cho phép kiểm soát cách các nguồn dữ liệu được hiển thị cho người dùng bằng
cách xác định kích thước và số liệu.

* Tích hợp sâu với Druid cho phép Superset duy trì tốc độ nhanh trong khi cắt và
cắt các bộ dữ liệu lớn, thời gian thực.

* Bảng điều khiển tải nhanh với bộ nhớ đệm cấu hình.

3.2 Mô tả phần mềm cài đặt hệ thống và kết quả đạt được.