Chancen und Herausforderungen agiler Vorgehensweisen

Wann agile Vorgehensweisen und leichtgewichtige Dokumente an ihre Grenzen kommen

Seit Jahren wächst der Hype um agile Vorgehensweisen, wobei sich der Hype in den vergangenen Jahren, zusammen mit den Themen Digitalisierung und Industrie 4.0 exponentiell gesteigert hat. Fast täglich erscheinen neue Artikel, White-Paper, Management-Präsentationen oder gar ganze Bücher, die Agilität als eine Art Wunderwaffe predigen. Agile Vorgehensweisen sollen helfen, der stetig steigenden Komplexität und dem Bedarf einer immer kürzer werdenden Time-To-Market gerecht zu werden. Aber ist es tatsächlich der Fall, dass mit agilen Vorgehensweisen nun – mehr als 30 Jahre nach Brooks Aussage: „there is no silver bullet in software engineering“ – endlich ein Allheilmittel gefunden wurde, um Software mit besserer Qualität in kürzerer Zeit zu liefern?

[den vollständigen Artikel finden Sie im Objektspektrum Online-Themenspezial Requirements Engineering]

Data Lake, Datenschutz und die Cloud

 

Data Lake in der Cloud

Ein wichtiges Thema, dass fast jedes Unternehmen „umtreibt“ ist die Frage, ob man mit seinen IT-Systemen wie etwa einem Data Lake in die Cloud gehen soll. Der Betrieb von Anwendungen in der Cloud bietet nämlich zahlreiche Vorteile, die in vielen Fällen das Entwickeln und auch die Betriebsführung derselben einfacher und billiger machen können. Auf der anderen Seite gibt es aber Nachteile, welche sorgfältig gegen die Vorteile abgewogen werden müssen. Dazu gehört unter anderem, eine genaue Vorstellung zu entwickeln, wie man mit einem geeigneten Vorgehen den eher negativ bewerteten Aspekten gegensteuern kann, ohne die eigentlichen Vorteile zu verlieren.  Zu diesen gehören:

  • Die Cloud bietet standardisierte Produkte und eine möglichst einfache Automatisierung aller Arbeitsschritte
  • „Pay per Use“ oder „Pay as you go“: Klare Preismodelle, d.h. die Kosten sind vorhersagbar. Das hängt natürlich davon ab, ob man die Einsatzszenarien hinreichend genau kennt: Ein möglicher Kostentreiber kann Datentransfer von und in die Cloud sein. Klar bedeutet hierbei auch nicht, dass sich die Kosten einfach berechnen lassen, denn es gibt typischerweise viele Faktoren und Unbekannte, die die Kosten am Ende bestimmen… Und: „Cloud“ ist nicht unbedingt in allen Fällen billiger!
  • Verläßliche und bei Bedarf hochverfügbare und einfach skalierbare Umgebungen, ohne eine eigene Infrastruktur dafür betreiben zu müssen

Dem gegenüber stehen auch Nachteile, wie:

  • Höhere Abhängigkeit im Vergleich mit „On-Premise“ Lösungen, da die Infrastruktur nicht mehr in meiner eigenen Hand liegt und gegebenenfalls auch proprietäre Lösungen des Cloud Providers in Frage kommen
  • Das Thema Dateneigentümerschaft ist problematisch, denn der Cloud Provider hat ja notwendigerweise auch die Daten
  • Datenschutzthemen allgemein werden vor dem Hintergrund der Cloud kritisch gesehen

Erhalten der Vorteile, minimieren der Nachteile..

Dem Problem „höhere Abhängigkeit“ läßt sich relativ leicht gegensteuern. Im Grunde genommen muss ich nur dafür sorgen, dass Standardprodukte zum Einsatz kommen, welche problemlos auch in der Cloud eines anderen Providers laufen könnten, wie hier skizziert:

  • Aufbau des Data Lakes in „leeren“ virtuellen Umgebungen mit einer Standard Linux Distribution als Betriebssystem
  • Einsatz einer standardisierten Big Data Distribution wie beispielsweise Hortonworks und, soweit möglich, Vermeidung irgendwelcher herstellerspezifischer Komponenten
  • Generell Einsatz von Open Source Hadoop Tools und Big Data Komponenten
  • Verwendung von Architekturstandards und –patterns
  • Einsatz gängiger Programmiersprachen und Protokolle
  • Vermeiden des Einsatzes von Cloud Provider spezifischen Lösungen

Ein schwierigeres Thema ist das des Datenschutzes und der eng damit verbundenen Problematik der Dateneigentümerschaft. Hier besteht ja das Grundproblem schon darin, dass die Daten nicht „bei mir“ sondern „irgendwo“ in der Cloud liegen. Das heißt natürlich, sie liegen in der Infrastruktur des Cloud Providers. Dieser hat damit potentiell auch Vollzugriff auf die Daten, wobei nicht zwischen sensiblen und (relativ) unsensiblen Daten unterschieden wird. Genau hier kommt auch gleich der Datenschutz ins Spiel – ohne nachgewiesenen Schutz dürfen sensible Daten typischerweise gar nicht das Unternehmen verlassen. Manchmal heißt „gar nicht“ auch im absoluten Sinne, dass es unmöglich ist, die Daten außerhalb bestimmter zugelassener „Bereiche“ innerhalb des Unternehmens zu speichern. In diesem Falle ist Cloud leider keine Lösung. Wenn es darum geht, dass Daten nur in Cloudcentern einer bestimmte Region physikalisch gespeichert werden oder gar ein Land nicht verlassen dürfen, dann ist die Antwort größerer Cloud Provider meist das Angebot, Daten auch physikalisch nur in Cloud-Rechenzentren einer bestimmten Region (Europa) oder eines Landes (z.B. Deutschland / Frankfurt) zu speichern. Oftmals ist das verbunden mit rechtlichen Konstrukten die unterbinden, dass Dritte Zugriff auf die Daten verlangen dürfen.

Eine Stufe „tiefergelegt“

Neben diesen allgemeinen Maßnahmen gibt es zahlreiche weitere, die tiefer gehen. Im folgenden eine Auswahl anhand von konkreter Praxiserfahrung in Data Lake Projekten:

  • Verschlüsselung der Root Partition aller „Server“ Instanzen und aller weiteren Partitionen (falls vorhanden), ganz besonders auch der Bereiche, in denen meine Daten gespeichert werden
  • Verschlüsselung aller Daten vor Upload in den Data Lake in der Cloud, Entschlüsselung erst nach Download aus der Cloud
  • Sichere Protokolle
  • Zugriffe über Edge Server / Bastion Server
  • Nur die benötigten Services und Ports zwischen konkreten Endpunkten freischalten
  • Feingranulares Berechtigungskonzept
  • Mandantenbasierte Architektur und Sandboxing
  • Klardaten speichern nur wo explizit hierfür eine Rechtsgrundlage existiert
  • Pseudonymisierung und Anonymisierung aller anderen Daten
  • Feingranulares Löschkonzept von Beginn an vorsehen

Und, und , und … Hier ließen sich sicher noch weitere Dinge aufzählen. Doch ich denke, dass das, was ich hier skizziert habe schon mal einen gewissen Überblick zu möglichen Lösungsszenarien gibt. Wenn ich alle diese Dinge beachte (es dürfen auch gerne mehr sein), dann habe ich tatsächlich eine Chance, einen sicheren Data Lake in der Cloud aufzubauen. Einen Data Lake, der den Anforderungen aus Compliance und Datenschutz wirklich genügt.

 

