Структура хранения данных

Последнее сообщение
ResEng 92 5
Янв 19

Добрый день, уважаемые коллеги.

Хотелось бы обсудить тему data management'а в НГ отрасли. В частности, подход к структуре хранения данных. Четкая БД позволяет быстро найти необходимую информацию, а как ее организовать - хз. Как вы струтурируете данные по месторождению? Есть месторождение, как идет разбивка данных? по скважинам, по дисциплинам, и т.д.? Как бороться с многочисленными копиями одних и тех же файлов в разных папках? в идеале получить примерное дерево хранения данных.

Буду рад услышать лучшие практики по этому вопросу.

 

WadiAra 81 7
Янв 19 #1

Существуют общепризнанные открытые стандарты по хранению и передаче данных PPDM, WITSML, PRODML, RESQML, есть решения с реализационными и не реализационными  БД, реализующие эти стандарты. Исходя из Ваших возможностей,  выбреется программное обеспечение под Ваши задачи (сервис, разработка, моделирование и т.д.).

Рушан 557 12
Янв 19 #2

Можно разбивать папки след образом как
- General
- Field01
- Field02
....
- Personal
-- Marat
-- Maxim
...
-- Shared - для быстрого обмена файлов, например, перед или после презентаций

Потом в каждом филде
- General
- Drilling
- Reservoir Engineering
-- прогнозы
-- PVT
- Petrophysics
-- методики интерпретаций
-- отчеты по рутинным и специальным исследованиям керна
- Wells
-- Well01
-- Well02

В Wells ты можешь разместить собственно "сырые" данные по скважинам - ласы, отчеты по бурению, сводки

В общем примерно такая идея.

GRR 509 3
Янв 19 #3

Вот рыбо для модельеров, можно на нее наращивать бесконечно, по таком же принципу и другие дисциплины, вероятно, все очень удобно, все всегда под рукой (но кто-то в команде все равно устроит бардак%))

Вложение: 
RomanK. 2158 11
Янв 19 #4

В такой структуре бардак начинается, когда просто файлы начинают кидать в корень папки. Ну и конечно вездесущие папки "Old" "New" "НЕ УДАЛЯТЬ" "Максим" "Для Петрова"

Петя Ботев 666 7
Янв 19 #5

RomanK. пишет:
В такой структуре бардак начинается, когда просто файлы начинают кидать в корень папки. Ну и конечно вездесущие папки "Old" "New" "НЕ УДАЛЯТЬ" "Максим" "Для Петрова"

ой как соглашусь то))) Личное мнение - данные нужно хранить в специализированых БД с четкой структурой, изменение которой невозможно. Иначе каша и потеря данных при смене персонала.

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

WadiAra 81 7
Янв 19 #6

Все зависит от задачи,  можно обойтись регламентированной структурой данных и обычным не заточенным под НГ промышленность решением: файловое хранилище (управление доступом, контекстный поиск, веб просмотр содержимого и т.д.), система управления версиями. Пример Google Drive.

sNeG 768 9
Янв 19 #7

Петя Ботев пишет:

RomanK. пишет:
В такой структуре бардак начинается, когда просто файлы начинают кидать в корень папки. Ну и конечно вездесущие папки "Old" "New" "НЕ УДАЛЯТЬ" "Максим" "Для Петрова"

ой как соглашусь то))) Личное мнение - данные нужно хранить в специализированых БД с четкой структурой, изменение которой невозможно. Иначе каша и потеря данных при смене персонала.

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

Такая база хороша когда уже все данные итоговые (конечные) туда занесены, я работал в конторе где так было - было удобно. Но для реализации такой базы нужен отдельный персонал . А на этапе работы над месторождением как работать если изменять даные нельзя?   

WadiAra 81 7
Янв 19 #8

sNeG пишет:

 А на этапе работы над месторождением как работать если изменять даные нельзя?   

Возможно Вы путаете структуру (схему данных) и сами данные, данные меняются, структура нет.

Петя Ботев 666 7
Янв 19 #9

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

GRR 509 3
Янв 19 #10

А что, в Petrel или RMS можно грузить данные напрямую из СУБД или какого-нибудь там Баспро с ГИДом?

чЧо-то сильно сомневаюсь, так же, как и обратно - из моделей в них ничо напрямую не засунешь.

Или есть у кого такой опыт уже?

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

Так что, бардака никак не меньше, скажу я вам..

WadiAra 81 7
Янв 19 #11

GRR пишет:

А что, в Petrel или RMS можно грузить данные напрямую из СУБД или какого-нибудь там Баспро с ГИДом?

