DataLakes & DataWarehouses: Wie sie im SEO verwendet werden

Veröffentlicht: 2021-02-16

Obwohl die Begriffe DataWarehouses und DataLakes längst Teil der Alltagssprache von Data Analysts und Data Scientists geworden sind, hört man in anderen Branchen erst seit einigen Jahren davon.
Zum Beispiel beginnen Webanalysten und SEO-Experten, sich ernsthaft mit diesen Konzepten zu befassen, aufgrund der Art ihrer Arbeit und der starken Verbindung, die zwischen ihrer Tätigkeit und der Datenmanipulation besteht. Viele neuere Artikel sprechen über das Interesse an der Implementierung eines SEO DataLake oder eines SEO DataWarehouse, wobei die beiden Begriffe als austauschbar behandelt werden und kein Unterschied zwischen den beiden gemacht wird.

In diesem Artikel führen wir Sie durch die Bestimmung der Unterschiede zwischen DataLakes und DataWarehouses, um ihre Zwecke und ihre Anwendungsfälle in SEO und Webanalyse zu verstehen.

DataWarehouse: strukturiertes Lagerhaus für Daten

Die erste Verwendung des Begriffs „DataWarehouse“ stammt aus dem Jahr 1988 in einem Artikel von Paul Murphy und Barry Delvin, An architecture for a business and information systems . Dieser Artikel gibt uns eine erste Definition des Konzepts als leicht zugängliche, relationale Datenbankumgebung, die alle Geschäftsdaten zusammenführt, die für die strategische Entscheidungsfindung nützlich sind.

Was beinhaltet ein DataWarehouse?

Das DataWarehouse wird verwendet, um die Geschäftsdaten, die für die strategische Entscheidungsfindung des Unternehmens nützlich sind, an einem einzigen Ort zu sammeln. Wir sprechen von Geschäftsdaten, die von Kundendaten über Bestandsinformationen bis hin zu Conversions auf einer kommerziellen Website oder organischen Besuchen (z. B. von einer Suchmaschine wie Google) reichen können.

Es ist allgemein anerkannt, dass die an ein DataWarehouse gesendeten Daten strukturierte, vorverarbeitete Daten sind, die zum Auslagern von Betriebsdatenbanken verwendet werden, was letztendlich ermöglicht, dass diese Betriebsdatenbanken so wenig wie möglich für Abfragezwecke angefordert werden.
Das Hauptziel eines DataWarehouse und derjenigen, die es verwalten, besteht darin, Daten aus verschiedenen, heterogenen Quellen (sowohl intern als auch extern) zusammenzuführen, um sie zu standardisieren, damit die verschiedenen Quellen miteinander kommunizieren können. Das Endziel ist es, diese Daten zu verwenden, um Analysen, Berichte, Entscheidungshilfen usw. durchzuführen.

Wer sind die täglichen Nutzer eines DataWarehouse?

Aufgrund der Art des DataWarehouse und des Formats und der Art der darin enthaltenen Daten ist es eine ideale Spielwiese für Daten- und Webanalysten.
Datenanalysten arbeiten mit dem DataWarehouse-Administrator (oder dem Verwaltungsteam) zusammen. Sie definieren die Geschäftsanforderungen und Anwendungsfälle. Sie identifizieren die Datenquellen und die Maßnahmen, die zur vorgelagerten Verarbeitung der Daten erforderlich sind. Diese Daten werden dann von den Datenanalysten am Ende der Kette verwendet.

Wie kommunizieren Benutzer mit einem DataWarehouse?

Sobald die Datenquellen identifiziert und die Daten im DataWarehouse verarbeitet, aufgenommen und verknüpft wurden, kann der Datenanalyst diese Daten in Analysen verwenden und neue Datenkombinationen erstellen. Dieser Prozess kann verwendet werden, um Berichts-Dashboards, Warn-Dashboards usw. zu verwalten.

Die am häufigsten verwendete Programmiersprache für Abfragen in einem DataWarehouse ist SQL (oder SQL-ähnliche Sprachen). SQL ermöglicht es Datenanalysten, Daten zu manipulieren und zu verarbeiten, um Geschäftsanforderungen zu erfüllen: Überwachung, strategische Entscheidungsfindung usw.