Data Lake und Datenschutz: Alles schwimmt in eigenen Bahnen

Sandboxing und logische Trennung von Bereichen

Ein Begriff, der in Diskussionen zur Architektur von Hadoop-basierten Data Lakes immer wieder fällt, ist „Sandboxing“. Damit ist gemeint, dass es für bestimmte Zwecke nützlich, für manche sogar notwendig ist, vom „eigentlichen“ Data Lake getrennte Bereiche zu haben. Diese können auch außerhalb der Data Lake Infrastruktur liegen. Ein Beispiel hierfür sind analytische Sandboxes, die maßgeschneiderte Umgebungen und Daten nur für Data Scientists bereitstellen. In solchen Umgebungen können verschiedene Methoden und Verfahren entwickelt und erprobt werden, ohne die große „Allgemeinheit“ der Data Lake User zu stören. Da solche Sandboxes typischerweise kleine Varianten derselben Hadoop Distribution sind, ist es in der Regel sehr einfach, später die Ergebnisse in den großen Data Lake zu übertragen. „Klein“ bedeutet hierbei, dass die Anzahl der Worker Nodes und damit auch des Speicherplatzes gegenüber dem eigentlichen Data Lake kleiner ausfallen. Es kann sogar Sinn machen, einen Single Node Cluster aufzusetzen, beispielsweise um bestimmte Funktionalitäten initial auszuprobieren.

Was natürlich auch in Hinblick auf Kosten und gemeinsame Verwendung von Ressourcen oftmals angestrebt wird, ist die Realisierung von „Sandboxes“ in der eigentlichen Data Lake Infrastruktur als alternative Variante. Neben der Notwendigkeit, für alle Benutzerkreise ein passendes Ressourcenmanagement zu entwickeln – hier ist YARN eine wichtige Komponente zur Steuerung – muss man auch Daten und Zugriffsbereiche separieren. Oder anders gesagt: Hier ist nicht nur aus Gründen des Datenschutzes ein passendes Sicherheits- und Zugriffskonzept zu entwickeln – in der Regel gibt es User, die nur auf bestimmte Daten in bestimmten „Sandboxes“ zugreifen dürfen! Jeder Benutzerkreis schwimmt also in seinen eigenen Bahnen.

 

 

 

 

Das läuft darauf hinaus, dass man abgegrenzte Bereiche einrichtet, auf die der eigentliche Data Lake keinen Zugriff hat, sondern nur ein bestimmter Kreis von Usern und / oder Mandanten. Ein typisches Beispiel sind spezielle Klardatenbereiche, die nur dann zulässig sind, wenn man nachweisen kann, dass nur berechtigte Personen mit diesen Daten etwas „machen dürfen“. Das Managen und Nutzen dieser Daten obliegt dann auch ausschließlich diesem Personenkreis. Genauso aber können das auch anonymisierte oder pseudonymisierte Bereiche sein, für die ähnliches gilt. Was also generell gefordert wird ist eine Mandantenfähigkeit des Data Lakes, also die Möglichkeit klar abgegrenzte Bereiche einzurichten

  • mit feingranularer Zugriffsteuerung
  • mit der Möglichkeit einer passenden Ressourcensteuerung

Es ist natürlich innerhalb eines großen Data Lakes viel schwieriger das alles einzurichten, zu steuern und zu administrieren. Deshalb muss immer auch eine Abwägung vorgenommen werden, ob es vielleicht einfacher ist, mit separaten Umgebungen zu arbeiten. Hier sind die Bereiche auch „physisch“ getrennt. Eine Forderung, die von Seiten des Datenschutzes oftmals erhoben wird. Aber nehmen wir mal an, wir könnten mit „logisch“ getrennten Bereichen im Data Lake arbeiten. Wie kann man das erreichen?

Mandantenfähigkeit

Typische Hadoop Distributionen wie z.B. Hortonworks enthalten Mittel für solche Zwecke. Das sind Services und Tools, die die Trennung von Mandanten unterstützen. Wichtig ist dabei, dass eine zentrale Security und Governance Infrastruktur eine Klammer um das Ganze bilden kann.

Im Fall von Hortonworks ist hierbei Apache Ranger eine wesentliche Komponente. Über Ranger lassen sich User, Gruppen / Rollen und deren Berechtigungen feingranular in den folgenden wichtigen Hadoop Komponenten verwalten:

  • Apache Hadoop HDFS
  • Apache Hive
  • Apache HBase
  • Apache Solr
  • Apache Storm
  • Apache Knox
  • Apache Kafka
  • Apache Nifi
  • Apache YARN

Mandanten sind hierbei Gruppen / Rollen und deren Berechtigungen. Grundsätzlich sind das zunächst die Berechtigungen zu schreiben, zu lesen, Daten zu löschen, Objekte anzulegen und zu löschen. Aber es geht auch noch spezieller: In Hive lässt sich beispielsweise der Zugriff auf Tabellen und Views, bestimmte Spalten und sogar eine „row-level“ Security in den Daten selbst realisieren. Das heißt es lässt sich eine Filterung der Daten abhängig vom Security Kontext über eine implizite „where-clause“ des SQL (HiveQL) Statements erreichen. Genauso lassen sich im Hadoop Filesystem HDFS Bereiche (Folder) nur für Mandanten einrichten, dasselbe gilt für Kafka Topics, also die Kafka Messages Bereiche, die nur für bestimmte Mandanten gedacht sind. Ranger wiederum nutzt die nativen Security Mechanismen der einzelnen Komponenten via Plug-Ins.

Und „Sandboxes“?

Sandboxes sind dann einfach die jeweils für bestimmte Nutzergruppen und / oder Mandanten zugänglichen Bereiche wie Hive und HBase Tabellen, bestimmte Directories im HDFS, bestimmte Kafka Topics und auch Solr Collections, beziehungsweise in Hive auch Views und noch tiefergehende Berechtigungen wie „Row-level Security“, die an einer „Mandanten-ID“ in der jeweiligen Tabelle festgemacht werden kann. Wichtig ist eigentlich nur, dass man allen anderen Usern / Gruppen / Rollen, die auch Zugriff auf den Data Lake haben, den Zugriff auf die solchermaßen geschützten Ressourcen entzieht. Für Klardaten bietet sich zusätzlich auch die Verwendung von „Encryption Zones“ im HDFS an, d.h. nur ein Mandant mit dem entsprechenden Schlüssel kann die Daten in Klarform abgreifen, alle anderen bleiben hier außen vor, selbst wenn sie unberechtigterweise sich Zugriff auf die Daten verschaffen können. Das generelle Verschlüsseln von Daten jenseits der speziellen Anforderungen der Anonymisierung und Pseudonymisierung ist besonders für den Cloud Betrieb relevant. Dazu demnächst mehr.

Data Lake und Datenschutz: Anonymisierung und Pseudonymisierung

Datenschutz im Data Lake wird zu „Muss“… Wie geht man vor?

