Wenn Sie die grundlegende Terminologie für grenzenlose Lakehouses kennen, können Sie Lakehouse-Architekturen besser bewerten und Kataloge, Tabellen, Abfrage-Engines und Governance in Google Cloudkonfigurieren. In jedem Eintrag wird ein wichtiges Konzept definiert, das in der gesamten Lakehouse-Dokumentation verwendet wird, und es wird auf detaillierte Anleitungen verwiesen. Eine End-to-End-Ansicht, wie diese Komponenten zusammenpassen, finden Sie unter Funktionsweise von Borderless Lakehouse.
Lakehouse-Grundlagen
Die folgenden Konzepte bilden die Grundlage der Lakehouse-Architektur von Google Cloud.
Data Lakehouse
Ein Data Lakehouse kombiniert die Kosteneinsparungen und die Flexibilität eines Data Lake mit der Datenverwaltung und der Leistung eines Data Warehouse. Sie können damit Daten in offenen Formaten in Cloud Storage speichern und BigQuery-Features wie präzise Sicherheitskontrollen und schnelle Abfragen verwenden.
Medaillon-Architektur
Ein gängiges Designmuster in einem Data Lakehouse ist die Medallion-Architektur, bei der Daten logisch in progressive Ebenen von Struktur und Qualität organisiert werden:
- Bronze-Ebene (Rohdaten): Nimmt Rohdaten auf und speichert sie in offenen Formaten wie Apache Iceberg in Cloud Storage.
- Silber-Ebene (bereinigt): Bereinigt, filtert und reichert die Rohdaten in standardisierten Tabellen an.
- Gold-Ebene (ausgewählt): Liefert vollständig ausgewählte, aggregierte Tabellen auf Geschäftsebene. BigQuery wird häufig verwendet, um die Gold-Ebene für leistungsstarke Nutzung, Berichterstellung und Analysen bereitzustellen.
Offene Interoperabilität
Offene Interoperabilität ist die Fähigkeit mehrerer Analyse- und Transaktionssysteme wie BigQuery, Apache Spark, Apache Flink und Trino, mit einer einzigen Kopie von Daten in offenen Formaten wie Apache Iceberg zu arbeiten. Dadurch entfällt die Notwendigkeit der Datenduplizierung und es wird eine konsistente Ansicht der Daten über alle Tools hinweg ermöglicht.
Lakehouse-Laufzeitkatalog
Der Lakehouse-Laufzeitkatalog ist ein zentraler, serverloser Metadatendienst, der als einzige verlässliche Informationsquelle für das Lakehouse von Google Cloud dient. Er ermöglicht es mehreren Engines wie Apache Spark, Apache Flink, Trino und BigQuery, dieselben Tabellen gleichzeitig zu erkennen und abzufragen. Engines stellen über Katalogendpunkte eine Verbindung her. Weitere Informationen finden Sie unter Informationen zum Lakehouse-Laufzeitkatalog.
Ressourcenhierarchie
Der Lakehouse-Laufzeitkatalog organisiert Metadaten in einer Hierarchie, die den Apache Iceberg-Standards entspricht und logische Identitäten physischen Speicherpfaden zuordnet.
Katalog
Ein Katalog ist der logische Container der obersten Ebene im Lakehouse-Laufzeitkatalog. Er definiert, wo Tabellendaten gespeichert werden können und welche Region die Metadaten bereitstellt. Weitere Informationen finden Sie unter Katalog erstellen.
Katalogtypen
Wenn Sie einen Katalog erstellen, können Sie zwischen zwei Speichermodellen wählen:
- Katalog mit mehreren Buckets (empfohlen): Sie können Ihren Katalog unabhängig benennen und einen Standardspeicherort (
default_location) sowie bis zu 128 zusätzliche Cloud Storage-Buckets oder Unterpfade inrestricted_locationskonfigurieren. Legen Sie beim Konfigurieren von Client-Abfrage-Engines (z. B. Spark oder Trino) den Warehouse-Pfad aufbl://projects/PROJECT_ID/catalogs/CATALOG_IDfest. - Katalog mit einem Bucket: Eine Legacy-Konfiguration, bei der der Katalog an einen einzelnen Cloud Storage-Bucket gebunden ist und den Namen des Buckets übernimmt.
Legen Sie beim Konfigurieren von Client-Abfrage-Engines den Warehouse-Pfad auf
gs://CLOUD_STORAGE_BUCKET_NAMEfest.
Weitere Informationen finden Sie unter Kataloge und Speicherorte.
Namespace
Ein Namespace ist eine logische Gruppierung von Tabellen in einem Katalog. Für Nutzer, die mit BigQuery vertraut sind, ist ein Namespace funktional mit einem Dataset vergleichbar. Namespaces übernehmen die Region ihres übergeordneten Katalogs und unterstützen keine Verschachtelung.
Tabelle
Eine Tabelle ist die Entität, die auf Daten in Cloud Storage verweist. Bei Apache Iceberg-Tabellen enthalten die Tabellenmetadaten das Schema, Partitionierungsinformationen und einen Verweis auf den aktuellen Tabellenstatus über eine metadata.json-Datei. Informationen zu den von Lakehouse unterstützten Tabellentypen finden Sie unter Tabellentypen.
P.C.N.T-Namenskonvention
Die P.C.N.T-Namenskonvention ist die vierteilige Konvention, die verwendet wird, um Tabellen im Lakehouse-Laufzeitkatalog von BigQuery eindeutig zu identifizieren und abzufragen. Es steht für Project.Catalog.Namespace.Table:
- Projekt: Die Google Cloud -Projekt-ID.
- Katalog: Der Name des Katalogs im Lakehouse-Laufzeitkatalog.
- Namespace: Die logische Gruppierung für Tabellen (ähnlich einem Dataset).
- Tabelle: Der Name der Datentabelle.
Katalogendpunkte
Ein Katalogendpunkt ist eine Protokollschnittstelle, über die Abfrage-Engines eine Verbindung zum Lakehouse-Laufzeitkatalog herstellen. Der von Ihnen verwendete Endpunkt bestimmt, mit welchen Tabellenformaten und Engines Sie arbeiten können.
Apache Iceberg REST-Katalogendpunkt
Der Apache Iceberg REST-Katalogendpunkt implementiert die offene Standard-Iceberg REST Catalog API. Er ist der empfohlene Endpunkt für neue Arbeitslasten und bietet Lese- und Schreibinteroperabilität zwischen Open-Source-Engines und BigQuery. Es unterstützt Kataloge mit mehreren Buckets, Credential Vending und regionenübergreifende Replikation (Vorabversion). Weitere Informationen finden Sie in der Übersicht über Apache Iceberg-REST-Katalogendpunkte.
Apache Hive-Katalogendpunkt
Der Apache Hive-Katalogendpunkt bietet Kompatibilität für Open-Source-Arbeitslasten, die von der Apache Hive Metastore-Schnittstelle (HMS) abhängen. Da der Lakehouse-Laufzeitkatalog diesen Endpunkt bereitstellt, können Sie Apache Hive- oder Spark-Arbeitslasten ausführen, ohne einen selbst gehosteten Hive-Metastore verwalten zu müssen. Der Endpunkt verwaltet Standard-Hive- und Spark-Tabellen anstelle von Apache Iceberg-Tabellen und unterstützt kundenverwaltete Verschlüsselungsschlüssel (CMEK) für Daten in Cloud Storage. Weitere Informationen finden Sie unter Informationen zum Hive-Katalogendpunkt.
Benutzerdefinierter Apache Iceberg-Katalog für BigQuery
Der benutzerdefinierte Apache Iceberg-Katalog für BigQuery ist eine frühere Integration, die ein Katalog-Plug-in (BigQueryMetastoreCatalog) verwendet, um Open-Source-Engines das Speichern von Apache Iceberg-Tabellendefinitionen in BigQuery zu ermöglichen. Namespaces werden BigQuery-Datasets zugeordnet. Sie fragen diese Tabellen also mit der Standard-BigQuery-Dataset-Syntax ab. Verwenden Sie für neue Arbeitslasten stattdessen den Apache Iceberg REST-Katalogendpunkt. Weitere Informationen finden Sie unter Benutzerdefinierter Apache Iceberg-Katalog für BigQuery.
Tabellentypen
Das Lakehouse von Google Cloud unterstützt mehrere Tabellentypen, je nachdem, welche Engine zum Verwalten der Daten und welchen Katalogendpunkt Sie verwenden. Einen detaillierten Vergleich finden Sie unter Tabellentypen vergleichen.
Apache Iceberg-Tabellen im Lakehouse-Laufzeitkatalog
Dies sind Apache Iceberg-Tabellen, die vom Lakehouse-Laufzeitkatalog verwaltet und über den Apache Iceberg REST-Katalogendpunkt bereitgestellt werden. Die Daten werden in Cloud Storage gespeichert. Open-Source-Engines haben Lese- und Schreibzugriff auf diese Tabellen. BigQuery hat Lesezugriff und Schreibzugriff (Vorabversion), wenn Sie BigQuery-DML aktivieren. Dies ist die empfohlene Option für die meisten Open-Lakehouse-Arbeitslasten. Weitere Informationen finden Sie unter Apache Iceberg-Tabellen verwalten.
Apache Hive-Tabellen
Dies sind Standard-Apache Hive- und Spark-Tabellen in Formaten wie Parquet, ORC, Avro und Delta Lake, die der Lakehouse-Laufzeitkatalog über den Apache Hive-Katalogendpunkt verwaltet. Open-Source-Engines haben Lese- und Schreibzugriff, BigQuery hat nur Lesezugriff. Wenn Sie Delta Lake-Tabellen verwenden möchten, erstellen Sie sie mit einer Delta-kompatiblen Engine wie Apache Spark und registrieren Sie sie im Metastore. Weitere Informationen finden Sie unter Unterstützte Speicherformate und -typen.
BigQuery-Tabellen
Diese Tabellen werden mit BigQuery verwaltet.
Verwaltete Apache Iceberg-Tabellen
Dies sind Apache Iceberg-Tabellen, die Sie in BigQuery erstellen und in Cloud Storage speichern. BigQuery übernimmt das gesamte Datenlayout und die Optimierung. Diese Tabellen können von mehreren Engines gelesen werden, aber BigQuery ist die einzige Engine, die direkt in sie schreiben kann. Diese Tabellen unterscheiden sich von Apache Iceberg-Tabellen im Lakehouse-Laufzeitkatalog. Weitere Informationen finden Sie unter Verwaltete Apache Iceberg-Tabellen.
Native Tabellen
Diese Tabellen werden von BigQuery verwaltet und speichern Daten im BigQuery-Speicher. Sie können diese Tabellen mit dem Lakehouse-Laufzeitkatalog verbinden.
Externe Tabellen
Externe Tabellen befinden sich außerhalb des Lakehouse-Laufzeitkatalogs. Ihre Daten und Metadaten werden in einem Speicher wie Cloud Storage, Amazon S3 oder Azure Blob Storage selbst verwaltet und BigQuery greift über Verbindungen darauf zu. BigQuery kann nur aus diesen Tabellen lesen.
Tabellenfunktionen und ‑optionen
Die folgenden Funktionen gelten für Apache Iceberg-Tabellen im Lakehouse-Laufzeitkatalog, sofern nicht anders angegeben.
Apache Iceberg-Tabellenversionen
Der Lakehouse-Laufzeitkatalog unterstützt Apache Iceberg V2- und V3-Tabellen (Vorabversion). V3-Tabellen unterstützen binäre Löschvektoren, mit denen Sie bestimmte Zeilen löschen können, ohne ganze Datendateien neu schreiben zu müssen. Iceberg V1-Tabellen werden nicht unterstützt. Sie müssen sie zuerst auf V2 aktualisieren. Weitere Informationen finden Sie unter Binäre Löschvektoren in Iceberg V3-Tabellen verwenden.
Tabellenentwicklung
Mit der Tabellenentwicklung können Sie das Schema oder die Partitionsspezifikation einer Tabelle im Laufe der Zeit ändern, ohne die Tabellendaten neu zu schreiben oder die Tabelle neu zu erstellen. Apache Iceberg-Tabellen im Lakehouse-Laufzeitkatalog unterstützen standardmäßig auch flexible Spaltennamen. Spaltennamen können daher Zeichen wie Leerzeichen und internationale Zeichen enthalten.
Zeitreise
Mit Zeitreisen können Sie die Daten einer Tabelle so abfragen, wie sie zu einem bestimmten Zeitpunkt oder einer bestimmten Snapshot-ID vorhanden waren. Dies ist nützlich für Audits, die Reproduktion von Experimenten oder die Wiederherstellung von Daten nach einem versehentlichen Löschen. Open-Source-Engines können innerhalb der in den Tabelleneigenschaften konfigurierten Aufbewahrungsdauer Zeitreisen durchführen, während Zeitreisen in BigQuery auf sieben Tage begrenzt sind.
Tabellenoptionen
Tabellenoptionen sind Tabellenattribute, mit denen von Google verwaltete Funktionen für einzelne Apache Iceberg-Tabellen aktiviert werden. Weitere Informationen finden Sie unter Tabellenoptionen konfigurieren.
BigQuery-DML
BigQuery-DML befindet sich in der Vorschau. Wenn Sie das Tabellenattribut gcp.biglake.bigquery-dml.enabled festlegen, kann BigQuery die Tabelle mithilfe von GoogleSQL-DDL- und -DML-Anweisungen (INSERT, UPDATE, DELETE und MERGE) erstellen, ändern und modifizieren, während Open-Source-Engines weiterhin dieselbe Tabelle lesen und schreiben.
Tabellenverwaltung
Die Tabellenverwaltung (Vorschau) automatisiert die Speicherwartung für Apache Iceberg-Tabellen. Wenn Sie die Tabellen-Property gcp.biglake.table-management.enabled festlegen, führt Lakehouse im Hintergrund eine Komprimierung (Zusammenführung), einen Snapshot-Ablauf und eine automatische Speicherbereinigung durch, um die Abfrageleistung und die Speichereffizienz aufrechtzuerhalten. Für die Tabellenverwaltung muss der Katalog Credential Vending verwenden. Weitere Informationen finden Sie unter Tabellenverwaltung aktivieren.
Änderungsverlauf
Mit dem Änderungsverlauf können Sie die GoogleSQL-Tabellenwertfunktion APPENDS verwenden, um Zeilen zu verfolgen, die über einen bestimmten Zeitraum an verwaltete Apache Iceberg-Tabellen angehängt wurden. Sie können damit Replikate inkrementell verwalten, Datenergänzungen prüfen oder nachgelagerte Pipelines ohne vollständige Tabellenscans auslösen. Weitere Informationen finden Sie unter Mit dem Änderungsverlauf arbeiten.
Caching von Metadaten
Metadaten-Caching beschleunigt die Abfrageleistung für externe BigQuery-Tabellen. Eine Kopie der Metadaten der Tabelle wird im BigQuery-Speicher gespeichert. Dadurch müssen Metadatendateien während der Abfrageausführung nicht mehr aus Cloud Storage gelesen werden.
Datenaufnahme und -migration
Lakehouse bietet mehrere Möglichkeiten, Daten in Apache Iceberg-Tabellen zu laden und Metadaten aus vorhandenen Metastores zu verschieben.
Tabellen im Batch importieren
Mit Dataflow-Job-Builder-Vorlagen können Sie vorhandene Apache Iceberg- und Delta Lake-Tabellen sowie Parquet-Dateien in von Lakehouse verwaltete Apache Iceberg-Tabellen importieren, ohne Code schreiben zu müssen.
Streamingaufnahme
Sie können Daten mithilfe von Open-Source-Engines (wie Spark oder Kafka), Dataflow oder der BigQuery Storage Write API (gRPC), die transaktionale, genau einmalige Schreibvorgänge bietet, in Apache Iceberg-Tabellen streamen. Sie können die Ausgabe von kontinuierlichen BigQuery-Abfragen auch direkt in von Apache Iceberg verwaltete Tabellen schreiben.
Change Data Capture (CDC)
Bei der CDC-Aufnahme werden Apache Iceberg-Tabellen mit Quellsystemen synchronisiert, indem Einfügungen, Aktualisierungen und Löschungen angewendet werden, anstatt vollständige Tabellen neu zu laden. Von Apache Iceberg verwaltete Tabellen unterstützen die BigQuery-CDC-Aufnahme (Vorabversion). Sie können Dataflow verwenden, um CDC-Logs aus Apache Iceberg- und Delta Lake-Tabellen zu migrieren (Vorabversion).
Metastore-Migration
Bei der Metastore-Migration werden Tabellenmetadaten aus vorhandenen Metastores in den Lakehouse-Laufzeitkatalog verschoben, ohne dass Datendateien kopiert werden. Sie können eine einmalige Migration oder einen Probelauf von Dataproc Metastore zum Apache Iceberg REST-Katalogendpunkt oder zum Apache Hive-Katalogendpunkt ausführen oder von externen Metastores wie Hive Metastore (Vorabversion) migrieren.
Cloudübergreifender Datenzugriff
Mit dem cloudübergreifenden Datenzugriff können Sie Daten, die in anderen Clouds und SaaS-Plattformen gespeichert sind, direkt über Google Cloudabfragen, ohne Dateien migrieren oder ETL-Pipelines erstellen zu müssen. Weitere Informationen finden Sie unter Cloudübergreifender Datenzugriff.
Föderierter Katalog
Ein föderierter Katalog ist ein Katalog im Lakehouse-Laufzeitkatalog, der eine Verbindung zu einem Remote-Kataloganbieter herstellt und seine Tabellen über den Apache Iceberg REST-Katalogendpunkt verfügbar macht. Anschließend können Sie diese Tabellen mit BigQuery, Managed Service for Apache Spark oder Apache Spark abfragen. Zu den unterstützten Remote-Kataloganbietern gehören Databricks Unity Catalog, AWS Glue Data Catalog, Snowflake Horizon Catalog, Workday Data Lake und SAP Business Data Cloud (SAP BDC). Weitere Informationen finden Sie unter Remote-Daten abfragen.
Metadatenaktualisierung im Hintergrund
Bei der Hintergrundaktualisierung von Metadaten synchronisiert ein föderierter Katalog regelmäßig Namespace- und Tabellenmetadaten aus dem Remote-Katalog, basierend auf einem Aktualisierungsintervall. Lakehouse authentifiziert sich beim Remote-Katalog mithilfe der OIDC-Tokenföderation oder von in Secret Manager gespeicherten Anmeldedaten.
Cloudübergreifender Transport
Beim cloudübergreifenden Datenzugriff wird die Aktualisierung von Hintergrundmetadaten vom Transport von Abfragedaten getrennt. Sie können einen oder beide über das öffentliche Internet oder privat über Cross-Cloud Interconnect weiterleiten, um Sicherheits- und Kostenanforderungen zu erfüllen. Um die Daten-Exfiltration einzuschränken, können Sie föderierte Katalogendpunkte auch mit VPC Service Controls schützen.
Cloudübergreifendes Caching
Beim cloudübergreifenden Caching werden Dateiblöcke, die aus dem Remote-Objektspeicher gelesen werden, lokal in der Google Cloud -Region gespeichert, in der Abfragen ausgeführt werden. Wiederholte Abfragen werden dann aus dem Cache und nicht aus der Remote-Cloud gelesen. Caching hilft, die Kosten für cloudübergreifenden ausgehenden Traffic zu senken, und ist standardmäßig deaktiviert. Sie können es für einen föderierten Katalog oder eine BigQuery-Verbindung zwischen Clouds aktivieren. Weitere Informationen finden Sie unter Intelligentes Caching.
Identitätsmodus
Der Identitätsmodus bestimmt, welche Identität Abfragen für einen Remote-Katalog ausführt:
- Dienstidentität (Standard): Die Aktualisierung von Hintergrundmetadaten und Abfragen werden als Dienstkonto des Katalogs ausgeführt.
- Nutzeridentitätsföderation: Abfragen werden mit der Identität des Endnutzers ausgeführt. Dadurch kann der Remote-Katalog seine eigenen Berechtigungen erzwingen und Audit-Logs einzelnen Nutzern zuordnen. Dieser Modus wird für Databricks Unity Catalog unterstützt.
SAP-BDC-Integration
Die SAP BDC-Integration funktioniert in zwei Richtungen. Durch die Föderation werden SAP BDC-Freigaben mithilfe des Delta Sharing-Protokolls mit Lakehouse synchronisiert, sodass Sie sie über BigQuery abfragen können. Beim Veröffentlichen werden Apache Iceberg-Tabellen oder Knowledge Catalog-Datenprodukte für SAP BDC freigegeben, ohne dass Daten migriert werden. Weitere Informationen finden Sie unter SAP BDC-Integration.
Öffentliche Datasets
Borderless Lakehouse hostet öffentliche Datasets, die über den Apache Iceberg REST-Katalogendpunkt bereitgestellt werden. Es bietet Lesezugriff für die explorative Datenanalyse und Tests, ohne dass eine Infrastruktur verwaltet werden muss. Google bezahlt die Speicherung und Sie bezahlen nur für die Abfragen, die Sie ausführen. Weitere Informationen finden Sie unter Öffentliche Datasets.
Sicherheit und Governance
Lakehouse kombiniert Identity and Access Management (IAM), die Delegierung des Speicherzugriffs und Netzwerksteuerungen, um Ihr Lakehouse zu schützen.
Zugriffssteuerung auf Ressourcenebene
IAM-Richtlinien für Kataloge, Namespaces und Tabellen steuern, wer Lakehouse-Ressourcen ansehen und ändern kann. Weitere Informationen finden Sie unter Katalog-, Namespace- und Tabellen-ACLs verwalten und Rollen und Berechtigungen.
Bereitstellung von Anmeldedaten
Die Bereitstellung von Anmeldedaten ist ein Sicherheitsmechanismus, der die Zugriffssteuerung bei Verwendung des Lakehouse-Laufzeitkatalogs verschärft. Anstatt Nutzern direkte Bucket-Berechtigungen zu gewähren, stellt der Apache Iceberg REST-Katalogendpunkt kurzlebige, eingeschränkte Speicheranmeldedaten bereit, deren Zugriff auf die spezifischen Tabellenpfade beschränkt ist, die für eine Abfrage erforderlich sind. Die Bereitstellung von Anmeldedaten ist auch für die Tabellenverwaltung erforderlich. Weitere Informationen finden Sie unter Anmeldedaten-Vending.
Verbindungen
Eine Verbindung ist eine BigQuery-Ressource, in der Anmeldedaten für den Zugriff auf externe Daten gespeichert werden. In Lakehouse von Google Cloud delegieren Verbindungen den Zugriff auf Cloud Storage, indem das Dienstkonto der Verbindung in Ihrem Namen auf den Storage-Bucket zugreift.
VPC Service Controls
VPC Service Controls-Dienstperimeter helfen, Daten-Exfiltration zu verhindern, indem sie den Zugriff auf die Lakehouse API (biglake.googleapis.com) und die Cloud Storage-Buckets einschränken, in denen Tabellendaten gespeichert sind. Weitere Informationen finden Sie unter VPC Service Controls mit der Ausgabe von Anmeldedaten verwenden.
Regionale Endpunkte
Regionale Endpunkte schränken Anfragen ein, sodass sie nur fortgesetzt werden, wenn die Zielkatalogressource am vom Endpunkt angegebenen Standort vorhanden ist. So können Sie die Anforderungen an den Datenstandort erfüllen. Weitere Informationen finden Sie unter Regionale Endpunkte.
Audit-Logging
In Cloud-Audit-Logs werden Verwaltungs- und Datenzugriffsaktivitäten für Lakehouse-Ressourcen aufgezeichnet. Weitere Informationen finden Sie unter Audit-Logs ansehen.
Einheitliche Governance
Mit der einheitlichen Governance können Sie Sicherheits- und Datenmanagementrichtlinien zentral definieren und durchsetzen, indem Sie sie in Knowledge Catalog einbinden. Wenn Sie Tabellen im Lakehouse-Laufzeitkatalog registrieren, registriert das System automatisch entsprechende Einträge in Knowledge Catalog. Dadurch werden Suche und Erkennung, Datenherkunft, Datenprofilerstellung und KI-generierte Datenerkenntnisse (Vorabversion) über alle Engines hinweg ermöglicht, ohne dass Dateien verschoben oder kopiert werden müssen.
Abfrage-Engines und ‑Tools
Das Lakehouse von Google Cloud entkoppelt Speicher und Computing, sodass verschiedene Analyse-Engines mit denselben offenen Tabellen arbeiten können.
Open-Source-Engines
Open-Source-Engines stellen über den Apache Iceberg REST-Katalogendpunkt eine Verbindung zum Lakehouse-Laufzeitkatalog her. Dazu wird die Standardkonfiguration des Apache Iceberg-Clients verwendet. Informationen zur Einrichtung der jeweiligen Engine finden Sie unter Apache Spark, Apache Flink und Trino. Sie können Lakehouse-Ressourcen auch mit Terraform verwalten.
Managed Service for Apache Spark
Managed Service for Apache Spark (ehemals Dataproc Serverless) bietet eine vollständig verwaltete Laufzeit für die Verarbeitung offener Tabellenformate wie Apache Iceberg. Es unterstützt zwei primäre Ausführungsmodi:
- Serverlose Batches: Entwickelt für automatisierte, nicht interaktive Datenverarbeitungspipelines und ETL-Arbeitslasten. Dieses Modell mit Bezahlung pro Ausführung macht die Clusterverwaltung überflüssig, beseitigt Ressourcenkonflikte zwischen Jobs und automatisiert die Infrastrukturwartung.
- Serverlose interaktive Sitzungen: Entwickelt für explorative Datenanalyse, Data Engineering und Data-Science-Experimente. Interaktive Sitzungen ermöglichen die Ausführung von Apache Spark-Notebooks mit Spark Connect oder Remote-Spark-Kernels. Sie bieten eine automatisch skalierende Umgebung ohne Infrastruktureinrichtung.
Dienststufen
Wenn Sie Apache Spark-Arbeitslasten in Managed Service for Apache Spark ausführen, können Sie zwischen Dienststufen wählen:
- Standardstufe: Die Standardausführungsstufe, die für Standard-Batchverarbeitungsarbeitslasten geeignet ist.
- Premium-Stufe: Bietet erweiterte Funktionen, einschließlich Unterstützung für serverlose interaktive Notebook-Sitzungen und leistungssteigernde Funktionen wie die Lightning Engine.
Sitzungsvorlagen
Sitzungsvorlagen vereinfachen die Konfiguration serverloser interaktiver Sitzungen.
Administratoren können damit gängige Umgebungseinstellungen wie Katalogattribute, Netzwerkkonfigurationen und Laufzeitversionen definieren und beibehalten. Das fördert die Konsistenz und minimiert wiederholte Einrichtungsschritte. Sie können Sitzungsvorlagen mit der Google Cloud Console, der gcloud CLI, der REST API oder Terraform erstellen und verwalten.
konversationelle Analyse
Mit der konversationellen Analyse (Vorabversion) können Sie Tabellen im Lakehouse-Laufzeitkatalog, einschließlich cloudübergreifender Quellen, mithilfe von Prompts in natürlicher Sprache in BigQuery abfragen.
Zuverlässigkeit
Der Lakehouse-Laufzeitkatalog bietet eine verwaltete Notfallwiederherstellung für Kataloge, die den Apache Iceberg REST-Katalogendpunkt (Vorabversion) verwenden. Weitere Informationen finden Sie unter Regionenübergreifende Replikation und Notfallwiederherstellung.
Regionsübergreifende Replikation
Bei der regionenübergreifenden Replikation werden Katalogmetadaten von einer primären Region in eine sekundäre Region kopiert, wenn der Katalog einen Cloud Storage-Bucket mit zwei Regionen oder mehreren Regionen verwendet. Dadurch bleibt der Katalog bei regionalen Ausfällen verfügbar. Cloud Storage repliziert die zugrunde liegenden Tabellendaten.
Failover
Beim Failover werden die primäre und die sekundäre Region für einen Katalog und alle zugehörigen Namespaces und Tabellen gewechselt. Bei einem Soft-Failover wird gewartet, bis alle Daten synchronisiert sind, bevor die neue primäre Instanz Schreibvorgänge akzeptiert. Dadurch wird Datenverlust verhindert und es eignet sich für geplante Tests. Bei einem harten Failover wird die Verfügbarkeit priorisiert und die neue primäre Instanz übernimmt, auch wenn die vorherige primäre Instanz nicht erreichbar ist.