Почему не надо бояться доверять молодым сотрудникам, или как в Ozon Tech набирают джунов на сорокочасовую рабочую неделю с окладом в половину от оклада джуна, прессуя их срочным трудовым договором и не выдавая учебных отпусков, ведь у них как раз за полгода две недели отпуска набирается
Масштабный материал, спасибо. Хотя я бы тут добавил, что Grafana для OLAP (для которого Clickhouse большей частью и используется) — это из раздела "сомнительно, но окей", так как когда задачи не time-series, а slice-and-dice, все эти time-series корни графаны начинают заметно мешаться под ногами. Жить можно, конечно, но можно рассмотреть и другие продукты.
Несколько вопросов по статье:
Старайтесь использовать колонки из ключа сортировки таблицы (секция ORDER BY при создании таблицы).
Можете разьяснить, это о чём? В чем разница чтения колонки из индекса и не из индекса?
К тому же, на основании данной фразы кто-то может подумать, что надо затянуть как можно больше колонок в sorting key (а лучше вообще все), что приведет к проблемам.
Используйте Materialized View или внешние системы по типу Airflow для вычисления агрегатов в фоне.
Там теперь еще есть production-ready проекции, которые и считают агрегаты в фоне без необходимости создания и поддержки дополнительных таблиц (но есть подвох для Replacing/Aggregating движков)
Интерпретируйте партицию как отдельный файл. На открытие и чтение каждого файла система тратит время. Чем меньше партиций используется в запросе, тем лучше
пишете вы, а потом используете партиционирование по toMonth(timestamp), складывая в одну партицию месяцы разных годов и лишая себя возможности использовать minmax индекс партиции.
Пример с партициямипо toMonth: https://fiddle.clickhouse.com/cd9fe46b-fedc-41e8-85e1-9893577d3729
Пример с партициями по toYYYYMM: https://fiddle.clickhouse.com/b6e5848d-a86f-4c8f-98f1-6772c13b4e59
Экспериментируйте с гранулярностью индекса
и не забывайте о последствиях, я бы добавил, дабы не возникло желание сделать гранулярность 1, "как в b-tree".
VertiPaq как раз-таки совсем не то, что было 25 лет назад, что позволило в свое время прикрутить к страничному SQL Server columnstore индексы и сделать SSAS Tabular (он же живет внутри модели Power BI). Vertipaq - это columnstore, in-memory, компрессия и прочие радости, которые делают его родственником современным колоночных аналитических систем. но статья странная, да )
из того, что вы описали, правильно я понимаю, что можно перефразировать Ваше "почему вам обязательно нужна звезда" в "почему вам обязательно нужна звезда, если вы работаете с Qlik, который по-другому не умеет"? просто есть Power BI, который умеет по-другому, за счет того, что имеет внутри себя движок от Tabular SSAS со всеми фичами columnstore хранилищ, что позволяет иметь примерно один и тот же вид модели, как на реляционном "транзакционном" источнике, так и в аналитической модели, вместо того, чтобы тратить ресурсы на разработку и поддержку второй модели специально для аналитики.
Прошу прощения за возможный негатив моего комментария, но у меня с Вами идеологические разногласия.
Ральф Кимбал (один из отцов dimensional modeling, частью которого является схема "звезда"): "Мы использовали этот подход для построения аналитических хранилищ поверх строчных баз данных, чтобы [получить хоть какой-то вменяемый performance, не сожрав все вычислительные ресурсы] уменьшить количество джойнов и соединять различные метрики через conformed dimensions. Этот продукт удобно потреблять [если data modeler и ETL developer, которые это всё поддерживают и расширяют - это не вы :)], но с развитием in-memory и колоночных хранилищ используемые методы поменяются" Microsoft (середина 2000-х): "Dimensional modeling - это, конечно, хорошо, но неинтуитивно и дорого поддерживать. Давайте купим создателей движка Vertipaq, который станет основой для наших columnstore индексов (для быстрых online запросов в режиме DirectQuery) и Tabular Data Model (которая в том числе обитает внутри Power BI)". ClickHouse: "Колоночное хранение, компрессия, векторные вычисления и бесплатность продукта решают большинство проблем, для решения которых придумывали dimensional modeling" Представитель Visiology: "Для работы с BI сегодня как никогда актуальна такая модель данных как “Звезда”. Мы создали концепцию перехода на “Звезду” для любых проектов, даже если изначально в них не подразумевалось использование такой модели данных"
не кажется ли Вам, что вы переоцениваете актуальность dimensional modeling в современной дата аналитике? я не отрицаю, что у нее остаются свои области применения, но такие броские фразы как "как никогда актуальна" и "для любых проектов", несколько смущают
и несколько вопросов по некоторым пунктам из статьи, которые я не совсем понял: 1. про фактовую таблицу (где вы описываете варианты звезды, вариант 2, собственно базовый, содержит ключи измерений и значения фактов) Вы пишете "Такая модель имеет меньше гибкости в сценариях связи (нельзя реализовать один ко многим, многие ко многим), потому что реализация этих сценариев подразумевает размножение строк в центральной таблице.". Насколько я помню, для построения "многие-ко-многим" использовались bridge tables, которые никак не влияют на количество фактов.
2. "По мере углубления практик BI использование такой модели данных как “Звезда” становится обязательным, если вы хотите сохранить гибкость." Гибкость в чем, в разработке? В статье "Visiology 3.0: реальная замена Microsoft Power BI или наш дерзкий маркетинговый ход?" от 6 июня Ваш коллега(?) пишет: - "Как хорошо знают аналитики, львиная доля времени, уходящего на манипуляции с BI-платформой, приходится на настройку ETL и подготовку витрин. За счет DAX мы стремимся делать сложные расчеты на сырых данных практически в реальном времени." - " Мы стремились создать простую и легко понятную модель данных. Ведь обычно очень много времени тратится на создание модели данных, ее доработку…а также на передачу другим аналитикам[...] В 3.0 можно будет загружать нормализованные таблицы и предусматривать между ними разные связи — не обязательно приводить к звезде." Все эти слова для меня более созвучны с понятием "гибкость", чем dimensional modeling.
3. У вас на последней картинке в списке хранилищ данных есть ClickHouse. Вы и поверх него предлагаете навешивать звезду или это просто показывает, что у Вашего продукта к нему коннектор есть?
Почему не надо бояться доверять молодым сотрудникам, или как в Ozon Tech набирают джунов на сорокочасовую рабочую неделю с окладом в половину от оклада джуна, прессуя их срочным трудовым договором и не выдавая учебных отпусков, ведь у них как раз за полгода две недели отпуска набирается
Масштабный материал, спасибо. Хотя я бы тут добавил, что Grafana для OLAP (для которого Clickhouse большей частью и используется) — это из раздела "сомнительно, но окей", так как когда задачи не time-series, а slice-and-dice, все эти time-series корни графаны начинают заметно мешаться под ногами. Жить можно, конечно, но можно рассмотреть и другие продукты.
Несколько вопросов по статье:
Можете разьяснить, это о чём? В чем разница чтения колонки из индекса и не из индекса?
К тому же, на основании данной фразы кто-то может подумать, что надо затянуть как можно больше колонок в sorting key (а лучше вообще все), что приведет к проблемам.
Там теперь еще есть production-ready проекции, которые и считают агрегаты в фоне без необходимости создания и поддержки дополнительных таблиц (но есть подвох для Replacing/Aggregating движков)
пишете вы, а потом используете партиционирование по toMonth(timestamp), складывая в одну партицию месяцы разных годов и лишая себя возможности использовать minmax индекс партиции.
Пример с партициямипо toMonth: https://fiddle.clickhouse.com/cd9fe46b-fedc-41e8-85e1-9893577d3729
Пример с партициями по toYYYYMM: https://fiddle.clickhouse.com/b6e5848d-a86f-4c8f-98f1-6772c13b4e59
и не забывайте о последствиях, я бы добавил, дабы не возникло желание сделать гранулярность 1, "как в b-tree".
VertiPaq как раз-таки совсем не то, что было 25 лет назад, что позволило в свое время прикрутить к страничному SQL Server columnstore индексы и сделать SSAS Tabular (он же живет внутри модели Power BI). Vertipaq - это columnstore, in-memory, компрессия и прочие радости, которые делают его родственником современным колоночных аналитических систем.
но статья странная, да )
вам выпишут штраф 3000 рублей за то, что перед переездом на срок более шести месяцев вы с учета не снялись (статья 21.5 КоАП РФ)
из того, что вы описали, правильно я понимаю, что можно перефразировать Ваше "почему вам обязательно нужна звезда" в "почему вам обязательно нужна звезда, если вы работаете с Qlik, который по-другому не умеет"? просто есть Power BI, который умеет по-другому, за счет того, что имеет внутри себя движок от Tabular SSAS со всеми фичами columnstore хранилищ, что позволяет иметь примерно один и тот же вид модели, как на реляционном "транзакционном" источнике, так и в аналитической модели, вместо того, чтобы тратить ресурсы на разработку и поддержку второй модели специально для аналитики.
Прошу прощения за возможный негатив моего комментария, но у меня с Вами идеологические разногласия.
Ральф Кимбал (один из отцов dimensional modeling, частью которого является схема "звезда"): "Мы использовали этот подход для построения аналитических хранилищ поверх строчных баз данных, чтобы [получить хоть какой-то вменяемый performance, не сожрав все вычислительные ресурсы] уменьшить количество джойнов и соединять различные метрики через conformed dimensions. Этот продукт удобно потреблять [если data modeler и ETL developer, которые это всё поддерживают и расширяют - это не вы :)], но с развитием in-memory и колоночных хранилищ используемые методы поменяются"
Microsoft (середина 2000-х): "Dimensional modeling - это, конечно, хорошо, но неинтуитивно и дорого поддерживать. Давайте купим создателей движка Vertipaq, который станет основой для наших columnstore индексов (для быстрых online запросов в режиме DirectQuery) и Tabular Data Model (которая в том числе обитает внутри Power BI)".
ClickHouse: "Колоночное хранение, компрессия, векторные вычисления и бесплатность продукта решают большинство проблем, для решения которых придумывали dimensional modeling"
Представитель Visiology: "Для работы с BI сегодня как никогда актуальна такая модель данных как “Звезда”. Мы создали концепцию перехода на “Звезду” для любых проектов, даже если изначально в них не подразумевалось использование такой модели данных"
не кажется ли Вам, что вы переоцениваете актуальность dimensional modeling в современной дата аналитике? я не отрицаю, что у нее остаются свои области применения, но такие броские фразы как "как никогда актуальна" и "для любых проектов", несколько смущают
и несколько вопросов по некоторым пунктам из статьи, которые я не совсем понял:
1. про фактовую таблицу (где вы описываете варианты звезды, вариант 2, собственно базовый, содержит ключи измерений и значения фактов) Вы пишете "Такая модель имеет меньше гибкости в сценариях связи (нельзя реализовать один ко многим, многие ко многим), потому что реализация этих сценариев подразумевает размножение строк в центральной таблице.". Насколько я помню, для построения "многие-ко-многим" использовались bridge tables, которые никак не влияют на количество фактов.
2. "По мере углубления практик BI использование такой модели данных как “Звезда” становится обязательным, если вы хотите сохранить гибкость." Гибкость в чем, в разработке? В статье "Visiology 3.0: реальная замена Microsoft Power BI или наш дерзкий маркетинговый ход?" от 6 июня Ваш коллега(?) пишет:
- "Как хорошо знают аналитики, львиная доля времени, уходящего на манипуляции с BI-платформой, приходится на настройку ETL и подготовку витрин. За счет DAX мы стремимся делать сложные расчеты на сырых данных практически в реальном времени."
- " Мы стремились создать простую и легко понятную модель данных. Ведь обычно очень много времени тратится на создание модели данных, ее доработку…а также на передачу другим аналитикам[...] В 3.0 можно будет загружать нормализованные таблицы и предусматривать между ними разные связи — не обязательно приводить к звезде."
Все эти слова для меня более созвучны с понятием "гибкость", чем dimensional modeling.
3. У вас на последней картинке в списке хранилищ данных есть ClickHouse. Вы и поверх него предлагаете навешивать звезду или это просто показывает, что у Вашего продукта к нему коннектор есть?