Как спроектировать платформу данных в реальном времени (технология)

Проворная песня

Я рисую, значит, я существую | DBus

Все играют в стриминг | Wormhole

Как будто я база данных | Moonbox

Последние десять километров красоты | Davinci

Введение: Платформа данных в реальном времени (RTDP, Платформа данных в реальном времени) является важной и распространенной платформой инфраструктуры больших данных. В последней части (часть проектирования) мы представили RTDP с точки зрения современной архитектуры хранилища данных и типичной обработки данных, а также обсудили общую архитектуру проектирования RTDP. Эта статья, как и следующая глава (техническая глава), начинается с технической точки зрения, знакомит с техническим выбором и соответствующими компонентами RTDP, а также обсуждает связанные режимы, подходящие для различных сценариев приложений. Гибкая дорога RTDP начинается здесь~

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

Как спроектировать платформу данных в реальном времени (дизайн)

1. Введение технического отбора

В главе о дизайне мы даем общий дизайн архитектуры RTDP (рис. 1). В технической главе мы рекомендуем выбор общих технических компонентов; кратко расскажем о каждом техническом компоненте, особенно о четырех технических платформах, которые мы абстрагируем и внедряем (унифицированная платформа сбора данных, унифицированная платформа потоковой обработки, унифицированная вычислительная платформа). Platform, Unified Data Visualization Platform) фокусируется на идеях дизайна; обсуждаются сквозные аспекты Pipeline, включая функциональную интеграцию, управление данными, безопасность данных и т. д.

Рис. 1 Архитектура RTDP

1.1 Общий технический выбор

Рисунок 2 Общий выбор технологии

Во-первых, давайте кратко интерпретируем рисунок 2:

Источник данных, клиент, перечисляет общие типы источников данных для большинства проектов приложений данных.
Платформа шины данных DBus, как унифицированная платформа сбора данных, отвечает за подключение различных источников данных. DBus извлекает данные постепенно или полностью, выполняет некоторую рутинную обработку данных и, наконец, публикует обработанные сообщения в Kafka.
Kafka, распределенная система сообщений, объединяет производителей и потребителей сообщений с распределенными возможностями высокой доступности, высокой пропускной способности и публикации-подписки.
Стриминговая платформа Wormhole как единая стриминговая платформа отвечает за обработку потоков и подключение к различным целевым хранилищам данных. Wormhole получает сообщения от Kafka, поддерживает настройку SQL в потоке для реализации логики обработки данных в потоке и поддерживает настройку данных для попадания в другое целевое хранилище данных (Sink) с эффектом согласованности в конечном итоге (идемпотентом).
На уровне вычислений и хранения данных архитектура RTDP выбирает выбор компонентов открытой технологии, и пользователи могут выбирать подходящее хранилище в соответствии с фактическими характеристиками данных, режимом вычислений, режимом доступа, объемом данных и другой информацией для решения конкретных проблем проекта данных. RTDP также поддерживает одновременный выбор нескольких разных хранилищ данных, чтобы более гибко поддерживать различные требования проекта.
Платформа вычислительных услуг Moonbox, как унифицированная платформа вычислительных услуг, отвечает за интеграцию хранения гетерогенных данных, оптимизацию вычислений с проталкиванием вниз, смешанные вычисления хранения гетерогенных данных (технология виртуализации данных), а также отвечает за отображение данных и взаимодействие. , единый расчет и распределение данных, единый язык запросов данных (SQL), единый интерфейс службы данных и т. д.
Платформа визуальных приложений Davinci, как унифицированная платформа визуализации данных, поддерживает различные требования к визуализации данных и взаимодействию настраиваемым образом и может интегрировать другие приложения данных для предоставления решений для некоторых требований к визуализации данных. Совместная работа над различными ежедневными приложениями данных. Другие системы потребления терминалов данных, такие как платформа разработки данных Zeppelin и платформа алгоритмов данных Jupyter, в этой статье не представлены.
Такие аспекты, как управление данными, безопасность данных, разработка, эксплуатация и обслуживание, а также движущие механизмы, могут быть интегрированы и переработаны через сервисные интерфейсы DBus, Wormhole, Moonbox и Davinci для поддержки требований сквозного контроля и управления.