Welche Anwendungsfälle und Projekttypen dienen DataWarehouses?

Es ist unmöglich, eine vollständige Liste von Anwendungsfällen zu erstellen, bei denen ein DataWarehouse zum Einsatz kommt. Hier sind jedoch einige Beispiele für Projekte, an denen ein Datenanalyst wahrscheinlich arbeiten wird:

Verbesserung eines DataWarehouse:
Diese Art von Projekt wird häufig beim Aufbau eines DataWarehouse angetroffen, aber auch, wenn ein neuer Bedarf oder Geschäftsanwendungsfall identifiziert wird.
Hier geht es darum, einem DWH neue Daten hinzuzufügen (wiederum können dies interne oder externe Daten sein).
In diesem Fall sprechen wir oft von einem ETL-Prozess (Extraction-Transformation-Loading):

  • Extraktion:
    Ein erster Schritt besteht darin, Daten aus den verschiedenen Quellen zu identifizieren und zu sammeln, die für weitere Operationen benötigt werden.
  • Transformation:
    Dieser zweite Schritt ist sehr wichtig, denn ohne Anpassung, ohne Standardisierung ist es im Allgemeinen unmöglich, neue Daten zu verwenden und sie mit den bereits im DWH vorhandenen Daten zu kommunizieren.
    Es ist daher eine Phase der notwendigen Standardisierung, die manchmal durch die durch das DWH auferlegte Starrheit in Bezug auf Formatierung und Tabellenschema erschwert werden kann.
  • Wird geladen:
    Aufnahmephase der verarbeiteten (und damit strukturierten) Daten in das DWH.

Durchführung statistischer Auswertungen:
Dies ist eine sehr häufige Verwendung von DWHs. Das Ziel kann sein, X oder Y durch die Daten zu beweisen, Statistiken auf der Grundlage der verfügbaren historischen Daten zu erstellen oder kausale Zusammenhänge herzustellen, um einen Befund zu erklären usw.
Berichterstattung & Alarmierung:
Dies ist wieder einmal ein sehr häufiger Anwendungsfall. Da die Daten in einem DWH hochgradig strukturiert und formatiert sind (ein festes und vordefiniertes Schema gemeinsam nutzen), ist alles geeignet, um Daten an Berichts- oder Warn-Dashboards weiterzuleiten.

Dies ist eine wiederkehrende Anforderung des Top-Managements, das in der Lage sein muss, operative Teams und den Zustand von Ergebnissen, Verkäufen usw. so einfach und schnell wie möglich zu überwachen.

Wenn wir all dies zusammenfassen, haben wir mehr oder weniger 2 Arten von Projekten: Datenerfassungs- und Integrationsprojekte (die auch mit einer Form der Datenspeicherung und -historisierung verglichen werden können) und Datenanalyse- und -auswertungsprojekte (durch Überwachung/Dashboarding und Alarmierung ).

Der Begriff eines DWH ist in der Alltagssprache derer, die mit Daten arbeiten, schon lange präsent. Die Funktionsweise und die zahlreichen Use Cases sind längst bestätigt und DWHs sind in vielen Unternehmen mit unterschiedlichem Reifegrad zu finden, wenn es um Fragen des Datenmanagements geht.

Dies gilt weniger für das Konzept der DataLakes, das viel jünger und viel weniger verbreitet ist.

Oncrawl-Daten³

Erweitern Sie Ihre Analyse mit nahtlosen Verbindungen zu zusätzlichen Datensätzen. Analysieren Sie Ihre SEO-Strategie basierend auf Daten zu Backlinks, SEO-Traffic, Rankings und benutzerdefinierten Datensätzen aus Ihrem CRM, Ihrer Überwachungslösung oder einer anderen Quelle.
Mehr erfahren

DataLake: Megadatensee (BigData)

