Nedra Digital: единый язык для нефтегазового рынка

Несмотря на то, что в последнее время нефтегазовая область существенно продвинулась в применении передовых информационных технологий, участники отечественного нефтегазового рынка все еще разговаривают между собой на разных «цифровых» языках, единые стандарты по обмену информацией до сих пор отсутствуют. Решить эту проблему призвана платформа данных разведки и добычи Nedra.DATA. О ее создании рассказывает Алексей Щербич, директор по индустриальным решениям Nedra Digital и номинант на премию Data Award.

- Какую задачу вы решаете с помощью созданной платформы?

Область разведки и разработки нефтегазовых месторождений (Upstream) характеризуется большим разнообразием специализированных цифровых форматов, которые практически не используются в других индустриях, что накладывает дополнительную сложность на стандартизацию подходов к работе с такими данными в рамках централизованных систем управления данными. Еще одной отличительной характеристикой является их вариативность в объемах и частоте появления по мере продвижения по так называемому «конвейеру Upstream». Так, например, отдельные специализированные файлы с результатами сейсморазведочных работ могут достигать объемов в сотни гигабайт, но частота их появления носит «сезонный» характер. В то же время, данные реального времени в процессе бурения скважин или параметры добычи, которые поступают со скважин и объектов трубопроводной сети, хоть и не являются крупными по объему, но поступают с очень высокой дискретностью (некоторые ежесекундно) по специализированным real-time протоколам.

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

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

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

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

- То есть игрокам рынка нужен единый язык?

В контексте индустрии Upstream платформа данных имеет очень предметно-ориентированную отраслевую специфику. Сегодня очевидно, что участники отечественного нефтегазового рынка действительно разговаривают между собой на разных «цифровых» языках, у них отсутствуют единые стандарты по обмену информацией, до сих пор в наличии большое количество проприетарных разработок, способов хранения информации, методов принятия data-driven решений. Заказчик и подрядчик зачастую работают в различных цифровых инструментах, между ними отсутствует единая цифровая среда коммуникации с единым «прозрачным» слоем данных. Аналогичные проблемы возникают и в коммуникациях между государственными структурами и нефтегазовыми компаниями. В силу того, что не достигается оптимальная скорость поставки данных и их прозрачность, методы обработки являются закрытыми на многих стадиях, а сами данные хранятся децентрализованно – возникает серьезная проблема итоговой накопленной ошибки, которая очень «огрубляет» финальное управленческое решение.

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

- Какие принципы пытались заложить в платформу Nedra.DATA?

Ключевой принцип – сокращение затрат на интеграцию специализированных данных и возможность формирования единой среды данных для работы нефтесервиса, недропользователей и государственных структур. С технической точки зрения можно выделить несколько моментов. Во-первых, это поддержка открытых стандартов хранения и трансфера Upstream данных, а также работы со специализированными форматами данных и системами хранения. Во-вторых, важна поддержка динамически формируемой онтологии данных: No-Code конструктор моделей данных, совместимость онтологии данных с LLM-сервисами и динамическое подключение внешних источников данных, их бесшовная интеграция в онтологическую модель. Активно обсуждаемая тема в последнее время – гибко настраиваемые дата-контракты для систем-поставщиков и систем-потребителей информации в платформе. Наконец, мониторинг качества данных и интегрируемость платформы с корпоративными системами нормативно-справочной информации.

- На чем основан опыт при создании платформы?

Начиная с 2003 года я лично занимался разработкой крупномасштабных продуктов, целью которых являлось повышение качества и скорости принятия технических и управленческих решений, основанных на специализированной нефтепромысловой информации. Говоря проще, создавал банки данных нефтегазовой информации, которые работали как в масштабах отдельных компаний, так и в государственных. Мой опыт складывается из знаний и личного опыта разработки и внедрения платформ данных разведки и добычи в российских и зарубежных компаниях. В компаниях CGG, Halliburton, Nedra Digital я прошел путь от математика-программиста до директора бизнес-подразделения по разработке продуктов в области управления Upstream-данными. За все это время сложилось понимание как технической, так и бизнес-проблематики, отчетливое представление о передовых рыночных продуктах, их преимуществах и недостатках. Поэтому при создании Nedra.DATA я ориентировался как на собственный опыт, так и на опыт коллег-единомышленников со схожими взглядами на методику построения крупномасштабных продуктов по управлению данными разведки и добычи.

- Какие технологии легли в основу созданной платформы?

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

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

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

Основные потери, которые возникают по мере прохождения данных от момента их получения до момента принятия управленческого решения, возникают на стыке работы смежных функциональных команд. На примере цепочки Upstream это можно проиллюстрировать как взаимодействие команд геологоразведки, геологии и моделирования, бурения и строительства скважин, эксплуатации и добычи. Команды почти всегда существуют в своих «информационных колодцах» со своими принятыми форматами хранения и передачи данных и общими принципами работы, которые слабо согласуются с внутренними стандартами и принципами смежной команды. В результате функциональная команда львиную долю времени тратит не на решение задач своей узкой доменной области, а на сбор и приведение в порядок исходных данных, без которых попросту не может начать свою работу. По разным оценкам (см. схему), эти потери могут составлять от 30% до 60% времени работы всей команды.

