Về mặt kỹ thuật sự khác nhau giữa s3n, s3a và s3 là gì?

Question

Tôi nhận thức được sự tồn tại của https://wiki.apache.org/hadoop/AmazonS3 và những lời sau đây:

S3 Native FileSystem (URI Đề án: s3n) Một hệ thống tập tin gốc để đọc và ghi các file thường xuyên trên S3. Ưu điểm của hệ thống tập tin này là bạn có thể truy cập các tập tin trên S3 được viết bằng các công cụ khác. Ngược lại, các công cụ khác có thể truy cập các tệp được viết bằng Hadoop. Điểm bất lợi là giới hạn 5 GB đối với kích thước tệp được S3 đặt ra.

S3A (Lược đồ URI: s3a) Bản kế thừa cho S3 Native, s3n fs, S3a: hệ thống sử dụng thư viện của Amazon để tương tác với S3. Điều này cho phép S3a hỗ trợ các tệp lớn hơn (không giới hạn 5GB), hoạt động hiệu suất cao hơn và hơn thế nữa. Hệ thống tệp được dự định là thay thế cho/kế thừa cho S3 Native: tất cả các đối tượng có thể truy cập từ các URL s3n: // cũng có thể truy cập được từ s3a chỉ bằng cách thay thế lược đồ URL.

Hệ thống tệp khối S3 (Lược đồ URI: s3) Hệ thống tệp dựa trên khối được S3 hỗ trợ. Các tệp được lưu trữ dưới dạng các khối, giống như chúng ở trong HDFS. Điều này cho phép thực hiện hiệu quả các đổi tên. Hệ thống tệp này yêu cầu bạn dành một nhóm cho hệ thống tệp - bạn không nên sử dụng nhóm chứa tệp hiện có hoặc ghi các tệp khác vào cùng một nhóm. Các tệp được lưu trữ bởi hệ thống tệp này có thể lớn hơn 5 GB nhưng chúng không tương thích với các công cụ S3 khác.

Tại sao thay đổi thư trên URI có thể tạo sự khác biệt như vậy? Ví dụ

val data = sc.textFile("s3n://bucket-name/key") 

để

val data = sc.textFile("s3a://bucket-name/key") 

sự khác biệt kỹ thuật cơ bản sự thay đổi này là gì? Có bài viết hay nào mà tôi có thể đọc được không?

Answer 1

Thay đổi thư trên lược đồ URI tạo ra sự khác biệt lớn vì nó gây ra phần mềm khác nhau được sử dụng để giao tiếp với S3. Hơi giống như sự khác biệt giữa http và https - nó chỉ là một thay đổi một chữ cái, nhưng nó gây ra một sự khác biệt lớn trong hành vi.

Sự khác biệt giữa s3 và s3n/s3a là s3 là một lớp phủ dựa trên khối trên đầu trang của Amazon S3, trong khi s3n/s3a không (chúng dựa trên đối tượng).

Sự khác biệt giữa s3n và s3a là s3n hỗ trợ các đối tượng có kích thước tối đa 5GB, trong khi s3a hỗ trợ các đối tượng tối đa 5TB và có hiệu suất cao hơn (cả hai đều là vì nó sử dụng tải lên nhiều phần). s3a là người kế thừa s3n.

Nếu bạn ở đây vì bạn muốn hiểu hệ thống tệp S3 nào bạn nên sử dụng với Amazon EMR, hãy đọc this article từ Amazon (mạng là: sử dụng s3: // vì s3: // và s3n: // có chức năng hoán đổi cho nhau trong bối cảnh EMR, trong khi s3a: // không tương thích với EMR).

Answer 2

trong Apache Hadoop, "s3: //" đề cập đến máy khách S3 ban đầu, sử dụng cấu trúc không chuẩn cho khả năng mở rộng. Thư viện đó không còn được dùng nữa và sẽ sớm bị xóa,

s3n là người kế thừa, sử dụng tên đường dẫn trực tiếp cho các đối tượng để bạn có thể đọc và ghi dữ liệu bằng các ứng dụng khác. Giống như s3: //, nó sử dụng jets3t.jar để nói chuyện với S3.

Trên dịch vụ EMR của Amazon, s3: // đề cập đến máy khách S3 của Amazon, điều này khác nhau. Một đường dẫn trong s3: // trên EMR tham chiếu trực tiếp đến một đối tượng trong kho đối tượng.

Trong Apache Hadoop, S3N và S3A là cả hai trình kết nối tới S3, với S3A kế thừa được tạo bằng cách sử dụng SDK AWS của Amazon. Tại sao lại có tên mới? vì vậy chúng tôi có thể vận chuyển nó song song với cái đã ổn định. S3A là nơi tất cả các công việc liên tục về khả năng mở rộng, hiệu suất, bảo mật, v.v. S3N bị bỏ lại một mình vì vậy chúng tôi không phá vỡ nó. S3A được vận chuyển trong Hadoop 2.6, nhưng vẫn ổn định cho đến 2.7, chủ yếu với một số vấn đề quy mô nhỏ nổi lên.

Nếu bạn đang sử dụng Hadoop 2.7 trở lên, hãy sử dụng s3a. Nếu bạn đang sử dụng Hadoop 2.5 hoặc cũ hơn. s3n, Nếu bạn đang sử dụng Hadoop 2.6, đó là một lựa chọn khó khăn hơn. -I'd thử s3a và chuyển về s3n nếu có problems-

Để biết thêm về lịch sử, xem http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

2017-03-14 Cập nhật trên thực tế, phân vùng bị phá vỡ trên S3a trong Hadoop 2,6 , khi kích thước khối được trả về trong một cuộc gọi listFiles() là 0: những thứ như Spark & phân vùng lợn công việc thành một nhiệm vụ/byte. Bạn không thể sử dụng S3a cho công việc phân tích trong Hadoop 2.6, ngay cả khi hoạt động của hệ thống tập tin lõi & tạo ra dữ liệu rất vui. Hadoop 2.7 sửa lỗi đó.

2018-01-10 Cập nhật Hadoop 3.0 đã cắt cài đặt s3: và s3n: s3a là tất cả những gì bạn nhận được. Nó bây giờ là tốt hơn đáng kể so với người tiền nhiệm của nó và thực hiện ít nhất là tốt như việc thực hiện Amazon. "S3:" của Amazon vẫn được cung cấp bởi EMR, là khách hàng nguồn đóng của họ. Tham khảo EMR docs để biết thêm thông tin.