Платформа потоковой передачи событий как единый источник достоверной информации для распределенных платформ

Разные сценарии использования требуют разных решений

Это утверждение может показаться очевидным, однако не все продукты следует этому простому правилу.

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

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

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

Компромисс: согласованность и доступность

Есть довольно занимательная теорема CAP, разработанная Эриком Брюэром:

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

Допуск раздела

Система, устойчивая к разделам, может выдержать любое количество сетевых сбоев, которые не приведут к отказу всей сети - потере соединения между несколькими узлами системы или даже стойками. В этом случае блоки данных по-прежнему извлекаются (если они присутствуют на доступном узле (ах), это сильно зависит от свойства согласованности), сохраняются и реплицируются на доступных узлах.

Допуск на разделение - это данность, когда речь идет о распределенных системах. Следовательно, мы ставим под угрозу только согласованность и доступность данных.

Согласованность данных

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

Доступность

Системы с гарантиями высокой доступности сосредоточены на обеспечении базовых операций чтения / записи, гарантируя, что все доступные узлы смогут обрабатывать такой запрос, независимо от того, сколько компонентов не обслуживает, если хотя бы один узел «жив».

Между тем, гарантии согласованности не соблюдаются - компромисс (низкая) возможная согласованность.

Это может произойти или быть сделано специально по нескольким причинам:

  • Повышение производительности для систем с интенсивной записью, где согласованность не так важна (например, Cassandra).
  • Добавления не могут быть постоянными после разрешения конфликтов
  • Чтения могут не получить последнюю запись из-за сбоя узла (ов)

С другой стороны, не нужно беспокоиться о потере данных в таких системах - все записи со временем будут доступны.

Поток данных в постоянной среде Polyglot

Теорема CAP научила нас, что обработка данных в распределенной среде никогда не была легкой задачей. Еще больше происходит, когда группе инженеров необходимо поддерживать разнообразие контента на нескольких платформах хранения одновременно - Постоянная среда Polyglot.

С первого взгляда на мою страницу в Твиттере мы можем увидеть различные типы динамического контента, который хранится, обслуживается, кэшируется и анализируется: сообщения, изображения, некоторая информация, которая мне может понравиться и т. Д. Согласно официальному сообщению в блоге «Инфраструктура Twitter: масштабирование », неудивительно, что разные данные обрабатываются по-разному, чтобы удовлетворить бизнес-сценарии и гарантировать ожидаемое поведение.

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

Например, Apache HBase используется многими продуктами в качестве надежного уровня хранения данных с высокими характеристиками производительности записи, но невероятно низкой скоростью сканирования. ElasticSearch - может улучшить низкую производительность сканирования, в этом случае HBase по-прежнему используется в качестве первичной базы данных, даже если данные для поиска также будут передаваться в ElasticSearch. Это может привести к другому побочному эффекту - задержке индекса в одну секунду или около того с неэффективностью обработки запросов отдельных документов. При необходимости это поведение можно решить, добавив кеш Redis, или аналогичное решение, которое будет хранить недавно сохраненные данные внутри кеша, чтобы оптимизировать производительность магазина в ElasticSearch с помощью массовых загрузок, которые потенциально могут также временная задержка индекса обхода. И так далее.

Однако для этого потребуется строительство нетривиального трубопровода. Учитывая, что один запрос хранилища должен сохраняться на всех перечисленных уровнях хранилища независимо от технологии и ее поведения:

Попытка обеспечить высокую согласованность путем последовательного сохранения одного документа на каждом уровне хранения приведет к снижению времени отклика. Введение параллельного подхода к этому потоку технически решает проблему со временем отклика, хотя такой подход тоже далеко не лучший. Вероятность отказа запроса увеличивается при наличии нескольких уровней хранения данных, что серьезно влияет на гарантию доступности системы. По сути, мы сталкиваемся с рационализмом теоремы «CAP».

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

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

Следовательно, постоянная архитектура Polyglot в сочетании со стандартными механизмами обработки запросов ухудшает не только гарантии согласованности и доступности из теоремы «CAP», но и общие характеристики системы, такие как время отклика, и может привести к возможной потере данных.

Наименее требовательный аспект, связанный с данными подходами, однако, далеко не последний по приоритету - обслуживание архитектуры. Из-за количества зависимостей между несколькими уровнями данных в архитектуре Polyglot Persistent любое обслуживание кода может превратиться в кошмар.

Пришло время изменить ситуацию.

Внутри лог-ориентированной архитектуры

Попробуйте представить бесконечный поток данных в начальной точке с индексом 0… И «вуаля» - вы получите высокоуровневое представление Monolog в архитектуре на основе журналов. Такой журнал является только добавляемой, упорядоченной по времени последовательностью входящих записей.

Чтобы быть эффективным в реальном времени, распределенной и высокодоступной среде, журнал должен удовлетворять следующим критериям:

  • Распределенный. Помимо распространения базового компонента, он также включает такие характеристики, как репликация, что предотвращает недоступность записей во время простоя узлов, а также позволяет масштабировать журнал. -выходная особенность. Масштабирование - ключевой аспект для всех распределенных платформ, поскольку он помогает настроить производительность служб приложений в зависимости от нагрузки в определенный момент времени, увеличивая или уменьшая количество их запусков. задания. В противном случае журнал может стать узким местом для производительности и надежности любой прикладной системы.
  • Прозрачный. Мне нравятся алгоритмы и различные типы оптимизации, но не в случае с компонентом журнала в архитектуре на основе журнала. Такой компонент должен быть настолько простым и быстрым, чтобы выполнять только 2 действия: «добавить» и «получить последнее незафиксированное», остальные действия с точки зрения производительности не являются важный. Более того, сосредоточение внимания на любых типах оптимизаций, не связанных с этими двумя действиями, скрывает основные обязанности журнала и цель существования - простейшую возможную абстракцию хранилища. Итак, оставьте это другим слоям.
  • Регулируемый. Приведены критерии, связанные с получением контроля над характеристиками «CAP» журнала, например. Журнал не может быть на 100% строгим в отношении атрибутов согласованности данных или доступности, кроме того, он должен быть регулируемым в отношении коэффициента репликации и других связанных настроек . Строго в зависимости только от той или иной гарантии согласованности или доступность - Журнал становится узким местом для всей прикладной системы.

