Quack, Quack, Ka-Ching: Kosten senken, indem man Snowflake von DuckDB abfragt

Aktualisierung 10/2024: Seit diesem Artikel hat sich viel geändert. Snowflake stellt die Erstellung der version-hint.txt-Datei seit ihrem 2024_05-Bundle ein, wodurch Teile des nachfolgenden Beitrags ungültig werden. Snowflake hat auch Polaris veröffentlicht, was interessant ist, wenn Sie auf Ihre Snowflake-Daten von verschiedenen Engines zugreifen möchten.

Snowflake hat kürzlich umfassende Unterstützung für das offene Tabellenformat Iceberg veröffentlicht. Die Verwendung offener Formate fördert die Datenagilität und reduziert die Abhängigkeit von Anbietern. Dieser Beitrag untersucht, wie diese Flexibilität genutzt werden kann, um die hohen Rechenkosten von Snowflake durch die Verwendung von DuckDB zur Abfrage von von Snowflake verwalteten Daten zu senken.

Was ist Apache Iceberg?

Apache Iceberg ist eine Tabellenformat-Spezifikation, die 2017 von Netflix erstellt wurde. Im Jahr 2018 hat Netflix das Iceberg-Projekt open-source gemacht und es der Apache Software Foundation gespendet.

Netflix hat Iceberg entwickelt, um die Einschränkungen von Datenseen zu überwinden, die einfache partitionierte Daten-Dateien mit minimalen Metadaten enthalten — auch bekannt als Hive-formatierten Tabellen. Dazu gehörten Leistungsprobleme (viele Dateiliste, viele Partitionen, begrenztes Pruning) und das Fehlen von Funktionen, die in Datenlagern üblich geworden sind, wie z.B. Zeitreisen, Schema-Evolution und ACID-Transaktionen.

Tabellenformat-Spezifikation

Eine Tabellenformat-Spezifikation ist eine standardisierte Methode zum Schreiben von Metadaten, um eine Tabelle zu definieren. Metadaten ermöglichen es Tools zu wissen, was sich in einem Datensatz befindet, ohne alle Daten im Inneren lesen zu müssen, aber sie können auch unterschiedliche Bedeutungen für Daten zuweisen — z.B. durch Markierung als nicht aktuell.

Apache Iceberg ist kein Speicherformat. Sie können die Daten Ihrer Iceberg-Tabelle in Formaten wie Parquet, ORC oder Avro speichern; Iceberg ist eine standardisierte Methode, um Metadaten neben diesen Daten-Dateien zu organisieren.

Offene Toolbox und Interoperabilität

Viele Engines und Tools implementieren die Iceberg-Spezifikation. Tools, die dieselbe Spezifikation implementieren, können alle mit denselben Iceberg-Tabellen interagieren, weshalb Apache Iceberg „multi-engine“ ist. Die meisten großen Engines, wie AWS Athena, Trino (Starburst), DuckDB und Snowflake, unterstützen Iceberg.

Dieser interoperable Ansatz unterscheidet sich grundlegend von dem, was in der Vergangenheit üblich war. Datenbanken wie Oracle, Vertica, BigQuery und so weiter speichern Metadaten und Daten in proprietären Formaten, was eine nahtlose Interoperabilität erschwert, viel Datenkopieren erfordert und potenziell zu einer Abhängigkeit von Anbietern führen kann.

Paradigmenwechsel

Durch die Arbeit mit einem zentral zugänglichen Format, das unabhängig von der Rechenmaschine ist, werden Rechenmaschinen austauschbar. Dies ermöglicht es uns, die am besten geeignete Rechenmaschine für eine bestimmte Aufgabe zu nutzen, ohne Daten bewegen zu müssen. Daten, die von einem Tool geschrieben werden, können sofort von einem anderen gelesen werden.

Diese Architektur führt zu einem Paradigmenwechsel, der den Datenaustausch über redundante Daten-Duplikation zwischen verschiedenen Rechenmaschinen begünstigt.

