Migrationsbewertung

Mit der BigQuery-Migrationsbewertung können Sie die Migration Ihres vorhandenen Data Warehouse zu BigQuery planen und prüfen. Sie können die BigQuery-Migrationsbewertung ausführen, um einen Bericht zu erstellen, in dem Sie die Kosten für die Speicherung Ihrer Daten in BigQuery ermitteln, um zu sehen, wie BigQuery Ihre bestehende Arbeitslast im Hinblick auf Kosteneinsparungen optimieren kann, und um einen Migrationsplan zu erstellen, der den Zeit- und Arbeitsaufwand für die Migration Ihres Data Warehouse zu BigQuery beschreibt.

In diesem Dokument wird beschrieben, wie Sie die BigQuery-Migrationsbewertung verwenden und die verschiedenen Möglichkeiten zum Prüfen der Bewertungsergebnisse kennen. Dieses Dokument richtet sich an Nutzer, die mit der Google Cloud Console und dem Batch-SQL-Übersetzer vertraut sind.

Übersicht

So bereiten Sie eine BigQuery-Migrationsbewertung vor und führen sie aus:

  1. Cloud Storage-Bucket erstellen

  2. Extrahieren Sie Metadaten und Abfragelogs aus Ihrem Data Warehouse mit dem dwh-migration-dumper-Tool.

  3. Metadaten und Abfragelogs in Ihren Cloud Storage-Bucket hochladen.

  4. Migrationsbewertung ausführen.

  5. Looker Studio-Bericht aufrufen.

  6. Optional: Abfragen der Bewertungsergebnisse, um detaillierte oder spezifische Bewertungsinformationen zu finden

Metadaten und Abfragelogs aus Ihrem Data Warehouse extrahieren

Sowohl Metadaten als auch Abfragelogs sind erforderlich, um die Bewertung mit Empfehlungen vorzubereiten.

Wählen Sie Ihr Data Warehouse aus, um die Metadaten und Abfragelogs zu extrahieren, die zum Ausführen der Bewertung erforderlich sind:

Teradata

Voraussetzungen

  • Eine Maschine, die mit dem Teradata-Quell-Data-Warehouse verbunden ist (Teradata 15 und höher wird unterstützt).
  • Ein Google Cloud-Konto mit einem Cloud Storage-Bucket zum Speichern der Daten
  • Ein leeres BigQuery-Dataset zum Speichern der Ergebnisse
  • Leseberechtigungen für das Dataset, um die Ergebnisse aufzurufen
  • Empfohlen: Zugriffsrechte auf Administratorebene für die Quelldatenbank, wenn das Extraktionstool für den Zugriff auf Systemtabellen verwendet wird

Anforderung: Logging aktivieren

Das dwh-migration-dumper-Tool extrahiert drei Arten von Logs: Abfragelogs, Hilfslogs und Logs zur Ressourcennutzung. Sie müssen das Logging für die folgenden Logtypen aktivieren, um umfangreichere Informationen zu erhalten:

dwh-migration-dumper-Tool ausführen

Laden Sie das dwh-migration-dumper-Tool herunter.

Laden Sie die Datei SHA256SUMS.txt herunter und führen Sie den folgenden Befehl aus, um die Richtigkeit der ZIP-Datei zu prüfen:

sha256sum --check SHA256SUMS.txt

Weitere Informationen zum Einrichten und Verwenden des Extraktionstools finden Sie unter Metadaten für Übersetzung und Bewertung generieren.

Verwenden Sie das Extraktionstool, um Logs und Metadaten aus Ihrem Teradata-Data-Warehouse als zwei ZIP-Dateien zu extrahieren. Führen Sie die folgenden Befehle auf einem Computer mit Zugriff auf das Quell-Data-Warehouse aus, um die Dateien zu generieren.

Generieren Sie die Metadaten-ZIP-Datei:

dwh-migration-dumper \
  --connector teradata \
  --database DATABASES \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

Generieren Sie die ZIP-Datei mit den Abfragelogs:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD

Ersetzen Sie Folgendes:

  • DATABASES: Eine durch Kommas getrennte Liste der zu extrahierenden Datenbanknamen.
  • PATH: Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll.
  • VERSION: Die Version Ihres Treibers.
  • HOST: Die Hostadresse.
  • USER: Der Nutzername für die Datenbankverbindung.
  • PASSWORD: Das Passwort für die Datenbankverbindung.

    Wenn dieses Feld leer bleibt, wird der Nutzer zur Eingabe seines Passworts aufgefordert.

Sie können das Flag --database nur für den Connector teradata verwenden. Mit diesem Flag können Sie die Metadaten einer oder mehrerer Datenbanken extrahieren. Wenn Sie die Abfragelogs mit dem Connector teradata-logs extrahieren, ist das Flag --database nicht verfügbar. Abfragelogs werden immer für alle Datenbanken extrahiert.

Standardmäßig werden die Abfragelogs aus der Ansicht dbc.QryLogV und aus der Tabelle dbc.DBQLSqlTbl extrahiert. Wenn Sie die Abfragelogs aus einem alternativen Speicherort extrahieren möchten, können Sie die Namen der Tabellen oder Ansichten mit den Flags -Dteradata-logs.query-logs-table und -Dteradata-logs.sql-logs-table angeben.

Die Dienstprogrammlogs werden standardmäßig aus der Tabelle dbc.DBQLUtilityTbl extrahiert. Wenn Sie die Dienstprogrammlogs aus einem alternativen Speicherort extrahieren müssen, können Sie den Namen der Tabelle mit dem Flag -Dteradata-logs.utility-logs-table angeben.

Standardmäßig werden die Logs zur Ressourcennutzung aus den Tabellen dbc.ResUsageScpu und dbc.ResUsageSpma extrahiert. Wenn Sie die Logs zur Ressourcennutzung aus einem alternativen Speicherort extrahieren möchten, können Sie die Namen der Tabellen mit den Flags -Dteradata-logs.res-usage-scpu-table und -Dteradata-logs.res-usage-spma-table angeben.

Beispiel:

Bash

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  -Dteradata-logs.query-logs-table=pdcrdata.QryLogV_hst \
  -Dteradata-logs.sql-logs-table=pdcrdata.DBQLSqlTbl_hst \
  -Dteradata-logs.log-date-column=LogDate \
  -Dteradata-logs.utility-logs-table=pdcrdata.DBQLUtilityTbl_hst \
  -Dteradata-logs.res-usage-scpu-table=pdcrdata.ResUsageScpu_hst \
  -Dteradata-logs.res-usage-spma-table=pdcrdata.ResUsageSpma_hst

Windows PowerShell

dwh-migration-dumper `
  --connector teradata-logs `
  --driver path\terajdbc4.jar `
  --host HOST `
  --assessment `
  --user USER `
  --password PASSWORD `
  "-Dteradata-logs.query-logs-table=pdcrdata.QryLogV_hst" `
  "-Dteradata-logs.sql-logs-table=pdcrdata.DBQLSqlTbl_hst" `
  "-Dteradata-logs.log-date-column=LogDate" `
  "-Dteradata-logs.utility-logs-table=pdcrdata.DBQLUtilityTbl_hst" `
  "-Dteradata-logs.res-usage-scpu-table=pdcrdata.ResUsageScpu_hst" `
  "-Dteradata-logs.res-usage-spma-table=pdcrdata.ResUsageSpma_hst"

Standardmäßig extrahiert das dwh-migration-dumper-Tool die Abfragelogs der letzten sieben Tage. Google empfiehlt, Abfragelogs über mindestens zwei Wochen bereitzustellen, um umfangreichere Informationen zu erhalten. Mit den Flags --query-log-start und --query-log-end können Sie einen benutzerdefinierten Zeitraum festlegen. Beispiel:

dwh-migration-dumper \
  --connector teradata-logs \
  --driver path/terajdbc4.jar \
  --host HOST \
  --assessment \
  --user USER \
  --password PASSWORD \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-15 00:00:00"

Sie können auch mehrere ZIP-Dateien mit Abfragelogs generieren, die verschiedene Zeiträume abdecken, und alle zur Bewertung bereitstellen.

Amazon Redshift

Voraussetzungen

  • Eine Maschine, die mit Ihrem Amazon-Redshift-Quell-Data-Warehouse verbunden ist
  • Ein Google Cloud-Konto mit einem Cloud Storage-Bucket zum Speichern der Daten
  • Ein leeres BigQuery-Dataset zum Speichern der Ergebnisse
  • Leseberechtigungen für das Dataset, um die Ergebnisse aufzurufen
  • Empfohlen: Superuser-Zugriff auf die Datenbank, wenn das Extraktionstool für den Zugriff auf Systemtabellen verwendet wird

dwh-migration-dumper-Tool ausführen

Laden Sie das dwh-migration-dumper-Befehlszeilentool zur Extraktion herunter.

Laden Sie die Datei SHA256SUMS.txt herunter und führen Sie den folgenden Befehl aus, um die Richtigkeit der ZIP-Datei zu prüfen:

sha256sum --check SHA256SUMS.txt

Weitere Informationen zur Verwendung des dwh-migration-dumper-Tools finden Sie auf der Seite Metadaten generieren.

Verwenden Sie das dwh-migration-dumper-Tool, um Logs und Metadaten aus Ihrem Amazon Redshift-Data-Warehouse als zwei ZIP-Dateien zu extrahieren. Führen Sie die folgenden Befehle auf einem Computer mit Zugriff auf das Quell-Data-Warehouse aus, um die Dateien zu generieren.

Generieren Sie die Metadaten-ZIP-Datei:

dwh-migration-dumper \
  --connector redshift \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

Generieren Sie die ZIP-Datei mit den Abfragelogs:

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME

Ersetzen Sie Folgendes:

  • DATABASE: Der Name der Datenbank, zu der eine Verbindung hergestellt werden soll.
  • PATH: Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll.
  • VERSION: Die Version Ihres Treibers.
  • USER: Der Nutzername für die Datenbankverbindung.
  • IAM_PROFILE_NAME: der Amazon Redshift-IAM-Profilname. Erforderlich für die Amazon Redshift-Authentifizierung und für den AWS API-Zugriff. Verwenden Sie die AWS API, um die Beschreibung von Amazon Redshift-Clustern abzurufen.

Standardmäßig speichert Amazon Redshift Abfragelogs für drei bis fünf Tage.

Standardmäßig extrahiert das dwh-migration-dumper-Tool Abfragelogs der letzten sieben Tage.

Google empfiehlt, Abfragelogs über mindestens zwei Wochen bereitzustellen, um umfangreichere Informationen zu erhalten. Möglicherweise müssen Sie das Extraktionstool mehrmals innerhalb von zwei Wochen ausführen, um die besten Ergebnisse zu erzielen. Mit den Flags --query-log-start und --query-log-end können Sie einen benutzerdefinierten Bereich festlegen. Beispiel:

dwh-migration-dumper \
  --connector redshift-raw-logs \
  --database DATABASE \
  --driver PATH/redshift-jdbc42-VERSION.jar \
  --host host.region.redshift.amazonaws.com \
  --assessment \
  --user USER \
  --iam-profile IAM_PROFILE_NAME \
  --query-log-start "2023-01-01 00:00:00" \
  --query-log-end "2023-01-02 00:00:00"

Sie können auch mehrere ZIP-Dateien mit Abfragelogs generieren, die verschiedene Zeiträume abdecken, und alle zur Bewertung bereitstellen.

Apache Hive

Wenn Sie Feedback oder Unterstützung für dieses Feature benötigen, senden Sie eine E-Mail an bq-edw-migration-support@google.com.

Voraussetzungen

  • Maschine, die mit Ihrem Apache Hive-Data-Warehouse der Quelle verbunden ist (die BigQuery-Migrationsbewertung unterstützt Hive auf Tez und MapReduce und Apache Hive-Versionen zwischen 2.2 und 3.1 (einschließlich))
  • Ein Google Cloud-Konto mit einem Cloud Storage-Bucket zum Speichern der Daten
  • Ein leeres BigQuery-Dataset zum Speichern der Ergebnisse
  • Leseberechtigungen für das Dataset, um die Ergebnisse aufzurufen
  • Zugriff auf Ihr Apache Hive-Quell-Data-Warehouse zum Konfigurieren der Extraktion von Abfragelogs
  • Aktuelle Tabellen-, Partitions- und Spaltenstatistiken

Die BigQuery-Migrationsbewertung verwendet Tabellen-, Partitions- und Spaltenstatistiken, um Ihr Apache Hive-Data-Warehouse besser zu verstehen und umfassende Informationen zu liefern. Wenn die Konfigurationseinstellung hive.stats.autogather in Ihrem Apache Hive-Quell-Data-Warehouse auf false gesetzt ist, empfiehlt Google, sie zu aktivieren oder Statistiken manuell zu aktualisieren, bevor Sie das dwh-migration-dumper-Tool ausführen.

dwh-migration-dumper-Tool ausführen

Laden Sie das dwh-migration-dumper-Befehlszeilentool zur Extraktion herunter.

Laden Sie die Datei SHA256SUMS.txt herunter und führen Sie den folgenden Befehl aus, um die Richtigkeit der ZIP-Datei zu prüfen:

sha256sum --check SHA256SUMS.txt

Weitere Informationen zur Verwendung des dwh-migration-dumper-Tools finden Sie unter Metadaten für Übersetzung und Bewertung generieren.

Verwenden Sie das dwh-migration-dumper-Tool, um Metadaten aus Ihrem Hive-Data-Warehouse als ZIP-Datei zu generieren.

Ohne Authentifizierung

Führen Sie zum Generieren der Metadaten-ZIP-Datei den folgenden Befehl auf einem Computer aus, der Zugriff auf das Quell-Data-Warehouse hat:

dwh-migration-dumper \
  --connector hiveql \
  --database DATABASES \
  --host hive.cluster.host \
  --port 9083 \
  --assessment

Mit Kerberos-Authentifizierung

Melden Sie sich zur Authentifizierung beim Metastore als Nutzer an, der Zugriff auf den Hive-Metastore hat, und generieren Sie ein Kerberos-Ticket. Generieren Sie dann die Metadaten-ZIP-Datei mit dem folgenden Befehl:

JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" \
  dwh-migration-dumper \
  --connector hiveql \
  --database DATABASES \
  --host hive.cluster.host \
  --port 9083 \
  --hive-kerberos-url PRINCIPAL/HOST \
  -Dhiveql.rpc.protection=hadoop.rpc.protection \
  --assessment

Ersetzen Sie Folgendes:

  • DATABASES: eine durch Kommas getrennte Liste der Namen der zu extrahierenden Datenbank. Wenn nicht angegeben, werden alle Datenbanken extrahiert.
  • PRINCIPAL: das Kerberos-Hauptkonto für das das Ticket ausgestellt wird
  • HOST: der Kerberos-Hostname, für den das Ticket ausgestellt wird
  • hadoop.rpc.protection: die Qualität des Schutzes (QOP) der SASL-Konfigurationsebene (Simple Authentication and Security Layer), entspricht dem Wert des Parameters hadoop.rpc.protection in der /etc/hadoop/conf/core-site.xml-Datei mit einem der folgenden Werte:
    • authentication
    • integrity
    • privacy

Abfragelogs mit dem Logging-Hook hadoop-migration-assessment extrahieren

So extrahieren Sie Abfragelogs:

  1. Laden Sie den Logging-Hook hadoop-migration-assessment hoch.
  2. Konfigurieren Sie die Logging-Hook-Attribute.
  3. Überprüfen Sie den Logging-Hook.

Logging-Hook hadoop-migration-assessment hochladen

  1. Laden Sie den Logging-Hook hadoop-migration-assessment für die Abfragelog-Extraktion herunter, der die Hive-Logging-Hook-Datei enthält.

  2. Extrahieren Sie die JAR-Datei.

    Wenn Sie prüfen müssen, ob das Tool die Compliance-Anforderungen erfüllt, überprüfen Sie den Quellcode aus dem GitHub-Repository für den Logging-Hook hadoop-migration-assessment und kompilieren Sie Ihre eigene Binärdatei.

  3. Kopieren Sie die JAR-Datei in den Hilfsbibliotheksordner in allen Clustern, in denen Sie das Abfrage-Logging aktivieren möchten. Je nach Anbieter müssen Sie den Hilfsbibliotheksordner in den Clustereinstellungen suchen und die JAR-Datei in den Hilfsbibliotheksordner im Hive-Cluster übertragen.

  4. Richten Sie Konfigurationsattribute für den Logging-Hook hadoop-migration-assessment ein. Je nach Hadoop-Anbieter müssen Sie die Clustereinstellungen über die UI-Konsole bearbeiten. Ändern Sie die Datei /etc/hive/conf/hive-site.xml oder wenden Sie die Konfiguration mit dem Konfigurationsmanager an.

