Fog und Edge versus Cloud

Ein Ding, ein Sensor, ein Übertragungsnetz. Ist das alles? Nicht ganz. Um die Daten, die das mit einem oder mehreren Sensoren bestückte (und deshalb «intelligente«) Ding erzeugt, auch gewinn- oder einsichtsbringend und wenn nötig in Echtzeit auszuwerten, muss am anderen Ende des Prozesses eine leistungsfähige Rechen- und Speicherkapazität stehen. Wie bei den Übertragungsnetzen selber, gibt es hier je nach IoT-Anwendung eine ganze Palette von sich ergänzenden Lösungen. Die Basis bilden zentrale Cloud-Lösungen; bei latenzkritischen Anwendungen, d.h. wenn es um die Echtzeit-Steuerung von Maschinen oder die Echtzeit-Auswertung von Informationen geht, kommen zudem Edge und Fog Computing ins Spiel. Denn dann würde die Übertragung, die Analyse und die Auswertung der Rohdaten vom Ort, wo sie gesammelt werden, bis zur zetralen Cloud und wieder retour, zu lange dauern.

Von unseren industriellen Kunden wird immer wieder angezweifelt, ob die Cloud der richtige Weg sei, um IoT und Predictive Analytics in Industrieprozessen, Produktionsanlagen und Maschinenparks zu implementieren. Einige Gründe sprechen dafür, einige aber auch dagegen:

IoT und Predictive Analytics in der Cloud: Was spricht dafür?

  • Aus der Cloud können Prozesse zentral überwacht werden. Mit den Daten lassen sich die Prozesse optimieren und besser betreiben. Die Informationen aus den Prozessen können zudem in die Produktentwicklung einfliessen.
  • In der Cloud sind die Daten zentral in einer Datenbank abgelegt und können für zukünftige aktuell noch unbekannte Analysen umfassend eingesetzt werden (Data Pool, Single Source of Truth).
  • Komplexe Algorithmen mit grossen Datenmengen können auf schweren Big Data Infrastrukturen ausgeführt werden (z.B. auf Hadoop oder MPP-Massive Parallel Processing Infrastrukturen). Es bestehen keine Limiten bezüglich CPU und RAM.
  • Die Daten können über eine zentrale Einheit zwischen den «Things» ausgetauscht werden. Das bringt strukturierten Informationsaustausch mit sich (im Gegensatz zur sog. Spaghetti-Vernetzung).
  • Das Thema Datensicherheit kann zentral angegangen werden und muss nicht dezentral für jede Einheit separat gelöst werden.

IoT und Predictive Analytics in der Cloud: Was spricht dagegen?

  • Die Daten verlassen das Netzwerk des Industrieprozesses (zum Beispiel des Herstellprozesses), was nicht von allen Kunden akzeptiert wird. Es besteht das potentielle Risiko, dass Prozess-Know-how abgesaugt wird.
  • Ist die Cloud über Internetverbindungen zugänglich, kann ein Angriff auf die Daten der Firma oder sogar auf die Anlagen selbst erfolgen (Cyber Security). Ein zentrales Element wie z.B. die IoT-Plattform eines grossen Providers ist grösser und bekannter; somit ist das Interesse und die Gefahr, dass ein solcher Punkt angegriffen und gehackt wird, ebenfalls viel grösser.
  • Die Latenzzeit zwischen Maschine und Cloud beeinträchtigt den Eingriff im Millisekundenbereich (Real-Time- oder Near-Real-Time-Applikationen). Viele Use Cases im Machine Learning und im datenanalytischen Bereich können so nicht oder nur eingeschränkt funktionieren.
  • Die Bandbreite des Netzwerkes ist oft nicht ausreichend, um die grossen Datenmengen zu übertragen.
  • Das Netzwerk kann ausfallen, die Verfügbarkeit der Applikation ist dann nicht sichergestellt. Im schlimmsten Fall kann sich das auf die Anlagenverfügbarkeit auswirken.
  • Bei grossen Datenmengen kann eine Cloud sehr teuer werden, wenn die Lizenzmodelle mengenspezifisch aufgesetzt sind.

Was ist Edge und wann wird es verwendet?

