Posts

Artikelserie: BI Tools im Vergleich – Datengrundlage

Dieser Artikel wird als Fortsetzung des ersten Artikels, einer Artikelserie zu BI Tools, die Datengrundlage erläutern.

Als Datengrundlage sollen die Trainingsdaten – AdventureWorks 2017 – von Microsoft dienen und Ziel soll es sein, ein möglichst gleiches Dashboard in jedem dieser Tools zu erstellen.

Bei der Datenbasis handelt es sich bereits um ein relationales Datenbankmodel mit strukturierten Daten, welches als Datei-Typ .bak zur Verfügung steht. Die Daten sind bereits bereinigt und normalisiert, sowie bestehen auch bereits Beziehungen zwischen den Tabellen. Demnach fallen sowohl aufwendige Datenbereinigungen weg, als auch der Aufbau eines relationalen Datenmodells im Dashboard. In den meisten Tools ist beides möglich, wenn auch nicht das optimale Programm. Vor allem sollte vermieden werden Datenbereinigungen in BI Tools vorzunehmen. Alle Tools bieten einem die Möglichkeit strukturierte und unstrukturierte Daten aus verschiedensten Datenquellen zu importieren. Die Datenquelle wird SQL Server von Microsoft sein, da die .bak Datei nicht direkt in die meisten Dashboards geladen werden kann und zudem auf Grund der Datenmenge ein kompletter Import auch nicht ratsam ist. Aus Gründen der Performance sollten nur die für das Dashboard relevanten Daten importiert werden. Für den Vergleich werden 15 von insgesamt 71 Tabellen importiert, um Visualisierungen für wesentliche Geschäftskennzahlen aufzubauen. Die obere Grafik zeigt das Entity-Relationship-Modell (ERM) zu den relevanten Tabellen. Die Datengrundlage eignet sich sehr gut für tiefer gehende Analysen und bietet zugleich ein großes Potential für sehr ausgefallene Visualisierungen. Im Fokus dieser Artikelserie soll aber nicht die Komplexität der Grafiken, sondern die allgemeine Handhabbarkeit stehen. Allgemein besteht die Gefahr, dass die Kernaussagen eines Reports in den Hintergrund rücken bei der Verwendung von zu komplexen Visualisierungen, welche lediglich der Ästhetik dienlich sind.

Eine Beschränkung soll gelten: So soll eine Manipulation von Daten lediglich in den Dashboards selbst vorgenommen werden. Bedeutet das keine Tabellen in SQL Server geändert oder Views erstellt werden. Gehen wir einfach Mal davon aus, dass der Data Engineer Haare auf den Zähnen hat und die Zuarbeit in jeglicher Art und Weise verwehrt wird.

Also ganz nach dem Motto: Help yourself! 😉

Daten zum Üben gibt es etliche. Einfach Mal Github, Kaggle oder andere Open Data Quellen anzapfen. Falls ihr Lust habt, dann probiert euch doch selber einmal an den Dashboards. Ihr solltet ein wenig Zeit mitbringen, aber wenn man erstmal drin ist macht es viel Spaß und es gibt immer etwas neues zu entdecken! Das erste Dashboard und somit die Fortsetzung dieser Artikelserie wird  Power BI als Grundlage haben.

Hier ein paar Links um euch startklar zu machen, falls das Interesse in euch geweckt wurde.

Dataset: AdventureWorks 2017

MS SQL Server

MS SSMS

MS Power BI (Desktop)

Artikelserie: BI Tools im Vergleich – Einführung und Motivation

„Mit welchem BI-Tool arbeitest du am liebsten?“ Mit dieser Frage werde ich dieser Tage oft konfrontiert. Meine klassische Antwort und eine typische Beraterantwort: „Es kommt darauf an.“ Nach einem Jahr als Berater sitzt diese Antwort sicher, aber gerade in diesem Fall auch begründet. Auf den Analytics und Business Intelligence Markt drängen jedes Jahr etliche neue Dashboard-Anbieter und die etablierten erweitern Services und Technik in rasantem Tempo. Zudem sind die Anforderungen an ein BI-Tool höchst unterschiedlich und von vielen Faktoren abhängig. Meine Perspektive, also die Anwenderperspektive eines Entwicklers, ist ein Faktor und auch der Kern dieser Artikelserie. Um die Masse an Tools auf eine machbare Anzahl runter zu brechen werde ich die bekanntesten Tools im Vergleich ausprobieren und hier vorstellen. Die Aufgabe ist also schnell erklärt: Ein Dashboard mit den gleichen Funktionen und Aussagen in unterschiedlichen Tools erstellen. Im Folgenden werde ich auch ein paar Worte zur Bewertungsgrundlage und zur Datengrundlage verlieren.

