Parquet, Iceberg und Data Lakehouses verstehen

 (davidgomes.com)
6 Punkte von GN⁺ 2023-12-31 | 2 Kommentare | Auf WhatsApp teilen
  • Datenspeichertechnologien bestehen nicht aus einem einzigen Block, sondern aus unterschiedlichen Schichten wie Dateiformaten, Speicherformaten, Tabellen-Metadatenebenen und Lakehouse-Architekturen
  • Avro, Parquet, ORC und Arrow sind Formate, die das binäre Layout von Daten festlegen; Parquet ist stark bei spaltenbasierter Komprimierung und analytischer Verarbeitung, während Avro besser für zeilenweise Verarbeitung geeignet ist
  • Iceberg und Delta Lake sind keine Dateiformate, sondern übergeordnete Metadatenebenen, die auf Dateien wie Parquet das Management großer Tabellen ermöglichen
  • Ein Data Lakehouse setzt auf rohe Dateien in Speichern wie S3 Warehouse-Funktionen wie SQL-Abfragen, Batch-Jobs und Governance auf
  • Da auch Warehouses wie Snowflake und BigQuery offene Formate wie Iceberg unterstützen, verschwimmt die Grenze zwischen Data Warehouse und Lakehouse zunehmend

Der Unterschied zwischen Dateiformat und Speicherformat

  • Open-Source-Formate zur effizienteren Speicherung und zum effizienteren Zugriff auf Daten unterscheiden sich sowohl in der Art der Speicherung als auch im Einsatzort
    • Apache Avro: binär, Zeilenspeicher (rowstore), Datei
    • Apache Parquet: binär, Spaltenspeicher (columnstore), Datei
    • Apache ORC: binär, Spaltenspeicher, Datei
    • Apache Arrow: binär, Spaltenspeicher, Speicher
    • Protocol Buffers: eine sprachneutrale Definitionssprache für Datenstrukturen; je nach Implementierung kann sie eher Zeilen- oder Spaltenspeicherung verwenden
    • CSV: textbasiert und strukturell sehr einfach
  • Wenn Apache-Arrow-DataFrames als Datei auf der Festplatte gespeichert werden, wird meist Feather verwendet; eine Umwandlung in andere Formate wie Parquet ist ebenfalls möglich
  • Systeme wie Snowflake, Redshift, Athena und Hive unterstützen das Lesen und Schreiben offener Formate ebenso wie proprietärer Speicherformate, aber der Umfang der Unterstützung offener Formate kann je nach Produkt unterschiedlich sein

Was Formate tatsächlich festlegen

  • Ein Dateiformat ist eine Spezifikation dafür, wie Daten im tatsächlichen binären Layout angeordnet werden
  • Parquet ist stark bei Komprimierung, während Avro durch seine zeilenbasierte Speicherung besser zum Lesen bestimmter Zeilenblöcke geeignet ist
  • Sowohl Parquet als auch Avro unterstützen Schema-Evolution, sodass sich das Schema neuer Daten ändern lässt, ohne alle bestehenden Daten neu schreiben zu müssen
  • Beide Formate unterstützen Dateisplitting, was für die parallele Datenverarbeitung wichtig ist
  • Das Apache-Parquet-Repository enthält die eigentliche Dateiformat-Spezifikation und eine Java-Referenzimplementierung
  • Parquet kann in vielen Sprachen und Tools gelesen und geschrieben werden; auch in Pandas lässt sich ein DataFrame mit to_parquet als lokale Parquet-Datei speichern
  • Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena und Apache Drill sind Beispiele für Engines, die mit Parquet-Dateien arbeiten können

