Apache Hive in Dataproc verwenden

Last reviewed 2022-04-06 UTC

In dieser Anleitung wird gezeigt, wie Sie Apache Hive effizient und flexibel in Dataproc verwenden, indem Sie Hive-Daten in Cloud Storage speichern und den Hive-Metaspeicher in einer MySQL-Datenbank in Cloud SQL hosten. Die Trennung zwischen Compute- und Speicherressourcen hat einige Vorteile:

Flexibilität: Sie können Clusterkonfigurationen auf bestimmte Hive-Arbeitslasten ausrichten und die Cluster unabhängig voneinander nach Bedarf skalieren.
Kosteneinsparungen: Sie können einen sitzungsspezifischen Cluster erstellen, sobald Sie einen Hive-Job ausführen müssen, und ihn wieder löschen, wenn er abgeschlossen ist. Die von den Jobs benötigten Ressourcen sind nur aktiv, wenn sie verwendet werden, sodass Sie nur für die tatsächliche Nutzung bezahlen. Außerdem können Sie für die Verarbeitung nicht kritischer Daten VMs auf Abruf verwenden oder sehr große Cluster mit niedrigeren Gesamtkosten erstellen.

Hive ist ein beliebtes Open-Source-Data-Warehouse-System auf der Grundlage von Apache Hadoop. Hive umfasst eine SQL-ähnliche Abfragesprache namens HiveQL, mit der große strukturierte Datasets analysiert werden. Der Hive-Metaspeicher enthält Metadaten zu Hive-Tabellen, z. B. dem Schema und Speicherort. Während MySQL normalerweise als Back-End für den Hive-Metaspeicher dient, ist es mit Cloud SQL möglich, relationale Datenbanken in Google Cloud ganz einfach einzurichten und zu verwalten.

Lernziele

MySQL-Instanz für den Hive-Metaspeicher in Cloud SQL erstellen
Hive-Server in Dataproc bereitstellen
Cloud SQL-Proxy auf den Dataproc-Clusterinstanzen installieren
Hive-Daten in Cloud Storage hochladen
Hive-Abfragen auf mehreren Dataproc-Clustern ausführen

Kosten

In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Dataproc
Cloud Storage
Cloud SQL

Mit dem Preisrechner können Sie eine Kostenschätzung für die geplante Nutzung vornehmen.

Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Hinweis

Neues Projekt erstellen

In the Google Cloud console, go to the project selector page.

Go to project selector
Select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Abrechnung aktivieren

Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

Umgebung initialisieren

Starten Sie eine Cloud Shell-Instanz:

Zu Cloud Shell
Legen Sie in Cloud Shell als Standardzone von Compute Engine die Zone fest, in der Sie Ihre Dataproc-Cluster erstellen möchten.
```
export PROJECT=$(gcloud info --format='value(config.project)')
export REGION=REGION
export ZONE=ZONE
gcloud config set compute/zone ${ZONE}
```
Dabei gilt:
- REGION: Die Region, in der Sie den Cluster erstellen möchten, z. B. us-central1.
- ZONE: Die Zone, in der Sie den Cluster erstellen möchten, z. B. us-central1-a.
Aktivieren Sie die Dataproc und Cloud SQL Admin APIs, indem Sie diesen Befehl in Cloud Shell ausführen:
```
gcloud services enable dataproc.googleapis.com sqladmin.googleapis.com
```

Referenzarchitektur

Der Einfachheit halber erstellen Sie im Rahmen dieser Anleitung alle Compute- und Speicherdienste in derselben Google Cloud-Region, um die Netzwerklatenz und Netzwerktransportkosten möglichst gering zu halten. Abbildung 1 enthält die Architektur für diese Anleitung.

Diagramm einer Architektur mit einer einzigen Region — **Abbildung 1.** Beispiel einer Hive-Architektur in einer einzigen Region

In dieser Architektur sieht der Lebenszyklus einer Hive-Abfrage folgendermaßen aus:

