Github user ahmed-mahran commented on a diff in the pull request:

    https://github.com/apache/spark/pull/14234#discussion_r71073739
  
    --- Diff: docs/structured-streaming-programming-guide.md ---
    @@ -410,26 +398,21 @@ see how this model handles event-time based 
processing and late arriving data.
     ## Handling Event-time and Late Data
     Event-time is the time embedded in the data itself. For many applications, 
you may want to operate on this event-time. For example, if you want to get the 
number of events generated by IoT devices every minute, then you probably want 
to use the time when the data was generated (that is, event-time in the data), 
rather than the time Spark receives them. This event-time is very naturally 
expressed in this model -- each event from the devices is a row in the table, 
and event-time is a column value in the row. This allows window-based 
aggregations (e.g. number of event every minute) to be just a special type of 
grouping and aggregation on the even-time column -- each time window is a group 
and each row can belong to multiple windows/groups. Therefore, such 
event-time-window-based aggregation queries can be defined consistently on both 
a static dataset (e.g. from collected device events logs) as well as on a data 
stream, making the life of the user much easier.
     
    -Furthermore this model naturally handles data that has arrived later than 
expected based on its event-time. Since Spark is updating the Result Table, it 
has full control over updating/cleaning up the aggregates when there is late 
data. While not yet implemented in Spark 2.0, event-time watermarking will be 
used to manage this data. These are explained later in more details in the 
[Window Operations](#window-operations-on-event-time) section.
    +Furthermore, this model naturally handles data that has arrived later than 
expected based on its event-time. Since Spark is updating the Result Table, it 
has full control over updating/cleaning up the aggregates when there is late 
data. While not yet implemented in Spark 2.0, event-time watermarking will be 
used to manage this data. These are explained later in more details in the 
[Window Operations](#window-operations-on-event-time) section.
     
     ## Fault Tolerance Semantics
     Delivering end-to-end exactly-once semantics was one of key goals behind 
the design of Structured Streaming. To achieve that, we have designed the 
Structured Streaming sources, the sinks and the execution engine to reliably 
track the exact progress of the processing so that it can handle any kind of 
failure by restarting and/or reprocessing. Every streaming source is assumed to 
have offsets (similar to Kafka offsets, or Kinesis sequence numbers)
     to track the read position in the stream. The engine uses checkpointing 
and write ahead logs to record the offset range of the data being processed in 
each trigger. The streaming sinks are designed to be idempotent for handling 
reprocessing. Together, using replayable sources and idempotant sinks, 
Structured Streaming can ensure **end-to-end exactly-once semantics** under any 
failure.
     
     # API using Datasets and DataFrames
    -Since Spark 2.0, DataFrames and Datasets can represent static, bounded 
data, as well as streaming, unbounded data. Similar to static 
Datasets/DataFrames, you can use the common entry point `SparkSession` (
    -[Scala](api/scala/index.html#org.apache.spark.sql.SparkSession)/
    --- End diff --
    
    many cases like this later


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org

Reply via email to