Ziel neuer Konzepte ist es, die Geräte und Sensoren in der Edge (im Deutschen am besten mit Rand übersetzt, in unserem Fall mit Industrieanlagen) oder in der Fog (d.h. im Industrienetzwerk) intelligenter zu machen, so dass die Kommunikation nicht nur von und zu der Cloud, sondern – wo sinnvoll – wieder zwischen den Geräten selbst stattfindet.

Warum also nicht Applikationen wie Predictive Maintenance direkt auf der Maschine ausführen? Dabei lassen sich Micro-Controllers einsetzten, die aber bezüglich Speicher und RAM beschränkt sind. Solche kleinen Prozessoreinheiten kommen dann auf Raspberry Pi’s, Onion Omega 3 oder ähnlichen Fabrikaten zum Einsatz, die kleine und kostengünstige IoT-Umgebungen zur Verfügung stellen. Diese Einheiten weisen wichtige Schnittstellen wie WiFi, Bluetooth und USB auf, die Leistungen sind aber recht gering. Ein Raspberry Pi Zero W etwa verfügt über 1 GHz CPU und 512 MB Storage bei einem Preis von 10 US-Dollar pro Einheit.

Micro Controllers und Raspberry Pi‘s

 

Damit auf diesen Systemen Algorithmen laufen können, müssen die Algorithmen sehr «leicht» gemacht sein, was häufig nicht möglich ist.

Was ist also die nächst grössere Einheit an Compute-Technologie? Heute lassen sich auch sogenannte SoC-Bauelemente (System on a Chip) einsetzen. Diese besitzen sehr viel höhere Leistungsdichten bei gleichzeitig geringem Platzbedarf. Sie sind bezüglich Hardwarekosten recht günstig, müssen aber speziell für den Einsatz entwickelt werden, was wiederum mit Entwicklungskosten verbunden ist.


Beispiel einer SoC Technologie

 

Einsatz finden solche Systeme, angefangen bei mobilen Telefongeräten bis hin zu Recheneinheiten, in Cloud-Centern. Die Leistungen gehen entsprechend bis 54 Cores hoch. Leistungsfähige Systeme mit 3 GHz, 512 GB RAM, 1 TB Storage und 100 Gbps Bandbreite sind aber mit einigen 100 US-Dollar auch wesentlich teurer als die Micro Controllers und Raspberry Pi‘s.

Warum braucht es Fog Computing?

Natürlich könnten wir auch einen Server an eine Maschine stellen, welcher bis zu 176 Cores, 2 TB RAM und 460 TB Storage ausweist. Die Hardware-Kosten würden dann aber dramatisch zunehmen und wir müssten uns die Frage stellen, wie teuer eine maschinennahe analytische Einheit sein darf. Dies ist natürlich abhängig von dem Preis der Maschine selber, aber in vielen Fällen lohnen sich die Mehrkosten vermutlich nicht.

Fog arbeitet mit der Cloud, während der Edge durch den Ausschluss der Cloud definiert wird. Fog arbeitet hierarchisch, wogegen Edge auf eine kleine Anzahl von Schichten beschränkt ist. Fog befasst sich neben der Berechnung auch mit Vernetzung, Speicherung, Steuerung und Beschleunigung. Mit Fog Computing kann daher eine interessante und preisgünstige Zwischenlösung zur Cloud geschaffen werden. Die Rechenleistung wird an die Peripherie der Netzwerke gedrückt und damit für eine Gruppe von «Dingen» zwischen Edge und Cloud ausgeführt.

Darstellung der Fog-Architektur

 

Fog: Ein Architekturkonzept

Fog ist zuerst einmal ein Architekturansatz, zweitens eine Software und drittens eine Hardwarekomponente. Der Ansatz ist noch recht neu. 2015 wurde von einigen wichtigen Exponenten wie Cisco, Intel, Dell, Microsoft und Princeton University das Open Fog Konsortium gegründet. Im Februar 2017 ist dann das erste Architekturkonzept publiziert worden, welches hier eingesehen werden kann.

Die Publikation ist nicht sehr konkret und man muss sich durch 162 Seiten Paper kämpfen. Trotzdem lohnt sich eine Sichtung des Dokuments. Ohne hier genauer darauf einzugehen, ist für uns folgende Zusammenarbeit von Edge, Fog und Cloud essentiell.

