Phục hồi lỗi trong các hệ thống tính toán đồ thị phân tán THuy Hue Tapchi TinhocNH

NGHIÊN CỨU CÁC PHƯƠNG PHÁP PHỤC HỒI LỖI TRONG
CÁC HỆ THỐNG TÍNH TOÁN ĐỒ THỊ PHÂN TÁN
ThS. Nguyễn Thanh Thụy – Học viện Ngân hàng
ThS.Trần Thị Huế - Học viện Ngân hàng
Tóm tắt
Với sự phổ biến của dữ liệu đồ thị trong ứng dụng thực tế (ví dụ, các mạng xã hội, mạng
lưới điện thoại di động, đồ thị web, vv…) và kích thước ngày càng tăng của nó, nhiều hệ
thống tính toán đồ thị phân tán đã được phát triển trong những năm gần đây để xử lý và phân
tích những đồ thị đồ sộ. Ngoài ra, các hệ thống tính toán đồ thị phân tán hiện tại chủ yếu khai
thác bộ nhớ chính nhằm hỗ trợ các tính linh hoạt của đồ thị. Do sự phức tạp của việc phân tích
đồ thị, không gian bộ nhớ là đặc biệt cần thiết đối với những phân tích đồ thị sinh ra kết quả
trung gian lớn. Như vậy trong quá trình hệ thống thực hiện có thể xuất hiện các hoạt động bất
thường hoặc suy giảm hiệu suất nghiêm trọng khi bộ nhớ bị cạn hoặc sử dụng quá số lõi.
Không những thế, hệ thống tính toán đồ thị phân tán ngày càng đòi hỏi nhiều nút tính toán để
đối phó với các yêu cầu đặt ra bởi đồ thị dựa trên các ứng dụng BigData hiện thời, việc tăng
số lượng các nút tính toán làm tăng việc xuất hiện các nút lỗi. Do đó việc trích lập dự phòng
một chiến lược phục hồi lỗi hiệu quả là rất quan trọng đối với hệ thống tính toán đồ thị phân
tán.
Bài viết này trình bày một số kỹ thuật khôi phục lỗi cho hệ thống xử lý đồ thị phân tán
song song với quá trình phục hồi. Ý tưởng chính là để phân chia một phần bị lỗi của đồ thị
cho các tập con còn lại dựa trên các checkpoint và file log.
1. Giới thiệu
Đồ thị nắm bắt các mối quan hệ phức tạp về sự phụ thuộc dữ liệu, và rất quan trọng cho
các ứng dụng Big Data như phân tích mạng xã hội, phân tích không-thời gian và sự chuyển
hướng, và phân tích người tiêu dùng. MapReduce được đề xuất như là một mô hình lập trình
cho Big Data khoảng một thập kỷ trước, và kể từ đó, nhiều hệ thống phân phối MapReduce
dựa trên đã được thiết kế cho các ứng dụng Big Data như các phân tích dữ liệu quy mô lớn
[Li14]. Tuy nhiên, trong những năm gần đây, MapReduce đã được chứng minh là không hiệu
quả để xử lý dữ liệu đồ thị, và một số hệ thống mới như Pregel [Malewicz10], Giraph [2],
GraphLab [Gonzalez12, Low12], và Trinity [Shao13] đã được đề xuất gần đây nhằm mở rộng
khả năng xử lý đồ thị phân tán.

Với sự bùng nổ ở kích thước đồ thị và nhu cầu ngày càng tăng của phân tích phức tạp,
hệ thống xử lý đồ thị phải liên tục mở rộng ra bằng cách tăng số lượng các nút tính toán, để
xử lý tải. Nhưng nhân rộng số lượng các nút có hai tác dụng trên khả năng phục hồi lỗi của
một hệ thống. Thứ nhất, tăng số lượng các nút chắc chắn sẽ dẫn đến sự gia tăng số lượng các
nút bị hỏng. Thứ hai, sau khi bị lỗi, tiến độ của toàn bộ hệ thống phải dừng lại cho đến khi lỗi
được phục hồi. Do đó, tiềm năng lớn các nút sẽ trở nên nhàn rỗi chỉ vì một tập hợp nhỏ của
các nút đã lỗi. Vì vậy việc khôi phục lỗi nhanh khi xuất hiện lỗi trở nên rất quan trọng đối với
các hệ thống xử lý đồ thị phân tán.