Attribute konfigurieren

Wenn Sie bereits andere Werte für die folgenden Konfigurationsschlüssel haben, hängen Sie die Einstellungen mit einem Komma an (,). Zum Einrichten des hadoop-migration-assessment-Logging-Hooks sind folgende Konfigurationseinstellungen erforderlich:

  • hive.exec.failure.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
  • hive.exec.post.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
  • hive.exec.pre.hooks: com.google.cloud.bigquery.dwhassessment.hooks.MigrationAssessmentLoggingHook
  • hive.aux.jars.path: Fügen Sie den Pfad zur JAR-Datei für den Logging-Hook hinzu, z. B. file:///HiveMigrationAssessmentQueryLogsHooks_deploy.jar.
  • dwhassessment.hook.base-directory: der Pfad zum Ausgabeordner der Abfragelogs. Beispiel: hdfs://tmp/logs/.
  • Sie können auch die folgenden optionalen Konfigurationen festlegen:

    • dwhassessment.hook.queue.capacity: die Warteschlangenkapazität für die Logging-Threads für Abfrageereignisse. Der Standardwert ist 64.
    • dwhassessment.hook.rollover-interval: die Häufigkeit, mit der die Datei-Übertragung ausgeführt werden soll. Beispiel: 600s. Der Standardwert beträgt 3.600 Sekunden (1 Stunde).
    • dwhassessment.hook.rollover-eligibility-check-interval: die Häufigkeit, mit der die Berechtigungsprüfung der Datei-Übertragung im Hintergrund ausgelöst wird. Beispiel: 600s. Der Standardwert beträgt 600 Sekunden (10 Minuten).

Logging-Hook überprüfen

Nachdem Sie den Prozess hive-server2 neu gestartet haben, führen Sie eine Testabfrage aus und analysieren Ihre Debugging-Logs. Die folgende Meldung wird angezeigt:

Logger successfully started, waiting for query events. Log directory is '[dwhassessment.hook.base-directory value]'; rollover interval is '60' minutes;
rollover eligibility check is '10' minutes

Der Logging-Hook erstellt einen datumspartitionierten Unterordner im konfigurierten Ordner. Die Avro-Datei mit Abfrageereignissen wird nach der Beendigung des Prozesses dwhassessment.hook.rollover-interval oder des Prozesses hive-server2 in diesem Ordner angezeigt. Sie können in Ihren Debugging-Logs nach ähnlichen Einträgen suchen, um den Status der Übertragung zu sehen:

Updated rollover time for logger ID 'my_logger_id' to '2023-12-25T10:15:30'
Performed rollover check for logger ID 'my_logger_id'. Expected rollover time
is '2023-12-25T10:15:30'

Die Übertragung erfolgt in den angegebenen Intervallen oder wenn sich der Tag ändert. Wenn sich das Datum ändert, erstellt der Logging-Hook auch einen neuen Unterordner für dieses Datum.

Google empfiehlt, Abfragelogs über mindestens zwei Wochen bereitzustellen, um umfangreichere Informationen zu erhalten.

Sie können auch Ordner mit Abfragelogs aus verschiedenen Hive-Clustern generieren und alle für eine einzelne Bewertung bereitstellen.

Snowflake

Voraussetzungen

Sie müssen die folgenden Anforderungen erfüllen, um Metadaten und Abfragelogs aus Snowflake zu extrahieren:

  • Eine Maschine, die eine Verbindung zu Ihrer Snowflake-Instanz herstellen kann.
  • Ein Google Cloud-Konto mit einem Cloud Storage-Bucket zum Speichern der Daten.
  • Ein leeres BigQuery-Dataset zum Speichern der Ergebnisse. Alternativ können Sie ein BigQuery-Dataset erstellen, wenn Sie den Bewertungsjob über die Google Cloud Console-UI erstellen.
  • Zugriff auf die Rolle ACCOUNTADMIN für Ihre Snowflake-Instanz oder eine von einem Kontoadministrator gewährte Rolle mit den IMPORTED PRIVILEGES-Berechtigungen für die Datenbank Snowflake.

dwh-migration-dumper-Tool ausführen

Laden Sie das dwh-migration-dumper-Befehlszeilentool zur Extraktion herunter.

Laden Sie die Datei SHA256SUMS.txt herunter und führen Sie den folgenden Befehl aus, um die Richtigkeit der ZIP-Datei zu prüfen:

sha256sum --check SHA256SUMS.txt

Weitere Informationen zur Verwendung des dwh-migration-dumper-Tools finden Sie auf der Seite Metadaten generieren.

Verwenden Sie das dwh-migration-dumper-Tool, um Logs und Metadaten aus Ihrem Snowflake-Data-Warehouse als zwei ZIP-Dateien zu extrahieren. Führen Sie die folgenden Befehle auf einem Computer mit Zugriff auf das Quell-Data-Warehouse aus, um die Dateien zu generieren.

Generieren Sie die Metadaten-ZIP-Datei:

dwh-migration-dumper \
  --connector snowflake \
  --host HOST_NAME \
  --database SNOWFLAKE \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --assessment \
  --password PASSWORD

Generieren Sie die ZIP-Datei mit den Abfragelogs:

dwh-migration-dumper \
  --connector snowflake-logs \
  --host HOST_NAME \
  --database SNOWFLAKE \
  --user USER_NAME \
  --role ROLE_NAME \
  --warehouse WAREHOUSE \
  --query-log-start STARTING_DATE \
  --query-log-end ENDING_DATE \
  --assessment \
  --password PASSWORD

Ersetzen Sie Folgendes:

  • HOST_NAME: der Hostname Ihrer Snowflake-Instanz.
  • USER_NAME: der Nutzername für die Datenbankverbindung, wobei der Nutzer die Zugriffsberechtigungen haben muss, die im Abschnitt Anforderungen beschrieben sind.
  • ROLE_NAME: (Optional) die Nutzerrolle beim Ausführen des dwh-migration-dumper-Tools, z. B. ACCOUNTADMIN.
  • WAREHOUSE: das Warehouse zum Ausführen der Verschiebevorgänge. Wenn Sie mehrere virtuelle Warehouses haben, können Sie ein beliebiges Warehouse angeben, um diese Abfrage auszuführen. Wenn Sie diese Abfrage mit den im Abschnitt Anforderungen beschriebenen Zugriffsberechtigungen ausführen, werden alle Warehouse-Artefakte in diesem Konto extrahiert.
  • STARTING_DATE: (Optional) wird verwendet, um das Startdatum in einem Zeitraum von Abfragelogs im Format YYYY-MM-DD anzugeben.
  • ENDING_DATE: (Optional) wird verwendet, um das Enddatum in einem Zeitraum von Abfragelogs im Format YYYY-MM-DD anzugeben.

Sie können auch mehrere ZIP-Dateien mit Abfragelogs generieren, die nicht-überlappende Zeiträume abdecken, und alle zur Bewertung bereitstellen.

Metadaten und Abfragelogs in Cloud Storage hochladen

Nachdem Sie die Metadaten und Abfragelogs aus Ihrem Data Warehouse extrahiert haben, können Sie die Dateien in einen Cloud Storage-Bucket hochladen, um mit der Migrationsbewertung fortzufahren.

Teradata

Laden Sie die Metadaten und eine oder mehrere ZIP-Dateien mit Abfragelogs in Ihren Cloud Storage-Bucket hoch. Weitere Informationen zum Erstellen von Buckets und zum Hochladen von Dateien in Cloud Storage erhalten Sie unter Buckets erstellen und Objekte aus einem Dateisystem hochladen. Das Limit für die unkomprimierte Gesamtgröße aller Dateien in der Metadaten-Zip-Datei beträgt 50 GB.

Die Einträge in allen ZIP-Dateien, die Abfragelogs enthalten, sind so unterteilt:

  • Abfrageverlaufsdateien mit dem Präfix query_history_.
  • Zeitachsendateien mit den Präfixen utility_logs_, dbc.ResUsageScpu_ und dbc.ResUsageSpma_.

Das Limit für die unkomprimierte Gesamtgröße aller Abfrageverlaufsdateien beträgt 5 TB. Das Limit für die unkomprimierte Gesamtgröße aller Zeitachsendateien beträgt 1 TB.

Wenn die Abfragelogs in einer anderen Datenbank archiviert werden, lesen Sie die Beschreibung des Flags -Dteradata-logs.query-logs-table und -Dteradata-logs.sql-logs-table weiter oben in diesem Abschnitt, in dem erläutert wird, wie Sie einen alternativen Speicherort für die Abfragelogs angeben.

Amazon Redshift

Laden Sie die Metadaten und eine oder mehrere ZIP-Dateien mit Abfragelogs in Ihren Cloud Storage-Bucket hoch. Weitere Informationen zum Erstellen von Buckets und zum Hochladen von Dateien in Cloud Storage erhalten Sie unter Buckets erstellen und Objekte aus einem Dateisystem hochladen. Das Limit für die unkomprimierte Gesamtgröße aller Dateien in der Metadaten-Zip-Datei beträgt 50 GB.

Die Einträge in allen ZIP-Dateien, die Abfragelogs enthalten, sind so unterteilt:

  • Abfrageverlaufsdateien mit den Präfixen querytext_ und ddltext_.
  • Zeitachsendateien mit den Präfixen query_queue_info_, wlm_query_ und querymetrics_.

Das Limit für die unkomprimierte Gesamtgröße aller Abfrageverlaufsdateien beträgt 5 TB. Das Limit für die unkomprimierte Gesamtgröße aller Zeitachsendateien beträgt 1 TB.

Apache Hive

Wenn Sie Feedback oder Unterstützung für dieses Feature benötigen, senden Sie eine E-Mail an bq-edw-migration-support@google.com.

Laden Sie die Metadaten und Ordner mit Abfragelogs aus einem oder mehreren Hive-Clustern in Ihren Cloud Storage-Bucket hoch. Weitere Informationen zum Erstellen von Buckets und zum Hochladen von Dateien in Cloud Storage erhalten Sie unter Buckets erstellen und Objekte aus einem Dateisystem hochladen.

Das Limit für die unkomprimierte Gesamtgröße aller Dateien in der Metadaten-Zip-Datei beträgt 50 GB.

Mit dem Cloud Storage-Connector können Sie Abfrage-Logs direkt in den Cloud Storage-Ordner kopieren. Die Ordner mit Unterordnern mit Abfragelogs müssen in denselben Cloud Storage-Ordner hochgeladen werden, in den auch die Metadaten-ZIP-Datei hochgeladen wird.

Abfragelog-Ordner haben Abfrageverlaufsdateien mit dem Präfix dwhassessment_. Das Limit für die unkomprimierte Gesamtgröße aller Abfrageverlaufsdateien beträgt 5 TB.

Snowflake

Laden Sie die Metadaten und die ZIP-Datei(en) mit Abfragelogs und Nutzungsverlauf in den Cloud Storage-Bucket hoch. Beim Hochladen dieser Dateien in Cloud Storage müssen die folgenden Anforderungen erfüllt sein:

  • Die unkomprimierte Gesamtgröße aller Dateien in der Metadaten-ZIP-Datei darf maximal 50 GB betragen.
  • Die Metadaten-ZIP-Datei und die ZIP-Datei mit Abfragelogs müssen in einen Cloud Storage-Ordner hochgeladen werden. Wenn Sie mehrere ZIP-Dateien mit nicht überlappenden Abfragelogs haben, können Sie alle hochladen.
  • Sie müssen alle Dateien in denselben Cloud Storage-Ordner hochladen.
  • Sie müssen alle ZIP-Dateien mit Metadaten und Abfragelogs genau so hochladen, wie sie vom dwh-migration-dumper-Tool ausgegeben werden. Entpacken, kombinieren oder ändern Sie sie nicht.
  • Die unkomprimierte Gesamtgröße aller Abfrageverlaufsdateien muss kleiner als 5 TB sein.

Weitere Informationen zum Erstellen von Buckets und zum Hochladen von Dateien in Cloud Storage erhalten Sie unter Buckets erstellen und Objekte aus einem Dateisystem hochladen.

BigQuery-Migrationsbewertung ausführen

Führen Sie die folgenden Schritte aus, um die BigQuery-Migrationsbewertung auszuführen. Bei diesen Schritten wird davon ausgegangen, dass Sie die Metadatendateien in einen Cloud Storage-Bucket hochgeladen haben, wie im vorherigen Abschnitt beschrieben.

Erforderliche Berechtigungen

Zum Aktivieren des BigQuery Migration Service benötigen Sie die folgenden IAM-Berechtigungen (Identity and Access Management):

  • resourcemanager.projects.get
  • resourcemanager.projects.update
  • serviceusage.services.enable
  • serviceusage.services.get

Für den Zugriff auf den BigQuery Migration Service und dessen Verwendung benötigen Sie die folgenden Berechtigungen für das Projekt:

  • bigquerymigration.workflows.create
  • bigquerymigration.workflows.get
  • bigquerymigration.workflows.list
  • bigquerymigration.workflows.delete
  • bigquerymigration.subtasks.get
  • bigquerymigration.subtasks.list

Zum Ausführen von BigQuery Migration Service benötigen Sie außerdem die folgenden Berechtigungen.

  • Berechtigungen zum Zugreifen auf die Cloud Storage-Buckets für Eingabe- und Ausgabedateien:

    • storage.objects.get für den Cloud Storage-Quell-Bucket
    • storage.objects.list für den Cloud Storage-Quell-Bucket
    • storage.objects.create für den Cloud Storage-Ziel-Bucket
    • storage.objects.delete für den Cloud Storage-Ziel-Bucket
    • storage.objects.update für den Cloud Storage-Ziel-Bucket
    • storage.buckets.get
    • storage.buckets.list
  • Berechtigung zum Lesen und Aktualisieren des BigQuery-Datasets, in das der BigQuery-Migrationsdienst die Ergebnisse schreibt:

    • bigquery.datasets.update
    • bigquery.datasets.get
    • bigquery.datasets.create
    • bigquery.datasets.delete
    • bigquery.jobs.create
    • bigquery.jobs.delete
    • bigquery.jobs.list
    • bigquery.jobs.update
    • bigquery.tables.create
    • bigquery.tables.get
    • bigquery.tables.getData
    • bigquery.tables.list
    • bigquery.tables.updateData

Um einen Looker Studio-Bericht für einen Nutzer freizugeben, müssen Sie die folgenden Rollen zuweisen:

  • roles/bigquery.dataViewer
  • roles/bigquery.jobUser

Wenn Sie dieses Dokument anpassen möchten, um Ihr eigenes Projekt und Ihren eigenen Nutzer in den Befehlen zu verwenden, bearbeiten Sie diese Variablen: PROJECT, USER_EMAIL.

Erstellen Sie eine benutzerdefinierte Rolle mit den Berechtigungen, die zum Verwenden der BigQuery-Migrationsbewertung erforderlich sind:

gcloud iam roles create BQMSrole \
  --project=PROJECT \
  --title=BQMSrole \
  --permissions=bigquerymigration.subtasks.get,bigquerymigration.subtasks.list,bigquerymigration.workflows.create,bigquerymigration.workflows.get,bigquerymigration.workflows.list,bigquerymigration.workflows.delete,resourcemanager.projects.update,resourcemanager.projects.get,serviceusage.services.enable,serviceusage.services.get,storage.objects.get,storage.objects.list,storage.objects.create,storage.objects.delete,storage.objects.update,bigquery.datasets.get,bigquery.datasets.update,bigquery.datasets.create,bigquery.datasets.delete,bigquery.tables.get,bigquery.tables.create,bigquery.tables.updateData,bigquery.tables.getData,bigquery.tables.list,bigquery.jobs.create,bigquery.jobs.update,bigquery.jobs.list,bigquery.jobs.delete,storage.buckets.list,storage.buckets.get

Benutzerdefinierte Rolle BQMSrole einem Nutzer erteilen:

gcloud projects add-iam-policy-binding \
  PROJECT \
  --member=user:USER_EMAIL \
  --role=projects/PROJECT/roles/BQMSrole

Weisen Sie einem Nutzer, für den Sie den Bericht freigeben möchten, die erforderlichen Rollen zu:

gcloud projects add-iam-policy-binding \
  PROJECT \
  --member=user:USER_EMAIL \
  --role=roles/bigquery.dataViewer