Далее мы дополнительно уточним технические компоненты и дополнительные темы, представленные на приведенном выше рисунке, представим функциональные характеристики технических компонентов, сосредоточимся на объяснении конструктивных идей наших собственных технических компонентов и обсудим дополнительные темы.

1.2 Введение технических компонентов

1.2.1 Платформа шины данных DBus

Рисунок 3 DBus архитектуры RTDP

1.2.1.1 Идея дизайна DBus

1) Взгляните на дизайн-мышление со стороны.

Он отвечает за подключение различных источников данных и извлечение инкрементных данных в режиме реального времени.Для базы данных принят метод извлечения журнала операций, а для типа журнала поддерживается стыковка с различными агентами.
Публикуйте все сообщения в Kafka в едином формате сообщений UMS. UMS — это стандартизированный формат JSON с собственными метаданными. Унифицированная UMS реализует разделение логических сообщений и физических тем Kafka, так что одна и та же тема может передаваться в несколько UMS. Таблица.
Он поддерживает полное извлечение данных из базы данных и интегрирует их с добавочными данными в сообщения UMS, что является прозрачным и незаметным для последующего использования.

2) Взгляните на дизайн-мышление с внутренней точки зрения.

Форматирование данных выполняется на базе вычислительного движка Storm для обеспечения наименьшей сквозной задержки сообщений.
Стандартизируйте и форматируйте данные из различных источников данных для создания информации UMS, в том числе:

✔ Генерировать уникальный монотонно возрастающий id для каждого сообщения, соответствующий системному полю ums_id_

✔ Подтвердите метку времени события каждого сообщения, соответствующую системному полю ums_ts_

✔ Подтвердите режим работы каждого сообщения (только добавить, удалить или вставить), соответствующий системному полю ums_op_

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

1.2.1.2 Особенности DBus

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

1.2.1.3 Техническая архитектура DBus

Рис. 4. Схема архитектуры потока данных DBus

Для получения более подробной технической информации и пользовательского интерфейса DBus, пожалуйста, обратитесь к:

Гитхаб:github.com/BriData

1.2.2 Распределенная система обмена сообщениями Kafka

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

Здесь мы специально обсуждаем темы управления метаданными сообщений (Metadata Management) и эволюции схемы (Schema Evolution) в Kafka.

Рисунок 5

Источник изображения:Корпус C durable.com/images/Kafka…

На рис. 5 показано, что в решении Confluent, лежащем в основе Kafka, представлен компонент управления метаданными: реестр схем. Этот компонент в основном отвечает за управление информацией о метаданных и информацией о теме сообщений, циркулирующих в Kafka, и предоставляет ряд услуг по управлению метаданными. Причина введения такого компонента заключается в том, что потребители Kafka могут понять, какие данные циркулируют по разным темам, а также метаданные данных, а также выполнять эффективный анализ и потребление.

Любая ссылка потока данных, независимо от того, в какой системе она работает, будет иметь проблемы с управлением метаданными для этой ссылки данных, и Kafka не является исключением. Schema Registry — это централизованное решение для управления метаданными канала передачи данных Kafka, основанное на Schema Registry, Confluent предоставляет соответствующий механизм безопасности данных Kafka и механизм эволюции схемы.

Для получения дополнительной информации о реестре схем см.:

Kafka Tutorial:Kafka, Avro Serialization and the Schema Registry

Корпус C durable.com/blog/Kafka-…

Итак, в архитектуре RTDP, как решить проблему управления метаданными сообщений Kafka и эволюции схемы?

1.2.2.1 Управление метаданными

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

1.2.2.2 Эволюция схемы

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

[Datastore].[Datastore Instance].[Database].[Table].[TableVersion].[Database Partition].[Table Partition]

