MonoVertex¶

MonoVertex is a simplified version of the Pipeline. The major design idea behind MonoVertex is to simplify data-processing in those cases where independently autoscaling vertices are not required. This means there will only be a single vertex called the MonoVertex, which is capable of running the Source, the Sink (with Fallback Sink if need be), and optionally the Transformer together. There is no concept of Edges in MonoVertex since there is only one Vertex. The MonoVertex runs the same containers run by the Pipeline, this means the users can switch between MonoVertex and Pipeline by just changing the spec. MonoVertex’s autoscaling is similar to the Source vertex of a Pipeline, where the vertex scales out if the pending at the Source is increasing, and scales down when the pending at the Source drops.

The major benefits of MonoVertex are as follows:

Very high TPS can be supported because there are no ISBs (RAFT consensus) in between.
Extremely low latency because there is no network hops between the Vertices (only one Vertex).
Low Operational overhead, no need to maintain ISBs.

MonoVertex - Condensed Pipeline with just one Vertex

Use cases of MonoVertex¶

There are a few scenarios where MonoVertex is the best fit, which can be best described as use-cases where “the user is reading from the Source, doing simple transformations, and writing to a Sink”. You don't need to scale these Source, Sink, or Map vertices by themselves. If the Sink can't keep up, you just need to add more pods. This brings a new set of Source, Transformer, and a Sink (optionally with a backup sink). The same goes for if the Source cannot keep up (pending is increasing), we just need to add more pods.

A Brief History¶

MonoVertex was developed because we found that, there are a decent amount of applications that read from Sources like Kafka, Pulsar, etc., and write to a User-Defined Sink (DBs, etc). Often, the transformation itself was not required because the User-Defined Sink can do the transformation before persisting the data in to the Sink. The extra hop through the ISB was not helping but just making things slower by adding more delays. Throughput was also getting limited to about 50K unless larger ISBs were used.

When not to use MonoVertex¶

The rule of thumb is, if you are just reading from the source and writing to a sink (with some transformation), then you might be able to get away with MonoVertex. For all other use cases, use the full Pipeline Semantics. Below are a few examples where you cannot use MonoVertex.

User-Defined Functions are not supported, only Transformer can be used. If you need Map support, please let us know by creating an issue,
If you are using the Reduce feature, then the full Pipeline semantics is required. This is because of the need for shuffling of data.
There are cases where you want to autoscale intermediate process nodes, especially in the case of ML workloads.
If there is a need for custom placement of vertices (e.g., GPU nodes for Inference), then the complete pipeline spec is required.
If you want to use the Join feature, then MonoVertex will not work.

Anatomy of MonoVertex¶

MonoVertex supports the same Sources, Sinks, and Transformers which are used in the Pipeline spec.

apiVersion: numaflow.numaproj.io/v1alpha1
kind: MonoVertex
metadata:
  name: simple-mono-vertex
spec:
  source:
    # same as the Pipeline Source
    # ...
    transformer: # transformer is an optional container to do any transformation to the incoming data before passing to the sink
    # same as the Pipeline Transformer
    # ...
  sink:
  # same as the Pipeline Sink
  # ...

Please keep in mind that, moving from a MonoVertex to Pipeline does not require code change, only spec change.

Example¶

A simple example using user-defined source, transformer, and sink.