Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Prasentation Hadoop HDFS + YARN
Ähnlich wie Prasentation Hadoop HDFS + YARN (20)
Prasentation Hadoop HDFS + YARN
- 1. Hadoop Einführung Gruppe D, Thema 11 1
- 2. • Einführung • Architektur • HDFS • YARN • Vorteile und Nachteile • Fazit • Quiz 2 Agenda
- 3. • Hadoop ist darauf ausgelegt, große Datenmengen verteilt Speichern und verarbeiten zu können • Kerneigenschaften von Hadoop • Datenlokalität • Skalierbarkeit Zuverlässigkeit 3 Einführung in Hadoop
- 4. Hadoop Architektur • Hadoop ist ein Framework • Besteht aus drei Komponenten (Open-Source) -Hadoop Distributed File System (HDFS) -YARN -Map Reduce • Stabile und klar definierte Schnittstellen • Kommerziell einkaufen S.30 4
- 5. HDFS Hadoop Distributed File System 5
- 6. „Every 2 Days we create as much Information as we did up in 2003“ -Eric Schmidt,2015
- 7. Quelle: KPBC Internet Trends 2018
- 8. HDFS (Hadoop distributed File System) • Ein verteiltes Dateisystem • Dazu ausgelegt sehr große Datengrößen zu speichern • Daten werden auf ein Cluster aus commodity Hardware verteilt • Extrem fehlertolerant • zentralisierte Speicherarchitektur durch Hierachie
- 11. “Moving Computation is Cheaper than Moving Data” 100GB 100GB 782x 128MB 128MB
- 12. Daten Replikation • HDFS ist dazu da, um zuverlässig große Dateien in vielen Komponenten zu speichern. • Die Speicherblöcke werden repliziert, um eine hohe Fehlertoleranz zu erreichen. • Die Repliken werden auf unterschiedlichen Maschinen gespeichert • Mit einer Anwendung, kann dem Namenode die vorhergesehene Anzahl der Replikationen vermittelt werden.
- 14. Heartbeats • Jeder Datanode sendet periodisch einen Heartbeat an den Namenode • Wenn kein Heartbeat ankommt wird der Datanode als „dead“ erklärt • Replikationsfaktor r fällt unter Normwert • -> Replikation wird hinzugefügt.
- 15. Delete Operation • Wenn eine Datei von einem User oder einer Anwendung gelöscht wird, wird sie nicht unmittelbar von HDFS entfernt. • Stattdessen findet man die Datei unter dem Verzeichnis /trash. • In einer Anwendung wird festgelegt, wie lange eine gelöschte Datei im Verzeichnis /trash bleibt.
- 16. YARN Yet Another Resource Negotiator (Noch ein weiterer Ressourcen Vermittler) 16
- 17. Was ist YARN? • Cluster resource manager • Schicht zwischen CPU, RAM, Speicher und Anwendungen • Applikationen können bestimmten physischen Knoten anfordern • Statische oder dynamische Zuweisung • Parallele Operationen möglich 17
- 18. Begrifflichkeiten in YARN • Task: Arbeitseinheit in einzelnem YARN Job • Container: Ressource (wie z.B. Speicher) auf einem Knoten 18
- 19. Zusammenhang bei einer YARN-Applikation 19
- 20. Prozesse in YARN • 2 Master- und ein Worker- Prozess • Resource manager (Master) • Erfasst und verteilt die Ressourcen des Clusters an die Application master • Application master (Master) • Koordiniert eine spezifische Anwendung • Node manager (worker) • Erschafft Container • Läuft auf jedem Knoten im Cluster • Führt Tasks an einem Knoten durch und managt diese 20
- 22. Scheduler in YARN • Arten von Schedulern: • FIFO • Capacity • Fair Schedulers • Definieren, wie die Aufteilung der Ressourcen erfolgt • Je nach eingestelltem Scheduler wird eine andere „Politik“ verfolgt 22
- 24. Vorteile Nachteile günstige Systeme Implementierung leicht zu beziehen Performancegewinn erst bei großem Netz leicht auszutauschen Debugging automatisches Parallelisieren und Verteilung Echtheit der Daten kann nicht überprüft werden Fehlertoleranz I/O-Ablaufplanung Monitoring und Überwachung 24 Vorteile und Nachteile von Hadoop
- 26. Fazit • Modulares System mit günstiger Hardware • Auf große Datenmengen ausgelegt • YARN und HDFS sind spezialisiert auf ein verteiltes System • Mithilfe der Master-Slave Architektur und den ihnen zugrunde liegenden Prozessen ist eine effektive Bearbeitung möglich • Hohe Fehlertoleranz und Schnelligkeit durch Datenredundanz • Erschwertes Debugging durch Verteilung auf viele Knoten 26
- 28. Danke für Ihre Aufmerksamkeit 28
Hinweis der Redaktion
- Hadoop Einführung B.B. Hadoop Architektur B.B. HDFS J.F YARN B.W. Fazit B.B.
- Quellen: J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.21-23 Bild: https://hadoop.apache.org/, abgerufen am 18.05.2021 Informationsinhalt: Wofür ist Hadoop ausgelegt? - Hadoop ist darauf ausgelegt, große Datenmengen verteilt Speichern und verarbeiten zu können. Datenlokalität - Die notwendige Verarbeitung von Daten findet in Hadoop auf dem Knoten des Clusters statt, auf dem die Daten abgelegt sind. Es muss lediglich der Programmcode übertragen werden. Damit kann der Datenverkehr gering gehalten werden. Skalierbarkeit - Skalierbarkeit wird durch ein horizontales Cluster realisiert, dem nach Bedarf Knoten hinzugefügt oder entfernt werden können. (Yahoo 4000 Knoten) Zuverlässig - Mehrfaches Speichern auf unterschiedliche Knoten - Zuverlässigkeit durch paralleler Verarbeitung auf unterschiedlichen Knoten
- Quellen: J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.12-23, S.28 Informationsinhalt: Hadoop ist ein Framework - Hadoop ist ein in Java geschriebenes Framework (Rahmen). - Hadoop setzt einzelne Komponenten voraus, lässt dabei jedoch offen, wodurch diese realisiert werden. - verteiltes Dateisystem (HDFS) - Ressourcenverwaltung (YARN) - Standardverfahren, um Daten zu verarbeiten (Map Reduce) Die drei Komponenten -Hadoop Distributed File System (HDFS): Ein über den gesamten Cluster verteiltes Dateisystem für die am Cluster abzulegenden Daten. -YARN: Eine Plattform, die Ressourcen auf dem Hadoop-Cluster verwaltet. YARN legt unter anderem fest, welche Prozesse welchen Ressourcen zugeteilt und wie Jobs abgearbeitet werden. -Hadoop Map Reduce: Ist die dritte Komponente von Hadoop. Wird im nächsten Vortrag vorgestellt. Stabile und klar definierte Schnittstellen - Dienen dazu, einzelne Komponenten modular zu gestalten und sie nach Bedarf auszutauschen. - Alternativen: - HDFS (MapR) - YARN (Mesos) - Map Reduce (Apache Spark)
- Quelle:
- Dieses Zitat stammt von damaligen Executive chairman von google ,,Eric Schmidt“. Es soll uns zeigen, dass die Menge an Daten, die wir bearbeiten extrem angestiegen ist und warum Lösungen wichtig sind die große Dateien effizient verarbeiten können.
- In diesen Diagramm können wir sehen, dass Eric Schmidt Recht hat. 2015 wurde vermutlich wirklich an einem Tag so viele Daten erzeugt wie in 2003. Der Trend ist exponentiell und wird weiter anhalten. Heute sind es 47 Zettabytes an Daten, 2025 163 Zettabytes. Zum Vergleich:163 Zettabyte entsprechen 163 Millarden TB. Warum ist das so? Neue Technologien wie autonomes Fahren oder Internet der Dinge werden extreme Datenkapazitäten fordern. Quellen: Internet Trends 2018, Mary Meeker, 30.5.2018. https://www.kleinerperkins.com/perspectives/internet-trends-report-2018/
- Jetzt kommen wir zu meinen Thema. Das HDFS (Hadoop distributed File System) ist ein verteiltes Dateisystem. Der Name beruht darauf, dass die Dateien in Blöcke aufgeteilt werden und dann abgespeichert. Es ist dazu ausgelegt sehr große Datengrößen zu speichern und schnell darauf zuzugreifen. Die Daten werden auf ein Cluster aus commodity Hardware verteilt. Commodity Hardware ist Hardware, welche günstig, gut verfügbar und leicht austauschbar ist. Außerdem ist das HDFS extrem fehlertolerant. Quellen: HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- Die Anforderungen von Big Data können auf die 5 V‘s reduziert werden. Volume (Umfang, Datenvolumen), Variety (Varianz), Velocity (Geschwindigkeit) und Veracity (Echtheit). Value (Wert) muss je nach Anwendungsfall individuell betrachtet werden. Volume und Velocity werden sehr gut abgedeckt. Volume dadurch, dass sehr viele Daten günstig gespeichert werden können. Velocity dadurch, dass HDFS schnell operiert. Variety und Veracity können aber vom HDFS nicht übernommen werden. Abbildung: https://www.migso-pcubed.com/blog/insight/what-can-big-data-do-for-you/ [JF] J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018) S.19
- HDFS stellt eine große Speicherkapazität bereit, die sich aus einem Cluster aus commodity Hardware zusammensetzt. Dadurch kann HDFS eine deutlich größere Speicherkapazität bereitstellen als es eine einzelne Maschine jemals könnte. Durch die Architektur eines verteilten Dateisystems ist die Komplexität allerdings auch um einiges höher. Es gibt eine Master-Slave Architektur. Der Name-Node ist der einzige Masterknoten. Er verwaltet alle Metadaten des Dateisystems. Die Datanodes sind die Slaves. Sie speichern die daten und führen Befehle aus. Die großen Dateien, welche HDFS speichern soll, werden in Blöcke aufgeteilt. Die Blöckgröße ist in der Regel 128MB oder 256MB. Der Datanode speichert dann diese Blöcke ab. Dadurch dass diese großen Dateien auf vielen Datanodes-Maschinen verteilt sind, können gleichzeitig die vielen Blöcke der Datei verarbeitet werden. Das ist der Grund warum HDFS so schnell ist. Der Namenode speichert, wo sich die einzelnen Blöcke einer Datei befinden und kann diese auf Anfrage lokalisieren. Deshalb reguliert er auch den Zugriff der Clients. Quellen: [BB] B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016) S.44-46 HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- . Jetzt nachdem ihr die Architektur kennt können wir darauf eingehen, warum HDFS schnell ist. Ein wichtiger Satz, der immer wieder die Vorteile von Hadoop zeigen soll ist folgendes Zitat: siehe Folie. Berechnungen zu bewegen ist billiger als Daten zu bewegen. In einem normalen computer programm, nimmt das Programm selber Speicherplatz ein und die Daten auch. Diese Daten sind relative klein und es ist kein Problem diese in das Programm zur Berechnung zu laden. Bei HDFS werden aber große Daten verarbeitet. Hätten wir jetzt 10 variable Datensätze mit jeweils 10 GB Daten, wo wir etwas ändern wollen. Müssten wir 100GB ins Programm laden und nochmal 100GB der verarbeiteten Daten zurück bewegen. Wer schonmal 200GB mit seinen Laptop verschoben hat, wird wissen dass das kein Zuckerschlecken ist. Dadurch das HDFS Blöcke von 128MB Größe hat, ist die Berechnung sehr schnell. -selbst ausgedachtes Beispiel Abbildungen: Laptop: https://www.vippng.com/preview/iioixTJ_free-cartoon-laptop-png-computer-cartoon/ Rechner: https://www.istockphoto.com/de/vektor/rechner-icon-vektor-isoliert-auf-wei%C3%9Fem-hintergrund-taschenrechner-zeichen-gm1031358946-276277684 Hadoop-Logo: HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- Das HDFS zeichnet sich durch eine hohe Fehlertoleranz aus. Es speichert zuverlässig große Daten in vielen Komponenten. Dabei werden die Speicherblöcke repliziert um sie abzusichern. Diese Repliken werden auf unterschiedlichen Maschinen gespeichert. Mit der Java basierenden Anwendung kann die Anzahl der Repliken eingestellt werden. Quellen: HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- Der Replikationsfaktor ist per Standarteinstellung drei. Das bedeutet drei verschiedene Repliken werden auf drei unterschiedlichen Datanodes-Maschinen gespeichert. Im dargestellten Beispiel ist der Replikationsfaktor r für die Dateien 1 und 3, r:2. Somit werden sie nur einmal repliziert. Für die Dateien 2,4, und 5 ist der Replikationsfaktor 3, somit werden sie dreimal repliziert. Quellen: HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- Jeder Datanode sendet periodisch einen Heartbeat an den Namenode, um zu zeigen dass er aktiv ist. Wenn kein Heartbeat ankommt wird der Daanode als dead erklärt. Per Standarteinstellung beträgt der Heartbeat 3 sek und nach 10 min ohne Heartbeat wird der Datanode als dead erklärt. Das hat zur Folge, dass der Replikationswert unter seinen Normwert fällt. Wenn wie im Beispiel vorhin ein r-Wert von 3 Norm ist, dann wird nach einem toten Datanode eine neue Replik auf einen weiteren Datanode erstellt. Quellen: HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- Noch eine kurze Anmerkung zur Delete-Operation. Wenn eine Datei von einem User oder einer Anwendung gelöscht wird, wird sie nicht unmittelbar von HDFS entfernt. Stattdessen findet man die Datei unter dem Verzeichnis /trash. In einer Anwendung wird festgelegt, wie lange eine gelöschte Datei im Verzeichnis /trash bleibt. Auch das trägt zu einer hohe Fehlertoleranz beziehungsweise einer besseren Fehlerbehebung bei. Quellen: HDFS Architecture Guide, Dhruba Borthakur, 10.10.2020 http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
- Quelle: B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.37 2. Baustein von Hadoop Kernfrage: Was passiert bei einer Anfrage an YARN?
- Quellen: B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.37/38 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.144 J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.8 T. White - Hadoop - The Definite Guide (O'Reilly, 2015), S.81 Zunächst einmal allgemeine Punkte: Weist Hardware wie Prozessorzeit und Speicher auf den Arbeitsknoten den Applikationen zu, die eine Task durchführen möchten Locality is critical -> zur effektiven Nutzung der Bandbreite ist es sinnvoll für die Applikationen, auf Knoten zu arbeiten, auf denen auch ihre benötigten Daten liegen Ressourcen können entweder komplett vor Beginn der Laufzeit angefordert werden (statisch) oder bei Bedarf während der Laufzeit zusätzlich angefordert werden (dynamisch) Bei mehr als einem Work Node ist die Ausführung von verschiedenen Operationen parallel möglich und gewünscht, um die Workload gleichmäßig zu verteilen
- Quellen: B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.395 J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.9 Für das Verständnis der Prozesse sind 2 Begriffe wichtig:
- Quellen: J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.9 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.41/42 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.387 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.363 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.391 Dargestellt ist ein Cluster, ein Knoten ist nur dem Resource manager vorbehalten. Der Application Manager sorgt für die Erstellung der Application master, während sich der Scheduler um die Planung der Jobs kümmert, auf ihn wird später noch eingegangen. Auf jedem weiteren Knoten läuft ein Node manager-Prozess, der die Knoten überwacht und mithilfe von Containern Tasks auf seinem Knoten ausführt. Diese Container sind den Application mastern unterstellt, welche über die Node manager den jeweiligen Status abfragen.
- Quellen: J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.9 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.41/42 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.387 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.363 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.391 Grundlegender Aufbau ähnlich HDFS Resource manager: Erfasst und verteilt die Ressourcen des Clusters (also Speicher, Prozessorkerne) an die Anwendungsmaster, plant die Ausführung der Jobs Optimiert Auslastung des Clusters (so viele Knoten wie möglich beschäftigen) Erfasst den Status der einzelnen Knoten Priorisiert aufgrund seiner Einstellungen bestimmte Ziele, wie z.B. Kapazitätsgarantie, Fairness(zwischen Anwendungen), Service-level-Agreements Application master: Koordiniert eine spezifische Anwendung, die auf dem Cluster ausgeführt wird (muss vom Resource manager geplant sein) Erfasst den Ausführungsstand der Jobs, die zur Erfüllung der Anwendung führen und zeigt diesen an Ist eine Framework-spezifische Bibliothek (sie nachfolgende Vorträge) Verhandelt um Ressourcen vom Resource manager Lässt Prozesse von Node managern ausführen Node manager Erschafft Container, in denen Tasks ausgeführt werden Führt Tasks auf einem Knoten durch und managt diese (Grundlage für die Tasks ist ein Auftrag vom Application master) Gibt Rückmeldung, ob Tasks laufen und wie weit sie sind Läuft auf jedem Knoten des Clusters und überwacht diesen in Hinblick auf seine Gesundheit und Auslastung
- Quellen: T. White - Hadoop - The Definite Guide (O'Reilly, 2015), S.80 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.41/42 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.387 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.363 B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.391 Die Clients fordern die Ausführung eines Jobs vom Resource manager (vgl. kommende Vorträge) . Dieser beauftragt einen Node manager, einen Application master zu erstellen. Vom Node manager wird ein Container mit einem Application master erstellt. Dieser fordert beim Resource manager Speicher und Prozessorzeit an. Die werden vom Resource manager geplant, woraufhin der Application master dafür sorgt, dass der Node manager den in Tasks unterteilten Job in Containern durchführt.
- Quellen: T. White - Hadoop - The Definite Guide (O'Reilly, 2015), S.86/87
- Quellen: T. White - Hadoop - The Definite Guide (O'Reilly, 2015), S.87 Kurzer Blick auf verschiedene Scheduler in YARN: FIFO: erster Job wird auch zuerst ausgeführt Capacity: verschiedene Warteschlangen ermöglichen, dass die Jobs gleichzeitig ausgeführt werden können, allerdings kann ein einzelner Job nicht die gesamte Kapazität nutzen Fair Schedulers: die Kapazität wird gleichmäßig zwischen allen Jobs aufgeteilt
- Quellen: J. Freiknecht & S. Papp - Big Data in der Praxis - Lösungen mit Hadoop, Spark, Hbase und Hive (Hanser, 2018), S.19, S.159-160 Informationsinhalt: Vorteile - günstige Systeme _______________________________________ - durch horizontale Cluster-Architektur - leicht zu beziehen_______________________________________ - viele kleinere Komponenten - leicht auszutauschen ____________________________________ - Architektur aus kleinen Teilsystemen - Austausch / Hinzufügen und Entfernen von Komponenten im laufendem Betrieb - automatisches Parallelisieren und Verteilung ___________ - Jobs können in Teilaufgaben zerlegt und dann parallel verarbeitet werden. Die Ergebnisse werden zur Gesamtlösung zusammengefügt - Fehlertoleranz ___________________________________________ - Ausfälle werden durch Pings erkannt. Datenredundanz ermöglicht es, betreffende Teil-Jobs erneut zu vergeben - I/O-Ablaufplanung ______________________________________ - Durch die Datenredundanz ist es möglich, identische Teil-Jobs mehrfach zu vergeben und den schnellsten zu verwenden - Monitoring und Überwachung __________________________ - Hadoop bietet gute Möglichkeiten, Jobs und Anwendungen zu überwachen Nachteile - Implementierung ________________________________________ - Umdenken bei der Implementierung, da sich der Umgang mit MapReduce-Jobs oder YARN sehr von SQL unterscheidet - Performancegewinn erst bei großem Netz ______________ - um Wirklich große Daten wirklich effizient verarbeiten zu können, sind viele Knoten nötig. Denn Hadoop bring keinen Performancegewinn sondern teilt die Arbeit lediglich auf die vorhandenen Knoten auf und verarbeitet parallel - Debugging ______________________________________________ - es ist ein tieferes Verständnis nötig, um das Debugging effizient durchzuführen, da sich Fehler auf mehrere Stellen verteilen können - Echtheit der Daten kann nicht überprüft werden________ - kann nicht gegen verschiedene Quellen verifizieren
- Quellen: B. Bengfort & J. Kim - Data Analytics with Hadoop (O'Reilly, 2016), S.40- 43 Zu sehen ist ein kompletter Hadoop cluster, auf dem alle benötigten Prozesse laufen (diese wurden im einzelnen bereits vorgestellt). 6 Prozesse, jeweils 3 für HDFS und YARN: HDFS: NameNode (Master) (Secondary NameNode) DataNode (Worker) YARN: ResourceManager (Master) ApplicationMaster (Master) NodeManager (Worker) ResourceManager und NameNode belegen jeweils einen eigenen Knoten, hier werden keine Dateien gespeichert. Sie dienen lediglich der Verwaltung Auf den anderen Knoten im Cluster liegen jeweils Daten (hier als Zylinder HDFS dargestellt), ein zugehöriger DataNode zur Speicherverwaltung sowie ein NodeManager für die Ressourcenverarbeitung. Es ist zudem möglich, dass ein ApplicationMaster auf einem Knoten vorkommt. Anmerkung: der Begriff „Application Manager“ wird in den Quellen unterschiedlich verwendet und wurde zum Zweck der Kontinuität in dem Bild auf dieser Folie zu Application Master geändert.
- Quellen: Modulares System mit günstiger Hardware Auf große Datenmengen ausgelegt
- Zum Abschluss gibt es ein Quiz mit einer Frage zu jedem der drei Themenbereiche. Über den Link wird das anonyme Google-Formular aufgerufen.