Schema und Daten aus Apache Hive migrieren

In diesem Dokument wird beschrieben, wie Sie Ihre Daten, Sicherheitseinstellungen und Pipelines von Apache Hive zu BigQuery migrieren.

Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen. Apache HiveQL wird von beiden SQL-Übersetzungsdiensten vollständig unterstützt.

Migration vorbereiten

In den folgenden Abschnitten wird beschrieben, wie Sie Informationen zu Tabellenstatistiken, Metadaten und Sicherheitseinstellungen erfassen, um Ihr Data Warehouse von Hive zu BigQuery zu migrieren.

Informationen zu Quelltabelle erfassen

Sammeln Sie Informationen zu Hive-Quelltabellen, z. B. deren Anzahl der Zeilen, Anzahl der Spalten, Spaltendatentypen, Größe, Eingabeformat der Daten und Standort. Diese Informationen sind nützlich für die Migration und auch für die Validierung der Datenmigration. Wenn Sie eine Hive-Tabelle namens employees in einer Datenbank namens corp haben, verwenden Sie die folgenden Befehle, um Tabelleninformationen zu erfassen:

# Find the number of rows in the table
hive> SELECT COUNT(*) FROM corp.employees;

# Output all the columns and their data types
hive> DESCRIBE corp.employees;

# Output the input format and location of the table
hive> SHOW CREATE TABLE corp.employees;
Output:
…
STORED AS INPUTFORMAT
  'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat'
LOCATION
  'hdfs://demo_cluster/user/hive/warehouse/corp/employees'
