Блог компании Цифровой СИБУР
Хранение данных
Машинное обучение
Hadoop
Комментарии 29
+2
Привет, спасибо за сайтью. А как вы мониторите потоки данных в таком зоопарке? Как быстро узнаете и узнаете ли что какой-то из потоков отвалился?
0
Если честно, пока никак не мониторим.

Но планируем мониторить следующим образом по предыдущему опыту:
  • Логи всех потоков и elt процессов будем складывать в ELK
  • Метрики процессов будем складывать в Grafana (под ней скорее всего будет Clickhouse).
  • Критичные алерты будут сыпаться в Slack
  • При необходимости прикрутим Sentry и Moira сверху
  • Проверки качества данных тоже постараемся положить в ELK
0
А как используется Ignite ML Framework в этой системе? Немного неожиданно его видеть не в области хранения и обработки данных.
0
Присоединяюсь к этому вопросу, можно ли узнать больше деталей про эту часть?
+1
Думаю тут есть некая путаница. Мы сделали свой кастомный ML фреймворк, работающий на игнайте, который совпал по названию с Ignite ML Framework :) И поместили в раздел к ML инструментам, тк пока планируем его использовать только для машинки.

По факту, это фреймворк управления жизенным циклом моделей (ci\cd, исполнение, мониторинг), который использует часть нашей инфраструктуры для своей работы (Elastic, HDFS, YARN). В то же время источником данных для обучения и работы моделей выступает наша платформа.

Коллеги обещают сделать отдельную статью про этот фреймворк.
0
Да, путаница действительно возникла потому что у Ignite есть собственный модуль ML. Вот и показалось что речь о нем)
0
И кстати об Ignite ML, во встроенном фреймворке есть возможность импорта и инференса моделей. Это свежий функционал и возможно Вы его пропустили. Нет ли планов по использованию этого встроенного фреймворка?
0
Все-таки Ignite ML framework больше про алгоритмы, а наш фреймворк больше про жизненный цикл и управление моделями.
Мы внимательно следим за развитием Ignite ML framework. Возможно в будущем будем его использовать под нашим движком в качестве одного из способов исполнения алгоритмов.
0
А что именно Вы имеете ввиду под «жизненным циклом»? В данный момент во фреймворке есть поддерка как тренировки моделей самого Ignite, так и импорт, поддержка и хранение сторонних моделей (TensorFlow, XGBoost и Spark MLib, хотя последние две вещи будут в релизе 2.8, но уже есть в мастер бранче).
0
Создание, миграции моделей между разными средами, исполнение моделей и их мониторинг.
Многие вещи так или иначе уже есть в Ignite ML Framework, многие постепенно появляются, но на текущий момент целиком переехать на него не можем.
+1
Спасибо за статью. А не могли бы вы подробней рассказать о том как используется Ignite ML в вашем решении?
+1
Отвечу немного шире.

Мы специально сразу добавили в архитектуру реляционную MPP базу по следующим причинам:
  1. Для хранения агрегатов, небольшого горизонта детальных данных и витрин данных
  2. Как инструмент с меньшим порогом входа для пользователей. Многие знают только SQL.
  3. Как более простую подложку для BI инструментов


Почему именно Вертика (в основном выбирали между GreenPlum, ClickHouse и Exasol):
  1. GreenPlum отмели, тк не очень подходит по нагрузке, отсутвию транзакций. И есть мучительный опыт с ним.
  2. ClickHouse сыроват и пока может решать весь набор требуемых задач.
  3. Exasol — пока очень дорогой, требовательный к железу, проприетарная ОС, мало инфы и внедрений в России. Т.к. мы все равно немного Enterprise, решили не рисковать.
  4. Опять же низкий порог входа. У Вертики прекрасный оптимизатор, который спокойно переваривает самые глупые запросы.
  5. Есть базовые интеграции с используемым стеком (c Hadoop, Kafka, Spark).
  6. В команде большая экспертиза по Вертике. Есть опыт двух больших внедрений.
0
Можете сказать размер данных в Вертике? И денормализуете ли данные? И не смотрели ли MariaDB Column Store? Мы всё никак не выберем, ClickHouse — быстрый, но крикой SQL. Остальные стоят денег
0
Первоначально оценили данные в 50ТБ. Думаю, что за 1 год заполним.

Про нормализацию:
Витрины будем делать денормализованными. Детальный слой планируем строить на смеси DataVault и AnchorModelling.

Columnstore, если честно, даже не рассматривали как возможный вариант. Не помню точно что повлияло, но она даже в short-list не вошла.

Сейчас полистали. По обзорам и отзывам в интернете, этому проекту ещё предстоит развиваться. Но текущая документация как-то скудно описывает и архитектуру, и возможности по оптимизации хранения под определённые запросы. Например, управление сегментацией, pruning при чтении…

