address comments

Author: polyzos

website/blog/releases/0.7.md

@@ -48,7 +48,7 @@ These enhancements make Fluss 0.7 ready for most production use cases.
 In Fluss 0.5, we first introduced the Streaming Lakehouse feature, with the powerful Union Read ability, we can significantly reduce the cost of streaming storage and improve the data freshness of Lakehouse.
 > Note: Union Reads allows querying and combining the results from both Lakehouse (historical) and Fluss (real-time) data.
 
-However, the initial implementation had architectural limitations affecting scalability and operability in production. In 0.7, we’ve completely re-architected the Streaming Lakehouse feature to address these challenges.
+However, the initial implementation had architectural limitations affecting scalability and operability in production. In Fluss 0.7, we’ve completely re-architected the Streaming Lakehouse feature to address these challenges.
 
 ### Elastic Stateless Service
 Previously, the lake tiering service was implemented as a Flink job encapsulating Fluss as a Source and Paimon as a Sink, storing sync offsets state in Flink’s State, this making it a stateful service. 
@@ -70,7 +70,7 @@ This optimization significantly reduces the load on Fluss and boosts batch proce
 * **Actionable Offset Visibility:** The offset state is now queryable, providing greater insight and control over data processing.
 
 This design ensures end-to-end consistency across all operations.
-Furthermore, this stateless design also decouples us from tight Flink dependency, paving the way for future lightweight execution models, such as running on FaaS (Function as a Service).
+Furthermore, this stateless design also decouples us from the tight Flink dependency, paving the way for future lightweight execution models, such as running on FaaS (Function as a Service).
 
 ### Pluggable Lake Format
 The previous implementation had a tight coupling with Apache Paimon, which restricted our ability to integrate with other lake formats, such as Iceberg. 
@@ -95,13 +95,13 @@ Apart from that, we also support the following advanced partition features to ma
 * **Dynamic Partition Creation:** Automatically creates required partitions based on incoming data, no manual pre-creation is required.
 * **Automatic Partition Discovery:** Fluss source adds matched new partitions to the subscription in real-time.
 
-Using real business data from **Taobao - the largest online shopping in China,** we tested the read and write performance between non-partitioned and partitioned tables (with 20 auto-created partitions). The write results show that the multi-level partition and dynamic partition creation mechanism do not have a significant impact on the write performance.
+Using real business data from **Taobao - the largest online shopping platform in China,** we tested the read and write performance between non-partitioned and partitioned tables (with 20 auto-created partitions). The write results show that the multi-level partition and dynamic partition creation mechanism do not have a significant impact on the write performance.
 ![Write Perf](../assets/0.7/write_perf.jpg)
 
 At the same time, under the same data scale, we tested the streaming read performance of non-partitioned tables and partitioned tables under three partition conditions: 
 **unconditional**, **medium matching** (hitting five partitions), and **exact matching** (hitting one partition). 
-From the results we can observe that when the partition condition only matches 1/20 of the partitions,
-**the network traffic is reduced by about 20 times** and the **processing time is reduced by nearly 9 times**, 
+From the results, we can observe that when the partition condition only matches 1/20 of the partitions,
+**the network traffic is reduced by about 20x** and the **processing time is reduced by nearly 9x**, 
 demonstrating the huge performance benefit of partition pruning in streaming reads.