Apache Flink Training: the exercise repository that ships with the Flink docs

An exercise repository, not a Flink distribution

flink-training is described in one line as the exercises that accompany the training content in the Flink documentation. The repository description calls it Apache Flink Training Excercises, and the licence is Apache-2.0 with the standard ASF header in the README.

The important thing to know before you clone it is what it is not. It is not a Flink distribution, it is not a job template, and it is not a demo application you would adapt. It is a set of graded exercises with their tests and their reference solutions, plus a common module that generates the data those exercises consume.

The audience is therefore a learner, and the second audience is an instructor. The module names visible at the repository root describe the shape of the curriculum: ride-cleansing, rides-and-fares, hourly-tips and long-ride-alerts, alongside common, config and the Gradle build files. Ride cleansing and rides and fares are the classic pair, one about cleaning a stream and one about joining two streams. The names are the curriculum, and each one is a self contained subproject.

The homepage for the project points at flink.apache.org, which is where the training content itself lives. The last push to this repository was on 2026-05-15, and the repository has no GitHub releases, so the branch structure is the versioning mechanism here rather than a tag list.

The JDK constraint: Java 8 or 11, and a JRE will not do

The software requirements section is short and strict, and the strictness is worth reading before you set anything up.

Flink supports Linux, OS X and Windows as development environments for Flink programs and local execution. The required tools are Git, a JDK for Java 8 or Java 11, and an IDE for Java, and optionally Scala, development with Gradle support. The requirement states plainly that a JRE is not sufficient and that other versions of Java are currently not supported.

For the IDE, IntelliJ is recommended. Eclipse or Visual Studio Code with the Java extension pack can also be used so long as you stick to Java. For Scala, IntelliJ is required along with its Scala plugin.

Windows gets its own note, and the guidance is practical rather than prohibitive. The shell command examples in the training instructions are for UNIX systems, and the note says you may find it worthwhile to set up cygwin or WSL. It then adds that for developing Flink jobs Windows works reasonably well, because you can run a Flink cluster on a single machine, submit jobs, run the webUI and execute jobs in the IDE. So the limitation is about the shell examples, not about Flink on Windows.

Clone, build and the first dependency download

The build is a Gradle wrapper invocation, and the three tasks together are the whole setup:

git clone https://github.com/apache/flink-training.git
cd flink-training
./gradlew test shadowJar

The test task runs the test suite across the modules, and shadowJar produces the fat jar. On a first build you will end up downloading all of the dependencies for the project, which the documentation says usually takes a few minutes depending on the speed of the internet connection. The success criterion is stated plainly: if all of the tests pass and the build is successful, you are off to a good start. That is a useful property of a training repository, since a green build proves your toolchain works before you write any code.

There is a separate path for users in China, documented in a collapsible section. The recommendation is to configure the Maven repository to use a mirror, done by uncommenting a block in the build.gradle file:

    repositories {
        // for access from China, you may need to uncomment this line
        maven { url 'https://maven.aliyun.com/repository/public/' }
        mavenCentral()
    }

After the build, the project has to be imported into the IDE as a Gradle project. Once imported, the documentation says you should be able to open RideCleansingTest and run it, which is the fastest way to confirm that your editor, your Gradle integration and your local runtime all agree with each other.

Scala exercises are compiled out by default

The exercises exist in Scala as well as Java, and they are switched off by default. The reason given is a couple of reported problems from non-Scala users, and the project decided to disable them for that reason rather than because the Scala versions are unmaintained.

Re-enabling them means editing the gradle.properties file:

# Scala exercises can be enabled by setting this to true
org.gradle.project.enable_scala = true

The flag can also be applied selectively in a single subproject if you want, which is the route to take when you are working in Java and only want to look at one Scala exercise.

The Scala toolchain has its own constraint that interacts with this. The documentation says you need IntelliJ with the JetBrains Scala plugin, a Scala 2.12 SDK added to the Global Libraries section of the Project Structure and to the module you are working on, and it flags that Scala 2.12.8 and above are not supported, with a link to the Flink Scala Versions page for details. So the Scala path in this repository is the one with more moving parts, which is consistent with it being off by default.

Branches track Flink versions, and master is not flink:master

The repository layout note is the part that trips people up. This repository has several branches set up pointing to different Apache Flink versions, similarly to the apache/flink repository. There is a release branch for each minor version of Apache Flink, with release-1.10 given as the example, and a master branch that points to the current Flink release, which the note stresses is not flink:master.

The practical instruction follows: if you want to work on a version other than the current Flink release, check out the appropriate branch.

That distinction is easy to skim past and costly to get wrong. A training repository that is coupled to a specific Flink minor version will not compile against a different one without changes, because the DataStream API it teaches has moved over time. If you are following training content written for an older release, the matching release branch is the only place the exercises line up with the prose.

The Gradle build file is where the version coupling is expressed, and the build.gradle file is also the file you edit for the Maven mirror. The same file therefore carries both a network configuration and a version binding, which is worth knowing before you start changing things in it.

The taxi data is generated, not downloaded

The exercises use data generators that produce simulated event streams, and the generators live in the common module under the exercises common sources directory. That design choice removes the classic first obstacle in a data engineering course, which is getting a dataset onto a laptop.

The data is inspired by the New York City Taxi and Limousine Commission public data set about taxi rides in New York City, so the shape of the events resembles something real without carrying a real payload.

The documentation then describes the schemas: a ride is represented by two events, and there is a separate schema section for taxi fare events. The pairing of a ride event and a fare event is what makes the rides-and-fares exercise possible, since that module is the join between the two streams.

The generator approach also means the exercises are deterministic enough to be graded. The test suite ships in the repository next to the exercises, and a reference solution exists for each one, so a learner can compare behaviour rather than guess at expected output.

How the lab exercises are meant to be used

The table of contents in the documentation lists the flow it expects: set up your development environment, use the taxi data streams, then learn about the data, run and debug Flink programs in your IDE, and finally work through exercises, tests and solutions.

The order is deliberate and worth following. Learn about the data comes before running programs, which means the streaming model is introduced on a known dataset rather than on an opaque one. Running and debugging in the IDE comes before the exercises, so the local execution loop is established once, with a known good program, rather than while you are also trying to solve a problem.

The repository itself is described as containing exercises, tests and reference solutions for the programming exercises, which is the three-part structure the whole thing rests on. An exercise gives you a failing or incomplete implementation, a test states the expected behaviour, and a solution shows one way to satisfy it. For a learner that means feedback that is not the opinion of whoever is reading the code, and for an instructor it means a baseline that can be reused.

What the repository does not provide is a production scaffolding. There is no cluster deployment configuration, no monitoring setup and no streaming platform config in the layout, only the Gradle build, the config directory, the common module and the four exercise modules.

Editorial conclusion

Adopt flink-training if you are working through the Flink training material and want a real build, a real test suite and reference solutions to diff against, because that is exactly what the repository contains and it exercises Gradle, IDE import and local execution. Do not adopt it as a project template for a new service, because it is version-locked to a Flink release branch and pinned to Java 8 or 11. Before you start, check out the branch that matches the Flink version you intend to use, because master points at the current Flink release rather than at flink:master, and confirm your JDK is 8 or 11 since a JRE is not sufficient.

Frequently asked questions

Official sources

1. apache/flink-training on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README