Hey everyone, I've been trying to set up Arize for a new streaming inference service we're building (Kafka -> Flink -> real-time model). The documentation keeps mentioning the `prediction_id` field, but I'm hitting a conceptual wall.
From what I gather, a `prediction_id` is supposed to uniquely identify each prediction event. My pipeline generates millions of events daily, and we don't naturally have a unique business key for every single inference—our downstream aggregations work on user sessions or batch timestamps. Forcing a UUID into every event feels like an extra payload and processing step.
So my practical questions:
* Is the `prediction_id` absolutely **required** for Arize to function, or can we use a composite of `model_id`, `timestamp`, and other features as a logical key?
* If it *is* mandatory, what's the underlying architectural reason? Is it for idempotent writes, joining actuals later, or something else?
* For those with high-volume streaming setups, how did you generate this ID without adding latency? Did you bake it into your model's scoring code, or add it in the pipeline?
I'm trying to understand the trade-off between system simplicity and observability tooling requirements. Any insights from your own implementations would be super helpful.
—Claire
The prediction ID is architecturally non-negotiable for any monitoring platform doing point-in-time analysis. The technical reason is that it's the primary key for the entire observability store. Without it, you cannot uniquely join a prediction to its later-arriving actual value, which breaks performance calculations. A composite key of model_id and timestamp will cause silent data collisions at high volume and make your data untrustworthy.
For generation, you don't need a business key. A UUID v4, or even a ULID if you want time-ordering, added in your Flink process function is trivial overhead. The payload increase is negligible compared to the feature payload you're already sending, and the latency impact is measured in microseconds for the ID generation itself. The real trade-off isn't system simplicity versus observability; it's between having a functioning observability system and a broken one.
What's your actual latency budget per event? I've yet to see a real-time model serving system where UUID generation was the bottleneck.
Show me the numbers, not the roadmap.
Great question. I agree with the other replies that the prediction_id is essential, but I get your hesitation about overhead.
In a past high-volume setup, we found that generating ULIDs in Flink was way more performant than UUIDs and gave us time-ordered IDs for debugging. The latency hit was negligible - less than generating a timestamp for us.
One caveat: if you ever plan to use Arize's monitoring for data drift or performance on specific cohorts, you'll absolutely need that unique join key. Trying to retrofit it later is a huge pain.
Keep it simple.