Янв 19
Добрый день, уважаемые коллеги.
Хотелось бы обсудить тему data management'а в НГ отрасли. В частности, подход к структуре хранения данных. Четкая БД позволяет быстро найти необходимую информацию, а как ее организовать - хз. Как вы струтурируете данные по месторождению? Есть месторождение, как идет разбивка данных? по скважинам, по дисциплинам, и т.д.? Как бороться с многочисленными копиями одних и тех же файлов в разных папках? в идеале получить примерное дерево хранения данных.
Буду рад услышать лучшие практики по этому вопросу.
Опубликовано
23 Янв 2019
Активность
41
ответ
3399
просмотров
21
участник
7
Рейтинг
Существуют общепризнанные открытые стандарты по хранению и передаче данных PPDM, WITSML, PRODML, RESQML, есть решения с реализационными и не реализационными БД, реализующие эти стандарты. Исходя из Ваших возможностей, выбреется программное обеспечение под Ваши задачи (сервис, разработка, моделирование и т.д.).
Можно разбивать папки след образом как
- General
- Field01
- Field02
....
- Personal
-- Marat
-- Maxim
...
-- Shared - для быстрого обмена файлов, например, перед или после презентаций
Потом в каждом филде
- General
- Drilling
- Reservoir Engineering
-- прогнозы
-- PVT
- Petrophysics
-- методики интерпретаций
-- отчеты по рутинным и специальным исследованиям керна
- Wells
-- Well01
-- Well02
В Wells ты можешь разместить собственно "сырые" данные по скважинам - ласы, отчеты по бурению, сводки
В общем примерно такая идея.
Вот рыбо для модельеров, можно на нее наращивать бесконечно, по таком же принципу и другие дисциплины, вероятно, все очень удобно, все всегда под рукой (но кто-то в команде все равно устроит бардак%))
В такой структуре бардак начинается, когда просто файлы начинают кидать в корень папки. Ну и конечно вездесущие папки "Old" "New" "НЕ УДАЛЯТЬ" "Максим" "Для Петрова"
ой как соглашусь то))) Личное мнение - данные нужно хранить в специализированых БД с четкой структурой, изменение которой невозможно. Иначе каша и потеря данных при смене персонала.
Я к сожалению за 12+ лет работы не увидел на практике таких, но постоянно вижу разговоры что "нам нужен бос про или что то подобное". Интересно было бы услышать мнение роснефтевцев, работающих в нем.
Все зависит от задачи, можно обойтись регламентированной структурой данных и обычным не заточенным под НГ промышленность решением: файловое хранилище (управление доступом, контекстный поиск, веб просмотр содержимого и т.д.), система управления версиями. Пример Google Drive.
Такая база хороша когда уже все данные итоговые (конечные) туда занесены, я работал в конторе где так было - было удобно. Но для реализации такой базы нужен отдельный персонал . А на этапе работы над месторождением как работать если изменять даные нельзя?
Возможно Вы путаете структуру (схему данных) и сами данные, данные меняются, структура нет.
я имею в виду что для получения данных персонал лезет не по папочкам на сервере, а непосредственное в некую софтину. Варианты заноса данных как всегда зависят от бюджета заведения - либо отдельно обученые люди заносят, либо отдельно обученые люди дрессируют остальной персонал.
Мне такой подходт кажется удобным. А то эта вечная история - Вася, дай мне то, Лена дай мне это.... Мага - а где у тебя это лежит? А ко мне не подходите...я занят.
А что, в Petrel или RMS можно грузить данные напрямую из СУБД или какого-нибудь там Баспро с ГИДом?
чЧо-то сильно сомневаюсь, так же, как и обратно - из моделей в них ничо напрямую не засунешь.
Или есть у кого такой опыт уже?
Кстати, довольно геморно получается - з ГИДа, скажем, выгружаешь, не факт, что можно все сразу, проверяшь, загружаешь в модельный софт и так же - если обратно.
Так что, бардака никак не меньше, скажу я вам..
В Петю через плагины можно реализовать обмен по протоколу WITSML, RESQML и PRODML. В РМС обмен по протоколу WITSML организуется стандартными средствами. Плюс можно написать на С# свой плагин для Пети или код на питоне для РМС по загрузке/выгрузке данных из своих источников (БД, файлы, другое приложение, веб сервера и пр.).
В прошлом году из РМС соединились через веб сервисы по протоколу WITSML 1.41 и загружали данные.
В Petrel - если крупная БД, то Studio. По части истории эксплуатации (заканчивания, добыча) есть плагин Ora2Petrel - для передачи данных из базы по типу Баспро. Если в Access - то есть OFM Connector. Ну и собственный вариант плагина через Ocean никто не отменял - на всех не напасешься.
А бардак от людей зависит, не от БД.
RMS напрямую коннектиться к OW.
Petrel как уже заметили к Studio, но студия это просто некое хранилище проектов Петрель, а так база у шлюмов в ProSource.
Тут, возможно, помогут легкие поб0и и общая нетолерантность стремлению контингента к хаосу..
У нас как раз таки такая структура. проблема, к примеру, в том, что в каждой дисциплине есть папка Wells, инженеры с каждой дисциплины копирует стопятьсот раз в разные папки одни и те же файлы (deviations, completion etc), какие-то уникальные данные вообще хз где и приходиться копаться везде и долго.
ну и как было сказано, просто бесят папки аля "Мага", "логи для васи 2014" и т.д. в итоге БД превращается в барахолку.
у нас есть шлюмовская база данных просорс - но имхо шляпа полная. подходит только для хранения файлов определенного типа. Очень долго выгружаются данные и совсем невозможно работать с какими-то личными файлами типа эксельками, анализами и т.д.
Есть еще у кого нибудь идейки по поводу дерева хранения файлов на оперируемом месторождении?
Зачем выдумывать, есть роксаровская ресвью. Удобная система хранения информации с возможностью построения карт и разрезов плюс гибкая формализация, техподдержка добавляет нужные шаблоны. Из минусов естественно цена и специфические требования к дополнительной информации, которая не всегда формализована. Удобно кстати реализована передача срезов бд с новой информацией например от недропользователя к исполнителю
В каждой дисциплине лучше так не делать. Я имел ввиду что в пределах папки по месторождению скважины лучше вынести отдельно(см рисунок) и внутри к-ой скважины уже создавать 01-LASes, 02-Cores, 03-PP Interpretation, 04-Completion, 05-Drilling. Типа такого. В самих папках по дисциплинам лучше создавать что то общее для всего месторождения. Например бизнес-прогнозы и сами методики прогнозов уже будут в 04-ResEng.
Final
Final_1
Final_final
Final_forreal
или "ой я не знаю", " ой отправьте письмо менеджеру если он мне скажет я вам дам"
super final
last final ...
super last finish final
super last finish final corrected))
_____xxx
___xxx
_xxx
xxx
Можно подвести предварительные итоги дискуссии:
как не выеживайся, один фиг будет бардак.
Выглядит интересно!
а где в таком случае храните PVT SCAL и т д? привязка идет к скважинам или же к дисциплинам или вообще в отдельную папку с информацией по месторождению?
где храните проекты/документацию по смежным дисциплинам?
по сути нужна постоянно висящая в трее программка, которая мониторит выделенную область данных на предмет повторений, нарушения структуры папок и так далее по желанию.
базы данных это хорошо, но от плодящихся эксель файлов все равно не избавиться.
PVT м.б. в 04-ResEng, а SCAL в зав-ти от того кто им занимается. Если петрофизик, то в 03-Petrophysics. По смежным или общим можно в 01-General.
Привет всем!
Интересная дискуссия.
Хочу также отметить, что вместо того, чтобы создавать копии данных в разных папкам можно разместить данные в наиболее подходящеё папке, а далее - размещать ярлыки (shortcut, link) во всех нужных папках. Таким образом данные плодиться не будут, а ярлыки при желании можно будет быстро удалить из папок, в которых они более не нужны.
По соданию паразитных папок типа 'New", "для Петрова': можно сделать типовую структуру папок и закрыть всем пользователям доступ на создание новых папок, понуждая тем самым раскладывать данные в имеющуюся структуру.
Для личных папок можно сделать например 12-Users а в нем уже папки типа "PetrovMV", "IvanovII", "SidorovNM" и т.д.
Для "паразитных" или временных можно создать 15-Temporary / 15-Shared / 15 - Temporary Shared где могут удаляться папки которым срок неделя или месяц (после backup)
Вставлю свои 5 копеек.
У нас двух терабайтник, висит по сетке. С коллегами строго определены типы папок, эксплуатационные скважины, там уже скважины, в каждой наличие обязательтных несколько папок, и так для каждой скважины.
Мусор есть, он будет у всех, дублироваться доки тоже будут. Ситуации разные, то новые ГИС, то КРС, то аварийные ситуации(тьфу-тьфУ), их ведь тоже необходимо где то хранить.
Быстро найти - это тоже навык, однако учится этому никто не хочет, не смотря на наличие структурированных хранилищ и огромного количества данных. Спаслись только тем, что все перенесли в вебпортал, и через него все пользователи смотрят на скважины и пласты.
По объектам, которые есть в нефтянке - месторождение, куст, скважина, ствол, пласт, перфорация, мероприятие, внутрискважинное оборудование и т.д., в количестве больше 200 штук.
По папкам Рушан уже написал, за 15 лет у нас структура не поменялась, но уже есть ощущение, что надо бы еще детальнее все организовывать.
Папки организовать - вещь простая, гораздо сложнее организовать людей, которые должны все делать своевременно. У нас есть пара инструментов, которые помогают.
а что за инструменты? поделитесь пж
дубинка, черенок от лопаты..
извините )
www.sibgeoproject.ru
1) есть новый продукт - ГеоЛинк - его задача искать в куче файловых архивов в разных форматах и показывать. все привязывается к карте. Этим решается задача поиска разнородной информации (а уж как лежит и где лежит - это второй вопрос)
2) Для данных ГРР есть Система Мониторинга Недропользования - со своей структурой данных. можно начинать с простого. это Российская замена PetroVision и PetroBank.
3) для специфичных задач есть отраслевые решения типа BasPro, Атлас, Schlumberger ProSource и т.п.
А в остальном, коллега gotcha - правильно все говорит.
есть аналог Kadme.
Да верно, только ГеоЛинк - отечественная разработка.
Организация данных, это вечно обсуждаемая тема, на которую тратиться огромное количество времени и ресурсов, а однозначного максимально удобного и наиболее приемлемого для всех варианта нет. И как результат - полный хаос.
С Петрелом и данными для него нам удалось навести порядок. Все официальные данные (скважины, каротажи, утвержденные варианты интерпретаций, карты, полигоны, сейсмика, и многое другое хранятся в единой базе Studio. Из этой базы можно забирать все, а заливать только "окончательные и утвержденные" данные, чтоюы не разводить бардака, которого хватает в персональных проектах.
Примерную структуру, если интересно скину.
Можно мне тоже в личку плиз.
Пожалуй поддержу OES
для постоянной работы с месторождением ResView можно рекомендовать. Пополняемые словари - это уже победа.
имхо будет луче чем ГИД. Бас-про не видел, не скажу
а вот использование Git (предложил WadiAra) маловероятно. Бесплатные репозитории - публичны, за приватные нужно платить. Кроме того - в Git приятно работать с ASCII файлами, но с бинарниками уже не так. Веди diff уже не сделаешь и подсветить разниwe не получится.
У меня всё больше проектная деятельность, сделал и забыл.
чуть интересней "Материалы"
Активно расставляем линки, скажем в 04.03 Керн... можно накидать линков на отчёты и таблицы лежащие в скважинах.
Иногда всё наоборот, пробы в 05.02 ФХС, а в каталогах скважин на эти файлы ссылки
Но, повторюсь. Мы проектанты, нам надо решить текущую проблему
Можно развернуть свой бесплатный Git сервер с преферансом и поэтессами. С бинарными файлами все верно, обычными средствами «diff» не сделаешь, но можно получить любую предыдущею версию бинарного файла и отследить историю изменений, что уже неплохо по сравнению с чисто каталогизированной системой хранения. Если постараться, то количество бинарных файлов в проектах будет минимально, а работа будет завязана на workflows и скрипты.
Я всегда с огромным сомнением относился к самописным (разработанным внутри компаний) программам. Локальные задачи, да, можно решить. Утилиты, конвертеры, расчётные модели... но боевая многопользовательская система с разграничением доступа, с версионностью... это АХОВАЯ задача.
уровень компьютерной грамотности необходимый для работы с Git - выше среднего, к сожалению на этом пути больше проблем с пользователями чем с ПО
IMHO 90% пользователей MS Excel не пользуется pivot table
Вот и получается, что делимся: а как нам идеально сделать структуру каталогов... и как отрубать пальцы тому кто назовёт файл "New исслед керна2.xlsx"
Конечно интересно. скрин в студию :)