1


Việc thiết kế các cơ chế phục hồi lỗi trong hệ thống phân tán là một nhiệm vụ không
tầm thường, khi họ phải đối phó với một số điều kiện đối lập. Nút lỗi có thể xảy ra bất cứ lúc
nào, hoặc trong thời gian thực hiện công việc bình thường, hoặc trong giai đoạn phục hồi. Các
thiết kế của một thuật toán phục hồi phải có khả năng xử lý cả hai loại lỗi. Hơn nữa, các thuật
toán phục hồi phải là rất hiệu quả vì các chi phí phục hồi có thể làm giảm đáng kể hiệu năng
hệ thống. Đến một mức độ nhất định, do thời gian phục hồi dài, thất bại có thể xảy ra nhiều
lần trước khi hệ thống thu hồi từ một thất bại ban đầu. Nếu vậy, hệ thống sẽ đi vào một vòng
lặp phục hồi vô tận mà không cần bất kỳ sự tiến bộ trong thực hiện. Cuối cùng, hệ thống phải
đối phó với những lỗi trong khi duy trì cơ chế phục hồi với các ứng dụng người dùng. Điều
này ngụ ý rằng các thuật toán phục hồi chỉ có thể dựa vào các mô hình tính toán của hệ thống,
chứ không phải bất kỳ tính toán logic áp dụng cho các ứng dụng cụ thể.
Các phương pháp phục hồi bình thường thông qua các hệ thống xử lý đồ thị phân tán
hiện nay là checkpoint-based [Low10, Malewicz10, Xin13]. Nó yêu cầu mỗi nút tính toán
định kỳ và đồng bộ ghi lại trạng thái đồ thị con của riêng mình để lưu trữ trạng thái ổn định
như các hệ thống tập tin phân tán dưới dạng checkpoint. Khi có lỗi, checkpoint-base phục hồi
sử dụng nút tính toán khỏe mạnh chưa sử dụng để thay thế cho mỗi nút lỗi và yêu cầu tất cả
các nút tính toán để tải lại tình trạng của đồ thị con từ checkpoint gần đây nhất và sau đó đồng
bộ tái thực hiện tất cả các khối lượng công việc bị mất. Một lỗi được phục hồi khi tất cả các

nút kết thúc các tính toán đã được hoàn thành trước khi lỗi xảy ra. Các tính toán lại sẽ bị lặp
lại lần nữa bất cứ khi nào lỗi tiếp tục xảy ra trong quá trình phục hồi.
Mặc dù checkpoint-base phục hồi có thể xử lý bất kỳ nút lỗi, nhưng nó có khả năng gặp
phải sự cố trễ phục hồi cao. Nguyên nhân vì đầu tiên checkpoint-base phục hồi thực hiện lại
khối công việc mất trên toàn đồ thị, trú ở cả nút lỗi và nút tính toán khỏe mạnh dựa trên
checkpoint gần nhất. Điều này sẽ phải chịu chi phí tính toán cao cũng như chi phí truyền
thông cao, bao gồm cả tải toàn bộ checkpoint, thực hiện tính toán và đi qua các thông điệp
trong tất cả các nút tính toán trong quá trình phục hồi. Thứ hai, khi một lỗi tiếp tục xảy ra
trong thời gian phục hồi, việc tính toán gây ra bởi lỗi trước đó có thể đã được phục hồi một
phần. Tuy nhiên, checkpoint-base phục hồi sẽ bỏ qua tất cả phần khối công việc hoàn thành
này, quay ngược lại mỗi nút tính toán đến checkpoint gần nhất và lặp lại các tính toán. Điều
này làm giảm khả năng thực hiện việc phục hồi từng bước.
2. Phục hồi lỗi trong hệ thống xử lý đồ thị phân tán (DGPS)
Chúng ta hãy xem xét một công việc đồ thị được thực thi trên một tập N các nút tính
toán từ superstep 1 tới smax. Một nút tính toán có thể lỗi bất cứ lúc nào trong quá trình thực
hiện công việc bình thường. Hãy để F(Nf, sf) biểu thị một thất bại sẽ xảy ra vào một tập Nf (⊆
N) của các nút tính toán khi công việc đã thực hiện thực hiện bình thường trong superstep s f
(∈ [1, smax]). Chúng tôi liên kết F với hai trạng thái SF và SF*, ghi lại các trạng thái đỉnh trước
và sau khi phục hồi của F tương ứng.
Hãy xem xét một thất bại F(Nf, sf) xảy ra trong khi thực hiện bình thường của một công
việc đồ thị. Trong thời gian phục hồi cho F, các nút tính toán có thể thất bại bất cứ lúc nào. Cụ
thể hơn, nhiều thất bại có thể xảy ra theo trình tự trước khi hệ thống đạt được trạng thái SF*.
Để đẩy nhanh phục hồi cho F, thì cần thực hiện ba nhiệm vụ chính:

2


Tái thực hiện tính toán sao cho tình trạng của tất cả các đỉnh được cập nhật thành một
một đạt được sau khi hoàn thành superstep sf
Lặp lại thông báo các nút trong khi tính toán lại

Phục hồi lỗi phân tầng đối với F
Phương pháp phục hồi này lại chạy các công việc từ superstep đầu tiên khi xảy ra mỗi
thất bại. Rõ ràng, cách tiếp cận này phải gánh chịu thời gian phục hồi dài như việc thực hiện
của mọi superstep có thể tốn kém nhiều công việc đồ thế giới thực. Trong trường hợp xấu
nhất, sự thất bại xảy ra trong quá trình thực hiện các superstep thức và hệ thống cần phải làm
lại tất cả các supersteps. Hơn nữa, nó có nhiều khả năng là một sự thất bại theo tầng sẽ xảy ra
như thời gian phục hồi trở nên dài hơn.
Bên cạnh checkpoints, chúng ta yêu cầu tất cả các nút tính toán đăng tin nhắn gửi đi của
nó vào cuối mỗi superstep. Các thông điệp đã đăng nhập được sử dụng để làm giảm khối
lượng công việc phục hồi được coi là một thất bại F(Nf, sf). Theo phương pháp khôi phục
checkpoint-base, với bất kỳ nút lỗi N ∈ Nf, sẽ được một nút mới có sẵn và gán các phân vùng
trong N cho nó. Chúng ta yêu cầu tất cả các thay thế để tải tình trạng của phân vùng đã nhận
được từ các checkpoint mới nhất, và tất cả các nút khỏe mạnh giữ các phân vùng ban đầu của
chúng. Khi superstep i ∈ [c + 1, sf] đang phục hồi, chỉ thay thế thực hiện tính toán cho các
đỉnh trong phân vùng đã lỗi, trong khi tất cả các nút khỏe mạnh chuyển tiếp thông báo đăng
nhập cục bộ đã đăng nhập tin nhắn đến các đỉnh trong phân vùng lỗi mà không cần bất kỳ tính
toán lại. Đối với i ∈ [c + 1, sf), các đỉnh trong phân vùng lỗi chuyển tiếp tin nhắn cho nhau,
nhưng đối với i = sf, chúng gửi tin nhắn đến những nút khỏe mạnh. Cách này đã giúp hạn chế
sự phục hồi việc tải các phân vùng lỗi (cả về tính toán lại và qua thông báo qua), do đó làm
giảm thời gian phục hồi. Hơn nữa chi phí của việc ghi cục bộ là không đáng kể tong nhiều
ứng dụng đồ thị như thời gian thực hiện bị chi phối bởi tính toán và chuyển thông báo qua
mạng. Tuy nhiên việc tính toán lại cho các phân vùng bị lỗi được chia sẻ giữa các nút để thay
thế những lỗi và điều này hạn chế hoàn thành song song giống như việc tính toán trong một
nút chỉ có thể thực hiện tuần tự. Điều này thúc đẩy chúng ta gán phân vùng lỗi đến nhiều nút
để đạt được song song của tính toán lại.
3. Phục hồi PARTITION-BASED
Chúng tôi đề xuất một phương pháp phân vùng dựa trên giải quyết vấn đề phục hồi thất
bại. Sau khi thất bại, quá trình phục hồi được khởi xướng bởi thi hành phục hồi. Hình 4.1 cho
thấy quy tình làm việc của thi hành phục hồi lỗi partition-based.

