Einführung in Objekttabellen

In diesem Dokument werden Objekttabellen beschrieben, bei denen es sich um schreibgeschützte Tabellen über unstrukturierte Datenobjekte handelt, die sich in Cloud Storage befinden.

Mit Objekttabellen können Sie unstrukturierte Daten in Cloud Storage analysieren. Sie können Analysen mit Remotefunktionen ausführen oder mit BigQuery ML Schlussfolgerungen ziehen und dann die Ergebnisse dieser Vorgänge mit den restlichen strukturierten Daten in BigQuery zusammenführen.

Wie BigLake-Tabellen verwenden Objekttabellen eine Zugriffsdelegation, die den Zugriff auf die Objekttabelle vom Zugriff auf die Cloud Storage-Objekte entkoppelt. Eine externe Verbindung, die mit einem Dienstkonto verknüpft ist, wird für die Verbindung mit Cloud Storage verwendet, sodass Sie Nutzern nur Zugriff auf die Objekttabelle gewähren müssen. So können Sie die Sicherheit auf Zeilenebene erzwingen und verwalten, auf welche Objekte Nutzer Zugriff haben.

Objekttabellenschema

Eine Objekttabelle stellt einen Metadatenindex über die unstrukturierten Datenobjekte in einem bestimmten Cloud Storage-Bucket bereit. Jede Zeile der Tabelle entspricht einem Objekt und die Tabellenspalten entsprechen den von Cloud Storage generierten Objektmetadaten, einschließlich aller benutzerdefinierten Metadaten.

Eine Objekttabelle enthält auch eine Pseudospalte data, die den Dateiinhalt in Rohbyte darstellt, die beim Erstellen der Objekttabelle automatisch ausgefüllt werden. Diese Pseudospalte wird von der ML.DECODE_IMAGE-Funktion verwendet, wenn Sie Inferenz für Bilddaten ausführen. Sie können die Pseudospalte data nicht in Abfragen einbinden und sie wird nicht als Teil des Objekttabellenschemas angezeigt.

In der folgenden Tabelle wird das von Objekttabellen verwendete feste Schema beschrieben:

Feldname	Typ	Mode	Beschreibung
`uri`	STRING	NULLWERTE ZULÄSSIG	`uri`: Die Uniform Resource Identifier (URI) des Objekts im Format `gs://bucket_name/[folder_name/]object_name`.
`generation`	INTEGER	NULLWERTE ZULÄSSIG	Die Generierung dieses Objekts, das die Objektversion identifiziert.
`content_type`	STRING	NULLWERTE ZULÄSSIG	Der Content-Type der Objektdaten, der angibt, um welche Art von Medien es sich handelt. Wenn ein Objekt ohne Content-Type gespeichert wird, wird es als application/octet-stream bereitgestellt.
`size`	INTEGER	NULLWERTE ZULÄSSIG	Die Inhaltslänge der Daten in Byte.
`md5_hash`	STRING	NULLWERTE ZULÄSSIG	Der MD5-Hash der Daten, codiert mit base64. Weitere Informationen zur Verwendung des MD5-Hashwerts finden Sie unter Cloud Storage-Objektmetadaten.
`updated`	TIMESTAMP	NULLWERTE ZULÄSSIG	Die letzten Metadaten des Objekts wurden geändert.
`metadata`	RECORD	REPEATED	Benutzerdefinierte Metadaten für das Objekt. Jedes Metadatenelement wird als Schlüssel/Wert-Paar in den untergeordneten Feldern `(metadata.)name` und `(metadata.)value` des Felds `metadata` dargestellt.
`(metadata.)name`	STRING	NULLWERTE ZULÄSSIG	Schlüssel in einem einzelnen Metadateneintrag
`(metadata.)value`	STRING	NULLWERTE ZULÄSSIG	Wert in einem einzelnen Metadateneintrag

Die Zeilen in einer Objekttabelle sehen in etwa so aus:

------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------

Anwendungsfälle

