apitech/loki - loki - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Robert Fratto	56e7318bec	chore(engine): don't sort metric queries (#18594 )	10 months ago
Ashwanth	cc9f9e199f	chore(engine): add predicate columns to projection list for metric queries (#18608 )	10 months ago
Christian Haudum	31fcc816e4	chore(engine): Minor logging cleanup in new query engine (#18513 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	10 months ago
Christian Haudum	acc8054444	chore(engine): Add tests for predicate pushdown for ambiguous columns (#18497 ) Ambiguous columns (columns that can either be a label or structured metadata) cannot be pushed down to the dataobjscan, because the dataobj reader lacks the capability of handling the precedence of metadata over labels. This change adds test cases that ensure that predicates with ambiguous columns are not pushed down in the optimizer. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	11 months ago
benclive	517c317c97	chore: Integrate indexes with the new query engine (#18427 )	11 months ago
Christian Haudum	1e9d2f58e9	chore(engine): Fix logical plan for metric queries (#18471 ) The logical plan for metric queries previously omitted the SORT instruction, because if would have translated into a SortMerge with a topK. However, due to the recent change, the sort merge does not do the topK any more, but is still used to merge multiple DataObjScan inputs in DESC timestamp order. This is required for the SELECT instruction (Filter operation), since it only accept a single input, which is ensured by the SORT. Fixes the error `filter expects exactly one input, got N`. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	11 months ago
Christian Haudum	d9f7d785ff	chore(engine): Sort entries in dataobj sections by timestamp descending (#18367 ) Sorting sections by `timestamp DESC` first and `streamID ASC` second allows for more efficient reading (by section) for BACKWARD log queries. - This change breaks FORWARD log queries. Which is ok for the time being. We will add support later again when columnar reading of the dataobj is introduced. - This change renders existing dataobj in storage incompatible. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	11 months ago
Christian Haudum	4305a6aa61	chore(engine): Make literals simple types (#17733 ) Representing data types as simple types (string, int64, float64) makes them more efficient to cast without conversion. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	11 months ago
Robert Fratto	a0914281b8	chore(engine): change DataObjScan to only cover a single logs section (#18350 )	11 months ago
Ashwanth	646ebe81d8	chore(engine): adds AST conversion and result builders for metric queries (#18166 )	11 months ago
Christian Haudum	b316d52612	chore(engine): Use shard information from query frontend in the new query engine (#17792 ) What this PR does / why we need it: This PR introduces the sharding to the new query engine to be able to test the engine using the exsiting Loki architecture with query frontend, query scheduler, and queriers. Note, this is only an interim solution used for validating and testing. By design, the first phase of the query engine implementation does only local execution of queries without sharding or time-based splitting. However, for testing the results of this first phase, we can utilise dual-ingestion (writing both chunks/tsdb and data objects in a way that sharding and splitting is performed in the query frontend using the existing middlewares. On the queriers themselves, the sub-queries are parsed and planned using the new logical and physical planner. If the query can successfully be planned, it will be executed by the new engine, otherwise it falls back to the old engine. Shard size considerations While performing time-splitting in the frontend works for data objects as well, sharding by information from TSDB is not directly mappable to data objects. The default target shard size in TSDB is 600MB (decompressed), whereas target size of data objects is 1GB compressed or roughly 10-15GB uncompressed. However, individual logs sections of a data object have a target size of 128MB, which is roughly 0.9-1.2GB. That is 1.5-2x larger than the TSDB target shard size. So when using the sharding calculation from TSDB, it would over-shard for data object sections, which is likely acceptable for testing and good enough for proving that local execution with the new engine works. How does sharding with data objects in this PR work? The query frontend passes down the calculated shards as part of the query parameters of the serialised sub-request. The logical planner on the querier stores the Shard annotation on the `MAKETABLE` alongside the stream selector. This is then used by the physical planner to filter out only the relevant sections of the resolved data objects from the metastore lookup. During exeuction, only readers for the relevant sections are initialised when performing the `DataObjScan`. Signed-off-by: Christian Haudum <christian.haudum@gmail.com> Co-authored-by: Ashwanth <iamashwanth@gmail.com>	11 months ago
Christian Haudum	16ccf9be1e	chore(engine): Filter by unknown column (#18131 ) The new engine fails to execute a query when an `arrow.Record` (batch) does not contain the column on which a label filter is used, e.g. `\| foo="bar"` where `foo` is neither a label nor a structured metadata. This change also fixed an incorrect conversion of the label filter operator `=`, which was converted to `MATCH_STR`, but requires to be `EQ`. The new engine reflects current behaviour of a label filter `\| foo=""` where `foo` is undefined. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	12 months ago
Ashwanth	ba9b93ba42	chore(engine): add optimisations to pushdown and project groupby labels (#18101 )	12 months ago
Ashwanth	635896dab9	chore(engine): adds vector aggregation planning and execution nodes (#18100 )	12 months ago
Christian Haudum	78342c030a	chore(engine): Correctly propagate search direction to data object scan (#18112 ) The sort order of the physical plan was only used in the SortMerge node, but not on the DataObjScan. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	12 months ago
Ashwanth	e1206fb84d	feat(planning): adds physical and logical nodes for range aggregation (#17974 ) Signed-off-by: Ashwanth <iamashwanth@gmail.com> Co-authored-by: Owen Diehl <ow.diehl@gmail.com>	12 months ago
Christian Haudum	1629181f9c	chore(engine): Unify name and type of builtin columns (#17608 ) Names and types used when creating and collecting records need to match. * `Entry.Line` maps to `builtin.message` of type `arrow.BinaryTypes.String` * `Entry.Timestamp` maps to `builin.timestamp` of type `arrow.FixedWidthTypes.Timestamp_ns` Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	94b1d2d5ce	chore(engine): Improve type system of the new query engine (#17456 ) What this PR does / why we need it: The original type system for the new engine was introduced before adding Apache Arrow and with that an additional type system. One aspect of the new type system of this PR is that the logical types of the engine are aligned/interchangeable with the arrow logical types. ```go type Type uint8 const ( NULL = Type(arrow.NULL) BOOL = Type(arrow.BOOL) STRING = Type(arrow.STRING) INT64 = Type(arrow.INT64) FLOAT64 = Type(arrow.FLOAT64) ) ``` The actual data types of Loki (`Boolean`, `String`, `Integer`, `Float`, `Timestamp`, `Duration`, and `Bytes`) are implemented as wrapper around a logical type. Different data types can use the same logical type as representation, such as `Integer`, `Timestamp` and `Duration` both use `INT64`. Since Arrow array types are bound to logical types, and one logical type can have multiple Loki data types, it is required to "annotate" Fields of an arrow.Record using its Metadata, similar to how it is done for distinguishing builtin columns from label/metadata/parsed columns. Additionally, the PR contains a mapping between Loki types and Arrow types. The `Literal` has been updated to use the new types. The old system also used UINT64 as representation of the `Timestamp` type, which is incorrect, since both LogQL and the DataObjects allow timestamps before unix epoch. --- Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	6b4430afd0	chore(engine): Collect pipeline records into Loki result (#17447 ) This PR adds the missing piece between existing HTTP handler and the new execution engine, which converts the Apache Arrow records from the vectorized, columnar, pull-based iterator pipeline into the existing (row-based) Loki response format. Since the engine only supports logs queries at the moment, the transformation logic does not take possible metric query results into account. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	64c477b1f7	chore(engine): Add framework for query executor (#17260 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	1705f98a9f	chore(engine): Wire up new execution engine (#17032 ) This PR connects the already existing components of the new query engine and wires them up in the querier API. The feature flag `-querier.engine.enable-v2-engine` controls whether supported queries should be executed using the new engine. Note that this implementation currently does not execute any queries. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	ba61aa88de	chore(engine): Integrate metastore into physical query planning (#17016 ) This PR integrates the data object lookup using the metastore into the query planning. To achieve that, I extended the `Metastore` interface with an additional function that not only returns the data object paths, but also the stream IDs of streams that match the given label matchers. ```go type Metastore interface { ... // StreamsIDs returns object store paths and stream IDs for all matching objects for the given matchers between [start,end] StreamIDs(ctx context.Context, start, end time.Time, matchers ...*labels.Matcher) ([]string, [][]int64, error) ... } ``` Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	6824f4e575	chore(engine): Add printer for Mermaid diagram format (#17000 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	04d2ba3ca8	chore(engine): Add simple plan optimizer (#16965 ) This PR adds a plan optimizer that pushes down limit and filter predicates to the scan node. ### Example Plan: ``` Limit #0xc0000110f8 offset=0 limit=1000 └── Filter #0xc00039dd10 │ └── Predicate expr=LT(timestamp.builtin, 1742826126000000000) └── Filter #0xc00039ddd0 │ └── Predicate expr=GT(age.metadata, 21) └── SortMerge #0xc00039de60 column=timestamp.builtin order=ASC ├── DataObjScan #0xc00011b420 location=obj1 stream_ids=(1, 2) projections=() direction=0 limit=0 └── DataObjScan #0xc00011b490 location=obj2 stream_ids=(3, 4) projections=() direction=0 limit=0 ``` Optimized plan: ``` Limit #0xc0000110f8 offset=0 limit=1000 └── SortMerge #0xc00039de60 column=timestamp.builtin order=ASC ├── DataObjScan #0xc00011b420 location=obj1 stream_ids=(1, 2) projections=() direction=0 limit=1000 │ ├── Predicate expr=LT(timestamp.builtin, 1742826126000000000) │ └── Predicate expr=GT(age.metadata, 21) └── DataObjScan #0xc00011b490 location=obj2 stream_ids=(3, 4) projections=() direction=0 limit=1000 ├── Predicate expr=LT(timestamp.builtin, 1742826126000000000) └── Predicate expr=GT(age.metadata, 21) ``` Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	40223d7320	chore(engine): Unify `Literal` and `ColumnRef` across logical and physical plan (#16927 ) Literals and column refs are used by both the logical and physical plan. However, the interfaces they need to implement are partly private (`isValue()` and `isExpression()`). Therefore they are wrapped in their own struct that implement these interfaces. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	138093b900	chore(planner): Convert AST into logical plan (#16916 ) Minimal implementation of the logical planner that converts a parsed LogQL statement in AST form into a logical plan in SSA form. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Christian Haudum	efe15486fe	chore(engine): Add first stage of physical query planning (#16891 ) Planning consists of two stages: 1. Conversion stage: Instructions from the logical plan are converted into Nodes in the physical plan. Most instructions can be translated into a single Node. However, `MakeTable` translates into multiple `DataObjScan` nodes. 2. Pushdown stage: a) Push down the limit of the `Limit` node to the `DataObjScan` nodes. b) Push down filter predicates from the `Filter` nodes to the `DataObjScan` nodes. This PR implements only the first stage. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Robert Fratto	cbe97e6c1a	chore(engine): Update logical planner types to be structured as SSA (#16841 ) Signed-off-by: Robert Fratto <robertfratto@gmail.com> Co-authored-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago
Ashwanth	c51fa39684	chore(dataobj): pass down line filters to logs reader (#16802 )	1 year ago
Christian Haudum	9691f3e5dc	chore: Move `pkg/dataobj/planner` to `pkg/engine/planner` (#16815 ) The package pkg/dataobj/planner/logical was initially created within the package pkg/dataobj because of the dependency on the internal package pkg/dataobj/internal/metadatamd. However, the package should be located inside a separate package without the dependency on the dataobj package, since the engine should be storage agnostic. --- Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	1 year ago

30 Commits (21f3d09caab2cc6d64fbb07ceeaea8efbce25814)