3


Failue
Statisticic
HDFS

FS

Generating recover plant

ilue
checkpointi

cilue
Logs

Recomputing missing
Suppersteps

messagec

ilue
Exchanging Graph patitions
Hình 1: Thi hành phục hồi lỗi

Lấy c + 1 là superstep checkpointing mới nhất cho lỗi. Thi hành phục hồi là trách nhiệm
đối với ba nhiệm vụ sau đây:
Tạo kế hoạch phục hồi partition-based: Đầu vào nhiệm vụ này bao gồm các trạng thái
trước khi bắt đầu phục hồi và số liệu thống kê được lưu trữu trong kho lưu trữ tin cậy.

Tính toán lại phân vùng lỗi: Nhiệm vụ này là để thông báo cho tất cả các nút tính toán
của φr kế hoạch phục hồi. Mỗi nút N kiểm tra φr để xem liệu một phân vùng lỗi được gán cho
nó. Mỗi nút sau đó bắt đầu tính toán lại cho các phân vùng lỗi.
Phân vùng đồ thị thay đổi: Nhiệm vụ này là để tái cân bằng khối lượng công việc
trong tất cả các nút tính toán sau khi tính toán lại các phân vùng lỗi hoàn tất. Nếu thay thế có
cấu hình khác hơn so với các nút bị hỏng, thì cho phép một phân vùng mới (khác với trước
khi lỗi xảy ra) để được một sự cân bằng tải tốt hơn, sau đó các nút có thể trao đổi giữa các
phân vùng khác đó.
Tính toán lại phân vùng lỗi
Hãy xem xét một lỗi F (Nf, sf) xảy ra trong quá trình thực bình thường. Các tính toán lại
cho các phân vùng lỗi bắt đầu từ checkpointing gần đây nhất superstep c + 1. Sau khi tất cả
các nút tính toán kết thúc superstep i, chúng tiến hành đồng bộ superstep i + 1. Mục tiêu của
phục hồi là để đạt được trạng thái SF*. Do đó, tính toán lại kết thúc khi tất cả các nút tính toán
hoàn tất superstep sf.
Thuật toán 1 cung cấp các chi tiết tính toán lại trong một phục hồi superstep.

4


Hãy xem xét một nút N. Trong superstep i (∈ [c + 1, sf]), N duy trì một danh sách M
thông báo sẽ được gửi qua đỉnh trú tại N trong superstep hiện hành. Ban đầu, M có chứa tất cả
các thong báo gửi đi đã đăng nhập cục bộ với superstep i nếu có (dòng 1). N sau đó lặp qua tất
cả các đỉnh hoạt động có trong đó và với mỗi đỉnh hoạt động, N thực hiện tính toán của mình
và gắn thêm tất cả các thông báo được gửi bởi đỉnh này cho M nếu giá trị đỉnh không được
cập nhật thành một vào cuối superstep i (dòng 2-5). Sau đó, N lặp trên các tin nhắn trong M.
Một thông điệp m trong M được chuyển tiếp nếu m là cần thiết của đỉnh đích của nó để thực
hiện tái tính toán trong superstep tiếp theo (dòng 6-9). Cuối cùng, N xả M vào kho lưu trữ cục
bộ của nó (dòng 10), nơi sẽ được sử dụng trong trường hợp có sự cố lan thêm.
4. Tạo sự phân công lại
Trong phần này, chúng ta xem làm thế nào để tạo ra một phân công lại cho một lỗi. Hãy

