Введение в большие данные: инструменты дата-инженера

Большие данные — это массивы информации настолько объёмные и разнообразные, что их уже нельзя удобно хранить и обрабатывать в привычных инструментах вроде Excel или одной базы данных на одном сервере. Чтобы с ними работать, приходится использовать распределённые системы — кластеры из десятков и иногда сотен машин, где и данные, и вычисления делятся между несколькими узлами.

Что это означает на практике: такими большими данными могут быть, например, логи всех запросов к крупному маркетплейсу за месяц, телеметрия с миллионов устройств, транзакции банка за год или действия пользователей в приложении. Это одновременно и привычные таблицы, и разные нетабличные данные: тексты, картинки, видео и JSON-файлы — файлы в формате «ключ-значение», где каждая строка может иметь разный набор полей.

С практической точки зрения инженера: большими данными принято считать те массивы, обработка которых невозможна без распределённых систем — кластеров, где хранение и вычисления разделены между многими машинами. Сам термин больше про подход к задаче (объём, скорость и разнообразие), а не про конкретный размер в гигабайтах.

Граница условная, но ориентиры есть. Условно «обычные» данные — это такие объёмы и нагрузки, с которыми справляется одна СУБД (система управления базами данных) или один сервер без распределения по кластеру. Запросы выполняются за секунды, схема стабильная, объёмы предсказуемые.

С большими данными несколько иначе:

Большие данные — это не про точный размер, а про объёмы, с которыми уже не справляются обычная база и один сервер.

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

Для удобства big data описывают через шесть V — шесть характеристик, которые подчёркивают, чем эти данные отличаются от привычных. Изначально классическое определение строилось на трёх V, но индустрия добавила ещё три. Для описания big data часто используют модель 3V, а в прикладных текстах — расширенные версии 5V и 6V.

Объём (volume) — про количество. Мировые данные растут по экспоненте, но для дата-инженера полезнее своя шкала: обычный продакшен-сервис накапливает десятки терабайт в год, у крупных российских маркетплейсов и банков — десятки и сотни петабайт (Ozon ≈ 60 ПБ, Wildberries ≈ 10 ПБ, Сбер > 150 ПБ).

Скорость (velocity) — насколько быстро данные приходят и насколько быстро их нужно обрабатывать. Платёжная система не может анализировать транзакции через сутки: фрод-проверки делаются за миллисекунды. Рекомендации в маркетплейсе тоже не ждут до утра.

Разнообразие (variety) — про форматы. В одном пайплайне (так называют цепочку обработки данных от источника до хранилища) рядом могут лежать строки из обычной базы, события в JSON, текстовые логи, картинки, аудио. Часть данных строго структурирована, часть — без жёсткой схемы, часть — вообще «как есть»: всё это нужно собирать и обрабатывать вместе.

Технологии big data обычно делят на несколько слоёв: хранение, обработка, передачу данных и оркестрацию; в реальных системах границы между ними часто размыты.

Два разных подхода к хранению, которые на практике часто работают вместе.

Data warehouse (DWH, хранилище данных) — это место для структурированных, очищенных и подготовленных к анализу данных. Схема здесь обычно задаётся заранее, поэтому DWH удобно использовать для SQL-запросов, отчётов и BI-аналитики. Примеры DWH-решений — Snowflake, Greenplum, Google BigQuery, Amazon Redshift; ClickHouse часто используют как аналитическую СУБД для DWH-сценариев.

Data lake (озеро данных) — это хранилище для сырых данных в исходном виде: JSON, CSV, Parquet, картинки, логи и другие форматы. Здесь схему часто применяют не при загрузке, а уже при чтении данных — такой подход называют schema-on-read. Data lake обычно строят на объектном хранилище вроде S3-совместимого хранилища или HDFS, а поверх него нередко используют табличные форматы и слои управления данными вроде Apache Iceberg, Delta Lake или Apache Hudi.

Lakehouse — это гибридный подход, который сочетает дешёвое хранение сырых данных, как в data lake, с возможностями классического data warehouse для аналитики и отчётности.

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

Apache Hadoop — исторически важная экосистема. В ней HDFS отвечает за распределённое хранение, YARN — за управление ресурсами, а MapReduce — за пакетную обработку. Hadoop до сих пор встречается в крупных российских компаниях, хотя во многих новых проектах вместо него выбирают Spark и облачные решения.

Apache Spark — один из самых распространённых движков для обработки больших объёмов данных сегодня. Во многих задачах работает заметно быстрее MapReduce за счёт обработки в памяти и оптимизаций выполнения. Поддерживает SQL, потоковую обработку, машинное обучение и графовую аналитику. Писать под Spark можно на Python (PySpark), Scala, Java и R.