Das Machine-Learning-Modell (ML) wird auf einer Data-Science-Plattform entwickelt. Das kann offline oder in der Cloud geschehen. Unser Unternehmen LeanBI setzt dafür als Plattform Dataiku ein. Das ML-Modell wird dann auf eine produktive Plattform exportiert, wo es, je nach den Anforderungen, auf der Edge, in der Fog oder direkt in der Cloud läuft. Der Trainings-Task zur Modell-Optimierung wird in der Regel an die Cloud abgegeben, da dieser Task rechenintensiv ist und eine breite Datenbasis benötigt. Das Modell wird damit periodisch in der Cloud mit neuen Daten optimiert und dieses verbesserte Modell dann auf die Fog oder Edge periodisch angewendet. Prinzipiell lässt sich dieser Trainings-Task auch offline ausführen, je nachdem, wie häufig er stattfinden muss.

Fog: Ein Stück Software

Die Softwarelandschaft rund um Edge und Fog Computing ist momentan noch recht übersichtlich. Dabei ist der Funktionsumfang teilweise sehr unterschiedlich. Cloud-Anbieter wie MS Azure IoT, Predix, AWS oder IBM Watson haben 2016/2017 Edge/Fog-Komponenten lanciert (meistens als Open Source), die besonders als Bindeglied zwischen der Edge und der Cloud wirken. Dabei werden Funktionalitäten bereitgestellt, die das Machine-Learning-Modell auf der Edge laufen lassen. Drei Beispiele dafür sind AWS Greengrass, Azure IoT Edge und IBM Edge Analytics.

Was Data Preparation, Data Cleansing und Data Processing auf der Edge/Fog anbelangt, sind diese Lösungen noch sehr programmieraufwändig. Sie sind zudem nicht unabhängig von der Cloud-Lösung einsetzbar. Zu den Software-Lösungen, die Edge und Fog Computing unabhängig vom Cloud Provider möglich machen, gehört Foghorn, entwickelt von einem Start-Up aus dem Silicon Valley.

Foghorn bietet die Möglichkeit der Datenaufbereitung und einer sehr schnellen Ausführungs-Engine, der sogenannten CEP Engine. CEP bedeutet Complex Event Processing und beinhaltet verschiedene Methoden, um Logik möglichst in Real Time abzuhandeln. CEP kann innerhalb von Docker betrieben werden und läuft damit auch direkt auf der Edge. Dabei läuft die Software meist nicht auf den Endpunkten der Anlagen, sondern auf den physischen Gateways.

Fog: Ein Stück Hardware

Die physischen Gateways bringen den Vorteil mit sich, dass Software immer noch Nahe der Anlage läuft, gleichzeitig aber ein ganzes Bündel an Maschinen und Anlagenpunkten bedient werden können. Netzwerkmässig läuft die Software damit noch im Automatisierungsnetzwerk, also abgekoppelt von der Cloud, der Datenaustausch findet über die Standard-Konnektoren der Gateways statt. Wichtige Daten können aber von diesem Punkt einfach der Cloud zur Verfügung gestellt werden.

Zusammenfassung und Fazit

Zukünftige analytische Lösungen werden weder nur auf der Maschine noch allein in der Cloud betrieben werden. Immer häufiger werden stattdessen Fog-Architekturen die passende Lösung sein.

Hier kommen Kombinationseinsätze von physischen Gateways und Cloud-Plattformen zum Einsatz, eine kostengünstige Form zur Umsetzung analytischer Lösungen nahe der Maschine oder Anlage bei gleichzeitiger optimaler Nutzung von Compute-Ressourcen in der Cloud.

Welche Herausforderungen verbleiben?

  • Die IoT-Edge- und Fog-Lösungen sind neueren Datums und zur Zeit einer starken Entwicklung unterworfen.
  • Es ist immer zu definieren, welche Daten in die Cloud gegeben werden und welche Daten in Edge und Fog verbleiben.
  • Storage, CPU und Kostengrenzen in der Edge/Fog.
  • Modellbildung an einem Ort – Ausführung und Verteilung an mehreren Orten.
  • Standards für Peer-to-Peer-Lösungen sind noch nicht genügend vorhanden.
     

Dieser Beitrag (inkl. Illustrationen) ist erstmals auf dem Blog von LeanBI erschienen. Mit freundlicher Genehmigung des Autors.

Marc Tresch

Mark Tresch, Dr. sc. techn., Dipl. Masch.-Ing. ETH, ist Geschäftsführer der auf Business Intelligence und Big-Data-Lösungen spezialisierten LeanBI AG.

 

.

