Apache Iceberg Storage und Pandas Analytics: Teil I

Ich probiere generell gerne Neues aus, und das gilt auch für die Technologie. Deshalb habe ich mich entschlossen, die Mechanismen hinter Apache Iceberg und insbesondere der Python-Implementierung PyIceberg genauer zu untersuchen.

Apache Iceberg with Industrial Piping

Ich habe mir insbesondere einige Schlüsselelemente angesehen, die normalerweise Teil der Datenverwaltungspraktiken sind, unabhängig von der Technologie:

• Datenqualitätskontrollen: Kann ich Schemata mindestens mit Datentypisierung, vorzugsweise jedoch mit Wertprüfung validieren?

  
  

• Datenintegrität: Können Sie Duplikate verhindern, Schlüssel erzwingen und ein gewisses Maß an referenzieller Integrität aufrechterhalten, wenn Daten über Datenstrukturen hinweg verknüpft werden?

  
  

  
  

• Datenzugriff: Können Sie die Sicherheit mit Zugriff auf Zeilenebene verwalten und ist die Zugriffszeit robust, sodass Abrufe und Ladevorgänge angemessen sind, d. h. den durchschnittlichen Erwartungen für Benutzer, Dienste und Anwendungen entsprechen?

  
  

• Metadatenverwaltung: Kann ich Schemata haben, die sich über mehrere Versionen hinweg weiterentwickeln können und mir möglicherweise die Möglichkeit bieten, Änderungen rückgängig zu machen?

Falls Sie PyIceberg noch nicht kennen: Es handelt sich um eine Python-Implementierung von Apache Iceberg, die keine JVM benötigt. PyIceberg ist Open Source, daher finden Sie das GitHub-Repository hier und Community-Support hier . Das Projekt begann zunächst als Erweiterung für Apache Spark, später für Flink und Hive.

Apache Arrow Foundation

Die Daten-E/A-Mechanik basiert auf Apache Arrow , einem Projekt zur Spezifikation tabellarischer Daten und deren Austausch zwischen Systemen, insbesondere im Bereich der In-Memory-Analyse. Arrow wurde ursprünglich in C geschrieben und später in verschiedene andere Sprachen portiert (siehe Implementierungen im obigen Homepage-Link).

Unten auf der Startseite finden Sie weitere Links zu Cookbooks für C++ , Java , Python und R , die Ihnen einen schnellen Einstieg in die Implementierung dieser Sprachen ermöglichen. Portierungen in gängige Sprachen und Toolkits wie C#, Rust, Ruby und MATLAB sind ebenfalls verfügbar.

Wenn Sie derzeit die Formate Apache Parquet oder ORC verwenden oder dies planen, werden Sie wahrscheinlich feststellen, dass Bibliotheken von Cloud-Anbietern oder Abfrage-Engines die Arrow-Bibliotheken als Ausgangsbasis für die spezifischen Erweiterungen jedes Anbieters beziehen und umschließen.

KI/ML-Erweiterungen

Es gibt CUDA-Erweiterungen für die KI/ML-Community, aber Sie vermeiden hoffentlich die Durchführung von Datentransformationen und -manipulationen auf teuren GPU-Ressourcen, da Sie so kostengünstiger und verarbeitungseffizienter vorgehen.

Ich denke, die fehlende Trennung der Aufgabenbereiche bei diesen datenorientierten Aufgaben ist einer der Gründe für die Nachfrage nach GPUs und die mangelnde CPU-Auslastung für das Training und den Betrieb von KI/ML-Modellen. Es liegt weniger an der mangelnden Erkenntnis, dass die Trennung notwendig ist, als vielmehr an der Zeit, die für die Entwicklung und Umsetzung dieser Trennung benötigt wird; sie findet also nicht statt.

GPUs sind keine Allzweckprozessoren wie CPUs und eignen sich (zumindest bisher) eher für Berechnungen von Algorithmen und Visualisierungen. Sie wurden entwickelt, um Punkte auf einem Dreieck parallel für grafische Darstellungen zu berechnen. NVIDIA bietet eine Einführung in die GPU-Leistung . Eine grundlegende Übersicht über zellbasierte Prozessoren (zu denen auch GPUs gehören) vom Ohio Supercomputing Lab (2007) finden Sie unten:

2007_tech_notes_jun_jul.pdf

PDF herunterladen • 196KB

