01One business story, several views of truth
A new order exists before its payment does. A payment arrives later, a customer changes city, and an analytical view must catch up. This lab uses synthetic commerce data to make those changes visible across a complete local pipeline.
MySQL holds the business records. Flink CDC moves their changes into Fluss. A Flink SQL job maintains a joined order table and writes to Kafka, Fluss/Paimon and Iceberg. ClickHouse serves the results; a separate batch job recomputes hourly summaries and compares lake-table row counts.
02Choose your route
- New to streaming? Start with the learning path: records and changes → state and time → storage and serving → recovery and evidence.
- Comparing architectures? Read the component responsibilities and consistency boundaries, then follow one order through the worked cases.
- Ready to operate? Check source access and machine prerequisites, run the local doctor, then work through the verification steps.
03Read online. Experiment locally.
| Online reading | Local lab with source access |
|---|---|
| Bilingual lessons, diagrams, SQL excerpts and verification notes | Containers, generated orders, query console and native component UIs |
| Static pages that can be shared and revisited | Your own CPU, memory, disk and Docker runtime |
| No live databases or management endpoints | Start, inspect, run cases and stop while retaining volumes |
04Questions you will be able to answer
- Why does a stream join keep state after producing a row?
- What changes when a query reads a current table, a changelog or a committed lake snapshot?
- Why can two healthy sinks disagree temporarily, and what would make that disagreement suspicious?
- What does a checkpoint protect, and what extra evidence is needed to claim end-to-end correctness?
05A learning system with explicit boundaries
This is a single-machine, synthetic-data lab. It is not a throughput benchmark, production reference deployment or financial reconciliation service. The public site presents source-backed explanations and clearly labeled verification evidence; it does not simulate a live cluster.
The implementation repository is currently private. Reading this site does not grant clone access. Authorized collaborators can use the local guide; other readers can study the architecture, SQL excerpts and upstream documentation without installing anything.
CONTINUE EXPLORING
Start with a question, make a prediction, inspect the implementation, then collect evidence. Each stage builds a mental model needed by the next.
Read each layer by the responsibility it owns, the data shape it stores and the consistency boundary it introduces.
Each case gives you a question, a concrete action, an expected observation and a limit on what you can conclude. Queries run in your local console, not on this website.
The reading site needs no installation. Running services and the full management console requires authorized access to the private implementation repository.
A useful lab separates inspected source, executed checks, expected behavior and open questions. This page makes those distinctions explicit.
Technical statements are grounded in the implementation and primary project documentation. Versioned links are preferred so a newer manual does not silently redefine this lab.