cluster - Diferencias entre Amazon S3 y S3n en Hadoop

amazon hadoop cluster (3)

Cuando conecté mi clúster Hadoop al almacenamiento de Amazon y descargué archivos a HDFS, encontré que s3:// no funcionaba. Cuando busco ayuda en Internet, encuentro que puedo usar S3n . Cuando usé S3n , funcionó. No entiendo las diferencias entre usar S3 y S3n con mi clúster Hadoop, ¿alguien puede explicarlo?

Aquí hay 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 archivos Hadoop respaldado por 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 archivos no son interoperables con otras herramientas S3; lo que esto significa es que si va a la consola AWS e intenta buscar archivos escritos por este sistema de archivos, no los encontrará, sino que encontrará archivos con el nombre 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 ...
El uso del sistema de archivos de bloques S3 ya no es recomendable. Varios proveedores de Hadoop como servicio, como Qubole y Amazon EMR, van tan lejos como mapear los URI s3: // y s3n: // al sistema de archivos nativo S3 para garantizar esto.

Así que siempre use el sistema de archivos nativo. No hay más límite de 5Gb. A veces puede que tengas que escribir s3:// lugar de s3n:// , pero solo asegúrate de que los archivos que crees estén visibles en el explorador de s3n:// en el navegador.

También vea http://docs.aws.amazon.com/ElasticMapReduce/latest/ManagementGuide/emr-plan-file-systems.html .

Anteriormente, Amazon EMR utilizaba S3 Native FileSystem con el esquema 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 puede usar s3bfs:// para acceder al viejo sistema de archivos de bloque, anteriormente conocido como s3:// .

Creo que su problema principal estaba relacionado con tener S3 y S3n como dos puntos de conexión separados para Hadoop. s3n:// significa "Un archivo normal, legible desde el mundo exterior, en esta url S3". s3:// refiere a un sistema de archivos HDFS mapeado en un contenedor S3 que está ubicado en el clúster de almacenamiento de 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!

Los dos sistemas de archivos para usar Amazon S3 están documentados en la página respectiva de wiki de Hadoop que se dirige a Amazon S3 :

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 . Por esta razón, no es adecuado como reemplazo de HDFS (que tiene soporte para archivos muy grandes).
S3 Block FileSystem (esquema de 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; 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 .
Hay dos formas de utilizar S3 con Map / Reduce de Hadoop, como reemplazo de HDFS utilizando el sistema de archivos de bloques S3 (es decir, utilizándolo como un sistema de archivos distribuido confiable con soporte para archivos muy grandes) o como un repositorio conveniente para la entrada de datos y salida de MapReduce, usando cualquiera de los sistemas de archivos S3. En el segundo caso, HDFS todavía se usa para la fase de Mapa / Reducir. [...]
[énfasis mío]

Entonces, la diferencia está relacionada principalmente con cómo se maneja el límite de 5GB (que es el objeto más grande que se puede cargar en un solo PUT , aunque los objetos pueden variar en tamaño de 1 byte a 5 terabytes , consulte ¿Cuántos datos puedo almacenar? ): al usar S3 Block FileSystem (esquema de URI: s3) permite remediar el límite de 5GB y almacenar archivos de hasta 5TB, reemplaza a HDFS por turno.