CEUR Publication

Fifth Conference on Software Engineering andInformation Management (SEIM-2020)

(full papers)Saint Petersburg, May 16, 2020

Peter Trifonov, Anna Yarygina (editors)

Saint Petersburg — 2020

Fifth Conference on Software Engineering and Information Management (SEIM-2020)Saint Petersburg, May 16, 2020

Peter Trifonov, Anna Yarygina (editors)

This volume contains twelve selected papers originally presented at the Fifth Conference onSoftware Engineering and Information Management (SEIM-2020), which was held in SaintPetersburg, Russia, on May 16, 2020. These papers were selected in thorough single-blindreviewing process.

ISBN 978-5-6043167-3-3

Формат 215х275. Печать цифровая.Тираж 40 экз. Заказ № 310108Отпечатано в ООО "Цифровая фабрика "Быстрый Цвет".197022, Санкт-Петербург, наб. реки Карповки, д.5, корп.16.(812) 644-40-44

Originally published online by CEUR Workshop Proceedings(CEUR-WS.org, ISSN 1613-0073, volume 2691)

Copyright c© 2020 for the individual papers by the papers’ authors. Copyright c© 2020 forthe volume as a collection by its editors. This volume and its papers are published underthe Creative Commons License Attribution 4.0 International (CC BY 4.0).

Table of Contents

Message from the Editors 4

SEIM-2020 Organization 5

Integration approach for automatic speech recognition of noisy Russian language DaniilGomonuk, Igor Nikiforov and Dmitriy Drobintsev 6

Fault Tolerant Distributed Hash-Join in Relational Databases Arsen Nasibullin and BorisNovikov 11

Energy Consumption Measurement Frameworks for Android OS: A Systematic LiteratureReviewVladislav Myasnikov, Stanislav Sartasov, Ilya Slesarev and Pavel Gessen 18

Worm-like image descriptor for signboard classificationAleksei Samarin and Valentin Malykh 30

Predicting earthquakes by anomalies in the ionosphereDaria Chaplygina and Natalia Grafeeva 34

Практические аспекты использования графов знаний для моделирования телекомму-никационных сетейIgor Kulikov and Nataly Zhukova 39

An analysis and optimization of primitive type boxings in Kotlin/NativeAlexander Kuznetsov 44

Meaning Error RateLiudmila Gordeeva, Vasily Ershov, Igor Labutin and Igor Kuralenok 51

Анализ времени связывания для реляционных программIrina Artemeva and Ekaterina Verbitskaia 58

Light Invariant Lane Detection Method Using Advanced Clustering Techniques Rami I. Al-Naim and Aleksandr Karavaev 66

MIRF 2.0 — a framework for distributed medical images analysisAlexandra Shvyrkova, Alexander Lomakin, Angelina Chizhova, Yurii Litvinov, Egor Ponomarev, AlexeyFefelov and Alexander Savelev 73

Successive Cancellation Permutation Decoding of Extended BCH codesNikolai V. Iakuba and Peter V. Trifonov 80

3

Message from the Editors

The Fifth Conference on Software Engineering and Information Management (SEIM-2020) opens its doors to young researchers and practitioners in different areas of computerscience and software engineering, providing an opportunity to present their research, discussstate-of-the-art technology and engage in useful networking. As before, we consider SEIMto mainly focus on researchers who are just starting out their scientific careers, and hope toease their introduction to the conference process. On the other hand, SEIM might also beof interest to more experienced researchers, who are aimed at sharing their research with awider scientific community.

The conference welcomes submissions on a wide range of topics, including but not limitedto:

• Algorithms and data structures• Big data• Cloud systems• Coding theory• Compilers• Crowdsourcing• Data storage and processing• Development management• Digital signal processing• Distributed systems• E-commerce / e-government• Empirical software engineering• High-performance computing• Information retrieval• Information security• Intelligent data analysis• Internet of Things• Machine learning

• Mobile systems• Modelling• Natural language processing• Networks and telecommunications• (Non-)relational databases• Operating systems• Programming languages• Recommendation systems• Robotics• Semantic web• Social networks• Software analysis• Software testing• Software verification• Software virtualization• Software-defined networks• Theoretical computer science• Visual languages

This year we received 64 papers, each reviewed by at least 3 members of the ProgramCommittee, of which 12 were selected for publication in CEUR-WS.org, 10 for indexing inRSCI. We would like to thank the members of our Program Committee for their continuouswork and contribution to the success of our conference.

These proceedings include the SEIM-2020 papers, which were selected by the ProgramCommittee for publication in CEUR-WS.org. These papers passed not only the originalreview procedure, but also an additional round of post-review with the conference feedback.We thank the authors for their submissions to SEIM-2020 and hope to see them in the future.

Furthermore, we would also like to thank Tatiana Mironova, Sergey Zherevchuk andSvyatoslav Mikhailov for their great help in organizing the conference, Computer ScienceCenter for hosting the event, and JetBrains Research for their overall support. The additionalinformation about the SEIM conference series can be found on the conference website at:http://2020.seim-conf.org/

Peter Trifonov, Anna Yarygina (editors)4

http://2020.seim-conf.org/

SEIM-2020 Organization

The conference was organized jointly with Computer Science Center and supported by JetBrains Research.

Steering CommitteeDmitry Bulychev / St. Petersburg State UniversityVladimir Itsykson / St. Petersburg Polytechnic UniversityAndrey Ivanov / JetBrainsIakov Kirilenko / St. Petersburg State UniversityKirill Krinkin / St. Petersburg Electrotechnical UniversityBoris Novikov / National Research University Higher School of Economics

Program Committee ChairsPeter Trifonov / St. Petersburg Polytechnic UniversityAnna Yarygina / Wrike

Program CommitteeMarat Akhin St Petersburg Polytechnic UniversitySergey Bezzateev ITMO UniversityDaniil Berezun HSE UniversityNikita Bobrov St Petersburg State UniversityNatalia Bogach St Petersburg Polytechnic UniversityPavel Braslavski Ural Federal UniversityTimofey Bryksin JetBrains ResearchDmitry Boulytchev St Petersburg State UniversityEkaterina Verbitskaya St Petersburg State UniversityViacheslav Galaktionov St Petersburg State UniversityNatalia Grafeeva St Petersburg State UniversityValentin GrigorievDmitry Grigorev St Petersburg State UniversitySemyon Grigorev St Petersburg State UniversityDaria Dzendzik ADAPT CentreMark Zaslavskiy JetBrains ResearchVladimir Itsykson St Petersburg Polytechnic UniversityEvgeny Kalishenko St Petersburg Electrotechnical UniversityAleksandr Kapitonov ITMO UniversityIakov Kirilenko St Petersburg State UniversityEvgeniy Klyuchikov St Petersburg State UniversityVladimir Kovalenko Delft University of TechnologyKirill Krinkin St Petersburg Electrotechnical UniversitySvetlana Lazareva RaidixYurii Litvinov St Petersburg State UniversityDmitry Luciv St Petersburg State University

Igor Malyshev St Petersburg Polytechnic UniversityElena Mikhailova St Petersburg State UniversityDmitry Mordvinov St Petersburg State UniversityBoris Novikov HSE UniversityAndrey Ovchinnikov St Petersburg University of AerospaceInstrumentationDaria Pado HSE UniversityOleg Pliss OracleNikita Povarov JetBrainsAnton Podkopaev HSE UniversitySergey Salishev St Petersburg State UniversityStanislav Sartasov St Petersburg State UniversityYuri Senichenkov St Petersburg Polytechnic UniversityKirill Smirnov St Petersburg State UniversityDarja Solodovnikova University of LatviaSergey Stupnikov Institute of Informatics Problems RASMaksim Tkatchenko Singapore Management UniversityArtem Trofimov YandexAndrey Turlikov St Petersburg University of AerospaceInstrumentationAnton Filatov St Petersburg Electrotechnical UniversityArtem Filatov St Petersburg Electrotechnical UniversityDmitry Tsitelov DevexpertsMikhail Zymbler South Ural State UniversityGeorge Chernishev St Petersburg State University

5

Интеграционный подход распознаваниязашумленной русскоязычной речи

Даниил Гомонюк∗, Игорь Никифоров†, Дмитрий Дробинцев‡Высшая школа программной инженерии

Санкт-Петербургский Политехнический УниверситетСанкт-Петербург, Россия

Email: ∗dan.gomonuk@gmail.com, †igor.nikiforovv@gmail.com, ‡drobintsev_df@spbstu.ru

Аннотация—Исследовательская работа посвящена мето-дам автоматического преобразования аудиозаписей в тексто-вый формат - распознаванию речи.

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

В работе предоставления обзор существующих методовраспознавания, которые включают "интегральные"и "ги-бридные"методы. Приведен сравнительный обзор существу-ющих реализаций рассмотренных методов и их метрики.На основе сравнительного анализа делается вывод, что тех-нология "Mozilla DeepSpeech"наиболее мощный инструментраспознавания.

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

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

Ключевые понятия—распознавание речи, зашумленнаяречь, аудиозапись, Mozilla DeepSpeech, Baidu, Kaldi

I. ВведениеИнновационные подходы и технологии с каждым днем

все больше и больше интегрируются в устоявшихся го-дами сферах жизнедеятельности человека. Не являетсяисключением и применение методов машинного обучениядля распознавания аудиозаписей. Так, например, распо-знавание речи по аудиозаписям позволяет повысить эф-фективность служб клиентской поддержки, даёт возмож-ность проводить аналитику звонков [1], избегая проблемс соблюдением закона “О персональных данных”, так какзачастую в аудио-звонках упоминается конфиденциальнаяинформация [2]. Ниже перечислены две основные группыметодов: основанные на применении скрытых марковскихмоделей и методы, основанные на нейронных сетях.

Описание методов, основанных на применении скрытыхмарковских моделей (далее СММ), можно найти, напри-мер, в работе [3]. Инструменты на основе этих методовочень точны, но требуют составления словаря, соотнося-щего слово и его фонемы (например слово “ноль” разби-вается на фонемы “n” “oo” “ll”). Такая система не сможет

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

лить на "интегральные"и "гибридные"[4] методы. Несмотряна то, что они подходят для распознавания спонтаннойречи, они не избавлены от недостатков:

• качество распознавания во многом зависит от каче-ства исходной аудиозаписи, что накладывает высокиетребования на качество исходной аудиозаписи;

• отсутствие универсальных методов и реализующих ихбиблиотек. Зачастую для каждой конкретной задачинеобходимо создавать свое собственное решение;

• для каждого языка (например, русского, английского,китайского), приходится проводить дополнительнуюнастройку систем распознавания.

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

ционного метода распознавания русской речи при наличиишума.

II. Технологии распознавания речи, основанные нанейронных сетях

Существует большое количество инструментов и тех-нологий распознавания речи, основанные на нейронныхсетях. К ведущим решениям с открытым исходным кодомможно отнести Mozilla DeepSpeech и Kaldi. Все методыделятся на две группы: интегральные и гибридные. Гибрид-ные решения состоят из множества отдельных компонен-тов, ошибка в одном компоненте может привести к про-блемам в других и повлиять на общий результат (качествораспознавания). Создание гибридных решений сложнее,

Copyright c© 2020 for this paper by its authors.Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).

6

Таблица IСравнение различных моделей распознавания речи [4]

Модель Технология Речевой корпус WER %Гибридные СММ/ИНС модели

CNN Torch7 WSJ (Nov’92) 6.7Kaldi-dnn5b-pretrain-dbn-dnn-smbr recipe Kaldi WSJ (Nov’92) 3.35

CTC моделиRNN-CTC + Kaldi + trigram LM Kaldi WSJ (Nov’92) 6.7

LSTM-CTC + trigram LM Eesen WSJ (Nov’92) 7.9Шифратор-дешифратор модели

CNN + RNN + CTC Baidu WSJ (Nov’92) 4.42CNN + ASG Torch7,Baidu LibriSpeech 7.2

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

III. Сравнительный анализ существующих реализацийсистем автоматизированного распознавания речи

A. Метрики оценки систем автоматизированного распо-знавания речи

Корректная оценка результатов работы систем автома-тизированного распознавания речи (англ. automatic systemrecognision, далее ASR системы), и как следствие воз-можность корректно сравнить разные ASR системы, имеетбольшое значение как для конечных пользователей, так идля разработчиков таких систем. В данной работе пред-ставленные метрики будут использоваться не только длясравнения систем, но и для оценки конечного результатаработы предложенного метода. Для ASR систем существу-ет две основные группы метрик оценивания [5]:

• метрики точности распознавания;• метрики скорости распознавания.Основным способом оценки точности распознавания яв-

ляются метрики, основанные на расстоянии Левенштейна[6]. Расстояние Левенштейна — это метрика, опреде-ляющая разницу между двумя символьными последова-тельностями. Она рассчитывается как количество опера-ций удаления, вставки и замены преобразовывающих однупоследовательность символов в другую. Наиболее распро-страненными метриками, основанными на расстоянии Ле-венштейна, являются WER - количество ошибочных слов впредложении и SER количество ошибочных предложений.

Важным параметром любой системы является скоростьее работы. Для ASR метрикой, на основе которой вычис-ляется скорость работы, является метрика SF(RT). Онасчитается как отношение скорости обработки аудиофайлак длительности этого аудиофайла. К примеру, если файлдлительность в одну минуту обрабатывается тридцать се-кунд, то SF = 0.5.

Естественным условием для сравнения разных ASR-систем с помощью этой метрики является запуск тестовна одинаковом оборудовании

B. Сравнительный анализ ASR по метрике WERПроведём сравнительный анализ различных моделей

для распознавания речи, по трём основным группам:гибридные СММ/ИНС модели, CTC-модели, шифратор-дешифратор модели на основе механизма внимания. Возь-мём только две лучше модели в каждой группе по показа-телю WER.Гибридные СММ/ИНС модели состоят из блока скры-

тых марковских моделей(СММ) определяющего наиболеевероятную последовательность фонем и блока искусствен-ной нейронной сети(ИНС), которая вычисляет вероятностьпоследовательности полученную от СММ.CTC (Connectionist Temporal Classification) позволяет

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

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

набора англоязычных аудиозаписей WSJ(Nov’92)[7] иLibriSpeech[8]. Оба этих набора являются стандартамидля тестирования англоязычных ASR.Как можно увидеть из Таблицы I. однозначными лиде-

рами по показателю WER являются технологии Kaldi иBaidu. Далее мы будем использовать их реализации: vosk- реализацию Kaldi для русского языка и DeepSpeech -открытый проект компании Mozilla реализующий техно-логию Baidu.Даже на этой небольшой выборке видно насколько об-

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

7

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

Другими словами, предлагается сделать ансамбль ASRсистем с коррекцией ошибок.

IV. Интеграционный подход распознавания зашумленнойречи

A. Описание методаОсновные этапы предложенного подхода: проводится

очистка аудиозаписи от шумов, после этого выполняетсяее распознавание с помощью нескольких разных системавтоматического распознавания речи. Полученные резуль-таты составят список наиболее вероятных гипотез (N-Best-List)[12], выбор из которых может произвести либооператор-человек, либо система контекстного анализа.

Рис. 1. Cтруктурная схема предлагаемого подхода

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

Первый этап, предобработка аудио. Аудиозапись приво-дится к заданному формату с конкретной частотой дискре-тизации. Затем производится очистка от шумов, напримерс помощью быстрого преобразования Фурье (далее БПФ).Очищенная от шумов аудиозапись разбивается на болеемелкие по паузам, тем самым решается несколько про-блем: во-первых, мы заранее знаем где были паузы - т.е.законченные мысли и можем это использовать при выдачеконечного результата, во-вторых, мы частично избежимпроблемы смешения дикторов.Второй этап, распознавание аудио. Полученные ауди-

