System Design
Case Study: YouTube
YouTube за одну минуту получает 500 часов нового видео - больше, чем человек физически способен посмотреть за месяц. И это нужно перекодировать, хранить и доставить в любую точку планеты за 200 ms.
- YouTube 2024: 2.7B MAU, 1B часов просмотра в день, 500 часов upload в минуту.
- Транскодинг pipeline: AV1 даёт 30% экономии bandwidth vs H.264, но в 5x медленнее в кодировании - YouTube использует custom ASIC Argos для AV1.
- Google Global Cache (GGC) стоит внутри 5000+ ISP сетей; локальный hit rate - 70-90% для top-1% видео.
- Recommendations: 70% всего watch time приходит от системы рекомендаций; одна модель ranking даёт 1-2% lift в watch time = миллиарды долларов ad revenue.
Требования и масштаб
Цели урока
- Определить функциональные и нефункциональные требования
- Провести back-of-envelope estimation
- Понять уникальные challenges video platform
Функциональные требования
YouTube - это не просто video hosting, а сложная экосистема с несколькими ключевыми функциями:
Масштаб YouTube (реальные цифры)
YouTube - одна из самых storage/bandwidth интенсивных систем в мире:
Back-of-Envelope Estimation
Для сравнения: суммарный интернет-трафик всего мира - около 1 Exabyte в день. YouTube генерирует значительную часть мирового трафика.
Ключевые технические challenges
Ключевые идеи
- YouTube работает в масштабе экзабайт storage и петабит bandwidth
- Ключевые challenges: upload processing pipeline, adaptive streaming, глобальная CDN-сеть, и ML-based recommendations
Сколько примерно storage нужно для хранения одного дня загружаемых видео (все качества), в петабайтах?
Video Upload Pipeline
Цели урока
- Спроектировать resumable upload для больших файлов
- Понять transcoding pipeline и parallel encoding
- Освоить async job processing для video
Проблема: загрузка больших файлов
Видео на YouTube может быть до 12 часов. При 1080p это ~60 GB. Загрузка такого файла с обычного интернета занимает часы. Что если соединение прервётся?
Transcoding Pipeline Architecture
После upload видео проходит через pipeline обработки. Это занимает от минут до часов в зависимости от длины.
Transcoding Job Implementation
HLS Segment Generation
Оптимизации для высокой нагрузки
Ключевые идеи
- Video upload pipeline состоит из: resumable upload для надёжности, async transcoding с параллельной обработкой разных quality, HLS сегментация для streaming
- Priority queues и GPU кластеры обеспечивают масштаб 500 часов/минуту
Почему transcoding выполняется асинхронно, а не сразу при upload?
Adaptive Bitrate Streaming
Цели урока
- Понять HLS и DASH протоколы streaming
- Изучить алгоритмы adaptive bitrate switching
- Освоить buffer management стратегии
Проблема: разное качество интернета
Пользователи смотрят видео с разных устройств и сетей: 5G, WiFi, медленный мобильный интернет. Как обеспечить лучший опыт для каждого?
HLS (HTTP Live Streaming)
Manifest Files
ABR Algorithms
Как player решает, когда переключиться на другое качество? Есть несколько подходов:
ABR Implementation
Оптимизации для быстрого старта
Ключевые идеи
- Adaptive Bitrate Streaming нарезает видео на 2-10 секундные сегменты, каждый доступен в нескольких качествах
- ABR алгоритм (buffer-based, throughput-based, или hybrid) выбирает оптимальное качество для каждого сегмента, балансируя между качеством картинки и риском буферизации
Почему buffer-based подход лучше pure throughput-based?
CDN и Edge Caching
Цели урока
- Спроектировать multi-tier CDN architecture
- Понять video-specific CDN optimizations
- Изучить ISP peering и Google Global Cache
Проблема: 250 Pbps bandwidth
Невозможно обслуживать 250 Petabits/second из централизованных data centers. Latency была бы огромной, а сеть - перегружена. Решение: доставлять контент как можно ближе к пользователю.
Multi-Tier CDN Architecture
Google Global Cache (GGC)
YouTube напрямую устанавливает серверы внутри сетей интернет-провайдеров. Это значительно снижает latency и costs для обеих сторон.
Video-Specific CDN Optimizations
CDN Selection Algorithm
Ключевые идеи
- YouTube использует multi-tier CDN: Edge PoPs (1000+), Regional Caches (100+), и Google Global Cache внутри ISP сетей
- Video-specific optimizations: segment-level caching, quality-aware prioritization, predictive prefetching
- Правило 80/20 работает: 10% видео = 80% трафика
Почему YouTube кеширует отдельные segments, а не целые видео?
Recommendation System
Цели урока
- Понять multi-stage recommendation pipeline
- Изучить candidate generation и ranking
- Освоить real-time personalization
Важность рекомендаций
70% времени просмотра на YouTube приходит от рекомендаций. Это главный driver engagement и revenue. Задача: из 800+ миллионов видео выбрать 20, которые пользователь захочет посмотреть.
Stage 1: Candidate Generation
Stage 2: Ranking
Из 10,000 candidates нужно выбрать top 500. Здесь используется сложная ML модель, которая предсказывает вероятность engagement.
Stage 3: Re-ranking
Real-time Personalization
Architecture Overview
Ключевые идеи
- YouTube recommendations - это multi-stage funnel: Candidate Generation (800M → 10K), Ranking (10K → 500), Re-ranking (500 → 20)
- Основная метрика - watch time, не клики
- Используются collaborative filtering, content-based, и контекстные signals
- Всё должно работать за < 100ms
Чем больше features в ranking-модели - тем лучше рекомендации. YouTube берёт всё подряд: историю, демографию, погоду, друзей.
В production ranking-моделях каждый feature стоит latency и удваивает риск утечки или bias. YouTube paper (Covington 2016) показывает, что 5-10 хорошо инженированных feature групп бьют сотни шумных.
ML-инженеры в YouTube тратят 80% времени на feature engineering и валидацию, а не на 'добавим ещё фичей'. Каждый сигнал должен проходить counterfactual evaluation - реально ли он улучшает long-term watch time, или просто коррелирует с clickbait.
Почему YouTube оптимизирует watch time, а не clicks?
Связь с предыдущим
Twitter дал гибридный fan-out как ответ на read-heavy social feed. YouTube масштабирует это в другом измерении - не 6M QPS на текст, а 250 Pbps на видео. Те же паттерны (CDN edge, async pipeline, sharded storage) применяются на 1000x больших данных, и появляются новые: транскодинг, ABR, ML-ranking из миллиарда кандидатов.
- Case Study: Twitter — Twitter гибридный fan-out → YouTube гибридный CDN с tiered caching
- CDN и Edge Caching — CDN - основа доставки видео при петабитах bandwidth
- Message Queue — Async transcoding pipeline через очереди - 500 часов/мин
Итоги
- YouTube storage и bandwidth измеряются в эксабайтах/петабитах. Невозможно обслуживать из одного дата-центра - требуется multi-tier CDN.
- Upload pipeline: resumable upload → async transcoding на GPU → HLS сегментация → CDN distribution. Транскодинг асинхронный, потому что занимает минуты-часы.
- Adaptive Bitrate Streaming делит видео на 2-10s сегменты в нескольких качествах. Player выбирает квалити per-segment по buffer и throughput.
- Multi-tier CDN: Origin (30 DC) → Regional Caches (100+) → Edge PoP (1000+) → ISP cache (GGC). Top 1% видео покрывает 60% трафика.
- Recommendations - multi-stage funnel: 800M кандидатов → 10K (collab filtering) → 500 (ranking model) → 20 (re-ranking с diversity rules). Всё за < 100 ms.
- Watch time, не clicks - главная метрика. Clickbait получает CTR, но не удержание, поэтому ranking оптимизирует expected watch time через multi-objective loss.
Вопросы для размышления
- Если ISP cache хранит top 0.1% видео, какой механизм должен предсказывать viral-видео ДО того, как оно стало вирусным?
- Что произойдёт со всем pipeline, если регуляторы запретят использовать watch history дольше 30 дней (как в EU GDPR)? Какой компонент перестроится сильнее всего?
- Можно ли применить hybrid push-pull от Twitter к YouTube notifications: 'новое видео от канала, на который подписан'? Где аналогия ломается?
Связанные уроки
- sd-14-twitter — Twitter feed паттерны предшествуют масштабу видео
- sd-08-cdn — CDN - основа доставки видео: edge nodes рядом с пользователем
- sd-09-message-queue — Video processing pipeline через очереди (transcode, thumbnail)
- arch-15-gpu-architecture — GPU для ML рекомендаций - та же параллельность что при транскодинге
- dist-11-replication