xem xét một lỗi F (Nf, sf). Sự phân công lại cho F là rất quan trọng để thực hiện phục hồi tổng
thể, nghĩa là khoảng thời gian phục hồi. Đặc biệt, nó quyết định các tính toán và chi phí kết
nối trong quá trình tính toán lại. Mục tiêu của phần này là để tìm thấy một phân công lại giảm
thiểu thời gian phục hồi Γ (F).
Với một phân công lại cho F, tính Γ (F) là phức tạp bởi thực tế là Γ (F) không chỉ phụ
thuộc vào sự phân công lại cho F, mà còn về những lỗi phân tầng cho F và các phân công lại
tương ứng. Do đó, chúng ta tìm kiếm một thuật toán thế hệ phân công lại trực tuyến mà có thể
phản ứng để đáp ứng với bất kỳ thất bại.
Một phân công lại có thể có lợi cho quá trình phục hồi còn lại cho F bằng cách tham gia
vào tài khoản của tất cả các lỗi phân tầng mà đã xảy ra. Cụ thể hơn, chúng ta thu thập các
trạng thái S sau khi lỗi xảy ra và đo thời gian tối thiểu cần thiết để chuyển đổi từ S đến S F*,
tức là thời gian thực hiện tính toán lại từ superstep c + 1 đến sf mà không lỗi phân tầng hơn
nữa. Sau đó hướng đến tạo ra một phân công lại giảm thiểu T low. Về cơ bản, S gói gọn tất cả
các thông tin hữu ích về các lỗi trước đó và các phân công lại tương ứng thực hiện, và T low

5


cung cấp giới hạn dưới là thời gian phục hồi còn lại cho F. Thuật toán 2 dưới đây phác họa
thuật toán phân công lại:

Đầu tiên chúng ta tạo ra một φr phân công lại bằng cách gán ngẫu nhiên phân vùng
trong Pf giữa các nút tính toán N, và sau đó tính toán Tlow bởi φr (dòng 1-2). Tiếp theo chúng
ta tạo một bản sao của φr như φr 'và cải thiện φr' lặp đi lặp lại (dòng 3-18). Trong lần lặp thứ
i, các thuật toán lựa chọn một số phân vùng này và thay đổi phân công lại của chúng (dòng 79). Những thông tin sửa đổi được lưu trữ trong Li. Li có trong các hình thức (φ, Time), nơi φ là
bản ghi ánh xạ phân vùng nút mà phân vùng được sửa đổi để được gán cho nút, và Time là Tlow
dưới sự đổi phân công lại. Các phân vùng đã chọn được loại bỏ để xem xét thêm (dòng 10).
Các lặp kết thúc khi không còn lỗi phân vùng ở bên trái. Sau đó, chúng tôi kiểm tra danh sách
L và tìm l sao cho Ll.Time là nhỏ nhất (dòng 11).
Thuật toán 3 mô tả làm thế nào để tạo ra thay đổi Li (dòng 7 trong thuật toán 2) trong

lần lặp thứ i.

6


Thuật toán 3 tập trung vào hai loại sửa đổi: i) trao đổi các phân công lại giữa hai phân
vùng; ii) thay đổi phân công lại cho một phân vùng. Cho một φr phân công lại,
NEXCHANGE lặp trên tất cả các phân vùng (dòng 2) và cho mỗi phân vùng P, nó liệt kê tất
cả các sửa đổi có thể, ví dụ, trao đổi phân công lại của P với phân vùng khác (dòng 3-9) cũng
như gán P đến một nút khác thay vì φr (P) (dòng 10-15). NEXCHANGE tính toán Tlow tương
ứng đạt được của mỗi biến đổi và chọn một trong các giá trị nhỏ nhất của Tlow làm sửa đổi Li
Thuật toán phân công lại này hơn thuật toán phân vùng truyền thống ở các khía cạnh
sau:
-

-

-

Đồ thị phân vùng truyền thống tập trung vào phân vùng một đồ thị tĩnh thành k thành phần
với mục tiêu giảm thiểu số cạnh giữa các phần, còn thuật toán này để giảm thiểu thời gian
phục hồi còn lại Tlow. Tlow là độc lập với cấu trúc đồ thị ban đầu nhưng dựa trên các trạng thái
đỉnh và thông báo đi qua trong suốt thời gian thực hiện.
Đồ thị phân vùng truyên thống đầu ra là các thành phần k với k được xác định trước. thuật
toán này tự động phân bổ các phân vùng lỗi trong các nút khỏe mạnh mà không biết trước k.
Hơn nữa, bên cạnh việc phân vùng, chúng cũng biết các nút mà một phân vùng lỗi sẽ phân
vùng lại.
Thứ ba, phân vùng truyền thống luôn đòi hỏi các thành phần k có kích thước tương đương,
trong khi chúng ta cho phép phân công lại không cân bằng.
5. Kết quả thực nghiệm