Funktionsreiche Lakehouses

Zusätzlich zur Förderung der Interoperabilität ermöglicht Apache Iceberg eine ständig wachsende Anzahl von Funktionen, die die Funktionslücke zwischen Datenseen und Datenlagern schließen und zu dem führen, was heute als Lakehouse bekannt ist. Dazu gehören Zeitreisen, ACID-Transaktionen, Partitionsentwicklung, versteckte Partitionierung, Schema-Evolution, oder Speicherkosten sparen usw. Dieser Blogbeitrag konzentriert sich ausschließlich auf Interoperabilität.

Apache Iceberg und Snowflake

Am 4. Dezember 2023 hat Snowflake einen Blogbeitrag veröffentlicht, in dem angekündigt wurde, dass ihre Integration von Apache Iceberg in der öffentlichen Vorschau ist.

Snowflake bietet nun zwei Möglichkeiten zur Arbeit mit Iceberg-Tabellen:

• Externes Katalog. Diese Tabellen werden extern, von einem Tool wie Apache Spark, Apache Flink oder sogar Trino, in Ihrem Objektspeicher geschrieben und in einem externen Katalog wie dem Hive Metastore, dem AWS Glue Data Catalog oder Nessie registriert. In diesem Modus sind die Tabellen von Snowflake aus schreibgeschützt.

• Snowflake-Katalog. Diese Tabellen sind von Snowflake aus les- und schreibbar und extern schreibgeschützt.

In beiden Fällen speichert Snowflake alle Daten und Iceberg-Metadaten in Ihrem eigenen (Cloud-)Objektspeicher. Beide Arbeitsweisen mit Iceberg haben Vorteile. Angesichts Ihrer Situation sollte klar sein, welche die angemessenste ist.

Alle Daten und Iceberg-Metadaten befinden sich in Ihrem eigenen (Cloud-)Objektspeicher.

Bei der Verwendung von Iceberg-Tabellen mit dem Snowflake-Katalog verhält sich Snowflake wie gewohnt; es bleibt ein „Zero-Ops“-Lager, und Sie können sorglos bleiben, während Snowflake Wartungsoperationen wie Komprimierung, Ablaufen von Snapshots und das Aufräumen von verwaisten Dateien durchführt. Iceberg-Tabellen verhalten sich fast identisch wie native Snowflake-Tabellen, obwohl es einige Einschränkungen gibt, die Sie überprüfen sollten.

Dieser Beitrag geht davon aus, dass Ihre Daten in Snowflake leben und gedeihen und dass Snowflake der Ort ist, an dem Ihre großangelegte Verarbeitung erfolgt. Die Verwendung des Snowflake-Katalogs ist daher die richtige Wahl.

Iceberg-Katalog

Bei der Verwendung von Iceberg-Tabellen mit dem Snowflake-Katalog bleibt der „Katalog“ auf der Seite von Snowflake. Um zu bestimmen, ob dies unsere Fähigkeit einschränkt, direkt mit Daten zu interagieren, sollten wir wissen, was der Metadatenkatalog tut; schließlich wird die Metadaten eines Tisches nicht in den Metadatendateien von Iceberg gespeichert? Kataloge bieten mindestens zwei Dinge:

• Datenbank-Abstraktion. Iceberg ist eine Spezifikation für technische Metadaten auf Tabellenebene, und Iceberg-Metadatendateien werden neben Ihren Datendateien gespeichert. Die Tabellen-Spezifikation ist sich keine Begriffe wie Tabellennamen, Schemata und Datenbanken oder Sammlungen bewusst. Ein Metadatenkatalog ermöglicht es Ihnen, Ihr „Pakete an Tabellen“ als Datenbank zu betrachten, indem er eine Hierarchie einführt und eine Karte von Tabellennamen auf Präfixe speichert.

