Uso del conector HDFS de OCI
El conector del sistema de archivos distribuido de Hadoop (HDFS) de OCI permite que la aplicación Apache Hadoop pueda leer y escribir datos que se envían y reciben de Object Storage.
Esto es para Big Data Service 3.0.4 o anterior. Si la versión es 3.0.4 o posterior, utilice la integración de claves de API de almacenamiento de objetos para conectarse a Object Storage. La Versión de Big Data Service se muestra en el separador Información del Cluster de la página Detalles del Cluster.
Directrices generales de ajuste
Siguiendo las directrices generales de ajuste para Big Data Service al ejecutar cargas de trabajo en el sistema de archivos de almacenamiento de objetos de OCI para obtener un rendimiento y una fiabilidad eficaces para cargas de trabajo medianas o mayores.
Ajuste de lectura
Por defecto, el InputStream creado por una aplicación de Hadoop es un envoltorio básico para el InputStream generado por el cliente del servicio de almacenamiento de objetos (OSS). Sin embargo, carece de optimizaciones de rendimiento.
Para mejorar la velocidad de lectura, utilice los siguientes parámetros asociados al almacenamiento en caché de lectura.
Configuraciones de ajuste de lectura anticipada
fs.oci.io.read.ahead=true
fs.oci.io.read.ahead.blocksize=6291456
fs.oci.io.read.ahead.blockcount=4
fs.oci.rename.operation.numthreads=2
Puede ajustar el tamaño del bloque, el recuento de threads o activar/desactivar el almacenamiento en caché según los patrones de carga de trabajo y las referencias de rendimiento. Estos son especialmente útiles para cargas de trabajo como distcp
, cargas de trabajo de Trino en las que la aplicación lee archivos completos de forma secuencial.
Almacenamiento en Caché de Metadatos de Parquet
fs.oci.caching.object.parquet.enabled=true
: este parámetro activa el almacenamiento en caché de los metadatos de pie de página de Parquet en RAM.fs.oci.caching.object.parquet.spec
: este parámetro permite ajustar el comportamiento del almacenamiento en caché, aunque su uso es opcional y depende de requisitos de carga de trabajo específicos.
Al activar el almacenamiento en caché de pie de página de Parquet, puede mejorar significativamente el rendimiento de lectura de los archivos de Parquet, especialmente en casos en los que se accede a los mismos archivos varias veces o cuando los metadatos son relativamente estáticos. Este mecanismo de almacenamiento en caché garantiza que los metadatos críticos estén fácilmente disponibles en la memoria, lo que reduce la necesidad de leer repetidamente los metadatos de los propios archivos Parquet. Defina los parámetros anteriores para activar el almacenamiento en caché del pie de página de Parquet en RAM.
El almacenamiento en caché de metadatos de Parquet es más eficaz cuando el recuento de bloques es 1, ya que permite almacenar en caché todos los metadatos y acceder a ellos rápidamente. Cuando el recuento de bloques es mayor que 1, la eficacia del almacenamiento en caché de metadatos depende de la carga de trabajo y los patrones de lectura de la aplicación. Las cargas de trabajo como distcp
, que leen archivos completos, pueden beneficiarse de un mayor paralelismo y la configuración blockcount
, mientras que las aplicaciones como Spark, que leen columnas específicas de un archivo Parquet, pueden tener sus propias estrategias de optimización que hacen que esta configuración sea menos relevante.
Ajuste de Escritura
El conector HDFS, por defecto, genera un archivo temporal local en el disco para almacenar en buffer los datos escritos en un archivo HDFS. Consulte las siguientes configuraciones de conector HDFS:
fs.oci.io.write.multipart.inmemory
: esta configuración permite el proceso de carga sobre la marcha. Si se define en true, el conector comienza a cargar partes de datos en el servicio de almacenamiento de objetos tan pronto como el tamaño escrito alcance el tamaño de parte predefinido, sin esperar a que todo el archivo se almacene en buffer en el disco.fs.oci.client.multipart.numthreads
: esta configuración especifica el número de threads que se van a utilizar para la carga de varias partes. Recomendamos basar el número de threads en el número esperado de fragmentos para un archivo típico. Una directriz general es definirla en 2 veces el número de vCPUs por ejecutor. Esta configuración garantiza el procesamiento paralelo de las partes de los datos durante la carga.fs.oci.client.multipart.partsize.mb
: esta configuración define el tamaño de cada parte de datos en megabytes para la carga de varias partes. Recomendamos utilizar un tamaño de fragmento más cercano a 64 MB que divida uniformemente el tamaño del archivo en fragmentos iguales. Por ejemplo, si el tamaño del archivo es de 640 MB, un tamaño de parte de 64 MB daría como resultado 10 fragmentos iguales.fs.oci.client.multipart.minobjectsize.mb
: esta configuración especifica el tamaño de objeto mínimo en megabytes para el que está activada la carga de varias partes. Los objetos de menor tamaño que el tamaño especificado se cargan mediante una solicitud PutObject estándar en lugar de la carga en varias partes. Esto puede ser útil para optimizar el rendimiento de archivos más pequeños.fs.oci.client.md5.numthreads
: esta configuración define el número de threads para calcular los valores hash MD5 de forma asíncrona. El hash MD5 se utiliza para verificar la integridad de los datos durante la transmisión. Al establecer un pool de threads dedicado, el cálculo de los hashes de MD5 se puede realizar simultáneamente con el proceso de carga de la parte de datos, lo que mejora la eficiencia general.
Algunos ajustes se basan en el tamaño del archivo. En general, queremos escribir archivos como fragmentos de 32 a 128 MB mediante la carga en varias partes (que está activada por defecto). Para el ajuste explícito, para un tamaño de archivo de X MB, utilice un tamaño de fragmento de varias partes más cercano a 64 MB que divida X de manera más uniforme en fragmentos iguales. Por ejemplo, si X es 640 MB, obtendría diez fragmentos de 64 MB, que es par. Si X es 641 MB, obtendrá diez fragmentos de 64 MB y un fragmento de 1 MB. Un tamaño de fragmento de 65 MB es mejor. Sin embargo, para un inicio predeterminado, establezca N en los siguientes ajustes en 64 (para 64 MB).
A continuación, el número de threads (M) es el número de fragmentos de un archivo típico. En general, esto puede ser 2 * vcpus por ejecutor. X * Se devuelven M bytes de pila para la transferencia, por lo que es posible que se deban ajustar para que quepan en una pila más pequeña.
Ejemplos de uso del conector HDFS desde clusters de Big Data Service
Debe tener creadas las políticas de IAM necesarias para acceder a los cubos de Object Storage y otros recursos.
- Hadoop
hadoop fs -ls oci://<bucket-name>@<namespace>/
- Spark
import org.apache.spark._ val conf = sc.getConf val test_prefix = sc.textFile("oci://<bucket-name>@<namespace>/") test_prefix.toDF().show()
Referencias: Formatos de URI para conectores HDFS