Tính mới trong MapReduce là gì?

Vài năm trước, MapReduce được ca ngợi là cuộc cách mạng của lập trình phân tán. Cũng đã có những người chỉ trích nhưng nhìn chung, có một sự cường điệu nhiệt tình. Nó thậm chí còn được cấp bằng sáng chế! [1]

Cái tên gợi nhớ mapvà reducetrong lập trình chức năng, nhưng khi tôi đọc (Wikipedia)

Bước ánh xạ: Nút chủ lấy đầu vào, chia nó thành các vấn đề phụ nhỏ hơn và phân phối chúng cho các nút worker. Một nút worker có thể thực hiện lại lần lượt, dẫn đến cấu trúc cây đa cấp. Nút worker xử lý vấn đề nhỏ hơn và chuyển câu trả lời trở lại nút chủ của nó.

Giảm bước: Nút chủ sau đó thu thập các câu trả lời cho tất cả các vấn đề phụ và kết hợp chúng theo một cách nào đó để tạo đầu ra - câu trả lời cho vấn đề ban đầu đang cố gắng giải quyết.

hoặc [2]

Nội bộ của MAP: [...] MAP chia giá trị đầu vào thành các từ. [...] MAP có nghĩa là liên kết từng cặp khóa / giá trị đã cho của đầu vào với nhiều cặp khóa / giá trị trung gian.

Nội bộ của GIẢM: [...] [GIẢM] thực hiện tổng hợp bắt buộc (giả sử, giảm): lấy nhiều giá trị và giảm chúng thành một giá trị duy nhất.

Tôi không thể không nghĩ: đây là sự phân chia & chinh phục (theo nghĩa của Mergesort), đơn giản và đơn giản! Vì vậy, có tính mới (khái niệm) trong MapReduce ở đâu đó không, hay nó chỉ là một triển khai mới của các ý tưởng cũ hữu ích trong các tình huống nhất định?

1. Bằng sáng chế Hoa Kỳ 7.650.331: "Hệ thống và phương pháp xử lý dữ liệu quy mô lớn hiệu quả" (2010)
2. Mô hình lập trình MapReduce của Google - Được xem lại bởi R. Lämmel (2007)

Tôi không thể không nghĩ: đây là sự phân chia & chinh phục, đơn giản và đơn giản!

M / R không phân chia & chinh phục. Nó không liên quan đến việc áp dụng lặp lại thuật toán cho một tập hợp con nhỏ hơn của đầu vào trước đó. Đó là một đường ống (một chức năng được chỉ định là một thành phần của các chức năng đơn giản hơn) trong đó các giai đoạn đường ống là bản đồ xen kẽ và giảm hoạt động. Các giai đoạn khác nhau có thể thực hiện các hoạt động khác nhau.

Vì vậy, có tính mới (khái niệm) trong MapReduce ở đâu đó không, hay nó chỉ là một triển khai mới của các ý tưởng cũ hữu ích trong các tình huống nhất định?

MapReduce không phá vỡ nền tảng mới trong lý thuyết tính toán - nó không cho thấy một cách mới để phân tách một vấn đề thành các hoạt động đơn giản hơn. Nó cho thấy rằng các hoạt động đơn giản hơn là thực tế cho một loại vấn đề cụ thể.

Các giấy MapReduce của đóng góp là

1. đánh giá một đường ống dẫn của hai toán tử trực giao được hiểu rõ có thể được phân phối hiệu quả và chịu lỗi cho một vấn đề cụ thể: tạo ra một chỉ mục văn bản của kho văn bản lớn
2. đo điểm chuẩn giảm bản đồ cho vấn đề đó để cho biết lượng dữ liệu được truyền giữa các nút và mức độ chênh lệch độ trễ trong các giai đoạn ảnh hưởng đến độ trễ chung
3. chỉ ra cách làm cho hệ thống có khả năng chịu lỗi để các lỗi máy trong quá trình tính toán có thể được bù tự động
4. xác định các lựa chọn thực hiện hữu ích và tối ưu hóa cụ thể

Một số bài phê bình rơi vào các lớp này:

1. "Bản đồ / giảm không phá vỡ nền tảng mới trong lý thuyết tính toán." Thật. Đóng góp ban đầu của bài báo là các toán tử được hiểu rõ này với một bộ tối ưu hóa cụ thể đã được sử dụng thành công để giải quyết các vấn đề thực sự dễ dàng và chịu lỗi hơn các giải pháp một lần.
2. "Tính toán phân tán này không dễ dàng phân hủy thành bản đồ và giảm hoạt động". Đủ công bằng, nhưng nhiều người làm.
3. "Một đường ống gồm n giai đoạn / giai đoạn giảm yêu cầu độ trễ tỷ lệ thuận với số bước giảm của đường ống trước khi bất kỳ kết quả nào được tạo ra." Có lẽ đúng. Toán tử giảm phải nhận tất cả đầu vào trước khi có thể tạo ra đầu ra hoàn chỉnh.
4. "Bản đồ / giảm là quá mức cần thiết cho trường hợp sử dụng này." Có lẽ. Khi các kỹ sư tìm thấy một chiếc búa mới sáng bóng, họ có xu hướng đi tìm bất cứ thứ gì trông giống như một cái đinh. Điều đó không có nghĩa là búa không phải là một công cụ được chế tạo tốt cho một vị trí nhất định.
5. "Bản đồ / thu nhỏ là sự thay thế kém cho DB quan hệ." Thật. Nếu một DB quan hệ chia tỷ lệ thành tập dữ liệu của bạn thì thật tuyệt vời cho bạn - bạn có các tùy chọn.

EDIT (Tháng 3 năm 2014) Tôi nên nói rằng tôi đã làm việc nhiều hơn về các thuật toán cho các mô hình tính toán kiểu MapReduce và tôi cảm thấy như mình đang bị tiêu cực quá mức. Kỹ thuật Divide-Compress-Conquer mà tôi nói đến dưới đây rất linh hoạt và có thể là nền tảng của các thuật toán mà tôi nghĩ là không tầm thường và thú vị.

Hãy để tôi đưa ra một câu trả lời sẽ kém hơn nhiều so với Mike về tính toàn diện, nhưng từ một mô hình của quan điểm lý thuyết tính toán / thuật toán.

$O(n^\epsilon)$$o(\log n)$

$O(1)$

• Phân vùng ví dụ vấn đề (thường là ngẫu nhiên)
• Thực hiện một số tính toán trên mỗi phân vùng song song và biểu diễn kết quả tính toán một cách gọn gàng
• Kết hợp tất cả các giải pháp chương trình con được trình bày nhỏ gọn trên một bộ xử lý và hoàn thành tính toán ở đó

$n$$O(\sqrt{n})$$\sqrt{n}$

Bây giờ, tôi nghĩ rằng đây thực sự là một bước ngoặt thú vị trong việc phân chia và chinh phục, điều khó khăn là sau giai đoạn phân chia bạn cần nén các giải pháp phụ để một bộ xử lý có thể chinh phục. Tuy nhiên, đây thực sự là kỹ thuật duy nhất chúng tôi nghĩ ra cho đến nay. Nó thất bại trong các vấn đề với đồ thị thưa thớt, chẳng hạn như kết nối thưa thớt. Tương phản điều này với mô hình phát trực tuyến, dẫn đến vô số ý tưởng mới, như thuật toán lấy mẫu khéo léo của Flajolet và Martin, thuật toán ghép đôi xác định của Misra và Gries, sức mạnh của các kỹ thuật phác thảo đơn giản, v.v.

Là một mô hình lập trình, giảm bản đồ đã rất thành công. Nhận xét của tôi coi bản đồ giảm như một mô hình tính toán thú vị. Mô hình lý thuyết tốt là một chút lẻ. Nếu chúng theo sát thực tế quá chặt chẽ, chúng khó sử dụng, nhưng quan trọng hơn, (để mượn một thuật ngữ từ học máy) đã chứng minh cho các mô hình quá cụ thể không khái quát hóa, tức là không giữ trong các mô hình khác. Đó là lý do tại sao chúng tôi muốn trừu tượng hóa càng nhiều chi tiết càng tốt, trong khi vẫn còn đủ để thách thức chúng tôi đưa ra các thuật toán mới. Cuối cùng, những ý tưởng mới đó cuối cùng sẽ có thể tìm đường trở lại thế giới thực. PRAM là một mô hình phi thực tế dẫn đến những ý tưởng thú vị nhưng những ý tưởng đó đã được chứng minh là hiếm khi áp dụng cho tính toán song song trong thế giới thực. Mặt khác, phát trực tuyến cũng không thực tế, nhưng nó đã truyền cảm hứng cho những ý tưởng thuật toán thực sự được sử dụng trong thế giới thực. Xemphác họa đếm tối thiểu . Các kỹ thuật phác thảo trên thực tế cũng được sử dụng trong các hệ thống dựa trên bản đồ thu nhỏ.

Tôi hoàn toàn đồng ý với bạn. Từ góc độ khái niệm, không có gì thực sự mới: Map / Giảm ban đầu được biết đến trong Parallel Computing như một mô hình lập trình luồng dữ liệu. Tuy nhiên, từ quan điểm thực tế, Map / Giảm theo đề xuất của Google và với các triển khai nguồn mở tiếp theo cũng đã thúc đẩy Điện toán đám mây và hiện khá phổ biến để phân tách và xử lý song song rất đơn giản. Tất nhiên, nó không phù hợp cho bất cứ điều gì khác đòi hỏi phân tách miền hoặc chức năng phức tạp.

Tôi nghĩ rằng bạn đã đánh vào đầu với nhận xét của bạn.

Không phải sự thật là trong bất kỳ bản đồ ngôn ngữ chức năng nào cũng có thể được song song - ngôn ngữ phải thuần túy . (Tôi tin rằng Haskell là ngôn ngữ hoàn toàn chính thống mơ hồ duy nhất. Lisp, OCaml và Scala đều không thuần túy.)

Chúng ta đã biết về lợi ích của mã thuần từ trước cả khi chia sẻ thời gian, khi các kỹ sư lần đầu tiên đưa ra bộ xử lý của họ. Vậy tại sao không ai sử dụng một ngôn ngữ thuần túy?

Nó thực sự, thực sự, thực sự khó khăn. Lập trình bằng ngôn ngữ thuần túy thường có cảm giác như lập trình bằng cả hai tay bị trói sau lưng.

Những gì MR làm là làm giảm bớt ràng buộc độ tinh khiết phần nào và cung cấp khung cho các phần khác (như pha trộn) làm cho việc viết mã phân phối cho một phần lớn các vấn đề trở nên khá dễ dàng.

$NC=P$