> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder.md).

# Transformation Builder

Создавайте пользовательские преобразования IoT Query с помощью визуального редактора рабочих процессов. Настраивайте SQL-узлы, просматривайте результаты, проверяйте рабочие процессы и планируйте выполнения

{% hint style="info" %}

#### Скоро!

Конструктор преобразований в настоящее время находится в разработке. Описание функции на этой странице отражает запланированную функциональность. Детали реализации могут измениться до финального релиза. Если вас интересует ранний доступ или у вас есть вопросы, свяжитесь с <iotquery@navixy.com>.
{% endhint %}

## Что такое Конструктор преобразований

**Конструктор трансформаций** — это визуальный инструмент для проектирования рабочих процессов преобразования данных без необходимости разрабатывать и поддерживать сложные конвейеры данных. Вы выстраиваете логику обработки в виде графа, где каждый шаг представлен отдельным блоком (узлом), а инструмент компилирует ваш граф в исполняемый SQL.

Конструктор преобразований предназначен для аналитиков, специалистов по BI и всех, кто обладает базовыми знаниями SQL и хочет самостоятельно контролировать логику подготовки данных. Он помогает ответить на ключевые вопросы подготовки данных: откуда берутся данные, как они соединяются, какие фильтры и преобразования применяются, как агрегируются временные ряды и в каком виде данные должны появиться в [слой преобразования](/docs/analytics/ru/iot-query/schema-overview/transformation-layer.md).

Конструктор преобразований — это не полноценный оркестратор ETL и не платформа данных. Это специализированный конструктор рабочих процессов, который компилирует ваш граф узлов в SQL-запрос и запланированную функцию базы данных. Готовые шаблоны рабочих процессов для распространенных преобразований Navixy доступны на [Шаблоны](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md) .

## Как это работает

Рабочий процесс в Конструкторе преобразований — это ориентированный граф узлов, расположенных от источников данных к результату:

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-a74268228ff712c9e4192afa5d2ad87fb5f93d50%2FBasic-flow-example.png?alt=media" alt="workflow graph example showing sources, transformations, and output"><figcaption><p align="center"><strong>Сырые данные → узлы преобразования → результат</strong></p></figcaption></figure>

Каждый узел соответствует одному логическому шагу обработки. Вы можете объединять несколько источников в один узел преобразования, а результат одного узла может подаваться на вход нескольким последующим узлам. Граф дает вам наглядное представление всего пути данных от исходных таблиц до целевой аналитической сущности.

Конструктор компилирует ваш граф в один SQL-запрос с использованием общих табличных выражений (CTE). Каждый узел становится CTE в итоговом запросе. Такой подход компиляции означает, что Конструктор не записывает данные в базу данных напрямую. Вместо этого он генерирует конфигурацию, которая выполняет фактическую обработку данных по расписанию.

{% hint style="warning" %}
Данные в графе должны течь только в одном направлении. Циклы не допускаются. Если Конструктор обнаруживает цикл, он возвращает ошибку проверки.
{% endhint %}

### Подключение к базе данных

Прежде чем начать создавать рабочий процесс, вам нужно подключиться к вашей базе данных PostgreSQL. Без активного подключения предпросмотр данных и обнаружение таблиц недоступны.