Thực nghiệm được tiến hành trên một cụm gồm 72 nút, mỗi nút được trang bị một bộ
xử lý 2.4GHz Intel X3430, bộ nhớ trong 8GB, hai đĩa cứng 500GB SATA. Tất cả các nút
được lưu trữ trên hai kệ. Các nút trong một kệ được kết nối thông qua một swich 1Gbs, và hai
kệ được kết nối thông qua một switch cụm 10Gbs. Trên mỗi nút tính toán cài đặt hệ điều hành

7


CentOS5.5, Java1.6.0 với 64-bit server VM và Hadoop 0.20.203.0. Nhóm tác giả đã mặc định
cấu hình Hadoop sau: (1) kích thước của bộ nhớ ảo cho mỗi nhiệm vụ được thiết lập đến
4GB; (2) mỗi nút được cấu hình để chạy một nhiệm vụ bản đồ. Theo mặc định, chọn 42 nút ra
khỏi 72 nút cho các thí nghiệm, và trong số đó có một nút hoạt động như là master chạy
Hadoop NameNode và daemon JobTracker trong khi 41 nút còn lại chạy daemon
TaskTracker.
Bảng 1 dưới đây cung cấp chi tiết số liệu và hai bộ dữ liệu đồ thị được tải về từ website
Dataset

Data Size

#Vertices

#Edges

#Partitions

Forest

2.7G

58,101,200

0

160

LiveJournal

1.0G

3,997,926

34,681,189

160

Friendster

31.16G

65,698,366

1,806,067,137

160

Bảng 1 Mô tả bộ số liệu
Đầu tiên chúng ta nghiên cứu các chi phí cần thiết của việc ghi lại các thông điệp vào
cuối mỗi superstep trong PBR. Hình 2 (a) cho thấy thời gian chạy và ta thấy PBR hầu như
giống CBR. Một quan sát thú vị là checkpointing superstep 10 không phải chịu thời gian vận
hành cao hơn so với supersteps khác. Điều này là bởi vì so với tính toán các cụm thuộc mới

cho mỗi quan sát, thời gian làm checkpointing là không đáng kể. Hình 2(b) thể hiện kết quả
khi thực hiện các phương pháp phục hồi cho những nút đơn lỗi bằng cách thay đổi superstep
không thành công từ 11 đến 19. Ta thấy thời gian phục hồi của cả hai CBR và PBR tăng tuyến
tính khi lỗi superstep thay đổi, và chúng ta thấy rằng PBR nhanh hơn so với CBR và có một
lợi rõ ràng khi lỗi superstep tăng. Hình 2(c) là kết quả của việc thực hiện các phương pháp
phục hồi cho nhiều nút lỗi. Số lượng các nút bị lỗi được thay đổi 1-5 và superstep lỗi được cài
là 15. Khi số lượng các nút lỗi tăng, thời gian phục hồi tăng tuyến tính cho PBR trong khi đó
vẫn không đổi cho CBR. Cuối cùng hình 2(d) là kết quả của việc phân tầng lỗi bằng cách thiết
lập các superstep lỗi đầu tiên từ 19 và thay đổi superstep lỗi thứ hai từ 11 đến 18. Lúc này ta
thấy khi superstep lỗi thứ hai tăng thì thời gian phục hồi tăng tuyến tính cho cả CBR và PBR
nhưng về mặt trung bình thì BPR có thể làm giảm thời gian phục hồi của một yếu tố hơn so
với CBR.

Hình 2 K-mean
Hình 3 (a) lại cho chúng ta thấy lô thời gian chạy của mỗi superstep cho semiclustering. Ta thấy PBR cần có thời gian dài hơn CBR trong thực hiện bình thường. Tương tự
như trên hình 3(b), 3(c), 3(d) cho chúng ta cũng đánh giá việc thực hiện các phương pháp
phục hồi cho những nút đơn lỗi, nhiều nút lỗi và lỗi phân tầng. Về cơ bản xu hướng của thời
gian chạy của PBR nhanh hơn CBR

8


