TGViewer
этогик // DevOps, Infrastructure, Productivity этогик // DevOps, Infrastructure, Productivity @etogeek · 4.38K subscribers
Post #356 5.59K
Хочу немного рассказать про стек, о котором я раньше никогда не слышал, а четыре года назад пришлось плотненько познакомиться сначала со стороны администрирования, а спустя время - и чуть-чуть потраблшутить часть разработки.

Добро пожаловать в мир Hadoop.

Всё это поделие максимально плотно связано с Java и Apache. Есть несколько коммерческих дистрибутивов/платформ, но в целом всё это с горем пополам и чертовой матерью поднимается и вручную (хотя может я просто не умею его готовить).

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

Расскажу про те, которые используются у нас.

HDFS - Hadoop Distributed File System - это буквально сетевая файловая хранилка, с репликацией данных, большой пропускной способностью. Состоит из NameNode (мастер-ноды) со всеми метаданными, и DataNode (агенты) - фактическое хранение данных.

HDFS фундаментально работает по системе Write Once Read Many - мы записали файл, и уже не можем его изменить (кроме как append и truncate). Это сильно упрощает модель согласованности данных: читатель гарантированно получает то, что было записано, без конфликтов. HDFS любит большие последовательные чтения файлов. Читать мелкие файлы - не очень.

YARN (Yet Another Resource Negotiator) - это оркестратор задач. Грубо говоря как кубер, только для data-задач - он выделяет на CPU/RAM для них. Есть кластер из нескольких серверов, мы можем запускать на нем yarn-контейнеры(не путать с докером) и выполнять в них map-reduce задачки. Не только MR, конечно, есть еще Spark, Hive и тд.

ResourceManager - мастер, NodeManager - агент на каждой ноде. При создании задачи появляется ApplicationMaster - он общается с ресурс-менеджером и управляет выполнением конкретного задания.

HBase - распределённая NoSQL-база поверх HDFS: по сути, это огромная таблица-словарь, где данные лежат как `row_key → набор полей → значения` (а не как "строка строго фиксированных в схеме колонок", как в реляционках).

В отличие от PostgreSQL, где схема задаёт одинаковые колонки для всех строк, в HBase "схема" обычно фиксирует только column family — условные "папки" полей. А внутри каждой такой "папки" у конкретной строки может быть любой набор колонок, и он может отличаться от строки к строке - удобно для разреженных данных и атрибутов, которые меняются со временем без бесконечных миграций.

Это может быть сложно представить, поэтому вот очень грубый пример:
0001: profile:name, profile:city, profile:role, contacts:telegram
0002: profile:name, profile:role, contacts:vk, contacts:instagram
0003: profile:name (и всё)
0004: profile:name, profile:city, skills:java, skills:kafka, skills:spark


Смысл: families (profile, contacts, skills) заранее "разрешены", а какие именно поля внутри них есть у конкретного пользователя - может отличаться.

По кластеру таблица разъезжается через regions: это диапазоны строк по row_key, и каждый RegionServer обслуживает свой набор регионов.

- HMaster - распределяет данные по нодам, DDL-операции
- RegionServer - воркеры на нодах. Сами данные физически лежат в HDFS, а RegionServer отвечает за чтение, запись и кеширование. Клиент через ZooKeeper/мета‑информацию узнаёт, на каком RegionServer лежит нужный кусок, и дальше идёт напрямую туда.

Во всех этих сервисах ZooKeeper используется как централизованное хранилище информации о состоянии кластера (кто жив, где мастер, где мета-данные). Как etcd в Кубере.

MapReduce - подход к обработке больших данных в два шага. На этапе Map данные разбиваются на куски, YARN поднимает контейнеры-мапперы и каждый преобразует свой кусок в пары "ключ → значение". На этапе Reduce результаты группируются по ключу и агрегируются. Простой грубый пример: считаем сколько пользователей в каждом городе. Map проходит по записям и выдает "Belgrade → 1", "Moscow → 1", "Belgrade → 1". Reduce суммирует по ключу: "Belgrade → 2", "Moscow → 1".
  • ❤ 26
  • 👍 9
  • 🔥 4
  • 😁 1
More from @etogeek
  1. Sep 4, 2026Баланс в EdTech Подписан на канал Mischa van den Burg и там недавно вышло видео, где автор…
  2. Aug 31, 2026Чтобы немного подвести итог серии постов про бекапы (раз и два), расскажу как я ими управл…
  3. Aug 25, 2026Мониторинг бекапов В прошлый раз я говорил про PITR-бекапы для PostgreSQL, теперь хочу нем…
  4. Aug 21, 2026Про бекапы. Хочу немного поделиться своим опытом в нескольких постах. Это больше информаци…
  5. Aug 13, 2026Когда я преподавал в Практикуме (был такой период, да. еще и видео снимал), студенты часто…
  6. Jun 25, 2026Некоторое время назад столкнулся с тем, что какой-то сервис отправил мне огромное количест…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →