Các trường hợp sử dụng cho Apache Spark vs Hadoop là gì


30

Với Hadoop 2.0 và YARN Hadoop được cho là không còn bị ràng buộc chỉ với các giải pháp thu nhỏ bản đồ. Với sự tiến bộ đó, các trường hợp sử dụng cho Apache Spark vs Hadoop đang xem xét cả hai ngồi trên đỉnh HDFS là gì? Tôi đã đọc qua tài liệu giới thiệu về Spark, nhưng tôi tò mò liệu có ai gặp phải vấn đề nào hiệu quả hơn và dễ giải quyết hơn với Spark so với Hadoop không.

Câu trả lời:


40

Hadoop có nghĩa là HDFS, YARN, MapReduce, và rất nhiều thứ khác. Ý bạn là Spark vs MapReduce ? Bởi vì Spark chạy trên / với Hadoop, đó là điểm chính.

Lý do chính để sử dụng Spark là vì tốc độ và điều này xuất phát từ thực tế là việc thực thi nó có thể giữ dữ liệu trong bộ nhớ giữa các giai đoạn thay vì luôn tồn tại trở lại HDFS sau Bản đồ hoặc Giảm. Ưu điểm này rất rõ rệt đối với các tính toán lặp, trong đó có hàng chục giai đoạn mà mỗi lần chạm vào cùng một dữ liệu. Đây là nơi mọi thứ có thể nhanh hơn "100 lần". Đối với các công việc đơn giản, một lần giống như ETL mà MapReduce được thiết kế, nói chung nó không nhanh hơn.

Một lý do khác để sử dụng Spark là ngôn ngữ cấp cao đẹp hơn so với MapReduce. Nó cung cấp một khung nhìn giống như lập trình chức năng bắt chước Scala, đẹp hơn nhiều so với viết mã MapReduce. (Mặc dù bạn phải sử dụng Scala hoặc sử dụng API Java hoặc Python kém phát triển cho Spark). CrunchCascading đã cung cấp một sự trừu tượng tương tự trên đầu MapReduce, nhưng đây vẫn là một lĩnh vực mà Spark rất đẹp.

Cuối cùng Spark có các tiểu dự án còn non trẻ nhưng đầy hứa hẹn cho ML, phân tích biểu đồ và phát trực tuyến, trong đó đưa ra một API tương tự, mạch lạc. Với MapReduce, bạn sẽ phải chuyển sang một số dự án khác cho việc này (Mahout, Giraph, Storm). Thật tuyệt khi có nó trong một gói, mặc dù chưa 'nướng'.

Tại sao bạn không sử dụng Spark? diễn giải bản thân:

  • Spark chủ yếu là Scala, với các API Java được port; MapReduce có thể thân thiện hơn và bản địa hơn cho các nhà phát triển dựa trên Java
  • Hiện tại có nhiều chuyên gia về MapReduce hơn Spark
  • Đối với các công việc song song dữ liệu, một lần, giống như ETL, MapReduce được thiết kế cho, MapReduce có trọng lượng nhẹ hơn so với tương đương Spark
  • Spark khá trưởng thành và bây giờ YARN cũng vậy, nhưng Spark-on-YARN vẫn còn khá mới. Cả hai có thể chưa được tích hợp tối ưu. Ví dụ cho đến gần đây tôi không nghĩ Spark có thể yêu cầu YARN phân bổ dựa trên số lõi? Đó là: MapReduce có thể dễ hiểu, quản lý và điều chỉnh hơn

Cảm ơn bạn đã làm rõ. Giữ dữ liệu trong bộ nhớ nghe có vẻ như có một số hàm ý thú vị - Tôi sẽ đọc về khái niệm Bộ dữ liệu phân tán linh hoạt của Spark thêm một chút nữa.
idclark

3
+1 cho một câu trả lời thực sự rõ ràng và hữu ích cho rất nhiều người có câu hỏi này, như tôi.
vefthym

3
Hãy nhớ rằng Sean Owen là đồng tác giả của cuốn sách O'Reilly mới trên Spark. :-)
sheldonkreger

1

Không chắc chắn về YARN, nhưng tôi nghĩ rằng Spark tạo ra sự khác biệt thực sự so với Hadoop (được quảng cáo là nhanh hơn 100 lần) nếu dữ liệu có thể nằm gọn trong bộ nhớ của các nút tính toán. Đơn giản vì nó tránh được việc truy cập đĩa cứng. Nếu dữ liệu không phù hợp với bộ nhớ thì vẫn có một số lợi ích do bộ đệm.


0

Thông tin tốt @Sean Owen. Muốn thêm một bổ sung. Spark có thể giúp xây dựng các đường ống dữ liệu hợp nhất trong kiến ​​trúc Lambda giải quyết cả hai lớp Batch và Streaming với khả năng ghi vào lớp phục vụ chung. Đó là lợi thế rất lớn để sử dụng lại logic giữa lô và Truyền phát. Ngoài ra, thuật toán Truyền trực tuyến K-Means trong Spark1.3 là một điểm cộng được thêm vào ML ngoài việc theo dõi công việc tuyệt vời và trực quan hóa quá trình trong 1.4.


0

Sẽ thật công bằng khi so sánh Spark với MapReduce - khung xử lý của Hadoop. Trong phần lớn các trường hợp, Spark có thể vượt trội hơn MapReduce. Cái trước cho phép xử lý dữ liệu trong bộ nhớ, giúp xử lý dữ liệu nhanh hơn tới 100 lần. Vì lý do này, Spark là một tùy chọn ưa thích nếu bạn cần thông tin chi tiết nhanh chóng, ví dụ: nếu bạn cần

  • chạy phân tích khách hàng, ví dụ so sánh hành vi của khách hàng với các mẫu hành vi của một phân khúc khách hàng cụ thể và kích hoạt một số hành động nhất định;
  • quản lý rủi ro và dự báo các kịch bản khác nhau có thể xảy ra;
  • phát hiện gian lận trong thời gian thực;
  • chạy phân tích dữ liệu lớn công nghiệp và dự đoán sự bất thường và lỗi máy.

Tuy nhiên, MapReduce rất giỏi trong việc xử lý các bộ dữ liệu thực sự lớn (nếu bạn ổn với thời gian cần thiết để xử lý). Bên cạnh đó, đây là một giải pháp kinh tế hơn, khi MapReduce đọc từ / ghi vào đĩa. Và đĩa thường rẻ hơn bộ nhớ.


-1

Học máy là một ví dụ điển hình về loại vấn đề trong đó các giải pháp dựa trên Spark vượt xa các giải pháp dựa trên bản đồ, mặc dù tuổi còn trẻ của tia lửa.


2
Tôi không nghĩ điều này là đúng, nhưng tôi nghĩ tôi biết những gì bạn đang làm: trong bộ nhớ hoạt động nhanh hơn rất nhiều cho tính toán lặp và rất nhiều ML là lặp đi lặp lại.
Sean Owen
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.