Mit der Einführung der europäischen Datenschutz-Grundverordnung (EU-DSGVO) hat sich auch das Vorgehen beim Aufbau von Data Lakes gewandelt. Datenschutzaspekte spielen eine sehr viel größere Rolle als vorher. Themen wie Anonymisierung und Pseudonymisierung von Daten und ganzen Datenbereichen sind zu einem Muss geworden und erzwingen ein sehr durchdachtes Vorgehen. Warum ist das aber gerade beim Aufbau von Data Lakes so kritisch? Sind denn Anonymisierung und Pseudonymisierung von Daten etwas Neues? Eigentlich nein, aber im Kontext von Data Lakes in gewisser Weise schon: Der ursprüngliche Focus von solchen Systemen lag in der Vergangenheit auf dem Managen von enorm vielen heterogenen Daten. Das heißt, man kümmerte sich in der Regel zunächst um das Bereitstellen dieser Daten für Analysen und operative Zwecke in unverschlüsselter Form, was auch die Umsetzung analytischer Use Cases mit diesen Daten mit eingeschlossen hat. Warum man das gemacht hat, liegt eigentlich auch auf der Hand: Man spart sich Komplexität und kann mit Klardaten auch sehr viel einfacher umgehen, da sich Analysen und analytische Anwendungen sehr einfach mit ihnen realisieren realisieren lassen. In solchen Systemen hat man in der Regel keine große Anforderungen in Sachen Datensicherheit und Governance realisieren zu müssen geschweige denn realisiert, da Ziel und Zweck eines Data Lakes von anderen Faktoren bestimmt wurde. Dieses Bild ändert sich allerdings sehr stark in letzter Zeit.

Eine daraus folgende Anforderung, mit dem man also sehr viel stärker als früher konfrontiert ist, ist die Forderung nach Pseudonymisierung und, noch stärker, Anonymisierung der Daten oder zumindest von Datenbereichen im Data Lake. Daten, die keinen direkten zeitlichen und operativen Zweckbezug mehr haben, können nicht einfach mehr klar abgelegt werden. Es reicht auch nicht, einfach die Datenträger zu verschlüsseln. Die Daten selbst müssen in einem solchen Fall in der Regel anonymisiert oder mindestens pseudonymisiert werden. Was verbirgt sich aber hinter diesen Begriffen?

Anonymisierung, Pseudonymisierung und Analytik

Kurz gesagt bedeutet Pseudonymisierung, dass ich die Daten bei Bedarf noch auf einen Ursprung (Person, Kunde, Mitarbeiter,…) zurückführen kann, zumindest theoretisch. Bei der Anonymisierung ist das nicht mehr möglich. Eine gute Gegenüberstellung findet sich hier: Anonymisisierung und Pseudonymisierung

Für die Durchführbarkeit von Analysen ist natürlich wichtig, dass bei diesen Vorgehensweisen nicht die Beziehungen in den Daten verlorengehen. Das bedeutet, dass eine Person in einem für mich wichtigen Datenauswertungskontext immer das gleiche Pseudonym bekommt. Ist dieses nicht mehr auf die Person rückführbar – was allerdings in der Regel sehr schwer nachweisbar ist – ist die Person sogar anonymisiert. Es wird typischerweise auch gefordert, dass der Schlüssel

  • nach einem bekannten sicheren Verfahren erzeugt wird
  • nur in eine Richtung funktioniert, das kann man organisatorisch „sicherstellen“, indem der Schlüssel „weggeworfen“ oder sicher verwahrt wird
  • der Schlüssel nicht im Data Lake selbst abgelegt werden darf, sondern eine sichere Stelle außerhalb benutzt wird

Aber die Schwachstelle des Ganzen ist oben schon angedeutet: Ein Nachweis zu führen, dass solchermaßen anonymisierte Daten tatsächlich anonym sind in dem Sinn, dass unter keinen Umständen über sie ein Personenbezug hergestellt werden kann, kann sich als unmöglich oder doch sehr schwierig herausstellen. Es gibt nämlich bekannte Situationen, in denen aus den Daten selbst ohne höheren Aufwand doch ein Personenbezug hergestellt werden kann. Ein typisches Beispiel sind Mitarbeiterdaten, die aufgrund ihres Arbeitsplatzes und ihrer Einordnung in die Organisationshierarchie des Unternehmen leicht identifizierbar sind. Oder Kundendaten, die alleine aufgrund der Tatsache, dass Adressgebiete nicht hinreichend groß gewählt wurden, auf einzelne Personen rückführbar sind – zumindest indirekt und unter Umständen unter Zuhilfenahme von „hinreichend schlauen“ Verfahren. Im ersten Fall der Mitarbeiterdaten ist das sogar besonders kritisch, da hier nicht nur die Interessen des Datenschutzes selbst, sondern auch des Betriebsrats und eventuell vorhandener Betriebsvereinbarungen berücksichtigt werden müssen. Ich glaube, diese Beispiele zeigen sehr gut, in welche Fallen man hier geraten kann.

Und was ist mit Klardaten?

Klardaten dürfen nur dann im Data Lake gespeichert und verwendet werden, wenn eine Erlaubnis dazu vorliegt. Es ist also bei der Verarbeitung und Speicherung solcher Daten immer auch eine Prüfung  der „Permissions“ zu diesen Daten vorzunehmen. Die Daten müssen auch unverzüglich  bei berechtigtem Entzug der „Permissions“ gelöscht werden können. Ein solcher Widerruf oder genereller Einspruch gegen die Datenspeicherung kann beispielsweise durch einen Kundenauftrag veranlasst sein. Jetzt ist aber allein die Aufgabe, diese „Permissions“ in korrekter Weise zu verwalten eine keinesfalls triviale Aufgabe, mit der die zum Management eines Data Lakes Berechtigten in der Regel ein Problem haben. Eine mögliche Abhilfe kann hier sein, dass zwar die grundlegenden Infrastruktur zum Speichern dieser Daten seitens des Data Lakes bereitgestellt und verwaltet wird (das „System an sich“), die Benutzung von solchermaßen kritischen Bereichen aber in die Hand dafür speziell Berechtigter gelegt wird. Diese müssen dann auch zwingend die Berechtigung nachweisen – denn die Verantwortung für diese Daten liegt jetzt komplett in deren Hand! Ein Zugriff von dem normalen (und in der Regel anonymisierten) Data Lake in diese Daten ist nicht möglich und wird normalerweise technisch unterbunden. Die Datenhaltung inklusive dem Laden und Verarbeiten der Daten und das Löschen wird von den dazu Berechtigten ausgeführt und hat mit der eigentlichen Betriebsführung des Data Lakes dann „nichts zu tun“. Das erfordert natürlich ein ausgeklügeltes Sicherheits- und Mandantenkonzept. Hierauf werde ich demnächst ein Licht werfen.

 

 

 

 

 

 

Data Lake und Datenschutz: Eine schwierige Beziehung

Focus von Hadoop-basierten Systemen

