Closed killme2008 closed 1 year ago
https://github.com/vthriller/promql this crate may be useful, but seems out dated.
https://github.com/vthriller/promql this crate may be useful, but seeoutdatedted.
Thanks for the link. It looks great! Prometheus has switched to a yacc(goyacc) based parser, so the pure hand-written one might be outdated, but it's still precious to learn from.
The PromQL supported by Prometheus is used widely in cloud-native observability. We want to enable it natively in the GreptimeDB. The GreptimeDB already supports remote read/write protocol for Prometheus. But it's not good enough for performance and DevOps. We want to implement PromQL in pure Rust, and cooperate reasonably with our query engine and table engine. We want to push computation down into storage, reducing data transfer and providing the best performance. And also keep compatible with Prometheus.
The PromQL in Prometheus:
Including:
So our design will focus on these three parts too.
Looks like Prometheus is using yacc to generate the parser. I think we can use it too. Hand-wiring is another choice, but I think it's not necessary. Using the same grammar file is a better way to make our parser compatible with Prometheus easily.
The evaluator is the core part of the engine:
// An evaluator evaluates given expressions over given fixed timestamps. It
// is attached to an engine through which it connects to a querier and reports
// errors. On timeout or cancellation of its context it terminates.
type evaluator struct {
ctx context.Context
startTimestamp int64 // Start time in milliseconds.
endTimestamp int64 // End time in milliseconds.
interval int64 // Interval in milliseconds.
maxSamples int
currentSamples int
logger log.Logger
lookbackDelta time.Duration
samplesStats *stats.QuerySamples
noStepSubqueryIntervalFn func(rangeMillis int64) int64
}
The core function is eval:
// eval evaluates the given expression as the given AST expression node requires.
func (ev *evaluator) eval(expr parser.Expr) (parser.Value, storage.Warnings) {
....
}
It would be the most complex part of our work.
There are 70 functions at functions.go. They can be implemented step by step.
TODO
Prometheus provides a compatible test suite for other implementations. https://github.com/promlabs/promql-compliance-tester We can use it to test our implementation.
The first milestone may be in 2023, January. Make the PromQL run and let the compatible test cases pass over 60%.
Follow-up works are tracked at https://github.com/GreptimeTeam/greptimedb/issues/1042
What problem does the new feature solve?
Right now GreptimeDB only supports SQL and gRPC protocols to query data. PromQL prevails in cloud-native observability. We want to support PromQL natively in GreptimeDB, so I open this issue to track it.
What does the feature do?
Supports PromQL natively.
Implementation challenges
There are some challenges to supporting PromQL in GreptimeDB:
Procedure
group by
&group without
#870increase
/idelta
/irate
#880Compliance Test
https://github.com/prometheus/compliance/tree/main/promql
The follow-up works are tracked at https://github.com/GreptimeTeam/greptimedb/issues/1042