Fog und Edge versus Cloud

Ein Ding, ein Sensor, ein Übertragungsnetz. Ist das alles? Nicht ganz. Um die Daten, die das mit einem oder mehreren Sensoren bestückte (und deshalb «intelligente«) Ding erzeugt, auch gewinn- oder einsichtsbringend und wenn nötig in Echtzeit auszuwerten, muss am anderen Ende des Prozesses eine leistungsfähige Rechen- und Speicherkapazität stehen. Wie bei den Übertragungsnetzen selber, gibt es hier je nach IoT-Anwendung eine ganze Palette von sich ergänzenden Lösungen. Die Basis bilden zentrale Cloud-Lösungen; bei latenzkritischen Anwendungen, d.h. wenn es um die Echtzeit-Steuerung von Maschinen oder die Echtzeit-Auswertung von Informationen geht, kommen zudem Edge und Fog Computing ins Spiel. Denn dann würde die Übertragung, die Analyse und die Auswertung der Rohdaten vom Ort, wo sie gesammelt werden, bis zur zetralen Cloud und wieder retour, zu lange dauern.

Von unseren industriellen Kunden wird immer wieder angezweifelt, ob die Cloud der richtige Weg sei, um IoT und Predictive Analytics in Industrieprozessen, Produktionsanlagen und Maschinenparks zu implementieren. Einige Gründe sprechen dafür, einige aber auch dagegen:

IoT und Predictive Analytics in der Cloud: Was spricht dafür?

  • Aus der Cloud können Prozesse zentral überwacht werden. Mit den Daten lassen sich die Prozesse optimieren und besser betreiben. Die Informationen aus den Prozessen können zudem in die Produktentwicklung einfliessen.
  • In der Cloud sind die Daten zentral in einer Datenbank abgelegt und können für zukünftige aktuell noch unbekannte Analysen umfassend eingesetzt werden (Data Pool, Single Source of Truth).
  • Komplexe Algorithmen mit grossen Datenmengen können auf schweren Big Data Infrastrukturen ausgeführt werden (z.B. auf Hadoop oder MPP-Massive Parallel Processing Infrastrukturen). Es bestehen keine Limiten bezüglich CPU und RAM.
  • Die Daten können über eine zentrale Einheit zwischen den «Things» ausgetauscht werden. Das bringt strukturierten Informationsaustausch mit sich (im Gegensatz zur sog. Spaghetti-Vernetzung).
  • Das Thema Datensicherheit kann zentral angegangen werden und muss nicht dezentral für jede Einheit separat gelöst werden.

IoT und Predictive Analytics in der Cloud: Was spricht dagegen?

  • Die Daten verlassen das Netzwerk des Industrieprozesses (zum Beispiel des Herstellprozesses), was nicht von allen Kunden akzeptiert wird. Es besteht das potentielle Risiko, dass Prozess-Know-how abgesaugt wird.
  • Ist die Cloud über Internetverbindungen zugänglich, kann ein Angriff auf die Daten der Firma oder sogar auf die Anlagen selbst erfolgen (Cyber Security). Ein zentrales Element wie z.B. die IoT-Plattform eines grossen Providers ist grösser und bekannter; somit ist das Interesse und die Gefahr, dass ein solcher Punkt angegriffen und gehackt wird, ebenfalls viel grösser.
  • Die Latenzzeit zwischen Maschine und Cloud beeinträchtigt den Eingriff im Millisekundenbereich (Real-Time- oder Near-Real-Time-Applikationen). Viele Use Cases im Machine Learning und im datenanalytischen Bereich können so nicht oder nur eingeschränkt funktionieren.
  • Die Bandbreite des Netzwerkes ist oft nicht ausreichend, um die grossen Datenmengen zu übertragen.
  • Das Netzwerk kann ausfallen, die Verfügbarkeit der Applikation ist dann nicht sichergestellt. Im schlimmsten Fall kann sich das auf die Anlagenverfügbarkeit auswirken.
  • Bei grossen Datenmengen kann eine Cloud sehr teuer werden, wenn die Lizenzmodelle mengenspezifisch aufgesetzt sind.

Was ist Edge und wann wird es verwendet?