Nachdem der Focus von Hadoop-basierten Big Data Systemen in der Vergangenheit im Wesentlichen auf dem Managen und Bereitstellen von Daten für Analysen und operative Zwecke gelegen hat, ohne große Anforderungen in Sachen Datensicherheit und Governance realisieren zu müssen, ändert sich dieses Bild stark in letzter Zeit. Mit dem Bekanntwerden der europäischen Datenschutz Grundverordnung https://dsgvo-gesetz.de/, welche zusammen mit einer Erneuerung des Bundesdatenschutzgesetzes ab Ende Mai 2018 zwingend angewendet werden muss und einen grundlegenden Paradigmenwechsel darstellt, wurde vielen Organisationen und Unternehmen deutlich, dass bisher eingeschlagene Wege und ein gewisser „sorgloser“ Umgang mit Daten in der Datenverarbeitung in Zukunft nicht mehr gangbar sind. Die europäische Datenschutzgrundverordnung soll jedem ein Recht einräumen, über seine Daten grundsätzlich selbst zu bestimmen. In diesem Zusammenhang sind auch traditionell so verstandene vom Kunden selbst eingeräumte Rechte an seinen Daten mit Hilfe von pauschalen Formulierungen nicht mehr tragbar. Die Rechte müssen stattdessen zukünftig sehr feingranular behandelt werden. Was heißt das? Technisch bedeutet das, dass auf Kundenanforderung  die von ihm gesammelten Daten zugänglich gemacht und von diesem beanstandete Daten schnell aus den Systemen gelöscht werden müssen, siehe dazu auch https://www.datenschutzbeauftragter-info.de/eu-datenschutzgrundverordnung-das-sind-die-neuerungen/. Besonders heikel sind die bei Verstößen gegen die Verordnung möglicherweise zu zahlenden Bußgelder. Diese können bis zu 4 Prozent der Jahresumsätze eines Unternehmens betragen! Klar, dass hier Handlungsbedarf besteht.

Personenbezogene Daten sind schwierige Daten…

Zu personenbezogenen Daten und dem gewünschten (geforderten!) Umgang mit diesen kann man dazu in Datenschutz-Handbüchern in etwa folgendes lesen:

Personenbezogene Daten sollen jederzeit gelöscht werden können, soweit nicht gesetzliche oder vertragliche Aufbewahrungspflichten entgegenstehen. Dasselbe gilt, wenn Grund zu der Annahme besteht, dass durch eine Löschung schutzwürdige Interessen des Betroffenen beeinträchtigt würden. In diesen Fällen wird typischerweise gefordert, dass an die Stelle einer Löschung eine Sperrung tritt.

Diese Daten sind also in den folgenden Fällen zu löschen:

  • Ihre Speicherung ist per se unzulässig
  • Es handelt sich um „schwierige“ Daten über die rassische oder ethnische Herkunft, politische, religiöse oder philosophische Meinungen und Überzeugungen, sexuelle Vorlieben, Vorstrafen und ähnliche Dinge, wobei ihre Richtigkeit von der verantwortlichen Stelle nicht bewiesen werden kann. Aber: Der Beweis ist zu erbringen, sobald der Betroffene die Richtigkeit bestreitet.
  • Wenn sie für eigene Zwecke verarbeitet werden, sobald ihre Kenntnis für die Erfüllung des Zweckes der Speicherung nicht mehr erforderlich ist. Das trifft in der Regel für dispositive Systeme wie Data Lakes, Data Warehouses und Artverwandte zu.

Recht auf Vergessenwerden

Das sogenannte „Recht auf Vergessenwerden“ soll sicherstellen, dass digitale Informationen mit einem Personenbezug nicht dauerhaft zur Verfügung stehen. In der am 24. Mai 2016 in Kraft getretenen und ab dem 25. Mai 2018 in allen EU-Mitgliedstaaten unmittelbar geltenden Datenschutz-Grundverordnung wird das Recht auf Löschung in Art. 17 geregelt. Näheres dazu kann man in der deutschen Version des Artikels 17 der DSGVO nachlesen. Kurz zusammengefasst hat eine betroffene Person hat das Recht, zu verlangen, dass sie betreffende personenbezogene Daten unverzüglich gelöscht werde, wenn

  • die personenbezogenen Daten für die Zwecke, für die sie erhoben oder auf sonstige Weise verarbeitet wurden, nicht mehr notwendig sind
  • die betroffene Person ihre Einwilligung, auf die sich die Verarbeitung stützte, widerruft, und es sonst an einer anderweitigen Rechtsgrundlage für die Verarbeitung fehlt. Solche können zum Beispiel gesetzliche Aufbewahrungspflichten sein oder aber das Einfrieren der Daten zur Beweissicherung („Legal Hold“).

Was ist also zu tun? Prinzipiell muss ich beim Aufbau von Data Lakes (und natürlich auch von anderen Systemen) die Forderungen „Data protection by design“ und „Data protection by default“ beachten, sonst laufe ich in eine gefährliche Sackgasse. Sackgasse kann im Extremfall bedeuten, dass ich die ganze „illegale“ Datenhaltung forensisch löschen muss – ein Albtraum für alle Beteiligten. Damit das nicht passiert, ist von Anfang an sauber zu trennen zwischen Daten, die personenbeziehbar sind und klar vorliegen müssen und solche, die lediglich anonymisiert, eventuell auch pseudonymisiert gespeichert werden können. Diese „Datentöpfe“ müssen in der Regel mindestens logisch voneinander separiert gespeichert und geschützt werden – Stichwort logische „Sandboxes“. Hierzu ist ein Mandantenkonzept zu entwickeln und im Data Lake auch konsequent umzusetzen.

Klardaten…

Zu den klar vorliegenden Daten, aber auch bei anderweitig problematischen Daten, ist immer eine Prüfung  der vom Kunden gegebenen Einverständnisse zu diesen Daten vorzunehmen. Diese müssen auch ohne größeren Zeitverzug bei Entzug dieser gelöscht werden können. Das impliziert natürlich, dass man in geeigneter Weise jeden (!) Datensatz mit den dazu gegebenen Permissions verknüpfen können muss. Üblicherweise wird von Datenschutzseite auch eine maximale Aufbewahrungsdauer gefordert, falls der Data Lake in einem solchen Fall nur als bereitstellendes System dient. Ein Ausweg aus diesem Dilemma bietet der Ansatz, nicht  einen zentralen Data Lake zu bauen, sondern im Rahmen eines „Sandboxing“ auch physikalisch getrennte Umgebungen für verschiedene klar definierte Anwendungszwecke aufzubauen.

Das Bereitstellen der aktuellen Kunden-Permissions erfordert in der Regel ein separates System. Dies muss in der Regel in Lage sein, in nahezu Echtzeit die Permissions aktualisieren zu können. Üblicherweise stellt ein solches System über einen Service die Informationen zu den Berechtigungen bereit. Vorteil der Entkoppelung ist, dass man im Data Lake nicht mit Aufgabe konfrontiert ist, das operative Handling rund um die Kunden-Permissions zu implementieren – es recht in der Regel der Aufruf eines solchen Services bei Bedarf.

Implikationen für den Betrieb des Data Lakes

Was ist ein solcher Bedarf? Nun, im Grunde genommen alles, wo Daten, die im Data Lake gespeichert sind, verwendet werden beziehungsweise auch für den Fall, das regelmäßig Löschroutinen über den Bestand des Data Lakes laufen (müssen). Für Anwendungen, die operativen Charakter haben, sind Klardaten meist  notwendig. Die Verarbeitung ist in Regel durch den Zweckbezug gedeckt, wenn der zeitliche Rahmen auch dazu passt. Ein Beispiel: Um Verspätungen im öffentlichen Verkehr berechnen zu können und personalisierte Verspätungsmeldungen und Empfehlungen geben zu können, braucht man neben den Streckendaten, Fahrtdaten und weiteren nützlichen Informationen auch personenbezogene Daten. Diese werden für die Berechnung von Prognosen bereitgestellt und können auch verarbeitet werden, wenn dieses zeitnah erfolgt, also zeitnah zur tatsächlichen Reise oder Fahrt. Genauso können daraus abgeleitete Empfehlungen an den Kunden weitergegeben werden. Voraussetzung ist natürlich, dass der Kunde sein Einverständnis zum Empfang solcher Information gegeben hat. Die Daten selbst, sofern sie noch personenbeziehbar sind, müssen allerdings dann auch zeitnah wieder gelöscht werden.

