Einschränkungen und Überlegungen

Durch die Integration von Spark und Hive in den Lakehouse-Laufzeitkatalog wird der Betriebsaufwand für die Wartung eines selbst gehosteten Hive-Metastores (HMS) reduziert. Gleichzeitig wird die einheitliche Metadatenfreigabe und direkte Tabellenabfragen in BigQuery ermöglicht.

In diesem Dokument werden die funktionalen Einschränkungen und Dienstüberlegungen dieser Integration erläutert. Bevor Sie Ihre Open-Source-Datenbankpipelines in den Lakehouse-Laufzeitkatalog migrieren oder darauf aufbauen, sollten Sie diese Einschränkungen prüfen, um festzustellen, ob diese Vorschau Ihren technischen Anforderungen entspricht.

Wenn Sie anstelle von Limits Konfigurations- und Abfrageanleitungen suchen, siehe Spark und Hive mit dem Lakehouse-Laufzeitkatalog verwenden.

Einschränkungen des Lakehouse-Laufzeitkatalogs

In diesem Abschnitt werden die Einschränkungen bei der Verwendung des Lakehouse-Laufzeitkatalogs mit verschiedenen Diensten aufgeführt.

Metastore-Einschränkungen

• Managed Service for Apache Spark unterstützt nur PySpark-Jobs mit Lakehouse Metastore.
• Mit der Dataproc API können keine Lakehouse Metastore-Attribute im Feld properties festgelegt werden.
• Sie können keine Managed Service for Apache Spark-Cluster erstellen, die Kerberos verwenden, da der Lakehouse-Laufzeitkatalog keine APIs für Delegierungstoken oder Primärschlüssel unterstützt.
• Für Datenbanken und Tabellen kann ein Cloud Storage-location_uri verwendet werden, der sich von ihrem Hive-Katalog unterscheidet, sofern sich der Cloud Storage-Bucket in derselben Region wie der Hive-Katalog befindet.
• Der Hive-Katalog darf keine Iceberg-Namespaces und -Tabellen enthalten. Verwenden Sie stattdessen den Lakehouse-Laufzeitkatalog, um Iceberg-Namespaces und -Tabellen zu erstellen und zu verwenden.

Tabelleneinschränkungen

• Das Umbenennen von Tabellen wird nicht unterstützt.
• Das Umbenennen von Partitionen wird nicht unterstützt.
• Wenn Sie Tabellen oder Datenbanken löschen, werden die zugehörigen Dateien nicht aus Cloud Storage entfernt.
• Die Suche ohne Berücksichtigung der Groß-/Kleinschreibung wird nicht unterstützt.
• Clustering und Bucketing werden nicht unterstützt.

Batchgröße für Partitionen

Der Lakehouse-Laufzeitkatalog unterstützt das Speichern und Abrufen von Partitionierungsinformationen zur Verwendung bei der Partitionierung. Er ist für Lesevorgänge über Schreibvorgänge optimiert, was durch die Partitionierung zu einer schnelleren Abfrageleistung führt.

Um die Leistung bei der Aufnahme von Partitionen zu optimieren, ist die Batch-Partitionsgröße auf 900 begrenzt.

Legen Sie die folgende Konfiguration für die Hive- und Spark-Attribute fest, die die Batchgröße von Partitionierungsvorgängen bestimmen:

• SET hive.msck.repair.batch.size = 900;
• SET spark.sql.addPartitionInBatch.size = 900;

BigQuery-Einschränkungen

• Standardmäßig werden in BigQuery die Datentypen ARRAY<ARRAY<>> oder ARRAY<MAP<>> nicht unterstützt. Die Unterstützung für MAP muss einer Zulassungsliste hinzugefügt werden. Wenden Sie sich an biglake-help@google.com, wenn Ihre Arbeitslasten MAP häufig verwenden.
• MAP-Schlüsseltypen unterstützen nur primitive Datentypen. Sie können ARRAY, STRUCT oder MAP nicht als Schlüsseltypen verwenden.
• Während der Vorschau kann BigQuery nur Daten aus Cloud Storage abfragen. Es gelten die folgenden Einschränkungen:
  • Tabellenstandort-URIs dürfen kein Platzhalterzeichen (*) enthalten.
  • Tabellenstandort-URIs müssen Verzeichnisse sein.

Einschränkungen bei der regionsübergreifenden Replikation und Notfallwiederherstellung

Der Lakehouse-Laufzeitkatalog bietet regionsübergreifende Replikation und Notfallwiederherstellung, um die Verfügbarkeit und Ausfallsicherheit Ihres Katalogs zu verbessern.

Bei Verwendung des Lakehouse-Laufzeitkatalogs mit Hive-Katalogen gelten die folgenden Einschränkungen:

• Hive-Kataloge bieten keine vollständigen Funktionen zur Notfallwiederherstellung, z. B. vom Nutzer initiierte Failover.

• Wenn Sie einen Hive-Katalog erstellen, müssen Sie primary_location so festlegen, dass er mit der Region Ihres Cloud Storage-Bucket übereinstimmt. Der Lakehouse-Laufzeitkatalog kopiert die Metadaten dann automatisch in eine sekundäre Region, basierend auf der Konfiguration mit zwei Regionen oder mehreren Regionen Ihres Buckets. Diese sekundäre Metadatenkopie ist schreibgeschützt und kann nicht zur primären Kopie hochgestuft werden. Die Datenredundanz hängt von den Einstellungen für zwei Regionen oder mehrere Regionen Ihres Buckets ab und ist unabhängig von der Metadatenreplikation des Lakehouse-Laufzeitkatalogs.

Überlegungen zur Verwendung des Lakehouse-Laufzeitkatalogs als Ersatz für Hive Metastore

Die Vorschauversion des Lakehouse-Laufzeitkatalogs unterstützt eine Teilmenge der Hive Metastore-Schnittstelle. Bei diesem Design wird die Kompatibilität mit dem Spark-ExternalCatalog priorisiert, für das keine vollständige Kompatibilität mit Hive Metastore erforderlich ist.

Ressourcenzuordnung

In der folgenden Tabelle werden Hive Metastore-Ressourcen den Lakehouse-Laufzeitkatalogressourcen und den erforderlichen IAM-Berechtigungen (Identity and Access Management) zugeordnet.

Governance

Der Hive Metastore (HMS) bietet Governance auf Tabellen-, Spalten- und Partitionsebene. Der Lakehouse-Laufzeitkatalog bietet IAM-Berechtigungen auf Tabellen- und Partitionsebene. Governance auf Spaltenebene wird nicht unterstützt.

Speichereinschränkungen

• Alle Einschränkungen für externe BigQuery-Tabellen gelten.

Partitionseinschränkungen

• Das Tracking von Statistiken auf Spaltenebene auf Partitionsebene wird nicht unterstützt.
• Die BatchCreateHivePartitions API beschränkt Aufrufe auf 900 Partitionen.

Nächste Schritte

• Spark und Hive mit dem Lakehouse-Laufzeitkatalog verwenden.