Пример: oracle.oracle01.db1.table1.v2.dbpar01.tablepar01

Среди них [Версия таблицы] представляет номер версии схемы этой таблицы.Если источником данных является база данных, этот номер версии автоматически поддерживается DBus.

В архитектуре RTDP нижний поток Kafka потребляется Wormhole.Когда Wormhole использует UMS, он будет рассматривать [TableVersion] как *, что означает, что при изменении восходящей схемы таблицы версия будет автоматически увеличиваться, но Wormhole будет игнорировать изменения этой версии будут потреблять инкрементные/полные данные всех версий этой таблицы, так как же Wormhole поддерживает эволюцию режима совместимости? В Wormhole вы можете настроить поток для обработки SQL и полей вывода.Когда изменение схемы восходящего потока является «изменением совместимости» (ссылаясь на добавление полей или изменение и расширение типов полей и т. д.), это не повлияет на правильное выполнение червоточины SQL. Когда в восходящем потоке происходит несовместимое изменение, Wormhole сообщит об ошибке, и потребуется ручное вмешательство для исправления логики новой схемы.

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

Таблица 1 Сравнение схемы реестра и DBus+UMS

Вот пример УМС:

Рис. 6 Пример сообщения UMS

1.2.3 Потоковая платформа Wormhole

Рисунок 7 Червоточина архитектуры RTDP

1.2.3.1 Идеи дизайна червоточины

1) Взгляните на дизайн-мышление со стороны.

Использование сообщений UMS и пользовательских сообщений JSON от Kafka
Отвечает за стыковку различных целевых хранилищ данных (Sink) и реализует возможную согласованность Sink с помощью идемпотентной логики.
Поддерживает конфигурацию SQL для реализации логики обработки в потоке.
Предоставляет абстракцию Flow. Поток определяется пространством имен источника и пространством имен приемника и является уникальным. Flow может определять логику обработки, которая является логической абстракцией потоковой обработки.Благодаря отделению от физической потоковой передачи Spark и потоковой передачи Flink один и тот же поток может обрабатывать несколько потоков обработки потока, а поток может произвольно переключаться между разными потоками.
Поддержка архитектуры Kappa на основе обратной засыпки; поддержка архитектуры Lambda на основе Wormhole Job

2) Взгляните на дизайн-мышление с внутренней точки зрения.

Обработка потока данных на базе Spark Streaming и вычислительного движка Flink. Spark Streaming может поддерживать такие сценарии, как высокая пропускная способность, пакетный поиск и приемник пакетной записи; Flink может поддерживать такие сценарии, как низкая задержка и правила CEP.
Реализовать идемпотентную логику хранения для разных стоков через ums_id_, ums_op_
Оптимизация логики поиска с помощью вычислительного проталкивания вниз
Абстрагируйте несколько объединений для поддержки функциональной гибкости и согласованности дизайна.

✔ Унифицированная фрактальная абстракция высокого порядка DAG

✔ Абстракция протокола UMS унифицированного универсального потока сообщений

✔ Единое пространство имен логических таблиц данных Абстракция пространства имен

Абстрактное несколько интерфейсов для поддержки расширяемости

✔ SinkProcessor: Расширьте поддержку дополнительных стоков.

✔ SwiftsInterface: поддержка логики обработки пользовательских потоков

✔ UDF: UDF поддерживает больший поток обработки

Сбор динамических показателей и статистики потоковых заданий в режиме реального времени через сообщения обратной связи

1.2.3.2 Особенности червоточины

