Системные коннекторы для обучения

Чтобы изучать Trino, не обязательно поднимать S3, Hive Metastore и PostgreSQL. В комплекте идут коннекторы, которые либо генерируют данные на лету, либо хранят их в памяти, либо вообще ничего не хранят. Они не требуют внешней инфраструктуры — достаточно самого Trino. Эти коннекторы незаменимы для обучения, для воспроизводимых примеров и для тестирования самого движка.

Этот урок разбирает пять таких коннекторов: tpch, tpcds, memory, faker и blackhole. У каждого свой механизм и своё назначение — и понимание этих механизмов само по себе углубляет понимание SPI.

Зачем нужны коннекторы без внешнего источника

Вспомним прошлые уроки: коннектор реализует SPI — Metadata, SplitManager, PageSource. Но SPI нигде не требует, чтобы за коннектором стоял реальный внешний источник. Коннектор может генерировать данные алгоритмически или держать их в памяти процесса Trino. Снаружи разницы нет: движок видит обычные catalog со схемами и таблицами, к которым работает обычный SQL.

Подключаются они тривиально — properties-файл с одной строкой. Внешних параметров им не нужно:

# etc/catalog/tpch.properties
connector.name=tpch

# etc/catalog/memory.properties
connector.name=memory

tpch и tpcds: стандартные бенчмарки

tpch — коннектор, генерирующий данные TPC-H, классического бенчмарка аналитических СУБД. TPC-H моделирует оптовую торговлю: восемь связанных таблиц — customer, orders, lineitem, part, supplier, partsupp, nation, region. Это узнаваемая star-подобная схема, на которой удобно показывать join-ы, агрегации, оконные функции.

Ключевая особенность: данные не хранятся, а генерируются алгоритмически в момент запроса. Каждая строка вычисляется детерминированной функцией от своего номера. Это означает, что таблица tpch.sf1.lineitem существует всегда, занимает ноль места на диске, и всегда содержит одни и те же строки.

Объём задаётся через схему — scale factor. Имя схемы sf1 означает scale factor 1 (примерно 1 ГБ данных в логическом измерении), sf100 — scale factor 100, sf1000 — терабайтный масштаб. Меняя схему, вы меняете объём, не меняя запрос:

SHOW SCHEMAS FROM tpch;

   Schema
------------
 sf1
 sf100
 sf1000
 sf300
 tiny
 ...

-- Один и тот же запрос на разных масштабах
SELECT count(*) FROM tpch.tiny.orders;   -- ~15 000 строк, мгновенно
SELECT count(*) FROM tpch.sf1.orders;    -- ~1 500 000 строк
SELECT count(*) FROM tpch.sf100.orders;  -- ~150 000 000 строк

tpcds — то же самое для TPC-DS: более новый и более тяжёлый бенчмарк, моделирующий розничную торговлю. У него гораздо больше таблиц (двадцать с лишним), более сложная схема со snowflake-связями, и его SQL-запросы заметно сложнее. Если TPC-H хорош для первых примеров, то TPC-DS ближе к реальной аналитической нагрузке.

Поскольку данные tpch и tpcds детерминированы и не требуют загрузки, это идеальный материал для воспроизводимых примеров. Любой пример с tpch.sf1 запустится одинаково на любом кластере Trino в мире — это и делает их стандартом для обучения и для сравнения производительности.

memory: таблицы в оперативной памяти

memory — коннектор, который хранит таблицы прямо в оперативной памяти кластера Trino. В отличие от tpch, он поддерживает не только чтение, но и запись: можно делать CREATE TABLE, CREATE TABLE AS SELECT, INSERT.

-- Создать таблицу в памяти и наполнить её данными из tpch
CREATE TABLE memory.default.top_customers AS
SELECT custkey, name, acctbal
FROM tpch.sf1.customer
WHERE acctbal > 9000;

-- Дальше с ней можно работать обычным SQL
SELECT count(*) FROM memory.default.top_customers;

 _col0
-------
 13860
(1 row)

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

Второе ограничение — объём. Таблицы memory живут в heap воркеров и конкурируют за память с самими запросами. Большой объём в memory положить нельзя — это его осознанная граница. Для обучения и небольших тестовых наборов этого с запасом хватает.

