vorheriger Artikel
In unserer kostenlosen Online-Event-Reihe Data Firework Days haben wir Dir bereits die b.telligent Referenzarchitektur für Cloud Data Platforms vorgestellt. Nun wollen wir in unserer Blogreihe weiter auf das Thema Cloud und die einzelnen Anbieter eingehen. Im ersten dreiteiligen Part der Reihe Blueprint: Cloud-Data-Platform-Architektur ging es deshalb erst mal um die Architektur von Cloud-Plattformen im Allgemeinen.
Lies hier Teil 1: Blue Print Cloud-Data-Platform-Architektur
Cloud-Data-Platform-Architektur?
Die verschiedenen Bereiche einer solchen Plattform sind:
- Ingestion – die Übertragung der Daten von den Quellsystemen in die Cloud Data Platform
- Processing – die Verarbeitung der Daten durch den Data Lake bis in das Zielformat
- DataLake – persistente Speicherung der Daten in jeglicher Form
- Analytics und Data Warehouse & BI – analyseoptimierte Speicherung und Datenanalyse
- Central Services – ergänzende Services, um eine Datenplattform aufzubauen, zu betreiben und Data Governance sicherzustellen
- Data Services – bedarfsgerechter Datenzugang
Spotlight: AWS
In diesem Blogpost beschäftigen wir uns mit der Frage, wie Amazons Lakehouse-Ansatz in unserer Referenzarchitektur einzuordnen ist und wie man damit eine Cloud Data Platform umsetzen kann.
Was ist der Lakehouse-Ansatz und welche Services beinhaltet er?
Mit dem Lakehouse-Architektur-Ansatz beschreibt AWS die Integration verschiedener Services in der AWS Cloud. Mit dieser Architektur wird eine integrierte und skalierbare Lösung zur Verarbeitung, Speicherung, Analyse und Governance großer Datenmengen realisierbar. Anders als andere Anbieter den Begriff Lakehouse definieren, geht diese Architektur über eine reine Verschmelzung von Data-Lake- und Data-Warehouse-Technologien hinaus. Sie umfasst auch Streaming, Data Governance und Analytics.
Dabei ist für AWS, neben der kosteneffektiven Skalierbarkeit des Gesamtsystems, auch die Nutzung von bedarfsgerechten Datendiensten ein wichtiges Anliegen. AWS folgt der Philosophie, dass mit dem Angebot eines einzigen Services immer nur eine kompromissbehaftete Lösung erreicht werden kann. Daher setzt AWS auf die Kombination unterschiedlicher Services, um die jeweiligen Anforderungen möglichst gut und umfassend abdecken zu können.
In der Abbildung oben werden einzelne AWS-Services ihrem Aufgabenbereich in der Lakehouse-Architektur zugeordnet, deren Kern der Data Lake ist. Um einen Data Lake auf AWS aufzubauen, werden die folgenden Services genutzt:
- Amazon S3 – Datenspeicherung
- Amazon Glue – Datenkatalog & ETL
- Amazon Lake Formation – Data Governance
- Amazon Aurora – direkter Zugriff auf den Data Lake per SQL-Schnittstelle
Um diesen Kern ordnen sich dann die anderen Services. Der Vorteil dabei: Diese können je nach Anwendungsfall bedarfsgerecht eingesetzt und kombiniert und müssen entsprechend auch nur nach Nutzung bezahlt werden.
In diesem Gesamtsystem ist die Kommunikation der Services untereinander auch in unterschiedliche Richtungen möglich. Ein Service, wie z. B. eine relationale Datenbank, kann zum einen den Data Lake mit Daten versorgen, zum anderen auch wieder aufbereitete Daten aus dem Data Lake oder dem Data Warehouse empfangen. Mit dem Amazon Glue Data Catalog wird die Verfügbarkeit der Daten über eine einheitliche Metadatensicht für alle Services sichergestellt. Die Daten im Data Catalog unterliegen der Governance durch Amazon Lake Formation.
Dieses Konzept lässt sich sehr gut am Zusammenspiel des Data Lakes mit Amazon Redshift, dem Cloud Data Warehouse Service auf AWS, erklären. Aufgrund der Metadaten im Data Catalog kann auf einen definierten Teil des Data Lake transparent, als Teil des Data Warehouse, zugegriffen werden. Hierzu wird innerhalb von Amazon Redshift der Service Spectrum genutzt. Mit Spectrum wird eine in dem Glue Data Catalog definierte Datenbank als ein Schema in der Amazon-Redshift-Datenbank integriert dargestellt. Die Tabellen in diesem Schema lassen sich dann gemeinsam mit den Redshift-nativen Tabellen in SQL-Abfragen mit Joins etc. nutzen. Allerdings unterliegt diese Nutzung weiterhin auch der Governance durch Amazon Lake Formation. Das heißt, es können nur die Tabellen, Spalten und Daten genutzt werden, für die der User auch Zugriffsberechtigungen hat.
Data Lake, Data Warehouse, Data Catalog & Co.: Welche Teile der Cloud Data Platform werden durch den Lakehouse-Ansatz abgedeckt?
Die im Lakehouse-Ansatz beschriebenen Services und Funktionalitäten können bereits auf den überwiegenden Teil der b.telligent Referenzarchitektur für Cloud Data Platforms übertragen werden:
- Ingestion und Processing
- Streaming – Amazon Kinesis
- Batch – Amazon Glue ETL
- Data Lake – Datenspeicherung
- Amazon S3
- Amazon Athena
- Data Warehouse
- Amazon Redshift
- Analytical Platform
- Amazon SageMaker
- Meta-Data Management und GDPR Services
- AWS Glue Data Catalog
- Amazon Lake Formation
Die restlichen Teile der b.telligent Referenzarchitektur werden durch andere Services abgedeckt. Diese werden allerdings nicht explizit als Teil des Amazon-Lakehouse-Architektur-Ansatzes beschrieben, sondern sind Teil des großen AWS-Service-Katalogs.
- Data Visualization/Reporting – AWS QuickSight
- Automation & Scheduling – Amazon Managed Airflow
- Continuous Deployment und Integration – AWS CodePipeline und CodeDeploy
- Process & Cost Monitoring & Logging – AWS CloudWatch, CloudTrail und AWS Cost Explorer
Eine vollständige Umsetzung der Referenzarchitektur mit AWS Services könnte folgendermaßen aussehen:
Wenn Du vor der Umsetzung einer Cloud Data Platform stehst und mehr zur Umsetzung auf AWS wissen möchtest, sprich uns einfach an und wir zeigen Dir gerne Möglichkeiten auf, wie wir Dich auf Deiner Reise in die AWS-Cloud-Welt begleiten können.