Der Ursprung dieses Konzepts wird James Dixon, CTO von Penthao, zugeschrieben, der es als eine Lösung zur Speicherung und Nutzung großer Datenmengen definiert, ohne Vorverarbeitung und ohne unbedingt einen bestimmten Anwendungsfall … Im Gegensatz zu DWHs, die sehr stark orientiert sind hin zur sofortigen Aktivierung.
Die DL versucht, die mit dem Aufkommen von BigData immer wichtiger werdende Lücke zu füllen, was mit all diesen Datenmassen zu tun ist, die wir heute sammeln können, und wie wir sie nutzen können.

Was beinhaltet ein DataLake?

Ich beginne damit, James Dixon zu zitieren, der einen sehr eindrucksvollen Vergleich verwendet, der sowohl als Erklärung für den „See“-Namen seines Konzepts als auch als Abgrenzung zum DWH dient:

„Wenn Sie sich einen Datamart als Speicher für abgefülltes Wasser vorstellen – gereinigt und verpackt und für den einfachen Verbrauch strukturiert – ist der Datensee ein großes Gewässer in einem natürlicheren Zustand. Der Inhalt des Datensees fließt von einer Quelle ein, um den See zu füllen, und verschiedene Benutzer des Sees können kommen, um Proben zu untersuchen, einzutauchen oder Proben zu nehmen.“

Dieses Zitat veranschaulicht perfekt den Unterschied zwischen der Art von Daten, die in einem DWH enthalten sind, das in Tabellen mit präzisen, festen Mustern strukturiert und organisiert ist, und der Art von Daten, die in einem DataLake enthalten sind, der roh, ohne vorherige Verarbeitung, zur Verfügung steht Proben von nach Bedarf, ob explorativ oder nicht.

Wo ein DWH darauf beschränkt ist, strukturierte Daten aufzunehmen, ist der DataLake darauf ausgelegt, alle Arten von Rohdaten (strukturiert oder nicht) zu speichern. Eine Debatte zwischen Tamara Dull (Amazon Web Service) und Anne Buff (Microsoft SAS) gibt uns eine etwas konkretere Vorstellung vom Inhalt eines DataLakes:

„Ein Data Lake ist ein Speicherort, der eine große Menge an Rohdaten in seinem nativen Format enthält, einschließlich strukturierter, halbstrukturierter und unstrukturierter Daten. Datenstruktur und Anforderungen werden erst definiert, wenn die Daten benötigt werden.“

Wer sind die täglichen Benutzer von DataLakes?

Wo ein Datenanalyst perfekt geeignet war, um mit den in einem DHW enthaltenen strukturierten Daten zu arbeiten, sind Rohdaten stattdessen die Spezialität von Datenwissenschaftlern, die oft besser gerüstet sind, um diese Art von Daten zu manipulieren.
Diese Änderung des Datenprofils und des Hauptbenutzers führt auch zu unterschiedlichen Programmiersprachen und Anwendungsfällen.

Welche Anwendungsfälle und Projekttypen bedient DataLakes?

