Termux и распределённые вычисления: развертывание Apache Spark, Hadoop и Dask кластера на мобильных устройствах

Мобильные устройства уже обладают достаточной вычислительной мощностью для учебных сценариев: от экспериментов с распределёнными фреймворками до отладки пайплайнов данных и измерения производительности. В экосистеме Termux это особенно удобно: можно быстро поднять среду выполнения, собрать зависимости и развернуть «мини-кластеры» в пределах локальной сети.

В этой статье покажем, какие архитектурные варианты подходят для Apache Spark, Hadoop и Dask, как подготовить окружение в Termux, как организовать взаимодействие узлов в локальной сети и как избежать типичных проблем (порты, сети, память, файловые системы). Материал ориентирован на обучение и прототипирование, а не на промышленную эксплуатацию.

Правовые и эксплуатационные ограничения (важно)

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

Если вам требуется VPN, используйте его только для создания локальной сети между устройствами (например, при отсутствии общего Wi‑Fi), а не для обхода ограничений внешнего доступа.

Архитектура мини-кластера: что реально работает на мобильных устройствах

В классической постановке кластер состоит из множества узлов с общей инфраструктурой (DHCP/DNS, стабильные хранилища, высокоскоростное соединение). На телефонах обычно делается следующее:

Один узел — «master» (head): web UI, orchestration.
1–3 узла — worker: исполнители задач и обработчики данных.
Отдельное хранилище обычно не поднимают на телефонах; вместо этого используют временные локальные каталоги или небольшой сетевой ресурс в локальной сети.
Локальная сеть: Wi‑Fi в одной подсети или VPN для объединения в одну подсеть.

Для Hadoop часто требуется HDFS и отдельные демоны (NameNode/DataNode, возможно YARN). На мобильных устройствах разумно начинать с минимального набора и тестировать устойчивость.

Подготовка Termux: базовые пакеты и Java/Python

Для Spark и Hadoop нужен Java. Для Dask — Python и обычно Docker/SSH не требуются, но полезна связность по сети.

На каждом устройстве подготовьте Termux и обновите базовые пакеты:

pkg update && pkg upgrade -y

Для Spark/Hadoop:

pkg install -y openjdk-17-jre-headless wget tar procps

Для Dask (и общих утилит):

pkg install -y python git curl nano

Далее удобнее работать в виртуальном окружении:

python -m venv ~/venv
source ~/venv/bin/activate
pip install --upgrade pip

Проверка Java:

java -version

Проверка сети: получите IP устройства.

ip addr show

Запишите IP в локальной сети: они понадобятся для конфигурации Spark master/workers, Hadoop (если вы поднимете демоны) и Dask scheduler/workers.

Организация сети между устройствами

Для корректной работы распределённых фреймворков узлам нужны прямые подключения по IP и портам. Обычно достаточно:

Подключить все устройства к одному Wi‑Fi.
Проверить, что IP устройства видны друг другу (без требований к внешнему доступу).
Открыть нужные порты локально (на телефонах часто дополнительных правил firewall не требуется, но следите за системными ограничениями).

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

ping <ip_второго_устройства>

Если ping невозможен из-за особенностей сети, все равно может работать TCP. Проверяйте порты утилитами вроде telnet/netcat (если доступно в Termux). Например:

pkg install -y netcat
nc -vz <ip_второго_устройства> <порт>

При необходимости используйте VPN только для создания общей локальной сети между устройствами.

Развертывание Dask кластера в Termux (рекомендуемый старт)

Dask — один из самых «дружелюбных» к прототипированию вариантов. Для него обычно достаточно запустить scheduler и workers, настроив адреса и количество процессов/потоков.

1) На узле scheduler

В активированном виртуальном окружении:

pip install dask[distributed] --upgrade

Запуск scheduler на узле scheduler (укажите IP интерфейса или используйте 0.0.0.0 для слушания на всех адресах):

dask-scheduler --host 0.0.0.0 --port 8786

Обычно web UI доступен на порту 8787. Подставьте адрес scheduler в браузере с другого устройства.

2) На узле worker

Запуск worker, указав адрес scheduler:

