Deep Lake, ein Lakehouse für Deep Learning: Aktuelle Herausforderungen

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

2. AKTUELLE HERAUSFORDERUNGEN

In diesem Abschnitt diskutieren wir die aktuellen und historischen Herausforderungen des unstrukturierten oder komplexen Datenmanagements.

2.1 Komplexe Datentypen in einer Datenbank

Es wird im Allgemeinen nicht empfohlen, Binärdaten wie Bilder direkt in einer Datenbank zu speichern. Dies liegt daran, dass Datenbanken nicht für die Speicherung und Bereitstellung großer Dateien optimiert sind und Leistungsprobleme verursachen können. Darüber hinaus passen Binärdaten nicht gut in das strukturierte Format einer Datenbank, was die Abfrage und Bearbeitung erschwert. Dies kann zu langen Ladezeiten für Benutzer führen. Datenbanken sind in der Regel teurer im Betrieb und in der Wartung als andere Speichertypen wie Dateisysteme oder Cloud-Speicherdienste. Daher kann das Speichern großer Mengen binärer Daten in einer Datenbank teurer sein als bei anderen Speicherlösungen.

2.2 Komplexe Daten in tabellarischen Formaten

Die Zunahme groß angelegter analytischer und BI-Arbeitslasten motivierte die Entwicklung komprimierter strukturierter Formate wie Parquet, ORC, Avro oder flüchtiger In-Memory-Formate wie Arrow [79, 6, 20, 13]. Mit der zunehmenden Verbreitung tabellarischer Formate entstanden Versuche, diese Formate für Deep Learning zu erweitern, wie etwa Petastorm [18] oder Feather [7]. Unseres Wissens nach haben sich diese Formate noch nicht weit verbreitet. Dieser Ansatz profitiert in erster Linie von nativen Integrationen mit Modern Data Stack (MDS). Wie bereits erwähnt, erfordern Upstream-Tools jedoch grundlegende Änderungen, um sich an Deep Learning-Anwendungen anzupassen.

2.3 Objektspeicher für Deep Learning

Die derzeitige Cloud-native Wahl zum Speichern großer unstrukturierter Datensätze ist Objektspeicher wie AWS S3 [1], Google Cloud Storage (GCS) [3] oder MinIO [17]. Objektspeicher bieten gegenüber verteilten Netzwerkdateisystemen drei Hauptvorteile. Sie sind (a) kosteneffizient, (b) skalierbar und (c) dienen als formatunabhängiges Repository. Cloud-Speicher sind jedoch nicht ohne Nachteile. Erstens führen sie zu erheblichen Latenzzeiten, insbesondere bei der Iteration über viele kleine Dateien wie Text oder JSON. Zweitens kann die Aufnahme unstrukturierter Daten ohne Metadatenkontrolle zu „Datensümpfen“ führen. Darüber hinaus verfügt der Objektspeicher über eine integrierte Versionskontrolle; er wird in Data-Science-Workflows selten verwendet. Schließlich werden Daten auf dem Objektspeicher vor dem Training auf eine virtuelle Maschine kopiert, was zu Speicheraufwand und zusätzlichen Kosten führt.

2.4 Zweite Generation von Data Lakes

Die Data Lakes der zweiten Generation um Delta, Iceberg und Hudi [27, 15, 10] erweitern die Objektspeicherung durch die Verwaltung von Dateien im Tabellenformat mit den folgenden primären Eigenschaften.

(1) Aktualisierungsvorgänge: Einfügen oder Löschen einer Zeile über einer Datei im tabellarischen Format.

(2) Streaming : Downstream-Datenaufnahme mit ACID-Eigenschaften und Upstream-Integration mit Abfrage-Engine, die eine SQL-Schnittstelle bereitstellt.

(3) Schemaentwicklung: Weiterentwicklung der spaltenorientierten Struktur unter Wahrung der Abwärtskompatibilität.

(4) Zeitreise und Nachverfolgung von Prüfprotokollen: Beibehaltung des historischen Zustands mit Rollback-Eigenschaft, sodass Abfragen reproduziert werden können. Außerdem Unterstützung für die zeilenbasierte Kontrolle der Datenherkunft.

(5) Layoutoptimierung: Integrierte Funktion zur Optimierung der Dateigröße und Datenkomprimierung mit Unterstützung für benutzerdefinierte Sortierung. Beschleunigt Abfragen erheblich.

Data Lakes der zweiten Generation unterliegen jedoch noch immer den Einschränkungen der inhärenten Datenformate für Deep Learning, wie bereits in Abschnitt 2.2 erläutert. Daher erweitern wir in diesem Artikel die Funktionen der zweiten Generation von Data Lakes für Deep Learning-Anwendungsfälle, indem wir das Format und die Upstream-Funktionen überdenken, einschließlich Abfragen, Visualisierung und nativer Integration in Deep Learning-Frameworks, um den ML-Lebenszyklus wie in Abb. 2 dargestellt zu vervollständigen.