Umgekehrt dürfen diese Informationen nicht ohne weiteres für andere analytische Zwecke verwendet werden, zumindest nicht, wenn hierbei noch ein Personenbezug herstellbar ist. Hier kommen jetzt verschiedene Möglichkeiten in Betracht, die die Situation trotzdem „retten“ können. Wichtige Stichwörter sind Pseudonymisierung und Anonymisierung und der Aufbau mindestens logisch streng getrennte Bereiche. Was dahinter steckt und wie man sich ein weiteres Vorgehen vorstellen kann? Dazu demnächst mehr.

Automagic Jersey API Testing

When writing or consuming REST APIs there are many excellent options to choose from. When it comes to testing parts of an API in isolation the situation is noticeably worse, though, especially in the Jersey ecosystem. Nevertheless is it useful to not only distinguish between unit and integration tests but also be able to apply both concepts when developing and testing REST APIs.

In this blog entry we will explore how unit tests relate to REST APIs in general, which tools the Jersey framework provides in this regard, the pitfalls to deal with when using them, and finally, how we may overcome its shortcomings.

Table Of Contents

Spring, anyone?

Yes, we, too, have heard of Spring. The abstractions it provides are arguably superior to Jersey’s more imperative style. This is especially true when it comes to easy testing where Spring shines, whereas Jersey does not.
Even though Jersey does provide a dedicated test framework you have to do all the work of setting it up and wiring it together yourself. If using custom filters, features and/or injection providers this becomes a tedious affair at best, and error prone or ignored at worst.

So why try making Jersey testing work regardless? Sometimes switching to Spring is not viable, e.g. for legacy projects. Some people simply like Jersey better. Having the option to write proper unit tests in Jersey is a good thing regardless of the motivation.

Unit Testing REST

Let us assume we have a very basic Jersey controller for a RESTlike ressource:


If we want to write unit tests for our controller we might trivially do so like this:

Note that this is a unit test for our Java controller method and not in fact for our REST API method.
When checking the result of our call its representation is a Java class and not a JSON string as indicated by our controller. At this point we are unit testing our implementation internals as opposed to our public contract.

To put it more bluntly we have not tested our actual REST API at all.

Jersey Test Framework

Overview

Luckily, Jersey does provide its own testing framework, including a slim in-memory application container.

Let’s try again:

Now we can make assertions about the API our actual consumers will use, and ensure our contract matches the actual responses going out.

Note that, while we did fire up an actual mini-application container, we restricted ourselves to the one controller we wanted to test. Thus we can still call this a unit test, confined to the actual unit under test.

Contrast this with e.g. RESTassured which allows testing your REST API in a very similar fashion but without allowing you to confine yourself to only parts of your application, making it more of an integration test suite.

Easy Mode?

So, it looks Jersey makes it all easy enough for us. For simple code such as above this may hold; if making use of more of Jerseys features the presented method does scale poorly, unfortunately.

There are some cases where things start to fall apart, among them mocks and providers.

Mocking

Mocking parts of an application is an essential technique to ensure manageable and meaningful tests. In our example we probably want to mock our service since its logic not the thing we want to test here; we rather assume this part of our application is working as intended and concentrate on the code the test is being written for:

If we test Java code wiring this up is straightforward:

Getting Jersey to pick this up requires the following in addition:

This means a lot of boilerplate to accommodate a standard workflow. While setting up tests this way is very much possible it does result in a lot of duplicate code that does not directly contribute to our test goals but needs to be maintained regardless.

Providers

One of the powerful features Jersey provides is customised injection of parameters into methods managed by Jersey’s lifecycle. In the following snippet we let Jersey handle the controller argument annotated as @User and have it inject a proper object at the call site whenever we need it. The actual setup of the @User instance is defined by a so called Provider that we register with Jersey.

To ensure this works in our unit tests we have to actively register our provider implementation or preferably bind to a mock instance:

This, too, necessitates additional code to make it work within the Jersey Test Framework, rendering testing your API properly more verbose and brittle than writing regular unit tests.

Custom Controller Tests

Taking the above into account may make testing REST resources look like too much of a hassle to do with Jersey. Which in turn may lead to many developers just not doing it.
Luckily, Jersey allows us to hide most of that boilerplate away, requiring us to write our test setups only slightly differently than what we are used to with regular Java tests.

Usage

Applied to our example controller such a test might look similar to the following:

It is readily apparent that not having to set up the Jersey container by ourselves improves readability and maintainability of our test. All the complexity is provided by and hidden behind the generic type of our extended class.

Mocking our internal EchoService is as terse as with a regular Java class; the only difference being that we retrieve an already mocked parameter instead of passing it on in the first place. The actual definition of the mocked behaviour is done as usual.

The actual tests can then be defined as demonstrated earlier – testing REST functionality as opposed to Java code.

Internals

Combining the terseness of a unit test with the capabilities of Jersey’s test framework may look like we are having our cake and eating it, too.
It is made possible by extending the JerseyTest class provided by Jersey’s test framework and automating all of the tedious setup it requires.
At the moment this means conforming to a set of assumptions in order to work properly:

  • controller dependencies must be provided explicitly – no injection via annotation
  • controller dependencies can only be accessed by type
  • test constructors should be explicitly annotated, defaulting to the constructor with the most arguments
  • constructor arguments are always mocked automatically
  • filters and providers are always registered for all controller tests

In turn this provides us with the following facilities:

  • automatic setup of the Jersey test container with the controller under test and classes relevant to the Jersey lifecycle
  • automatic mocking of all constructor parameters
  • convenient accessor method for constructor parameters

The actual implementation is rather concise and straightforward, too:

pom.xml

Since Jersey is a tad picky when it comes to mixing versions of its various sub-projects here is the `pom.xml` used throughout the examples above.

AWS DMS

DWH-Modernisierung mit dem AWS Database Migration Service

AWSLogoIm Rahmen einer Modernisierungsstrategie für die eigene BI-Umgebung steht inzwischen eine große Bandbreite verschiedenster neuer Technologien zur Verfügung. Diese sollten im Rahmen der Erarbeitung eines Konzeptes berücksichtigt werden. Die Potentiale, die die Nutzung von Clouddiensten bietet, sind definitiv eine der zu prüfenden Möglichkeiten bei der Modernisierung eines Data-Warehouses (DWH). Denn im Vergleich zu anderen neuen Technologien haben Clouddienste den Hypestatus bereits verlassen und sind auch in großen Unternehmen (z.B. Deutsche Bahn AG) inzwischen ein Teil der Gesamtstrategie der IT.

