Updated on 2024-10-23 GMT+08:00

Structured Streaming Functions and Reliability

Functions Supported by Structured Streaming

  1. ETL operations on streaming data are supported.
  2. Schema inference and partitioning of streaming DataFrames or Datasets are supported.
  3. Operations on the streaming DataFrames or Datasets are supported, including SQL-like operations without types (such as select, where, and groupBy) and RDD operations with types (such as map, filter, and flatMap).
  4. Aggregation calculation based on Event Time and processing of delay data are supported.
  5. Deduplication of streaming data is supported.
  6. Status computing is supported.
  7. Stream processing tasks can be monitored.
  8. Batch-stream join and stream join are supported.

    The following table lists the supported join operations.

    Left Table

    Right Table

    Supported Join Type

    Description

    Static

    Static

    All types

    In stream processing, join operations with no streaming data involved are supported.

    Stream

    Static

    Inner

    Supported, but stateless.

    Left Outer

    Supported, but stateless.

    Right Outer

    Not supported.

    Full Outer

    Not supported.

    Stream

    Stream

    Inner

    Supported. The watermark or time range can be used to clear status of the left and right tables.

    Left Outer

    Conditionally supported. The watermark can be used to clear status of the left table, and watermark and time range must be used for the right table.

    Right Outer

    Conditionally supported. The watermark can be used to clear status of the right table, and watermark and time range must be used for the left table.

    Full Outer

    Not supported.

Functions Not Supported by Structured Streaming

  1. Multi-stream aggregation is not supported.
  2. The following operations of obtaining multiple rows are not supported: limit, first, and take.
  3. Distinct is not supported.
  4. Sorting is supported only when output mode is complete.
  5. The external connection between streams and static data sets is conditionally supported.
  6. Immediate query and result return on some data sets are not supported.
    • count(): Instead of returning a single count from streaming data sets, it uses ds.groupBy().count() to return a streaming data set containing the running count.
    • foreach(): The ds.writeStream.foreach(...) is used to replace it.
    • show(): The output console sink is used to replace it.

Structured Streaming Reliability

Based on the checkpoint and WAL mechanisms, Structured Streaming provides end-to-end exactly-once error tolerance semantics for the sources that can be replayed and the idempotent sinks that support repeated processing.

  1. You can enable the checkpoint function by setting option ("checkpointLocation", "checkpoint path") in the program.

    When data is restored from checkpoint, the application or configuration may change. Some changes may result in the failure in restoring data from the checkpoint. The restrictions are as follows:

    1. The number or type of sources cannot be changed.
    2. The source type and query statement determine whether the source parameter can change. For example:
      • The parameters related to rate control can be added, deleted, or modified. For example: spark.readStream.format("kafka").option("subscribe", "topic") is changed to spark.readStream.format("kafka").option("subscribe", "topic").option("maxOffsetsPerTrigger", ...).
      • Unexpected problems may occur when the topic/file of the consumption is modified. For example: spark.readStream.format("kafka").option("subscribe", "topic") is changed to spark.readStream.format("kafka").option("subscribe", "newTopic").
    3. The type of sink changes. Specific sinks can be combined. The specific scenarios need to be verified. For example:
      • File sink can be changed to kafka sink. Kafka processes only new data.
      • Kafka sink cannot be changed to file sink.
      • Kafka sink can be changed to foreach sink, and vice versa.
    4. The sink type and query statement determine whether the sink parameter can change. For example:
      • The output path of file sink cannot be changed.
      • The output topic of Kafka sink can be changed.
      • The custom operator code in foreach sink can be changed, but the change result depends on the user code.
    5. The projection, filter, and map-like operations can be changed in some scenarios. For example:
      • Filters can be added and deleted. For example: sdf.selectExpr("a") is changed to sdf.where(...).selectExpr("a").filter(...).
      • When Output schema is the same, projections can be changed. For example: sdf.selectExpr("stringColumn AS json").writeStream is changed to sdf.select(to_json(...).as("json")).writeStream.
      • If Output schema is different, projections can be changed in some conditions. For example: when sdf.selectExpr("a").writeStream is changed to sdf.selectExpr("b").writeStream, no error occurs only when the sink supports schema conversion from a to b.
    6. In some scenarios, the status restoration will fail after status is changed.
      • Streaming aggregation: For example, in the sdf.groupBy("a").agg(...) operation, the type or quantity of the grouping key or the aggregation key cannot be changed.
      • Streaming deduplication: For example, in the sdf.dropDuplicates("a") operation, the type or quantity of the grouping key or the aggregation key cannot be changed.
      • Stream-stream join: For example, in the sdf1.join(sdf2, ...) operation, the schema of the association key cannot be changed, and the join type cannot be changed. Change of other join conditions may lead to uncertainty results.
      • Any status computing: You cannot modify the schema or timeout type of the user-defined status in operations such as sdf.groupByKey(...).mapGroupsWithState(...) and sdf.groupByKey(...).flatMapGroupsWithState(...). While users can change the state-mapping function, the outcome depends on their code. If schema changes are necessary, users can encode or decode the status data into binary data to enable schema migration.
  1. Fault tolerance list of Source

    Sources

    Supported Options

    Fault Tolerance Supported

    Description

    File source

    path: file path, which is mandatory.

    maxFilesPerTrigger: maximum number of files in each trigger. The default value is infinity.

    latestFirst: whether to process limited number of new files. The default value is false.

    fileNameOnly: whether the file name is used as the new file for verification instead of using the complete path. (Default value: false)

    Supported

    Paths with wildcard are supported, but multiple paths separated by commas (,) are not supported.

    Files must be placed in a given directory in atomic mode, which can be implemented through file movement in most file systems.

    Socket Source

    host: IP address of the connected node, which is mandatory.

    port: connected port, which is mandatory.

    Not supported.

    -

    Rate Source

    rowsPerSecond: number of rows generated per second. The default value is 1.

    rampUpTime: rising time before the speed specified by rowsPerSecond is reached.

    numPartitions: concurrency degree for generating data rows.

    Supported

    -

    Kafka Source

    For details, see https://archive.apache.org/dist/spark/docs/3.3.1/structured-streaming-kafka-integration.html.

    Supported

    -

  2. Fault tolerance list of Sink

    Sinks

    Supported Output Mode

    Supported Options

    Fault Tolerance

    Description

    File Sink

    Append

    Path: The specified file format must be specified.

    For details, see APIs in DataFrameWriter.

    exactly-once

    Data can be written to partition tables. Time-based partition is better.

    Kafka Sink

    Append, Update, Complete

    For details, see https://archive.apache.org/dist/spark/docs/3.3.1/structured-streaming-kafka-integration.html.

    at-least-once

    For details, see https://archive.apache.org/dist/spark/docs/3.3.1/structured-streaming-kafka-integration.html.

    Foreach Sink

    Append, Update, Complete

    None

    Depends on ForeachWriter.

    For details, see https://archive.apache.org/dist/spark/docs/3.3.1/structured-streaming-programming-guide.html#using-foreach.

    ForeachBatch Sink

    Append, Update, Complete

    None

    Depends on operator.

    For details, see https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#using-foreach-and-foreachbatch.

    Console Sink

    Append, Update, Complete

    numRows: number of rows printed in each round. The default value is 20.

    truncate: whether to clear the output when the output is too long. The default value is true.

    Not supported

    -

    Memory Sink

    Append, Complete

    None

    Not supported. In complete mode, the entire table is rebuilt after the query is restarted.

    -