hadoop - común - Técnicamente, ¿cuál es la diferencia entre s3n, s3a y s3?

hadoop tutorial

Question

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

S3 Native FileSystem (esquema 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 se escribieron 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 del archivo impuesto por S3.

S3A (esquema URI: s3a) Un sucesor del S3 Native, s3n fs, el sistema S3a: utiliza las bibliotecas de Amazon para interactuar con S3. Esto permite que S3a admita archivos más grandes (no más de 5 GB 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: // Las 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 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 mayores de 5 GB, pero no son interoperables con otras herramientas 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 que subyace a este cambio? ¿Hay algún buen artículo que pueda leer sobre esto?

Answer 1

El cambio de letra en el esquema URI hace una gran diferencia porque hace que se use un software diferente 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 encima de Amazon S3, mientras que s3n / s3a no lo están (están basadas en objetos).

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

Si estás aquí porque quieres entender qué sistema de archivos S3 debes usar con Amazon EMR, entonces lee este artículo de Amazon (solo disponible en la máquina Wayback). 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.

Para obtener consejos adicionales, lea Trabajar con sistemas de almacenamiento y archivos .

Answer 2

en Apache Hadoop, "s3: //" se refiere al cliente S3 original, que utilizaba una estructura no estándar para la escalabilidad. Esa biblioteca está en desuso y pronto se eliminará,

s3n es su sucesor, que utiliza nombres de ruta directa a objetos, por lo que puede 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 el propio SDK de AWS de Amazon. ¿Por qué el nuevo nombre? para poder enviarlo al lado del que era estable. S3A es donde va todo el trabajo continuo sobre escalabilidad, rendimiento, seguridad, etc. S3N se queda solo para que no lo rompamos. S3A se envió en Hadoop 2.6, pero aún se estaba estabilizando hasta 2.7, principalmente con algunos problemas menores de escala.

Si está utilizando Hadoop 2.7 o posterior, use s3a. Si está utilizando Hadoop 2.5 o anterior. s3n, si está utilizando Hadoop 2.6, es una opción más difícil. -Intentarí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 se rompe en S3a en Hadoop 2.6, ya que el tamaño del bloque devuelto en una llamada listFiles() es 0: cosas como Spark & ​​pig particionan 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.

Actualización del 10-01-2018 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. EMR, que es su cliente de código cerrado, todavía ofrece el "s3:" de Amazon. Consulte los documentos de EMR para obtener más información.