Có phải bộ nhớ đệm là ưu điểm duy nhất của tia lửa trên bản đồ-giảm?

Question

Tôi đã bắt đầu tìm hiểu về Apache Spark và rất ấn tượng bởi khung công tác. Mặc dù một điều khiến tôi bận tâm là trong tất cả các bài thuyết trình Spark họ nói về cách Spark lưu trữ RDD và do đó nhiều thao tác cần cùng một dữ liệu nhanh hơn các cách tiếp cận khác như Map Reduce.

Vì vậy, câu hỏi tôi gặp phải là nếu đây là trường hợp, thì chỉ cần thêm một bộ đệm ẩn bên trong các khung công tác MR như Yarn/Hadoop.

Tại sao lại tạo toàn bộ khung công tác mới?

Tôi chắc chắn rằng tôi đang thiếu điều gì đó ở đây và bạn sẽ có thể chỉ cho tôi một số tài liệu hướng dẫn tôi nhiều hơn về tia lửa.

Answer 1

Caching + trong tính toán bộ nhớ chắc chắn là một điều lớn cho tia lửa, Tuy nhiên có những thứ khác.

---

RDD (Tập dữ liệu phân tán hồi phục): RDD là trừu tượng chính của tia lửa. Nó cho phép phục hồi các nút bị lỗi bằng cách tính lại DAG trong khi cũng hỗ trợ một kiểu khôi phục tương tự hơn cho Hadoop bằng cách kiểm tra điểm, để giảm bớt sự phụ thuộc của RDD. Lưu trữ một công việc tia lửa trong một DAG cho phép tính toán lười biếng của RDD và cũng có thể cho phép động cơ tối ưu hóa của tia lửa để sắp xếp dòng chảy theo những cách tạo nên sự khác biệt lớn về hiệu suất.

---

API Spark: Hadoop MapReduce có API rất nghiêm ngặt không cho phép nhiều tính linh hoạt. Kể từ khi tia lửa tóm tắt đi nhiều chi tiết cấp thấp, nó cho phép năng suất cao hơn. Ngoài ra những thứ như biến phát sóng và ắc quy linh hoạt hơn nhiều so với DistributedCache và quầy IMO.

---

Phát trực tiếp tia lửa: phát trực tuyến tia lửa dựa trên giấy Phân loại luồng, đề xuất mô hình mới để tính toán cửa sổ trên luồng sử dụng các lô vi mô. Hadoop không hỗ trợ bất cứ điều gì như thế này.

---

Là một sản phẩm trong bộ tính toán tia lửa hoạt động như bộ lập lịch luồng riêng của nó. Trong khi đó, với tiêu chuẩn MR bạn cần một công việc lên lịch bên ngoài như Azkaban hoặc Oozie để sắp xếp các dòng phức tạp

---

Dự án hadoop được tạo thành từ MapReduce, SỢI, commons và HDFS; Tuy nhiên, spark đang cố gắng tạo ra một nền tảng dữ liệu lớn thống nhất với các thư viện (trong cùng một repo) cho việc học máy, xử lý đồ thị, phát trực tuyến, nhiều thư viện kiểu sql và tôi tin rằng một thư viện học tập sâu trong giai đoạn đầu. Trong khi không ai trong số này là đúng một tính năng của tia lửa nó là một sản phẩm của mô hình điện toán của tia lửa. Tachyon và BlinkDB là hai công nghệ khác được xây dựng xung quanh tia lửa.

Answer 2

Vì vậy, nó không chỉ là bộ nhớ đệm. Aaronman bị ốm rất nhiều nên chỉ thêm vào những gì anh ta đã bỏ lỡ.

Hiệu suất thô với bộ đệm ẩn nhanh hơn 2-10 lần do khung công tác được định hướng tốt và hiệu quả hơn. Ví dụ. 1 jvm cho mỗi nút với các chuỗi akka tốt hơn là forking toàn bộ quá trình cho mỗi tác vụ.

