Im Ideenreich des Professor Kohls

Vor kurzem hatten Arne Christmann und ich erneut die Gelegenheit, einen der drei Innovationsräume auf dem Campus der TH Köln in Gummersbach zu besuchen, das “ideenreich” von Professor Kohls.

So sieht es dort aus:
 IMG_8952.jpg
IMG_8953.jpg

Wir hatten uns zwei Ziele gesetzt:

Primär wollten wir den Raum besser verstehen, um ihn im Rahmen von Workshops nutzen zu können, sowohl extern als auch intern.

Da das so allein sehr trocken geworden wäre, haben wir uns als Sekundärziel eine konkrete Frage gestellt, die wir dort erörtern wollten: “Wie schaffen wir Arbeitsorte, die Mitarbeiter maximal motivieren?” Oder alternativ “… mininimal demotivieren?”, da wir ja alle wissen, dass die beste Motivation, die intrinsische ist 😉

Für diejenigen die das ideenreich methodisch einsortieren wollen, hier ein Mapping auf zwei bekannte Designprozesse:

design thinking.png

Im “Design Thinking” ist es für die ersten drei Phasen geeignet, “EMPATHIZE” bis “IDEATE”.

BDC double diamond.png

Im “BDC Double Diamond” ist es​ für die ersten drei Phasen geeignet, “Discover” bis “Develop”.

Um aus der Fülle der Werkzeuge auszuwählen, setzten wir uns eine Timebox von 15 Minuten, in der jeder seine Favoriten für die Aufgabenstellung suchte. Anschließend stellten wir sie uns gegenseitig vor. Hier sehen Sie unsere Auswahl:

IMG_8596.jpg

Daraus wählten wir gemeinsam zwei aus: Das “Design Studio Pro” (von den Machern der bekannten “Story Cubes”), um dem Prozess einen Rahmen zu geben und für zusätzliche Impulse, da es um Orte ging, das “MethodKit – Cities”.

IMG_8591.jpg

Notwendig für Lösungen mit Menschen im Mittelpunkt ist Empathie. Eine klassische Methode für Empathie sind Personas. Das Design Studio Pro geht hier einen interessanten Weg und gibt völlig überzeichnete fiktive Personas vor, die “Extraordinaires”.

Da Zufall und die durch ihn erreichten neuen Verknüpfungen fantastische Mittel für Kreativität sind zogen wir blind drei Personas: “Knight”, “Future Child” und “Time Traveller”. Auf der Vorderseite jeder Karte befindet sich ein großes Bild des jeweiligen Extraordinaires, auf der Rückseite ist er oder sie in typischen Lebenssituationen zu sehen.

Die Extraordinaires auf unseren Problemraum einer “fiktiven IT-Unternehmensberatung mit Zentrale im Oberbergischen” anzuwenden, verlangte ein Mapping auf reale Mitarbeitergruppen:

  • Den “Knight” hielten wir eindeutig für einen Repräsentanten der “Projekt-Pendler”. Regelmäßig “schärft er sein Schwert” mittels Software Craftsmanship und “kämpft gemeinsam mit anderen gegen den Drachen” Komplexität (beides Bilder von der Rückseite der Karte).

    IMG_8587.jpg

  • Das “Future Child” deuteten wir als unseren Nachwuchs: Studenten sowie alle anderen die “noch nicht bei uns arbeiten”. Im vulkanischen Gruß, der in der Zeichnung zu sehen ist, sahen wir die “Logik der reinen Lehre”, die sie mitbringen, z. B. von der Uni. Kritisch ist dabei immer wieder der Konflikt mit Autoritäten um die Deutungshoheit.

    IMG_8588.jpg

  • Die “Time Traveller” interpretierten wir als “Leute die an/in der Zukunft arbeiten”, also BDI und andere Visionäre im Unternehmen. Aus verschiedenen Zeiten und von verschiedenen Orten bringen sie “Trophäen” mit, wichtig für ihr Wohlbefinden ist ein jeweils “passendes Outfit”, das Schneider sicherstellen und eine gut ausgestattete “Werkstatt” (alles Bilder von der Rückseite).

    IMG_8589.jpg

