Да, есть такое мнение, но немногие это учитывают как важный фактор при выборе платформы для аналитики.
Кому-то, возможно, будет интересно почитать короткую дискуссию на эту тему — она в комментариях к статье: Selling the Data Lakehouse
Отличная вводная статья, но я бы выделил Snowflake в отдельную статью. SF не называют свой продукт serverless, по сути — это managed analytical db, т.к. вы указываете какие вычислительные ресурсы использовать. При этом есть serverless фичи, например — Snowpipe. Вот, например, они сравнивают SF с serverless аналогами: https://www.snowflake.com/blog/snowflake-versus-query-engines/
А вот Google BigQuery является serverless analytical db, в ней вы вычислительными ресурсами не управляете.
Дополню вашу аналитику парой фактов про упомянутые компании. В 2019 Sisense объединились с Periscope Data, а у Амазона есть QuickSight.
Ну и облака с AI можно сказать наступают в России, а в мире уже наступили :).
Да, но если речь именно о «больших данных» :). Но с действительно «большими» и Extract не пройдет :). Кстати, упоминая большие данные, вы примерно какой объем подразумевали?
когда речь идет о больших данных работать с LIVE соединением становится просто невозможно. А BI в большинстве случаев и нужно для больших данных.
Скорее как раз наоборот, хотя и понятно, что вы имели ввиду. С производительностью в LIVE/DIRECT всё будет хорошо при условии, что запросы идут в хранилище на аналитической БД с «правильной» моделью данных.
IMHO, оригинальная статья — неудачный верхнеуровневый обзор по теме. Как было замечено выше, тот кто не в теме, вряд ли что-то поймёт или поймёт неправильно.
Перевод нет смысла комментировать, т.к. вопросы в основном к оригиналу.
По ETL вопрос не в том, из каких иточников данные извлекаются. Про ETL написано «Данные хранятся во временной промежуточной базе данных.», а про ELT «Промежуточная база данных отсутствует». Можете на примере пояснить, что это за база такая и зачем она?
Если вам интересно, могу другие неудачные интерпретации прокомментировать.
«Как-то все в кучу, начали про Кимбала, закончили про упокой...»
Это точно… Похоже на то, как будто студента попросили сделать доклад по теме хранилищ данных. Помимо «в кучу» ещё хватает либо некорректных либо спорных интерпретаций различных понятий (например, ETL), плюс перевод ещё больше местами путает.
Я бы не рекомендовал статью для тех, кто хочет предметно разобраться в этой теме.
приводя в качестве аргумента сотни субъективных обзоров, заполонивших Интернет. Если же вы хотите разобраться, какой инструмент подходит именно вашей компании, не пролистывая сотни страниц “честных” мнений, то ниже будет то, что нужно.
Извините, но это сравнение — еще 1 крайне субъективный и поверхностный обзор. Плюс есть существенные ляпы, которые вводят интересующих в заблуждение…
«Когда первый раз читаешь про Anchor Modeling, становится страшно.»
Это точно :). Очень смелое решение, учитывая масштаб проекта. Смотрел видео вашего доклада на конференции HPE и судя по вопросам, присутствующие там дядьки были весьма удивлены :). Респект!
Пару вопросов:
1) Витрины для Tableau у вас по Кимбаллу или другой подход? И сколько в них примерно таблиц и Тб?
2) Учитывая поддержку историчности для атрибутов, как аналитики пишут запросы, когда нужно получить срез на заданную дату (в срезе, например, несколько десятков полей). В Data Vault для этого можно использовать PIT таблицы. Интересно посмотреть на такой SQL запрос.
Алексей, спасибо за ваши интересные мысли тут! По этому поводу добавлю своих :).
У всех свои объёмы и свои запросы и нужно тестировать именно на своём кейсе. У кого-то 100 Тб, а кому-то и 2-х Гб достаточно. В данном тесте чеки с 12 млн. строк, допустим, это объём для какой-то локальной сети, торгующей бытовой техникой. Если делать аналитикуи на перспективу сразу ставить БД (хотя можно и без), то чем бесплатная неприхотливая Vertica CE на 1 ноде плохой вариант (также как и Exasol)?
"..MPP обычно имеют некий предел..."
Согласен, например, хорошо знакомый вам Sybase IQ.
«сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных»
Почему Exasol заточен на анализ небольшого объёма горячих данных? Я этого не писал. На сайте TPC-H есть результаты бенчмарка для 100 Тб (это максимум для tpc-h), в Badoo сейчас около 40 Тб, Тинькофф начинают 2-й этап пилота на десятках Тб (написали в параллельной ветке).
«Вот пример — у телекомов «горячие данные»...»
Успешно внедрённый вами проект на Vertica, вопросов нет.
Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
А кто тестировал? Мне, например, не очевидны такие выводы.
"… класс задач не тот для Вертики."
А я бы так не ограничивал задачи для Vertica.В данном тесте переделать модель и соответственно переписать запросы и картина сильно поменяется.
Но оставим объёмы и производительность. В статье ещё внимание уделяется другим моментам. Например, модели данных, которая оказалась не «удобной» для Vertica в данном кейсе. Ещё я оставил за рамками статьи утилизацию ресурсов при выполнении теста. Vertica на джоины и агрегации кушала больше оперативной памяти чем сами данные и в определённых прогонах я получил: ERROR 3587: Insufficient resources to execute plan on pool general [Timedout waiting for resource request: Request exceeds limits: Memory(KB)...
Движки у Vertica и Exasol явно сильно отличаются и как минимум в определённых случаях Exasol оптимальнее использует ресурсы. Exasol прямо в документации пишут, что не бойтесь нормализации модели, а в Vertica надо с этим аккуратно.
В итоге, я не делал выводов о том, какая БД лучше. Vertica и Exasol — отличные варианты для DWH и аналитики при правильном их использовании, иначе я не писал бы про них столько :).
Про апельсины и лимоны не соглашусь. Это 2 БД для DWH и аналитики. И если Vertica не IM DB, то Exasol не только IM DB (данные не обязательно должны помещать в память).
Привет! Согласен, что тест на 3 нодах, который можно выполнить, используя Vertica Community Edition, был бы интереснее. Но я не смог бы тогда сравнивать с другими БД из моего списка. Exasol, к сожалению, предлагает для бесплатного использования только single node (trial cloud не считаю), Teradata Developer Edition тоже.
Также я не считаю, что 1 нода — это критическое ограничение в моём тесте. Возможно, я продолжу данный тест Vertica на 3-х нодах (например, + 2 ноды и объём данных * 3). В итоге у меня либо получится примерно то же время выполнения, либо худшее, т.к. для данного теста возможно будет сложно подобрать хороший ключ для сегментирования.
Кстати, пользуясь случаем, нигде не находил информации, какую модель (подход) для DWH вы используете в своих проектах (Yota и др.)?
Спасибо alexxz, очень интересен ваш опыт.
Можете ещё поделиться, какой подход используете для модели DWH (3NF, DataVault, Kimball, Anchor,...)?
Меня в Exasol очень заинтересовало то, что они рекомендуют использовать полностью нормализованную модель (например, Data Vault), не опасаясь проблем с производительностью запросов при соединении множества таблиц. Планирую это проверить.
Ещё можно ориентироваться на спец. предложение для Tableau:
до 100 Gb of raw data — 12 000 Евро
до 500 Gb — 26 000
до 2 Тб — 45 000
Не думаю, что итоговая договорная стоимость для других кейсов, будет значительно дороже.
Нету тут противоречия, по указанной ссылке просто нет результатов для других объёмов. Указал диапазон, чтобы была понятней область применения СУБД. К слову, 100 Тб — максимальный scale factor для tpc-h согласно спецификации.
Кому-то, возможно, будет интересно почитать короткую дискуссию на эту тему — она в комментариях к статье:
Selling the Data Lakehouse
Отличная вводная статья, но я бы выделил Snowflake в отдельную статью. SF не называют свой продукт serverless, по сути — это managed analytical db, т.к. вы указываете какие вычислительные ресурсы использовать. При этом есть serverless фичи, например — Snowpipe. Вот, например, они сравнивают SF с serverless аналогами:
https://www.snowflake.com/blog/snowflake-versus-query-engines/
А вот Google BigQuery является serverless analytical db, в ней вы вычислительными ресурсами не управляете.
Дополню вашу аналитику парой фактов про упомянутые компании. В 2019 Sisense объединились с Periscope Data, а у Амазона есть QuickSight.
Ну и облака с AI можно сказать наступают в России, а в мире уже наступили :).
Скорее как раз наоборот, хотя и понятно, что вы имели ввиду. С производительностью в LIVE/DIRECT всё будет хорошо при условии, что запросы идут в хранилище на аналитической БД с «правильной» моделью данных.
А Direct Query в Qlik?
Перевод нет смысла комментировать, т.к. вопросы в основном к оригиналу.
По ETL вопрос не в том, из каких иточников данные извлекаются. Про ETL написано «Данные хранятся во временной промежуточной базе данных.», а про ELT «Промежуточная база данных отсутствует». Можете на примере пояснить, что это за база такая и зачем она?
Если вам интересно, могу другие неудачные интерпретации прокомментировать.
Это точно… Похоже на то, как будто студента попросили сделать доклад по теме хранилищ данных. Помимо «в кучу» ещё хватает либо некорректных либо спорных интерпретаций различных понятий (например, ETL), плюс перевод ещё больше местами путает.
Я бы не рекомендовал статью для тех, кто хочет предметно разобраться в этой теме.
Извините, но это сравнение — еще 1 крайне субъективный и поверхностный обзор. Плюс есть существенные ляпы, которые вводят интересующих в заблуждение…
А есть где-то записи докладов и материалы этой франшизы?
Это точно :). Очень смелое решение, учитывая масштаб проекта. Смотрел видео вашего доклада на конференции HPE и судя по вопросам, присутствующие там дядьки были весьма удивлены :). Респект!
Пару вопросов:
1) Витрины для Tableau у вас по Кимбаллу или другой подход? И сколько в них примерно таблиц и Тб?
2) Учитывая поддержку историчности для атрибутов, как аналитики пишут запросы, когда нужно получить срез на заданную дату (в срезе, например, несколько десятков полей). В Data Vault для этого можно использовать PIT таблицы. Интересно посмотреть на такой SQL запрос.
А оценивали, как Exasol справляется с запросами, когда данные читаются с диска (например, относительно Greenplum)?
Удачи!
У всех свои объёмы и свои запросы и нужно тестировать именно на своём кейсе. У кого-то 100 Тб, а кому-то и 2-х Гб достаточно. В данном тесте чеки с 12 млн. строк, допустим, это объём для какой-то локальной сети, торгующей бытовой техникой. Если делать аналитикуи на перспективу сразу ставить БД (хотя можно и без), то чем бесплатная неприхотливая Vertica CE на 1 ноде плохой вариант (также как и Exasol)?
"..MPP обычно имеют некий предел..."
Согласен, например, хорошо знакомый вам Sybase IQ.
«сравнивать Вертику с СУБД, заточенными на анализ небольшого объема горячих данных при хранении большого числа данных»
Почему Exasol заточен на анализ небольшого объёма горячих данных? Я этого не писал. На сайте TPC-H есть результаты бенчмарка для 100 Тб (это максимум для tpc-h), в Badoo сейчас около 40 Тб, Тинькофф начинают 2-й этап пилота на десятках Тб (написали в параллельной ветке).
«Вот пример — у телекомов «горячие данные»...»
Успешно внедрённый вами проект на Vertica, вопросов нет.
Здесь inmemory и в частности Exasol выглядят не очень подходящим решением и если смоделировать тесты по задачам под данное направление, то они проиграют в нагрузочных тестах и по скорости загрузки и по скорости выполнения параллельных запросов.
А кто тестировал? Мне, например, не очевидны такие выводы.
"… класс задач не тот для Вертики."
А я бы так не ограничивал задачи для Vertica.В данном тесте переделать модель и соответственно переписать запросы и картина сильно поменяется.
Но оставим объёмы и производительность. В статье ещё внимание уделяется другим моментам. Например, модели данных, которая оказалась не «удобной» для Vertica в данном кейсе. Ещё я оставил за рамками статьи утилизацию ресурсов при выполнении теста. Vertica на джоины и агрегации кушала больше оперативной памяти чем сами данные и в определённых прогонах я получил:
ERROR 3587: Insufficient resources to execute plan on pool general [Timedout waiting for resource request: Request exceeds limits: Memory(KB)...
Движки у Vertica и Exasol явно сильно отличаются и как минимум в определённых случаях Exasol оптимальнее использует ресурсы. Exasol прямо в документации пишут, что не бойтесь нормализации модели, а в Vertica надо с этим аккуратно.
В итоге, я не делал выводов о том, какая БД лучше. Vertica и Exasol — отличные варианты для DWH и аналитики при правильном их использовании, иначе я не писал бы про них столько :).
Также я не считаю, что 1 нода — это критическое ограничение в моём тесте. Возможно, я продолжу данный тест Vertica на 3-х нодах (например, + 2 ноды и объём данных * 3). В итоге у меня либо получится примерно то же время выполнения, либо худшее, т.к. для данного теста возможно будет сложно подобрать хороший ключ для сегментирования.
Кстати, пользуясь случаем, нигде не находил информации, какую модель (подход) для DWH вы используете в своих проектах (Yota и др.)?
Можете ещё поделиться, какой подход используете для модели DWH (3NF, DataVault, Kimball, Anchor,...)?
Меня в Exasol очень заинтересовало то, что они рекомендуют использовать полностью нормализованную модель (например, Data Vault), не опасаясь проблем с производительностью запросов при соединении множества таблиц. Планирую это проверить.
до 100 Gb of raw data — 12 000 Евро
до 500 Gb — 26 000
до 2 Тб — 45 000
Не думаю, что итоговая договорная стоимость для других кейсов, будет значительно дороже.