AWS Germany – Amazon Web Services in Deutschland

Neu – Amazon S3 Tables: Optimierter Speicher für Analytics Workloads

Von Jeff Barr, übersetzt von Franz Stefan

Amazon S3 Tables bieten Ihnen einen Speicher, welcher für tabellarische Daten wie etwa tägliche Kauftransaktionen, Streaming-Sensordaten und Werbeeinblendungen im Apache Iceberg-Format optimiert ist. Dies ist unter anderm für einfache Abfragen mit beliebten Abfrage-Engines wie Amazon Athena Amazon EMR und Apache Spark von Interesse.

Im Vergleich zu einem selbstverwalteten Tabellenspeicher, können Sie eine bis zu 3-mal schnellere Abfrageleistung und bis zu 10-mal mehr Transaktionen pro Sekunde erwarten. Zusätzlich erhalten Sie die betrieblichen Effizienz, die bei der Nutzung eines vollständig verwalteten Dienstes selbstverständlich ist.

Iceberg ist zur beliebtesten Methode für die Verwaltung von Parquet Dateien geworden. Tausende AWS-Kunden verwenden Iceberg um Abfragen über Millarden von Dateien durchzuführen. Diese Dateien können Petabytes oder sogar Exabytes an Daten enthalten.

Tabellen-Buckets, Tabellen und Namensräume

Tabellen-Buckets sind eine weitere Art von S3-Buckets und nehmen ihren Platz neben den bestehenden Allzweck-Buckets und Verzeichnis-Buckets ein. Sie können sich ein Tabellen-Bucket als analytisches Warehouse vorstellen, welches Iceberg-Tabellen mit verschiedenen Schemata speichern kann. Des weiteren bieten S3 Tables die gleiche Haltbarkeit, Verfügbarkeit, Skalierbarkeit und Leistungsmerkmale wie Amazon S3 selbst. Darüber hinaus optimieren Sie automatisch Ihren Speicher, um die Abfrageleistung zu maximieren und die Kosten zu minimieren. Jedes Tabellen-Bucket befindet sich in einer bestimmten AWS-Region und hat einen Namen, der innerhalb des AWS-Kontos in Bezug auf die Region eindeutig sein muss. Buckets werden durch ARN referenziert und haben eine Ressourcenrichtlinie. Schließlich verwendet jedes Bucket Namespaces, um die Tabellen im Bucket logisch zu gruppieren.

Tabellen sind strukturierte Datensätze, die in einem Tabellen-Bucket gespeichert sind. Wie Tabellen-Buckets haben sie ARNs und Ressourcenrichtlinien und existieren innerhalb eines der Namespaces des Buckets. Tabellen werden vollständig verwaltet, mit automatischer, konfigurierbarer kontinuierlicher Wartung einschließlich Komprimierung, Verwaltung gealterter Snapshots und Entfernung nicht referenzierter Dateien. Jede Tabelle verfügt über einen S3-API-Endpunkt für Speichervorgänge.

Namespaces können aus Zugriffsrichtlinien heraus referenziert werden, um die Zugriffsverwaltung zu vereinfachen.

Buckets und Tabellen von der Kommandozeile

Okay, lassen Sie uns direkt eintauchen, ein Bucket erstellen und ein oder zwei Tabellen darin platzieren. Ich werde das AWS Command Line Interface (AWS CLI) verwenden, aber die AWS Management Console und API-Unterstützung sind ebenfalls verfügbar. Der Einfachheit halber werde ich die Ausgabe der ausführlicheren Befehle durch jq leiten und Ihnen nur die relevantesten Werte zeigen.

Der erste Schritt besteht darin, ein Tabellen-Bucket zu erstellen:

$ aws s3tables create-table-bucket --name jbarr-table-bucket-2 | jq .arn
"arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2"
Bash

Der Einfachheit halber erstelle ich eine Umgebungsvariable mit dem ARN des Tabellen-Buckets:

$ export ARN="arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2"
Bash

Und dann liste ich meine Tabellen-Buckets auf:

$ aws s3tables list-table-buckets | jq .tableBuckets[].arn
"arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1"
"arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2"
Bash

Ich kann auf verschiedene Weise auf die Tabelle zugreifen und diese befüllen. Zu Testzwecken habe ich Apache Spark installiert und dann die Spark-Shell mit Kommandozeilenargumenten aufgerufen. In einem nächsten Schritt möchte ich das Paket Amazon S3 Tables Catalog for Apache Iceberg verwenden und spark.s3.tableBucketArnmytablebucket auf eine ARN meines Tabellen-Buckets setzen.

Ich erstelle einen Namensraum mydata, den ich zur Gruppierung meiner Tabellen verwenden werde:

scala> spark.sql("""CREATE NAMESPACE IF NOT EXISTS mytablebucket.mydata""")

Dann erstelle ich eine einfache Iceberg-Tabelle im Namensraum:
spark.sql("""CREATE TABLE IF NOT EXISTS mytablebucket.mydata.table1
 (id INT,
  name STRING,
  value INT)
  USING iceberg
  """)