Принимая во внимание озвученные выше выводы, следует отметить еще один факт. На момент начала разработки на рынке начал быстро набирать популярность подход к управлению данными, заявленный сообществом Open Subsurface Data Universe (OSDU). Некоторые отечественные компании даже успели поучаствовать в этом сообществе. OSDU предложил объединить усилия нефтесервисных компаний-производителей ПО и нефтяных компаний для создания полностью открытого стандарта управления данными разведки и добычи, а также полностью открытого конечного продукта, построенного на принципах open source. Не учесть этих привлекательных особенностей, которые уже заинтересовали нашу целевую аудиторию, мы просто не могли.

Таким образом, возвращаясь к вопросу о технологиях, на которых построен продукт Nedra.DATA, выделим некоторые особенности. Прежде всего, это открытый архитектурный стек, построенный на надежных и пользующихся популярностью компонентах. Следуя идее OSDU об открытости, в том числе и исходного кода для полномасштабной совместной разработки, мы ориентировались как на архитектурные open source компоненты, так и на открытый исходный код, который производится нашей командой разработки. Первые два релиза платформы все еще доступны в открытом виде. Поскольку отклика на совместную разработку мы в ожидаемых масштабах на рынке не получили, далее мы сфокусировались на разработке наиболее привлекательных коммерческих «фичей» продукта. Поэтому и архитектура в процессе внедрений претерпевала некоторые изменения для удовлетворения требований информационной безопасности и адресных функциональных требований заказчиков. Однако от принципа открытости мы не отказались, а лишь отложили его до момента, когда сможем собрать серьезную инициативную группу компаний.

Кроме открытого архитектурного стека, отметим реализованную идею децентрализованного подхода к управлению данными в платформе, которая построена на основе принципа Data Mesh. Набор функциональных сервисов в Nedra.DATA, в том числе, ориентирован и на реализацию этой идеи, которую коротко можно охарактеризовать тремя основными составляющими: domain-driven архитектура, сервисы самообслуживания в платформе, управление данными как продуктом.

Раскрывать сам подход, полагаю, в рамках этого интервью нецелесообразно, он подробно проиллюстрирован в открытых источниках. Коротко скажу лишь о том, зачем мы решили его использовать. Я уже отмечал выше, что одна из ключевых проблем, которую призвана решить индустриальная платформа – это сокращение транзакционных издержек на стыке работы смежных функциональных групп. Проще говоря – обеспечить «соседние» команды эффективными инструментами подготовки и интеграции данных. Платформа в этом случае становится единым стандартом поставки и обмена данных для всех поставщиков и потребителей, а сами поставщики и потребители пользуются сервисами платформы для того, чтобы результаты работы одной команды могли быть бесшовно переиспользованы всеми заинтересованными потребителями. Таким образом, децентрализованный подход на основе Data Mesh упрощает возможность реализации очевидного принципа работы с данными в мультикомандной среде: всякие порожденные одной командой данные бессмысленны, если ими не пользуется ни одна из соседних команд.

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

- Из каких основных частей состоит платформа?

Платформа Nedra.DATA ориентирована на реализацию всех ключевых направлений работы с данными, которые представлены в методологическом пособии DAMA-DMBOK. Нет смысла их перечислять, специалистам по управлению данными они все хорошо известны. Однако мы говорим о том, что создаем именно предметно-ориентированную индустриальную дата-платформу. А значит, помимо классических задач управления данными она должна быть ориентирована на индустриальную проблематику.

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

Разрозненность форматов данных, используемых в нефтегазовой области, привносит требования к платформе в части «парсинга» таковых форматов и создания процедур трансформации данных для приведения в канонический вид. На сегодня в платформе запланирована поддержка более 80 различных типов данных индустриальных форматов: файловые данные, специализированные отраслевые базы данных, транспортные форматы и пр. Серьезно стоит вопрос бизнес-аналитики, в котором дата-платформа должна помочь подготовить из всего многообразия данных быстрые информационные слои для использования в BI-инструментах.

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

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

- Какими инструментами и подходами обеспечивается качество данных?

