NGHIÊN CỨU CÁC PHƯƠNG PHÁP PHỤC HỒI LỖI TRONG Tóm tắt 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 1 ThS.Trần Thị Huế - Học viện Ngân hàng 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.
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 s max. 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(N f, s f ) biểu thị một thất bại sẽ xảy ra vào một tập N f ( 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, s max ]). Chúng tôi liên kết F với hai trạng thái S F và S F *, 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(N f, s f ) 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 S F *. Để đẩ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 s f - 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(N f, s f ). Theo phương pháp khôi phục checkpoint-base, với bất kỳ nút lỗi N N f, 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, s f ] đ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, s f ), 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 = s f, 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 HDFS Logs Statisticic ilue checkpointi cilue messagec ilue Generating recover plant Recomputing missing Suppersteps 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 (N f, s f ) 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 S F *. 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 s f. 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, s f ]), 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 (N f, s f ). 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 s f 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 P f giữa các nút tính toán N, và sau đó tính toán T low 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 7-9). Những thông tin sửa đổi được lưu trữ trong L i. L i có trong các hình thức (φ, T ime ), 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à T ime là T low 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 L l.t ime là nhỏ nhất (dòng 11). Thuật toán 3 mô tả làm thế nào để tạo ra thay đổi L i (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 T low 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 T low làm sửa đổi L i sau: 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 - Đồ 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 T low. T low 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. http://incubator.apache.org/giraph/ [2] http://giraph.apache.org/. [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 apache giraph to a trillion edges. http://tinyurl.com/ktf6d25, 2013. [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. (http://www.cse.cuhk.edu.hk/pregelplus/pregelplus.pdf), 2014. 10