Die spezifischen Anwendungsfälle für zellbasierte Prozessoren sind die wichtigste Erkenntnis, da sich die meisten Ingenieure in ihrer Entwicklungskarriere auf einen einzelnen Prozessor und nicht auf mehrere konzentrieren. Die Fähigkeiten zur Workload-Trennung für spezifische Rechenressourcen müssen entwickelt und geschärft werden (Ende des Zwischenthemas).

Apache Iceberg unter der Haube

Der allgemeine Ansatz für Metadaten und Datenspeicherung zielt auf die Gewährleistung der Unveränderlichkeit ab, was definitiv ein Pluspunkt ist. Warum? Kurz gesagt: Datenzugriffsparallelität und -leistung lassen sich mit Implementierungen der Unveränderlichkeit (bei guter Umsetzung) besser skalieren und gewährleisten zudem die Rückverfolgbarkeit bei der Entwicklung von Schemata und Daten. Wenn Sie RDBMS-Produkte nutzen, kann das bekannte Problem der Daten- (Metadaten-) und Indexfragmentierung Wachsamkeit und Wartungszyklen erfordern. Dies ist besonders in analytischen (ROLAP) oder hybriden (OLTP + lange Historie) Fällen von Bedeutung, verschwindet jedoch mit Implementierungen der Unveränderlichkeit.

Wie bereits erwähnt, nutzt Iceberg verschiedene Bibliotheken aus Apache-Projekten von Arrow, Parquet, ORC und AVRO. Diese konzentrieren sich hauptsächlich auf I/O-Operationen, unabhängig davon, ob diese im Arbeitsspeicher oder dateibasiert erfolgen. Iceberg nutzt außerdem Pydantic in großem Umfang für die Metadatenimplementierung in Python.

Die „Modelle“ für Schemastrukturen werden mit Pydantic erstellt und validiert. Metadatenobjekte werden in einem Katalog mithilfe eines persistenten Speichers gespeichert. Der Zugriff auf den persistenten Speicher erfolgt über REST, ein SQL-DBMS, einen In-Memory-Speicher, Apache Hive, AWS Glue odereine benutzerdefinierte Konfiguration . Die Übersicht von https://iceberg.apache.org/spec/ gibt Ihnen einen visuellen Überblick über die Organisation. Weitere Details zur Abbildung: Die Metadatendatei ist eine Apache AVRO-Datei, und die Manifestlisten liegen im JSON-Format vor. Die Schemavalidierungseigenschaften in Verbindung mit Pydantic sind wahrscheinlich der Grund für die Wahl dieser Kombination.

Metadaten und Datenqualität

Die Metadatenorganisation beginnt auf Namespace-Ebene und stellt eine logische bzw. kontextuelle Trennung der Daten dar. Bei Bedarf können Sie beim Datenzugriff Namespace-übergreifende Referenzen verwenden. Tabellenobjekte werden „unter“ einem Namespace erstellt und stellen die Implementierungstypen für Schemata bereit, die Sie hier finden. Für die Speicherung georäumlicher Daten unterstützt Iceberg Geometrie- und geografische Typen und bietet Unterstützung für CRS (Koordinatenreferenzsystem) und Kanteninterpolation in der Metadatenebene. Datenpartitionierung und Zeilenherkunft sind ebenfalls verfügbar. Die Anzahl der Datensätze, die zur Detailherkunft gespeichert werden, kann bei der Katalogerstellung festgelegt werden.

Zur besseren Veranschaulichung des obigen Diagramms habe ich die Konsolendateiausgabe der Iceberg-Tabellen eingefügt, die ich für die Beispielimplementierung in Teil II erstellt habe. Ich habe auf meinem Gerät einen Ordner „Warehouse“ angelegt, dessen Auflistung unter dem Namespace „docs“ beginnt. Er führt durch die „Forecast“-Daten und Metadaten.

Namespace and Table Organization

Data and Metadata for Forecasts Object

Die Implementierung von Pydantic, insbesondere im „strikten“ Modus (Metadaten und Daten), deckt die Punkte „Metadaten“ und „Datenqualität“ am Anfang des Artikels ab. Sie erhalten außerdem Schemaversionskontrollen in den Metadaten bis auf Spaltenebene und sehr gute Mechanismen zur Unterstützung der Schemaentwicklung. Iceberg-Metadaten bieten viele Variationen, die mit dem RDBMS-Äquivalent von „Constraints“ (nicht der wörtlichen Tabellen-DDL) implementiert werden. Sie erhalten Typvalidierung, obligatorische Feldbezeichnungen sowie eine Überprüfung auf Größe und Genauigkeit. Es fehlt jedoch die Anwendung einer benutzerdefinierten Werteliste auf bestimmte Felder.