Aufgrund seiner Unstrukturierung und der beträchtlichen Datenmenge, die ein DataLake enthalten kann, können sich die Anwendungsfälle stark von denen unterscheiden, die zuvor im DWH-Framework gefunden wurden, zum Beispiel:

  • Die Implementierung von Machine-Learning-Algorithmen zur Schaffung von Mehrwert für BigData:
    Wir sprechen hier oft von prädiktiver Analyse, basierend auf maschinellen Lernalgorithmen, die alle Arten von Daten ausnutzen.
    Um ein konkreteres Beispiel zu nehmen, stellen wir uns vor, dass ein Unternehmen der Finanzbranche (Banken & Versicherungen) die Wahrscheinlichkeit bestimmen möchte, dass eine Finanztransaktion X betrügerisch ist. Dies kann Data Scientists in Anspruch nehmen, die in der Lage sind, maschinelle Lernalgorithmen zu erstellen, die mit der astronomischen Datenmenge trainieren, die im DataLake enthalten ist (Menge, Datum, Häufigkeit, übliches Profil der vom Kontoinhaber durchgeführten Transaktionen usw.). Das Ziel ist die Durchführung einer prädiktiven Studie, die verwendet wird, um potenziell betrügerische Transaktionen zu identifizieren und es dem Unternehmen so zu ermöglichen, seine Reaktionszeit bei der Erkennung zu verkürzen und letztendlich große Verluste für sich und seine Kunden zu vermeiden.
    Dies ist ein einfaches Beispiel, das regelmäßig verwendet wird, um das Interesse und den Mehrwert des maschinellen Lernens zu veranschaulichen, aber es gibt so viele andere, wie Sie sich vorstellen können.
  • DataLakes als Datenquelle für ein DataWarehouse:
    Ganz einfach, ein DataLake kann als Transitzone zwischen Ihren verschiedenen internen und externen Datenquellen und Ihrem DWH fungieren. Das eigentliche Prinzip eines DataLakes besteht darin, alle Arten von Daten, strukturiert oder unstrukturiert, zu zentralisieren, um prädiktive Studien über ML durchzuführen oder als Proben für die Analyse zu extrahieren. Das DWH scheint daher für diese zweite Kategorie von Projekten sehr geeignet und profitiert von einem DataLake als potenzieller Quelle (vorausgesetzt, die DataLake-Daten werden strukturiert über eine Vorverarbeitung importiert, falls erforderlich).
  • Von DataLake zu BI (Business Intelligence) Software:
    Wir können dies als eine ähnliche Verwendung wie bei DataWarehouses sehen, obwohl es bestimmte Besonderheiten bei der Verwendung eines DataLake für diesen Zweck gibt. Mit einem DataLake können Sie etwas exotischere Visualisierungen (aufgrund der Vielfalt der darin enthaltenen Daten) über Tools wie Tableau, Qlikview, Google Data Studio, Microstrategy usw. erstellen.

Wie kommunizieren Benutzer mit einem DataLake?

Angesichts der Anwendungsfälle und Benutzer (Data Scientists) finden wir sehr oft Programmiersprachen wie Python, Java, R, Scala usw.
Diese Sprachen sind größtenteils schon lange im Bereich Data Science präsent.

Ein DataLake ist also ein Werkzeug zur Verwaltung von BigData. Es stützt sich auf die massive Speicherung von Rohdaten für erweiterte Analyse- und Visualisierungszwecke und ermöglicht so die Verbesserung von Daten, die zuvor nicht viel genutzt wurden.

Zusammenfassend ist hier eine Tabelle der Unterscheidungsmerkmale, die sich seit Beginn dieses Artikels etabliert haben:

DataWarehouse DataLake
Art der Daten Strukturierte, vorverarbeitete Daten, organisiert in Tabellen mit definierten Schemata Rohdaten, strukturiert oder unstrukturiert gespeichert
Benutzer Datenanalysten, Webanalysten Datenwissenschaftler
(manchmal Datenanalysten)
Datenvolumen Klein groß
(Je nach Bedarf und Anwendungsfall)
Potenziell sehr groß
(Große Daten)
Verwendete Programmiersprache SQL oder SQL-ähnlich Python, R, Java, Scala und andere
Art des Projekts Analytische und statistische Projekte, Berichterstellung, Alarmierung, Projekte vom Typ ELT (Exportieren, Transformieren, Laden), einige prädiktive und datengesteuerte Analysen Vorausschauende Analyse, maschinelles Lernen, Übergangszone zwischen Datenquellen und DWH, erweiterte Visualisierung – BI, datengesteuerte Analyse

Vorausschauende Analyse, maschinelles Lernen, Übergangszone zwischen Datenquellen und DWH, erweiterte Visualisierung – BI, datengesteuerte Analyse

Es sind diese Unterschiede, die diese beiden Konzepte zu komplementären Werkzeugen machen. In vielen Fällen verlassen sie sich je nach Reifegrad der Governance und des Datenmanagements eines Unternehmens möglicherweise auf eine Kombination dieser beiden Tools.
Ein DWH wird hauptsächlich für die traditionelle Berichterstattung und Analyse verwendet, während ein DataLake als Datenquelle dient, bevor es sein volles Potenzial ausschöpft, wenn das Unternehmen sich der Reife der Datensubjekte nähert.