Erstmal kurz zu mir: Wie bereits erwähnt arbeite ich seit einem Jahr als Berater, genauer als Data Analyst in einem BI-Consulting Unternehmen namens DATANOMIQ. Bereits davor habe ich mich auf der anderen Seite der Macht, quasi als Kunde eines Beraters, viel mit Dashboards beschäftigt. Aber erst in dem vergangenen Jahr wurde mir die Fülle an BI Tools bewusst und der Lerneffekt war riesig. Die folgende Grafik zeigt alle Tools welche ich in der Artikelserie vorstellen möchte.

Gartner’s Magic Quadrant for Analytics and Business Intelligence Platform führt jedes Jahr eine Portfolioanalyse über die visionärsten und bedeutendsten BI-Tools durch, unter der genannten befindet sich nur eines, welches nicht in dieser Übersicht geführt wird, ich jedoch als potenziellen Newcomer für die kommenden Jahre erwarte. Trotz mittlerweile einigen Jahren Erfahrung gibt es noch reichlich Potential nach oben und viel Neues zu entdecken, gerade in einem so direkten Vergleich. Also seht mich ruhig als fortgeschrittenen BI-Analyst, der für sich herausfinden will, welche Tools aus Anwendersicht am besten geeignet sind und vielleicht kann ich dem ein oder anderen auch ein paar nützliche Tipps mit auf den Weg geben.

Was ist eigentlich eine „Analytical and Business Intelligence Platform“?

Für alle, die komplett neu im Thema sind, möchte ich erklären, was eine Analytical and Business Intelligence Platform in diesem Kontext ist und warum wir es nachfolgend auch einfach als BI-Tool bezeichnen können. Es sind Softwarelösungen zur Generierung von Erkenntnissen mittels Visualisierung und Informationsintegration von Daten. Sie sollten einfach handhabbar sein, weil der Nutzer für die Erstellung von Dashboards keine speziellen IT-Kenntnisse mitbringen muss und das Userinterface der jeweiligen Software einen mehr oder minder gut befähigt die meisten Features zu nutzen. Die meisten und zumindest die oben genannten lassen sich aber auch um komplexere Anwendungen und Programmiersprachen erweitern. Zudem bestimmt natürlich auch der Use Case den Schwierigkeitsgrad der Umsetzung.

Cloudbasierte BI Tools sind mittlerweile der Standard und folgen dem allgemeinen Trend. Die klassische Desktop-Version wird aber ebenfalls von den meisten angeboten. Von den oben genannten haben lediglich Data Studio und Looker keine Desktop- Version. Für den einfachen User macht das keinen großen Unterschied, welche Version man nutzt. Aber für das Unternehmen in Gesamtheit ist es ein wesentlicher Entscheidungsfaktor für die Wahl der Software und auch auf den Workflow des Developers bzw. BI-Analyst kann sich das auswirken.

Unternehmensperspektive: Strategie & Struktur

Die Unternehmensstrategie setzt einen wesentlichen Rahmen zur Entwicklung einer Datenstrategie worunter auch ein anständiges Konzept zur Data Governance gehört.

Ein wesentlicher Punkt der Datenstrategie ist die Verteilung der BI- und Datenkompetenz im Unternehmen. An der Entwicklung der Dashboards arbeiten in der Regel zwei Parteien, der Developer, der im Unternehmen meistens die Bezeichnung BI- oder Data Analyst hat, und der Stakeholder, also einzelner User oder die User ganzer Fachabteilungen.

Prognose: Laut Gartner wird die Anzahl der Daten- und Analyse-Experten in den Fachabteilungen, also die Entwickler und Benutzer von BI Tools, drei Mal so schnell wachsen verglichen mit dem bereits starken Wachstum an IT-Fachkräften.

Nicht selten gibt es für ein Dashboard mehrere Stakeholder verschiedener Abteilungen. Je nach Organisation und Softwarelösung mit unterschiedlich weitreichenden Verantwortlichkeiten, was die Entwicklung eines Dashboards an geht.