Sie können die Metadaten in einer Objekttabelle auf dieselbe Weise abfragen wie jede andere BigQuery-Tabelle. Der primäre Anwendungsfall für Objekttabellen besteht jedoch darin, unstrukturierte Daten für die Analyse zugänglich zu machen. Sie können BigQuery ML verwenden, um mit TensorFlow-, TensorFlow Lite- und PyTorch-Modellen Inferenz für Bildobjekttabellen auszuführen. Mit Remote-Funktionen können Sie auch auf fast beliebige Weise unstrukturierte Daten analysieren. Sie können beispielsweise eine Remote-Funktion erstellen, mit der Sie Bilder mithilfe von Cloud Vision analysieren, oder eine, mit der Sie Metadaten mithilfe von Apache Tika extrahieren können.

In der folgenden Tabelle werden die Integrationspunkte beschrieben, mit denen Sie maschinelles Lernen für Objekttabellendaten ausführen können:

Integration	Beschreibung	Anwendungsfall	Tutorial
Importierte BigQuery ML-Modelle	Importieren Sie TensorFlow-, TensorFlow Lite- oder ONNX-Modelle in BigQuery ML, um lokale Inferenz in BigQuery auszuführen.	Sie verwenden Open-Source- oder benutzerdefinierte Modelle, die den unterstützten Einschränkungen entsprechen.	Anleitung: Inferenz für eine Objekttabelle mithilfe eines Featurevektormodells ausführen
Cloud Run-Funktionen	Verwenden Sie Cloud Run Functions zum Aufrufen von Diensten oder gehosteten Modellen. Dies ist die allgemeinste Integration.	Sie hosten Ihre Modelle selbst in Compute Engine, Google Kubernetes Engine oder einer anderen kundeneigenen Infrastruktur.
Die `ML.ANNOTATE_IMAGE`-Funktion	Annotieren Sie Bilder mithilfe der Cloud Vision API.	Sie möchten Bilder mithilfe eines vortrainierten Vision API-Modells annotieren.	Bilder mit der Funktion `ML.ANNOTATE_IMAGE` annotieren
Die `ML.PROCESS_DOCUMENT`-Funktion	Verwenden Sie die Document AI API, um Dokumentstatistiken zu extrahieren.	Sie möchten vortrainierte oder benutzerdefinierte Dokumentprozessoren von Document AI verwenden.	Dokumente mit der Funktion `ML.PROCESS_DOCUMENT` verarbeiten
Die `ML.TRANSCRIBE`-Funktion	Verwenden Sie die Speech-to-Text API, um Audiodateien zu transkribieren.	Sie möchten vortrainierte oder benutzerdefinierte Spracherkennungssysteme von Speech-to-Text verwenden.	Audiodateien mit der Funktion `ML.TRANSCRIBE` transkribieren

Sie können eine Ansicht oder Tabelle aus den Ergebnissen Ihrer Analyse erstellen, wenn Sie Ihre Ergebnisse mit anderen strukturierten Daten zusammenführen möchten. Mit der folgenden Anweisung wird beispielsweise eine Tabelle auf Grundlage der Inferenzergebnisse erstellt:

CREATE TABLE my_dataset.my_inference_results AS
SELECT uri, content_type, vision_feature
FROM ML.PREDICT(
  MODEL my_dataset.vision_model,
  SELECT ML.DECODE_IMAGE(data) AS vision_input
  FROM my_dataset.object_table
);

Nachdem die Tabelle erstellt wurde, können Sie sie anhand der Standard- oder benutzerdefinierten Metadatenfelder mit anderen Tabellen zusammenführen:

SELECT a.vision_feature, a.uri, b.description
FROM my_dataset.my_inference_results a
JOIN my_dataset.image_description b
ON a.uri = b.uri;

Sie können auch einen Suchindex erstellen, um die Ergebnisse Ihrer Analyse zu durchsuchen. Mit der folgenden Anweisung wird beispielsweise ein Suchindex für Daten erstellt, die aus PDF-Dateien extrahiert wurden:

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Anschließend können Sie mit dem Index feststellen, was Sie in diesen Ergebnissen benötigen:

SELECT * FROM pdf_text_extract WHERE SEARCH(pdf_text, 'Google');

Vorteile

Die Analyse unstrukturierter Daten in BigQuery bietet folgende Vorteile:

