Big Data
Что такое Big Data: 5V
В 2012 году Target отправил купоны для беременных старшекласснице. Её отец пришёл в магазин с жалобой. Через неделю он извинился - дочь действительно была беременна. Алгоритм знал раньше семьи. Добро пожаловать в мир Big Data - где данные знают о нас больше, чем мы сами.
- **Netflix** рекомендует фильмы на основе миллиардов просмотров - экономя 1B/год на оттоке клиентов
- **Tesla** собирает данные с каждого автомобиля: миллиарды километров для обучения автопилота
- **CERN** генерирует 1 PB/сек при работе коллайдера - больше, чем весь интернет-трафик некоторых стран
Volume - объём данных
Каждый день человечество создаёт **2.5 квинтиллиона байт** данных. Один Facebook (Meta) генерирует **более 600 TB новых данных ежедневно** - посты, фото, видео, лайки, комментарии. YouTube получает **500 часов видео каждую минуту**. И это только две компании.
| Единица | Размер | Пример |
|---|---|---|
| Гигабайт (GB) | 10⁹ байт | 2 часа HD-видео |
| Терабайт (TB) | 10¹² байт | 500 часов HD-видео |
| Петабайт (PB) | 10¹⁵ байт | Вся почта Gmail (~15 PB) |
| Эксабайт (EB) | 10¹⁸ байт | Весь интернет-трафик за день |
| Зеттабайт (ZB) | 10²¹ байт | Все данные мира (~120 ZB в 2023) |
Почему один сервер не справится? Даже мощный сервер с 64 TB диска и 100 Gbps сетью физически не может принять, хранить и обработать петабайты данных. Решение - **horizontal scaling**: вместо одного гигантского сервера используем сотни обычных.
**Horizontal scaling** - это не просто "больше серверов". Это фундаментальная смена парадигмы: данные **распределяются** по узлам, и каждый узел обрабатывает свою часть параллельно. Именно на этом принципе построены Hadoop, Spark и все Big Data системы.
Vertical scaling имеет жёсткий потолок - нельзя бесконечно наращивать RAM и CPU одного сервера. Horizontal scaling теоретически безлимитен, но создаёт новые проблемы: координация узлов, отказоустойчивость, консистентность данных.
Facebook генерирует 600 TB данных в день. Один сервер вмещает 64 TB. Как решить проблему хранения?
Velocity - скорость поступления
Объём - это только полдела. Данные не просто **большие**, они приходят **быстро**. Биржа NYSE обрабатывает **миллионы сделок в секунду**. IoT-датчики на заводе генерируют **тысячи событий в секунду**. Рекомендательный движок Netflix должен подобрать фильм **до того, как пользователь закроет приложение** - за доли секунды.
| Режим | Задержка | Примеры | Технологии |
|---|---|---|---|
| Real-time | < 1 сек | Биржевые торги, fraud detection, IoT-алерты | Kafka Streams, Apache Flink |
| Near-real-time | 1 сек - 5 мин | Рекомендации, поисковые подсказки, мониторинг | Spark Streaming, Kafka |
| Batch | минуты - часы | Отчёты, ETL, обучение ML-моделей | Hadoop MapReduce, Spark |
Ключевое различие - **stream processing** vs **batch processing**. Batch - это классический подход: накопили данные за день, обработали ночью. Stream - обработка каждого события по мере поступления.
**Apache Kafka** - де-факто стандарт для streaming данных. Kafka работает как распределённый лог: продюсеры пишут события, консьюмеры читают их. Пропускная способность - **миллионы сообщений в секунду** с задержкой менее 10 мс.
На практике часто используют **Lambda Architecture**: batch-слой для точных исторических данных + stream-слой для мгновенных результатов. Так устроены системы рекомендаций Netflix, Spotify и YouTube.
Банк хочет блокировать мошеннические транзакции. Какой режим обработки нужен?
Variety - разнообразие форматов
Данные приходят не только из SQL-таблиц. **80% данных в мире - неструктурированные**: текст, фото, видео, аудио, логи. Больница хранит структурированные анализы крови рядом с неструктурированными рентгеновскими снимками и текстами врачебных заключений.
| Тип | Описание | Примеры | Хранилище |
|---|---|---|---|
| Structured | Фиксированная схема, строки и столбцы | Таблицы клиентов, транзакции, логи в CSV | PostgreSQL, MySQL, Oracle |
| Semi-structured | Есть структура, но гибкая | JSON, XML, Avro, Parquet, логи Nginx | MongoDB, Elasticsearch, S3 |
| Unstructured | Нет схемы, произвольный формат | Текст, фото, видео, PDF, email | HDFS, S3, Data Lake |
**Data Lake** - хранилище, которое принимает данные **любого** формата без предварительной трансформации. В отличие от Data Warehouse (структурированный, чистый, дорогой), Data Lake работает по принципу "сохрани всё, разберём потом". AWS S3, Azure Data Lake, Google Cloud Storage - примеры облачных Data Lake.
Data Lake легко превращается в **Data Swamp** (болото) - если нет каталога данных, версионирования и governance, через год никто не знает что лежит в озере и можно ли этим данным доверять.
Интернет-магазин хранит: таблицу заказов (SQL), отзывы клиентов (текст), фото товаров (PNG), логи кликов (JSON). К какому типу относятся логи кликов?
Veracity - достоверность данных
У вас петабайты данных, они приходят в реальном времени, во всех форматах. Но можно ли им **доверять**? IBM оценивает, что **плохие данные обходятся экономике США в 3.1 триллиона ежегодно**. Дубликаты, пропуски, ошибки, устаревшие записи - всё это превращает Big Data в Big Garbage.
**Garbage In - Garbage Out (GIGO)** - фундаментальный принцип. Самый лучший алгоритм на грязных данных выдаст мусорные результаты. ML-модель, обученная на данных с 30% ошибок, будет ошибаться минимум в 30% случаев.
| Проблема | Пример | Решение |
|---|---|---|
| Missing values | NULL в 20% записей | Imputation (среднее, медиана) или удаление |
| Duplicates | Один клиент 3 раза | Deduplication по ключевым полям |
| Inconsistency | "Москва" vs "МСК" vs "Moscow" | Нормализация, справочники |
| Outliers | Возраст = 999 | Статистическая фильтрация (IQR, z-score) |
| Staleness | Адрес 5-летней давности | TTL (Time-To-Live), периодическое обновление |
Правило 80/20 в Data Engineering: **80% времени тратится на очистку данных**, и только 20% - на саму аналитику или ML. Инвестируйте в Data Quality Pipeline - это окупится многократно.
В датасете 1 миллион записей клиентов. 15% записей содержат дубликаты, 10% - пропущенные поля, 5% - невалидные email. Что делать в первую очередь?
Value - ценность данных
У вас есть петабайты (Volume) данных, которые поступают в реальном времени (Velocity), в разных форматах (Variety), и вы очистили их (Veracity). Но зачем? **Данные бесполезны без анализа.** Настоящая ценность Big Data - в способности превращать сырые данные в бизнес-решения.
| Компания | Данные | Value (бизнес-результат) |
|---|---|---|
| Netflix | История просмотров, оценки, время суток | Рекомендации экономят 1B/год на удержании клиентов |
| Amazon | Покупки, просмотры, корзины, возвраты | 35% дохода приходит от рекомендательного движка |
| Uber | GPS-трекинг, запросы, пробки, погода | Dynamic pricing - оптимальная цена в каждый момент |
| Spotify | Прослушивания, скипы, плейлисты, время дня | Discover Weekly - 40M+ пользователей слушают каждый понедельник |
**ROI Big Data проектов** - возврат инвестиций. Построить кластер Hadoop стоит от 100K до миллионов. Нанять Data Engineering команду - ещё дороже. Окупится ли это?
Не каждый Big Data проект приносит ценность. По данным Gartner, **60-85% Big Data проектов заканчиваются неудачей**. Главные причины: нечёткая бизнес-цель, плохое качество данных, отсутствие data-driven культуры.
**Data-Driven Decision Making** - принятие решений на основе данных, а не интуиции. Это культурный сдвиг: вместо "мне кажется, что пользователям нравится синяя кнопка" - "A/B тест показал, что синяя кнопка даёт +12% конверсии с p-value < 0.01".
Больше данных = лучше результат. Надо собирать максимум данных и результаты аналитики/ML улучшатся автоматически.
Больше данных без качества и правильной модели = больше шума. Чистые, релевантные данные с хорошей моделью побеждают гигантские грязные датасеты.
Google доказал это в статье 'More data beats clever algorithms' - но с оговоркой: данные должны быть **релевантными** задаче. 10 PB фотографий котов не помогут предсказать цены акций, сколько бы их ни было. А 1000 чистых, размеченных медицинских снимков могут спасти жизни.
Компания собрала 10 PB данных о поведении пользователей, но не имеет Data Science команды и не ставила конкретных бизнес-вопросов. Какова ценность этих данных?
Ключевые идеи
- **Volume** - данные измеряются в петабайтах и эксабайтах, один сервер не справится → horizontal scaling
- **Velocity** - данные приходят в реальном времени, batch-обработки недостаточно → stream processing (Kafka)
- **Variety** - 80% данных неструктурированные → Data Lake принимает всё, разбираемся при чтении
- **Veracity** - грязные данные = мусорные результаты → Data Quality Pipeline обязателен
- **Value** - Target и беременная школьница: именно Value делает Big Data мощным - не объём сам по себе, а способность извлекать неожиданные инсайты из данных
Связанные темы
5V - это фундамент. Дальше мы изучим конкретные инструменты для работы с каждым измерением:
- Hadoop Ecosystem — Кластерная система для Volume + Variety
- MapReduce — Парадигма распределённой обработки для Volume
Вопросы для размышления
- Какие из 5V наиболее критичны для вашей работы или проектов? Почему?
- Назовите пример из реальной жизни, где плохое качество данных (Veracity) привело к ошибочным решениям.
- Если бы вам дали 1 PB данных и 100K бюджета, с чего бы вы начали: с инфраструктуры, очистки данных или найма аналитиков?
Связанные уроки
- bd-02 — Hadoop ecosystem - практический ответ на проблему Volume и Variety, описанную в 5V.
- stream-01 — Velocity в 5V прямо описывает задачи stream processing - batch vs stream выбор определяется скоростью поступления данных.
- ds-01-intro — Горизонтальное масштабирование для Volume - тот же принцип, что и в distributed systems: данные распределяются по независимым узлам.
- prob-01-intro — Veracity и оценка качества данных требуют статистического мышления: outlier detection, z-score, IQR.
- db-01-intro