Open-source управление данными: паттерны и основные практики
Архитектуры данных с открытым исходным кодом открывают перед современными организациями практически неограниченные возможности в области управления данными, начиная с устранения привязки к одному поставщику и повышения экономической эффективности и заканчивая грандиозной масштабируемостью, высокой доступностью и гибкостью. В этом руководстве Вы узнаете об основных методах построения стека архитектуры данных с открытым исходным кодом, а также о шаблонах проектирования компонентов инфраструктуры, безопасности данных и о многом другом.
Введение
Технологии с открытым исходным кодом составляют основу масштабируемых, безопасных и экономически эффективных решений для работы с данными. Они предлагают множество вариантов, от распределенных баз данных до систем обмена сообщениями и аналитических движков. Современные архитектуры данных часто используют сразу несколько технологий, что позволяет использовать их уникальные преимущества и возможности по максимуму. В этой статье мы рассмотрим ключевые технологии работы с данными с открытым исходным кодом, а основные методы построения архитектур данных, включая требования к инфраструктуре, стратегии обеспечения высокой доступности, методы оптимизации и многое другое. Особое внимание мы уделим PostgreSQL, Apache Cassandra и Apache Kafka, благодаря чему Вы сможете получить подробное представление о каждом из этих продуктов.
Open-source технологии работы с данными
Внедрение архитектур данных с открытым исходным кодом дает организациям значительные преимущества, включая повышение экономической эффективности за счет отказа от лицензионных платежей, гибкость в настройке и снижение привязки к поставщикам. Такие решения пользуются поддержкой различных сообществ, что способствует быстрому внедрению инноваций, их постоянному совершенствованию и регулярному пересмотру системы безопасности.
Решения с открытым исходным кодом облегчают интеграцию с другими системами, способствуют обмену знаниями в сообществе разработчиков и позволяют организациям вносить свой вклад в экосистему, влияя на направления будущего развития в области работы с данными. Ключевые категории экосистемы данных с открытым исходным кодом включают в себя реляционные и NoSQL-базы данных, распределенные системы обмена сообщениями, фреймворки для обработки больших данных, а также средства оркестрации данных и управления рабочими процессами.
С помощью заранее определенных схем реляционные базы данных отлично справляются с задачей управления структурированными данными и обеспечивают ограничения целостности данных. Они идеально подходят для приложений, требующих высокой согласованности и сложных взаимосвязей данных. Наиболее популярными вариантами являются PostgreSQL и MySQL.
Базы данных NoSQL - это нереляционные системы, предназначенные для работы со специфическими моделями данных, включая форматы ключ-значение, документ, семейство столбцов и графы. В них приоритет отдается масштабируемости и гибкости, а не строгой согласованности. Например, Apache Cassandra, хранилище семейства колонок, отлично справляется с большими нагрузками на запись и обеспечивает линейную масштабируемость на нескольких узлах.
Распределенные системы обмена сообщениями обеспечивают потоковую передачу данных в режиме реального времени и архитектуру, ориентированную на события. Они отделяют производителей данных от потребителей, обеспечивая масштабируемое и отказоустойчивое распределение сообщений между распределенными системами. Например, Apache Kafka обеспечивает высокую пропускную способность и постоянное хранение потоков данных, что делает ее незаменимой при создании крупномасштабных конвейеров данных и аналитических приложений, работающих в режиме реального времени.
Фреймворки для обработки больших данных предназначены для обработки и анализа огромных массивов данных в распределенных вычислительных средах. Они предлагают масштабируемые возможности параллельной обработки, с которыми не могут сравниться традиционные инструменты обработки данных. Например, Apache Spark, представляет собой единый механизм анализа данных, поддерживающий возможности пакетной и потоковой обработки, машинного обучения и вычисления графов на одном и том же распределенном наборе данных.
Средства оркестрации данных и управления рабочими процессами помогают автоматизировать и управлять сложными конвейерами обработки данных в различных системах. Они координируют задачи, справляются с зависимостями и обеспечивают бесперебойную передачу данных между различными компонентами экосистемы данных. Например, Apache Airflow, позволяет пользователям создавать, планировать и контролировать рабочие процессы, облегчая управление процессами ETL (извлечение-трансформация-загрузка) и приложениями, подразумевающими интенсивное использование данных.
Популярные open-source инструменты работы с данными
Прежде чем перейти к рассмотрению основных методов построения архитектур данных, давайте сделаем краткий обзор PostgreSQL, Apache Kafka и Apache Cassandra.
PostgreSQL - это реляционная база данных, известная своей надежностью, масштабируемостью и строгим соответствием международным стандартам по работе с данными.
- поддерживает широкий спектр функций, включая сложные запросы, внешние ключи, триггеры, обновляемые представления и транзакционную целостность.
- архитектура данной БД обеспечивает высокий уровень параллелизма благодаря реализации многоверсионного контроля параллелизма (MVCC), который позволяет читателям и писателям работать одновременно без блокировки друг друга.
Благодаря тому, что в PostgreSQL большое внимание уделяется целостности данных и способности эффективно обрабатывать большие объемы данных, она является незаменимым компонентом корпоративных приложений, геопространственных систем и сложных рабочих нагрузок по анализу данных.
Apache Cassandra - это масштабируемая, высокопроизводительная распределенная NoSQL база данных, предназначенная для обработки больших объемов данных.
- обеспечивает высокую доступность без единой точки отказа и поддерживает кластеры, охватывающие сразу несколько центров обработки данных.
- архитектура основана на кольцевой конструкции и использует последовательное хэширование для распределения данных, что обеспечивает линейную масштабируемость и отказоустойчивость.
- предлагает настраиваемые уровни согласованности и репликацию данных.
Модель данных Cassandra основана на широких хранилищах столбцов, что делает ее идеальным вариантом для работы с данными временных рядов, данными датчиков и другими сценариями, требующими быстрой записи и чтения больших массивов данных.
Apache Kafka - это распределенная платформа потоковой передачи событий, предназначенная для высокопроизводительных, отказоустойчивых и масштабируемых конвейеров данных.
- использует модель публикации-подписки, где данные организованы в темы, которые могут быть разделены между несколькими серверами для параллельной обработки.
- Архитектура включает продюсеров, которые записывают данные в темы, консюмеров, которые читают их из тем, и брокеров, которые хранят и обслуживают данные.
- В ней ведется упорядоченный журнал событий, что позволяет воспроизводить и перерабатывать потоки данных.
- Среди ключевых особенностей - доставка сообщений с низкой задержкой, сохранение данных, потоковая обработка и строгие гарантии упорядочивания и доставки сообщений.
Благодаря способности обрабатывать миллионы сообщений в секунду Kafka широко используется для создания приложений потоковой передачи данных в режиме реального времени, агрегации журналов и сбора метрик, а также в качестве основы архитектур микросервисов.
Open-source управление данными: паттерны и основные практики
Давайте рассмотрим некоторые ключевые модели и практики развертывания и управления решениями для работы с данными с открытым исходным кодом.
Масштабируемость и высокая доступность
Масштабируемость и высокая доступность - важнейшие аспекты современных архитектур данных. По мере роста систем и увеличения спроса способность эффективно масштабироваться и поддерживать бесперебойное обслуживание становится решающим фактором.
PostgreSQL предлагает как вертикальное, так и горизонтальное масштабирование. Вертикальное масштабирование предполагает модернизацию аппаратных ресурсов, а горизонтальное масштабирование может быть достигнуто за счет реплик чтения, разбиения на разделы и шардинга. Высокая доступность поддерживается за счет встроенной потоковой репликации, которая поддерживает резервные серверы для обхода отказов, и логической репликации для более детального контроля над репликацией определенных таблиц или баз данных.
Ключевая практика: для повышения производительности и доступности данных используйте балансировку нагрузки.
Для распределения запросов между несколькими экземплярами PostgreSQL можно использовать такие инструменты балансировки нагрузки, как HAProxy.
Настройка высокой доступности PostgreSQL обычно включает в себя следующее:
- Основной сервер для записи
- Несколько реплик для чтения для масштабирования операций чтения
- Потоковая репликация для синхронизации данных практически в режиме реального времени
- Механизм обхода отказа (например, Patroni) для перевода резервного сервера в основной в случае сбоя
- Пул соединений и балансировка нагрузки для эффективного управления клиентскими соединениями
Такая конфигурация обеспечивает масштабируемость при чтении и высокой доступности: основной сервер обрабатывает записи, а реплики для чтения обслуживают запросы на чтение и обеспечивают возможность обхода отказа.
Горизонтальная масштабируемость Kafka достигается в первую очередь за счет разделения тем, что позволяет распределять обработку данных между несколькими брокерами в кластере. Такая архитектура позволяет Kafka работать с большими объемами данных, а также добавлять брокеров по мере необходимости. Высокая доступность обеспечивается за счет репликации, причем каждый раздел обычно имеет несколько реплик на разных брокерах.
Основные практики:
- Обеспечьте избыточность и отказоустойчивость, используя коэффициент репликации три для производственных сред.
- Повысьте отказоустойчивость и обеспечьте защиту от сбоев на уровне зоны путем развертывания кластеров Kafka в нескольких зонах доступности или центрах обработки данных
Типичное производственное развертывание Kafka может включать в себя кластер, состоящий изиз трех-пяти брокеров, распределенных по трем зонам доступности, с коэффициентом репликации три (или более) для критических тем. Такая конфигурация обеспечивает как масштабируемость за счет добавления дополнительных брокеров или разделов, так и высокую доступность за счет репликации и распределения по зонам.
Масштабируемость и высокая доступность в Cassandra достигаются за счет распределенной архитектуры, использующей последовательное хеширование для распределения данных по узлам. Виртуальные узлы (vnodes) улучшают балансировку нагрузки. Масштабируемость линейная: удвоение количества узлов обычно удваивает пропускную способность и объем хранения.
Ключевые практики:
- Поддерживайте географическую избыточность с помощью репликации в нескольких центрах обработки данных
- Обеспечьте компромисс между производительностью чтения/записи с помощью соответствующих уровней согласованности
Типичное развертывание Cassandra включает в себя несколько центров обработки данных, каждый из которых содержит не менее трех узлов (для обеспечения кворума). При правильной настройке такая система обеспечивает отличную масштабируемость, поскольку для увеличения емкости узлы можно добавлять в абсолютно любой центр обработки данных. Она также обеспечивает и высокую доступность, поскольку потеря одного узла или даже целого центра обработки данных никак не повлияет на общую работу.
Планирование пропускной способности
Эффективное планирование мощностей имеет решающее значение для обеспечения оптимальной производительности, масштабируемости и экономической эффективности технологий обработки данных с открытым исходным кодом. Оно включает в себя оценку требований к оборудованию и распределение ресурсов, необходимые для поддержки текущих и будущих рабочих нагрузок. Ниже приведены методы, связанные с процессором, памятью, сетью и хранилищем, которые следует учитывать при работе с PostgreSQL, Kafka и Cassandra:
|
Параметр |
POSTGRESQL |
APACHE KAFKA |
APACHE CASSANDRA |
|---|---|---|---|
|
CPU |
PostgreSQL выигрывает как от однопоточной производительности, так и от многоядерной:
|
CPU зависят от объема работы:
|
|
|
Память |
|
|
Выделите 16-32 ГБ оперативной памяти на узел (память также используется для кэширования, что повышает производительность чтения). |
|
Сеть |
|
|
Обеспечьте высокую пропускную способность и низкую скорость соединения между узлами, особенно в развертываниях с несколькими центрами обработки данных. |
|
Хранение |
|
|
|
Ваши требования могут меняться в зависимости от характеристик рабочей нагрузки, моделей данных и потребностей приложений. По мере развития Вашей системы будьте готовы к переоценке и корректировке распределения ресурсов. Такие инструменты с открытым исходным кодом, как Prometheus для мониторинга и Grafana для визуализации данных могут дать ценные сведения об использовании ресурсов и помочь в принятии решений по планированию мощностей.
Аварийное восстановление
Для аварийного восстановления следует использовать дополнительные возможности PostgreSQL. Обязательно проводите тесты процедур аварийного восстановления, включая восстановление из логических и физических резервных копий и восстановление по точкам во времени (PITR) для того, чтобы проверить целостность данных и ознакомить команду с процессами восстановления.
Ключевые практики:
- Включите непрерывное архивирование WAL и используйте такие инструменты, как pg_basebackup, pg_waldump и pg_receivewal (для создания полных резервных копий и восстановления до любого определенного момента, защищаясь от логических ошибок и повреждения данных.)
- Реализуйте как логическое (pg_dump), так и физическое (pg_basebackup) резервное копирование со стратегией ротации.
- Храните резервные копии за пределами сайта или в облачном хранилище, чтобы обезопасить себя от сбоев в масштабах сайта.
В архитектурах на базе Kafka для аварийного восстановления используется Kafka MirrorMaker 2.0 (MM2). Он использует фреймворк Kafka Connect для эффективной кросс-кластерной репликации. Архитектура MM2 включаетв себя MirrorSourceConnector (для репликации данных и метаданных) и MirrorCheckpointConnector (для синхронизации смещений групп потребителей). Такая конструкция позволяет сохранять структуры тем, разделов и смещения потребителей в разных кластерах, что способствует быстрому восстановлению работоспособности в аварийных ситуациях.
Для эффективного аварийного восстановления MM2 может реплицировать данные в удаленные места, поддерживая как активно-пассивные, так и активно-активные конфигурации для достижения конкретных целей по времени и точке восстановления. MM2 минимизирует потерю данных и время простоя в случае сбоя кластера или регионального отключения. Это гарантирует то, что в случае аварии Вы сможете быстро перенаправить трафик на вторичный сайт с минимальной потерей данных и изменением конфигурации.
Чтобы настроить MirrorMaker 2.0 для аварийного восстановления:
- Определите исходный кластер, настроив детали подключения для основного кластера Kafka
- Определите детали для целевого (резервного/вторичного) кластера Kafka
- Создайте потоки репликации, указав, какие темы должны быть реплицированы (используйте регулярные выражения для включения или исключения определенных тем)
- Настройте коэффициент репликации для зеркальных тем в целевом кластере
- Включите синхронизацию со смещением для поддержания согласованности между исходным и целевым кластерами
Пример MM2 конфигурации:
clusters:
primary:
bootstrap.servers: primary-kafka:9092
dr:
bootstrap.servers: dr-kafka:9092
mirrors:
primary->dr:
source: primary
target: dr
topics: ".*"
topics.exclude: "internal.*"
replication.factor: 3
sync.topic.acls.enabled: true
В приведенной выше конфигурации указаны два кластера: основной и dr (аварийное восстановление), каждый из которых имеет соответствующие загрузочные серверы. Раздел зеркал устанавливает поток репликации с первичного кластера на кластер dr. Он настроен на репликацию всех тем (.*), кроме тех, которые начинаются с internal (internal.*). Коэффициент репликации установлен на 3 для зеркальных тем в целевом кластере, что обеспечивает избыточность данных. Кроме того, конфигурация позволяет синхронизировать списки контроля доступа (ACL) между кластерами, поддерживая согласованный контроль доступа в основной среде и среде аварийного восстановления.
Распределенная архитектура Cassandra обеспечивает встроенную избыточность, при этом крайне важно учитывать меры по аварийному восстановлению, в том числе:
|
лучшие практики |
|
|---|---|
|
Снапшоты |
Используйте функцию моментальных снимков Cassandra для создания точечных резервных копий данных и выполните команду nodetool snapshot для создания согласованных снимков на всех узлах. Эти снимки можно использовать для полного или частичного восстановления данных. |
|
Инкреметальное резервное копирование |
Включите инкрементальное резервное копирование, установив значение incremental_backups: true в cassandra.yaml. Это создаст ссылки на новые SSTables, что позволит использовать более подробные варианты восстановления и снизит накладные расходы на хранение полных снимков. |
|
Коммит для архивирования |
Настройте архивирование журнала фиксации, установив commitlog_archiving_enabled: true в cassandra.yaml. Это позволит вам фиксировать все записи между моментальными снимками, что позволит использовать PITR. |
Безопасность
Механизмы аутентификации гарантируют, что получить доступ к Вашим системам данных могут только авторизованные пользователи или приложения. Защита периметра сосредоточена на шифровании передаваемых данных.
Ключевые практики:
- Обеспечьте безопасность с помощью обычных мер аутентификации (например, комбинации имя пользователя/пароль, RBAC) и рассмотрите расширенные методы аутентификации, такие как Kerberos
- Шифруйте данные при передаче с помощью SSL/TLS для предотвращения вторжений, таких как подслушивание и атаки «человек посередине».
Аутентификация в PostgreSQL управляется через файл pg_hba.conf, поддерживающий аутентификацию по паролю, LDAP и сертификату. RBAC позволяет осуществлять гранулярное управление правами доступа. Для шифрованных соединений PostgreSQL поддерживает SSL/TLS, который можно включить, настроив параметр ssl в файле postgresql.conf, указав пути к сертификатам и ключам и установив ssl=on. Клиенты могут устанавливать защищенные соединения, используя параметр sslmode=require в строке подключения.
Для аутентификации в Kafka реализовано решение Simple Authentication and Security Layer (SASL) с несколькими механизмами, включая PLAIN, SCRAM и Kerberos. ACL обеспечивают строгий контроль авторизации над темами и группами потребителей. Чтобы включить SSL/TLS в Kafka, необходимо создать хранилище ключей с закрытым ключом и сертификатом брокера и хранилище доверия с сертификатом центра сертификации. Настройте их в файле server.properties каждого брокера.
Пример конфигурации SSL в Kafka:
listeners=SSL://hostname:9093 ssl.keystore.location=/path/to/kafka.server.keystore.jks ssl.keystore.password=keystore-password ssl.key.password=key-password ssl.truststore.location=/path/to/kafka.server.truststore.jks ssl.truststore.password=truststore-password ssl.client.auth=required
Cassandra предоставляет несколько вариантов аутентификации и авторизации. По умолчанию используется аутентификатор AllowAllAuthenticator, который не выполняет никакой специальной аутентификации. Для производственных сред рекомендуется использовать PasswordAuthenticator или пользовательский аутентификатор. RBAC в Cassandra позволяет определять гранулярные разрешения для пользователей и ролей. Для SSL/TLS Cassandra использует файлы Java keystore. Вам нужно будет создать хранилище ключей для каждого узла и хранилище доверия для клиентов. Настройте их в файле cassandra.yaml. Если эта функция включена, клиенты должны подключаться с помощью SSL для связи с кластером.
Мониторинг
Основные показатели мониторинга для PostgreSQL включают производительность запросов, количество соединений, задержку репликации и рост размера базы данных.
Ключевые практики:
- Используйте представления pg_stat_* для получения исчерпывающей информации о деятельности базы данных, включая длительные запросы (pg_stat_activity) и использование индексов (pg_stat_user_indexes).
- Отслеживайте операции vacuum, особенно активность autovacuum и раздувание таблиц (для предотвращения проблем с производительностью).
- Отслеживайте частоту и продолжительность контрольных точек, чтобы избежать скачков операций ввода-вывода.
- Для управления соединениями отслеживайте активные и незадействованные соединения, а при использовании инструментов пула соединений, таких как PgBouncer, отслеживайте их специфические метрики для обеспечения оптимальной производительности.
JMX-метрики Kafka предоставляют подробную информацию о производительности кластера, включая подробную статистику по брокерам, темам и клиентским операциям. Ключевые JMX-метрики включают в себя статистику на уровне брокера, такую как количество запросов и загрузка сетевых процессоров, метрики на уровне темы, такие как количество байт в секунду, и метрики группы потребителей, такие как задержка и скорость фиксации смещения. Такие инструменты, как Prometheus и Grafana, могут эффективно собирать, визуализировать и оповещать об этих метриках, обеспечивая целостное представление о состоянии и производительности кластера Kafka.
Ключевые практики:
- Отслеживайте отставание потребителей, чтобы выявить слабые места процесса обработки данных.
- Отслеживайте активные контроллеры и их изменения для обеспечения стабильности кластера.
- Для продюсеров наблюдайте за размерами пакетов и коэффициентами сжатия.
- Для консюмеров отслеживайте частоту и размер запросов на выборку
Мониторинг Cassandra должен охватывать состояние узлов, взаимодействие кластера и производительность запросов, уделяя особое внимание таким ключевым показателям, как задержки при чтении/записи, скорость уплотнения и использование кучи. К числу важных областей, которые обязательно необходимо отслеживать, относятся сплетенная связь для обеспечения стабильности кластера, ожидающие уплотнения и количество SSTable на ключевое пространство, скорость восстановления чтения и передача с подсказками для обеспечения согласованности данных.
Ключевые практики:
- Внимательно следите за паузами в сборке мусора, чтобы предотвратить снижение производительности и нестабильность узлов.
- Используйте утилиту nodetool Cassandra, в частности команду tablestats, для получения подробной информации о состоянии кластера и производительности таблиц.
Настройка и оптимизация
PostgreSQL, Kafka и Cassandra предлагают уникальные варианты конфигурации для настройки и оптимизации производительности, основные методы приведены ниже:
|
Лучшие практики |
|
|---|---|
|
PostgreSQL |
|
|
Kafka |
|
|
Cassandra |
|
Заключение
В этой статье мы рассмотрели ключевые open-source технологии работы с данными, PostgreSQL, Apache Cassandra и Apache Kafka, а также поговорили об их архитектуре и основных методах управления. Мы рассмотрели основные модели построения масштабируемых и устойчивых инфраструктур данных, включая стратегии высокой доступности, планирование мощностей, аварийное восстановление, меры безопасности, подходы к мониторингу и методы оптимизации производительности. Используя эти решения с открытым исходным кодом и следуя лучшим практикам, организации смогут создавать мощные, гибкие и экономически эффективные архитектуры данных.