Warum Dateiformate allein für große Datenverwaltung nicht ausreichen

  • Einzelne Dateiformate definieren nur das Layout einer einzelnen Datei und reichen deshalb nicht aus, um große, sich laufend verändernde Datensätze zu verwalten
  • Für das Speichern vieler Tabellen, die Schema-Evolution einzelner Tabellen, Point-in-Time-Abfragen, effiziente Partitionierung, das Lesen von Schemata durch externe Tools und das Speichern von Statistiken für kostenbasierte Abfrageoptimierung ist eine höhere Ebene nötig
  • Diese Ebene umfasst Tabellenformate und ein Schema-Registry oder Metastore
  • Die Confluent Schema Registry unterstützt Avro und Protobuf und eignet sich eher für Streaming-Daten, die tendenziell zeilenbasiert gespeichert werden

Die Rolle von Hive, Iceberg und Delta Lake

  • Facebook veröffentlichte 2009 Hive zusammen mit einem eigenen Tabellen-Metadatenformat, und Hive begann später, mehrere Formate zu unterstützen
  • Netflix entwickelte Iceberg, um die Leistungs- und Skalierungsgrenzen von Hive zu überwinden
  • Databricks entwickelte Delta Lake als Alternative zu Iceberg und veröffentlichte es später als Open Source
  • Sowohl Iceberg als auch Delta Lake verwenden Parquet als Dateiformat für einzelne Dateien
  • Hive, Delta Lake und Iceberg unterstützen alle Konzepte, die einem Schema-Registry oder Metastore entsprechen
  • Diese Kataloge und Metastores können auch für Data Governance genutzt werden, also zur Verwaltung, welche Teams oder Nutzer auf welche Tabellen zugreifen dürfen

Welche Aufgaben Iceberg und Delta Lake übernehmen

  • Delta Lake und Iceberg sind weder Query Engines noch Storage Engines selbst, sondern offene Spezifikationen, die den Betrieb von Query Engines ermöglichen
  • Beide lösen dasselbe Problem auf unterschiedliche Weise; rund um Delta Lake gibt es Diskussionen über Offenheit, weil die Vielfalt der Beitragenden geringer ist als bei Iceberg
  • In vielen Data Warehouses und Lakehouses wie Redshift, BigQuery, Snowflake, Athena und Dremio wächst die Unterstützung für Iceberg schnell
  • Iceberg und Delta Lake bieten die Funktionen, die für den Betrieb großer Tabellen nötig sind
    • Partitionierung
    • Schema-Evolution
    • Datenkomprimierung
    • ACID-Transaktionen bei Schemaänderungen
    • effiziente Abfrageoptimierung durch Column Pruning, Predicate Pushdown und das Sammeln von Statistiken
    • Time Travel für Point-in-Time-Abfragen
  • Iceberg unterstützt Partition Evolution, sodass sich Partitionierung oder Shard Key einer Tabelle ändern lassen, ohne alle bestehenden Daten neu schreiben zu müssen
  • Bei Netflix waren Änderungen an der Partitionierung ein großes Problem und einer der Gründe für die Entwicklung von Iceberg

Proprietäre Formate und der Druck zur Iceberg-Unterstützung

  • Die Iceberg-Spezifikation gewinnt schnell an Popularität als Format, das von vielen Systemen unterstützt wird
  • Produkte mit proprietären Formaten stehen unter Druck, in ihrem eigenen Format zwar möglichst hohe Leistung zu erzielen, aber zugleich Iceberg oder Delta Lake in irgendeiner Form unterstützen zu müssen
  • Iceberg könnte zu einem Pflicht-Häkchen werden, das jedes Datenbanksystem irgendwann unterstützen muss
  • Aus Leistungsgründen dürfte es für Iceberg schwierig sein, proprietäre Datenformate vollständig zu ersetzen
  • Wenn ein Datenformat nur für eine einzelne Query Engine entwickelt wird, können Datenbankentwickler maximale Effizienz herausholen und schneller innovieren