Da mit dem Wechsel der BI-Umgebung in die Cloud sowieso eine Ablösung der On-Premises Infrastruktur ein Teil der Aufgabe ist können in diesem Zuge auch gleich noch weitere Potenziale erschlossen werden. Diese können sich in Einsparpotenziale, einer Simplifizierung oder auch einer Nutzung schnellerer Technologien für die BI-Umgebung äußern. So kann man z.B. noch die folgenden Punkt andenken:

  • Umstellung auf andere z.B. lizenzfreier Data-Warehouse-Technologien wie PostgreSQL
  • Konsolidieren bestehender BI-Datenbanken durch Schemaanpassung oder Zusammenführung/Auseinanderdividieren von Data-Warehouses
  • Kontinuierliche Replikation von Daten aus dem Quell- in das Zielsystem anstatt einer ad hoc Ablösung einer Datenbank durch Einmal-Migration mit der Möglichkeit einer längerfristigen Umstellung aller Applikationen auf eine neue Datenbanktechnologie

Umsetzung in Amazon Web Services (AWS) mit dem Database Migration Service

Amazon bietet mit den Amazon Database Migration Services (AWS DMS) ein umfangreiches Toolset an, um die Migration einer lokalen BI-Umgebung (DWH oder Datenbanken) bzw. deren Replikation in die Amazon-Cloud zu vereinfachen. Die Tools sind darauf angelegt, eine Migration bzw. Replikation strukturiert und transparent zu organisieren und unterstützt bei den Herausforderungen, die bei dieser Art der Aufgabenstellung klassischerweise auftreten. Diese können beispielsweise uneinheitliche Schemaobjekte der verschiedenen BI-Datenbanktechnologien oder die Notwendigkeit der parallelen Führung einer doppelten Datenhaltung in der Übergangsphase in die Cloud sein. In AWS sind die Tools darauf ausgelegt, genau dieses zu gewährleisten.

Migration vs. Replikation in AWS

In AWS wird nicht eindeutig zwischen einer Replikation bzw. Migration unterschieden. Grundsätzlich kann eine Migration ein einmaliger Transfer einer Datenbank mit der Ablösung einer legacy Datenbank verstanden werden, während bei der Replikation eher ein Parallelbetrieb verschiedener Datenbanken verstanden wird. So können zur Erhöhung der Ausfallsicherheit durchaus DWHS oder Datenbanken repliziert werden ohne das eigentliche Ausgangssystem irgendwann abzuschalten.

Bei den meisten Ablösungen von DWHs ist es aber zumeist so, dass diese doppelt vorgehalten werden. Die auf das DWH zugreifenden Applikationen (z.B. Analytic Tools) können häufig nicht einfach parallel mit migriert werden. Daher findet auch bei einer klassischen Migration in einem gewissen zeitlichen Rahmen eine Replikation statt. Daher wird in AWS nur wenig zwischen einer Replikation und Migration unterschieden.

Im Rahmen von AWS ist es wichtig zu verstehen, dass die AWS eigenen Tools im Rahmen der Database Migration Services vor allem Migrationen bzw. Replikationen von und nach AWS unterstützen.

homogene vs. heterogene Migration

In AWS wird grundsätzlich zwischen einer homogenen und einer heterogenen Migration (bzw. Replikation) unterschieden. Diese sind interne Bezeichnungen innerhalb von AWS um zu verdeutlichen, dass nicht nur eine Migration oder Replikation innerhalb gleicher Datenbanksysteme (z.B. „homogen“ von Oracle nach Oracle). Auch ein Wechsel der Systeme ist möglich (z.B. „heterogen“ von Oracle nach postgreSQL). Jeder, der eine solche „heterogene“ Migration bereits mal organisiert hat, weiß um die Herausforderungen, die damit verbunden sind.

DMS Task vs. Schema Conversion Tool (SCT) vs. native Migrationstools

In AWS stehen verschiedene Werkzeuge für die Migration bzw. Replikation von DWHs oder einfachen Datenbanken zu Verfügung. Grob formuliert kann ein Task ein Full Load, ein Delta Load oder beides beinhalten. Als kontinuierlicher Dienst ist dieser nicht zeitgebunden, sondern repliziert kontinuierlich Daten aus einem Quellsystem in ein Zielsystem. Der Service bietet darüber hinaus auch noch weitere Funktionen um einen Task herum, wie Logs, Benachrichtigungen usw..

Migrations- und Replikationsmöglichkeiten

Auswahlmöglichkeiten für ein Task in DMS

Bei heterogenen Migrationen (siehe unten) kann das notwendige Mapping der Schemata des Quell- und Zielsystems durch das Schema Conversion Tool (SCT) organisiert werden. Dieses ist ein desktopbasierendes und kostenfreies Werkzeug für Windows, Mac und Linux. Dieses erlaubt das Folgende:

  • Kopieren eines Datenbankschemas von einer Quelle auf ein Ziel
  • Konvertieren eines Datenbank- oder Data Warehouse-Schemas
  • Analysieren einer Datenbank, um
    • die Konvertierungskomplexität zu ermitteln
    • mögliche Einschränkungen für die Ausführung auf Amazon RDS zu ermitteln
    • zu ermitteln, ob ein Lizenz-Downgrade möglich ist
  • Konvertieren von eingebettetem SQL-Code in einer Anwendung
  • Migrieren von Data Warehouse-Daten zu Amazon Redshift

Siehe https://aws.amazon.com/de/dms/faqs/ – 07.06.2017

Analyse heterogene Migration

Auswertung einer Analytik im Schema Conversion Tool mit einer Übersicht (links) und einer Detailauswertung (rechts)

Man beachte, dass für die heterogene Migration bzw. Replikation nur bestimmte DWH- bzw. Datenbanksysteme unterstützt werden. Dies sind im Folgenden:

Quelldatenbank Zieldatenbank auf Amazon RDS
Oracle Database Amazon Aurora, MySQL, PostgreSQL, MariaDB
Oracle Data Warehouse Amazon Redshift
Microsoft SQL Server Amazon Aurora, Amazon Redshift, MySQL, PostgreSQL, MariaDB
Teradata Amazon Redshift
IBM Netezza Amazon Redshift
Greenplum Amazon Redshift
HPE Vertica Amazon Redshift
MySQL und MariaDB PostgreSQL
PostgreSQL Amazon Aurora, MySQL, MariaDB
Amazon Aurora PostgreSQL

https://aws.amazon.com/de/dms/ – 26.05.2017

Die Entwicklung geht aber immer weiter. Seit 10. April 2017 wird auch NoSQL-Datenbank MongodDB als Quellsystem sowie Amazon DynamoDB als Sourcesystem unterstützt.

Das SCT migriert die Daten nicht direkt über das Tool, bietet aber eine direkte Integration in ein DMS Task an, so dass mit dem definierten Mapping innerhalb von SCT die Migration bzw. Replikation innerhalb des Task möglich ist.

Zudem stehen auch in AWS die nativen Migrationstools wie Export/Import oder Datapump (Oracle) oder auch pg_dump (potgreSQL) zur Verfügung, unabhängig davon, ob die Datenbank im Rahmen von RDS oder auf einer EC2-Instanz läuft.

Kosten