Поддержка визуализации, настройки и разработки и реализации потоковых проектов на основе SQL.
Поддерживает управление, эксплуатацию и техническое обслуживание, диагностику и мониторинг императивной динамической потоковой передачи.
Поддержка унифицированных структурированных сообщений UMS и настраиваемых полуструктурированных сообщений JSON.
Поддерживает обработку потоков сообщений о событиях с тремя состояниями CRUD.
Поддерживает один физический поток для одновременной обработки нескольких логических бизнес-потоков.
Поддерживает Lookup Anywhere, Pushdown Anywhere в потоке
Поддерживает потоковую передачу временных меток событий на основе бизнес-политики
Поддерживает управление регистрацией и динамическую загрузку пользовательских функций.
Поддержка одновременного идемпотентного хранения многоцелевых систем данных
Поддерживает многоуровневое инкрементное управление качеством данных на основе сообщений.
Поддерживает инкрементную потоковую передачу на основе сообщений и пакетную обработку
Поддержка архитектуры Lambda и архитектуры Kappa
Поддерживает бесшовную интеграцию с трехсторонними системами и может использоваться в качестве механизма управления потоком трехсторонних систем.
Поддержка развертывания частного облака, управление разрешениями безопасности и управление мультитенантными ресурсами.

1.2.3.3 Техническая архитектура червоточин

Рис. 8. Схема архитектуры потока данных червоточины

Для получения дополнительных технических деталей и пользовательского интерфейса Wormhole см.:

Гитхаб:GitHub.com/EDP963/червь…

1.2.4 Выбор общих вычислений и хранения данных

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

Вот некоторые из наиболее распространенных вариантов:

Реляционная база данных (Oracle/MySQL и т. д.): подходит для сложных реляционных вычислений с небольшими объемами данных.
Распределенная система хранения столбцов

✔ Kudu: оптимизация сканирования, подходящая для анализа OLAP и сценариев расчета.

✔ HBase: произвольное чтение и запись, подходит для сценариев обслуживания данных

✔ Cassandra: высокопроизводительная запись, подходит для высокочастотной записи массивных данных

✔ ClickHouse: высокопроизводительные вычисления, подходящие для сценариев записи только вставки (операции обновления и удаления будут поддерживаться позже)

Распределенная файловая система

✔ HDFS/Parquet/Hive: только добавление, подходит для сценариев обработки больших объемов данных.

Распределенная система документов

✔ MongoDB: Сбалансированные возможности, подходящие для средних и сложных вычислений с большими объемами данных

Распределенная система индексации

✔ ElasticSearch: возможность индексирования, подходящая для нечетких запросов и сценариев анализа OLAP.

Распределенная система предварительных вычислений

✔ Druid/Kylin: возможности предварительного расчета, подходящие для высокопроизводительных сценариев анализа OLAP.

1.2.5 Moonbox, платформа вычислительных услуг

Рисунок 9 Moonbox архитектуры RTDP

1.2.5.1 Идеи дизайна Moonbox

1) Взгляните на дизайн-мышление со стороны.

Отвечает за взаимодействие с различными системами данных и поддержку специального смешивания в разнородных системах данных унифицированным образом.
Предоставляет три метода вызова клиента: служба RESTful, соединение JDBC, соединение ODBC.
Унифицированное закрытие метаданных, закрытие единого языка запросов SQL, закрытие единого контроля полномочий
Обеспечивает два режима записи результатов запроса: Merge, Replace.
Предоставьте два интерактивных режима: пакетный режим, режим Adhoc.
Реализация виртуализации данных, многопользовательская реализация, может рассматриваться как виртуальная база данных.

2) Взгляните на дизайн-мышление с внутренней точки зрения.

SQL анализируется, и посредством обычного процесса обработки и синтаксического анализа Catalyst логическое поддерево выполнения, которое может протолкнуть систему данных, наконец, создается для проталкивающих вычислений, а затем результат извлекается для смешанных вычислений и возвращается.
Поддерживает два уровня пространства имен: database.table для обеспечения работы с виртуальной базой данных.
Обеспечьте распределенный сервисный модуль Moonbox Grid, чтобы обеспечить высокую доступность и возможность параллелизма.
Быстрый путь выполнения для всей логики pushdown (без путаницы)

1.2.5.2 Особенности Moonbox

