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 normales en S3. La ventaja de este sistema de archivos es que puede acceder a archivos en S3 que fueron escritos con otras herramientas. Por el contrario, otras herramientas pueden acceder a archivos escritos con 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 que S3a admita archivos más grandes (no más límite de 5 GB), operaciones de mayor rendimiento y más. El sistema de archivos está destinado a ser un reemplazo de / sucesor de S3 Native: todos los objetos accesibles desde s3n: // URL también deberían ser accesibles desde s3a simplemente reemplazando el esquema de URL.
S3 Block FileSystem (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 la implementación eficiente de cambios de nombre. Este sistema de archivos requiere que dediques un depósito para el sistema de archivos; no debes 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 tener un tamaño superior a 5 GB, pero no son interoperables con otras herramientas de S3.
¿Por qué un cambio de letra en el URI podría hacer tanta 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 subyacente a este cambio? ¿Hay algún buen artículo que pueda leer sobre esto?
fuente
s3aesquema. Es posible que la respuesta deba revisarse.en Apache Hadoop, "s3: //" se refiere al cliente S3 original, que usaba una estructura no estándar para la escalabilidad. Esa biblioteca está obsoleta y pronto se eliminará.
s3n es su sucesor, que usaba nombres de ruta directos a los objetos, por lo que puede leer y escribir datos con otras aplicaciones. Como 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, siendo S3A el sucesor creado con el propio AWS SDK de Amazon. ¿Por qué el nuevo nombre? para que pudiéramos enviarlo junto con el que era estable. S3A es donde va todo el trabajo en curso sobre escalabilidad, rendimiento, seguridad, etc. S3N se deja solo para que no lo rompamos. S3A se envió en Hadoop 2.6, pero todavía se estaba estabilizando hasta la 2.7, principalmente con algunos problemas menores que surgieron.
Si está usando Hadoop 2.7 o posterior, use s3a. Si está utilizando Hadoop 2.5 o anterior. s3n, si está utilizando Hadoop 2.6, es una elección más difícil. -Probaría s3a y volvería a s3n si hubiera problemas-
Para obtener más información sobre la historia, consulte http://hortonworks.com/blog/history-apache-hadoops-support-amazon-s3/
2017-03-14 Actualización en realidad, la partición está rota en S3a en Hadoop 2.6, ya que el tamaño de bloque devuelto en una
listFiles()llamada 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 centrales del sistema de archivos y la generación de datos son felices. Hadoop 2.7 corrige eso.2018-01-10 Actualización Hadoop 3.0 ha reducido sus implementaciones s3: y s3n: s3a es todo lo que obtienes. Ahora es significativamente mejor que su predecesor y funciona tan bien como la implementación de Amazon. El "s3:" de Amazon todavía lo ofrece EMR, que es su cliente de código cerrado. Consulte los documentos de EMR para obtener más información.
fuente