Die obige Grafik zeigt die wesentlichen Prozessschritte von der Konzeption bis zum fertigen Dashboard und drei oft gelebte Konzepte zur Verteilung der Aufgaben zwischen dem User und dem Developer. Natürlich handelt es sich fast immer um einen iterativen Prozess und am Ende stellen sich auch positive Nebenerkenntnisse heraus. Verschiedene Tools unterstützen durch Ihre Konfiguration und Features verschiedene Ansätze zur Aufgabenverteilung, auch wenn mit jedem Tool fast jedes System gelebt werden kann, provozieren einige Tools mit ihrem logischen Aufbau und dem Lizenzmodell zu einer bestimmten Organisationsform. Looker zum Beispiel verkauft mit der Software das Konzept, dem User eine größere Möglichkeit zu geben, das Dashboard in Eigenregie zu bauen und gleichzeitig die Datenhoheit an den richtigen Stellen zu gewährleisten (mittlerer Balken in der Grafik). Somit wird dem User eine höhere Verantwortung übertragen und weit mehr Kompetenzen müssen vermittelt werden, da der Aufbau von Visualisierung ebenfalls Fehlerpotential in sich birgt. Ein Full‑Service hingegen unterstützt das Konzept fast aller Tools durch Zuweisen von Berechtigungen. Teilweise werden aber gewisse kostenintensive Features nicht genutzt oder auf Cloud-Lizenzen verzichtet, so dass jeder Mitarbeiter unabhängig auf einer eigenen Desktop-Version arbeitet, am Ende dann leider die Single Source of Truth nicht mehr gegeben ist. Denn das führt eigentlich gezwungenermaßen dazu, dass die User sich aus x beliebigen Datentöpfen bedienen, ungeschultes Personal falsche Berechnungen anstellt und am Ende die unterschiedlichen Abteilungen sich mit schlichtweg falschen KPIs überbieten. Das spricht meistens für ein Unternehmen ohne vollumfängliches Konzept für Data Governance bzw. einer fehlenden Datenstrategie.

Zu dem Thema könnte man einen Roman schreiben und um euch diesen zu ersparen, möchte ich kurz die wichtigsten Fragestellungen aus Unternehmensperspektive aufzählen, ohne Anspruch auf Vollständigkeit:

  • Wann wird ein Return on Invest (ROI) realisiert werden?
  • Wie hoch ist mein Budget für BI-Lösungen?
  • Sollen die Mitarbeiter mit BI-Kompetenz zentral oder dezentral organisiert sein?
  • Wie ist meine Infrastruktur aufgebaut? Cloudbasiert oder on Premise?
  • Soll der Stakeholder/User Zeit-Ressourcen für den Aufbau von Dashboards erhalten?
  • Über welche Skills verfügen die Mitarbeiter bereits?
  • Welche Autorisierung in Bezug auf die Datensichtbarkeit und -manipulation haben die jeweiligen Mitarbeiter der Fachabteilungen?
  • Bedarf an Dashboards: Wie häufig werden diese benötigt und wie oft werden bestehende Dashboards angepasst?
  • Kann die Data Exploration durch den Stakeholder/User einen signifikanten Mehrwert liefern?
  • Werden Dashboards in der Regel für mehrere Stakeholder gebaut?

Die Entscheidung für die Wahl eines Dashboards ist nicht nur davon abhängig, wie sich die Grafiken von links nach rechts schieben lassen, sondern es handelt sich auch um eine wichtige strategische Frage aus Unternehmersicht.

Ein Leitsatz hierbei sollte lauten:
Die Strategie des Unternehmens bestimmt die Anforderungen an das Tool und nicht andersrum!

Perspektive eines Entwicklers:      Bewertungsgrundlage der Tools

So jetzt Mal Butter bei die Fische und ab zum Kern des Artikels. Jeder der Artikel wird aus den folgenden Elementen bestehen:

  • Das Tool:
    • Daten laden
    • Daten transformieren
    • Daten visualisieren
    • Zukunftsfähigkeit am Beispiel von Pythonintegration
    • Handhabbarkeit
  • Umweltfaktoren:
    • Community
    • Dokumentation
    • Features anderer Entwickler(-firmen) zur Erweiterung
    • Lizenzmodell
      • Cloud (SaaS) ODER on premise Lizenzen?
      • Preis (pro Lizenz, Unternehmenslizenz etc.)
      • Freie Version

 

