Распределённые вычисления на Android: настройка кластеров Spark и Hadoop в Termux

Android-устройства в связке с Termux позволяют организовать учебный и прикладной кластер распределённых вычислений «по месту»: несколько телефонов/планшетов работают как узлы, а главный мобильный компьютер выполняет оркестрацию. Важно честно понимать ограничения: слабая оперативная память, тепловые режимы, ограниченная пропускная способность Wi‑Fi и особенности мобильных ОС. Поэтому в статье мы будем делать акцент на практиках стабильности: управлении памятью, аккуратной сетевой настройке и корректной подготовке конфигураций Spark и Hadoop.

Материал ориентирован на безопасные сценарии: кластер создаётся во внутренней локальной сети (LAN) между устройствами, без задач по обходу блокировок.

Требования и архитектура кластера

Рекомендуемая архитектура:

1 узел-мастер (может быть один из устройств) — управляет распределением задач.
1–N узлов-воркеров — исполняют вычисления.
Одинаковая локальная сеть — все устройства должны видеть друг друга по IP.

Базовые требования:

Android 10+ (желательно 11/12+).
Termux последней версии.
Хороший Wi‑Fi или локальная сеть через роутер.
Желательно: отдельное питание/зарядка для узлов воркеров.

По сети важен принцип: сначала добиваемся устойчивого обмена между узлами, и только затем поднимаем демоны Spark/Hadoop. Иначе вы получите «зависания» и долгие таймауты.

Подготовка Termux: окружение и базовые пакеты

Начнём с базовой подготовки. Ориентируйтесь на разный объём памяти: для телефонов с 4 ГБ RAM и меньше особенно критично следить за JVM-параметрами.

pkg update -y && pkg upgrade -y
pkg install -y openjdk-17 wget curl tar nano rsync net-tools proot

Далее проверим Java:

java -version

Если планируете Spark/Hadoop с JVM, лучше держать единый Java на всех узлах кластера.

Создание локальной сети между устройствами

Для кластеризации требуется, чтобы устройства обменивались трафиком по IP. Самый простой вариант — подключить все устройства к одному Wi‑Fi/роутеру. Если вы используете VPN, то только для создания локальной сети между устройствами (например, туннель для LAN-сегмента), а не для обхода блокировок.

Проверьте доступность адресов:

ip a
netstat -rn

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

Стратегия хранения данных и логов на Android

Android-накопители и файловые системы имеют нюансы производительности. Для устойчивости:

Храните логи в локальных каталогах Termux, а не на внешних SD при возможности.
Используйте отдельные директории для данных, временных и логов.
Ограничивайте размер кэшей (особенно в Spark).

Пример структуры каталогов:

mkdir -p ~/cluster/{hadoop,spark,data,logs,conf,tmp}

Установка Hadoop на узле (подход для Android)

На Android нет «готового Hadoop-пакета под Termux», поэтому обычно делается установка из исходников или использование бинарей, которые можно запустить в пользовательском пространстве. На практике чаще всего берут бинарный дистрибутив Hadoop, а затем адаптируют пути и JVM-параметры.

Примерно для подготовки (проверяйте актуальность версий и совместимость):

cd ~/cluster
wget -O hadoop.tar.gz <URL_к_дистрибутиву_Хadoop>
tar -xzf hadoop.tar.gz
mv hadoop hadoop-3.x

Далее зададим переменные окружения в ~/.bashrc (или используйте Termux: при необходимости добавьте в профиль):

nano ~/.bashrc

Добавьте (пример):

export JAVA_HOME="$HOME/.sdkman/candidates/java/current" 2>/dev/null || true
export HADOOP_HOME="$HOME/cluster/hadoop-3.x"
export PATH="$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin"

Затем загрузим профиль:

source ~/.bashrc

Проверим:

hadoop version

Конфигурация Hadoop для небольшого кластера

Для мобильных узлов важно минимизировать число компонентов и «тяжёлых» сервисов. Типовой набор включает NameNode, DataNode и JobHistory/ResourceManager (в зависимости от режима). Для учебного и компактного кластера часто используют:

Standalone/псевдо-кластер (минимум демонов) для отладки.
Затем — ограниченный режим с несколькими ролями на разных узлах.

Основные конфигурации Hadoop обычно лежат в $HADOOP_HOME/etc/hadoop. На мобильных устройствах удобнее хранить конфиги в каталоге проекта и синхронизировать их на узлы через rsync.

Пример синхронизации конфигов:

rsync -av ~/cluster/conf/ hadoop@<worker_ip>:~/cluster/conf/

Для корректной работы NameNode и DataNode подготовьте:

core-site.xml — задаёт адреса HDFS и временные параметры.
hdfs-site.xml — настройки репликации и путей хранения.
yarn-site.xml (если используете YARN) — планировщик ресурсов.

Пример параметра репликации для небольшого кластера (на 2 узлах репликация 2 может быть допустима, но с Android вы часто выбираете компромисс):

<property>
  <name>dfs.replication</name>
  <value>2</value>
</property>

Важнее всего: укажите корректные пути для NameNode/DataNode на каждом узле, чтобы не писать на недоступные директории.

Spark на Android: установка и базовая конфигурация

Spark в Termux запускается как JVM-приложение. На слабых устройствах критично ограничивать:

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

Подготовим каталог:

cd ~/cluster
wget -O spark.tgz <URL_к_дистрибутиву_Spark>
tar -xzf spark.tgz
mv spark spark-3.x

Проверим:

~/cluster/spark-3.x/bin/spark-submit --version

Дальше нужно настроить master/worker:

spark://<master_ip>:7077 — адрес Spark master.
рабочие узлы подключаются через SPARK_WORKER_CORES и память.

