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 4de6b2e docs: fix typos in blog posts (#6)
4de6b2e is described below
commit 4de6b2ef63fdb1f053cc479ebfeecc417a99677e
Author: Mukunda Rao Katta <[email protected]>
AuthorDate: Fri May 15 01:30:13 2026 -0700
docs: fix typos in blog posts (#6)
---
blog/2025-06-01-partial-updates.md | 2 +-
blog/2025-07-07-fluss-java-client.md | 4 ++--
blog/2026-02-01-fluss-fraud-detection.md | 4 ++--
blog/2026-03-05-fluss-for-ai.md | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/blog/2025-06-01-partial-updates.md
b/blog/2025-06-01-partial-updates.md
index a250401..d5e8d69 100644
--- a/blog/2025-06-01-partial-updates.md
+++ b/blog/2025-06-01-partial-updates.md
@@ -137,7 +137,7 @@ INSERT INTO clicks VALUES
> **Note:** 🚨 So far the jobs we run were bounded jobs, so they will finish
> after inserting the records. Moving forward we will run some streaming jobs.
So keep in mind that each job runs with a `parallelism of 3` and our
environment is set up `with 10 slots total`.
-So make sure to keep an eye to the Flink Web UI to see how many slots are used
and how many are available and stop some jobs when are no longer needed to free
up resourecs.
+So make sure to keep an eye to the Flink Web UI to see how many slots are used
and how many are available and stop some jobs when are no longer needed to free
up resources.
**Step 4:** At this point let's open up a separate terminal and start the
Flink SQL CLI.
diff --git a/blog/2025-07-07-fluss-java-client.md
b/blog/2025-07-07-fluss-java-client.md
index c332fbc..24e5385 100644
--- a/blog/2025-07-07-fluss-java-client.md
+++ b/blog/2025-07-07-fluss-java-client.md
@@ -244,7 +244,7 @@ LogScanner logScanner = readingsTable.newScan()
```
```java
-Lookuper sensorInforLookuper = sensorInfoTable
+Lookuper sensorInfoLookuper = sensorInfoTable
.newLookup()
.createLookuper();
```
@@ -270,7 +270,7 @@ and creating a **SensorReadingEnriched** record.
logger.info("Received reading from sensor '{}' at '{}'.",
row.getInt(0), row.getTimestampNtz(1, 6).toString());
logger.info("Performing lookup to get the information for sensor
'{}'. ", row.getInt(0));
- LookupResult lookupResult = sensorInforLookuper.lookup(row).get();
+ LookupResult lookupResult = sensorInfoLookuper.lookup(row).get();
SensorInfo sensorInfo = lookupResult.getRowList().stream().map(r
-> new SensorInfo(
r.getInt(0),
r.getString(1).toString(),
diff --git a/blog/2026-02-01-fluss-fraud-detection.md
b/blog/2026-02-01-fluss-fraud-detection.md
index 3ac3983..62dd023 100644
--- a/blog/2026-02-01-fluss-fraud-detection.md
+++ b/blog/2026-02-01-fluss-fraud-detection.md
@@ -461,7 +461,7 @@ public DataStream<Transaction> createSource() {
.name("transactions-datastream");
}
```
-As you can see in the snippet below , the deserialization of the Fluss
`LogRecord` from the Transaction table into the `Transaction` POJO required by
the DataStream type is handled by the `TransactionDeserializationSchema` class,
which extends `FlussDeserializationSchema` to override the `deserialize`
method. The `record` is used to instanciate a `Transaction` POJO. The
corresponding changeLog type is mapped into the `kind` field and since the
Fluss source is a Log Table it always equals [...]
+As you can see in the snippet below , the deserialization of the Fluss
`LogRecord` from the Transaction table into the `Transaction` POJO required by
the DataStream type is handled by the `TransactionDeserializationSchema` class,
which extends `FlussDeserializationSchema` to override the `deserialize`
method. The `record` is used to instantiate a `Transaction` POJO. The
corresponding changeLog type is mapped into the `kind` field and since the
Fluss source is a Log Table it always equals [...]
Snippet from TransactionDeserializationSchema.java
```java
@@ -590,7 +590,7 @@ public DataStream<EnrichedFraud>
transform(DataStream<Fraud> fraudsDs) {
The ```fraudsView``` is a dynamic table created on top of the fraud stream.
It exposes a processing-time attribute.
For each record in ```f``` (```fraudsView```), the corresponding account row
is looked up as it existed at the processing time of ```f``` (```f.procTime```).
-Enriched records are converted back and returned as a
`DataStream<EnrichedFraud>` in order to be written to the Fluss sink by the
next startegy.
+Enriched records are converted back and returned as a
`DataStream<EnrichedFraud>` in order to be written to the Fluss sink by the
next strategy.
### 5. SinkStrategy interface and FraudFlussSinkStrategy implementation
This interface models the writing of a `Datastream<T>` to the FlinkSink,
exposing the `createSink` method.
diff --git a/blog/2026-03-05-fluss-for-ai.md b/blog/2026-03-05-fluss-for-ai.md
index 9056dc0..5d57447 100644
--- a/blog/2026-03-05-fluss-for-ai.md
+++ b/blog/2026-03-05-fluss-for-ai.md
@@ -108,7 +108,7 @@ As these capabilities came together, we started noticing a
recurring pattern: te
At its core, a feature store exists to compute and serve features, the
structured inputs consumed by machine learning models. These features might
represent recent activity, aggregated behavior, derived metrics, or
continuously updated scores that capture how an entity changes over time.
-The reason feature stores exist at all is a well-known failure mode in
production ML systems. Trainin data is often computed offline using batch
pipelines, while inference data is computed online using streaming or
request-time logic. Over time, these two paths drift apart in logic, timing, or
semantics.
+The reason feature stores exist at all is a well-known failure mode in
production ML systems. Training data is often computed offline using batch
pipelines, while inference data is computed online using streaming or
request-time logic. Over time, these two paths drift apart in logic, timing, or
semantics.
This divergence is commonly referred to as **training–serving skew**. It’s
subtle, hard to detect early, and is responsible for a large number of models
underperforming in production despite looking correct during training and
evaluation.