DataLakes sind meiner Meinung nach eher eine Antwort auf die neuen Datenthemen des 21. Jahrhunderts, insbesondere mit dem Aufkommen von BigData und der zunehmenden Fähigkeit von Unternehmen, Daten zu sammeln, als ein Ersatz für DWHs, wie manche vielleicht denken.
Beide haben ihre Vorteile, Nachteile, Stärken und Schwächen. Der beste Weg, das Beste aus beiden herauszuholen, ist nach wie vor, beide zusammen zu verwenden, um mit allen Eventualitäten fertig zu werden und eine größere Bandbreite an Anforderungen zu erfüllen.

Nachdem wir die Konzepte klar definiert haben, konzentrieren wir uns schließlich auf die Verwendung von DataWarehouses und DataLakes für das Marketing und insbesondere für SEO (auch wenn in vielen Fällen das, was für ersteres gilt, auch für letzteres gilt, und umgekehrt umgekehrt).

DataWarehouse und DataLake SEO

Wir sprechen hier von einem DataWarehouse oder einem DataLake (oder beiden), wo zumindest ein Teil der vorhandenen Daten für SEO-Anwendungsfälle verwendet werden kann.

Warum DataLakes und DataWarehouses mit Marketing und SEO in Verbindung bringen?

SEO (und allgemein Marketing) hat in den letzten Jahren bereits eine sehr deutliche Hinwendung zu Daten genommen. Immer mehr Aufgaben erfordern den Einsatz verschiedener Datenquellen:

  • Analytische Daten (Google Analytics, AT Internet usw.)
  • Leistungsdaten (Google Search Console, Analytics)
  • Protokolldaten, eine sehr große Datenquelle für einige Websites, die eine hohe Aktualisierungsfrequenz und eine große Speicherkapazität erfordern.
  • Netlinking-Daten (Majestic, Ahrefs, Babbar)
  • Positionsdaten (SEMRush, Monitorank usw.)
  • Crawling-Daten (OnCrawl etc.)
  • Manchmal auch Geschäfts-/Branchendaten

Zu dieser Liste sollten wir auch die Verwendung von APIs von Tools wie Search Console, Majestic, Google Analytics hinzufügen, was uns natürlich zu den weiter oben in diesem Artikel beschriebenen Lösungen führt.
Es ist diese starke Verbindung zwischen SEO und Daten, die immer mehr Webanalysten und SEO-Experten dazu bringt, sich über neue Möglichkeiten zur Organisation ihrer Datenpipeline zu informieren.

Die Treiber für diesen Übergang sind jedoch nicht nur das Potenzial und die Vernetzung von SEO und Daten. Viele alltägliche Anwendungsfälle stimmen mit den oben aufgeführten Projekttypen für DWHs und DLs überein.

Die Anwendungsfälle eines SEO DataWarehouse oder eines SEO DataLake.