Ziel neuer Konzepte ist es, die Geräte und Sensoren in der Edge (im Deutschen am besten mit Rand übersetzt, in unserem Fall mit Industrieanlagen) oder in der Fog (d.h. im Industrienetzwerk) intelligenter zu machen, so dass die Kommunikation nicht nur von und zu der Cloud, sondern – wo sinnvoll – wieder zwischen den Geräten selbst stattfindet.

Warum also nicht Applikationen wie Predictive Maintenance direkt auf der Maschine ausführen? Dabei lassen sich Micro-Controllers einsetzten, die aber bezüglich Speicher und RAM beschränkt sind. Solche kleinen Prozessoreinheiten kommen dann auf Raspberry Pi’s, Onion Omega 3 oder ähnlichen Fabrikaten zum Einsatz, die kleine und kostengünstige IoT-Umgebungen zur Verfügung stellen. Diese Einheiten weisen wichtige Schnittstellen wie WiFi, Bluetooth und USB auf, die Leistungen sind aber recht gering. Ein Raspberry Pi Zero W etwa verfügt über 1 GHz CPU und 512 MB Storage bei einem Preis von 10 US-Dollar pro Einheit.

Micro Controllers und Raspberry Pi‘s

 

Damit auf diesen Systemen Algorithmen laufen können, müssen die Algorithmen sehr «leicht» gemacht sein, was häufig nicht möglich ist.

Was ist also die nächst grössere Einheit an Compute-Technologie? Heute lassen sich auch sogenannte SoC-Bauelemente (System on a Chip) einsetzen. Diese besitzen sehr viel höhere Leistungsdichten bei gleichzeitig geringem Platzbedarf. Sie sind bezüglich Hardwarekosten recht günstig, müssen aber speziell für den Einsatz entwickelt werden, was wiederum mit Entwicklungskosten verbunden ist.


Beispiel einer SoC Technologie

 

Einsatz finden solche Systeme, angefangen bei mobilen Telefongeräten bis hin zu Recheneinheiten, in Cloud-Centern. Die Leistungen gehen entsprechend bis 54 Cores hoch. Leistungsfähige Systeme mit 3 GHz, 512 GB RAM, 1 TB Storage und 100 Gbps Bandbreite sind aber mit einigen 100 US-Dollar auch wesentlich teurer als die Micro Controllers und Raspberry Pi‘s.

Warum braucht es Fog Computing?

Natürlich könnten wir auch einen Server an eine Maschine stellen, welcher bis zu 176 Cores, 2 TB RAM und 460 TB Storage ausweist. Die Hardware-Kosten würden dann aber dramatisch zunehmen und wir müssten uns die Frage stellen, wie teuer eine maschinennahe analytische Einheit sein darf. Dies ist natürlich abhängig von dem Preis der Maschine selber, aber in vielen Fällen lohnen sich die Mehrkosten vermutlich nicht.

Fog arbeitet mit der Cloud, während der Edge durch den Ausschluss der Cloud definiert wird. Fog arbeitet hierarchisch, wogegen Edge auf eine kleine Anzahl von Schichten beschränkt ist. Fog befasst sich neben der Berechnung auch mit Vernetzung, Speicherung, Steuerung und Beschleunigung. Mit Fog Computing kann daher eine interessante und preisgünstige Zwischenlösung zur Cloud geschaffen werden. Die Rechenleistung wird an die Peripherie der Netzwerke gedrückt und damit für eine Gruppe von «Dingen» zwischen Edge und Cloud ausgeführt.

Darstellung der Fog-Architektur

 

Fog: Ein Architekturkonzept

Fog ist zuerst einmal ein Architekturansatz, zweitens eine Software und drittens eine Hardwarekomponente. Der Ansatz ist noch recht neu. 2015 wurde von einigen wichtigen Exponenten wie Cisco, Intel, Dell, Microsoft und Princeton University das Open Fog Konsortium gegründet. Im Februar 2017 ist dann das erste Architekturkonzept publiziert worden, welches hier eingesehen werden kann.

Die Publikation ist nicht sehr konkret und man muss sich durch 162 Seiten Paper kämpfen. Trotzdem lohnt sich eine Sichtung des Dokuments. Ohne hier genauer darauf einzugehen, ist für uns folgende Zusammenarbeit von Edge, Fog und Cloud essentiell.