gcloud projects add-iam-policy-binding \
  PROJECT \
  --member=user:USER_EMAIL \
  --role=roles/bigquery.jobUser

Unterstützte Standorte

Das Feature zur Migrationsbewertung von BigQuery wird an zwei Arten von Standorten unterstützt:

  • Eine Region ist ein bestimmter geografischer Ort, wie z. B. London.

  • Eine Multiregion ist ein großes geografisches Gebiet (beispielsweise die USA), das mindestens zwei geografische Regionen enthält. Multiregionale Standorte können größere Kontingente bieten als einzelne Regionen.

Weitere Informationen zu Regionen und Zonen finden Sie unter Geografie und Regionen.

Regionen

In der folgenden Tabelle sind die Regionen in Amerika aufgeführt, in denen die BigQuery-Migrationsbewertung verfügbar ist.
Beschreibung der Region Name der Region Details
Columbus, Ohio us-east5
Dallas us-south1 Blattsymbol Niedriger CO2-Wert
Iowa us-central1 Blattsymbol Niedriger CO2-Wert
South Carolina us-east1
Northern Virginia us-east4
Oregon us-west1 Blattsymbol Niedriger CO2-Wert
Los Angeles us-west2
Salt Lake City us-west3
In der folgenden Tabelle sind die Regionen im asiatisch-pazifischen Raum aufgeführt, in denen die BigQuery-Migrationsbewertung verfügbar ist.
Beschreibung der Region Name der Region Details
Singapur asia-southeast1
Tokio asia-northeast1
In der folgenden Tabelle sind die Regionen in Europa aufgeführt, in denen die BigQuery-Migrationsbewertung verfügbar ist.
Beschreibung der Region Name der Region Details
Belgien europe-west1 Blattsymbol Niedriger CO2-Wert
Finnland europe-north1 Blattsymbol Niedriger CO2-Wert
Frankfurt europe-west3 Blattsymbol Niedriger CO2-Wert
London europe-west2 Blattsymbol Niedriger CO2-Wert
Madrid europe-southwest1 Blattsymbol Niedriger CO2-Wert
Niederlande europe-west4 Blattsymbol Niedriger CO2-Wert
Paris europe-west9 Blattsymbol Niedriger CO2-Wert
Turin europe-west12
Warschau europe-central2
Zürich europe-west6 Blattsymbol Niedriger CO2-Wert

Multiregionen

In der folgenden Tabelle sind die Multiregionen aufgeführt, in denen die BigQuery-Migrationsbewertung verfügbar ist.
Beschreibung des multiregionalen Standorts Name des multiregionalen Standorts
Rechenzentren in Mitgliedsstaaten der Europäischen Union EU
Rechenzentren in den USA US

Hinweise

Bevor Sie die Bewertung ausführen, müssen Sie die BigQuery Migration API aktivieren und ein BigQuery-Dataset erstellen, um die Ergebnisse der Bewertung zu speichern.

BigQuery Migration API aktivieren

Aktivieren Sie die BigQuery Migration API wie im Folgenden dargestellt:

  1. Rufen Sie in der Google Cloud Console die Seite BigQuery Migration API auf.

    Zu „BigQuery Migration API“

  2. Klicken Sie auf Aktivieren.

Dataset für die Bewertungsergebnisse erstellen

Die BigQuery-Migrationsbewertung schreibt die Bewertungsergebnisse in Tabellen in BigQuery. Erstellen Sie zuerst ein Dataset, in dem die Tabellen gespeichert werden. Wenn Sie den Looker Studio-Bericht freigeben, müssen Sie Nutzern auch die Berechtigung zum Lesen dieses Datasets erteilen. Weitere Informationen finden Sie unter Bericht für Nutzer bereitstellen.

Migrationsbewertung ausführen

Console

  1. Öffnen Sie in der Google Cloud Console die Seite BigQuery.

    BigQuery aufrufen

  2. Gehen Sie im Navigationsbereich zu Bewertung.

  3. Klicken Sie auf Bewertung starten.

  4. Füllen Sie das Dialogfeld für die Bewertungskonfiguration aus.

    1. Geben Sie als Anzeigename einen Namen ein. Er darf Buchstaben, Ziffern oder Unterstriche enthalten. Dieser Name dient nur Anzeigezwecken und muss nicht eindeutig sein.
    2. Wählen Sie in der Liste Datenspeicherort einen Speicherort für den Bewertungsjob aus. Der Bewertungsjob muss sich am selben Speicherort wie der Cloud Storage-Bucket der extrahierten Dateien und das BigQuery-Ausgabe-Dataset befinden.

      Wenn dieser Standort jedoch eine Multi-Region US oder EU ist, können sich der Standort des Cloud Storage-Buckets und der BigQuery-Dataset-Speicherort in einer der Regionen innerhalb dieser Multiregion befinden. Der Cloud Storage-Bucket und das BigQuery-Dataset können sich an verschiedenen Standorten innerhalb derselben Multi-Region befinden. Wenn Sie beispielsweise die Multiregion US auswählen, kann sich der Cloud Storage-Bucket in der Region us-central1 befinden, während sich das BigQuery-Dataset in der Region us-east1 befinden kann.

    3. Wählen Sie für Datenquelle für Bewertung Ihr Data Warehouse aus.

    4. Geben Sie unter Pfad zu Eingabedateien den Pfad zu dem Cloud Storage-Bucket ein, der Ihre extrahierten Dateien enthält.

    5. Führen Sie eine der folgenden Optionen aus, um auszuwählen, wie die Bewertungsergebnisse gespeichert werden:

      • Lassen Sie das Kästchen Neues BigQuery-Dataset automatisch erstellen angeklickt, damit das BigQuery-Dataset automatisch erstellt wird. Der Name des Datasets wird automatisch generiert.
      • Entfernen Sie das Häkchen aus dem Kästchen Neues BigQuery-Dataset automatisch erstellen und wählen Sie entweder das vorhandene leere BigQuery-Dataset im Format projectId.datasetId aus oder erstellen Sie einen neuen Dataset-Namen. In dieser Option können Sie den Namen des BigQuery-Datasets auswählen.

    Option 1: Automatische BigQuery-Dataset-Generierung (Standard) Dialogfeld zur Konfiguration von Bewertungen

    Option 2: BigQuery-Dataset manuell erstellen: Dialogfeld zur Konfiguration von Bewertungen mit manueller Dataset-Erstellung

  5. Klicken Sie auf Erstellen. Der Status des Jobs wird in der Liste der Bewertungsjobs angezeigt.

    Während die Bewertung ausgeführt wird, können Sie den Fortschritt und die geschätzte Zeit bis zum Abschluss in der Kurzinfo des Statussymbols prüfen.

    Bewertungsfortschritt in der Kurzinfo.

  6. Während die Bewertung ausgeführt wird, können Sie in der Liste der Bewertungsjobs auf den Link Bericht ansehen klicken, um den Bewertungsbericht mit unvollständigen Daten in Looker Studio aufzurufen. Es kann einige Zeit dauern, bis der Link Bericht aufrufen angezeigt wird, während die Bewertung ausgeführt wird. Der Bericht wird in einem neuen Tab geöffnet.

    Der Bericht wird während der Verarbeitung mit neuen Daten aktualisiert. Aktualisieren Sie den Tab mit dem Bericht oder klicken Sie noch einmal auf Bericht aufrufen, um den aktualisierten Bericht aufzurufen.

  7. Klicken Sie nach Abschluss der Bewertung auf Bericht ansehen, um den vollständigen Bewertungsbericht in Looker Studio aufzurufen. Der Bericht wird in einem neuen Tab geöffnet.

API

Rufen Sie die Methode create mit einem definierten Workflow auf.

Rufen Sie dann die Methode start auf, um den Bewertungs-Workflow zu starten.

Die Bewertung erstellt Tabellen im BigQuery-Dataset, das Sie zuvor erstellt haben. Sie können diese Informationen zu den Tabellen und Abfragen abfragen, die in Ihrem vorhandenen Data Warehouse verwendet werden. Informationen zu den Ausgabedateien der Übersetzung finden Sie unter Batch SQL-Übersetzer.

Teilbares aggregiertes Bewertungsergebnis

Wenn Sie Unterstützung während der Vorschau benötigen, senden Sie eine E-Mail an bq-edw-migration-support@google.com.

Für Amazon Redshift-, Teradata- und Snowflake-Bewertungen erstellt der Workflow neben dem zuvor erstellten BigQuery-Dataset ein weiteres einfaches Dataset mit demselben Namen sowie dem Suffix _shareableRedactedAggregate. Dieses Dataset enthält stark aggregierte Daten, die aus dem Ausgabe-Dataset abgeleitet werden, und enthält keine personenidentifizierbaren Informationen.

Informationen zum Suchen, Prüfen und sicheren Freigeben des Datasets für andere Nutzer finden Sie unter Ausgabetabellen der Migrationsbewertung abfragen.

Die Funktion ist standardmäßig aktiviert, kann aber über die öffentliche API deaktiviert werden.

Informationen zur Prüfung

Klicken Sie zum Aufrufen der Seite mit den Bewertungsdetails auf den Anzeigenamen in der Liste der Bewertungsjobs.

Seite mit Liste der Bewertungen

Die Seite mit den Bewertungsdetails enthält den Tab Konfiguration, auf dem Sie weitere Informationen zu einem Bewertungsjob aufrufen können, und den Tab Fehler, auf dem Sie alle Fehler, die während der Bewertungsverarbeitung aufgetreten sind.

Rufen Sie den Tab Konfiguration auf, um die Attribute der Bewertung aufzurufen.

Seite mit den Bewertungsdetails – Tab „Konfiguration“.

Rufen Sie den Tab Fehler auf, um die Fehler anzuzeigen, die während der Bewertungsverarbeitung aufgetreten sind.

Seite mit Bewertungsdetails – Tab „Fehler“.

Looker Studio-Bericht erstellen und freigeben

Nach Abschluss der Bewertungsaufgaben können Sie einen Looker Studio-Bericht mit den Ergebnissen erstellen und freigeben.

Bericht ansehen

Klicken Sie neben der jeweiligen Bewertungsaufgabe auf den Link Bericht ansehen. Der Looker Studio-Bericht wird in einem neuen Tab im Vorschaumodus geöffnet. Sie können den Vorschaumodus verwenden, um den Inhalt des Berichts zu prüfen, bevor Sie ihn weiter freigeben.

Der Bericht sieht ungefähr so aus:

Bewertungsbericht.

Wählen Sie Ihr Data Warehouse aus, um zu sehen, welche Ansichten im Bericht enthalten sind:

Teradata

Der Bericht besteht aus drei Teilen, dem eine Seite mit einer Übersicht der Highlights vorangestellt ist. Diese Seite enthält die folgenden Abschnitte:

  • Vorhandenes System. Dieser Abschnitt ist ein Snapshot des vorhandenen Teradata-Systems und der vorhandenen Nutzung, einschließlich der Anzahl der Datenbanken, Schemas, Tabellen und der Gesamtgröße (in TB). Außerdem werden die Schemas nach Größe aufgelistet und auf eine potenzielle suboptimale Ressourcennutzung (Tabellen ohne Schreibvorgänge oder wenige Lesevorgänge verweist).
  • BigQuery stabiler Zustand – Transformationen (Vorschläge). Dieser Abschnitt zeigt, wie das System nach der Migration in BigQuery aussieht. Er enthält Vorschläge zur Optimierung von Arbeitslasten in BigQuery (und Vermeidung von unnötiger Inanspruchnahme).
  • Migrationsplan. Dieser Abschnitt enthält Informationen zum Migrationsaufwand selbst, z. B. zum Wechsel vom vorhandenen System zum stabilen Zustand von BigQuery. In diesem Abschnitt werden die Anzahl der automatisch übersetzten Abfragen und die erwartete Zeit zum Verschieben der einzelnen Tabellen in BigQuery angegeben.

Die einzelnen Abschnitte umfassen folgende Details:

Vorhandenes System.

  • Computing und Abfragen
    • CPU-Auslastung:
      • Heatmap der stündlichen durchschnittlichen CPU-Auslastung (Gesamtansicht der Systemressourcenauslastung)
      • Abfragen nach Stunde und Tag mit CPU-Auslastung
      • Abfragen nach Typ (Lesen/Schreiben) mit CPU-Auslastung
      • Anwendungen mit CPU-Auslastung
      • Overlay der stündlichen CPU-Auslastung mit durchschnittlicher stündlicher Abfrageleistung und durchschnittlicher stündlicher Anwendungsleistung
    • Abfragehistogramm nach Typ und Abfragedauer
    • Anwendungsdetailansicht (Anwendung, Nutzer, eindeutige Abfragen, Berichterstellung und ETL-Aufschlüsselung)
  • Speicherübersicht
    • Datenbanken nach Volumen, Ansichten und Zugriffsraten
    • Tabellen mit Zugriffsraten nach Nutzern, Abfragen, Schreibvorgängen und dem Erstellen temporärer Tabellen
  • Anwendungen: Zugriffsraten und IP-Adressen

BigQuery stabiler Zustand – Transformationen (Vorschläge)

  • Join-Indexe in materialisierte Ansichten konvertiert
  • Clustering und Partitionierung von Kandidaten nach Metadaten und Nutzung
  • Abfragen mit niedriger Latenz, die als Kandidaten für BigQuery BI Engine identifiziert wurden
  • Mit Standardwerten konfigurierte Spalten, die das Feature zur Spaltenbeschreibung zum Speichern von Standardwerten verwenden
  • Eindeutige Indexe in Teradata (um Zeilen mit nicht eindeutigen Schlüsseln in einer Tabelle zu verhindern) verwenden Staging-Tabellen und eine MERGE-Anweisung, um nur eindeutige Einträge in die Zieltabellen einzufügen und dann Duplikate zu verwerfen.
  • Verbleibende Abfragen und Schema, unverändert übersetzt

Migrationsplan

  • Detaillierte Ansicht mit automatisch übersetzten Abfragen
    • Gesamtzahl der Abfragen mit Filterung nach Nutzer, Anwendung, betroffenen Tabellen, abgefragten Tabellen und Abfragetyp
    • Buckets von Abfragen mit ähnlichen Mustern, die gruppiert und zusammen angezeigt werden, sodass der Nutzer die Übersetzungsphilosophie nach Abfragetyp sehen kann.
  • Abfragen, die menschliches Eingreifen erfordern
    • Abfragen mit Verstößen gegen die lexikalische BigQuery-Struktur
    • Benutzerdefinierte Funktionen und Verfahren
    • Reservierte BigQuery-Keywords
  • Tabellen werden nach Schreib- und Lesevorgängen gruppiert, um sie zum Verschieben zu gruppieren.
  • Datenmigration mit BigQuery Data Transfer Service: Geschätzte Migrationszeit nach Tabelle

Der Abschnitt Vorhandenes System enthält die folgenden Ansichten:

Systemübersicht
Die Systemübersicht bietet eine allgemeine Übersicht über die Volume-Messwerte der Schlüsselkomponenten im vorhandenen System für einen bestimmten Zeitraum. Die auszuwertende Zeitachse hängt von den Logs ab, die von der BigQuery-Migrationsbewertung analysiert wurden. In dieser Ansicht erhalten Sie einen schnellen Einblick in die Nutzung des Quell-Data-Warehouse, das für die Migrationsplanung verwendet werden kann.
Tabellen-Volumen
Die Ansicht „Tabellen-Volume“ enthält Statistiken zu den größten Tabellen und Datenbanken, die von der BigQuery-Migrationsbewertung gefunden wurden. Da das Extrahieren großer Tabellen aus dem Quell-Data-Warehouse-System länger dauern kann, kann diese Ansicht bei der Migrationsplanung und -sequenzierung hilfreich sein.
Tabellennutzung
Die Ansicht „Tabellennutzung“ enthält Statistiken zu den Tabellen, die im Quell-Data-Warehouse-System stark genutzt werden. Anhand der Statistiken zu stark genutzten Tabellen können Sie verstehen, welche Tabellen möglicherweise viele Abhängigkeiten haben und eine zusätzliche Planung während des Migrationsprozesses erfordern.
Anwendungen
Die Ansichten "Anwendungsnutzung" und "Anwendungsmuster" enthalten Statistiken zu Anwendungen, die während der Verarbeitung von Logs gefunden wurden. Diese Ansichten ermöglichen Nutzern, die Nutzung bestimmter Anwendungen im Zeitverlauf und die Auswirkungen auf die Ressourcennutzung zu verstehen. Während einer Migration ist es wichtig, die Aufnahme und Nutzung von Daten zu visualisieren, um die Abhängigkeiten des Data Warehouse besser zu verstehen und die Auswirkungen der gemeinsamen Migration verschiedener abhängiger Anwendungen zu analysieren. Die IP-Adresstabelle kann nützlich sein, um die genaue Anwendung mit dem Data Warehouse über JDBC-Verbindungen zu bestimmen.
Abfragen
Die Abfrageansicht enthält eine Aufschlüsselung der ausgeführten SQL-Anweisungen und Statistiken zu deren Nutzung. Sie können das Histogramm für Abfragetyp und -zeit verwenden, um niedrige Zeiträume der Systemauslastung und optimale Tageszeiten für die Datenübertragung zu ermitteln. Sie können diese Ansicht auch verwenden, um häufig ausgeführte Abfragen und die Nutzer zu bestimmen, die diese Ausführungen aufrufen.
Datenbanken
Die Ansicht der Datenbanken enthält Messwerte zur Größe, Tabellen, Ansichten und im Quell-Data-Warehouse definierte Verfahren. Diese Ansicht bietet Einblick in das Volumen der zu migrierenden Objekte.
Datenbankkopplung
Die Ansicht "Datenbankkopplung" bietet eine allgemeine Ansicht der Datenbanken und Tabellen, auf die in einer einzigen Abfrage zugegriffen wird. Diese Ansicht kann zeigen, auf welche Tabellen und Datenbanken häufig verwiesen wird und was Sie für die Migrationsplanung verwenden können.

