This is an automated email from the ASF dual-hosted git repository.
polyzos pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/fluss-blog.git
The following commit(s) were added to refs/heads/main by this push:
new 61ece88 tiering-service-part1-hotfix (#12)
61ece88 is described below
commit 61ece88ebb13208b9ae75d97845275a21c9a0b37
Author: Giannis Polyzos <[email protected]>
AuthorDate: Thu Jun 4 12:44:32 2026 +0300
tiering-service-part1-hotfix (#12)
---
blog/2026-06-04-tiering-service-part1.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/blog/2026-06-04-tiering-service-part1.md
b/blog/2026-06-04-tiering-service-part1.md
index 4c928c6..b95421c 100644
--- a/blog/2026-06-04-tiering-service-part1.md
+++ b/blog/2026-06-04-tiering-service-part1.md
@@ -126,11 +126,11 @@ Three concepts are important to understand when you're
reading this:
We have one table, called `orders`, with four buckets. It's a log table (we'll
talk about what that means in Part 2, when we cover table kinds. For now, just
think **"an append-only stream of records"**). Freshness is configured to five
minutes. The Flink tiering job is up and running.
-Here's what happens:.
+Here's what happens:
#### T+0s the timer fires.
-Five minutes have passed since the last tiering round for `orders`. The
coordinator transitions the table from WAITING to READY and pushes it onto the
back of the pending queue. The act of entering the pending queue is also what
increments the table's tiering epoch · to (say) 7 · so every fresh attempt is
stamped at enqueue time, before any job has picked it up. Right now the queue
contains just `orders`.
+Five minutes have passed since the last tiering round for `orders`. The
coordinator transitions the table from WAITING to READY and pushes it onto the
back of the pending queue. The act of entering the pending queue is also what
increments the table's tiering epoch, to (say) 7, so every fresh attempt is
stamped at enqueue time, before any job has picked it up. Right now the queue
contains just `orders`.
#### T+0s the Flink job sends its heartbeat.
@@ -172,7 +172,7 @@ The freshness timer is computed from when the round
**completed**, not from when
That's it. Round complete. The lake now contains `orders` data up to the
offsets that were current at T+0s. In another ~five minutes, the whole process
repeats.
-> **The most subtle point in this section: The "stopping offset" is decided at
planning time, not at reading time.** When the enumerator asks the tablet
servers "what's your latest offset?" at T+0s, those answers freeze. Any records
written to Fluss after T+0s but before the readers actually start working are
not part of this round · they'll be picked up in the next one. This is correct
behavior, but it means the lake always lags by at least one round, even if your
freshness is configure [...]
+> **The most subtle point in this section: The "stopping offset" is decided at
planning time, not at reading time.** When the enumerator asks the tablet
servers "what's your latest offset?" at T+0s, those answers freeze. Any records
written to Fluss after T+0s but before the readers actually start working are
not part of this round; they'll be picked up in the next one. This is correct
behavior, but it means the lake always lags by at least one round, even if your
freshness is configured [...]
## Next Up
You've now got the mental model, the processes, the heartbeat conversation,
the lifecycle, and what happens during one full round.
