🥇Нефтегазовая промышленность как пример для периферийных облачных систем

На прошлой неделе моя команда провела захватывающее мероприятие в отеле Four Seasons в Хьюстоне, штат Техас. Оно было посвящено продолжению тенденции развития более тесных отношений между участниками. Это было событие, которое объединило пользователей, партнеров и клиентов. Кроме этого, на мероприятии присутствовало много представителей Hitachi. При организации этого предприятия мы ставили перед собой две цели:

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

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

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

Периферийные (граничные) или облачные вычисления?

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

Беспроводные сети последней мили модернизируются в таких местах, как Пермский бассейн, с переходом каналов со спутника (где скорость измерялась в кбит/с) на 10 Мбит/с канал с использованием 4G/LTE или нелицензионного диапазона частот. Даже эти модернизированные сети могут не справляться при столкновении с терабайтами и петабайтами данных на границе.
Сенсорные системы от таких компаний, как FOTECH, которые объединяются со множеством других как новых, так и давно работающих сенсорных платформ, способны производить несколько терабайт в день. Дополнительные цифровые камеры, которые устанавливают для наблюдением за безопасностью и защиты от кражи также генерируют большой объем данных, а это означает, что на границе формируется полный набор категорий больших данных (объем, скорость поступления и разнообразие).
В случае систем сейсморазведки, используемых для сбора данных, проекты включают «конвергентные» системы, помещенные в контейнеры ISO, для сбора и переформатирования сейсмических данных потенциально до масштаба 10 петабайт данных. Из-за удаленных местоположений, в которых работают эти системы разведки, существует серьезная нехватка пропускной способности для перемещения данных от границы последней мили до центра обработки данных по сетям. Поэтому сервисные компании в буквальном смысле отправляют данные от границы до центра обработки данных на ленточных, оптических или прочных магнитных запоминающих устройствах.
Операторы браунфилд (brownfield) заводов, где ежедневно происходят тысячи событий и десятки «красных аварийных сигналов», хотят работать более оптимально и стабильно. Однако сети с низкой скоростью передачи данных и практически полное отсутствие хранилищ для сбора данных для анализа на заводах позволяют предположить, что перед началом базового анализа текущих операций требуется нечто более фундаментальное.

Это, безусловно, заставляет меня думать о том, что в то время как поставщики общедоступных облачных систем пытаются перенести все эти данные на свои платформы, существует суровая реальность, с которой нужно пытаться справиться. Возможно, лучший способ классифицировать эту проблему — это пытаться пропихнуть слона через соломинку! Тем не менее, многие из достоинств облака просто необходимы. Так что мы можем сделать?

Переход к периферийным облачным системам

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

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

Источник: habr.com