Mit diesem Verständnis und immer wieder zwischen der Metapher der fiktiven Welt und unserer realen hin und her springend folgten wir zunächst weiter dem Prozess des Design Studio Pro und zogen für jede Persona eine “Design Challenge”:

  • Der Ritter brauchte einen “Place for Ceremony”, was wir als Ort, um Projekterfolge zu feiern und sich auszutauschen, interpretierten. Dieser sollte dicht am Geschehen sein, damit die Zeremonie zeitnah stattfinden kann.

  • Das Kind der Zukunft brauchte “something for carrying things”. Das haben wir im Kontext als Community verstanden, die die Person im Sinne von Aus-/Weiterbildung und Karriere “trägt”.

  • Die Zeitreisende verlangte es nach “somewhere to sit”. Das deuteten wir als “Heimat”: eine Komfortzone, wo Trophäen ausgestellt werden und das Bedürfnis nach Selbst-Transzendenz befriedigt wird.

Der nächste Schritt im Prozess des Design Studio Pro ist “improve” mit zwei zufälligen Karten pro Extraordinaire und Design Challenge:

  • Für den Zeremonien-Ort des Projekt-Ritters waren die Hinweise “Sustainability” und “Decoration”. Für die Umweltfreundlichkeit notierten wir uns, dass der Ort Bio-Produkte verwenden und auch anderweitig benutzt werden sowie sozial-integrativ sein sollte. Für die Dekoration fielen uns Personalisierung für IT und Konsistenz ein.

  • Für die Community des Zukunft-Kindes zogen wir “Adaptability” sowie “Integration”. Dazu schrieben wir Toofreiheit mit BYOD/S, externe Visibilität, Themenfreiheit und Gamification auf.

  • Für die Heimat der Zeitreisenden zogen wir “Exaggeration” und “Automation”. Dazu fielen uns der Koffer als mobile Werkstatt und Smart Home ein.

Wir kamen zu drei Ergebnissen, einem pro Persona:

  • Der Ritter braucht einen Ort, um zusammen mit Kollegen aber auch mit Kunden-Mitarbeitern (z. B. den “Einwohnern Thyssenhausens”) zu feiern. Der letzte Schritt im Design Studio Pro ist, dem Ergebnis einen Namen zu geben. Diesen Ort nannten wir “Taverne”.

  • Das Kind der Zukunft braucht eine Community für die Weitergabe von Wissen mit Vertrauen als Basis. Die Hierarchie dort sollte ausschließlich auf Kompetenz beruhen, die Organisation sollte ortsungebunden und asynchron sein. Diesen Ort nannten wir “Starfleet Academy”

  • Die Zeitreisende braucht als Ruhepol und Ausgleich eine Heimat. Diese nannten wir “Secret Lair”.

Natürlich gibt es eine Menge Synergie-Effekte zwischen den drei Orten. Die “Taverne” kann z. B Teil des Netzwerks der “Starfleet Academy” sein, wo wiederum die Time Traveller lehren. Das “Secret Lair” der Time Traveller dient mit seinen Trophäen allen als Inspiration.

Das wurde noch klarer als wir aus dem “Method Kit – Cities” drei Karten als zusätzlichen Input für unsere Arbeitsorte zogen und passend platzierten:

  • “Research & Innovation”

  • “Local Knowledge”

  • “Networks”

Hier sehen Sie das fertige Gedankenmodell:

IMG_8595.jpg

Zusammenfassend war die Arbeit im ideenreich fantastisch. An einer Menge Stellen erkennt man Prof. Kohls Liebe zum Detail:

  • Die Mechanik zur Einstellung der Arbeitshöhe des riesigen Tischs in der Mitte scheint 1:1 aus der Metall-Industrie zu stammen, die Platte ist aus dickem, naturbelassenem Holz, welches man gerne anfasst.

  • Überhaupt der Tisch: Man könnte denken, dass kein großer Unterschied zwischen Post-Its auf einer vertikalen Wand und einer horizontalen Oberfläche besteht. Es ist aber hilfreich, um das gemeinsame Gedankenmodell herumlaufen und es aus verschiedenen Perspektiven betrachten zu können. Ebenso können 3D-Objekte oder Materialien die man weder kleben noch pinnen will benutzt und platziert werden.

  • Die gigantische Menge an Werkzeugen ist über Jahre zusammengestellt und wird stetig erweitert. Prof. Kohls ganzes Netzwerk sucht dabei eifrig mit: In einer Kartenspiel-Box fanden wir etwa einen Geburtags-Glückwunsch.

Natürlich könnten wir sehr stolz sein, falls OC-eigene Materialien wie Storytelling-Box oder Glaubenssatz-Kartenspiel mit in die Sammlung aufgenommen würden.

Dieses irgendwann zwischendurch entstandene Lego-Objekt schliesst den Kreis zwischen Fragestellung und Ergebnis:

IMG_8593.jpg

