{"id":21417599,"url":"https://github.com/mmikhail2001/highload_youtube","last_synced_at":"2026-05-14T13:42:00.907Z","repository":{"id":193735833,"uuid":"689248318","full_name":"mmikhail2001/Highload_YouTube","owner":"mmikhail2001","description":"Расчетно-пояснительная записка. Проектирование высоконагруженного сервиса YouTube.","archived":false,"fork":false,"pushed_at":"2023-12-01T19:13:39.000Z","size":9953,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-01-23T05:45:46.781Z","etag":null,"topics":["bgp-anycast","cassandra","cdn","clickhouse","ecmp","envoy","geo-dns","internet-exchange","k8s","kafka","load-balancing","mapreduce","s3","tarantool"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mmikhail2001.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2023-09-09T08:05:36.000Z","updated_at":"2025-01-01T12:32:37.000Z","dependencies_parsed_at":"2023-11-27T17:36:17.723Z","dependency_job_id":null,"html_url":"https://github.com/mmikhail2001/Highload_YouTube","commit_stats":null,"previous_names":["mmikhail2001/highload_youtube"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmikhail2001%2FHighload_YouTube","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmikhail2001%2FHighload_YouTube/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmikhail2001%2FHighload_YouTube/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mmikhail2001%2FHighload_YouTube/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mmikhail2001","download_url":"https://codeload.github.com/mmikhail2001/Highload_YouTube/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243918629,"owners_count":20368745,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bgp-anycast","cassandra","cdn","clickhouse","ecmp","envoy","geo-dns","internet-exchange","k8s","kafka","load-balancing","mapreduce","s3","tarantool"],"created_at":"2024-11-22T19:16:30.455Z","updated_at":"2025-10-16T19:32:42.770Z","avatar_url":"https://github.com/mmikhail2001.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Highload YouTube\n\n## Содержание\n* ### [1. Тема, целевая аудитория](#1)\n* ### [2. Расчет нагрузки](#2)\n* ### [3. Глобальная балансировка нагрузки](#3)\n* ### [4. Локальная балансировка нагрузки](#4)\n* ### [5. Логическая схема БД](#5)\n* ### [6. Физическая схема БД](#6)\n* ### [7. Алгоритмы](#7)\n* ### [8. Технологии](#8)\n* ### [9. Схема проекта](#9)\n* ### [10. Обеспечение надежности](#10)\n* ### [11. Расчет ресурсов](#11)\n\n## 1. Тема и целевая аудитория\u003ca name=\"1\"\u003e\u003c/a\u003e\n\n### 1.1 Тема\nСервис **YouTube** - видеохостинг, предоставляющий пользователям услуги хранения, доставки и показа видео\n\n### 1.2 MVP\nФункциональность сервиса\n1. **Просмотр** видео\n2. **Загрузка** видео\n3. **Комментирование, лайки, подписки** на канал\n4. **Рекомендации** на главной странице и на странице видео\n5. **Авторизация**\n6. **Поиск**\n\n### 1.3 Целевая аудитория\n- Местоположение - **Россия**\n- **Размер аудитории** на локальном рынке \\[[1](https://mediascope.net/data/#internet)]\n\t- месячный охват 95 млн. человек\n\t- дневной охват 52 млн. человек\n- Среднее время просмотра в день - 85 мин \\[[2](https://mediascope.net/upload/iblock/ee9/b91rtnqh1jf0zhalydi9jf125voo5o8e/медиапотребление.pdf)], хотя по миру это значение намного меньше \\[[3](https://www.oberlo.com/statistics/average-time-spent-on-youtube)]\n- Некоторые факты об аудитории\n\t- 15% доля YouTube в интернет-потреблении на локальном рынке (18% - доля видео в целом) \\[[4](https://mediascope.net/upload/iblock/ee9/b91rtnqh1jf0zhalydi9jf125voo5o8e/медиапотребление.pdf)]\n\t- Средний возраст 25-34 лет\n\t- 40% - доля женщин \\[[5](https://bloggingwizard.com/youtube-statistics/#:~:text=60.59%25%20of%20YouTube%E2%80%99s%20audience%20is%20male)]\n\n## 2. Расчет нагрузки\u003ca name=\"2\"\u003e\u003c/a\u003e\n\nСтатистика для расчетов\n\n|Метрика|Аудитория|Значение|Обозначение|\n| ------------- | --- |-------------|--|\n|MAU (чел.)\\[[6](https://mediascope.net/data/#internet)]|Мир|2500 млн.|MAU_WORLD|\n|MAU (чел.)\\[[7](https://mediascope.net/data/#internet)]|Россия|95 млн.|MAU_RUS|\n|DAU (чел.)\\[[8](https://mediascope.net/data/#internet)]|Россия|52 млн.|MAU_RUS|\n|Количество просмотров / месяц \\[[9](https://www.globalmediainsight.com/blog/youtube-users-statistics/#:~:text=YouTube%20Views%20by%20Country)]|Россия|207 млрд.|VIEWS_MONTH|\n|Среднее время просмотра / день (мин)\\[[10](https://inclient.ru/youtube-stats/#:~:text=%D0%92%20%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8%20YouTube%20%D1%81%D0%BC%D0%BE%D1%82%D1%80%D1%8F%D1%82%20%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80%D0%BD%D0%BE%2086%20%D0%BC%D0%B8%D0%BD%D1%83%D1%82%20%D0%B2%20%D0%B4%D0%B5%D0%BD%D1%8C)]|Россия|86|VIEW_DURATION_DAY|\n|Загрузка видео / минута (час)\\[[11](https://bloggingwizard.com/youtube-statistics/#:~:text=That%E2%80%99s%2030%2C000%20hours%20of%20video%20uploaded%20every%20hour%2C%20720%2C000%20uploaded%20every%20day%2C%205.04%20million%20uploaded%20every%20week%2C%2021.9%20million%20uploaded%20every%20month%20and%20262.8%20million%20uploaded%20every%20year.)] |Мир|500|UPLOAD_MINUTE|\n|Загрузка видео / час (час)\\[[12](https://bloggingwizard.com/youtube-statistics/#:~:text=That%E2%80%99s%2030%2C000%20hours%20of%20video%20uploaded%20every%20hour%2C%20720%2C000%20uploaded%20every%20day%2C%205.04%20million%20uploaded%20every%20week%2C%2021.9%20million%20uploaded%20every%20month%20and%20262.8%20million%20uploaded%20every%20year.)] |Мир|30 тыс.|UPLOAD_HOUR|\n|Загрузка видео / день (час)\\[[13](https://bloggingwizard.com/youtube-statistics/#:~:text=That%E2%80%99s%2030%2C000%20hours%20of%20video%20uploaded%20every%20hour%2C%20720%2C000%20uploaded%20every%20day%2C%205.04%20million%20uploaded%20every%20week%2C%2021.9%20million%20uploaded%20every%20month%20and%20262.8%20million%20uploaded%20every%20year.)] |Мир|720 тыс.|UPLOAD_DAY|\n|Загрузка видео / месяц (час)\\[[14](https://bloggingwizard.com/youtube-statistics/#:~:text=That%E2%80%99s%2030%2C000%20hours%20of%20video%20uploaded%20every%20hour%2C%20720%2C000%20uploaded%20every%20day%2C%205.04%20million%20uploaded%20every%20week%2C%2021.9%20million%20uploaded%20every%20month%20and%20262.8%20million%20uploaded%20every%20year.)] |Мир|21.9 млн.|UPLOAD_MONTH|\n|Загрузка видео / год (час)\\[[15](https://bloggingwizard.com/youtube-statistics/#:~:text=That%E2%80%99s%2030%2C000%20hours%20of%20video%20uploaded%20every%20hour%2C%20720%2C000%20uploaded%20every%20day%2C%205.04%20million%20uploaded%20every%20week%2C%2021.9%20million%20uploaded%20every%20month%20and%20262.8%20million%20uploaded%20every%20year.)] |Мир|263 млн.|UPLOAD_YEAR|\n|Передача видео / минуту (час)\\[[16](https://www.wyzowl.com/youtube-stats/#:~:text=An%20average%20of%20694%2C000%20hours%20of%20video%20are%20streamed%20by%20YouTuber%20users%20each%20and%20every%20minute.%20This%20is%20even%20higher%20than%20Netflix%2C%20whose%20users%20stream%20452%2C000%20hours%20per%20minute.)] |Мир|694 тыс.|DOWNLOAD_MIN|\n|Количество комментариев / 1000 просмотров\\[[17](https://tubularlabs.com/blog/3-metrics-youtube-success/#:~:text=Comments%20to%20Views%3A%20How%20High%20is%20Engagement%3F)]|Мир|5|COMMENTS|\n|Количество лайков / 100 просмотров\\[[18](https://tubularlabs.com/blog/3-metrics-youtube-success/#:~:text=Likes%20to%20Views%3A%20How%20Popular%20is%20Your%20Video%3F)].|Мир|4|LIKES|\n|Количество новых подписок / день / канал \\[[19](https://medium.com/@jasonrbodie/average-youtube-channel-growth-rate-f6837584c9ac)]|Мир|1000|SUBS|\n|Количество поисковых запросов / день \\[[20](https://www.globalmediainsight.com/blog/youtube-users-statistics/#searchstat:~:text=Every%20day%2C%20more%20than%203.5%20billion%20searches%20are%20made%20on%20YouTube.)]|Мир|3.5 млрд.|SEARCH_DAY|\n|Средняя продолжительность видео (мин)\\[[21](https://bloggingwizard.com/youtube-statistics/#:~:text=7.-,The%20average%20length%20of%20a%20YouTube%20video%20is%2011.7%20minutes,-According%20to%20Statista)]|Мир|11.7|DURATION|\n|Количество посещений страниц / день / пользователь \\[[22](https://www.globalmediainsight.com/blog/youtube-users-statistics/#:~:text=An%20average%20YouTube%20visitor%20checks%20nearly%20nine%20pages%20per%20day.%C2%A0)]|Мир|9|VISITS_DAY_USER|\n|Средняя продолжительность посещения сайта (мин)\\[[23](https://inclient.ru/youtube-stats/#:~:text=%D0%9F%D0%BE%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%BC%20Similarweb%20%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D1%8F%D1%8F%20%D0%BF%D1%80%D0%BE%D0%B4%D0%BE%D0%BB%D0%B6%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%20%D0%BF%D0%BE%D1%81%D0%B5%D1%89%D0%B5%D0%BD%D0%B8%D1%8F%20%D1%81%D0%B0%D0%B9%D1%82%D0%B0%20youtube.com%20%D1%81%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D1%82%2020%20%D0%BC%D0%B8%D0%BD%D1%83%D1%82%2016%20%D1%81%D0%B5%D0%BA%D1%83%D0%BD%D0%B4)] \\[[24](https://www.statista.com/statistics/1257254/youtubecom-time-spent-per-visit/#:~:text=In%20March%202021%2C%20users%20worldwide%20spent%20an%20average%20of%201777%20seconds%20(29%20minutes%20and%2037%20seconds))]|Мир|20|VISIT_TIME|\n\nНекоторую метрику на российском рынке приблизительно можно рассчитать относительно мировой метрики\n- METRICS (rus) = METRICS (world) * (MAU / MAU)\n- METRICS (rus) = METRICS (world) * K\n- K = 95 / 2500 = 0.038\n\n### 2.1 Продуктовые метрики\n\n### 2.1.1 Сводная таблица продуктовых метрик\n\n|Действие пользователя |Количество / месяц|\n| ------------- |-------------|\n|Просмотр видео|207 млрд.|\n|Показ рекомендаций|70 млрд.|\n|Добавление лайка|8.3 млрд.|\n|Посещение сервиса (проверка авторизации)|6.2 млрд.|\n|Поиск|3.9 млрд.|\n|Подписка на канал|3.6 млрд.|\n|Лента подписок|2 млрд.|\n|Добавление комментария|1 млрд.|\n|Загрузка видеоролика на канал|4.3 млн.|\n\n### 2.1.2 Расчет продуктовых метрик\n\n- **Просмотров видео** - VIEWS_MONTH.\n- **Комментарии** - 1 млрд. / мес.\n\t- На каждые 1000 просмотров приходится COMMENTS комментариев.\n\t- Значит, в месяц происходит ```VIEWS_MONTH / 1000 * COMMENTS = 207 млрд. / 1000 * 5 = 1 млрд``` запросов на добавление комментария.\n- **Лайки** - 8.28 млрд. / мес.\n\t- На каждые 100 просмотров приходится LIKES лайков.\n\t- Значит, в месяц происходит ```VIEWS_MONTH / 100 * LIKES = 207 млрд. / 100 * 4 = 8.28 млрд``` запросов на установку лайка.\n- **Подписки** - 3.6 млрд. / мес.\n\t- В среднем, каждый канал в день набирает SUBS подписчиков при MAU_WORLD активных пользователей в месяц.\n\t- Приблизительно, каждый канал на локальном рынке в день набирает ```SUBS * K = 1000 * 0.038 = 38```.\n\t- Значит, ```MAU_RUS * 38 = 95 млн * 38 = 3.6 млрд ```подписок осуществляется в месяц. \n- **Загрузка видеоролика на канал** - 4.3 млн. / мес.\n\t- В России загружается UPLOAD_MONTH часов контента в месяц.\n\t- Каждое видео в среднем длится DURATION минут.\n\t- Следовательно, 1.6 млн. видеороликов в месяц загружаются на платформу.  \n\t- `(UPLOAD_MONTH * K * 60) мин / DURATION = (21_900_000 час * 0.038 * 60) мин / 11.7 мин = 4.3 млн видеороликов`\n- **Показ рекомендаций на главной странице** - 70 млрд. / мес.\n\t- В среднем, каждый пользователь в день посещает VISITS_DAY_USER страниц сервиса.\n\t- Допустим, на каждые 3 посещения страницы видео приходится одно посещение главной страницы\n\t- Тогда, общее количество посещений этих страниц, а, следовательно, и предложенных рекомендаций 276 млрд. \n\t- ```VIEWS_MONTH * 1/3 = 207 * 1/3 = 70 млрд```\n- **Лента подписок** -  2.07 млрд. / мес.\n\t- Допустим, что на каждые 100 просмотров видео приходится 1 просмотр ленты подписок. \n\t- `VIEWS_MONTH * 1/100 = 207 * 1/100 = 2.07 млрд`\n- **Авторизация** - 6.24 млрд. / мес\n\t- При каждом пользовательском визите сервиса (при каждой новой вкладке браузера) клиентской стороне необходимо проверить авторизацию пользователя по id сессии.\n\t- Допустим, что в день пользователь заходит на сервис 4 раза (`VIEW_DURATION_DAY / VISIT_TIME = 86 / 20 = 4`)\n\t- Тогда `DAU_RUS * 4 = 52 млн * 4 = 208 млн.` запросов на проверку авторизации в день. Значит, `208 млн. * 30 = 6.24 млрд.` запросов на авторизацию в месяц.\n- **Поиск** - 3.9 млрд. / мес.\n\t- В день происходит SEARCH_DAY поисковых запросов\n\t- `SEARCH_DAY * K * 30 = 3.5 млрд. 0.038 * 30 = 3.9 млрд`\n\n## 2.2 Технические метрики\n\n### 2.2.1 Сводные таблицы технических метрик\n\n|Хранилище |Стартовый размер (Пб)|Увеличение (Пб/год)|\n| ------------- |-------------|-------------|\n|Видео |540|540\\[[25](https://youtubeprofi.info/raspolozhenie-i-kolichestvo-serverov-youtube/#:~:text=%D0%92%202016%20%D0%B3.%20%D1%83%20YouTube%20%D0%B1%D1%8B%D0%BB%D0%BE%201%20%D0%9F%D0%91%20(1%20000%20%D0%A2%D0%91)%20%D0%B2%20%D0%B4%D0%B5%D0%BD%D1%8C%20%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE%20%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%BD%D1%82%D0%B0%2C%20%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%BD%D0%B0%20%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D1%8B.)]|\n|Данные пользователя |4|2|\n\n|Сетевой трафик |Потребление|\n| ------------- |-------------|\n|Загрузка видео (Пб / сутки) |2.4|\n|Отдача видео (Пб / сутки) |133|\n|Отдача статики (Пб / сутки)|25|\n|Средний исходящий трафик (Пб / сутки) |158 (133 + 25)|\n|Пиковый трафик отдачи видео (Тбит / с)|44|\n|Пиковый исходящий трафик (Тбит / с)|54|\n|Пиковый входящий трафик (Тбит / с)|0.8|\n\n|Тип запроса |RPS (Статика)|\n| ------------- |-------------|\n|Станица видео|2.5 млн|\n|Главная страница|1351 тыс|\n|Главная страница|75 тыс|\n|Лента подписок|38 тыс.|\n|Загрузка видеоролика на канал|17|\n\n|Тип запроса |RPS (API)|\n| ------------- |-------------|\n|Станица видео|307 тыс|\n|Главная страница|54 тыс|\n|Добавление лайка|6.4 тыс|\n|Проверка авторизации|4.8 тыс|\n|Поиск|3 тыс|\n|Подписка на канал|2.8 тыс|\n|Лента подписок|1.5 тыс|\n|Добавление комментария|800|\n|Загрузка видеоролика на канал|4|\n\n### 2.2.2 Расчет технических метрик\n#### 2.2.2.1 Хранилище\n- **Видео**\n\t- Во всем мире UPLOAD_DAY часов видео загружается на платформу каждый день. Значит, в России будет загружаться ```UPLOAD_DAY * K = 720 тыс. * 0.038 = 27_360 часов``` контента в день.\n\t- Допустим, все видео имеют разрешения 1080p \\[[26](https://osgamers.com/frequently-asked-questions/what-is-the-best-quality-for-youtube#:~:text=Statistics%20and%20research%20has%20shown%20that%20the%20amount%20people%20watching%20care%20about%20quality%20peaks%20at%201080p.%20There%20is%20no%20advantage%20as%20far%20as%20your%20viewers%20are%20concerned.)] \\[[27](https://osgamers.com/frequently-asked-questions/what-is-the-best-quality-for-youtube#:~:text=The%20most%20common%20resolutions%20for%20Youtube%20videos%20are%201280%20x%20720p%20and%201920%20x%201080p)] с частотой кадров 30 fps в формате SDR. В хранилище хранятся все варианты разрешений для обеспечения адаптивного битрейта.\n\t\t- 2160p (4K) - 40 Mbps \\[[28](https://support.google.com/youtube/answer/1722171?hl=en#zippy=%2Cframe-rate%2Cbitrate%2Cvideo-codec-h%2Cvideo-resolution-and-aspect-ratio%2Ccolor-space:~:text=Recommended%20video%20bitrates%20for%20SDR%20uploads)]\n\t\t- 1440p (2K) - 16 Mbps\n\t\t- **1080p - 8 Mbps** \n\t\t- 720p - 5 Mbps                                                 \n\t\t- 480p - 2.5 Mbps\n\t\t- 360p - 1 Mbps\n\t- ```(27_360 час * 60 * 60) сек * (8 + 5 + 2.5 + 1) Mpbs / 8 / 1024 = 198.4 тыс. Гб```\n\t- В день 95 млн. человек загружают 198.4 тыс. Гб видео. Значит, каждый год требуется `198_400 * 365 = 72 Пб` памяти для хранения видео (не включая резервные копии)\n\t- Для обеспечения надежности хранения данных в S3 хранилище допустим, что каждое видео имеет **2 резервных копии** (хранение разных версий файлов не учитываем). Таким образом, в год необходимо резервировать хранилище размером 216 Пб. \n\t- Так как в современном мире все больше выпускается **4K камер**, данные разрешение становится все более и более доступным для пользователя. Поэтому увеличим размер хранилища в 2.5 раза (40 Mbps / 8 Mbps / 2 = 2.5). Выходит, **540 Пб**. \n\t- Пусть стартовый объем хранилища на первый год будет таким же.\n- **Пользовательские данные**\n\t- Рассчитаем размер данных в объектом хранилище на пользователя. Размер данных, хранящихся в СУБД, приведен в разделе Физическая схема БД.\n\t - Допустим, остальные пользовательские данные имеют следующий размер\n\t\t - Аватар пользователя - 2 Мб\n\t\t - Превью видео - 10 Мб\n\t- 36 Мб с учетом **двух резервных копий** необходимо на каждого пользователя. \n\t- MAU_RUS - 95 млн, пользователей интернета в России - 130 млн.\n\t- Допустим, что общее количество аккаунтов 110 млн, значит, **стартовый размер хранилища** `45 Мб * 110 млн =` **4 Пб** \n\t- Пусть увеличение хранилища в год требует двое меньше объема, т.к. многие данные фиксируются на момент регистрации пользователя.  \n\n#### 2.2.2.2 Потребление трафика\n- **Среднее использование трафика (в сутки)**\n\t- **Отдача видео (download)** - 133 Пб / сутки\n\t\t- В среднем, DOWNLOAD_MIN часов видео транслируется каждую минуту. \n\t\t\t- `(DOWNLOAD_MIN * K * 60 * 60) (сек/мин) / 60 (сек/сек) * 8 Mbps / 8 / 1024 = 1545 Гб / сек`\n\t\t\t- `1545 * 60 * 60 * 24 = 133 Пб / сутки`\n\t\u003e Другой вариант расчета: `VIEW_DURATION_DAY * 60 * DAY_RUS * 8 Mbps / 8 / 1024 / 1024 / 1024 = 250 Пб / сутки`\n\t- **Страницы (стартовая, страница видео, лента подписок)** - 25 Пб / сутки\n\t\t- html, js, css - 2 Мб\n\t\t- Превью в формате WebP - 20 шт. * 50 Кб = 1 Мб\n\t\t- Выше нами было допущено, что в месяц\n\t\t\t- главная страница открывается 1/3 * VIEWS_MONTH раз\n\t\t\t- страница видео открывается VIEWS_MONTH раз\n\t\t\t- лента подписок открывается 1/100 VIEWS_MONTH раз\n\t\t- `(1 + 1/3 + 1/100) * VIEWS_MONTH * 3 Мб / 30 = 1.34 * 207 млрд. * 3 Мб = 25 Пб / сутки`\n\t- **Загрузка видео (upload)** - 2.4 Пб / сутки\n\t\t- В день загружается UPLOAD_DAY часов видео в день. \n\t\t\t- `UPLOAD_DAY * 60 * 60 * 8 Mbps / 8 /  1024 / 1024 / 1024 = 720 тыс. * 60 * 60 * 8 Mbps / 8 / 1024 / 1024 / 1024 = 2.4 Пб / сутки`\n- **Пиковое использование трафика (в секунду)**\n\t- **Отдача видео (download)** - 44 Тбит / c \n\t\t- Допустим, что пиковое (дневное) потребление в 1.8 раза больше среднего \\[[29](https://cloud.mail.ru/public/8Mau/tKmAN3kqb)] (слайд 14), получим `133 Пб/сутки * 1024 Тб * 1.8 / 86400 * 8 = 22 Тбит / c`\n\t\t- Также учтем некоторый **запас** по потреблению трафика - x2. Таким образом, потребление **44 Тбит/c**. \n\t- **Общее пиковое потребление (видео и страницы)** - 54 Тбит / c \n\t\t-  `(133 Пб/сутки + 25 Пб/сутки) * 1024 Тб * 1.8 / 86400 * 8 * 2 = 54 Тбит / c`\n\t- **Загрузка видео (upload)** - 0.8 Тбит / c\n\t\t- С учетом дневного пика и запаса (1.8 \\* 2 = x3.6) - **0.8 Тбит / c**\n\n#### 2.2.2.3 RPS по типам запросов\n\n- Количество подзапросов для каждого действия пользователя\n\t- **Страница видео** (18 запросов)\n\t\t- Статика\n\t\t\t- Первый видеочанк - 1 запрос\n\t\t\t- Превью - 10 запросов \n\t\t\t- html, js, css - 5 запросов\n\t\t- Динамика\n\t\t\t- Комментарии, кол-во лайков, просмотров, описание видео - 1 запрос\n\t\t\t- Рекомендации - 1 запрос\n\t- **Поиск / главная страница** (26 запросов)\n\t\t- Статика\n\t\t\t- Превью - 20 запросов \n\t\t\t- html, js, css - 5 запросов\n\t\t- Динамика\n\t\t\t- Поиск / Рекомендации - 1 запрос\n\t- **Лента подписок** (26 запросов)\n\t\t- Статика\n\t\t\t- Превью - 20 запросов \n\t\t\t- html, js, css - 5 запросов\n\t\t- Динамика\n\t\t\t- Список подписок - 1 запрос\n\t- **Добавление лайка** (Динамика - 1 запрос)\n\t- **Подписка на канал** (Динамика - 1 запрос)\n\t- **Добавление комментария** (Динамика - 1 запроса)\n\t- **Загрузка видеоролика на канал** (6 запросов)\n\t\t- Статика\n\t\t\t- html, js, css - 5 запросов\n\t\t- Динамика\n\t\t\t- Отправка параметров загрузки видео - 1 запрос\n\t- **Проверка авторизации** (Динамика - 1 запрос)\n\n\u003e Увеличим каждое значение RPS в 2 раза для отказоустойчивости в случае пиковых нагрузок\n\n|Тип запроса |RPS (Статика)|\n| ------------- |-------------|\n|Станица видео|`207 млрд / 30 / 86400 * 16 * 2 = 2.5 млн`|\n|Главная страница|`70 млрд / 30 / 86400 * 27 * 2 = 1351 тыс`|\n|Поиск|`3.9 млрд / 30 / 86400 * 27 * 2 = 75 тыс`|\n|Лента подписок|`2 млрд / 30 / 86400 * 25 * 2 = 38 тыс.`|\n|Загрузка видеоролика на канал|`4.3 млн / 30 / 86400 * 5 * 2 = 17`|\n\n|Тип запроса |RPS (API)|\n| ------------- |-------------|\n|Станица видео|`207 млрд / 30 / 86400 * 2 * 2 = 307 тыс`|\n|Главная страница|`70 млрд / 30 / 86400 * 1 * 2 = 54 тыс`|\n|Поиск|`70 млрд / 30 / 86400 * 1 * 2 = 3 тыс`|\n|Лента подписок|`2 млрд / 30 / 86400 * 1 * 2 = 1.5 тыс.`|\n|Добавление лайка|`8.3 млрд / 30 / 86400 * 1 * 2 = 6.4 тыс`|\n|Проверка авторизации|`6.2 млрд / 30 / 86400 * 1 * 2 = 4.8 тыс`|\n|Подписка на канал|`3.6 млрд / 30 / 86400 * 1 * 2 = 2.8 тыс`|\n|Добавление комментария|`1 млрд / 30 / 86400 * 1 * 2 = 800`|\n|Загрузка видеоролика на канал|`4.3 млн / 30 / 86400 * 1 * 2 = 4`|\n\n## 3. Глобальная балансировка нагрузки \u003ca name=\"3\"\u003e\u003c/a\u003e\n\n### 3.1 Схема глобальной балансировки до датацентров\n\nСхема глобальной балансировки включает следующее:\n1. Кэши в локальных ISP.\n2. CDN подключены к крупным IX.\n3. GeoDNS выбирает ближайшую группу CDN.\n4. BGP Anycast до ближайшего CDN.\n5. CDN кэширует статику и ускоряет динамику с ЦОДов\n\n\n*Пояснения:*\n1. Предложение всем локальным **ISP** использовать специальные **Storage сервера сервиса YouTube**\\[[30](https://www.youtube.com/watch?v=g5v2-H-sabM\u0026t=537s)] (уменьшение трафика с внешних линков ISP, ускорение доставки контента пользователям).\n2. Сеть **CDN** подключена к крупным точкам обмена трафика **Internet Exchange** (Cloud-IX объединяет в себе крупные Российские и не только IX \\[[31](https://hww.ru/2021/03/tochki-obmena-trafikom-ili-kak-ustroen-internet-v-rossii/#:~:text=SDN%2C%20Xelent%2C%20Infobox.-,Cloud%2DIX,-%D0%92%202012%20%D0%B3)])\n3. **GeoDNS** сервера определяют локацию пользователя и возвращают IP адрес, за которым находится группа CDN. CDN, в свою очередь, знают об адресах ЦОДов. \n4. Узлы сети в России распределены неравномерно \\[[32](https://telecomlife.ru/magistralnaya-set/)], поэтому, если назначить всем CDN один IP адрес, **BGP Anycast** может выбрать оптимальный маршрут с точки зрения топологии (метрика - количество хопов), но географически неоптимальный \\[[33](https://youtu.be/LPCbKzhvAGc?t=1265)]. Необходимо кластеризовать сервера CDN на локальные группы и назначить каждой группе один IP адрес. Маршрут до ближайшего к пользователю CDN в рамках группы будет выбран BGP роутером. Текущая конфигурация называется \"Региональный Anycast\" \\[[34](https://www.youtube.com/watch?v=LPCbKzhvAGc\u0026t=1370s)]. Преимущества и недостатки BGP Anycast \\[[35](https://www.youtube.com/watch?v=9VVzu87lVbE\u0026list=LL\u0026index=12\u0026t=1240s)].\n5. CDN, близкий к пользователю сервер, держит с граничными маршрутизаторами ЦОДов постоянные \"прогретые\" соединения (увеличенное окно передачи) для ускорения доставки динамического контента и статики. Статика кэшируется на CDN.  \n\n### 3.2 Физическое расположение датацентров\n\n- Наибольшая плотность населения России приходится на западную и юго-западную часть \\[[36](https://www.statdata.ru/karta/plotnost-naseleniya-rossii)]. \n- Расположим сервера в следующих городах: в Москве в двух зонах доступности и в Новосибирске (расположение ЦОДов в России \\[[37](https://yandex.ru/maps/?display-text=Дата-центры\u0026ll=42.072758%2C49.349507\u0026mode=search\u0026sctx=ZAAAAAgBEAAaKAoSCQiPNo5Y4FhAEUsgJXZt2U5AEhIJYJD0aZV0ZUAR9wX0wp1ZREAiBgABAgMEBSgKOABAkE5IAWIScG9pbnRfY29udGV4dF92Mj0xagJydZ0BzcxMPaABAKgBAL0B4DucO8IBMOO21I%2BKB8OQmYjwAfD6p5jyAvLMr6q2Aqi8qOj3BeP4xfGAAdPYgcuVBZG31ZugBeoBAPIBAPgBAIICGmNhdGVnb3J5X2lkOigxNzE2NDcwNDgzNDUpigIMMTcxNjQ3MDQ4MzQ1kgIAmgIMZGVza3RvcC1tYXBzqgIzMTkzNzMyNDc4MjQyLDIyMjI1ODM2NTUyMywyMDcyNDkzNzMyOTgsMjE2NjE4NTAzODAx\u0026sll=42.072758%2C49.349507\u0026sspn=18.673879%2C7.829843\u0026text=category_id%3A%28171647048345%29\u0026z=5.81)]\\[[38](https://www.datacentermap.com/russia/)])\n- Сеть CDN будет состоять из 100 серверов, расположенных по всей стране. \n- Сервера можно арендовать в ЦОДах существующих компаних, например, Selectel \\[[39](https://docs.selectel.ru/control-panel-actions/selectel-infrastructure/#инфраструктура-selectel)] имеет 2 AZ в Москве и 1 AZ в Новосибирске, или построить свои ЦОДы. Этот вопрос необходимо согласовать с бизнесом.  \n ![](img/Pasted%20image%2020231002075842.png)\n \u003e 1. VK имеет 3 ЦОДа в Москве, в Санкт-Петербурге и Екатеринбурге \\[[40](https://uchet-jkh.ru/i/gde-naxodyatsya-servera-vkontakte/#:~:text=%D0%A1%D0%B5%D0%B9%D1%87%D0%B0%D1%81%20%D0%92%D0%9A%D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D0%B5%20%D0%B8%D0%BC%D0%B5%D0%B5%D1%82%20%D0%BD%D0%B5%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE%20%D0%BA%D1%80%D1%83%D0%BF%D0%BD%D1%8B%D1%85%20%D1%86%D0%B5%D0%BD%D1%82%D1%80%D0%BE%D0%B2%20%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85)], а также сеть CDN, состоящую из 100 серверов \\[[41](https://habr.com/ru/news/731714/#:~:text=%D0%9F%D0%BE%20%D0%B8%D1%85%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D0%BC%2C%20VK%20%D1%83%D0%B6%D0%B5%20%D0%BD%D0%B5%D1%81%D0%BA%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE%20%D0%BB%D0%B5%D1%82%20%D1%80%D0%B0%D0%B7%D0%B2%D0%B8%D0%B2%D0%B0%D0%B5%D1%82%20%D1%81%D0%B2%D0%BE%D1%8E%20CDN%2D%D1%81%D0%B5%D1%82%D1%8C%2C%20%D0%B0%20%D0%B2%20%D1%8D%D1%82%D0%BE%D0%BC%20%D0%B3%D0%BE%D0%B4%D1%83%20%D0%BA%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%80%D0%B5%D1%88%D0%B8%D0%BB%D0%B0%20%D1%83%D0%B2%D0%B5%D0%BB%D0%B8%D1%87%D0%B8%D1%82%D1%8C%20%D0%B5%D1%91%20%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80%D0%BD%D0%BE%20%D0%B2%D0%B4%D0%B2%D0%BE%D0%B5%20%D0%B1%D0%BE%D0%BB%D0%B5%D0%B5%20%D1%87%D0%B5%D0%BC%20%D1%81%D0%BE%20100%20CDN%2D%D1%83%D0%B7%D0%BB%D0%BE%D0%B2%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5%20%D1%81%D0%B5%D0%B9%D1%87%D0%B0%D1%81%20%D0%B5%D1%81%D1%82%D1%8C%20%D1%83%20VK%20%D0%BF%D0%BE%20%D0%B2%D1%81%D0%B5%D0%B9%20%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B5.)]. \n \u003e 2. Сервис YouTube имеет один российский ДЦ в Москве \\[[42](https://youtubeprofi.info/raspolozhenie-i-kolichestvo-serverov-youtube/#:~:text=%D0%B2%20%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8%20%D0%B8%20%D0%AE%D0%B6%D0%BD%D0%BE%D0%B9%20%D0%90%D0%BC%D0%B5%D1%80%D0%B8%D0%BA%D0%B5%20%E2%80%93%20%D0%BF%D0%BE%201.)] (основную нагрузку по потреблению видео берут на себя CDN)\n \n\n## 4. Локальная балансировка нагрузки \u003ca name=\"4\"\u003e\u003c/a\u003e\n\n### 4.1 Схема локальной балансировки для входящих и межсервисных запросов\n\n1. **CDN держит \"прогретые\" соединения с граничными маршрутизаторами** в ЦОДах. Для обеспечения доступности и отказоустойчивости зарезервируем второй маршрутизатор (резервирование N+1). Используем для этого протокол **BGP**, который анонсирует одинаковую метрику другим AS и, соответственно, запросы балансируются хэшам.   \n2. Многоуровневая балансировка. После граничного маршрутизатора следует **слой коммутаторов**, далее - **слой L7 балансировщиков**. Симметричная топология позволяет балансировать трафик посредством стека **BGP, ECMP**.\n\t- на каждом балансере программный роутер (для BGP Anycast)\n\t- режим ECMP **per-flow** для \"закрепления\" одной tcp сессии за одним сервером\n\t- для избавления от поляризации в ECMP добавление соли в хэш каждым узлом.\n\t- ECMP балансирует на основе **5-tuple hashing**. Расширим реализацию добавлением **consistent hashing** для минимизации расщепления tcp сессий в случае добавления или удаление из балансировки L7 балансировщиков. \n4. **L7 балансировщики** - **serive load balancer**-ы вне кластера **k8s**. Сервисы расположены на отдельных bare-metal серверах из соображений безопасности, доступности, отказоустойчивости.\n\t- реализация L7 balancer - **envoy**\n\t- динамическое конфигурирование upsteram-ов через Service Discovery, который находится в кластере k8s \n\t- **функциональная балансировка** по субдоменам и префиксам. \n\t- **rate limiting**\n \t- cache\t \t\n\t- **ssl termination**. Оптимизация: **session cache, session tickets** \n5. Балансировка Service-ом запросов между подами в рамках одного replicaset. Т.к. сервис - это правила iptables, то балансировка примитивная - **случайное распределение**. \n\n## 5. Логическая схема БД \u003ca name=\"5\"\u003e\u003c/a\u003e\n\n### 5.1 ER диаграмма логического уровня\n\nНа рисунке представлена **нормализованная ER диаграмма логического уровня**, показывающая все сущности, связи между ними и атрибуты ([ER-диаграмма](https://drawsql.app/teams/bmstu-7/diagrams/youtube))\n\n![](files/drawSQL-youtube-export-2023-10-19.png)\n\nВидеофайлы, превью видео, аватарки будут храниться в **объектом хранилище**. В соответствующих таблицах присутствуют ссылки на хранилище.\n\n### 5.2 Характер нагрузки, требования к системе\n- **Много чтений, мало записей** (см. сводную таблицу продуктовых метрик)\n- **Чтение может отставать** от записи (**not consistency**)\n\t- Только что вышедший ролик может не сразу появляться на странице\n\t- Лайк одного пользователя может не сразу инкрементировать счетчик лайков у другого\n- Есть блогеры, у которых много контента (**hot spot**)\n- **Не толерантны к задержке**\n\t- Главная страница с рекомендациями должна загружаться быстро\n\t- Видео на странице видео должно сразу воспроизводиться\n- **Большинство запросов селективные по ключу** \n\n|Тип запроса |RPS (API)|Характер запроса|\n| ------------- |-------------|--------|\n|Станица видео|307 тыс|**Селективный** запрос по video_id|\n|Главная страница|54 тыс|**Селективные** запросы по video_ids (video_ids от рекомендательной системы)|\n|Добавление лайка|6.4 тыс|**Селективный** запрос по video_id и инкремент поля|\n|Проверка авторизации|4.8 тыс|**Селективный** запрос по user_id|\n|Поиск|3 тыс|**Full scan** запрос|\n|Подписка на канал|2.8 тыс|**Селективный** запрос по user_id и обновление поле списка подписчиков|\n|Лента подписок|1.5 тыс|**Селективный** запрос по user_id, **селективные** запросы по video_ids|\n|Добавление комментария|800|Добавление записи по новому comment_id|\n|Загрузка видеоролика на канал|4|Добавление записи по новому video_id, загрузка исходного видео в хранилище, асинхронная обработка видео|\n- **Онлайн выдача рекомендаций** по user_id\n- Быстрые атомарные **инкременты** (количество лайков, подписчиков, комментариев, просмотров)\n- **Асинхронная** многостадийная **обработка загружаемых видео**\n\nИсходя из характера запросов и особенностей системы схему данных нужно **денормализировать** (см. физическую схему БД). \n\u003e Денормализованная БД позволит не обращаться к разным сущностям для сбора всей информации, необходимой для рендера страницы, что уменьшит задержку. Однако вследствие дублирования данных в нескольких таблицах необходимо организовать **асинхронные процессы обновления дублируемых полей** в одних таблицах при обновлении этих полей в других. \n\n## 6. Физическая схема БД \u003ca name=\"6\"\u003e\u003c/a\u003e\n\n\u003e При расчете размера хранения id всех сущностей имеет тип uuid4 (16 байт)\n\n### 6.1 Метаданные видео\n![](files/Pasted%20image%2020231020011417.png)\n\n\n- **СУБД**\n\t- Cassandra (key - wide columns)\n- **Индексы**\n\t- Partition key - video_id\n- **Запросы**\n\t- Запросы по video_id\n\t\t- Чтение данных column set-а\n\t\t- Обновление полей\n\t- Добавление строки\n- **Подходы к масштабированию**\n\t- Шардирование по video_id\n- **Резервное копирование** \n\t- Присутствует\n- **Размер хранения** - 2.3 Тб / год\n\t- Средний размер строки 660 байт\n\t- Загрузки видео имеет 4 RPS\n\t- `660 * 4 * 86400 * 30 * 365 = 2.3 Тб / год`\n\n*Замечания*\n- Размерность ML фичей фиксирована, поэтому количество столбцов заранее известно\n\n### 6.2 Комментарии под видео\n\n![](files/Pasted%20image%2020231020011615.png)\n\n\n-  **СУБД**\n\t- Mogno (document-oriented)\n- **Индексы**\n\t- **btree index**: (video_id, count_likes)\n\t- **btree index**: (video_id, created_at) \n\t- **btree index**: (video_id, comment_id) \n- **Запросы**\n\t- Топ комментариев по количеству лайков\n\t- Новые комментарии\n\t- Конкретный комментарий (для вложенных комментариев)\n\t- Добавление новых комментариев\n\t- Обновление полей\n\t\t- count_likes\n\t\t- text\n\t\t- likes_user_ids\n\t\t- username\n- **Подходы к масштабированию**\n\t- Много реплик на чтение (т.к. страница видео имеет большой RPS, каждый раз отображаются топ комментариев)\n- **Резервное копирование** \n\t- Присутствует\n- **Размер хранения** - 227 Тб / год\n\t- Средний размер строки 330 байт\n\t\t- Среднее количество лайков на видео 12 \\[[43](https://charmbeautify.com/lifestyle/how-many-likes-does-the-average-person-get-on-youtube#:~:text=got%20your%20answer%3A-,The%20average%20person%20on%20YouTube%20gets%20about%2012%20likes%20per%20video,-.)]\n\t\t- Среднее количество символов в комментарии 58 \\[[44](http://cba.scit.wlv.ac.uk/~cm1993/papers/CommentingYouTubePreprint.pdf)]\n\t- Добавление комментария имеет 800 RPS\n\t- `330 * 800 * 86400 * 30 * 365 = 227 Тб / год`\n\n\n\n### 6.3 Реакции пользователя\n![](files/Pasted%20image%2020231020011631.png)\n\n- **СУБД**\n\t- Tarantool (in-memory)\n- **Индексы**\n\t- **btree index**: (user_id, video_id)\n\t- **btree index**: (user_id, created_at) \n-  **Запросы**\n\t- Поиск реакции пользователя на видео (селективный запрос по ключу)\n\t- Понравившиеся и просмотренные видео пользователя (количество лимитировано)\n\t- Добавление строк\n\t- Обновление views.continue по (user_id, video_id)\n\t- Обновление likes.vote по (user_id, video_id)\n- **Подходы к масштабированию**\n\t- Шардинг по user_id\n\t- Репликация master/slave\n- **Резервное копирование** \n\t- Присутствует\n- **Размер хранения** - Лайки 240 Тб/год и просмотра 11 Пб / год\n\t- Средний размер строки 44 байта\n\t- Добавление лайка имеет 6.4 тыс. RPS\n\t- Страница видео (добавление просмотра) имеет 307 тыс. RPS\n\t- Лайки: `44 * 6400 * 86400 * 30 * 365 = 240 Тб / год`\n\t- Просмотры:  `44 * 307000 * 86400 * 30 * 365 = 11.2 Пб / год`\n\n### 6.4 Данные пользователя \n\n![](files/Pasted%20image%2020231020011807.png)\n\n-  **СУБД**\n\t- Cassandra (key - wide columns)\n- **Инексы**\n\t- Partition key - user_id\n - **Запросы**\n\t- Запросы по user_id\n\t\t- Чтение данных column set-а\n\t\t- Обновление полей\n\t- Добавление строки\n- **Подходы к масштабированию**\n\t- Шардирование по user_id\n- **Резервное копирование** \n\t- Присутствует\n- **Размер хранения** - 57 Гб\n\t- Средний размер строки - 530 байт\n\t\t- В среднем на человека приходится 15 видео (`(UPLOAD_YEAR / MAU_RUS) * 60 / DURAION = 15`)\n\t- MAU в России 95 млн. Берем 110 млн, т.к. необходимо хранить данные не только активных пользователей.\n\t- `530 * 110_000_000 = 57 Гб`\n\n### 6.5 Сессия пользователя\n\n![](files/Pasted%20image%2020231020014838.png)\n\n- **СУБД**\n\t- Redis (key - touple)\n- **Индексы**\n\t- Ключ - session_id\n- **Запросы**\n\t- Чтение по ключу session_id\n\t- Добавление новой сессии\n- Подходы к масштабированию**\n\t- Шардирование по session_id\n\t- Репликация master/slave\n- **Резервное копирование** \n\t- Присутствует\n- **Размер хранения** - 3.7 Гб\n\t- Средний размер строки - 40 байт\n\t- MAU в России 95 млн. Сессии хранятся только активных пользователей.\n\t- `40 * 95_000_000 = 3.7 Гб`\n\n### 6.6 Другие хранилища и сервисы\n- **Kafka**\n\t- Прием логов, статистики, стриминг consumer-ам\n\t- Очередь на обновление данных в денормализованной схеме\n\t- Обеспечение работы pipeline-а обработки видео\n\t- Буфер запросов\n\t- Публикация событий, происходящих в системе\n- **S3** \n\t- Видеочанки\n\t- Аватарки пользователей\n\t- Превью видео\n\t- ML модели\n- **Feature store**\n\t- Специализированная БД для хранения фич для ML\n- **Spark streaming**\n\t- Прием на потоке данных из kafka\n\t- MapReduce (e.g. определение топ тегов для каждого видео)\n- **Hadoop**\n\t- Хранение данных для рекомендательной системы\n- **ClickHouse**\n\t- Аналитика для аналитиков\n- **Elastic Search**\n\t- Поиск видео по запросу\n\t- Поиск по названию, описанию, тегам, специфике канала\n \n### [Физическая схема](https://drive.google.com/file/d/1pL2ZMze6rzH9rk132Jd2hL3U_TRu0PPp/view?usp=sharing)\n\n\n\n\n## 7. Алгоритмы \u003ca name=\"7\"\u003e\u003c/a\u003e\n\n### 7.1 Рекомендации \n\n- Новому пользователю рекомендуем самые популярные видео. Это видео за текущий месяц, которые быстро набирают просмотры. \n- **Подготовка рекомендаций (оффлайн в hadoop)**\n\t- **Модель совстречаемости** (item2item рекомендации): на каждой паре видео сопоставляем взвешенную сумму взаимодействий в рамках одной сессии. Таким образом для каждого видео можно получить список видероликов, которые пользователи смотрели вместе с первым, лайкали вместе с первым и т.д.\n\t\t- Дешево по ресурсам. Совстречаемость можно пересчитывать не часто.\n\t\t- Быстрая выдача онлайн.\n\t\t- Нет учета особенностей пользователя. Однако на веб-сервисе YouTube не требуется в профиле заполнять предпочтения, хобби, любимые тематики видео и т.д.\n- **Ответ на запрос, формирование выдачи (онлайн)**\n\t- Подбор похожих видеороликов на те, которые пользователь смотрел недавно (последний месяц или неделя)\n\t- Видео, для которых нужно найти похожие по модели совстречаемости, ранжируются исходя из **веса взаимодействия** с ними пользователя: время просмотра видео, наличие лайка, наличие комментария.\n\t- Походы в БД за метаданными видео по id (превью, название, канал), проверка.\n\t- Чистовое ранжирование\n\t\t- фильтрация\n\t\t- разнообразие\n\t\t- сортировка рекомендуемых видео (по популярности видео, по соотношению лайков / дизлайков, по новизне)\n\n\nВидео, которые присутствовали в рекомендациях, \n- не встречаются больше в рекомендациях\n- анализируются на предмет клика по ним пользователя (для валидации модели).\n\n***User2item** рекомендации дорогие по ресурсам, так как каждый новый просмотр требует пересчета всего списка рекомендаций. Поэтому используем item2item для подготовки рекомендаций и динамическое ранжирование для конкретного пользователя*.\n\nИсточник \\[[45](https://github.com/vadim0912/ML2023/blob/master/lecture09/RecSys.pdf)]\n\n### 7.2 Пайплайн обработки видео\n\nАсинхронный пайплан обработки видео состоит из следующих стадий. Запускается во много потоков на многих нодах.\n- **Разбиение** исходных видеофайлов **на чанки**\n- **Фильтрация контента** нейросетями (цензура).  \n- Определение ключевых **тегов видео**, категории видео нейросетями.\n- **Транскодирование видеочанка** в несколько форматов, чтобы обеспечить доступность для разных типов устройств (MP4, WebM и т.д.)\n- Конвертация видеочанка в различные **разрешения** (1080, 720, 480 и т.д.)\n- **Загрузка видео** на главные сервера CDN и в кластер S3.\n\n## 8. Технологии \u003ca name=\"8\"\u003e\u003c/a\u003e\n\n| Технология  | Применение  | Обоснование|\n|-------------|--------------------------------|-|\n| Go          | Backend, основной язык сервисов| Простота языка, удобные тулзы из коробки, высокая утилизация CPU|\n| C          | Backend, высоконагруженные сервисы| Оптимизация узких мест, ускорение высоконагруженных частей проекта|\n| Python          | Рекомендательная система, PySpark для запросов в Hadoop, ML задачи| Единый язык для ML задач |\n| TypeScript, React | Frontend| Типизация, сокращение человеко-часов не отладку, ускорение процесса разработки, компонентный подход|\n| ELK*     | Автоматизация работы с логами. Хранение и поиск данных, обработка и фильтрация, интерфейс для администрирования \\[[46](https://habr.com/ru/articles/671344/)]| Масштабируемость, отказоустойчивость, гибкость поиска, REST API, универсальность \\[[47](https://bigdataschool.ru/blog/elk-stack-key-features.html)]. **Конкуренты**: Splunk, Graylog|\n| Vault       | Хранилище секретов| Специализированная БД для хранения секретов, поддержка полного жизненного цикла секрета, политики доступа \\[[48](https://habr.com/ru/articles/306812/)] **Конкуренты**: облачные решения, хранение в репозитории |\n| Jaeger      | Система трассировки| - |                                   |\n| VictoriaMetrics  | Хранение метрик и работа с метриками| Производительность, меньший объем для хранения, чем в Prometheus \\[[49](https://habr.com/ru/companies/otus/articles/541640/#:~:text=VictoriaMetrics%20%D1%82%D1%80%D0%B5%D0%B1%D1%83%D0%B5%D1%82%20%D0%B4%D0%BE%205%20%D1%80%D0%B0%D0%B7%20%D0%BC%D0%B5%D0%BD%D1%8C%D1%88%D0%B5%20%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B9%20%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D0%B8%20%D0%B8%20%D0%B4%D0%BE%207%20%D1%80%D0%B0%D0%B7%20%D0%BC%D0%B5%D0%BD%D1%8C%D1%88%D0%B5%20%D0%B4%D0%B8%D1%81%D0%BA%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE%20%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D1%81%D1%82%D0%B2%D0%B0%20%D0%BF%D0%BE%20%D1%81%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D1%8E%20%D1%81%20Prometheus%20%D0%BF%D1%80%D0%B8%20%D1%81%D0%BA%D1%80%D0%B0%D0%B9%D0%BF%D0%B8%D0%BD%D0%B3%D0%B5%20%D1%82%D1%8B%D1%81%D1%8F%D1%87%20node_exporter.%20%D0%AD%D1%82%D0%BE%20%D0%BF%D1%80%D0%B8%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%20%D0%BA%20%D0%B7%D0%BD%D0%B0%D1%87%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D0%B9%20%D1%8D%D0%BA%D0%BE%D0%BD%D0%BE%D0%BC%D0%B8%D0%B8%20%D0%BD%D0%B0%20%D0%B8%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B5.)] \\[[50](https://habr.com/ru/articles/568090/#:~:text=%D0%92%20%D0%BA%D0%B0%D0%BA%D0%BE%D0%B9%2D%D1%82%D0%BE,vmselect%20%2B%20vminsert%20%2B%20vmstorage.)]. **Конкуренты**: Prometheus, graphit \\[[51](https://prometheus.io/docs/introduction/comparison/)]|\n| Grafana     | Визуализация графиков, мониторинг и алерты| **Конкуренты**: Kibana |\n| Kafka       | Стриминговый сервис, брокер сообщений| Партиционирование из коробки, много топиков, сообщения могут быть прочитаны многими consumer-ами. **Конкуренты**: Pulsar, RabbitMQ \\[[52](https://habr.com/ru/companies/slurm/articles/548702/)]|\n| Envoy       | Балансировщик, reverse proxy| Динамическое чтение логов из SD, бОльшая функциональность, чем в nginx, поддержка gRPC \\[[53](https://habr.com/ru/companies/slurm/articles/513504/#:~:text=%D0%9D%D0%B0%D1%88%D0%B0%20%D1%81%D1%82%D0%B0%D1%80%D0%B0%D1%8F%20%D0%B8%D0%BD%D1%84%D1%80%D0%B0%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%82%D1%83%D1%80%D0%B0%2C%20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%BD%D0%B0%20Nginx)].  **Конкуренты:** HAProxy, nginx, traefic|\n| GitHub      | Система контроля версий, командная разработка, CI/CD.| - |\n| Kubernetes  | Deploy| Масштабирование, отказоустойчивость, утилизация ресурсов|\n| Redis       | Кэш сессий |  **Конкуренты**: Tarantool |\n| Tarantool  | Хранение лайков и просмотров| In-memory, persistence. **Конкуренты**: Redis |\n| Cassandra  | Хранилище метаданных пользователя и видео| Линейная масштабируемость, обработка больших объемов, высокая производительность, доступность, децентрализованная архитектура. Column-Family. \\[[54](https://habr.com/ru/companies/otus/articles/729890/)] **Конкурент**ы: Apache HBase, Bigtable (строгая согласованность), ScyllaDB|\n| MongoDB  | Хранение комментариев| Формат хранения данных json. **Конкуренты**: PostreSQL|\n| S3  | Хранение статического контента| Стандартный протокол. **Конкуренты**: облачные решения |\n| Hadoop  | Big Data | Стандартный утилиты, spark запросы. **Конкуренты**: YTsaurus |\n| ClickHouse  | Аналитическая БД| Производительность, масштабируемость, сжатие, язык запросов, большие объемы данных, поддержка Golang **Конкуренты**: Vertica, GreenPlum |\n| Elastic Search  | Поиск видео | Специализированная БД для задач полнотекстового поиска|\n| HTTP/3  | Протокол L7| Транспортный протокол Quic поверх UDP, отсутствие проблем TCP (блокировки head-of-line, RTT) |\n| HESP \\[[55](https://habr.com/ru/companies/gcorelabs/articles/593805/)]  | Протокол стриминга видео| Адаптивный битрейт, низкие требования к полосе пропускания, поверх HTTP, поддержка онлайн трансляций. \\[[56](https://investim.guru/news/youtube-hls-ili-rtmp-kakoy-protokol-luchshe-vybrat-dlya-potokovoy-peredachi-video?utm_referrer=https%3A%2F%2Fyandex.ru%2F)] **Конкуренты**: WebRTC, HLS, RTMP, HTTP range requests|\n\n## 9. Схема проекта \u003ca name=\"9\"\u003e\u003c/a\u003e\n\n![Youtube-общая схема](https://github.com/mmikhail2001/Highload_YouTube/assets/71098937/a18bf2f1-4c56-4382-9747-fe06e8413b51)\n\n### [Схема проекта](https://drive.google.com/file/d/1pL2ZMze6rzH9rk132Jd2hL3U_TRu0PPp/view?usp=sharing)\n\n## 10. Обеспечение надежности \u003ca name=\"10\"\u003e\u003c/a\u003e\n\n- Резервирование аппаратных ресурсов, серверов, дисков (raid-массивы)\n- Использование крупных IX для размещения CDN серверов\n- Резервирование CDN, резервирование ДЦ, резервирование граничных роутеров на входе в ДЦ (BGP Anycast)\n- Многоуровневая локальная балансировка до k8s кластера\n\t- Граничные роутеры\n\t- Уровень access switch-ей\n\t- Уровень L7 балансировщиков\n- Резервные копии файлов в S3 хранилище, tired S3\n- Расчеты пикового трафика и размера хранение с коэффициентом запаса  \n- Взаимодействие между сервисами\n\t- План Б при отказе сервисов, урезанная выдача, fallback реализации на более простую\n\t\t- Например, топ видео вместо рекомендательной системы\n\t\t- Рекомендации двухдневной давности\n  \t- Circuit breaker (возможность проблемному сервису восстановиться - временное отключение)\n\t- Установка дедлайнов по 99.95 персентилю, deadline propagation \n\t- Re-try requests (повторные запросы в рамках дедлайна для времени обработки исходного запроса) \n- Rate limiting для клиента (например, алгоритм Token Bucket)\n- SIEM-система - анализ трафика на возможность атаки \n- Использование k8s\n\t- минимизация отказов, т.к. оркестратор **масштабирует сервисы** исходя из текущей нагрузки\n\t- **эфимерность stateless подов** (перезапуск, реплицирование)\n\t- способ деплоя **Rolling updates**\n\t\t- замена подов со старой версией один за другим на поды без простоя \n\t\t- оркестратор дожидается готовности новых pod'ов (readiness пробы) прежде чем приступить к сворачиванию старых \n\t\t- возникшая проблема - обновление прерывается без простоя кластера.\n\t- **liveness** и **readiness** пробы от kubelet \n\t- etcd\n\t\t- надежность при (n / 2) + 1 живых узлах\n\t\t- каждый узел хранит копию узла-лидера\n\t\t- все изменения должны быть приняты большинством перед сохранением\n- CQRS\n\t- синхронное чтение из БД\n\t- асинхронная запись через брокер сообщений\n- event-driven архитектура (content processor на общей схеме, запись в денормализованную схему, статистика для )\n\t- **применения**\n \t\t- content processor\n   \t\t- запись в денормализованную схему\n     \t\t- статистика для сервисов агрегации статистики\t \t \t\n\t- события публикуем в брокер сообщений\n\t- consumer-ы на другой стороне асинхронно обрабатывают события\n- Отказоустойчивость БД\n\t- Используемые БД устойчивы к разделению (P из CAP теоремы)\n\t- Отказоустойчивость - второе имя Cassandra. Отсутствие центрального узла - отсутствие bottleneck. Все узлы непрерывно общаются между собой. Репликация данных на большие число узлов в кластере. \n\t- Реплицирование / шардирование обеспечивают отказоустойчивость при многочисленных транзакциях на чтение / запись \n\t- Резервное копирование, снапшоты и xlog-и (binlog, wal) для восстановительных операций.\n\n## 11. Расчет ресурсов \u003ca name=\"11\"\u003e\u003c/a\u003e\n\n![](files/Pasted%20image%2020231127184140.png)\n### CDN\n- 100 CDN (Для сравнения CDN Selectel - 30 PoP, 300+ Tbit/s)\n\t- Раздача видео, статики \n- Пиковый исходящий трафик = 54 Tbit/s\n- 54000 Gbit / 100 Gbit =  540 серверов\n- 540 серверов / 100 CDN = 6 серверов / CDN в среднем (в центральном округе больше) \n- Конфигурация 2U 2x6338/16x32GB/**24xNVMe16T/2x100Gb/s**\n\n### AZ\n- 2 AZ в Москве и 1 AZ в Новосибирске \n- Провайдер датацентров - **Selectel**\n\t- Пользуемся услугой: Размещение оборудования -\u003e Изолированная зона для серверов\n- **S3**\n\t- Размещение - bare-metal (hdfs)\n\t- 180 Пб / год\n\t- 180000 Тб / (24 * 16) = 470 серверов\n \t- 3 резервные копии: 470 * 3 = 1400 серверов\n\t- Конфигурация 2U 2620v3/16x32GB/**24xNVMe16T**/2x25Gb/s\n- Суммарный RPS API 380 тыс. (табл)\n- **БД**\n\t- Размещение - bare-metal \n\t- Суммарный размер хранения 11 Пб (табл)\n\t- (11 * 1024) / (24 * 16) = 30 серверов\n \t- min количество реплик 2 (master, slave, slave) = 90 серверов \n\t- Конфигурация 2U 2620v3/16x32GB/**24xNVMe16T**/2x25Gb/s\n- **Сервисы** - k8s\n\t- 100 RPS / CPU (табл)\n\t- Виртуальная сеть 100 RPS / 2 = 50 RPS\n\t- 380 000 RPS / 50 RPS = 7600 CPU / 64 = 120 серверов\n\t- Конфигурация 1U **2x6338/16x128GB**/2xNVMe8T/2x40Gb/s\n- **Balancers, API Gateway** \n\t- Размещение - виртуальные машины\n\t- 500 RPS / CPU (табл)\n\t- 380 000 / 500 = 750 / 64 = 12 сервера\n\t- Конфигурация 1U **2x6338/16x128GB**/2xNVMe8T/**2x40Gb/s**\n- 3100 U / 48 U/Rack = 65 стоек (4 ряда в машинном зале)\n- 3 AZ: 3100 U * 3 = 9300 U (резервирование N + 2 по ДЦ)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmmikhail2001%2Fhighload_youtube","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmmikhail2001%2Fhighload_youtube","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmmikhail2001%2Fhighload_youtube/lists"}