SQL

Ich verwende einige SHOWs3tables-Befehle, um meine Arbeit zu überprüfen:

$ aws s3tables list-namespaces --table-bucket-arn $ARN | jq .namespaces[].namespace[] 
"mydata"
$
$ aws s3tables list-tables --table-bucket-arn $ARN | jq .tables[].name
"table1"
Bash

Dann kehre ich zur Spark-Shell zurück und füge meiner Tabelle einige Datenzeilen hinzu:

spark.sql("""INSERT INTO mytablebucket.mydata.table1
  VALUES
  (1, 'Jeff', 100),
  (2, 'Carmen', 200),
  (3, 'Stephen', 300),
  (4, 'Andy', 400),
  (5, 'Tina', 500),
  (6, 'Bianca', 600),
  (7, 'Grace', 700)
  """)
SQL

Buckets und Tabellen aus der Konsole
Ich kann Tabellen-Buckets auch mit der S3-Konsole erstellen und bearbeiten. Ich klicke auf Tabellen-Buckets (Table buckets), um zu beginnen:

Bevor ich mein erstes Bucket erstelle, klicke ich auf Integration aktivieren (Enable integration), damit ich auf meine Tabellen-Buckets mittels Amazon Athena, Amazon Redshift, Amazon EMR und anderen AWS-Abfrage-Engines zugreifen kann (ich kann dies später ändern, wenn ich es jetzt nicht mache):

Ich lese das Kleingedruckte und klicke auf Integration aktivieren (Enable integration), um die angegebene IAM-Rolle und einen Eintrag im AWS Glue Data Catalog zu erstellen:

Nach ein paar Sekunden ist die Integration aktiviert und ich klicke auf Tabellen-Bucket erstellen (Create table bucket), um fortzufahren:

Ich gebe einen Namen ein (jbarr-table-bucket-3) und klicke auf Tabellen-Bucket erstellen (Create table bucket):

Von hier aus kann ich Tabellen erstellen und verwenden, wie ich es Ihnen zuvor im CLI-Abschnitt gezeigt habe.

Tabellenwartung
Tabellen-Buckets übernehmen einige wichtige Wartungsaufgaben, die in Ihrer Verantwortung lägen, wenn Sie Ihre eigenen Iceberg-Tabellen erstellen und verwalten würden. Um Sie von diesen Pflichten zu entlasten und Sie damit mehr Zeit für Ihre Tabelle haben, werden die folgenden Wartungsoperationen automatisch durchgeführt:

Komprimierung – Dieser Prozess kombiniert mehrere kleine Tabellenobjekte zu einem größeren Objekt, um die Abfrageleistung zu verbessern. Dabei wird eine Zieldateigröße angestrebt, die zwischen 64 MiB und 512 MiB konfiguriert werden kann. Das neue Objekt wird als neuer Snapshot neu geschrieben.

Snapshot-Verwaltung – Dieser Prozess lässt Tabellen-Snapshots ablaufen und entfernt sie letztendlich. Es gibt Konfigurationsoptionen für die Mindestanzahl der zu behaltenden Snapshots und das maximale Alter eines zu behaltenden Snapshots. Abgelaufene Snapshots werden als nicht aktuell markiert und später nach einer festgelegten Anzahl von Tagen gelöscht.

Entfernung nicht referenzierter Dateien – Dieser Prozess entfernt und löscht Objekte, die von keinem Tabellen-Snapshot referenziert werden.

Wissenswerte Dinge
Hier sind einige wichtige Dinge, die Sie über Tabellen-Buckets und Tabellen wissen sollten:

AWS-Integration – Die Integration von S3-Tabellen mit dem AWS Glue Data Catalog befindet sich in der Vorschau und ermöglicht Ihnen, Daten mit AWS Analytics-Diensten wie Amazon Athena, Amazon Redshift, Amazon EMR und Amazon QuickSight abzufragen und zu visualisieren.

S3-API-Unterstützung – Tabellen-Buckets unterstützen relevante S3-API-Funktionen einschließlich GetObject, HeadObject, PutObject und die Multipart-Upload-Operationen.

Sicherheit – Alle in Tabellen-Buckets gespeicherten Objekte werden automatisch verschlüsselt. Tabellen-Buckets sind so konfiguriert, dass sie Block Public Access erzwingen.

Preisgestaltung – Sie zahlen für Speicher, Anfragen, eine Objektüberwachungsgebühr und Gebühren für die Komprimierung. Weitere Informationen finden Sie auf der Seite S3-Preisgestaltung.

Regionen – Sie können die neue Funktion in den AWS-Regionen US East (Ohio, N. Virginia) und US West (Oregon) nutzen.

Jeff Barr
Jeff Barr ist AWS Chief Evangelist. Er startete diesen Blog in 2004 and schreibt seitdem fast ununterbrochen Beiträge.