Grundsätzlich werden die einzelnen Tasks in AWS DMS nicht in Rechnung gestellt, d.h. prinzipiell kann eine virtuell unendliche Anzahl von Tasks eingerichtet werden ohne dass es zu einem finanziellen Mehraufwand kommt. Auch das Schema Conversion Tool ist lizenzkostenfrei. Wie üblich bei AWS ist nur die für die Migration benötigte Infrastruktur kostenpflichtig. Kostenfaktor sind vor allem zwei AWS Dienste:

  • Die Migrations- und Replikationstasks werden auf Replikationsinstanzen ausgeführt, deren Betrieb kostenpflichtig ist.
  • Sind AWS-externe Datenbanken an der Migration beteiligt, die via DierectConnect oder VPN an AWS angebunden sind, treten weitere Kosten durch den Datentransfer für die Migration und Replikation auf.

Die aktuelle Preisgestaltung kann direkt von der AWS Webseite abgerufen werden: https://aws.amazon.com/de/dms/pricing/

Fazit

Eine Modernisierungsstrategie für ein Datawarehouse sollte die Migration in die Cloud beinhalten. Als Erweiterung sollte aber auch die Ablösung lizenzgebundener DWH-Systeme durch lizenzfreier Systeme mit angedacht werden, alleine schon um Kostenvorteile zu erwirtschaften. In AWS steht auch das notwendige Werkzeugset zur Verfügung um dieses schnell und transparent zu planen. Mit dem Einsatz des Schema Conversion Tools können die erwarteten Aufwände und Risiken schnell analysiert werden. Man springt so nicht ins kalte Wasser.

Durch die Replikationsmöglichkeit in AWS DMS besteht auch die Möglichkeit, eine Migration nicht ad hoc zu vollziehen, sondern über einen längeren Zeitraum um die neue Umgebung testen zu können. Dies bietet so die Möglichkeit auch DWHs und Datenbanken abzulösen die von einer umfangreichen Anzahl von Applikationen genutzt werden und deren ad hoc Umstellung auf eine neue Datenbanktechnologie nur mit hohem Aufwand bzw. Risiko verbunden ist.

Zudem erlaubt es diese eine einfache Skalierung von Datenbankservern (auch weltweit verteilt), Einrichtung hochverfügbarer Infrastrukturen sowie on-the-fly Sicherung auf räumlich verteilten Standorte.

E-Commerce goes Marketplaces – Amazon als wichtigen Kanal verstehen

Wer nicht mit der Zeit geht, der geht mit der Zeit. Dieses Sprichwort trifft auf viele, technologisch-getrieben Unternehmensbereiche zu und davon ist auch der Onlinehandel nicht ausgenommen. Der Umsatz verschiebt sich immer mehr in Richtung Marktplätze – bezogen auf den europäischen und amerikanischen Markt betrifft das im Wesentlichen Amazon und eBay. Betrachtet man nur den deutschen Markt, so kommt man als Onlinehändler an Amazon praktisch nicht mehr vorbei. Weit über 100 Millionen Produkte werden hier von circa 90.000 Händlern parallel zum Verkauf angeboten, welche sich wiederum in mehr als 30.000 Kategorien und Unterkategorien aufgliedern.

Das Sortiment auf Amazon umfasst mittlerweile beinahe jedes nur denkbare, physische Produkt – vom kleinen Radiergummi, über Nahrungsergänzungsmittel, die neuesten Mode- und Fashionartikel, Elektronik bis hin zu Waren des täglichen Bedarfs. Gepaart mit dem Prime-Service, der 1-Click-Bestellung und kundenfreundlichen Rücknahmebedingungen bleibt aus Käufersicht kaum ein Wunsch offen. Mit der Brille eines Verkäufers betrachtet, bieten sich zwar ebenso große Chancen und Möglichkeiten, aber auch Risiken, denn Amazon ist für viele Händler Fluch und Segen zu gleich.

Seit knapp zwei Jahren ist um das Thema „Amazon-SEO“ ein wahrer Hype in Deutschland entstanden. Die Tatsache, dass man seine Produkte auf Amazon ebenso einfach optimieren kann wie seine Website für die Google-Suchmaschine, bietet für findige Händler und clevere Optimierer ganz neue Möglichkeiten der Skalierung. Auf Google wie auf Amazon gilt der gleich Grundsatz: wer in den Suchergebnissen weit oben steht, bekommt den Traffic und steigert seine Umsätze. Letzteres gilt insbesondere für den Marktplatz, denn eine Studie aus 2016 hat gerade erst belegt: 55% der Nutzer starten ihre Produktrecherche nicht mehr auf Google, sondern direkt auf Amazon.

Während man als Onlinehändler mit seinem eigenen Webshop aufwendig und teilweise sehr kostspielig für genügend Traffic sorgen muss, bieten sich mit Amazon ganz andere, neue Möglichkeiten. Doch auch Risiken und Hürden gilt es auf dem Marktplatz zu meistern, denn viele Händler scheitern nicht selten an der Skalierung. Steigen die Sales, steigen auch die Herausforderungen. Gerade dann, wenn man seine Produkte aus Fernost anliefern lässt, gilt es viele Stolpersteine und Probleme bei der Einfuhr zu meistern.

merchantday 2017 – die E-Commerce-Konferenz für Amazon-Seller

Wie genau man die Hürden aus Händlersicht am besten nimmt und Probleme von Anfang an vermeidet, ist das zentrale Thema auf der Amazon-Konferenz merchantday in Hannover. Unser Senior Consultant Ronny Marx, Initiator und Moderater des Events, hat im Rahmen des 7P-Projekts „intomarkets“ zusammen mit einer Partneragentur in Hannover eine Fachkonferenz ins Leben gerufen, auf der sich dieses Jahr alles rund um das Thema „Verkaufen auf Amazon“ dreht. Ronny ist seit vielen Jahren im Bereich E-Commerce engagiert und in der Amazon-Szene gut vernetzt.

Top-Speaker der Branche berichten über Insides aus ihrem Leben als Onlinehändler und geben praktische Tipps, wie man sein Business auf Amazon in erfolgreiche Bahnen führt. Eines der zentralen Themen auf dem merchantday wird der Bereich „Import von Waren aus China“ sein. Eine erfahrene Rechtsanwältin erklärt dabei, wie man mit Markenrechtsverstößen in diesem speziellen Fall umgehen muss. Ein anderer Speaker, selbst seit vielen Jahren erfolgreicher Onlinehändler und Importeur von chinesischen Waren, hält einen spannenden Vortrag, worauf man beim Import aus Fernost achten muss.

Ein weiteres wichtiges Thema der Konferenz wird der Bereich „Brand-Building“ sein, denn nur etablierte Marken haben auf lange Sicht eine realistische Chance, sich auf dem Marktplatz zu etablieren. Hier sind gleich zwei Speaker zu dem Thema unterwegs und erklären, wie man eine Marke mithilfe von Amazon aufbaut und Social-Media-Fans zu zahlen Kunden konvertiert.
Wo es um Amazon-SEO geht, darf auch der Suchalgorithmus A9 nicht fehlen, um den sich viele Mythen und Märchen ranken. Einer der Top-Experten auf dem Gebiet wird genau erklären, was auf Amazon wirklich funktioniert, wie man die richtige Keywords für sein Produkt findet und mit welchen Tricks man schneller zu besseren Suchergebnisplatzierungen gelangt. Ein weiterer interessanter Vortrag geht anschließend auch auf die bezahlten Werbekampagnen ein, mit denen man ähnlich wie mit Google-Adwords, schnell und effektiv für eine Menge Traffic und Umsatz sorgen kann.

