В начале 2018 года у нас активно пошел процесс цифровизации производства и процессов в компании. В секторе нефтехимии это не просто модный тренд, а новый эволюционный шаг в сторону повышения эффективности и конкурентоспособности. Учитывая специфику бизнеса, который и без всякой цифровизации показывает неплохие экономические результаты, перед «цифровизаторами» стоит непростая задача: всё-таки менять устоявшиеся процессы в компании — довольно кропотливая работа.

Наша цифровизация началась с создания двух центров и соответствующих им функциональных блоков.

Это «Функция цифровых технологий», в которую включены все продуктовые направления: цифровизация процессов, IIoT и продвинутая аналитика, а также центр управления данными, ставший самостоятельным направлением.



И вот как раз главная задача дата-офиса заключается в том, чтобы полноценно внедрить культуру принятия решений, основанных на данных (да, да, data-driven decision), а также в принципе упорядочить всё, что касается работы с данными: аналитика, обработка, хранение и отчетность. Особенность в том, что все наши цифровые инструменты должны будут не только активно использовать собственные данные, то есть те, которые генерируют сами (например, мобильные обходы, или датчики IIoT), но и внешние данные, с четким пониманием, где и зачем их нужно использовать.

Меня зовут Артем Данилов, я руководитель направления «Инфраструктура и технологии» в СИБУРе, в этом посте я расскажу, как и на чем мы строим большую систему обработки и хранения данных для всего СИБУРа. Для начала поговорим только о верхнеуровневой архитектуре и о том, как можно стать частью нашей команды.

Вот какие направления включает в себя работа в дата-офисе:

1. Работа с данными

Здесь трудятся ребята, которые активно занимаются инвентаризацией и каталогизацией наших данных. Они понимают, какие есть потребности у той или иной функции, могут определить, какого рода аналитика может понадобиться, какие метрики стоит отслеживать для принятия решений и как используются данные в определённой бизнес-области.

2. BI и визуализация данных

Направление тесно связано с первым и позволяет наглядно представить результат работы ребят из первой команды.

3. Направление контроля качества данных

Здесь внедряются инструменты контроля качества данных и проводится имплементация всей методологии такого контроля. Иными словами, ребята отсюда внедряют софт, пишут различные проверки и тесты, понимают, как происходят кросс-проверки между разными системами, отмечают функции тех сотрудников, которые отвечают за качество данных, а также налаживают общую методологию.

4. Управление НСИ

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

Когда компания что-то активно закупает для своей деятельности, у нее обычно есть специальные процессы заполнения этих справочников. В противном случае хаос достигнет такого уровня, что работать будет невозможно от слова «совсем». У нас такая система тоже есть (MDM).

Проблемы тут вот в чем. Допустим, в одном из региональных подразделений, которых у нас много, сидят сотрудники и вносят в систему данные. Вносят руками, со всеми вытекающими из такого способа последствиями. То есть им надо внести данные, проверить, что все доехало в систему в нужном виде, без дублей. При этом некоторые вещи, в случае заполнения каких-то реквизитов и обязательных полей, приходится вообще самостоятельно искать и гуглить. Например, есть у тебя ИНН компании, а тебе нужны остальные сведения — ты проверяешь через специальные сервисы и ЕГРЮЛ.

Все эти данные, конечно, уже где-то есть, поэтому было бы правильно их просто автоматически подтягивать.

Раньше в компании в принципе не было какой-то единой должности, четкой команды, которая бы этим занималась. Было множество разрозненных подразделений, вручную вносящих данные. Но таким структурам обычно сложно даже сформулировать, что именно и где именно в процессе работы с данными надо изменить, чтобы все было отлично. Поэтому мы пересматриваем формат и структуру управления НСИ.

5. Внедрение хранилища данных (узел данных)

Вот именно это мы и начали делать в рамках этого направления.

Давайте сразу определимся с терминами, а то используемые мной словосочетания могут пересекаться с какими-нибудь другими концепциями. Грубо говоря, узел данных = озеро данных + хранилище данных. Чуть дальше я раскрою это подробнее.

Архитектура


В первую очередь мы постарались прикинуть, с какими именно данными предстоит работать — какие тут есть системы, какие датчики. Поняли, что будут как потоковые данные (это то, что генерируют сами предприятия со всего своего оборудования, это IIoT и прочее) и классические системы, разные CRM, ERP и подобное.

Поняли, что данных в текущих системах будет не прямо чтобы совсем много по объему, но с внедрением цифровых инструментов и IIoT их станет очень много. А еще будут очень разнородные данные из классических учетных систем. Поэтому придумали архитектуру вот такого плана.



Далее подробнее по блокам.

Хранение




Это основное ядро нашей платформы. То, что используется для обработки и хранения данных. Задача — загружать данные более чем из 60 различных систем, когда они начнут их поставлять. То есть тут вообще все данные, которые могут пригодиться для принятия каких-то решений.