Das Machine-Learning-Modell (ML) wird auf einer Data-Science-Plattform entwickelt. Das kann offline oder in der Cloud geschehen. Unser Unternehmen LeanBI setzt dafür als Plattform Dataiku ein. Das ML-Modell wird dann auf eine produktive Plattform exportiert, wo es, je nach den Anforderungen, auf der Edge, in der Fog oder direkt in der Cloud läuft. Der Trainings-Task zur Modell-Optimierung wird in der Regel an die Cloud abgegeben, da dieser Task rechenintensiv ist und eine breite Datenbasis benötigt. Das Modell wird damit periodisch in der Cloud mit neuen Daten optimiert und dieses verbesserte Modell dann auf die Fog oder Edge periodisch angewendet. Prinzipiell lässt sich dieser Trainings-Task auch offline ausführen, je nachdem, wie häufig er stattfinden muss.

Fog: Ein Stück Software

Die Softwarelandschaft rund um Edge und Fog Computing ist momentan noch recht übersichtlich. Dabei ist der Funktionsumfang teilweise sehr unterschiedlich. Cloud-Anbieter wie MS Azure IoT, Predix, AWS oder IBM Watson haben 2016/2017 Edge/Fog-Komponenten lanciert (meistens als Open Source), die besonders als Bindeglied zwischen der Edge und der Cloud wirken. Dabei werden Funktionalitäten bereitgestellt, die das Machine-Learning-Modell auf der Edge laufen lassen. Drei Beispiele dafür sind AWS Greengrass, Azure IoT Edge und IBM Edge Analytics.

Was Data Preparation, Data Cleansing und Data Processing auf der Edge/Fog anbelangt, sind diese Lösungen noch sehr programmieraufwändig. Sie sind zudem nicht unabhängig von der Cloud-Lösung einsetzbar. Zu den Software-Lösungen, die Edge und Fog Computing unabhängig vom Cloud Provider möglich machen, gehört Foghorn, entwickelt von einem Start-Up aus dem Silicon Valley.

Foghorn bietet die Möglichkeit der Datenaufbereitung und einer sehr schnellen Ausführungs-Engine, der sogenannten CEP Engine. CEP bedeutet Complex Event Processing und beinhaltet verschiedene Methoden, um Logik möglichst in Real Time abzuhandeln. CEP kann innerhalb von Docker betrieben werden und läuft damit auch direkt auf der Edge. Dabei läuft die Software meist nicht auf den Endpunkten der Anlagen, sondern auf den physischen Gateways.

Fog: Ein Stück Hardware

Die physischen Gateways bringen den Vorteil mit sich, dass Software immer noch Nahe der Anlage läuft, gleichzeitig aber ein ganzes Bündel an Maschinen und Anlagenpunkten bedient werden können. Netzwerkmässig läuft die Software damit noch im Automatisierungsnetzwerk, also abgekoppelt von der Cloud, der Datenaustausch findet über die Standard-Konnektoren der Gateways statt. Wichtige Daten können aber von diesem Punkt einfach der Cloud zur Verfügung gestellt werden.

Zusammenfassung und Fazit

Zukünftige analytische Lösungen werden weder nur auf der Maschine noch allein in der Cloud betrieben werden. Immer häufiger werden stattdessen Fog-Architekturen die passende Lösung sein.

Hier kommen Kombinationseinsätze von physischen Gateways und Cloud-Plattformen zum Einsatz, eine kostengünstige Form zur Umsetzung analytischer Lösungen nahe der Maschine oder Anlage bei gleichzeitiger optimaler Nutzung von Compute-Ressourcen in der Cloud.

Welche Herausforderungen verbleiben?

  • Die IoT-Edge- und Fog-Lösungen sind neueren Datums und zur Zeit einer starken Entwicklung unterworfen.
  • Es ist immer zu definieren, welche Daten in die Cloud gegeben werden und welche Daten in Edge und Fog verbleiben.
  • Storage, CPU und Kostengrenzen in der Edge/Fog.
  • Modellbildung an einem Ort – Ausführung und Verteilung an mehreren Orten.
  • Standards für Peer-to-Peer-Lösungen sind noch nicht genügend vorhanden.
     

Dieser Beitrag (inkl. Illustrationen) ist erstmals auf dem Blog von LeanBI erschienen. Mit freundlicher Genehmigung des Autors.

Marc Tresch

Mark Tresch, Dr. sc. techn., Dipl. Masch.-Ing. ETH, ist Geschäftsführer der auf Business Intelligence und Big-Data-Lösungen spezialisierten LeanBI AG.

 

.