Beiträge

Werkstattbericht No. 3 – So haben wir den SourceTracker entwickelt

/2 Kommentare/in /von

Datenjournalisten und Big-Data-Experten haben einen sehr unterschiedlichen Blick auf Daten: Erstere möchte die Daten am liebsten in einem interaktiv Framework untersuchen und eine Geschichte erzählen. Letztere kämpfen mit der Integration heterogener Daten und befassen sich mit verteilten Algorithmen des maschinellen Lernens oder der Graphanalyse. Wie können Datenjournalisten und Big-Data-Experten bei der Entwicklung einer komplexen Big-Data-Plattform wie News-Stream 3.0 produktiv zusammenarbeiten und voneinander lernen?

Die gemeinsame Entwicklung und Nutzung unserer Big-Data-Plattform soll am Beispiel des “SourceTrackers” gezeigt werden, unseres jüngsten Demonstrators.

Ziel des SourceTrackers ist es, die Verbreitung von Aussagen auf den Websites von Medien nachzuvollziehen – etwa, um zu verfolgen, welche Aussagen aus PR-Material unverändert übernommen werden oder in welchen Fällen die Meldungen aus dem Dienst der dpa vor der Veröffentlichung stark oder weniger stark umgeschrieben werden. Die Vermutung: für die dpa-Redaktion, aber auch für PR-Agenturen ergeben sich daraus nützliche Hinweise für die Gestaltung von Meldungen.
Inspiriert hat uns dabei das Projekt Churnalism, eine britische Suchmaschine, die handwerklich fragwürdigen Copy & Paste Journalismus aufdecken sollte, inzwischen aber eingestellt wurde.

Wie gehen wir bei der Analyse vor?

Bei unserer Analyse werden die Dokumente zunächst anhand ihrer digitalen Fingerabdrücke verglichen. Im nächsten Schritt werden die Dokumente auf Zeichenebene verglichen. Ein Demonstrator visualisiert die Analyse einzelner Dokumente und ihrer Nutzung.

SourceTracker

Eine weitere Art der Analyse ist die Gesamtschau auf einen Tag – im Beispiel der 29. September 2015. Jeder Kreis steht für eine eine Meldung aus dem dpa-Basisdienst. Je weiter oben der Kreis eingezeichnet ist, desto mehr Websites haben Bestandteile dieser Meldung übernommen (y-Achse). Je weiter rechts der Kreis eingezeichnet ist, desto weniger Sätze der Meldung wurden verändert. Die Farben stehen für die dpa-Ressorts (wi=Wirtschaft, pl=Politik, vm=Vermischtes, sp=Sport, ku=Kultur).

SourceTracker Analyse

Hier noch einmal die Liste der Top 5 Geschichten vom 25. 9. Lesebeispiel: “Bestandteile der Game of Thrones-Meldung wurden auf 166 Websites verwendet. Im Durchschnitt haben die Websites 66,98% übernommen”.

SourceTracker Analyse2

Unser Big-Data-Framework

Wir wollten von Projektbeginn an unter Big-Data-Bedingungen arbeiten: nicht mit “Spielzeugdaten”, sondern große Datenmengen und hochperformanten verteilte Algorithmen. Neben dem dpa Basisdienst und Twitter verarbeiten wir einen Newsfeed mit Artikeln aus über 1000 Online-Nachrichtenquellen, die von unserem Spider dafür extrahiert wurden. Das Big-Data-Framework Apache Spark bildet das Herzstück unseres Clusters. Spark ist im Vergleich zu seinem Vorgänger Hadoop MapReduce rasend schnell, weil es auf die verteilte Verarbeitung im Arbeitsspeicher setzt – und es erlaubt sowohl die Echtzeitverarbeitung von Datenströmen als auch die effiziente Abarbeitung von “Datenstapeln” (Batch-Verarbeitung). Der Entwicklungscluser von News Stream 3.0 füllt einen kompletten Serverschrank, aktuell 16 Server mit insgesamt 100 Terabyte Festplattenplatz, Tendenz wachsend.