• Zeiger auf die aktuelle Tabellenversion. Wenn eine Iceberg-Tabelle verändert wird, werden neue Daten- und Metadatendateien hinzugefügt und neben den alten gespeichert. Der Katalog verfolgt die Tabellen-Präfixe, muss aber auch wissen, welche Metadatendateien „aktuell“ sind.

Zusammengefasst: Sie benötigen Zugriff auf den Katalog, um zu wissen, welche Tabellenversion aktuell ist, und um Tabellen nach Namen zuzugreifen und Abfragen so zu schreiben, wie Sie es gewohnt sind.

Iceberg-Katalog SDK

Wenn Sie Ihre Iceberg-Tabellen mit Spark lesen möchten, haben Sie Glück! Snowflake hat ein Iceberg-Katalog-SDK für Spark veröffentlicht, das die Katalogschnittstelle von Spark mithilfe einer (ansonsten undocumented) Snowflake-Katalog-API implementiert. Derzeit ist diese Snowflake-Funktionalität kostenlos und erfordert kein laufendes Lager, verursacht keine „serverless credits“ oder „Cloud-Dienste“-Kosten.

Snowflakes Ankündigung enthält sofort verwendbaren Beispielcode und bestätigt, dass Spark Iceberg-Metadaten und Parquet-Dateien direkt aus dem vom Kunden verwalteten Speicherkonto liest:

Nachdem Sie eine erste Verbindung zu Snowflake über das Iceberg-Katalog-SDK hergestellt haben, kann Spark Iceberg-Metadaten und Parquet-Dateien direkt aus dem vom Kunden verwalteten Speicherkonto lesen. Mit dieser Konfiguration können mehrere Engines konsistent aus einer einzigen Kopie von Daten lesen.

Leider ist dies nicht sofort hilfreich, um aus DuckDB abzufragen. Es gibt kein Snowflake-Katalog-SDK für DuckDB. Zum Glück können wir das Dateisystem direkt verwenden, um unsere Daten zu lesen.

Iceberg-Dateisystem-Katalog

Wenn es möglich erscheint, einen Katalog über ein Dateisystem oder ein Objektspeicher durch einfache Namenskonventionen zu implementieren, ist das auch der Fall! Tatsächlich ist Iceberg's Hadoop Katalog genau das. Seine Klassendokumentation lautet:

HadoopCatalog […] verwendet ein angegebenes Verzeichnis unter einem angegebenen Dateisystem als das Lagerverzeichnis und organisiert mehrere Verzeichnisebenen, die der Datenbank, dem Namensraum und der Tabelle zugeordnet sind. Der HadoopCatalog nimmt einen Standort als Lagerverzeichnis. Wenn eine Tabelle wie $db.$tbl erstellt wird, wird das Verzeichnis $db/$tbl im Lagerverzeichnis erstellt, und die Tabellendaten werden in diesem Verzeichnis abgelegt.

Damit Iceberg weiß, welche Metadaten die neuesten sind, erwartet es, dass die Metadatendateien der Tabelle im Dateisystem nach einer Funktion monoton wachsender Versionsnummern benannt werden. Es sucht auch nach einer optionalen version-hint.text-Datei, die auf die neueste Version verweist.

Hinweis: Autoren halten Konsistenz und monoton wachsende Versionen aufrecht, indem sie das hier dokumentierte Schema implementieren hier. Leider erfordert dies, dass Speichersysteme atomare Umbenennungen unterstützen, was viele Speicher-Engines, insbesondere S3, Google Cloud Storage und Azure Blob Storage, nicht tun. Dies ist einer der Gründe, warum einer der ursprünglichen Autoren von Iceberg, Ryan Blue, die Erstellung von Hadoop-Tabellen als „einen seiner größten Fehler“ bezeichnet hat. Selbst bei Speichersystemen, die atomare Umbenennungen unterstützen, kann die Leistung geringer sein als bei Verwendung eines „e proper“ Metadatenkatalogs. Die Verwendung von HadoopCatalog wird im Allgemeinen für die Produktion abgeraten.

