Data Science und Business Intelligence – Abgrenzung und Unterschied

(Last Updated On: 5. April 2018)

Data Science und Business Intelligence teilen viele Gemeinsamkeiten. Beides beschreibt Ansätze zur Gewinnung von Business Insights, also Einsichten in die Geschäftsentwicklung, durch die Analyse von Informationen. Ziel dieser Methodiken ist die Förderung gut durchdachter Geschäftsentscheidungen. Dabei werden verschiedene Techniken eingesetzt. Man unterscheidet Techniken

  • zur Erhebung von Daten
  • zur kostengünstigen Speicherung von Daten
  • zur Bereinigung von Daten. Beispielsweise werden hier statistische Ausreißer oder inkonsistente und daher wenig aussagekräftige Daten entfernt.
  • zur effizienten Suche und Zusammenfassung von relevanten Daten.
  • Zur Analyse der Daten, um daraus Wissen zu generieren. Hierbei unterscheidet man zwischen Methoden zur Erkennung neuer Muster (z. B. Data Mining) und zur Wiedererkennung bekannter Muster (z. B. Machine Learning).
  • zur ansprechenden und performanten Visualisierung der Daten.

In diesem Beitrag werde ich versuchen, den Unterschied der beiden Ansätze besser verständlich zu machen.

Business Intelligence funktioniert allgemein nach dem folgenden Prinzip: In einem zentralen Data Warehouse werden die Daten verschiedener Umsysteme gesammelt. Diese Umsysteme sind beispielsweise Buchhaltungs-, Kundenbeziehungs- und Produktionsplanungs-Systeme, die Geschäftsdaten aus dem operativen Geschäftsbetrieb beinhalten. Diese Umsysteme werden häufig als transaktional orientierte Systeme bezeichnet, bekannt unter dem Kürzel Online-Transactional Processing (OLTP). Das Data Warehouse sammelt die Daten aus diesen Systemen, um sie an einem zentralen Ort für die Analyse zu nutzen. Das Data Warehouse ist ein für die Analyse von Daten zugeschnittener Datentopf. Data Warehouse Systeme sind häufig bekannt unter dem Kürzel Online Analytical Processing (OLAP).

Beide Systeme, sowohl die transaktionsorientierten OLTP-Systeme, in denen die Geschäftsdaten erzeugt werden, als auch das analytische Data Warehouse, sind in der Regel klassische relationale Datenbanksysteme. Das können beispielsweise Datenbankmanagement-Systeme wie Oracle Database, MaxDB, SAP ASE, Microsoft SQL Server, IBM DB2 oder aber auch SAP HANA sein. Das heißt, wenn im Data Warehouse die Daten mehrerer Systeme vereint werden sollen, müssen die Datensätze dieser OLTP-Datenbanken in die OLAP-Datenbank überführt werden.

Es macht in der Regel keinen Sinn, die Daten aus den OLTP-Systemen 1:1 in das Data Warehouse zu kopieren. Dazu gibt es verschiedene Gründe

  • Nicht alle Daten aus den OLTP-Systemen sind für das Data Warehouse relevant
  • Einige der relevanten Daten verfälschen die Aussagefähigkeit der Daten (beispielsweise statistische Ausreißer)
  • Es ist nicht notwendig, jeden einzelnen Datensatz der OLTP-Datenbank in die OLAP-Datenbank zu kopieren. Für Analysen reicht es häufig, Aggregate in Form von Summen oder Mengen zu bilden
  • Die Daten liegen in den Quellsystemen häufig nicht in der Form vor, wie sie im Zielsystem benötigt werden. So können Daten beispielsweise angereichert oder miteinander kombiniert werden.
  • Es ist nicht notwendig, die Daten in der 3., 4. oder 5. Normalform zu halten, da auf analytischen Systeme keine Transaktionen wie etwa Buchungssätze oder Bestellung abgearbeitet werden. Deswegen werden Daten, die in das Data Warehouse geladen werden, entnormalisiert.

Der Transport dieser Daten geschieht klassischerweise in einem ETL-Prozess (Extract, Transform and Load). Die Daten werden aus den Quellsystemen extrahiert, dann in die gewünschte Zielform verarbeitet und abschließend in die Zieldatenbank des Data Warehouses geladen. Data Warehouse Datenbanken (OLAP) sind häufig spaltenorientiert, während transaktionale Datenbanken (OLTP) häufig zeilenorientiert sind. Die Spaltenorientierung begünstigt die kostengünstige Analysefähigkeit der Daten, die in der Datenbank gespeichert sind.

Im Data Warehouse werden dann statistische Methoden angewandt, um Analysen auf diese Daten durch zu führen. Das Endergebnis der Analysen im Business Intelligence Prozess sind häufig statistische Analysen und Visualisierungen dieser Ergebnisse in Form von Diagrammen zur Erkennung von Trends. Business Intelligence beantwortet häufig die Frage: „Was ist in der Vergangenheit passiert, und wie reagieren wir in Zukunft darauf?“ Natürlich sind, in beschränktem Maße, durch Extrapolation auch Aussagen über die Zukunft möglich. „Wo geht die Reise hin, auf Basis der Entwicklung des Diagramms?“

Fassen wir also kurz zusammen, die klassische Business Intelligence

  • Nutzt häufig strukturierte Daten aus relationalen OLTP-Datenbanken
  • Speichert diese ebenfalls strukturiert in einem Data Warehouse, einer OLAP-Anwendung
  • Analysiert diese Daten durch statistische Methoden
  • Beantwortet Fragen über die Vergangenheit oder die Gegenwart: „Was ist in der Vergangenheit passiert / Was passiert jetzt gerade?“
  • Stellt diese Ergebnisse visuell in Form von Reports und Diagrammen dar.

Kommen wir nun zum Begriff Data Science. Data Science wird häufig in Zusammenhang mit der Verarbeitung unstrukturierter oder semi-strukturierter Daten verwendet.

Unstrukturierte Daten sind beispielsweise klassische Binärdateien, wie etwa Audio- oder Video-Aufzeichnungen. Auch auf diese Binärdaten lassen sich beispielsweise Suchabfragen durchführen, um Muster zu erkennen. Ein klassisches Anwendungsbeispiel ist die Fingerabdruck-Datenbank im Krimi. Man versucht Anhand von Mustern Fingerabdrücke zu erkennen, die diesem Muster entsprechen. Aber auch Dokumente sind mit dem Stichwort unstrukturiert gemeint, da Text keiner festen Datenstruktur folgt. Dies schließt beispielsweise Office-Dokumente oder PDF-Dateien mit ein.

Semi-Strukturierte Daten sind Daten, die zwar einer Struktur folgen, jedoch keine Konsistenz-Beschränkungen (Constraints) auf diese Daten anwenden, wie es eine relationale Datenbank tun würde. Typischerweise sind semi-strukturierte Daten solche, die mit einer strukturierten Auszeichnungssprache wie XML oder JSON ausgezeichnet wurden. Im Gegensatz zu voll-strukturierten Daten erlauben diese Standards jedoch, dass die abgelegten Daten nicht jedes mal der selben Struktur folgen. So ist es beispielsweise erlaubt, ein Attribut in einem Datensatz weg zu lassen und im anderen wiederum zu definieren. Dies würde in einer relationalen Datenbank entweder zu einem Fehler führen oder dazu, dass die weg gelassenen Attribute einfach mit einem „null“-Wert belegt werden. Auch das Wechseln von Datentypen für ein Attribut ist möglich. So ist es in einer semi-strukturierten Datenhaltung beispielsweise möglich, für das Attribut „Alter“ nicht nur einen Integer-Wert, sondern auch einen String wie „130 (verstorben)“ anzugeben.

Die Fähigkeit, unstrukturierte und semi-strukturierte Daten zu verarbeiten, und dennoch Suchmethoden auf diese Daten anzuwenden, ist im Bereich der Big Data Verarbeitung wichtig. Denn die Eingangsdaten liegen hier häufig unstrukturiert oder semi-strukturiert vor. Portale wie Youtube oder Instagram haben häufig mit unstrukturierten Daten wie Binärdateien zu tun, Webcrawler fischen nach Informationen aus Social Media Plattformen, RSS-Feeds oder nackten Websiten, um diese dann semi-strukturiert in Form von JSON beispielsweise abzulegen. RPC-, Rest- und GraphQL-APIs von Geschäftspartnern und Behörden antworten ebenfalls häufig semi-strukturiert in Form von JSON oder XML.

All diese Daten müssen nun nicht nur gespeichert werden, sondern auch analysiert. Eine Analyse auf Daten durchzuführen, deren Struktur keinem einheitlichen Standard folgt, ist schwierig. So wird es beispielsweise schwierig:

  • Diese Daten kostengünstig zu speichern
  • Die Daten zu durchsuchen, um die relevanten Daten auszuwählen
  • Die Daten performant zu lesen, da das Datenwachstum exponentiell ansteigt,die Lesegeschwindigkeit von Datenträgern allerdings nur linear anwächst.
  • die Daten performant für Analysen zur Verfügung zu stellen, da es schwierig wird, Indizes auf diese Daten aufzubauen und diese in Blöcken im Arbeitsspeicher vorzuhalten.
  • Verarbeitungsschritte und Berechnungen auf diese Daten auszuwählen
  • Analyseprozeduren für diese unstrukturierten Daten zu bauen.

Um diese Probleme zu lösen, gibt es verschiedene Lösungsansätze und Technologien. Buzzwords in diesem Umfeld sind beispielsweise Apache Hadoop mit HDFS und MapReduce, um die Verarbeitung zu den Daten zu bringen und die Daten parallel lesen und verarbeiten zu können, anstatt dies linear zu erledigen. Passende Datenbank-Engines für Volltextsuche (Lucene, SolR), Zeitreihenspeicherung (SAP Vora, OpenTSDB), Wide Column Stores (Cassandra, HBase), Graphen (Neo4j, SAP Vora), JSON-Dokumente (MongoDB, PostgreSQL) sowie die in-Memory-Zwischenablage häufig benötigter Daten (SAP Vora, SAP HANA) sollen den kostenoptimierten Zugriff auf die verteilt gespeicherten Daten ermöglichen. Wichtig in diesem Zusammenhang ist die Wahl der passenden Storage Engine im Zusammenhang mit dem CAP-Theorem. CAP steht für Consistency, Availability und Partition Tolerance der in einer Storage-Engine gespeicherten Daten. Man kann immer nur zwei der gewählten Ziele erreichen. In der Praxis führt dies in großen Big Data Szenarien dazu, dass man mehrere Storage-Engines für verschiedene Schreib- und Lesezwecke benötigt. Man spricht von einer „Polyglot Persistence“. Man hält Daten also in mehreren Speicher-Engines bereit, um sie je nach Anwendungszweck im optimalen Zielformat vorzuhalten.

Während Business Intelligence auf die Daten klassischerweise rein statistische Analysemethoden anwendet, wendet Data Science Analysemethoden wie Natural Language Processing (NLP), Machine Learning und Graphenanalyse an. Diese Analyseverfahren sind predictive, man versucht also einen „Educated Guess“ auf Basis der vorliegenden Daten über die Zukunft vorzunehmen. Data Science beantwortet also Fragen wie „Auf Basis der Daten die wir haben, was passiert am wahrscheinlichsten in der Zukunft?“. Fassen wir also zusammen, Data Science

  • Nutzt häufig unstrukturierte und semi-strukturierte Daten wie XML, JSON, Volltext und Binärdaten
  • Speichert diese Daten in der Regel in verschiedenen verteilten Storage-Engines, mitunter auch mehrfach, um die Daten für den jeweiligen Anwendungszweck performant und dabei möglichst kostengünstig verarbeiten zu können
  • Analysiert diese Daten durch statistische Methoden, Natural Language Processing (NLP), Machine Learning und Graphenanalyse.
  • Beantwortet Fragen über die Zukunft: „Was wird am wahrscheinlichsten passieren, und wie beeinflussen wir das?“
  • Stellt diese Ergebnisse visuell dar.

 

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.