91 lines
4.3 KiB
Plaintext
91 lines
4.3 KiB
Plaintext
[role="xpack"]
|
|
[[transform-overview]]
|
|
=== {transform-cap} overview
|
|
++++
|
|
<titleabbrev>Overview</titleabbrev>
|
|
++++
|
|
|
|
You can use {transforms} to _pivot_ your data into a new entity-centric index.
|
|
By transforming and summarizing your data, it becomes possible to visualize and
|
|
analyze it in alternative and interesting ways.
|
|
|
|
A lot of {es} indices are organized as a stream of events: each event is an
|
|
individual document, for example a single item purchase. {transforms-cap} enable
|
|
you to summarize this data, bringing it into an organized, more
|
|
analysis-friendly format. For example, you can summarize all the purchases of a
|
|
single customer.
|
|
|
|
{transforms-cap} enable you to define a pivot, which is a set of
|
|
features that transform the index into a different, more digestible format.
|
|
Pivoting results in a summary of your data in a new index.
|
|
|
|
To define a pivot, first you select one or more fields that you will use to
|
|
group your data. You can select categorical fields (terms) and numerical fields
|
|
for grouping. If you use numerical fields, the field values are bucketed using
|
|
an interval that you specify.
|
|
|
|
The second step is deciding how you want to aggregate the grouped data. When
|
|
using aggregations, you practically ask questions about the index. There are
|
|
different types of aggregations, each with its own purpose and output. To learn
|
|
more about the supported aggregations and group-by fields, see
|
|
<<put-transform>>.
|
|
|
|
As an optional step, you can also add a query to further limit the scope of the
|
|
aggregation.
|
|
|
|
The {transform} performs a composite aggregation that paginates through all the
|
|
data defined by the source index query. The output of the aggregation is stored
|
|
in a _destination index_. Each time the {transform} queries the source index, it
|
|
creates a _checkpoint_. You can decide whether you want the {transform} to run
|
|
once or continuously. A _batch {transform}_ is a single operation that has a
|
|
single checkpoint. _{ctransforms-cap}_ continually increment and process
|
|
checkpoints as new source data is ingested.
|
|
|
|
Imagine that you run a webshop that sells clothes. Every order creates a
|
|
document that contains a unique order ID, the name and the category of the
|
|
ordered product, its price, the ordered quantity, the exact date of the order,
|
|
and some customer information (name, gender, location, etc). Your dataset
|
|
contains all the transactions from last year.
|
|
|
|
If you want to check the sales in the different categories in your last fiscal
|
|
year, define a {transform} that groups the data by the product categories
|
|
(women's shoes, men's clothing, etc.) and the order date. Use the last year as
|
|
the interval for the order date. Then add a sum aggregation on the ordered
|
|
quantity. The result is an entity-centric index that shows the number of sold
|
|
items in every product category in the last year.
|
|
|
|
[role="screenshot"]
|
|
image::images/pivot-preview.jpg["Example of a {transform} pivot in {kib}"]
|
|
|
|
IMPORTANT: The {transform} leaves your source index intact. It
|
|
creates a new index that is dedicated to the transformed data.
|
|
|
|
|
|
[[transform-performance]]
|
|
==== Performance considerations
|
|
|
|
{transforms-cap} perform search aggregations on the source indices then index
|
|
the results into the destination index. Therefore, a {transform} never takes
|
|
less time or uses less resources than the aggregation and indexing processes.
|
|
|
|
If your {transform} must process a lot of historic data, it has high resource
|
|
usage initially--particularly during the first checkpoint.
|
|
|
|
For better performance, make sure that your search aggregations and queries are
|
|
optimized and that your {transform} is processing only necessary data. Consider
|
|
whether you can apply a source query to the {transform} to reduce the scope of
|
|
data it processes. Also consider whether the cluster has sufficient resources in
|
|
place to support both the composite aggregation search and the indexing of its
|
|
results.
|
|
|
|
If you prefer to spread out the impact on your cluster (at the cost of a slower
|
|
{transform}), you can throttle the rate at which it performs search and index
|
|
requests. Set the `docs_per_second` limit when you <<put-transform,create>> or
|
|
<<update-transform,update>> your {transform}. If you want to calculate the
|
|
current rate, use the following information from the
|
|
{ref}/get-transform-stats.html[get {transform} stats API]:
|
|
```
|
|
documents_processed / search_time_in_ms * 1000
|
|
```
|
|
|