Wie schaffe ich Arbeitsorte die Mitarbeiter maximal motivieren? Mit Räumen, real oder virtuell, wo man schon mit Freude die Tür öffnet, weil überall die Liebe zum Detail spürbar ist. Wie z. B. im ideenreich 😎

Falls Sie jetzt Lust bekommen haben, auch das ideenreich zu besuchen: Hervorragend 😀
Sehr gerne stehen Arne Christmann (arne.christmann@opitz-consulting.com) oder ich (karsten.will@opitz-consulting.com) für die Buchung halb- oder ganztägiger Workshops und als Moderatoren zur Verfügung.

Karsten Will

 

Veröffentlicht unter Uncategorized | 1 Kommentar

Sequences and Flow Control in Oracle Data Integrator

Most developers that start working with Oracle Data Integrator (ODI) and create their first mappings will stumble upon an error message like this pretty early in their ODI career:

ODI Sequences Error Message

In this blog post, I will first recreate this error with ODI 12.2.1.2.6 and then show what you can do about it. For understanding this post, you should have some basic ODI knowledge (what mappings are, that they have a logical and a physical design, and that you can use different knowledge modules in the latter).

The Problem

In my example, I get files with revenue data from cinemas and load them into an Oracle database table. To make sure that I don’t get in any trouble when a cinema shows the same film more at the same time more than once (maybe everybody wants to see the new Star Wars film), I add an aggregator between source datastore (the file) and target datastore (the database table):

ODI Sequences Logical Design

For the target datastore, I chose the knowledge module IKM Oracle Incremental Update (MERGE) that uses an intermediate table (what ODI calls I$ table) and allows for Flow Control (validating the loaded data). Apart from that, I didn’t do any other changes in datastore properties or physical design.

When I run this mapping as it is, I can see in the Operator tab of ODI Studio that it fails:

ODI Sequences Execution with Error

When I open the task where the error happened, I see the aforementioned error message:

ODI Sequences Error Message

When I look at the target code, I find the reason for this error:

ODI Sequences Error Cause

The mapping selects the next sequence value for the primary key column of my target datastore in the same SELECT statement where I group by the source attributes. Unfortunately for me, Oracle database doesn’t accept that.

How can I deal with this problem? There is a relatively obvious and a not-so-obvious way. First, let’s talk about the relatively obvious one.

The Relatively Obvious Solution

I open the mapping again and click on the primary key attribute of the target datastore (the one where you select the next sequence value). As Execute on Hint, I select “Target”.

ODI Sequences Execute on Target

When I run the mapping again, I don’t get the error anymore but I still get a warning:

ODI Sequences Execution with Warning

When I look at the session details, I see the reason for this warning: The mapping completed its run but two erroneous records were found during flow control (in task 260 when looking for potential not null constraint violations, to be precise):

ODI Sequences Warning Message

The mapping has put these records into an error table (ODI calls them E$ table) that I can query using ODI Studio or the database development tool of my choice:

ODI Sequences Error Records

That way, I can understand what happened: I didn’t insert any values for the primary key column into my I$ table but I still checked if this column was null (which it was since I didn’t insert any values). This means I have to go back to the datastore properties.

For the primary key attribute of the target datastore, I have to un-check the box that says Check Not Null (Flow Control only):

ODI Sequences Check Not Null

When I run the mapping again after this change, it finishes without any errors or warnings.

ODI Sequences Execution Successful

That was the first, relatively obvious way of dealing with our ODI sequence error. The second, not-so-obvious way is changing the knowledge module I use in the mapping.

The Not-So-Obvious Solution

In the Global Objects section of ODI Studio’s Designer tab, I duplicate the knowledge module IKM Oracle Incremental Update (MERGE) and give it a new name like IKM Oracle Incremental Update (Sequence).

ODI Sequences IKM Duplicate

In the new knowledge module, I have to change two tasks: the one called Insert flow into I$ table where data is written into the intermediate table and the one called Merge Rows where I update the target datastore.

In the Insert flow into I$ table task, I have to make sure that I don’t insert any values for the primary key column (the one that is populated by the sequence). I achieve this by adding “and !PK” both to the column lists of the I$ table itself and the SELECT statement that is used to fill it:

ODI Sequences IKM Change Integration Table

The meaning of selectors like “TRG” and “PK” can be found in the ODI Substitution API Reference that is a valuable resource when working with knowledge modules.

In the Merge Rows task of my new knowledge module, I make a similar change so that the mapping won’t load the values for the primary key column from the intermediate table anymore:

ODI Sequences IKM Change Target Table

Sometimes it’s good to remember your Boolean logic: the negation of “and !PK” is, of course, “or PK”.