Ich werde zunächst mit Schmerzpunkten beginnen, auf die SEO-Experten häufig stoßen, bevor ich erkläre, wie die Verwendung eines DataLake oder eines DataWarehouse eine Antwort ist, die berücksichtigt werden muss, wenn sie angegangen werden.
Unter den wichtigsten Schmerzpunkten stechen die folgenden hervor:

  • Die Vervielfältigung von Excel-Dateien (das Loseblatt unserer Dekade) und das damit verbundene Copy-and-Paste:
    Für viele SEOs ist dies immer noch die Norm, aber seien wir ehrlich, es ist sowohl zeitaufwändig, einschränkend als auch sehr förderlich für menschliches Versagen. Dafür ist ein DataWarehouse eine perfekte Lösung. DataWarehouses ermöglichen es nicht nur, alle für die Durchführung dieser oder jener Audits/Analysen erforderlichen KPIs aus den verschiedenen verfügbaren Datenquellen zu sammeln, sondern auch die Verarbeitung zu automatisieren, die erforderlich ist, um das erwartete Ergebnis zu erzielen.
    Während ein DataWarehouse aufgebaut wird, werden immer mehr Anwendungsfälle identifiziert und immer mehr Probleme gelöst, was im Laufe der Zeit zu immer größeren Zeiteinsparungen führt.
  • Kapazitätsgrenzen (zur Erinnerung: Excel kann eine ganze Datei nur öffnen, wenn sie 1.048.576 Zeilen nicht überschreitet. Das scheint viel zu sein, ist es aber in den heutigen Bänden nicht wirklich): Hier gibt es nicht wirklich einen bestimmten Anwendungsfall, denn in Im Allgemeinen leiden sowohl DataLakes als auch DataWarehouses nicht unter dieser Art von Begrenzung. Beide bieten die Möglichkeit, große Datenmengen für jede Art von Bedarf anzufordern. Für diesen konkreten Fall ist es wichtig zu bedenken, dass je nach Bedarf das eine oder andere es Ihnen ermöglicht, sich von Kapazitätsgrenzen zu befreien und diese Situationen letztendlich leichter zu meistern.
  • Reagieren Sie auf den Bedarf an Datenhistorisierung
    Spoiler: Einer der Anwendungsfälle kann beispielsweise darin bestehen, einen Verlauf der Daten aus der Google Search Console in einem SEO DataWarehouse zu speichern, anstatt die Daten jede Woche in ein Google Sheet zu kopieren und zu pausieren, um ein Data Studio-Dashboard zu pflegen.In Meiner Meinung nach haben wir hier einen der häufigsten Anwendungsfälle unter SEO-Experten, egal ob in Agenturen oder Inhouse: Datenhistorisierung. Tatsächlich schauen sich viele SEO-Analysten historische Daten an und ziehen daraus Schlüsse.
    Das Beispiel, das Ihnen vielleicht direkt in den Sinn gekommen ist, ist der Fall der Google Search Console. Es bietet heute nur Zugriff auf 16 Monate Verlauf (sogar über API). Und wenn ein manueller Rückstand durch Exporte, die jede Woche in Google Sheets eingefügt werden (oder andere obskure Methoden), möglich bleibt, ist dies eine erhebliche Zeitverschwendung, zusätzlich dazu, dass es schmerzhaft und langweilig ist.
    Das ist eine gute Sache, denn es ist ein relativ einfaches Problem, das mit einem DataWarehouse angegangen werden kann. Sie müssen lediglich eine automatische Verbindung zur Google Search Console API einrichten, die verschiedenen möglichen Vorverarbeitungen und Datenkombinationen definieren, die erforderlich sind, um Daten mit echtem Mehrwert zu erhalten, und schließlich die API-Aufrufe automatisieren.
  • Der Wunsch, Analysen weiterzuentwickeln, Crawl-Daten, Zielgruppendaten, Protokolle usw. auf industrialisierte Weise zusammenzuführen oder „kreuzweise zu analysieren“.
    Denn ein kleiner Wettbewerbsvorteil schadet nie. Unsere Beschreibungen zu einem DataWarehouse und einem DataLake sprechen hier für sich. Eines der Hauptziele beider Tools ist die Erschließung neuer Analysemöglichkeiten durch Datenerhebung und Cross-Analyse und/oder maschinelles Lernen.
    Um nur ein sehr repräsentatives Beispiel zu nennen; die Verwendung von maschinellen Lernalgorithmen wie Random Forest oder XG-Boost, um Ranking-Vorhersagen bei Google zu treffen.
    Die Idee besteht ganz einfach darin, einen Algorithmus auf einer großen Anzahl von Google-SERPs (Ergebnisseiten) und allen für diese SERPs erfassbaren SEO-Metriken zu trainieren, um auf der Grundlage derselben Metriken das Ranking-Potenzial einer bestimmten URL (und daher insbesondere, um die wichtigsten Metriken für die Rangfolge in einem bestimmten Sektor/Thema zu bestimmen).
    → Die vollständige Methodik finden Sie in dem Artikel von Vincent Terrasi, Product Director bei Oncrawl, „Successulating Google Rankings at the Cutting Edge of Data Science“ , 2018.
  • Der Wunsch, das Reporting so weit wie möglich zu automatisieren, um sich auf Aufgaben mit hoher Wertschöpfung zu konzentrieren. Auch dies fällt buchstäblich in die klassischen Anwendungsfälle eines DataWarehouse. Es bietet die Möglichkeit, die gesamte Wiederherstellung und Verarbeitung der verschiedenen Datenquellen zu automatisieren, und adressiert diesen Schmerzpunkt perfekt. Einmal eingerichtet, wird eine Tabelle automatisch in das DWH eingespeist und kann als Verbindung zu BI-Software für das Dashboarding genutzt werden, sei es für Monitoring, Alerting etc. Selbstverständlich hört die Automatisierung nicht nur beim Reporting von Projekten auf. Sowohl ein DWH als auch ein DL können für viele automatisierte SEO-Optimierungen verwendet werden. Zum Beispiel dynamische Aktualisierungen interner Linkblöcke zu Rang, Crawl-Budget, SEO-Zielgruppe usw. (alle Daten im DWH enthalten).
  • Der Wunsch, Sicherheitsbedenken ein für alle Mal ein Ende zu bereiten (wir wissen, wer was getan hat und wo sie zu finden sind) und Zeitaufwand für die Wartung zu vermeiden. Wir beenden hier streng genommen einen eher prozessorientierten Aspekt als einen Anwendungsfall.
    Sowohl DataLakes als auch DataWarehouses implizieren die Implementierung bestimmter Prozesse, die auf folgende vereinfachte Weise dargestellt werden können:

    • Ausgangspunkt ist eine Beobachtung, die in ein Statement of Needs heruntergebrochen wird (Business Team / SEO – Data Analyst).
    • Anschließend wird dies in eine eher technische Spezifikation umgewandelt, die es dem Team, das das Tool verwaltet, ermöglicht, zu verstehen, was getan werden muss und wie es getan werden muss.
    • Dasselbe Verwaltungsteam führt die Anfrage aus.
    • Das Geschäftsteam und die Datenanalysten erstellen einen prozeduralen Anwendungsfall für die durchgeführte Arbeit.
    • Es gibt einen fortlaufenden Prozess, bei dem die beiden Enden der Kette (Business-Team und Verwaltungsteam des DataWarehouse oder DataLake) sicherstellen, dass sich in Bezug auf Input und Output nichts ändert.
      Dies gilt insbesondere für ein DWH, das alle Daten zurückweist, die nicht Teil der Struktur (des vordefinierten Schemas) sind.

