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 )	5 months ago
Robert Fratto	ed1b61d253	chore(engine): improve performance of topk pipeline (#18593 )	5 months ago
Robert Fratto	e1bc2f9d7f	chore(engine): fix panic when closing uninitialized prefetchWrapper (#18592 )	5 months ago
Robert Fratto	9129d8cdd0	chore(engine): use columnar logs.Reader for DataObjScan (#18577 )	5 months ago
Ashwanth	da4e59f8c6	chore(dataobj): store sort order information in section metadata (#18499 )	5 months ago
Christian Haudum	6f7dc12eb4	chore(engine): Add support for regex and substr filters (#18501 ) Filters predicates on ambiguous columns (basically any label filter expression) cannot be pushed down to the DataObjScan and need to be evaluated in the Filter node. This PR adds the evaluation functions for MATCH_RE(string,string) and MATCH_SUBSTR(string, string) and their negating equivalent. Under the hood, the PR also replaces the type specific comparison function implementations with a generic one, which now also handle arrow.Timestamp arrays correctly. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	5 months ago
Robert Fratto	86c57c8616	chore: consistently use new labels.Labels API (#18490 )	5 months ago
Christian Haudum	cea56469b9	chore(engine): Pass context to Pipeline's Read() function (#18459 ) This change unifies how the request context is passed through the execution of pipelines. Instead of storing the context on pipelines, pass them as argument to the `Read()` function. This change alters the interface method of `Pipeline` from `Read() bool` to `Read(context.Context) bool`. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	6 months ago
Christian Haudum	d446d47cf8	chore(engine): Prefetch inputs of SortMerge operator (#18395 ) This PR changes how inputs of the SortMerge operator are consumed. The inputs are wrapped with a `prefetchWrapper` which consumes the next batch (`arrow.Record`) in the background while the current batch is processed by the parent node. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	6 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>	6 months ago
Ashwanth	f1d6c37342	chore(dataobjscan): correctly pass context to readers (#18386 )	6 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>	6 months ago
Robert Fratto	a0914281b8	chore(engine): change DataObjScan to only cover a single logs section (#18350 )	6 months ago
Robert Fratto	5266865fef	chore(engine): add implementation for performing topk across streams of Arrow records (#18330 ) This commit adds a `engine.topkBatch` type, which can be used by the implementation of execution nodes to perform compute the set of topk rows from a stream of records. This is needed as part of #17976, and more generally for efficiently sorting rows when a limit is also used. Implementing this required quite a few helper utilities in the new `arrowagg` package. The `arrowagg` package provides utilities for aggregating various Arrow types: * `arrowagg.Arrays` to concatenate a stream of `arrow.Array`s. * `arrayagg.Records` to concatenate a stream of `arrow.Record`s, creating a merged schema. * `arrowagg.Mapper` for quickly finding fields in incoming schemas, since arrow-go can return false when comparing two identical schemas/fields. Co-authored-by: Ashwanth <iamashwanth@gmail.com>	6 months ago
Christian Haudum	4fbe7c1a21	fix(engine): Fix bug in `SortMerge` which caused rows to be skipped due to incorrect sorting (#18334 ) This PR fixes two problems with the sorting of rows of input records: 1) When sorting input indexes (`batchIndexes []int`) based on their current timestamp at index `offset` (`timestamps []int64`), the positional correspondence was not maintained leading to pull rows from wrong records. 2) When calculating how many rows from the current batch could be yield, the comparison of the timestamp with the next highest timestamp was wrong. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	6 months ago
Ashwanth	50374f0bb1	chore(engine): column expression evaluation for ambiguous column type look-ups (#18228 )	6 months ago
Ashwanth	646ebe81d8	chore(engine): adds AST conversion and result builders for metric queries (#18166 )	6 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>	6 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>	6 months ago
Ashwanth	635896dab9	chore(engine): adds vector aggregation planning and execution nodes (#18100 )	6 months ago
Christian Haudum	3956ea1be7	chore(engine): Map line filter expressions to data object predicates (#18102 ) This PR converts line filter expressions into message predicates for the data object scan, instead of returning an error. Signed-off-by: Christian Haudum <christian.haudum@gmail.com> Co-authored-by: Ashwanth <iamashwanth@gmail.com>	7 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>	7 months ago
Ashwanth	1effa30851	chore(engine): implement range aggregation operator (#17997 )	7 months ago
Karsten Jeschkies	c2573fea5a	refactor(stringlabels): Support stringlabels in util, engine and logql. (#17998 ) This is a next step of support Prometheus `stringlabels` implementation in Loki. It adds support in the `util`, `engine` and `logql` packages. The tests should compile with build tag `stringlabels`.	7 months ago
Christian Haudum	dd68679fd7	fix(engine): Fix out-of-bounds panic in SortMerge implementation (#17967 ) If p.inputs[i].Read() returns a batch with 0 rows, getting the timestamp for the record would panic, because it would try to access the value of the timestamp column at position 0, which does not exist. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	7 months ago
Robert Fratto	36bcb5aa2d	chore(dataobj): fix regression in allocations of row readers (#17784 )	7 months ago
Robert Fratto	a237444f0d	refactor(dataobj): invert dependency between dataobj and sections (#17762 ) Originally, the dataobj package was a higher-level API around sections. This design caused it to become a bottleneck: * Implementing any new public behaviour for a section required bubbling it up to the dataobj API for it to be exposed, making it tedious to add new sections or update existing ones. * The `dataobj.Builder` pattern was focused on constructing dataobjs for storing log data, which will cause friction as we build objects around other use cases. This PR builds on top of the foundation laid out by #17704 and #17708, fully inverting the dependency between dataobj and sections: * The `dataobj` package has no knowledge of what sections exist, and can now be used for writing and reading generic sections. Section packages now create higher-level APIs around the abstractions provided by `dataobj`. * Section packages are now public, and callers interact directly with these packages for writing and reading section-specific data. * All logic for a section (encoding, decoding, buffering, reading) is now fully self-contained inside the section package. Previously, the implementation of each section was spread across three packages (`pkg/dataobj/internal/encoding`, `pkg/dataobj/internal/sections/SECTION`, `pkg/dataobj`). * Cutting a section is now a decision made by the caller rather than the section implementation. Previously, the logs section builder would create multiple sections. For the most part, this change is a no-op, with two exceptions: 1. Section cutting is now performed by the caller; however, this shouldn't result in any issues. 2. Removing the high-level `dataobj.Stream` and `dataobj.Record` types will temporarily reduce the allocation gains from #16988. I will address this after this PR is merged.	7 months ago
Owen Diehl	ccb65f9670	feat(engine, dataobj): logql bench wiring for new engine [non-fork] (#17627 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com> Co-authored-by: Christian Haudum <christian.haudum@gmail.com> Co-authored-by: Robert Fratto <robertfratto@gmail.com>	8 months ago
Christian Haudum	cbb5be6d57	feat(engine): Implements predicate mapping for DataObjScan (#17621 ) This is an initial implementation of `buildLogsPredicate(expr physical.Expression) (dataobj.LogsPredicate, error)`. While there have been discussions about bypassing this approach in favor of directly using `dataset.Reader` and `dataset.Predicate`, this PR provides essential supported functionality to unblock progress in the interim. Specifically, it handles mapping common timestamp and metadata equality predicates. Signed-off-by: Christian Haudum <christian.haudum@gmail.com> Co-authored-by: Owen Diehl <ow.diehl@gmail.com>	8 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>	8 months ago
Christian Haudum	0ea1097c8f	chore(engine): Use configured storage bucket in execution context (#17583 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	8 months ago
Christian Haudum	23c4f8d89a	chore(engine): Fix regression introduced with merging PR #17456 (#17578 ) `types.ColumnTypeMetadataKey` was renamed to `types.MetadataKeyColumnType` in https://github.com/grafana/loki/pull/17456 However, https://github.com/grafana/loki/pull/17568 was merged before that, which still used the old name. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	8 months 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>	8 months ago
Robert Fratto	4841b2abe2	chore(engine): provide basic implementation of DataObjScan (#17568 ) Co-authored-by: Ashwanth Goli <iamashwanth@gmail.com>	8 months 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>	8 months ago
Christian Haudum	208e519564	chore(engine): Add framework for function evaluation (#17374 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	8 months ago
Christian Haudum	1f8e4eebfb	chore(engine): Implement execution pipeline for SortMerge operator (#17406 ) This PR contains an implementation of the k-way merge operation without using a heap, like @rfratto described [here](https://github.com/grafana/loki/pull/17280). The SortMerge is implemented only using slices: * Maintain the following invariant: * For each input pipeline, we store the next record to process. (this already exists as `HeapSortMerge.batches`) * Additionally for each record, track the starting slice offset (which resets to zero whenever a new record is loaded in). * Iteration stops when all input pipelines have been exhausted (no change from how this is now). * To get the next record: * Iterate through each record, looking at the value from their starting slice offset. * Track the top _two_ winners (e.g., the record whose next value is the smallest and the record whose next value is the next smallest). * Find the largest offset in the starting record whose value is still less than the value of the runner-up record from the previous step. * Return the slice of that record using the two offsets, and update the stored offset of the returned record for the next call to `Read`. This approach, like the one with heap, still requires to concatenate (coalesce) the single row records - which is not implemented in this PR yet. On that note, single row records are the worst case scenario with this implementation, not necessarily the regular case. Update: After an offline discussion, @owen-d and I agreed on ignoring the worst-case scenario of single-row records for now. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	8 months ago
Owen Diehl	cf54d502fc	feat(dataobj, executor): filter node execution (#17327 ) # Add Filter Pipeline Implementation This PR implements a filter pipeline for Loki's engine executor component. The filter operator enables row-level filtering of Arrow record batches based on boolean expressions. This is a fundamental component for query execution. ## Changes - Implement `NewFilterPipeline` for evaluating filter predicates on record batches - Add `filterBatch` utility to efficiently filter Arrow records - Update `executeFilter` in the executor to use the new implementation - Add comprehensive test suite for the filter pipeline: - Basic literal predicates (true/false) - Column reference predicates - Empty batch handling - Multiple batch processing ## Implementation Notes The filter implementation follows the same pattern as the project pipeline, evaluating predicates against each record and creating a new filtered record based on the results. The implementation supports compound predicates with AND logic. This implementation provides a foundation for more advanced filtering operations as the expression evaluator is enhanced to support more complex expressions.	8 months ago
Owen Diehl	395030b130	feat(dataobj executor): project node (#17312 )	9 months ago
Owen Diehl	920e3b23ed	chore(dataobj,testing,executor): pipeline equality testing (#17311 )	9 months ago
Christian Haudum	e828c48702	chore(engine): Implement execution pipeline for the limit operator (#17264 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	9 months ago
Owen Diehl	cff0df63b3	chore(dataobj,executor): CSV arrow batches & pipeline helpers (#17290 )	9 months ago
Christian Haudum	64c477b1f7	chore(engine): Add framework for query executor (#17260 ) Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	9 months ago
Christian Haudum	525b41155d	chore(engine): Add expression evaluator to evaluate physical expressions against a given record batch (#17257 ) The evaluator takes a physcial expressions and an arrow.Record as input and return a ColumnVector. This PR only implements the evaluation of the LiteralExpr and ColumnExpr. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>	9 months ago

44 Commits (JStickler-patch-1)