Bitte wählen Sie die Bereiche, die Sie exportieren möchten:
Alle Apache SchulungenSchulung Apache Cassandra: Verteilte Wide-Column-Datenbank
Schulung Apache Cassandra: Verteilte Wide-Column-Datenbank
Data Modeling, CQL, Replikation und Konsistenz
3 Tage / S6887
Neues SeminarSchulungsformen
Offene Schulung
- 3 Tage
- 5 gesicherte Termine
- Köln / Online
- 2.030,00 p. P. zzgl. MwSt.
- Dritter Mitarbeitende kostenfrei
- Learning & Networking in einem. Garantierte Durchführung ab 1 Teilnehmenden.
Präsenz Online
Inhouse-/Firmenschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- 3 Tage - anpassbar
- Termin nach Wunsch
- In Ihrem Hause oder bei der GFU
- Preis nach Angebot
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Beschreibung
Relationale Datenbanken skalieren vertikal - mehr RAM, schnellere CPU, größere SSD. Irgendwann ist Schluss. Cassandra skaliert horizontal - mehr Nodes, linear mehr Durchsatz, linear mehr Speicher. Ohne Single Point of Failure, ohne Master-Slave-Architektur, ohne Downtime bei Cluster-Erweiterung. Netflix speichert Milliarden Nutzeraktivitäten pro Tag in Cassandra. Apple betreibt über 100.000 Cassandra-Nodes. Discord verwaltet Billionen von Nachrichten. Uber speichert Fahrtdaten und Echtzeit-Positionen.
Der Preis dafür: Cassandra denkt anders als SQL. Kein JOIN, kein GROUP BY über Partitionen, keine Ad-hoc-Queries auf beliebige Spalten. Das Datenmodell wird nicht normalisiert, sondern query-driven entworfen: Erst die Queries definieren, dann die Tabellen so bauen, dass jede Query von einer einzigen Partition beantwortet wird. Wer relationales Denken auf Cassandra anwendet, bekommt ein langsames, fragiles System. Wer Cassandra-Denken versteht, bekommt eine Datenbank, die bei 10 Milliarden Zeilen genauso schnell antwortet wie bei 10 Millionen.
Dieses dreitägige Seminar zeigt beides: das Datenmodellierungs-Handwerk (der schwierigste und wichtigste Teil) und den Cluster-Betrieb (der technische Teil). Am Ende steht nicht nur Wissen, sondern ein funktionierender Cluster mit einem produktionsreifen Datenmodell.
Der Preis dafür: Cassandra denkt anders als SQL. Kein JOIN, kein GROUP BY über Partitionen, keine Ad-hoc-Queries auf beliebige Spalten. Das Datenmodell wird nicht normalisiert, sondern query-driven entworfen: Erst die Queries definieren, dann die Tabellen so bauen, dass jede Query von einer einzigen Partition beantwortet wird. Wer relationales Denken auf Cassandra anwendet, bekommt ein langsames, fragiles System. Wer Cassandra-Denken versteht, bekommt eine Datenbank, die bei 10 Milliarden Zeilen genauso schnell antwortet wie bei 10 Millionen.
Dieses dreitägige Seminar zeigt beides: das Datenmodellierungs-Handwerk (der schwierigste und wichtigste Teil) und den Cluster-Betrieb (der technische Teil). Am Ende steht nicht nur Wissen, sondern ein funktionierender Cluster mit einem produktionsreifen Datenmodell.
Verschaffen Sie sich einen Überblick über alle Apache Weiterbildungen.
Schulungsziel
Jede teilnehmende Person verlässt das Seminar mit dem Verständnis der Cassandra-Architektur (Ring, Replikation, Tunable Consistency), der Fähigkeit, query-driven Datenmodelle zu entwerfen (Partition Key, Clustering, Denormalisierung), CQL-Kompetenz (CRUD, TTL, Collections, Tracing), Cluster-Betriebswissen (Scaling, Repair, Compaction, Monitoring), einem funktionierenden 3-Knoten-Cluster mit eigenem Datenmodell und einer begründeten Bewertung von Cassandra vs. Alternativen.
Details
Inhalt
Tag 1: Architektur, CQL und Datenmodellierung
1. Cassandra-Architektur: Warum anders als SQL
4. Schreibpfad, Lese-Pfad und Compaction
7. Integration: Kafka, Spark und Applikations-Treiber
Phase 1 - Use Case und Queries (15 Min):
1. Cassandra-Architektur: Warum anders als SQL
- Ziele und Erwartungen der Teilnehmenden
- Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
- Wann Cassandra, wann nicht: Cassandra für schreibintensive Workloads (IoT-Sensordaten, Logs, Messaging, Nutzeraktivitäten, Zeitreihen), global verteilte Verfügbarkeit (Multi-Datacenter, keine Downtime bei Region-Ausfall), vorhersagbare Latenz bei massiver Skalierung. Nicht für: Ad-hoc-Analytics (-> ClickHouse), komplexe Joins (-> PostgreSQL), kleine Datenmengen (< 10 GB -> overkill), starke Konsistenzanforderungen (-> relationale DB).
- Peer-to-Peer-Architektur: Kein Master, kein Slave - alle Nodes sind gleichberechtigt. Jeder Node kann Lese- und Schreibanfragen beantworten. Kein Single Point of Failure. Vergleich: PostgreSQL (Primary/Standby), MongoDB (Primary/Secondary), Cassandra (Ring, alle Peers).
- Ring, Partitioner und Token-Verteilung: Consistent Hashing verteilt Daten gleichmäßig über alle Nodes. Partition Key -> Hash -> Token -> zuständiger Node. Vnodes (Virtual Nodes) für automatische Lastverteilung.
- Replikation: Replication Factor (RF) definiert, auf wie vielen Nodes jede Partition gespeichert wird. RF=3: jede Partition auf 3 Nodes. Replication Strategy: SimpleStrategy (ein Datacenter), NetworkTopologyStrategy (Multi-Datacenter - RF pro DC konfigurierbar).
- CAP-Theorem und Tunable Consistency: Cassandra ist AP (Available + Partition-tolerant), aber Konsistenz ist über Consistency Level steuerbar: ONE (schnell, evtl. stale), QUORUM (Mehrheit, guter Kompromiss), ALL (konsistent, aber langsam und fragil), LOCAL_QUORUM (Quorum im lokalen DC - Standard für Multi-DC). Formel: R + W > RF -> Strong Consistency möglich.
- Praxis-Übung: 3-Knoten-Cluster aufsetzen (Docker Compose oder bereitgestellt). nodetool status -> Ring-Topologie inspizieren. nodetool ring -> Token-Verteilung sehen. Replication Factor und Consistency Level konzeptuell durchspielen: Was passiert, wenn 1 Node ausfällt bei RF=3 und CL=QUORUM?
- CQL vs. SQL: CQL sieht aus wie SQL, verhält sich aber anders. CREATE TABLE, INSERT, SELECT, UPDATE, DELETE - vertraute Syntax. Aber: kein JOIN, kein Subquery, kein GROUP BY über Partitionen, kein ORDER BY auf beliebige Spalten, kein ALTER TABLE ADD CONSTRAINT.
- Keyspace und Tabellen: Keyspace = Datenbank (mit Replication Strategy). Tabelle = Sammlung von Zeilen mit definiertem Schema. CREATE KEYSPACE, CREATE TABLE mit Primary Key.
- Primary Key: Partition Key + Clustering Columns. Partition Key bestimmt, auf welchem Node die Daten liegen. Clustering Columns bestimmen die Sortierung innerhalb der Partition. Compound Partition Key für Multi-Tenancy (z.B. (tenant_id, year)).
- Datentypen: Primitive (text, int, bigint, float, double, boolean, timestamp, uuid, timeuuid), Collections (list, set, map), User-Defined Types (UDT), Frozen Types, Counter.
- CRUD-Operationen: INSERT INTO (Upsert - überschreibt bei gleichem Primary Key), SELECT mit Partition Key (Pflicht!) und optionalen Clustering-Filtern, UPDATE (auch Upsert), DELETE (Tombstones - nicht sofort gelöscht, sondern markiert). ALLOW FILTERING - warum man es nie in Produktion nutzen sollte.
- TTL und Timestamps: Daten automatisch ablaufen lassen (INSERT ... USING TTL 86400 - nach 24 Stunden gelöscht). Für Logs, Sessions, temporäre Daten. WriteTimestamp für Conflict Resolution (Last-Write-Wins).
- Praxis-Übung: Keyspace erstellen (RF=3, NetworkTopologyStrategy). 3 Tabellen erstellen (User-Profil, Nachrichten, Sensor-Daten). 100 Zeilen einfügen, Queries ausführen, TTL testen. ALLOW FILTERING ausprobieren -> verstehen warum es langsam ist und warum das Datenmodell geändert werden muss statt ALLOW FILTERING zu nutzen.
- Das Cassandra-Modellierungsprinzip: Nicht „Welche Entitäten habe ich?" (relational), sondern „Welche Queries muss ich beantworten?" Für jede Query eine Tabelle. Denormalisierung ist kein Anti-Pattern - es ist das Design-Prinzip. Daten werden dupliziert, damit jede Query von einer einzigen Partition-Read beantwortet wird.
- Modellierungs-Workflow: (1) Queries auflisten (z.B. „Alle Nachrichten eines Users, sortiert nach Datum"), (2) Tabelle für jede Query entwerfen (Partition Key = Query-Filter, Clustering Columns = Sortierung), (3) Denormalisierung akzeptieren (gleiche Daten in mehreren Tabellen), (4) Schreib-Aufwand evaluieren (mehr Tabellen = mehr Writes bei jeder Änderung).
- Partition-Sizing: Eine Partition sollte < 100 MB sein (Performance-Grenze). Zu große Partitionen (z.B. alle Nachrichten eines Users in einer Partition über 5 Jahre) -> Partition Split mit Compound Key (z.B. (user_id, year_month)). Zu viele kleine Partitionen -> ineffizient für Range-Scans.
- Anti-Patterns: Partitionslose Queries (Full Table Scan), Single-Partition-Hotspots (ein Key bekommt 90 % der Writes), übermäßige Denormalisierung (10 Tabellen für 3 Queries), Counter-Missbrauch, Collection-Spalten als Ersatz für eigene Tabellen.
- Modellierungs-Patterns: Time-Series (Partition per Device + Zeitfenster), Messaging (Partition per Conversation, Clustering per Timestamp), Sensor-Daten (Partition per Sensor + Tag, Clustering per Sekunde), User Activity (Partition per User + Monat), Wide Row (wenige Partitionen, viele Clustering Rows).
- Praxis-Übung: Datenmodell für eine Messaging-Applikation entwerfen: 5 Queries definieren (Nachrichten einer Conversation, letzte Conversations eines Users, ungelesene Nachrichten, Nachricht per ID, Suche nach Datum). Für jede Query eine Tabelle entwerfen. Partition-Sizing berechnen. Denormalisierung bewusst einsetzen. Modell im Cluster implementieren und alle 5 Queries testen.
4. Schreibpfad, Lese-Pfad und Compaction
- Write Path: Client -> Coordinator Node -> Commit Log (append-only, crash-safe) -> Memtable (In-Memory) -> Flush -> SSTable (on-disk, immutable). Deshalb ist Cassandra Write-optimiert: jeder Write ist ein sequentieller Append, kein Random I/O.
- Read Path: Client -> Coordinator Node -> Bloom Filter (schnelle Prüfung: ist der Key in dieser SSTable?) -> Partition Index -> SSTable(s) lesen -> Merge aus mehreren SSTables -> Ergebnis. Lesen ist aufwändiger als Schreiben - deshalb: Datenmodell so entwerfen, dass möglichst wenige SSTables gelesen werden.
- Compaction: Hintergrund-Prozess, der mehrere SSTables zu einer zusammenführt (entfernt Tombstones, merged Updates, reduziert Anzahl der Dateien). Strategien: SizeTieredCompactionStrategy (STCS - Standard, gut für Write-Heavy), LeveledCompactionStrategy (LCS - besser für Read-Heavy, gleichmäßigere Latenz), TimeWindowCompactionStrategy (TWCS - optimal für Zeitreihen, TTL-Workloads).
- Tombstones und gc_grace_seconds: Deletes erzeugen Tombstones (Löschmarkierungen), die erst nach gc_grace_seconds (Default: 10 Tage) bei Compaction entfernt werden. Zu viele Tombstones -> langsame Reads. Anti-Pattern: häufige Deletes in Cassandra (besser: TTL oder Datenmodell-Redesign).
- Praxis-Übung: Write Path beobachten: nodetool flush -> SSTables auf Disk inspizieren. 10.000 Zeilen schreiben, 5.000 updaten, 2.000 löschen -> nodetool compactionstats -> Compaction beobachten. Tombstone-Problem provozieren: 1.000 Zeilen löschen, Query auf die Partition -> Tombstone-Warning in Logs finden.
- Nodes hinzufügen (Scale-Out): Neuen Node zum Ring hinzufügen -> automatisches Token-Rebalancing -> Daten werden von bestehenden Nodes auf den neuen Node gestreamt. Zero Downtime. Linear mehr Throughput und Speicher.
- Nodes entfernen (Decommission): nodetool decommission -> Node gibt seine Token ab, Daten werden auf verbleibende Nodes verteilt -> Node verlässt den Ring sauber.
- Repair: Anti-Entropy-Mechanismus - gleicht Daten zwischen Replicas ab, die durch Netzwerkprobleme, Node-Ausfälle oder Hints-Timeout inkonsistent geworden sind. nodetool repair - regelmäßig ausführen (mindestens innerhalb von gc_grace_seconds). Incremental vs. Full Repair.
- Multi-Datacenter: NetworkTopologyStrategy mit RF pro DC (z.B. DC1: RF=3, DC2: RF=3). LOCAL_QUORUM als Consistency Level -> Queries werden nur im lokalen DC beantwortet (niedrige Latenz), Replikation ins Remote-DC asynchron. Disaster Recovery: ein DC fällt komplett aus -> anderes DC übernimmt nahtlos.
- Backup und Restore: nodetool snapshot (konsistenter Snapshot aller SSTables), Medusa (Spotify: automatisiertes Backup auf Object Storage), Restore per Node oder ganzen Cluster.
- Praxis-Übung: Vierten Node zum 3-Knoten-Cluster hinzufügen -> nodetool status beobachten (Streaming-Fortschritt). Node wieder decommissionen. nodetool repair auf einer Tabelle ausführen. Snapshot erstellen und inspizieren.
- CQL Tracing: TRACING ON -> Query-Execution-Details (welche Nodes kontaktiert, Latenz pro Node, Partitionen gelesen, SSTables gescannt). Für Debugging langsamer Queries.
- Indexierung: Secondary Indexes (nur für Low-Cardinality, z.B. Status-Feld), Materialized Views (automatisch aktualisierte denormalisierte Tabellen - mit Einschränkungen), SASI (SSTable Attached Secondary Index - für Prefix- und Range-Suche).
- Performance-Konfiguration: memtable_allocation_type, commitlog_sync, concurrent_reads/writes, compaction_throughput_mb_per_sec, read_request_timeout, key_cache, row_cache.
- Monitoring: JMX-Metriken (Read/Write Latency, Pending Tasks, Compaction, Tombstone Scans), Prometheus + cassandra_exporter + Grafana als Standard-Stack, DataStax MCAC (Metric Collector for Apache Cassandra). Wichtigste Metriken: P99-Latenz, Pending Compactions, Dropped Mutations, Tombstone Warnings.
- Praxis-Übung: CQL Tracing für die Messaging-Queries aktivieren - langsame Query identifizieren und optimieren (Datenmodell anpassen oder Cache konfigurieren). Prometheus + Grafana auf dem Cluster einrichten, vorgefertigtes Cassandra-Dashboard importieren, Load-Test mit cassandra-stress -> Metriken beobachten.
7. Integration: Kafka, Spark und Applikations-Treiber
- Applikations-Treiber: DataStax Java Driver (Standard), Python Driver (cassandra-driver), Node.js Driver, Go Driver (gocql). Prepared Statements (Performance + SQL-Injection-Schutz), Connection Pooling, Load Balancing Policies (DCAwareRoundRobinPolicy), Retry Policies, Speculative Execution.
- Kafka -> Cassandra: Kafka Connect Cassandra Sink Connector - Events aus Kafka-Topics direkt in Cassandra-Tabellen schreiben. Für Event-Sourcing, CDC, IoT-Daten-Ingestion. Konfiguration: Topic-to-Table-Mapping, Key-Mapping, TTL.
- Spark + Cassandra: Spark Cassandra Connector - Cassandra-Tabellen als Spark DataFrames lesen und schreiben. Für Batch-Analytics auf Cassandra-Daten (Cassandra für OLTP, Spark für OLAP). Co-Located Analytics: Spark-Worker auf Cassandra-Nodes -> Daten werden lokal gelesen (kein Netzwerk-Transfer).
- Change Data Capture (CDC): Cassandra CDC-Feature (seit 3.8) - Änderungen in Commit Log erfassen und an externe Systeme weiterleiten (Debezium Cassandra Connector). Für Event-Streaming, Cache-Invalidierung, Suchlindex-Updates.
- Praxis-Übung: Python-Applikation schreiben, die 10.000 Sensor-Datenpunkte in Cassandra schreibt und die letzten 100 Datenpunkte pro Sensor liest. Prepared Statements, DCAwareRoundRobinPolicy, Retry konfigurieren. Optional: Kafka Connect Sink -> Sensor-Daten aus Kafka-Topic in Cassandra-Tabelle schreiben.
- ScyllaDB: Cassandra-kompatibel (CQL, SSTable-Format), aber in C++ statt Java geschrieben -> 3-10× bessere Latenz bei gleichem Hardware-Einsatz, bessere Ressourcen-Nutzung (Shard-per-Core-Architektur), kein JVM-Tuning. Drop-in-Replacement für Cassandra. Wann ScyllaDB: wenn Latenz < 1ms P99 nötig, wenn Hardware-Kosten reduziert werden sollen.
- Amazon DynamoDB: Managed, serverless, zero Ops. Pay-per-Request oder Provisioned Capacity. Cassandra-kompatibel über Amazon Keyspaces. Wann DynamoDB: wenn kein Cluster-Betrieb gewünscht, wenn AWS-Lock-in akzeptabel, wenn Auto-Scaling ohne Aufwand nötig.
- DataStax Astra DB: Managed Cassandra as a Service, Multi-Cloud (AWS, Azure, GCP). Serverless-Option. Vektor-Suche integriert (Cassandra + Vektor-DB in einem).
- NewSQL-Alternativen: CockroachDB, YugabyteDB - horizontal skalierbar wie Cassandra, aber mit SQL, JOINs und Strong Consistency. Trade-off: höhere Write-Latenz als Cassandra, dafür SQL-Kompatibilität.
- Entscheidungsmatrix: Write-Heavy + Eventual Consistency ok -> Cassandra/ScyllaDB. Write-Heavy + Strong Consistency nötig -> YugabyteDB/CockroachDB. Managed + AWS -> DynamoDB. Read-Heavy + Joins -> PostgreSQL.
- Praxis-Übung: cassandra-stress auf dem 3-Knoten-Cluster ausführen: 100.000 Writes/Reads, P50/P99-Latenz messen. Ergebnis mit ScyllaDB-Benchmarks vergleichen (Trainer zeigt publizierte Benchmarks). Entscheidungsmatrix für 3 Use Cases ausfüllen: IoT-Plattform, E-Commerce-Warenkorb, Finanztransaktions-Log.
Phase 1 - Use Case und Queries (15 Min):
- Eigenen Use Case beschreiben (oder vorgegebenes Szenario: IoT-Plattform mit 10.000 Sensoren, 1 Mrd. Datenpunkte/Tag, 5 Queries).
- Queries exakt definieren: Welche Daten, welche Filter, welche Sortierung, welche Latenz-Anforderung?
- Für jede Query eine Tabelle entwerfen (Partition Key, Clustering Columns, Denormalisierung).
- Partition-Sizing berechnen: passt eine Partition unter 100 MB?
- Modell im Cluster implementieren, Testdaten laden, alle Queries ausführen und Latenz messen.
- Datenmodell vorstellen. Feedback: Sind die Partition Keys richtig? Gibt es Hotspots? Sind die Partitionen zu groß? Fehlt eine Tabelle für eine Query?
- Stresstest: „10× mehr Daten als heute - skaliert das Modell?" „Ein neuer Query-Typ wird gefordert - brauchen wir eine neue Tabelle?" „Ein Node fällt aus - was passiert mit CL=QUORUM?"
Zielgruppe & Vorkenntnisse
- Backend-Entwickler: Die hochverfügbare, horizontal skalierende Datenbanken für schreibintensive Workloads benötigen (IoT, Logging, Messaging, Zeitreihen, Nutzeraktivitäten).
- Platform Engineers und DevOps: Die Cassandra-Cluster aufbauen, betreiben und skalieren.
- Data Engineers: Die Cassandra als Speicherschicht in Streaming-Architekturen (Kafka -> Cassandra) einsetzen.
- Architekten und Tech Leads: Die Cassandra vs. DynamoDB vs. ScyllaDB vs. relationale Datenbanken bewerten.
Abgrenzung: Dieses Seminar behandelt Apache Cassandra als verteilte Wide-Column-Datenbank - nicht relationale Datenbanken (dafür: PostgreSQL, SQL Server), nicht Dokumentendatenbanken (dafür: MongoDB S2492/S2790), nicht Suchmaschinen (dafür: Elasticsearch S2004), nicht allgemeines NoSQL-Überblick (dafür: S3499, 3T) .
Ihre Schulung
In Präsenz | Online |
|---|---|
| Lernmethode | |
Ausgewogene Mischung aus Theorie und praktischen Übungen auf persönlichem Schulungs-PC. | Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent. |
| Unterlagen | |
Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. | Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne. |
| Arbeitsmaterialien | |
DIN A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its | |
| Teilnahmezertifikat | |
Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF. | |
Organisation
In Präsenz | Online | |
|---|---|---|
| Teilnehmendenzahl | ||
min. 1, max. 8 Personen | ||
| Garantierte Durchführung | ||
Ab 1 Teilnehmenden* | ||
| Schulungszeiten | ||
| ||
| Ort der Schulung | ||
 GFU SchulungszentrumAm Grauen Stein 27 51105 Köln-Deutz oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden. Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen. | ||
| Räumlichkeiten | ||
Helle und modern ausgestattete Räume mit perfekter Infrastruktur | Bequem aus dem Homeoffice von überall | |
| Preisvorteil | ||
Dritter Mitarbeitende nimmt kostenfrei teil. Eventuell anfallende Prüfungskosten für den dritten Teilnehmenden werden zusätzlich berechnet. Hinweis: Um den Erfolg der Schulung zu gewährleisten, sollte auch der dritte Teilnehmende die erwarteten Vorkenntnisse mitbringen. | ||
| KOMPASS — Förderung für Solo-Selbstständige | ||
Solo-Selbstständige können für dieses Seminar eine Förderung via KOMPASS beantragen. | ||
| All-Inclusive | ||
Gebäck, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch | Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu. | |
| Barrierefreiheit | ||
Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei | - | |
Buchen ohne Risiko
| Rechnungsstellung |
Erst nach dem erfolgreichen Seminar. Keine Vorkasse. |
| Stornierung |
Kostenfrei bis zum Vortag des Seminars |
| Vormerken statt buchen |
Sichern Sie sich unverbindlich Ihren Seminarplatz schon vor der Buchung - auch wenn Sie selbst nicht berechtigt sind zu buchen |
Kostenfreie Services
In Präsenz | Online |
|---|---|
|
|
Buchungsmöglichkeiten
Online oder in Präsenz teilnehmen
Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.
Gesicherte offene Termine
| Termin | Ort | Preis | ||
|---|---|---|---|---|
| 10.08.-12.08.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 12.10.-14.10.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 14.12.-16.12.2026 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 2027 | ||||
| 19.04.-21.04.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
| 21.06.-23.06.2027 Plätze vorhanden Köln / Online 2.030,00 | Köln / Online | 2.030,00 | Buchen Vormerken | |
Inhouse-/Firmenschulung
- Lernumgebung in der Cloud
- Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Individualschulung
- Lernumgebung in der Cloud
- 1 Teilnehmender = Fokus aufs Fachliche und maximaler Raum für individuelle Fragen.
Präsenz Online Hybrid
Nachbetreuung
Unterstützung nach der Schulung durch
individuelle Nachbetreuung
FAQ für Offene Schulungen
Welche Schulungsform ist ideal für mich?
- Alle folgenden Schulungsformen können auch Online als Virtual Classroom durchgeführt werden.
- Eine Offene Schulung findet zu einem festgelegten Zeitpunkt im voll ausgestatteten Schulungszentrum oder Online/Remote statt. Sie treffen auf Teilnehmende anderer Unternehmen und profitieren vom direkten Wissensaustausch.
- Eine Inhouse-/Firmen-Schulung geht auf die individuellen Bedürfnisse Ihres Unternehmens ein. Sie erhalten eine kostenfreie Beratung von Ihrem Seminarleiter und können Inhalte und Dauer auf Ihren Schulungsbedarf anpassen. Inhouse-Schulungen können Europaweit durchgeführt werden.
- Bei einer Individual-Schulung erhalten Sie eine 1-zu-1 Betreuung und bestimmen Inhalt, Zeit und Lerntempo. Der Dozent passt sich Ihren Wünschen und Bedürfnissen an.
Wie kann ich an einer Online Schulung teilnehmen?
Sie können unsere Schulungen auch als Remote Schulung im Virtual Classroom anfragen.
In drei Schritten zum Online Seminar im Virtual Classroom:
- Seminar auswählen und auf "Buchen" klicken
- Wählen Sie bei "Wie möchten Sie teilnehmen?" einfach "Online" aus.
- Formular ausfüllen und über den Button "Jetzt buchen" absenden.
Unser Kundenservice meldet sich bei Ihnen mit der Buchungsbestätigung.
Was ist ein Virtual Classroom?
Unsere Online Schulungen finden im Virtual Classroom statt. Ein Virtual Classroom bündelt mehrere Werkzeuge, wie Audio-Konferenz, Text-Chat, Interaktives Whiteboard, oder Application Sharing.
Vorteile von Virtual Classroom:
- Sie erhalten 1 zu 1 die gleiche Lernumgebung, die Sie auch vor Ort bei uns vorfinden
- Die technische Vorbereitung wird von den GFU-Technikern vorgenommen
- Sie erhalten remote Zugriff auf Ihren persönlichen Schulungs-PC im GFU-Seminarraum
- Die Virtual Classroom Lösung lässt sich auch im Browser betreiben
- Die GFU-Technik leistet wie gewohnt Soforthilfe bei Problemen
- Die Schulungsunterlagen bekommen Sie via DHL zugeschickt
- Sie sparen Reisekosten und Zeit
Welche gesicherten Termine gibt es?
- 10. Aug. - 12. Aug. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 12. Okt. - 14. Okt. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 14. Dez. - 16. Dez. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 19. Apr. - 21. Apr. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- 21. Jun. - 23. Jun. ✓ Noch einige Plätze frei ▶ Köln + Online/Remote
- Auch als Inhouse-Schulung, bundesweit mit Termin nach Wunsch und individuellen Inhalten
- Buchen ohne Risiko! Kostenfreie Stornierung bis zum Vortag des Seminars
Das GFU-Sorglos-Paket
Die Seminare der GFU finden in angenehmer Atmosphäre statt und sind perfekt organisiert. Profitieren Sie von dem Rundum-Service der GFU!
Shuttle-Service
Machen Sie sich keinen Kopf um die Anreise! Unser Shuttle fährt Sie. Oder Sie parken einfach auf einem extra für Sie reservierten Parkplatz.
Hotelreservierung
Hotelzimmer gesucht? Wir organisieren Ihnen eins. Ihr Vorteil: Sie sparen Zeit und Geld!
Kostenfreies Storno
Stornierung bei offenen Seminaren kostenfrei bis einen Tag vor Schulungsbeginn.
Technik-Support
Unsere Techniker sind immer zur Stelle, egal ob online oder vor Ort.