Sie reduziert den manuellen Aufwand, da Sie Vorverarbeitungsschritte wie die Feinabstimmung der Bildgrößen mit den Modellanforderungen automatisieren können.
Sie können auch die einfache und vertraute SQL-Schnittstelle verwenden, um mit unstrukturierten Daten zu arbeiten.
Sie können Kosten sparen, indem Sie vorhandene BigQuery-Slots nutzen, anstatt neue Formen der Rechenleistung bereitstellen zu müssen.

Signierte URLs

Generieren Sie eine signierte URL, um Zugriff auf die Daten eines Objekts zu erhalten. Sie können die signierte URL verwenden, um die Objektdaten direkt anzusehen, und außerdem signierte URLs an Remotefunktionen übergeben, damit sie mit Objekttabellendaten arbeiten können.

Verwenden Sie die Funktion EXTERNAL_OBJECT_TRANSFORM, um signierte URLs zu generieren, wie im folgenden Beispiel gezeigt:

SELECT uri, signed_url
FROM EXTERNAL_OBJECT_TRANSFORM(TABLE `mydataset.myobjecttable`, ['SIGNED_URL']);

Dies gibt Ergebnisse wie die folgenden zurück:

---------------------------------------------------------------------------------------------------
|  uri                 | signed_url                                                               |
—--------------------------------------------------------------------------------------------------
| gs://mybucket/a.docx | https://storage.googleapis.com/mybucket/a.docx?X-Goog-Signature=abcd&... |
—-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-Signature=wxyz&...  |
—--------------------------------------------------------------------------------------------------

Signierte URLs, die aus Objekttabellen generiert werden, ermöglichen jedem Nutzer oder Verfahren, der es ermöglicht, die entsprechenden Objekte zu lesen. Die generierten signierten URLs laufen nach sechs Stunden ab. Weitere Informationen finden Sie unter Von Cloud Storage signierte URLs.

Zugriffssteuerung

Objekttabellen werden auf BigLake basiert und verwenden daher eine externe Verbindung basierend auf einem Dienstkonto, um auf Cloud Storage-Daten zuzugreifen. Durch die Zugriffsdelegation wird der Zugriff auf die Tabelle vom Zugriff auf den zugrunde liegenden Datenspeicher entkoppelt. Sie erteilen dem Dienstkonto Berechtigungen zum Zugriff auf Daten und Metadaten aus den Objekten und zur Anzeige in der Tabelle. Sie erteilen den Nutzern Berechtigungen nur für die Tabelle, in der Sie den Datenzugriff mithilfe von Identity and Access Management (IAM) und der Sicherheit auf Zeilenebene steuern können.

Objekttabellen unterscheiden sich von anderen Tabellen, die die Zugriffsdelegation verwenden, da der Zugriff auf eine Zeile einer Objekttabelle Zugriff auf den zugrunde liegenden Dateiinhalt gewährt. Nutzer können zwar nicht direkt auf das Objekt zugreifen, können aber eine signierte URL generieren, mit der sie den Dateiinhalt sehen können. Wenn der Nutzer beispielsweise Zugriff auf die Objekttabellenzeile hat, die die Bilddatei flower.jpg darstellt, kann er eine signierte URL generieren, die die Datei anzeigt. Er sieht dann ein Bild eines Gänseblümchens.

Durch das Festlegen einer Zugriffsrichtlinie auf Zeilenebene für eine Objekttabelle wird der Zugriff eines Nutzers oder einer Gruppe auf die Objektmetadaten in den ausgewählten Zeilen sowie auf die Objekte beschränkt, die durch diese Zeilen dargestellt werden. Die folgende Anweisung gewährt beispielsweise dem Nutzer Alice nur Zugriff auf Zeilen, die Objekte darstellen, die vor dem 25. Juni 2022 erstellt wurden:

CREATE ROW ACCESS POLICY before_20220625
ON my_dataset.my_object_table
GRANT TO ("user:alice@example.com")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

Wenn diese Zugriffsrichtlinie auf Zeilenebene festgelegt ist, gelten für Alice die folgenden Ergebnisse:

