SubQuery - ClickHouse, dbt, Iceberg

🏠  Зачем платить за две квартиры, если можно жить в одной?

Представьте: в одной вы храните все вещи. В другой — работаете. А между ними каждый день перевозите коробки. Звучит абсурдно? 🤪

А теперь замените квартиры на Data Lake и DWH, а коробки — на данные. Узнаёте свою архитектуру? 

А что, если хранить данные и работать с ними можно в одном месте? Именно на этом строится идея лейкхауса.

Данные хранятся в S3, Apache Iceberg обеспечивает транзакции и управление таблицами, а Spark, Trino и DuckDB работают с ними без необходимости создавать отдельную копию под каждый движок.

Но есть нюанс.

Построить лейкхаус — полдела. Не дать ему превратиться в свалку — вот настоящее искусство.

Мелкие файлы, разросшиеся метаданные, старые снапшоты… Без обслуживания даже красивая архитектура начинает тормозить и дорожать.

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

👉  https://subquery.ru/blog/data-lakehouse-iceberg

Меньше переездов, больше аналитики. И никаких коробок посреди комнаты.

🗑 У вас хранилище данных или свалка?

Двести таблиц лежат рядом. Где сырые данные, где очищенные, а что уже можно спокойно брать в отчёт — никто точно не помнит. Пора раскладывать данные по слоям.

В новой статье разбираемся:

— зачем вообще делить DWH на слои;
— чем Staging → Core → Витрины отличается от Bronze → Silver → Gold;
— где должны жить сырые данные, бизнес-логика и готовые метрики;
— почему тесты нужны на каждом слое;
— и на какие архитектурные грабли наступают чаще всего.

Спойлер: семь слоёв там, где нужны три, — тоже не лучшая архитектура.

👉 Прочитать подробнее можно по ссылке: 
https://subquery.ru/blog/data-warehouse-layering

А сколько слоёв в вашем хранилище?

🧠 Мы много рассказывали о том, как семантический слой помогает ИИ правильно считать метрики и не придумывать бизнес-логику на ходу.

Но для успеха помимо расчета метрик у сущностей нужно ещё понимать связи между этими сущностями. За эту часть и отвечает онтология, а без неё LLM будет пытаться угадать на основе своих знаний из интернета.

Если семантический слой — это словарь;
то онтология — словарь + связи между понятиями.

Именно эти связи дают ИИ контекст бизнеса и позволяют отвечать уже не только на вопрос «сколько», но и разбираться в «почему»и «как это связано».

В новой статье разбираемся:

— чем онтология отличается от семантического слоя и модели данных;
— зачем она нужна ИИ-агентам;
— как выглядит на реальном бизнес-примере;
— что такое RDF и OWL и нужны ли они вам вообще;
— как начать строить свою онтологию без огромного проекта на полгода.

ЧИТАТЬ ТУТ ⬇️
https://subquery.ru/blog/semantic-layer/what-is-ontology

И да, там есть прекрасная аналогия с сыром, из которого ИИ пытается сделать обратно молоко 🧀

🔒  А вы точно знаете, кто в компании видит зарплаты?

А ещё персональные данные клиентов? Продажи других регионов? Финансовые показатели?

Когда таблиц сто, пользователей триста, а доступы годами выдавались «на всякий случай», ответить на этот вопрос становится неожиданно сложно. А параллельно маркетинг, финансы и продажи могут считать одну и ту же выручку тремя разными способами.

Это как раз задача Data Governance — и семантический слой здесь нужен не только для единой логики метрик.

Он может стать единой точкой, где определяется:
— кто отвечает за конкретную метрику и как она считается;
— какие строки доступны пользователю — RLS;
— какие колонки он вообще может видеть — CLS;
— какие правила доступа применяются ко всем отчётам и запросам.

В новой статье разбираем всё это на практических примерах с Cube и в конце даём план внедрения — от инвентаризации метрик до матрицы доступов.

👉 Читать про семантический слой и Governance: порядок и права доступа
👈
Потому что «кажется, у него не должно быть доступа» — не лучшая политика безопасности 😅

Очень хочется рассказать, над чем работаем уже продолжительное время, и я решил не сдерживаться.🤭

Основной модуль в нашем сервисе - 🟠dbt. Он позволяет целым командам на регулярной основе перерабатывать большие массивы данных, и сейчас под управлением SubQuery находится несколько сотен терабайт.
Но какое вам до этого дело, правильно?)🤷

Для работы с dbt нужны данные и субд, которая их хранит и обрабатывает. Мы прекрасно понимаем, что это значимое препятствие для работы с сервисом😥. И вот скриншот закрывает первый вопрос - регулярные поставки данных.

Долго думали, как это правильно организовать, чтобы и масштабировалось, и селф-сервис присутствовал с кастомизациями, и пропускная способность высокая для больших ребят, и закрывались как адхоки, так и крон-задачи.. придумали😉. Наверняка, позже будет статья на хабре об архитектуре решения, а пока гоняем внутри и готовим к публичному тестированию.