dask-worker <ip_scheduler>:8786 --nprocs 2 --memory-limit 2GB

Параметры подбирайте под RAM вашего устройства. Для телефонов часто лучше использовать меньше процессов и ограничивать memory-limit.

3) Мини-клиент (проверка из Termux)

Создайте простой тестовый скрипт:

cat > test_dask.py << 'PY'
from dask.distributed import Client
import dask.array as da

client = Client("tcp://<ip_scheduler>:8786")

x = da.random.random((2000, 2000), chunks=(500, 500))
y = (x + 1).sum()

print(y.compute())
PY

python test_dask.py

Если вычисления выполняются и возвращается результат — кластер готов.

Развертывание Apache Spark кластера в Termux (standalone/mini-setup)

Для Spark в учебной конфигурации часто используют режим Standalone. На практике это означает: master и workers с простыми конфигурациями, без сложной интеграции с внешними менеджерами.

Ниже — общий план. Реальные версии зависят от доступных ресурсов и Java. Убедитесь, что Spark поддерживает выбранную версию Java.

1) Скачивание Spark

На всех узлах установите один и тот же Spark:

SPARK_VERSION=3.5.1
mkdir -p ~/spark
cd ~/spark
wget -q https://archive.apache.org/dist/spark/spark-${SPARK_VERSION}/spark-${SPARK_VERSION}-bin-hadoop3.tgz
tar -xzf spark-${SPARK_VERSION}-bin-hadoop3.tgz
ln -s spark-${SPARK_VERSION}-bin-hadoop3 current

2) Настройка master/workers

На узле master отредактируйте файлы конфигурации в conf/. Часто для Standalone достаточно задать список workers.

Сделайте базовую конфигурацию директории:

cd ~/spark/current
cp conf/slaves.template conf/slaves
# В conf/slaves перечислите IP worker'ов по одному в строке

Откройте файл conf/slaves и добавьте IP адреса worker-узлов:

nano conf/slaves

Содержимое (пример):

<ip_worker1>
<ip_worker2>

Дополнительно при необходимости проверьте conf/spark-env.sh и переменные окружения (JAVA_HOME и параметры памяти).

3) Запуск master на узле master

cd ~/spark/current
sbin/start-master.sh

Если в вашей сети есть ограничения, полезно явно указать host в conf/spark-env.sh (конкретные переменные зависят от версии Spark, но смысл такой: master должен объявлять корректный адрес).

4) Запуск workers на узлах worker

cd ~/spark/current
sbin/start-slave.sh spark://<ip_master>:7077

Проверка: посмотрите лог master и web UI. Spark Standalone обычно предоставляет web интерфейс на master (порт 8080 по умолчанию).

5) Запуск тестовой задачи

Например, попробуйте простой job wordcount (предварительно подготовьте текстовый файл в доступном каталоге).

cd ~/spark/current
# Пример: если файл доступен локально в каталоге узлов, лучше использовать copy/rsync или сетевую папку
./bin/spark-submit --class org.apache.spark.examples.SparkPi --master spark://<ip_master>:7077 --executor-memory 512M --total-executor-cores 2 examples/jars/spark-examples_2.12-3.5.1.jar 10

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

Развертывание Hadoop кластера на мобильных устройствах (минимальная постановка)

Hadoop сложнее Spark и Dask из-за множества демонов и модели хранения. Тем не менее для обучения можно собрать минимальный stand-alone/HDFS/YARN setup.

Реалистичный сценарий:

Поднять HDFS с одним NameNode и несколькими DataNode (на нескольких устройствах).
Опционально включить YARN для запуска контейнеров.
Для первых тестов ограничиться небольшими данными.

1) Установка Hadoop

Скачайте Hadoop и разверните на всех узлах. Например:

HADOOP_VERSION=3.3.6
mkdir -p ~/hadoop
cd ~/hadoop
wget -q https://archive.apache.org/dist/hadoop/common/hadoop-${HADOOP_VERSION}/hadoop-${HADOOP_VERSION}.tar.gz
tar -xzf hadoop-${HADOOP_VERSION}.tar.gz
ln -s hadoop-${HADOOP_VERSION} current

