Архитектура гигантов: стек данных в Facebook, Netflix, Airbnb и Pinterest

Главный Data Scientist компании Keen IO Мишель Ветцлер рассказала о том, как устроены системы хранения и обработки данных компаний, которые ежедневно обрабатывают миллиарды запросов от пользователей.

В Keen IO мы верим, что компании, которые учатся использовать данные о событиях, имеют существенное преимущество. Это точно относится и к лидирующим мировым технологическим компаниям. Команды по работе с данными компаний Facebook, Amazon, Airbnb, Pinterest и Netflix продолжают нас удивлять. Их работа задает новые стандарты в том, что могут знать программы и компании.

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

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

Netflix

C 93 миллионами ежемесячно активных пользователей, у Netflix нет недостатка во данных для обработки. Как команда Netflix описывает в своем тексте о «Развитии конвейера данных Netflix», они собирают около 500 миллиардов событий каждый день, что составляет 1.3 ПБ данных. В пиковые часы они записывают 8 миллионов событий в секунду. Более 100 человек работает в компании в качестве инженеров по данным или аналитиков.

Вот упрощенный вид их структуры данных из вышеупомянутого поста, показывающий Apache Kafka, Elastic Search, AWS S3, Apache Spark, Apache Hadoop и EMR как основные компоненты.

Facebook

Более миллиарда активных пользователей делают Facebook одним из самых больших хранилищ данных в мире, содержащим более 300 петабайт. Эти данные используются самыми разными способами — от традиционной пакетной обработки до аналитики графов, машинного обучения и интерактивной аналитики в реальном времени.

Для масштабирования интерактивного выполнения запросов инженеры Facebook изобрели Presto, уникальный распределенный движок SQL-запросов, оптимизированный для анализа по запросу. Он используется тысячами сотрудников, которые ежедневно выполняют более 30,000 запросов при помощи множества подключаемых бэкенд-хранилищ данных, таких как Hive, HBase и Scribe.

Airbnb

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

На прошлогоднем митапе «Создание аналитической команды высшего класса» Елена Гревал, менеджер в области науки о данных в Airbnb, упомянула, что компания уже расширила команду по работе с данными до 30+ инженеров. Это прибавляет к годовым затратам на сотрудников более 5 миллионов долларов.

В отличном посте в блоге «Инфраструктура данных в Airbnb» инженеры Джеймс Мейфилд, Кришна Путтасвоми, Сваруп Джагадиш и Кевин Лонг описали компоненты, входящие в состав их стека и то, как они обеспечивают высокий уровень надежности критически важных данных. В основном они полагаются на Hive и Apache Spark, а также Facebook Presto.

Pinterest

Pinterest обеспечивает 100 миллионам ежемесячно активных пользователей более 10 миллиардов просмотров страниц каждый месяц. В 2015 они расширили команду по работе с данными до более чем 250 инженеров. Их инфраструктура в основном полагается на Apache Kafka, Storm, Hadoop, HBase и Redshift.

Не только команде Pinterest надо отслеживать огромное количество данных пользователей. Как и любой социальной платформе, им нужно предоставлять детальные отчеты рекламодателям. Тонгбо Хуанг написал пост «Что стоит за пинами: создание аналитики в Pinterest» о их работе по реконструкции системы аналитики под свои нужды. Вот как они использовали Apache Kafka, AWS S3 и HBase для этого:

Twitter/Crashlytics

В «Управлении 5 миллиардами сессий в день в реальном времени» Эд Соловей описывает архитектуру, созданную командой Crashlytics Answers для управления миллиардами мобильных событий в день.

Прием событий

Архивирование

Пакетная обработка

Вычисления

Общий вид

Архитектура данных в Keen IO

Как я упоминала ранее, мы создали API Keen, чтобы каждый разработчик мог использовать высококачественную архитектуру без необходимости в огромной команде и инфраструктуре. Тысячи команд инженеров используют API Keen для записи, анализа, передачи и встраивания данных о событиях в свой бизнес через систему пакетной обработки в реальном времени.

Хотя типичный разработчик, использующий Keen, никогда не узнает, что происходит за кулисами, когда он отправляет событие или запрос, вот как выглядит архитектура, которая обрабатывает полученные данные:

Со стороны приема системы балансировки нагрузки управляют миллиардами входящих post-запросов, в то время как события поступают из приложений, веб-сайтов, подключенных устройств, серверов, систем биллинга и т. д. События оцениваются, выстраиваются в иерархию и опционально дополняются метаданными, например, IP и геоданными. Это происходит за считанные секунды.

Надежно сохраненные в Apache Cassandra данные о событиях доступны для запросов через REST API. Наша архитектура (при помощи технологий Apache Storm, DynamoDB, Redis и AWS lambda) поддерживают разнообразные запросы от исследования входящих данных в реальном времени до кешированных запросов, которые могут быть моментально загружены в приложения и клиенто-ориентированные отчеты. Keen обрабатывает триллионы событий каждый день и обслуживает тысячи отчетов, автоматизаций и дата-интерфейсов клиентов.