озаписи помещаются в базу данных и маркируются какотносящиеся к одному тексту. Каждая аудиозапись от-правляется параллельно во все системы ASR, на выхо-де которых мы получаем варианты распознанной фразы.После обработки всех аудиозаписей и получения наборовраспознанных фраз можно приступать к анализу текстов.Третий этап, коррекция ошибок. Сначала мы исправля-

ем ошибки в каждой фразе - сравнивая её с вариантами отдругих ASR, и составляем наиболее полное предложение.Затем в этом предложении проводится обработка после-довательностей, разделенных пробелами - мы определяемявляется ли последовательность словом, если нет, то какиеварианты слов из алфавита могут ей соответствовать. Еслипоследовательность невозможно распознать она маркиру-ется спецсимволом MASK.Четвертый этап, коррекция ошибок на основе контекста.

На данном этапе с помощью ручного или автоматическогоанализа контекста выявляется, составляют ли полученныефразы осмысленный текст. Автоматический анализ кон-текста предлагается производить с помощью BERT.

B. АлгоритмПредложенный метод призван уменьшить количество

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

ление наиболее вероятных вариантов фраз происходит последующему алгоритму (описан для трех систем).

• проверяем не состоит ли фраза из одного слова;• удаляем все пробельные символы и определяем явля-

ется ли получившийся результат словом с заданнымредакционным расстоянием;

• если предыдущий пункт верен, обработку можно счи-тать завершенной.

Все три варианта фразы сортируются по следующимпараметрам:

• совпадения количества пробельных символов унескольких фраз, это свидетельствует о правильномопределении границ слов;

• совпадения длины строки;

8

• по количеству точно распознанных слов (сколько словиз фразы есть в словаре);

• по приоритету ASR, если по какой-то причине мыдоверяем одной из ASR больше.

После сортировки принимаем первую фразу за истин-ную. Выравниваем фразы, по совпадающим словам, за-меняя пробелы вокруг совпавших слов на спецсимволы.Таким образом мы получаем границы, правильно распо-знанных участков.

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

Таким образом, получаем лучшую из возможных ком-бинацию результатов, в которой не распознанные участ-ки помечены спецсимволом MASK. Если предложение неудалось распознать полностью, то фраза анализируетсяс помощью BERT - анализатора контекста от компанииGoogle.

C. Особенности очистки от шумаОдной из задач, которую необходимо было решить в

рамках данной работы, является задача предобработкизвука и удаления шумов. Нам необходимо это сделать нетолько для уменьшения вероятности ошибки, но и длябольшей однородности записей.

Есть два основных способа решения этой проблемы:модели на основе рекуррентных нейронных сетей, и раз-личные алгоритмы спектрального анализа. В работе былпроизведен сравнительный анализ двух инструментов, ре-ализующих эти подходы: RNNoise и ffmpeg.

В рамка проекта ffmpeg разработан фильтр afftdn, пред-назначенный для очистки аудио от шума. В основе этогофильтра лежит алгоритм БПФ.

RNNoise — это свободный инструмент, основанный нарекуррентной нейронной сети с типом ячеек GRU. МодельRNNoise обученная на различных видах шумов, пытаетсяанализировать аудиозапись и вычленять различные видышума.

При практическом использовании оказалось, что фильтрafftdn справляется с задачей лучше RNNoise, и работаетбыстрее, поэтому для очистки шумов был выбран именноон.

D. Реализация подходаДля реализации предложенного подхода разработана

программная система, отвечающая следующим требовани-ям:

1) возможность встраивания новых процедур для обра-ботки аудиозаписи;

2) возможность параллельного распознавания аудиоза-писей с помощью ASR, следовательно необходимавозможность одновременного использования одногоаудио файла;

3) удобство использования и замены разных ASR ис-пользующих разные библиотеки;

4) предоставление кроссплатформенного интерфейсадля работы с системой.

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

“Клиент-Сервер“, тем самым обеспечивает кроссплатфор-менность системы. Использование REST-сервиса предо-ставляет широкие возможности для клиентских приложе-ний. Клиентское приложение может быть написано подпрактически любую операционную систему, под практиче-ски любую платформу (включая мобильную), и практиче-ски на любом языке программирования. Вместо аутенти-фикации пользователя REST-API сервис реализует простойспособ защиты данных пользователей. При загрузке файлаклиент получает уникальный ключ, полученный на основепереданной аудиозаписи, вычисленный с использованиемхеш-функции. Результат распознавания предоставляетсяв ответ на получение этого ключа. Для предотвращенияперехвата ключа, связь между клиентом и сервером реа-лизована через протокол HTTPS.Для того чтобы повысить отклик программной системы

каждый из перечисленных сервисов должен иметь возмож-ность обрабатывать аудиозаписи независимо. Это сложнореализовать при обработке всей аудиозаписи целиком, по-этому решено разбивать аудиозапись на меньшие отрезкиориентируясь на паузы в речи. По умолчанию, разбиениеосуществляется на группы, в которых встречается 100 паузпо 2 секунды. Эти два параметра (длина интервала паузыи количество пауз) настраивается в системе для гибкогоконфигурирования и получения наилучшего качества рас-познавания. Чтобы сервисы имели возможность одновре-менно работать с одним и тем же участком аудиофайлакаждый участок загружается в сервис хранения файловоткуда любой другой сервис может его получить. Разбие-ние позволило не только использовать независимость сер-висов, но и снизило время ожидания пользователем перво-го предложения. Независимость работы всех компонентовпозволила использовать все ASR-системы одновременно,тем самым обеспечив параллельность системы на этапераспознавания аудиозаписи.В качестве конкретных инструментов для реализации

были выбраны:

1) язык разработки - Python3.6;2) очередь задач - Redis;3) сервис конвертации и очистки от шума - ffmpeg;4) сервис диаризации - pyAudioAnalysis;5) сервис хранения файлов - Scality S3;6) сервисы ASR - Kaldi, DeepSpeech, CMUSphinx.

9

E. РезультатыРезультаты работы программной системы были оценены

по показателям WER и SF, описанных в пункте III-A.Тестовые записи, взятые из набора русскоязычных аудиоopen_stt, обладают следующими характеристиками:

• 15 минут записи - 1400 слов;• 17Мб;• 128 Kbit/sec;• 3% шума.Замеренные показатели сравнивались со средним значе-

нием трех ASR систем, лежащих в основе программнойсистемы. На проверочном наборе данных предложеннаясистема показала ухудшение по показателю SF в среднемна 27%. Другими словами, программная система работаетмедленнее, что объясняется большим количеством компо-нентов. По показателю WER программная система пока-зала результаты лучше на 7%, снизив количество ошибокза счет контекстного анализа.

V. ЗаключениеВ работе приведен обзор методов преобразования ауди-

озаписей в текст. Проведен сравнительный анализ су-ществующих реализаций для рассмотренных методов, наоснове которого сделан вывод что интегральные системыпока что немного уступают в точности распознаваниягибридным СММ/ИНС моделям.

Представлен интеграционный подход, который комби-нирует различные ASR с системами улучшения аудио иобработкой текста.

Приведены детали реализации и проведен анализ ре-зультатов по двум метрикам качества, который показываетвыигрыш используемого метода над существующими под-ходами.

Список литературы[1] Using the Doc2Vec Algorithm to Detect Semantically Similar Jira Issues

in the Process of Resolving Customer Requests Kovalev, A., Voinov,N., Nikiforov, I. 2020 Studies in Computational Intelligence

[2] Федеральный закон от 27.07.2006 n 152-фз (ред. от 31.12.2017) "Оперсональных данных"

[3] Балакшин Павел Валерьевич. Алгоритмические и программныесредства распознавания речи на основе скрытых марковскихмоделей для телефонных служб поддержки клиентов: диссер-тация кандидата технических наук: 05.13.11 / Балакшин Па-вел Валерьевич;[Место защиты: Федеральное государственноеавтономное образовательное учреждение высшего образования«Санкт-Петербургский национальный исследовательский универси-тет информационных технологий, механики и оптики»].- Санкт-Петербург, 2015.- 127 с.

[4] Марковников, Н. М., и И. С. Кипяткова. Аналитический обзоринтегральных систем распознавания речи. Труды СПИИРАН, т. 3,вып. 58, June 2018, сс. 77-10, doi:10.15622/sp.58.4.

[5] Карпов Алексей Анатольевич, Кипяткова Ирина Сергеевна. "Мето-дология оценивания работы систем автоматического распознаванияречи"Известия высших учебных заведений. Приборостроение, vol.55, no. 11, 2012, pp. 38-43.

[6] Прытков В.А. "Функция расстояния между строками на основекусочно-постоянной модели"Доклады Белорусского государствен-ного университета информатики и радиоэлектроники, no. 4 (74),2013, pp. 22-28.

[7] Paul, Douglas B. and Janet M. Baker. “The design for the wall streetjournal-based CSR corpus.” ICSLP (1992).

[8] V. Panayotov, G. Chen, D. Povey and S. Khudanpur, "Librispeech:An ASR corpus based on public domain audio books,"2015 IEEEInternational Conference on Acoustics, Speech and Signal Processing(ICASSP), Brisbane, QLD, 2015, pp. 5206-5210.

[9] Makovkin K.A. [Hybrid models – Hidden Markov Models/Multilayerperceptron and their application in speech recognition systems. Servey].Rechevye tehnologii – Speech Technology. 2012. vol. 3. pp. 58–83. (InRuss.).

[10] Markovnikov N.M., Kipyatkova I., Karpov A., Filchenkov A. Deep neuralnetworks in Russian speech recognition. Proceedings of 2017 ArtificialIntelligence and Natural Language Conference. 2017. pp. 54–67

[11] Levenshtein V.I. Binary codes capable of correcting deletions, insertions,and reversals. Soviet physics. Doklady. 1996. vol. 10. pp. 707–710.

[12] Yen-Lu Chow and Richard Schwartz. 1989. The N-Best algorithm:an efficient procedure for finding top N sentence hypotheses. InProceedings of the workshop on Speech and Natural Language(HLT ’89). Association for Computational Linguistics, USA, 199–202.DOI:https://doi.org/10.3115/1075434.1075467

[13] Ronzhin A.L., Karpov A.A., Li I.V. Rechevoj i mnogomodal’nyjinterfejsy [Speech and multimodal interfaces]. М.: Nauka. 2006. 173p. (In Russ.).

[14] Kipyatkova I., Karpov A. DNN-Based Acoustic Modeling for RussianSpeech Recognition Using Kaldi. International Conference on Speechand Computer. 2016. pp. 246–253.

[15] LeCun Y., Bengio Y. Convolutional networks for images, speech, andtime series. The handbook of brain theory and neural networks. 1995.vol. 3361. no. 10. pp. 1995.

[16] Романенко А.Н., Матвеев Ю.Н., and Минкер В.. "Перенос знаний взадаче автоматического распознавания русской речи в телефонныхпереговорах"Научно-технический вестник информационных техно-логий, механики и оптики, vol. 18, no. 2, 2018, pp. 236-242.

[17] Povey D. et al. The Kaldi speech recognition toolkit». IEEE 2011workshop on automatic speech recognition and understanding. IEEESignal Processing Society. 2011. 4 p.

[18] Comparing Speech Recognition Systems (Microsoft API, Google APIAnd CMU Sphinx) Këpuska V, Bohouta G

[19] Zaity B., Wannous H., Shaheen Z., Chernoruckiy I., Drobintsev P.,Pak V. "A hybrid convolutional and recurrent network approach forconversational AI in spoken language understanding."(2019).

Integration approach for automatic speech recognition ofnoisy Russian language

Daniil Gomonyuk, Igor Nikiforov, Dmitry DrobintsevHigher School of Software Engineering

Peter the Great St. Petersburg Polytechnic UniversitySt. Petersburg, Russia

Abstract—The research considers methods for the automatedconversion of audio recordings into a text data format, in otherwords, speech recognition. Particular emphasis is placed on therecognition of noisy Russian-language speech.

The paper provides an overview of existing speech recognitionmethods which include end-to-end and modular methods. Thereis a review and comparative analysis of existing implementationsof the methods and their metrics. Based on a comparativeanalysis, it is concluded that Mozilla DeepSpeech technology isthe most powerful speech recognition tool.

A distinctive feature of the work is the use of the combinedrecognition method, which allows to improve the recognitionquality of noisy recordings. The end-to-end and modular methodsare combined in single approach. The proposed approach isimplemented in a software package for recognizing noisy Russian-language speech using Mozilla DeepSpeech technology. Theresults showing the effectiveness of the proposed end-to-endmethod are demonstrated.

The developed software package can be used in companiesengaged in technical support and call centers to improve theefficiency of processing customer requests.

10

Fault Tolerant Distributed Hash-Joinin Relational Databases

1st Arsen NasibullinSaint-Petersburg State University

Saint-Petersburg, Russianevskyarseny@yandex.ru

2nd Boris NovikovHSE University

Saint-Petersburg, Russiabnovikov@hseu.ru

Abstract—The business today are facing with immense chal-lenges due to complex applications and rapid growth in datavolumes. Many of applications use data for computing statisticaldata to make proper decision in other applications such asmachine learning or social networking. Mostly, these applica-tions assume performing sophisticated client queries with suchoperators as aggregation and join. State-of-the-art distributedrelational databases get over these challenges. Unfortunately,distributed database management systems suffer from failures.Failures causes sophisticated queries with joining large tablesare re-executed so that enormous volume of resources must beleveraged.In this paper, we introduce a new fault tolerant join algorithm fordistributed RDBMS. The algorithm based on mechanisms of datareplication and heartbeat messages. We compare our algorithmwith traditional, unreliable distributed join algorithm. This paperdemonstrates how we achieved trade-off between time requiredto perform tasks of failed sites and extra resources needed tocarry it out.

Index Terms—databases, hash-join, fault-tolerance, query pro-cessing, replication

I. INTRODUCTION

Let us consider the definition of distributed database sys-tems. Distributed database systems are database managementsystems, consisting of local database systems [1], [2]. Thesesystems with their own disks are located and dispersed overa network of interconnected computers. In this paper, wedeal with shared-nothing architecture of distributed databasesystems.

Fault tolerance is the property of system to keep on carryingout tasks in the event of the failure [1], [3]. A system is able todetect a failure and properly handle it without affecting correctexecution of tasks.

Distributed systems, based on MapReduce framework, pro-vide high availability, improved performance. They also pro-vide fault-tolerance in case of any site is down. In contrast todistributed systems, parallel RDBMS cannot handle occurredfails so that entire work has to be re-executed. In our workwe will focus on how achieve fault tolerance for RDBMS.

Modern distributed database systems are applicable for avariety of tasks such as business intelligence [1], [4]. Mostly,these tasks assume performing sophisticated client querieswith such operators as aggregation and join.

The join operation has been studied and discussed exten-sively in research efforts because it is one of the most time-consuming and data-intensive operations in relational queryprocessing [4]–[7].

Distributed database systems have the main goal isprocessing an enormous amount of data in a short time,by transmitting data, handling its and passing the finaloutcome to applications. In failure-free scenarios, databasesystems may achieve good results. Given that failures arecommon at large-scale, distributed database systems remainfault tolerance as built-in feature. As example, modern dataprocessing systems have algorithms of recovering tasks of afailed site [8].

According to studies [9], [10], the most common failuretypes are divided into the following:

• Communication failure. This type of failures is spe-cific for distributed systems. There are many types ofcommunication failures - errors in messages, unorderedmessages, undelivered message, and lost connection. Thefirst two types are responsibility of computer network.Lost messages and/or connection can be the consequenceof failed sites or communication failure.

• System failure. A hardware of a software failure maycause a system failure. For example, may be either CPUcrashed or the presence of bugs in application code whichcause failures occur. Once a system failure occurred,content of main memory is loosen.

• Media failure. It refers to the failures of the secondarystorage devices that store the database. Such failures maybe due to operating system errors, as well as to hardwarefaults such as head crashes or controller failures. Theimportant point from the perspective of DBMS reliabilityis that all or part of the database that is on the secondarystorage is considered to be destroyed and inaccessible.

• Transaction failure. Transactions can fail for a numberof reasons. For instance, a failure can occur due to eitherincorrect input data or potential deadlock.

As state in [9], hardware and software failures make upmore than 90% of all failures. This percentage has not changedsignificantly since the early days of computing. What is moreinteresting is the occurrence of soft failure is significantly

11

higher than that of hardware failures.In contrast to the occurrence of system failures, the occurrenceof transaction failures, as it states in [10], is 3%. Moderndatabase management systems are capable of recovering ex-ecution of abrupt interrupted transactions in a short time. Inthis paper, we do not consider transactions failures.

Unfortunately, state-of-the-art data processing systems donot have algorithms for handling failures when a client per-forms a query joining two of more tables. Currently, themodern relational and NoSQL distributed database systemsre-execute an entire query even if a one node of systemsbecomes inactive. For example, a node with stored databecomes unavailable when transmitting data to sites wherejoin operation are performed. It causes re-execution of a querywith join leads to spend enormous resources and time to endup a join query.

The paper addresses the challenges of recovering tasks atfailed sites. Our solution achieves the fault tolerant executionof join queries through making trade-off between completingrecovery tasks for the least time and extra resources to beleveraged for this. Data replication insure to reallocate aclient query to available site with stored data. An approachof sending heartbeat messages allows to detect a failure ofany site and undertake required steps to recover undone work.

We leverage the following notations used in the paper:

TABLE INOTATIONS USED IN THE PAPER

Symbol ExplanationR Input relation RS Input relation Sb Block sizeB(R) The number of blocks of relation RB(S) The number of blocks of relation ST (R) The number of tuples of relation RT (S) The number of tuples of relation S|K| The number of keepers|W | The number of workersI(A) The number of distinct join attribute valuesKeepers Nodes, where data is storedWorkers Nodes, where join operation are performed

This paper is organized as follows. Section II describesrelated work. Description of the distributed cost model, usedin the paper, is given in Section III. In Section IV, we addressto classical distributed hash-join algorithm and examine costof the execution. Fault tolerant distributed hash-join algorithmand its cost is introduced in Section V. Section VI providesthe description and evaluations of how fault tolerant algorithmgets over failures. Comparison of estimations is presented inSection VII. This paper is concluded by Section VIII.

II. RELATED WORK

In this section, we briefly review works dedicated to dif-ferent approaches of tackling failures in modern framework

for processing vast amount of data in parallel called HadoopMapReduce [8]. We examined algorithms [6], [11]–[13] ofparallel join for different kind of systems. Analyzed works donot consider the task of handling failures. Authors supposedalgorithms work on fail-free systems.

Review [14] describes the state of the art approaches toimprove the performance of parallel query processing usingMapReduce. Even more, authors discussed significant weak-nesses and limitations of the framework. A classification ofexisting studies over MapReduce is provided focusing on theoptimization objective.

Authors proposed a strategy of doubling each task in execu-tion [15]. This stands for if one of the tasks fails, the secondbackup task will end up on time, reducing the job completiontime by using larger amounts of resources. Intuitively, readersmay guess that doubling the tasks leads to approximatelydoubling the resources.

In work [16], authors have devised two strategies to improvethe failure detection in Hadoop via heartbeat messages in theworker side. The first strategy is an adaptive interval whichwill dynamically configure the expiry time adapted to thevarious sizes of jobs. As authors state, the adaptive intervalis advantageous to the small jobs. The second strategy is toevaluate the reputation of each worker according the reports ofthe failed fetch-errors from each worker. If a worker failures,it lows its reputation. Once the reputation becomes equal tosome bound, the master node marks this worker as failed.

To remove single point of failure in Hadoop, a newapproach of a metadata replication based solution wasproposed in [17]. The solution involves three major phases:in initialization phase, each secondary node is registered toprimary node and its initial metadata such as version file andfile system image are caught up with those of active/primarynode; in replication phase, the runtime metadata (such asoutstanding operations and lease states) for failover in futureare replicated; in failover phase, standby/new elected primarynode takes over all communications.

III. DISTRIBUTED COST MODEL

One of the challenges of multi objective query optimizationin distributed database management systems is to find Paretoset of solutions or the best possible trade-offs among theobjective functions [18]. Objective functions are defined astotal time of query execution, I/O operations, CPU instructionsand a number of messages to be transmitted.

In distributed database systems the total time of query exe-cution is expressed through mathematical model of weightedaverage. This model consists of time to perform I/O operations,CPU instructions and time to exchange a number of messagesamong involved sites. In this work we are going to findtrade-off between the least time of the execution in case offailure occurrence and extra resources required to recoverfailed tasks. We will evaluate time to perform I/O operations,CPU instructions, and communication separately.

12

In this paper, we consider joining two relations R and S,and R.A = S.B is the join condition. Assume all data of eachrelation evenly distributed throughout the system; each nodestores T (R)|K| and

T (S)|K| respectively.

IV. CLASSICAL DISTRIBUTED HASH-JOIN ALGORITHMIn this section, we describe distributed hash-join algorithm.

We will often refer to distributed hash-join algorithm asclassical join algorithm.

At the highest level, the working of distributed hash join indistributed database systems of a shared-nothing architectureis straightforward:

1) A coordinator receives a client query. Then, the coordi-nator populates messages with a client query across allkeepers.

2) Each keeper reads its partitions of relation R, applies ahash function h1 to the join attribute of each attribute.Hash function h1 has its range of values 0...|K| − 1. Ifa tuple hashes to value i, then it is sent to a worker Wi.Once a keeper ends up reading its partitions of relationR, it notifies the coordinator about the status of work.

3) Each worker Wi builds a hash table, allocated in mem-ory, and fills in it with tuples received from step 2. Inthis step, each worker uses a different hash function h2than the one used in the step 2.

4) Once all keepers stopped reading their partitions ofrelation R, the coordinator initiates a probing phase bysending notifications to keepers.

5) Each keeper reads its partitions of relation S, applies ahash function h1 to the join attribute of each attributeas it is in the step 2. If a tuple hashes to value i, then ithas to be sent to a worker Wi.

6) A worker receives a tuple of relation S, probes the hashtable built in step 2 to find out a tuple of relation S joinswith any tuple of relation R. If so, tuples join and anoutcome tuple is generated.

C

K1

K2

KM

...

W1

W2

W3

WN

Fig. 1. Scheme of working of distributed join

Figure 1 illustrates a scheme of working distributed join al-gorithm. The red lines stands for a communication between thecoordinator and a keeper at two phases building and probing.

The direction of a red line from a keeper to the coordinatormeans process of sending a notification to the coordinator withmessage a keeper stopped reading its partitions on a particularphase. The blue lines among keepers and workers denote theprocess of sending tuples at two phases. Lines of green color,directed from workers to the coordinator, signify submittingoutcome tuples.

Here and further in the paper we do not consider thesingle coordinator receives all client queries. Instead, a newcoordinator is assigned for each query.

A. Cost of Classical Distributed Hash-Join

1) Communication cost: the coordinator sends a messageto K keepers to take up reading their partitions of relation R.One more message the coordinator sends to keepers to startreading partitions of relation S. At the building phase, keeperssend T (R) messages to workers, and at the probing phase theysend T (S) messages. The total communication cost:

Tmsg = 2 + T (R) + T (S) (1)

2) I/O cost: keepers read B(R) blocks at the building phaseand workers write B(R) blocks into their disks. At the probingphase, keepers read B(S) blocks of relation S. To write theresult of matching, it will take

IOmatches =B(R)T (S) +B(S)T (R)

I(A)(2)

The total I/O cost:

TI/O = 2B(R) +B(S) + IOmatches (3)

3) CPU cost: at the both building and probing phases,the coordinator sends 2 messages to keepers. Each keeper re-ceives 2 messages. For reading both relations, keepers performB(R) + B(S) operations. To write blocks of relation R oneach worker, it is required to perform B(R) operations. At thebuilding and probing phases, keepers perform T (R) + T (S)operations to submit messages to workers and workers executeT (R) + T (S) operations to receive messages. Each workerexecutes

CPUcompare =B(R)T (S) +B(S)T (R) + T (R)T (S)

I(A)|W | (4)

comparing of tuples both relations during the matching, andwriting join result. The total CPU cost:

TCPU = B(S) + 2(T (R) + T (S) +B(R) + |K|+ 1)+CPUcompare

(5)

V. FAULT TOLERANT DISTRIBUTED HASH-JOIN

We identified a few causes the classical distributed join mayinterrupt at any phase of algorithm.• The coordinator became unreachable. For example, due

to a communication or a system failure. All stored datamay be loosen.

13

• A media or system failure occurred at a keeper or aworker performing operations over its disk.

• A site was suddenly turned off in the middle of theprobing phase so the entire work has to be re-executed.

To detect and properly handle the failures above, we decidedto leverage the concept of sending heartbeat messages. Theconcept of heartbeat is widely used in the consensus algorithmRaft [19]. In a heartbeat message, a site may inform anothersite about status of carried out tasks or pass crucial metadatainformation.

The approach of heartbeat messages benefits detecting anyfailures of sites. The coordinator’s duty is to send heartbeatmessages to all sites and receive responses. Once the coordi-nator receives heartbeat messages, it has to sort out inputs. Ifan input contains error message, it stands for an error occurredin a site, for example, software or media failure. If there is noresponse from a site, it means either a site is unreachable dueto communication failure or hardware issues occurred.We injected the approach of heartbeat messages into our algo-rithm. Based on content of a received message, the coordinatorundertakes required steps to recover work of a failed site.

Apart from telling about communication and system fail-ures, consider failures with disks. A failure with a disk can becaused by power loss, media faults, I/O errors, or corruptionof information on the disk. Particularly, a failure with a diskof a worker may cause the loss of intermediate join result.To prevent the loss of data stored in sites, we leverage thestrategy of full data replication [20], [21]. Keepers form aring. Keeper (i + 1) mod |K| stores a full copy of data ofthe previous keeper i mod |K|. To protect intermediate dataof workers from the loss, each keeper copy data for joining toboth workers. The first worker executes join operation of bothtables whereas the second worker stays on until the coordinatorsignals to join reserved data.

A. Algorithm

Summarizing said all above, we introduce fault tolerantdistributed hash-join algorithm. The algorithm is similar toclassical hash-join for distributed database systems in a shared-nothing architecture.

1) Building. A coordinator receives a client query. To ini-tiate a build phase, the coordinator populates messageswith a client query across all nodes. Once messages aresent, the coordinator sets status of performing a clientquery as processing for all keepers.

2) Each keeper reads its partitions of relation R, applies ahash function h1 to the join attribute of each attribute.Hash function h1 has its range of values 0...|W | − 1. Ifa tuple hashes to value i, then it is sent to i mod |W |and (i+1) mod |W | workers. For the latter, a messagehas to contain message reserved data. Once a keeperends up reading its partitions of relation R, it notifiesthe coordinator about the status of work.

3) Each worker builds a hash table, allocated in memory,and fills in it with tuples received from step 2. In this

step, each worker uses a different hash function h2 thanthe one used in the step 2.

4) Once all keepers stopped reading their partitions ofrelation R, the coordinator initiates a probing phase bysending notifications to keepers.

5) Probing. Each keeper reads its partitions of relation S,applies a hash function h1 to the join attribute of eachattribute as it is in the step 2. If a tuple hashes to valuei, then it is sent to i mod |W | and (i + 1) mod |W |workers.

6) Worker i mod |W | receives a tuple of relation S, probesthe hash table built in step 2 to find out a tuple of relationS joins with any tuple of relation R. If so, tuples joinand an outcome tuple is generated. The other worker(i+ 1) mod |W | puts reserved data into its disk.

7) Once an outcome tuple is generated, a worker sendsheartbeat message the following worker. In thismessage, it points a position of the last successfullyjoined tuple of relation S.

C

K1

K2

KM

...

W3

W2

W1

WN

RC

...

Fig. 2. Scheme of working of fault tolerant distributed join

In the Figure 2 shown a scheme of working of fault tolerantdistributed join algorithm. There is the same principle ofworking as it is shown in Figure 1 for the classical joinalgorithm. The difference is that there is added a reserved co-ordinator RC and it synchronizes with the primary coordinatorC. Workers comprise a ring of nodes. Each worker is aware ofthe following node. It facilitates a worker submits info aboutproceeded work during the join to the following worker. Incase of i mod |W | worker is failed, (i+1) mod |W | workertakes over tasks of a failed worker.

B. Cost of Fault Tolerant Distributed Hash-Join Algorithm

1) Communication cost: similar to the classical distributedjoin algorithm, in fault tolerant algorithm the coordinator sendsone message to keepers to take up reading their partitionsof relation R and one message to start reading partitions ofrelation S. At the building phase, keepers send T (R) messagesto workers, and at the probing phase they send T (S) messages.

Tmsg = 2 + T (R) + T (S) (6)

14

2) I/O cost: keepers read B(R) blocks at the building phaseand workers write B(R) blocks into their disks in parallelincluding reserved blocks of relation R. At the probing phase,keepers read B(S) blocks and workers write B(S) blocksas reserved. To write the result of matching, it’s required toperform

IOmatches =B(R)T (S) +B(S)T (R)

I(A)(7)

I/O operations. The total I/O cost:

TI/O = 2(B(S) +B(R)) + IOmatches (8)

3) CPU cost: the coordinator carries out 2 operations tosubmit messages to keepers at the both phases. All in all,keepers perform 2|K| operations to receive messages. To readand write both relations by keepers at two phases, it will takes

IORW = 2(B(S) +B(R)) (9)

At the building and probing phases, to submit and receivemessages with tuples, it will takes

CSR = 2(T (R) + T (S)) (10)

operations to submit and receive messages with tuples. Eachworker executes

CPUcompare =T (R)T (S)

I(A)|W | (11)

operations comparing of tuples both relations during thematching, and

CPUjoin =B(R)T (S) +B(S)T (R)

I(A)|W | (12)

operations to write join result. After an outcome tuple isgenerated and sent to the coordinator, two operations areneeded to send a message from i mod W worker to (i+ 1)mod |W | worker.The total CPU cost:

TCPU = IORW + CSR + 2(|K|+ 1)+CPUcompare + CPUjoin

(13)

VI. HANDLING FAILURES

In this section, we examine steps to handle failures duringthe execution of fault tolerant hash join algorithm.

A. Failure of The Coordinator

As we said before, the coordinator may fail at any phase. Forinstance, the coordinator becomes unreachable before probingphase or even in the middle of the execution of building phase.To eliminate any of those scenarios, the secondary coordinatortakes over a work of the failed coordinator. Both keepers andworkers have to be aware of the secondary coordinator and beable to quickly join it.We suggest adding both coordinators’ addresses to keepersand workers. When a heartbeat message is sent from a site to

the failed coordinator, a node should handle it by re-sending amessage to the secondary coordinator and keeping on workwith it. A database manager should be aware of a failedcoordinator and recover it.

FailedCoordinator

K1

K2

KM

...

W3

W2

W1

WN

NewPrimary

Coordinator

...

