Yuriy Gavrilov: posts tagged SQL

Trino + OTP верификация запросов в bi – параноя.mode = true

Fri, 11 Sep 2026 01:17:04 +0300

Представьте: дашборд в BI видят все сотрудники. Закрыть его нельзя — так исторически сложилось. Но данные нужно скрыть. Решение — динамическая фильтрация на уровне SQL: пользователь вводит логин и одноразовый код (TOTP), а запрос показывает только те строки, которые ему разрешены.

Это не полноценная система безопасности, но это работающий барьер, который можно внедрить без изменения BI-системы. В статье — пошаговая инструкция: от демо-таблиц до настройки прав в Trino, генерации QR-кодов и увеличения окна действия OTP.

Архитектура

`catalog.schema.dashboard_users` — справочник сотрудников: логин, имя, отдел, должность, руководитель, TOTP-секрет, флаг активности.
`catalog.schema.dashboard_data` — данные дашборда. У каждой строки есть политика доступа: `ALL`, `OWNER`, `DEPARTMENT`, `MANAGER`, `DIRECTOR`.
Функция `verify_totp` — Python UDF, проверяет OTP-код по секрету и текущему времени.
Итоговый запрос — аутентифицирует пользователя и фильтрует строки по атрибутам.

Пользователь вводит логин и OTP как параметры BI. Если они верны — получает свои данные. Если нет — пустой результат.

Шаг 1. Демо-таблицы

Создадим две таблицы в вымышленной схеме `catalog.schema`.

CREATE TABLE catalog.schema.dashboard_users (
    login         VARCHAR,
    employee_name VARCHAR,
    department    VARCHAR,
    position_name VARCHAR,
    manager_login VARCHAR,
    totp_secret   VARCHAR,
    is_active     BOOLEAN
);

INSERT INTO catalog.schema.dashboard_users VALUES
    ('vasya', 'Василий', 'sales',    'manager',  'ivan',  'JBSWY3DPEHPK3PXP', true),
    ('petya', 'Пётр',    'sales',    'analyst',  'vasya', 'KRSXG5CTMVRXEZLU', true),
    ('masha', 'Мария',   'finance',  'analyst',  'ivan',  'NB2W45DFOIZA',     true),
    ('ivan',  'Иван',    'management','director', null,   'MFRGGZDFMZTWQ2LK', true);

CREATE TABLE catalog.schema.dashboard_data (
    row_id        BIGINT,
    row_title     VARCHAR,
    amount        DECIMAL(12,2),
    owner_login   VARCHAR,
    department    VARCHAR,
    manager_login VARCHAR,
    access_policy VARCHAR
);

INSERT INTO catalog.schema.dashboard_data VALUES
    (1, 'Личная строка Васи',       1000.00, 'vasya', 'sales',   'ivan',  'OWNER'),
    (2, 'Личная строка Пети',       2000.00, 'petya', 'sales',   'vasya', 'OWNER'),
    (3, 'Общая строка отдела Sales',3000.00, null,    'sales',   null,    'DEPARTMENT'),
    (4, 'Общая строка Finance',     4000.00, null,    'finance', null,    'DEPARTMENT'),
    (5, 'Строка команды Васи',      5000.00, 'petya', 'sales',   'vasya', 'MANAGER'),
    (6, 'Строка команды Ивана',     6000.00, 'masha', 'finance', 'ivan',  'MANAGER'),
    (7, 'Директорская строка',      7000.00, null,    null,      null,    'DIRECTOR'),
    (8, 'Публичная строка',         8000.00, null,    null,      null,    'ALL');

Либо можно сгенерировать коды разово прямо в запросе.

Шаг 1.1. Массовая генерация TOTP-секретов и QR-кодов

Когда пользователей много, вручную придумывать Base32-секреты неудобно. Можно сгенерировать их прямо в Trino при вставке в таблицу `dashboard_users`. Ниже — готовый блок для демо и тестов.

Важно: `random()` в Trino не является криптостойким генератором. Для продакшена секреты лучше генерировать вне Trino (например, через `openssl rand -base64 20` или Python `pyotp.random_base32()`) и вставлять уже готовыми. Для демонстрации и параноидального режима «лишь бы закрыть дашборд» этого достаточно.

Вставка пользователей с автоматической генерацией секретов

INSERT INTO catalog.schema.dashboard_users (
    login,
    employee_name,
    department,
    position_name,
    manager_login,
    totp_secret,
    is_active
)
SELECT
    login,
    employee_name,
    department,
    position_name,
    manager_login,

    -- Генерация Base32-секрета длиной 16 символов (80 бит)
    array_join(
        transform(
            sequence(1, 16),
            i -> substr(
                'ABCDEFGHIJKLMNOPQRSTUVWXYZ234567',
                CAST(floor(random() * 32) + 1 AS INTEGER),
                1
            )
        ),
        ''
    ) AS totp_secret,

    true AS is_active
FROM (
    VALUES
        ('vasya', 'Василий', 'sales',     'manager',  'ivan'),
        ('petya', 'Пётр',    'sales',     'analyst',  'vasya'),
        ('masha', 'Мария',   'finance',   'analyst',  'ivan'),
        ('ivan',  'Иван',    'management','director', CAST(NULL AS VARCHAR))
) AS src (
    login,
    employee_name,
    department,
    position_name,
    manager_login
);

Как получить строку для QR-кода

После вставки можно сразу сформировать URI формата `otpauth://`, который останется только превратить в QR-код любым генератором:

SELECT
    login,
    totp_secret,
    'otpauth://totp/DemoBI:' || login
        || '?secret=' || totp_secret
        || '&issuer=DemoBI' AS otpauth_uri
FROM catalog.schema.dashboard_users;

Пример результата:

login	totp_secret	otpauth_uri
vasya	JBSWY3DPEHPK3PXP	otpauth://totp/DemoBI:vasya?secret=JBSWY3DPEHPK3PXP&issuer=DemoBI
petya	KRSXG5CTMVRXEZLU	otpauth://totp/DemoBI:petya?secret=KRSXG5CTMVRXEZLU&issuer=DemoBI

Эту строку можно вставить в любой генератор QR-кодов (онлайн или офлайн), а затем отсканировать приложением:

Google Authenticator,
Yandex ID,
KeePass (с плагином TOTP),
и любым другим менеджером паролей, поддерживающим TOTP.

Настройка длины секрета

`sequence(1, 16)` — 16 символов Base32 = 80 бит. Этого достаточно для большинства случаев и именно такую длину часто используют по умолчанию.
Если хотите более длинный секрет, замените `16` на `32`. Тогда получится 160 бит.
Алфавит `’ABCDEFGHIJKLMNOPQRSTUVWXYZ234567’` — это стандартный Base32-алфавит (без цифр 0, 1, 8, 9). Менять его не нужно.

Если нужен детерминированный секрет (не рекомендуется)

Иногда для тестов хотят, чтобы секрет зависел от логина. Можно использовать хеш:

substr(
    upper(to_base32(from_utf8(login || 'some_salt'))),
    1, 16
) AS totp_secret

Но это небезопасно: зная логин и соль, можно вычислить секрет. Для реальной эксплуатации используйте случайную генерацию вне Trino.

Шаг 2. Inline-функция для тестов в DBeaver

В DBeaver можно использовать `WITH FUNCTION` — Python-код прямо в запросе. Это удобно для отладки, но не работает в BI, потому что BI схлопывает запрос в одну строку и ломает форматирование Python.

WITH FUNCTION verify_totp(secret VARCHAR, code VARCHAR, time_step BIGINT)
RETURNS BOOLEAN
LANGUAGE PYTHON
WITH (handler = 'verify_handler')
AS $$
import hmac, hashlib, struct, base64

