Deep Lake, ein Lakehouse für Deep Learning: Tensor-Speicherformat

Linktabelle

• Zusammenfassung und Einleitung
• Derzeitige Herausforderungen
• Tensor-Speicherformat
• Übersicht zum Deep Lake System
• Anwendungsfälle für maschinelles Lernen
• Leistungsbenchmarks
• Diskussion und Einschränkungen
• Ähnliche Projekte
• Schlussfolgerungen, Danksagungen und Referenzen

3. TENSOR-SPEICHERFORMAT

Deep Lake-Datensätze folgen einer spaltenorientierten Speicherarchitektur mit Tensoren als Spalten, wie in Abb. 3 dargestellt. Jeder Tensor ist eine Sammlung von Chunks – binäre Blobs, die die Datenproben enthalten. Eine mit jedem Tensor verknüpfte Indexzuordnung hilft dabei, für einen bestimmten Probenindex den richtigen Chunk und Index der Probe innerhalb dieses Chunks zu finden.

3.1 Datensatz

Ein Sample in einem Datensatz stellt eine einzelne Zeile dar, die über parallele Tensoren indiziert ist. Im Gegensatz zu einem Dokumentspeicherformat sind Sample-Elemente logisch unabhängig, was einen teilweisen Zugriff auf Samples ermöglicht, um leistungsfähige Abfragen auszuführen oder ausgewählte Tensoren über das Netzwerk an die GPU-Trainingsinstanzen zu streamen. Mehrere Tensoren können gruppiert werden. Gruppen implementieren syntaktische Verschachtelung und definieren, wie Tensoren miteinander in Beziehung stehen. Syntaktische Verschachtelung vermeidet die Formatkomplikation für hierarchisches Speicherlayout. Änderungen am Schema des Datensatzes werden im Laufe der Zeit auch mit der Versionskontrolle verfolgt, ähnlich wie Änderungen am Datensatzinhalt.

3.2 Tensoren

Tensoren sind typisiert und können an Ort und Stelle angehängt oder geändert werden. Der Standardzugriff auf einen Index oder einen Satz von Indizes gibt die Daten als NumPy-Arrays zurück [55]. Anstatt 1-D-Daten wie in Parquet [79] oder Serien in Arrow [13] zu speichern, können Tensoren n-dimensionale Daten aufnehmen, wobei die erste Dimension typischerweise der Index- oder Batch-Dimension entspricht. Tensoren können dynamisch geformte Arrays enthalten, die auch als zerlumpte Tensoren bezeichnet werden, im Gegensatz zu anderen statisch gestückelten Array-Formaten wie Zarr [52].

3.3 Typen

Htype definiert die Erwartungen an Samples in einem Tensor wie Datentyp (dtype wie in NumPy [55]), Form, Anzahl der Dimensionen oder Komprimierung. Typisierte Tensoren machen die Interaktion mit Deep-Learning-Frameworks unkompliziert und ermöglichen Plausibilitätsprüfungen und ein effizientes Speicherlayout. Durch Erben von einem generischen Tensor-Htype können wir Typen wie Bild, Video, Audio, Bbox, Dicom und andere konstruieren. Beispielsweise würde ein Tensor mit Bild-Htype erwarten, dass die an ihn angehängten Samples den Dtype uint8 und die Formlänge 3 haben (d. h. Breite, Höhe und Anzahl der Kanäle). Wir erweitern das Konzept der Htypes weiter und ermöglichen Metatypen, die das Speichern von Bildsequenzen in Tensoren (Sequenz[Bild]) unterstützen, auf entfernt gespeicherte Bilder verweisen und gleichzeitig das reguläre Verhalten eines Bildtensors (Link[Bild]) beibehalten oder sogar eine mögliche formatübergreifende Unterstützung ermöglichen.

3.4 Speicherlayout

Ein Deep Lake-Datensatz enthält eine Herkunftsdatei im JSON-Format und Ordner pro Tensor. Ein Tensor enthält Chunks, Chunk-Encoder, Kachel-Encoder und Tensor-Metadaten. Tensoren können optional ausgeblendet werden. Beispielsweise können ausgeblendete Tensoren verwendet werden, um herunterskalierte Versionen von Bildern beizubehalten oder Forminformationen für schnelle Abfragen beizubehalten.