Im Rahmen dieser Artikelserie erscheinen im Laufe der kommenden Monate folgende Artikel zu den Reviews der BI-Tools:

  1. Power BI von Microsoft
  2. Tableau
  3. MicroStrategy (erscheint demnächst)
  4. Looker (erscheint demnächst)
  5. Qlik Sense (erscheint demnächst)

Über einen vorausgehend veröffentlichten Artikel wird die Datengrundlage erläutert, die für alle Reviews gemeinsam verwendet wird: Vorstellung der Datengrundlage

Big Data Essentials – Intro

1. Big Data Definition

Data umfasst Nummern, Text, Bilder, Audio, Video und jede Art von Informationen die in Ihrem Computer gespeichert werden können. Big Data umfasst Datenmengen, die eine oder mehrere der folgenden Eigenschaften aufweisen: Hohes Volumen (High Volume), hohe Vielfalt (High Variety) und / oder eine notwendige hohe Geschwindigkeit (High Velocity) zur Auswertung. Diese drei Eigenschaften werden oft auch als die 3V’s von Big Data bezeichnet.

1.1. Volumen: Menge der erzeugten Daten

Volumen bezieht sich auf die Menge der generierten Daten. Traditionelle Datenanalysemodelle erfordern typischerweise Server mit großen Speicherkapazitäten, bei massiver Rechenleistung sind diese Modelle nicht gut skalierbar. Um die Rechenleistung zu erhöhen, müssen Sie weiter investieren, möglicherweise auch in teurere proprietäre Hardware. Die NASA ist eines von vielen Unternehmen, die enorme Mengen an Daten sammeln. Ende 2014 sammelte die NASA alle paar Sekunden etwa 1,73 GB an Daten. Und auch dieser Betrag der Datenansammlung steigt an, so dass die Datenerfassung entsprechend exponentiell mitwachsen muss. Es resultieren sehr hohe Datenvolumen und es kann schwierig sein, diese zu speichern.

1.2. Vielfalt: Unterschiedliche Arten von Daten

Das  traditionelle  Datenmodell (ERM)  erfordert  die  Entwicklung  eines  Schemas,  das  die  Daten in ein Korsett zwingt. Um das Schema zu erstellen, muss man das Format der Daten kennen, die gesammelt werden. Daten  können  wie  XML-Dateien  strukturiert  sein,  halb  strukturiert  wie  E-Mails oder unstrukturiert wie Videodateien.

Wikipedia – als Beispiel – enthält mehr als nur Textdaten, es enthält Hyperlinks, Bilder, Sound-Dateien und viele andere Datentypen mit mehreren verschiedenen Arten von Daten. Insbesondere unstrukturierte   Daten haben   eine   große   Vielfalt.  Es   kann   sehr   schwierig   sein, diese Vielfalt in einem Datenmodell zu beschreiben.

1.3. Geschwindigkeit: Geschwindigkeit, mit der Daten genutzt werden

Traditionelle Datenanalysemodelle wurden für die Stapelverarbeitung (batch processing) entwickelt. Sie sammeln die gesamte Datenmenge und verarbeiten sie, um sie in die Datenbank zu speichern. Erst mit einer Echtzeitanalyse der Daten kann schnell auf Informationen reagiert werden. Beispielsweise können Netzwerksensoren, die mit dem Internet der Dinge (IoT) verbunden sind, tausende von Datenpunkten pro Sekunde erzeugen. Im Gegensatz zu Wikipedia, deren Daten später verarbeitet werden können, müssen Daten von Smartphones und anderen Netzwerkteilnehmern mit entsprechender Sensorik in  Echtzeit  verarbeitet  werden.

2. Geschichte von Big Data

2.1. Google Solution

  • Google File System speichert die Daten, Bigtable organisiert die Daten und MapReduce verarbeitet es.
  • Diese Komponenten arbeiten zusammen auf einer Sammlung von Computern, die als Cluster bezeichnet werden.
  • Jeder einzelne Computer in einem Cluster wird als Knoten bezeichnet.

2.2 Google File System

Das Google File System (GFS) teilt Daten in Stücke ‚Chunks’ auf. Diese ‚Chunks’ werden verteilt und auf verschiedene Knoten in einem Cluster nachgebildet. Der Vorteil ist nicht nur die mögliche parallele Verarbeitung bei der späteren Analysen, sondern auch die Datensicherheit. Denn die Verteilung und die Nachbildung schützen vor Datenverlust.