Sieben tolle Vorträge und ein cooles Networking-Event mit anschließender Aftershow-Party erwarten die circa 300 Teilnehmer am 09.06.2017 im Wiennecke Congress-Zentrum in Hannover. Im konkreten Themenumfeld „Amazon“ ist das von 7P initiierte Event eines der wenigen Veranstaltungen in Deutschland, die es derzeit für Onlinehändler gibt. Wir freuen uns auf spannende Vorträge und einen tollen Fachkongress in Hannover.

Container-Deployment auf AWS

Eines der fantastischen Phänomene, welche die zunehmend Cloud-zentrierte IT-Welt in jüngerer Zeit maßgeblich beeinflusst, sind zweifelsohne die Amazon Web Services (AWS). Natürlich beschäftigen auch wir bei 7P uns entsprechend eifrig mit der Thematik und unseren Kunden bleibt die Popularität der AWS nicht verborgen. So ist es wenig verwunderlich, dass der Begriff und die Möglichkeit eines Einsatzes in der Amazon Cloud bei praktisch jedem neuen Projekt fällt bzw. diskutiert wird. Höchste Zeit uns der Frage auch hier im Blog zu widmen.
Als erster Artikel zum Thema AWS auf diesem Blog, richtet sich dieser eher an Leser, die wenig bis keine Vorerfahrung haben. Weiterlesen

Viele, schnelle Daten: Data Lakes und Lambda-Architektur

In Zeiten allgemeiner Vernetzung und dem Wunsch, die anfallenden Daten in vielfältiger Art und Weise nutzen zu können, besteht die Herausforderung, die Daten in einer modernen Umgebung zu sammeln und wieder bereitzustellen. Wie? Möglichst in einer flexiblen und skalierbaren Umgebung, denn die Anforderungen steigen in der Regel mit der Datenmenge. Und hier gilt: Sie kann sehr schnell wachsen und im Petabyte Bereich liegen. Daten haben dabei alle möglichen Formate und auch die zeitlichen Anforderungen nach Speicherung und dem Bereitstellen der Daten rangiert von klassischer Batchverarbeitung bis hin zu Echtzeitszenarien. Technisch werden solche Anforderungen oftmals mit Hadoop-basierten Data Lakes und einer darin integrierten Lambda-Architektur gelöst.

Schnelle und langsame Daten: Lambda-Architektur

Eine Lambda-Architektur ist eine Architektur zur Massenverarbeitung von Daten, deren Kern meist eine Datenhaltung in einem organisiertem Data Lake ist. Sie ist in der Lage, eine Echtzeitverarbeitung zu ermöglichen und bringt Durchsatz und Latenz der Daten in ein sinnvolles, den jeweiligen Anwendungsfällen angepasstes Verhältnis. Aufgebaut wird auf folgenden Ideen:

  • Daten werden fortgeschrieben
  • Veränderungen werden zu neuen Datensätzen. Diese haben zum Zeitpunkt der Veränderung Gültigkeit, die alten Daten verbleiben jedoch im Data Lake, was eine Historie über die Daten ermöglicht
  • Informationen ergeben sich aus den Aggregationen über die Daten im Data Lake
  • Es gibt eine Zugriffsschicht, die eine konsolidierte Sicht auf die Daten ermöglicht

Um zum Ziel zu kommen, wird technisch ein sogenannter Batch Layer für die Daten geringerer Geschwindigkeit und ein Speed Layer für die Daten höherer Geschwindigkeit aufgebaut. Bei letzterem führt in der Regel eine Kombination aus Messaging und Streaming in Verbindung mit einer schnellen NoSQL Datenbank zum Ziel. Typische Komponenten aus dem Hadoop Ökosystem sind hierbei Apache Storm, Kafka und Spark Streaming.

Eine Zugriffschicht dient dazu, die Daten in einer sinnvollen Art und Weise zusammenzuführen, gemeinsam auswertbar zu machen und den Konsumenten zur Verfügung zu stellen. Hier wird oftmals auch ein Zugriff über SQL ermöglicht, was wiederum den Einsatz von Hive und weiterer geeigneter SQL-on-Hadoop Varianten voraussetzt. Es ist auch die Stelle, an der ein geeignetes Governance Konzept zum Tragen kommen muss, was in natürlicher Weise zum Begriff des Data Lakes überleitet.

Organisation von Daten: Data Lake

Data Lakes sind eine moderne, einfach zu betreibende, hoch skalierbare und flexible Systeme für die Speicherung, Verarbeitung und Bereitstellung aller Arten von Daten. Sie bedienen in der Regel eine weite Bandbreite an analytischen Anwendungsfällen. Kernaufgabe des Data Lakes ist hierbei, die Daten aufzunehmen, sinnvoll abzulegen und wieder in einer geordneten Art und Weise zur Verfügung zu stellen. Da Hadoop-basierte Systeme (fast) linear und horizontal skalieren, kommen in der Regel auch Technologien aus dem Hadoop Umfeld ins Spiel,  da sie flexible und einfach skalierbare Umgebungen ermöglichen können.

Bei dem Aufbau von Data Lakes ist es besonders wichtig, auf eine sinnvolle und einfach gehaltene Organisation zu achten. Die Daten sollen ja „im See“ nicht untertauchen und verloren gehen. Ein organisierter Data Lake, auch Data Reservoir genannt, kann das gewährleisten. Hier werden typischerweise klare Prozesse und Regeln unter dem  Stichwort Sicherheit und Governance geschaffen. Genauso dient ein logisches Schichten- und Speicherkonzept, welches die Schichten der Lambda-Architektur reflektiert, dem Data Lake zu dem gewünschten Grad an Organisation und Transparenz.

Das Konzept eines Data Lakes überschneidet sich hier natürlich mit der Idee einer Lambda-Architektur. Im Grunde beleuchten beide ja auch nur verschiedene Aspekte einer Sache: Der Data Lake betrachtet das Ganze aus organisatorischer Sicht, die Lambda-Architektur aus der Sicht der unterschiedlichen Geschwindigkeitsanforderungen an die Daten.

Fazit

Wenn ich nun als Unternehmen die Anforderung habe, alle Daten, die in den Vertriebsprozessen meines Unternehmens anfallen, insbesondere auch die Interaktionen mit meinen Kunden über alle Kanäle hinweg zu sammeln und zu verarbeiten, bietet sich eine Umsetzung mit Hilfe von Data Lakes und einer Lambda-Architektur wie oben beschrieben förmlich an. Das gilt auch für die Echtzeitverarbeitung, die für Recommendation Engines besonders wichtig ist.

Der Aufbau von flexiblen und hoch skalierbaren Systemen, die in Lage sind, Daten in allen gewünschten Geschwindigkeiten aufzunehmen und bereitzustellen ist eben mit Lambda-Architekturen, die einen organisierten Data Lake zugrunde liegen haben, sinnvoll zu bewerkstelligen und wird in der Regel auch so umgesetzt. Data Lakes bedienen dabei den organisatorischen Aspekt einer sinnvollen Speicherung und Bereitstellung aller Arten von Daten, die Lambda Architektur ermöglicht es, „langsame“ Daten (Batch) und Echtzeitdaten zu verarbeiten und letztlich in der gewünschte Geschwindigkeit zur Verfügung zu stellen. Die Kombination beider Konzepte führt hierbei zum Erfolg.