Оригинал тут: RAW Hollow – революция в управлении данными от Netflix

Пояснения для тех, кто не знаком с темой

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

Традиционные методы хранения данных (базы данных) бывают медленными, когда нужно получать данные очень-очень быстро, или сложными, когда их очень много и они постоянно меняются. Например, когда вы заходите посмотреть что-то, Netflix должен мгновенно понять, что вам показать на основе ваших предпочтений и доступного контента. Обычные базы данных могут не справляться с такой скоростью и объемом запросов.

• Распределенные системы: Это означает, что Netflix не использует один огромный компьютер. Вместо этого у них тысячи маленьких компьютеров (серверов), расположенных в разных точках мира, которые работают вместе, чтобы обеспечить бесперебойный сервис.
• In-Memory: “В памяти” означает, что данные хранятся прямо в оперативной памяти сервера (как в вашем компьютере, когда вы запускаете программы), а не на медленном жестком диске. Это делает доступ к данным невероятно быстрым.
• Co-Located: “Совместно размещенный” означает, что данные хранятся на том же самом сервере, где работает программа, которой эти данные нужны. Не нужно отправлять запрос по сети на другой сервер, чтобы получить данные, что экономит время.
• Object Store: Это не традиционная реляционная база данных с таблицами. Вместо этого данные хранятся как объекты (подобно файлам или записям), что более гибко.
• Hollow (оригинальный): Это была технология Netflix для очень быстрого чтения данных. Она позволяла хранить целые каталоги данных в памяти для моментального доступа, но не позволяла изменять эти данные. Представьте, что это очень быстрая, но только для чтения, копия огромной книги.
• RAW Hollow (Read After Write Hollow): Это развитие Hollow. Теперь можно не только читать, но и записывать данные, сохраняя при этом молниеносную скорость. Добавлена возможность изменять “книгу”, причем изменения мгновенно становятся видны другим, а система гарантирует, что данные не потеряются.
• CAP Theorem: Это фундаментальная концепция в распределенных системах. Она утверждает, что из трех свойств – согласованность (Consistency), доступность (Availability), устойчивость к разделению (Partition tolerance) – можно одновременно гарантировать только два. Netflix же, благодаря RAW Hollow, предлагает гибкость в выборе: можно работать в режиме максимальной доступности (AP), где данные становятся согласованными со временем, или в режиме максимальной согласованности (CP), где данные всегда актуальны, но могут быть короткие задержки.

Важное в статье

1. Проблема, которую решает RAW Hollow: Традиционные базы данных страдают от непредсказуемой производительности, сложности синхронизации кэшей и накладных расходов сети. RAW Hollow решает эти проблемы, предоставляя сверхбыстрый доступ к данным (микросекунды для чтения) за счет их хранения в памяти непосредственно в приложении.

2. Эволюция от Hollow: RAW Hollow является развитием уже зарекомендовавшей себя технологии Hollow, которая использовалась Netflix более 10 лет как кеш *только для чтения*. Новая версия добавляет возможность записи и гарантии атомарности и согласованности.

3. Архитектура RAW Hollow:
   • Writers (Записывающие): Точка входа для всех операций записи. Используют Zookeeper для выбора лидера и синхронную репликацию для обеспечения долговечности данных. Способны обрабатывать до 1000 записей в секунду с нагрузкой 10 КБ.
   • Logkeepers (Хранители логов): Простая, но надежная инфраструктура для долговечности. В памяти хранят циклический лог, обеспечивая быструю фиксацию записей. Высокая отказоустойчивость за счет развертывания в нескольких зонах доступности AWS.
   • Producers (Производители): Синхронизируют данные из Logkeepers и распространяют их через внутренний паб/саб сервис Netflix (Gutenberg) на Writers и Local Clients. Создают снимки данных каждые 30 секунд для долгосрочного хранения в S3, что обеспечивает надежность на уровне “11 девяток”.
   • Local Clients (Локальные клиенты): Самая уникальная особенность. Каждое приложение-клиент поддерживает полную, материализованную копию всего набора данных в своей памяти. Это позволяет осуществлять операции чтения без сетевых задержек (микросекунды). Получают обновления в реальном времени от Logkeepers.

4. Свойства ACID и согласованность:
   • Атомарность: Гарантируется через API Bulk Update, где все операции в транзакции либо выполняются полностью, либо не выполняются вовсе.
   • Согласованность: Поддерживается за счет всесторонней валидации схемы. API Conditional Bulk Update позволяет применять предварительные условия для предотвращения состояний гонки.
   • Изоляция: Реализован уровень Read Committed, предотвращающий “грязные” чтения.
   • Долговечность: Обеспечивается синхронной репликацией на Logkeepers и регулярными снимками в S3.

5. Гибкость модели согласованности (CAP Theorem):
   • Eventually Consistent (AP-система по умолчанию): Приоритет доступности и отказоустойчивости. Чтения мгновенны, обновления распространяются быстро, но временные несоответствия могут быть (идеально для рекомендаций).
   • Strong Consistency (CP-система по запросу): Позволяет запрашивать сильную согласованность для отдельных операций. Клиент временно синхронизируется с последними изменениями. Это позволяет достичь баланса между производительностью и точностью данных для критически важных операций (например, финансовые транзакции).

6. Производительность и масштабируемость:
   • Чтение: Микросекунды, так как данные “co-located”.
   • Запись: До 1000 записей/сек (10 КБ полезной нагрузки), задержка распространения обновлений — миллисекунды.
   • Масштаб данных: До 100 миллионов записей на сущность, благодаря эффективному сжатию.

7. Применение в реальном мире: RAW Hollow уже активно используется в более чем 160 критически важных сервисах Netflix (Tier-0), включая:
   • Управление метаданными видео (каталоги контента).
   • Системы рекомендаций и персонализации.
   • Управление сетевой инфраструктурой CDN (Open Connect).
   • Управление идентификацией и доступом (OneID).
   • Потенциал для игр, финансовых услуг (рыночные данные, борьба с мошенничеством), электронной коммерции.

8. Операционная готовность: Наличие инструментов мониторинга, отслеживания изменений, возможность “нулевого копирования” для окружений и быстрого отката версий.

---

Вывод ИИ

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

---

Шаги по применению (для внедрения аналогичного подхода)

Внедрение системы, подобной RAW Hollow, требует глубокой экспертизы в распределенных системах и серьезных инженерных ресурсов. Вот шаги, которые должны предпринять компании, сталкивающиеся с аналогичными проблемами:

1. Анализ требований и выявление “боли”:
   • Определите, какие ваши сервисы страдают от высокой задержки чтения, непредсказуемой производительности баз данных или сложностей с синхронизацией кэшей.
   • Оцените, укладываются ли ваши наборы данных в категории “малые” или “средние” (помещаются ли в оперативную память). Слишком большие dataset’ы не подходят для RAW Hollow-подобных решений.

2. Исследование существующих решений:
   • Прежде чем разрабатывать что-то свое, изучите готовые ин-мемори базы данных (Redis, Apache Ignite, GemFire/Pivotal CloudFoundry Data Services) и распределенные кэши. Hollow/RAW Hollow — это более низкоуровневое и кастомизированное решение.
   • Оцените возможность использования Apache Kafka или подобных систем для потоковой обработки изменений, как это делает Netflix.

3. Проектирование архитектуры:
   • Модель данных: Разработайте оптимальную схему данных, которая будет эффективно храниться в памяти и обеспечивать быстрый доступ. Учитывайте возможности сжатия и индексирования.
   • Модель согласованности: Для каждого компонента или операции четко определите требуемый уровень согласованности (сильная или конечная). Это критический шаг.
   • Компоненты: Определите необходимые компоненты, аналогичные Writers, Logkeepers, Producers и Local Clients.
     • Writers: Как будут приниматься и обрабатываться запросы на запись? Нужен ли механизм выбора лидера?
     • Durability Layer: Как будет обеспечиваться долговечность данных? Локальные логи? Репликация? Архивация в S3-подобные хранилища?
     • Change Propagation: Как изменения будут распространяться между узлами и клиентами? Нужен эффективный механизм паб/саб.
     • Local Data Stores: Как данные будут храниться в памяти клиентов/сервисов? Как будут обновляться?
   • Отказоустойчивость: Разработайте механизмы для обработки сбоев отдельных компонентов (например, падение Writer, Logkeeper), восстановления после сбоев и обеспечения непрерывной работы.

4. Выбор технологий и инструментов:
   • Для координации: Zookeeper или Consul для выбора лидера и управления распределенным состоянием.
   • Для потоковой обработки/паб/саб: Kafka, Pulsar или Kinesis.
   • Для хранения снимков: S3-совместимые хранилища.
   • Для in-memory хранения: Возможно, придется использовать кастомные структуры данных или библиотеки для работы с памятью в выбранном языке программирования (например, Java ByteBuffer для эффективного управления памятью).

5. Разработка и реализация PoC (Proof of Concept):
   • Начните с небольшой, изолированной PoC, чтобы проверить ключевые концепции: co-located storage, запись, распространение изменений, согласованность.
   • Измерьте производительность и задержку на ранних этапах.

6. Тестирование и оптимизация:
   • Нагрузочное тестирование: Проверьте систему под высокой нагрузкой чтения и записи.
   • Chaos Engineering: Внедряйте контролируемые сбои (как Netflix с Chaos Monkey), чтобы убедиться в устойчивости системы.
   • Мониторинг: Встройте комплексные системы мониторинга и логирования для отслеживания состояния, производительности и проблемных мест во всех компонентах.

7. Развертывание и эксплуатация:
   • Постепенное развертывание в производственной среде, начиная с менее критичных сервисов.
   • Обеспечение операционных процедур: обновление, резервное копирование, восстановление, масштабирование.

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