Der Hive-Client sendet eine Abfrage an einen Hive-Server, der in einem sitzungsspezifischen Dataproc-Cluster ausgeführt wird.
Der Server verarbeitet die Abfrage und fordert Metadaten aus dem Metaspeicherdienst an.
Der Metaspeicherdienst ruft die Hive-Metadaten über den Cloud SQL-Proxy aus Cloud SQL ab.
Der Server lädt Daten aus dem Hive-Warehouse in einem regionalen Bucket in Cloud Storage.
Der Server gibt das Ergebnis an den Client zurück.

Überlegungen zu multiregionalen Architekturen

In dieser Anleitung geht es vorrangig um eine Architektur in einer einzigen Region. Sie können jedoch auch eine multiregionale Architektur in Betracht ziehen, wenn Sie Hive-Server an verschiedenen geografischen Standorten ausführen müssen. Erstellen Sie in diesem Fall separate Dataproc-Cluster, in denen der Metaspeicherdienst gehostet wird und die sich in derselben Region wie die Cloud SQL-Instanz befinden. Der Metaspeicherdienst kann große Anfragenmengen an die MySQL-Datenbank senden. Deshalb ist es sehr wichtig, dass er sich in geografischer Nähe zu der MySQL-Datenbank befindet, um die Leistungseinbußen möglichst gering zu halten. Im Vergleich dazu sendet der Hive-Server normalerweise wesentlich weniger Anfragen an den Metaspeicherdienst. Daher kann es trotz der höheren Latenz eher akzeptabel sein, wenn sich der Hive-Server und der Metaspeicherdienst in verschiedenen Regionen befinden.

Der Metaspeicherdienst kann nur auf Dataproc-Masterknoten und nicht auf Worker-Knoten ausgeführt werden. Dataproc erzwingt mindestens 2 Worker-Knoten in Standardclustern und in Hochverfügbarkeits-Clustern. Sie können stattdessen einen Cluster mit einem einzigen Knoten für den Metaspeicherdienst erstellen, um keine Ressourcen für nicht verwendete Worker-Knoten zu vergeuden. Erstellen Sie mehrere Cluster mit einem einzigen Knoten, wenn Sie eine hohe Verfügbarkeit erzielen möchten.

Der Cloud SQL-Proxy muss nur auf den Metaspeicherdienst-Clustern installiert werden, da nur die Metaspeicherdienst-Cluster eine direkte Verbindung mit der Cloud SQL-Instanz benötigen. Die Hive-Server verweisen dann auf die Metadatenspeicher-Cluster, indem das hive.metastore.uris-Attribut auf die durch Kommas getrennte Liste der URIs gesetzt wird. Beispiel:

thrift://metastore1:9083,thrift://metastore2:9083

Sie können auch die Verwendung eines Buckets mit zwei oder mehreren Regionen in Betracht ziehen, wenn auf die Hive-Daten von Hive-Servern an mehreren Standorten zugegriffen werden muss. Ob ein Bucket-Standort ausgewählt wird, hängt vom jeweiligen Anwendungsfall ab. Sie müssen die Latenz, Verfügbarkeit und Kosten gegeneinander abwägen.

Abbildung 2 enthält ein Beispiel einer multiregionalen Architektur.

Diagramm einer multiregionalen Hive-Architektur — **Abbildung 2.** Beispiel einer multiregionalen Hive-Architektur

Wie Sie sehen können, ist das multiregionale Szenario etwas komplexer. Der Einfachheit halber wird in dieser Anleitung eine Architektur in einer einzigen Region verwendet.

(Optional) Warehouse-Bucket erstellen

Wenn Sie keinen Cloud Storage-Bucket zum Speichern von Hive-Daten haben, erstellen Sie einen Warehouse-Bucket. (Führen Sie die folgenden Befehle in Cloud Shell aus.) Ersetzen Sie dabei BUCKET_NAME durch einen eindeutigen Bucket-Namen:

export WAREHOUSE_BUCKET=BUCKET_NAME
gsutil mb -l ${REGION} gs://${WAREHOUSE_BUCKET}

Cloud SQL-Instanz erstellen

In diesem Abschnitt erstellen Sie eine neue Cloud SQL-Instanz, in der später der Hive-Metaspeicher gehostet wird.

Erstellen Sie in der Cloud Shell eine neue Cloud SQL-Instanz:

gcloud sql instances create hive-metastore \
    --database-version="MYSQL_5_7" \
    --activation-policy=ALWAYS \
    --zone ${ZONE}

Die Verarbeitung dieses Befehls kann einige Minuten dauern.

Dataproc-Cluster erstellen

Erstellen Sie den ersten Dataproc-Cluster und ersetzen Sie CLUSTER_NAME durch einen Namen wie hive-cluster:

gcloud dataproc clusters create CLUSTER_NAME \
    --scopes sql-admin \
    --region ${REGION} \
    --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
    --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
    --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore" \
    --metadata "enable-cloud-sql-proxy-on-workers=false"

Hinweise:

Sie geben den sql-admin-Zugriffsbereich an, damit Clusterinstanzen auf die Cloud SQL Admin API zugreifen können.
Sie fügen die Initialisierungsaktion in ein Skript ein, das Sie in einem Cloud Storage-Bucket speichern, und verweisen mit dem Flag --initialization-actions auf diesen Bucket. Weitere Informationen finden Sie unter Initialisierungsaktionen – wichtige Überlegungen und Richtlinien.
Sie geben den URI für den Hive-Warehouse-Bucket im Attribut hive:hive.metastore.warehouse.dir an. Dadurch wird in der Konfiguration der Hive-Server festgelegt, dass Lese- und Schreibvorgänge aus dem bzw. an den richtigen Speicherort erfolgen. Dieses Attribut muss mindestens ein Verzeichnis enthalten (z. B. gs://my-bucket/my-directory); Hive funktioniert nicht ordnungsgemäß, wenn dieses Attribut auf einen Bucket-Namen ohne Verzeichnis (z. B. gs://my-bucket) gesetzt ist.
Sie geben enable-cloud-sql-proxy-on-workers=false an, um sicherzustellen, dass der Cloud SQL-Proxy nur auf Masterknoten ausgeführt wird. Dies ist ausreichend, damit der Hive-Metastore-Dienst funktioniert und unnötige Lasten in Cloud SQL vermeidet.
Sie geben die Initialisierungsaktion des Cloud SQL-Proxys an, die Dataproc automatisch auf allen Clusterinstanzen ausführt. Diese Aktion umfasst folgende Schritte:
- Der Cloud SQL-Proxy wird installiert.
- Es wird eine sichere Verbindung mit der Cloud SQL-Instanz hergestellt, die im Metadatenparameter hive-metastore-instance angegeben ist.
- Es werden ein hive-Nutzer und die Datenbank des Hive-Metaspeichers erstellt.
Den vollständigen Code für die Cloud SQL-Proxy-Initialisierungsaktion finden Sie auf GitHub.
Der Einfachheit halber wird in dieser Anleitung nur eine Master-Instanz verwendet. Zum Erhöhen der Ausfallsicherheit in einer Produktionsumgebung empfiehlt es sich, mithilfe des Hochverfügbarkeitsmodus von Dataproc einen Cluster mit drei Master-Instanzen zu erstellen.
In dieser Anleitung wird eine Cloud SQL-Instanz mit einer öffentlichen IP-Adresse verwendet. Wenn Sie stattdessen eine Instanz mit nur einer privaten IP-Adresse verwenden, können Sie erzwingen, dass der Proxy die private IP-Adresse verwendet. Übergeben Sie dazu den Parameter --metadata "use-cloud-sql-private-ip=true".

Hive-Tabelle erstellen

In diesem Abschnitt laden Sie ein Beispiel-Dataset in den Warehouse-Bucket hoch, erstellen eine neue Hive-Tabelle und führen einige HiveQL-Abfragen für das Dataset aus.

Kopieren Sie das Beispiel-Dataset in den Warehouse-Bucket:
```
gsutil cp gs://hive-solution/part-00000.parquet \
gs://${WAREHOUSE_BUCKET}/datasets/transactions/part-00000.parquet
```
Das Beispiel-Dataset wird in das Parquet-Format komprimiert und enthält Tausende fiktiver Banktransaktionsdatensätze mit drei Spalten: Datum, Betrag und Transaktionstyp.

Erstellen Sie eine externe Hive-Tabelle für das Dataset:

gcloud dataproc jobs submit hive \
    --cluster CLUSTER_NAME \
    --region ${REGION} \
    --execute "
      CREATE EXTERNAL TABLE transactions
      (SubmissionDate DATE, TransactionAmount DOUBLE, TransactionType STRING)
      STORED AS PARQUET
      LOCATION 'gs://${WAREHOUSE_BUCKET}/datasets/transactions';"

Hive-Abfragen ausführen

Für die Ausführung von Hive-Abfragen stehen verschiedene Tools in Dataproc zur Verfügung. In diesem Abschnitt erfahren Sie, wie Sie Abfragen mit den folgenden Tools ausführen:

Hive Jobs API in Dataproc
Beeline, ein beliebter Befehlszeilenclient auf Grundlage von SQLLine
SparkSQL, die API von Apache Spark für das Abrufen strukturierter Daten

Sie führen in jedem Abschnitt eine Beispielabfrage aus.

Hive mit der Dataproc Jobs API abfragen

Führen Sie die folgende einfache HiveQL-Abfrage durch, um sicherzustellen, dass die Parquet-Datei richtig mit der Hive-Tabelle verknüpft ist:

gcloud dataproc jobs submit hive \
    --cluster CLUSTER_NAME \
    --region ${REGION} \
    --execute "
      SELECT *
      FROM transactions
      LIMIT 10;"

Die Ausgabe enthält die folgenden Informationen:

+-----------------+--------------------+------------------+
| submissiondate  | transactionamount  | transactiontype  |
+-----------------+--------------------+------------------+
| 2017-12-03      | 1167.39            | debit            |
| 2017-09-23      | 2567.87            | debit            |
| 2017-12-22      | 1074.73            | credit           |
| 2018-01-21      | 5718.58            | debit            |
| 2017-10-21      | 333.26             | debit            |
| 2017-09-12      | 2439.62            | debit            |
| 2017-08-06      | 5885.08            | debit            |
| 2017-12-05      | 7353.92            | authorization    |
| 2017-09-12      | 4710.29            | authorization    |
| 2018-01-05      | 9115.27            | debit            |
+-----------------+--------------------+------------------+

Hive mit Beeline abfragen

Öffnen Sie eine SSH-Sitzung mit der Master-Instanz von Dataproc (CLUSTER_NAME-m):
```
gcloud compute ssh CLUSTER_NAME-m
```
Öffnen Sie in der Eingabeaufforderung der Master-Instanz eine Beeline-Sitzung:
```
beeline -u "jdbc:hive2://localhost:10000"
```
Hinweise:
- Sie können auch auf den Namen der Masterinstanz als Host statt auf localhost verweisen:
```
beeline -u "jdbc:hive2://CLUSTER_NAME-m:10000"
```
- Wenn Sie den Hochverfügbarkeitsmodus mit 3 Mastern verwendet haben, müssen Sie stattdessen den folgenden Befehl verwenden:
```
beeline -u "jdbc:hive2://CLUSTER_NAME-m-0:2181,CLUSTER_NAME-m-1:2181,CLUSTER_NAME-m-2:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2"
```

Führen Sie die folgende HiveQL-Abfrage aus, wenn die Beeline-Eingabeaufforderung geöffnet wird:

SELECT TransactionType, AVG(TransactionAmount) AS AverageAmount
FROM transactions
WHERE SubmissionDate = '2017-12-22'
GROUP BY TransactionType;

Die Ausgabe enthält die folgenden Informationen:

+------------------+--------------------+
| transactiontype  |   averageamount    |
+------------------+--------------------+
| authorization    | 4890.092525252529  |
| credit           | 4863.769269565219  |
| debit            | 4982.781458176331  |
+------------------+--------------------+

Schließen Sie die Beeline-Sitzung:
```
!quit
```
Schließen Sie die SSH-Verbindung:
```
exit
```

Hive mit SparkSQL abfragen

Öffnen Sie eine SSH-Sitzung mit der Master-Instanz von Dataproc:
```
gcloud compute ssh CLUSTER_NAME-m
```
Öffnen Sie in der Eingabeaufforderung der Master-Instanz eine neue PySpark-Shell-Sitzung:
```
pyspark
```

Wenn die PySpark-Shell-Eingabeaufforderung angezeigt wird, geben Sie den folgenden Python-Code ein:

from pyspark.sql import HiveContext
hc = HiveContext(sc)
hc.sql("""
SELECT SubmissionDate, AVG(TransactionAmount) as AvgDebit
FROM transactions
WHERE TransactionType = 'debit'
GROUP BY SubmissionDate
HAVING SubmissionDate >= '2017-10-01' AND SubmissionDate < '2017-10-06'
ORDER BY SubmissionDate
""").show()

Die Ausgabe enthält die folgenden Informationen:

+-----------------+--------------------+
| submissiondate  |      avgdebit      |
+-----------------+--------------------+
| 2017-10-01      | 4963.114920399849  |
| 2017-10-02      | 5021.493300510582  |
| 2017-10-03      | 4982.382279569891  |
| 2017-10-04      | 4873.302702503676  |
| 2017-10-05      | 4967.696333583777  |
+-----------------+--------------------+

Schließen Sie die PySpark-Sitzung:
```
exit()
```
Schließen Sie die SSH-Verbindung:
```
exit
```

Hive-Metaspeicher untersuchen

Sie prüfen nun, ob der Hive-Metaspeicher in Cloud SQL Informationen zur Tabelle transactions enthält.

Starten Sie in der Cloud Shell eine neue MySQL-Sitzung auf der Cloud SQL-Instanz:
```
gcloud sql connect hive-metastore --user=root
```
Wenn Sie zur Eingabe des root-Nutzerpassworts aufgefordert werden, geben Sie nichts ein und drücken Sie nur die Taste RETURN. Der Einfachheit halber haben Sie in dieser Anleitung kein Passwort für den root-Nutzer festgelegt. Informationen zum Festlegen eines Passworts, um die Metaspeicher-Datenbank besser zu schützen, finden Sie in der Dokumentation zu Cloud SQL. Die Cloud SQL-Proxy-Initialisierungsaktion umfasst auch einen Mechanismus für den Schutz von Passwörtern durch Verschlüsselung. Weitere Informationen finden Sie im Code-Repository der Aktion.
Legen Sie hive_metastore über die MySQL-Eingabeaufforderung als Standarddatenbank für den Rest der Sitzung fest:
```
USE hive_metastore;
```

Prüfen Sie, ob der Speicherort des Warehouse-Buckets im Metaspeicher aufgezeichnet wurde:

SELECT DB_LOCATION_URI FROM DBS;

Sie erhalten folgende Ausgabe:

+-------------------------------------+
| DB_LOCATION_URI                     |
+-------------------------------------+
| gs://[WAREHOUSE_BUCKET]/datasets   |
+-------------------------------------+

Überprüfen Sie, ob im Metaspeicher ordnungsgemäß auf die Tabelle verwiesen wird:

SELECT TBL_NAME, TBL_TYPE FROM TBLS;

Sie erhalten folgende Ausgabe:

+--------------+----------------+
| TBL_NAME     | TBL_TYPE       |
+--------------+----------------+
| transactions | EXTERNAL_TABLE |
+--------------+----------------+

Überprüfen Sie, ob auch ordnungsgemäß auf die Tabellenspalten verwiesen wird:

SELECT COLUMN_NAME, TYPE_NAME
FROM COLUMNS_V2 c, TBLS t
WHERE c.CD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';

Sie erhalten folgende Ausgabe:

+-------------------+-----------+
| COLUMN_NAME       | TYPE_NAME |
+-------------------+-----------+
| submissiondate    | date      |
| transactionamount | double    |
| transactiontype   | string    |
+-------------------+-----------+

Überprüfen Sie, ob außerdem richtig auf das Eingabeformat und den Speicherort verwiesen wird:

SELECT INPUT_FORMAT, LOCATION
FROM SDS s, TBLS t
WHERE s.SD_ID = t.SD_ID AND t.TBL_NAME = 'transactions';

Sie erhalten folgende Ausgabe:

+---------------------------------------------------------------+------------------------------------------------+
| INPUT_FORMAT                                                  | LOCATION                                       |
+---------------------------------------------------------------+------------------------------------------------+
| org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat | gs://[WAREHOUSE_BUCKET]/datasets/transactions |
+---------------------------------------------------------------+------------------------------------------------+

Schließen Sie die MySQL-Sitzung:
```
exit
```

Weiteren Dataproc-Cluster erstellen

In diesem Abschnitt erstellen Sie einen weiteren Dataproc-Cluster, damit die Hive-Daten und der Hive-Metaspeicher von mehreren Clustern gemeinsam verwendet werden können.

Erstellen Sie einen neuen Dataproc-Cluster:

gcloud dataproc clusters create other-CLUSTER_NAME \
    --scopes cloud-platform \
    --image-version 2.0 \
    --region ${REGION} \
    --initialization-actions gs://goog-dataproc-initialization-actions-${REGION}/cloud-sql-proxy/cloud-sql-proxy.sh \
    --properties "hive:hive.metastore.warehouse.dir=gs://${WAREHOUSE_BUCKET}/datasets" \
    --metadata "hive-metastore-instance=${PROJECT}:${REGION}:hive-metastore"\
    --metadata "enable-cloud-sql-proxy-on-workers=false"

Stellen Sie sicher, dass der neue Cluster auf die Daten zugreifen kann:

gcloud dataproc jobs submit hive \
    --cluster other-CLUSTER_NAME \
    --region ${REGION} \
    --execute "
      SELECT TransactionType, COUNT(TransactionType) as Count
      FROM transactions
      WHERE SubmissionDate = '2017-08-22'
      GROUP BY TransactionType;"

Die Ausgabe enthält die folgenden Informationen:

+------------------+--------+
| transactiontype  | count  |
+------------------+--------+
| authorization    | 696    |
| credit           | 1722   |
| debit            | 2599   |
+------------------+--------+

Das war's auch schon! Sie haben die Anleitung abgeschlossen.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder Sie behalten das Projekt und löschen die einzelnen Ressourcen.

So vermeiden Sie, dass Ihrem Google Cloud-Konto die in dieser Anleitung verwendeten Ressourcen in Rechnung gestellt werden:

Bereinigen Sie alle erstellten Ressourcen, damit sie Ihnen nicht in Rechnung gestellt werden. Sie vermeiden weitere Kosten am einfachsten, indem Sie das für die Anleitung erstellte Projekt löschen.
Alternativ können Sie einzelne Ressourcen löschen.

Projekt löschen

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Einzelne Ressourcen löschen

Führen Sie die folgenden Befehle in der Cloud Shell aus, um einzelne Ressourcen anstatt des gesamten Projekts zu löschen:

gcloud dataproc clusters delete CLUSTER_NAME --region ${REGION} --quiet
gcloud dataproc clusters delete other-CLUSTER_NAME --region ${REGION} --quiet
gcloud sql instances delete hive-metastore --quiet
gsutil rm -r gs://${WAREHOUSE_BUCKET}/datasets

Weitere Informationen

Das serverlose, in hohem Maße skalierbare und kostengünstige Data Warehouse von Google, BigQuery, testen
Anleitung zur Migration von Hadoop-Arbeitslasten in Google Cloud
Weitere Informationen über diese Initialisierungsaktion und darüber, wie Hive HCatalog in Dataproc verwendet werden kann
Mehr über das Konfigurieren von Cloud SQL für hohe Verfügbarkeit zur Verbesserung der Dienstzuverlässigkeit erfahren
Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center