Big Data
Большие данные — данные такого объёма или скорости поступления, что одна машина и обычная СУБД с ними не справляются, и нужен распределённый кластер.
Что такое Big Data
Big Data (большие данные, «биг дата») — данные, которые нельзя обработать на одной машине обычной СУБД за приемлемое время. Определение техническое, а не про величие: как только запрос перестаёт помещаться в один сервер и приходится раскладывать данные и вычисления по кластеру, начинается Big Data. Пока помещается — это просто данные, даже если их сотни гигабайт.
Отсюда главный практический вывод: «большие» — не абсолютная величина. 500 ГБ логов, по которым раз в день строят три агрегата, большими данными не являются. 50 ГБ, по которым нужны произвольные срезы за секунду при 1000 одновременных пользователей, — уже проблема соответствующего класса.
Про «три V» — и почему их мало
Каноническое определение перечисляет Volume (объём), Velocity (скорость поступления), Variety (разнородность); позже добавили Veracity (достоверность) и Value (ценность). Модель полезна как чек-лист, но решение принимается не по ней: она не отвечает на вопрос, нужен ли вам кластер. Отвечает — упирается ли конкретная нагрузка в один сервер.
Когда данные действительно «большие»
Ориентиры по порядку величины — это не жёсткие границы, а точки, где обычно меняется инструмент:
| Объём активных данных | Что берут | Почему |
|---|---|---|
| До ~100 ГБ | PostgreSQL, MySQL | Влезает в RAM и индексы одного сервера |
| Сотни ГБ — единицы ТБ | ClickHouse на одной ноде | Колоночное хранение и сжатие снимают проблему |
| Десятки ТБ и выше | Greenplum, ClickHouse-кластер | Одна машина не тянет ни диск, ни скан |
| Сотни ТБ — петабайты | Spark + object storage | Хранение отделено от вычислений |
Порядок действий, который экономит бюджеты: сначала колоночная СУБД и нормальные индексы, только потом кластер. Значительная часть «биг-дата»-проектов — это OLTP-база, которую использовали не по назначению.
Из чего состоит стек
- Хранение: HDFS или object storage (S3, MinIO) — сырой слой в Parquet.
- Обработка: Spark для батчей, Flink для потока.
- Транспорт: Kafka — буфер между источниками и обработкой.
- Запросы: ClickHouse, Greenplum, Trino поверх файлов.
- Оркестрация: Airflow или Dagster — расписание и зависимости ETL.
- Витрины: DWH и BI поверх него.
Почему нужен кластер
Одна машина упирается в физику. Диск читается со скоростью порядка гигабайта в секунду у NVMe — полный скан 100 ТБ занял бы сутки с лишним, сколько бы ядер вы ни поставили. Единственный выход — читать параллельно с сотни дисков, то есть шардировать данные по узлам и приносить вычисление к данным, а не наоборот. На этой идее построены и MapReduce, и Spark, и MPP-хранилища.
Второй ограничитель — надёжность: на сотне узлов диски выходят из строя регулярно, поэтому репликация и повтор упавших задач встроены в такие системы по умолчанию.
Инфраструктура
Big-data-кластер — это не «много сильных серверов», а много средних. Типовая нода обработки: 16–32 ядра, 128–256 ГБ RAM, локальные NVMe под shuffle. Узкое место чаще сеть, а не CPU: shuffle в Spark гоняет между нодами объёмы, сопоставимые с исходным датасетом, поэтому 10 Gbit/s внутри стойки — практический минимум.
GPU в классическом big-data-стеке не нужны: SQL-агрегация и джойны упираются в диск и сеть. Карты появляются на следующем шаге — когда на собранных данных обучают модели в рамках Data Science.
Связанные термины
- Hadoop / Spark / Hive — базовый стек обработки больших данных
- DWH / хранилища данных — куда big data превращается в витрины
- ETL / интеграция данных — как данные попадают в контур
- Шардирование — механизм, делающий кластер возможным
- ClickHouse — частая альтернатива кластеру для аналитики
- Data Science — что делают с данными после сбора
Готовы запустить GPU-задачу?
Запустить GPU-сервер