2) Конфигурация core-site.xml, hdfs-site.xml

Вам нужно корректно настроить:

fs.defaultFS (адрес NameNode).
hosts/подписи DataNode и репликации.
порты (обычно 8020/9000 зависят от версии и конфигов).

Общие файлы лежат в etc/hadoop/ внутри Hadoop.

Пример логики: на master узле задайте NameNode, а на других — список DataNode.

Из-за различий версий и требований к Java лучше ориентироваться на официальные шаблоны конфигураций для выбранной версии Hadoop. Практически вы должны:

Создать имена кластеров/директории журналов.
Согласовать пользователя, права на каталогах, пути для HDFS.
Убедиться, что устройства используют доступные порты.

3) Форматирование HDFS (на NameNode)

cd ~/hadoop/current
bin/hdfs namenode -format

Если директории не подготовлены или прав недостаточно — получите ошибки. На мобильных файловых системах права и производительность могут отличаться, поэтому внимательно следите за каталогами в hadoop.tmp.dir и dfs.data.dir.

4) Запуск NameNode и DataNode

На NameNode (master узел):

bin/hdfs --daemon start namenode

На DataNode (worker узлы):

bin/hdfs --daemon start datanode

Проверьте web UI NameNode (порт 9870 часто используется) и состояние через утилиты:

bin/hdfs dfsadmin -report

5) Запуск MapReduce/YARN (опционально)

Если вы включаете YARN, потребуется дополнительная настройка yarn-site.xml, запуск ResourceManager/NodeManager и проверка связности по сети.

На мобильных устройствах часто на первом этапе проще:

или использовать минимальный режим без YARN (в зависимости от версии),
или ограничиться запуском демо-контейнеров с небольшими ресурсами.

Практические советы: производительность, память и устойчивость

Энергосбережение и throttling: отключайте ограничения производительности, насколько это возможно в настройках ОС.
Термозащита: при длительных нагрузках устройства будут снижать частоту.
Ограничивайте память: в Spark задавайте --executor-memory и число ядер/процессов, в Dask — memory-limit.
Сеть важнее CPU: для распределённых вычислений узким местом часто становится сеть Wi‑Fi, а не вычисления.
Логи решают всё: держите под рукой tail -f логов master/scheduler и демонов Hadoop.

Устранение типовых ошибок

Worker не подключается: проверьте IP, порты и слушает ли сервис на нужном интерфейсе (например, 0.0.0.0 вместо localhost).
Вылеты/OOM: уменьшайте memory и размеры чанков/задач.
Hadoop не стартует: проверьте согласованность конфигов и существование директорий под HDFS, права на каталоги, а также доступность NameNode с DataNode.
Долгие задания: на телефонах выбирайте меньшие размеры данных и больше контролируйте параллелизм.

Безопасность и корректная эксплуатация

Для учебных кластеров включайте осознанный минимум:

Ограничивайте доступ к web UI/демонам в пределах локальной сети.
Не публикуйте порты наружу без необходимости.
Следите за версиями библиотек и не используйте неизвестные скрипты.

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

Сравнение подходов: Spark vs Hadoop vs Dask

Фреймворк	Что удобно на телефонах	Основные сложности
Dask	Легко поднять scheduler/workers, быстрый старт	Ограничения по RAM и параллелизму
Spark	Простая standalone-схема, понятные примеры	Нужно аккуратно настроить хосты и память
Hadoop	Отлично подходит для учебной модели HDFS/MapReduce	Много компонентов и требований к конфигам

Заключение

Termux позволяет организовать учебные и прототипные «мини-кластеры» распределённых вычислений на мобильных устройствах: Dask обычно лучше всего подходит для быстрого старта, Spark — для отработки параллельных задач и пайплайнов, а Hadoop — для знакомства с HDFS/YARN и моделью хранения/вычислений. Ключ к успеху — корректная локальная сеть, разумные ограничения по памяти и внимательная настройка адресов/портов.

Если хотите сделать такой проект «под ключ» или нужна помощь с развертыванием, настройкой и обучением команды, обращайтесь в РыбинскЛАБ — мы поможем спроектировать решение под ваши задачи и условия.