Tối ưu hóa Join đệ quy trên tập dữ liệu lớn trong môi trường Spark

Bài viết nghiên cứu nhằm đề xuất một số giải pháp hiệu quả cho xử lý Join đệ quy trên nền tảng xử lý dữ liệu lớn thế hệ mới Spark. Đề xuất của chúng tôi đã loại bỏ một lượng lớn dữ liệu dư thừa được tạo ra trong các xử lý lặp của Join đệ quy, tận dụng những lợi thế của việc xử lý trong bộ nhớ và cơ chế bộ nhớ đệm để giảm thiểu các chi phí có liên quan. Thông qua mô hình chi phí và các thực nghiệm, nghiên cứu này chỉ ra rằng các giải pháp của chúng tôi đã cải tiến đáng kể hiệu suất thực thi của Join đệ quy trong môi trường MapReduce.

Kỷ yếu Hội nghị Khoa học Quốc gia lần thứ IX ―Nghiên cứu ứng dụng Công nghệ thông tin (FAIR'9)‖; Cần Thơ, ngày 4-5/8/2016 DOI: 10.15625/vap.2016.00091 TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN TRONG MÔI TRƯỜNG SPARK Phan Thượng Cang1, Trần Thị Tố Quyên1, Phan Anh Cang2 Khoa Công nghệ thông tin Truyền thông, Đại học Cần Thơ Khoa Công nghệ thông tin, Trường Đại học Sư phạm Kỹ thuật Vĩnh Long ptcang@cit.ctu.edu.vn, tranthitoquyen@cit.ctu.edu.vn, cangpa@vlute.edu.vn TÓM TẮT— MapReduce trở thành mơ hình lập trình cho phân tích xử lý liệu lớn năm gần Tuy nhiên, mơ hình cịn tồn số mặt hạn chế chưa hỗ trợ đầy đủ cho tính tốn lặp, chế nhớ đệm (cache), hoạt động với đa đầu vào (multiple inputs) Ngồi ra, chi phí cho việc đọc/viết truyền thơng liệu mơ hình cịn q tốn Một hoạt động phức tạp đáng ý thường sử dụng MapReduce Join đệ quy Nó địi hỏi đặc trưng xử lý mà hạn chế MapReduce Vì vậy, nghiên cứu này, chúng tơi đề xuất số giải pháp hiệu cho xử lý Join đệ quy tảng xử lý liệu lớn hệ Spark Đề xuất loại bỏ lượng lớn liệu dư thừa tạo xử lý lặp Join đệ quy, tận dụng lợi việc xử lý nhớ chế nhớ đệm để giảm thiểu chi phí có liên quan Thơng qua mơ hình chi phí thực nghiệm, nghiên cứu giải pháp cải tiến đáng kể hiệu suất thực thi Join đệ quy mơi trường MapReduce Từ khóa— Big data analytics, recusrsive join, map reduce, spark I GIỚI THIỆU Trong thời đại bùng nổ thông tin nay, thuật ngữ “Big Data” dần trở nên quen thuộc đặt nhiều thách thức nghiên cứu cơng nghệ tìm kiếm (search-engines), phân tích mạng xã hội (social network analysis), phân tích liệu Web (Web-data analysis), phân tích giám sát mạng (network-monitoring analysis), mơ lớn (massive-scale simulations), cảm biến thông lượng cao (high-throughput sensors), v.v Để xử lý lượng liệu cực lớn cho cơng việc trên, cần có mơ hình lập trình phân tán chạy cụm máy tính (clusters) Ý tưởng việc tính toán phân tán chia toán thành toán giải máy riêng biệt kết nối cụm máy tính MapReduce [1] Google đề xuất năm 2004 trở thành mơ hình chuẩn phổ biến để xử lý liệu lớn hệ thống song song phân tán Một cụm máy tính thực thi cơng việc MapReduce gồm hàng ngàn nút tính tốn (computing nodes) với khả chịu lỗi cao, thích hợp với ứng dụng xử lý liệu cực lớn, song song co giãn Mơ hình MapReduce tương thích với nhiều loại giải thuật phân tích tài liệu web lớn (web-scale document analysis) [1], thực thi câu truy vấn quan hệ (relational query evaluation) [2] xử lý ảnh quy mô lớn (large scale image processing) [3] Tuy nhiên, khơng thiết kế cho hoạt động với đa đầu vào (multiple inputs) Ngồi ra, không hỗ trợ tốt cho nhiều ứng dụng xử lý liệu lớn địi hỏi tính tốn lặp lại PageRank [4], HITS (HypertextInduced Topic Search) [5], câu truy vấn đệ quy (recursive relational queries) [6], phân cụm liệu (clustering) [7], phân tích mạng neutron (neural network analysis) [8], phân tích mạng xã hội (social network analysis) [9] phân tích lưu lượng liệu internet (Internet traffic analysis) [10] Những ứng dụng liên quan đến tính tốn lặp lặp lại liên tục tập liệu lớn chúng đạt đến điều kiện dừng hay điểm dừng (a fix point) Để khắc phục hạn chế đó, lập trình viên phải cài đặt giải thuật lặp lại môi trường MapReduce cách thực thi nhiều chuỗi công việc tự quản lý công việc lặp Điều dẫn đến việc đọc viết liệu phải thực lại nhiều lần, làm tăng đáng kể chi phí I/O, CPU, truyền thơng, ảnh hưởng nhiều đến tốc độ xử lý ứng dụng Đây thách thức khơng nhỏ việc xử lý liệu lớn môi trường MapReduce Join [11, 12] phép kết nối từ hai nhiều tập liệu sở liệu Join thường sử dụng câu truy vấn liệu tiêu biểu với chi phí độ phức tạp lớn Các dạng Join Join hai chiều (two-way join), Join đa chiều (multi-way join) [13], Join chuỗi (chain join) [14] Join đệ quy (recursive join) [15– 17] Các truy vấn Join tập liệu trở nên phức tạp ngữ cảnh Big Data Trong phạm vi nghiên cứu này, tập trung nghiên cứu xử lý Join đệ quy, dạng Join phức tạp có chi phí thực thi lớn áp dụng nhiều lĩnh vực PageRank, khai thác liệu đồ thị (graph mining), giám sát mạng máy tính, mạng xã hội, tin sinh học (bioinformatics), v.v Một ví dụ điển hình cho ứng dụng Join đệ quy câu truy vấn khám phá mối quan hệ cá nhân mạng xã hội định nghĩa sau: Friend(x, y) ← Know(x, y); Friend(x, y) ← Friend(x, z) ⋈ Know(z, y); Một cá nhân x bạn y x quen biết trực tiếp với y Một cá nhân x bạn y x bạn z z quen biết với y Điều đồng nghĩa với câu truy vấn tìm tất bạn bạn cá nhân (friends of friends of a user) TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 730 Việc thực thi câu truy vấn Join đệ quy thông thường bao gồm hai pha công việc lặp lại Thứ nhất, pha xử lý Join: đọc, xử lý vận chuyển nhiều tập liệu đầu vào; loại bỏ dịng khơng thoả mãn điều kiện join; kết hợp dòng thoả mãn điều kiện join để tạo kết tạm thời Thứ hai, pha xác định tập liệu tăng cường (incremental dataset): đọc lại tất liệu kết sinh từ vòng lặp trước để loại bỏ kết bị trùng lắp tập kết tạm thời; ghi lại tập kết không trùng với tập kết trước (cịn gọi tập liệu tăng cường) Tập liệu tăng cường đầu vào cho pha xử lý Join Hai pha công việc thực lặp lại không phát kết Với hạn chế rõ ràng MapReduce khơng hỗ trợ trực tiếp cho hoạt động Join đặc biệt Join đệ quy Do đó, việc thực thi câu truy vấn Join đệ quy tập liệu lớn môi trường MapReduce trở thành mối quan tâm hàng đầu chứa đựng thách thức lớn cho nhà nghiên cứu Chính vậy, nhóm nghiên cứu chúng tơi tập trung vào việc tìm kiếm đề xuất giải pháp tối ưu cho xử lý Join đệ quy Để thực điều đó, nhóm trước tiên tiến hành nghiên cứu thành phần mở rộng tảng MapReduce để hỗ trợ hiệu cho việc thực thi công việc lặp lại nhiều lần chế nhớ đệm (cache) mà giữ lại tập liệu khơng đổi xử lý lặp Sau đó, chúng tơi đưa phương thức để loại bỏ phần tử dư thừa không tham gia vào hoạt động Join II CÁC NGHIÊN CỨU LIÊN QUAN A Join đệ quy môi trường MapReduce Câu truy vấn Join đệ quy quan hệ xem câu truy vấn bao đóng bắc cầu quan hệ [17] Trên thực tế, có nhiều thuật tốn thiết kế để tính bao đóng bắc cầu quan hệ sở liệu truyền thống Naive [24], Semi-naive [1–3], Smart [27, 28], Minimal evaluations [28], Warshall [30] Warren [31] Chúng phân loại thành hai nhóm chính, thuật tốn lặp (Naive, Semi-naive, Smart, Minimal evaluations) thuật tốn tính trực tiếp (Warshall Warren) Tuy nhiên, thuật tốn khơng phải lúc phù hợp để thực môi trường MapReduce Một số nghiên cứu gần tìm thấy giải pháp cho vấn đề Afrati et al [32, 33] đề xuất việc thực thi đệ quy cụm máy tính (cluster) để tính bao đóng bắc cầu cho câu truy vấn đệ quy Các tác giả giải pháp để làm giảm đáng kể số lần lặp cần thiết cho bao đóng bắc cầu phi tuyến (nonlinear transitive closures) Giải pháp sử dụng hai nhóm tác vụ gồm nhóm tác vụ Join (Join tasks) nhóm tác vụ loại bỏ trùng lắp (Dup-elim tasks) Nhóm tác vụ Join thực việc tính tốn join liệu (cịn gọi tuples) Nhóm tác vụ cịn lại loại bỏ liệu kết trùng lắp trước phân phát đến nhóm tác vụ Join Kết số lần lặp cho thực thi Join đệ quy giảm đến O(log2 n) thay O(n) đồ thị n-node Một trở ngại lớn giải pháp tác vụ (tasks) chạy đệ quy thời gian dài làm tăng nguy thất bại Ngoài ra, giải pháp phải sửa đổi số đặc trưng mơ hình MapReduce chế phục hồi lỗi thuộc tính khóa tác vụ Map (blocking property) Bên cạnh đó, sử dụng để tính bao đóng bắc cầu phi tuyến chi phí truyền thơng thường lớn nhiều so với bao đóng bắc cầu tuyến tính (linear transitive closures) chép kết đầu tác vụ loại bỏ trùng lắp Pregel [34] thực đệ quy thực đồ thị cách sử dụng mơ hình BSP (Bulk Synchronous Parallel) khoảng thời gian kiểm tra tất tác vụ (được gọi checkpoint) Nếu có tác vụ thất bại tất tác vụ phải thực thi lại checkpoint trước Điều hạn chế lớn giải pháp Hadoop [35] cung cấp tảng xử lý liệu lớn theo mơ hình MapReduce hệ thống tập tin phân tán HDFS (Hadoop Distributed File System) Nó chạy trên cụm máy tính phân tán mà đảm bảo độ tin cậy khả chịu đựng lỗi Tuy nhiên, phát triển ý tưởng ban đầu MapReduce nên Hadoop không hỗ trợ tốt hoạt động có đa đầu vào (multiple inputs) xử lý lặp Join đệ quy HaLoop [36] phiên chỉnh sửa Hadoop, thiết kế nhằm hỗ trợ hiệu cho ứng dụng mơ hình MapReduce cần chế nhớ đệm xử lý lặp Join đệ quy HaLoop sử dụng hệ thống phân tán để lưu trữ liệu đầu vào đầu cơng việc MapReduce Nó thực đệ quy cách lặp lại công việc MapReduce giảm thiểu truyền thông nhớ đệm đầu vào Mapper đầu vào/ra Reducer Giải pháp tránh việc đọc lại truyền lại liệu qua mạng, tất nhiên phải đọc lại nhớ đệm Một hạn chế tác vụ nên hoạt động vòng lặp đồng đầu tác vụ phải gửi đến Map/Reduce Ngoài ra, nhược điểm việc thực nhớ đệm HaLoop xuất phát từ hoạt động viết lại hoàn toàn nhớ đệm cho lần lặp Về mặt ý tưởng, HaLoop hỗ trợ tốt để xử lý truy vấn đệ quy tập liệu lớn Tuy nhiên, HaLoop dừng lại mức nghiên cứu Trên thực nghiệm [37], phương thức cache HaLoop cịn phát sinh lỗi khơng kiểm sốt cache đĩa cứng, không cache tập liệu tăng cường qua vịng lặp Hiện HaLoop khơng phát triển hỗ trợ Gần nhất, Shaw et al [38] đề xuất giải pháp tối ưu cho Join đệ quy sử dụng giải thuật Semi-Nạve mơi trường MapReduce HaLoop Giải pháp thực thi việc lặp lại hai công việc MapReduce bao gồm cơng việc Join cơng việc tính tập liệu tăng cường Giải pháp sử dụng nhớ đệm cho đầu vào Reducer (Reducer Input Cache) HaLoop để giảm thiểu chi phí có liên quan Tuy nhiên, giải pháp không tránh khỏi hạn chế HaLoop Bên cạnh đó, liệu tạo công việc Join phải đọc lại chuyển qua mạng lần cơng việc tính tập liệu tăng cường Hơn nữa, chi phí đọc viết nhớ đệm Phan Thượng Cang, Trần Thị Tố Quyên, Phan Anh Cang 731 đáng kể tất tập liệu tăng cường lần lặp trước phải viết, mục đọc lại để dị tìm trùng lắp cơng việc tính tập liệu tăng cường Điều đáng lưu ý nhớ đệm phải viết lại có tập liệu tăng cường tìm thấy Ngồi ra, liệu khơng tham gia vào cơng việc Join xử lý truyền qua mạng mà không bị loại bỏ Tất điều dẫn đến chi phí thực thi Join đệ quy lớn chưa hiệu Từ hạn chế giải pháp nêu, cần tìm kiếm tảng xử lý hỗ trợ tốt cho chế nhớ đệm thực thi lặp công việc MapReduce Trên tảng xử lý liệu lớn đó, tiến hành tối ưu hóa Join đệ quy cách có hiệu Việc loại bỏ liệu không tham gia vào Join cần xem xét cách thấu đáo B Apache Spark Spark [18] tảng viết ngôn ngữ Scala, cho phép xử lý liệu lớn phân tán cách hiệu nhanh chóng Spark tương thích với nhiều hệ thống lưu trữ tập tin HDFS, Cassandra [19], HBase [20] Amazon S3 [21] Spark có tốc độ xử lý nhanh gấp 100 lần so với Hadoop MapReduce cache nhớ, nhanh gấp 10 lần cache đĩa [22] Spark hỗ trợ ngơn ngữ lập trình Scala, Python, Java, cung cấp nhiều công cụ lập trình cấp cao Đặc điểm bật Spark tập liệu phân tán có khả phục hồi RDD (Resilient Distributed Dataset), kiểu liệu tập hợp phân tán (distributed collection) lưu tạm thời nhớ RAM, có khả chịu lỗi cao tính tốn song song RDDs hỗ trợ kiểu hoạt động: transformations actions Transformations thao tác “lazy”, có nghĩa thao tác khơng thực lập tức, mà ghi nhớ bước thực lại Thao tác thực q trình thực có Actions gọi cơng việc tính tốn Transformations diễn Mặc định, RDD tính tốn lại có Actions gọi Tuy nhiên, RDDs lưu lại nhớ RAM lệnh persist (hoặc cache) để sử dụng sau Actions trả kết cho chương trình điều khiển (driver) sau thực hàng loạt tính tốn RDD Khả xử lý lặp Spark Spark công cụ hỗ trợ mạnh mẽ cho xử lý lặp tập liệu lớn Một phương thức Spark thích hợp cho loại xử lý thông qua RDD RDD mô tả " , cấu trúc liệu song song chịu lỗi cho phép người dùng giữ lại kết trung gian nhớ, kiểm soát phân vùng chúng để tối ưu hóa vị trí lưu trữ liệu, xử lý chúng thông qua tập phép toán." [23] Bằng cách sử dụng RDD, lập trình viên “ghim” (pin) tập liệu lớn họ vào nhớ Điều giúp cho Spark RDD hỗ trợ xử lý lặp hiệu so với việc đọc lượng lớn liệu từ đĩa cho lần lặp Hadoop MapReduce Việc xử lý lặp Hadoop MapReduce thực chuỗi công việc nối tiếp mà kết trung gian phải viết đến HDFS sau chúng phải đọc lại để làm đầu vào cho công việc Trong đó, Spark đọc liệu đầu vào từ HDFS, thực loạt hoạt động lặp lặp lại liệu dạng RDD, sau viết đến HDFS Rõ ràng, Spark RDD chạy nhanh Hadoop MapReduce tác vụ liệu nạp lên nhớ xử lý đó, tác vụ sau sử dụng lại liệu nằm sẵn nhớ cục thay phải đọc ghi liên tục vào HDFS Hadoop MapReduce Tương tự, thuật toán xử lý đồ thị PageRank đòi hỏi lặp lại nhiều lần tập liệu chế truyền thơng điệp, cần chương trình MapReduce Tuy nhiên, chế MapReduce hoạt động liên quan đến đọc/ghi HDFS nhiều Điều không hiệu khơng liên quan đến việc đọc ghi liệu vào đĩa mà liên quan đến hoạt động nhập/xuất chép liệu cụm máy tính với khả chịu lỗi Ngồi ra, lần lặp MapReduce có độ trễ cao, lần lặp bắt đầu cơng việc trước hồn tồn kết thúc Spark chứa thư viện đồ thị tính tốn gọi GraphX Kết hợp khả tính toán nhớ hỗ trợ khả xử lý đồ thị Spark góp phần cải thiện hiệu suất thuật tốn so với chương trình MapReduce truyền thống Ngồi ra, phần lớn thuật tốn máy học địi hỏi việc thực thi thuật tốn có tính lặp lại Các thuật tốn liên quan đến tượng nghẽn cổ chai I/O việc triển khai MapReduce MapReduce sử dụng tác vụ song song tạo gánh nặng cho giải thuật đệ quy Spark có thư viện máy học gọi MLib mà bao gồm giải thuật mức cao phù hợp với lặp lại hiệu so với sử dụng MapReduce Hadoop Cơ chế nhớ đệm Spark Do RDD khởi tạo lại lần thực Action nên tốn nhiều thời gian ta gặp phải trường hợp RDD sử dụng lại nhiều lần, chi phí cho cơng việc lớn Vì thế, Spark hỗ trợ chế gọi persist hay cache Khi yêu cầu Spark thực persist RDD, nút chứa RDD lưu RDD vào nhớ, nút tính tốn lần Nếu việc persist thất bại, Spark tự tính lại phần bị thiếu cần thiết TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 732 C Bộ lọc Bloom giao Bộ lọc Bloom Bộ lọc Bloom (Bloom Filter, BF) [39] giới thiệu năm 1970 Burton Bloom cấu trúc liệu xác suất sử dụng để kiểm tra xem phần tử có nằm tập hợp hay khơng Hình Cấu trúc lọc Bloom Hình biểu diễn cấu trúc lọc Bloom gồm m bit, k hàm băm độc lập tập hợp S gồm n phần tử biểu diễn BF(S) Hoạt động lọc BF(S) mô tả sau:    Khởi đầu, bit BF thiết lập Khi thêm phần tử x thuộc S vào lọc, k vị trí x mảng bit BF xác định k hàm băm vị trí đặt với giá trị Thực công việc với tất phần tử S để có BF biểu diễn cho tập S hay gọi BF(S) Để kiểm tra phần tử z có thuộc S hay không, cần kiểm tra tất k vị trí z (tương ứng k hàm băm giá trị z): o Nếu tất giá trị vị trí z ∈ S o Ngược lại, tồn vị trí có giá trị chắn z ∉ S Trong số trường hợp, hàm băm cho nhiều phần tử trả giá trị phần tử khơng tồn S có giá trị băm vị trí Chính lý mà BF trả phần tử dương tính giả (false positives), khơng trả phần tử âm tính giả (false negatives) Phần tử dương tính giả phần tử BF xác định thuộc tập S thực khơng thuộc S Phần tử âm tính giả phần tử BF xác định không thuộc tập S thực lại thuộc S Bộ lọc Bloom có nhiều ưu điểm sau:  Không gian lưu trữ hiệu (space eciency): Kích thước lọc cố định, không phụ thuộc vào số lượng phần tử n có mối liên hệ mảng bit m dương tính giả theo xác suất [40]: k kn     1  k f  1  p   1  1     1  e   m       kn m     k Xây dựng lọc nhanh (Fast construction): thực thi BF nhanh, địi hỏi lần qt liệu Truy vấn lọc nhanh hiệu quả: việc kiểm tra vị trí phần tử S u cầu tính tốn k hàm băm (k thường số nhỏ) truy cập đến k bit Bộ lọc Bloom giao Bộ lọc Bloom giao (Intersection Bloom Filter, IBF) nhóm đề xuất nghiên cứu [17, 41] IBF cấu trúc liệu xác suất thiết kế để biểu diễn phần giao hai tập hợp sử dụng để nhận phần tử chung tập hợp với xác suất dương tính giả (false positive) a) Các phương thức xây dựng lọc Bloom giao IBF tiếp nhận đầu vào trả kết với hai khả xảy sau:   “No”: x KHÔNG phải yếu tố chung tập S1 S2 “Yes”: x LÀ yếu tố chung tập S1 S2 Ba tiếp cận để xây dựng lọc giao IBF: (1) cặp lọc Bloom, (2) giao hai lọc Bloom (3) giao hai lọc Bloom phân đoạn   Tiếp cận 1: Hình Cấu trúc lọc Bloom giao (a) mô tả tiếp cận dùng cặp lọc Bloom Phần giao hai tập hợp công thức sau: S1 ∩ S2 = (S1 ∪ S2) \ (S1 ∆ S2) = (S1 ∪ S2) \ ((S1 \ S2) ∪ (S2 \ S1)) Điều tương ứng với việc sử dụng lọc BF(S1) cho tập S2 để chọn phần tử chung S2 sử dụng lọc BF(S2) cho tập S1 để chọn phần tử chung S1 Gộp kết nhận tất phần tử chung tập hợp Ưu điểm cách tiếp cận không yêu cầu lọc phải có kích thước (m) k hàm băm Tiếp cận 2: Hình Cấu trúc lọc Bloom giao (b) mô tả tiếp cận giao hai lọc Bloom Phan Thượng Cang, Trần Thị Tố Quyên, Phan Anh Cang  733 Với cách tiếp cận đòi hỏi hai lọc Bloom phải có kích thước m k hàm băm giống Để xây dựng lọc giao IBF, tính giao hai lọc Bloom BF(S1) BF(S2) phép toán AND bit sau: IBF(S1, S2) = BF(S1) & BF(S2) Để kiểm tra phần tử có phần tử chung hay không, tác giả tiến hành thực truy vấn vào lọc giao vừa tạo (IBF) Ưu điểm phương pháp tiếp cận trì giao lọc Bloom để loại bỏ hầu hết tuple không tham gia từ hai nguồn liệu đầu vào thay sử dụng hai lọc phương pháp tiếp cận Tiếp cận 3: Hình (c) mơ tả tiếp cận giao hai lọc Bloom phân đoạn Bộ lọc Bloom phân đoạn (Partitioned Bloom filter) [42], biến thể lọc Bloom chuẩn, định nghĩa mảng m bit chia thành k mảng rời với kích thước mp = m/k bit Tương tự tiếp cận 2, lọc giao IBF(S1, S2) tạo việc giao hai lọc Bloom phân đoạn BF(S1) BF(S2) phép toán AND (a) (b) (c) Cặp lọc Bloom Giao hai lọc Bloom Giao hai lọc Bloom phân đoạn Hình Cấu trúc lọc Bloom giao b) Xác suất phần giao sai Xác suất phần giao sai tỉ lệ dương tính giả lọc giao IBF Từ kết chứng minh nghiên cứu [17, 41], xác xuất phần giao sai cho tiếp cận định nghĩa sau:  Xác suất phần giao sai tiếp cận (dùng cặp lọc Bloom): a cho BF(S1), f  pair( S1 ) k1|S1|       1  1    m1     b cho BF(S2), k1 f  pair( S2 ) k |S |        1  1    m2     k2 Trong đó, m1, k1 m2, k2 là kích thước số hàm băm tương ứng lọc BF(S1) BF(S2)  Xác suất phần giao sai tiếp cận (giao hai lọc Bloom):    k | S1 |    k | S |  f  BF  1  1    1  1      m    m      Trong đó, BF(S1), BF(S2) IBF(S1, S2) có kích thước m k hàm băm Xác suất phần giao sai tiếp cận (giao hai lọc phân đoạn): k f PBF |S |   k 1  1  1      m    k k |S |    1  1  k     m    k Trong đó, BF(S1), BF(S2) IBF(S1, S2) có kích thước m k hàm băm, k phân đoạn với kích thước mp=m/k TỐI ƯU HĨA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 734  So sánh xác suất phần giao sai tiếp cận: Xác suất phần giao sai tiếp cận gần nhỏ xác suất phần giao sai tiếp cận 3: f  pair  f  BF  f  PBF Điều có nghĩa hiệu suất lọc tiếp cận tốt tiếp cận chúng nhận biết sai phần tử chung D Giải thuật Intersection Bloom Join Intersection Bloom Join [41] giải thuật Join cải tiến từ giải thuật Bloom Join với việc sử dụng lọc Bloom giao IBF thay dùng lọc Bloom chuẩn Giải thuật dùng lọc Bloom giao để lọc hai tập liệu nhằm loại bỏ hầu hết phần tử không tham gia vào Join giảm đáng kể chi phí liên quan Nó chứng minh hiệu so với thuật giải thuật Join khác [17] Chính mà giải thuật Intersection Bloom Join giải thuật sử dụng cho Join đệ quy nghiên cứu III TỐI ƯU HÓA JOIN ĐỆ QUY TRONG MAPREDUCE VỚI SPARK A Join đệ quy Join đệ quy quan hệ K(x, y) bao đóng bắc cầu quan hệ K Nó địi hỏi khởi tạo lặp lại khơng có kết tìm thấy [17]: (Initialization) A(x, y) K(x, y) { (Iteration) A(x, y) A(x, z) ⋈ K(z, y) B Tối ưu hóa Join đệ quy MapReduce Giải thuật Join đệ quy MapReduce Một giải thuật Join đệ quy phổ biến phù hợp để triển khai môi trường MapReduce gần giải thuật Semi-Nạve [17, 37] Ngồi ra, áp dụng cho việc tính tốn tập liệu quan hệ dạng hàng cột (tabular) mà chúng tơi quan tâm xử lý Chính vậy, nghiên cứu tập trung việc tối ưu hóa thuật tốn Semi-Nạve cho Join đệ quy mơi trường MapReduce Giải thuật Semi-Nạve cho việc tính tốn Join đệ quy: Algorithm – Thuật tốn Semi-Nạve cho Join đệ quy F0=⌽, ∆F0=K(x,y), i=0; (1) Repeat (2) i++; (3) Fi-1 (∆F0   ∆Fi-1); (4) ∆Fi ∏xy(∆Fi-1 ⋈z K) – Fi-1; (5) Until ∆Fi = ⌽; (6) Giải thuật thực thi lặp lại công việc MapReduce: công việc Join (Join job) công việc xác định tập liệu tăng cường (job for computing incremental dataset) Tại vòng lặp thứ i, công việc Join thực thi join ∆Fi-1 K để tạo tập Oi Công việc xác định tập liệu tăng cường đọc tập liệu Oi tính ∆Fi = Fi-1 - Oi cách loại bỏ trùng lắp Oi với kết trước Đề xuất giải pháp tối ưu cho Join đệ quy MapReduce Xem xét dịng (5) thuật tốn Semi-Nạve, ∆Fi ∏xy(∆Fi-1 ⋈z K) – Fi-1, tiến hành đề xuất số giải pháp tối ưu hóa cho thuật tốn thực thi môi trường MapReduce sau (1) Sử dụng chế xử lý lặp nhớ để làm tăng hiệu thực thi cho công việc Vấn đề giải việc tận dụng khả xử lý lặp Spark RDD (2) Sử dụng chế cache tập liệu K để giảm thiểu chi phí đọc viết liệu lại nhiều lần K tập liệu khơng có thay đổi lần lặp Chúng tơi tìm thấy giải pháp cho vấn đề việc sử dụng chế vùng đệm Spark để thực cache tập K nhớ, đầy tràn xuống đĩa cứng theo thứ tự: MEMORY_AND_DISK_SER (3) Loại bỏ liệu dư thừa không tham gia vào Join để giảm đáng kể chi phí có liên quan đến việc đọc/viết truyền thơng cho liệu vơ ích Chúng tơi sử dụng lọc giao IBF để loại bỏ liệu dư thừa công việc Join F K Thuật toán Join sử dụng trường hợp thuật toán Intersection Bloom Join [41] trình bày trước Phan Thượng Cang, Trần Thị Tố Quyên, Phan Anh Cang 735 Công việc tiền xử lý Trước thực Join hai tập liệu K với F, hai tập liệu cần chuyển thành kiểu liệu Spark – PairRDD loại bỏ cặp khóa/giá trị rỗng Song song đó, xây dựng lọc giao IBF(K, F) theo tiếp cận đề xuất trước Sự thực thi lặp Join đệ quy Hai tập liệu K F lọc lọc giao IBF(K, F) để loại bỏ phần tử không tham gia Join Sau đó, tiến hành Join hai tập liệu lọc Sau lần join, tiến hành xử lý kết join để tạo F công việc thứ Việc join lần thực tập K F vừa tạo Việc join hai tập liệu lặp lại nhiều lần bắt gặp điều kiện dừng, giải thuật join đệ quy kết thúc Trong trình tạo tập liệu, chúng tơi có thực phân mảnh (PartitionBy) cho tập liệu, nhằm chia nhỏ liệu, tránh việc tràn nhớ, giảm liệu vận chuyển qua mạng tăng tốc độ xử lý Các điều kiện dừng cho thuật toán Join đệ quy (fixpoint):    Chu trình xử lý đạt đến số vịng lặp tối đa giới hạn Hoặc Fi rỗng, khơng có liệu sinh Hoặc giao hai lọc BF_K BF_DeltaFi rỗng, kết sinh khơng có liệu tham gia vào join vịng lặp Hình Lưu đồ giải thuật tối ưu hố Join đệ quy Spark Hình lưu đồ cho giải thuật tối ưu hóa Join đệ quy Spark Dựa vào giải thuật Semi-Naïve, đưa giải thuật tối ưu hóa Join đệ quy Spark sau: Algorithm – Giải thuật tối ưu hóa Semi-Nạve cho Join đệ quy MapReduce // Đọc file từ HDFS JavaSparkContext.textFile(input) // Tạo JavaPairRDD pairRDD_K ← createJavaPairRDD (input, column) //cache pairRDD_K pairRDD_DeltaF ← createJavaPairRDD (input, column) RDD_F ← createJavaPairRDD (input, column) //cache RDD_F // Xây dựng lọc Bloom TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 736 BF_K ← addKeyBF_K(pairRDD_K) // BF_K chứa khóa tập K BF_DeltaF ← addKeyBF_DeltaF(pairRDD_DeltaF) //BF_DeltaF chứa khóa DeltaF // Thực join đệ quy recursiveJoin (pairRDD_K, pairRDD_DeltaF, iteration){ IBF ← BF_K.and(BF_DeltaF) //Tạo lọc giao IBF(K, DeltaF) if (! IBF.isEmpty() && iteration < maxIteration){ // Lọc liệu không tham gia join tập K temp_K ← filter(pairRDD_K) // Lọc liệu không tham gia join tập DeltaF temp_DeltaF ←filter(pairRDD_DeltaF) // Join hai tập liệu lọc joinResult ← temp_K.join (temp_DeltaF) // Xử lý kết join dạng JavaPairRDD rs ← combineKeyValue (JavaPairRDD.fromJavaRDD(joinResult.values(), int column); //Loại kết trùng lắp rs ← rs.subtract(RDD_F) //Lưu kết vào HDFS rs.saveAsTextFile (path output) pairRDD_DeltaF ← createJavaPairRDD (rs, column) // Tạo lại BF_DeltaF addKeyBF_DeltaF(pairRDD_DeltaF) // Bổ sung kết F RDD_F ← RDD_F.union(rs) //cache RDD_F iteration++ // Đệ quy recursiveJoin (pairRDD_K, pairRDD_DeltaF, iteration) } } Mơ hình chi phí Join đệ quy MapReduce a) Các tham số mơ hình chi phí Bảng bảng tham số sử dụng mơ hình chi phí Join đệ quy Map Reduce Bảng Các tham số cho mơ hình chi phí Join đệ quy MapReduce Parameter Explanation cl Chi phí đọc hay ghi liệu cục cr Chi phí đọc hay ghi liệu từ xa ct Chi phí truyền thơng liệu từ nút đến nút khác B+1 Kích thước vùng đệm xếp B+1 pages mpk Tổng số tác vụ map tập liệu K mp∆Fi-1 Tổng số tác vụ map tập liệu tăng cường ∆Fi-1 mpOi Tổng số tác vụ map tập liệu kết Join Oi |K| Kích thước tập liệu K |∆Fi-1| Kích thước tập liệu tăng cường lần lặp i-1 |∆F0| = |K| |∆Fi| Kích thước tập liệu tăng cường lần lặp i |Fi-1| Kích thước tất tập liệu tăng cường lần lặp từ đến i-1 |Di| Kích thước tập liệu trung gian cơng việc Join Ji |D+i| Kích thước tập liệu trung gian cơng việc tính tập liệu tăng cường Ii |Oi| Kích thước tập liệu kết cơng việc Join vịng lặp thứ i fIBF(K) Xác xuất dương tính giả lọc giao Bloom IBF(K) Phan Thượng Cang, Trần Thị Tố Quyên, Phan Anh Cang ∂i-1K φi l Cpre CK Tỉ lệ Join ∆Fi-1 với K Tỉ lệ khác biệt tập kết Oi với Fi-1 Số lần lặp chiều sâu đồ thị quan hệ trừ Tổng chi phí thực thi cơng việc tiền xử lý phân tán BF(K) đến nút Tổng chi phí để đọc, map, xếp, trộn (shuffle), cache K the reducers (RIC) lần lặp Tổng chi phí để đọc tập liệu tăng cường ∆Fi-1 Tổng chi phí để xếp chép (sort and copy) cho công việc Join nút mappers reducers Tổng chi phí để chuyển liệu trung gian nút cho công việc Join Tổng chi phí để đọc cục phần liệu K cache reducers Tổng chi phí để viết kết công việc Join (Oi) Tổng chi phí để đọc Oi Tổng chi phí để xếp chép (sort and copy) cho cơng việc tính tập liệu tăng cường nút mappers reducers Tổng chi phí để chuyển liệu trung gian nút cho cơng việc tính tập liệu tăng cường Tổng chi phí để đọc cục phần liệu Fi-1 cache reducers Tổng chi phí để viết kết tập liệu tăng cường ∆Fi Cread (Ji) Csort (Ji) Ctr (Ji) Ccache (Ji) Cwrite (Ji) Cread (Ii) Csort (Ii) Ctr (Ii) Ccache (Ii) Cwrite (Ii) Theo đó, đưa chi phí tổng Join đệ quy sau: l C ( Jˆ )  C K   Cread ( J i )  Csort ( J i )  Ctr ( J i )  Ccache ( J i )  Cwrite ( J i ) i 1 l   Cread ( I i )  Csort ( I i )  Ctr ( I i )  Ccache ( I i )  Cwrite ( I i ) i 1 Trong đó:  CK = cr |K| + cl |K|.2.( log B | K |  log B (mpk )  log B (mpk ) ) + (ct + cl) |K|  Cread (Ji) = cr |∆Fi-1|  Csort (Ji) = cl |Di| ( log B | Di |  log B (mpFi 1 )  log B (mpFi 1 ) )  Ctr (Ji) = ct |Di|  Ccache (Ji) = cl |K|  Cwrite (Ji) = cr |Oi|  |Di|  Cread (Ii) = cr |Oi|  Csort (Ii) = cl |D+i| ( log B | Oi |  log B (mpOi )  log B (mpOi ) )  Ctr (Ii) = ct |D+i |  Ccache (Ii) = cl |Fi-1|  Cwrite (Ii) = cr |∆Fi|  |D+i| = |Oi| |∆Fi-1| = φi-1.|Oi-1|  |∆Fi| = φi |Oi| 737 TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 738 b) Phân tích chi phí hai hướng tiếp cận Đầu tiên, so sánh chi phí thực thi Join đệ quy tảng Hadoop Spark: C Hadoop(Jˆ ) CSpark (Jˆ ) Hầu hết hoạt động I/O Hadoop đĩa từ xa HDFS, chúng thực thi nhớ Spark Vì vậy, tất chi phí thành phần Hadoop lớn nhiều so với chi phí Spark Chúng ta dễ dàng suy ra: C Hadoop(Jˆ ) > CSpark(Jˆ ) Vấn đề cịn lại so sánh chi phí thực thi Join đệ quy chưa tối ưu với giải pháp tối ưu tảng Spark: CSpark(Jˆ ) COptSpark(Jˆ ) Chúng ta cần so sánh thành phần liệu trung gian tạo cơng việc Join yếu tố định đến chi phí tổng thực thi Join đệ quy Lượng liệu trung gian công việc Join Join đệ quy sau:  Đối với Join đệ quy chưa tối ưu: |Di|  |∆Fi-1| = φi-1.|Oi-1| Đối với Join đệ quy tối ưu: |Di| = ∂i-1K.|∆Fi-1| + fIBF(K) (1 − ∂i-1K).|∆Fi-1| = ∂i-1K.|Di| + fIBF(K) (1 − ∂i-1K) |Di| ≤ |Di| Ngoài ra, giải pháp tối ưu kết thúc trước vòng lặp so với giải pháp chưa tối ưu nhờ vào đặc tính lọc Bloom giao Vì vậy, sau nhận biểu thức: C Hadoop(Jˆ ) > CSpark(Jˆ ) > COptSpark(Jˆ ) Điều có nghĩa giải pháp đề xuất nghiên cứu mang lại tối ưu hóa chi phí thực thi cho Join đệ quy Spark so với giải pháp So với giải thuật Join đệ quy chưa cải tiến (không sử dụng cache, lọc), giải thuật Join đệ quy có sử dụng cache lọc giảm lượng chi phí lớn việc đọc ghi lại liệu nhiều lần đĩa, liệu dư thừa trình Join liệu vận chuyển qua mạng Cùng với đó, việc sử dụng lọc giao làm điều kiện dừng tránh lần Join dư thừa cuối cùng, không cần phải đợi kết Join rỗng kết thúc chương trình IV THỰC NGHIỆM VÀ ĐÁNH GIÁ A Mô tả cluster liệu Chúng tiến hành thực nghiệm cụm máy tính gồm 14 nút (1 master 13 slaves) Phịng thí nghiệm Mạng di động Dữ liệu lớn Khoa Công nghệ thông tin TT, Trường Đại học Cần Thơ Mỗi máy tính có cấu hình CPUs Intel Core i5 3.2 Ghz với RAM: 4GB, HDD: 500GB, hệ điều hành Ubuntu 14.04 LTS 64 bits Phiên Java cài đặt 1.8, Hadoop 2.7.1, Spark 1.6 Dữ liệu chuẩn sinh Purdue MapReduce Benchmarks Suite có kích thước 5GB, 10GB, 20GB 30GB Các tập liệu lưu trữ dạng tập tin văn (text file) Mỗi dòng tập tin liệu có tối đa 39 trường phân biệt dấu phẩy Mỗi trường liệu chứa 19 ký tự B Phương thức đánh giá Nhóm chúng tơi áp dụng ba tiếp cận: giải thuật Semi-Naïve Hadoop, giải thuật Semi-Nạve Spark Semi-Nạve có áp dụng giải pháp cải tiến để thực thi câu truy vấn Join đệ quy đề cập phần I Trên tập liệu thực nghiệm, đánh giá ba tiếp cận dựa lượng liệu trung gian cần vận chuyển qua mạng, lượng liệu cần đọc vào thời gian thực thi C Tham số sử dụng cho lọc Bloom Các tham số dùng để xây dựng lọc Bloom bảng sau: Tests Bảng Các Tham số để xây dựng lọc Bloom fBF0 n0 k m/n m (bit) n fBF Test 0.000101 50,000 21 1,050,000 15,002 0.000000 Test 0.000101 50,000 21 1,050,000 15,053 0.000000 Test 0.000101 50,000 21 1,050,000 15,101 0.000000 Test 0.000101 50,000 21 1,050,000 15,121 0.000000 Phan Thượng Cang, Trần Thị Tố Quyên, Phan Anh Cang 739 D Đánh giá ba hướng tiếp cận Chúng tơi tiến hành so sánh giải thuật Semi-Nạve Hadoop, Semi-Naïve Spark Semi-Naïve cải tiến để thấy lượng liệu trung gian, lượng liệu đọc vào thời gian thực thi, qua đánh giá mức độ cải tiến đề xuất nghiên cứu Bảng Lượng liệu trung gian tiếp cận (#records) Tiếp cận 5GB.Test1 10GB.Test2 20GB.Test3 Semi-Naïve – Hadoop 30GB.Test3 73,339,332 146,668,049 293,330,613 421,466,111 Semi-Naïve – Spark 7,281,636 22,884,615 45,755,154 103,957,219 Semi-Naïve + Cache + Filter – Spark 1,139,985 4,158,931 9,152,159 24,870,278 Bảng mô tả kết lượng liệu trung gian cần vận chuyển qua mạng ba hướng tiếp cận: Hình Lượng liệu trung gian ba hướng tiếp cận Hình Lượng liệu cần đọc ba hướng tiếp cận Kết so sánh thể rõ cải tiến Spark so với Hadoop Hình Từ việc quản lý công việc lặp phân chia partitions nhớ giúp giảm thiểu đáng kể lượng liệu trung gian cần vận chuyển qua mạng Bộ lọc Bloom tính cache tiếp tục cải tiến, làm giảm thêm lượng liệu dư thừa khơng tham gia vào q trình Join, tối ưu việc xử lý cho join đệ quy Spark Bảng mô tả kết lượng liệu cần đọc ba hướng tiếp cận Bảng Lượng liệu cần đọc tiếp cận Tiếp cận (s) 5GB.Test1 10GB.Test2 20GB.Test3 Semi-Naïve – Hadoop 30GB.Test3 147,615,684 295,213,667 590,437,461 975,000,351 Semi-Naïve – Spark 9,362,202 41,615,177 83,208,544 268,632,499 Semi-Naïve + Cache + Filter – Spark 2,080,330 8,317,760 16,627,752 34,850,020 Hình Thời gian thực thi ba hướng tiếp cận Kết từ Hình cho thấy từ tính lập lịch biểu để xử lý luồng liệu quản lý vòng lặp, Spark thực thi trực tiếp nhớ tránh việc quét lại liệu nhiều lần Bên cạnh đó, việc sử dụng cache tối ưu chi phí quét liệu đầu vào Hình cho thấy Spark cải thiện nhiều tốc độ xử lý so với Hadoop Từ nghiên cứu cải tiến giúp tối ưu hoá thời gian thực thi cho giải thuật Semi Nạve Đối với giải thuật Semi-Nạve có cải tiến, liệu lớn hiệu suất cải thiện, liệu nhỏ tốn chi phí cho việc xử lý lọc TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 740 Bảng Thời gian thực thi hướng tiếp cận (giây) Tiếp cận (s) 5GB.Test1 10GB.Test2 20GB.Test3 Semi-Naïve – Hadoop 30GB.Test3 1,202 2,279 3,984 8,472 Semi-Naïve – Spark 844 1,251 2,669 6,583 Semi-Naïve + Cache + Filter – Spark 424 715 1,436 2,696 V KẾT LUẬN VÀ KIẾN NGHỊ A Kết luận nghiên cứu Nhóm nghiên cứu đưa giải pháp cải tiến hiệu cho vấn đề “Tối ưu hoá Join đệ quy tập liệu lớn môi trường MapReduce” Những kết đáng ý nghiên cứu bao gồm: (1) Một điều tra giải pháp có cho Join đệ quy tập liệu lớn mơi trường MapReduce Nó hạn chế giải pháp cần thiết cho đề xuất nghiên cứu (2) Tối ưu hóa cho Join đệ quy MapReduce Những giải pháp hiệu dùng để cải tiến Join đệ quy sau: (a) Cơ chế xử lý lặp nhớ với Spark RDD nhằm làm tăng hiệu thực thi; (b) Cơ chế vùng nhớ đệm Spark nhằm cache tập liệu không đổi lần lặp giảm thiểu chi phí đọc viết lại liệu; (c) Bộ lọc giao thuật toán Intersection Bloom Join nhằm loại bỏ liệu dư thừa khơng tham gia vào Join, có nghĩa làm giảm chi phí có liên quan đến việc đọc/viết truyền thơng cho liệu vơ ích (3) Mơ hình chi phí cho Join đệ quy MapReduce Đây sở lý thuyết quan trọng để làm sở cho việc đánh giá so sánh giải pháp (4) Sự triển khai phát triển ứng dụng tảng xử lý liệu lớn phổ biến Hadoop hệ mới Spark (5) Các thực nghiệm đánh giá cho Join đệ quy MapReduce với Hadoop Spark Join đệ quy phép tốn tiêu tốn nhiều chi phí, thời gian tài ngun Thơng qua mơ hình chi phí thực nghiệm, chúng tơi chứng minh giải pháp cải tiến mang lại hiệu đáng kể so với giải pháp tính tốn Join đệ quy tập liệu lớn Việc thực thi Join đệ quy môi trường Spark khai thác tối đa khả Spark xử lý song song phân tán, xử lý lặp, chế nhớ đệm tính tốn nhanh nhớ Hơn nữa, việc sử dụng lọc Bloom để loại bỏ phần tử khơng tham gia join tồn tập liệu đầu vào làm giảm bớt gánh nặng đọc/viết xử lý nhiều liệu Những đóng góp chúng tơi có ý nghĩa thực tiễn cao Bộ lọc giao áp dụng để giải vấn đề phổ biến nhiều lĩnh vực Join, hòa giải chống trùng lắp liệu (reconciliation and deduplication), sửa lỗi (error-correction), v.v Tối ưu hóa Join đệ quy MapReduce với Spark mang lại lợi ích to lớn cho nhiều lĩnh vực sở liệu lớn, mạng xã hội, tin sinh học, mạng sensor, giám sát mạng, máy học, v,v Sau cùng, nghiên cứu bước quan trọng đóng góp vào ngữ cảnh tối ưu hóa quản lý liệu lớn sở hạ tầng đám mây B Hướng phát triển Mặc dù, giải thuật giảm thiểu nhiều chi phí cho việc đọc/viết liệu tăng tốc cho trình xử lý Tuy nhiên, việc tối ưu Join đệ quy tập liệu lớn mơi trường Spark cịn tồn nhiều hạn chế Để đạt hiệu mong muốn, đòi hỏi phải có hệ thống cụm máy tính (cluster) đủ mạnh chạy ổn định xử lý liệu sau lần Join Hơn nữa, vấn đề nghiêng liệu thách thức lớn cho đề tài cho toán xử lý liệu lớn nói chung Đây hướng phát triển mà đề tài muốn hướng đến tương lai TÀI LIỆU THAM KHẢO [1] [2] [3] [4] [5] [6] [7] [8] J Dean and S Ghemawat, “MapReduce: simplified data processing on large clusters,” Commun ACM, vol 51, no 1, p 107, Jan 2008 “Apache Hive TM.” [Online] Available: https://hive.apache.org/ [Accessed: 14-Jun-2016] K Wiley, A Connolly, S Krughoff, J Gardner, M Balazinska, B Howe, Y Kwon, and Y Bu, “Astronomical Image Processing with Hadoop,” ResearchGate, Jul 2011 Page, Lawrence, Brin, Sergey, Motwani, Rajeev, Winograd, and Terry, “Page, L., et al.: The PageRank citation ranking: Bringing order to the web,” ResearchGate, Jan 1998 J M Kleinberg, “Authoritative Sources in a Hyperlinked Environment,” J ACM, vol 46, no 5, pp 604–632, Sep 1999 Bancilhon and R Ramakrishnan, “An Amateur's Introduction to Recursive Query Processing Strategies,” 1986 A K Jain, M N Murty, and P J Flynn, Data Clustering: A Review 1999 M T Hagan, H B Demuth, M H Beale, and O De Jess, Neural Network Design, 2nd ed USA: Martin Hagan, 2014 Phan Thượng Cang, Trần Thị Tố Quyên, Phan Anh Cang [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] 741 S Wasserman and K Faust, Social Network Analysis: Methods and Applications Cambridge University Press, 1994 A W Moore and D Zuev, “Internet Traffic Classification Using Bayesian Analysis Techniques,” in Proceedings of the 2005 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems, New York, NY, USA, 2005, pp 50–60 E F Codd, “A Relational Model of Data for Large Shared Data Banks,” Commun ACM, vol 13, no 6, pp 377–387, Jun 1970 E F Codd, “Relational Completeness of Data Base Sublanguages,” R Rustin Ed Database Syst 65-98 Prentice Hall IBM Res Rep RJ 987 San Jose Calif., 1972 K.-L Tan and H Lu, “A Note on the Strategy Space of Multiway Join Query Optimization Problem in Parallel Systems,” SIGMOD Rec, vol 20, no 4, pp 81–82, Dec 1991 X Lin and M E Orlowska, “An efficient processing of a chain join with the minimum communication cost in distributed database systems,” Distrib Parallel Databases, vol 3, no 1, pp 69–83, Jan 1995 C Ordonez, “Optimizing Recursive Queries in SQL,” in Proceedings of the 2005 ACM SIGMOD International Conference on Management of Data, New York, NY, USA, 2005, pp 834–839 S Idreos, E Liarou, and M Koubarakis, “Continuous Multi-way Joins over Distributed Hash Tables,” in Proceedings of the 11th International Conference on Extending Database Technology: Advances in Database Technology, New York, NY, USA, 2008, pp 594–605 T.-C Phan, L d’Orazio, and P Rigaux, “A Theoretical and Experimental Comparison of Filter-Based Equijoins in MapReduce,” in Transactions on Large-Scale Data- and Knowledge-Centered Systems XXV, A Hameurlain, J Küng, and R Wagner, Eds Springer Berlin Heidelberg, 2016, pp 33–70 “Apache SparkTM - Lightning-Fast Cluster Computing.” [Online] Available: http://spark.apache.org/ [Accessed: 14-Jun2016] “The Apache Cassandra Project.” [Online] Available: http://cassandra.apache.org/ [Accessed: 14-Jun-2016] “Apache HBase – Apache HBaseTM Home.” [Online] Available: https://hbase.apache.org/ [Accessed: 14-Jun-2016] “Amazon Simple Storage Service (S3) - Cloud Storage,” Amazon Web Services, Inc [Online] Available: //aws.amazon.com/s3/ [Accessed: 14-Jun-2016] M Zaharia, M Chowdhury, M J Franklin, S Shenker, and I Stoica, “Spark: Cluster Computing with Working Sets,” in Proceedings of the 2Nd USENIX Conference on Hot Topics in Cloud Computing, Berkeley, CA, USA, 2010, pp 10–10 M Zaharia, M Chowdhury, T Das, A Dave, J Ma, M McCauley, M J Franklin, S Shenker, and I Stoica, “Resilient Distributed Datasets: A Fault-tolerant Abstraction for In-memory Cluster Computing,” in Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation, Berkeley, CA, USA, 2012, pp 2–2 F Bancilhon, “Naive Evaluation of Recursively Defined Relations,” in On Knowledge Base Management Systems, M L Brodie and J Mylopoulos, Eds Springer New York, 1986, pp 165–178 I Balbin and K Ramamohanarao, “A Generalization of the Differential Approach to Recursive Query Evaluation,” J Log Program, vol 4, no 3, pp 259–262, Sep 1987 F Bancilhon, D Maier, Y Sagiv, and J D Ullman, “Magic Sets and Other Strange Ways to Implement Logic Programs (Extended Abstract),” in Proceedings of the Fifth ACM SIGACT-SIGMOD Symposium on Principles of Database Systems, New York, NY, USA, 1986, pp 1–15 J D Ullman, Principles of Database and Knowledge-base Systems, Vol I New York, NY, USA: Computer Science Press, Inc., 1988 Y E Ioannidis, “On the Computation of the Transitive Closure of Relational Operators,” in Proceedings of the 12th International Conference on Very Large Data Bases, San Francisco, CA, USA, 1986, pp 403–411 P Valduriez and H Boral, “Evaluation of Recursive Queries Using Join Indices,” in Expert Database Systems, 1986, pp 271–293 S Warshall, “A Theorem on Boolean Matrices,” J ACM, vol 9, no 1, pp 11–12, Jan 1962 H S Warren Jr., “A Modification of Warshall’s Algorithm for the Transitive Closure of Binary Relations,” Commun ACM, vol 18, no 4, pp 218–220, Apr 1975 F N Afrati, V Borkar, M Carey, N Polyzotis, and J D Ullman, “Map-reduce Extensions and Recursive Queries,” in Proceedings of the 14th International Conference on Extending Database Technology, New York, NY, USA, 2011, pp 1–8 F N Afrati, V Borkar, M Carey, N Polyzotis, and J D Ullman, “Cluster Computing, Recursion and Datalog,” in Proceedings of the First International Conference on Datalog Reloaded, Berlin, Heidelberg, 2011, pp 120–144 G Malewicz, M H Austern, A J Bik, J C Dehnert, I Horn, N Leiser, and G Czajkowski, “Pregel: A System for Largescale Graph Processing,” in Proceedings of the 2010 ACM SIGMOD International Conference on Management of Data, New York, NY, USA, 2010, pp 135–146 J Chandar, “Join Algorithms using Map/Reduce,” University of Edinburgh, 2010 Y Bu, B Howe, M Balazinska, and M D Ernst, “The HaLoop Approach to Large-scale Iterative Data Analysis,” VLDB J., vol 21, no 2, pp 169–190, Apr 2012 T T Q Tran, “Traitement de la jointure récursive en MapReduce,” Université Blaise Pascal-Clermont-Ferrand II, ClermontFerrand, 2014 742 [38] [39] [40] [41] [42] TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK M Shaw, P Koutris, B Howe, and D Suciu, “Optimizing Large-scale Semi-NaïVe Datalog Evaluation in Hadoop,” in Proceedings of the Second International Conference on Datalog in Academia and Industry, Berlin, Heidelberg, 2012, pp 165–176 B H Bloom, “Space/time trade-offs in hash coding with allowable errors,” Commun ACM, vol 13, no 7, pp 422–426, Jul 1970 D Guo, J Wu, H Chen, and X Luo, “Theory and Network Applications of Dynamic Bloom Filters,” in Proceedings IEEE INFOCOM 2006 25TH IEEE International Conference on Computer Communications, 2006, pp 1–12 T C Phan, L d’Orazio, and P Rigaux, “Toward Intersection Filter-based Optimization for Joins in MapReduce,” in Proceedings of the 2Nd International Workshop on Cloud Intelligence, New York, NY, USA, 2013, p 2:1–2:2 A Kirsch and M Mitzenmacher, “Less Hashing, Same Performance: Building a Better Bloom Filter,” in Algorithms – ESA 2006, Y Azar and T Erlebach, Eds Springer Berlin Heidelberg, 2006, pp 456–467 OPTIMIZATION FOR RECURSIVE JOINS ON LARGE-SCALE DATASETS USING SPARK Phan Thuong Cang, Tran Thi To Quyen, Phan Anh Cang ABSTRACT— MapReduce has recently become the dominant programming model for analyzing and processing large-scale data However, the model has its own limitations It does not completely support iterative computation, caching mechanism, and operations with multiple inputs Besides, I/O and communication costs of the model are so expensive One of notably complex operations used extensively and expensively in MapReduce is a recursive Join It requires processing characteristics that are also the limitations of the MapReduce environment Therefore, this research proposed efficient solutions of processing the recursive join on large-scale datasets using Spark, a next-generation processing engine of MapReduce Our proposal eliminates a large amount of redundant data generated in repeated processing of the join, and takes advantages of in-memory computing means and cache mechanism Through cost models and experiments, the present research shows that our solutions significantly improve the execution perfomance of the recursive Join in MapReduce  ... join vịng lặp Hình Lưu đồ giải thuật tối ưu hố Join đệ quy Spark Hình lưu đồ cho giải thuật tối ưu hóa Join đệ quy Spark Dựa vào giải thuật Semi-Naïve, đưa giải thuật tối ưu hóa Join đệ quy Spark. .. Intersection Bloom Join giải thuật sử dụng cho Join đệ quy nghiên cứu III TỐI ƯU HÓA JOIN ĐỆ QUY TRONG MAPREDUCE VỚI SPARK A Join đệ quy Join đệ quy quan hệ K(x, y) bao đóng bắc cầu quan hệ K... |Oi| 737 TỐI ƯU HÓA JOIN ĐỆ QUY TRÊN TẬP DỮ LIỆU LỚN VỚI SPARK 738 b) Phân tích chi phí hai hướng tiếp cận Đầu tiên, so sánh chi phí thực thi Join đệ quy tảng Hadoop Spark: C Hadoop(Jˆ ) CSpark