The reverse process of converting serialized data back into its original data structure or object.
Refers to components or operations that come later in a data processing pipeline, closer to the sink.
A continuous flow of data generated by events, such as user interactions, sensor readings, or system logs.
The time at which an event actually occurred, as recorded in the event data.
The time difference between when an event actually occurred and when it is processed by the stream processing system.
The time delay between an event occurring and the result of processing that event being available.
The time at which an event is processed by the stream processing system.
The practice of analyzing data as it is generated, providing immediate insights and enabling timely decision-making.
The process of converting data structures or objects into a format that can be stored or transmitted (e.g., JSON, Avro, Protobuf).
A piece of metadata associated with an event that indicates when it occurred.
The rate at which a stream processing system can process events, typically measured in events per second or bytes per second.
Refers to components or operations that come earlier in a data processing pipeline, closer to the source.
The process of summarizing data in a stream by computing metrics such as sum, average, count, or max.
A method of analyzing streams of events to detect patterns, correlations, and trends.
The process of removing duplicate events from a stream to ensure accurate processing.
A fixed-size window that advances by a smaller step than its size, creating overlaps.
The process of identifying sequences of events that match a specific pattern within a stream.
A window defined by periods of activity followed by gaps of inactivity.
An auxiliary input to a stream processing pipeline, often used to provide additional context or data to enrich the main stream.
A type of join operation that matches events from two streams within a specified time range.
The process of computing summary statistics (e.g., sum, average, count) over a data stream.
The process of adding additional data to events in a stream, often by joining the stream with a reference dataset.
An operation that combines events from two or more streams based on a common key, often within a specified time window.
A fixed-size, non-overlapping window. Each event belongs to exactly one tumbling window.
A type of stream processing where the system maintains and updates state based on processed events.
A type of stream processing where each event is processed independently, without relying on any information about past events.
The process of computing an aggregate function (e.g., sum, average, count) over the events within a specific window.
The point in time when a window is considered complete and its results are finalized.
A technique for dividing a continuous stream of data into finite chunks or "windows" based on time, count, or other criteria.
A mechanism that determines when the results of a windowed computation should be emitted.
The maximum amount of time after a window closes that late events can still be processed.
The process of dividing a data stream into smaller, independent subsets (partitions) based on a key.
A data stream where each event has a key, allowing for partitioning and stateful processing.
Events that arrive after the watermark for their corresponding window has already passed.
Events that arrive at the stream processing system with timestamps earlier than the current watermark.
The process of redistributing events in a stream based on a key, often to balance load across processing tasks.
The difference between event time and processing time.
A mechanism in event stream processing for tracking the progress of event time.
A delivery guarantee ensuring that each event is processed at least one time.
A delivery guarantee ensuring that each event is processed at most once.
A special queue used to store events that cannot be processed due to errors or invalid data.
A strong delivery guarantee ensuring that each event is processed exactly once, even with failures.
The ability of a system to continue operating correctly in the presence of failures.
A property of an operation where applying it multiple times has the same effect as applying it once.
The process of restoring a stream processing system to normal operation after a failure.
A consistent snapshot of the state of a stream processing application at a specific point in time.
A type of checkpoint that only stores the changes to the state since the last checkpoint, rather than the entire state.
Information maintained by the stream processing system about past events.
A mechanism that regulates the flow of data in a stream processing system.
The ability of a stream processing system to automatically adjust resources based on workload demands.
The ability of a stream processing system to handle increasing amounts of data and processing demands by adding more resources.
The destination where the processed data from a stream processing system is sent.
The origin of a data stream.
A unit of concurrent computation in RisingWave.
The physical representation of data streams in RisingWave's storage layer.
A process in RisingWave for populating a materialized view with historical data while keeping it consistent with real-time updates.
A control message used for synchronizing operators and ensuring consistent checkpointing in RisingWave.
A service in RisingWave responsible for optimizing the storage layer by merging and reorganizing data.
A node in RisingWave's architecture that performs data processing tasks.
An interface in RisingWave that enables integration with external systems for data ingestion and output.
A query in RisingWave that runs continuously on incoming data streams, updating its results in real time.
The entry point for users to interact with a RisingWave cluster.
A precomputed and continuously updated result of a query in RisingWave.
The central coordinator in a RisingWave cluster that manages metadata and orchestrates cluster operations.
A representation of how a query will be executed in RisingWave.
The ability of a database to handle changes to the structure of data without requiring downtime or manual intervention.
A node in RisingWave's architecture that manages the storage of data streams and state.
A logical unit of a query plan in RisingWave.
A SQL-based language used in RisingWave for defining and querying data streams.
RisingWave's ability to handle both batch and stream processing workloads within a single system.
In RisingWave, a watermark is an event-time mechanism used to track progress in processing streams, similar to the general watermark concept.
An open-source, distributed stream processing framework known for its low-latency processing, exactly-once semantics, and support for both batch and stream processing.
A distributed, high-throughput, fault-tolerant event streaming platform often used as a message broker for stream processing applications.
A micro-batch-based stream processing framework built on top of Apache Spark.
A unified programming model for defining both batch and stream processing pipelines.
A distributed stream processing framework that is tightly coupled with Apache Kafka.
A streaming database built on top of Apache Kafka.
A streaming database that provides low-latency access to materialized views over streaming data.
The ability to reprocess historical events from a stream, often for debugging or backfilling purposes.