Экосистема для хранения и обработки больших данных на кластере обычных машин: HDFS (распределённая файловая система), YARN (менеджер ресурсов), MapReduce (исходный движок обработки), плюс надстройки: Hive (SQL поверх файлов), Spark, HBase, Sqoop (импорт из баз), Oozie/Airflow для оркестрации. Сегодня из этого набора чаще всего живут HDFS или S3 как хранилище, YARN или Kubernetes как ресурсы и Spark как движок.
Файл делится на блоки по 128 МБ (настраивается), каждый блок реплицируется на три DataNode (фактор репликации 3). Файл в 100 МБ займёт один блок меньше полного размера, блок займёт только 100 МБ на диске, но три копии. Клиент получает от NameNode список узлов, пишет первую копию, DataNode передают блок дальше по конвейеру. NameNode хранит метаданные в памяти: имя файла, права, список блоков и их расположение на узлах; сами данные через NameNode не проходят. Репликация даёт отказоустойчивость и локальность чтения: задача запускается там, где лежит блок.
В HDFS каждый файл и блок это запись в памяти NameNode (около 150 байт): миллионы мелких файлов исчерпывают память единственного NameNode и замедляют операции с метаданными, а каждый файл занимает отдельный блок и задачу при чтении. В S3 нет NameNode и лимита на число объектов, поэтому система не ломается, но остаются накладные расходы: листинг миллионов объектов медленный, каждый объект это отдельный запрос с задержкой, чтение мелких файлов Spark'ом дорогое. Лечение общее: компакция в файлы по 100–500 МБ и партиционирование без лишней детализации.
HDFS: блоки на дисках узлов кластера, локальность данных, NameNode как единая точка метаданных, пропускная способность кластера, ограничение по числу файлов. S3: объектное хранилище, отделённое от вычислений, масштабируется бесконечно и дёшево, нет локальности, выше задержка на запрос, нет переименования папок (переименование это копирование), листинг дорогой, итоговая согласованность исторически. Сейчас стандарт: S3 как хранилище, Spark/Trino как вычисления, Iceberg как слой таблиц. S3 против PostgreSQL: S3 хранит файлы без схемы, транзакций и индексов, дёшево и много; база хранит структурированные данные с запросами, ограничениями и транзакциями, дорого и ограниченно по объёму.
Hive даёт SQL поверх файлов в HDFS/S3 и каталог таблиц (Hive Metastore), который используют и Spark, и Trino. Эффективен для пакетной обработки больших таблиц по расписанию, где задержка не важна; для интерактивных запросов его сменили Spark, Impala, Trino. Метаданные Hive это таблица и её партиции как пути к папкам, список файлов определяется листингом директории при запросе. Iceberg хранит метаданные в самих файлах: snapshot → manifest list → manifest с перечнем файлов данных и статистикой по колонкам, поэтому планирование не требует листинга, видны версии и возможны атомарные изменения.
Префиксы по слою и источнику с партициями по дате: raw/<источник>/<таблица>/dt=2025-04-01/part-0001.parquet, отдельно staging, marts, quarantine. Это даёт отсечение по дате при чтении Spark/Trino, понятные права по префиксам и политики жизненного цикла (удалить raw старше года). Файлы в корень без префиксов работают, но листинг и права становятся неуправляемыми. Теги на бакетах и объектах нужны для учёта затрат и политик. Каталог (Glue, Hive Metastore, OpenMetadata) делает файлы таблицами с схемой и lineage; без него озеро превращается в свалку.
Ориентир: файлы по 100–500 МБ, партиции по дню, число объектов в партиции единицы или десятки. Тысячи мелких JSON от API сохраняют в raw как есть (это журнал), но на следующем слое компактят в Parquet. Регулярность задаёт пайплайн: одна загрузка в сутки это одна партиция; стриминг пишет часто и требует периодической компакции. Мониторить число объектов и суммарный размер по префиксам.