Fig. 3. All messages route to the new coordinator

Figure 3 depicts a case when the coordinator is failed and allmessages from nodes re-route to the reserved coordinator.

B. Failure of a Keeper

A keeper may fail at any phase:

1) Before performing a query. Once the coordinator knowsa keeper is failed, it will redirect tasks to another keeperwhere reserved data of a failed keeper is stored.

2) Building or probing. Despite the phase, a keeper stopssending heartbeat messages to the coordinator. The latterreassigns task to another keeper with stored data of aninactive keeper and says its to keep scanning a particularrelation.

To handle the first case, all the coordinator needs to carry outis to mark the failed coordinator as unreachable and not tosubmit messages to it. We do not calculate cost of performingthis case because of we assume the coordinator is aware ofthe address of the failed keeper and the cost will not affectthe query execution.Let us consider the second case. As we pointed out in SectionIII, the total cost of execution is the sum of communicationcost, I/O cost and CPU cost. Communication cost is composedof sending a message from the coordinator to a keeper andsubmitting messages of a particular relation to workers.

Tmsg = 1 +T (R) + T (S)

|K| (14)

I/O cost implies scanning blocks of two relations, writingblocks of relation R twice in parallel and once blocks ofrelation S.

TI/O =2(B(R) +B(S))

|K| (15)

As for CPU cost, it is composed of two operations to send andreceive message from the coordinator to a keeper, reading and

15

writing blocks of two relations and submitting and receivingmessages with tuples.

TCPU = 2 + 2B(R) +B(S) + T (R) + T (S)

|K| (16)

The total cost of the execution of recovering work of a failedkeeper is the sum of

Trecovery = (14) + (15) + (16) (17)

C. Failure of a Worker

If a worker becomes unavailable at building phase, thecoordinator submits a notification in the following heartbeatmessage stop communicating with an unavailable worker.If worker i mod |W | is in unreachable state at the probingphase, the coordinator sends out a message to worker (i+ 1)mod |W | so that it may take over task of joining tuples.The cost of communication:

Tmsg = 1 (18)

I/O cost is composed of the following assumption. Duringperforming join operation, once a worker i mod |W | sendsan outcome tuple to the coordinator, it submits index of a tupleV which just joined and sent to the coordinator. Worker (i+1)mod |W | starts reading from V + 1 tuple.

TI/O = 2

T (S)|W | − V

b(19)

CPU cost is the sum of performing sending and receivingmessages, reading untreated tuples and comparing them

TCPU = 2 +

T (S)|W | − V

b+

(T (R)|W | − V )(T (S)|W | − V )

I(A)(20)

The total cost to recover work of a failed worker is the sumof

Trecovery = (18) + (19) + (20) (21)

VII. EVALUATION AND COMPARISON

In this section we computed cost of both algorithms.The average time of the execution of joining both tables is

defined by introducing the probability P that the total time ofthe execution is the sum of probabilities of fail-free executionand total time of work required to recover a work at a failedsite at any phase.The formula below depicts the average time of execution

The average time = P ∗NW + (1− P ) ∗RW (22)where NW is the total time of fail-free execution of analgorithm whereas RW is the total time of recovering work. Incase of fault tolerant join algorithm, under RW we assume theexecution of recovery work at any phase described in SectionVI. For classical distributed join, the recovery work is to re-execute the entire query across all sites.We consider the following cases: fail-free work, a keeper fails,and a worker fails. For simplicity, we assume that the proba-bility of fault tolerant work of any site equals. As we said in

TABLE IIPARAMETERS USED FOR COMPUTING OF COSTS

T(R) = T(S) 256 50000 100000|W | = |K| 5

B(R) 16 1000 5000B(S) 16 500 1000

b 16 20 100

Normalwork

Keeperfailed

Workerfailed

0

200

400

600514 514 514514

103

1

Tim

eof

the

exec

utio

nin

ms

Classical distributed join Fault tolerant join

Fig. 4. Comparison of communication time required to execute both algo-rithms. T(R) = T(S) = 256

Section III, we analyze different objective functions separately.Table II provides parameters used during evaluations.

Working with disks in fail-free mode of work, the executionof fault tolerant join takes from 5 to 11% more time thanclassical join takes. This is due to tuples of the second tablehave to be written and marked as reserved. In the rest cases,fault tolerant join algorithm works with disks 97% time faster.

As for CPU cost, classical join wins in term of time of theexecution at fail-free mode. 81% time less requires to recoverwork of the execution of client query if a keeper fails. In caseof a worker fails, it will take 93% less time to assign a taskof a failed site to another worker.

The more fascinating results are got when comparing com-munication costs. In fail-free case, time required to pass dataacross all sites for both algorithms equals. When a keeperfails, fault tolerant algorithm works 80% time faster thanclassical algorithm works. In case of a worker fails, faulttolerant join algorithms demonstrates impressive time of theexecution. It will 99% faster than its competitor. The resultsof communication evaluations are shown in Figures 4, 5, 6.

VIII. CONCLUSION

In this paper, we introduced a fault-tolerant distributedhash-join algorithm. Cost model has been provided, classicaland fault tolerant algorithms are compared with each other.In case of failure-free, the unstable algorithm demonstratesbetter results. In contrast to classical distributed hash join,estimations showed that fault tolerant join algorithm takesprecedence over unreliable distributed hash join algorithm.

16

Normalwork

Keeperfailed

Workerfailed

0

0.5

1

·105

1 1 11

0.2

1 · 10−5

Tim

eof

the

exec

utio

nin

ms

Classical distributed join Fault tolerant join

Fig. 5. Comparison of communication time required to execute both algo-rithms. T(R) = T(S) = 50.000

Normalwork

Keeperfailed

Workerfailed

0

1

2

·105

2 2 22

0.4

1 · 10−5

Tim

eof

the

exec

utio

nin

ms

Classical distributed join Fault tolerant join

Fig. 6. Comparison of communication time required to execute both algo-rithms. T(R) = T(S) = 100.000

With double copying tuples of relations to servers, where joinis performed, we may omit abrupt failures of workers and keepon joining tuples in available ones.

Future work includes adapting our algorithm to data skew.We will also consider implementing fault tolerant algorithmand conduct experiments with other RDBMS.

REFERENCES

[1] A. S. Tanenbaum and M. v. Steen, Distributed Systems: Principles andParadigms (2Nd Edition). Upper Saddle River, NJ, USA: Prentice-Hall,Inc., 2006.

[2] S. K. Rahimi and F. S. Haug, Distributed Database ManagementSystems: A Practical Approach. Wiley-IEEE Computer Society Pr,2010.

[3] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basicconcepts and taxonomy of dependable and secure computing,” IEEETrans. Dependable Secur. Comput., vol. 1, no. 1, pp. 11–33, Jan. 2004.[Online]. Available: https://doi.org/10.1109/TDSC.2004.2

[4] B. Catania and L. Jain, Advanced Query Processing: An Introduction,01 2012, vol. 36, pp. 1–13.

[5] G. Graefe, “Query evaluation techniques for large databases,” ACMComput. Surv., vol. 25, no. 2, pp. 73–169, Jun. 1993. [Online].Available: http://doi.acm.org/10.1145/152610.152611

[6] C. Barthels, I. Müller, T. Schneider, G. Alonso, and T. Hoefler,“Distributed join algorithms on thousands of cores,” Proc. VLDBEndow., vol. 10, no. 5, pp. 517–528, Jan. 2017. [Online]. Available:https://doi.org/10.14778/3055540.3055545

[7] C. Kim, T. Kaldewey, V. W. Lee, E. Sedlar, A. D. Nguyen, N. Satish,J. Chhugani, A. Di Blas, and P. Dubey, “Sort vs. hash revisited:Fast join implementation on modern multi-core cpus,” Proc. VLDBEndow., vol. 2, no. 2, pp. 1378–1389, Aug. 2009. [Online]. Available:https://doi.org/10.14778/1687553.1687564

