И в области баз и банков геолого-геофизических и промысловых (ГГиП) данных все примерно так же скучно. Как видно из исследований Deloitte Digital нефтяники, горняки и водители больших грузовиков далеки от больших взрывов. Новые базы и хранилища создаются, но практически всегда для обеспечения функционала работы с данными для того, или иного приложения. Системы организации и хранения данных, созданные целевым образом под организацию и хранение, ждет суровая действительность. Они выпадают из бизнес процесса, вращающегося вокруг прикладных систем обработки, интерпретации и моделирования. В связи с этим данные продолжают накапливаться в прикладных базах, обтекают специализированные системы и удобно рассаживаются по Excel таблицам и файловым папкам, в лучшем случае корпоративным и централизованным (если такой ресурс предоставлен пользователям).

Основной направляющей новых систем хранения и организации данных является, на наш взгляд, их отличная от реляционной структура. Исторически сложилось так, что все задачи организации данных были решены при помощи реляционного моделирования в силу доминирующей позиции реляционных инструментов на рынке. Ситуация поменялась, и неэффективность применения реляционных технологий во множестве архивных (write once read many) систем стала очевидной.

Если отбросить уже, наконец, иллюзии об одном «всесильном кольце», что объединит их навек, остается принять, что этот набор географически распределенных прикладных баз разного толка, файловых систем и таблиц — это и есть наша база данных. Умеренно распределенная, исключительно гетерогенная, слабо связанная база данных, с которой нам предстоит учиться работать потому, что вышеупомянутые ее характеристики в силу особенностей бизнеса в ближайшее десятилетие вряд ли изменятся. Как говорил Нил МакНотан, один из немногих систематических исследователей в области управления ГГиП данными: «Работа в проектах - есть ограниченность. Мы вынуждены обрезать данные в проект только по той причине, что не можем пока поработать со всеми данными сразу» (вольная цитата).

Итак, оставив попытки глобально систематизировать процесс накопления данных (все загружать!) и оставив заботу об их ремастеринге, обеспечении целостности, резервном копировании и защите от природных катастроф специалистам ДИТ — нам остается всего одна забота: доступ! Но это существенная забота, ведь доступ - это не только физическая передача и скорость, это и разграничения и права, достоверность и известный уровень качества, структурирование информации как предварительное, так и в соотвествии с запросом и т.д.

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

Интерфейсы со значительным количеством систем. Даже в случае, когда интерфейс только на чтение – задача нетривиальная. Системы меняются как точки зрения ИТ инфраструктуры, так и с точки зрения моделей данных (например с новыми версиями). Разграничение доступа у многих систем сугубо индивидуально. Соответственно, системе, поддерживающей постоянные, даже самые простые интерфейсы с большим количеством других систем, нужна непрерывная поддержка этих интерфейсов. Затраты и непрерывный цикл разработки.

Push или Pull интерфейсы? С точки зрения характера интерфейсов сложно расчитывать на то, что сторонние системы будут подготавливать и транслировать данные вовне (даже если разработчики это декларируют) — это не входит в их функциональные обязанности. Соответственно, преимущественно интерфейсы/агенты платформы инструмента доступа будут отвечать за извлечение данных из сторонних систем.

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

Кэширование и обратный индекс. Практика показывает, что в системе, поставившей себя в полную зависимость от других систем по части запросов (а так зачастую и организованы классические системы доступа типа портала) есть две существенные проблемы:
a. Производительность — сторонние системы обрабатывают запрос с непредсказуемой производительностью, иногда крайне медленно.
b. Надежность — при большом количестве подключенных систем в любой промежуток времени одна или несколько из них обязательно испытывают сбои и не могут ответить на запрос.
Единственный способ победить эти недуги — глубокое индексирование информации и эффективная работа с индексом.

Разграничение доступа. Доступ к данным необходимо разграничить. Не все ИТ системы организуют разграничение доступа единообразно. В связи с этим для некоторых систем необходимо хранение или восстановление и постоянное обновление связи внутренних пользователей с пользователями и группами корпоративного домена.

Связь с НСИ. Качество. При подключении большого количества данных из большого количества систем мы неизбежно сталкиваемся с проблемами достоверного определения актуальности и качества данных. Любой пре и пост-процессинг данных, в том числе когнитивные инструменты, которые помогут нам достоверно определять актуальность и качество данных, полученных в ответ на запрос — востребованы! Интересно, что качество является функцией использования, а не наоборот. Данные качественные там, где их постоянно кто-то использует. Лучшая база данных с самыми качественными данными пролежавшая 10 лет невостребованной таит в себе много сюрпризов.

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

Завершить этот маленький очерк хочется параграфом, наполненным ключевыми словами. DevOps специализация — ее развитие в компании требует особого внимания. Эти люди, наряду с людьми в специализации DataScience, отвечают за будущее работы с данными в компании. JSON — по прежнему арабская вязь для любителей SQL синтаксиса, но, похоже, необходимо осваивать. Python — основная проблема не столько во владении синтаксисом сколько в наличии времени и мотивации у специалистов геологических и геофизических специальностей его применять. Из лучших COSS (коммерческое ПО с открытым кодом) — конечно Elasticsearch. И как с любым OSS — оставить всякие иллюзии в отношении out of the box решения от самого производителя ОSS.