Большие данные (Big Data): признаки, методы и инструменты обработки

Большие данные (Big Data) — это наборы данных, которые из-за объема, скорости поступления или разнообразия форматов нельзя удобно хранить и обрабатывать на одном компьютере обычными средствами, поэтому для них используют распределенные системы из многих серверов. Граница не задана числом гигабайт: она определяется тем, справляется ли с задачей одна машина.

Отсюда ответ на частый школьный тест «какие данные из перечисленных можно отнести к большим данным»: верный вариант — журналы поисковых запросов сайта за день. Они огромны по объему, поступают непрерывным потоком и состоят из разнородных полей. Фотографии из отпуска, отчет из 100 строк и подбор пароля от Wi-Fi под эти признаки не подходят. Ниже — разбор теста, признаки 3V/5V, как устроена обработка (с примером MapReduce на Python) и какие инструменты за что отвечают.

Разбор теста: почему именно журналы запросов

Проверять каждый вариант удобно по трем базовым признакам: объем, скорость, разнообразие.

Оговорка: журнал небольшого сайта с сотней посетителей в день спокойно обрабатывается одним скриптом. Тест подразумевает поисковую систему или крупный сервис, где поток запросов действительно огромен.

Признаки больших данных: от 3V к 5V

Классическую модель трех V описал аналитик Дуг Лейни в 2001 году. Позже к ней добавили еще два признака, и получилась модель 5V. Это не стандарт, а удобная мнемоника: встречаются варианты с 7 и 10 V.

Первые три V описывают сами данные и определяют, нужна ли распределенная инфраструктура. Последние два описывают качество и смысл работы: они важны и для маленьких таблиц, поэтому по ним одним «большие» данные от обычных не отличить.

Big Data, база данных, хранилище и озеро данных

Эти термины часто смешивают, хотя они про разное.

• База данных (БД) — система хранения с языком запросов, например PostgreSQL. Она может хранить и маленькие, и большие данные.
• Хранилище данных (DWH) — база для аналитики, куда данные сводят из разных источников уже очищенными и в единой структуре.
• Озеро данных (data lake) — хранилище сырых файлов любого формата (логи, JSON, Parquet, картинки), структура задается при чтении.
• Big Data — не отдельный продукт, а характеристика задачи: объем, скорость и разнообразие требуют распределенной обработки.

Структура данных тоже бывает разной: структурированные (таблицы с фиксированными колонками), полуструктурированные (JSON, XML, логи с метками полей), неструктурированные (текст, аудио, видео, изображения). Журнал запросов обычно полуструктурирован: у каждой записи есть поля, но набор полей может меняться.

Как обрабатывают большие данные

Главная идея — не покупать один сверхмощный сервер, а разделить данные на части и обработать их параллельно на многих обычных машинах (горизонтальное масштабирование). В классическом Hadoop код отправляют туда, где лежат данные (принцип локальности), а не гоняют терабайты по сети. В современных системах на объектном хранилище S3-типа вычисления и хранение разделены: данные читаются по сети, а скорость обеспечивают колоночные форматы и чтение только нужных столбцов и частей.

Режимов обработки два:

• Пакетная (batch) — обрабатывают накопленный объем целиком, например раз в сутки пересчитывают статистику за день. Типичные инструменты: Spark, Hadoop MapReduce.
• Потоковая (stream) — обрабатывают события по мере поступления, с задержкой от долей секунды до минут. Типичные инструменты: Kafka как транспорт плюс Flink или Spark Structured Streaming.

Классическая схема пакетной обработки — MapReduce: map считает промежуточный результат на своем куске данных, shuffle группирует его по ключу, reduce сводит частичные результаты в итог.

MapReduce вручную на восьми записях

Возьмем журнал из восьми запросов и разделим его на два куска, как будто они лежат на двух серверах.

• Кусок A: погода, python, погода, новости. Map дает погода: 2, python: 1, новости: 1.
• Кусок B: python, погода, big data, python. Map дает python: 2, погода: 1, big data: 1.
• Reduce складывает счетчики по ключам: python: 3, погода: 3, новости: 1, big data: 1.

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

Тот же принцип в коде на Python

Модель ниже работает на одном компьютере: вместо серверов — четыре процесса, вместо терабайт — миллион строк. Это упрощение, зато видна вся логика.

import random
from collections import Counter
from multiprocessing import Pool

QUERIES = ["погода", "курс доллара", "python", "big data", "рецепт блинов", "новости"]
WEIGHTS = [30, 20, 15, 5, 20, 10]


def make_log(n, seed=42):
    rnd = random.Random(seed)
    return rnd.choices(QUERIES, WEIGHTS, k=n)  # журнал: одна строка = один запрос


def map_chunk(chunk):
    return Counter(chunk)  # map + локальная свертка на своем куске


def reduce_counts(parts):
    total = Counter()
    for part in parts:
        total.update(part)  # reduce: складываем частичные счетчики
    return total