faker: реалистичные синтетические данные

tpch даёт фиксированную схему оптовой торговли. Но что если нужны тестовые данные именно вашей структуры — таблица пользователей с именами, email, датами регистрации? Для этого есть faker — коннектор, генерирующий реалистичные синтетические данные по описанию столбцов.

faker работает иначе, чем tpch. С tpch схема жёстко задана. С faker вы сами создаёте таблицу с нужными столбцами, а коннектор генерирует для них правдоподобные значения. Тип столбца и подсказки определяют характер данных:

-- Создаём таблицу нужной структуры в faker-catalog
CREATE TABLE faker.default.users (
  id        BIGINT,
  full_name VARCHAR,
  email     VARCHAR,
  signup_at TIMESTAMP(6)
);

-- Читаем сгенерированные строки: faker наполнит их синтетикой
SELECT * FROM faker.default.users LIMIT 3;

 id  |   full_name    |        email            |       signup_at
-----+----------------+-------------------------+----------------------------
 1   | Jane Cooper    | [email protected] | 2025-11-02 14:08:51.000000
 2   | Robert Fox     | [email protected]  | 2026-01-19 09:42:13.000000
 3   | Aaron Hughes   | [email protected]   | 2025-08-30 22:15:04.000000
(3 rows)

Назначение faker — тестовые данные под вашу схему, демонстрации, нагрузочные сценарии, проверка SQL-логики на правдоподобных значениях. Когда tpch не подходит, потому что нужна не оптовая торговля, а именно ваша предметная область, — берут faker.

blackhole: коннектор, который ничего не хранит

blackhole — самый необычный из пяти. Он принимает данные на запись и выбрасывает их, ничего не сохраняя. На чтение он отдаёт пустой результат или нули — в зависимости от настройки. Имя говорит само за себя: данные улетают в чёрную дыру.

CREATE TABLE blackhole.default.sink (id BIGINT, payload VARCHAR);

-- INSERT отработает успешно, но данные никуда не запишутся
INSERT INTO blackhole.default.sink
SELECT orderkey, comment FROM tpch.sf10.orders;

INSERT: 15000000 rows

Зачем такой коннектор. Его назначение — тестирование самого Trino, а не данных. С blackhole как приёмником можно измерить, как быстро движок читает источник и обрабатывает данные, исключив из картины стоимость записи в реальное хранилище. Запрос выполнит всё чтение, все join-ы и агрегации, но на финальном шаге запись будет бесплатной. Это изолирует производительность движка от производительности целевого хранилища. blackhole также используют как заглушку в тестах и как пример минимального коннектора.

Сводка: что выбрать для какой задачи

Все пять коннекторов объединяет одно: они не требуют внешней инфраструктуры. Это делает их незаменимыми для обучения — все примеры в этом курсе можно воспроизвести на голом Trino, без облака и без отдельных серверов. И, что важнее, разбор их механизмов закрепляет понимание SPI: коннектор это просто реализация интерфейсов, и за ним может стоять что угодно — реальная СУБД, генератор, кусок памяти или чёрная дыра.

Попробуй сам

На кластере Trino с подключёнными tpch, memory и faker (в песочнице курса они есть) проделайте:

1. Выполните SELECT count(*) для таблицы orders на трёх масштабах tpch: tpch.tiny.orders, tpch.sf1.orders, tpch.sf10.orders. Засеките время каждого. Объясните рост: данные генерируются на лету, больше строк — больше работы.
2. Через CREATE TABLE AS SELECT материализуйте в memory.default выборку из tpch.sf1.customer. Сделайте к ней пару запросов. Затем мысленно ответьте: что станет с этой таблицей после рестарта кластера.
3. Создайте в faker.default таблицу с 3-4 столбцами разных типов и посмотрите сгенерированные строки. Сравните характер данных с tpch.
4. Сформулируйте, чем faker принципиально отличается от tpch по способу задания схемы.

Этот набор — ваша рабочая площадка на весь курс: дальше многие примеры будут опираться именно на tpch.