Wegbereiter für ein Lakehouse in den Wolken

Robert_frei

Hallo, ich bin AWS Solution Architekt bei der Five1 und Kopf des Big Data Science Teams. Wir arbeiten an der Grenze zwischen klassischer Datenanalyse, Machine Learning und AWS Cloud Infrastruktur. Ich bin begeistert davon, wie Lakeformation und Redshift eine Brücke schlagen, zwischen dem klassischen AWS Data Lake (bestehend aus S3, Glue und Athena) und der State-of-the-art "Lakehouse Architektur" die Machine Learrning, Delta Lake und Data Warehouse elegant in sich vereint! Mehr zu diesem Thema erfahren Sie in diesem Blogbeitrag. 

Vom Data- zum Delta-Lake

AWS bietet als Hyperscaler mit AWS S3 das perfekte Werkzeug, um einen DataLake zu errichten; Unbegrenzter, kostengünstiger Speicherplatz für strukturierte und unstrukturierte Daten gleichermaßen. AWS Glue liefert den dazugehörten Metadaten Store dazu.

Beim Betrachten von AWS Lakeformation, gewinnt man den Eindruck, es würde im Wesentlichen eine Plattform bereitstellen, um diese Services in sich zu vereinen. Wer bereits Daten in S3 und Metadaten in AWS Glue verwaltet, kann Lakeformation, wie eine Käseglocke, über die bereits vorhandenen Ressourcen ‘stülpen’.

 

  • S3 Buckets können über ‚Data Lake Locations‘ zu LakeFormation hinzugefügt werden.

  • Glue Datenbanken,Tabellen, Crawler und Jobs werden unter ‘Data Catalog‘ angezeigt.

  • Vorhandene Zugriffssteuerung auf die Daten mit IAM kann zunächst übernommen werden, sollte jedoch durch die granular feineren Berechtigungsmöglichkeiten über Lakeformation ersetzt werden (mehr dazu später).

Redshift_1

Bei genauerer Betrachtung wird klar; Lakeformation hebt den DataLake auf ein neues Level und erweitert seine Funktionalität fundamental über die Möglichkeiten von S3, Glue und IAM hinaus!

 

 

Endlich zeitgemäße Zugriffssteuerung

Was für jeden SAPler offensichtlich ist; dass nämlich die Zugriffsberechtigung auf Daten nicht nur auf Tabellenebene stattfinden kann, sondern auf Zeilen, Spalten und Zellebene erforderlich ist, stellte in der AWS zunächst ein Problem dar. AWS IAM ermöglicht es zunächst nur auf Objekte in S3, oder über den Glue Data Catalog Zugriff auf ganze Tabellen zu gewähren. In AWS Lakeformation wird diese Limitation aufgehoben! Fortan ist es kein Problem, für einzelne Entwickler, Analysten oder Applikationen den Zugriff auf bestimmte Spalten oder einzelne Zellen zu beschränken!

 

Sobald Sie AWS Lakeformation verwenden, um den Zugriff auf Ihre Daten zu verwalten, müssen Sie "Data Permissions" festlegen, um IAM-Benutzern oder IAM-Rollen den Zugriff über Lake Formation zu ermöglichen. Das funktioniert sogar, wenn der Auftraggeber keinen Zugriff auf S3 hat! Es wird sogar empfohlen, den Zugriff auf S3 nicht mehr direkt, sondern nur noch über Lakeformation zu gewähren! Die 'Data Permissions' erlauben den Zugriff auf Glue-Datenbanken oder nur auf bestimmte Tabellen oder (wie empfohlen) auf Datenkatalog-Ressourcen, die mit 'LF-Tags' versehen sind. Zusätzlich definieren Sie 'Datenfilter' für bestimmte Tabellen im Datenkatalog, um Spalten und Zeilen zu definieren, auf die der Principal Zugriff hat.

 

Dank "gemanagter Tabellen" mehr Sicherheit beim Datenmanagement

In AWS Lakeformation existieren zwei Arten von Tabellen. Die einen sind die üblichen im Glue Data Katalog definierten Tabellen. Die zweite Art wird als ‘gemanagte’ Tabellen bezeichnet. Gemanagte Tabellen unterstützen sogenannte ‘Transaktionen’. Transaktionen wurde bereits von einem Kollegen von mir in einem anderen Blog im Kontext der Lakehouse Architektur von Databricks sehr gut beschrieben, weshalb ich ihn hier zu Wort kommen lassen möchte:

 

Die Erhaltung der Konsistenz der Daten ist im operativen Einsatz von grundlegender Bedeutung, wofür Transaktionen die technische Grundlage sind. Das Datenmanagement im Lakehouse ermöglicht Transaktionen mit garantiertem Verhalten, indem analog zu einem Warehouse ein Transaktionslog geführt wird und bei Fehlern Rollbacks durchgeführt werden. Durch diese Verarbeitungsweise ergeben sich außerdem Möglichkeiten zur Performanceoptimierung gegenüber Data Lakes. ‘ - Zitat Five1-DataLakehouse

 

Redshift_2

 

Konkret bedeutet dies: Indem ich meine vorhandenen, in S3 liegenden Daten, in AWS Lakeformation als ‘gemangte Tabellen’ integriere, bekomme ich die Möglichkeit jede Veränderung an ihnen, die über eine Transaktion durchgeführt wurde, zu dokumentieren und ggf. sogar rückgängig machen zu können. ‘time travel’ querries erlauben es, den Datenstand zu jedem beliebigen Zeitpunkt (definiert über einen Zeitpunkt oder Transaktions-ID) einzusehen:

SELECT *

FROM gluedb.gluetable

FOR SYSTEM_TIME AS OF TIMESTAMP '2021-09-30 10:00:00'

 

 

Vom Delta-Lake zum "Lakehouse"

 

Für viele praktische Anwendungen und Anwender wird, trotz der Vorzüge von AWS Lakeformation, eine bewährtes DataWarehouse nicht wegzudenken sein. (www.five1.de/technologien/sap/dwc).

Gleichzeitig heißt mit der Zeit gehen auch, sich nicht den Möglichkeiten der Cloud hinsichtlich Skalierbarkeit und vor allem auch modernen Machine Learning Ansätzen zu verschließen. Wie also die Daten sowohl in einem klassischen DataWarehouse den BI Spezialisten als auch DataScientisten in der Cloud zugänglich machen?

 

An dieser Stelle kommt AWS Redshift ins Spiel! Die DataWarehouse Lösung der AWS! Stand sie bislang nur als selbst gehosteter Cluster zur Verfügung, bietet AWS seit Neustem auch eine ‘Serverless’ Lösung an, bei der jeder Verwaltungsaufwand des Servers selber, komplett wegfällt! Dank ‘Redshift Spektrum’, kann Redshift direkt auf die bereits in S3 liegenden Daten zugreifen, ohne dass diese auf den Cluster kopiert werden müssten! Der Benutzer kann direkt AWS eigene UI (‘querry editor v2’) verwenden, um sich mit Redshift zu verbinden oder auch eine bereits vertraute UI (z.B. einen SQL Client) verwenden.

 

Redshift_3

 

Umsetzung & Kosten

 

AWS Lakeformation kann aufgesetzt werden, bevor oder nachdem sie einen DataLake in AWS S3 aufgesetzt und ggf. bereits einen Metadaten-Katalog in AWS Glue aufgebaut haben. Wichtig zu erwähnen ist:

  • LakeFormation übernimmt nicht das Erstellen von S3 Buckets

  • Ein bereits auf S3 abgestimmtes Berechtigungskonzept in IAM muss angepasst werden, wenn auf Lakeformation umgestiegen wird, da vermieden werden muss, dass es nicht zu Unstimmigkeiten kommt, welche Daten über Lakeformation und welche über S3 zugänglich sind.

Kosten fallen für die Verwendung von Tabellen an die ‚verwaltet‘ sind und mit Zeilen-, Spalten- und Zellen Level Zugriffskontrolle (2,25$/TB gescannter Daten) versehen sind.

Zusätzlich fallen für ‚verwaltet‘ Tabellen Kosten für das Metadatenmanagement an (1$/100.000 S3 Objekte pro Monat und 1$/1.000.000 API Requests pro Monat) und für die Speicherplatzoptimierung (2,25$/TB).

 

Für den Einsatz von AWS Redshift gibt es grundsätzlich zwei Möglichkeiten:

  • Redshift Cluster

    Über die Konsole oder API kann ein Redshift Cluster erzeugt werden, der z.B. über den ‚Abfrage-Editor v2‘, nach dem Hochfahren direkt einsatzbereit ist. Nachdem ein Cluster deployt wurde, kann seine Größe dynamisch angepasst werden (sowohl die Art als auch die Anzahl der Knoten)!Ein Cluster kann pausiert werden, damit er keine Kosten verursacht, zu Zeiten, in denen er nicht verwendet wird. Die Kosten für einen Cluster fangen bei 0,25$/h an und hängen empfindlich von seiner Größe und Art der Knoten ab. Die Verwendung von ‚reserved-Instanzes‘ kann die Kosten gegenüber ‚On-demand Instanzen‘ senken. Es steht zudem eine kostenlose Testversion 2 Monate lang zur Verfügung.

  • Redshift Serverless

    Über die Konsole oder API kann Redshift Serverless deployt werden, ohne irgendwelche Angaben über Hardwarekonfigurationen treffen zu müssen. Redshift Serverless stellt automatisch immer die benötigten Rechenressourcen bereit. Sie können jedoch limitiert werden, um eine geeignete Balance zwischen Kosten und Performance zu gewährleisten. Bei Redshift Serverless fallen Kosten nur für die tatsächlich genutzte Rechenleistung des Warehouses bei Verwendung an (0,36$ pro RPU-Stunde (32-512)).

 

 

Fazit: Vorteile vom AWS "Lakehouse"

Für den Anwender ergeben sich daraus die Vorteile, ein klassisches Data Warehouse parallel zu einem DeltaLake (=Datalake + Transactions) zur Verfügung zu haben. Alle Services sind dabei AWS Cloud Nativ und sind entsprechend vollumfänglich in weitere AWS Services integrierbar!

 

  • Streaming - besonders für IoT Daten interessant

    AWS MSK, AWS Kinesis, Kafka

  • Maschinelles Lernen

    AWS Sagemaker Studio

  • BigData Processing

    AWS EMR mit Apache Spark

  • Dockerisierung von Anwendungen

    AWS EKS, Kubernetes

  • Serverless – besonders sicher und kosteneffizient

    AWS Lambda

 

Veröffentlich am 5.10.2022

Thema: big data, AWS, Data Warehouse, Data Science, Datenplattform, Data Lake, Infrastruktur