Unsere Plattform basiert auf einer “Lambda-Architektur”. Dieser Begriff beschreibt ein Modell, bei dem die verwendeten Rohdaten unverändert gespeichert werden. Parallel zur echtzeitnahen Verarbeitung neu eintreffender Daten kann eine Neuprozessierung von Teilen oder des gesamten Datenbestandes stattfinden. Das erleichtert die Erprobung und Verbesserung von Algorithmen. Die Ergebnisse, also in unserem Fall Dokumente mit dokumentbezogenen oder dokumentübergreifenden Metadaten, werden über eine Auslieferungsschicht verfügbar gemacht. Die Rohdaten, das können je nach Clustergröße Terabytes oder Petabytes sein, werden bei uns in der verteilten Datenbank HBase gespeichert. Ausgeliefert werden die prozessierten Daten über eine verteilte Suche – hier ist die maximale Datenmenge durch den verfügbaren Arbeitsspeicher begrenzt – in unserem Fall auf mehre Milliarden Dokumente.

BigData Frameform

Mehrere Suchindexe biete Zugriff auf einen Teil der prozessierten Daten – entsprechend den aktuellen Anforderungen der Demonstratoren. Über die Such-Schnittstelle lassen sich bereits einige der Fragen beantworten, die uns nach der Präsentation unserer ersten SourceTracker-Demo gestellt wurden:

