Technicznie jaka jest różnica między s3n, s3a i s3?

Mam świadomość istnienia https://wiki.apache.org/hadoop/AmazonS3 oraz następujących słów:

S3 Native FileSystem (schemat URI: s3n) Natywny system plików do odczytu i zapisu zwykłych plików na S3. Zaletą tego systemu plików jest to, że możesz uzyskać dostęp do plików na S3, które zostały napisane za pomocą innych narzędzi. I odwrotnie, inne narzędzia mogą uzyskiwać dostęp do plików zapisanych przy użyciu Hadoop. Wadą jest ograniczenie rozmiaru pliku do 5 GB narzucone przez S3.

S3A (schemat URI: s3a) Następca S3 Native, s3n fs, system S3a: wykorzystuje biblioteki Amazon do interakcji z S3. Dzięki temu S3a może obsługiwać większe pliki (bez limitu 5 GB), operacje o wyższej wydajności i nie tylko. System plików ma być zamiennikiem / następcą S3 Native: wszystkie obiekty dostępne z adresów URL s3n: // powinny być również dostępne z s3a po prostu poprzez zastąpienie schematu adresu URL.

S3 Block FileSystem (schemat URI: s3) Oparty na blokach system plików wspierany przez S3. Pliki są przechowywane jako bloki, tak jak w HDFS. Pozwala to na wydajną implementację zmian nazw. Ten system plików wymaga dedykowania zasobnika dla systemu plików - nie powinieneś używać istniejącego zasobnika zawierającego pliki ani zapisywać innych plików w tym samym zasobniku. Pliki przechowywane przez ten system plików mogą być większe niż 5 GB, ale nie są kompatybilne z innymi narzędziami S3.

Dlaczego zmiana litery w identyfikatorze URI może mieć takie znaczenie? Na przykład

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

do

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

Jaka jest różnica techniczna leżąca u podstaw tej zmiany? Czy są jakieś dobre artykuły, które mogę przeczytać na ten temat?

Zmiana litery w schemacie URI robi dużą różnicę, ponieważ powoduje użycie innego oprogramowania do połączenia z S3. Trochę jak różnica między http i https - to tylko jedna litera zmiana, ale powoduje dużą różnicę w zachowaniu.

Różnica między s3 i s3n / s3a polega na tym, że s3 jest nakładką opartą na blokach na Amazon S3, podczas gdy s3n / s3a nie są (są oparte na obiektach).

Różnica między s3n i s3a polega na tym, że s3n obsługuje obiekty o rozmiarze do 5 GB, podczas gdy s3a obsługuje obiekty do 5 TB i ma wyższą wydajność (oba są spowodowane przesyłaniem wieloczęściowym). s3a jest następcą s3n.

Jeśli jesteś tutaj, ponieważ chcesz zrozumieć, którego systemu plików S3 powinieneś używać z Amazon EMR, przeczytaj ten artykuł z Amazon (dostępny tylko na maszynie Wayback). Sieć to: użyj s3: //, ponieważ s3: // i s3n: // są funkcjonalnie wymienne w kontekście EMR, podczas gdy s3a: // nie jest kompatybilny z EMR.

Aby uzyskać dodatkowe porady, przeczytaj artykuł Praca z pamięcią masową i systemami plików .

w Apache Hadoop „s3: //” odnosi się do oryginalnego klienta S3, który wykorzystywał niestandardową strukturę zapewniającą skalowalność. Ta biblioteka jest przestarzała i wkrótce zostanie usunięta,

s3n jest jego następcą, który używał bezpośrednich nazw ścieżek do obiektów, dzięki czemu można czytać i zapisywać dane za pomocą innych aplikacji. Podobnie jak s3: //, używa jets3t.jar do komunikacji z S3.

W usłudze EMR firmy Amazon s3: // odnosi się do własnego klienta S3 firmy Amazon, który jest inny. Ścieżka w s3: // w EMR odnosi się bezpośrednio do obiektu w składnicy obiektów.

W Apache Hadoop, S3N i S3A to oba złącza do S3, przy czym S3A jest następcą zbudowanym przy użyciu własnego AWS SDK firmy Amazon. Dlaczego nowa nazwa? abyśmy mogli wysłać go obok siebie z tym, który był stabilny. S3A to miejsce, w którym toczą się wszystkie trwające prace nad skalowalnością, wydajnością, bezpieczeństwem itp. S3N zostaje sam, więc go nie psujemy. S3A był dostarczany w Hadoop 2.6, ale nadal stabilizował się do wersji 2.7, głównie z niewielkimi problemami w skali.

Jeśli używasz Hadoop 2.7 lub nowszego, użyj s3a. Jeśli używasz Hadoop 2.5 lub starszego. s3n, jeśli używasz Hadoop 2.6, jest to trudniejszy wybór. - Spróbowałbym s3a i przełączyłbym się z powrotem na s3n, gdyby były problemy-

Więcej informacji na temat historii można znaleźć pod adresem http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

2017-03-14 Aktualizacja faktycznie, partycjonowanie jest zepsute na S3a w Hadoop 2.6, ponieważ rozmiar bloku zwracany w listFiles()wywołaniu wynosi 0: rzeczy takie jak Spark i świnia dzielą pracę na jedno zadanie / bajt. Nie możesz używać S3a do pracy analitycznej w Hadoop 2.6, nawet jeśli podstawowe operacje systemu plików i generowanie danych są szczęśliwe. Hadoop 2.7 to naprawia.

10.01.2018 Aktualizacja Hadoop 3.0 ograniczyła implementacje s3: i s3n: s3a to wszystko, co dostajesz. Jest teraz znacznie lepszy niż jego poprzednik i działa co najmniej tak dobrze, jak wdrożenie Amazon. Amazon „s3:” jest nadal oferowany przez firmę EMR, która jest ich klientem o zamkniętym kodzie źródłowym. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją EMR .