Комментарии 29
Привет, спасибо за сайтью. А как вы мониторите потоки данных в таком зоопарке? Как быстро узнаете и узнаете ли что какой-то из потоков отвалился?
Если честно, пока никак не мониторим.
Но планируем мониторить следующим образом по предыдущему опыту:
Но планируем мониторить следующим образом по предыдущему опыту:
- Логи всех потоков и elt процессов будем складывать в ELK
- Метрики процессов будем складывать в Grafana (под ней скорее всего будет Clickhouse).
- Критичные алерты будут сыпаться в Slack
- При необходимости прикрутим Sentry и Moira сверху
- Проверки качества данных тоже постараемся положить в ELK
А как используется Ignite ML Framework в этой системе? Немного неожиданно его видеть не в области хранения и обработки данных.
Присоединяюсь к этому вопросу, можно ли узнать больше деталей про эту часть?
Думаю тут есть некая путаница. Мы сделали свой кастомный ML фреймворк, работающий на игнайте, который совпал по названию с Ignite ML Framework :) И поместили в раздел к ML инструментам, тк пока планируем его использовать только для машинки.
По факту, это фреймворк управления жизенным циклом моделей (ci\cd, исполнение, мониторинг), который использует часть нашей инфраструктуры для своей работы (Elastic, HDFS, YARN). В то же время источником данных для обучения и работы моделей выступает наша платформа.
Коллеги обещают сделать отдельную статью про этот фреймворк.
По факту, это фреймворк управления жизенным циклом моделей (ci\cd, исполнение, мониторинг), который использует часть нашей инфраструктуры для своей работы (Elastic, HDFS, YARN). В то же время источником данных для обучения и работы моделей выступает наша платформа.
Коллеги обещают сделать отдельную статью про этот фреймворк.
Да, путаница действительно возникла потому что у Ignite есть собственный модуль ML. Вот и показалось что речь о нем)
И кстати об Ignite ML, во встроенном фреймворке есть возможность импорта и инференса моделей. Это свежий функционал и возможно Вы его пропустили. Нет ли планов по использованию этого встроенного фреймворка?
Все-таки Ignite ML framework больше про алгоритмы, а наш фреймворк больше про жизненный цикл и управление моделями.
Мы внимательно следим за развитием Ignite ML framework. Возможно в будущем будем его использовать под нашим движком в качестве одного из способов исполнения алгоритмов.
Мы внимательно следим за развитием Ignite ML framework. Возможно в будущем будем его использовать под нашим движком в качестве одного из способов исполнения алгоритмов.
Спасибо за статью. А не могли бы вы подробней рассказать о том как используется Ignite ML в вашем решении?
Ответил вот здесь :)
Почему в качестве ХД решили вертику использовать?
Отвечу немного шире.
Мы специально сразу добавили в архитектуру реляционную MPP базу по следующим причинам:
Почему именно Вертика (в основном выбирали между GreenPlum, ClickHouse и Exasol):
Мы специально сразу добавили в архитектуру реляционную MPP базу по следующим причинам:
- Для хранения агрегатов, небольшого горизонта детальных данных и витрин данных
- Как инструмент с меньшим порогом входа для пользователей. Многие знают только SQL.
- Как более простую подложку для BI инструментов
Почему именно Вертика (в основном выбирали между GreenPlum, ClickHouse и Exasol):
- GreenPlum отмели, тк не очень подходит по нагрузке, отсутвию транзакций. И есть мучительный опыт с ним.
- ClickHouse сыроват и пока может решать весь набор требуемых задач.
- Exasol — пока очень дорогой, требовательный к железу, проприетарная ОС, мало инфы и внедрений в России. Т.к. мы все равно немного Enterprise, решили не рисковать.
- Опять же низкий порог входа. У Вертики прекрасный оптимизатор, который спокойно переваривает самые глупые запросы.
- Есть базовые интеграции с используемым стеком (c Hadoop, Kafka, Spark).
- В команде большая экспертиза по Вертике. Есть опыт двух больших внедрений.
Можете сказать размер данных в Вертике? И денормализуете ли данные? И не смотрели ли MariaDB Column Store? Мы всё никак не выберем, ClickHouse — быстрый, но крикой SQL. Остальные стоят денег
Первоначально оценили данные в 50ТБ. Думаю, что за 1 год заполним.
Про нормализацию:
Витрины будем делать денормализованными. Детальный слой планируем строить на смеси DataVault и AnchorModelling.
Columnstore, если честно, даже не рассматривали как возможный вариант. Не помню точно что повлияло, но она даже в short-list не вошла.
Сейчас полистали. По обзорам и отзывам в интернете, этому проекту ещё предстоит развиваться. Но текущая документация как-то скудно описывает и архитектуру, и возможности по оптимизации хранения под определённые запросы. Например, управление сегментацией, pruning при чтении…
Иначе говоря, если бы встал вопрос сейчас, мы тоже бы не заинтересовались.
Про нормализацию:
Витрины будем делать денормализованными. Детальный слой планируем строить на смеси DataVault и AnchorModelling.
Columnstore, если честно, даже не рассматривали как возможный вариант. Не помню точно что повлияло, но она даже в short-list не вошла.
Сейчас полистали. По обзорам и отзывам в интернете, этому проекту ещё предстоит развиваться. Но текущая документация как-то скудно описывает и архитектуру, и возможности по оптимизации хранения под определённые запросы. Например, управление сегментацией, pruning при чтении…
Иначе говоря, если бы встал вопрос сейчас, мы тоже бы не заинтересовались.
Странно. А какие транзакции отсутствуют в Greenplum? Можете описать структуры данных и конфигурации кластеров Greenplum, вызвавшие негативный опыт использования/тестирования?
Долго пытался понять, откуда “отсутствие транзакций” в greenplum взялось в нашем начальном ответе.
Вышла накладочка, по смыслу надо читать не “в greenplum отсутствуют транзакции“, а в наших бизнес-процессах внесения данных в хранилище отсутствует OLTP нагрузка.
Причём тут транзакции? При том, что greenplum вполне себе позволяет хранить данные построчно, делая транзакционную нагрузку менее тяжёлой. Это был плюс, который мог качнуть решение в сторону greenplum.
Что касается второй части вопроса. В целом выглядит как заявка на масштабный холивар, ещё и с основательной подготовкой.
disclaimer: Нам жаль, если мы своим комментарием задели чьи-то чувства к greenplum (если это так), но копаться сейчас в памяти и восстанавливать историю, чтобы потом получить в ответ что-то вроде “Ну так вы просто неправильно всё сделали!” — не хочется.
Делать всё то же самое не ради поспорить, а просто поделиться опытом — занятие бессмысленное, много воды уже утекло, системы меняются, то что могло раньше раздражать уже могли поправить.
До сих пор ни одно решение по хранению не позиционирует себя как silver bullet — всегда найдётся кейс, когда решение будет плохим, и вертика — не исключение.
Если есть интерес, мы можем подробней остановиться на тех фичах, которые нас привлекли к Vertica (а не оттолкнули от greenplum). И при этом постараемся обойтись без описания структур данных и конфигурации кластера.
Вышла накладочка, по смыслу надо читать не “в greenplum отсутствуют транзакции“, а в наших бизнес-процессах внесения данных в хранилище отсутствует OLTP нагрузка.
Причём тут транзакции? При том, что greenplum вполне себе позволяет хранить данные построчно, делая транзакционную нагрузку менее тяжёлой. Это был плюс, который мог качнуть решение в сторону greenplum.
Что касается второй части вопроса. В целом выглядит как заявка на масштабный холивар, ещё и с основательной подготовкой.
disclaimer: Нам жаль, если мы своим комментарием задели чьи-то чувства к greenplum (если это так), но копаться сейчас в памяти и восстанавливать историю, чтобы потом получить в ответ что-то вроде “Ну так вы просто неправильно всё сделали!” — не хочется.
Делать всё то же самое не ради поспорить, а просто поделиться опытом — занятие бессмысленное, много воды уже утекло, системы меняются, то что могло раньше раздражать уже могли поправить.
До сих пор ни одно решение по хранению не позиционирует себя как silver bullet — всегда найдётся кейс, когда решение будет плохим, и вертика — не исключение.
Если есть интерес, мы можем подробней остановиться на тех фичах, которые нас привлекли к Vertica (а не оттолкнули от greenplum). И при этом постараемся обойтись без описания структур данных и конфигурации кластера.
На всякий случай, в Greenplum есть транзакции (ACID + ANSI SQL). С нагрузкой тоже все ок, эксплуатируем очень жёсткие кластера по 20+ нод :)
Но Вертика тоже отличная система и у вас грандиозные планы, так держать!
странный подход. flume и kafka, spark и flink. нафига толкать в проект прямые аналоги? с ML тоже ощущение что натолкали все за что глаза зацепились. и spark ml и тензор и ignite ml с боку прилажен. причем судя по диаграмме план тащить данные из вертики в ml либы, хотя наиболее оптимально было бы на хадуп кластере внутри spark датафрейма дергать ml.
По Flume и Kafka — в целом да, в кафку сейчас можно любую функциональность запихнуть. Но с точки зрения эксплуатации и последующей разработки, мы их разделили, чтобы максимально упростить процесс изменений и контроля.
По Spark и Flink — если нам нужен микробатчинг или батчинг, то будем использовать Spark. Если нужна обработка в «реальном времени» — будем использовать Flink. Они все-таки немного разные, будем подбирать по задаче.
По ML — затолкнули все, что используют наши сайнтисты.
По Spark и Flink — если нам нужен микробатчинг или батчинг, то будем использовать Spark. Если нужна обработка в «реальном времени» — будем использовать Flink. Они все-таки немного разные, будем подбирать по задаче.
По ML — затолкнули все, что используют наши сайнтисты.
Сбор данных проводится из всех основных систем — 1С, SAP и куча всего остального. На основе собранных тут данных будет строиться вся аналитика, вся предиктивка, вся цифровая отчетность.
Вероятно еще данные берете из MES-системы СИБУР-а. Там одна из баз это БД Historian(Proficy Historian).
Я как-раз занимаюсь сейчас передачей данных в Historian с помощью коллекторов. Так вот у GE IP(Intelligent Platforms) есть множество вариантов работы с big daga. Есть такая платформа как Predix Platform, можете ее еще рассмотреть как вариант.
Спасибо за инфу! Задача такая есть. Решение Predix смотрели (их private cloud), думаем над использованием его подсистемы для переноса архивных данные Historian'а в Hadoop.
Historian HD provides big data capabilities on a Hadoop platform. Historian Analysis provides visualization of key equipment and process information in S95 model context. CSense analyzes and troubleshoots asset- and process-performance issues.
Я думаю что с Hadoop platform проблем не возникнет. Csense конечно бы прикрутить еще можно, но Predix его скора вытеснит.
А чем обусловлен выбор именно Tableu? Не рассматривали вариант PowerBI? В прошлом году анализировал возможное решение по BI, и с точки зрения критериев оценки (стоимость владения, требования входа), хотя в общем по функционалу решения ± одинаковые, за исключением того, что PowerBI поддерживает R и в скором времени, на скок знаю, будет поддержка Python.
По 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 жутко медленный.
Начали сравнивать, оказалось, что Tableau сильно впереди за счёт push-down в СУБД, наличия честного Live connect без ограничений, а также наличия уже известных практик impact анализа по отчётам (хоть и не в коробке продукта).
Ни Qlik Sense, ни PowerBI live connect’ом не порадовали. PowerBI ещё удивил наличием технических ограничений по объёму данных (кол-ву строк).
В принципе PowerBI развивается и мы видим, что MS выкатывает новые фичи. Но пока что нас не впечатлило.
Что касается поддержки R — в табло она уже очень давно есть. Есть также и поддержки других языков через embedding в R, что более эффективно для расчётов, потому что сам R жутко медленный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы строим систему обработки, хранения и анализа данных в СИБУРе