2.3. Bigtable

Bigtable ist ein Datenbanksystem, das GFS zum Speichern und Abrufen von Daten verwendet. Trotz seines Namens ist Bigtable nicht nur eine sehr große Tabelle. Bigtable ordnet die Datenspeicher mit einem Zeilenschlüssel, einem Spaltenschlüssel und einem Zeitstempel zu. Auf diese Weise können dieselben Informationen über einen längeren Zeitraum hinweg erfasst werden, ohne dass bereits vorhandene Einträge überschrieben werden. Die Zeilen sind dann in den Untertabellen partitioniert, die über einem Cluster verteilt sind. Bigtable wurde entwickelt, um riesige Datenmengen zu bewältigen, mit der Möglichkeit, neue Einträge zum Cluster hinzuzufügen, ohne dass eine der vorhandenen Dateien neu konfiguriert werden muss.

2.4. MapReduce

Als dritter Teil des Puzzles wurde ein Parallelverarbeitungsparadigma namens MapReduce genutzt, um die bei GFS gespeicherten Daten zu verarbeiten. Der Name MapReduce wird aus den Namen von zwei Schritten im Prozess übernommen. Obwohl der Mapreduce-Prozess durch Apache Hadoop berühmt geworden ist, ist das kaum eine neue Idee. In der Tat können viele gängige Aufgaben wie Sortieren und Falten von Wäsche als Beispiele für den MapReduce- Prozess betrachtet werden.