Иначе говоря, если бы встал вопрос сейчас, мы тоже бы не заинтересовались.
0
Я делал тестовый стенд на AnchorModelling, с помощью Spark данные нормализовал — получилось прикольно. Но ClickHouse и Columnstore не вывезли разворачивание по разным причинам. Потому пока остановились на ClickHouse и просто широкой таблице. А MemSQL не видели?
0
AnchorModelling тяжело ложится что на ClickHouse, что на Columnstore. В DataVault меньше джойнов, должно быстрее летать. В любом случае надо смотреть на частоту изменения модели данных и ее размеры в целом.

MemSQL не видели, спасибо, исследуем!
0
Странно. А какие транзакции отсутствуют в Greenplum? Можете описать структуры данных и конфигурации кластеров Greenplum, вызвавшие негативный опыт использования/тестирования?
0
Долго пытался понять, откуда “отсутствие транзакций” в greenplum взялось в нашем начальном ответе.

Вышла накладочка, по смыслу надо читать не “в greenplum отсутствуют транзакции“, а в наших бизнес-процессах внесения данных в хранилище отсутствует OLTP нагрузка.

Причём тут транзакции? При том, что greenplum вполне себе позволяет хранить данные построчно, делая транзакционную нагрузку менее тяжёлой. Это был плюс, который мог качнуть решение в сторону greenplum.

Что касается второй части вопроса. В целом выглядит как заявка на масштабный холивар, ещё и с основательной подготовкой.

disclaimer: Нам жаль, если мы своим комментарием задели чьи-то чувства к greenplum (если это так), но копаться сейчас в памяти и восстанавливать историю, чтобы потом получить в ответ что-то вроде “Ну так вы просто неправильно всё сделали!” — не хочется.

Делать всё то же самое не ради поспорить, а просто поделиться опытом — занятие бессмысленное, много воды уже утекло, системы меняются, то что могло раньше раздражать уже могли поправить.

До сих пор ни одно решение по хранению не позиционирует себя как silver bullet — всегда найдётся кейс, когда решение будет плохим, и вертика — не исключение.

Если есть интерес, мы можем подробней остановиться на тех фичах, которые нас привлекли к Vertica (а не оттолкнули от greenplum). И при этом постараемся обойтись без описания структур данных и конфигурации кластера.
0

На всякий случай, в Greenplum есть транзакции (ACID + ANSI SQL). С нагрузкой тоже все ок, эксплуатируем очень жёсткие кластера по 20+ нод :)
Но Вертика тоже отличная система и у вас грандиозные планы, так держать!

0
странный подход. flume и kafka, spark и flink. нафига толкать в проект прямые аналоги? с ML тоже ощущение что натолкали все за что глаза зацепились. и spark ml и тензор и ignite ml с боку прилажен. причем судя по диаграмме план тащить данные из вертики в ml либы, хотя наиболее оптимально было бы на хадуп кластере внутри spark датафрейма дергать ml.
+1
По Flume и Kafka — в целом да, в кафку сейчас можно любую функциональность запихнуть. Но с точки зрения эксплуатации и последующей разработки, мы их разделили, чтобы максимально упростить процесс изменений и контроля.

По Spark и Flink — если нам нужен микробатчинг или батчинг, то будем использовать Spark. Если нужна обработка в «реальном времени» — будем использовать Flink. Они все-таки немного разные, будем подбирать по задаче.

По ML — затолкнули все, что используют наши сайнтисты.
+1
Сбор данных проводится из всех основных систем — 1С, SAP и куча всего остального. На основе собранных тут данных будет строиться вся аналитика, вся предиктивка, вся цифровая отчетность.

Вероятно еще данные берете из MES-системы СИБУР-а. Там одна из баз это БД Historian(Proficy Historian).
Я как-раз занимаюсь сейчас передачей данных в Historian с помощью коллекторов. Так вот у GE IP(Intelligent Platforms) есть множество вариантов работы с big daga. Есть такая платформа как Predix Platform, можете ее еще рассмотреть как вариант.
+1
Спасибо за инфу! Задача такая есть. Решение Predix смотрели (их private cloud), думаем над использованием его подсистемы для переноса архивных данные Historian'а в Hadoop.
0
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 его скора вытеснит.
0
Csense сейчас используем для некоторых задач, но весь поток будем через Historian API забирать. С их Hadoop Platform есть одна проблема — он стоит приличное количество денег и только только появился.
0
А чем обусловлен выбор именно Tableu? Не рассматривали вариант PowerBI? В прошлом году анализировал возможное решение по BI, и с точки зрения критериев оценки (стоимость владения, требования входа), хотя в общем по функционалу решения ± одинаковые, за исключением того, что PowerBI поддерживает R и в скором времени, на скок знаю, будет поддержка Python.
0
По 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 жутко медленный.
Только полноправные пользователи могут оставлять комментарии., пожалуйста.