Der Abschnitt BigQuery stabiler Zustand enthält die folgenden Ansichten:

Tabellen ohne Nutzung
In der Ansicht „Keine Nutzung“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während der Analyse des Logzeitraums keine Nutzung finden konnte. Eine mangelnde Nutzung kann darauf hinweisen, dass Sie diese Tabelle während der Migration nicht zu BigQuery übertragen müssen oder dass die Kosten für die Speicherung von Daten in BigQuery niedriger sein können. Sie sollten die Liste der nicht verwendeten Tabellen validieren, da sie außerhalb des Logzeitraums verwendet werden könnten, z. B. eine Tabelle, die nur alle drei oder sechs Monate verwendet wird.
Tabellen ohne Schreibvorgänge
In der Ansicht „Tabellen ohne Schreibvorgänge“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während des Analysezeitraums keine Aktualisierungen finden konnte. Fehlende Schreibvorgänge können darauf hinweisen, dass Sie die Speicherkosten in BigQuery senken können.
Abfragen mit niedriger Latenz
In der Ansicht „Abfragen mit niedriger Latenz“ wird eine Verteilung der Abfragelaufzeiten basierend auf den analysierten Logdaten angezeigt. Wenn das Diagramm zur Verteilung der Abfragedauer eine große Anzahl von Abfragen mit weniger als 1 Sekunde anzeigt, sollten Sie BigQuery BI Engine aktivieren, um BI- und andere Arbeitslasten mit niedriger Latenz zu beschleunigen.
Materialisierte Ansichten
Die materialisierte Ansicht bietet weitere Optimierungsvorschläge, um die Leistung in BigQuery zu verbessern.
Clustering und Partitionierung

Die Ansicht "Partitionierung und Clustering" enthält Tabellen, die von Partitionierung, Clustering oder beidem profitieren würden.

Die Metadatenvorschläge werden dadurch erreicht, dass das Schema des Quelldatenspeichers (Partitionierung und Primärschlüssel in der Quelltabelle) analysiert und das nächstgelegene BigQuery-Äquivalent ermittelt wird, um ähnliche Optimierungsmerkmale zu erreichen.

Die Arbeitslastvorschläge werden durch die Analyse der Quellabfragelogs erreicht. Die Empfehlung wird durch die Analyse der Arbeitslasten ermittelt, insbesondere durch die Klauseln WHERE oder JOIN in den analysierten Abfragelogs.

Clustering-Empfehlung

Die Partitionierungsansicht zeigt Tabellen an, die je nach ihrer Definition zur Partitionierungseinschränkung mehr als 10.000 Partitionen haben können. Diese Tabellen sind in der Regel gute Kandidaten für BigQuery-Clustering, das eine detaillierte Tabellenpartitionierung ermöglicht.

Eindeutige Einschränkungen

In der Ansicht „Eindeutige Einschränkungen“ werden sowohl die SET-Tabellen als auch die eindeutigen Indexe im Quell-Data-Warehouse angezeigt. In BigQuery wird empfohlen, Staging-Tabellen und eine MERGE-Anweisung zu verwenden, um nur eindeutige Einträge in eine Zieltabelle einzufügen. Verwenden Sie den Inhalt dieser Ansicht, um festzustellen, für welche Tabellen Sie während der Migration möglicherweise die ETL anpassen müssen.

Standardwerte/Diagnoseeinschränkungen

Diese Ansicht zeigt Tabellen, in denen Diagnoseeinschränkungen zum Festlegen von Standardspaltenwerten verwendet werden. Weitere Informationen in BigQuery finden Sie unter Standardspaltenwerte angeben.

Der Abschnitt Migrationspfad des Berichts enthält die folgenden Ansichten:

SQL-Übersetzung
In der SQL-Übersetzungsansicht werden die Anzahl und Details der Abfragen aufgelistet, die von der BigQuery-Migrationsbewertung automatisch konvertiert wurden und keinen manuellen Eingriff erfordern. Die automatische SQL-Übersetzung erreicht in der Regel hohe Übersetzungsraten, wenn Metadaten bereitgestellt werden. Diese Ansicht ist interaktiv und ermöglicht die Analyse gängiger Abfragen und wie diese übersetzt werden.
Offline-Aufwand
Die Ansicht „Offline-Aufwand“ erfasst die Bereiche, die manuell erforderlich sind, einschließlich bestimmter UDFs und potenzieller lexikalischer Struktur- und Syntaxverstöße für Tabellen oder Spalten.
Reservierte BigQuery-Keywords
Die Ansicht "Reservierte BigQuery-Keywords" zeigt die erkannte Nutzung von Keywords an, die in der GoogleSQL-Sprache eine besondere Bedeutung haben. Sie können nur als Kennungen verwendet werden, wenn sie in Backticks `) eingeschlossen sind.
Zeitplan für Tabellenaktualisierungen
In der Ansicht „Zeitplan für die Tabellenaktualisierung“ sehen Sie, wann und wie häufig Tabellen aktualisiert werden, damit Sie planen können, wie und wann Sie sie migrieren.
Datenmigration zu BigQuery
In der Ansicht „Datenmigration zu BigQuery“ wird der Migrationspfad mit der erwarteten Zeit für die Migration Ihrer Daten mit dem Data Transfer Service von BigQuery Data Transfer Service dargestellt. Weitere Informationen finden Sie in der Anleitung zu BigQuery Data Transfer Service für Teradata.

Der Abschnitt „Anhang“ enthält die folgenden Ansichten.

Berücksichtigung der Groß-/Kleinschreibung
Die Ansicht „Groß-/Kleinschreibung beachten“ zeigt Tabellen im Quell-Data Warehouse an, die für Vergleiche konfiguriert sind, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird. Standardmäßig wird bei Stringvergleichen in BigQuery die Groß-/Kleinschreibung beachtet. Weitere Informationen finden Sie unter Sortierung.

Amazon Redshift

Highlights der Migration
Die Ansicht „Highlights der Migration“ enthält eine Zusammenfassung der drei Abschnitte des Berichts:
  1. Der Bereich Vorhandenes System enthält Informationen zur Anzahl der Datenbanken, Schemas, Tabellen und der Gesamtgröße des vorhandenen Redshift-Systems. Außerdem werden die Schemas nach Größe und möglicher suboptimaler Ressourcennutzung aufgelistet. Anhand dieser Informationen können Sie Ihre Daten optimieren- Entfernen, partitionieren oder gruppieren Sie dazu die Tabellen.
  2. Der Bereich BigQuery stabiler Zustand enthält Informationen dazu, wie Ihre Daten nach der Migration in BigQuery aussehen, einschließlich der Anzahl der Abfragen, die automatisch mit dem BigQuery Migration Service übersetzt werden können. In diesem Abschnitt werden auch die Kosten für das Speichern Ihrer Daten in BigQuery auf der Grundlage der jährlichen Datenaufnahmerate angezeigt. Außerdem werden Optimierungsvorschläge für Tabellen, Bereitstellung und Speicherplatz angezeigt.
  3. Der Bereich Migrationspfad enthält Informationen zur Migration selbst. Für jede Tabelle werden die erwartete Migrationszeit, die Anzahl der Zeilen in der Tabelle und ihre Größe angezeigt.

Der Abschnitt Vorhandenes System enthält die folgenden Ansichten:

Abfragen nach Typ und Zeitplan
In der Ansicht „Abfragen nach Typ“ und „Zeitplan“ werden Ihre Abfragen in ETL/Write und Reporting/Aggregation kategorisiert. Wenn Sie Ihre Abfrage im Laufe der Zeit sehen, können Sie Ihre vorhandenen Nutzungsmuster verstehen sowie Burstiness und potenzielle Überdimensionierungen erkennen, die sich auf Kosten und Leistung auswirken können.
Abfrage in Warteschlange stellen
Die Ansicht „Abfragewarteschlange“ enthält zusätzliche Details zur Systemlast, einschließlich Abfragevolumen, Mixing und Leistungseinbußen aufgrund von Warteschlangen, z. B. unzureichende Ressourcen.
Abfragen und WLM-Skalierung
Die Ansicht „Abfragen“ und „WLM-Skalierung“ identifiziert die Gleichzeitigkeitsskalierung als zusätzliche Kosten und Konfigurationskomplexität. Sie zeigt, wie Ihr Redshift-System Abfragen auf der Grundlage der von Ihnen festgelegten Regeln weiterleitet und wie sich Warteschlangen, Gleichzeitigkeitsskalierung und verworfene Abfragen auf die Leistung auswirken.
In Warteschlange stellen und warten
Die Ansicht für „Warteschlangen“ und „Wartezeiten“ bietet einen detaillierteren Einblick in Warteschlangen- und Wartezeiten für Abfragen im Laufe der Zeit.
WLM-Klassen und Leistung
Die Ansicht „WLM-Klassen“ und „Leistung“ bietet eine optionale Möglichkeit, Ihre Regeln BigQuery zuzuordnen. Wir empfehlen jedoch, BigQuery Ihre Abfragen automatisch weiterleiten zu lassen.
Informationen zum Abfrage- und Tabellen-Volume
In der Statistikansicht zu Abfrage- und Tabellen-Volume werden Abfragen nach Größe, Häufigkeit und Top-Nutzern aufgelistet. So können Sie die Lastquellen auf dem System kategorisieren und die Migration der Arbeitslasten planen.
Datenbanken und Schemas
Die Ansicht der Datenbanken enthält Messwerte zur Größe, Tabellen, Ansichten und im Quell-Data-Warehouse definierte Verfahren. Dadurch erhalten Sie Einblick in die Menge der zu migrierenden Objekte.
Tabellen-Volumen
Die Ansicht „Tabellen-Volumen“ liefert Statistiken über die größten Tabellen und Datenbanken und zeigt, wie auf sie zugegriffen wird. Da das Extrahieren großer Tabellen aus dem Quell-Data-Warehouse-System länger dauern kann, unterstützt Sie diese Ansicht bei der Migrationsplanung und -sequenzierung.
Tabellennutzung
Die Ansicht „Tabellennutzung“ enthält Statistiken zu den Tabellen, die im Quell-Data-Warehouse-System stark genutzt werden. Stark genutzte Tabellen können genutzt werden, um Tabellen zu verstehen, die möglicherweise viele Abhängigkeiten haben und eine zusätzliche Planung während des Migrationsprozesses rechtfertigen.
Importer und Exporter
Die Ansicht „Importer und Exporter“ enthält Informationen zu Daten und Nutzern, die am Datenimport (mit COPY-Abfragen) und Datenexport (mit UNLOAD-Abfragen) beteiligt sind. Mithilfe dieser Ansicht lassen sich die Staging-Ebene und die Prozesse im Zusammenhang mit Datenaufnahme und Exporten identifizieren.
Clusterauslastung
Die Ansicht „Clusterauslastung“ enthält allgemeine Informationen zu allen verfügbaren Clustern und zeigt die CPU-Auslastung für jeden Cluster an. Mit dieser Ansicht können Sie die Kapazitätsreserve des Systems besser nachvollziehen.

Der Abschnitt BigQuery stabiler Zustand enthält die folgenden Ansichten:

Clustering und Partitionierung

Die Ansicht "Partitionierung und Clustering" enthält Tabellen, die von Partitionierung, Clustering oder beidem profitieren würden.

Die Metadatenvorschläge werden dadurch erreicht, dass das Schema des Quelldatenspeichers (wie Sort Key und Dist Key in der Quelltabelle) analysiert und das nächstgelegene BigQuery-Äquivalent ermittelt wird, um ähnliche Optimierungsmerkmale zu erreichen.

Die Arbeitslastvorschläge werden durch das Analysieren der Quellabfragelogs erreicht. Die Empfehlung wird durch die Analyse der Arbeitslasten ermittelt, insbesondere durch die Klauseln WHERE oder JOIN in den analysierten Abfragelogs.

Unten auf der Seite befindet sich eine übersetzte Anweisung zum Erstellen einer Tabelle, in der alle Optimierungen angegeben sind. Alle übersetzten DDL-Anweisungen können auch aus dem Dataset extrahiert werden. Übersetzte DDL-Anweisungen werden gespeichert in Tabelle „SchemaConversion“ in Spalte „CreateTableDDL“.

Die Empfehlungen im Bericht gelten nur für Tabellen, die größer sind als 1 GB, da kleine Tabellen nicht von Clustering und Partitionierung profitieren. DDLs für alle Tabellen (einschließlich Tabellen, die kleiner als 1 GB sind) sind jedoch in der Tabelle SchemaConversion verfügbar.

Tabellen ohne Nutzung

In der Ansicht „Tabellen ohne Nutzung“ werden Tabellen angezeigt, in denen BigQuery-Migrationsbewertung keine Nutzung während der analysierten Logzeiträume festgestellt hat. Mangelnde Nutzung kann darauf hindeuten, dass Sie diese Tabelle nicht während der Migration zu BigQuery übertragen müssen, oder dass die Kosten für die Datenspeicherung BigQuery (in Rechnung gestellt als Langzeitspeicherung) niedriger sein könnten. Wir empfehlen, dass Sie die Liste der nicht verwendeten Tabellen validieren, da sie außerhalb des Logzeitraums verwendet werden könnten, z. B. eine Tabelle, die nur alle drei oder sechs Monate verwendet wird.

Tabellen ohne Schreibvorgänge

In der Ansicht „Tabellen ohne Schreibvorgänge“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während der analysierten Logzeiträume keine Aktualisierungen identifiziert hat. Ein Mangel an Schreibvorgängen kann darauf hindeuten, dass die Ihre Speicherkosten in BigQuery (in Rechnung gestellt als Langzeitspeicherung) niedriger sein könnten.

BI Engine und materialisierte Ansichten

Die BI Engine und die materialisierten Ansichten liefern weitere Optimierungsvorschläge, um die Leistung auf BigQuery zu verbessern.

Der Abschnitt Migrationspfad enthält die folgenden Ansichten:

SQL-Übersetzung
In der SQL-Übersetzungsansicht werden die Anzahl und Details der Abfragen aufgelistet, die von der BigQuery-Migrationsbewertung automatisch konvertiert wurden und keinen manuellen Eingriff erfordern. Die automatische SQL-Übersetzung erreicht in der Regel hohe Übersetzungsraten, wenn Metadaten bereitgestellt werden.
Offline-Aufwand der SQL-Übersetzung
Die Ansicht „Offline-Aufwand der SQL-Übersetzung“ erfasst die Bereiche, die manuelle Eingriffe erfordern, einschließlich bestimmter UDFs und Abfragen mit potenziellen Unklarheiten der Übersetzung.
Unterstützung für Änderung von Tabellenanhängen
Die Ansicht „Unterstützung für Änderung von Tabellenanhängen“ zeigt Details zu gängigen Redshift-SQL-Konstrukten an, die kein direktes BigQuery-Gegenstück haben.
Unterstützung für den Kopierbefehl
Die Ansicht „Unterstützung für den Kopierbefehl“ zeigt Details zu häufig verwendeten Redshift-SQL-Konstrukten, die kein direktes BigQuery-Gegenstück haben.
SQL-Warnungen
In der Ansicht „SQL-Warnungen“ werden Bereiche erfasst, die erfolgreich übersetzt wurden, aber eine Überprüfung erfordern.
Lexikalische Struktur und Syntaxverstöße
In der Ansicht „Lexikalische Struktur und Syntaxverstöße“ werden Namen von Spalten, Tabellen, Funktionen und Verfahren angezeigt, die gegen die BigQuery-Syntax verstoßen.
Reservierte BigQuery-Keywords
Die Ansicht "Reservierte BigQuery-Keywords" zeigt die erkannte Nutzung von Keywords an, die in der GoogleSQL-Sprache eine besondere Bedeutung haben. Sie können nur als Kennungen verwendet werden, wenn sie in Backticks `) eingeschlossen sind.
Schemakopplung
Die Ansicht "Schemakopplung" bietet eine allgemeine Ansicht der Datenbanken, Schemas und Tabellen, auf die in einer einzigen Abfrage zugegriffen wird. Diese Ansicht kann zeigen, auf welche Tabellen, Schemas und Datenbanken häufig verwiesen wird und was Sie für die Migrationsplanung verwenden können.
Zeitplan für Tabellenaktualisierungen
In der Ansicht „Zeitplan für die Tabellenaktualisierung“ sehen Sie, wann und wie häufig Tabellen aktualisiert werden, damit Sie planen können, wie und wann Sie sie migrieren.
Tabellenskalierung
In der Ansicht „Tabellenskalierung“ werden die Tabellen mit den meisten Spalten aufgelistet.
Datenmigration zu BigQuery
In der Ansicht „Datenmigration zu BigQuery“ wird der Migrationspfad mit der erwarteten Zeit für die Migration Ihrer Daten mit dem Data Transfer Service von BigQuery Migration Service dargestellt. Weitere Informationen finden Sie in der Anleitung zu BigQuery Data Transfer Service für Redshift.
Zusammenfassung der Bewertungsausführung