Поддерживает плавное микширование в гетерогенных системах
Поддержка расчета и записи запросов с унифицированным синтаксисом SQL.
Поддержка трех методов вызова: служба RESTful, соединение JDBC, соединение ODBC.
Поддержка двух интерактивных режимов: пакетный режим, режим Adhoc.
Поддержка инструмента Cli Command и Zeppelin
Поддержка многопользовательской системы прав пользователей
Поддержка разрешений на уровне таблицы, разрешений на уровне, прав на чтение, разрешений на запись, разрешений UDF
Поддержка управления ресурсами планировщика YARN
Поддержка служб метаданных
Поддержка запланированных задач
Поддержка политики безопасности

1.2.5.3 Техническая архитектура Moonbox

Рисунок 10 Логический модуль Moonbox

Для получения более подробной технической информации и пользовательского интерфейса Moonbox, пожалуйста, обратитесь к:

Гитхаб:GitHub.com/EDP963/луна…

1.2.6 Платформа визуальных приложений Davinci

Рисунок 11 Davinci архитектуры RTDP

1.2.6.1 Идеи дизайна Davinci

1) Взгляните на дизайн-мышление со стороны.

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

2) Взгляните на дизайн-мышление с внутренней точки зрения.

Развернуть вокруг View и Widget. Вид — это логическое представление данных; Виджет — это представление визуализации данных.
Благодаря определяемому пользователем выбору категорийных данных, упорядоченных данных и количественных данных представления автоматически отображаются в соответствии с разумной логикой визуализации.

1.2.6.2 Возможности Davinci

1) Источник данных

Поддержка источника данных JDBC
Поддержка загрузки файлов CSV

2) Просмотр данных

Поддержка определения шаблонов SQL
Поддержка выделения SQL
Поддержка тестов SQL
Поддерживается операция обратной записи

3) Визуальные компоненты

Поддержка предопределенных диаграмм
Поддержка компонентов контроллера
Поддержка свободного стиля

4) Способность к взаимодействию

Поддержка полноэкранного отображения отображаемых компонентов
Поддержка отображаемых локальных контроллеров
Поддержка фильтрации связи между визуальными компонентами
Поддержка визуальных компонентов контроллера группового управления
Поддержка локальных расширенных фильтров для отображаемых объектов.
Поддержка пейджинга и слайдера для отображения больших объемов данных

5) Возможность интеграции

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

6) Разрешения безопасности

Поддержка разрешений строк и столбцов данных
Поддержка интеграции входа в систему LDAP

Для получения более подробной технической информации и пользовательского интерфейса Davinci, пожалуйста, обратитесь к:

Гитхаб:GitHub.com/EDP963/посетить ви…

1.3 Аспекты обсуждения темы

1.3.1 Управление данными

1) Управление метаданными

DBus может получать метаданные источника данных в режиме реального времени и предоставлять служебный запрос
Moonbox может получать метаданные системы данных в режиме реального времени и предоставлять сервисные запросы.
Для архитектуры RTDP информация о метаданных источников данных в реальном времени и специальных источников данных может быть собрана путем вызова служб RESTful DBus и Moonbox, и на основе этого может быть построена система управления метаданными на уровне предприятия.

2) Качество данных

Wormhole может настроить сообщения так, чтобы они попадали в HDFS (hdfslog) в режиме реального времени. Wormhole Job на основе hdfslog поддерживает архитектуру Lambda, Backfill на основе hdfslog поддерживает архитектуру Kappa. Вы можете выбрать архитектуру Lambda или архитектуру Kappa для регулярного обновления приемника, настроив запланированную задачу для обеспечения согласованности данных в конечном итоге. Wormhole также поддерживает обратную связь в режиме реального времени с информацией о сообщениях об обработке исключений или исключений записи приемника в систему Wormhole и предоставляет службы RESTful для сторонних приложений для вызова и обработки.
Moonbox может выполнять произвольное микширование гетерогенных систем, что дает удобство Moonbox «Швейцарский армейский нож». Вы можете написать обычную логику SQL-скрипта через Moonbox, сравнить данные интересующих разнородных систем или выполнить статистику по полям интересующей таблицы данных и т. д., а также вы можете заново разработать систему проверки качества данных на основе возможности Moonbox.