Snowflake nutzt vermutlich eine proprietäre, hochleistungsfähige Katalogimplementierung in seinem Backend. Es ist jedoch nett genug, Daten und Metadaten im vom Kunden verwalteten Objektspeicher in einer für den Hadoop-Katalog kompatiblen Weise zu materialisieren — sie halten sogar eine aktuelle version-hint.text-Datei! Diese Kompatibilität bedeutet, dass jeder Leser, der den Iceberg-Hadoop-Katalog unterstützt, Snowflake-Daten direkt lesen kann, indem er auf den Root des Iceberg-Lagers im Objektspeichers verweist.

DuckDB

DuckDB hat teilweise Unterstützung für den Iceberg-Hadoop-Katalog und die Dateisystem-Tabellen. Während DuckDB leider (noch?) nicht unterstützt, ein ganzes Lager zu lesen, können Sie es auf ein Tabellenpräfix hinweisen. DuckDB wird dann die version-hint.text-Datei aufnehmen und die neueste Version der Tabelle lesen.

Erstellen einer Iceberg-Tabelle

Snowflake dazu zu bringen, eine Iceberg-Tabelle in Ihrer Cloud zu erstellen, erfordert einige Konfiguration. Das folgende Beispiel verwendet S3 als Speicherschicht, aber Snowflake unterstützt auch Google Cloud Storage und Azure Storage. Hier finden Sie ein Playbook für S3:

Auf hoher Ebene muss Folgendes erfolgen:

• Speicher bereitstellen: Erstellen Sie einen S3-Bucket und eine IAM-Rolle für Snowflake und stellen Sie sicher, dass die IAM-Rolle die erforderlichen Berechtigungen zum Zugriff auf den Bucket hat.

• Snowflake mit dem Speicher verbinden: Erstellen Sie ein Snowflake Externes Volume. Im Fall von S3 erstellt ein externes Volume einen IAM-Benutzer auf Snowflakes Konto. Sie müssen eine Vertrauensbeziehung schaffen, damit dieser IAM-Benutzer die Rolle mit Zugriff auf Ihren S3-Bucket übernehmen kann.

Wir können endlich native Iceberg-Tabellen in Snowflake mit CREATE ICEBERG TABLE erstellen, und Sie finden Ihre Parquet- und Iceberg-Metadatendateien im S3-Bucket.

Daten aus DuckDB lesen

Nachdem wir eine sichere Verbindung zwischen S3 und Snowflake hergestellt und Iceberg-Tabellen in Snowflake erstellt haben, wollen wir — schließlich — sehen, wie DuckDB das Abfragen dieser Tabellen erleichtert.

Wir verwenden DuckDB's Iceberg-Erweiterung, um die Iceberg-Tabellen, die wir in Snowflake erstellt haben, direkt aus S3 zu lesen. Wiederum finden Sie das Playbook hier. Die Hauptfunktionalität wird durch die folgende iceberg_scan-Methode bereitgestellt:

select * from iceberg_scan('s3://chapter-platform-iceberg/icebergs/line_item';)
Die iceberg_scan-Methode ruft die Tabellen aus S3 ab. Sie müssen nicht explizit auf die aktuelle manifest.json-Datei zeigen, da die version-hint.text auf die aktuelle Version der Tabellen verweist.

Wir haben nun die wahre Stärke offener Tabellenformate entfesselt: Wir haben den Komfort von Snowflake und seinem Katalog, können aber Kosten sparen, indem wir Single-Node-Abfragen auf DuckDB durchführen.

Aktuell unterstützt DuckDB das Schreiben von Iceberg-Tabellen nicht — nur das Lesen. Sie können jedoch in Parquet schreiben, z.B. nach S3 mit COPY <table_name> TO 's3://bucket/file.parquet';. Selbst wenn DuckDB Iceberg- Schreibvorgänge unterstützen würde, würde Snowflake dies nicht tun — obwohl Sie die Ausgaben von DuckDB als Iceberg-Tabelle mit externem Katalog in Snowflake registrieren könnten.

