Parallel distributed system for social networks streaming data analysis
A comparison of the effectiveness of remote procedure call technology (RMI) and the framework for distributed computing (Hazelcast), as a means for the development of the cluster system, is performed. The parallel distributed dynamically scalable faulttolerant system for processing large amount of s...
Збережено в:
| Дата: | 2017 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2017
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/157 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-157 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/07/ef02f9e69f46eca1d86e2f6502937107.pdf |
| spelling |
pp_isofts_kiev_ua-article-1572018-07-12T14:26:38Z Parallel distributed system for social networks streaming data analysis Параллельная распределенная система для анализа потоковых данных социальных сетей Паралельна розподілена система для аналізу потокових даних соціальних мереж Doroshenko, А.Yu. Titov, D.S. network; analysis; fault-tolerance; scaling; cluster UDC 004.424 сеть; анализ; отказоустойчивость; масштабирование; кластер УДК 004.424 мережа; аналіз; відмовостійкість; масштабування; кластер УДК 004.424 A comparison of the effectiveness of remote procedure call technology (RMI) and the framework for distributed computing (Hazelcast), as a means for the development of the cluster system, is performed. The parallel distributed dynamically scalable faulttolerant system for processing large amount of streaming data is proposed. The inspection and initial study of this system on the example of data from the Twitter social network is performed. The mechanism of the deployment of the created cluster to the cloud platform is examined. Проведено сравнение эффективности технологии удаленного вызова процедур (RMI) и фреймворка для распределенных вычислений (Hazelcast), как средств для разработки кластерной системы. Предложена параллельная распределенная динамически масштабируемая отказоустойчивая система для обработки потоковых данных большого объема. Проведена проверка и первичное исследование этой системы на примере обработки данных социальной сети Twitter. Рассмотрен механизм развертывания созданного кластера в облачной платформе. Проведено порівняння ефективності технології віддаленого виклику процедур (RMI) та фреймворку для розподілених обчислень (Hazelcast), як засобів для розробки кластерної системи. Запропонована паралельна розподілена динамічно масштабована відмовостійка система для обробки потокових даних великого обсягу. Проведена перевірка та первинне дослідження цієї системи на прикладі обробки да-них соціальної мережі Twitter. Розглянутий механізм розгортання створеного кластеру в хмарній платформі. Інститут програмних систем НАН України 2017-06-16 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/157 PROBLEMS IN PROGRAMMING; No 4 (2015) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2015) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2015) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/157/151 Copyright (c) 2017 ПРОБЛЕМИ ПРОГРАМУВАННЯ |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2018-07-12T14:26:38Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
network analysis fault-tolerance scaling cluster UDC 004.424 |
| spellingShingle |
network analysis fault-tolerance scaling cluster UDC 004.424 Doroshenko, А.Yu. Titov, D.S. Parallel distributed system for social networks streaming data analysis |
| topic_facet |
network analysis fault-tolerance scaling cluster UDC 004.424 сеть анализ отказоустойчивость масштабирование кластер УДК 004.424 мережа аналіз відмовостійкість масштабування кластер УДК 004.424 |
| format |
Article |
| author |
Doroshenko, А.Yu. Titov, D.S. |
| author_facet |
Doroshenko, А.Yu. Titov, D.S. |
| author_sort |
Doroshenko, А.Yu. |
| title |
Parallel distributed system for social networks streaming data analysis |
| title_short |
Parallel distributed system for social networks streaming data analysis |
| title_full |
Parallel distributed system for social networks streaming data analysis |
| title_fullStr |
Parallel distributed system for social networks streaming data analysis |
| title_full_unstemmed |
Parallel distributed system for social networks streaming data analysis |
| title_sort |
parallel distributed system for social networks streaming data analysis |
| title_alt |
Параллельная распределенная система для анализа потоковых данных социальных сетей Паралельна розподілена система для аналізу потокових даних соціальних мереж |
| description |
A comparison of the effectiveness of remote procedure call technology (RMI) and the framework for distributed computing (Hazelcast), as a means for the development of the cluster system, is performed. The parallel distributed dynamically scalable faulttolerant system for processing large amount of streaming data is proposed. The inspection and initial study of this system on the example of data from the Twitter social network is performed. The mechanism of the deployment of the created cluster to the cloud platform is examined. |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2017 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/157 |
| work_keys_str_mv |
AT doroshenkoayu paralleldistributedsystemforsocialnetworksstreamingdataanalysis AT titovds paralleldistributedsystemforsocialnetworksstreamingdataanalysis AT doroshenkoayu parallelʹnaâraspredelennaâsistemadlâanalizapotokovyhdannyhsocialʹnyhsetej AT titovds parallelʹnaâraspredelennaâsistemadlâanalizapotokovyhdannyhsocialʹnyhsetej AT doroshenkoayu paralelʹnarozpodílenasistemadlâanalízupotokovihdanihsocíalʹnihmerež AT titovds paralelʹnarozpodílenasistemadlâanalízupotokovihdanihsocíalʹnihmerež |
| first_indexed |
2025-07-17T09:49:01Z |
| last_indexed |
2025-07-17T09:49:01Z |
| _version_ |
1838409560990154752 |
| fulltext |
Моделі та засоби паралельних і розподілених програм
© А.Ю. Дорошенко, Д.С. Тітов, 2015
ISSN 1727-4907. Проблеми програмування. 2015. № 4 31
УДК 004.424
А.Ю. Дорошенко, Д.С. Тітов
ПАРАЛЕЛЬНА РОЗПОДІЛЕНА СИСТЕМА ДЛЯ АНАЛІЗУ
ПОТОКОВИХ ДАНИХ СОЦІАЛЬНИХ МЕРЕЖ
Проведено порівняння ефективності технології віддаленого виклику процедур (RMI) та фреймворку
для розподілених обчислень (Hazelcast), як засобів для розробки кластерної системи. Запропонована
паралельна розподілена динамічно масштабована відмовостійка система для обробки потокових даних
великого обсягу. Проведена перевірка та первинне дослідження цієї системи на прикладі обробки да-
них соціальної мережі Twitter. Розглянутий механізм розгортання створеного кластеру в хмарній плат-
формі.
Ключові слова: мережа, аналіз, відмовостійкість, масштабування, кластер.
Вступ
Зростання популярності соціальних
медіа останнім часом змусило суттєво тра-
нсформуватись індустрію маркетологічніх
та соціологічних досліджень. Замість того,
щоб формувати контрольні групи, коли
організація хоче отримати джерело думок
про їхню продукцію, рекламу або брен-
динг, стало набагато простіше і дешевше
знайти цільову аудиторію, – та їх думки –
в соціальних мережах.
На початку розвитку соціальних
ЗМІ, дослідники мали можливість оціню-
вати соціальні настрої в ручному режимі,
адже обсяг інформації був відносно ма-
лий. Проте наразі потоки даних в Інтерне-
ті в цілому та соціальних мережах зокре-
ма сягнули колосальних масштабів, тому
виникла потреба у створенні високопро-
дуктивних систем для автоматизованої
обробки цих даних [1]. Більш того, сучас-
ні бізнес стратегії, що реалізують CRM-
підхід, потребують не лише пасивного
аналізу соціального контенту, а ще й пе-
редбачають проактивну реакцію на певні
сигнали, що надходять з соціального Ін-
тернет-простору. Таким чином, дослі-
дження показують, що 64 % споживачів
очікують отримати зворотній зв’язок від
компанії в режимі реального часу та 94 %
готові відмовитись від послуг певної ком-
панії, якщо обслуговування клієнтів не
передбачає цього [2].
У роботі [3] зазначається, що одні-
єю з найбільш цікавих з точки зору аналі-
зу відгуків про бренди соціальних мереж є
мікроблогінгова платформа Twitter. Пере-
вагою Twitter є те, що повідомлення про
актуальні події з’являються в цій соціаль-
ній мережі набагато швидше, ніж в будь-
яких інших новинних джерелах. Тому
Twitter стали розглядати як корисне дже-
рело інформації, яку можна використову-
вати для прогнозування будь-яких показ-
ників, у тому числі і фінансових. Twitter
може слугувати джерелом інформації про
настрої користувачів, тобто з нього зруч-
но виокремлювати психологічну складову
соціальних обговорень.
Відзначено, що пікове навантажен-
ня цієї соціальної мережі оцінюється в
140000 повідомлень в секунду та час об-
робки такого обсягу даних за допомогою
наївного баєсівського класифікатору з
використанням апаратного забезпечення
[4] може сягати 12.458 секунди. Це свід-
чить про те, що система, призначена для
обробки потокових даних великого обся-
гу, має бути паралельною та розподіле-
ною, для того щоб встигати обробляти
вхідні дані вчасно.
Також обчислення у реальному ча-
сі великої кількості даних грає велику
роль у високочастотному трейдингу – ос-
новній формі алгоритмічної торгівлі на
фінансових ринках, в якій сучасне облад-
нання та алгоритми використовуються
для швидкого здійснення торгівельних
операцій над цінними паперами. Як за-
значається в [5], затримка в обробці даних
вже навіть в 10 мілісекунд може призвес-
ти до суттєвих фінансових збитків.
Моделі та засоби паралельних і розподілених програм
32
В роботі розглянуто дві технології,
на базі яких можна створити паралельну
розподілену систему для обробки даних з
соціальних мереж в реальному часу: Java
Remote Method Invocation [6] та Hazelcast
Framework [7]. Також представлена їх ефе-
ктивна порівняльна характеристика.
1. Отримання даних з соціальної
мережі Twitter
Соціальна мережа Twitter надає до-
ступ до своїх даних у вигляді Twitter REST
API та Twitter Firehose. В даній статті не
розглядається Twitter REST API, оскільки
доступ до нього є пакетним: клієнт відпра-
вляє запит до серверу, а той відповідає
певним пакетом даних. Така форма досту-
пу не є отриманням інформації у реально-
му часі, на відміну від Twitter Firehose.
Firehose («пожежний шланг») – те-
хнологія, за якою Twitter надає текстові
повідомлення одразу як вони з’являються
в системі, тобто у реальному часі [8]. Дос-
туп до повного потоку контенту є платним,
проте існує безкоштовна лімітована версія
– Twitter Sample Stream, що фактично яв-
ляє собою Twitter Firehose, обмежений 1 %
кількості повідомлень.
Існує декілька Java-провайдерів для
взаємодії з Twitter Sample Stream, одним з
найпопулярніших та найзручніших є
Spring Social, а семе його підмодуль –
Spring Social Twitter [9]. Для початку про-
слуховування вхідного потоку достатню
створити Spring Bean, що імплементує ін-
терфейс StreamListener:
@Component
public class TwitterStreamListener
implements StreamListener {
@Override
public void onTweet(Tweet tweet) {
}
@Override
public void
onDelete(StreamDeleteEvent streamDelete-
vent) {
}
@Override
public void onLimit(int i) {
}
@Override
public void
onWarning(StreamWarningEvent
streamWarningEvent) {
}
}
Метод onTweet() цього обробника
спрацьовуватиме кожного разу, коли до
системи буде надходити чергове повідом-
лення.
2. Реалізація паралельної
розподіленої системи за
допомогою RMI
2.1. Загальні відомості про техно-
логію RMI. Перша розглянута технологія,
придатна для розподілення обчислень, це
Java remote method invocation (RMI) – про-
грамний інтерфейс виклику віддалених
методів платформи Java. RMI представляє
собою розподілену об’єктну модель, що
описує механізм виклику віддалених мето-
дів, які працюють на іншій віртуальній
машині Java. Під час виклику методу від-
даленого об’єкта, в дійсності викликається
звичайний Java метод, інкапсульований у
спеціальному об’єкті-заглушці, який являє
собою представника серверного об’єкта.
Заглушка розташовується на клієнтському
комп’ютері, а не на сервері. Вона упаковує
параметри віддаленого методу в пакет
байтів. Кожен параметр кодується за до-
помогою алгоритму, що забезпечує неза-
лежність від апаратного забезпечення.
2.2. Архітектура паралельної роз-
поділеної системи на основі RMI. В ре-
зультаті була спроектована архітектура
паралельної розподіленої системи, яка пе-
редбачає динамічне масштабування обчис-
лювального кластеру за допомогою синх-
ронізації через сервер бази даних. Під час
ініціалізації першого обчислювального
вузла, він реєструється на сервері бази да-
них та бере на себе керуючу роль (master).
В подальшому цей вузол відповідає за
отримання вхідного потоку даних та роз-
поділення його, також master бере участь
безпосередньо в обробці даних. Інші обчи-
Моделі та засоби паралельних і розподілених програм
33
слювальні вузли можна динамічно підк-
лючати до системи, запускаючи той самий
Java-додаток на сторонніх машинах. Ці
вузли беруть на себе роль «підлеглих»
(slaves) та відповідають лише за обробку
даних, що надходять від master-вузла.
Далі представлений приклад RMI-
сервісу, що може викликатись віддалено
для обробки повідомлень:
@Component
public class TwitterConsumer
implements IConsumer {
@Autowired
private TwitterProcessor
twitterProcessor;
public void
consume(TweetWrapper tweetWrapper) {
twitterProcessor.process(tweetWrapper);
}
@Override
public Class<IConsumer>
getServiceInterface() {
return IConsumer.class;
}
}
Інтерфейс IConsumer в свою чергу
наслідує інтерфейс Remote, для того щоб
сервіс можна було внести до RMI-реєстру
так експортувати назовні.
До переваг створеної системи мож-
на віднести можливість запуску обчислю-
вального вузла на будь-якому комп’ютері,
що має реальна IP-адреса, тобто обчислю-
вальні машини не обов’язково повинні
знаходитись в межах однієї локальної ме-
режі (але повинні бути доступними для
з’єднання ззовні).
Слабким місцем подібної архітек-
тури є необхідність використовувати
окремий сервер бази даних для синхроні-
зації вузлів між собою, адже технологія
RMI не має вбудованого механізму для
динамічного знаходження інших вузлів на
рівні додатку. Отже, якщо сервер бази да-
них буде виведений з ладу, система перес-
тане функціонувати.
2.3. Відмовостійкість системи на
основі RMI. Для забезпечення відмовос-
тійкості системи потрібно реалізувати
зміну ролі обчислювального вузла з
master на slave у випадку, коли поточний
master-вузол припиняє функціонування.
Як вже було зазначено, RMI не має
вбудованого механізму синхронізації вуз-
лів, отже цю функціональність необхідно
імплементувати окремо. Проблема полягає
в тому, що тоді коли master-вузол може
легко дізнатись про те, що певний slave-
вузол відключився (перехвативши виклю-
чну ситуацію при зверненні до віддаленої
машини), slave-вузли не мають такої наго-
ди. Тому постає необхідність реалізувати
так званий планувальник, якій з певним
інтервалом буде опитувати master-вузол,
щоб дізнатись, чи той ще функціонує.
Приклад подібного планувальнику наведе-
ний нижче:
@Component
public class StateChecker {
@Autowired
private NodeManager
nodeManager;
@Scheduled(initialDelay = 5000,
fixedRate = 500)
public void checkMasterNode()
throws RemoteException,
NotBoundException {
if (nodeManager.isSlaveNode())
{
Node masterNode =
nodeManager.getMasterNode();
if (masterNode == null ||
!nodeManager.isNodeRunning(masterNode))
{
nodeManager.selectNewMasterNode(masterN
ode);
}
}
}
}
Моделі та засоби паралельних і розподілених програм
34
Метод checkMasterNode() виклика-
ється кожні 500 мілісекунд та у разі необ-
хідності ініціює реініціалізацію master-
вузла.
3. Реалізація паралельної
розподіленої системи за
допомогою Hazelcast
3.1. Загальні відомості про фрей-
мворк Hazelcast. Hazelcast – це платформа
з відкритим програмним кодом для Java,
яка використовується для побудови клас-
терів та масштабованого розподілу даних.
Типовими функціями фреймворку є:
• організація обміну даними/станом
серед багатьох серверів та кешування да-
них (розподілений кеш);
• кластерне розподілення програми та
забезпечення захищеної комунікації між
обчислювальними вузлами;
• синхронізоване використання даних
у пам’яті;
• розподіл обчислень між багатьма
серверами та паралельне виконання задач;
• забезпечення відмовостійкого
управління даними.
3.2. Архітектура паралельної ро-
зподіленої системи на основі
Hazelcast. Перевагою використання
Hazelcast є автоматичне розгортання та
управління обчислювальним кластером:
розробник не повинен передбачати окре-
мого механізму синхронізації обчислюва-
льних вузлів між собою (як, наприклад,
розглянутий вище підхід з використанням
бази даних). Це гарантує ще більшу від-
мовостійкість, оскільки збій жодного
окремого серверу не зможе призвести до
того, що система перестане функціонува-
ти в цілому.
Загалом підхід до розподілення об-
числень нагадує підхід, розглянутий в
попередньому розділі, за винятком того,
що для комунікації між вузлами викорис-
товуються не об’єкти-заглушки, а розпо-
ділений ExecutorService, який отримує на
вхід екземпляри класів, імплементуючих
інтерфейси Callable або Runnable. Ці
представляють собою команди (з інкапсу-
льованими всередині даними), які будуть
виконані на певному обчислювальному
вузлі. Фрагмент такого класу наведений
нижче:
public class TwitterCallable
implements Callable<TweetWrapper>,
Serializable {
…
public
TwitterCallable(TweetWrapper
tweetWrapper) {
this.tweetWrapper =
tweetWrapper;
}
@Override
public TweetWrapper call() throws
Exception {
TweetWrapper result =
twitterProcessor.process(tweetWrapper);
return result;
}
…
}
3.3. Відмовостійкість системи на
основі Hazelcast. Hazelcast надає дуже
зручний механізм моніторингу подій, які
трапляються з вузлами кластеру – інтер-
фейс MembershipListener. Цей інтерфейс
має три методи, що дозволяють відслідко-
вувати додавання нового вузла, відклю-
чення вузла та зміну атрибутів вузла. Саме
можливість задавати значення певних ат-
рибутів на елементах кластеру дозволяє
відділяти master-вузол від інших та дина-
мічно змінювати конфігурацію системи.
Приклад реалізації цього інтерфейсу наве-
дений нижче:
public class
ClusterMembershipListener implements
MembershipListener {
private static final Logger
LOGGER =
LoggerFactory.getLogger(ClusterMembership
Listener.class);
private ApplicationContext
applicationContext;
Моделі та засоби паралельних і розподілених програм
35
public void
memberAdded(MembershipEvent
membershipEvent) {
LOGGER.info("Member added:
{}", membershipEvent);
}
public void
memberRemoved(MembershipEvent
membershipEvent) {
Boolean isMasterNode =
membershipEvent.getMember().getBooleanA
ttribute(SocialBootApplication.IS_MASTER
_NODE);
if (isMasterNode) {
applicationContext.getBean(NodeManager.cl
ass).selectNewMasterNode();
}
LOGGER.info("Member
removed: {}", membershipEvent);
}
public void
memberAttributeChanged(MemberAttributeE
vent memberAttributeEvent) {
LOGGER.info("Member
attribute changed: {}",
memberAttributeEvent);
}
public void
setApplicationContext(ApplicationContext
applicationContext) {
this.applicationContext =
applicationContext;
}
}
3.4. Розгортання кластеру в хма-
рині Amazon Elastic Compute Cloud. Для
розгортання системи на основі Hazelcast
була обрана хмарна платформа Amazon
Elastic Compute Cloud (EC2). EC2 предста-
вляє собою веб-сервіс, який дозволяє
отримати доступ до обчислювальних по-
тужностей і налаштувати ресурси з міні-
мальними затратами. Він надає користува-
чам повний контроль над обчислювальни-
ми ресурсами, а також доступне середо-
вище для роботи. Служба скорочує час,
необхідний для отримання і завантаження
нового сервера [10].
Для тестування кластеру в ЕС2 було
замовлено 5 серверів, які мають фіксовані
технічні характеристики [11]. На серверах
встановлена операційна система Ubuntu
Linux, доступ здійснюється за допомогою
протоколу SSH.
Загалом Hazelcast передбачає три
опції для знаходження вузлів один-одним:
• статична IP-адресація;
• multicast в локальній мережі;
• AWS EC2 Auto Discovery.
Перший підхід не задовольняє пот-
ребу динамічного підключення обчислю-
вальних вузлів, а між другим та третім був
обраний AWS EC2 Auto Discovery, оскіль-
ки він представляє собою просту та зручну
інтеграцію з середовищем ЕС2.
Нижче наведений метод, що відпо-
відає за створення HazelcastInstance – ос-
новного класу фреймворку Hazelcast, який
інкапсулює в собі всі налаштування клас-
теру:
@Bean
public HazelcastInstance
hazelcastInstance(@Value("${aws.access.key
}") String accessKey,
@Value("${aws.secret.key}") String
secretKey) {
Config config = new Config();
config.getNetworkConfig().setPort(5900);
config.getNetworkConfig().setPortAutoIncre
ment(true);
config.addListenerConfig(new
ListenerConfig(clusterMembershipListener())
);
NetworkConfig network =
config.getNetworkConfig();
JoinConfig join =
network.getJoin();
join.getMulticastConfig().setEnabled(false);
join.getTcpIpConfig().setEnabled(false);
Моделі та засоби паралельних і розподілених програм
36
join.getAwsConfig().setAccessKey(accessKe
y).setSecretKey(secretKey).setEnabled(true);
HazelcastInstance
hazelcastInstance =
Hazelcast.newHazelcastInstance(config);
Set<Member> members =
hazelcastInstance.getCluster().getMembers();
Member localMember =
hazelcastInstance.getCluster().getLocalMemb
er();
localMember.setBooleanAttribute(IS_MAST
ER_NODE, members.size() == 1);
return hazelcastInstance;
}
Як бачимо, інтеграція з ЕС2 полягає
у вказанні ключу доступу та секретного
ключу доступу до платформи, які можна
отримати в панелі керування хмарним сер-
вісом.
Після запуску додатку на першому
сервері, Hazelcast створює кластер, що на-
разі складається з одного обчислювального
вузла. В терміналі це виглядає наступним
чином:
Members [1] {
Member [172.31.37.199]:5900 this
}
Коли будуть додаватись інші вузли,
їх синхронізація між собою відбувати-
меться повністю прозоро для розробника,
так відображатиметься в терміналі. Крім
того, існує можливість запуску декількох
екземплярів додатків на одному сервері – в
такому випадку кожний вузол стартує на
своєму власному порту, завдяки опції
setPortAutoIncrement(true):
Members [5] {
Member [172.31.37.199]:5900 this
Member [172.31.37.198]:5900
Member [172.31.37.197]:5900
Member [172.31.37.197]:5901
}
Відповідно, динамічне відключення
вузлів також миттєво відображається в
консолі серверу, що дозволяє своєчасно
реагувати на раптові зміни топології роз-
горнутого кластеру.
4. Інтерфейс управління
кластером
Для зручного управління кластером
в обох системах реалізований WEB-
інтерфейс, який дозволяє керувати станом
кожного окремого вузла за допомогою
запитів до REST-сервісів.
WEB-інтерфейс побудований на
основі фреймворку Jersey: при запуску
кожного екземпляру додатку на сервері
стартує WEB-сервер, доступний, за замо-
вченням, за адресою http://localhost:8080
(або за значенням зовнішньої реальної IP-
адреси, якщо доступ виконується ззовні).
Наприклад, для запуску отримання пові-
домлень від Twitter на master-вузлі, необ-
хідно звернутися за допомогою GET-
запиту до точки доступу «/twitter/start»,
та, відповідно, для припинення обробки
до «/twitter/stop». Клас, що реалізує даний
сервіс, наведений далі:
@Service
@Path("/twitter")
@Consumes(MediaType.APPLICATI
ON_JSON)
@Produces(MediaType.APPLICATIO
N_JSON)
public class TwitterService {
@Autowired
private TwitterTemplate
twitterTemplate;
@Autowired
private List<StreamListener>
streamListeners;
private Stream userStream;
private void startListening() {
if (userStream == null) {
userStream =
twitterTemplate.streamingOperations().sampl
e(streamListeners);
}
}
private void stopListening() {
Моделі та засоби паралельних і розподілених програм
37
if (userStream != null) {
userStream.close();
userStream = null;
}
}
@GET
@Path("/start")
public String start() {
startListening();
return "Started";
}
@GET
@Path("/stop")
public String stop() {
stopListening();
return "Stopped";
}
}
5. Ефективна порівняльна
характеристика систем на
основі RMI та Hazelcast
5.1. Проведення тестування сис-
теми. Для порівняння ефективності розг-
лянутих технологій, була проведена серія
експериментів: кожна система запуска-
лась на одному, двох, трьох, чотирьох та
п’яти серверах. В кожному випадку де-
сять разів з інтервалом в сто секунд обчи-
слювалась кількість оброблених за цей
інтервал повідомлень та фіксувалось се-
реднє арифметичне значення. Результати
експерименту та побудований графік
представлені далі в таблиці та на рисунку,
де S – це кількість серверів, а Р – кількість
опрацьованих повідомлень.
Таблиця
S RMI, P Hazelcast, P
1 404.7 407.8
2 409.3 414.5
3 425.4 431.1
4 410.4 438.5
5 414.2 448.5
Рисунок. Графік ефективності розглянутих
систем
5.2. Аналіз отриманих результа-
тів. Як бачимо, при малій кількості серве-
рів RMI та Hazelcast показують схожу
динаміку приросту ефективності (втім,
Hazelcast має відносно кращі результати),
проте після підключення четвертого вузла
RMI демонструю різкий спад ефективнос-
ті, а Hazelcast продовжує збільшувати
ефективність майже лінійно.
Потенційним поясненням такої ди-
наміки є те, що RMI оперує зі з’єднан-
нями, використовуючи певний кеш, внут-
рішня реалізація якого може знижувати
ефективність системи при збільшенні кі-
лькості обчислювальних вузлів. Hazelcast,
між тим, використовує пул безпосередніх
з’єднань між вузлами через сокети. Крім
того, RMI виконує постійні DNS-запити
для встановлення відповідності між IP- та
DNS-адресами, а це також може призво-
дити до затримок зі збільшенням кількос-
ті вузлів.
Інше потенційне пояснення даного
ефекту полягає у тому, що реалізований
RMI-планувальник, який кожні пів секун-
ди перевіряє статус master-вузла, при збі-
льшенні вузлів може створювати надмірне
навантаження на мережу і через це швид-
кість обміну даними значно падає. В тако-
му випадку може допомогти збільшення
інтервалу опитування планувальника, але
при збільшенні цього інтервалу також збі-
льшується час, який система буде просто-
ювати у разі раптового відключення
Моделі та засоби паралельних і розподілених програм
38
master-вузла, що є неприйнятним, коли
існують вимоги до сталого функціонуван-
ня системи.
Висновки
В роботі розглянуте актуальне пи-
тання створення високонавантажених сис-
тем, які можуть горизонтально масштабу-
ватись та забезпечувати безперебійну об-
робку потокових даних великих обсягів.
Як приклад джерела даних для обробки
обрана соціальна мережа Twitter та її пото-
ковий API - Twitter Firehose (а саме його
тестова версія Twitter Sample Stream).
Розроблено дві системи: з викорис-
танням Java Remote Method Invocation та
Hazelcast Framework. Системи представ-
ляють собою динамічно масштабовані та
відмовостійкі кластерні рішення, придатні
до розгортання в локальній мережі або в
хмарній платформі Amazon EC2. Одним з
головних надбань розроблених рішень є
те, що дослідник може нарощувати ресур-
си для обчислень за своїм бажанням, різної
конфігурації та потужності, що дає змогу
досягати бажаної швидкодії системи.
Ці рішення порівняні як з точки зо-
ру їх архітектурних та концептуальних
переваг і недоліків, так и з точки зору їх-
ньої ефективності. В результаті серії екс-
периментів встановлено, що Hazelcast
демонструє кращі результати, та чим бі-
льше вузлів додається до кластеру, тим
ефективніше він працює, на відміну від
RMI. Розглянуто декілька гіпотез віднос-
но цього ефекту.
В подальшому планується оптимі-
зація рішення на основі Hazelcast, реалі-
зація криптографічного захисту даних, що
передаються та низка інших покращень.
1. Social Listening in Practice. Market Research
[Електронний ресурс]. – Режим доступу:
https://www.brandwatch.com/guide-market-
research/ – 2015 р.
2. Social Listening in Practice. Social customer
service [Електронний ресурс]. –
Режим доступу:
https://www.brandwatch.com/customer-
service-guide/ – 2015 р.
3. Тітов Д.С., Дорошенко А.Ю. Моніторинг
соціальних мереж в системі реального часу
// Наукова дискусія: теорія, практика, іно-
вації. – 2015. – С. 93–96.
4. Intel Core i7-3770k Processor [Электроний
ресурс]. – Режим доступу:
http://ark.intel.com/products/65523. –
01.11.2012 г.
5. Charlie Munger: HFT is Legalized Front-
Running [Електронний ресурс]. – Режим
доступу:
http://blogs.barrons.com/stockstowatchtoday/
2013/05/03/charlie-munger-hft-is-legalized-
front-running/ – 03.05.2015 р.
6. Remote Method Invocation [Електронний
ресурс]. – Режим доступу:
http://www.oracle.com/technetwork/java/java
se/tech/index-jsp-136424.html – 2015 р.
7. Hazelcast [Електронний ресурс]. – Режим
доступу: https://hazelcast.org/ – 2015 р.
8. Public streams [Електронний ресурс]. –
Режим доступу:
https://dev.twitter.com/streaming/public –
2015 р.
9. Spring Social [Електронний ресурс]. – Ре-
жим доступу: http://projects.spring.io/spring-
social/ – 2015 р.
10. Amazon EC2 [Електронний ресурс]. – Ре-
жим доступу: https://aws.amazon.com/ec2/ –
2015 р.
11. Amazon EC2 Instances [Електронний ре-
сурс]. – Режим доступу:
http://aws.amazon.com/ec2/instance-types/ –
2015 р.
1. Brandwatch Social Listening in Practice.
Market Research [Online] Available from:
https://www.brandwatch.com/guide-market-
research/ [Accessed: 26 September 2015].
2. Brandwatch Social Listening in Practice.
Social customer service [Online]
Available from:
https://www.brandwatch.com/customer-
service-guide/ [Accessed: 26 September
2015].
3. Titov D.S. & Doroshenko A.Yu. Social
networks monitoring in real-time systems. In
Scientific discussion: theory, practice,
innovation. Kyiv, Wednesday 27th to
Thursday 28th March 2015. – Kyiv: IOMP. –
P. 93–96 (in Ukrainian).
4. Intel Intel Core i7-3770k Processor
[Online] Available from:
http://ark.intel.com/products/65523
[Accessed: 26 September 2015].
Моделі та засоби паралельних і розподілених програм
39
5. Charlie Munger HFT is Legalized Front-
Running [Online] Available from:
http://blogs.barrons.com/stockstowatchtoday/
2013/05/03/charlie-munger-hft-is-legalized-
front-running/ [Accessed: 26 September
2015].
6. Oracle Remote Method Invocation Home
[Online] Available from:
http://www.oracle.com/technetwork/java/java
se/tech/index-jsp-136424.html
[Accessed: 26 September 2015]
7. Hazelcast Hazelcast [Online]
Available from: https://hazelcast.org/ [Acce-
sed: 26 September 2015].
8. Twitter Public streams [Online] Available
from: https://dev.twitter.com/streaming/public
[Accessed: 26 September 2015]
9. Spring Spring Social [Online] Available from:
http://projects.spring.io/spring-social/ [Acce-
sed: 26 September 2015].
10. Amazon Amazon EC2 [Online] Available
from: https://aws.amazon.com/ec2/
[Accessed: 26 September 2015].
11. Amazon Amazon EC2 Instances
[Online] Available from:
http://aws.amazon.com/ec2/instance-types/
[Accessed: 26 September 2015].
Одержано 01.10.2015
Про авторів:
Дорошенко Анатолій Юхимович,
доктор фізико-математичних наук,
професор, завідувач відділу теорії
комп’ютерних обчислень Інституту
програмних систем НАН України,
професор кафедри автоматики і управлін-
ня в технічних системах НТУУ “КПІ”.
Кількість наукових публікацій в
українських виданнях – понад 150.
Кількість наукових публікацій в
іноземних виданнях – понад 30,
Індекс Гірша – 3.
ORCID orcid.org/0000-0002-8435-1451,
Тітов Дмитро Сергійович,
студент факультету інформатики та
обчислювальної техніки,
кафедри автоматики і управління
в технічних системах НТУУ “КПІ”.
Кількість наукових публікацій в
українських виданнях – 2.
ORCID orcid.org/0000-0003-1607-5405.
Місце роботи авторів:
Інститут програмних систем
НАН України,
03680, Київ-187,
проспект Академіка Глушкова, 40.
Тел.: (044) 526 1538.
E-mail: dor@isofts.kiev.ua,
Національний технічний університет
України "КПІ"
03056, Київ-56, проспект Перемоги, 37.
Тел.: (044) 236 7989.
E-mail: dmytro.titov@gmail.com
mailto:dor@isofts.kiev.ua
mailto:dmytro.titov@gmail.com
|