Können wir diese Analysen für alle dpa-Meldungen eines Tages, einer Woche oder eines Monats durchführen?

  • Was sind meistzitierten Sätze?
  • Welche Medien übernehmen große Teile der dpa-Meldungen?
  • Welche nur einzelne Passagen?
  • Ist das von Ressort zu Ressort unterschiedlich?

    • Per Python-Skript kann der Entwicklungsredakteur direkt auf die Such-API zugreifen und experimentieren. Und sobald klar ist, welche Reports regelmäßig gewünscht werden, können wir diese effizient für Spark implementieren.

    Andere Fragen erfordern eine Anpassung unserer bisherigen Datenverarbeitungs-Pipeline.

  • Werden die Agenturinhalte im Laufe eines Tages nach und nach durch redaktionelle Inhalte ersetzt? Hierfür müssten wir verschiedene Versionen von Artikeln vorhalten.
  • Könnten wir nicht mit den gleichen Methoden herausfinden, welche Medien sich bei Wikipedia bedienen? Hierzu müssten wir nur die regelmäßig bereitgestellten Wikipedia-Dumps einlesen und prozessieren.
  • Kann ich mich benachrichtigen lassen, sobald ein Artikel von anderen Medien aufgegriffen wird? Das wäre ein erster Anwendungsfall für ein Alert-Modul in unserer Spark-Pipeline.

    • Währenddessen laufen auf dem Cluster längst neue Experimente: es geht um die Topic-Erkennung in Nachrichten und eine Verknüpfung maschinell gelernter Themen mit des semantsichen Metadaten der Dokumente (vgl. Blogbeitrag). Die nächste Demo wird nicht lange auf sich warten lassen.

    Wollen Sie mehr erfahren? Werden Sie jetzt News-Stream 3.0 Beta-Tester http://bit.ly/newsstreambetatester

    Werkstattbericht No. 1 – Die Big-Data-Infrastruktur

    /in /von

    Twitter ist für viele Forschungsprojekte und Journalisten eine der primären Informationsquellen, wenn es um die Analyse von Social-Media-Inhalten oder Breaking-News-Ereignisse geht. Hier kann die Twitter-Analyse ein Einstiegspunkt für weitere Untersuchungen und Recherchen sein.

    Um den kontinuierlich, ständig wachsenden Datenstrom in Echtzeit zu bändigen bedarf es flexibler Lösungen. Aus journalistischer Sicht wollten wir uns unbedingt von starren Datendashboards lösen und Journalisten mehr Flexibilität bei der Datenaufbereitung, -analyse und -visualisierung geben.

    Im Projekt Newsstream 3.0 wurde pünktlich zu den britischen Unterhauswahlen ein erster Demonstrator umgesetzt, mit dem sich die Twitter-Reaktionen auf die Wahldebatten verfolgen lassen. Das Kopf-an-Kopf-Rennen der Parteien lässt sich an einem Zeitstrahl ablesen, auf dem die Anzahl der Tweets von Labour und Tories verglichen wird.

    GE2015_UK

    Der Demonstrator ist zu einem sehr frühen Zeitpunkt im Projektverlauf entstanden, pünktlich zum ersten Meilenstein, bei dem Anforderungsanalyse und Grobkonzept vorgelegt wurden. Interessant sind an dieser Stelle deshalb weniger die Ergebnisse der Analyse, sondern die verwendeten Technologien. Hinter dem Demonstrator steht eine ausgewachsene Big-Data-Infrastruktur: ein Hadoop-Cluster mit 16 Nodes und einer Speicherkapazität von insgesamt 100 Terabyte, auf dem Clouderas Open-Source-Distribution betrieben wird, die sowohl eine verteilte Stapelverarbeitung als auch die Echtzeitanalyse mit Apache Spark ermöglicht. Für die performante Auslieferung von Daten bindet Cloudera die verteilte Open-Source-Suchlösung Apache Solr an.

    Das verwendete Dashboard stammt aus einem anderen Kontext, nämlich der Logfile-Analyse. Während Big Data für viele Unternehmen bisher noch kein Thema ist, hat sich im IT-Betrieb die kollaborative Auswertung von großen Mengen von Logfiles durchgesetzt – auch dank des interaktiven Dashboards “Kibana”, das ursprünglich als Demo-Applikation für die Open-Source-Suche Elasticsearch entwickelt wurde. Ebenso wie Twitter ist auch bei Logfiles die Zeit die wichtigste Dimension: hier geht es z.B. um die Anzahl der Nutzer oder der Fehlermeldungen pro Zeiteinheit. Mit wenigen Klicks lässt sich bei Kibana ein neues Dashboard als Kopie erstellen oder ein Widget hinzufügen. Die Auswahl reicht von Säulen- und Tortendiagrammen über Kartendarstellungen bis zu Tagclouds und Listen. Flexibilität ist für die Nutzer von Loganalyse-Tools zentral: wenn z.B. zusätzliche Informationen geloggt werden, muss es einfach möglich sein, auf diese Informationen zuzugreifen und sie im Dahsboard anzuzeigen. Eine gute Benutzbarkeit ist angesichts der hektischen Arbeitsbedingungen im IT-Betrieb ebenfalls von großer Bedeutung.

    Die Ähnlichkeit zu den Anforderungen von Redakteuren sind frappierend. Für uns lag es deshalb nahe, ein Dashboard wie “Kibana” für die Twitter-Analyse zu verwenden. Um eine nahtlose Integration in Clouderas CDH zu ermöglichen, griffen wir dabei auf einen Entwicklungszweig von Kibana mit Namen “Banana” zurück. Die Twitter-Analyse ist für uns nur der Anfang. Im nächsten Schritt wird es darum gehen, eine Vielzahl von Quellen anzubinden und die Nutzungsmuster der Redakteure zu untersuchen. Ergebnisse der im Projekt entwickelten Textanalyse-Algorithmen werden an die Stelle der vom Datenanbieter wie Twitter gelieferten Metadaten treten. Der aktuelle Demonstrator dient dabei als Baukasten. Eine Aufgabe wird der Export von Widgets bzw. der ermittelten Datensätze für die Nutzung in anderen Formaten und Applikationen sein. Auch die visuelle Weiterentwicklung spielt eine Rolle – auch hier ist für eine einfache Erweiterbarkeit gesorgt, da die gewählte Lösung auf der im Datenjournalismus beliebten Open-Source-Bibliothek D3.js basiert.

    Wollen Sie mehr erfahren? Werden Sie jetzt News-Stream 3.0 Beta-Tester http://bit.ly/newsstreambetatester