Data Lake und Data Lakehouse

  • Ein Data Lake ist der Ort, an dem ein Unternehmen große Datenmengen als Rohdateien in Formaten wie Parquet oder CSV speichert
  • Ein Data Warehouse speichert Daten strukturierter, etwa als SQL-Tabellen mit Schema und Datenbankschemata
  • Ein Data Lakehouse kombiniert einen Data Lake mit Funktionen wie SQL-Abfrageausführung, Batch-Jobs und Konfiguration von Data Governance
  • Mit Iceberg, einer Query Engine und weiteren Zusatzkomponenten lässt sich auf einem Data Lake ein Data Lakehouse aufbauen
  • Früher musste man für solche Funktionen ein Data Warehouse oder ein traditionelleres DBMS einführen
  • Ein Data Lakehouse verwendet Cloud-Blob-Storage wie HDFS oder S3 als Speicherort für alle Daten und optimiert Query Engines dafür, auf diesem Speicher schnell zu arbeiten
  • Databricks und Dremio sind Beispiele für Data-Lakehouse-Produkte
  • Da Warehouses wie Snowflake und BigQuery offene Datenformate wie Iceberg ergänzen, wird die Unterscheidung zwischen Data Warehouse und Data Lakehouse zunehmend unschärfer

Verwandte Beiträge

2 Kommentare

 
happing94 2024-01-03

Ich habe Iceberg und Delta Lake verglichen; hier ist das wirklich übersichtlich zusammengefasst.
Das entspricht fast genau meiner eigenen Einschätzung und Meinung.
Der online durchgeführte Benchmark wurde mit Spark ausgeführt, und der Head of DevRel von Tabular schrieb, dass der Benchmark zwar als Referenz dienen könne, aber keine große Bedeutung habe.
Wenn man sich für Open Source entscheiden will, scheint iceberg die einzige Wahl zu sein.
Die Zusammenfassung ist gut, aber es wäre noch besser, wenn es auch Links zu den verwendeten Referenzen gäbe.
 