TBLPROPERTIES (
…

# Get the total size of the table data in bytes
shell> hdfs dfs -du -s TABLE_LOCATION

Umwandlung des Quelltabellenformats

Einige der von Hive unterstützten Formate können nicht direkt in BigQuery aufgenommen werden.

Hive unterstützt das Speichern von Daten in den folgenden Formaten:

Textdatei
RC-Datei
Sequenzdatei
Avro-Datei
ORC-Datei
Parquet-Datei

BigQuery unterstützt das Laden von Daten aus Cloud Storage mit den folgenden Dateiformaten:

CSV
JSON (durch Zeilenumbruch getrennt)
Avro
ORC
Parquet

BigQuery kann Datendateien in den Formaten Avro, ORC und Parquet direkt ohne Schemadateien laden. Bei Textdateien, die nicht als CSV- oder JSON-Datei (durch Zeilenumbruch getrennt) formatiert sind, können Sie entweder die Daten in eine Hive-Tabelle im Avro-Format kopieren oder das Tabellenschema in eine BigQuery-JSON-Schema, das bei der Aufnahme bereitgestellt werden soll.

Hive-Zugriffssteuerungseinstellungen erfassen

Hive und BigQuery haben unterschiedliche Zugriffssteuerungsmechanismen. Sammeln Sie alle Einstellungen für die Hive-Zugriffssteuerung wie Rollen, Gruppen, Mitglieder und Berechtigungen, die ihnen zugewiesen sind. Planen Sie ein Sicherheitsmodell in BigQuery auf Dataset-Ebene und implementieren Sie eine differenzierte ACL. Ein Hive-Nutzer kann beispielsweise einem Google-Konto und eine HDFS-Gruppe einer Google-Gruppe zugeordnet werden. Der Zugriff kann auf Dataset-Ebene festgelegt werden. Verwenden Sie die folgenden Befehle, um die Einstellungen für die Zugriffssteuerung in Hive zu erfassen:

# List all the users
> hdfs dfs -ls /user/ | cut -d/ -f3

# Show all the groups that a specific user belongs to
> hdfs groups user_name

# List all the roles
hive> SHOW ROLES;

# Show all the roles assigned to a specific group
hive> SHOW ROLE GRANT GROUP group_name

# Show all the grants for a specific role
hive> SHOW GRANT ROLE role_name;

# Show all the grants for a specific role on a specific object
hive> SHOW GRANT ROLE role_name on object_type object_name;

In Hive können Sie direkt auf die HDFS-Dateien hinter den Tabellen zugreifen, wenn Sie die erforderlichen Berechtigungen haben. In Standard-BigQuery-Tabellen werden die Daten nach dem Laden in die Tabelle im BigQuery-Speicher gespeichert. Sie können Daten mit der BigQuery Storage Read API lesen, aber die gesamte Sicherheit auf IAM-, Zeilen- und Spaltenebene wird weiterhin erzwungen. Wenn Sie externe BigQuery-Tabellen zum Abfragen der Daten in Cloud Storage verwenden, wird der Zugriff auf Cloud Storage auch durch IAM gesteuert.

Sie können eine BigLake-Tabelle erstellen, mit der Sie die Connectors zum Abfragen der Daten mit Apache Spark, Trino oder Apache Hive verwenden können. Die BigQuery Storage API erzwingt Richtlinien für die Zeilen- und Spaltenebene für alle BigLake-Tabellen in Cloud Storage oder BigQuery.

Datenmigration

Die Migration von Hive-Daten von Ihrem lokalen oder einem anderen cloudbasierten Quellcluster zu BigQuery umfasst zwei Schritte:

Daten aus einem Quellcluster in Cloud Storage kopieren
Daten aus Cloud Storage in BigQuery laden

In den folgenden Abschnitten wird die Migration von Hive-Daten, die Validierung migrierter Daten und die Migration von kontinuierlich aufgenommenen Daten behandelt. Die Beispiele wurden für Nicht-ACID-Tabellen geschrieben.

Daten in Partitionsspalten

In Hive werden Daten in partitionierten Tabellen in einer Verzeichnisstruktur gespeichert. Jede Partition der Tabelle ist mit einem bestimmten Wert der Partitionsspalte verknüpft. Die Datendateien selbst enthalten keine Daten der Partitionsspalten. Verwenden Sie den Befehl SHOW PARTITIONS, um die verschiedenen Partitionen in einer partitionierten Tabelle aufzulisten.

Das folgende Beispiel zeigt, dass die Hive-Quelltabelle nach den Spalten joining_date und department partitioniert ist. Die Datendateien in dieser Tabelle enthalten keine Daten im Zusammenhang mit diesen beiden Spalten.

hive> SHOW PARTITIONS corp.employees_partitioned
joining_date="2018-10-01"/department="HR"
joining_date="2018-10-01"/department="Analyst"
joining_date="2018-11-01"/department="HR"

Eine Möglichkeit zum Kopieren dieser Spalten besteht darin, die partitionierte Tabelle in eine nicht partitionierte Tabelle zu konvertieren, bevor sie in BigQuery geladen wird:

Erstellen Sie eine nicht partitionierte Tabelle mit einem Schema, das der partitionierten Tabelle ähnelt.
Laden Sie Daten aus der partitionierten Quelltabelle in die nicht partitionierte Tabelle.
Kopieren Sie diese Datendateien unter der bereitgestellten nicht partitionierten Tabelle nach Cloud Storage.
Laden Sie die Daten mit dem Befehl bq load in BigQuery und geben Sie gegebenenfalls den Namen der Partitionsspalte TIMESTAMP oder DATE als Argument time_partitioning_field an.

Daten in Cloud Storage kopieren

Der erste Schritt bei der Datenmigration besteht darin, die Daten in Cloud Storage zu kopieren. Verwenden Sie Hadoop DistCp, um Daten aus Ihrem lokalen oder anderen Cloud-Cluster in Cloud Storage zu kopieren. Speichern Sie Ihre Daten in einem Bucket in derselben Region oder Multiregion wie das Dataset, in dem Sie die Daten in BigQuery speichern möchten. Wenn Sie beispielsweise ein vorhandenes BigQuery-Dataset als Ziel in der Region Tokio verwenden möchten, müssen Sie einen regionalen Cloud Storage-Bucket in Tokio auswählen, um die Daten zu speichern.

Nachdem Sie den Speicherort des Cloud Storage-Buckets ausgewählt haben, können Sie mit dem folgenden Befehl alle Datendateien auflisten, die am Speicherort der Hive-Tabelle employees vorhanden sind:

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0

Kopieren Sie alle Dateien von oben in Cloud Storage:

> hadoop distcp
hdfs://demo_cluster/user/hive/warehouse/corp/employees
gs://hive_data/corp/employees

Beachten Sie, dass Ihnen das Speichern der Daten in Cloud Storage gemäß den Preisen für die Datenspeicherung in Rechnung gestellt wird.

Es können Staging-Verzeichnisse vorhanden sein, die Zwischendateien enthalten, die für Abfragejobs erstellt wurden. Achten Sie darauf, dass Sie solche Verzeichnisse löschen, bevor Sie den Befehl bq load ausführen.

Daten laden

BigQuery unterstützt das Laden von Daten im Batch in vielen Formaten aus Cloud Storage. Achten Sie darauf, dass das BigQuery-Dataset, in das Sie Ihre Daten laden möchten, bereits vorhanden ist, bevor Sie einen Ladejob erstellen.

Der folgende Befehl zeigt die Daten, die aus Hive für eine Nicht-ACID-Tabelle kopiert wurden:

> gcloud storage ls gs://hive_data/corp/employees/
gs://hive-migration/corp/employees/
gs://hive-migration/corp/employees/000000_0
gs://hive-migration/corp/employees/000001_0
gs://hive-migration/corp/employees/000002_0

Verwenden Sie den Befehl bq load, um Ihre Hive-Daten in BigQuery zu laden. In der URL können Sie das Platzhalterzeichen * verwenden, um Daten aus mehreren Dateien mit einem gemeinsamen Objektpräfix zu laden. Verwenden Sie beispielsweise den folgenden Befehl, um alle Dateien mit dem Präfix gs://hive_data/corp/employees/ zu laden:

bq load --source_format=AVRO corp.employees gs://hive_data/corp/employees/*

Da das Ausführen von Jobs sehr lange dauern kann, können Sie sie asynchron ausführen. Setzen Sie dazu das Flag --sync auf False. Durch Ausführen des Befehls bq load wird die Job-ID des erstellten Ladejobs ausgegeben. Sie können mit diesem Befehl den Jobstatus abfragen. Diese Daten enthalten Details wie den Jobtyp, den Jobstatus und den Nutzer, der den Job ausgeführt hat.

Fragen Sie den Status jedes Ladejobs anhand der entsprechenden Job-ID ab und überprüfen Sie, ob ein Job mit Fehlern fehlgeschlagen ist. Im Falle eines Fehlers verwendet BigQuery beim Laden von Daten in eine Tabelle die Methode „Alle oder Keine“. Sie können versuchen, die Fehler zu beheben, und einen weiteren Ladejob neu erstellen. Weitere Informationen finden Sie unter Fehlerbehebung.

Achten Sie darauf, dass Ihr Kontingent für Ladejobs pro Tabelle und Projekt ausreicht. Wenn Sie das Kontingent überschreiten, schlägt der Ladejob mit dem Fehler quotaExceeded fehl.

Beachten Sie, dass Ihnen keine Kosten für das Laden von Daten aus Cloud Storage in BigQuery berechnet werden. Sobald die Daten in BigQuery geladen sind, gelten die entsprechenden Speicherpreise von BigQuery. Wenn die Ladejobs erfolgreich abgeschlossen sind, können Sie die verbleibenden Dateien in Cloud Storage löschen. Dadurch vermeiden Sie Gebühren für das Speichern redundanter Daten.

Validierung

Nachdem Sie Daten erfolgreich geladen haben, können Sie Ihre migrierten Daten prüfen. Vergleichen Sie dazu die Anzahl der Zeilen in der Hive und den BigQuery-Tabellen. In den Tabelleninformationen finden Sie Details zu BigQuery-Tabellen, z. B. die Anzahl der Zeilen, die Anzahl der Spalten, Partitionierungsfelder oder Clustering-Felder. Verwenden Sie zur weiteren Validierung das Datenvalidierungstool.

Kontinuierliche Aufnahme

Wenn Sie kontinuierlich Daten in eine Hive-Tabelle aufnehmen, führen Sie eine erste Migration durch und migrieren Sie dann nur die inkrementellen Datenänderungen zu BigQuery. Es ist üblich, Skripts zu erstellen, die wiederholt ausgeführt werden, um neue Daten zu finden und zu laden. Dafür gibt es viele Möglichkeiten. In den folgenden Abschnitten wird ein möglicher Ansatz beschrieben.

Sie können den Migrationsfortschritt in einer Cloud SQL-Datenbanktabelle verfolgen, die in den folgenden Abschnitten als Tracking-Tabelle bezeichnet wird. Speichern Sie bei der ersten Ausführung der Migration den Fortschritt in der Tracking-Tabelle. Bei den nachfolgenden Migrationsausführungen können Sie anhand der Tracking-Tabelleninformationen feststellen, ob zusätzliche Daten aufgenommen wurden und zu BigQuery migriert werden können.

Wählen Sie eine Spalte des Typs INT64, TIMESTAMP oder DATE aus, um die inkrementellen Daten zu unterscheiden. Dies wird als inkrementelle Spalte bezeichnet.

Die folgende Tabelle ist ein Beispiel für eine Tabelle ohne Partitionierung, die einen TIMESTAMP-Typ für ihre inkrementelle Spalte verwendet:

+-----------------------------+-----------+-----------+-----------+-----------+
| timestamp_identifier        | column_2  | column_3  | column_4  | column_5  |
+-----------------------------+-----------+-----------+-----------+-----------+
| 2018-10-10 21\:56\:41       |           |           |           |           |
| 2018-10-11 03\:13\:25       |           |           |           |           |
| 2018-10-11 08\:25\:32       |           |           |           |           |
| 2018-10-12 05\:02\:16       |           |           |           |           |
| 2018-10-12 15\:21\:45       |           |           |           |           |
+-----------------------------+-----------+-----------+-----------+-----------+

Die folgende Tabelle ist ein Beispiel für eine Tabelle, die nach einer DATE-typisierten Spalte partition_column partitioniert ist. Sie hat in jeder Partition eine inkrementelle Spalte int_identifier vom Typ „Ganzzahl“.

+---------------------+---------------------+----------+----------+-----------+
| partition_column    | int_identifier      | column_3 | column_4 | column_5  |
+---------------------+---------------------+----------+----------+-----------+
| 2018-10-01          | 1                   |          |          |           |
| 2018-10-01          | 2                   |          |          |           |
| ...                 | ...                 |          |          |           |
| 2018-10-01          | 1000                |          |          |           |
| 2018-11-01          | 1                   |          |          |           |
| 2018-11-01          | 2                   |          |          |           |
| ...                 | ...                 |          |          |           |
| 2018-11-01          | 2000                |          |          |           |
+---------------------+---------------------+----------+----------+-----------+

In den folgenden Abschnitten wird beschrieben, wie Sie Hive-Daten migrieren, je nachdem, ob sie partitioniert sind oder nicht und ob sie inkrementelle Spalten enthalten.

Nicht partitionierte Tabelle ohne inkrementelle Spalten

Wenn keine Dateiverdichtungen in Hive vorhanden sind, erstellt Hive neue Datendateien bei der Aufnahme neuer Daten. Speichern Sie bei der ersten Ausführung die Liste der Dateien in der Tracking-Tabelle und schließen Sie die erste Migration der Hive-Tabelle ab. Kopieren Sie dazu diese Dateien nach Cloud Storage und laden Sie sie in BigQuery.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
Found 3 items
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0

Nach der ersten Migration werden einige Daten in Hive aufgenommen. Sie müssen diese inkrementellen Daten nur zu BigQuery migrieren. Listen Sie bei den nachfolgenden Migrationsausführungen die Datendateien noch einmal auf und vergleichen Sie sie mit den Informationen aus der Tracking-Tabelle, um neue Datendateien zu erkennen, die noch nicht migriert wurden.

> hdfs dfs -ls hdfs://demo_cluster/user/hive/warehouse/corp/employees
Found 5 items
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000000_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000001_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000002_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000003_0
hdfs://demo_cluster/user/hive/warehouse/corp/employees/000004_0

In diesem Beispiel sind am Speicherort der Tabelle zwei neue Dateien vorhanden. Migrieren Sie die Daten. Kopieren Sie dazu diese neuen Datendateien nach Cloud Storage und laden Sie sie in die vorhandene BigQuery-Tabelle.

Nicht partitionierte Tabelle mit inkrementellen Spalten

In diesem Fall können Sie den Höchstwert inkrementeller Spalten verwenden, um festzustellen, ob neue Daten hinzugefügt wurden. Fragen Sie bei der ersten Migration die Hive-Tabelle ab, um den Höchstwert der inkrementellen Spalte abzurufen und in der Tracking-Tabelle zu speichern:

hive> SELECT MAX(timestamp_identifier) FROM corp.employees;
2018-12-31 22:15:04

Wiederholen Sie dieselbe Abfrage in den nachfolgenden Migrationsausführungen noch einmal, um den aktuellen Maximalwert der inkrementellen Spalte abzurufen und mit dem vorherigen Höchstwert aus der Tracking-Tabelle zu vergleichen. So können Sie prüfen, ob inkrementelle Daten vorhanden sind:

hive> SELECT MAX(timestamp_identifier) FROM corp.employees;
2019-01-04 07:21:16

Wenn der aktuelle Höchstwert größer als der vorherige Maximalwert ist, bedeutet dies, dass inkrementelle Daten wie im Beispiel in die Hive-Tabelle aufgenommen wurden. Erstellen Sie zum Migrieren der inkrementellen Daten eine Staging-Tabelle und laden Sie nur die inkrementellen Daten in diese.

hive> CREATE TABLE stage_employees LIKE corp.employees;
hive> INSERT INTO TABLE stage_employees SELECT * FROM corp.employees WHERE timestamp_identifier>"2018-12-31 22:15:04" and timestamp_identifier<="2019-01-04 07:21:16"

Migrieren Sie die Staging-Tabelle. Listen Sie dazu die HDFS-Datendateien auf, kopieren Sie sie in Cloud Storage und laden Sie sie in die vorhandene BigQuery-Tabelle.

Partitionierte Tabelle ohne inkrementelle Spalte

Durch die Aufnahme von Daten in eine partitionierte Tabelle können neue Partitionen erstellt und/oder inkrementelle Daten an vorhandene Partitionen angehängt werden. In diesem Szenario können Sie die aktualisierten Partitionen identifizieren, aber Sie können nicht ohne weiteres feststellen, welche Daten zu diesen bestehenden Partitionen hinzugefügt wurden, da es keine inkrementelle Spalte zur Unterscheidung gibt. Eine weitere Option ist die Aufnahme und Verwaltung von HDFS-Snapshots. Da dies jedoch Leistungseinbußen verursacht, werden Hives generell deaktiviert.

Führen Sie bei der ersten Migration der Tabelle den Befehl SHOW PARTITIONS aus und speichern Sie die Informationen zu den verschiedenen Partitionen in der Tracking-Tabelle.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01

Die obige Ausgabe zeigt, dass die Tabelle employees zwei Partitionen hat. Eine vereinfachte Version der Tracking-Tabelle zeigt, wie diese Informationen gespeichert werden können.

partition_information	file_path	gcs_copy_status	gcs_file_path	bq_job_id	...
partition_column =2018-10-01
partition_column =2018-11-01

Führen Sie bei den nachfolgenden Migrationsausführungen den Befehl SHOW PARTITIONS noch einmal aus, um alle Partitionen aufzulisten und diese mit den Partitionsinformationen aus der Tracking-Tabelle zu vergleichen, um zu prüfen, ob neue Partitionen vorhanden sind, die noch nicht migriert wurden.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01
partition_column=2018-12-01
partition_column=2019-01-01

Wenn wie im Beispiel neue Partitionen identifiziert werden, erstellen Sie eine Staging-Tabelle und laden nur die neuen Partitionen aus der Quelltabelle in diese Tabelle. Migrieren Sie die Staging-Tabelle. Kopieren Sie dazu die Dateien in Cloud Storage und laden Sie sie in die vorhandene BigQuery-Tabelle.

Partitionierte Tabelle mit inkrementellen Spalten

In diesem Szenario ist die Hive-Tabelle partitioniert und in jeder Partition ist eine inkrementelle Spalte vorhanden. Kontinuierlich aufgenommene Daten werden in diesem Spaltenwert erhöht. Hier haben Sie die Möglichkeit, die neuen Partitionen wie im vorherigen Abschnitt beschrieben zu migrieren und inkrementell Daten zu migrieren, die in die vorhandenen Partitionen aufgenommen wurden.

Speichern Sie bei der ersten Migration der Tabelle die Mindest- und Höchstwerte der inkrementellen Spalte in jeder Partition sowie die Informationen zu den Tabellenpartitionen in der Tracking-Tabelle.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";
1 1000

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-11-01";
1 2000

Die obige Ausgabe zeigt, dass die Tabellenmitarbeiter zwei Partitionen und die Mindest- und Höchstwerte der inkrementellen Spalte in jeder Partition haben. Eine vereinfachte Version der Tracking-Tabelle zeigt, wie diese Informationen gespeichert werden können.

partition_information	inc_col_min	inc_col_max	file_path	gcs_copy_status	...
partition_column =2018-10-01	1	1000
partition_column =2018-11-01	1	2000

Führen Sie in den nachfolgenden Ausführungen die gleichen Abfragen aus, um den aktuellen Höchstwert in jeder Partition abzurufen und mit dem vorherigen Höchstwert aus der Tracking-Tabelle zu vergleichen.

hive> SHOW PARTITIONS corp.employees
partition_column=2018-10-01
partition_column=2018-11-01
partition_column=2018-12-01
partition_column=2019-01-01

hive> SELECT MIN(int_identifier),MAX(int_identifier) FROM corp.employees WHERE partition_column="2018-10-01";

In diesem Beispiel wurden zwei neue Partitionen identifiziert und einige inkrementelle Daten wurden in die vorhandene Partition partition_column=2018-10-01 aufgenommen. Wenn inkrementelle Daten vorhanden sind, erstellen Sie eine Staging-Tabelle, laden Sie nur die inkrementellen Daten in die Staging-Tabelle, kopieren Sie die Daten in Cloud Storage und laden Sie die Daten in die vorhandene BigQuery-Tabelle.

Sicherheitseinstellungen

BigQuery verwendet IAM, um den Zugriff auf Ressourcen zu verwalten. Vordefinierte Rollen von BigQuery bieten einen detaillierten Zugriff auf einen bestimmten Dienst und sollen allgemeine Anwendungsfälle und Zugriffskontrollmuster unterstützen. Sie können benutzerdefinierte Rollen verwenden, um einen detaillierteren Zugriff zu ermöglichen und eine Reihe von Berechtigungen anzupassen.

Zugriffssteuerungen für Tabellen und Datasets geben die Vorgänge an, die Nutzer, Gruppen und Dienstkonten für Tabellen, Ansichten und Datasets ausführen dürfen. Mit autorisierten Ansichten können Sie Abfrageergebnisse mit bestimmten Nutzern und Gruppen teilen, ohne diesen Zugriff auf die zugrunde liegenden Quelldaten zu erteilen. Mit der Sicherheit auf Zeilenebene und Sicherheit auf Spaltenebene können Sie einschränken, wer auf welche Zeilen oder Spalten in einer Tabelle zugreifen kann. Mit der Datenmaskierung können Sie Spaltendaten für Gruppen von Nutzern selektiv verdecken und gleichzeitig den Zugriff auf die Spalte zulassen.

Wenn Sie Zugriffssteuerungen anwenden, können Sie den folgenden Nutzern und Gruppen Zugriff gewähren:

Nutzer per E-Mail: Ermöglicht einem bestimmten Google-Konto den Zugriff auf das Dataset
Gruppe per E-Mail: Ermöglicht allen Mitgliedern einer Google-Gruppe den Zugriff auf das Dataset
Domain: Ermöglicht allen Nutzern und Gruppen in einer Google-Domain Zugriff auf das Dataset
Alle authentifizierten Nutzer: Ermöglicht allen Inhabern von Google-Konten den Zugriff auf das Dataset und macht es öffentlich
Projektinhaber: Ermöglicht allen Projektinhabern den Zugriff auf das Dataset
Projektbetrachter: Ermöglicht allen Projektbetrachtern den Zugriff auf das Dataset
Projektbearbeiter: Ermöglicht allen Projektbearbeitern den Zugriff auf das Dataset
Autorisierte Ansicht: Ermöglicht einen Lesezugriff auf das Dataset

Änderungen der Datenpipeline

In den folgenden Abschnitten wird erläutert, wie Sie Ihre Datenpipelines bei der Migration von Hive zu BigQuery ändern.

Sqoop

Wenn Ihre vorhandene Pipeline Sqoop zum Importieren von Daten in HDFS oder Hive zur Verarbeitung verwendet, ändern Sie den Job so, dass Daten in Cloud Storage importiert werden.

Wenn Sie Daten in HDFS importieren, wählen Sie eine der folgenden Optionen aus:

Kopieren Sie die Sqoop-Ausgabedateien mithilfe von Hadoop DistCp nach Cloud Storage.
Geben Sie die Dateien direkt mit dem Cloud Storage-Connector in Cloud Storage aus. Der Cloud Storage-Connector ist eine Open-Source-Java-Bibliothek, mit der Sie Apache Hadoop- oder Apache Spark-Jobs direkt für Daten in Cloud Storage erstellen. Weitere Informationen finden Sie unter Cloud Storage-Connector installieren.

Wenn Sie möchten, dass Sqoop Daten in Hive importiert, die in Google Cloud ausgeführt werden, verweisen Sie direkt auf die Hive-Tabelle und verwenden Sie Cloud Storage als Hive-Warehouse anstelle von HDFS. Legen Sie dazu das Attribut hive.metastore.warehouse.dir auf einen Cloud Storage-Bucket fest.

Sie können Ihren Sqoop-Job ausführen, ohne einen Hadoop-Cluster zu verwalten. Senden Sie dazu mit Dataproc Sqoop-Jobs, um Daten in BigQuery zu importieren.

Spark SQL und HiveQL

Der Batch-SQL-Übersetzer oder interaktive SQL-Übersetzer kann Spark SQL oder HiveQL automatisch in GoogleSQL übersetzen.

Wenn Sie Spark SQL oder HiveQL nicht zu BigQuery migrieren möchten, können Sie Dataproc oder den BigQuery-Connector mit Apache Spark verwenden.

Hive-ETL

Wenn bereits ETL-Jobs in Hive vorhanden sind, können Sie diese auf folgende Arten ändern, um sie von Hive zu migrieren:

Hive-ETL-Job mithilfe des Batch-SQL-Übersetzers in einen BigQuery-Job konvertieren.
Apache Spark mit dem BigQuery-Connector verwenden, um in BigQuery zu lesen und zu schreiben. Dataproc verwenden, um Spark-Jobs mithilfe von sitzungsspezifischen Clustern kostengünstig auszuführen.
Pipelines mit dem Apache Beam SDK neuschreiben und in Dataflow ausführen.
Apache Beam SQL verwenden, um Pipelines neu zu schreiben.

Zum Verwalten Ihrer ETL-Pipeline können Sie Cloud Composer (Apache Airflow) und Dataproc-Workflowvorlagen verwenden. Cloud Composer bietet ein Tool zum Konvertieren von Oozie-Workflows in Cloud Composer-Workflows.

Dataflow

Wenn Sie Ihre Hive ETL-Pipeline in vollständig verwaltete Cloud-Dienste verschieben möchten, können Sie Ihre Datenpipelines mit dem Apache Beam SDK schreiben und in Dataflow ausführen.

Dataflow ist ein verwalteter Dienst zum Ausführen von Datenverarbeitungspipelines. Es führt Programme aus, die mit dem Open-Source-Framework Apache Beam geschrieben wurden. Apache Beam ist ein vereinheitlichtes Programmiermodell, mit dem Sie sowohl Batch- als auch Streaming-Pipelines entwickeln können.

Wenn es sich bei Ihren Datenpipelines um Standarddatenverschiebung handelt, können Sie Dataflow-Vorlagen verwenden, um Dataflow-Pipelines schnell zu erstellen, ohne Code schreiben zu müssen. Sie können auf diese von Google bereitgestellte Vorlage verweisen, mit der Sie Textdateien aus Cloud Storage lesen, Transformationen anwenden und die Ergebnisse in eine BigQuery-Tabelle schreiben können.

Zur weiteren Vereinfachung der Datenverarbeitung können Sie auch Beam SQL ausprobieren, um Daten mit SQL-ähnlichen Anweisungen zu verarbeiten.