API Scala. Scala là viết tắt của Ngôn ngữ có thể mở rộng và rõ ràng là ngôn ngữ tốt nhất để lựa chọn xử lý song song. Họ nói rằng Scala cắt giảm mã xuống 2-5x, nhưng theo kinh nghiệm của tôi từ việc tái cấu trúc mã bằng các ngôn ngữ khác - đặc biệt là mã java mapreduce, nó giống mã ít hơn 10-100x.Nghiêm túc là tôi đã refactored 100s LOC từ java thành một số ít Scala/Spark. Nó cũng dễ dàng hơn nhiều để đọc và lý do về. Spark thậm chí còn ngắn gọn và dễ sử dụng hơn các công cụ trừu tượng Hadoop như tổ ong &, thậm chí còn tốt hơn cả Scalding.

Spark có repl/shell. Sự cần thiết cho một chu trình triển khai biên dịch để chạy các công việc đơn giản bị loại bỏ. Người ta có thể chơi tương tác với dữ liệu giống như một sử dụng Bash để chọc quanh một hệ thống.

Điều cuối cùng cần lưu ý là dễ dàng tích hợp với DBB của Big Table, như cassandra và hbase. Trong cass để đọc một bảng để thực hiện một số phân tích, chỉ cần

sc.cassandraTable[MyType](tableName).select(myCols).where(someCQL) 

Điều tương tự cũng được mong đợi cho HBase. Bây giờ hãy thử làm điều đó trong bất kỳ khuôn khổ MPP nào khác !!

CẬP NHẬT ý nghĩ chỉ ra đây chỉ là những ưu điểm của Spark, có khá nhiều điều hữu ích ở trên cùng. Ví dụ. GraphX ​​để xử lý đồ thị, MLLib cho việc học máy dễ dàng, Spark SQL cho BI, BlinkDB cho các truy vấn nhanh apprx điên, và như đã đề cập Spark Streaming

Answer 3

nhiều được aaronman và samthebest bao trả. Tôi có thêm vài điểm nữa.

1. Spark có mức chi phí thấp hơn cho mỗi công việc và trên mỗi tác vụ. Nó cung cấp cho nó khả năng được áp dụng cho các trường hợp mà Hadoop MR không được áp dụng. Đó là trường hợp khi trả lời là cần thiết trong 1-30 giây.
   Chi phí thấp trên mỗi tác vụ giúp Spark hiệu quả hơn cho các công việc lớn ngay cả với rất nhiều tác vụ ngắn. Theo ước tính rất sơ bộ - khi nhiệm vụ mất 1 giây Spark sẽ hiệu quả gấp 2 lần thì Hadoop MR.

2. Spark có trừu tượng thấp hơn sau đó MR - đó là biểu đồ tính toán. Kết quả là có thể thực hiện xử lý hiệu quả hơn sau đó MR - đặc biệt trong trường hợp không cần phân loại. Nói cách khác - trong MR chúng tôi luôn trả tiền cho việc phân loại, nhưng trong Spark - chúng tôi không phải trả tiền.

Answer 4

• Apache Spark quá trình dữ liệu trong bộ nhớ trong khi Hadoop MapReduce vẫn trở lại với đĩa sau khi một bản đồ hoặc giảm hoạt động. Nhưng Spark cần nhiều bộ nhớ

• Spark tải một quá trình vào bộ nhớ và giữ nó ở đó cho đến khi có thông báo mới.

• Tập dữ liệu phân tán linh hoạt (RDD), cho phép bạn lưu trữ dữ liệu trong bộ nhớ một cách minh bạch và tiếp tục lưu vào đĩa nếu cần.

• Vì Spark sử dụng trong bộ nhớ, không có rào cản đồng bộ hóa làm chậm bạn xuống. Đây là một lý do chính cho hiệu suất của Spark.

• Thay vì chỉ xử lý một loạt dữ liệu được lưu trữ, như trường hợp với MapReduce, Spark cũng có thể thao tác dữ liệu trong thời gian thực bằng cách sử dụng Spark Streaming.