What have I achieved with these knowledge module modifications? Thanks to them, I won’t have to worry about the correct Execute on Hint settings anymore:

ODI Sequences No Execute on Hint

I just have to make sure that in the physical design of my mapping, the new knowledge module is set for the target datastore:

ODI Sequences New IKM

If I always fill my primary key columns with a sequence, I can even set this knowledge module as default so that all future mappings will use it:

ODI Sequences IKM Default for this Pair

When I run the mapping with the new knowlege module, it finishes without any errors or warnings:

ODI Sequences Execution Successful with New IKM

When I look into the generated code for the Insert flow into I$ table task, I see the difference the knowledge module changes made:

ODI Sequences Target Code with New IKM

As expected, the I$ table ignores the primary key column and everything works fine. That was the second, not-so-obvious way of dealing with our ODI sequence error.

Lessons Learned

Is there a lesson to learn from this? I think there are at least two:

  1. Almost always, there are multiple ways to solve an ODI problem.
  2. If the way you found doesn’t include fiddling around with knowledge modules, maybe it should.

 

Veröffentlicht unter Analytics & BigData | Verschlagwortet mit , | Kommentar hinterlassen

ChatbotConf 2017: Chatbots, Startups und Walzer

Mit dem rechten Fuß nach vorne. Der linke Fuß wandert schräg nach links. Und der rechte zieht hinterher. Ich bin in Wien und tanze Walzer. Passt ja irgendwie. Aber war ich nicht auf der ChatbotConf 2017? Stimmt… Ich starte wohl besser von vorne. Weiterlesen

Veröffentlicht unter News | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Autonomous databases, Blockchains and Cloud-native architectures – an OOW 17 recap

Oracle Open World (OOW) 2017 just ended on thursday last week. As usual, it was a great and inspiring conference, which nevertheless felt slightly different than the years before.

Why does it felt different?

A different spirit seemed noticeable, because Oracle starts to put more focus on the developer community – more power to the developers! For the first time, an Oracle Code track took place as part of Java One. Oracle Code was established between last years OOW and this years conference and was run at several locations all over the world. This promising new format explicitly addresses developers, so the tracks are more technical and are not necessarily focusing Oracle products and technologies, but are also covering Open Source technologies, like Kafka, etc.

With respect to Open Source it is also interesting to see that Oracle integrates, uses and thrives respective technologies in their platform services, which will be discussed in the following.

News and worth mentioning

Autonomous Database

One of the most polarizing announcements was a new version of Oracle flagship, the database Oracle 18c. This version implements a new and revolutionary concept, of a self-driving autonomous database, which needs less human interactions; typical DBA tasks like patch, tune, back up, and upgrade are done by the database autonomously.

„This is a big deal, by the way. No one else does this. This is the most important thing we’ve done in a long, long time.” (Larry Ellison, Oracle Executive Chairman and CTO)

The autonomy of the database is achieved by leveraging Machine Learning (ML) algorithms. A very exciting and outstanding development, which will of course changes the role of DBAs in the future. But DBAs will not become superfluous; they need to rethink their roles.

Container native app development of the future

Oracle announced their new development platform for Cloud-native applications, which consists of

  • Container Pipelines, a.k.a. as Wercker for managing container builds and deployments,
  • Container Registry Service, implemented as a full Docker v2 comptabile private registry
  • Container Engine, which is a Fully-managed Kubernetes Service; This service was announced to be available soon.