Запись с упреждающей записью (WAL) - один из ключевых механизмов предотвращения повреждения данных в системах баз данных, таких как HBase и PostgreSQL, разделяет общий принцип с подходом на основе журнала - добавление всех событий изменения состояния в файл журнала. Однако между этими двумя подходами есть существенная разница - файлы WAL сжимаются, достигая определенного размера или события, в то время, архитектура входа в систему на основе журнала, предназначенная для постоянного накопления записей и воспроизведения журнала в любой момент времени. .

Тот факт, что Log может хранить все исторические данные, - еще одна головокружительная тема.

Помимо аспекта сбоя, записи журнала могут быть воспроизведены всякий раз, когда приходит время интегрировать новый уровень хранения данных, что, в свою очередь, сокращает усилия по разработке, обслуживанию и исследованиям (например, поиск наиболее подходящей технологии) при общей гибкости, поскольку это действие может быть выполняется без чрезмерной нагрузки на платформу.

Apache Kafka как компонент журнала

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

Технически говоря, Kafka по-прежнему служит своей самой примитивной цели, являясь брокером сообщений, таким как Apache ActiveMQ и другие реализации JMS API, именно отсюда приходит запрос: «Kafka vs. JMS», однако , Apache Kafka - это нечто большее, что-то более подходящее для выполнения роли компонента журнала из-за ряда дополнительных функций, таких как:

  • Обработка в реальном времени с помощью Kafka Streams.
  • Это распределенный и высокодоступный компонент, но все же позволяет регулировать соотношение доступности / согласованности со свойствами replication-factor, min.insync.replicas и acks.
  • Может хранить петабайты (!!!) сообщений (записей) неограниченно долго непосредственно в файловой системе.

В целом, он идеально подходит для компонента журнала по заданным критериям.

Монолог против монолога с уплотнением против полилога

Разделение - это ключ к производительности, отказоустойчивости, масштабируемости и гибкости Kafka. Каждый раздел в Apache Kafka полностью независим и упорядочен по временной последовательности сообщений, поэтому, чтобы гарантировать порядок записи записей для одного компонента журнала, конфигурация должна выглядеть так:

1 тема + 1 раздел = монолог

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

В таком сценарии может возникнуть логичный вопрос о необходимости хранения исторических данных. Политику сохранения журналов можно включить соответственно без каких-либо изменений в структуре Monolog - «1 тема + 1 раздел», что может быть вполне допустимым подходом в случае отказа от функции постоянного воспроизведения журнала - Монолог с уплотнением.

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

(1 тема + 1 раздел) * N = Полилог

Не существует прямого правила, по которому Monolog можно разделить на структуру Polylog, все критерии подходят, если они дают приличное распространение.

Применение журнала

Урок выучен. Как синхронная, так и асинхронная параллельная запись в любой системе, особенно в среде Polyglot Persistent, приводит к огромным проблемам со временем отклика или таким бедствиям, как постоянная десинхронизация данных и другие. Чтобы решить все эти проблемы, следует избегать подхода параллельной записи, вместо этого компонент журнала будет выполнять роль первичного источника данных и, что более важно, также будет служить единый источник правды для остальных компонентов приложения и уровней данных.

Что с гарантиями согласованности / доступности для компонента журнала? Здесь нет проблем: компонент журнала, то есть кластер Apache Kafka, можно эффективно настроить, чтобы обеспечить приличную доступность без потери данных или нарушения целостности. Пример такой конфигурации: 3 узла брокера, RF 3 и ISR 2 с подтверждениями, установленными для всех - подробное руководство можно найти здесь.

Что с достаточно высокой доступностью на уровне приложения? С одной из самых низких возможных задержек ~ 1 мс (в конце концов, мы все еще имеем дело с асинхронными сообщениями и репликацией) , Записи журнала будут обрабатываться полностью независимыми потребителями (несколькими группами потребителей), которые, в свою очередь, будут передавать данные на другие уровни. Таким образом, всякий раз, когда происходит полный отказ одного или нескольких уровней данных, он не спровоцирует отказ всей системы.

Что с высокоинтенсивными операциями удаления и обновления? Сильная сторона архитектуры на основе журналов заключается в высокоинтенсивных операциях чтения и записи. Из-за желания удовлетворить также высокоинтенсивные операции удаления / обновления, шаблон CDC (Change Data Capture), или аналогичный, должен быть применен соответственно к журналу.

Быстро… Заключение

Архитектура на основе журналов с Apache Kafka, как один из лучших представителей систем, которые были разработаны с учетом слова «журнал», как правило, решает проблемы, связанные с обширными зависимостями компонентов, временем отклика и потерей данных в среде Polyglot Persistent. высокоинтенсивные операции чтения / записи.

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

С другой стороны, архитектура на основе журнала не является лекарством от всех проблем, поскольку компонент журнала не может эффективно работать с высокоинтенсивными операциями удаления / обновления из-за своей природы, что также хорошо для большинства случаев. Тем не менее, отдельный механизм CDC может быть применен поверх журнала соответственно.

Экспериментируйте и делитесь своими мыслями!

Дальнейшее чтение