3) Анализ родословной

Логика потоковой обработки червоточины обычно выполняется с помощью SQL, который можно агрегировать с помощью сервисов RESTful.
Moonbox отвечает за унифицированный ввод запроса данных, а вся логика — это SQL, который можно собрать через логи Moonbox.
Для архитектуры RTDP логика обработки в реальном времени и SQL специальной логики обработки могут использоваться для вызова службы RESTful Wormhole и сбора журналов Moonbox, на основе которых может быть построена система анализа родословных на уровне предприятия.

1.3.2 Безопасность данных

Рис. 12 Безопасность данных RTDP

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

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

1.3.3 DevOps

1) Управление эксплуатацией и техническим обслуживанием

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

2) Мониторинг и раннее предупреждение

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

2. Обсуждение сценариев режима

В прошлой главе мы представили архитектуру проектирования и функциональные характеристики каждого технического компонента архитектуры RTDP, Пока у читателя есть конкретное представление и понимание того, как реализована архитектура RTDP. Итак, какие общие сценарии приложений данных может решить архитектура RTDP? Ниже мы обсудим несколько шаблонов использования и сценарии, в которые подходит каждый шаблон.

2.1 Синхронный режим

2.1.1 Описание режима

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

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

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

2.1.2 Технические трудности

Конкретная реализация относительно проста.

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

2.1.3 Управление эксплуатацией и техническим обслуживанием

Управление эксплуатацией и обслуживанием относительно простое.

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

2.1.4 Применимые сценарии

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

2.2 Режим расчета расхода

2.2.1 Описание режима

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

В архитектуре RTDP настройка и поддержка логики обработки потока в основном выполняется на платформе Wormhole. Помимо возможностей синхронного режима, потоковый режим в основном предоставляет две возможности:

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

2.2.2 Технические трудности

Конкретная реализация относительно сложна.

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

2.2.3 Управление эксплуатацией и техническим обслуживанием

Управление эксплуатацией и техническим обслуживанием относительно сложно.

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

2.2.4 Применимые сценарии

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

2.3 Режим вращения

2.3.1 Описание режима

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

В архитектуре RTDP интеграция Kafka->Червоточины->Sink->Moonbox->Kafka может использоваться для реализации любого расчета цикла вращения на любой частоте. Помимо возможностей режима потоковой передачи, основными возможностями, предоставляемыми режимом циклического перебора, являются: Теоретическая поддержка любой сложной логики потоковых вычислений с малой задержкой.

2.3.2 Технические трудности

Сложно реализовать.

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

2.3.3 Управление эксплуатацией и техническим обслуживанием

Управление эксплуатацией и обслуживанием затруднено.

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

2.3.4 Применимые сценарии

Многоэтапные сложные логические сценарии обработки данных с малой задержкой
Построение сети обработки потоков данных в режиме реального времени на уровне компании

2.4 Умный режим

2.4.1 Описание режима

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

Умные точки:

Интеллектуальный дрейф Wormhole Flow (интеллектуальная автоматическая работа и обслуживание)
Интеллектуальная оптимизация предварительно вычисленного Moonbox (интеллектуальная автоматическая оптимизация)
Полная вычислительная логика интеллектуально преобразуется в логику потоковых вычислений, а затем развертывается в Wormhole + Moonbox (интеллектуальная автоматизированная разработка и развертывание).
и т.д

2.4.2 Технические трудности

Конкретная реализация является наиболее простой в теории, но наиболее сложной является эффективная техническая реализация.

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

2.4.3 Управление эксплуатацией и техническим обслуживанием

Нулевой O&M.

2.4.4 Применимые сценарии

полная сцена.

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

Автор: Лу Шаньвэй

Источник: Технологический институт CreditEase.