Quadratische Funktion:

  • wendet die gleiche Logik auf jeden Wert an, jeweils einen Wert
  • gibt das Ergebnis für jeden Wert aus
    (map square'(1 2 3 4)) = (1 4 9 16)

Additionsfunktion

  • wendet die gleiche Logik auf alle Werte an, die zusammen genommen werden.
    (reduce + ‘(1 4 9 16)) = 30

Die Namen Map und Reduce können bei der Programmierung mindestens bis in die 70er-Jahre zurückverfolgt werden. In diesem Beispiel sieht man, wie die Liste das MapReduce-Modell verwendet. Zuerst benutzt man Map der Quadratfunktion auf einer Eingangsliste für die Quadratfunktion, da sie abgebildet ist, alle angelegten Eingaben und erzeugt eine einzige Ausgabe pro Eingabe, in diesem Fall (1, 4, 9 und 16). Additionsfunktion reduziert die Liste und erzeugt eine einzelne Ausgabe von 30, der die Summe aller Eingänge ist.

Google nutzte die Leistung von MapReduce, um einen Suchmaschinen-Markt zu dominieren. Das Paradigma kam in der 19. Websearch-Engine zum Einsatz und etablierte sich innerhalb weniger Jahre und ist bis heute noch relevant. Google verwendete MapReduce auf verschiedene Weise, um die Websuche zu verbessern. Es wurde verwendet, um den Seiteninhalt zu indexieren und ein Ranking über die Relevant einer Webseite zu berechnen.

Dieses  Beispiel  zeigt  uns  den MapReduce-Algorithmus, mit dem Google Wordcount auf Webseiten ausführte. Die Map-Methode verwendet als Eingabe einen Schlüssel (key) und einen Wert, wobei der Schlüssel den Namen des Dokuments darstellt  und  der  Wert  der  Kontext  dieses Dokuments ist. Die Map-Methode durchläuft jedes Wort im Dokument und gibt es als Tuple zurück, die aus dem Wort und dem Zähler 1 besteht.

Die   Reduce-Methode   nimmt   als   Eingabe auch  einen  Schlüssel  und  eine  Liste  von  Werten an, in der der Schlüssel ein Wort darstellt. Die  Liste  von  Werten  ist  die  Liste  von  Zählungen dieses Worts. In diesem Beispiel ist der Wert 1. Die Methode “Reduce” durchläuft alle Zählungen. Wenn die Schleife beendet ist, um die Methode zu reduzieren, wird sie als Tuple zurückgegeben, die aus dem Wort und seiner Gesamtanzahl besteht.

 

A quick primer on TensorFlow – Google’s machine learning workhorse

Introducing Google Brains‘ TensorFlow™

This week started with major news for the machine learning and data science community: the Google Brain Team announced the open sourcing of TensorFlow, their numerical library for tensor network computations. This software is actively developed (and used!) within Google and builds on many of Google’s large scale neural network applications such as automatic image labeling and captioning as well as the speech recognition in Google’s apps.

TensorFlow in bullet points

Here are the main features:

  • Supports deep neural networks – and much more machine learning approaches
  • Highly scalable across many machines and huge data sets
  • Runs on desktops, servers, in cloud and even mobile devices
  • Computation can run on CPUs, GPUs or both
  • All this flexibility is covered by a single API making the execution very streamlined
  • Available interfaces: C++ and Python. More will follow (Java, R, Lua, Go…)
  • Comes with many tools helping to build and visualize the data flow networks
  • Includes a powerful gradient based optimizer with auto-differentiation
  • Extensible with C++
  • Usable for commercial applications – released under Apache Software Licence 2.0

Tensor, what? Tensor, why?

„Numerical library for tensor network computations“ maybe doesn’t sound too exciting, but let’s  consider the implications.

Application of tensors and their networks is a relatively new (but fast evolving) approach in machine learning. Tensors, if you recall your algebra classes, are simply n-dimensional data arrays (so a scalar is a 0th order tensor, a vector is 1st order, and a matrix a 2nd order matrix).

A simple practical example of is color image’s RGB layers (essentially three 2D matrices combined into a 3rd order tensor). Or a more business minded example – if your data source generates a table (a 2D array) every hour, you can look at the full data set as a 3rd order tensor – time being the extra dimension.

Tensor networks then represent “data flow graphs”, where the edges are your multi-dimensional data sets and nodes are the mathematical operations on this data.

Example of of a data flow graph with multiple nodes (data operations). Notice how the execution of nodes is asynchronous. This allows incredible scalability across many machines. Image Source.

Looking at your data through the tensor formalism gives you a lot of powerful tools that were already developed for tensor algebra, allowing fast, complex computations.  

Tensor networks are also a natural fit for computations done on graphical processing units (GPUs) as they are built exactly for the purpose of very fast numerical operations on such a data – speeding up your calculations significantly compared to standard CPU execution!

The importance of flexible architecture & scaling

The data flow graph approach has also further advantages. Most notably, you can split the design of your data flows (i.e. data cleaning, processing, transformations, model building etc.) from its execution. You first build up the graph of your data flow and then you send it to for execution: either on the CPUs of your machines (and it can be your laptop just as well as cluster) or GPUs or a combination. This happens through a single interface that hides all the complexities from you.

Since the execution is asynchronous it scales across many machines and can deal with huge amounts of data.

You can count on the Google guys to build tools not only for academic use, but also heavy-duty operations in the industry!

Is this just another deep learning library?

TensorFlow is of course not the first library to embrace the tensor formalism and GPU execution. The nearest comparisons (and competitors) are Theano, Torch and CGT (Caffe to a limited degree).

While there are significant overlaps between the libraries, TensorFlow tries to provide a broader framework. It is not only a deep learning library – the Data Flow Graphs can incorporate any data processing/analysis applications. It also comes with a very powerful gradient based optimizer with automatic calculations of derivatives offering huge flexibility.

Given this broad vision the closest competitor is probably Theano (while Caffe and the existing Theano wrappers have a narrower focus on deep learning). TensorFlow’s distinguishing feature is that by design its focus is on large, scalable architectures with a complete flexibility in the hardware, best suited for industry/operational use, whereas the other libraries have more academic pedigrees.

Initial analyses also indicate that TensorFlow should bring also performance improvements compared to Theano, although no comprehensive benchmarks have yet been published.

As the other packages are out already for a while, they have large, active communities and often additional supporting software (examples are the very useful wrappers around Theano like Lasagne, Keras and Blocks that provider higher level abstractions to its engine).

Of course, with Google’s gravitas, one can expect that TensorFlow’s open source community will grow very fast and the contributors will quickly add a lot of additional features (and find hidden bugs).

Finally, keep in mind, that while Google provided us with this great data processing framework and some of its machine learning capabilities, it is likely that the most powerful machine learning algorithms still remain Google’s proprietary secret.

Nonetheless, TensorFlow is a huge and very welcome contribution to the open source machine learning world!

Where to go next?

You can find Google’s getting started guide here. The TensorFlow white paper is worth a read too. Source code can be found at the Github page. There is also a Vagrant virtual machine with TensorFlow pre-installed available here.

Events

Nothing Found

Sorry, no posts matched your criteria