В Петю через плагины можно реализовать обмен по протоколу WITSML, RESQML и PRODML. В РМС обмен по протоколу WITSML организуется стандартными средствами. Плюс можно написать на С# свой плагин для Пети или код на питоне  для РМС по загрузке/выгрузке данных из своих источников (БД, файлы, другое приложение, веб сервера и пр.).

GRR пишет:

Или есть у кого такой опыт уже?

В прошлом году из РМС соединились через веб сервисы по протоколу WITSML 1.41 и загружали данные.

Гоша 1180 12
Янв 19 #12

GRR пишет:

А что, в Petrel или RMS можно грузить данные напрямую из СУБД или какого-нибудь там Баспро с ГИДом?

В Petrel - если крупная БД, то Studio. По части истории эксплуатации (заканчивания, добыча) есть плагин Ora2Petrel - для передачи данных из базы по типу Баспро. Если в Access - то есть OFM Connector. Ну и собственный вариант плагина через Ocean никто не отменял - на всех не напасешься.

А бардак от людей зависит, не от БД.

 

rbildano 189 7
Янв 19 #13

GRR пишет:

А что, в Petrel или RMS можно грузить данные напрямую из СУБД или какого-нибудь там Баспро с ГИДом?

чЧо-то сильно сомневаюсь, так же, как и обратно - из моделей в них ничо напрямую не засунешь.

Или есть у кого такой опыт уже?

RMS напрямую коннектиться к OW.

Petrel как уже заметили к Studio, но студия это просто некое хранилище проектов Петрель, а так база у шлюмов в ProSource.

GRR 509 3
Янв 19 #14

Гоша пишет:

А бардак от людей зависит, не от БД.

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

ResEng 92 5
Янв 19 #15

Рушан пишет:
Можно разбивать папки след образом как - General - Field01 - Field02 .... - Personal -- Marat -- Maxim ... -- Shared - для быстрого обмена файлов, например, перед или после презентаций Потом в каждом филде - General - Drilling - Reservoir Engineering -- прогнозы -- PVT - Petrophysics -- методики интерпретаций -- отчеты по рутинным и специальным исследованиям керна - Wells -- Well01 -- Well02 В Wells ты можешь разместить собственно "сырые" данные по скважинам - ласы, отчеты по бурению, сводки В общем примерно такая идея.

У нас как раз таки такая структура. проблема, к примеру, в том, что в каждой дисциплине есть папка Wells, инженеры с каждой дисциплины копирует стопятьсот раз в разные папки одни и те же файлы (deviations, completion etc), какие-то уникальные данные вообще хз где и приходиться копаться везде и долго.

ну и как было сказано, просто бесят папки аля "Мага", "логи для васи 2014" и т.д. в итоге БД превращается в барахолку.

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

Есть еще у кого нибудь идейки по поводу дерева хранения файлов на оперируемом месторождении?

OES 4 1
Янв 19 #16

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

Рушан 557 12
Янв 19 #17

ResEng пишет:

У нас как раз таки такая структура. проблема, к примеру, в том, что в каждой дисциплине есть папка Wells, инженеры с каждой дисциплины копирует стопятьсот раз в разные папки одни и те же файлы (deviations, completion etc), какие-то уникальные данные вообще хз где и приходиться копаться везде и долго.

В каждой дисциплине лучше так не делать. Я имел ввиду что в пределах папки по месторождению скважины лучше вынести отдельно(см рисунок) и внутри к-ой скважины уже создавать 01-LASes, 02-Cores, 03-PP Interpretation, 04-Completion, 05-Drilling. Типа такого. В самих папках по дисциплинам лучше создавать что то общее для всего месторождения. Например бизнес-прогнозы и сами методики прогнозов уже будут в 04-ResEng.

Belle 111 12
Янв 19 #18

RomanK. пишет:
В такой структуре бардак начинается, когда просто файлы начинают кидать в корень папки. Ну и конечно вездесущие папки "Old" "New" "НЕ УДАЛЯТЬ" "Максим" "Для Петрова"

 

Final

Final_1

Final_final

Final_forreal

Belle 111 12
Янв 19 #19

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

или "ой я не знаю", " ой отправьте письмо менеджеру если он мне скажет я вам дам"

 

sNeG 768 9
Янв 19 #20

Belle пишет:

RomanK. пишет:
В такой структуре бардак начинается, когда просто файлы начинают кидать в корень папки. Ну и конечно вездесущие папки "Old" "New" "НЕ УДАЛЯТЬ" "Максим" "Для Петрова"

 

Final

Final_1

Final_final

Final_forreal

super final

last final ...

super last finish final

super last finish final corrected))

Stroncz 569 12
Янв 19 #21

