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

В небольшом цикле из двух статей мы разберём опыт СИБУРа в создании, поддержке и развитии DQ (Data Quality — качество данных) сервиса для DWH (Data Warehouse — хранилище данных) в условиях санкций и исчезающих вендоров проверенных и привычных решений.

Рассказывать об этом опыте будет Александр Бергер, Lead DQ Analyst в Цифровом СИБУРе, которому посчастливилось лидить процесс создания DQ-сервиса на решениях вендора, который решил покинуть рынок РФ в разгар рабочего процесса.

Что такое Data Quality?

Если вкратце, то DQ-сервис — это набор инструментов для проверки качества данных, поступающих в хранилище, передающихся между слоями хранилища или уже хранящихся в DWH.

Качество данных необходимо проверять, чтобы понимать, можно тем или иным данным доверять или нет — это критично, потому что на основе этих данных принимаются управленческие решения и цена ошибки в этом процессе очень высока, особенно в промышленном секторе, ярким представителем которого и является компания СИБУР.

В производственных процессах в СИБУРе повсеместно задействованы современные информационные технологии, и в наших производственных контурах постоянно генерируются данные — оборудование, датчики, всевозможные автоматизации, IoT — отправляют данные 24/7, которые нужно передавать, собирать, обрабатывать, хранить.

СИБУРу важно следить за качеством данных, от этого зависит рентабельность бизнеса. Поэтому компания выделяет ресурсы на развитие DQ-сервиса для DWH.

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

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

Срочное импортозамещение

До широко известных событий 2022 мы строили DQ на SAS Data Quality. На SAS у нас был выстроен процесс проверки качества данных, мы определили зоны ответственности и планировали начать процесс обучения коллег из бизнеса взаимодействию с сервисом. Проверки поступающих данных настраивались инженером качества над Vertica. И к февралю мы начали внедрение SAS Decision Management — инструмента для self-service проверок качества данных.

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

Анализ рынка

Первое, с чем мы столкнулись, — отсутствие готовых коммерческих отечественных решений на рынке РФ для нашего стека. Поэтому назвать то, что мы делали, «импортозамещением» можно с оговорками: мы замещали, да, но не отечественными решениями, а тем, чем могли.

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

Первые шаги

Мы провели анализ рынка, и самым подходящим под наши потребности решением оказалась опенсорсная библиотека Great Expectations (GX), которая сделана на Python.

Достоинства GX, важные для нас:

• Есть множество кастомных проверок.

• Высокая степень гибкости настроек и сценариев.

• Достаточно живое комьюнити.

• Бесплатный доступ.

Взвесив все за и против, мы сделали выбор в пользу GX.

И сразу на грабли

У нас уже была команда, которая разрабатывала каталог данных. И мы начали разработку DQ-инструмента как микросервиса для каталога данных. Но не своими силами, а привлекли подрядчиков.

СИБУР, как большая компания, может себе позволить иметь отдельную команду, чтобы развивать собственные сервисы. Но в условиях хаоса мы приняли решение привлечь подрядчиков с релевантным опытом.

С нашей стороны, как сейчас уже понятно, было ошибкой отдавать разработку микросервиса на аутсорс. Нет, они всё хорошо разработали, но подрядчики рано или поздно заканчиваются, и нам пришлось попрощаться с ними.

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

Однако неприятности на этом не закончились. И если историю с подрядчиками можно отнести в категорию рисков, которые мы осознавали и оценивали как «Возможные» при принятии решения, то события, которые развернулись дальше, мы отнесли в категорию «Вряд ли такое может произойти».

Чистый Open Source или форк

Дело в том, что в работе с Open Source библиотеками есть нюансы, связанные с обновлениями. В целом это классическая история с опенсорсными решениями, что они тоже развиваются (обнаруживаются различные уязвимости в безопасности, архитектурные недочёты).

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

Никогда такого не было, и вот опять

В какой-то момент мы обнаружили, что в новых версиях GX отвалилась поддержка Vertica и Oracle, а это для нас критично. И на множество вопросов «Когда это всё закончится?» они перестали отвечать, потому что сфокусировались на развитии своего облачного продукта, который будет распространяться по подписке.

То есть перед нами возникла дилемма:

1. Пользоваться старой версией GX, в которой есть поддержка нужных нам решений.

2. Делать форк и оптимизировать его под наши нужды.

3. Искать замену.

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

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

Выбор решения

Мы начали анализировать, что есть на рынке. Снова. Пообщавшись с коллегами из других компаний, поняли, что мы не одиноки в истории с GX и проблемы у нас похожие.

В России пользуется популярностью Arenadata Catalog, он в плане написания проверок качества данных тоже базируется на GX. И его разработчики пошли по второму пути — сделали форк. Но у них компания, которая заточена на разработку каталога и проверок качества данных. А у нас немного другой профиль.

И так как в решениях на базе Great Expectations теперь нет поддержки Vertica и Oracle, нам они, как уже упоминалось выше, не подходят. Поэтому мы начали анализировать другие популярные решения.

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

Soda vs Great Expectations

В нашу выборку попал DQ-инструмент SODA — это Open Source. Мы проанализировали SODA, сравнили c GX и подумали, что он будет лучше. Потому что его проще поддерживать, он подключается к Vertica и Oracle — а это то, что нам нужно.

В SODA нет проблем с подключениями, потому в GX идёт подключение с помощью SQLAlchemy, а в SODA по-другому — отдельные коннекторы написаны.

В общем, протестировали, проанализировали, посоветовались с коллегами в других компаниях и поняли, что многие переключаются на работу с SODA. Там активное комьюнити, люди пользуются, проблем нет.

Вместо заключения

Наше текущее положение можно увидеть на этом графике. Он шуточный, но, кажется, в нём есть доля правды. Чем больше опыта ты набираешься в работе с данными, тем больше приходишь к тому, что проверки SQL-скриптами и разработка собственного DQ-инструмента с нуля выглядят более правильно.

Риски использования Open Source есть и никуда не денутся, в чём мы убедились на собственном опыте, когда разработчик:

1. убрал нужную нам функциональность;

2. ушёл в сторону платной модели.

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

Сейчас мы занимаемся миграцией с GX на SODA, так как этот вариант нам подошёл больше всего. Но и здесь сохраняются риски: разработчик может перестать поддерживать это решение, что-то может отвалиться либо переведено в какую-то платную подписку, а мы её купить не сможем, потому что мы в России.

Также не стоит забывать, что SODA разрабатывает компания, которая находится на Западе. И мы снова можем оказаться в затруднительном положении. Если такое случится, будем искать что-то на нашем рынке либо разрабатывать своё решение.

Но разработка собственного решения не выглядит привлекательной идеей для нас, как и для многих других компаний. Поэтому сейчас единственное, что остаётся, — это внедрять продукты с открытым исходным кодом.

Подводя итоги по импортозамещению, можем сказать, что мы сделали всё возможное, чтобы не столкнуться с историей, когда у нас что-то отвалится и придётся всё резко переделывать. По крайней мере, старались организовать архитектуру именно таким образом. Мы выстраиваем многослойный DWH на Open Source стеке, внедряем туда Data Quality инструменты — тоже на базе опенсорсных решений.

Концепцию и архитектуру нашего DQ-решения, которое можно применить в любой компании, обсудим в следующей статье. Если есть какие-то вопросы по этой теме — ждём в комментариях.