Данные в современных исследованиях имеют определяющую роль [11]. Они могут быть представлены как в неструктурированном, так и в Труды XIX Международной конференции «Аналитика и управление данными в областях с интенсивным использованием данных» (DAMDID/ RCDL’2017), Москва, Россия, 10–13 октября 2017 года
К одной из областей ИИИД можно отнести течение многофазных потоков жидкости [8]. Данные собираются с множества сенсоров, например, выполняется дискретная запись акустического сигнала, температур, давления, течения жидкости. Накопленные объемы данных служат для характеристики многофазных потоков и их режимов. Важным приложением интерпретации акустического сигнала и накопленных мета-данных является предсказание скорости потока жидкости.
Несмотря на значительные успехи в интерпретации данных с сенсоров, проблемы построение сложных моделей, объясняющих динамику течения жидкости, остаются открытыми. Проведение точного физического эксперимента требует от исследователя серьезных усилий, т. к. необходимо обеспечить множество специальных условий [32]. Численное моделирование, особенно для недостаточно хорошо изученных потоков, часто требует калибровки с экспериментом [25, 31]. Разработка подходов к анализу данных для интерпретации потоковых данных виртуального эксперимента является важной и перспективной проблемой для исследования.
Параметры модели течения жидкости не являются статичным элементом. Внешние условия изменчивы и влияют на неё. Из-за этого предсказательная способность модели может начинать резко ухудшаться [30]. Это приводит к необходимости проведения её повторной калибровки. Важно отследить тот момент, когда модель начинает выдавать заведомо плохой результат. Таким образом, платформа, обрабатывающая вычисления, должна уметь работать с потоковыми данными в режиме, близком к реальному времени. Это обуславливает особое отношение к такому роду задач.
Одной из таких особенностей является требование распределенности. Система должна быть легко масштабируема, чтобы обрабатывать модель любой сложности с постоянно возрастающим объемом данных за разумный промежуток времени. Готовых открытых систем в области гидродинамики, удовлетворяющих данному требованию, по сведению авторов, нет.
Всё больше задач формируется не в рамках одной области, а междисциплинарно. Таким образом, возрастает роль онтологических спецификаций [37]. Это позволяет как различным ученым в рамках одной области, так и ученым из различных областей использовать общие понятия, что необходимо для ускорения проведения совместных исследований. В данной работе область применения исследования лежит как в контексте изучения физических явлений, а именно, течения жидкости, так и управления гипотезами [10].
Новизной данной работы является распределенная реализация метода бинарной оценки качества модели, работающей с потоковыми данными.
Статья организована следующим образом. В разделе 2 представлен сравнительный обзор платформ, на базе которых может быть осуществлен виртуальный эксперимент. Раздел 3 определяет онтологическую спецификацию двух предметных областей: течения жидкости и управления гипотезами. В разделе 4 выполнена концептуальная спецификация данных, используемых в виртуальном эксперименте. Раздел 5 описывает формат сырых входных данных, данных, поступающих на вход модели, и извлечённые значимые признаки модели течения жидкости. Раздел 6 содержит описание метода оценки качества с использованием двух подходов: частотного и Байесовского. Раздел 7 раскрывает архитектуру использованного для расчётов программно-аппаратного комплекса. В разделе 8 представлен реализованный поток работ. Раздел 9 описывает результаты, полученные на практике. 2 Обзор платформ 2.1 Критерии выбора
Одним из ключевых элементов ИИИД, наряду с машинным обучением, является явное использование гипотез в определении виртуального эксперимента [10]. Многие исследователи скептически относятся к подходу с использованием машинного обучения, так как он дает низкую интерпретируемость полученных результатов, так как многие методы в нем используются как черный ящик [18]. Подход же на основе гипотез лишен данного недостатка. Гипотезы в математическом виде описывают априорные знания об исследуемом явлении, которые проверяются в рамках виртуального эксперимента.
На сегодняшний день отсутствует единая методология работы с потоковыми данными [36]. Программные продукты, которые в той или иной мере реализуют представления отдельных групп ученых на то, как нужно работать с ними, не являются развитыми и стабильными.
В рамках исследования существующих решений по поставленной перед нами цели рассмотрим платформы для обработки данных в таких области научной деятельности как: • средства управления гипотезами и проведения виртуального эксперимента; • средства управления и обработки потоковых данных.
В качестве требований, предъявляемым при сравнительном анализе систем, будем применять следующие положения: 1. Система должна соответствовать онтологической спецификации предметной области. Это значит, что на базе нее возможно: a. реализовать модель; b. провести статистическое тестирование; 2. Система должна уметь работать с большим объемом потоковых данных; 3. Распределенность и скорость, т. е. должна легко масштабироваться в зависимости от вычислительной нагрузки. Результат должен получаться в режиме, близком к реальному времени; 4. Открытость, т. е. система должны быть с открытым исходным кодом; 5. Стабильность работы также является важным критерием, т. к. многие средства были разработаны ещё совсем недавно и не прошли полного цикла отладки. 2.2 Управление гипотезами
В настоящее время в рамках работы в областях с интенсивным использованием данных многие исследователи приходят к выводу о необходимости унификации подходов построения виртуальных экспериментов. Отдельные научные группы разрабатывают свои программные продукты, реализующие видение своих авторов к данной проблематике. Проанализируем некоторые из них – такие продукты, как: Hephaestus [10, 38], Features Collection and Correlation Engine (FCCE) [26, 38], ϒDB [11, 12, 38]. Сводная информация по сравнению платформ управления гипотезами представлена в Таблице 1. 2.3 Потоковые системы
Для сравнения выберем открытые системы,
которые являются наиболее популярными с точки
зрения применимости в практических задачах. К
таким продуктам можно отнести: Storm [
Серьёзной проблемой выбора потоковых фреймворков [36, 29] является отсутствие в настоящее время единых и объективных критериев оценки производительности [36]. В научной литературе существуют публикации, авторы которых проводят определённые сравнения, однако проблемой являются узкая специализация и ограниченность применения этих тестов [9]. В связи с отсутствием единой методологии целесообразно получать сравнительную производительность систем на данных конкретной исследовательской задачи для всех анализируемых платформ.
Однако скорость является не единственным
критерием выбора платформы. Сводные
данные [
Исходя из всех выше приведенных обзоров, можно сделать следующие выводы.
В рамках данной работы невозможно использовать никакую из существующих систем по управлению гипотезами. Это обусловлено тем, что они: • ориентированы на работу с статическими данными, хранящимися в базе данных; • нет гибкого инструмента построение виртуального эксперимента; имеется ориентаций на свои области применения; • не являются открытыми программными продуктами; • не носят законченного характера; некоторые модули имеют только описательный характер без практической реализации; • плохая документированность. Таблица 2 Сравнение потоковых систем Критерий Storm Поддержка языков Java программирования Режим работы Обработка сообщений Управление окном Управление ресурсами Задержка обработки Механизмы обеспечения отказоустойчивости Управление потоком Операции с сохранением состояния Потоковая примитива Пропускная способность Потоковый (tuple-wise) По крайней мере один раз (at least once) Нет, встроенными средствами
Низкая ACK записи Проблематично Нет Tuple Низкая В качестве платформы оценки качества виртуального эксперимента выбрана платформа на базе Spark Streaming. Этот выбор обусловлен следующими положениями: • текущая реализация модели течения жидкости представлена на Python; • имеется возможность расширения функционала программирования проверки статистических гипотез за счет установки дополнительных библиотек; • возможность управления окном на основе времени.
Из сравнительной таблицы потоковых систем видно, что Spark Streaming не является самой производительной системой. Её выбор обусловлен поддержкой языка Python и обеспечением минимально необходимого функционала. 3 Онтологическая спецификация 3.1 Течение жидкости
Онтологическая спецификация течения жидкости представлена на Рис. 1. Данная онтология описывает проведение реального эксперимента, при котором анализируется течение жидкости в трубе [8]. В качестве жидкости могут использоваться: вода, масло, их смесь с газом. Жидкость в рамках данного эксперимента обладает следующими свойствами: температура, скорость потока, давление. В рамках модели акустический шум и спектр являются функциями давления. Спектр в свою очередь характеризуется амплитудой и частотой, которые являются входными данными для определения величины частотного пика. Давление измеряется гидрофонами, установленными в гидродинамической трубе. Также для измерения температуры скорости потока используются дополнительные сенсоры. Данные с гидрофонов и сенсоров поступают на аналогово-цифровой преобразователь, который, в свою очередь, усиливает и дискретизирует поступающий сигнал в соответствии с заданными свойствами. В
Java, Scala Потоковый и микропакеты Строго один раз (exactly once) На основе: времени, строк, приходящих данных YARN, Built-in Низкая Распределенные снапшоты Естественно Да
Java, Scala, Python Микро-пакеты (microbatch) Строго один раз (exactly once) Только на основе времени
Средняя Микро-пакет Проблематично Да DStream Высокая эксперименте частота дискретизации составляет 100 кГц. Обработанный сигнал записывается в результирующий файл эксперимента.
Онтология предметной области соответствует реальному физическому эксперименту. Каждый эксперимент выполняется в течение 25 секунд. Затем происходит некоторое изменение в параметрах модели, затем эксперимент повторяется снова. Так на выходе получается набор результирующих файлов. Поток данных формируется искусственно с использованием этих файлов. 3.2 Управление гипотезами
Онтологическая спецификация управления гипотезами представлена на Рис. 2.
Определим некоторые термины предметной области. Виртуальный эксперимент – деятельность по применению набора гипотез для воспроизведения симуляций близких к наблюдаемому явлению. Гипотеза – формальная спецификация свойств исследуемого объекта или явления, имеющих математическое представление. Модель – алгоритм, реализующий гипотезы. Оценка качества – характеристика модели, позволяющая сделать вывод о её соответствии реальному явлению.
Статистическое тестирование – это процесс принятия решения о том, противоречит ли рассматриваемая статистическая гипотеза выборке данных. Частотный подход – аппарат проверки гипотез, базирующийся на частотном определении вероятности, т. е. вероятности как предела относительной частоты наблюдения некоторого события в серии однородных независимых испытаний. Байесовский подход – аппарат проверки гипотез, базирующийся на байесовском определении вероятности, для которой имеются некоторые априорные знания о наблюдаемом явлении. Потоковая система – программное средство, позволяющее анализировать непрерывно поступающие на ее вход данные.
Oil is a
measures request
implement has has send data has property
request has property
0..* AcousticNoise -rms:Float 0..*
VirtualExperiment 0..* Observation
Рисунок 1 Онтология течения жидкости Рисунок 2 Онтология управления гипотезами Spectrum -frequency:Float -amplitude:Float Рисунок 3 Концептуальная спецификация На базе потоковой системы реализована модель, описывающая течение жидкости в трубе. Также данная система имеет модули выполнения проверки статистических тестов. На базе результата работы модели и входных данных сформулированы гипотезы, позволяющие получить оценку качества модели. Оценка высчитывается на базе статистических тестов, заложенных в потоковой системе. В виртуальном эксперименте рассматриваются частотный и Байесовский подходы для получения оценки качества. 4 Концептуальная спецификация Концептуальная спецификация виртуального эксперимента представлена на Рис. 3.
В рамках исследуемой модели имеется априорное знание о зависимости скорости потока от a function of
has property
HydrophoneObservation
-preasure:Float 1..*
PipeObservation -temperature:Float -volrate:Float -timestamp:DateTime температуры, значении частоты пика спектра, шума потока. Также известно, что имеются корреляции между показателями гидрофонов, установленных в гидродинамической трубе. Данные разделяются на полученные из наблюдения и вычисленные из данных наблюдения. К непосредственно получаемым данным относится информация от гидрофонов и сенсоров, а именно: давление, температура, скорость потока. К вычисляемым относятся: спектр, амплитуда, акустический шум. Все эти характеристики рассчитываются на основе наблюдаемых показателей давления. Все данные, кроме временной метки, имеют вещественный тип. 5 Формат данных 5.1 Входные данные Данные, полученные в рамках реального физического эксперимента, хранятся в CSV (Comma Separated Value) файлах на распределенной файловой системе (HDFS). На вход системе поступает два вида файлов: данные, полученные с гидрофонов; данные, полученные с сенсоров.
Файл с информацией, полученной с гидрофонов, имеет следующее описание. Заголовок файла состоит из порядкового номера nm,– указатель канала гидрофона h{i}, где i – число от 0 до 2. Столбцы разделены знаком табуляции. Заголовок файла выглядит так: nm\t\h0\h1\h2.
Частота дискретизации для сбора акустических данных составляет 100 кГц. Один эксперимент длится 25 секунд. Таким образом, каждый CSV файл содержит 2,5 миллиона строк.
Файл с информацией, полученной с сенсоров, имеет следующее описание: заголовок файла состоит из timestamp – временной метки, temp – температуры, vol_rate – скорости потока, file – файла, соответствующего показателям гидрофонов. Столбцы разделены знаком “;”. Заголовок файла выглядит так: timestamp;temp;vol_rate;file Показатели температуры и скорости потока собираются один раз в секунду. Вопросы синхронизации показателей различных файлов решаются через информацию временных меток и сопоставления имен файлов в соответствующих полях. 5.2 Обрабатываемые данные
Данные для обработки в потоковой системе преобразуются в формат RDD (Resilient Distributed Dataset) – отказоустойчивый набор элементов, обработка которых может выполняться параллельно [28]. Вся логика работы с данными происходит в рамках этого концепта. Существуют два способа получения такого набора: • параллелизация последовательного массива в рамках текущей программы с помощью вызова метода parallelize(); • на этапе извлечения данных из внешних источников, таких, как HDFS, HBase, Streaming Context.
При создании распределенного набора можно как явно задать число, показывающее, сколько параллельных разделов использовать при работе с этими данными, так и использовать значение по умолчанию.
В рамках виртуального эксперимента самые «тяжелые» в вычислительном плане задачи ложатся H0 H1 на набор данных, поступивших с гидрофонов. Так как используется информация из трёх каналов, то степень параллелизма на этапе предобработки устанавливается также равной трём.
Концепт RDD имеет свой API и поддерживает два вида операций: • трансформацию – получение нового набора из существующего; • действие – запускает задание на выполнение.
При написании программы важно отслеживать область действия переменных в рамках данных видов операций.
Важными характеристиками RDD являются: • распределенность – операции над данными выполняются на различных узлах кластера; • ленивое исполнение (“lazy”) – трансформация не выполняется прямо сейчас; система хранит последовательность операций над набором; выполнение происходит, только если в коде программы встретилась операция действия; • управление состоянием – возможность выбора, из какого хранилища (память или диск) они будут повторно использоваться. 6 Подход оценки качества 6.1 Описание метода
Рассматриваемый нами метод оценки качества виртуального эксперимента опирается на классическую теорию детектирования сигнала [14]. Эта теория выступает как средство количественной оценки возможности различать информационную составляющую сигнала от шума [24]. Базовые компоненты теории детектирования представлены на Рис. 4.
Первым ее элементом является источник, который генерируют выходной сигнал. Его выход может быть одним из нескольких вариантов. В самом простом случае это гипотезы: 1 и 0. Второй и третий компоненты соответственно: механизм вероятностного перехода и пространство наблюдений. Механизм перехода может рассматриваться для определения, какая гипотеза истина. На основе этих знаний он генерирует точку в пространстве наблюдений в соответствии с некоторым законом вероятности. Независимая дискретная случайная величина , чья плотность вероятности нам известна, добавляется к выходу источника.
Decision rule
Decision Source
Probabilistic transition mechanism
Observation
space n Noise Рисунок 4 Компоненты теории детектирования
Четвертым компонентом теории детектирования сигнала является правило принятия решения. После получения наблюдаемой переменой в пространстве наблюдений мы должны угадать какая гипотеза была истинной. Правило принятия решений сопоставляет точке наблюдений одну из гипотезПодходящий выбор правил будет зависеть от факторов, которые определяются постановкой конкретной исследовательской задачи.
Мы рассматриваем оценку качества как бинарное событие, которое в математическом представлении определено в виде гипотез: 0: модель корректна; 1:происходит нарушение работы модели. Чтобы сделать предположение о качестве модели, необходимо выполнить статистическую проверку данных. быть метод.
Одним из параметров, передаваемых на вход нашей системы
один измеренная величина раз в
секунду, является скорости потока. В рамках проведения виртуального эксперимента модель выдавала вычисленную величину ̂ скорости потока. Оценивая их разность ̂ − на протяжении 25 секунд, можно сделать вывод об оценке качества модели при заданных условиях эксперимента.
Известно, нормальному что закону разность ̂ −
подчиняется распределения [8].
Таким образом, в качестве аппарата проверки гипотез могут использованы следующие подходы: классический или частотный метод; Байесовский 6.2 Частотный подход
В рамках классического подхода вероятность определяется наступления
как события.
относительная Все события частота имеют независимый характер. Общая методика проведения статистического тестирования широко представлена в литературе (см., например, [35]). возьмем разность = ̂ − контрольного значения
шкала [20] доказательной силы Байесовского критерия приведена в Таблице 3. распределение свободы: Статистика критерия имеет Стьюдента с − 1 степенями ( )= ( ̅ − )√
где выборочное среднее ̅ = дисперсия 2 = 1 ∑ −1 =1( − ̅)2.
Пусть задан уровень значимости = 0.05. В нашей задаче
используем альтернативу.
Таким образом, двухстороннюю статистический критерий будет иметь вид | | > /2, где квантиль распределения Стьюдента с – − 1 степенями свободы. Если | | > /2, то нулевая ~ ( − 1), 1 ∑ =1 , выборочная гипотеза 0 отвергается. 6.3 Байесовский подход
Байесовский подход отличается от классического тем, что в своей основе имеет другое определение вероятности (она интерпретируется как мера незнания, а не как объективная случайность [33]). В общем виде вероятность определяется как степень уверенности в истинности суждения. Мы имеем некоторое априорное знание о наблюдении, которое уточняется в процессе эксперимента.
Байесовская проверка в рамках теории детектирования базируется на двух предположениях: • выходы источника регулируются вероятностным присвоением, они обозначаются 1 и 0 и называются априорными вероятностями, которые представляют собой информацию об источнике до проведения эксперимента; • каждому из возможных исходов присваивается стоимость; обозначим стоимости 4-х исходов С00, С10, С01, С11; первый индекс указывает на выбранную гипотезу, второй – на ту, которая истинна; после каждого эксперимента стоимости могут уточняться. • Правило принятия решения должно быть таким, чтобы меньше.
средняя
стоимость
Описание архитектуры Для проведения вычислительного эксперимента в рамках поставленных задач был собран программноаппаратный вычислительный комплекс: аппаратная часть построена на базе серверов и коммутатора фирмы
Quanta [23];
программная
часть
–
программный
кластер
на
базе
продукта HDP
(Hortonworks Data Platform) [
Каждый сервер выполняет определенную роль в кластере, которая определяет его технические характеристики.
Технические характеристики управляющих и рабочих узлов представлены в Таблице 4. Таблица 4 Характеристики узлов Характеристика Тип процессора Количество ядер Память Тип дисков Объем дисков Резервирование дисков Подключение дисков Операционная система Сетевые интерфейсы Значение
40/24 32/64ГБ SSD, HDD 240ГБ, 2/4ТБ
CentOS 6.9 10GbEthernet Роли серверов в кластере: • m1, m2 – управляющие
узлы, к в – предъявляются повышенные требования в плане производительности и надежности; на установлены компоненты, отвечающие распределение задач по рабочим узлам кластера, такие, как Name Node сервиса
Active-Passive; в качестве Active сервера для большинства из них выступает узел m1; • s1, s2, s3, s4 рабочие узлы;
основной вычислительный элемент кластера обеспечивает выполнение программного кода приложений в распределенной среде; выход из строя такого узла не является критическим, так как их состояние постоянно отслеживается управляющими узлами, которые в случае падения перезапустят задачу на оставшихся доступных серверах, однако
это приведет к замедлению выполнения расчетов на кластере.
Доступ к компонентам управления платформы осуществляется из общей сети лаборатории за счет ним них за подключения коммутатора кластера с общим маршрутизатором по интерфейсу 1GbEthernet. 7.2 Программная часть
Для построение вычислительной системы была использована платформа HDP версии 2.6. Эта версия является последней актуальной на момент написания этой статьи. На аппаратные сервера был установлен минимально необходимый набор программных компонент для проведения виртуального эксперимента: • HDFS [7] – отказоустойчивая распределенная
файловая система; • YARN [22] – менеджер ресурсов, основной
планировщик задач, запускаемых на кластере;
• Storm [
Flink [2] – системы потоковой обработки
данных;
• Kafka [3] – виртуальная очередь;
• Ambari [
кластером; • ZooKeeper [17] – сервер координации работы
распределенных приложений;
• Zeppelin [
Все представленные ниже компоненты, кроме Apache Flink, входят в установочный пакет HDP кластера. Flink установлен дополнительно как сервис над YARN. Установка одновременно трёх потоковых систем в рамках одного кластера обусловлена тем, что в настоящий момент нет единой методологии оценки. Поэтому типовым является сценарий, когда существующая практическая задача в тестовом виде реализуется одновременно на всех платформах, а уже затем сравнивается производительность, полученная на практике. Также на момент развертывания кластера были неизвестны ограничения всех систем, и соответственно не было принято решение о применимости конкретного продукта для реализации виртуального эксперимента. 8 Поток работы
Поток работ виртуального эксперимента представлен на Рис. 5.
Виртуальный эксперимент заключается в одновременной непрерывной работе следующих компонент над потоком входных данными: • Producer – программа, занимающаяся извлечением данных из csv-файла и отправляющая сообщения в очередь Kafka; • Kafka – обслуживает прием, промежуточное
хранение, репликацию данных; • Spark Streaming – выполняет роль Consumer, извлекает данные из очереди в формате RDD и передает их на обработку в ядро Spark. • Spark – выполняет вычисления с данными, вызывает модель течения жидкости, проводит статистические тесты оценки качества модели. Этапы потока работ таковы: 1. Данные, полученные в результате физического эксперимента, хранятся в распределенной файловой системе. Producer представляет собой программный модуль, реализованный на Python. Этот компонент первым шагом извлекает данные из CSV-файлов, содержащих показатели гидрофонов, значения температуры и скорости потока и формирует два массива строк; 2. Подготовка данных к отправке заключается в разбиении полученных массивов строк на партии по 100 тыс. значений для показателей гидрофонов и одного – для температуры и скорости потока; 3. Отправка сообщений осуществляется с помощью вызова метода send() из загруженной библиотеки kafka-python [19]. Этот метод является ассиметричным. Для увеличения скорости отправки значение Ack выставлено в 0, чтобы Producer не ждал от Kafka-пакета подтверждения доставки. Так как кластер находится в изолированном сетевом сегменте и на серверах используются высокоскоростные сетевые интерфейсы, то потерь пакетов не происходит; 4. Из-за ограничений Spark Streaming как потоковой системы [6], а именно: a) имеется только временное управление
окном; b) реализованы чтение данных из всех разделов очереди и запись их в одну
RDD; c) недостаточна производительность работы ядра Spark из-за использования промежуточного слоя Pythonинтерпретатора и самой архитектуры
Spark; d) не реализован функционал Backpressure
стандартными средствами; возникла необходимость в оптимизации гиперпараметров модели. Изначально предполагалось подавать на вход модуля обработки данных из очереди 100 тыс. сообщений в секунду. За данный интервал времени Spark должен их успевать обрабатывать. Однако, таких скоростей: как обработки, так и подачи в очередь достигнуть не удалось. Поэтому возникла необходимость в увеличении временного интервала отправки партии сообщений; 5. Слияние полученных признаков в один кортеж
для отправки его на вход модели; 6. Расчет модели на базе полученных входных данных. Распределение задания расчета модели по кластеру выполняется ядром Spark, исходя из своей внутренней логики работы; 7. Проведение статистического теста. Для оценки качества модели мы используем одновыборочный T-тест с двух сторонней альтернативой или Байесовский подход. На выходе мы имеем строку с результатом в формате: a. число – для оценки в случае байесовского критерия; b. True/False – для оценки статистического
критерия; 8. Вывод результата в консоль.
Start
Read data from
csv files Features Extraction
Producer Prepare data to send
Send data to queues
Kafka Processing queues
Spark Streaming Receive data from
kafka Optimization model hyperparameters FFT Cut Peak
RMS
RMS
Temp
RMS
VolRate Node 1
Node 2
Node 3
Node 4 Stop
Console
Output Result Рисунок 5 Поток работ 9 Полученный результат
По результатам проведенного эксперимента получены данные, представленные в Таблице 6. Цветом подсвечены результаты оценки качества виртуального эксперимента различными методами. Использованы следующие обозначения: • белый – модель корректно описывает входные
данные (Гипотеза 0); • серый – модель не корректна (Гипотеза 1). Таблица 6 Полученный результат
Join Features and
VolRate Spark
Model Processing По полученным результатам можно определить момент, когда модель начинает некачественно описывать поведение течения жидкости по входным данным. Результаты обоих методов схожи, но всё же немного отличаются, так как мы попали в граничные области Баейсовского критерия (3,3046), которые имеют слабую доказательную силу, поэтому отвергнуть гипотезу 0 о том, что модель корректна, нельзя. 10 Заключение
Представлен подход, позволяющий оценить качество научных гипотез на примере области течения жидкости. Его идея базируется на классической теории детектирования, в рамках которой в качестве правил принятия решения выступают критерий Стьюдента и критерий правдоподобия.
Разработаны онтология предметной области и концептуальная схема виртуального эксперимента для исследования характеристик течения жидкости в трубе на основе его акустического шума. Произведен анализ существующих инструментов организации распределенной обработки потоковых данных.
Выполнено исследование подходов к организации методов проверки гипотез и оценки [30] Ünalmis, Ö.H.: Subsea Multiphase Flowmeter: [36] Самарев, Р.С.: Обзор состояния области Performance Tests in Multiphase Flow Loop. Society потоковой обработки данных. Труды ИСП РАН, of Petroleum Engineers (1), сс. 231-260 (2017) [31] Wilcox, D.C.: Turbulence modeling for CFD. D C W [37] Скворцов Н.А., Аввакумова, Е.А., Брюхов, Д.О.,
Industries (2006) Вовченко, А.Е., Вольнова, А.А., Длужневская, [32] Zagarola, M.V., Smits, A.J.: Mean-flow Scaling of О.Б., Кайгородов, П.В., Калиниченко, Л.А., Turbulent Pipe Flow. J. of Fluid Mechanics, 373, Князев, А.Ю., Ковалева, Д.А., Малков, О.Ю., pp. 33-79 (1998) Позаненко, А.С., Ступников, С.А.: [33] Байесовский подход к теории вероятностей. Концептуальный подход к решению задач в Примеры Байесовских рассуждений. Глава 6. астрономии. Астрофизический бюллетень, 71 (1), 2007. http://www.machinelearning.ru/wiki/images/ сс. 122-133 (2016) 4/43/BayesML-2007-textbook-2.pdf [38] Тарасов, Е.А.: Сокращение числа виртуальных [34] Критерий Стьюдента. http://www. экспериментов с помощью оценки корреляций machinelearning.ru/wiki/index.php?title=Критерий параметров взаимодействующих гипотез. Сб. _Стьюдента трудов XVIII Межд. конф. DAMDID/RCDL, сc. 383-388 (2016) [35] Проверка статистических гипотез. http://www.
machinelearning.ru/wiki/index.php?title=Проверка_ статистических_гипотез