_____xxx

___xxx

_xxx

xxx

WadiAra 81 7
Янв 19 #22

Можно подвести предварительные итоги дискуссии:

  1. Чистое хранение данных в каталогизированном хранилище прошлый век.
  2. С базой данных лучше, чем без базы данных.
  3. Должны быть строгие регламенты по оформлению/хранению/обмену моделей/данных.
  4. Чтобы не плодить хаос, и всегда можно было найти концы/крайнего, необходима централизованная система контроля версии. Думаю, поможет опыт разработки программного обеспечения, когда в том же Git над проектом совместно работают десятки человек. Успешное завершение таких проектов результат грамотного управления данными и ресурсами.
AGA 752 7
Янв 19 #23

как не выеживайся, один фиг будет бардак.

ResEng 92 5
Янв 19 #24

Рушан пишет:

ResEng пишет:

У нас как раз таки такая структура. проблема, к примеру, в том, что в каждой дисциплине есть папка Wells, инженеры с каждой дисциплины копирует стопятьсот раз в разные папки одни и те же файлы (deviations, completion etc), какие-то уникальные данные вообще хз где и приходиться копаться везде и долго.

В каждой дисциплине лучше так не делать. Я имел ввиду что в пределах папки по месторождению скважины лучше вынести отдельно(см рисунок) и внутри к-ой скважины уже создавать 01-LASes, 02-Cores, 03-PP Interpretation, 04-Completion, 05-Drilling. Типа такого. В самих папках по дисциплинам лучше создавать что то общее для всего месторождения. Например бизнес-прогнозы и сами методики прогнозов уже будут в 04-ResEng.

Выглядит интересно!

а где в таком случае храните PVT SCAL и т д? привязка идет к скважинам или же к дисциплинам или вообще в отдельную папку с информацией по месторождению?

где храните проекты/документацию по смежным дисциплинам? 

 

 

 

Dorzhi 894 12
Янв 19 #25

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

Рушан 557 12
Янв 19 #26

ResEng пишет:

а где в таком случае храните PVT SCAL и т д? привязка идет к скважинам или же к дисциплинам или вообще в отдельную папку с информацией по месторождению?

где храните проекты/документацию по смежным дисциплинам? 

PVT м.б. в 04-ResEng, а SCAL в зав-ти от того кто им занимается. Если петрофизик, то в 03-Petrophysics. По смежным или общим можно в 01-General.

AKazak 57 7
Янв 19 #27

Привет всем!

Интересная дискуссия.
Хочу также отметить, что вместо того, чтобы создавать копии данных в разных папкам можно разместить данные в наиболее подходящеё папке, а далее - размещать ярлыки (shortcut, link) во всех нужных папках. Таким образом данные плодиться не будут, а ярлыки при желании можно будет быстро удалить из папок, в которых они более не нужны.

По соданию паразитных папок типа 'New", "для Петрова': можно сделать типовую структуру папок и закрыть всем пользователям доступ на создание новых папок, понуждая тем самым раскладывать данные в имеющуюся структуру.

Рушан 557 12
Янв 19 #28

Для личных папок можно сделать например 12-Users а в нем уже папки типа "PetrovMV", "IvanovII", "SidorovNM" и т.д.

Для "паразитных" или временных можно создать 15-Temporary / 15-Shared / 15 - Temporary Shared где могут удаляться папки которым срок неделя или месяц (после backup)

Сергей Киб 47 3
Фев 19 #29

 

Вставлю свои 5 копеек.

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

Мусор есть, он будет у всех, дублироваться доки тоже будут. Ситуации разные, то новые ГИС, то КРС, то аварийные ситуации(тьфу-тьфУ), их ведь тоже необходимо где то хранить.

gotcha 87 11
Фев 19 #30

ResEng пишет:

Хотелось бы обсудить тему data management'а в НГ отрасли. В частности, подход к структуре хранения данных. Четкая БД позволяет быстро найти необходимую информацию, а как ее организовать - хз.

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

ResEng пишет:

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

По объектам, которые есть в нефтянке - месторождение, куст, скважина, ствол, пласт, перфорация, мероприятие, внутрискважинное оборудование и т.д., в количестве больше 200 штук.

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

Папки организовать - вещь простая, гораздо сложнее организовать людей, которые должны все делать своевременно. У нас есть пара инструментов, которые помогают.

AlexanderP 28 2
Фев 19 #31

gotcha пишет:

У нас есть пара инструментов, которые помогают.

а что за инструменты? поделитесь пж

 

GRR 509 3
Фев 19 #32

AlexanderP пишет:

gotcha пишет:

У нас есть пара инструментов, которые помогают.

