Diferencia entre Amazon S3 y S3n en Hadoop

Question

Cuando conecté mi clúster de Hadoop al almacenamiento de Amazon y descargué el archivo a HDFS, encontré que s3: // no funcionaba, pero buscando ayuda en Internet encontré que puedo usar S3n así que cuando usado S3n funcionó. No entiendo la diferencia entre usar S3 o s3n con mi cluster hadoop, ¿alguien puede explicarlo?

Answer 1

Creo que su principal problema estaba relacionado con tener S3 y S3N dos puntos de conexión separados para Hadoop. S3n: // significa "Un archivo normal, legible desde el mundo exterior, en esta url S3". S3: // se refiere a un sistema de archivos HDFS mapeado en un contenedor S3 que está ubicado en el clúster de almacenamiento AWS. Entonces, cuando estaba usando un archivo del cubo de almacenamiento de Amazon, debe usar S3N y esa es la razón por la cual su problema se resuelve.¡La información agregada por @Steffen también es genial!

Answer 2

Los dos sistemas de archivos para el uso de Amazon S3 están documentados en la respectiva Hadoop wiki page addressing Amazon S3:

• S3 nativo sistema de archivos (esquema URI: S3N)
  Un sistema de archivos nativo para leer y escribir archivos regulares sobre S3 . La ventaja de este sistema de archivos es que puede acceder a los 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. Por esta razón no es adecuado como reemplazo de HDFS (que es compatible con archivos muy grandes).

• S3 Bloquear sistema de archivos (esquema URI: s3)
  Un 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; usted no debe usar un depósito existente que contenga archivos, o escriba 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.

Hay dos maneras de que S3 se puede utilizar con Mapa/Reducir de Hadoop, ya sea como reemplazo para HDFS utilizando el bloque de sistema de archivos S3 (es decir usarlo como un sistema de ficheros distribuido fiable con soporte para muy archivos grandes) o como un repositorio conveniente para la entrada de datos a salida de MapReduce, usando cualquiera de los sistemas de archivos S3. En el segundo caso, HDFS se sigue utilizando para la fase de Mapa/Reducir. [...]

[el énfasis es mío]

Así que la diferencia se debe principalmente a cómo se maneja el límite de 5GB (que es el más grande objeto que se puede cargar en un solo PUT , aunque objetos pueden variar en tamaño de 1 byte a 5 terabytes, vea How much data can I store?): mientras usa el S3 Block FileSystem (esquema URI: s3) permite remediar el límite de 5GB y almacenar archivos hasta 5TB, reemplaza HDFS a su vez.

Answer 3

Aquí es una explicación: https://notes.mindprince.in/2014/08/01/difference-between-s3-block-and-s3-native-filesystem-on-hadoop.html

El primer sistema de ficheros Hadoop respaldado-S3 se introdujo en Hadoop 0.10.0 (hadoop-574). Se llamó sistema de archivos de bloque S3 y se le asignó el esquema URI s3: //. En esta implementación, los archivos se almacenan como bloques, al igual que en HDFS. Los archivos almacenados por este sistema de ficheros no son interoperables con otras herramientas S3 - lo que esto significa es que si vas a la consola de AWS y tratar de buscar los archivos escritos por este sistema de archivos, que no encontrará en ellos - en lugar que puedes encontrar archivos llamado algo así como block_-1212312341234512345 etc.

Para superar estas limitaciones, se introdujo otro sistema de archivos respaldado por S3 en Hadoop 0.18.0 (HADOOP-930). Se llamó sistema de archivos nativo S3 y se le asignó el esquema URI s3n: //. Este sistema de archivos le permite acceder a archivos en S3 escritos con otras herramientas ... Cuando se introdujo este sistema de archivos, S3 tenía un límite de tamaño de archivo de 5 GB y, por lo tanto, este sistema de archivos solo podía funcionar con archivos de menos de 5 GB. A finales de 2010, Amazon ... aumentó el límite de tamaño de archivo de 5GB a 5TB ...

No se recomienda el uso del sistema de archivos de bloques S3. Varios proveedores de-as-a-Service Hadoop como Qubole y Amazon EMR van tan lejos como el mapeo tanto el s3: // y la S3N: // URI en el sistema de archivos nativo S3 para asegurar esto.

Así que siempre use el sistema de archivos nativo. No hay más límite de 5Gb. A veces puede que tenga que escribir s3:// en lugar de s3n://, pero sólo asegúrese de que los archivos se crean son visibles en el cubo explorador en el navegador.

Véase también http://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-file-systems.html.

Anteriormente, Amazon EMR utilizaba S3 Native FileSystem con el esquema de URI, s3n. Si bien esto funciona, recomendamos que use el esquema de URI s3 para obtener el mejor rendimiento, seguridad y confiabilidad.

También dice que usted puede utilizar s3bfs:// para acceder al sistema de archivos de bloques de edad, anteriormente conocido como s3://.