- Дата публикации
Как Trigger.dev даёт каждому пользователю SQL-доступ к общему ClickHouse и не ломает кластер
Что появилось / что изменилось
Trigger.dev запустила свой язык запросов TRQL (Trigger Query Language) для разделяемого кластера ClickHouse. Это SQL‑подобный DSL, через который пользователи пишут привычный SELECT/WHERE/GROUP BY, но фактически работают не с «сырым» ClickHouse, а с компилируемыми, безопасными запросами.
Ключевые изменения:
- Пользователи получают возможность писать произвольные аналитические запросы в стиле SQL к общему хранилищу данных Trigger.dev.
- Язык TRQL не позволяет выполнять операции записи и администрирования: в нём физически нет INSERT, UPDATE, DELETE, DROP, SET и неразрешённых функций ClickHouse.
- Все запросы автоматически ограничиваются «своим» tenant'ом: TRQL сам добавляет фильтры по организации, пользователь не может их убрать.
- Скрыта внутренняя схема ClickHouse: вместо trigger_dev.task_runs_v2 с колонками cost_in_cents пользователи видят логичную схему уровня «SELECT total_cost FROM runs».
- В схеме TRQL появились дополнительные возможности поверх ClickHouse: виртуальные колонки, автоматическое разбиение по времени, трансформации значений и метаданные для визуализации.
- Под капотом используется общий кластер ClickHouse, который умеет обрабатывать миллиарды строк с типичными агрегациями за доли секунды.
Как это работает
TRQL — это отдельный язык, который компилируется в реальные запросы ClickHouse.
-
Грамматика на ANTLR. Команда Trigger.dev описала строгую грамматику TRQL как подмножество SQL. ANTLR по этой грамматике генерирует лексер и парсер на TypeScript.
- Лексер разбивает текст запроса на токены: ключевые слова, идентификаторы, операторы, строки.
- Парсер строит абстрактное синтаксическое дерево (AST) — структурное представление запроса.
-
Безопасность «по конструкции». Если в грамматике нет ключевого слова DELETE или функции, которую не разрешили, то её нельзя даже синтаксически выразить. Не происходит «проверка и отклонение» — такой запрос просто невозможно разобрать.
-
Компилятор TRQL. Все последующие шаги работают не со строкой, а с AST:
- Автоматически добавляют фильтры по организации для каждого запроса.
- Подменяют логические сущности на реальные таблицы и колонки ClickHouse (например,
runs.total_cost→trigger_dev.task_runs_v2.cost_in_centsс нужными преобразованиями). - Подставляют виртуальные колонки, правила агрегирования, временные бакеты.
- В итоге генерируют валидный SQL для ClickHouse.
-
ClickHouse как движок. ClickHouse хранит данные в колонках, поэтому запрос «SELECT status, total_cost» читает только эти колонки и не трогает output или error. Это даёт высокую скорость на больших объёмах. ClickHouse поддерживает JSON‑функции, сложные агрегации, перцентили и полнотекстовый поиск, поэтому TRQL может использовать эти возможности под капотом.
TRQL изначально вдохновился HogQL от PostHog, но команда Trigger.dev переписала его на TypeScript и развила под собственные сценарии.
Что это значит для вас
Если вы используете Trigger.dev для фоновых задач и хотите нормальную аналитику по событиям и задачам, TRQL закрывает сразу несколько болей:
- SQL без страха сломать всё. Можно давать доступ к аналитике продуктовой команде, аналитикам и инженерам без риска, что кто‑то выполнит DROP TABLE или вытащит данные соседнего клиента.
- Простая схема вместо внутренних таблиц. Вам не нужно разбираться, как именно Trigger.dev хранит task_runs в ClickHouse. Вы работаете с логичными сущностями уровня продукта.
- Готовность к дашбордам. TRQL встроен в Query & Dashboards, поэтому на тех же запросах можно строить визуализации, использовать виртуальные колонки и временные бакеты.
Кому это полезно:
- Продуктовым и data‑командам, которые хотят писать SQL‑подобные запросы по данным Trigger.dev, но не отвечать за безопасность инфраструктуры.
- Инженерам, которым нужно быстро собрать отчёты по задачам, ошибкам, стоимости выполнения и статусам без отдельного DWH.
Где не подойдёт:
- Если вам нужен полный доступ к ClickHouse ради сложных оптимизаций, ручного шардирования или нестандартных функций, TRQL будет ограничивать. Это осознанный дизайн, а не баг.
- Если вы не пользуетесь Trigger.dev, TRQL сам по себе вам не нужен — это язык именно для их данных.
Про ограничения по доступности или необходимости VPN авторы не пишут, но продукт ориентирован на разработчиков, которым комфортно работать с SQL‑подобным интерфейсом.
Место на рынке
TRQL решает ту же задачу, что HogQL у PostHog: дать пользователю SQL‑подобный язык поверх ClickHouse, но с контролируемой грамматикой и безопасной многотенантностью.
Общие черты:
- Оба языка компилируются в ClickHouse‑SQL.
- Оба скрывают внутренние таблицы и колонки, предлагая более удобную схему.
- Оба используют идею «язык как граница безопасности» — опасные операции просто не входят в грамматику.
Отличия:
- HogQL родился в экосистеме PostHog и реализован на Python, TRQL — в экосистеме Trigger.dev и работает на TypeScript.
- TRQL заточен под данные Trigger.dev: задачи, запуски, стоимость, статусы. HogQL — под продуктовую аналитику событий.
Прямых сравнений по скорости выполнения запросов, стоимости инфраструктуры или лимитам объёма данных авторы не приводят. Главное отличие — контекст использования: TRQL — про аналитику фоновых задач в Trigger.dev, HogQL — про аналитику пользовательских событий в PostHog.