Einschränkungen und Überlegungen

Durch die Integration von Spark und Hive in den Lakehouse-Laufzeitkatalog wird der Betriebsaufwand für die Verwaltung eines selbst gehosteten Hive-Metastores (HMS) reduziert. Gleichzeitig wird die gemeinsame Nutzung einheitlicher Metadaten und direkter Tabellenabfragen in BigQuery ermöglicht.

In diesem Dokument werden die funktionalen Einschränkungen und Service-Überlegungen dieser Integration beschrieben. Bevor Sie Ihre Open-Source-Datenbankpipelines in den Lakehouse-Laufzeitkatalog migrieren oder dort erstellen, sollten Sie sich diese Einschränkungen ansehen, um festzustellen, ob diese Vorschau Ihren technischen Anforderungen entspricht.

Wenn Sie statt Einschränkungen Konfigurations- und Abfrageanleitungen suchen, lesen Sie den Abschnitt 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.
  • Die Dataproc API unterstützt das Festlegen von Lakehouse Metastore-Properties im Feld properties nicht.
  • Sie können keine Managed Service for Apache Spark-Cluster erstellen, die Kerberos verwenden, da der Lakehouse-Laufzeitkatalog keine APIs für Delegierungstokens oder Primärschlüssel unterstützt.
  • Für Datenbanken und Tabellen kann ein Cloud Storage-location_uri verwendet werden, das sich von ihrem Hive-Katalog unterscheidet, sofern sich der Cloud Storage-Bucket in derselben Region wie der Hive-Katalog befindet.

Tabellenbeschrä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 beim Partition Pruning. Sie ist für Lesevorgänge optimiert, was zu einer schnelleren Abfrageleistung durch das Entfernen von Partitionen führt.

Um die Leistung bei der Aufnahme von Partitionen zu optimieren, ist die Batchpartitionsgröß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 die Datentypen ARRAY<ARRAY<>> und ARRAY<MAP<>> in BigQuery 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 intensiv nutzen.
  • MAP-Schlüsseltypen unterstützen nur primitive Datentypen. ARRAY, STRUCT oder MAP können nicht als Schlüsseltypen verwendet werden.
  • Während der Vorschau kann BigQuery nur Daten aus Cloud Storage abfragen. Es gelten die folgenden Einschränkungen:
    • Tabellenstandort-URIs dürfen keinen Platzhalter (*) enthalten.
    • Tabellen-URI-Speicherorte müssen Verzeichnisse sein.

Einschränkungen bei der regionsübergreifenden Replikation und Notfallwiederherstellung

Der Lakehouse-Laufzeitkatalog bietet regionenü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. ein vom Nutzer initiiertes 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 des Buckets mit zwei oder mehreren Regionen. 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 die biregionale oder multiregionale Konfiguration Ihres Buckets ab. Diese ist unabhängig von der Replikation von Lakehouse-Laufzeitkatalog-Metadaten.

Ü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 Spark ExternalCatalog priorisiert, für die keine vollständige Kompatibilität mit dem 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.

Hive-Metastore-Ressource Lakehouse-Laufzeitkatalogressource IAM-Berechtigung
Katalog Katalog biglake.catalogs.*
Datenbank Datenbank biglake.namespaces.*
Tabelle Tabelle biglake.tables.*

Governance

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

Speicherbegrenzungen

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

Einschränkungen für Partitionen

  • Das Erfassen von Statistiken auf Spaltenebene auf Partitionsebene wird nicht unterstützt.
  • Die BatchCreateHivePartitions API begrenzt Aufrufe auf 900 Partitionen.

Nächste Schritte