Tensoren werden auf Speicherebene in Blöcken gespeichert. Statisch (abgeleitet) geformte Blöcke vermeiden zwar die Pflege einer Blockzuordnungstabelle, führen jedoch zu erheblichem Benutzeraufwand bei der Spezifikation des Tensors, Einschränkungen bei der Verwendung benutzerdefinierter Komprimierung, nicht ausreichend genutztem Speicher für dynamisch geformte Tensoren und Ineffizienzen bei der Nachbearbeitung. Deep-Lake-Blöcke werden basierend auf der Unter- und Obergrenze der Blockgröße erstellt, um eine begrenzte Anzahl von Samples aufzunehmen. Dies geht mit dem Kompromiss einher, dass eine komprimierte Indexzuordnung vorliegt, die die Zuordnung des Sample-Index zur Block-ID pro Tensor beibehält und gleichzeitig Blockgrößen im optimalen Bereich für das Streaming ermöglicht, während gemischt geformte Samples aufgenommen werden. Man könnte den in diesem Dokument verfolgten Ansatz als einen optimierten Kompromiss zwischen der Seitenzuordnung des Dateisystems und dem rechnerdefinierten kartenlosen Array-Speichersystem betrachten. Aus praktischen Gründen kann ein einzelner Blockencoder auf Milliarden von Bildern skaliert werden, während ein 150-MB-Blockencoder pro 1 PB Tensordaten beibehalten wird. Eine weitere Skalierung kann durch Sharding des Blockencoders erreicht werden. Chunks enthalten Header-Informationen wie Byte-Bereiche, Formen der Samples und die Sample-Daten selbst. Wenn ein Sample größer als die obere Chunk-Grenze ist, was bei großen Luft- oder Mikroskopbildern der Fall ist, wird das Sample über räumliche Dimensionen hinweg in Chunks aufgeteilt. Die einzige Ausnahme von der Aufteilung sind Videos. Videos bleiben dank effizienter Frame-Zuordnung zu Indizes, ausschließlicher Keyframe-Dekomprimierung und bereichsbasierter Anfragen beim Streaming erhalten.

3.5 Zugriffsmuster

Das Tensor-Speicherformat ist für Deep-Learning-Training und Inferenz optimiert, einschließlich sequentiellem und wahlfreiem Zugriff. Der sequentielle Zugriff wird zum Ausführen von Scan-Abfragen, zum Umwandeln von Tensoren in andere Tensoren oder zum Ausführen von Inferenzen verwendet. Anwendungsfälle für wahlfreien Zugriff umfassen mehrere Annotatoren, die Beschriftungen auf dasselbe Bild schreiben, oder Modelle, die Rückvorhersagen zusammen mit dem Datensatz speichern. Während der strikte Modus deaktiviert ist, können Indizes außerhalb der Grenzen eines Tensors zugewiesen werden, wodurch spärliche Tensoren berücksichtigt werden. Eine zufällige Zuweisung im Laufe der Zeit führt jedoch zu ineffizient gespeicherten Datenblöcken. Um das Datenlayout zu korrigieren, implementieren wir einen On-the-Fly-Rechunking-Algorithmus, um das Datenlayout zu optimieren. Eines der wichtigsten Zugriffsmuster von Deep Lake ist der Shuffled-Stream-Zugriff zum Trainieren von Modellen für maschinelles Lernen. Es erfordert zufälligen oder benutzerdefinierten Zugriff beim Streamen von Blöcken in den Trainingsprozess. Dies wird erreicht, indem bereichsbasierte Anfragen zum Zugriff auf Unterelemente innerhalb von Blöcken einbezogen werden, komplexe Abfragen vor dem Training ausgeführt werden, um die Reihenfolge zu bestimmen, und ein Puffercache mit abgerufenen und ungenutzten Daten verwaltet wird. Dadurch wird vermieden, dass für die Ausführung des Shuffling-Algorithmus ein separater Computercluster erforderlich ist [50].

Jeder Tensor hat seine eigenen Chunks und die Standard-Chunkgröße beträgt 8 MB. Ein einzelner Chunk besteht aus Daten aus mehreren Indizes, wenn die einzelnen Datenpunkte (Bild, Beschriftung, Anmerkung usw.) kleiner als die Chunkgröße sind. Umgekehrt werden die Daten auf mehrere Chunks aufgeteilt (Kacheln), wenn einzelne Datenpunkte größer als die Chunkgröße sind. Ausnahmen von der Chunking-Logik sind Videodaten.

Das Deep Lake-Format ist für die Maximierung des Durchsatzes bei der GPU-Verarbeitung optimiert. Es umfasst CPU-Vorabruf, Dekomprimierung oder Dekodierung, Transformationen und GPU-Speicherübertragung im erwarteten Layout eines Deep-Learning-Frameworks.

3.6 Speicheranbieter

Deep Lake kann an jeden beliebigen Speicheranbieter angeschlossen werden, einschließlich Objektspeichern wie AWS S3 [1], Google Cloud Storage (GCS) [3], POSIX-kompatiblen Dateisystemen oder lokalem In-Memory-Speicher. Darüber hinaus erstellt es Speichercaching, indem es verschiedene Speicheranbieter miteinander verkettet, zum Beispiel den Least Recently Used (LRU)-Cache eines entfernten S3-Speichers mit lokalen In-Memory-Daten.