def verify_handler(secret_b32, code, time_step):
    if secret_b32 is None or code is None or time_step is None:
        return False

    code = str(code).strip()
    if not code.isdigit() or len(code) != 6:
        return False

    secret = str(secret_b32).strip().replace(" ", "").upper()
    padding = "=" * ((8 - len(secret) % 8) % 8)

    try:
        key = base64.b32decode(secret + padding, casefold=True)
    except Exception:
        return False

    current = int(time_step // 30)   # 30 секунд — стандарт TOTP
    for offset in (-1, 0, 1):
        counter = current + offset
        msg = struct.pack(">Q", counter)
        digest = hmac.new(key, msg, hashlib.sha1).digest()
        o = digest[19] & 15
        expected = (struct.unpack(">I", digest[o:o+4])[0] & 0x7fffffff) % 1000000
        expected_code = f"{expected:06d}"
        if hmac.compare_digest(expected_code, code):
            return True
    return False
$$
SELECT verify_totp('JBSWY3DPEHPK3PXP', '123456', CAST(to_unixtime(now()) AS BIGINT));

Важно: тело функции должно начинаться с новой строки после `$$`. Если BI отправляет всё в одну строку — будет ошибка `Function definition must start with a newline after opening quotes`.

Шаг 3. Регистрация функции администратором

Чтобы BI-запросы не содержали Python-код, функцию нужно создать один раз на стороне Trino. Это делает администратор или пользователь с правами на создание функций.

Сразу еще скажу, что регистрация не во всех каталогах работает, в iceberg например не работает, а вот в iceberg + rest надо проверять. Такая фича давно в плане, но не уверен готова ли. Можно регать функции в каталоге memory конектора, но это придется делать каждую загрузку.

DROP FUNCTION IF EXISTS catalog.schema.verify_totp(VARCHAR, VARCHAR, BIGINT);

CREATE FUNCTION catalog.schema.verify_totp(
    secret VARCHAR,
    code VARCHAR,
    time_step BIGINT
)
RETURNS BOOLEAN
LANGUAGE PYTHON
WITH (handler = 'verify_handler')
AS $$
import hmac, hashlib, struct, base64

def verify_handler(secret_b32, code, time_step):
    if secret_b32 is None or code is None or time_step is None:
        return False

    code = str(code).strip()
    if not code.isdigit() or len(code) != 6:
        return False

    secret = str(secret_b32).strip().replace(" ", "").upper()
    padding = "=" * ((8 - len(secret) % 8) % 8)

    try:
        key = base64.b32decode(secret + padding, casefold=True)
    except Exception:
        return False

    current = int(time_step // 30)
    for offset in (-1, 0, 1):
        counter = current + offset
        msg = struct.pack(">Q", counter)
        digest = hmac.new(key, msg, hashlib.sha1).digest()
        o = digest[19] & 15
        expected = (struct.unpack(">I", digest[o:o+4])[0] & 0x7fffffff) % 1000000
        expected_code = f"{expected:06d}"
        if hmac.compare_digest(expected_code, code):
            return True
    return False
$$;

Проверка:

SELECT catalog.schema.verify_totp(
    'JBSWY3DPEHPK3PXP',
    '465617',
    CAST(to_unixtime(now()) AS BIGINT)
) AS is_valid;

Примечание: в вашей среде создание функции может быть не разрешено без настройки прав. Об этом — следующий шаг.

Шаг 4. Настройка прав доступа

Нужно разрешить группе admins создавать функции в схеме `catalog.schema`, а группе bi_users — только вызывать `verify_totp`. В Trino это делается через system access control.

Вариант A. File-based ACL

Файл `/etc/trino/access-control.properties`:

access-control.name=file
security.config-file=/etc/trino/rules/access-control.json
security.refresh-period=1m

Файл `access-control.json`:

{
  "catalogs": [
    {
      "group": "admins",
      "catalog": "catalog",
      "allow": "all"
    },
    {
      "group": "bi_users",
      "catalog": "catalog",
      "allow": "read-only"
    }
  ],
  "schemas": [
    {
      "group": "admins",
      "catalog": "catalog",
      "schema": "schema",
      "owner": true
    },
    {
      "group": "bi_users",
      "catalog": "catalog",
      "schema": "schema",
      "owner": false
    }
  ],
  "functions": [
    {
      "group": "admins",
      "catalog": "catalog",
      "schema": "schema",
      "function": ".*",
      "privileges": ["EXECUTE", "GRANT_EXECUTE", "OWNERSHIP"]
    },
    {
      "group": "bi_users",
      "catalog": "catalog",
      "schema": "schema",
      "function": "verify_totp",
      "privileges": ["EXECUTE"]
    }
  ]
}

Вариант B. OPA (Rego)

Если Trino использует OPA, политика может выглядеть так:

package trino

default allow := false

is_admin {
    input.context.identity.groups[_] == "admins"
}

is_bi_user {
    input.context.identity.groups[_] == "bi_users"
}

is_target_schema {
    input.action.resource.catalog.name == "catalog"
    input.action.resource.schema.name == "schema"
}

is_verify_totp {
    input.action.resource.catalog.name == "catalog"
    input.action.resource.schema.name == "schema"
    input.action.resource.function.name == "verify_totp"
}

allow {
    is_admin
    is_target_schema
    input.action.operation == "CreateFunction"
}

allow {
    is_admin
    is_target_schema
    input.action.operation == "DropFunction"
}

allow {
    is_admin
    is_target_schema
    input.action.operation == "ExecuteFunction"
}

allow {
    is_bi_user
    is_verify_totp
    input.action.operation == "ExecuteFunction"
}

Точные названия операций (`CreateFunction`, `ExecuteFunction`) лучше уточнить в логах OPA при тестовом запросе.

Шаг 5. Запрос для BI (без Python)

После регистрации функции BI-запрос становится обычным SQL. Пользователь вводит `:login` и `:otp` как параметры.

WITH auth_user AS (
    SELECT
        login,
        employee_name,
        department,
        position_name,
        manager_login
    FROM catalog.schema.dashboard_users
    WHERE login = lower(trim(':login'))
      AND is_active = true
      AND catalog.schema.verify_totp(
            totp_secret,
            trim(':otp'),
            CAST(to_unixtime(now()) AS BIGINT)
          )
    LIMIT 1
)
SELECT
    d.row_id,
    d.row_title,
    d.amount,
    d.owner_login,
    d.department,
    d.manager_login,
    d.access_policy,
    a.login AS current_login,
    a.employee_name AS current_employee_name,
    a.department AS current_department,
    a.position_name AS current_position_name,
    CASE
        WHEN d.access_policy = 'ALL' THEN 'Видно всем авторизованным'
        WHEN d.access_policy = 'OWNER' AND d.owner_login = a.login THEN 'Видно владельцу строки'
        WHEN d.access_policy = 'DEPARTMENT' AND d.department = a.department THEN 'Видно сотруднику отдела'
        WHEN d.access_policy = 'MANAGER' AND d.manager_login = a.login THEN 'Видно руководителю'
        WHEN d.access_policy = 'DIRECTOR' AND a.position_name = 'director' THEN 'Видно директору'
        ELSE null
    END AS access_reason
FROM catalog.schema.dashboard_data d
CROSS JOIN auth_user a
WHERE
       d.access_policy = 'ALL'
    OR (d.access_policy = 'OWNER' AND d.owner_login = a.login)
    OR (d.access_policy = 'DEPARTMENT' AND d.department = a.department)
    OR (d.access_policy = 'MANAGER' AND d.manager_login = a.login)
    OR (d.access_policy = 'DIRECTOR' AND a.position_name = 'director');

Важно про параметры: если BI подставляет их как сырой текст, нужны кавычки: `’:login’`, `’:otp’`. Если BI использует bind-параметры — кавычки не нужны: `:login`, `:otp`. В предыдущих ошибках (`Column ‘jbswy3dpehpk3pxp’ cannot be resolved`) видно, что в вашем случае нужны именно кавычки.

Шаг 6. Логика доступа

`auth_user` — возвращает 0 строк, если логин не найден, пользователь неактивен или OTP неверный.
`CROSS JOIN auth_user` — если `auth_user` пуст, результат всего запроса пуст.
`WHERE` с `OR` — оставляет только те строки, которые разрешены политикой:
- `ALL` — всем авторизованным;
- `OWNER` — владельцу (`owner_login = a.login`);
- `DEPARTMENT` — сотруднику того же отдела;
- `MANAGER` — руководителю (`manager_login = a.login`);
- `DIRECTOR` — директору (`position_name = ‘director’`).

Пример: `vasya` увидит свои строки, строки отдела `sales`, строки, где он руководитель, и публичные. `petya` — только свои, отдел `sales` и публичные.

Шаг 7. Генерация QR-кода для OTP

Каждому пользователю нужно выдать TOTP-секрет и удобно передать его в приложение-аутентификатор. Стандартный способ — использовать URI формата `otpauth://`.

Пример для пользователя `vasya`:

otpauth://totp/DemoBI:vasya?secret=JBSWY3DPEHPK3PXP&issuer=DemoBI

Здесь:

`DemoBI:vasya` — метка, которая отобразится в приложении. Можно заменить на название отчёта, отдела или что угодно, например `SalesDashboard:vasya`.
`secret=JBSWY3DPEHPK3PXP` — Base32-секрет.
`issuer=DemoBI` — имя издателя, обычно название компании или системы.

Эту строку можно вставить в любой генератор QR-кодов (онлайн или офлайн). После генерации QR-код сканируется приложением:

Google Authenticator,
Yandex ID,
KeePass (с плагином TOTP),
и любым другим менеджером паролей, поддерживающим TOTP.

Это стандарт, поэтому совместимость широкая. QR-код можно распечатать или отправить пользователю.

Совет: если у вас много пользователей, сгенерируйте QR-коды автоматически из таблицы `dashboard_users`, подставляя логин и секрет.

Шаг 8. Увеличение окна действия OTP (2–5 минут)

По умолчанию TOTP-код действует 30 секунд. Это может быть неудобно: пользователь не успевает ввести код. Можно увеличить окно действия, изменив функцию.

В Python-коде есть строка:

current = int(time_step // 30)

Здесь `30` — это количество секунд в одном временном шаге. Если заменить `30` на `300`, то код будет действителен 5 минут (300 секунд). При этом приложение-аутентификатор продолжит генерировать коды каждые 30 секунд, но сервер будет принимать любой код, сгенерированный в течение этих 5 минут. Это удобно и безопасно: окно не бесконечное, но достаточное, чтобы успеть ввести код.

Пример изменённой функции:

current = int(time_step // 300)   # 5 минут
for offset in (-1, 0, 1):
    ...

Если оставить смещения `-1, 0, 1`, то общее окно станет 15 минут (5 минут назад, текущие 5 минут, 5 минут вперёд). Это может быть избыточно. Лучше убрать смещения и проверять только текущий интервал:

current = int(time_step // 300)
counter = current
msg = struct.pack(">Q", counter)
...
# без цикла for

Тогда код будет действителен ровно 5 минут.

Если хотите 2 минуты — используйте `120` вместо `300`.

Важно: после изменения функции её нужно пересоздать ( `DROP FUNCTION` и `CREATE FUNCTION` ). Все пользователи автоматически начнут работать с новым окном.

Шаг 9. Безопасность

Секреты TOTP нельзя хранить в открытой схеме. Лучше вынести `dashboard_users` в закрытую схему, например `security.users`.
BI-пользователи не должны иметь прямой доступ к таблице с секретами. Только к функции и к данным.
OTP-код попадает в логи Trino и BI. Логи могут быть доступны администраторам или храниться в системе. Это не смертельно, потому что код короткоживущий, но помните: любой, кто видит лог, может увидеть введённый OTP. Если окно действия увеличено до 5 минут, риск возрастает. По возможности используйте реального пользователя из аутентификации BI, а не ручной ввод логина.
Права на создание функций — только у группы `admins`. BI-пользователям — только `EXECUTE` на конкретную функцию.

Заключение

Мы построили параноидальный, но рабочий механизм: OTP-аутентификация + динамическая фильтрация строк на уровне SQL. Это не заменяет полноценный RBAC, но позволяет быстро закрыть дашборд от посторонних глаз без изменения BI-системы.

Что проверено: inline-функция в DBeaver, запрос с фильтрацией, логика доступа.
Что требует настройки: регистрация функции и права в Trino. После настройки прав (шаг 4) функция создаётся один раз, а BI-запросы становятся чистыми и безопасными.

Удачи в паранойе! :)

StarRocks: Архитектура, Практика и место в современном Data Stack

Sun, 15 Mar 2026 19:06:01 +0300

StarRocks — это аналитическая MPP-база данных нового поколения.
Если коротко, она пытается решить трилемму аналитики: объединить скорость ClickHouse (за счет векторизации и C++), гибкость Trino (поддержка сложных JOIN-ов) и простоту использования MySQL (совместимый протокол).

Это короткое руководство проведет вас от понимания архитектуры до построения простого конвейера загрузки данных (ETL) в домашнем продакшене.

Часть 1. Архитектура: FE и BE

В отличие от PostgreSQL (монолит) или ClickHouse (где узлы часто одноранговые), StarRocks имеет четкое разделение ролей. Это критически важно для понимания масштабирования и эксплуатации.

1. FE (Frontend) — “Мозг”

Написан на Java.

Роль: Управляющий слой.
Функции:
- Принимает подключения клиентов (по протоколу MySQL).
- Хранит метаданные (схемы таблиц, права доступа).
- Парсит SQL и строит план выполнения запроса (Query Plan).
- Управляет транзакциями загрузки данных.
Масштабирование: Обычно запускают 1 или 3 узла для обеспечения высокой доступности (HA).
Важно: Клиенты (DBeaver, BI, сurl) подключаются только к FE.

2. BE (Backend) — “Мускулы”

Написан на C++ (использует SIMD-инструкции процессора).

Роль: Слой хранения и вычислений.
Функции:
- Физически хранит данные (в колоночном формате).
- Выполняет “тяжелую” работу: фильтрацию, агрегацию, JOIN-ы.
- Управляет репликацией данных.
Масштабирование: Можно добавлять узлы линейно. Чем больше BE, тем быстрее выполняются запросы и тем больше данных можно хранить.

В Docker All-in-One: Оба компонента упакованы в один контейнер для удобства, но слушают разные порты:

`9030`: FE (SQL интерфейс, сюда идет DBeaver).

`8030`: FE (HTTP API для загрузки Stream Load, сюда идет curl).

`8040`: BE (HTTP API метрик и логов).

Часть 2. Быстрый старт (Docker Compose)

Мы поднимем стек StarRocks и MinIO (S3-совместимое хранилище), используя bridge-сеть для связности.

Файл `docker-compose.yml` (Полностью рабочий пример):

version: "3.9"

networks:
  starrocks-stack-network:
    driver: bridge

services:
  starrocks:
    image: starrocks/allin1-ubuntu:4.0-latest
    container_name: starrocks
    hostname: starrocks.local.com
    platform: "linux/amd64"
    restart: unless-stopped
    ports:
      - "9030:9030" # MySQL Protocol (SQL клиенты)
      - "8030:8030" # FE HTTP (Stream Load)
      - "8040:8040" # BE HTTP (Logs/Metrics)
    environment:
      - TZ=UTC
    networks:
      starrocks-stack-network:
    volumes:
      # Персистентность данных (чтобы данные не исчезли после рестарта)
      - ${HOME}/dv/starrocks/be/storage:/data/deploy/starrocks/be/storage
      - ${HOME}/dv/starrocks/be/log:/data/deploy/starrocks/be/log
      - ${HOME}/dv/starrocks/fe/meta:/data/deploy/starrocks/fe/meta
      - ${HOME}/dv/starrocks/fe/log:/data/deploy/starrocks/fe/log

  minio:
    image: quay.io/minio/minio
    container_name: minio
    platform: "linux/amd64"
    hostname: minio.local.com
    restart: unless-stopped
    ports:
      - "9000:9000" # S3 API
      - "9001:9001" # Web UI
    networks:
      starrocks-stack-network:
    environment:
      MINIO_ROOT_USER: root
      MINIO_ROOT_PASSWORD: rootroot
    volumes:
      - ${HOME}/dv/minio/data:/data
    command: server /data --console-address ":9001"

Запуск:
`docker-compose up -d`

Часть 3. Моделирование данных (Table Design)

В StarRocks нельзя просто “создать таблицу”. Нужно выбрать тип ключа (Key Model), который определит, как база будет хранить и обновлять данные.

Подключение (DBeaver): `localhost:9030`, User: `root`, Password: (пусто).

CREATE DATABASE IF NOT EXISTS demo_db;
USE demo_db;

1. Primary Key Model (Для изменяемых данных)

Это “флагманская” возможность StarRocks. Она поддерживает быстрые Upsert (вставка новых или обновление старых записей по ID) в реальном времени.

CREATE TABLE IF NOT EXISTS users (
    user_id INT NOT NULL,
    username VARCHAR(50),
    email VARCHAR(100),
    register_date DATE, 
    city VARCHAR(50)
)
PRIMARY KEY (user_id) -- Уникальный ключ
DISTRIBUTED BY HASH(user_id) -- Распределение данных
PROPERTIES (
    "replication_num" = "1" -- Для локального теста ставим 1 реплику
);

2. Aggregate Key Model (Для витрин данных)

База автоматически агрегирует данные при вставке. Если вы вставите новую продажу с *существующими* датой и категорией, StarRocks не создаст новую строку, а прибавит суммы к уже существующей строке. Это экономит место и ускоряет `GROUP BY`.

CREATE TABLE IF NOT EXISTS daily_sales (
    report_date DATE NOT NULL,
    category VARCHAR(50) NOT NULL,
    
    -- Метрики с функцией агрегации:
    total_amount BIGINT SUM DEFAULT "0", 
    items_sold INT SUM DEFAULT "0"       
)
AGGREGATE KEY (report_date, category)
DISTRIBUTED BY HASH(report_date) BUCKETS 3
PROPERTIES (
    "replication_num" = "1"
);

Часть 4. загрузка данных users (Stream Load)

Для загрузки данных в продакшене мы используем Service Account (Техническую учетную запись). Это стандарт безопасности: мы не используем `root` и не используем токены в конфигах (так как они требуют перезагрузки кластера для смены).

Шаг 1. Создание сервисного пользователя (SQL)

Выполнять под `root`:

-- 1. Создаем пользователя-бота
CREATE USER IF NOT EXISTS 'etl_loader'@'%' IDENTIFIED BY 'SecretPass123!';

-- 2. Даем права ТОЛЬКО на вставку и чтение в базе demo_db
GRANT INSERT, SELECT ON demo_db.* TO 'etl_loader'@'%';

-- Права применяются мгновенно.

Шаг 2. Загрузка сложного JSON через CURL

Stream Load — это самый быстрый способ загрузки (до 100 МБ/сек на узел). Он поддерживает транзакционность (ACID).

Пример файла `users.json`:

{
  "users": [
    {"user_id": 101, "username": "alex", "email": "a@test.com", "city": "NY"},
    {"user_id": 102, "username": "bob", "email": "b@test.com", "city": "LA"}
  ]
}

Команда загрузки (Terminal):

curl --location-trusted \
    -u etl_loader:SecretPass123! \
    -H "Expect: 100-continue" \
    -H "format: json" \
    -H "strip_outer_array: true" \
    -H "json_root: $.users" \
    -H "jsonpaths: [\"$.user_id\", \"$.username\", \"$.email\", \"$.city\"]" \
    -H "columns: user_id, username, email, city" \
    -T "users.json" \
    -XPUT http://localhost:8030/api/demo_db/users/_stream_load

Ответ

{
    "TxnId": 9596,
    "Label": "a9a37ab6-3678-4c08-95b7-2fd8b6ae973e",
    "Db": "demo_db",
    "Table": "users",
    "Status": "Success",
    "Message": "OK",
    "NumberTotalRows": 2,
    "NumberLoadedRows": 2,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 177,
    "LoadTimeMs": 153,
    "BeginTxnTimeMs": 2,
    "StreamLoadPlanTimeMs": 2,
    "ReadDataTimeMs": 0,
    "WriteDataTimeMs": 26,
    "CommitAndPublishTimeMs": 121
}%

Шаг 3. Загрузка в Aggregate Table (Example)

Давайте “дольем” данные в таблицу продаж. Агрегация произойдет на лету.
Файл sales.json (простой список):

[
    {"dt": "2023-11-01", "cat": "Electronics", "amt": 100, "qty": 1},
    {"dt": "2023-11-01", "cat": "Electronics", "amt": 50,  "qty": 1}
]

curl --location-trusted \
    -u etl_loader:SecretPass123! \
    -H "format: json" \
    -H "Expect: 100-continue" \
    -H "strip_outer_array: true" \
    -H "jsonpaths: [\"$.dt\", \"$.cat\", \"$.amt\", \"$.qty\"]" \
    -H "columns: report_date, category, total_amount, items_sold" \
    -T "sales.json" \
    -XPUT http://localhost:8030/api/demo_db/daily_sales/_stream_load

Ответ:

{
    "TxnId": 9613,
    "Label": "bce0721a-dc2d-4927-be93-e0979a57873d",
    "Db": "demo_db",
    "Table": "daily_sales",
    "Status": "Success",
    "Message": "OK",
    "NumberTotalRows": 2,
    "NumberLoadedRows": 2,
    "NumberFilteredRows": 0,
    "NumberUnselectedRows": 0,
    "LoadBytes": 143,
    "LoadTimeMs": 52,
    "BeginTxnTimeMs": 3,
    "StreamLoadPlanTimeMs": 2,
    "ReadDataTimeMs": 0,
    "WriteDataTimeMs": 24,
    "CommitAndPublishTimeMs": 20
}%

Разбор заголовков:

`-u ...`: Авторизация сервисным пользователем.
`Expect: 100-continue`: Критически важно для надежности передачи больших файлов.
`json_root: $.users`: Указывает базе, что данные лежат внутри ключа `users`.
`strip_outer_array: true`: Говорит базе, что внутри лежит массив `[...]` и его нужно “развернуть” в отдельные строки.

Часть 5. Совместимость и Trino Dialect

Одна из сильных сторон StarRocks — способность “притворяться” другими базами данных для облегчения миграции.

Если у вас есть дашборды, написанные на диалекте Trino (Presto), вам не нужно переписывать все SQL-запросы.

Пример трансляции функций:

-- Функция Trino, которой нет в StarRocks
SELECT doy(date '2022-03-06'); 
-- Ошибка: No matching function...

-- Проверяем, как StarRocks переведет этот запрос
TRANSLATE TRINO select doy(date '2022-03-06');
-- Результат: SELECT dayofyear('2022-03-06')

-- Включаем режим автоматической трансляции в сессии
SET sql_dialect = 'trino'; 

-- Теперь запрос выполняется корректно, но это не правда. а вот так SELECT dayofyear('2022-03-06') работает. Может бага или у меня версия не та. 
SELECT doy(date '2022-03-06');   

-- Возвращаем нативный режим
SET sql_dialect = 'starrocks';

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

Итог: Сравнение и Выбор решения ( грубо )

Характеристика	StarRocks	ClickHouse	Trino (Presto)
Основной сценарий	OLAP-витрины с JOIN-ами и обновлениями данных	Сбор логов, событий, метрик (Append-only)	Федерация данных (запрос к S3 + Postgres + Kafka одновременно)
JOIN производительность	⭐⭐⭐ (Excellent, CBO оптимизатор)	⭐ (Слабо, требует денормализации)	⭐⭐⭐ (Excellent)
Обновление (UPDATE)	⭐⭐⭐ (Работает как в OLTP, Primary Key)	⭐ (Тяжелые асинхронные ALTER)	❌ (Обычно только полная перезапись партиций), iceberg не в счёт :)
Язык Engine	C++ (SIMD Vectorized)	C++ (SIMD Vectorized)	Java (JVM)
Место в стеке	Serving Layer (Быстрый доступ для BI)	Storage Layer (Хранение логов)	Query Engine (Ad-hoc запросы к Data Lake)

Выбирайте StarRocks, если:

Вам нужна “витрина” для BI (Superset/Tableau), где данные должны быть всегда свежими (Real-time updates).
Ваш бизнес требует сложных аналитических запросов с множеством JOIN-ов, и ClickHouse не справляется/падает по памяти.
Вы хотите использовать стандартный протокол MySQL без установки проприетарных драйверов.

Настройка ldap в Querybook

Fri, 28 Mar 2025 00:09:54 +0300

Казалось не очевидная задача, но победа случилась на второй день.

querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:47] "GET /ds/user/me/ HTTP/1.1" 401 285 0.000000
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:47] "GET /ds/user/login_method/ HTTP/1.1" 200 273 0.000000
querybook_web            | [2025-03-27 Thu 20:36:56] - /opt/querybook/querybook/server/app/auth/ldap_auth.py - DEBUG   "LDAP bind TRY with username: 'uid=jduke,ou=Users,dc=ldap,dc=example'"
querybook_web            | [2025-03-27 Thu 20:36:56] - /opt/querybook/querybook/server/app/auth/ldap_auth.py - DEBUG   "LDAP bind SUCCESS with username: 'uid=jduke,ou=Users,dc=ldap,dc=example'"
querybook_worker         | [2025-03-27 20:36:56,786: INFO/MainProcess] Task celery.local.sync_elasticsearch__debouncer[f407a87d-ae47-450b-95b1-c44df07eb1e7] received
querybook_worker         | [2025-03-27 20:36:56,787: DEBUG/MainProcess] TaskPool: Apply <function fast_trace_task at 0x7fb3791b0d30> (args:('celery.local.sync_elasticsearch__debouncer', 'f407a87d-ae47-450b-95b1-c44df07eb1e7', {'lang': 'py', 'task': 'celery.local.sync_elasticsearch__debouncer', 'id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'shadow': None, 'eta': None, 'expires': None, 'group': None, 'group_index': None, 'retries': 0, 'timelimit': [None, None], 'root_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'parent_id': None, 'argsrepr': "['users', 1]", 'kwargsrepr': '{}', 'origin': 'gen100@6ede59afb0cf', 'ignore_result': False, 'properties': {'correlation_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'reply_to': '70ed7e91-4699-31e4-8f50-86d1a850d89a', 'delivery_mode': 2, 'delivery_info': {'exchange': '', 'routing_key': 'celery'}, 'priority': 0, 'body_encoding': 'base64', 'delivery_tag': '2d6aecef-9aea-4564-9bd0-994731c8eba5'}, 'reply_to': '70ed7e91-4699-31e4-8f50-86d1a850d89a', 'correlation_id': 'f407a87d-ae47-450b-95b1-c44df07eb1e7', 'hostname': 'celery@05a545667216', 'delivery_info': {'exchange': '', 'routing_key': 'celery', 'priority': 0,... kwargs:{})
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "POST /ds/login/ HTTP/1.1" 200 655 0.282608
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/user/me/ HTTP/1.1" 200 490 0.011824
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/user/setting/ HTTP/1.1" 200 215 0.020317
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:56] "GET /ds/announcement/ HTTP/1.1" 200 215 0.011983
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/query/transpile/ HTTP/1.1" 200 419 0.017954
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/user/notifiers/ HTTP/1.1" 200 348 0.018368
querybook_web            | 127.0.0.1 - - [2025-03-27 20:36:57] "GET /ds/query_execution_exporter/ HTTP/1.1" 200 215 0.023621
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:02] "GET /ds/user/environment/ HTTP/1.1" 200 233 5.029392
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /static/favicon/querybook.svg HTTP/1.1" 200 5544 0.017975
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/query_metastore/ HTTP/1.1" 200 215 0.010979
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/environment/ HTTP/1.1" 200 215 0.029958
querybook_web            | 127.0.0.1 - - [2025-03-27 20:37:05] "GET /ds/admin/query_engine/ HTTP/1.1" 200 215 0.017463
querybook_worker         | [2025-03-27 20:37:06,821: INFO/MainProcess] Task celery.local.sync_elasticsearch[185cb78a-0b66-47de-a3db-71e6bea1e53c] received
querybook_worker         | [2025-03-27 20:37:06,821: DEBUG/MainProcess] basic.qos: prefetch_count->6
querybook_worker         | [2025-03-27 20:37:06,823: INFO/ForkPoolWorker-3] Task celery.local.sync_elasticsearch__debouncer[f407a87d-ae47-450b-95b1-c44df07eb1e7] succeeded in 5.021026143018389s: None
querybook_elasticsearch  | [2025-03-27T20:37:19,071][INFO ][o.o.i.i.ManagedIndexCoordinator] [d8d3bb7a5243] Cancel background move metadata process.
querybook_elasticsearch  | [2025-03-27T20:37:19,073][INFO ][o.o.i.i.ManagedIndexCoordinator] [d8d3bb7a5243] Performing move cluster state metadata.
querybook_elasticsearch  | [2025-03-27T20:37:19,074][INFO ][o.o.i.i.MetadataService  ] [d8d3bb7a5243] Move metadata has finished.

Мистер Дюк теперь может заходить в Querybook

Тот кто первый входит будет являться админом

Далее сделал конвектор к Trino и один eviroment, и добавил конектор в него и юзера

Можно писать запросики

Красивый прогресс

Тоже красиво

Работает и даже на русском.

PS: Откуда взялся Ldap?

Вот этот под руку попался https://github.com/intoolswetrust/ldap-server

Он на базе Apache Directory https://directory.apache.org/apacheds/downloads.html
Сделан как раз для тестов, то что нужно.

Вот так делаем:

docker pull kwart/ldap-server
docker run -it --rm kwart/ldap-server

Потом так:

../containers/bundled_querybook_config.yaml

AUTH_BACKEND: 'app.auth.ldap_auth' # Same as import path when running Python
LDAP_CONN: 'ldap://192.168.215.2:389'
LDAP_USER_DN: 'uid={},ou=Users,dc=ldap,dc=example'

И так

LDAP_CONN: "ldap://192.168.215.2:389"   #  без сертификатов, и так сойдет,  но они нужны и корневые особенно для ldaps. 
LDAP_USER_DN: "uid={},ou=Users,dc=ldap,dc=example"
LDAP_UID_FIELD: "uid"
LDAP_EMAIL_FIELD: "uid"  # У меня нет почты в ldap поэтому схитрил, но надо бы добавить атрибут mail в схему LDAP
LDAP_LASTNAME_FIELD: "sn"
LDAP_FIRSTNAME_FIELD: "cn"  # Используйте cn, если givenName отсутствует
LDAP_FULLNAME_FIELD: "cn"
LDAP_BIND_DN: "uid=admin,ou=system"
LDAP_BIND_PASSWORD: "secret"
LDAP_SEARCH_BASE: "dc=ldap,dc=example"

Теперь осталось придумать как всунуть туда hive matastore – это будет чуть сложнее, чем казалось.
Один всунуть можно, но одного мало, а много лень. Может сделать еще один как все и уже его одного добавлять? пока не знаю 🧐

План запросов — Анализируем производительность в Trino

Fri, 04 Oct 2024 19:50:00 +0300

Оригинал: https://medium.com/@simon.thelin90/query-plans-analyse-sql-performance-in-trino-97ac1e8f8044

Или тут: https://a.gavrilov.info/data/posts/Query%20Plans%20—%20Analyse%20SQL%20Performance%20In%20Trino%20%7C%20by%20Simon%20Thelin%20%7C%20Medium.pdf Query Plans — Analyse SQL Performance In Trino

Ещё одно воскресенье и ещё одна #датаболь для обсуждения.
Сегодня я хочу углубиться в то, как мы можем понять план запроса в Trino.

Исследование плана запроса
Порядок выполнения SQL — Давайте вспомним
Прежде чем мы начнем рассматривать это, давайте вспомним порядок выполнения в SQL-запросе.
FROM, JOIN
WHERE
GROUP BY
HAVING
SELECT
DISTINCT
ORDER BY
LIMIT
Это поможет нам, когда будем читать план запроса.
Как определить, является ли ваш SQL производительным?⚡
Прежде чем запрос может быть запланирован, движок также должен:
Идентифицировать таблицы
Идентифицировать столбцы, использованные в запросе
SQL, простой подсчёт названий должностей, где мы группируем по департаменту.
EXPLAIN ANALYZE WITH

count_titles AS (
SELECT
department,
COUNT(job_title) AS count_job_titles
FROM lakehouse.bronze.jobs
GROUP BY 1
)

SELECT * FROM count_titles
SQL-запрос использует Общую Табличную Выражение (CTE) под именем count_titles для упрощения структуры и улучшения читаемости запроса.
Он начинается с выбора данных из таблицы lakehouse.bronze.jobs.
Внутри CTE данные группируются по столбцу department.
Для каждой группы департаментов подсчитывается количество вхождений job_title и обозначается как count_job_titles.
После определения CTE основной запрос выбирает все столбцы из count_titles CTE.
Основная цель запроса — получить количество названий должностей для каждого департамента из таблицы lakehouse.bronze.jobs.
План запроса 📣
В очереди: 1.84ms, Анализ: 85.69ms, Планирование: 58.35ms, Выполнение: 450.11ms
Фрагмент 1 [HASH]
CPU: 7.57ms, Запланировано: 11.12ms, Заблокировано: 1.80s (Вход: 933.53ms, Выход: 0.00ns), Вход: 8 строк (176B); на задачу: ср.: 4.00, отклонение: 2.00, Выход: 3 строки (67B)
Количество входных данных, обработанных рабочими для этого этапа, может быть перекошено
Выходная структура: [department, count]
Разделение выхода: SINGLE []
Агрегат[тип = FINAL, ключи = [department]]
│ Расклад: [department:varchar, count:bigint]
│ Оценки: {строк: 3 (68B), cpu: 226, память: 68B, сеть: 0B}
│ CPU: 3.00ms (15.00%), Запланировано: 3.00ms (6.52%), Заблокировано: 0.00ns (0.00%), Выход: 3 строки (67B)
│ Ср. вход: 1.00 строки, стандартное отклонение входа: 132.29%
│ count := count(count_0)
└─ LocalExchange[разделение = HASH, аргументы = [department::varchar]]
│ Расклад: [department:varchar, count_0:bigint]
│ Оценки: {строк: 10 (226B), cpu: 226, память: 0B, сеть: 0B}
│ CPU: 1.00ms (5.00%), Запланировано: 1.00ms (2.17%), Заблокировано: 716.00ms (31.49%), Выход: 8 строк (176B)
│ Ср. вход: 1.00 строки, стандартное отклонение входа: 86.60%
└─ RemoteSource[идентификаторы источников = [2]]
Расклад: [department:varchar, count_0:bigint]
CPU: 0.00ns (0.00%), Запланировано: 1.00ms (2.17%), Заблокировано: 933.00ms (41.03%), Выход: 8 строк (176B)
Ср. вход: 1.00 строки, стандартное отклонение входа: 86.60%

Фрагмент 2 [HASH]
CPU: 11.24ms, Запланировано: 19.46ms, Заблокировано: 860.54ms (Вход: 444.24ms, Выход: 0.00ns), Вход: 10 строк (362B); на задачу: ср.: 5.00, отклонение: 2.00, Выход: 8 строк (176B)
Количество входных данных, обработанных рабочими для этого этапа, может быть перекошено
Выходная структура: [department, count_0]
Разделение выхода: HASH [department]
Агрегат[тип = PARTIAL, ключи = [department]]
│ Расклад: [department:varchar, count_0:bigint]
│ Оценки: {строк: 10 (226B), cpu: ?, память: ?, сеть: ?}
│ CPU: 4.00ms (20.00%), Запланировано: 7.00ms (15.22%), Заблокировано: 0.00ns (0.00%), Выход: 8 строк (176B)
│ Ср. вход: 1.25 строки, стандартное отклонение входа: 118.32%
│ count_0 := count(job_title)
└─ Агрегат[тип = FINAL, ключи = [department, job_title]]
│ Расклад: [department:varchar, job_title:varchar]
│ Оценки: {строк: 10 (362B), cpu: 362, память: 362B, сеть: 0B}
│ CPU: 1.00ms (5.00%), Запланировано: 2.00ms (4.35%), Заблокировано: 0.00ns (0.00%), Выход: 10 строк (362B)
│ Ср. вход: 1.25 строки, стандартное отклонение входа: 118.32%
└─ LocalExchange[разделение = HASH, аргументы = [department::varchar, job_title::varchar]]
│ Расклад: [department:varchar, job_title:varchar]
│ Оценки: {строк: 10 (362B), cpu: 362, память: 0B, сеть: 0B}
│ CPU: 0.00ns (0.00%), Запланировано: 0.00ns (0.00%), Заблокировано: 181.00ms (7.96%), Выход: 10 строк (362B)
│ Ср. вход: 1.25 строки, стандартное отклонение входа: 190.79%
└─ RemoteSource[идентификаторы источников = [3]]
Расклад: [department:varchar, job_title:varchar]
CPU: 0.00ns (0.00%), Запланировано: 0.00ns (0.00%), Заблокировано: 444.00ms (19.53%), Выход: 10 строк (362B)
Ср. вход: 1.25 строки, стандартное отклонение входа: 190.79%

Фрагмент 3 [SOURCE]
CPU: 11.49ms, Запланировано: 32.68ms, Заблокировано: 0.00ns (Вход: 0.00ns, Выход: 0.00ns), Вход: 10 строк (382B); на задачу: ср.: 10.00, std.dev.: 0.00, Выход: 10 строк (362B)
Выходная структура: [department, job_title]
Разделение выхода: HASH [department, job_title]
Агрегат[тип = PARTIAL, ключи = [department, job_title]]
│ Расклад: [department:varchar, job_title:varchar]
│ Оценки: {строк: 10 (362B), cpu: ?, память: ?, сеть: ?}
│ CPU: 1.00ms (5.00%), Запланировано: 3.00ms (6.52%), Заблокировано: 0.00ns (0.00%), Выход: 10 строк (362B)
│ Ср. вход: 10.00 строк, std.dev.: 0.00%
└─ Сканирование таблицы[таблица = lakehouse:bronze.jobs]
Расклад: [job_title:varchar, department:varchar]
Оценки: {строк: 10 (362B), cpu: 362, память: 0B, сеть: 0B}
CPU: 10.00ms (50.00%), Запланировано: 29.00ms (63.04%), Заблокировано: 0.00ns (0.00%), Выход: 10 строк (382B)
Ср. вход: 10.00 строк, std.dev.: 0.00%
job_title := job_title:varchar:ОБЫЧНО
department := department:varchar:ОБЫЧНО
Вход: 10 строк (382B), Физический вход: 1.32kB, Время физического входа: 7.50ms
Общая информация о выводе и плане запроса

Высокоуровневый вывод выполнения.

В очереди: 1.84ms
Анализ: 85.69ms
Планирование: 58.35ms
Выполнение: 467.68ms
Разделение на фрагменты
Выполнение запроса делится на три главные фрагмента. Каждый фрагмент представляет этап в процессе выполнения.
Фрагмент 1 [HASH]

HASH
Роль: Этот фрагмент обрабатывает окончательную агрегацию результатов.
Производительность:
CPU: 7.57ms
Запланировано: 11.12ms
Заблокировано: 1.80s (главным образом ожидание данных от других фрагментов)
Вход/Выход:
Вход: 8 строк (176B)
Выход: 3 строки (67B)
Выходная структура: [department, count]
Операции:
Агрегация: Окончательная агрегация по департаменту для вычисления общего количества названий должностей.
Локальный обмен: Перераспределение данных по департаменту для подготовки к окончательной агрегации.
Фрагмент 2 [HASH]

Роль: Этот фрагмент выполняет частичную агрегацию названий должностей по департаменту.
Производительность:
CPU: 11.24ms
Запланировано: 19.46ms
Заблокировано: 860.54ms
Вход/Выход:
Вход: 10 строк (362B)
Выход: 8 строк (176B)
Выходная структура: [department, count_0]
Операции:
Частичная агрегация: Подсчитывает названия должностей по департаменту.
Локальный обмен: Перераспределение данных по департаменту, job_title для дальнейшей агрегации.
Фрагмент 3 [SOURCE]

SOURCE — Сканирование таблицы
Роль: Этот фрагмент читает данные из исходной таблицы.
Производительность:
CPU: 11.49ms
Запланировано: 32.68ms
Вход/Выход:
Вход: 10 строк (382B)
Выход: 10 строк (362B)
Выходная структура: [department, job_title]

Операции:
Сканирование таблицы: Чтение столбцов department и job_title из таблицы lakehouse.bronze.jobs.
Частичная агрегация: Группировка данных по департаменту и job_title и подготовка их к дальнейшей обработке.

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

Время блокировки: Значительное время блокировки указывает на ожидание передачи данных между фрагментами, особенно в Фрагменте 1 и Фрагменте 2. Это часто является признаком задержек передачи данных или неравенства во времени обработки между фрагментами.
Перекос данных: Обратите внимание на перекос в количестве данных, обрабатываемых рабочими на различных этапах, что приводит к тому, что некоторые рабочие обрабатывают больше данных, чем другие. Это может вызывать неэффективность.
Шаги агрегации: Запрос включает несколько этапов частичных и окончательных агрегаций, которые можно оптимизировать, если возможно, уменьшив переброс данных между фрагментами.
CPU и планирование: Время работы CPU и планирования относительно низкое по сравнению с заблокированным временем, что предполагает, что ресурсы CPU не являются узким местом.
Настройка SQL: Измените ваш SQL и изучите план запроса, чтобы найти правильный баланс между этими факторами.

Предложения по оптимизации
Модель данных: Убедитесь, что у вас есть правильная модель данных, например, звездная схема, и выполните расчет OBT на основе звездной схемы.
Материализованное представление: Предварительно посчитайте частые агрегации. Однако я бы предпочел предыдущий шаг этому, это может быть полезно, если у вас нет много времени или вы работаете над первым шагом параллельно, но будьте осторожны, чтобы избежать большого технического долга.
Упростите агрегации: Минимизируйте сложные шаги агрегации, чтобы уменьшить переброс данных.

Introduction to Bash and SQL, Git and Docker

Sun, 28 Jul 2024 22:23:10 +0300

Хорошие книги от Bobby Iliev https://bobbyiliev.com/

https://a.gavrilov.info/data/posts/introduction-to-bash-scripting-dark.pdf
https://a.gavrilov.info/data/posts/introduction-to-bash-scripting-light.pdf
https://a.gavrilov.info/data/posts/introduction-to-sql-dark.pdf
https://a.gavrilov.info/data/posts/introduction-to-sql-light.pdf

https://github.com/bobbyiliev/introduction-to-bash-scripting
https://github.com/bobbyiliev/introduction-to-sql

и есть еще про гит

https://a.gavrilov.info/data/posts/introduction-to-git-and-github-dark.pdf
https://a.gavrilov.info/data/posts/introduction-to-git-and-github-light.pdf

https://a.gavrilov.info/data/posts/introduction-to-docker-dark.pdf
https://a.gavrilov.info/data/posts/introduction-to-docker-light.pdf

Загрузка данных iceberg в Trino

Tue, 28 Feb 2023 20:30:19 +0300

Создание схем

CREATE SCHEMA delta.my_schema_d
WITH (location = ‘s3a://test/delta_p’);

CREATE SCHEMA hive.my_schema_h
WITH (location = ‘s3a://test/hive_p’);

CREATE SCHEMA iceberg.my_schema_i
WITH (location = ‘s3a://test/iceberg_p’);

Создание таблицы на базе CSV

create table hive.my_schema_h.taxi_p (
VendorID bigint,
tpep_pickup_datetime varchar,
tpep_dropoff_datetime varchar,
passenger_count bigint,
trip_distance decimal(20,2),
RatecodeID bigint,
store_and_fwd_flag varchar,
PULocationID bigint,
DOLocationID bigint,
payment_type bigint,
fare_amount decimal(20,2),
extra decimal(20,2),
mta_tax decimal(20,2),
tip_amount decimal(20,2),
tolls_amount decimal(20,2),
improvement_surcharge decimal(20,2),
total_amount decimal(20,2))
WITH (
format = ‘TEXTFILE’,
textfile_field_separator = ‘,’,
skip_header_line_count=1
);

Создание таблицы iceberg

create table iceberg.my_schema_i.taxi_i (
VendorID bigint,
tpep_pickup_datetime varchar,
tpep_dropoff_datetime varchar,
passenger_count bigint,
trip_distance decimal(20,2),
RatecodeID bigint,
store_and_fwd_flag varchar,
PULocationID bigint,
DOLocationID bigint,
payment_type bigint,
fare_amount decimal(20,2),
extra decimal(20,2),
mta_tax decimal(20,2),
tip_amount decimal(20,2),
tolls_amount decimal(20,2),
improvement_surcharge decimal(20,2),
total_amount decimal(20,2))

Запись таблицы iceberg

insert into iceberg.my_schema_i.taxi_i select * from hive.my_schema_h.taxi_p

Классификация в Trino

Tue, 28 Feb 2023 20:25:27 +0300

CREATE SCHEMA delta.my_schema_d
WITH (location = ‘s3a://test/delta_p’);

CREATE TABLE delta.my_schema_d.iris (
id int
, sepal_length double
, sepal_width double
, petal_length double
, petal_width double
, species varchar
);

INSERT INTO delta.my_schema_d.iris VALUES
(1, 5.1, 3.5, 1.4, 0.2, ‘Iris-setosa’),
(2, 4.9, 3, 1.4, 0.2, ‘Iris-setosa’),
(3, 4.7, 3.2, 1.3, 0.2, ‘Iris-setosa’),
(4, 4.6, 3.1, 1.5, 0.2, ‘Iris-setosa’),
(5, 5, 3.6, 1.4, 0.2, ‘Iris-setosa’),
(6, 5.4, 3.9, 1.7, 0.4, ‘Iris-setosa’),
(7, 4.6, 3.4, 1.4, 0.3, ‘Iris-setosa’),
(8, 5, 3.4, 1.5, 0.2, ‘Iris-setosa’),
(9, 4.4, 2.9, 1.4, 0.2, ‘Iris-setosa’),
(10, 4.9, 3.1, 1.5, 0.1, ‘Iris-setosa’),
(11, 5.4, 3.7, 1.5, 0.2, ‘Iris-setosa’),
(12, 4.8, 3.4, 1.6, 0.2, ‘Iris-setosa’),
(13, 4.8, 3, 1.4, 0.1, ‘Iris-setosa’),
(14, 4.3, 3, 1.1, 0.1, ‘Iris-setosa’),
(15, 5.8, 4, 1.2, 0.2, ‘Iris-setosa’),
(16, 5.7, 4.4, 1.5, 0.4, ‘Iris-setosa’),
(17, 5.4, 3.9, 1.3, 0.4, ‘Iris-setosa’),
(18, 5.1, 3.5, 1.4, 0.3, ‘Iris-setosa’),
(19, 5.7, 3.8, 1.7, 0.3, ‘Iris-setosa’),
(20, 5.1, 3.8, 1.5, 0.3, ‘Iris-setosa’),
(21, 5.4, 3.4, 1.7, 0.2, ‘Iris-setosa’),
(22, 5.1, 3.7, 1.5, 0.4, ‘Iris-setosa’),
(23, 4.6, 3.6, 1, 0.2, ‘Iris-setosa’),
(24, 5.1, 3.3, 1.7, 0.5, ‘Iris-setosa’),
(25, 4.8, 3.4, 1.9, 0.2, ‘Iris-setosa’),
(26, 5, 3, 1.6, 0.2, ‘Iris-setosa’),
(27, 5, 3.4, 1.6, 0.4, ‘Iris-setosa’),
(28, 5.2, 3.5, 1.5, 0.2, ‘Iris-setosa’),
(29, 5.2, 3.4, 1.4, 0.2, ‘Iris-setosa’),
(30, 4.7, 3.2, 1.6, 0.2, ‘Iris-setosa’),
(31, 4.8, 3.1, 1.6, 0.2, ‘Iris-setosa’),
(32, 5.4, 3.4, 1.5, 0.4, ‘Iris-setosa’),
(33, 5.2, 4.1, 1.5, 0.1, ‘Iris-setosa’),
(34, 5.5, 4.2, 1.4, 0.2, ‘Iris-setosa’),
(35, 4.9, 3.1, 1.5, 0.1, ‘Iris-setosa’),
(36, 5, 3.2, 1.2, 0.2, ‘Iris-setosa’),
(37, 5.5, 3.5, 1.3, 0.2, ‘Iris-setosa’),
(38, 4.9, 3.1, 1.5, 0.1, ‘Iris-setosa’),
(39, 4.4, 3, 1.3, 0.2, ‘Iris-setosa’),
(40, 5.1, 3.4, 1.5, 0.2, ‘Iris-setosa’),
(41, 5, 3.5, 1.3, 0.3, ‘Iris-setosa’),
(42, 4.5, 2.3, 1.3, 0.3, ‘Iris-setosa’),
(43, 4.4, 3.2, 1.3, 0.2, ‘Iris-setosa’),
(44, 5, 3.5, 1.6, 0.6, ‘Iris-setosa’),
(45, 5.1, 3.8, 1.9, 0.4, ‘Iris-setosa’),
(46, 4.8, 3, 1.4, 0.3, ‘Iris-setosa’),
(47, 5.1, 3.8, 1.6, 0.2, ‘Iris-setosa’),
(48, 4.6, 3.2, 1.4, 0.2, ‘Iris-setosa’),
(49, 5.3, 3.7, 1.5, 0.2, ‘Iris-setosa’),
(50, 5, 3.3, 1.4, 0.2, ‘Iris-setosa’),
(51, 7, 3.2, 4.7, 1.4, ‘Iris-versicolor’),
(52, 6.4, 3.2, 4.5, 1.5, ‘Iris-versicolor’),
(53, 6.9, 3.1, 4.9, 1.5, ‘Iris-versicolor’),
(54, 5.5, 2.3, 4, 1.3, ‘Iris-versicolor’),
(55, 6.5, 2.8, 4.6, 1.5, ‘Iris-versicolor’),
(56, 5.7, 2.8, 4.5, 1.3, ‘Iris-versicolor’),
(57, 6.3, 3.3, 4.7, 1.6, ‘Iris-versicolor’),
(58, 4.9, 2.4, 3.3, 1, ‘Iris-versicolor’),
(59, 6.6, 2.9, 4.6, 1.3, ‘Iris-versicolor’),
(60, 5.2, 2.7, 3.9, 1.4, ‘Iris-versicolor’),
(61, 5, 2, 3.5, 1, ‘Iris-versicolor’),
(62, 5.9, 3, 4.2, 1.5, ‘Iris-versicolor’),
(63, 6, 2.2, 4, 1, ‘Iris-versicolor’),
(64, 6.1, 2.9, 4.7, 1.4, ‘Iris-versicolor’),
(65, 5.6, 2.9, 3.6, 1.3, ‘Iris-versicolor’),
(66, 6.7, 3.1, 4.4, 1.4, ‘Iris-versicolor’),
(67, 5.6, 3, 4.5, 1.5, ‘Iris-versicolor’),
(68, 5.8, 2.7, 4.1, 1, ‘Iris-versicolor’),
(69, 6.2, 2.2, 4.5, 1.5, ‘Iris-versicolor’),
(70, 5.6, 2.5, 3.9, 1.1, ‘Iris-versicolor’),
(71, 5.9, 3.2, 4.8, 1.8, ‘Iris-versicolor’),
(72, 6.1, 2.8, 4, 1.3, ‘Iris-versicolor’),
(73, 6.3, 2.5, 4.9, 1.5, ‘Iris-versicolor’),
(74, 6.1, 2.8, 4.7, 1.2, ‘Iris-versicolor’),
(75, 6.4, 2.9, 4.3, 1.3, ‘Iris-versicolor’),
(76, 6.6, 3, 4.4, 1.4, ‘Iris-versicolor’),
(77, 6.8, 2.8, 4.8, 1.4, ‘Iris-versicolor’),
(78, 6.7, 3, 5, 1.7, ‘Iris-versicolor’),
(79, 6, 2.9, 4.5, 1.5, ‘Iris-versicolor’),
(80, 5.7, 2.6, 3.5, 1, ‘Iris-versicolor’),
(81, 5.5, 2.4, 3.8, 1.1, ‘Iris-versicolor’),
(82, 5.5, 2.4, 3.7, 1, ‘Iris-versicolor’),
(83, 5.8, 2.7, 3.9, 1.2, ‘Iris-versicolor’),
(84, 6, 2.7, 5.1, 1.6, ‘Iris-versicolor’),
(85, 5.4, 3, 4.5, 1.5, ‘Iris-versicolor’),
(86, 6, 3.4, 4.5, 1.6, ‘Iris-versicolor’),
(87, 6.7, 3.1, 4.7, 1.5, ‘Iris-versicolor’),
(88, 6.3, 2.3, 4.4, 1.3, ‘Iris-versicolor’),
(89, 5.6, 3, 4.1, 1.3, ‘Iris-versicolor’),
(90, 5.5, 2.5, 4, 1.3, ‘Iris-versicolor’),
(91, 5.5, 2.6, 4.4, 1.2, ‘Iris-versicolor’),
(92, 6.1, 3, 4.6, 1.4, ‘Iris-versicolor’),
(93, 5.8, 2.6, 4, 1.2, ‘Iris-versicolor’),
(94, 5, 2.3, 3.3, 1, ‘Iris-versicolor’),
(95, 5.6, 2.7, 4.2, 1.3, ‘Iris-versicolor’),
(96, 5.7, 3, 4.2, 1.2, ‘Iris-versicolor’),
(97, 5.7, 2.9, 4.2, 1.3, ‘Iris-versicolor’),
(98, 6.2, 2.9, 4.3, 1.3, ‘Iris-versicolor’),
(99, 5.1, 2.5, 3, 1.1, ‘Iris-versicolor’),
(100, 5.7, 2.8, 4.1, 1.3, ‘Iris-versicolor’),
(101, 6.3, 3.3, 6, 2.5, ‘Iris-virginica’),
(102, 5.8, 2.7, 5.1, 1.9, ‘Iris-virginica’),
(103, 7.1, 3, 5.9, 2.1, ‘Iris-virginica’),
(104, 6.3, 2.9, 5.6, 1.8, ‘Iris-virginica’),
(105, 6.5, 3, 5.8, 2.2, ‘Iris-virginica’),
(106, 7.6, 3, 6.6, 2.1, ‘Iris-virginica’),
(107, 4.9, 2.5, 4.5, 1.7, ‘Iris-virginica’),
(108, 7.3, 2.9, 6.3, 1.8, ‘Iris-virginica’),
(109, 6.7, 2.5, 5.8, 1.8, ‘Iris-virginica’),
(110, 7.2, 3.6, 6.1, 2.5, ‘Iris-virginica’),
(111, 6.5, 3.2, 5.1, 2, ‘Iris-virginica’),
(112, 6.4, 2.7, 5.3, 1.9, ‘Iris-virginica’),
(113, 6.8, 3, 5.5, 2.1, ‘Iris-virginica’),
(114, 5.7, 2.5, 5, 2, ‘Iris-virginica’),
(115, 5.8, 2.8, 5.1, 2.4, ‘Iris-virginica’),
(116, 6.4, 3.2, 5.3, 2.3, ‘Iris-virginica’),
(117, 6.5, 3, 5.5, 1.8, ‘Iris-virginica’),
(118, 7.7, 3.8, 6.7, 2.2, ‘Iris-virginica’),
(119, 7.7, 2.6, 6.9, 2.3, ‘Iris-virginica’),
(120, 6, 2.2, 5, 1.5, ‘Iris-virginica’),
(121, 6.9, 3.2, 5.7, 2.3, ‘Iris-virginica’),
(122, 5.6, 2.8, 4.9, 2, ‘Iris-virginica’),
(123, 7.7, 2.8, 6.7, 2, ‘Iris-virginica’),
(124, 6.3, 2.7, 4.9, 1.8, ‘Iris-virginica’),
(125, 6.7, 3.3, 5.7, 2.1, ‘Iris-virginica’),
(126, 7.2, 3.2, 6, 1.8, ‘Iris-virginica’),
(127, 6.2, 2.8, 4.8, 1.8, ‘Iris-virginica’),
(128, 6.1, 3, 4.9, 1.8, ‘Iris-virginica’),
(129, 6.4, 2.8, 5.6, 2.1, ‘Iris-virginica’),
(130, 7.2, 3, 5.8, 1.6, ‘Iris-virginica’),
(131, 7.4, 2.8, 6.1, 1.9, ‘Iris-virginica’),
(132, 7.9, 3.8, 6.4, 2, ‘Iris-virginica’),
(133, 6.4, 2.8, 5.6, 2.2, ‘Iris-virginica’),
(134, 6.3, 2.8, 5.1, 1.5, ‘Iris-virginica’),
(135, 6.1, 2.6, 5.6, 1.4, ‘Iris-virginica’),
(136, 7.7, 3, 6.1, 2.3, ‘Iris-virginica’),
(137, 6.3, 3.4, 5.6, 2.4, ‘Iris-virginica’),
(138, 6.4, 3.1, 5.5, 1.8, ‘Iris-virginica’),
(139, 6, 3, 4.8, 1.8, ‘Iris-virginica’),
(140, 6.9, 3.1, 5.4, 2.1, ‘Iris-virginica’),
(141, 6.7, 3.1, 5.6, 2.4, ‘Iris-virginica’),
(142, 6.9, 3.1, 5.1, 2.3, ‘Iris-virginica’),
(143, 5.8, 2.7, 5.1, 1.9, ‘Iris-virginica’),
(144, 6.8, 3.2, 5.9, 2.3, ‘Iris-virginica’),
(145, 6.7, 3.3, 5.7, 2.5, ‘Iris-virginica’),
(146, 6.7, 3, 5.2, 2.3, ‘Iris-virginica’),
(147, 6.3, 2.5, 5, 1.9, ‘Iris-virginica’),
(148, 6.5, 3, 5.2, 2, ‘Iris-virginica’),
(149, 6.2, 3.4, 5.4, 2.3, ‘Iris-virginica’),
(150, 5.9, 3, 5.1, 1.8, ‘Iris-virginica’);

select classify(features(5.8, 3, 5.1, 1.8), model) AS prediction
FROM (
SELECT learn_classifier(species, features(sepal_length, sepal_width, petal_length, petal_width)) AS model FROM delta.my_schema_d.iris
) t;

Iris-virginica