Подход к контролю качества данных мы разделяем на несколько логических этапов: экспертный контроль специализированными методами в прикладном ПО, технический контроль на входе в платформу, технический контроль после поступления в платформу. Первый этап опосредованно относится к платформе, т.к. проводится экспертами в тех программных продуктах, которые используются для узких доменных задач. Например, ПО для обработки данных сейсморазведки позволяет оценить качество первичного полевого сейсмического материала. Второй этап контроля качества позволяет определить очевидный брак на момент поступления данных в платформу. Это могут быть элементарные проверки на физичность поступающих параметров, дубликаты данных, проверки на полноту входных датасетов. Что касается контроля качества на третьем этапе, то для этих целей мы занимаемся разработкой специализированного сервиса, который по выбранному профилю данных позволяет сформировать комплекс проверок, осуществляющих технический контроль за выбранной группой данных. Репозиторий проверок создается дата-инженерами в связке с экспертами через NoCode инструменты. Что касается специфики самих проверок, то в целом методологически она соответствует рекомендациям DAMA-DMBOK. Идея в том, чтобы по отдельным доменным областям знаний пользователь (в широком смысле) мог самостоятельно наработать необходимую ему для дальнейшей работы базу проверок или воспользоваться ранее созданной, которая уже попала в реестр.

- Что получилось особенно удачно?

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

В самом начале мы говорили об открытости как об одном из ключевых запросов пользователей. Все структуры данных, поступающих в платформу, понятны и хранятся в привычных для пользователей стандартах, все процессы преобразования данных прозрачны, архитектурные компоненты – открыты. Дата-контракты, которые используются для приемки и выгрузки данных в платформе, описаны на простых языках сериализации (AVRO или JSON), более того – сами поставщики имеют возможность описать структуры данных, передаваемых ими в платформу.

Особенно удачно удалось приспособить платформу под решение интеграционных задач. Проблема семантической интероперабельности, о ней мы еще не говорили, то есть неоднозначной интерпретации одних и тех же данных в разных информационных системах из-за различного контекста, в больших организациях – один из ключевых барьеров в построении интегрированных сред. В платформе Nedra.DATA построен сервис управления онтологиями данных, позволяющий эту проблему разрешать динамически. Можно проиллюстрировать логику формирования единой модели через многослойную архитектуру хранилища, управляемую единой динамически формируемой онтологической моделью (доменной моделью данных).

- Что можно считать главной особенностью платформы?

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

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

- Каковы успехи? Платформа востребована рынком?

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

- В каком направлении будет развиваться проект?

Направлений много, скажем лишь о некоторых из них. Сегодня в отрасли просматривается очевидный тренд на построение цифровых двойников отдельных доменных процессов и производственных объектов. Еще не до конца очевидно, каков будет необходимый и достаточный перечень элементов архитектуры и бизнес-функций в цифровых двойниках (горячие дискуссии на этот счет до сих пор ведутся), но в чем нет сомнений – так это в том, что каждый цифровой двойник требует наличия качественно организованного слоя данных. Как можно заметить (см. схему), платформа Nedra.DATA в это требование очень органично вписывается. Слой данных как составная часть цифрового двойника должен обязательно «уметь» интегрировать данные из множества систем-источников, снимать проблематику противоречивости данных в этих источниках, формировать единую онтологию данных цифрового двойника, следить за качеством интегрированных данных, обеспечивать функции поиска, предоставлять различные средства доступа к хранимым данным. Все эти функции в Nedra.DATA представлены. Безусловно, каждый цифровой двойник будет иметь массу особенностей с точки зрения работы с исходными данными, способов их интеграции, и в Nedra.DATA для этих целей необходимо будет привносить индивидуальные изменения, однако принципиально архитектурно и функционально продукт готов к решению подобных задач.

Цифровые двойники сами по себе – платформенные решения, где платформа данных является одним из функциональных компонентов. Поскольку цифровой двойник призван виртуализировать множество процессов, которые происходят в реальном производстве, то для этих целей информационные источники, инженерные и бизнес-сервисы, сами пользователи и другие «участники» этих процессов должны быть объединены едиными управляющими движками – так называемыми бизнес-оркестраторами. Вопрос того, как именно управлять бизнес-логикой – с помощью оркестрации или хореографии – зачастую дискуссионный, но необходимость наличия такого управляющего слоя в двойнике признается почти всеми. Поэтому перед платформой данных стоят задачи обеспечения потенциальных оркестраторов данными в необходимых форматах, объемах и с требуемой частотой.

Еще раз напомню о том, что в рамках платформенных подходов активно внедряются основанные на LLM-компоненты. Это тоже объективная реальность для нас, поэтому Nedra.DATA и LLM-сервисы уже становятся единым целым. Этими задачами мы прямо сейчас активно занимаемся.

Напоследок хочу напомнить о том, что успех OSDU стал возможным не благодаря одному успешному вендору, который разработал концепцию, предложил подходы к стандартизации, а именно через объединение множества разработчиков – представителей нефтесервиса и недропользователей. И если мы действительно испытываем необходимость в коммуникации на едином «нефтегазовом языке», а я об этом дефиците уже упоминал в самом начале разговора, то без объединения усилий единолично создать такой отечественный стандарт одной команде или даже одной компании почти невозможно. К этому объединению мне и хотелось бы призвать.