[8] A. S. Foundation. (2019) Apache hadoop. [Online]. Available:https://hadoop.apache.org/

[9] M. T. zsu and P. Valduriez, Principles of Distributed Database Systems,3rd ed. Springer Publishing Company, Incorporated, 2011.

[10] J. Gray, P. McJones, M. Blasgen, B. Lindsay, R. Lorie, T. Price,F. Putzolu, and I. Traiger, “The recovery manager of the system rdatabase manager,” ACM Comput. Surv., vol. 13, no. 2, pp. 223–242, Jun.1981. [Online]. Available: http://doi.acm.org/10.1145/356842.356847

[11] G. Gardarin and P. Valduriez, “Join and semijoin algorithms for amultiprocessor database machine,” ACM Transactions on DatabaseSystems, vol. 9, 03 1984.

[12] C. Balkesen, G. Alonso, J. Teubner, and M. T. Özsu, “Multi-core, main-memory joins: Sort vs. hash revisited,” Proc. VLDBEndow., vol. 7, no. 1, p. 85–96, Sep. 2013. [Online]. Available:https://doi.org/10.14778/2732219.2732227

[13] J. Teubner and G. Alonso, “Main-memory hash joins on modernprocessor architectures,” IEEE Transactions on Knowledge and DataEngineering, vol. 27, no. 7, pp. 1754–1766, July 2015.

[14] C. Doulkeridis and K. Norvaag, “A survey of large-scale analytical queryprocessing in mapreduce,” The VLDB Journal, vol. 23, no. 3, pp. 355–380, Jun. 2014. [Online]. Available: http://dx.doi.org/10.1007/s00778-013-0319-9

[15] P. Costa, M. Pasin, A. Bessani, and M. Correia, “Byzantine fault-tolerantmapreduce: Faults are not just crashes,” 11 2011, pp. 32–39.

[16] H. Zhu and H. Chen, “Adaptive failure detection via heartbeat underhadoop,” 12 2011, pp. 231–238.

[17] F. Wang, J. Qiu, J. Yang, B. Dong, X. Li, and Y. Li, “Hadoop highavailability through metadata replication,” in Proceedings of the FirstInternational Workshop on Cloud Data Management, ser. CloudDB ’09.New York, NY, USA: ACM, 2009, pp. 37–44. [Online]. Available:http://doi.acm.org/10.1145/1651263.1651271

[18] V. Singh, “Multi-objective parametric query optimization for distributeddatabase systems,” in Proceedings of Fifth International Conference onSoft Computing for Problem Solving, M. Pant, K. Deep, J. C. Bansal,A. Nagar, and K. N. Das, Eds. Singapore: Springer Singapore, 2016,pp. 219–233.

[19] D. Ongaro and J. Ousterhout, “In search of an understandable consensusalgorithm,” in Proceedings of the 2014 USENIX Conference on USENIXAnnual Technical Conference, ser. USENIX ATC’14. Berkeley, CA,USA: USENIX Association, 2014, pp. 305–320. [Online]. Available:http://dl.acm.org/citation.cfm?id=2643634.2643666

[20] S. H. Son, “Replicated data management in distributed databasesystems,” SIGMOD Rec., vol. 17, no. 4, pp. 62–69, Nov. 1988.[Online]. Available: http://doi.acm.org/10.1145/61733.61738

[21] G. Alonso and B. Kemme, “How to select a replication protocolaccording to scalability, availability and communication overhead,” 082001.

17

Energy Consumption Measurement Frameworks forAndroid OS: A Systematic Literature Review

Vladislav Myasnikov∗, Stanislav Sartasov†, Ilya Slesarev‡ and Pavel Gessen§∗Saint Petersburg State University

vladislav.myasnikov@bk.ru†Saint Petersburg State University

stanislav.sartasov@spbu.ru‡Saint Petersburg State University

slesarev.pr@gmail.com§Saint Petersburg Polytechnical University

pashagess2@mail.ru

Abstract—In a modern world smartphones became a com-monly used electronic devices performing numerous day-to-day tasks and much more. Quick battery discharge degradesuser experience, and computationally intensive or badly writtenprograms are responsible for it. It is not always evident whichtool to use and how to set up an experiment to estimate energyconsumption of a specific application. For this we conducted aSystematic Literature Review (SLR) to list existing frameworks tomeasure application power metering for Android OS, to classifythe approaches used to create them and also to assess theiraccuracy and experimental methodology. Our findings indicatethat although there is a considerable amount of studies in thisfield with various approaches, there is still a vacant place for areadily available tool, and it is difficult to compare accuracy ofdifferent frameworks. However there is a solid set of practicesand techniques for experimental setup in application energymeasurement.

I. INTRODUCTIONIt is impossible to imagine a modern world without smart-

phones and other mobile devices. Their compact size com-bined with significant computational capabilities grant them afirm position as a day-to-day informational and recreationaltool. At the end of 2019 a number of smartphone users isexpected to be 3.2 billion with Android OS as a leading mobileoperating system [1].

As smartphones and tablets are mobile electronic devices,its user experience is substantially defined by battery lifetime.While hardware components are constantly improving withpower-saving electronics and more capacitous batteries beingavailable to the market, inefficiently written software causesdegradation of user experience due to elevated charge drain.

Different applications and even different versions of thesame application consume energy differently. A school ofthought called ”green software development” advocates a needto consider energy consumption as well as performance met-rics during application development [2]. A common practice isenergy-efficient refactoring — such a change in software codethat doesn’t change its end user functionality but decreases itsenergy footprint.

Was a particular energy refactoring effective? How muchenergy did we save by applying it? To answer these questions

one should be able to compare application or module energyconsumption before and after refactoring. Therefore a toolfor conducting such experiments is required. Such a toolmay come as one-time testbed for a specific project or amore generic and reusable framework or utility. It should benoted that there’s little uniformity among such tools. Theydiffer not only in metering methodologies but in measurementresults as well, i.e. some frameworks measure battery chargepercentage change, other calculate consumed power in watts,while another group operates in abstract units of measure.

In order to help practitioners and engineers better under-stand current state-of-the-art approaches to energy consump-tion measurement and to select proper approach, technique ortool for a particular experiment, we conduct a systematic liter-ature review (SLR) on the energy consumption measurementframeworks for mobile devices using Android OS. We selectedthis mobile platform as it is the most presented platform onthe market compared to iOS and Windows Phone [3], and itis also open-sourced, meaning that some types of frameworks(for example those that modify OS kernel) might be absent onother platforms.

This paper is organized as follows. In Section 2 our method-ology for SLR is described and research questions (RQs) areformulated. Section 3 contains answers for RQs. Limitationsof this study are reported in Section 4. A side question ofrelating our proposed framework classification to a number ofcommercial profilers is addressed in Section 5. Conclusionsare drawn and future work is outlined in Section 6.

II. METHOD

We followed SLR guidelines by Kitchenham and Charters[4] with a number of differences:

• Instead of manual search process we addressed onlinesearch engine. While this decision certainly affects theselection of studies compared to manual search, we useda large number of papers to make a preliminary list andintroduced additional phases to study selection process,so we think the impact of this change on SLR quality isnegligible.

18

• Quality assessment was done along with the data ex-traction process and in some sense — as a part ofit. However Kitchenham and Charters [4] allow suchmethodology, noting that quality information can be usedeither to assist primary study selection by constructingdetailed inclusion/exclusion criteria prior to the main datacollection activity or to assist data analysis and synthesis,so it is collected along with the main data.

A. Research Questions

A following list of research questions (RQs) was compiledduring initial literature assessment:

• RQ1: What approaches exist to estimate code fragments,methods or application energy consumption under An-droid OS?

• RQ2: Are there open source code repositories or otherprogramming artifacts for corresponding frameworks?

• RQ3: What devices are used in measurement experi-ments?

• RQ4: How many frameworks specify or suggest experi-mental methodology?

• RQ5: What is the measurement p