if __name__ == "__main__":
    log = make_log(1_000_000)
    size = 250_000
    chunks = [log[i:i + size] for i in range(0, len(log), size)]
    with Pool(4) as pool:
        parts = pool.map(map_chunk, chunks)
    result = reduce_counts(parts)
    assert result == Counter(log)  # параллельный итог = последовательному
    print("частей:", len(chunks), "строк:", sum(result.values()))
    for query, count in result.most_common(3):
        print(query, count)

Вывод при запуске на Python 3.14 (и на 3.9 он такой же, генератор задан сидом 42):

частей: 4 строк: 1000000
погода 299502
курс доллара 200322
рецепт блинов 200046

Что происходит по шагам:

1. make_log генерирует журнал из миллиона запросов с заданными частотами.
2. Журнал режется на 4 куска по 250 000 строк — аналог блоков в распределенной файловой системе.
3. pool.map запускает map_chunk параллельно в четырех процессах, каждый возвращает свой Counter.
4. reduce_counts складывает частичные счетчики, а assert проверяет, что итог равен подсчету без разбиения.

Граница модели: в реальном кластере добавляются сеть, сбои узлов, повторный запуск упавших задач и shuffle между машинами. Эту часть берут на себя Hadoop или Spark, а разработчик пишет в основном логику map и reduce.

Тот же подсчет на SQL

На практике такой подсчет чаще пишут на SQL, а движок сам распределяет работу. Запрос ниже проверен на SQLite 3.51 и PostgreSQL 16 на тех же восьми записях. Та же конструкция GROUP BY есть в Spark SQL и ClickHouse.

CREATE TABLE search_log (ts TEXT, query TEXT);
INSERT INTO search_log VALUES
  ('2026-09-24 10:00:01', 'погода'),
  ('2026-09-24 10:00:02', 'python'),
  ('2026-09-24 10:00:02', 'погода'),
  ('2026-09-24 10:00:03', 'новости'),
  ('2026-09-24 10:00:05', 'python'),
  ('2026-09-24 10:00:06', 'погода'),
  ('2026-09-24 10:00:08', 'big data'),
  ('2026-09-24 10:00:09', 'python');

SELECT query, COUNT(*) AS cnt
FROM search_log
GROUP BY query
ORDER BY cnt DESC, query
LIMIT 3;

Результат в SQLite:

python|3
погода|3
big data|1

GROUP BY здесь играет роль shuffle и reduce одновременно. Второй ключ сортировки query нужен, чтобы порядок при равных счетчиках был предсказуемым: без него СУБД вправе вернуть строки с одинаковым cnt в любом порядке.

Инструменты обработки: что за что отвечает

Выбирать инструмент удобно от задачи, а не от списка модных названий.

Коротко о ключевых проектах. Hadoop появился в 2006 году по мотивам публикаций Google о GFS и MapReduce и включает HDFS, планировщик YARN и MapReduce. Spark держит промежуточные данные в памяти и обычно быстрее MapReduce на многошаговых задачах. Kafka создали в LinkedIn как распределенный журнал событий. ClickHouse разработали в Яндексе для Метрики и открыли в 2016 году.

Методы анализа больших данных

Методы анализа не уникальны для Big Data: регрессия или деревья решений работают и на таблице из тысячи строк. Большие данные меняют масштаб и инфраструктуру, а не математику.

Выводы

• Большие данные определяются не числом гигабайт, а тем, что объем, скорость и разнообразие требуют распределенной обработки.
• В школьном тесте к большим данным относятся журналы поисковых запросов за день: огромный непрерывный поток разнородных записей.
• Модель 3V (объем, скорость, разнообразие) описывает сами данные, достоверность и ценность в 5V — качество и смысл работы с ними.
• Основной прием обработки — разделить данные и считать части параллельно, как в MapReduce; в production это делают Spark, Hadoop, Kafka, Flink, ClickHouse.
• Методы анализа (ML, регрессия, ассоциации) те же, что для обычных данных; меняется масштаб и инфраструктура.

Где применяется / связь с практикой

FAQ

С какого объема данные считаются большими?
Общепринятого порога нет. Ориентир — момент, когда данные перестают помещаться или обрабатываться на одном сервере за нужное время; для одной задачи это сотни гигабайт, для другой — десятки терабайт. Стоит ли при этом разворачивать кластер и во что он обойдется — отдельный вопрос о плюсах и минусах Big Data.

Можно ли работать с большими данными на Python?
Да: PySpark дает Python-интерфейс к Spark, а код с multiprocessing из статьи показывает ту же идею в миниатюре. Для реального кластера логику пишут на Python, SQL, Scala или Java, а распределение берет на себя движок.

Чем дата-инженер отличается от аналитика больших данных?
Дата-инженер строит инфраструктуру и конвейеры, через которые данные собираются и очищаются. Аналитик или data scientist использует эти данные, чтобы отвечать на вопросы бизнеса и строить модели.