Начнём с извлечения и обработки данных. Для этих целей мы планируем использовать ETL-инструмент NiFi для потоковых и пакетных данных, а также инструменты для стриминговой обработки: Flume для первичного приема данных и их декодирования, Kafka для буферизации, Flink и Spark Streaming как основные инструменты обработки потоков данных.

Наиболее сложно работать с системами стэка SAP. Извлекать из SAP данные придётся с помощью отдельного ETL-инструмента — SAP Data Services.

В качестве инструментов хранения мы планируем использовать платформу Cloudera Hadoop (сам HDFS, HBASE, Hive, Impala), аналитическую СУБД Vertica и, для отдельных кейсов, elasticsearch.

В принципе, мы используем самый современный стэк. Да, нас можно попробовать закидать помидорами и поусмехаться над тем, что мы называем самым современным стэком, но на самом деле — так и есть.

Мы не ограничены legacy-разработкой, но при этом не можем использовать bleeding edge в промышленном решении из-за явной enterprise ориентированности нашей платформы. Поэтому, может, мы и не тащим Horton, а ограничиваемся Clouder’ой, там, где можно, мы обязательно пытаемся затащить более новый инструмент.



Для контроля качества данных используется SAS Data Quality, а Airflow для управления всем этим добром. Мониторинг всей платформы делаем через стек ELK. Визуализацию по большей части планируем делать на Tableau, какие-то совсем статичные отчеты на SAP BO.

Уже сейчас понимаем, что часть задач невозможно реализовать через стандартные BI-решения, так как требуется совсем изощренная визуализация в реальном времени с множеством картонных контролов. Поэтому будем писать свой фреймворк визуализации, который можно было бы встраивать в разрабатываемые цифровые продукты.

Про цифровую платформу


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

Озеро данных — один из элементов этой платформы.
В рамках этой активности мы понимаем, что нам потребуется реализовать удобный интерфейс доступа к аналитическим данным. Поэтому в планах реализовать Data API и объектную модель производства для более удобного доступа к производственным данным.

Что еще делаем и кто нам нужен


Кроме хранения и обработки данных на нашей платформе будет работать всё машинное обучение, а также IIoT-фреймворк. Озеро будет выступать и как источник данных для обучения и работы моделей, и как мощности для работы моделей. Уже сейчас готов ML-фреймворк, который будет работать поверх платформы.



Прямо сейчас в команде есть я, пара архитекторов и 6 разработчиков, поэтому мы активно ищем новых людей (мне нужны архитекторы данных и дата-инженеры), которые помогут нам с развитием платформы. Ковыряться в легаси не придётся (легаси тут только на входе от систем), стэк свежий.



Вот где будут тонкости — так это в интеграциях. Связывать старое с новым, да так, чтобы оно все нормально работало и решало задачи — это вызов. Кроме этого, надо будет придумывать, прорабатывать и навешивать кучу самых разных метрик.

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

Если совсем коротко, ты мы хотим сделать так, чтобы работать с данными стало по-настоящему круто. Вот, например, маркетинг и продажи — у них есть люди, которые собирают всю статистику руками. То есть сидят и из 5 разных систем выкачивают разрозненные данные в разных форматах, загружают их из 5 разных программ, потом выгружают себе в эксель все это считать. Потом сводят информацию в единые экселевские таблицы, как-то пытаются делать визуализацию.

В общем, времени уходит вагон на все это. Подобные проблемы мы и хотим решить нашей платформой. А в следующих постах подробно расскажем о том, как мы связывали элементы между собой и настраивали корректную работу системы.

Кстати, кроме архитекторов и дата-инженеров в этой команде мы будем рады видеть:

Комментарии (25)


  1. HDDimon
    21.01.2019 14:11
    +1

    Привет, спасибо за сайтью. А как вы мониторите потоки данных в таком зоопарке? Как быстро узнаете и узнаете ли что какой-то из потоков отвалился?


    1. Izayda Автор
      22.01.2019 12:47
      +1

      Если честно, пока никак не мониторим.

      Но планируем мониторить следующим образом по предыдущему опыту:

      • Логи всех потоков и elt процессов будем складывать в ELK
      • Метрики процессов будем складывать в Grafana (под ней скорее всего будет Clickhouse).
      • Критичные алерты будут сыпаться в Slack
      • При необходимости прикрутим Sentry и Moira сверху
      • Проверки качества данных тоже постараемся положить в ELK


  1. dmitrievanthony
    21.01.2019 17:31

    А как используется Ignite ML Framework в этой системе? Немного неожиданно его видеть не в области хранения и обработки данных.


    1. chiefy
      22.01.2019 12:23

      Присоединяюсь к этому вопросу, можно ли узнать больше деталей про эту часть?


    1. Izayda Автор
      22.01.2019 12:51
      +1

      Думаю тут есть некая путаница. Мы сделали свой кастомный ML фреймворк, работающий на игнайте, который совпал по названию с Ignite ML Framework :) И поместили в раздел к ML инструментам, тк пока планируем его использовать только для машинки.

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

      Коллеги обещают сделать отдельную статью про этот фреймворк.


      1. chiefy
        22.01.2019 12:55

        Да, путаница действительно возникла потому что у Ignite есть собственный модуль ML. Вот и показалось что речь о нем)


        1. chiefy
          22.01.2019 13:02

          И кстати об Ignite ML, во встроенном фреймворке есть возможность импорта и инференса моделей. Это свежий функционал и возможно Вы его пропустили. Нет ли планов по использованию этого встроенного фреймворка?


          1. Izayda Автор
            22.01.2019 14:43

            Все-таки Ignite ML framework больше про алгоритмы, а наш фреймворк больше про жизненный цикл и управление моделями.
            Мы внимательно следим за развитием Ignite ML framework. Возможно в будущем будем его использовать под нашим движком в качестве одного из способов исполнения алгоритмов.


            1. chiefy
              22.01.2019 14:50

              А что именно Вы имеете ввиду под «жизненным циклом»? В данный момент во фреймворке есть поддерка как тренировки моделей самого Ignite, так и импорт, поддержка и хранение сторонних моделей (TensorFlow, XGBoost и Spark MLib, хотя последние две вещи будут в релизе 2.8, но уже есть в мастер бранче).


              1. Izayda Автор
                23.01.2019 17:03

                Создание, миграции моделей между разными средами, исполнение моделей и их мониторинг.
                Многие вещи так или иначе уже есть в Ignite ML Framework, многие постепенно появляются, но на текущий момент целиком переехать на него не можем.


  1. AplatonoVV
    21.01.2019 17:31
    +1

    Спасибо за статью. А не могли бы вы подробней рассказать о том как используется Ignite ML в вашем решении?


    1. Izayda Автор
      22.01.2019 13:01
      +1

      Ответил вот здесь :)


  1. pe4albka
    21.01.2019 17:31

    Почему в качестве ХД решили вертику использовать?


    1. Izayda Автор
      22.01.2019 12:59
      +1

      Отвечу немного шире.

      Мы специально сразу добавили в архитектуру реляционную MPP базу по следующим причинам:

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


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


      1. TimonKK
        22.01.2019 22:09

        Можете сказать размер данных в Вертике? И денормализуете ли данные? И не смотрели ли MariaDB Column Store? Мы всё никак не выберем, ClickHouse — быстрый, но крикой SQL. Остальные стоят денег


        1. Izayda Автор
          23.01.2019 17:05

          Первоначально оценили данные в 50ТБ. Думаю, что за 1 год заполним.

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

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

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

          Иначе говоря, если бы встал вопрос сейчас, мы тоже бы не заинтересовались.


          1. TimonKK
            23.01.2019 17:33

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


            1. Izayda Автор
              23.01.2019 17:53

              AnchorModelling тяжело ложится что на ClickHouse, что на Columnstore. В DataVault меньше джойнов, должно быстрее летать. В любом случае надо смотреть на частоту изменения модели данных и ее размеры в целом.

              MemSQL не видели, спасибо, исследуем!


  1. Yo1
    22.01.2019 09:00

    странный подход. flume и kafka, spark и flink. нафига толкать в проект прямые аналоги? с ML тоже ощущение что натолкали все за что глаза зацепились. и spark ml и тензор и ignite ml с боку прилажен. причем судя по диаграмме план тащить данные из вертики в ml либы, хотя наиболее оптимально было бы на хадуп кластере внутри spark датафрейма дергать ml.


    1. Izayda Автор
      22.01.2019 13:16
      +1

      По Flume и Kafka — в целом да, в кафку сейчас можно любую функциональность запихнуть. Но с точки зрения эксплуатации и последующей разработки, мы их разделили, чтобы максимально упростить процесс изменений и контроля.

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

      По ML — затолкнули все, что используют наши сайнтисты.


  1. AntonAK83
    22.01.2019 11:12

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

    Вероятно еще данные берете из MES-системы СИБУР-а. Там одна из баз это БД Historian(Proficy Historian).
    Я как-раз занимаюсь сейчас передачей данных в Historian с помощью коллекторов. Так вот у GE IP(Intelligent Platforms) есть множество вариантов работы с big daga. Есть такая платформа как Predix Platform, можете ее еще рассмотреть как вариант.


    1. Izayda Автор
      22.01.2019 13:26
      +1

      Спасибо за инфу! Задача такая есть. Решение Predix смотрели (их private cloud), думаем над использованием его подсистемы для переноса архивных данные Historian'а в Hadoop.


      1. AntonAK83
        23.01.2019 06:41

        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 его скора вытеснит.


        1. Izayda Автор
          23.01.2019 17:06

          Csense сейчас используем для некоторых задач, но весь поток будем через Historian API забирать. С их Hadoop Platform есть одна проблема — он стоит приличное количество денег и только только появился.


  1. StrangeBelk
    24.01.2019 10:47

    А чем обусловлен выбор именно Tableu? Не рассматривали вариант PowerBI? В прошлом году анализировал возможное решение по BI, и с точки зрения критериев оценки (стоимость владения, требования входа), хотя в общем по функционалу решения ± одинаковые, за исключением того, что PowerBI поддерживает R и в скором времени, на скок знаю, будет поддержка Python.