GN⁺ 2023-12-31
Meinungen auf Hacker News

  • Apache Iceberg und Delta Lake werden zwar häufig beide als Open Table Format eingeordnet, wirken in der Praxis aber ziemlich unterschiedlich.
    Die Iceberg-Spezifikation findet sich unter https://iceberg.apache.org/spec/, und wer sich mit Datenbanksystemen auskennt, dürfte damit ohne große Schwierigkeiten eine Implementierung bauen können, die Iceberg-Tabellen erstellt und abfragt.
    Bei Delta Lake hingegen ist es https://github.com/delta-io/delta/blob/master/PROTOCOL.md; schon der Aufwand, der nötig wäre, um die aktuelle Spezifikation vollständig zu implementieren, ist schwer abzuschätzen, und dieser sich ständig verändernden riesigen Spezifikation zu folgen, wirkt noch entmutigender.
    Ehrlich gesagt liest sich die Delta-Lake-Spezifikation wie ein Dokument, das die Implementierungskompromisse rückwärts rekonstruiert, die entstanden sind, als Databricks für Fortune-1000-Unternehmen, die sich an Hadoop die Finger verbrannt hatten, schnell Lakehouses aufgebaut hat.
    Ich bin noch nicht überzeugt, dass die Einführung von Delta Lake wirklich bedeutet, in ein offenes Ökosystem einzutreten, und ich hätte gern belastbare Gründe, die einen da beruhigen.
    Nebenbei ist auch die GitHub-Historie nicht gerade beruhigend: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
    Es wirkt so, als würden beliebige Features und Fixes als PRs von Databricks-Ingenieuren eingestellt und dann umgehend von Senior Engineers bei Databricks genehmigt.

    • Stimme allem zu. Dass Databricks Funktionen wie Bloom Filter absichtlich aus Open-Source-Delta heraushält, ist natürlich ihr gutes Recht.
      Aber dann kann man es nicht zugleich als Community-getriebenes offenes Format bezeichnen. Höchstens als Animal-Farm-Variante von „manche sind gleicher als andere“.
    • Ich habe Delta-Unterstützung für eine Komponente von Microsoft Fabric von Grund auf implementiert, und ohne zusätzliches Herumprobieren mit der Spark-Implementierung fühlte sich die „Spezifikation“ ziemlich unzureichend an.
      Wenn man Funktionen wie berechnete Spalten oder Check-Constraints nutzen will, muss man auch Spark-SQL-Ausdrücke unterstützen, und deren Dokumentation ist noch dürftiger.
    • Ich habe denselben Eindruck. Bei allem, was Databricks anbietet, bin ich extrem vorsichtig.
      Es ist eher dem Namen nach Open Source, und ich denke, man sollte dem nicht vertrauen.
      Ich habe auch Delta Lake verwendet, und im praktischen Einsatz gab es viele frustrierende Einschränkungen und scharfe Kanten. Am Ende haben wir dieses Projekt komplett eingestellt und damals auch Iceberg untersucht.
      Iceberg und Hudi wirkten in ihrer Funktionszusammenstellung konsistenter entworfen, waren aber weniger gut unterstützt; ich hoffe, dass sich das künftig verbessert.
    • Ich beobachte diesen Bereich seit etwa ein bis zwei Jahren und habe mich gefragt, warum Iceberg im Open-Source-Umfeld beliebter ist; diese Erklärung hilft.
      In den letzten sechs Monaten hatte ich den Eindruck, dass Iceberg Schwierigkeiten hat, Tools für Nutzer außerhalb des JVM-Ökosystems bereitzustellen, während Delta hier voraus ist. In dieser Hinsicht ist Delta deutlich zugänglicher.
    • Dass Delta-Änderungen JSON verwenden, ist wirklich töricht.
      Zum Vergleich: In SQL Server ist das deutlich besser umgesetzt. Spaltenorientiert gespeicherte Tabellen (Columnstore Indexes, das interne Äquivalent der Engine zu Parquet/ORC) sind unveränderlich, und das Delta wird aus Gründen der Komprimierbarkeit, Zugänglichkeit und Geschwindigkeit in einem B-Tree gespeichert.
      Ab einem bestimmten Zeitpunkt wird der Columnstore teilweise oder vollständig defragmentiert, zusammengeführt oder neu aufgebaut; der B-Tree wird gelöscht und beginnt dann erneut, während neue Änderungen auflaufen.
      Das mit JSON zu machen, ist gelinde gesagt ein Zeichen schlechter Zeiten.
      Alles dürfte besser sein als Delta Lake, und insbesondere Iceberg wirkt besser.

  • Guter Artikel. Ich arbeite seit Jahren mit Parquet-Dateien auf S3, wusste aber nicht genau, was Iceberg eigentlich ist; der Artikel erklärt es gut.
    Iceberg ist ein Datenbank-Metadatenformat, das unter anderem das Schema und die Partitionierung des zugrunde liegenden Datensatzes beschreibt.
    Die meisten nutzen Hive-Partitionierungskonventionen wie /key3=000/key2=002/, aber Iceberg ist besser, weil es der Query Engine mehr Struktur zugänglich macht.
    In einem traditionellen DBMS wie Postgres werden Schema, Query Engine und Speicherformat als ein Paket geliefert.
    In Big Data hingegen setzt man Datenbankkomponenten von Grund auf zusammen und kann sie miteinander kombinieren. Man kann Iceberg als Metadatenformat, DuckDB als Query Engine, Parquet als Speicherformat und S3 als Speichermedium verwenden.

  • In der Datenbankwelt ist das eine große Veränderung. Denn dank Delta, Iceberg und Hudi werden Daten meist in Open-Source-Formaten auf S3 gespeichert.
    Wenn ein erheblicher Teil von Storage und Verarbeitung standardisiert ist, wird der Wechsel zwischen Datenbanken einfacher, und nahezu jedes Tool kann am Ende dieselbe Menge von Dateien transaktional sicher verarbeiten.
    Während Snowflake zum Beispiel in Dateien schreibt, kann ein Data Scientist in einem Jupyter Notebook in Echtzeit Abfragen ausführen, und ClickHouse kann auf denselben Daten nutzerorientierte Analysen mit Konsistenzgarantien bereitstellen.
    Wenn ein Unternehmen später entscheidet, von Snowflake zu Databricks zu wechseln, ist das dann keine so große Sache mehr.
    Derzeit ist das Abfragen solcher Formate auf S3 noch nicht so schnell wie natives Laden, aber der Marktdruck wird alle Datenbankanbieter zu Performance-Optimierungen zwingen, sodass sie am Ende nahe an die Performance nativ geladener Daten herankommen werden.
    Für Offenheit, Open Source und dafür, dass Unternehmen ihre Daten in offenen und portablen Formaten besitzen, ist das ein großer Gewinn.
    Ein Lakehouse hat dieselben Implikationen. Viele Unternehmen betreiben sowohl einen Data Lake als auch ein Data Warehouse und kopieren Daten zwischen beiden hin und her.
    Nur ein einziges System zu haben, das denselben Datensatz abfragt und verwaltet, hat ebenfalls eine große Wirkung.
    Es ist eine sehr spannende Zeit, im Bereich Data Engineering zu arbeiten.

    • Apache Arrow und Substrait haben daran gearbeitet, diese Realität möglich zu machen.
      Für die Zukunft zeichnet sich ab, dass man bei der Abfrageausführung Ausführungspläne nicht nur an mehrere Engines über die Cloud hinweg, sondern auch an lokale Maschinen schicken kann.
    • Die Annahme, dass alle Datenbankanbieter ihre internen Speicherformate aufgeben und nur noch über die Compute-Schicht konkurrieren werden, ignoriert die Engineering-Infrastruktur und Geschäftsmodelle, die sie über Jahrzehnte aufgebaut haben.
      Snowflake könnte dann vielleicht genauso gut den Betrieb einstellen und den Investoren Milliarden Dollar zurückgeben. Daten im eigenen Ökosystem einzuschließen, ist ihr gesamtes Geschäftsmodell.
      Ich frage mich, ob es gute Beispiele dafür gibt, dass offene Standards Unternehmen dazu gebracht haben, proprietäre Technologien aufzugeben.

  • Der Aussage „Die beste Methode, einen Apache-Arrow-DataFrame als Datei auf der Festplatte zu speichern, ist Feather, und man kann ihn auch in Apache Parquet usw. konvertieren“ stimme ich entschieden nicht zu.
    Wenn man ein nicht-JVM-basiertes Lakehouse direkt bauen will, ist die beste Konfiguration: Iceberg als Metadaten, Parquet als Daten, DuckDB als Query Engine und Abfragen als Arrow-Tabellen.
    Die Kosten, Parquet direkt als Arrow zu lesen, sind sehr niedrig; anschließend kann man es an Arrow→Pandas oder Polars weitergeben. Das geht direkt oder über einen auf Arrow Flight basierenden Dienst.
    Wenn man hier Feather einfügt, funktioniert der aktuelle Python-Lakehouse-Stack insgesamt nicht gut.

    • Eine Zeit lang dachte ich, Feather gebe keine langfristigen Formatgarantien.
      Das kann sich inzwischen geändert haben, aber Parquet fühlt sich weiterhin wie die zukunftssicherste Option an.

  • Von Data Lakes habe ich gehört, aber „Data Lakehouse“ klingt wie ein Ort, an dem Daten der Oberschicht im Sommer mit dem Datenboot zum Datenangeln fahren.

    • Der Name ist leicht zu verspotten, aber ich denke, das zugrunde liegende Problem ist real.
      Viele Unternehmen speichern Daten in einem Data Lake und nutzen ein Warehouse, um BI für Tools wie Tableau oder PowerBI bereitzustellen. Dabei kopieren sie Daten zwischen beiden hin und her.
      Ein Data Lakehouse, das den Lake direkt abfragt und Transaktionen sowie Governance auf einen einzigen Datensatz anwendet, kann den Stack stark vereinfachen und auch Kosten senken.
    • Ich habe ohnehin nie verstanden, was „Data Lake“ außer „Sammlung heterogener großer Datendateien“ bedeuten soll.
    • Namensgebung ist schwierig, und ich hoffe, die Branche findet irgendwann einen besseren Namen.
      Jedes Mal, wenn ich ihn höre oder lese, fühlt er sich in meinem Kopf ziemlich unbeholfen an.

  • Auf Iceberg setze ich besonders große Hoffnungen, weil es Open Source ist.
    Als ich zuletzt nachgesehen habe, gab es allerdings nur eine Spark-Bibliothek als Implementierung, und der Iceberg-Connector von Trino (früher Presto, eine SQL-Engine) hing stark von Hive ab.
    Es wirkte so, als habe die gesamte Branche Schwierigkeiten, sich vom Erbe von MapReduce, Hive und – ich wage es zu sagen – Spark scheiden zu lassen.
    Seitdem habe ich mir Iceberg nicht wieder angesehen, plane das aber bald und hoffe wirklich, dass sich dieser Bereich weiterentwickelt.
    Inzwischen haben wir die Werkzeuge und die Rechenleistung, um Daten auch ohne Legacy-Technologien zu verarbeiten, und nicht alle Daten sind Big Data.
    Zum Glück ähnelt Data Engineering daher immer stärker der normalen Backend-Entwicklung, und gewöhnliche Entwicklungspraktiken setzen sich ebenfalls durch.
    Ich hoffe, dass es in sehr naher Zukunft eine reine Python-Iceberg-Bibliothek geben wird.

    • Trino ist heute bei keinem Data-Lake-Connector mehr von Hadoop/Hive abhängig.
      In die Entfernung dieser Abhängigkeit ist enorm viel Aufwand geflossen.
    • Bei mir war es ähnlich. Ich habe etwa einen Monat Freizeit damit verbracht, den alten Stack so weit hinzubekommen, dass ich einfach Daten einfügen konnte, und endete unzufrieden.
      Databend hatte ich in einer Stunde am Laufen, und ich dachte, dass eine Rust-Implementierung gegenüber Java/Hive portabler wäre und sich künftig leichter ernsthaft nutzen ließe.

  • Ich weiß nicht, warum all das nicht konkreter erklärt wird.
    Ich fände es gut, wenn beschrieben würde, wie die Daten gespeichert werden, wie man sie verbindet und abfragt und wie schnell die Abfragen sind – zum Beispiel der Unterschied zwischen Transaktionsgeschwindigkeit und Geschwindigkeit analytischer Abfragen.

  • Wir verarbeiten derzeit auf GCP rund 100 TB Daten, nutzen BigQuery als Query Engine und verwenden einfaches Hive-Partitioning wie /key3=000/key2=002/
    Wir können alle gewünschten Abfragen ausführen, und die Kosten sind extrem niedrig, daher sind wir zufrieden.
    Allerdings steigt die Latenz inzwischen ziemlich stark, auch wenn das für uns nicht besonders kritisch ist. Trotzdem frage ich mich, ob der Einsatz von Iceberg diesen Punkt verbessern würde.
    Ich würde gern wissen, ob jemand damit Erfahrung hat; insgesamt ist so eine Architektur wirklich großartig.

    • Es gibt eine gute Zusammenfassung zu diesem Thema: der Abschnitt „Optimizing read performance“ in https://aws.amazon.com/blogs/big-data/choosing-an-open-table...
      Der Hauptzweck solcher Technologien ist Datenmanagement in großem Maßstab, sie erweitern aber auch die Funktionen, die ein rohes Speicherformat wie Parquet bietet. Es könnte also helfen, aber man sollte prüfen, ob es wirklich nötig ist.
      Ich habe BigQuery nicht genutzt, aber es könnte ähnliche Funktionen geben.
      Zuerst sollte man definieren, was hier mit „Latenz“ gemeint ist und welches Niveau „ziemlich hoch“ bedeutet.
      Analytische Datenspeicher sind für effiziente Batch-Verarbeitung konzipiert; das Auffinden einzelner Datensätze ist nicht das Hauptziel dieser Architektur. Für schnelle Suche braucht man Caching oder Indexierung.
      In manchen Fällen kann es schon reichen, bei der Suche nach einem einzelnen Datensatz limit 1 hinzuzufügen.
      Man sollte prüfen, ob ein effizientes Datenspeicherformat wie Parquet verwendet wird, und die Dateigrößen kontrollieren, um sicherzustellen, dass kein „Small File Problem“ vorliegt.
      Danach sollte man auch prüfen, ob die passenden BigQuery-Funktionen genutzt werden. Vor und nach solchen Checks sollte man explain für die Abfragen ausführen; wenn keine Partitionsschlüssel oder Indexspalten verwendet werden, liefert auch kein Big-Data-System sofortige Suchergebnisse.
    • Unsere Größenordnung liegt bei etwa einem Zehntel davon, aber bei Datenvisualisierung sind Kunden natürlich ungeduldig, daher ist Query-Geschwindigkeit ein großes Thema.
      Wenn man BigQuery-Tabellen nicht als Input für Berechnungen mit hohem Durchsatz nutzt, würde ich mich darauf konzentrieren, das BI-Tool zu optimieren oder Analytik-Tabellen zu erstellen, die Endnutzer-Latenz vermeiden.
      Zum Beispiel haben wir kürzlich Fact-/Dimension-Table-Joins und COALESCE-Operationen materialisiert, um eine große Tabelle speziell für Analysen zu erstellen.
      Konzeptionell liegt sie zwar „außerhalb“ des normalen Data-Warehouse-Aufbaus, existiert aber in dbt, sodass Datenqualität und Lineage weiterhin erhalten blieben.
      Dadurch konnten wir feste Tableau-Berechnungen entfernen und die Lade-/Gruppierungszeit für Endnutzer um etwa 95 % reduzieren.
    • Wenn ihr nativen BigQuery-Speicher nutzt, wird Iceberg eure Abfragen vermutlich nicht beschleunigen.
      Bei Federated Queries auf GCS/S3 könnte es schneller werden.
    • Falls ein Wechsel zu AWS in Ordnung ist, sieht das ziemlich gut aus: https://www.boilingdata.com/

  • Mir gefällt die Haltung wirklich: „Dieser Artikel ist weder zu 100 % umfassend noch wahrscheinlich der beste Einstiegspunkt für die meisten Leute. Denn ich schreibe ihn für mich selbst. Ich finde, der beste Weg, etwas Neues zu lernen, ist, mich dazu zu zwingen, es jemand anderem wieder zu erklären.“
    Ich habe begonnen, diesen Ansatz auch auf Papier und in den Notizen auf meiner Website zu übernehmen.

  • Ich hatte mich sehr darauf gefreut, tiefer in die Iceberg-Ära stärker verwalteter Parquet-Speicher einzutauchen.
    Aber die Unterstützung für schnelle GPU-I/O (GPUDirect/cuFile) hinkt noch um Jahre hinterher.
    Deshalb stoßen wir jedes Mal an diese Wand, wenn wir es für AI-Workloads zu Kunden bringen wollen.
    Es sieht letztlich nach etwas aus, das passieren wird, und eher nach einer Frage des „wann“ als des „ob“. Es wäre wirklich großartig, wenn man beides zugleich bekommen könnte.

    • Mich würde interessieren, um welchen Use Case es geht. Geht es um das Speichern von Bilddaten?
      Für Textspeicherung reicht Parquet heute aus.
      PyTorch Data Loader und TF Data bieten Multi-Thread-Clients, die parallel vorab lesen, Speicherpuffer füllen und dann Daten mit der GPU austauschen.
      Ich stimme zu, dass S3 hier zum Bottleneck werden kann. Deshalb setzen wir HopsFS als global verteilten, konsistenten NVMe-Cache auf S3 ein.
      Anyscale hat mit einem lokalen NVMe-Cache für S3 etwas Ähnliches gemacht.
      Ein weiteres interessantes Dateiformat ist Lance: Es ist Parquet-ähnlich, aber für Bilddaten gedacht. Es hat zusätzlich einen schnellen Random-I/O-Index, um Bilder innerhalb der Datei zu finden.