• Các DataFrames API được lấy cảm hứng từ khung dữ liệu trong R và Python (Gấu trúc), nhưng được thiết kế từ mặt đất lên là một mở rộng của hiện RDD API.

• Một DataFrame là một tập hợp phân phối dữ liệu được tổ chức thành các cột được đặt tên, nhưng với tối ưu hóa phong phú hơn dưới mui xe có hỗ trợ với tốc độ của tia lửa.

• Sử dụng RDD s Spark đơn giản hoá các hoạt động phức tạp như tham gia và groupby và trong backend, bạn đang làm việc với các dữ liệu bị phân mảnh. Sự phân mảnh đó là điều cho phép Spark thực thi song song.

• Spark cho phép để phát triển, đường ống dữ liệu đa bước phức tạp sử dụng đồ thị không chu trình có hướng (DAG ) mẫu. Nó hỗ trợ chia sẻ dữ liệu trong bộ nhớ trên các DAG, do đó các công việc khác nhau có thể làm việc với cùng một dữ liệu. DAG s là phần chính của tốc độ Spark s.

• Spark mã cơ sở nhỏ hơn nhiều.

Hy vọng điều này sẽ hữu ích.

Answer 5

Tôi nghĩ có ba lý do chính.

Hai lý do chính xuất phát từ thực tế là, thông thường, một lý do không chạy một công việc MapReduce duy nhất, mà là một tập hợp các công việc theo thứ tự.

1. Một trong những hạn chế chính của MapReduce là nó vẫn giữ nguyên tập dữ liệu đầy đủ cho HDFS sau khi chạy từng công việc. Điều này là rất tốn kém, bởi vì nó phải chịu cả ba lần (để nhân rộng) kích thước của tập dữ liệu trong đĩa I/O và một số lượng tương tự của mạng I/O. Spark có cái nhìn toàn diện hơn về một đường ống hoạt động. Khi đầu ra của một hoạt động cần được đưa vào một hoạt động khác, Spark truyền dữ liệu trực tiếp mà không cần ghi vào lưu trữ liên tục. Đây là một sự đổi mới trên MapReduce đến từ giấy Dryad của Microsoft, và không phải là bản gốc của Spark.
2. Sự đổi mới chính của Spark là giới thiệu một bộ nhớ đệm trong bộ nhớ trừu tượng. Điều này làm cho Spark lý tưởng cho khối lượng công việc mà nhiều hoạt động truy cập vào cùng một dữ liệu đầu vào. Người dùng có thể hướng dẫn Spark để cache bộ dữ liệu đầu vào trong bộ nhớ, vì vậy chúng không cần phải được đọc từ đĩa cho mỗi thao tác.
3. Điều gì về công việc Spark sẽ làm sôi động xuống một công việc MapReduce đơn lẻ? Trong nhiều trường hợp, chúng cũng chạy nhanh hơn trên Spark so với MapReduce. Lợi thế chính mà Spark có ở đây là nó có thể khởi chạy các tác vụ nhanh hơn nhiều. MapReduce bắt đầu một JVM mới cho mỗi tác vụ, có thể mất vài giây với việc tải các JAR, JITing, phân tích cú pháp cấu hình XML, v.v. Spark giữ một JVM thực thi chạy trên mỗi nút, do đó khởi chạy một nhiệm vụ đơn giản là tạo RPC cho nó và chuyển một Runnable đến một hồ bơi thread, trong đó có trong các chữ số duy nhất của mili giây.

Cuối cùng, quan niệm sai lầm phổ biến có thể đáng nhắc đến là Spark bằng cách nào đó chạy hoàn toàn trong bộ nhớ trong khi MapReduce thì không. Điều này chỉ đơn giản là không phải vậy. Việc triển khai shuffle của Spark hoạt động rất giống với MapReduce: mỗi bản ghi được tuần tự hóa và ghi ra đĩa ở phía bản đồ và sau đó được lấy và deserialized ở phía bên giảm.