Auch dies ist eine nicht erschöpfende Liste von Schmerzpunkten und möglichen Anwendungsfällen für DataWarehouse – DataLake SEO. Grenzen finden sich eher in der Vorstellungslosigkeit derer, die sie benutzen, als in den Werkzeugen selbst.

Auswahl eines DataWarehouse oder DataLake für Ihre SEO-Anwendungen

Zusammenfassend lässt sich sagen, dass DataWarehouses und DataLakes im Gegensatz zu dem, was Sie oft hören oder lesen, separate Strukturen für die Datenspeicherung und -erfassung sind und nicht inkompatibel sind. Man muss sich nicht für eines entscheiden, ganz im Gegenteil. Beide haben unterschiedliche Anwendungsfälle und es gibt sogar einige Anhaftungen.

Der Fall von SEO ist ein aufschlussreiches Beispiel und verstärkt die Notwendigkeit von DataWarehouses und DataLakes im Allgemeinen. Daten sind im SEO allgegenwärtig: Wir müssen riesige Datenmengen aus verschiedenen Quellen manipulieren. So ist es nicht verwunderlich, dass wir in diesem Zusammenhang von DataWarehouses und DataLakes sprechen. Wir können uns viele Anwendungsfälle von DataWarehouses oder DataLakes im SEO vorstellen, sei es zu Automatisierungszwecken, um „erweiterte“ Analysen durch Daten durchzuführen oder einfach um wiederkehrende Probleme (Schmerzpunkte) zu lösen.