Die Zusammenfassung der Bewertungsausführung enthält die Vollständigkeit des Berichts, den Fortschritt der laufenden Bewertung und den Status der verarbeiteten Dateien und Fehler.

Die Berichtsvollständigkeit stellt den Prozentsatz der erfolgreich verarbeiteten Daten dar, die empfohlen werden, um aussagekräftige Informationen im Bewertungsbericht anzuzeigen. Wenn die Daten für einen bestimmten Abschnitt des Berichts fehlen, werden diese Informationen in der Tabelle Bewertungsmodule unter dem Indikator Vollständigkeit des Berichts aufgeführt. “

Der Messwert Fortschritt gibt den Prozentsatz der bisher verarbeiteten Daten sowie die Schätzung der verbleibenden Zeit für die Verarbeitung aller Daten an. Nach Abschluss der Verarbeitung wird der Fortschrittsmesswert nicht mehr angezeigt.

Zusammenfassung der Bewertungsausführung.

Apache Hive

Dem Bericht mit einer dreiteiligen Beschreibung wird eine Übersichtsseite mit den folgenden Abschnitten vorangestellt:

  • Vorhandenes System – Hive. Dieser Abschnitt besteht aus einem Snapshot des vorhandenen Hive-Systems und der vorhandenen Nutzung, einschließlich der Anzahl der Datenbanken, Tabellen, ihrer Gesamtgröße (in GB) und der Anzahl der verarbeiteten Abfragelogs. In diesem Abschnitt werden auch die Datenbanken nach Größe aufgelistet und es wird auf eine potenzielle suboptimale Ressourcennutzung (Tabellen ohne Schreibvorgänge oder mit wenigen Lesevorgängen) und -bereitstellung verwiesen. Dieser Abschnitt enthält folgende Details:

    • Computing und Abfragen
      • CPU-Auslastung:
        • Abfragen nach Stunde und Tag mit CPU-Auslastung
        • Abfragen nach Typ (Lesen/Schreiben)
        • Warteschlangen und Anwendungen
        • Overlay der stündlichen CPU-Auslastung mit durchschnittlicher stündlicher Abfrageleistung und durchschnittlicher stündlicher Anwendungsleistung
      • Abfragehistogramm nach Typ und Abfragedauer
      • Warteschlangen- und Warteseite
      • Detailansicht der Warteschlangen (Warteschlange, Nutzer, eindeutige Abfragen, Berichterstellung im Vergleich zu ETL-Aufschlüsselung, nach Messwerten)
    • Speicherübersicht
      • Datenbanken nach Volumen, Ansichten und Zugriffsraten
      • Tabellen mit Zugriffsraten nach Nutzern, Abfragen, Schreibvorgängen und dem Erstellen temporärer Tabellen
    • Warteschlangen und Anwendungen: Zugriffsraten und Client-IP-Adressen
  • BigQuery stabiler Zustand. Dieser Abschnitt zeigt, wie das System nach der Migration in BigQuery aussieht. Er enthält Vorschläge zur Optimierung von Arbeitslasten in BigQuery (und Vermeidung von unnötiger Inanspruchnahme). Dieser Abschnitt enthält folgende Details:

    • Tabellen, die als Kandidaten für materialisierte Ansichten identifiziert wurden
    • Clustering und Partitionierung von Kandidaten nach Metadaten und Nutzung
    • Abfragen mit niedriger Latenz, die als Kandidaten für BigQuery BI Engine identifiziert wurden
    • Tabellen ohne Lese- oder Schreibnutzung
    • Partitionierte Tabellen mit Datenverzerrung
  • Migrationsplan. Dieser Abschnitt enthält Informationen zur Migration selbst. Zum Beispiel zur Überführung des vorhandenen Systems in einen stabilen BigQuery-Zustand. Dieser Abschnitt enthält die angegebenen Speicherziele für jede Tabelle, die für die Migration als wichtig eingestuften Tabellen und die Anzahl der automatisch übersetzten Abfragen. Dieser Abschnitt enthält folgende Details:

    • Detaillierte Ansicht mit automatisch übersetzten Abfragen
      • Gesamtzahl der Abfragen mit Filterung nach Nutzer, Anwendung, betroffenen Tabellen, abgefragten Tabellen und Abfragetyp
      • Abfrage-Buckets, die nach ähnlichen Mustern gruppiert sind, sodass Nutzer die Übersetzungsphilosophie nach Abfragetyp sehen können
    • Abfragen, die menschliches Eingreifen erfordern
      • Abfragen mit Verstößen gegen die lexikalische BigQuery-Struktur
      • Benutzerdefinierte Funktionen und Verfahren
      • Reservierte BigQuery-Keywords
    • Abfragen, die eine Überprüfung erfordern
    • Tabellen werden nach Schreib- und Lesevorgängen gruppiert, um sie zum Verschieben zu gruppieren.
    • Identifiziertes Speicherziel für externe und verwaltete Tabellen

Der Abschnitt Vorhandenes System – Hive enthält die folgenden Ansichten:

Systemübersicht
Diese Ansicht bietet eine allgemeine Übersicht über die Volume-Messwerte der Schlüsselkomponenten im vorhandenen System für einen bestimmten Zeitraum. Die auszuwertende Zeitachse hängt von den Logs ab, die von der BigQuery-Migrationsbewertung analysiert wurden. In dieser Ansicht erhalten Sie einen schnellen Einblick in die Nutzung des Quell-Data-Warehouse, das für die Migrationsplanung verwendet werden kann.
Tabellen-Volumen
Diese Ansicht enthält Statistiken zu den größten Tabellen und Datenbanken, die bei der BigQuery-Migrationsbewertung gefunden wurden. Da das Extrahieren großer Tabellen aus dem Quell-Data-Warehouse-System länger dauern kann, kann diese Ansicht bei der Migrationsplanung und -sequenzierung hilfreich sein.
Tabellennutzung
Diese Ansicht enthält Statistiken zu den Tabellen, die im Quell-Data-Warehouse-System stark genutzt werden. Anhand der Statistiken zu stark genutzten Tabellen können Sie verstehen, welche Tabellen möglicherweise viele Abhängigkeiten haben und eine zusätzliche Planung während des Migrationsprozesses erfordern.
Warteschlangenauslastung
Diese Ansicht enthält Statistiken zur Nutzung der YARN-Warteschlangen bei der Verarbeitung von Logs. Diese Ansichten ermöglichen Nutzern, die Nutzung bestimmter Warteschlangen und Anwendungen im Zeitverlauf sowie die Auswirkungen auf die Ressourcennutzung zu verstehen. Anhand dieser Ansichten können Sie Arbeitslasten für die Migration identifizieren und priorisieren. Während einer Migration ist es wichtig, die Aufnahme und Nutzung von Daten zu visualisieren, um die Abhängigkeiten des Data Warehouse besser zu verstehen und die Auswirkungen der gemeinsamen Migration verschiedener abhängiger Anwendungen zu analysieren. Die IP-Adresstabelle kann nützlich sein, um die genaue Anwendung mit dem Data Warehouse über JDBC-Verbindungen zu bestimmen.
Warteschlangenmesswerte
Diese Ansicht enthält eine Aufschlüsselung der verschiedenen Messwerte zu YARN-Warteschlangen, die während der Verarbeitung von Logs gefunden wurden. Anhand dieser Ansicht lassen sich Nutzungsmuster in bestimmten Warteschlangen und die Auswirkungen auf die Migration nachvollziehen. Sie können diese Ansicht auch verwenden, um Verbindungen zwischen Tabellen, auf die in Abfragen zugegriffen wird, sowie die Warteschlangen, in denen die Abfrage ausgeführt wurde, zu identifizieren.
In Warteschlange stellen und warten
Diese Ansicht bietet einen Einblick in die Warteschlangen-Verweildauer von Abfragen im Quell-Data-Warehouse. Die Warteschlangen-Verweildauer kann auf eine Leistungsverschlechterung aufgrund von unzureichender Ressourcenbereitstellung hinweisen und zusätzliche Ressourcen beinhalten höhere Hardware- und Wartungskosten.
Abfragen
Diese Ansicht enthält eine Aufschlüsselung der ausgeführten SQL-Anweisungen und Statistiken zu deren Nutzung. Sie können das Histogramm für Abfragetyp und -zeit verwenden, um niedrige Zeiträume der Systemauslastung und optimale Tageszeiten für die Datenübertragung zu ermitteln. Sie können diese Ansicht auch verwenden, um die am häufigsten verwendeten Hive-Ausführungs-Engines und häufig ausgeführte Abfragen zusammen mit den Nutzerdetails zu identifizieren.
Datenbanken
Diese Ansicht enthält Messwerte zur Größe, zu Tabellen und Ansichten sowie zu im Quell-Data-Warehouse definierten Verfahren. Diese Ansicht bietet Einblick in das Volumen der zu migrierenden Objekte.
Datenbank- und Tabellenkopplung
Diese Ansicht bietet eine allgemeine Ansicht der Datenbanken und Tabellen, auf die in einer einzigen Abfrage zugegriffen wird. Diese Ansicht kann zeigen, auf welche Tabellen und Datenbanken häufig verwiesen wird und was Sie für die Migrationsplanung verwenden können.

Der Abschnitt BigQuery stabiler Zustand enthält die folgenden Ansichten:

Tabellen ohne Nutzung
In der Ansicht „Keine Nutzung“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während der Analyse des Logzeitraums keine Nutzung finden konnte. Eine mangelnde Nutzung kann darauf hinweisen, dass Sie diese Tabelle während der Migration nicht zu BigQuery übertragen müssen oder dass die Kosten für die Speicherung von Daten in BigQuery niedriger sein können. Sie müssen die Liste der nicht verwendeten Tabellen validieren, da sie außerhalb des Logzeitraums verwendet werden könnten, z. B. eine Tabelle, die nur alle drei oder sechs Monate verwendet wird.
Tabellen ohne Schreibvorgänge
In der Ansicht „Tabellen ohne Schreibvorgänge“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während des Analysezeitraums keine Aktualisierungen finden konnte. Fehlende Schreibvorgänge können darauf hinweisen, dass Sie die Speicherkosten in BigQuery senken können.
Empfehlungen zum Clustering und zur Partitionierung

Diese Ansicht zeigt Tabellen, die von Partitionierung, Clustering oder beidem profitieren würden.

Die Metadatenvorschläge werden dadurch erreicht, dass das Schema des Quelldatenspeichers (Partitionierung und Primärschlüssel in der Quelltabelle) analysiert und das nächstgelegene BigQuery-Äquivalent ermittelt wird, um ähnliche Optimierungsmerkmale zu erreichen.

Die Arbeitslastvorschläge werden durch die Analyse der Quellabfragelogs erreicht. Die Empfehlung wird durch die Analyse der Arbeitslasten ermittelt, insbesondere durch die Klauseln WHERE oder JOIN in den analysierten Abfragelogs.

In Cluster konvertierte Partitionen

In dieser Ansicht werden Tabellen mit mehr als 10.000 Partitionen basierend auf ihrer Definition zur Partitionierungseinschränkung angezeigt. Diese Tabellen sind in der Regel gute Kandidaten für BigQuery-Clustering, das eine detaillierte Tabellenpartitionierung ermöglicht.

Verzerrte Partitionen

In der Ansicht „Verzerrte Partitionen“ werden Tabellen angezeigt, die auf der Metadatenanalyse basieren und in einer oder mehreren Partitionen eine Datenverzerrung aufweisen. Diese Tabellen sind gute Kandidaten für Schemaänderungen, da Abfragen auf verzerrten Partitionen möglicherweise nicht gut funktionieren.

BI Engine und materialisierte Ansichten

In der Ansicht „Abfragen mit niedriger Latenz und materialisierte Ansichten“ werden eine Verteilung der Abfragelaufzeiten basierend auf den analysierten Logdaten sowie weitere Optimierungsvorschläge zur Verbesserung der Leistung in BigQuery angezeigt. Wenn das Diagramm zur Verteilung der Abfragedauer eine große Anzahl von Abfragen mit Laufzeiten von weniger als einer Sekunde anzeigt, sollten Sie eventuell BI Engine aktivieren, um BI- und andere Arbeitslasten mit niedriger Latenz zu beschleunigen.

Der Abschnitt Migrationsplan des Berichts enthält die folgenden Ansichten:

SQL-Übersetzung
In der SQL-Übersetzungsansicht werden die Anzahl und Details der Abfragen aufgelistet, die von der BigQuery-Migrationsbewertung automatisch konvertiert wurden und keinen manuellen Eingriff erfordern. Die automatische SQL-Übersetzung erreicht in der Regel hohe Übersetzungsraten, wenn Metadaten bereitgestellt werden. Diese Ansicht ist interaktiv und ermöglicht die Analyse gängiger Abfragen und wie diese übersetzt werden.
Offline-Aufwand der SQL-Übersetzung
Die Ansicht „Offline-Aufwand“ erfasst die Bereiche, die manuell erforderlich sind, einschließlich bestimmter UDFs und potenzieller lexikalischer Struktur- und Syntaxverstöße für Tabellen oder Spalten.
SQL-Warnungen
In der Ansicht „SQL-Warnungen“ werden Bereiche erfasst, die erfolgreich übersetzt wurden, aber eine Überprüfung erfordern.
Reservierte BigQuery-Keywords
Die Ansicht „Reservierte BigQuery-Keywords“ zeigt die erkannte Nutzung von Keywords an, die in der GoogleSQL-Sprache eine besondere Bedeutung haben. Diese Keywords können nur dann als Kennungen verwendet werden, wenn sie in Backticks (`) eingeschlossen sind.
Zeitplan für Tabellenaktualisierungen
In der Ansicht „Zeitplan für die Tabellenaktualisierung“ sehen Sie, wann und wie häufig Tabellen aktualisiert werden, damit Sie planen können, wie und wann Sie sie migrieren.
Externe BigLake-Tabellen
Die Ansicht „Externe BigLake-Tabellen“ beschreibt Tabellen, die als Ziele für die Migration zu BigLake anstelle von BigQuery identifiziert wurden.

Der Abschnitt Anhang des Berichts enthält die folgenden Ansichten.

Detaillierte Analyse des Offline-Aufwands der SQL-Übersetzung
Die Ansicht „Detaillierte Analyse des Offline-Aufwands“ bietet einen zusätzlichen Einblick in die SQL-Bereiche, die einen manuellen Eingriff erfordern.
Detaillierte SQL-Warnungsanalyse
Die Ansicht „Detaillierte Warnungsanalyse“ bietet einen zusätzlichen Einblick in die SQL-Bereiche, die erfolgreich übersetzt wurden, aber eine Überprüfung erfordern.

Snowflake

Der Bericht besteht aus verschiedenen Abschnitten, die entweder separat oder zusammen verwendet werden können. Das folgende Diagramm organisiert diese Abschnitte in drei allgemeine Nutzerziele, um Ihnen bei der Bewertung Ihrer Migrationsanforderungen zu helfen:

Flussdiagramm für Migrationsbewertungsbericht für Snowflake

Ansichten unter „Migrations-Highlights“

Der Abschnitt Migrations-Highlights enthält die folgenden Ansichten:

Vergleich von Snowflake- und BigQuery-Preismodellen
Liste der Preise mit verschiedenen Stufen/Versionen. Enthält auch eine Abbildung dazu, wie Sie mit BigQuery-Autoscaling Kosten im Vergleich zu denen von Snowflake sparen können.
Gesamtbetriebskosten
Interaktive Tabelle, in der der Nutzer Folgendes definieren kann: BigQuery-Edition, Zusicherung, Referenz-Slot-Zusicherung, Prozentsatz des aktiven Speichers und Prozentsatz der geladenen oder geänderten Daten. Damit können die Kosten für benutzerdefinierte Fälle besser schätzen.
Highlights der automatischen Übersetzung
Aggregiertes Übersetzungsverhältnis, gruppiert nach Nutzer oder Datenbank, aufsteigend oder absteigend sortiert. Enthält auch die häufigste Fehlermeldung für eine fehlgeschlagene automatische Übersetzung.

Ansichten unter „Vorhandenes System“

Der Abschnitt Vorhandenes System enthält die folgenden Ansichten:

Systemübersicht
Die Systemübersicht zeigt die allgemeinen Volume-Messwerte der Schlüsselkomponenten im vorhandenen System für einen bestimmten Zeitraum. Die auszuwertende Zeitachse hängt von den Logs ab, die von der BigQuery-Migrationsbewertung analysiert wurden. In dieser Ansicht erhalten Sie einen schnellen Einblick in die Nutzung des Quell-Data-Warehouse, das für die Migrationsplanung verwendet werden kann.
Übersicht über virtuelle Warehouses
Zeigt die Snowflake-Kosten nach Warehouse sowie die knotenbasierte Neuskalierung im jeweiligen Zeitraum an.
Tabellen-Volumen
Die Ansicht „Tabellen-Volume“ enthält Statistiken zu den größten Tabellen und Datenbanken, die von der BigQuery-Migrationsbewertung gefunden wurden. Da das Extrahieren großer Tabellen aus dem Quell-Data-Warehouse-System länger dauern kann, kann diese Ansicht bei der Migrationsplanung und -sequenzierung hilfreich sein.
Tabellennutzung
Die Ansicht „Tabellennutzung“ enthält Statistiken zu den Tabellen, die im Quell-Data-Warehouse-System stark genutzt werden. Anhand der Statistiken zu stark genutzten Tabellen können Sie verstehen, welche Tabellen möglicherweise viele Abhängigkeiten haben und eine zusätzliche Planung während des Migrationsprozesses erfordern.
Abfragen
Die Abfrageansicht enthält eine Aufschlüsselung der ausgeführten SQL-Anweisungen und Statistiken zu deren Nutzung. Sie können das Histogramm für Abfragetyp und -zeit verwenden, um niedrige Zeiträume der Systemauslastung und optimale Tageszeiten für die Datenübertragung zu ermitteln. Sie können diese Ansicht auch verwenden, um häufig ausgeführte Abfragen und die Nutzer zu bestimmen, die diese Ausführungen aufrufen.
Datenbanken
Die Ansicht der Datenbanken enthält Messwerte zur Größe, Tabellen, Ansichten sowie im Quell-Data-Warehouse definierte Verfahren. Diese Ansicht bietet Einblick in das Volumen der zu migrierenden Objekte.

Ansichten unter „BigQuery stabiler Zustand“

Der Abschnitt BigQuery stabiler Zustand enthält die folgenden Ansichten:

Tabellen ohne Nutzung
In der Ansicht „Tabellen ohne Nutzung“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während der Analyse des Logzeitraums keine Nutzung finden konnte. Dies kann darauf hinweisen, welche Tabellen während der Migration möglicherweise nicht an BigQuery übertragen werden müssen oder dass die Kosten für die Speicherung von Daten in BigQuery niedriger sein könnten. Sie müssen die Liste der nicht verwendeten Tabellen überprüfen, da sie außerhalb des analysierten Logging-Zeitraums verwendet werden könnten, z. B. eine Tabelle, die nur einmal pro Quartal oder Halbjahr verwendet wird.
Tabellen ohne Schreibvorgänge
In der Ansicht „Tabellen ohne Schreibvorgänge“ werden Tabellen angezeigt, in denen die BigQuery-Migrationsbewertung während des Analysezeitraums keine Aktualisierungen finden konnte. Dies kann darauf hinweisen, dass die Kosten für die Speicherung von Daten in BigQuery niedriger sein könnten.

Ansichten unter „Migrationsplan“

Der Abschnitt Migrationsplan des Berichts enthält die folgenden Ansichten:

SQL-Übersetzung
In der SQL-Übersetzungsansicht werden die Anzahl und Details der Abfragen aufgelistet, die von der BigQuery-Migrationsbewertung automatisch konvertiert wurden und keinen manuellen Eingriff erfordern. Die automatische SQL-Übersetzung erreicht in der Regel hohe Übersetzungsraten, wenn Metadaten bereitgestellt werden. Diese Ansicht ist interaktiv und ermöglicht die Analyse gängiger Abfragen und wie diese übersetzt werden.
Offline-Aufwand der SQL-Übersetzung
Die Ansicht „Offline-Aufwand“ erfasst die Bereiche, die manuell erforderlich sind, einschließlich bestimmter UDFs und potenzieller lexikalischer Struktur- und Syntaxverstöße für Tabellen oder Spalten.
SQL-Warnungen – Zur Überprüfung
In der Ansicht „Warnungen zur Überprüfung“ werden die Bereiche erfasst, die hauptsächlich übersetzt werden, aber einige manuelle Prüfungen erfordern.
Reservierte BigQuery-Keywords
Die Ansicht "Reservierte BigQuery-Keywords" zeigt die erkannte Nutzung von Keywords an, die in der GoogleSQL-Sprache eine besondere Bedeutung haben. Sie können nur als Kennungen verwendet werden, wenn sie in Backticks `) eingeschlossen sind.
Datenbank- und Tabellenkopplung
Die Ansicht "Datenbankkopplung" bietet eine allgemeine Ansicht der Datenbanken und Tabellen, auf die in einer einzigen Abfrage zugegriffen wird. Diese Ansicht kann zeigen, auf welche Tabellen und Datenbanken häufig verwiesen wird und was für die Migrationsplanung verwendet werden kann.
Zeitplan für Tabellenaktualisierungen
In der Ansicht „Zeitplan für die Tabellenaktualisierungen“ sehen Sie, wann und wie häufig Tabellen aktualisiert werden, damit Sie planen können, wie und wann Sie sie migrieren.

Ansichten unter „PoC“

Der Abschnitt PoC (Proof of Concept) enthält die folgenden Ansichten:

PoC für die Demonstration von Einsparungen für BigQuery im stabilen Zustand
Dies umfasst die häufigsten Abfragen, die Abfragen, die die meisten Daten lesen, die langsamsten Abfragen und die Tabellen, die von den eben genannten Abfragen betroffen sind.
PoC für die Demonstration des BigQuery-Migrationsplans
Hier sehen Sie, wie BigQuery die komplexesten Abfragen und die betroffenen Tabellen übersetzt.

Bericht freigeben

Der Looker Studio-Bericht ist ein Frontend-Dashboard für die Migrationsbewertung. Es basiert auf den zugrunde liegenden Dataset-Zugriffsberechtigungen. Zum Freigeben des Berichts muss der Empfänger Zugriff auf den Looker Studio-Bericht selbst und auf das BigQuery-Dataset haben, das die Bewertungsergebnisse enthält.

Wenn Sie den Bericht über die Google Cloud Console öffnen, sehen Sie den Bericht im Vorschaumodus. Führen Sie die folgenden Schritte aus, um den Bericht zu erstellen und für andere Nutzer freizugeben:

  1. Klicken Sie auf Bearbeiten und freigeben. Looker Studio fordert Sie auf, neu erstellte Looker Studio-Connectors an den neuen Bericht anzuhängen.
  2. Klicken Sie auf Zum Bericht hinzufügen. Der Bericht erhält eine einzelne Berichts-ID, mit der Sie auf den Bericht zugreifen können.
  3. Um den Looker Studio-Bericht für andere Nutzer freizugeben, führen Sie die Schritte unter Berichte für Betrachter und Bearbeiter freigeben aus.
  4. Gewähren Sie den Nutzern die Berechtigung zum Aufrufen des BigQuery-Datasets, mit dem die Bewertungsaufgabe ausgeführt wurde. Weitere Informationen finden Sie unter Zugriff auf ein Dataset gewähren.

Ausgabetabellen der Migrationsbewertung abfragen

Looker Studio ist die einfachste Möglichkeit zum Aufrufen der Bewertungsergebnisse. Sie können aber auch die zugrunde liegenden Daten im BigQuery-Dataset aufrufen und abfragen.

Beispielabfrage

Im folgenden Beispiel wird die Gesamtzahl der eindeutigen Abfragen, die Anzahl der Abfragen mit fehlgeschlagener Übersetzung und der Prozentsatz der eindeutigen Abfragen zurückgegeben, deren Übersetzung fehlgeschlagen ist.

  SELECT
    QueryCount.v AS QueryCount,
    ErrorCount.v as ErrorCount,
    (ErrorCount.v * 100) / QueryCount.v AS FailurePercentage
  FROM
  (
    SELECT
     COUNT(*) AS v
    FROM
      `your_project.your_dataset.TranslationErrors`
    WHERE Type = "ERROR"
  ) AS ErrorCount,
  (
    SELECT
      COUNT(DISTINCT(QueryHash)) AS v
    FROM
      `your_project.your_dataset.Queries`
  ) AS QueryCount;

Dataset für Nutzer in anderen Projekten freigeben

Wenn Sie das Dataset nach der Prüfung des Datasets für einen Nutzer freigeben möchten, der nicht in Ihrem Projekt enthalten ist, verwenden Sie den Publisher-Workflow von Analytics Hub.

  1. Öffnen Sie in der Google Cloud Console die Seite BigQuery.

    BigQuery aufrufen

  2. Klicken Sie auf das Dataset, um die Details aufzurufen.

  3. Klicken Sie auf Freigabe > Als Eintrag veröffentlichen.

  4. Erstellen Sie im daraufhin geöffneten Dialogfeld einen Eintrag, wenn Sie dazu aufgefordert werden.

    Wenn Sie bereits einen Datenpool haben, überspringen Sie Schritt 5.

  5. Pool erstellen und Berechtigungen festlegen Damit ein Nutzer Ihre Einträge in dieser Pool ansehen kann, fügen Sie ihn der Liste Abonnenten hinzu.

  6. Geben Sie die Details des Eintrags ein.

    Anzeigename ist der Name dieses Eintrags und ist erforderlich. andere Felder sind optional.

  7. Klicken Sie auf Veröffentlichen.

    Ein privater Eintrag wird erstellt.

  8. Wählen Sie für Ihren Eintrag unter Aktionen die Option Weitere Aktionen aus.

  9. Klicken Sie auf Link zur Freigabe kopieren.

    Sie können den Link für Nutzer freigeben, die Abozugriff auf Ihren Pool oder Ihren Eintrag haben.

Bewertungstabellenschemas

Wählen Sie Ihr Data Warehouse aus, um die Tabellen und zugehörigen Schemas aufzurufen, die die BigQuery-Migrationsbewertung in BigQuery schreibt:

Teradata

AllRIChildren

Diese Tabelle enthält Informationen zur referenziellen Integrität der untergeordneten Tabellen.

Spalte Typ Beschreibung
IndexId INTEGER Die Referenzindexnummer.
IndexName STRING Der Name des Index.
ChildDB STRING Der Name der referenzierenden Datenbank, in Kleinbuchstaben umgewandelt.
ChildDBOriginal STRING Der Name der referenzierenden Datenbank mit beibehaltener Groß-/Kleinschreibung.
ChildTable STRING Der Name der referenzierenden Tabelle, in Kleinbuchstaben umgewandelt.
ChildTableOriginal STRING Der Name der referenzierenden Tabelle mit beibehaltener Groß-/Kleinschreibung.
ChildKeyColumn STRING Der Name einer Spalte im referenzierenden Schlüssel, in Kleinbuchstaben umgewandelt.
ChildKeyColumnOriginal STRING Der Name einer Spalte im referenzierenden Schlüssel mit beibehaltener Groß-/Kleinschreibung.
ParentDB STRING Der Name der referenzierten Datenbank, in Kleinbuchstaben umgewandelt.
ParentDBOriginal STRING Der Name der referenzierten Datenbank mit beibehaltener Groß-/Kleinschreibung.
ParentTable STRING Der Name der referenzierten Tabelle, in Kleinbuchstaben umgewandelt.
ParentTableOriginal STRING Der Name der referenzierten Tabelle mit beibehaltener Groß-/Kleinschreibung.
ParentKeyColumn STRING Der Name der Spalte in einem referenzierten Schlüssel, in Kleinbuchstaben umgewandelt.
ParentKeyColumnOriginal STRING Der Name der Spalte in einem referenzierten Schlüssel mit beibehaltener Groß-/Kleinschreibung.

AllRIParents

Diese Tabelle enthält die Informationen zur referenziellen Integrität der übergeordneten Tabellen.

Spalte Typ Beschreibung
IndexId INTEGER Die Referenzindexnummer.
IndexName STRING Der Name des Index.
ChildDB STRING Der Name der referenzierenden Datenbank, in Kleinbuchstaben umgewandelt.
ChildDBOriginal STRING Der Name der referenzierenden Datenbank mit beibehaltener Groß-/Kleinschreibung.
ChildTable STRING Der Name der referenzierenden Tabelle, in Kleinbuchstaben umgewandelt.
ChildTableOriginal STRING Der Name der referenzierenden Tabelle mit beibehaltener Groß-/Kleinschreibung.
ChildKeyColumn STRING Der Name einer Spalte im referenzierenden Schlüssel, in Kleinbuchstaben umgewandelt.
ChildKeyColumnOriginal STRING Der Name einer Spalte im referenzierenden Schlüssel mit beibehaltener Groß-/Kleinschreibung.
ParentDB STRING Der Name der referenzierten Datenbank, in Kleinbuchstaben umgewandelt.
ParentDBOriginal STRING Der Name der referenzierten Datenbank mit beibehaltener Groß-/Kleinschreibung.
ParentTable STRING Der Name der referenzierten Tabelle, in Kleinbuchstaben umgewandelt.
ParentTableOriginal STRING Der Name der referenzierten Tabelle mit beibehaltener Groß-/Kleinschreibung.
ParentKeyColumn STRING Der Name der Spalte in einem referenzierten Schlüssel, in Kleinbuchstaben umgewandelt.
ParentKeyColumnOriginal STRING Der Name der Spalte in einem referenzierten Schlüssel mit beibehaltener Groß-/Kleinschreibung.

Columns

Diese Tabelle enthält Informationen zu den Spalten.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt.
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle, in Kleinbuchstaben umgewandelt.
TableNameOriginal STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
ColumnName STRING Der Name der Spalte, in Kleinbuchstaben umgewandelt.
ColumnNameOriginal STRING Der Name der Spalte mit beibehaltener Groß-/Kleinschreibung.
ColumnType STRING Der BigQuery-Typ der Spalte, z. B. STRING.
OriginalColumnType STRING Der ursprüngliche Typ der Spalte, z. B. VARCHAR.
ColumnLength INTEGER Die maximale Anzahl von Byte der Spalte, z. B. 30 für VARCHAR(30).
DefaultValue STRING Der Standardwert, falls vorhanden.
Nullable BOOLEAN Gibt an, ob die Spalte Nullwerte enthalten kann.

DiskSpace