Die Abfrage SELECT * FROM my_dataset.my_object_table; gibt nur Zeilen zurück, die vor dem 25. Juni 2022 einen updated-Wert haben.
Das Ausführen von Inferenzen auf my_dataset.my_object_table gibt nur Vorhersagen für Objekte zurück, die vor dem 25. Juni 2022 einen updated-Wert haben.
Das Generieren von signierten URLs für my_dataset.my_object_table erstellt nur URLs für Objekte, die vor dem 25. Juni 2022 einen updated-Wert haben.

Sie können den Zugriff auf Objekttabellenzeilen auch mithilfe benutzerdefinierter Metadaten einschränken. Die folgende Anweisung beschränkt beispielsweise die Gruppe users nur auf Zeilen, in denen das Objekt mit Tags gekennzeichnet ist, die keine personenbezogenen Daten enthalten:

CREATE ROW ACCESS POLICY no_pii
ON my_dataset.my_object_table
GRANT TO ("group:users@example.com")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

Sicherheitsmodell

Die folgenden Organisationsrollen sind in der Regel an der Verwaltung und Verwendung von Objekttabellen beteiligt:

Data-Lake-Administratoren. Diese Administratoren verwalten normalerweise IAM-Richtlinien (Identity and Access Management) in Cloud Storage-Buckets und -Objekten.
Data-Warehouse-Administratoren. Diese Administratoren erstellen, löschen und aktualisieren in der Regel Tabellen.
Datenanalyst*innen. Die Analysten lesen normalerweise Daten und führen Abfragen aus.

Data-Lake-Administratoren sind dafür verantwortlich, Verbindungen zu erstellen und für Data-Warehouse-Administratoren freizugeben. Data-Warehouse-Administratoren erstellen wiederum Tabellen, legen geeignete Zugriffssteuerungen fest und geben die Tabellen für Datenanalysten frei.

Unterstützte Objektdateien

Sie können eine Objekttabelle für jeden Typ und jede Größe von unstrukturierten Datendateien erstellen und Remotefunktionen für alle Arten von unstrukturierten Daten erstellen. Für eine Inferenz mit BigQuery ML darf eine Objekttabelle jedoch nur Bilddateien enthalten, die verschiedene Größen- und Typanforderungen erfüllen. Weitere Informationen finden Sie unter Einschränkungen.

Metadaten-Caching für bessere Leistung

Mit im Cache gespeicherten Metadaten können Sie die Leistung von Inferenzen und anderen Arten von Analysen an Objekttabellen verbessern. Das Caching von Metadaten ist besonders hilfreich, wenn die Objekttabelle auf eine große Anzahl von Objekten verweist. Die Metadaten enthalten Dateinamen, Partitionierungsinformationen und physische Metadaten aus Dateien wie der Zeilenanzahl. Sie können auswählen, ob das Caching von Metadaten für eine Tabelle aktiviert werden soll. Abfragen mit einer großen Anzahl von Dateien und mit Hive-Partitionsfiltern profitieren am meisten vom Metadaten-Caching.

Wenn Sie das Caching von Metadaten nicht aktivieren, müssen Abfragen in der Tabelle die externe Datenquelle lesen, um Objektmetadaten abzurufen. Durch das Lesen dieser Daten erhöht sich die Abfragelatenz. Das Auflisten von Millionen von Dateien aus der externen Datenquelle kann einige Minuten dauern. Wenn Sie das Metadaten-Caching aktivieren, können Abfragen die Auflistung von Dateien aus der externen Datenquelle vermeiden und Dateien schneller partitionieren und bereinigen.

Es gibt zwei Attribute, die diese Funktion steuern:

Die maximale Veralterung gibt an, wann Abfragen im Cache gespeicherte Metadaten verwenden.
Der Metadaten-Cache-Modus gibt an, wie die Metadaten erhoben werden.

