The means of the apache hadoop for parallel and distributed programs
Nowadays Grid-based scientific projects become more wide-spread. However, the essential restriction is the problem to choose the appropriate platform for concrete tasks resolutions. The distributed platform Apache Hadoop is considered in the paper. This modern Grid platform, based on the modern scie...
Gespeichert in:
| Datum: | 2026 |
|---|---|
| Hauptverfasser: | , |
| Format: | Artikel |
| Sprache: | Russisch |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2026
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/966 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| _version_ | 1866844992461340672 |
|---|---|
| author | Rukhlis, K.A. Doroshenko, A.Yu. |
| author_facet | Rukhlis, K.A. Doroshenko, A.Yu. |
| author_institution_txt_mv | [
{
"author": "K.A. Rukhlis",
"institution": "Institute of Software Systems NAS of Ukraine"
},
{
"author": "A.Yu. Doroshenko",
"institution": "Institute of Software Systems NAS of Ukraine"
}
] |
| author_sort | Rukhlis, K.A. |
| baseUrl_str | https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| collection | OJS |
| datestamp_date | 2026-06-01T21:28:34Z |
| description | Nowadays Grid-based scientific projects become more wide-spread. However, the essential restriction is the problem to choose the appropriate platform for concrete tasks resolutions. The distributed platform Apache Hadoop is considered in the paper. This modern Grid platform, based on the modern scientific paradigms, is suitable for processing of the huge amount of the data in reliable and effective way. The functional comparison of this platform to the other modern Grid platforms is described in this paper.Problems in programming 2010; 4: 3-10 |
| first_indexed | 2026-06-02T01:02:02Z |
| format | Article |
| fulltext |
Моделі та засоби паралельних і розподілених програм
УДК 004.075
К.А. Рухлис, А.Е. Дорошенко
СРЕДСТВА ПЛАТФОРМЫ APACHE HADOOP ДЛЯ
ПАРАЛЛЕЛЬНЫХ И РАСПРЕДЕЛЁННЫХ ВЫЧИСЛЕНИЙ
В связи с широким распространением Grid-систем для научных вычислений важной становится
проблема выбора наиболее подходящей платформы для решения конкретных задач. Проблема
усложняется ещё и тем, что тенденция роста объёмов данных для обработки имеет экспоненциальный
характер. В работе рассмотрена одна из новейших Grid-платформ, реализующая новейшие методики в
управлении вычислениями, ресурсами, отказоустойчивости и балансировки. Приведено сравнение
основных компонент данной платформы с существующими аналогами и конкурирующими
платформами.
Введение
Ещё недавно, гетерогенные вычис-
ления значительно уступали гомогенным
как по количеству существующих про-
граммных платформ так и по их качеству.
Однако, рост количества различных элек-
тронных устройств, повышение произво-
дительности и функциональности уст-
ройств, а также значительное снижение их
стоимости привели к выравниванию такого
положения. Кроме того, развитию гетеро-
генных вычислений способствует сущест-
вование и развитие платформы Java, как
основы гетерогенных сред, маскирующей
всё разнообразие базовых операционных
сред и аппаратных решений.
Развитие Java платформ для распре-
делённых гетерогенных вычислений по-
шло двумя путями. Первый из них связан с
реализацией парадигмы клиент-серверных
вычислений, приведшей к сервисно-
ориентированным системам. Самым рас-
пространённым представителем этого на-
правления стала система Globus [1]. Вто-
рой путь развития – это одноранговые
(peer-to-peer, Р2Р) решения, где нет чётко
выраженного серверного узла, а взаимо-
действие между двумя узлами кластера
происходит непосредственно. Из наиболее
популярных можно выделить платформы
JXTA [2] и JGroups [3]. К недостаткам су-
ществующих платформ можно отнести их
слаборазвитую инфраструктуру для отка-
зоустойчивых вычислений и отсутствие
адекватных средств для обработки боль-
ших объёмов данных. Это привело к неко-
торой стагнации в развитии платформ для
гетерогенных вычислений, учитывая по-
стоянный экспоненциальный рост коли-
чества обрабатываемой информации.
Встроенных средств распределённой ин-
фраструктуры, адаптированных к обработ-
ке многомерных массивов данных, средств
отказоустойчивости, средств репликации и
эффективного кеширования у существую-
щих платформ либо нет, либо недостаточ-
но. Особенно актуальной эта проблема
стала для поисковых и аналитических сис-
тем Google и Yahoo.
Именно тогда компания Google соз-
дала новую платформу (и, собственно,
подход к вычислениям) MapReduce [4],
предназначенную для высокоэффективных
параллельных вычислений на очень боль-
ших объёмах данных (несколько петабайт),
распределённую файловую систему Google
File System [5] и СУБД BigTable [6].
Подход MapReduce состоит из двух
частей (рис. 1).
Во время выполнения вычислений
первой части, Map, управляющий узел
(master) обрабатывает исходные данные/за-
дачи и производит разбиение с рассылкой
подзадач/блоков данных на остальные,
подчиненные, узлы (worker) кластера.
На этапе выполнения второй части,
Reduce, управляющий узел получает ре-
зультаты вычислений с подчиненных узлов
и на их основе формирует общий
3© К.А. Рухлис, А.Е. Дорошенко, 2010
ISSN 1727-4907. Проблеми програмування. 2010. № 4
Моделі та засоби паралельних і розподілених програм
результат. Одна из особенностей данного
подхода в том, что части Map/Reduce могут
выполняться параллельно. Кроме того, в
общем случае управляющих узлов может
быть больше одного, что позволяет уско-
рить выполнение Map, и повысить отказо-
устойчивость.
При всей общей привлекательности
подхода у этой систем есть два основных
недостатка: проприетарность и возмож-
ность влиять на её развитие только у роди-
тельской компании Google, а также реали-
зация на C++, что накладывает ограниче-
ния на переносимость платформы. Отве-
том Yahoo и Apache Foundation стала от-
крытая реализация MapReduce парадигмы
на Java, получившей название Apache Ha-
doop (http://hadoop.apache.org).
1. Структура Apache Hadoop
Платформа Apache Hadoop [7] – это
развивающаяся и постоянно рас-
ширяющаяся платформа распределенных
параллельных вычислений. Cостоит из
следующих компонент:
• Hadoop Common – ядро и утилитар-
ные части для использования остальными
подпроектами Hadoop;
• Avro – подсистема сериализации
данных и интеграции с обработчиками
сценарных (скриптовых) кодов;
• Chukwa – подсистема сбора данных
для управления большими распреде-
лёнными системами;
• HBase – масштабируемая распреде-
лённая СУБД, конкурент Google BigTable;
• HDFS – распределённая высокоско-
ростная файловая система;
• Hive – инфраструктура для анализа
данных;
• MapReduce – каркас (framework)
для распределённой обработки данных на
кластере;
• Pig – платформа для анализа боль-
ших объёмов данных с использованием
парадигмы MapReduce;
• ZooKeeper – подсистема, координи-
рующая жизненный цикл кластера.
В основу разработки Hadoop были
положены следующие основные критерии:
• масштабируемость – реализовано
надежное хранение и обработка огромных
объемов данных (петабайты);
• гетерогенность и дешевизна – фи-
зическая инфраструктура для Hadoop
представляет собой гетерогенный кластер;
большая часть таких кластеров реализует-
ся на публично доступном оборудовании, а
каждый такой кластер может состоять из
тысяч узлов;
• эффективность – эффективное рас-
пределение данных как основа для высо-
копроизводительных вычислений;
• надежность – использование любых
доступных методологий для
отказоустойчивого хранения данных;
• независимость от платформы – лю-
бая программно-аппаратная среда, для ко-
торой существует виртуальная машина
Вычислительный узел
worker-1
Вычислительный узел
worker-N
...
Map
Map Map
Reduce
Reduce
Рис. 1. MapReduce подход к вычислению задач
4
http://hadoop.apache.org/
Моделі та засоби паралельних і розподілених програм
JVM, подходит для объединения в кластер
Hadoop.
Система Hadoop включает в себя
средства как для реализации обработки
данных (Data Grid), так и высокопроизво-
дительных вычислений (Computational
Grid), что является одной из ключевых ее
особенностей. Кроме того, в отличие от
большинства существующих Grid-
платформ, предназначенных либо для реа-
лизации Data Grid, либо для Computational
Grid, либо для создания инфраструктуры,
Hadoop объединяет в себе все эти средства.
Это позволяет рассматривать Hadoop как
универсальное законченное решения для
вычислительных задач на больших объё-
мах данных, где важнейшее значение име-
ет не только скорость и отказоустойчи-
вость обработки данных, но и вопросы их
хранения и распространения.
Основные компоненты Hadoop –
MapReduce, HDFS и HBase.
1.1. Hadoop MapReduce [8] – реа-
лизация подхода MapReduce в Hadoop.
Предназначен для организации вычисле-
ний на больших объёмах данных. Едини-
цами вычислений в Hadoop являются зада-
ния (Job). В кластере обязательно сущест-
вует минимум один узел JobTracker (любой
узел), который выполняет функции управ-
ления работой остальных вычислительных
узлов. В его функции входит управление
выполнением заданий, планирование вы-
полнения, мониторинг выполнения, пере-
распределение задач в случае отказа вы-
числительных узлов (Task Tracker). Кроме
того, в Hadoop MapReduce входят средства
для управления кешированием, сжатием
промежуточных данных, балансировкой
нагрузки в кластере, отладки, выстраива-
ние задач в очереди.
1.2. Hadoop HDFS [9, 10] – второй
по важности компонент Hadoop, пред-
ставляющий собой распределённую фай-
ловую систему. Её структура показана
на рис. 2.
HDFS использует парадигму веду-
щий/ведомый (master/slave). Сам кластер
состоит из:
1) одного ведущего серверного узла
NameNode (master-server), управляющего
файловой системой и доступом клиентов к
файловой системе. К функциям NameNode
относятся также распределение размеще-
ния файлов по файловой системе и работа
с метаданными. Следует учесть, что в об-
мене данными конкретных файлов между
хранилищем и клиентом NameNode непо-
средственно не участвует;
2) узлов данных DataNode, которые
используются собственно для физического
хранения конкретных файлов. Следует
учитывать, что файл HDFS логически со-
стоит из блоков, а DataNode хранят физи-
Рис. 2. Архитектура Hadoop HDFS
5
Моделі та засоби паралельних і розподілених програм
чески и обеспечивают операции чте-
ния/записи/создания/удаления/репликации.
Таким образом, файл HDFS физически
может храниться блоками на нескольких
узлах DataNode. Обычно, количество узлов
DataNode равно количеству узлов кластера
Hadoop;
3) клиентов – любых приложений, ко-
торым нужен доступ к определённому
файлу/каталогу HDFS.
Пространство имён HDFS – иерар-
хическое, где любой клиент может прово-
дить операции создания/удаления/чтения/
записи как каталогов, так и файлов. Отка-
зоустойчивость обеспечивается репли-
кацией блоков в нескольких экземплярах
на разных узлах. Алгоритмы репликации и
количество копий настраиваются в Hadoop.
Кроме того, в HDFS реализован механизм
отложенного удаления или удаления «в два
этапа»: после запроса на удаление файл
перемещается в каталог /trash и хранится
там определенный период времени. Имен-
но в этот период времени пользователь
может восстановить его.
Кроме того, для обеспечения отка-
зоустойчивости каждый DataNode раз в
определенный период времени посылает
сигнал NameNode, сигнализирующий
NameNode, что этот узел «жив». В случае
неполучения сигнала NameNode помечает
конкретный DataNode как «мёртвый» и ре-
плицирует все хранившиеся на нём блоки
на другие узлы.
1.3. Hadoop HBase [11] представ-
ляет собой распределённое хранилище
данных, реализующее парадигму BigTable.
Данные организованы в таблицы. Но, в от-
личии от традиционной реляционной мо-
дели и существующих реляционных
СУБД, одна и та же ячейка таблицы может
содержать одновременно несколько значе-
ний. Для различения этих значений ис-
пользуется временная метка добавления
этих данных. Основа парадигмы BigTable,
в противовес реляционной модели, – это
использование понятия Map (ассоциатив-
ного массива), как абстрактного типа дан-
ных, определяющего множество уникаль-
ных ключей, каждому из которых соответ-
ствует одно или несколько значений.
Физически таблица HBase может
быть представлена следующим образом:
Map<byte[], Map<byte[], Map<byte[],
Map<Long, byte[]>>>>.|
Первый Map отображает ключи
строк к семействам столбцов, второй – се-
мейства столбцов на ключи столбцов, тре-
тий – ключи столбцов на временные метки,
а последний – временные метки на кон-
кретные значения ячеек. В качестве типов
данных для ключей обычно используют
строки. Временная метка хранится в цело-
численном типе long, а значение колонки –
как массив байтов. Ключ столбца всегда
описывается в комбинации с его семейст-
вом: family:key. Для получения конкретно-
го значения ячейки необходимо знать три
координаты: ключ строки, ключ столбца,
временная метка.
Вторым отличием HBase от обыч-
ных реляционных СУБД является её при-
надлежность к классу нереляционных рас-
пределенных (NoSQL) СУБД. Этот класс
предназначен для решения основных про-
блем реляционных СУБД: масштабируе-
мости, балансировки нагрузки на узлы,
обеспечения эффективного и отказоустой-
чивого механизма хранения данных, ли-
нейного увеличения (в худшем случае) ко-
личества дополнительных обменов дан-
ными для распределённой транзакции и
усложнения инфраструктуры для под-
держки распределённых транзакций. Соб-
ственно, одной из нереляционных СУБД и
является HBase.
К основным характеристикам HBa-
se относятся [11, 12]:
1) использование парадигмы Map для
представления данных;
2) распределённость – данные распре-
делены по кластеру для ускорения, отказо-
устойчивости и балансировки нагрузки на
узлы; постоянно используется репликация
и оптимизация по ряду параметров и кэ-
ширование наиболее часто используемых
данных;
3) отсортированность – характерная
черта HBase, все пары ключ-значение хра-
нятся в отсортированном порядке;
4) многомерность – одна и та же ячей-
ка таблицы может содержать одновремен-
но несколько значений; размерности ячеек
6
Моделі та засоби паралельних і розподілених програм
не обязаны совпадать;
5) разряжённость данных (sparse) –
любая строка может иметь любое количе-
ство столбцов в семействе или не иметь их
вовсе. Количество столбцов в двух разных
строках независимо друг от друга;
6) сохраняемость – данные, которые
были сохранены, остаются в базе до тех
пор, пока не будут оттуда удалены соответ-
ствующим запросом. Ни перезагруз-
ка/остановка серверов, ни сетевые пробле-
мы не приведут к потере сохранённых
данных.
2. Сравнение некоторых
возможностей и производительно-
сти компонент Hadoop с конкури-
рующими платформами
Собственно Hadoop – уникальный
продукт, объединяющий в себе средства
для реализации распределенной обработки
данных (Data Grid) , высокопроизводи-
тельных вычислений (Computational Grid)
и обеспечения инфраструктуры. Поскольку
конкурирующих продуктов с таким набо-
ром интегрированных подсистем фактиче-
ски нет, то сравнивать можно только кон-
кретные подсистемы.
Одной из основных подсистем Ha-
doop, фактически реализующей принцип
MapReduce подход для построения высо-
копроизводительных вычислений, является
Hadoop MapReduce. Его основным кросс-
платформенным конкурентом, основанным
на Java и также реализующий MapReduce
парадигму явялется система GridGain
(http://www.gridgain.com/). К преимущест-
вам этой системы перед Hadoop MapRe-
duce с функциональной точки зрения мож-
но отнести:
1) автоматический поиск и обнаруже-
ние узлов в кластер;
2) автоматическую установку и раз-
вёртывание программ на узлы;
3) встроенную поддержку интеграции
со всеми распространёнными приклад-
ными программными интерфейсами и из-
вестными серверами приложений Java, та-
ких как: JBoss, Spring, Spring AOP, JBoss
AOP, AspectJ, JGroups, Coherence, GigaS-
paces, JXInsight, Weblogic, Websphere;
4) развитый прикладной программный
интерфейс для добавления собственных
поставщиков услуг.
К преимуществам Hadoop MapRe-
duce относятся более развитые средства
отказоустойчивости, балансировки, мони-
торинга и отладки процесса выполнения,
наличие возможности компрессии данных
во время информационных обменов.
2.1. Сравнение производительно-
сти HBase/HDFS и производительности
DBMS-X. DBMS-X – одна из самых рас-
пространённых параллельных реляцион-
ных СУБД с языком запросов SQL. Также
как и HBase, эта СУБД использует репли-
кацию данных для ускорения доступа и
повышение отказоустойчивости. Для уско-
рения доступа к данным внутри таблиц,
после репликации DBMS-X производит
индексацию и сортировку данных по раз-
личным атрибутам и метаатрибутам. Хра-
нение осуществляется по «строчному»
принципу, в отличие от HBase. Основной
сценарий использования и оптимизация
этой СУБД заключается в применении её в
режиме чтения/добавления данных, в чем
назначение HBase и DBMS-X и пересека-
ются.
Одной из отличительных особенно-
стей хранения данных DBMS-X является
её способность сжимать таблицы данных,
при этом в ряде случаев достигается 40 %
увеличение производительности операций
с БД в режиме чтения. Единственная про-
блема – то, что система недостаточно ин-
теллектуальна, чтоб определить текущий
способ использования того или иного эк-
земпляра СУБД. В результате, если вклю-
чена служба репликации DBMS-X либо же
СУБД используется в режиме постоянного
добавления-модификации-удаления дан-
ных, то компрессия данных приводит к по-
тери производительности по сравнению с
несжатым контентом.
Физически тестовая система пред-
ставляет собой гетерогенный кластер из
250 узлов, с ЦПУ различной архитектуры
и возможностей в большом диапазоне ар-
хитектур, от Pentium 4 3GHz до Intel Core 2
7
http://www.gridgain.com/
Моделі та засоби паралельних і розподілених програм
Quad Q9650 3.0GHz/12MB/1333MHz, объ-
ём ОЗУ от 3ГБ до 16ГБ на узел. Тесты со-
стоят из следующих частей:
1) начальная инициализация БД с тре-
мя наборами данных: 0.5GB, 1GB, 2GB на
узел;
2) сохранение данных в БД отдельны-
ми транзакциями;
3) выполнение запросов на чтение к
БД;
4) проверка отказоустойчивости.
Начальная инициализация БД в
DBMS-X состоит из собственно изначаль-
ной загрузки дампа данных и, запускаемый
вручную, этап последующего сжатия, ин-
дексирования загруженных данных. Кроме
того, процесс репликации в DBMS-X явля-
ется очень медленным, особенно, если
сравнивать его производительность с про-
изводительностью подсистемы репликации
HBase/HDFS.
При увеличении объёмов данных на
узле, время, необходимое для инициализа-
ции БД DBMS-X растёт фактически ли-
нейно. При этом, HBase/HDFS фактически
не тратит время на репликацию на «логи-
ческом уровне», как это делает DBMS-X, а
использует средства репликации файловой
системы HDFS.
Рис. 3. Скорость изначальной инициализа-
ции БД
Сохранение данных в БД отдель-
ными запросами – тест инициализации
БД, только вместо загрузки данных одним
дампом, каждая запись загружается в БД
отдельным запросом. Ситуация повторяет
начальную инициализацию БД, подсисте-
мы репликации/индексирования DBMS-X
не рассчитаны на такой сценарий работы и
проигрывают методу «грубой силы»
HBase/HDFS. Фактически, HBase/HDFS
тратит время только на то, чтоб размещать
новую запись в распределённом кеше,
время от времени сохранять дамп блока на
диск и осуществлять его репликацию по
узлам.
Выполнение запросов к БД пред-
ставляет собой два теста. В первом тесте
осуществляется выборка данных из одной
таблицы, обработка их бизнес-логикой с
последующей выборкой данных из второй
– каждым вычислительным узлом. Это
один из вариантов повсеместного исполь-
зования реляционных БД, Вторым тестом
является поиск и сбор статистических
данных по вхождению определённых тек-
стовых шаблонов в текстовые поля таблиц.
Это достаточно распространённая задача, к
примеру, подсчёт статистических данных
по ссылкам у поисковых систем. Результат
показан на рис. 4.
Результаты тестов оказались доста-
точно интересными. Как видно из графи-
ков, при выполнении теста 1, т. е., факти-
чески, последовательности простых запро-
сов SELECT, классическая реляционная
СУБД DBMS-X оказалась в худшем случае
в пять раз быстрее чем HBase (4 минуты
против 20), в лучшем случае почти в 7 раз
быстрее чем HBase (10.8 минут против
68.4 минут). Основная причина такого
«провала» HBase – использование реля-
ционной СУБД в идеальных для себя усло-
виях, когда все запросы возможно выпол-
нять используя заранее построенные ин-
дексы и сжатые таблицы данных. HBase
фактически приходилось делать полный
просмотр таблиц данных для отбора той
или иной записи. Это особенно чётко вид-
но, при увеличении объёмов обрабатывае-
мых данных с 0.5ГБ на узел до 2ГБ на
узел.
При этом время выполнения запро-
сов DBMS-X увеличилось всего на 6.8
минут, а время выполнения запросов
HBase – на 48.4 минут (!).
8
Моделі та засоби паралельних і розподілених програм
Рис. 4. Результаты теста 1 и теста 2 выполнения запросов
Также интересными являются и ре-
зультаты второго теста, где DBMS-X уже
не может использовать индексы, кроме то-
го, ей приходится постоянно распаковы-
вать данные, производить лишние обмены
данными между узлами и т. д.
С ростом объёмов обрабатываемых
данных эти недостатки становятся всё бо-
лее явными. Архитектура HBase и находя-
щаяся в основе HDFS намного лучше под-
ходит для подобного рода задач.
Проверка отказоустойчивости
осуществлялась путём принудительного
физического отключения половины узлов
кластера во время проведения второго тес-
та выполнения запросов к БД. Измерялось
общее затрачиваемое время на прохожде-
ние теста. После этого проверялось дина-
мическое подключение узлов в кластер и
последующий запуск этого теста. Измеря-
лось ускорение от подключения дополни-
тельных узлов в кластер. Результаты пока-
зали, приблизительно на 10 % большую
эффективность подсистемы обеспечения
отказоустойчивости и балансировки на-
грузки HBase/HDFS по сравнению с
DBMS-X.
Заключение
Рассмотрена одна из новейших
Grid-платформ Apache Hadoop. Описаны её
основные компоненты. Приведён практи-
ческий пример использования этой плат-
формы и сравнения эффективности её ра-
боты с конкурирующими платформами. В
процессе сравнения выявлен ряд недостат-
ков компонента СУБД HBase по сравне-
нию с «традиционной» параллельной ре-
ляционной СУБД. Также описано, что вы-
числительной подсистеме Hadoop MapRe-
duce не хватает средств Р2Р основанных
платформ. Соответственно, имеется необ-
ходимость в дальнейшем улучшении ос-
новных компонент: MapReduce и HBase.
1. Berman F., Fox G., Hey T. (eds). Grid
Computing: Making the Global Infrastructure
a Reality. Chichester: John Wiley & Sons,
2003. – 1060 p.
2. Sun JXTA, http://jxta.org
3. JGroups, www.jgroups.org
4. MapReduce: Simplified Data Processing on
Large Clusters,
http://labs.google.com/papers/mapreduce.html
9
http://jxta.org/
http://labs.google.com/papers/mapreduce.html
Моделі та засоби паралельних і розподілених програм
5. The Google File System,
http://labs.google.com/papers/gfs.html
Об авторах:
6. Bigtable: A Distributed Storage System for
Structured Data,
http://labs.google.com/papers/bigtable.html
Рухлис Константин Александрович,
младший научный сотрудник,
7. T. White, Hadoop: The Definitive Guide,
Sebastopol: O’Reilly Media, Inc,2009. Дорошенко Анатолий Ефимович,
доктор физико-математических наук, 8. Hadoop MapReduce Documentation,
http://hadoop.apache.org/common/docs/curre
nt/
профессор, заведующий отделом.
Место работы авторов: 9. Hadoop Distributed File System
Documentation,
http://hadoop.apache.org/common/docs/curre
nt/hdfs_user_guide.html
Институт программных систем
НАН Украины,
10. HDFS Architecture,
http://hadoop.apache.org/common/docs/curre
nt/hdfs_design.html
03187, Киев-187,
Проспект Академика Глушкова, 40.
Тел.: 0503122617,
11. HBase Documentation,
http://hadoop.apache.org/hbase/docs/r0.20.2/ e-mail: ukkr@yandex.ru
12. Understanding HBase and BigTable,
http://jimbojw.com/wiki/index.php?title=Und
erstanding_HBase_and_BigTable .
Получено 03.03.2010
10
http://labs.google.com/papers/gfs.html
http://labs.google.com/papers/bigtable.html
http://hadoop.apache.org/common/docs/current/hdfs_user_guide.html
http://hadoop.apache.org/common/docs/current/hdfs_user_guide.html
http://hadoop.apache.org/common/docs/current/hdfs_design.html
http://hadoop.apache.org/common/docs/current/hdfs_design.html
http://hadoop.apache.org/hbase/docs/r0.20.2/
http://jimbojw.com/wiki/index.php?title=Understanding_HBase_and_BigTable
http://jimbojw.com/wiki/index.php?title=Understanding_HBase_and_BigTable
|
| id | pp_isofts_kiev_ua-article-966 |
| institution | Problems in programming |
| keywords_txt_mv | keywords |
| language | Russian |
| last_indexed | 2026-06-02T01:02:02Z |
| publishDate | 2026 |
| publisher | PROBLEMS IN PROGRAMMING |
| record_format | ojs |
| resource_txt_mv | ppisoftskievua/df/8af738c6efa4084ddd822aacd9aceddf.pdf |
| spelling | pp_isofts_kiev_ua-article-9662026-06-01T21:28:34Z The means of the apache hadoop for parallel and distributed programs Средства платформы apache hadoop для параллельных и распределенных вычислени Засоби платформи apache hadoop для паралельних і розподілених обчислень Rukhlis, K.A. Doroshenko, A.Yu. UDC 004.075 УДК 004.075 УДК 004.075 Nowadays Grid-based scientific projects become more wide-spread. However, the essential restriction is the problem to choose the appropriate platform for concrete tasks resolutions. The distributed platform Apache Hadoop is considered in the paper. This modern Grid platform, based on the modern scientific paradigms, is suitable for processing of the huge amount of the data in reliable and effective way. The functional comparison of this platform to the other modern Grid platforms is described in this paper.Problems in programming 2010; 4: 3-10 В связи с широким распространением Grid-систем для научных вычислений важной становится проблема выбора наиболее подходящей платформы для решения конкретных задач. Проблема усложняется ещё и тем, что тенденция роста объёмов данных для обработки имеет экспоненциальный характер. В работе рассмотрена одна из новейших Grid-платформ, реализующая новейшие методики в управлении вычислениями, ресурсами, отказоустойчивости и балансировки. Приведено сравнение основных компонент данной платформы с существующими аналогами и конкурирующими платформами.Problems in programming 2010; 4: 3-10 У зв'язку з широким розповсюдженням Grid-систем для наукових обчислень важливою стає проблема вибору найбільш підходящої платформи для вирішення конкретних завдань. Проблема ускладнюється – тим, що тенденція зростання обсягів даних для обробки має експонентний характер. У роботі розглянута одна з новітніх Grid-платформ, що реалізує сучасні методики керування обчисленнями, ресурсами та балансування навантаженням. Наведено порівняння основних компонент даної платформи з існуючими аналогами і конкуруючими системами.Problems in programming 2010; 4: 3-10 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2026-06-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/966 PROBLEMS IN PROGRAMMING; No 4 (2010); 3-10 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2010); 3-10 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2010); 3-10 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/966/1034 Copyright (c) 2026 PROBLEMS IN PROGRAMMING |
| spellingShingle | UDC 004.075 Rukhlis, K.A. Doroshenko, A.Yu. The means of the apache hadoop for parallel and distributed programs |
| title | The means of the apache hadoop for parallel and distributed programs |
| title_alt | Средства платформы apache hadoop для параллельных и распределенных вычислени Засоби платформи apache hadoop для паралельних і розподілених обчислень |
| title_full | The means of the apache hadoop for parallel and distributed programs |
| title_fullStr | The means of the apache hadoop for parallel and distributed programs |
| title_full_unstemmed | The means of the apache hadoop for parallel and distributed programs |
| title_short | The means of the apache hadoop for parallel and distributed programs |
| title_sort | means of the apache hadoop for parallel and distributed programs |
| topic | UDC 004.075 |
| topic_facet | UDC 004.075 УДК 004.075 УДК 004.075 |
| url | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/966 |
| work_keys_str_mv | AT rukhliska themeansoftheapachehadoopforparallelanddistributedprograms AT doroshenkoayu themeansoftheapachehadoopforparallelanddistributedprograms AT rukhliska sredstvaplatformyapachehadoopdlâparallelʹnyhiraspredelennyhvyčisleni AT doroshenkoayu sredstvaplatformyapachehadoopdlâparallelʹnyhiraspredelennyhvyčisleni AT rukhliska zasobiplatformiapachehadoopdlâparalelʹnihírozpodílenihobčislenʹ AT doroshenkoayu zasobiplatformiapachehadoopdlâparalelʹnihírozpodílenihobčislenʹ AT rukhliska meansoftheapachehadoopforparallelanddistributedprograms AT doroshenkoayu meansoftheapachehadoopforparallelanddistributedprograms |