Die folgende Tabelle enthält Informationen zur Speicherplatzbelegung für jede Datenbank.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt.
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
MaxPerm INTEGER Die maximale Anzahl der Byte, die dem permanenten Speicherplatz zugeordnet sind.
MaxSpool INTEGER Die maximale Anzahl der Byte, die dem Spool-Bereich zugeordnet sind.
MaxTemp INTEGER Die maximale Anzahl der Byte, die dem temporären Speicherplatz zugeordnet sind.
CurrentPerm INTEGER Die Anzahl der Byte, die derzeit dem permanenten Speicherplatz zugeordnet sind.
CurrentSpool INTEGER Die Anzahl der Byte, die derzeit dem Spool-Bereich zugeordnet sind.
CurrentTemp INTEGER Die Anzahl der Byte, die derzeit dem temporären Speicherplatz zugeordnet sind.
PeakPerm INTEGER Die Höchstzahl der Byte, die seit dem letzten Zurücksetzen für den permanenten Speicherplatz verwendet wurden.
PeakSpool INTEGER Die Höchstzahl der Byte, die seit dem letzten Zurücksetzen für den Spool-Bereich verwendet wurden.
PeakPersistentSpool INTEGER Die Höchstzahl der Byte, die seit dem letzten Zurücksetzen für den nichtflüchtigen Speicherplatz verwendet wurden.
PeakTemp INTEGER Die Höchstzahl der Byte, die seit dem letzten Zurücksetzen für den temporären Speicherplatz verwendet wurden.
MaxProfileSpool INTEGER Das Limit für den Spool-Bereich für den Nutzer.
MaxProfileTemp INTEGER Das Limit für den temporären Speicherplatz für den Nutzer.
AllocatedPerm INTEGER Aktuelle Zuordnung des permanenten Speicherplatzes.
AllocatedSpool INTEGER Aktuelle Zuordnung des Spool-Bereichs.
AllocatedTemp INTEGER Aktuelle Zuordnung des temporären Speicherplatzes.

Functions

Diese Tabelle enthält Informationen zu den Funktionen.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt.
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
FunctionName STRING Der Name der Funktion.
LanguageName STRING Der Name der Sprache.

Indices

Diese Tabelle enthält Informationen zu den Indexen.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt.
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle, in Kleinbuchstaben umgewandelt.
TableNameOriginal STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
IndexName STRING Der Name des Index.
ColumnName STRING Der Name der Spalte, in Kleinbuchstaben umgewandelt.
ColumnNameOriginal STRING Der Name der Spalte mit beibehaltener Groß-/Kleinschreibung.
OrdinalPosition INTEGER Die Position der Spalte.
UniqueFlag BOOLEAN Gibt an, ob der Index Eindeutigkeit erzwingt.

Queries

Diese Tabelle enthält Informationen zu den extrahierten Abfragen.

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
QueryText STRING Der Text der Abfrage.

QueryLogs

Diese Tabelle enthält einige Ausführungsstatistiken zu den extrahierten Abfragen.

Spalte Typ Beschreibung
QueryText STRING Der Text der Abfrage.
QueryHash STRING Der Hash der Abfrage.
QueryId STRING Die ID der Abfrage.
QueryType STRING Der Typ der Abfrage, entweder Abfrage oder DDL.
UserId BYTES Die ID des Nutzers, der die Abfrage ausgeführt hat.
UserName STRING Der Name des Nutzers, der die Abfrage ausgeführt hat.
StartTime TIMESTAMP Zeitstempel für das Senden der Abfrage.
Duration STRING Dauer der Abfrage in Millisekunden.
AppId STRING Die ID der Anwendung, die die Abfrage ausgeführt hat.
ProxyUser STRING Der Proxy-Nutzer, wenn über eine Mittelstufe verwendet.
ProxyRole STRING Die Proxy-Rolle, wenn über eine Mittelstufe verwendet.

QueryTypeStatistics

Diese Tabelle enthält Statistiken zu Abfragetypen.

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
QueryType STRING Der Typ der Abfrage.
UpdatedTable STRING Die gegebenenfalls von der Abfrage aktualisierte Tabelle.
QueriedTables ARRAY<STRING> Eine Liste der abgefragten Tabellen.

ResUsageScpu

Diese Tabelle enthält Informationen zur CPU-Ressourcennutzung.

Spalte Typ Beschreibung
EventTime TIMESTAMP Die Uhrzeit des Ereignisses.
NodeId INTEGER Knoten-ID
CabinetId INTEGER Die physische Schranknummer des Knotens.
ModuleId INTEGER Die physische Modulnummer des Knotens.
NodeType STRING Typ des Knotens.
CpuId INTEGER ID der CPU in diesem Knoten.
MeasurementPeriod INTEGER Der Zeitraum der Messung, ausgedrückt in Hundertstelsekunden.
SummaryFlag STRING S: Zeile mit Zusammenfassung (Summary), N – Zeile ohne Zusammenfassung (Non-summary)
CpuFrequency FLOAT CPU-Frequenz in MHz.
CpuIdle FLOAT Die Inaktivitätszeit der CPU, ausgedrückt in Hundertstelsekunden.
CpuIoWait FLOAT Die Zeit, die die CPU auf die E/A wartet, ausgedrückt in Hundertstelsekunden.
CpuUServ FLOAT Die Zeit, in der die CPU den Nutzercode ausführt, ausgedrückt in Hundertstelsekunden.
CpuUExec FLOAT Die Zeit, in der die CPU den Dienstcode ausführt, ausgedrückt in Hunderstelsekunden.

Roles

Diese Tabelle enthält Informationen zu Rollen.

Spalte Typ Beschreibung
RoleName STRING Der Name der Rolle.
Grantor STRING Der Datenbankname, der die Rolle zugewiesen hat.
Grantee STRING Der Nutzer, dem die Rolle zugewiesen wurde.
WhenGranted TIMESTAMP Wann die Rolle gewährt wurde.
WithAdmin BOOLEAN Ist die Option „Administrator“ für die zugewiesene Rolle festgelegt.

SchemaConversion

Die folgende Tabelle enthält Informationen zu Schemakonvertierungen im Zusammenhang mit Clustering und Partitionierung.

Spaltenname Spaltentyp Beschreibung
DatabaseName STRING Der Name der Quelldatenbank, für die der Vorschlag gemacht wird. Eine Datenbank ist einem Dataset in BigQuery zugeordnet.
TableName STRING Der Name der Tabelle, für die der Vorschlag gemacht wird.
PartitioningColumnName STRING Der Name der vorgeschlagenen Partitionierungsspalte in BigQuery.
ClusteringColumnNames ARRAY Die Namen der vorgeschlagenen Clustering-Spalten in BigQuery.
CreateTableDDL STRING Die CREATE TABLE statement zum Erstellen der Tabelle in BigQuery.

TableInfo

Diese Tabelle enthält Informationen zu Tabellen.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt.
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle, in Kleinbuchstaben umgewandelt.
TableNameOriginal STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
LastAccessTimestamp TIMESTAMP Der Zeitpunkt des letzten Zugriffs auf die Tabelle.
LastAlterTimestamp TIMESTAMP Der Zeitpunkt der letzten Änderung der Tabelle.
TableKind STRING Der Typ der Tabelle.

TableRelations

Diese Tabelle enthält Informationen zu Tabellen.

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage, die die Beziehung hergestellt hat.
DatabaseName1 STRING Der Name der ersten Datenbank.
TableName1 STRING Der Name der ersten Tabelle.
DatabaseName2 STRING Der Name der zweiten Datenbank.
TableName2 STRING Der Name der zweiten Tabelle.
Relation STRING Die Art der Beziehung zwischen den beiden Tabellen.

TableSizes

Diese Tabelle enthält Informationen zu Tabellengrößen.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt.
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle, in Kleinbuchstaben umgewandelt.
TableNameOriginal STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
TableSizeInBytes INTEGER Die Größe der Tabelle in Byte.

Users

Diese Tabelle enthält Informationen zu Nutzern.

Spalte Typ Beschreibung
UserName STRING Der Nutzername.
CreatorName STRING Der Name der Entität, die diesen Nutzer erstellt hat.
CreateTimestamp TIMESTAMP Der Zeitstempel für die Erstellung des Nutzers.
LastAccessTimestamp TIMESTAMP Der Zeitstempel, zu dem dieser Nutzer zuletzt auf eine Datenbank zugegriffen hat.

Amazon Redshift

Columns

Die Tabelle Columns stammt aus einer der folgenden Tabellen: SVV_COLUMNS, INFORMATION_SCHEMA.COLUMNS oder PG_TABLE_DEF, geordnet nach Priorität. Das Tool versucht zuerst, die Daten aus der Tabelle mit der höchsten Priorität zu laden. Wenn dies fehlschlägt, wird versucht, die Daten aus der Tabelle mit der zweithöchsten Priorität zu laden. Weitere Informationen zum Schema und zur Verwendung finden Sie in der Dokumentation zu Amazon Redshift und PostgreSQL.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Instanz.
SchemaName STRING Der Name des Schemas.
TableName STRING Der Name der Tabelle.
ColumnName STRING Der Name der Spalte.
DefaultValue STRING Der Standardwert, falls verfügbar.
Nullable BOOLEAN Gibt an, ob eine Spalte einen Nullwert haben kann.
ColumnType STRING Der Typ der Spalte, z. B. VARCHAR.
ColumnLength INTEGER Die Größe der Spalte, z. B. 30 für VARCHAR(30).

CreateAndDropStatistic

Die folgende Tabelle enthält Informationen zum Erstellen und Löschen von Tabellen.

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
DefaultDatabase STRING Die Standarddatenbank.
EntityType STRING Der Typ der Entität, z. B. TABLE.
EntityName STRING Der Name der Entität.
Operation STRING Der Vorgang: entweder CREATE oder DROP.

Databases

Diese Tabelle stammt direkt aus der Tabelle PG_DATABASE_INFO von Amazon Redshift. Die ursprünglichen Feldnamen aus der Tabelle „PG“ sind in den Beschreibungen enthalten. Weitere Informationen zum Schema und zur Verwendung finden Sie in der Dokumentation zu Amazon Redshift und PostgreSQL.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Instanz. Quellname: datname
Owner STRING Der Inhaber der Datenbank. Beispiel: der Nutzer, der die Datenbank erstellt hat. Quellname: datdba

ExternalColumns

Diese Tabelle enthält Informationen direkt aus der Tabelle SVV_EXTERNAL_COLUMNS von Amazon Redshift. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu Amazon Redshift.

Spalte Typ Beschreibung
SchemaName STRING Der Name des externen Schemas.
TableName STRING Der Name der externen Tabelle.
ColumnName STRING Der Name der externen Spalte.
ColumnType STRING Der Typ der Spalte.
Nullable BOOLEAN Gibt an, ob eine Spalte einen Nullwert haben kann.

ExternalDatabases

Diese Tabelle enthält Informationen direkt aus der Tabelle SVV_EXTERNAL_DATABASES von Amazon Redshift. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu Amazon Redshift.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der externen Datenbank.
Location STRING Der Speicherort der Datenbank.

ExternalPartitions

Diese Tabelle enthält Informationen aus der Tabelle SVV_EXTERNAL_PARTITIONS von Amazon Redshift. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu Amazon Redshift.

Spalte Typ Beschreibung
SchemaName STRING Der Name des externen Schemas.
TableName STRING Der Name der externen Tabelle.
Location STRING Der Speicherort der Partition. Die Spaltengröße ist auf 128 Zeichen beschränkt. Längere Werte werden abgeschnitten.

ExternalSchemas

Diese Tabelle enthält Informationen direkt aus der Tabelle SVV_EXTERNAL_SCHEMAS von Amazon Redshift. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu Amazon Redshift.

Spalte Typ Beschreibung
SchemaName STRING Der Name des externen Schemas.
DatabaseName STRING Der Name der externen Datenbank.

ExternalTables

Diese Tabelle enthält Informationen aus der Tabelle SVV_EXTERNAL_TABLES direkt von Amazon Redshift. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu Amazon Redshift.

Spalte Typ Beschreibung
SchemaName STRING Der Name des externen Schemas.
TableName STRING Der Name der externen Tabelle.

Functions

Diese Tabelle enthält direkt Informationen aus der Tabelle PG_PROC von Amazon Redshift. Weitere Informationen zum Schema und zur Verwendung finden Sie in der Dokumentation zu Amazon Redshift und PostgreSQL.

Spalte Typ Beschreibung
SchemaName STRING Der Name des Schemas.
FunctionName STRING Der Name der Funktion.
LanguageName STRING Die Implementierungssprache oder die Aufrufschnittstelle dieser Funktion.

Queries

Diese Tabelle wird mit den Informationen aus der Tabelle QueryLogs generiert. Im Gegensatz zur Tabelle QueryLogs enthält jede Zeile in der Tabelle „Queries“ nur eine einzige Abfrageanweisung, die in der Spalte „QueryText“ gespeichert ist. Diese Tabelle enthält die Quelldaten zum Generieren der Statistiktabellen und Übersetzungsausgaben.

Spalte Typ Beschreibung
QueryText STRING Der Text der Abfrage.
QueryHash STRING Der Hash der Abfrage.

QueryLogs

Diese Tabelle enthält Informationen zur Abfrageausführung.

Spalte Typ Beschreibung
QueryText STRING Der Text der Abfrage.
QueryHash STRING Der Hash der Abfrage.
QueryID STRING Die ID der Abfrage.
UserID STRING Die ID des Nutzers.
StartTime TIMESTAMP Die Startzeit.
Duration INTEGER Dauer in Millisekunden.

QueryTypeStatistics

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
DefaultDatabase STRING Die Standarddatenbank.
QueryType STRING Der Typ der Abfrage.
UpdatedTable STRING Die aktualisierte Tabelle.
QueriedTables ARRAY<STRING> Die abgefragten Tabellen.

TableInfo

Diese Tabelle enthält Informationen, die aus der Tabelle SVV_TABLE_INFO in Amazon Redshift extrahiert wurden.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Instanz.
SchemaName STRING Der Name des Schemas.
TableId INTEGER Die Tabellen-ID.
TableName STRING Der Name der Tabelle.
SortKey1 STRING Erste Spalte im Sortierschlüssel.
SortKeyNum INTEGER Anzahl der als Sortierschlüssel definierten Spalten.
MaxVarchar INTEGER Größe der größten Spalte, die den Datentyp VARCHAR verwendet.
Size INTEGER Größe der Tabelle in 1 MB großen Datenblöcken.
TblRows INTEGER Anzahl der Zeilen in der Tabelle.

TableRelations

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage, die die Beziehung hergestellt hat (z. B. eine JOIN-Abfrage).
DefaultDatabase STRING Die Standarddatenbank.
TableName1 STRING Die erste Tabelle der Beziehung.
TableName2 STRING Die zweite Tabelle der Beziehung.
Relation STRING Die Art der Beziehung. Nimmt einen der folgenden Werte: COMMA_JOIN, CROSS_JOIN, FULL_OUTER_JOIN, INNER_JOIN, LEFT_OUTER_JOIN, RIGHT_OUTER_JOIN, CREATED_FROM, oder INSERT_INTO.
Count INTEGER Wie oft diese Beziehung beobachtet wurde.

TableSizes

Diese Tabelle enthält Informationen zu Tabellengrößen.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Instanz.
SchemaName STRING Der Name des Schemas.
TableName STRING Der Name der Tabelle.
TableSizeInBytes INTEGER Die Größe der Tabelle in Byte.

Tables

Diese Tabelle enthält Informationen, die aus der Tabelle SVV_TABLES in Amazon Redshift extrahiert wurden. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu Amazon Redshift.

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Instanz.
SchemaName STRING Der Name des Schemas.
TableName STRING Der Name der Tabelle.
TableType STRING Der Typ der Tabelle.

TranslatedQueries

Diese Tabelle enthält Abfrageübersetzungen.

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
TranslatedQueryText STRING Ergebnis der Übersetzung vom Quelldialekt zu GoogleSQL.

TranslationErrors

Diese Tabelle enthält Informationen zu Fehlern bei der Abfrageübersetzung.

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
Severity STRING Die Schwere des Fehlers, z. B. ERROR.
Category STRING Die Kategorie des Fehlers, z. B. AttributeNotFound.
Message STRING Die Nachricht mit den Fehlerdetails.
LocationOffset INTEGER Die Zeichenposition des Fehlerorts.
LocationLine INTEGER Die Zeilennummer des Fehlers.
LocationColumn INTEGER Die Spaltennummer des Fehlers.
LocationLength INTEGER Die Zeichenlänge der Position des Fehlers.

UserTableRelations

Spalte Typ Beschreibung
UserID STRING Die Nutzer-ID.
TableName STRING Der Name der Tabelle.
Relation STRING Die Beziehung.
Count INTEGER Die Anzahl.

Users