Wenn Sie das Caching von Metadaten aktiviert haben, geben Sie auch das maximale Intervall der Metadatenveralterung an, das für Vorgänge in Bezug auf die Tabelle akzeptabel ist. Wenn Sie beispielsweise ein Intervall von 1 Stunde angeben, verwenden die Vorgänge für die Tabelle im Cache gespeicherte Metadaten, wenn sie innerhalb der letzten Stunde aktualisiert wurden. Sind die im Cache gespeicherten Metadaten älter, werden für den Vorgang stattdessen Metadaten aus Cloud Storage abgerufen. Sie können ein Veralterungsintervall zwischen 30 Minuten und 7 Tagen festlegen.

Sie können den Cache entweder automatisch oder manuell aktualisieren:

Bei automatischen Aktualisierungen wird der Cache in einem systemdefinierten Intervall aktualisiert, in der Regel zwischen 30 und 60 Minuten. Das automatische Aktualisieren des Caches ist ein guter Ansatz, wenn die Objekte in Cloud Storage in zufälligen Intervallen hinzugefügt, gelöscht oder geändert werden. Wenn Sie den Zeitpunkt der Aktualisierung steuern müssen, z. B. um die Aktualisierung am Ende eines Extract-Transform-Ladejobs auszulösen, verwenden Sie die manuelle Aktualisierung.
Bei manuellen Aktualisierungen führen Sie das Systemverfahren BQ.REFRESH_EXTERNAL_METADATA_CACHE aus, um den Metadaten-Cache nach einem Zeitplan zu aktualisieren, der Ihren Anforderungen entspricht. Das manuelle Aktualisieren des Caches ist ein guter Ansatz, wenn die Objekte in Cloud Storage in bekannten Intervallen hinzugefügt, gelöscht oder geändert werden, z. B. als Ausgabe einer Pipeline.

Wenn Sie mehrere manuelle Aktualisierungen gleichzeitig ausführen, ist nur eine erfolgreich.

Der Metadaten-Cache läuft nach 7 Tagen ab, wenn er nicht aktualisiert wird.

Sowohl manuelle als auch automatische Cache-Aktualisierungen werden mit der Abfragepriorität INTERACTIVE ausgeführt.

Wenn Sie automatische Aktualisierungen verwenden möchten, empfehlen wir, eine Reservierung zu erstellen und dann eine Zuweisung mit dem Jobtyp BACKGROUND für das Projekt zu erstellen, in dem die Metadaten-Cache-Aktualisierungsjobs ausgeführt werden. Dadurch wird verhindert, dass die Aktualisierungsjobs mit Nutzerabfragen um Ressourcen konkurrieren und möglicherweise fehlschlagen, wenn nicht genügend Ressourcen verfügbar sind.

Sie sollten berücksichtigen, wie die Werte für Veralterung und Metadaten-Caching-Modus interagieren, bevor Sie sie festlegen. Betrachten Sie hierzu folgende Beispiele:

Wenn Sie den Metadaten-Cache für eine Tabelle manuell aktualisieren und das Veralterungsintervall auf 2 Tage festlegen, müssen Sie das Systemverfahren BQ.REFRESH_EXTERNAL_METADATA_CACHE alle 2 Tage oder weniger ausführen, wenn Sie Vorgänge wünschen. um die im Cache gespeicherten Metadaten zu verwenden.
Wenn Sie den Metadaten-Cache für eine Tabelle automatisch aktualisieren und das Veralterungsintervall auf 30 Minuten festlegen, ist es möglich, dass einige Vorgänge für die Tabelle aus Cloud Storage gelesen werden, wenn die Metadaten-Cache-Aktualisierung länger als die üblichen 30 bis 60 Minuten dauert.

Fragen Sie die Ansicht INFORMATION_SCHEMA.JOBS ab, um Informationen zu Aktualisierungsjobs für Metadaten zu erhalten, wie im folgenden Beispiel gezeigt:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Weitere Informationen finden Sie unter Caching von Metadaten.

Weitere Informationen zum Festlegen von Metadaten-Caching-Optionen finden Sie unter Objekttabellen erstellen.

Beschränkungen

