Дельные дополнения. И да, скорее публикация ориентирована на маленькие-средние компании. С крупными предприятиями всегда есть нюансы. Читая, вспомнил и свой опыт работы с Informatica PC, кажется, в том же Банке :) Спасибо за то, что делитесь опытом!
Пробую объяснить свой сценарий. Есть Greenplum как general purpose DWH, в нем делаются все преобразования, джоины, тяжелые расчеты. В результате получаются витрины, содержащие очищенные и ценные данные. Эти витрины имеет смысл перенести в Clickhouse, т.к. именно Clickhouse может обеспечить отклик запросов за миллисекунды.
Например, BI инструмент будет смотреть именно в Clickhouse. Пользователю, работающему с BI (PowerBI / Tableau / Datalens / ...) не обязательно знать детали реализации и что и куда смотрит. Он просто кликает графики и дашборды, получая ответы на вопросы интерактивно, вне зависимости от объемов данных.
Недаром Arenadata строит свой стек на Hadoop + Greenplum + Clickhouse (и всё Open Source).
От Select * есть технологический антидот - SQLFluff, rule_L044
Про CTE хотелось бы узнать, какие парсеры-компиляторы умные, какие нет; и почему нельзя рассчитывать на умные.
Привет, спасибо.
Да, SQLFluff отдельная история. В особенности с dbt (шаблонизированным кодом). Ее можно встраивать как проверку на этапе DEV – тогда каждый разработчик/аналитик сам отвечает. Либо на этапе TEST/CI – как проверка кода, тогда в этом контуре нужно будет скомпилировать код и проверить.
По поводу парсеров – я имел в виду сами аналитические движки. Часть из них может составить полный план запроса и оптимизировать (переписать). Например, 3 CTE читающие разные таблицы select *, финальный запрос с применением фильтра WHERE на даты + категории. Часть движков сможет эти фильтры переместить сразу в изначальные CTE, чтобы не читать все строки. Другие движки будут полностью собирать 3 CTE-таблицы в промежуточную область, и только потом фильтровать, что будет значительно дольше.
Тот, кто был замотивирован, уже выиграл бесплатное обучение.
Любое качественное обучение и материал стоит денег. Платите ли вы их напрямую, либо косвенно.
3 дня это дефолтные настройки для ускорения разработки и экономии ресурсов. Каждое подключение конфигурируется «тегом». Сейчас их всего 3 для удобства: dev (для каждого члена команды), ci (он же тест), prod. У аналитиков по дефолту dev в настройках подключения под личной учеткой. Это реализовано в макросе:
{#- prepare expression to filter rows to last 'development_days_of_data' (e.g. last 3 days) -#}
{%- if target.name in ['dev', 'ci'] and last_n_days_of_data == true -%}
{%- set dev_rows_expression = ts_field ~ ' >= dateadd(day, ' ~ -var('development_days_of_data') ~ ', current_timestamp::date)' -%}
{%- else -%}
{%- set dev_rows_expression = '1 = 1' -%}
{%- endif -%}
Если есть цель построить витрины за бОльший период или оценить производительность – просто корректируется скомпилированный код вручную (убирается фильтр либо расширяется диапазон дат), запускается через dbeaver. Либо просто в локальной версии репо меняется значение переменной:
Отрадно видеть в слайдах дашборд по мониторингу dbt джобов, который я создал для Wheely :)
Нелишним считаю сослаться на свой обзор от мая 2020: habr.com/ru/company/otus/blog/501380
dbt очень перспективный инструмент. Россия немного отстает в части адаптации и внедрения. Но интерес будет только расти в ближайшее время.
Сегодня в русскоязычном сегменте не хватает кейсов на dbt. Моя недавняя публикация на тему решения для Сквозной Аналитики на Хабр: habr.com/ru/post/538106
Очень странно было увидеть недетерминированный запрос в решении. Где сортировка-то?
Для моей задачи сортировка неважна. После формирования колонки применяется фильтр LIKE на наличие тега или отсутствие. Но сортировка может иметь значение — это верное замечание. Пример с сортировкой: http://sqlfiddle.com/#!4/16ed58/10
Вы анонсировали ТРИ разные СУБД (а по тексту ещё и на четвёртую ссылаетесь). Соответственно вопрос — где описание/пример (или хотя бы упоминание) RANGE clause?
Например, шаг 4 в задаче сессионизации:
,sum(is_new_session) over (partition by user_id order by ts rows between unbounded preceding and current row) as session_index
А хэш-то зачем? чтобы сервер не скучал? Простой конкатенации вполне достаточно, тем более что всё использование результата — это сравнить с LAG() на точное совпадение.
Соглашусь, хеш можно расценить как избыточный шаг здесь, особенно при условии разового использования.
Кстати, а как решение справится с делением на сессии, если работать от одной учётной записи в двух разных окнах браузера, параллельно?
Думаю, кука в браузере будет одна и серия хитов из разных табов браузера будут записана как одна сессия.
Публикация скорее направлена на расширение кругозора и для тех, кто ищет подсказки и подходы к решению.
Спасибо, тоже давно поглядываю в сторону Snowflake.
Немного охлаждает пыл необходимость полноценного тестирования, подготовки плана миграции.
Однако мы используем dbt для всей логической модели Хранилища, а dbt отлично интегрирован как с Redshift, так и со Snowflake (и с BigQuery, но его пока не рассматриваем).
Про проект Хранилища Wheely на dbt будет большой отдельный пост!
Честно говоря, не рассматривался. Знаю про продукт и примерно сценарии его использования.
Некоторое время назад там не было полноценной поддержки соединения таблиц (JOIN). Предлагалось создавать широкие таблицы и работать с ними.
В Wheely специфика метрик и расчетов предполагает большое количество соединений и сложных, многоуровневых CTE.
В целом симпатизирую Clickhouse, присмотрюсь в будущем, возможно потестируем что-то и найдем применение.
Спасибо за ответ. Примерно так и предполагал. У нас сейчас в команде нет возможности выделить ресурс на полноценный Ops-сопровождение решения.
В Redshift радует то, что это fully managed service. Раз в неделю автоматические обновления, в случае необходимости рестарт кластера 1-й кнопкой, автоматические бэкапы, и всё родное для AWS.
Vertica функциональнее, соглашусь. Если уметь выжать из неё всё. Уже несколько лет назад там были полнотекстовый индекс, in-database ML, сессионизация, pattern-matching по сессиям. И фишка с проекциями конечно супер.
Кстати, справедливости ради, хочется именно подчеркнуть, что время на компиляцию требуется только при первом запуске запроса. Все последующие запуски в точности того же запроса происходят без этапа компиляции.
Т.е. при использовании BI-инструментов (читай конструкторов запросов) и преднастроенных дашбордов эффект может быть и незаметен.
Верно! Есть такая особенность, может показаться неприятной.
Не буду оправдывать или защищать, Vertica я тоже очень люблю.
Что по поводу бюджета? При примерно одинаковых мощностях, что выходит дороже?
Как решается вопрос с Operations? Обновление версий/maintenance? На себя всё берет вендор?
Потенциально в планах на ближайшие месяцы PoC со Snowflake.
Snowflake отлично работает с JSON — у нас источник MongoDB.
Если получится — будет максимально объективный обзор и сравнение. Подписывайтесь и не пропустите!
Дельные дополнения.
И да, скорее публикация ориентирована на маленькие-средние компании. С крупными предприятиями всегда есть нюансы. Читая, вспомнил и свой опыт работы с Informatica PC, кажется, в том же Банке :)
Спасибо за то, что делитесь опытом!
Пробую объяснить свой сценарий.
Есть Greenplum как general purpose DWH, в нем делаются все преобразования, джоины, тяжелые расчеты. В результате получаются витрины, содержащие очищенные и ценные данные.
Эти витрины имеет смысл перенести в Clickhouse, т.к. именно Clickhouse может обеспечить отклик запросов за миллисекунды.
Например, BI инструмент будет смотреть именно в Clickhouse.
Пользователю, работающему с BI (PowerBI / Tableau / Datalens / ...) не обязательно знать детали реализации и что и куда смотрит. Он просто кликает графики и дашборды, получая ответы на вопросы интерактивно, вне зависимости от объемов данных.
Недаром Arenadata строит свой стек на Hadoop + Greenplum + Clickhouse (и всё Open Source).
Интересный комментарий из ТГ:
Привет, спасибо.
Да, SQLFluff отдельная история.
В особенности с dbt (шаблонизированным кодом). Ее можно встраивать как проверку на этапе DEV – тогда каждый разработчик/аналитик сам отвечает.
Либо на этапе TEST/CI – как проверка кода, тогда в этом контуре нужно будет скомпилировать код и проверить.
По поводу парсеров – я имел в виду сами аналитические движки. Часть из них может составить полный план запроса и оптимизировать (переписать).
Например, 3 CTE читающие разные таблицы select *, финальный запрос с применением фильтра WHERE на даты + категории.
Часть движков сможет эти фильтры переместить сразу в изначальные CTE, чтобы не читать все строки. Другие движки будут полностью собирать 3 CTE-таблицы в промежуточную область, и только потом фильтровать, что будет значительно дольше.
Действительно Airbyte решили выпилить коннектор
HTTP Request.Подробности здесь: https://github.com/airbytehq/airbyte/pull/5185.
API Метрики можно подключить так:
– Source type: File
– Provider: HTTPS
Любое качественное обучение и материал стоит денег. Платите ли вы их напрямую, либо косвенно.
Большое уважение. Спасибо, Дмитрий, что делишься опытом!
Всё верно подмечено.
3 дня это дефолтные настройки для ускорения разработки и экономии ресурсов. Каждое подключение конфигурируется «тегом». Сейчас их всего 3 для удобства: dev (для каждого члена команды), ci (он же тест), prod. У аналитиков по дефолту dev в настройках подключения под личной учеткой. Это реализовано в макросе:
Если есть цель построить витрины за бОльший период или оценить производительность – просто корректируется скомпилированный код вручную (убирается фильтр либо расширяется диапазон дат), запускается через dbeaver. Либо просто в локальной версии репо меняется значение переменной:
Качественная работа!
Отдельное спасибо за код.
Нелишним считаю сослаться на свой обзор от мая 2020: habr.com/ru/company/otus/blog/501380
dbt очень перспективный инструмент. Россия немного отстает в части адаптации и внедрения. Но интерес будет только расти в ближайшее время.
Сегодня в русскоязычном сегменте не хватает кейсов на dbt. Моя недавняя публикация на тему решения для Сквозной Аналитики на Хабр:
habr.com/ru/post/538106
Например, шаг 4 в задаче сессионизации:
Соглашусь, хеш можно расценить как избыточный шаг здесь, особенно при условии разового использования.
Думаю, кука в браузере будет одна и серия хитов из разных табов браузера будут записана как одна сессия.
Публикация скорее направлена на расширение кругозора и для тех, кто ищет подсказки и подходы к решению.
RFM (Recency-Frequency-Monetary value) — анализ Customer Lifetime Value, клиентская аналитика и прогнозирование продаж.
Немного охлаждает пыл необходимость полноценного тестирования, подготовки плана миграции.
Однако мы используем dbt для всей логической модели Хранилища, а dbt отлично интегрирован как с Redshift, так и со Snowflake (и с BigQuery, но его пока не рассматриваем).
Про проект Хранилища Wheely на dbt будет большой отдельный пост!
Некоторое время назад там не было полноценной поддержки соединения таблиц (JOIN). Предлагалось создавать широкие таблицы и работать с ними.
В Wheely специфика метрик и расчетов предполагает большое количество соединений и сложных, многоуровневых CTE.
В целом симпатизирую Clickhouse, присмотрюсь в будущем, возможно потестируем что-то и найдем применение.
В Redshift радует то, что это fully managed service. Раз в неделю автоматические обновления, в случае необходимости рестарт кластера 1-й кнопкой, автоматические бэкапы, и всё родное для AWS.
Vertica функциональнее, соглашусь. Если уметь выжать из неё всё. Уже несколько лет назад там были полнотекстовый индекс, in-database ML, сессионизация, pattern-matching по сессиям. И фишка с проекциями конечно супер.
Т.е. при использовании BI-инструментов (читай конструкторов запросов) и преднастроенных дашбордов эффект может быть и незаметен.
Не буду оправдывать или защищать, Vertica я тоже очень люблю.
Что по поводу бюджета? При примерно одинаковых мощностях, что выходит дороже?
Как решается вопрос с Operations? Обновление версий/maintenance? На себя всё берет вендор?
Snowflake отлично работает с JSON — у нас источник MongoDB.
Если получится — будет максимально объективный обзор и сравнение. Подписывайтесь и не пропустите!