Hadoop — исторически важная экосистема распределённого хранения и вычислений, а Spark чаще выбирают как более удобный и быстрый вычислительный слой. В реальных кластерах они соседствуют: Spark читает данные из HDFS или S3 и крутит поверх них свои вычисления.

Системы вроде Spark обрабатывают данные «порциями» по расписанию, а потоковые — разбирают непрерывный поток событий сразу, как только данные поступают.

Apache Kafka — распределённый брокер сообщений, через который проходят потоки событий. Через Kafka проходят клики, транзакции, телеметрия — всё, что генерируется быстрее, чем удобно складывать в базу. Дата-инженер настраивает топики (каналы для потоков данных), продюсеров (отправителей данных) и консьюмеров (получателей), следя за пропускной способностью системы.

Apache Flink — движок, который обрабатывает события в реальном времени, считая метрики, агрегаты и правила на лету. Применяют там, где задержка критична: антифрод, рекомендации, мониторинг. Например, может считать сумму покупок за последние 5 минут и обновлять её с каждой новой транзакцией.

Чаще всего Kafka и Flink стоят в связке: Kafka служит шиной событий, а Flink — вычислительным слоем для потоковой обработки.

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

Данные нужно как-то доставить из источника в хранилище — это отдельная задача. Источники бывают разные: рабочие базы продакшена, внешние API, файлы от партнёров, потоки событий.

Apache Kafka Connect — надстройка над Kafka, которая умеет забирать данные из других систем. Готовые коннекторы подключаются к PostgreSQL, MySQL, MongoDB и публикуют изменения в Kafka. Удобно для CDC (change data capture) — отслеживания того, что поменялось в исходной базе.

Apache NiFi — инструмент с визуальным интерфейсом, в котором пайплайн собирается из блоков мышкой. Подходит, когда источников много, маршруты сложные, и удобнее видеть схему потока, а не код.

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

Apache Airflow — один из самых распространённых и зрелых оркестраторов в дата-инжиниринге. Пайплайны описываются на Python в виде DAG (направленного ациклического графа). Airflow помогает запускать задачи, контролировать зависимости между ними и отслеживать ошибки, но сам данные не переносит.

Dagster — более молодой инструмент с упором на тестируемость, типы данных и наблюдаемость пайплайнов. Чаще встречается в продуктовых командах, которые строят дата-платформу с нуля.

В русскоязычных компаниях также активно используются Prefect и собственные внутренние оркестраторы крупных банков и маркетплейсов.

К хранению относятся не только DWH и озёра, но и специализированные базы под конкретные сценарии:

• HDFS — файловая система Hadoop, в которой данные раскиданы по многим серверам и работают как одно целое. До сих пор встречается в крупных корпоративных кластерах;

• S3 и совместимые хранилища — объектное хранилище: данные лежат как файлы с уникальными адресами, без папок и структуры. Стандарт для облачных озёр данных. В России распространены MinIO и хранилища Yandex Cloud, VK Cloud, Cloud.ru;

• Apache HBase — распределённая NoSQL-база для очень больших таблиц, где важны быстрый доступ по ключу и стабильная работа под нагрузкой;

• Apache Cassandra — NoSQL-база, которая хорошо подходит для высоких скоростей записи, но реальная пропускная способность зависит от размера кластера, схемы и нагрузки. Используется в высоконагруженных сервисах, где важна скорость и отказоустойчивость.

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

Big data в бизнесе — уже не модный термин, а инструмент, по которому считают деньги. Вот основные сферы, где работа с большими объёмами данных даёт измеримый результат.

Маркетплейсы, ретейл и e-commerce работают с десятками терабайт пользовательских действий. Из них собирают:

• персональные рекомендации товаров;
• сегменты аудитории для таргетинга;
• расчёт LTV и оттока клиентов;
• A/B-тесты на больших выборках;
• динамическое ценообразование.

По данным исследования «Аэро» и «Матемаркетинга», 90% опрошенных российских компаний принимают решения на основе данных, но только 13% полностью довольны их объёмом и качеством. Эту проблему как раз и закрывает дата-инженер.

Банки — одни из самых зрелых заказчиков big data. Например:

• антифрод в реальном времени;
• кредитный скоринг по сотням признаков;
• мониторинг подозрительных операций (AML);
• алгоритмическая торговля;
• персональные предложения по продуктам.

Сбер, Т-Банк и Альфа-Банк строят собственные дата-платформы и активно нанимают дата-инженеров.

Новичку не нужно учить весь стек целиком. Для старта достаточно понимать роль каждого слоя и освоить по одному инструменту на слой.

Помимо языков пригодятся:

• понимание, как устроены обычные базы данных: индексы, транзакции, нормализация;
• основы Linux и работы в терминале;
• Git и базовое представление о CI/CD;
• Docker для локальной разработки;
• общее представление о распределённых системах: зачем вычисления делят на части, что такое шардирование и репликация.

Путь от нуля до собеседования укладывается в три блока.