Objekttabellen sind schreibgeschützt, da sie in Cloud Storage unstrukturierten Datenobjekten zugeordnet werden. Sie können keine Objekttabelle oder Objekttabellendaten ändern.
Die Objekttabellenunterstützung ist in Legacy-SQL oder anderen Cloudumgebungen wie AWS und Microsoft Azure nicht verfügbar.
Wenn Sie mithilfe von BigQuery ML Schlussfolgerungen ziehen möchten, müssen das Modell und die verwendete Objekttabelle die unter Einschränkungen beschriebenen Anforderungen erfüllen.
Abfragen, die Objekttabellen enthalten, können nicht auf mehr als 10 GB Objektmetadaten zugreifen. Wenn eine Abfrage beispielsweise über eine Kombination von Metadatenspalten in Objekttabellen und Objektdaten über signierte URLs auf 100 TB zugreift, können nur 10 GB von diesen 100 TB aus den Metadatenspalten stammen.
Objekttabellen unterliegen den gleichen Einschränkungen wie alle anderen externen BigQuery-Tabellen. Weitere Informationen finden Sie unter Kontingente.
Abfragen von Objekttabellen unterliegen denselben Einschränkungen wie alle anderen BigQuery-Abfragen. Weitere Informationen finden Sie unter Kontingente.
Für Remote-Funktionen, die unstrukturierte Daten aus Objekttabellen verarbeiten, gelten die gleichen Einschränkungen wie für alle anderen Remote-Funktionen.
Signierte URLs, die für die Objekte in einer Objekttabelle generiert wurden, laufen nach sechs Stunden ab. Dies ist das Zeitlimit für die Abfrageausführung.
Inferenz mit BigQuery ML wird bei On-Demand-Preisen oder in der Standardversion nicht unterstützt.
Die folgenden Funktionen werden bei On-Demand-Preisen und in der Standardversion nicht unterstützt:

Kosten

Kosten fallen im Zusammenhang mit den folgenden Aspekten von Objekttabellen an:

Tabellen abfragen
Metadaten-Cache aktualisieren.

Wenn Sie Slot-Reservierungen haben, fallen für die Abfrage externer Tabellen keine Kosten an. Stattdessen werden für diese Abfragen Slots verwendet.

In der folgenden Tabelle sehen Sie, wie sich Ihr Preismodell darauf auswirkt, wie diese Kosten angewendet werden:

	On-Demand-Preise.	Standard-, Enterprise- und Enterprise Plus-Versionen
Abfragen	Die von den Nutzerabfragen verarbeiteten Byte werden Ihnen in Rechnung gestellt.	Slots in Reservierungszuweisungen mit einem `QUERY`-Jobtyp werden während der Abfragezeit verbraucht.
Metadaten-Cache manuell aktualisieren.	Ihnen werden die verarbeiteten Byte in Rechnung gestellt um den Cache zu aktualisieren.	Slots in Reservierungszuweisungen mit einem `QUERY`-Jobtyp werden während der Cache-Aktualisierung genutzt.
Metadaten-Cache automatisch aktualisieren.	Ihnen werden die verarbeiteten Byte in Rechnung gestellt um den Cache zu aktualisieren.	Slots in Reservierungszuweisungen mit einem `BACKGROUND`-Jobtyp werden während der Cache-Aktualisierung verbraucht. Wenn keine `BACKGROUND`-Reservierungen für die Aktualisierung des Metadaten-Cache verfügbar sind, verwendet BigQuery stattdessen automatisch Slots in `QUERY`-Reservierungen, wenn Sie die Enterprise- oder Enterprise Plus-Version verwenden.

Außerdem werden Ihnen die Speicherung und der Datenzugriff durch Cloud Storage, Amazon S3 und Azure Blob Storage abhängig von den Preisrichtlinien der einzelnen Produkte in Rechnung gestellt.

Objekttabellen mit Analytics Hub verwenden

Objekttabellen sind mit Analytics Hub kompatibel. Datasets, die Objekttabellen enthalten, können als Analytics Hub-Einträge veröffentlicht werden. Analytics Hub-Abonnenten können diese Einträge abonnieren, die ein schreibgeschützten Dataset, das als verknüpftes Dataset bezeichnet wird, in ihrem Projekt bereitstellen. Abonnenten können alle Tabellen im verknüpften Dataset abfragen, einschließlich aller Objekttabellen. Weitere Informationen finden Sie unter Einträge abonnieren.