Yuriy Gavrilov: posts tagged SQL

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