*Teil 2 aus dem Tagebuch unseres Community-Projekts zur NRW-Wahl 2022
Im ersten Teil dieser Serie „Modern Cloud Analytics – Oder: Als wir versuchten, die Wahlen in NRW vorherzusehen“ hatten wir aus relativ hoher Flughöhe auf unser kleines Community-Projekt zu den Landtagswahlen in NRW geschaut. Wenn du den Beitrag gelesen hast, weißt du schon, dass die Vorhersage, die wir mithilfe einer Twitter-Analyse machen wollten, ihre Tücken hatte. Und wir müssten lügen, wenn das unseren Stolz nicht ein wenig angekratzt hätte. Aber wie bei jeder Forschungsarbeit konnten wir auch in diesem Projekt, Erkenntnisse sammeln, die wir dir nicht vorenthalten möchten: Welche Werkzeuge und Methoden gibt es, um die riesigen unstrukturierte Datenmengen aus sozialen Netzwerken für Vorhersagen zu nutzen? Wie kann Künstliche Intelligenz dabei helfen?
Die Analytics-Welt hat sich verändert
Das sind wichtige Fragen in einer Data-Warehouse-Welt, die sich schneller dreht als wir denken können. So war es vor 20 Jahren noch selbstverständlich,
- dass die Datenbank als zentraler Datenspeicher auf einem möglichst mächtigen Server im lokalen Netz installiert war,
- Daten mit Skripten oder mit lokal installierten ETL-Werkzeugen in die Datenbank geladen wurden,
- Daten meist mit vorgefertigten Abfragen exportiert
- und später in den Fachbereichen mit Excel, in vordefinierten Berichten oder in interaktiven Dashboards bereitgestellt und analysiert wurden.
Heute sieht es eher so aus:
- Data Warehouses werden in der Cloud gespeichert,
- die Weiterverarbeitung findet in Cloud-basierten Plattformen statt.
- Bei der Datenauswertung bekommen wir längst keine wohlformatierter Endlostabellen mehr vorgelegt, sondern wir können Zahlen und Fakten mit Hilfe ausgeklügelter Präsentationstechniken erklären und visualisieren.
- Künstliche Intelligenz hilft uns, (fast) unendlich große Datenmengen zu nutzen und zu kategorisieren.
Damit hat sich auch unsere professionelle Rolle verändert: Als Fachleute für Data Analytics müssen wir die Funktionsweisen sowie die Stärken und Schwächen der Werkzeuge kennen. Nur dann können wir Lösungen entwickeln, die den Mitarbeitenden weiterhelfen und der Sache, um die es geht, dienen.
Was das mit unserem Community-Projekt zu tun hat
In der „alten Welt“ wäre es darum gegangen, eine Prozesslandschaft so optimal wie möglich auszugestalten. Heute hingegen kommt es darauf an, einzelne Schritte zu verbessern, damit wir die am Markt gängigen Werkzeuge besser verstehen und einzusetzen lernen. Um eine realistische Umgebung zu schaffen, wählten wir Tools aus, die am Markt verbreitet sind und kostengünstig genutzt werden können. Nun aber endlich zur Sache:
Wie ist eigentlich ein Tweet-Datensatz aufgebaut?
Twitter stellt seine Datensätze in JSON bereit. (Siehe Abbildung 1) Damit enthält jeder Datensatz neben der eigentlichen Nachricht auch diverse Metadaten. Dazu gehören Angaben wie Autor, Ort und Uhrzeit der Erstellung, Verbindungen zu Tweets, die referenziert werden, die Anzahl der Follower des Autors und Referenzen zu Mediadaten wie Bilder und so weiter.
Hier ist jedoch anzumerken, dass Twitter nach diesem Projekt eine neue API-Version publiziert hat, die den Zugriff stärker einschränkt. Version 2.0 hat nicht nur wesentlich eingeschränktere Zugriffsmöglichkeiten, sondern ist auch von der Konfiguration her aufwendiger, da hier jeder auszugebende Tag zu konfigurieren ist. Details findest du auf der Firmenhomepage von Twitter Inc.
Abbildung 1: Auszug aus einem Tweet – Datensatz
Analyseprozess in fünf Schritten
Wie gesagt war unsere Idee, die Landtagswahlergebnisse in Nordrhein-Westfalen auf der Grundlage von Social-Media-Beiträgen vorherzusagen, ein ziemlicher Schnellschuss. Als Datenquelle wurde Twitter auserkoren, auch weil die damalige Schnittstellenversion es uns leicht machte, kostenlos und unkompliziert auf Tweets zuzugreifen. Ein Hashtag genügte. Es reichte also, die Hashtags der Parteien, die im Landtag vertreten waren, und die Hashtags ihrer jeweiligen Spitzenkandidat:innen zu suchen. Zusätzlich wurden Tweets gesammelt, die ein Hashtag enthielten, das auf die Landtagswahl hindeutet, wie #Landtagswahl, #LTWNRW, #LTW22 und so weiter.
Wie wir aus dieser Vielzahl an Tweets eine Prognose über die Landtagswahl erstellen wollten, zeigt die Prozesskette in Abbildung 2.
Abbildung 2: Überblick über die Prozesskette
Schritt 1 – Extraktion: Im ersten Schritt wurden die Datensätze mit den definierten Hashtags aus Twitter extrahiert und über den Zeitraum mehrerer Wochen im Data Lake Storage in Form von JSON-Dateien abgelegt. Hierbei wurde jeder Datensatz in eine separate Datei geschrieben.
Schritt 2 – Übertrag: Im zweiten Schritt wurden diese Dateien in eine Datenbanktabelle übertragen. Mit separaten Feldern. Da zu diesem Zeitpunkt war noch nicht klar war, in wie vielen Feldern wir am Ende verwertbare Daten finden würden, wurden zunächst sämtliche Felder extrahiert und in eine denormalisierte Tabelle geschrieben.
Schritt 3 – Denormalisierung: Im dritten Schritt ging es darum, die Daten aus einer denormalisierten Tabelle in ein normalisiertes Datenmodell zu übertragen, um damit die spätere Aufbereitung in Pyramid oder Azure Machine Learning zu unterstützen.
Schritt 4: Datentransfer zu Azure inkl. Rückkanal für die (Zwischen-)Speicherung der Ergebnisse
Schritt 5: Datentransfer zu Pyramid inkl. Rückkanal für die (Zwischen-)Speicherung der Ergebnisse
Genauer hingeschaut: Von der Extraktion bis zur Denormalisierung
Lass uns die Schritte 1 bis 3 noch etwas genauer ansehen:
- Extraktion
Im ersten Schritt des Analyseprozesses wurden die Datensätze mit Apache NiFi aus Twitter extrahiert und im Data Lake einer Microsoft Azure Instanz gespeichert. Apache NiFi ist eines er beliebtesten Open-Source-Produkte, um große Datenmengen von einer Datenquelle in ein Target zu übertragen. Hierzu werden einzelne Datenpakete (FlowFiles) über Serverprozesse verarbeitet und/oder gespeichert. Diese FlowFile Processors können über Connections miteinander verbunden werden.
Dieses Konstrukt hat zweierlei Funktionen: Zum einem werden Datenflüsse definiert, zum anderen dienen die Connections als Zwischenspeicher, sodass die FlowFile Processors mit unterschiedlichen Geschwindigkeiten arbeiten können. In Abhängigkeit von der Datenmenge kann die Rate der verarbeitbaren FlowFiles über die Anzahl paralleler FlowFile Processor skaliert werden.
Zur Extraktion der Daten aus Twitter stand, als wir unser Projekt durchführten, ein vorkonfigurierter Connector zur Verfügung, sodass sich ein Job zur Speicherung schnell implementieren ließ. Hierzu bedurfte es lediglich der Konfiguration des FlowFile-Processors zur Definition der gesuchten Hashtags und des Speicherorts. (Siehe Abbildung 3).
Abbildung 3: Konfiguration des FlowFile – Processors
Die Krux war jedoch, dass hierbei jeder Tweet in eine eigene Datei geschrieben wurde. Krux deswegen, weil wir im zweiten Schritt der Verarbeitung nicht weniger als 158.000 Datensätze zu verarbeiten hatten!
Ursprünglich hatten wir für diesen Schritt eine Implementierung in Airbyte geplant. Airbyte ist ein ELT-Werkzeug, das im Cloud-Kontext weit verbreitet ist. Sowohl in einer kommerziellen als auch einer Open-Source -Variante. Zur Anbindung an jeweilige Datenquellen und -speicher bietet das Tool mehr als 300 Konnektoren und erlaubt die einfache Anbindung von Datenquellen in JSON-Format. Zum Zeitpunkt der Implementierung war jedoch ein vorkonfigurierter Konnektor für so eine große Anzahl von Dateien nicht verfügbar. Wir hätten also für jede Datei einen separaten Konnektor konfigurieren müssen.
- Übertragung in die Datenbank
Der zweite Schritt der Analyse, die Übertragung der Daten in Datenbanktabellen, läuft in zwei Etappen ab:
- Zunächst werden die Daten im JSON-Format abgelegt.
- Dann werden die einzelnen Attribute aus der JSON-Datei geparst und in einer Tabelle gespeichert. Sollte eine verschachtelte JSON-Struktur vorliegen, so wird die Substruktur iterativ aufgelöst, wobei zur Verknüpfung eine künstliche Airbyte ID generiert und die Parent-Child-Beziehung über einen Foreign Key abgebildet wird.
Zwar stellt Airbyte ein Software Development Kit zur Verfügung, ebenso Hilfen zur Implementierung eines eigenen Konnektors zur Anbindung vieler Dateien in einem Verzeichnis – allerdings war uns die Zeit für die Anbindung zu lang, sodass ein anderer Ansatz gewählt wurde:
Wir banden die JSON-Dateien im Data-Lake-Speicher als externe Datenquellen direkt in die Snowflake-Datenbank ein. Die Dateien standen uns dort für die weitere Verarbeitung wie eine externe Tabelle zur Verfügung. Dieses Vorgehen hat jedoch Grenzen: Da das Parsen des JSON-Formats per SQL-Statement erfolgt, gestaltet sich eine Normalisierung der Daten bei verschachtelten JSON-Strukturen sehr aufwendig.
- Normalisierung
Beim dritten Schritt der Analyse ging es darum, die Daten aus einer denormalisierten Tabelle in ein normalisiertes Datenmodell zu übertragen, sodass die Daten für die folgende Datenanalyse aufbereitet zur Verfügung stehen. Diesen Schritt haben wir über DBT (einer im Cloudkontext verbreitetem Werkzeug zur Implementierung von Transformations- und Analysealgorithmen in SQL und/oder Python) direkt auf dem Prozessor implementiert.
Die Stärke von DBT besteht für uns als Team darin, dass Analyse-Code kollaborativ in einer sehr stark an SQL und Python angelehnten Form erstellt und deployt werden kann. Entsprechend einfach sehen die Statements zur Extraktion der Tweet-Header-Daten aus. (Siehe Abbildung 3)
{{
config(
materialized='incremental',
unique_key='tweet_id'
)
}}
select *
from
(select distinct
'STREAM LTWNRW' twitter_search_stream,
TWEET_ID,
CREATED_AT_UTC,
coalesce(FULL_TEXT,TEXT) as TEXT,
IN_REPLY_TO_STATUS_ID as REPLY_TO_TWEET_ID,
IN_REPLY_TO_STATUS_USER_ID as REPLY_TO_USER_ID,
QUOTED_STATUS_ID as QUOTE_TO_TWEET_ID,
RETWEETED_STATUS_TWEET_ID as RETWEET_TO_TWEET_ID,
POSSIBLY_SENSITIVE,
LANG,
"SOURCE",
USER_ID,
to_varchar(PLACE_ID) as PLACE_ID
from {{ ref('stage_twitter') }} }
Abbildung 3: Quellcode zur Auslese der Twitter – Headerdaten
Das Zieldatenmodell wurde in einer 2-nf-Architektur aufgebaut und berücksichtigt diverse Kardinalitäten: So ist es nicht unwahrscheinlich, dass ein Benutzer mehrere Tweets schreibt, sich zu unterschiedlichen Zeiten an verschiedenen Orten aufhält und sich beispielsweise mit fortschreitender Zeit auch die Anzahl der Follower ändert. Ebenso kann ein Tweet z. B. mehrere Hashtags enthalten.
Abbildung 4 zeigt den Ausschnitt des Datenmodells, in das die Twitterdaten aufgenommen und für die Bereitstellung zu weiteren Analysen genutzt wurden.
Abbildung 4: Die so aufbereiteten Daten wurden für diese Serie verwendet.
Summary
Zunächst einmal konnten Twitterdaten für die folgenden Analysen bereitgestellt werden. Um für kommende Projekte besser gerüstet zu sein, bot sich hier die Gelegenheit, Werkzeuge zu testen, die im Cloud-Kontext verbreitet sind. Der Einfachheit halber wurden nur Nachrichten über einen Dienst verwertet. Diese Beschränkung war der Einfachheit des Testfalles geschuldet – technisch wäre die Einbindung weiterer Messengerdienste möglich gewesen.
Die Einbindung weiterer Datenquellen mittels CSV-Datei war für keines der Werkzeuge ein Hindernis. Dennoch war die Nutzung der Anbindung von Twitter über Nifi eine deutliche Vereinfachung. Einen Komfort, den es zukünftig nicht mehr geben wird, weil diese Nutzung mit der neuen Twitter Version deutlich aufwendiger wird. Künftig müssen die hier abzurufenden Informationen explizit konfiguriert werden.
Die verwendeten Werkzeuge erlauben eine Anbindung weiterer Messengerdienste, sofern ein entsprechendes SDK verfügbar ist. Vor diesem Hintergrund wäre jedoch auch zu prüfen, ob, und ggf. inwieweit, die Analyseergebnisse davon betroffen sein könnten.
