Técnicamente, ¿cuál es la diferencia entre s3n, s3a y s3?

Soy consciente de la existencia de https://wiki.apache.org/hadoop/AmazonS3 y las siguientes palabras:

S3 Native FileSystem (esquema de URI: s3n) Un sistema de archivos nativo para leer y escribir archivos regulares en S3. La ventaja de este sistema de archivos es que puede acceder a archivos en S3 que se escribieron con otras herramientas. Por el contrario, otras herramientas pueden acceder a archivos escritos usando Hadoop. La desventaja es el límite de 5 GB en el tamaño de archivo impuesto por S3.

S3A (esquema URI: s3a) Un sucesor del S3 Native, s3n fs, el sistema S3a: usa las bibliotecas de Amazon para interactuar con S3. Esto permite a S3a soportar archivos más grandes (no más de 5GB de límite), operaciones de mayor rendimiento y más. El sistema de archivos está destinado a ser un reemplazo / sucesor de S3 Native: todos los objetos accesibles desde s3n: // URL también deben ser accesibles desde s3a simplemente reemplazando el esquema de URL.

S3 Block FileSystem (esquema URI: s3) Sistema de archivos basado en bloques respaldado por S3. Los archivos se almacenan como bloques, al igual que en HDFS. Esto permite una implementación eficiente de los cambios de nombre. Este sistema de archivos requiere que dedique un depósito para el sistema de archivos; no debe usar un depósito existente que contenga archivos ni escribir otros archivos en el mismo depósito. Los archivos almacenados por este sistema de archivos pueden ser más grandes que 5GB, pero no son interoperables con otras herramientas S3.

¿Por qué un cambio de letra en el URI podría marcar la diferencia? Por ejemplo

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

a

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

¿Cuál es la diferencia técnica que subyace a este cambio? ¿Hay algún buen artículo que pueda leer sobre esto?

El cambio de letra en el esquema de URI hace una gran diferencia porque hace que se usen diferentes progtwigs para interactuar con S3. Algo así como la diferencia entre http y https – es solo un cambio de una letra, pero desencadena una gran diferencia en el comportamiento.

La diferencia entre s3 y s3n / s3a es que s3 es una superposición basada en bloques en la parte superior de Amazon S3, mientras que s3n / s3a no (están basados ​​en objetos).

La diferencia entre s3n y s3a es que s3n admite objetos de hasta 5GB de tamaño, mientras que s3a admite objetos de hasta 5TB y tiene un mayor rendimiento (ambos son porque usa carga de varias partes). s3a es el sucesor de s3n.

Si está aquí porque quiere saber qué sistema de archivos S3 debe usar con Amazon EMR, lea este artículo de Amazon (la red es: use s3: // porque s3: // y s3n: // son funcionalmente intercambiables) en el contexto de EMR, mientras que s3a: // no es compatible con EMR).

en Apache Hadoop, “s3: //” hace referencia al cliente S3 original, que utilizaba una estructura no estándar para la escalabilidad. Esa biblioteca está en desuso y pronto será eliminada,

s3n es su sucesor, que usó nombres de ruta directos a los objetos, para que pueda leer y escribir datos con otras aplicaciones. Al igual que s3: //, usa jets3t.jar para hablar con S3.

En el servicio EMR de Amazon, s3: // se refiere al propio cliente S3 de Amazon, que es diferente. Una ruta en s3: // en EMR se refiere directamente a un objeto en el almacén de objetos.

En Apache Hadoop, S3N y S3A son ambos conectores a S3, con S3A, el sucesor creado utilizando AWS SDK de Amazon. ¿Por qué el nuevo nombre? para poder enviarlo lado a lado con el que estaba estable. S3A es donde funciona todo el trabajo continuo de escalabilidad, rendimiento, seguridad, etc. S3N se deja solo para que no lo rompamos. S3A se envió en Hadoop 2.6, pero aún se estabilizaba hasta 2.7, principalmente con la aparición de algunos problemas de escala menores.

Si está usando Hadoop 2.7 o posterior, use s3a. Si está usando Hadoop 2.5 o anterior. s3n, si está usando Hadoop 2.6, es una elección más difícil. -Intentaría s3a y volvería a s3n si hubiera problemas-

Para más de la historia, vea http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/

2017-03-14 Actualización en realidad, el particionamiento se rompe en S3a en Hadoop 2.6, ya que el tamaño de bloque devuelto en una listFiles() a listFiles() es 0: cosas como Spark & ​​Pig dividen el trabajo en una tarea / byte. No puede usar S3a para el trabajo de análisis en Hadoop 2.6, incluso si las operaciones del sistema de archivos y la generación de datos son satisfactorias. Hadoop 2.7 corrige eso.

2018-01-10 Actualización Hadoop 3.0 ha cortado sus implementaciones s3: y s3n: s3a es todo lo que obtienes. Ahora es significativamente mejor que su predecesor y funciona al menos tan bien como la implementación de Amazon. “S3:” de Amazon todavía es ofrecido por EMR, que es su cliente de código cerrado. Consulte los documentos de EMR para obtener más información.