а что за инструменты? поделитесь пж

 

дубинка, черенок от лопаты..

извините )

gloryvictory 14 4
Фев 19 #33

www.sibgeoproject.ru
1) есть новый продукт - ГеоЛинк - его задача искать в куче файловых архивов в разных форматах и показывать. все привязывается к карте. Этим решается задача поиска разнородной информации (а уж как лежит и где лежит - это второй вопрос)
2) Для данных ГРР есть Система Мониторинга Недропользования - со своей структурой данных. можно начинать с простого. это Российская замена PetroVision и PetroBank.
3) для специфичных задач есть отраслевые решения типа BasPro, Атлас, Schlumberger ProSource и т.п.

А в остальном, коллега gotcha - правильно все говорит.

rbildano 189 7
Фев 19 #34

gloryvictory пишет:
www.sibgeoproject.ru 1) есть новый продукт - ГеоЛинк - его задача искать в куче файловых архивов в разных форматах и показывать. все привязывается к карте. Этим решается задача поиска разнородной информации (а уж как лежит и где лежит - это второй вопрос)

есть аналог Kadme.

gloryvictory 14 4
Фев 19 #35

Да верно, только ГеоЛинк - отечественная разработка.

volvlad 2110 12
Фев 19 #36

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

С Петрелом и данными для него нам удалось навести порядок. Все официальные данные (скважины, каротажи, утвержденные варианты интерпретаций, карты, полигоны, сейсмика, и многое другое хранятся в единой базе Studio. Из этой базы можно забирать все, а заливать только "окончательные и утвержденные" данные, чтоюы не разводить бардака, которого хватает в персональных проектах.

Примерную структуру, если интересно скину.

rbildano 189 7
Фев 19 #37

volvlad пишет:

Примерную структуру, если интересно скину.

Можно мне тоже в личку плиз.

softland 276 10
Фев 19 #38

Пожалуй поддержу OES 

для постоянной работы с месторождением ResView можно рекомендовать. Пополняемые словари - это уже победа.

имхо будет луче чем ГИД. Бас-про не видел, не скажу

а вот использование Git (предложил WadiAra) маловероятно. Бесплатные репозитории - публичны, за приватные нужно платить. Кроме того - в Git приятно работать с ASCII файлами, но с бинарниками уже не так. Веди diff уже не сделаешь и подсветить разниwe не получится.

У меня всё больше проектная деятельность, сделал и забыл. prj.pngчуть интересней "Материалы"

mater.png

Активно расставляем линки, скажем в 04.03 Керн... можно накидать линков на отчёты и таблицы лежащие в скважинах.

Иногда всё наоборот, пробы в 05.02 ФХС, а в каталогах скважин на эти файлы ссылки

Но, повторюсь. Мы проектанты, нам надо решить текущую проблему

WadiAra 81 7
Фев 19 #39

softland пишет:

а вот использование Git (предложил WadiAra) маловероятно. Бесплатные репозитории - публичны, за приватные нужно платить. Кроме того - в Git приятно работать с ASCII файлами, но с бинарниками уже не так. Веди diff уже не сделаешь и подсветить разниwe не получится.

Можно развернуть свой бесплатный Git сервер с преферансом и поэтессами. С бинарными файлами все верно, обычными средствами «diff» не сделаешь, но можно получить любую предыдущею версию бинарного файла и отследить историю изменений, что уже неплохо по сравнению с  чисто каталогизированной системой хранения. Если постараться, то количество бинарных файлов в проектах будет минимально, а работа будет завязана на workflows и скрипты.

softland 276 10
Фев 19 #40

Я всегда с огромным сомнением относился к самописным (разработанным внутри компаний) программам. Локальные задачи, да, можно решить. Утилиты, конвертеры, расчётные модели... но боевая многопользовательская система с разграничением доступа, с версионностью... это АХОВАЯ задача. 

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

IMHO 90% пользователей MS Excel не пользуется pivot table

Вот и получается, что делимся: а как нам идеально сделать структуру каталогов... и как отрубать пальцы тому кто назовёт файл "New исслед керна2.xlsx"

ResEng 92 5
Фев 19 #41

volvlad пишет:

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

С Петрелом и данными для него нам удалось навести порядок. Все официальные данные (скважины, каротажи, утвержденные варианты интерпретаций, карты, полигоны, сейсмика, и многое другое хранятся в единой базе Studio. Из этой базы можно забирать все, а заливать только "окончательные и утвержденные" данные, чтоюы не разводить бардака, которого хватает в персональных проектах.

Примерную структуру, если интересно скину.

Конечно интересно. скрин в студию :)

Go to top