OCI-HDFS-Connector verwenden

Optimierung lesen

Standardmäßig ist die von einer Hadoop-Anwendung erstellte InputStream ein grundlegender Wrapper für die InputStream, die vom Object Storage Service-(OSS-)Client generiert wird. Es fehlen jedoch Performanceoptimierungen.

Um die Lesegeschwindigkeit zu erhöhen, verwenden Sie die folgenden Parameter für das Lese-Caching.

Optimierungskonfigurationen im Voraus lesen

• 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

Parquet-Metadaten-Caching

• fs.oci.caching.object.parquet.enabled=true: Dieser Parameter aktiviert das Caching von Parquet-Footer-Metadaten im RAM.
• fs.oci.caching.object.parquet.spec: Dieser Parameter ermöglicht die Feinabstimmung des Caching-Verhaltens, obwohl seine Verwendung optional ist und von bestimmten Workload-Anforderungen abhängt.

Durch die Aktivierung von Parquet-Footer-Caching können Sie die Leseleistung von Parquet-Dateien erheblich verbessern, insbesondere in Szenarien, in denen mehrmals auf dieselben Dateien zugegriffen wird oder die Metadaten relativ statisch sind. Dieser Caching-Mechanismus stellt sicher, dass kritische Metadaten im Speicher verfügbar sind, sodass die Metadaten nicht wiederholt aus den Parquet-Dateien gelesen werden müssen. Legen Sie die vorhergehenden Parameter fest, um das Caching des Parquet-Footers im RAM zu aktivieren.

Parquet-Metadaten-Caching ist am effektivsten, wenn die Blockanzahl 1 ist, da damit die gesamten Metadaten gecacht und schnell aufgerufen werden können. Wenn die Blockanzahl größer als 1 ist, hängt die Effektivität des Metadaten-Caches von der Workload und den Lesemustern der Anwendung ab. Workloads wie distcp, die ganze Dateien lesen, können von einer höheren Parallelität und der Einstellung blockcount profitieren, während Anwendungen wie Spark, die bestimmte Spalten aus einer Parquet-Datei lesen, möglicherweise über eigene Optimierungsstrategien verfügen, die diese Einstellungen weniger relevant machen.

Optimierung schreiben

Der HDFS-Connector generiert standardmäßig eine lokale temporäre Datei auf dem Datenträger, um Daten zu puffern, die in eine HDFS-Datei geschrieben wurden. Siehe die folgenden HDFS-Connector-Konfigurationen:

• fs.oci.io.write.multipart.inmemory: Diese Konfiguration aktiviert den "upload-as-you-go"-Prozess. Wenn dieser Wert auf "true" gesetzt wird, beginnt der Connector, Datenteile in Object Storage Service hochzuladen, sobald die geschriebene Größe die vordefinierte Teilgröße erreicht, ohne darauf zu warten, dass die gesamte Datei auf dem Datenträger gepuffert wird.
• fs.oci.client.multipart.numthreads: Diese Konfiguration gibt die Anzahl der Threads an, die für Multipart-Uploads verwendet werden sollen. Wir empfehlen, die Anzahl der Threads auf der erwarteten Anzahl von Chunks für eine typische Datei zu basieren. Eine allgemeine Richtlinie ist, sie auf das 2-fache der Anzahl von vCPUs pro Executor zu setzen. Diese Konfiguration gewährleistet die parallele Verarbeitung von Datenteilen während des Uploads.
• fs.oci.client.multipart.partsize.mb: Diese Konfiguration definiert die Größe jedes Datenteils in Megabyte für Multipart-Uploads. Wir empfehlen die Verwendung einer Chunk-Größe von 64 MB, bei der die Dateigröße gleichmäßig in gleiche Chunks unterteilt wird. Beispiel: Wenn die Dateigröße 640 MB beträgt, führt eine Teilgröße von 64 MB zu 10 gleich großen Blöcken.
• fs.oci.client.multipart.minobjectsize.mb: Diese Konfiguration gibt die Mindestobjektgröße in Megabyte an, für die Multipart-Uploads aktiviert sind. Objekte, die kleiner als die angegebene Größe sind, werden mit einer standardmäßigen PutObject-Anforderung anstelle von Multipart-Uploads hochgeladen. Dies kann nützlich sein, um die Performance für kleinere Dateien zu optimieren.
• fs.oci.client.md5.numthreads: Diese Konfiguration legt die Anzahl der Threads für die asynchrone Berechnung von MD5-Hashwerten fest. Der Hash MD5 wird verwendet, um die Datenintegrität während der Übertragung zu überprüfen. Durch die Einrichtung eines dedizierten Threadpools kann die Berechnung von MD5-Hashes gleichzeitig mit dem Prozess zum Hochladen von Datenteilen durchgeführt werden, wodurch die Gesamteffizienz verbessert wird.

Einige Optimierungen basieren auf der Dateigröße. Im Allgemeinen möchten wir Dateien als 32 bis 128 MB-Chunks durch Multipart-Upload schreiben (was standardmäßig aktiviert ist). Verwenden Sie für explizites Tuning für eine Dateigröße von X MB eine mehrteilige Chunk-Größe, die 64 MB am ehesten gleichmäßig X in gleiche Chunks unterteilt. Beispiel: Wenn X 640 MB beträgt, erhalten Sie zehn 64 MB Chunks, was gleichmäßig ist. Wenn X 641 MB beträgt, erhalten Sie zehn 64 MB Chunks und einen 1 MB Chunk. Eine Blockgröße von 65 MB ist besser. Für einen Standardstart setzen Sie N in den folgenden Optimierungen jedoch auf 64 (für 64 MB).

Die Anzahl der Threads (M) entspricht dann der Anzahl der Chunks für eine typische Datei. Im Allgemeinen kann dies 2 * vcpus pro Executor sein. X * M Byte Heap für die Übertragung werden zurückgegeben, so dass diese möglicherweise angepasst werden müssen, um in einen kleineren Heap zu passen.

• 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()

Referenzen: URI-Formate für HDFS-Connectors