I addition, a new Serverless platform based on Fn (http://fnproject.io), which is a Open Source container native serverless platform, was announced. The main advantage of this approach is that serverless functions can be developed and tested locally before deploying it to a runtime. The target runtime the so defined Serverless functions is the Managed Kubernetes Service (Container Engine), which is capable to execute Containers and Serverless functions.

Blockchain – the next big thing in IT

A topic, which was impressively present at this years OOW was Blockchain. The corresponding sessions were always completely packed. The sessions where covering different aspects beginning with an introduction, what Blockchain is and how it can be implemented. Furthermore it was shown, how Oracle will approach the topic with a new fully-managed Blockchain Cloud Service. This upcoming service is based on Hyperledger, which is hosted by the Linux Foundation, where Oracle recently joined.

„Blockchain hold the promise to fundamentally transform how business is done, making business-to-business interactions more secure, transparent, and efficient.“ (Amit Zavery, Senior Vice President Oracle Cloud Platform)

So, let’s stay tuned for more and see, if Blockchain becomes significantly game changing as discussed nowadays.

Simplified Cloud adoption through improved subscription model

In the past, Oracle’s subscription model was not flexible enough, since customers need to specify what kind of Cloud Services are needed. Now, Oracle introduces so called Universal credits, which makes life easier. Customers, buy credits and have access to all IaaS and PaaS offerings. More flexibility at lower costs that is the key promise – sounds great!

In addition, a new Bring your own licence (BYOL) model has been introduced which allows customers to use existing on premise licenses for respective Cloud Services. Another interesting offering to existing on premise licenses, to get started with Cloud.

Further interesting facts

Besides the aforementioned points, it was also noticeable that the Oracle Cloud offerings become more and more integrated. In the near future Cloud Services will be grouped in reasonable packages. Examples for that are:

  • Oracle Mobile Cloud enterprise (OMCe)
    • Mobile Cloud Service
    • Intelligent Bots
    • Customer Experience Analytics
  • Oracle Integration Cloud (OIC)
    • Integration Cloud Service (ICS)
    • Process Cloud Service (PCS)
    • Visual Cloud Builder Service (VBCS)
    • Analytics
  • Deeper integration of Oracle API Platform Cloud Service and Apiary to allow a full API Management

Further relevant topics, which were dominating the conference were:

  • Machine Learning and Artifical intelligence (Oracle Analytics Cloud)
  • Chatbots (Oracle Intelligent Bots Service)
  • API Management

Summary

As it can be seen from this article, there was again tons of new information, which can be taken home from the conference. It again showed the relevance of OOW for daily business, because learning about newest products, roadmaps and concepts is essential. It is important to sharpen the view on diverse topics and how the way, to position Oracle’s portfolio at customers can be improved and how those can add significant value by implementing Oracle Cloud solutions.

 

 

Veröffentlicht unter Cloud & Infrastructure, News, Strategy & Methods | Verschlagwortet mit , , , , , , | Kommentar hinterlassen

Reduzierte Big Data Kosten mit AWS Spot Instanzen

Wer sich heutzutage mit Big Data Themen kombiniert mit Amazon Web Services (AWS) beschäftigt, benötigt in der Regel schon ein eigenes kleines Wörterbuch für die ganzen Abkürzungen und Toolnamen aus beiden Welten. Ein weiteres Thema ist die eigene Problemstellung in dieser neuen Welt zu implementieren. Das sich dieser Weg durchaus auf verschiedenen Ebenen lohnt, möchte ich in diesem Blogartikel aufzeigen.

Was ist AWS EMR

Amazon bietet eine eigene Big Data Distribution an. Diese hat neben dem Resourcen Manager (Yarn), einem Hadoop File System und Spark noch einige andere Tools wie Sqoop, Oozie und Zeppelin.

Durch den Elastic Map Reduce (EMR) Dienst wird ein Big Data Cluster komplett erzeugt, inklusive ausgewählter Hardware und Software. Wenn das entsprechende „Create Cluster“ Kommando verwendet wird dauert es ca. 7 Minuten bis der neue Cluster Einsatzbereit ist und alle Instanzen den Status „running“ haben.

Der Cluster kann beispielsweise über die AWS Console (AWS Webseite) konfiguriert werden oder über das AWS Kommandozeilentool. Das zuletzt genannte Tool stellt eine spannende Option für Automatisierungen dar.

AWS EMR kostet ein einen kleinen Betrag extra zu den anfallenden Kosten für die Instanzen.

In diesem Beispiel werden m4.large Instanz Typen in der Region EU(Frankfurt) verwendet.

Diese kosten in diesem Moment 0,12 US Dollar pro Instanz und Stunde. Der EMR Aufschlag beträgt 0,03 US Dollar pro Stunde und Instanz. Dies ist exklusive der Mehrwertsteuer. Es gibt zwar noch Transfer und Storage Gebühren und vieles mehr, aber die genannten Kosten und die Mehrwertsteuer stellen den absolut größten Teil der Kosten dar und können für eine grobe Kosteneinschätzung verwendet werden. Weitere Informationen hierzu können direkt auf der AWS Pricing Webseite nachgelesen werden.

Aufgerundet exklusive Mehrwertsteuer kostet jede Instanz pro Stunde 0,15 US Dollar.

 

Spot Instanzen

AWS bietet Spot Instanzen an. Die Idee ist, dass Kunden statt einem fixen Preis, wie bei den bisher hier verwendeten On-Demand Instanzen (m4.large 0,12 US Dollar pro Instanz pro Stunde), wie bei einer Auktion ein Gebot für die Nutzung der Instanzen abgeben. Dies kann dazu führen, dass Instanzen 90% unter dem On-Demand Preis zur Verfügung gestellt werden können. Daraus können bei richtiger Nutzung großartige Mehrwerte gezogen werden. Es muss nur definiert werden, was das Ziel sein soll. Eines könnte die Reduzierung der Kosten sein.

Änderung der Abrechnungseinheiten von Stunden auf Sekunden

Eine aktuelle Änderung in der Preisgestaltung von AWS ist die Umstellung der Abrechnungsintervalle zum 02.10.2017. Bisher wurden alle Instanzen Stundenweise abgerechnet, wenn eine Verarbeitung 125 Minuten dauert, dann wurden 3 Stunden für jede Instanz im Cluster berechnet. Dies wird jetzt auf sekundengenaue Abrechnung umgestellt. Nachlesen können sie die Details bei AWS direkt new-per-second-billing-for-ec2-instances-and-ebs-volumes.

Es gibt eine Mindestabnahmezeit pro Instanz von 60 Sekunden, danach wird sekundengenau abgerechnet. In unserem Beispiel (125 Minuten Verarbeitung) alte Berechnung:

Prei pro Instanz pro Stunde: 0,12 $ (Instanz) + 0,03 $ (EMR) (Steuern entfallen als Vereinfachung)

Preis in $ Instanzen Stunden Gesamtsumme in $  %
Alte Berechnung 0,15 3 3,00 1,35 100,00
Neue Berechnung 0,15 3 2,08 0,94 69,43

Natürlich ist beim Beispiel mit 125 Minuten der Effekt fast maximal. In diesem Beispiel wurden über 30% Kosten eingespart, durch die Veränderung der Abrechnungseinheiten

Was für Gruppen gibt es im EMR: Master, Core, Task

Das AWS EMR bietet durch die verwendete Hadoop Technologie basierend auf dem Hadoop File System (HDFS) und dem Resourcen Manager (YARN) eine perfekte Umgebung, um AWS Spot Instanzen zu verwenden.

Sowohl Instanzen aus der Master Gruppe, wie auch aus der Core Gruppe, sollten nicht mit Spot Instanzen verwendet werden. In der Master Gruppe laufen in der Regel die Master Prozesse von Anwendungen, also zum Beispiel der HDFS NameNode oder den Applications Manager, welcher einen Teil des Yarn Resource Manager ist. An dieser Stelle müssen On-Demand Instanzen verwendet werden, da die Instanzen nicht wegfallen dürfen.

Auch in der Core Gruppe sollten keine Instanzen wegfallen. In dieser Gruppe liegen die DataNodes des HDFS. Wenn von diesen DataNodes zu viele wegfallen, kann es trotz impliziter Replikation zu Datenverlusten kommen.

Die Task Gruppe und ihre Instanzen sind optional und haben weder NameNode noch DataNode Prozesse. Es werden hier also keine HDFS Daten persistiert sondern lediglich Resourcen für die Verarbeitung zur Verfügung gestellt. Aus HDFS Sicht sind die Task Nodes also nicht existent, für Yarn stellen sie jedoch zusätzliche Verarbeitungs-Resourcen zur Verfügung.

Dies hat zur Folge, dass vorhandene Task Instanzen die Verarbeitung beschleunigen. Sollten diese Instanzen mitten in der Verarbeitung nicht mehr verfügbar sein, wie es bei Spot Instanzen der Fall sein kann, ist dies kein Problem. Der Resourcen Manager stellt fest, dass Verarbeitungs-Resourcen weggefallen sind und verteilt deren Aufgaben an andere Instanzen die verfügbar sind und Kapazitäten frei haben. Dies kann sich nur auf die Laufzeit nicht aber auf den Erfolg der Verarbeitung auswirken.

Beispielsetup mit einer Task Gruppe die aus Spot Instanzen besteht

Dies ergibt spannende Möglichkeiten. Wenn die Verarbeitung mit einer Master und 8 Core On-Demand Instanzen durchgeführt wird und 125 Minuten dauert, berechnen wir die EC2 und EMR Kosten für diese Verarbeitung. Wenn weitere 8 Task Spot Instanzen hinzukommen reduziert sich die Laufzeit auf 65% von 125 Minuten (2,08 Stunden) ergibt 81,25 Minuten (1,35 Stunden) Laufzeit.

Der Preis pro Instanz pro Stunde für On-Demand setzt sich zusammen aus (0,12 $ Instanz, 0,03 $ EMR).

Der Preis pro Stunde für Spot Instanzen setzt sich zusammen aus (0,03 $ Instanz und 0,03 $ EMR).

Preis in $ Instanzen Stunden Gesamtsumme in $  %
1 Master 8 Core 0,15 9 2,08 2,81 100,00
1 Master 8 Core 0,15 9 1,35 1,82
8 Task 0,06 8 1,35 0,65
Summe neu 2,47 87,98

 

Durch das Hinzufügen von 8 Spot Instanzen als EMR Task Gruppe wurde die Laufzeit der Verarbeitung um 35% reduziert und das zu etwa 12,02% reduzierten Kosten.

Im Positivfall wurde sowohl Geld gespart als auch eine deutlich kürzere Verarbeitungszeit benötigt. Der Negativfall, wir bekommen die Spotinstanzen nicht zu dem gewünschten Preis, bedeutet 100% Laufzeit und 100% Kosten wir haben also den Status Quo.

Dies stellt nur ein einfaches Beispiel dar, was mit etwas Kreativität möglich ist. Natürlich skalieren verschiedene Daten und Programme unterschiedliche und der geneigte Leser muss eigene Tests durchführen, welches Setup das Passende ist. Dabei sind nicht nur Kostenoptimierungen, sondern auch Laufzeitoptimierungen als Ziel möglich. Wie verschiedene Instanz Typen (M4.Large in diesem Beispiel) zu der eigenen Verarbeitung passen wurde ebenfalls komplett ausgeblendet. Auch hier bietet sich noch einiges an Optimierungspotential.

 

Veröffentlicht unter Analytics & BigData, Cloud & Infrastructure | Kommentar hinterlassen

IT|espresso – 10 unterschätzte Kriterien für eine Mobile Strategie

Nativ, Web, Hybrid oder Cross Compiled? Im Rahmen unserer zahlreichen Beratungskontexte haben wir bisher 48 Kriterien für die Auswahl der richtigen Mobile-Strategie ausgemacht. 10 davon die häufig unterschätzt bzw. sogar komplett vergessen werden, wollen wir Ihnen im Rahmen als Impulsvortrag auf unserem IT|espresso  vorstellen. Danach freuen wir uns, Sie zu einem hervorragenden Stück Kuchen einzuladen und lebhaft mit Ihnen über das Thema zu diskutieren.

Ihre Anmeldung können Sie unter folgenden Link durchführen: Anmeldung.

Für mehr Informationen zu den Angeboten von Opitz Consulting zum Thema Mobile kontaktieren Sie gerne Karsten Will (karsten.will@opitz-consulting.com) oder Philipp Leinius (philipp.leinius@opitz-consulting.com).

Wir freuen uns auf Ihre Teilnahme!

Quellen & Weiterführende Informationen:

https://thecattlecrew.net/2017/07/07/mobile-team-as-a-service/

https://thecattlecrew.net/2017/07/27/managed-services-engagement-modelle/

Veröffentlicht unter Frontend Development, Managed Services, Software Engineering | Kommentar hinterlassen

Apache Kafka – im Detail (Teil 2)

Schaut man sich Kafka im Detail an, wird der Aufbau schnell komplex. Dort gibt es dann Broker, Partitionen, Replica, Leader, Follower und die aus Teil 1 schon bekannten Topics. Aber der Reihe nach: Kafka selbst läuft auf sogenannten Brokern, oft auch Nodes genannt, wobei ein Broker im Prinzip ein Kafka Server ist. Ab zwei oder mehr Brokern spricht man auch von einem Broker Cluster bzw. Kafka Cluster.

Kafka Cluster

Im Prinzip speichern die Broker die Nachrichten oder Daten einfach nur, sodass die Consumer sich diese dann abholen können. Diese Daten werden dazu in Topics unterteilt, sodass nicht jeder Consumer jede Nachricht bedenken muss. Der Producer bestimmt dabei, welche Nachricht in welchem Topic landet. Die Topics müssen dafür vorher manuell erstellt werden.

Kafka Aufbau - Page 1

Abbildung 1 – Darstellung eines Kafka Clusters

Interessant wird es, wenn man betrachtet wie die Broker die Nachrichten speichern. Dazu werden die Topics in Partitionen unterteilt. Die gespeicherten Nachrichten in jeder Partition sind nach zeitlichem Eingang sortiert und diese Reihenfolge ist unveränderbar. Die zeitliche Reihenfolge der Nachrichten ist dabei nur per Partition, nicht aber pro Topic sichergestellt. Es sei denn ein Topic hat nur eine Partition. Zur Identifizierung bekommt jede Nachricht eine eindeutige ID, das sogenannte Offset. Dadurch können Consumer ganz gezielt bestimmte Nachrichten abfragen. (siehe Abbildung 2)

Kafka speichert alle Nachrichten über einen einstellbaren Zeitraum und da es eine konstante Skalierung in Bezug zur Datenmenge aufweist, ist auch das Speichern großer Datenmengen über einen längeren Zeitraum kein Problem, zumindest nicht für Kafka.

topicKafka

Abbildung 2 – Darstellung eines Topics (kafka.apache.org/documentation/)

Ein großer Vorteil der Partitionen ist es, dass die Datenmenge eines Topics größer werden kann als die Speicherkapazität des Brokers. Dies ist in Abbildung 1 in Topic 1 veranschaulicht.

Ausfallsicherheit

Um die Ausfallsicherheit zu gewährleisten, können von den Topics bzw. von den Partitionen Kopien, sogenannte Replicas, erstellt werden. Das ergibt natürlich nur Sinn, wenn es mindestens so viele Broker wie Replicas gibt. Unter allen Brokern, die Kopien einer Replica haben,  wird mit Hilfe von Zookeeper bestimmt, wer der Leader wird. Da in Zookeeper die Informationen über den Aufbau des Clusters gespeichert werden. Der Leader bekommt die Nachrichten von den Producern und wird von den Consumern angefragt, wenn sie Nachrichten haben wollen. Außerdem sorgt er dafür, dass die Follower aktuelle Kopien des Leaders haben.  In Abbildung 1 sind die Leader die grün umrahmten Partitionen und die schwarzen sind die Follower. Die Partitionen aus Topic 1 haben dabei nichts mit denen aus Topic 2 zu tun.

Consumer

Der letzte hier noch nicht weiter erläuterte Teil von Kafka sind die Consumer. Alle Anwendungen, die Nachrichten von Kafka empfangen, werden als Consumer bezeichnet. Es ist möglich, dass ein einzelner Consumer alle Nachrichten aus einem bestimmten Topic oder aber nur aus bestimmten Partitionen eines Topics lesen kann. Letzteres Szenario entspräche dann eher einer klassischen Message Queue. Mit dem Unterschied, dass auch in diesem Fall der Consumer Nachrichten mehrmals lesen könnte und nicht zwangsweise die Nachrichten in der Reihenfolge lesen muss wie sie auf den Partitionen gespeichert sind.

Dieses Szenario hat allerdings ein Problem. Angenommen wir haben einen Producer, der schneller Nachrichten an das Topic sendet, als unser Programm verarbeiten kann. In diesem Fall würde unser Consumer weiter und weiter beim Konsumieren der Nachrichten zurückfallen und ein merkbarer Lag zwischen Senden und Empfangen würde entstehen, der nicht mehr aufgeholt werden könnte. Hier hätte man jetzt zwei Möglichkeiten. Entweder man optimiert den Consumer (Bessere Hardware oder besserer Code) oder aber man schaltet einen zweiten Consumer dazu, der parallel zum Ersten auch Nachrichten empfangen kann. Um Letzteres implementieren zu können, gibt es bei Kafka die sogenannten Consumer Groups.

Consumer Groups

Ein Consumer kann einer Consumer Group beitreten, die immer einem Topic zugeordnet ist. Innerhalb einer solchen Consumer Group werden eine oder mehrere Partitionen genau einem Consumer zugeordnet. Das heißt ein Consumer kann mehreren Partitionen zugeordnet sein, eine Partition aber immer nur genau einem Consumer. Der Vorteil hierbei liegt in der Parallelität. Je mehr Partitionen ein Topic hat, desto mehr Nachrichten können parallel von einer Consumer Group empfangen werden.

Ein weiterer Vorteil Kafkas ist es, dass während der Laufzeit Consumer die Consumer Group verlassen oder hinzukommen können. Jedes Mal wenn dies passiert führt Kafka ein sogenanntes rebalancing aus und verteilt die Partitionen auf alle verfügbaren Consumer. Dabei ist die Parallelität durch die Anzahl der Partitionen beschränkt. Gibt es mehr Consumer als Partitionen, sind diese überschüssigen Consumer solange im Leerlauf.

Im normalen Use Case von Kafka gibt es daher viele Producer (Datenproduzierende Systeme), die in viele verschiedene Topics  schreiben. Diese Topics werden dann von Consumern abgerufen, und die Daten werden analysiert, verarbeitet und abgespeichert. Kafka erlaubt hierzu eine extrem hohe Durchsatzrate, kann aber auch als Puffer dienen, falls bei den Consumern mal etwas schief läuft.

Veröffentlicht unter Analytics & BigData, IoT & Industry 4.0, Software Engineering | Kommentar hinterlassen