Чем отличается?

– мы в первую очередь ориентируемся на data специалистов, так что ожидайте упор на сырьё
– не просим креды от вашей СУБД, но и не лочим данные у себя, об этом позже
– предположу, что у нас самый большой в рунете опыт работы с маркетинговыми источниками - свыше сотни интеграций за плечами
– будут бесплатные квоты, не сомневайтесь. Коммьюнити 💚

Когда ждать?

Надеюсь успеть до релиза GTA 🤣

🩺 У вас Iceberg тормозит? Сейчас поставим диагноз

Жалобы: запросы стали выполняться дольше.
Данных больше не стало.
Кластер жив.
В приложении ничего не меняли.

Что ж, посмотрим пациента 👨‍⚕️

Чаще всего причина одна из пяти:
— слишком много мелких файлов;
— неправильная сортировка;
— раздутые манифесты;
— накопившиеся старые снапшоты;
— партиции, которые больше не соответствуют реальным запросам.

В новой статье проводим полную диспансеризацию Iceberg-таблицы:
—  на какие симптомы смотреть;
—  как подтвердить диагноз SQL-запросом;
—  как лечить;
—  как проверить, что лечение помогло.
А в конце — диагностический чек-лист и скрипт обслуживания.

👉 Читать статью можно тут: 
https://subquery.ru/blog/iceberg-queries-speedup

Сохраняйте. Даже если у вашего Iceberg пока ничего не болит.

🏞️ Google показал, как должен работать современный лейкхаус

В июле Google представил Borderless Lakehouse — архитектуру на Apache Iceberg, которая объединяет каталоги AWS, Snowflake и Databricks, позволяет разным движкам работать с одними таблицами и автоматически оптимизирует хранение. Следом появился фреймворк из 6 слоёв оптимизации Iceberg.

Производительность складывается сразу из нескольких уровней:
— файлов и их раскладки;
— метаданных;
— обработки изменений данных;
— сортировки и кластеризации;
— модели исполнения;
— того, насколько хорошо движок вообще понимает Iceberg.

А сверху появляется ещё один важный слой — управление всей этой системой: обслуживание таблиц, наблюдаемость, маршрутизация запросов и работа ИИ-агентов.

В статье — не просто архитектура Google, а набор принципов, которые можно применять в открытом лейкхаусе с разными движками и облаками.

👉 Читать про лейкхаус как у Google: шесть слоев оптимизации 👈

Очень рекомендуем сохранить. Кажется, это одна из тех статей, к которым мы ещё не раз будем возвращаться

Уже убедили вас, что семантический слой нужен?😏

Мы рассказывали, для чего он, как помогает ИИ не выдумывать метрики и как с его помощью ускорять аналитику.

Следующий логичный вопрос: а какой семантический слой выбрать?

Мы разобрали 9 решений, которые стоит рассматривать в 2026 году: dbt Semantic Layer, Cube, AtScale, Snowflake Semantic Views, Databricks Metric Views, Looker, GoodData, MicroStrategy ONE и Atlan.

И разделили их на четыре категории — потому что под словами «семантический слой» сегодня скрываются довольно разные инструменты.

Внутри — плюсы, минусы, примеры моделей и сравнительная таблица. А главное — что выбирать именно под ваш сценарий.

👉 Какой семантический слой выбрать

Спойлер: лучшего семантического слоя нет. Есть тот, который подходит вашему стеку и задачам.

...А какой используете вы? 👀

— А как ты это посчитал?
— Сейчас покажу…

ищет SQL
пытается вспомнить, какой CSV был финальным
открывает Python
понимает, что график строился вообще в другом файле

— В общем, поверьте, там всё правильно 😅

Потому что одно дело — получить результат. Другое — через неделю восстановить весь путь от запроса до графика.

#буднианалитика

🦆 Утка улетает в AWS

Если пропустили новости: Amazon покупает DuckLabs — команду, которая стоит за DuckDB. И кажется, это довольно прозрачный намёк на то, куда всё движется 👀

DuckDB уже отлично работает напрямую с данными в S3, а теперь логично ожидать, что эта связка будет развиваться ещё активнее.

И очень вовремя мы на днях выпустили большой разбор DuckDB + Apache Iceberg
.
Почему эта пара интересна:
— данные лежат в S3 в открытом формате
— Iceberg отвечает за таблицы, версии и каталог
— DuckDB позволяет запускать SQL прямо поверх них
— а для многих задач вообще не нужен отдельный кластер

В статье разбираем не только красивую сторону, но и реальные ограничения: запись, производительность, обслуживание таблиц и ситуации, когда вместо DuckDB всё-таки лучше взять Trino, Spark или Athena.

Кажется, это уже не просто интересный эксперимент. За этим будущее.

👉 Начать изучать можно здесь:
https://subquery.ru/blog/duckdb-iceberg