Панель подключения позволяет указать ваш [URL подключения](/docs/analytics/ru/iot-query/connection-setup.md#connection-string-format), подключаться и отключаться, а также видеть количество таблиц, найденных в каждой категории. Конструктор использует две схемы в вашей базе данных:

* `raw_telematics_data` для телематических данных и данных датчиков устройств
* `raw_business_data` для справочных бизнес-данных (транспорт, сотрудники, геозоны и подобные сущности)

После подключения Конструктор автоматически обнаруживает доступные таблицы и столбцы, которые затем можно выбрать при настройке узлов источников данных.

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-d059f27250d15460203d3ffe972d7e4be190f9d9%2FConnection-url.png?alt=media" alt="connection panel showing URL input and discovered table counts"><figcaption></figcaption></figure>

### Узлы источников данных

Узлы источников данных определяют, откуда рабочий процесс читает данные. Каждый исходный узел соответствует одной таблице в слое Сырые данные.

<details>

<summary>Сырые данные: телематика</summary>

Этот узел загружает данные временных рядов из `raw_telematics_data` схемы.

| Параметр                   | Описание                                                                                                                      |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| **Имя таблицы**            | Выберите из списка таблиц, обнаруженных при подключении к базе данных.                                                        |
| **Столбец времени**        | Столбец с меткой времени, используемый для сортировки и фильтров по времени. По умолчанию `device_time`.                      |
| **Столбцы**                | Список определенных столбцов для включения или `*` для выбора всех столбцов.                                                  |
| **Условие фильтрации**     | Необязательный SQL `WHERE` условие, применяемое непосредственно к исходному запросу.                                          |
| **Минуты временного окна** | Необязательный временной лимит (в минутах) для ограничения временного окна в SQL. Оставьте пустым, если ограничение не нужно. |

Каждый узел Сырые данные: телематика читает данные ровно из одной таблицы. Чтобы использовать данные из нескольких таблиц, добавьте отдельный узел для каждой таблицы.

</details>

<details>

<summary>Сырые данные: бизнес</summary>

Этот Узел загружает справочные данные из `raw_business_data` схемы. Типичные таблицы включают `объекты`, `Транспорт`, `устройства`, и `sensor_description`.

| Параметр             | Описание                                                                     |
| -------------------- | ---------------------------------------------------------------------------- |
| **Имя таблицы**      | Выберите из списка обнаруженных бизнес-таблиц.                               |
| **Ключевой столбец** | Ключевой столбец для этой таблицы (например, `object_id` или `sensor_id`).   |
| **Столбцы**          | Список определенных столбцов для включения или `*` для выбора всех столбцов. |

Сырые данные: узлы бизнеса в основном используются как второй вход для узла SQL Transform, позволяя вам соединять справочные данные с временными рядами телематики.

</details>

### Узлы преобразования

Узлы преобразования определяют, что происходит с вашими данными после их загрузки из источников. Каждый тип преобразования обрабатывает определенный шаблон обработки.

<details>

<summary>SQL-преобразование</summary>

Объединяет данные ровно из двух исходных узлов с помощью SQL `JOIN` операция.

| Параметр               | Описание                                                                                                                                    |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Тип соединения**     | Тип соединения: `INNER`, `LEFT`, `RIGHT`, или `FULL` (full outer join).                                                                     |
| **Условие соединения** | Условие для сопоставления строк между двумя входами (например, сопоставление по `device_id`).                                               |
| **Выберите столбцы**   | Список столбцов для включения в вывод. Поддерживает префиксную нотацию, например `source.*` чтобы выбрать все столбцы из конкретного входа. |

SQL Transform требует ровно два входа. Входы могут быть любой комбинацией узлов Источник данных или выходов других узлов преобразования.

</details>

<details>

<summary>Фильтр</summary>

Фильтрует данные по временному диапазону и пользовательским условиям. Все условия выполняются в базе данных в рамках `WHERE` предложения (pushdown filtering).

| Параметр                                | Описание                                                                                                           |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| **Столбец времени**                     | Столбец timestamp, который будет использоваться для фильтрации по времени. По умолчанию: `device_time`.            |
| **Начало / конец временного диапазона** | Начальная и конечная границы временного фильтра.                                                                   |
| **Динамические условия**                | Список SQL-условий, объединенных с `AND`. Используйте их для дополнительной фильтрации сверх временного диапазона. |

</details>

<details>

<summary>Ресемплинг</summary>

Агрегирует данные временных рядов в фиксированные временные интервалы. Это полезно для преобразования высокочастотных данных в сводную статистику за регулярные периоды.

| Параметр            | Описание                                                                                                                                                                   |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Столбец времени** | Столбец timestamp, который следует использовать для группировки по интервалам. По умолчанию `device_time`.                                                                 |
| **Интервал**        | Интервал агрегации: `1 мин`, `5 мин`, `15 мин`, `1 час`, или `1 день`.                                                                                                     |
| **Группа по**       | Дополнительные столбцы для Группа по (кроме временного интервала).                                                                                                         |
| **Агрегации**       | Список пар столбец-метод, определяющих, как агрегируется каждый столбец. Доступные методы: `среднее`, `сумма`, `минимум`, `максимум`, `первый`, `последний`, `количество`. |

</details>

<details>

<summary>Арифметика</summary>

Добавляет или заменяет столбцы с помощью SQL-выражений. Используйте этот узел для создания вычисляемых столбцов на основе существующих данных.

| Параметр      | Описание                                                                                                                               |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **Выражения** | Список определений выражений. Каждая запись включает необязательный исходный столбец, SQL-выражение и обязательный выходной псевдоним. |

Например, чтобы преобразовать значение скорости, вы можете задать исходный столбец как `speed`, выражение как `speed * 1.2`, а псевдоним как `speed_adjusted`. Псевдоним обязателен для каждого выражения.

</details>

<details>

<summary>Пользовательский SQL</summary>

Предоставляет свободный ввод SQL для сложной логики, которую не могут выразить другие типы Узел. Используйте это, когда вам нужен полный контроль над запросом.

| Параметр                 | Описание                                                                      |
| ------------------------ | ----------------------------------------------------------------------------- |
| **Пользовательский SQL** | A `SELECT` запрос, в котором вышестоящие узлы доступны по их псевдонимам CTE. |

Псевдонимы исходного Узел следуют шаблону `a_<node_id>` (например, `a_узел_1`, `a_filter_1`). Идентификаторы Узел приводятся к допустимым SQL-идентификаторам, а пробелы и специальные символы заменяются на подчеркивания.

Пользовательские узлы SQL принимают один или два входа. Ваш запрос может обращаться к соответствующим CTE по их псевдонимам.

</details>

### Конфигурация вывода

<details>

<summary>Вывод</summary>

Этот **Вывод** Узел определяет, как результаты преобразования должны быть записаны в слой Transformation. Он задает метаданные целевой таблицы, которые внешний runtime использует для хранения обработанных данных.

| Параметр            | Описание                                                                                                                                                                                 |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Имя таблицы**     | Имя целевой таблицы в `processed_custom_data` схемы.                                                                                                                                     |
| **Столбец времени** | Столбец временной метки в выходных данных (например, `device_time`).                                                                                                                     |
| **Разбиение по**    | Выражение разбиения для организации хранимых данных (например, `DATE(device_time)`).                                                                                                     |
| **Первичный ключ**  | Список столбцов, которые однозначно идентифицируют каждую строку (например, `[device_id, device_time]`).                                                                                 |
| **Режим записи**    | Как данные записываются в целевую таблицу: `append` (добавляет новые строки), `overwrite` (заменяет существующие данные), или `upsert` (обновляет существующие строки, вставляет новые). |

</details>

## Создание рабочего процесса

Типичный рабочий процесс состоит из следующих шагов:

{% stepper %}
{% step %}
**Откройте конструктор преобразований**

Запустите интерфейс конструктора преобразований.
{% endstep %}

{% step %}
**Подключитесь к своей базе данных**

Введите URL подключения PostgreSQL и установите соединение. Конструктор автоматически обнаружит доступные таблицы и столбцы.
{% endstep %}

{% step %}
**Добавьте узлы источников данных**

Добавьте [**Сырые данные: телематика**](#raw-data-telematics) узел и выберите таблицу и столбцы, с которыми хотите работать. Если вам нужны справочные данные (например, сведения о транспортном средстве или описания датчиков), добавьте еще один [**Сырые данные: бизнес**](#raw-data-business) узел.
{% endstep %}

{% step %}
**Добавьте узлы преобразования**

Добавьте узлы преобразования, необходимые вашему рабочему процессу:

* [**SQL-преобразование**](#sql-transform) для объединения данных
* [**Фильтр**](#filter) для сужения результатов
* [**Ресемплинг**](#resampling) для агрегирования временных рядов
* [**Арифметика**](#arithmetic) для добавления вычисляемых столбцов
* [**Пользовательский SQL**](#custom-sql) для сложной логики.
  {% endstep %}

{% step %}
**Настройте выходной узел**

Добавьте [Вывод](#output) узел и задайте имя целевой таблицы, столбцы первичного ключа и режим записи для вашей аналитической сущности.
{% endstep %}

{% step %}
**Соедините узлы**

Нарисуйте связи между узлами, чтобы определить поток данных. Соедините исходные узлы с узлами преобразования, а узлы преобразования — с выходным узлом. Данные текут слева направо, от источников к выходу.
{% endstep %}

{% step %}
**Проверьте и исправьте ошибки**

Проверьте подсказки валидации на наличие проблем с настройкой. Исправьте ошибки в параметрах узла или структуре графа по мере необходимости.
{% endstep %}

{% step %}
**Предварительный просмотр результатов**

Нажмите **Выполнить** чтобы выполнить предварительный просмотр вашего рабочего процесса. Конструктор преобразует граф в SQL и выполняет его в вашей базе данных, возвращая до 100 строк, чтобы вы могли проверить результат.

{% hint style="info" %}
**Экспорт**

Вы можете экспортировать завершенный рабочий процесс как YAML-файл для выполнения во время работы или для совместного использования с коллегами. См. [Справочник по YAML рабочего процесса](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/workflow-yaml-reference.md) для получения сведений о формате.
{% endhint %}
{% endstep %}

{% step %}

#### Планирование выполнения

Нажмите **Запланировать** чтобы открыть диалог настройки, где вы можете определить точное время и частоту выполнения рабочего процесса. В заданное время функция в базе данных запустит рабочий процесс и сохранит его результат в слой преобразования.
{% endstep %}
{% endstepper %}

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-284bc5a571d1f159214d822c840d6be699ccac98%2FComplete-flow-example.png?alt=media" alt="completed workflow graph with all node types connected"><figcaption><p>Пример полного потока преобразований</p></figcaption></figure>

### Предварительный просмотр результатов

После того как вы нажмете **Выполнить** в панели инструментов, конструктор преобразует граф вашего рабочего процесса в один SQL-запрос с CTEs и выполнит его в подключенной базе данных PostgreSQL. Результаты отображаются в нижней панели.

**При успешном выполнении**, панель отображает:

* Таблица результатов, отображающая до 100 строк выходных данных
* Выполненный SQL-запрос (полный CTE-запрос, сгенерированный компилятором)
* Количество строк, количество столбцов и время выполнения
* Возможность экспортировать результат в CSV

**При ошибке выполнения**, панель отображает:

* Сообщение об ошибке, описывающее, что пошло не так
* Выполненный SQL-запрос (если компиляция прошла успешно)
* Подробности ошибки базы данных (если ошибка произошла во время выполнения запроса)

{% hint style="warning" %}
Предварительный просмотр результатов требует активного подключения PostgreSQL. Без подключения предварительный просмотр возвращает пустой результат без выполнения SQL. Предварительный просмотр всегда использует реальные данные из вашей базы данных, а не фиктивные данные.
{% endhint %}

<figure><img src="https://1999959041-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoFNFEIINiGFbhi3Px3dE%2Fuploads%2Fgit-blob-d16d21dd58df9cea2fe996abeb4873df4e438da9%2FExecuted-flow-result.png?alt=media" alt="Results preview panel showing successful execution with result table and SQL"><figcaption><p>Результат выполненного потока</p></figcaption></figure>

## Проверка и компиляция

Builder проверяет ваш рабочий процесс на двух уровнях.

1. **Проверка графа** проверяет общую структуру вашего рабочего процесса. Граф должен быть корректным направленным ациклическим графом (DAG), то есть данные должны двигаться в одном направлении без циклов. Если Builder обнаруживает цикл, он возвращает ошибку и выделяет затронутые узлы.
2. **Проверка узла** проверяет конфигурацию каждого узла отдельно. Builder проверяет, что обязательные поля заполнены, что указанные столбцы существуют в выходных данных вышестоящего узла и что параметры узла согласуются с его типом (например, SQL Transform должен иметь ровно два входа).

Во время компиляции Builder преобразует ваш граф в один SQL-запрос. Каждый узел становится CTE с псевдонимом `a_<node_id>`. Узлы упорядочиваются в топологическом порядке, чтобы каждый CTE мог ссылаться на выходные данные своих предыдущих узлов. Если компиляция завершается сбоем из-за ошибки конфигурации или неверной структуры графа, Builder возвращает сведения об ошибке вместе с любым частичным SQL, который ему удалось сгенерировать.

## Экспорт

### Экспорт и импорт YAML

Вы можете экспортировать готовый рабочий процесс в виде файла YAML с помощью **Экспорт** кнопки на панели инструментов. Экспортированный файл содержит полное описание рабочего процесса в формате версии 2, включая все конфигурации узлов, ребра графа и позиции макета.

Чтобы загрузить ранее сохраненный рабочий процесс, используйте **Import** функцию и выберите `.yaml` или `.yml` файл. Для полной документации по формату см. [Справочник по YAML рабочего процесса](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/workflow-yaml-reference.md).

## Текущие ограничения

Transformation Builder сейчас находится в начальной версии, и к нему применяются несколько ограничений:

* **Предварительный просмотр требует активного подключения PostgreSQL.** Без подключения вы не можете просмотреть результаты. Предварительный просмотр ограничен 100 строками.
* **Граф должен быть ацикличным.** Данные движутся только в одном направлении, от источников к результату.
* **Встроенного механизма выполнения нет.** Builder генерирует конфигурацию и SQL для внешнего выполнения в среде исполнения. Он сам не обрабатывает и не хранит данные.
* **Только пакетная обработка.** Обработка потоковых данных не поддерживается.

## Следующие шаги

* [**Шаблоны**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/templates.md): Готовые конфигурации рабочих процессов, которые вы можете импортировать и адаптировать в Transformation Builder.
* [**слой преобразования**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer.md): Узнайте, как слой трансформации организует обработанные данные в схемы и как запрашивать их.
* [**Справочник по YAML рабочего процесса**](/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder/workflow-yaml-reference.md): Ознакомьтесь с полными Характеристиками формата экспорта и импорта YAML.
* [**Слой сырых данных**](/docs/analytics/ru/iot-query/schema-overview/bronze-layer.md): Изучите исходные схемы (`raw_telematics_data` и `raw_business_data`) которые предоставляют входные данные для ваших рабочих процессов.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://navixy.com/docs/analytics/ru/iot-query/schema-overview/transformation-layer/transformation-builder.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