Diese Tabelle enthält Informationen, die aus der Tabelle PG_USER in Amazon Redshift extrahiert wurden. Weitere Informationen zum Schema und zur Nutzung finden Sie in der Dokumentation zu PostgreSQL.

Spalte Typ Beschreibung
UserName STRING Der Nutzername.
UserId STRING Die Nutzer-ID.

Apache Hive

Columns

Diese Tabelle enthält Informationen zu den Spalten:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
ColumnName STRING Der Name der Spalte mit beibehaltener Groß-/Kleinschreibung.
ColumnType STRING Der BigQuery-Typ der Spalte, z. B. STRING.
OriginalColumnType STRING Der ursprüngliche Typ der Spalte, z. B. VARCHAR.

CreateAndDropStatistic

Die folgende Tabelle enthält Informationen zum Erstellen und Löschen von Tabellen:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
DefaultDatabase STRING Die Standarddatenbank.
EntityType STRING Der Typ der Entität, z. B. TABLE.
EntityName STRING Der Name der Entität.
Operation STRING Der Vorgang, der für die Tabelle ausgeführt wird (CREATE oder DROP).

Databases

Diese Tabelle enthält Informationen zu den Datenbanken:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
Owner STRING Der Inhaber der Datenbank. Beispiel: der Nutzer, der die Datenbank erstellt hat.
Location STRING Speicherort der Datenbank im Dateisystem.

Functions

Diese Tabelle enthält Informationen zu den Funktionen:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
FunctionName STRING Der Name der Funktion.
LanguageName STRING Der Name der Sprache.
ClassName STRING Der Klassenname der Funktion.

ObjectReferences

Diese Tabelle enthält Informationen zu den Objekten, auf die in Abfragen verwiesen wird:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
DefaultDatabase STRING Die Standarddatenbank.
Clause STRING Die Klausel, in der das Objekt vorkommt. Beispiel: SELECT.
ObjectName STRING Der Name des Objekts.
Type STRING Der Typ des Objekts.
Subtype STRING Der Untertyp des Objekts.

ParititionKeys

Die folgende Tabelle enthält Informationen zu den Partitionsschlüsseln:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
ColumnName STRING Der Name der Spalte mit beibehaltener Groß-/Kleinschreibung.
ColumnType STRING Der BigQuery-Typ der Spalte, z. B. STRING.

Parititions

Diese Tabelle enthält Informationen zu den Tabellenpartitionen:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
PartitionName STRING Der Name der Partition.
CreateTimestamp TIMESTAMP Der Zeitstempel der Erstellung dieser Partition.
LastAccessTimestamp TIMESTAMP Der Zeitstempel des letzten Zugriffs auf diese Partition.
LastDdlTimestamp TIMESTAMP Der Zeitstempel der letzten Änderung dieser Partition.
TotalSize INTEGER Die komprimierte Größe der Partition in Byte.

Queries

Diese Tabelle wird mit den Informationen aus der Tabelle QueryLogs generiert. Im Gegensatz zur Tabelle QueryLogs enthält jede Zeile in der Tabelle „Queries“ nur eine einzige Abfrageanweisung, die in der Spalte QueryText gespeichert ist. Diese Tabelle enthält die Quelldaten zum Generieren der Statistiktabellen und Übersetzungsausgaben:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
QueryText STRING Der Text der Abfrage.

QueryLogs

Diese Tabelle enthält einige Ausführungsstatistiken zu den extrahierten Abfragen:

Spalte Typ Beschreibung
QueryText STRING Der Text der Abfrage.
QueryHash STRING Der Hash der Abfrage.
QueryId STRING Die ID der Abfrage.
QueryType STRING Der Typ der Abfrage, entweder Query oder DDL.
UserName STRING Der Name des Nutzers, der die Abfrage ausgeführt hat.
StartTime TIMESTAMP Der Zeitstempel für das Senden der Abfrage.
Duration STRING Die Dauer der Abfrage in Millisekunden.

QueryTypeStatistics

Diese Tabelle enthält Statistiken zu Abfragetypen:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
QueryType STRING Der Typ der Abfrage.
UpdatedTable STRING Gegebenenfalls die von der Abfrage aktualisierte Tabelle.
QueriedTables ARRAY<STRING> Eine Liste der abgefragten Tabellen.

QueryTypes

Diese Tabelle enthält Statistiken zu Abfragetypen:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
Category STRING Die Kategorie der Abfrage.
Type STRING Der Typ der Abfrage.
Subtype STRING Der Untertyp der Abfrage.

SchemaConversion

Die folgende Tabelle enthält Informationen zu Schemakonvertierungen im Zusammenhang mit Clustering und Partitionierung:

Spaltenname Spaltentyp Beschreibung
DatabaseName STRING Der Name der Quelldatenbank, für die der Vorschlag gemacht wird. Eine Datenbank ist einem Dataset in BigQuery zugeordnet.
TableName STRING Der Name der Tabelle, für die der Vorschlag gemacht wird.
PartitioningColumnName STRING Der Name der vorgeschlagenen Partitionierungsspalte in BigQuery.
ClusteringColumnNames ARRAY Die Namen der vorgeschlagenen Clustering-Spalten in BigQuery.
CreateTableDDL STRING Die CREATE TABLE statement zum Erstellen der Tabelle in BigQuery.

TableRelations

Diese Tabelle enthält Informationen zu Tabellen:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage, die die Beziehung hergestellt hat.
DatabaseName1 STRING Der Name der ersten Datenbank.
TableName1 STRING Der Name der ersten Tabelle.
DatabaseName2 STRING Der Name der zweiten Datenbank.
TableName2 STRING Der Name der zweiten Tabelle.
Relation STRING Die Art der Beziehung zwischen den beiden Tabellen.

TableSizes

Diese Tabelle enthält Informationen zu Tabellengrößen:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
TotalSize INTEGER Die Größe der Tabelle in Byte.

Tables

Diese Tabelle enthält Informationen zu Tabellen:

Spalte Typ Beschreibung
DatabaseName STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung.
TableName STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung.
Type STRING Der Typ der Tabelle.

TranslatedQueries

Diese Tabelle enthält Abfrageübersetzungen:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
TranslatedQueryText STRING Das Ergebnis der Übersetzung vom Quelldialekt in GoogleSQL.

TranslationErrors

Diese Tabelle enthält Informationen zu Fehlern bei der Abfrageübersetzung:

Spalte Typ Beschreibung
QueryHash STRING Der Hash der Abfrage.
Severity STRING Die Schwere des Fehlers, z. B. ERROR.
Category STRING Die Kategorie des Fehlers, z. B. AttributeNotFound.
Message STRING Die Nachricht mit den Fehlerdetails.
LocationOffset INTEGER Die Zeichenposition des Fehlerorts.
LocationLine INTEGER Die Zeilennummer des Fehlers.
LocationColumn INTEGER Die Spaltennummer des Fehlers.
LocationLength INTEGER Die Zeichenlänge der Position des Fehlers.

UserTableRelations

Spalte Typ Beschreibung
UserID STRING Die Nutzer-ID.
TableName STRING Der Name der Tabelle.
Relation STRING Die Beziehung.
Count INTEGER Die Anzahl.

Snowflake

Warehouses

Spalte Typ Beschreibung Präsenz
WarehouseName STRING Der Name des Warehouse. Immer
State STRING Der Status des Warehouse. Mögliche Werte: STARTED, SUSPENDED, RESIZING. Immer
Type STRING Warehouse-Typ. Mögliche Werte: STANDARD, SNOWPARK-OPTIMIZED. Immer
Size STRING Größe des Warehouse. Mögliche Werte: X-Small, Small, Medium, Large, X-Large, 2X-Large ... 6X-Large. Immer

Databases

Spalte Typ Beschreibung Präsenz
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung. Immer
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt. Immer

Schemata

Spalte Typ Beschreibung Präsenz
DatabaseNameOriginal STRING Der Name der Datenbank, zu der das Schema gehört, wobei die Groß-/Kleinschreibung beibehalten wird. Immer
DatabaseName STRING Der Name der Datenbank, zu der das Schema gehört, in Kleinbuchstaben umgewandelt. Immer
SchemaNameOriginal STRING Der Name des Schemas, wobei die Groß-/Kleinschreibung beibehalten wird. Immer
SchemaName STRING Der Name des Schemas, in Kleinbuchstaben umgewandelt. Immer

Tables

Spalte Typ Beschreibung Präsenz
DatabaseNameOriginal STRING Der Name der Datenbank, zu der die Tabelle gehört, wobei die Groß-/Kleinschreibung beibehalten wird. Immer
DatabaseName STRING Der Name der Datenbank, zu der die Tabelle gehört, in Kleinbuchstaben umgewandelt. Immer
SchemaNameOriginal STRING Der Name des Schemas, zu dem die Tabelle gehört, wobei die Groß-/Kleinschreibung beibehalten wird. Immer
SchemaName STRING Der Name des Schemas, zu dem die Tabelle gehört, in Kleinbuchstaben umgewandelt. Immer
TableNameOriginal STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung. Immer
TableName STRING Der Name der Tabelle, in Kleinbuchstaben umgewandelt. Immer
TableType STRING Typ der Tabelle (Ansicht / Materialisierte Ansicht / Basistabelle). Immer
RowCount BIGNUMERIC Anzahl der Zeilen in der Tabelle. Immer

Columns

Spalte Typ Beschreibung Präsenz
DatabaseName STRING Der Name der Datenbank, in Kleinbuchstaben umgewandelt. Immer
DatabaseNameOriginal STRING Der Name der Datenbank mit beibehaltener Groß-/Kleinschreibung. Immer
SchemaName STRING Der Name des Schemas, in Kleinbuchstaben umgewandelt. Immer
SchemaNameOriginal STRING Der Name des Schemas, wobei die Groß-/Kleinschreibung beibehalten wird. Immer
TableName STRING Der Name der Tabelle, in Kleinbuchstaben umgewandelt. Immer
TableNameOriginal STRING Der Name der Tabelle mit beibehaltener Groß-/Kleinschreibung. Immer
ColumnName STRING Der Name der Spalte, in Kleinbuchstaben umgewandelt. Immer
ColumnNameOriginal STRING Der Name der Spalte mit beibehaltener Groß-/Kleinschreibung. Immer
ColumnType STRING Der Typ der Spalte. Immer

CreateAndDropStatistics

Spalte Typ Beschreibung Präsenz
QueryHash STRING Der Hash der Abfrage. Immer
DefaultDatabase STRING Die Standarddatenbank. Immer
EntityType STRING Der Typ der Entität, z. B. TABLE. Immer
EntityName STRING Der Name der Entität. Immer
Operation STRING Der Vorgang: entweder CREATE oder DROP. Immer

Queries

Spalte Typ Beschreibung Präsenz
QueryText STRING Der Text der Abfrage. Immer
QueryHash STRING Der Hash der Abfrage. Immer

QueryLogs

Spalte Typ Beschreibung Präsenz
QueryText STRING Der Text der Abfrage. Immer
QueryHash STRING Der Hash der Abfrage. Immer
QueryID STRING Die ID der Abfrage. Immer
UserID STRING Die ID des Nutzers. Immer
StartTime TIMESTAMP Die Startzeit. Immer
Duration INTEGER Dauer in Millisekunden. Immer

QueryTypeStatistics

Spalte Typ Beschreibung Präsenz
QueryHash STRING Der Hash der Abfrage. Immer
DefaultDatabase STRING Die Standarddatenbank. Immer
QueryType STRING Der Typ der Abfrage. Immer
UpdatedTable STRING Die aktualisierte Tabelle. Immer
QueriedTables REPEATED STRING Die abgefragten Tabellen. Immer

TableRelations

Spalte Typ Beschreibung Präsenz
QueryHash STRING Der Hash der Abfrage, die die Beziehung hergestellt hat (z. B. eine JOIN-Abfrage). Immer
DefaultDatabase STRING Die Standarddatenbank. Immer
TableName1 STRING Die erste Tabelle der Beziehung. Immer
TableName2 STRING Die zweite Tabelle der Beziehung. Immer
Relation STRING Die Art der Beziehung. Immer
Count INTEGER Wie oft diese Beziehung beobachtet wurde. Immer

TranslatedQueries

Spalte Typ Beschreibung Präsenz
QueryHash STRING Der Hash der Abfrage. Immer
TranslatedQueryText STRING Ergebnis der Übersetzung vom Quelldialekt in BigQuery SQL. Immer

TranslationErrors

Spalte Typ Beschreibung Präsenz
QueryHash STRING Der Hash der Abfrage. Immer
Severity STRING Der Schweregrad des Fehlers, z. B. ERROR. Immer
Category STRING Die Kategorie des Fehlers, z. B. AttributeNotFound. Immer
Message STRING Die Nachricht mit den Fehlerdetails. Immer
LocationOffset INTEGER Die Zeichenposition des Fehlerorts. Immer
LocationLine INTEGER Die Zeilennummer des Fehlers. Immer
LocationColumn INTEGER Die Spaltennummer des Fehlers. Immer
LocationLength INTEGER Die Zeichenlänge der Position des Fehlers. Immer

UserTableRelations

Spalte Typ Beschreibung Präsenz
UserID STRING Nutzer-ID Immer
TableName STRING Der Name der Tabelle. Immer
Relation STRING Die Beziehung. Immer
Count INTEGER Die Anzahl. Immer

Fehlerbehebung

In diesem Abschnitt werden einige häufige Probleme und Techniken zur Fehlerbehebung bei der Migration Ihres Data Warehouse zu BigQuery erläutert.

Fehler im dwh-migration-dumper-Tool

Informationen zur Behebung von Fehlern und Warnungen in der Terminalausgabe des dwh-migration-dumper-Tools, die während der Extraktion von Metadaten oder Abfragelogs aufgetreten sind, finden Sie unter Fehlerbehebung bei Metadaten generieren.

Fehler bei der Hive-Migration

In diesem Abschnitt werden häufige Probleme beschrieben, die bei der Migration Ihres Data Warehouse von Hive zu BigQuery auftreten können.

Der Logging-Hook schreibt Debugging-Logeinträge in Ihre hive-server2-Logs. Überprüfen Sie bei Problemen die Logging-Hook-Debugging-Logs, die den String MigrationAssessmentLoggingHook enthalten.

Fehler ClassNotFoundException verarbeiten

Der Fehler kann dadurch verursacht werden, dass die Logging-Hook-JAR-Datei am falschen Ort gespeichert wurde. Prüfen Sie, ob Sie die JAR-Datei dem Ordner „auxlib“ im Hive-Cluster hinzugefügt haben. Alternativ können Sie den vollständigen Pfad zur JAR-Datei im Attribut hive.aux.jars.path angeben, z. B. file:///HiveMigrationAssessmentQueryLogsHooks_deploy.jar.

Unterordner werden nicht im konfigurierten Ordner angezeigt

Dieses Problem kann durch eine fehlerhafte Konfiguration oder Probleme bei der Logging-Hook-Initialisierung verursacht werden.

Suchen Sie in den hive-server2-Debugging-Logs nach den folgenden Logging-Hook-Einträgen:

Unable to initialize logger, logging disabled
Log dir configuration key 'dwhassessment.hook.base-directory' is not set,
logging disabled.
Error while trying to set permission

Sehen Sie sich die Problemdetails an und prüfen Sie, ob Sie etwas korrigieren müssen, um das Problem zu beheben.

Dateien werden nicht im Ordner angezeigt

Dieses Problem kann durch Probleme verursacht werden, die während einer Ereignisverarbeitung oder beim Schreiben in eine Datei aufgetreten sind.

Suchen Sie in den hive-server2-Debugging-Logs nach den folgenden Logging-Hook-Einträgen:

Failed to close writer for file
Got exception while processing event
Error writing record for query

Sehen Sie sich die Problemdetails an und prüfen Sie, ob Sie etwas korrigieren müssen, um das Problem zu beheben.

Einige Abfrageereignisse fehlen

Dieses Problem kann durch einen Überlauf der Logging-Hook-Thread-Warteschlange verursacht werden.

Suchen Sie in den hive-server2-Debugging-Logs nach dem folgenden Logging-Hook-Eintrag:

Writer queue is full. Ignoring event

Wenn solche Einträge vorhanden sind, sollten Sie den Parameter dwhassessment.hook.queue.capacity erhöhen.

Nächste Schritte

Weitere Informationen zum dwh-migration-dumper-Tool finden Sie unter dwh-migration-tools.

Weitere Informationen zu den folgenden Schritten bei der Data-Warehouse-Migration: