Data Lakehouse vs. Data Warehouse in der Cloud: Teil 2 - Datenintegrität und Sicherheitskonzepte

Data Lakehouse vs. Data Warehouse - Datenintegrität 

Primär- und Fremdschlüssel dienen zur Sicherung der Konsistenz eines Datenbestands. Beim Data Lakehouse-Ansatz lässt sich aufgrund der Aufnahme von unstrukturierten Daten ein gewisser Graubereich an Datenmängeln nicht verhindern und wird billigend in Kauf genommen. 

Beim DWH-Ansatz ist das Identifizieren eindeutiger Geschäftsobjekte und ihrer Beziehungen zueinander essenziell und bedarf einer Sicherstellung durch Primärschlüssel (Eindeutigkeit) und Fremdschlüssel (Konsistenz des Gesamtdatenbestands). 

Eine Implementierung von entsprechenden Constraint-Objekten ist in Apache Spark und den verwendeten Dateiformaten nicht vorgesehen und ist für einen Data Lakehouse-Ansatz auch nicht existenziell. 

Nachteilig ist, dass auch die Hersteller von analytischen Datenbanksystemen in Cloud-Umgebungen (bis auf wenige Ausnahmen) die Implementierung von Primär- und Fremdschlüsseln nicht vorgenommen haben. Gerade bei DWH-Systemen und für die hieraus gewonnenen Erkenntnisse ist die Datenqualität und Datenkonsistenz eminent wichtig. Letztere muss somit über den Beladungsprozess sichergestellt sein und bedarf auch einer steten Validierung der gespeicherten Daten. 

Data Lakehouse vs. Data Warehouse - Berechtigungsvergabe 

In Cloud-Umgebungen haben Sicherheitsaspekte einen hohen Stellenwert. Das Konzept Least Privilege ist in der Informationssicherheit von großer Bedeutung. Hierbei handelt es sich um die Vergabe der geringsten Berechtigung, die ein Anwender unbedingt benötigt, um seine Aufgabe zu erfüllen. Das Konzept trägt als grundlegendes Sicherheitsprinzip dazu bei, Cloud-Umgebungen zu schützen und Risiken zu minimieren. In der Praxis hat dies folgende Auswirkungen: 

• Begrenzte Berechtigungen: 
  Ein Benutzer oder Dienst erhält nur die rollenbasierten Berechtigungen (Role Based Access Control), die für seine spezifischen Aufgaben erforderlich sind. Übermäßige Berechtigungen werden so vermieden.  
• Minimierung des Risikos:  
  Weniger Berechtigungen bedeuten weniger Angriffsfläche für potenzielle Bedrohungen. Falls ein Benutzerkonto kompromittiert wird, sind die Auswirkungen begrenzt. 
• Compliance und Datenschutz: 
  Least Privilege ist eine bewährte Methode zur Einhaltung von Datenschutzbestimmungen und -richtlinien. 

Data Lakehouse-Systeme sind nicht zur direkten Benutzung für Endanwender vorgesehen. Daher dürfte sich der Kreis auf wenige Entwickler, Analysten und technische Benutzer für Bewirtschaftungsprozesse beschränken. Date Lakehouse-Systeme können mit unterschiedlichen Dateiformaten realisiert werden. Werden tabellenähnliche Dateiformate wie Parquet, Avro oder OCR verwendet, besteht die Möglichkeit auf diese mittels externer Tabellenobjekte (External Tables) zu referenzieren. Das Prinzip der geringsten Berechtigung (Least Privilege) und die rollenbasierte Zugriffssteuerung (RBAC) lassen sich durch diese Technik auch für Data Lakehouses realisieren. Jedoch werden Row Level Security als auch Column Level Security durch External Tables nicht direkt unterstützt und müssen durch benutzerdefinierte Sicherheitsregeln realisiert werden. 

Die Metadatenschicht in Form von External Tables bietet neben der Berechtigungssteuerung zusätzlich noch die Möglichkeit des Datenzugriffs über SQL-Abfragen. 

External Tables stellen über ihren Metadaten-Layer eine relationale Abstraktionsschicht her, durch den es weitere Anwendungen wie Datenbanken oder Big Data-Programmen (Hive, Spark SQL, etc.) ermöglicht wird, SQL-Abfragen auszuführen. Das Schreiben oder Aktualisieren von Daten in External Tables wird nicht unterstützt und erfolgt daher im Rahmen der Bewirtschaftungsprozesse des Data Lakehouses. 

DWH-Anwendungen, die auf einem relationalem Cloud-Datenbankdienst basieren, bieten hier i.d.R. sowohl die gleichen als auch ergänzende Sicherheitsmechanismen, wie sie aus dem Betrieb im eigenen Rechenzentrum bekannt sind. 

Neben der Authentifizierung ist die Autorisierung als Berechtigungsvergabe die Kernaufgabe. Die am häufigsten angewendete ist die rollenbasierte Zugriffsteuerung. Analog zu den Data Lakehouse-Anwendungen erfolgt der Einsatz über die Definition von Benutzerrollen (Art der Aktivität). Rollen beinhalten Sammlungen von Berechtigungen, die bestimmte Aktionen auf Datenbankobjekten ermöglichen. Damit die Berechtigungen nicht für alle Datenobjekte angewendet werden, lassen sich Berechtigungen bestimmen, Datenbereichen zuordnen. Durch das Definieren eines Bereichs werden zulässige Aktionen weiter eingeschränkt. 

Feingranulare Berechtigungen ermöglicht es, Berechtigungen auf Spaltenebene, Zeilenebene oder auf einzelne Zellen in einer Tabelle zu gewähren oder zu verweigern. 

Data Lakehouse vs. Data Warehouse - Fazit 

Die Konzepte Data Lakehouse und Data Warehouse stellen zwei verschiedene Ansätze zur Speicherung und Verwaltung von Daten in Unternehmen dar. Beide Konzepte haben je Einsatzszenario und Unternehmensstrategie ihre Berechtigung. Besteht der Bedarf für ein Data Lakehouse, so wird dieses i.d.R. zusätzlich zu einem DWH betrieben, wobei der Data Lake als Datenhaltungsschicht des Data Lakehouses mit der Speichermöglichkeit von unstrukturierten Daten über ein Alleinstellungsmerkmal verfügt. 

In Azure werden beide Konzepte durch verschiedene Dienste und Programme umfassend unterstützt. 

Mit dem Aufkommen von Anwendungen auf Basis von künstlicher Intelligenz steigt der Bedarf an qualitativ hochwertigen Daten, um Ergebnisse von entsprechender Qualität zu erzielen. Qualitätsgesicherte Daten finden sich vornehmlich im DWH wieder. Daher werden auch in zeitgemäßen Data Lakehouses-Anwendungen erprobte DWH-Konzepte wie Layer-Architektur, Dublettenfilterung, Harmonisierung, Plausibilitätsprüfungen und Umgang mit unvollständigen Daten implementiert, um eine vergleichbare Datenqualität zu erreichen. 

Bezogen auf Anbieterunabhängigkeit sei erwähnt, dass mit Apache Spark Pool und seinen offenen Formaten die geringste Bindung an einen Anbieter besteht. Jedoch gibt es hier, verglichen mit Data Lakehouse-DBs signifikante Nachteile hinsichtlich der Flexibilität. Bei den DBMS hat man eine deutlich hohe Vendor-Lock-Gefahr. Dies ist bei Herstellern, wie bspw. Snowflake und Exasol geringer, da diese bei den meisten Cloud-Anbietern verfügbar sind bzw. über eine Public Cloud-Angebote verfügen. Die höchste Bindung an einen Cloud-Anbieter sind Produkte (bspw. Google BigQuery und AWS Redshift), die anbieterspezifisch sind. Hier gibt es für den Anwender individuell zwischen den Angeboten abzuwägen.