Реализация более быстрой, удобной для разработчиков и более безопасной архитектуры Kappa.
С момента своего восхождения к господству в 80-х годах реляционные базы данных использовались в бизнес-приложениях для записи транзакций, хранения информации о бизнес-объектах (сущностях), а также для обработки и анализа исторических данных для обоснования бизнес-решений. В этом посте мы обсудим устоявшиеся шаблоны баз данных и то, как они преобразуются в новую потоковую архитектуру, которая приводит к более быстрому пониманию современных бизнес-приложений.
Операционные и аналитические рабочие нагрузки
Рабочие нагрузки базы данных обычно классифицируются как операционные или аналитические. Операционные рабочие нагрузки связаны с мгновенным сбором и обслуживанием данных. Например, запись транзакции или обновление профиля пользователя. Они, как правило, перегружены записью с шаблонами произвольного доступа. С другой стороны, аналитические рабочие нагрузки связаны с обработкой и агрегированием больших объемов исторических данных с целью ответа на специальные запросы. Например, финансовый аналитик может захотеть узнать «общий объем продаж компании за квартал за последние 3 года». Аналитические базы данных, как правило, требуют большого количества операций чтения и высокого уровня параллелизма.
Некоторые приложения могут делать все это в одной базе данных, обычно используя оптимизированные для записи (3NF) таблицы для операционных данных (транзакций и сущностей) и денормализованные таблицы — обычно по схеме снежинка или звезда — для аналитических данных. Данные будут поэтапно преобразовываться пакетами из операционных в аналитические таблицы с помощью сценария SQL, который можно вызывать извне или с помощью триггеров и хранимых процедур. Несколько баз данных поддерживают материализованные представления, что является удобной обобщенной реализацией этого метода.
По мере роста сложности и назначения приложений единая база данных перегружается объемом данных, которые необходимо хранить, обрабатывать и обслуживать. В какой-то момент мы достигаем физических пределов возможностей одной базы данных, поэтому операционные и аналитические рабочие нагрузки обычно разделяются и размещаются в нескольких базах данных.
Оперативные и аналитические рабочие нагрузки существенно различаются, и современные базы данных эволюционировали таким образом, что они оптимизированы для одного типа рабочей нагрузки. Операционные базы данных, как правило, ориентированы на строки с транзакционными гарантиями. Эти базы данных предназначены для корректности данных, надежности, параллелизма записи и шаблонов произвольного доступа. Аналитические базы данных, в свою очередь, имеют тенденцию быть ориентированными на столбцы и высокопараллельными. Они оптимизируются для одновременного сканирования диапазонов и агрегирования, которые обычно требуются для создания отчетов, информационных панелей и инструментов бизнес-аналитики.
Что такое шаблон ETL?
Чтобы преодолеть разрыв между оперативными и аналитическими базами данных, появился общий шаблон проектирования. Приложения будут хранить и извлекать данные о транзакциях и объектах, используя оперативную базу данных. Затем на периодической основе (обычно один раз в день) данные будут извлекаться, преобразовываться и загружаться (ETL) в хранилище данных для использования в отчетах, информационных панелях и инструментах бизнес-аналитики.
Эта архитектура, которой уже несколько десятилетий, остается распространенной и по сей день. Это позволяет назначать работу для конкретной базы данных, оптимизированной для обработки нагрузки. Однако у этой архитектуры есть и свои недостатки, наиболее существенным из которых является задержка данных. Процесс ETL запускается нечасто и часто занимает несколько часов. При такой архитектуре результирующие данные для анализа обычно доступны только на следующий день. Это напрямую влияет на задержку бизнес-решений и снижение способности реагировать на события по мере их возникновения.
Переход к потоковой передаче данных в реальном времени
В 2014 году Мартин Клеппман, автор книги Designing Data-Intensive Applications, выступил с основополагающим докладом под названием Выворачивание базы данных наизнанку. Он описал новый архитектурный шаблон. для обработки данных в режиме реального времени. Основная идея состоит в том, чтобы внедрить журнал упреждающей записи (WAL), который до этого момента был внутренним (хотя и фундаментальным) компонентом каждой операционной базы данных. Затем можно использовать потоковую структуру для обработки журнала почти в реальном времени, тем самым обеспечивая всегда актуальный эквивалент материализованного представления.
Эта концепция также распространяется на шаблон ETL. В некотором смысле таблицы в хранилище данных — это просто материализованные представления, которые живут в другой базе данных. Вместо ежедневной обработки заданий ETL у вас может быть конвейер потоковой передачи, который постоянно обновляет аналитические представления по мере поступления новых данных.
Модернизация архитектуры Kappa с помощью Redpanda, Materialise и dbt
В последние годы концепция базы данных Клеппмана наизнанку приобрела популярность и даже получила название: архитектура Каппа. В своем выступлении Клеппман рассказал об эталонной реализации с использованием Apache Samza®, платформы потоковой передачи на основе Java, и Apache Kafka® в качестве внешнего WAL. Сегодня мы считаем, что у нас есть альтернативная реализация архитектуры Kappa, которая значительно быстрее, удобнее для разработчиков, имеет лучшие гарантии безопасности и обеспечивает лучшее управление данными. Этот новый стек использует Redpanda для WAL, Materialise для потоковой передачи SQL и dbt для управления версиями и управления. Ниже мы подробно обсудим каждую часть этого стека.
Redpanda: быстрый, безопасный и простой распределенный журнал
Redpanda — это платформа потоковой передачи событий на основе Raft с распределенным журналом, написанным на C++, предназначенная для использования преимуществ современного оборудования. Он работает с в 10–40 раз меньшими задержками и в 6 раз большей пропускной способностью транзакций, чем Kafka, сохраняя при этом совместимость API.
Redpanda не использует кеш страниц и гарантирует полную сохранность логов при подтверждении получения. Консенсус на основе Raft делает Redpanda отказоустойчивым, хорошо работающим даже при частичных сбоях среды. Он подвергается обширному тестированию хаоса и в настоящее время проходит стороннюю сертификацию для обеспечения корректности в условиях отказа. Redpanda имеет практически бесконечное хранение данных с многоуровневым хранилищем. Высокая пропускная способность, малая задержка, отказоустойчивость, правильность и бесконечное хранение в совокупности делают Redpanda жизнеспособной системой записи и лучшим выбором для экстернализованного WAL.
Materialise: потоковый SQL-движок
Materialize — это база данных, специально созданная для потоковой аналитики. Он постепенно обновляет результаты запроса (определенные с помощью материализованных представлений SQL) по мере поступления новых данных, не требуя обновления вручную. Первоначальная эталонная реализация архитектуры Kappa использовала Apache Samza, и с тех пор появилось множество других потоковых фреймворков, которые требуют императивных навыков программирования на таких языках, как Java, Scala или Python. Однако SQL — это язык общения для пакетной обработки данных и аналитики, поэтому имеет смысл использовать его и для потоковой передачи. Благодаря использованию SQL-стандарта ANSI, Materialise возвращает мощь потоковой обработки в руки инженеров по обработке данных и аналитиков. Materialize также совместим с Postgres по проводам и может работать с его широкой экосистемой инструментов и интеграций.
Пользователи могут легко создавать источники и приемники Materialise, которые читают темы Redpanda и пишут в них. Вместе Redpanda и Materialise создают быструю и простую в использовании реализацию архитектуры Kappa. И, как бы замечательно это ни казалось, комбинация становится еще лучше, когда мы добавляем в стек dbt.
dbt: структура преобразования данных
dbt — это инструмент, совершенно не похожий ни на один другой. В некотором отношении dbt делает для данных то же, что Terraform делает для построения облачной инфраструктуры или что Maven/Gradle/и т. д. делают для создания кода. dbt фокусируется на том, чтобы позволить группам обработки данных работать как инженеры-программисты, позволяя им внедрять лучшие практики, такие как контроль версий, тестирование и CI/CD, в свой аналитический код. С dbt у пользователей есть СУХОЙ подход к определению и выполнению логики преобразования. Логика выражена в моделях dbt, которые написаны на SQL с возможностью дополнения с помощью Jinja.
Используя такие функции, как refs, dbt также автоматически обрабатывает зависимости, упрощая выполнение в различных средах (например, разработка, производство или подготовка) и на основе зависимостей. Он поддерживает ряд платформ данных, таких как Postgres и Snowflake. dbt находится поверх этих платформ данных и выполняет к ним SQL-запросы, снижая вычислительные ресурсы/хранилище.
Materialize — еще одна поддерживаемая среда выполнения благодаря совместимости с Postgres. Со стандартной серверной частью базы данных dbt может выполнять периодические обновления за счет использования инкрементных моделей. По сути, это похоже на запуск заданий mini-ETL для обновления данных. С помощью dbt и Materialise вы можете определить свою логику в dbt для Materialize, чтобы выполнять непрерывные обновления в реальном времени. Независимо от того, как часто поступают ваши данные, ваши модели будут оставаться актуальными без ручного или настроенного обновления. В качестве среды преобразования dbt предоставляет средства для упаковки, тестирования и документирования моделей, конвейеров и схем. Особенно в сочетании с инструментом контроля версий, таким как Git, эта комбинация дает группам данных мощный, самодокументируемый стек разработки для потоковых конвейеров данных.
Начните сегодня!
Это современная каппа-архитектура: Redpanda как быстрое и прочное бревно; Materialize для потоковой передачи на основе SQL; и dbt для dataOps. Этот стек сочетает в себе скорость, простоту использования, продуктивность разработчиков и управление. Лучше всего то, что вам не нужно вкладывать средства в настройку большой инфраструктуры: весь этот стек можно упаковать для запуска в виде единого проекта Docker Compose на вашем собственном ноутбуке или рабочей станции. Вы можете попробовать это сами, используя этот пример проекта.
Для получения дополнительной информации или помощи с Redpanda, в частности, мы рекомендуем вам присоединиться к нашему каналу сообщества Slack или загрузить наш двоичный файл с GitHub.