Оптимизация памяти: JVM и лимиты под Android

Для Android оптимизация памяти — ключ к стабильности. Рекомендации:

Устанавливайте фиксированные значения для driver/executor memory.
Снижайте number of cores для исполнителей, чтобы уменьшить давление на CPU и GC.
Убирайте агрессивные кэши.
Контролируйте суммарную память: учтите, что Termux + OS + браузеры/фоновые процессы тоже забирают RAM.

Пример JVM-параметров (используются через env/system properties):

export SPARK_DAEMON_JAVA_OPTS="-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xms256m -Xmx512m"

Для spark-submit:

spark-submit 
  --master spark://<master_ip>:7077 
  --deploy-mode client 
  --driver-memory 512m 
  --executor-memory 512m 
  --executor-cores 1 
  --conf spark.sql.shuffle.partitions=8 
  --conf spark.storage.level=MEMORY_AND_DISK_SER 
  --conf spark.locality.wait=1 
  <ваш_скрипт_or_jar>

Для Hadoop тоже нужно ограничить JVM:

export HADOOP_HEAPSIZE=512

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

Сетевое взаимодействие: порты, имена и таймауты

Чтобы Spark и Hadoop работали между узлами, важно:

правильно указать hostnames/IP в конфигурациях;
разрешить необходимые порты (на стороне роутера/файрвола);
избежать NAT/изоляции клиентов в «гостевом Wi‑Fi».

Для отладки используйте базовую сетевую диагностику:

ping -c 3 <ip_другого_узла>
nc -vz <ip_узла> 7077
nc -vz <ip_узла> 9000

Если nc не установлен:

pkg install -y netcat-openbsd

Порты Spark по умолчанию:

7077 — master URL;
динамические порты воркеров (их можно ограничивать через настройки, чтобы упростить диагностику).

Порты Hadoop (HDFS/YARN) зависят от выбранной роли. Для компактного кластера лучше заранее зафиксировать минимальный набор и проверять его на каждом узле.

Запуск Spark: master и worker

На master-узле:

cd ~/cluster/spark-3.x
./sbin/start-master.sh

Проверьте веб-страницу master (если доступна из сети) или журналы в logs/.

На worker-узлах выполните:

cd ~/cluster/spark-3.x
./sbin/start-worker.sh spark://<master_ip>:7077

Если worker не подключается, в первую очередь проверьте IP маршрутизацию (устройства должны быть в одном сегменте), затем доступность порта master и корректность времени (разные часы иногда создают проблемы с TLS/подписью логов, хотя в базовой конфигурации это реже).

Запуск Hadoop: минимальный сценарий и проверка HDFS

На узле NameNode подготовьте форматирование (обычно выполняется один раз):

cd $HADOOP_HOME
hdfs namenode -format

Далее запустите демоны (на практике состав зависит от того, как вы распределили роли между узлами):

start-dfs.sh
start-yarn.sh

Проверка HDFS:

hdfs dfs -mkdir -p /user
hdfs dfs -ls /

Для отладки удобно выполнить простой тест чтения/записи:

echo "hello from android cluster" | hdfs dfs -put - /user/hello.txt
hdfs dfs -cat /user/hello.txt

Как запускать вычисления Spark поверх данных Hadoop

После того как HDFS доступен, можно запускать задачи Spark, читающие данные из HDFS. Примерная идея:

загружаем небольшой набор данных в HDFS;
выполняем Spark job с ограниченным числом партиций;
смотрим логи и web-интерфейсы Spark.

Если вы запускаете spark job, ориентируйтесь на параметры:

--conf spark.default.parallelism=8
--conf spark.sql.shuffle.partitions=8
--conf spark.network.timeout=300s
--conf spark.executor.heartbeatInterval=30s

Эти настройки снижают вероятность «провалов» из‑за временных задержек сети и помогают на Wi‑Fi, где бывают микропотери пакетов.

Практические меры устойчивости на мобильных узлах

Чтобы кластер не «умирал» при работе:

Убедитесь, что устройства не уходят в глубокий сон: отключите оптимизацию батареи для Termux/соответствующих процессов.
Ограничьте фоновую активность.
Запускайте на зарядке.
Следите за температурой (перегрев снижает частоты и увеличивает таймауты).
Очищайте временные файлы: каталоги tmp и устаревшие логи.

Пример очистки:

rm -rf ~/cluster/tmp/*
find ~/cluster/logs -type f -mtime +7 -delete

Типовые проблемы и способы диагностики

Проблема 1: worker не виден master’ом. Проверьте IP, порты, и что устройства в одной сети. Выполните nc -vz <master_ip> 7077 с worker.

Проблема 2: падает JVM (OOM). Уменьшайте --executor-memory, --driver-memory, снижайте число партиций и кеширование.

Проблема 3: длительные зависания на shuffle. На мобильных сетях shuffle дорогой. Снижайте spark.sql.shuffle.partitions, уменьшайте объём данных, используйте локальную обработку небольших наборов.

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

Заключение

Организация распределённых вычислений Spark и Hadoop в Termux на Android — реальный и полезный опыт, если подойти к задаче инженерно: обеспечить работу в локальной сети, корректно настроить адреса и порты, а главное — грамотно ограничить память JVM и снизить нагрузку на shuffle и параллелизм. Такой кластер чаще всего подходит для обучения, прототипов и небольших задач, где важнее стабильность, чем максимальная скорость.

Если вам нужна консультация по подбору архитектуры, конфигураций Spark/Hadoop под конкретные модели устройств, а также сопровождение по внедрению кластера в учебной/прикладной среде — обращайтесь в РыбинскЛАБ (услуги по DevOps/инфраструктуре и инженерному консалтингу для мобильных и серверных стендов).