Hình 4.3: semi-clustering
Tóm lại kết quả cho thấy rằng có thể khôi phục lỗi nhanh cho hệ thống tính toán bằng
phương pháp phục hồi phân vùng.
6. Kết luận
Bài viết trình bày kỹ thuật khôi phục dữ liệu lỗi dựa trên phương pháp phục hồi phân vùng.
Khác với phương pháp khôi phục truyền thống dựa trên checkpoint, phương pháp này thực
hiện phân chia các lỗi cho nhiều vùng tính toán nên quá trình phục hồi được thực hiện đồng
thời. Bài toán cũng đã trình bày kết quả tính toán và chi phí tính toán với hệ thống Giraph với

40 nút tính toán, kết quả đo được rằng do việc phục hồi được thực hiện song song nên phương
pháp này đã nhanh hơn phương pháp phục hồi dựa trên checkpoint khoảng 30 lần.
Tài liệu tham khảo
[1] Apache Giraph. />[2] />[Bertsekas89] D. P. Bertsekas and J. N. Tsitsiklis. Parallel and dis-tributed computation:
numerical methods. In Prentice-Hall, 1989.
[Bu13] Y. Bu. Pregelix: dataflow-based big graph analytics. In SoCC, page 54, 2013.
[Ching13]A.
Ching.
Scaling
2013.

apache

giraph

to

a

trillion

edges.

[Frommer00] A. Frommer and D. B. Szyld. On asynchronous iterations. In J. Comput.
Appl. Math., 2000.
[Gonzalez12] J. E. Gonzalez, Y. Low, H. Gu, D. Bickson, and C. Guestrin.
PowerGraph: Distributed graph-parallel computation on natural graphs. In OSDI, pages 17–
30, 2012.
[Khayyat13] Z. Khayyat, K. Awara, A. Alonazi, H. Jamjoom, D. Williams, and P.
Kalnis. Mizan: a system for dynamic load balancing in large-scale graph processing. In

EuroSys, pages 169–182, 2013.
[Kyrola12] A. Kyrola, G. E. Blelloch, and C. Guestrin. GraphChi: Large-scale graph
computation on just a PC. In OSDI, pages 31–46, 2012.
[Li14] F. Li, B. C. Ooi, M. T. ¨ Ozsu, and S. Wu. Distributed data management using
mapreduce. ACM Comput. Surv., 46(3):31:1–31:42, 2014
[Low12] Y. Low, J. Gonzalez, A. Kyrola, D. Bickson, C. Guestrin, and J.
M.Hellerstein. Distributed GraphLab: A framework for machine learning in the Cloud.
PVLDB, 5(8):716–727, 2012.

9


[Low10] Y. Low, J. Gonzalez, A. Kyrola, D. Bickson, C. Guestrin, and J.
M.Hellerstein. Graphlab: A new parallel framework for machine learning. In UAI, pages 340–
349, 2010.
[Malewicz10] G. Malewicz, M. H. Austern, A. J. C. Bik, J. C. Dehnert, I. Horn, N.
Leiser, and G. Czajkowski. Pregel: a system for large-scale graph processing. In SIGMOD
Conference, pages 135–146, 2010.
[Salihoglu13] S. Salihoglu and J. Widom. GPS: a graph processing system. In SSDBM,
pages 22:1–22:12, 2013.
[Salihoglu14] S. Salihoglu and J. Widom. Optimizing graph algorithms on Pregel-like
systems. PVLDB, 7(7):577–588, 2014.
[Shao13] B. Shao, H. Wang, and Y. Li. Trinity: A distributed graph engine on a
memory cloud. In SIGMOD, pages 505–516, 2013
[Tian13] Y. Tian, A. Balmin, S. A. Corsten, S. Tatikonda, and J. McPherson. From
“think like a vertex” to “think like a graph”. PVLDB, 7(3):193–204, 2013.
[Valiant90]L. G. Valiant. A bridging model for parallel computation. Communications
of the ACM, 33(8):103–111, 1990.
[Xin13] R. S. Xin, J. E. Gonzalez, M. J. Franklin, and I. Stoica. GraphX: a resilient
distributed graph system on Spark. In GRADES, page 2, 2013.

[Yan14a] D. Yan, J. Cheng, Y. Lu, and W. Ng. Blogel: A block-centric framework for
distributed computation on real-world graphs. PVLDB, 7(14), 2014.
[Yan14b]D. Yan, J. Cheng, Y. Lu, and W. Ng. Pregel+: Technical report.
( 2014.

10