Нафтогазова промисловість як приклад для периферійних хмарних систем

Минулого тижня моя команда провела захоплюючий захід у готелі Four Seasons у Х'юстоні, штат Техас. Воно було присвячено продовженню тенденції розвитку тісніших відносин між учасниками. Це була подія, яка об'єднала користувачів, партнерів та клієнтів. Крім цього, на заході були присутні багато представників Hitachi. При організації цього підприємства ми ставили собі дві мети:

  1. Підігрівати інтерес до досліджень нових проблем галузі, що продовжуються;
  2. Перевірити області, в яких ми вже працюємо та розвиваємось, а також їх коригування на основі відгуків користувачів.

Дуг Гібсон і Метт Холл (Agile Geoscience) почали з обговорення стану галузі та різних проблем, пов'язаних з управлінням та обробкою сейсмічних даних. Було досить надихаюче і, безумовно, показово почути, як розподіляються обсяги інвестицій між видобутком, транспортуванням та переробкою. Нещодавно левова частка інвестування йшла у видобуток, яка колись була королем за споживаним обсягом коштів, але поступово інвестиції переходять і в переробку, і в транспортування. Метт розповів про своє захоплення буквальним спостереженням геологічного розвитку Землі за допомогою сейсмічних даних.

Нафтогазова промисловість як приклад для периферійних хмарних систем

Загалом я вважаю, що наш захід можна розглядати як «перший вихід у світ» для робіт, які ми розпочали кілька років тому. Ми продовжимо інформувати вас про різні досягнення та успіхи в нашій роботі, що ведеться в цьому напрямку. Далі, натхненні одним виступом Метта Холла, ми провели серію сесій, результатом яких став цінний обмін досвідом.

Нафтогазова промисловість як приклад для периферійних хмарних систем

Периферійні (граничні) чи хмарні обчислення?

На одній із сесій Даг і Раві (Hitachi Research в Санта-Кларі) провели дискусію про те, як перенести деяку частину аналітики до периферійних обчислень для більш швидкого та точного прийняття рішень. Для цього є багато причин, і я думаю, що три найбільш значущі з них — це вузькі канали передачі даних, великі обсяги даних (як за швидкістю надходження, обсягом та різноманітністю), і жорсткі графіки прийняття рішень. Незважаючи на те, що деякі процеси (особливо геологічні) можуть зайняти тижні, місяці або роки, щоб завершитися, все ж таки в цій галузі чимало випадків коли терміновість має особливе значення. У такому разі неможливість доступу до централізованої хмари може мати катастрофічні наслідки! Зокрема, питання, які стосуються ОЗТОС (здоров'я, безпека та навколишнє середовище), а також питання, пов'язані з видобутком нафти та газу, потребують швидкого аналізу та прийняття рішень. Можливо, найкращий спосіб показати це на прикладі різних чисел конкретні деталі нехай залишаться анонімними, щоб «захистити невинних».

  • Бездротові мережі останньої милі модернізуються в таких місцях, як Пермський басейн, з переходом каналів із супутника (де швидкість вимірювалася в кбіт/с) на 10 Мбіт/с канал із використанням 4G/LTE або неліцензійного діапазону частот. Навіть ці модернізовані мережі можуть не справлятися під час зіткнення з терабайтами та петабайтами даних на кордоні.
  • Сенсорні системи від таких компаній, як FOTECH, які поєднуються з безліччю інших як нових, так і давно працюючих сенсорних платформ, здатні виробляти кілька терабайт на день. Додаткові цифрові камери, які встановлюють для спостереження за безпекою та захисту від крадіжки, також генерують великий обсяг даних, а це означає, що на кордоні формується повний набір категорій великих даних (обсяг, швидкість надходження та різноманітність).
  • У разі систем сейсморозвідки, що використовуються для збору даних, проекти включають «конвергентні» системи, поміщені в контейнери ISO, для збирання та переформатування сейсмічних даних потенційно до масштабу 10 петабайт даних. Через віддалені місця розташування, в яких працюють ці системи розвідки, існує серйозна нестача пропускної здатності для переміщення даних від межі останньої милі до центру обробки даних по мережах. Тому сервісні компанії буквально відправляють дані від кордону до центру обробки даних на стрічкових, оптичних або міцних магнітних пристроях.
  • Оператори браунфілд (brownfield) заводів, де щодня відбуваються тисячі подій та десятки «червоних аварійних сигналів», хочуть працювати більш оптимально та стабільно. Однак мережі з низькою швидкістю передачі даних та практично повна відсутність сховищ для збору даних для аналізу на заводах дозволяють припустити, що перед початком базового аналізу поточних операцій потрібно щось фундаментальне.

Це, безумовно, змушує мене думати про те, що постачальники загальнодоступних хмарних систем намагаються перенести всі ці дані на свої платформи, існує сувора реальність, з якою потрібно намагатися впоратися. Можливо, найкращий спосіб класифікувати цю проблему – це намагатися пропхати слона через соломинку! Тим не менш, багато з переваг хмари просто необхідні. То що ми можемо зробити?

Перехід до периферійних хмарних систем

Зрозуміло, на ринку Hitachi вже є (галузеві) оптимізовані рішення, які збагачують дані на кордоні, аналізують їх та стискають до мінімального корисного обсягу даних, а також надають бізнес-консультативні системи, здатні покращити процеси, пов'язані з периферійними обчисленнями. Тим не менш, мій висновок, зроблений минулого тижня, полягає в тому, що вирішення цих складних проблем стосуються не стільки віджету, який ви виводите на стіл, скільки підходу до вирішення проблеми. Це дійсно дух платформи Lumada від Hitachi Insight Group, оскільки вона включає методи для залучення користувачів, екосистем і, при необхідності, надає інструменти для обговорення. Я був дуже щасливий повернутись до вирішення проблем (а не до продажу продуктів), тому що Метт Холл сказав: «Я був радий бачити, що співробітники компанії Hitachi почали правильно розуміти масштаби проблеми», коли ми закривали наш саміт.

То може O&G (нафтогазова промисловість) виступити живим прикладом, який показує необхідність впровадження периферійних обчислень? Схоже, що з огляду на проблеми, виявлені під час нашого саміту, а також інші галузеві взаємодії, ймовірна відповідь — так. Можливо, причина цього така ясна, тому що периферійні обчислення, цільова побудова для галузі та змішання шаблонів хмарного проектування очевидні в міру модернізації стеків. Я вважаю, що в даному випадку питання «як» заслуговує на увагу. Використовуючи цитату Метта з останнього абзацу, ми розуміємо як підштовхнути принцип хмарних обчислень до периферійних обчислень. По суті, для цієї галузі ми повинні проводити «старомодні», а іноді й особисті контакти з людьми, які беруть участь у різних частинах екосистеми нафтогазової промисловості, таких як геологи, інженери буріння, геофізики тощо. З урахуванням цих взаємодій, які необхідно вирішити, їх масштаби та глибина стають очевиднішими і навіть переконливими. Тоді, коли ми складемо плани виконання та втілимо їх у життя, ми вирішимо збудувати периферійні хмарні системи. Однак, якщо ми сидимо в центрі, просто читаємо та представляємо ці проблеми, у нас не буде достатньо розуміння та співчуття, щоб справді зробити все можливе. Отже, ще раз, так, нафта і газ породять периферійні хмарні системи, але розуміння реальних потреб користувачів на місцях допоможе нам визначити, які проблеми мають першорядне значення.

Джерело: habr.com

Додати коментар або відгук