Warum macht Snowflake das?

Wenn die Verwendung von Iceberg-Tabellen in Snowflake ein wenig wie Kuchenessen und Kleingeld geht, wobei Snowflake die Rechnung trägt, warum hat Snowflake dann diese Integration aufgebaut? Der Schritt macht im Kontext des heftigen Wettbewerbs durch Databricks Sinn. Beide Giganten versuchen, ihre Systeme zu öffnen, um Kunden zu gewinnen.

Snowflake sendet die Botschaft an seine (potenziellen) Kunden, dass die Wahl von Snowflake sie nicht an einen Anbieter bindet und dass es keine Risiko von Lock-in gibt; bei ihnen haben Sie immer die Möglichkeit, die Rechenmaschinen zu wechseln, wann Sie wollen. Databricks verhält sich ähnlich, indem es sein Delta-Lake-Format öffnet und Hudi und Iceberg besser über UniForm unterstützt.

Snowflake möchte weiterhin so viel Rechenleistung wie möglich in ihren Systemen halten. Es gibt einen klaren Weg, um externe Metadaten in den Iceberg-Katalog zu verschieben, aber in die andere Richtung ist es viel herausfordernder. Durch das Besitzen des Metadatenkatalogs bleibt Snowflake die gewählte Rechenmaschine und der einzige Schreiber. Hätte Snowflake seine Systeme nicht geöffnet, hätte es wahrscheinlich viele Kunden verloren, die Angst vor Lock-in hatten.

Fazit

Offene Tabellenformate wie Iceberg ermöglichen eine echte Trennung von Rechenleistung und Speicherung. Durch die Verwendung der Iceberg-Tabellen von Snowflake können Sie weiterhin von Snowflakes leistungsstarken und operationsfreien Fähigkeiten profitieren und gleichzeitig gelegentlich aus ihrem "umzäunten Garten" entkommen. Da Iceberg mit Parquet Eigenschaften und Funktionen hat, die denen der nativen Snowflake-Tabellen sehr ähnlich sind — wie effiziente Kompression, Partition-Pruning, Schema-Evolution usw. — und da Snowflake Unterstützung für sie implementiert hat, sollten Sie in der Lage sein, Iceberg-Tabellen anstelle von nativen Tabellen ohne signifikante Auswirkungen auf die Leistung oder Funktionalität zu verwenden. Wir empfehlen daher, standardmäßig Iceberg-Tabellen mit Snowflake zu verwenden.

Dieser Beitrag hat gezeigt, wie einfach es ist, eine Abfrage auf DuckDB anstelle auf teuren Snowflake-Rechenressourcen auszuführen, indem direkt auf von Snowflake verwaltete Daten in Ihrem eigenen Objektspeicher verwiesen wird. Dort können Sie sogar Daten kombinieren, die in Ihrem Snowflake-Lager nicht verfügbar sind. Wissen, dass Sie DuckDB von Instanzen aus betreiben können, die etwa 10% der Kosten eines vergleichbar leistungsstarken Snowflake-Lagers haben, kann erhebliche Kosteneinsparungen bringen. Natürlich soll dies nicht bedeuten, dass DuckDB ein Ersatz für Snowflake ist. Wir denken, dass dies eine gute Demonstration der Kraft der Interoperabilität ist.

Dieser Beitrag ist das Ergebnis einer Zusammenarbeit von

Jelle De Vleminck, Robbert, Moenes Bensoussia und Jonathan Merlevede

• 👏 Wenn Ihnen dieser Artikel gefallen hat, vergessen Sie nicht, zu klatschen

• 🗣️ Teilen Sie Ihre Gedanken in den Kommentaren; wir werden versuchen zu antworten

• 🗞️ Folgen Sie mir und abonnieren Sie datamindedbe für weitere Beiträge über Cloud-, Plattform-, Daten- und Software-Engineering.

• 👀 Für weitere Informationen über Data Minded besuchen Sie unsere Website.