Die Verwendung von Wertelisten ist meiner Erfahrung nach in OLTP-Designmustern häufiger anzutreffen als in OLAP(Analytics)-Fällen für ein RDBMS. Apache Iceberg ist eindeutig für analytische Anwendungsfälle und nicht für die Transaktionsverarbeitung konzipiert. Insgesamt ist es ein guter Ausgangspunkt für Datenqualität und Metadaten. Die „Standard“-Werteattribute bieten die Möglichkeit, ein Ersatz-„Schlüssel“-Äquivalent zu implementieren oder „Bezeichner“-Feld-IDs zu verwenden.

Es bietet kein Äquivalent zu einem Primär- oder eindeutigen Schlüssel, einem Datenbank-Einschränkungstyp, der Eindeutigkeit unabhängig vom zugehörigen Index gewährleistet. Es gibt auch keine benutzergesteuerte Indizierung, aber wenn Sie bereits eines der zuvor genannten Dateiformate verwenden, ist das nichts Neues und wird auch nicht erwartet. Die Gewährleistung der Eindeutigkeit obliegt dem „Benutzer“. Sie können beispielsweise Eindeutigkeit innerhalb einer Struktur erzwingen, aber das liegt in Ihrer Verantwortung; Iceberg übernimmt das nicht für Sie.

Sicherheit auf Zeilenebene

Die Herausforderungen für Apache Iceberg liegen in den Bereichen RWA (Row-Level Access Security) und Datenintegrität. Ich bewerte die integrierten Funktionen der Bibliotheken und nicht, wie man mit zusätzlichen Tools eine Lösung für diese Probleme entwickeln kann.

RWA-Sicherheit ist nicht in die Bibliotheken integriert. Es gibt einige sehr nützliche Funktionen für Zeilen- und Metadaten, die Ihnen bei der Diagnose von Datenqualitätsproblemen helfen und Funktionen zur Änderung im Zeitverlauf bieten. Letzteres könnte in einem Zeitreihen-Anwendungsfall sehr nützlich sein. RWA-Sicherheit ist jedoch in der Regel eine Sicherheitsanforderung des Unternehmens; hoffentlich wird die LDAP-Integration irgendwann verfügbar sein, um dies zu ermöglichen.

Datenintegrität

Die Datenintegritätsfunktionen stehen bei Iceberg nicht wirklich im Fokus, möglicherweise weil der Trend im KI/ML-Datenzugriff dahin geht, Datentabellen zu denormalisieren, sodass Fremdschlüssel nicht mehr benötigt werden, d. h. eine einzige große Tabelle. Sie kommt in traditionelleren Analysefällen zum Einsatz, in denen mehrere Tabellen Beziehungsverknüpfungen (physisch oder virtuell) erfordern. Daher wäre sie für diese Fälle eine hilfreiche Ergänzung. Auch wenn die Daten nur informativ in Metadaten erfasst werden, verbessert sie die Validierung. In Iceberg wird dieser Bereich jedoch übersehen.

Datenzugriff

Nutzer, die aktuell eines der zuvor genannten Apache Arrow-Formate verwenden, wissen, worauf sie sich bei der Verwendung der einzelnen Formate einstellen. Für große Datenmengen wird Parquet häufig für große bis sehr große Datensätze verwendet, insbesondere wenn eine Partitionierung erforderlich ist, um angemessene Abfrageantwortzeiten zu gewährleisten. Ich habe eine kleine Implementierung erstellt, die ich in Teil II des Artikels detailliert beschreiben werde und in der einfache Antwortzeiten aufgezeichnet werden. Wie viele wissen, reagiert Parquet, insbesondere bei guter Partitionierung, sehr schnell auf Abfragen. Das spaltenbasierte Format eignet sich besonders gut für analytische Anwendungsfälle.

Im nächsten Teil des Artikels werde ich eine einfache Implementierung mit Apache Iceberg und Finanzdaten mit einigen Python-Aggregationen durchgehen.