Долго пытался понять, откуда “отсутствие транзакций” в greenplum взялось в нашем начальном ответе.
Вышла накладочка, по смыслу надо читать не “в greenplum отсутствуют транзакции“, а в наших бизнес-процессах внесения данных в хранилище отсутствует OLTP нагрузка.
Причём тут транзакции? При том, что greenplum вполне себе позволяет хранить данные построчно, делая транзакционную нагрузку менее тяжёлой. Это был плюс, который мог качнуть решение в сторону greenplum.
Что касается второй части вопроса. В целом выглядит как заявка на масштабный холивар, ещё и с основательной подготовкой.
disclaimer: Нам жаль, если мы своим комментарием задели чьи-то чувства к greenplum (если это так), но копаться сейчас в памяти и восстанавливать историю, чтобы потом получить в ответ что-то вроде “Ну так вы просто неправильно всё сделали!” — не хочется.
Делать всё то же самое не ради поспорить, а просто поделиться опытом — занятие бессмысленное, много воды уже утекло, системы меняются, то что могло раньше раздражать уже могли поправить.
До сих пор ни одно решение по хранению не позиционирует себя как silver bullet — всегда найдётся кейс, когда решение будет плохим, и вертика — не исключение.
Если есть интерес, мы можем подробней остановиться на тех фичах, которые нас привлекли к Vertica (а не оттолкнули от greenplum). И при этом постараемся обойтись без описания структур данных и конфигурации кластера.
По BI провели полномасштабный feature discovery по множеству продуктов. Особенно тщательно изучили лидеров Gartner с наличием хоть какого-то варианта Self-Service: PowerBI, Qlik Sense, Tableau.
Начали сравнивать, оказалось, что Tableau сильно впереди за счёт push-down в СУБД, наличия честного Live connect без ограничений, а также наличия уже известных практик impact анализа по отчётам (хоть и не в коробке продукта).
Ни Qlik Sense, ни PowerBI live connect’ом не порадовали. PowerBI ещё удивил наличием технических ограничений по объёму данных (кол-ву строк).
В принципе PowerBI развивается и мы видим, что MS выкатывает новые фичи. Но пока что нас не впечатлило.
Что касается поддержки R — в табло она уже очень давно есть. Есть также и поддержки других языков через embedding в R, что более эффективно для расчётов, потому что сам R жутко медленный.
AnchorModelling тяжело ложится что на ClickHouse, что на Columnstore. В DataVault меньше джойнов, должно быстрее летать. В любом случае надо смотреть на частоту изменения модели данных и ее размеры в целом.
Csense сейчас используем для некоторых задач, но весь поток будем через Historian API забирать. С их Hadoop Platform есть одна проблема — он стоит приличное количество денег и только только появился.
Первоначально оценили данные в 50ТБ. Думаю, что за 1 год заполним.
Про нормализацию:
Витрины будем делать денормализованными. Детальный слой планируем строить на смеси DataVault и AnchorModelling.
Columnstore, если честно, даже не рассматривали как возможный вариант. Не помню точно что повлияло, но она даже в short-list не вошла.
Сейчас полистали. По обзорам и отзывам в интернете, этому проекту ещё предстоит развиваться. Но текущая документация как-то скудно описывает и архитектуру, и возможности по оптимизации хранения под определённые запросы. Например, управление сегментацией, pruning при чтении…
Иначе говоря, если бы встал вопрос сейчас, мы тоже бы не заинтересовались.
Создание, миграции моделей между разными средами, исполнение моделей и их мониторинг.
Многие вещи так или иначе уже есть в Ignite ML Framework, многие постепенно появляются, но на текущий момент целиком переехать на него не можем.
Все-таки Ignite ML framework больше про алгоритмы, а наш фреймворк больше про жизненный цикл и управление моделями.
Мы внимательно следим за развитием Ignite ML framework. Возможно в будущем будем его использовать под нашим движком в качестве одного из способов исполнения алгоритмов.
Спасибо за инфу! Задача такая есть. Решение Predix смотрели (их private cloud), думаем над использованием его подсистемы для переноса архивных данные Historian'а в Hadoop.
По Flume и Kafka — в целом да, в кафку сейчас можно любую функциональность запихнуть. Но с точки зрения эксплуатации и последующей разработки, мы их разделили, чтобы максимально упростить процесс изменений и контроля.
По Spark и Flink — если нам нужен микробатчинг или батчинг, то будем использовать Spark. Если нужна обработка в «реальном времени» — будем использовать Flink. Они все-таки немного разные, будем подбирать по задаче.
По ML — затолкнули все, что используют наши сайнтисты.
Мы специально сразу добавили в архитектуру реляционную MPP базу по следующим причинам:
Для хранения агрегатов, небольшого горизонта детальных данных и витрин данных
Как инструмент с меньшим порогом входа для пользователей. Многие знают только SQL.
Как более простую подложку для BI инструментов
Почему именно Вертика (в основном выбирали между GreenPlum, ClickHouse и Exasol):
GreenPlum отмели, тк не очень подходит по нагрузке, отсутвию транзакций. И есть мучительный опыт с ним.
ClickHouse сыроват и пока может решать весь набор требуемых задач.
Exasol — пока очень дорогой, требовательный к железу, проприетарная ОС, мало инфы и внедрений в России. Т.к. мы все равно немного Enterprise, решили не рисковать.
Опять же низкий порог входа. У Вертики прекрасный оптимизатор, который спокойно переваривает самые глупые запросы.
Есть базовые интеграции с используемым стеком (c Hadoop, Kafka, Spark).
В команде большая экспертиза по Вертике. Есть опыт двух больших внедрений.
Думаю тут есть некая путаница. Мы сделали свой кастомный ML фреймворк, работающий на игнайте, который совпал по названию с Ignite ML Framework :) И поместили в раздел к ML инструментам, тк пока планируем его использовать только для машинки.
По факту, это фреймворк управления жизенным циклом моделей (ci\cd, исполнение, мониторинг), который использует часть нашей инфраструктуры для своей работы (Elastic, HDFS, YARN). В то же время источником данных для обучения и работы моделей выступает наша платформа.
Коллеги обещают сделать отдельную статью про этот фреймворк.
Вышла накладочка, по смыслу надо читать не “в greenplum отсутствуют транзакции“, а в наших бизнес-процессах внесения данных в хранилище отсутствует OLTP нагрузка.
Причём тут транзакции? При том, что greenplum вполне себе позволяет хранить данные построчно, делая транзакционную нагрузку менее тяжёлой. Это был плюс, который мог качнуть решение в сторону greenplum.
Что касается второй части вопроса. В целом выглядит как заявка на масштабный холивар, ещё и с основательной подготовкой.
disclaimer: Нам жаль, если мы своим комментарием задели чьи-то чувства к greenplum (если это так), но копаться сейчас в памяти и восстанавливать историю, чтобы потом получить в ответ что-то вроде “Ну так вы просто неправильно всё сделали!” — не хочется.
Делать всё то же самое не ради поспорить, а просто поделиться опытом — занятие бессмысленное, много воды уже утекло, системы меняются, то что могло раньше раздражать уже могли поправить.
До сих пор ни одно решение по хранению не позиционирует себя как silver bullet — всегда найдётся кейс, когда решение будет плохим, и вертика — не исключение.
Если есть интерес, мы можем подробней остановиться на тех фичах, которые нас привлекли к Vertica (а не оттолкнули от greenplum). И при этом постараемся обойтись без описания структур данных и конфигурации кластера.
Начали сравнивать, оказалось, что Tableau сильно впереди за счёт push-down в СУБД, наличия честного Live connect без ограничений, а также наличия уже известных практик impact анализа по отчётам (хоть и не в коробке продукта).
Ни Qlik Sense, ни PowerBI live connect’ом не порадовали. PowerBI ещё удивил наличием технических ограничений по объёму данных (кол-ву строк).
В принципе PowerBI развивается и мы видим, что MS выкатывает новые фичи. Но пока что нас не впечатлило.
Что касается поддержки R — в табло она уже очень давно есть. Есть также и поддержки других языков через embedding в R, что более эффективно для расчётов, потому что сам R жутко медленный.
MemSQL не видели, спасибо, исследуем!
Про нормализацию:
Витрины будем делать денормализованными. Детальный слой планируем строить на смеси DataVault и AnchorModelling.
Columnstore, если честно, даже не рассматривали как возможный вариант. Не помню точно что повлияло, но она даже в short-list не вошла.
Сейчас полистали. По обзорам и отзывам в интернете, этому проекту ещё предстоит развиваться. Но текущая документация как-то скудно описывает и архитектуру, и возможности по оптимизации хранения под определённые запросы. Например, управление сегментацией, pruning при чтении…
Иначе говоря, если бы встал вопрос сейчас, мы тоже бы не заинтересовались.
Многие вещи так или иначе уже есть в Ignite ML Framework, многие постепенно появляются, но на текущий момент целиком переехать на него не можем.
Мы внимательно следим за развитием Ignite ML framework. Возможно в будущем будем его использовать под нашим движком в качестве одного из способов исполнения алгоритмов.
По Spark и Flink — если нам нужен микробатчинг или батчинг, то будем использовать Spark. Если нужна обработка в «реальном времени» — будем использовать Flink. Они все-таки немного разные, будем подбирать по задаче.
По ML — затолкнули все, что используют наши сайнтисты.
Мы специально сразу добавили в архитектуру реляционную MPP базу по следующим причинам:
Почему именно Вертика (в основном выбирали между GreenPlum, ClickHouse и Exasol):
По факту, это фреймворк управления жизенным циклом моделей (ci\cd, исполнение, мониторинг), который использует часть нашей инфраструктуры для своей работы (Elastic, HDFS, YARN). В то же время источником данных для обучения и работы моделей выступает наша платформа.
Коллеги обещают сделать отдельную статью про этот фреймворк.
Но планируем мониторить следующим образом по предыдущему опыту: