Архитектурный проектный документ

1. Введение

1.1 Проектный фон

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

1.2 Обзор проекта

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

1.3 Терминологическая таблица

2. Общий дизайн

2.1 Общий архитектурный дизайн

2.2 Дизайн серых функций

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

2.3 Дизайн высокой доступности и производительности

Все сервисы Qualitis являются идемпотентными, поэтому можно реализовать балансировку нагрузки между несколькими сервисами Qualitis. Как показано на рисунке ниже:

Балансировка нагрузки не только обеспечивает высокую доступность, но и повышает производительность.

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

1. Кэш запросов: использование распределённого кэша для кэширования результатов запросов, что позволяет избежать необходимости каждый раз запрашивать базу данных при отсутствии запроса, значительно снижая нагрузку на базу данных и повышая скорость запросов.

2.4 Многопоточный синхронный дизайн

1. Процессная синхронизация

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

Система Qualitis использует Zookeeper для координации нескольких процессов, и несколько экземпляров Qualitis конкурируют за создание временных узлов в Zookeeper. Экземпляр, успешно создавший временный узел, становится ролью Monitor и отвечает за обновление состояния задачи мониторинга.

2. Потоковая ограниченная пропускная способность

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

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

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

3. Модульный дизайн

3.1 Общая диаграмма модульного дизайна

3.2 Диаграмма вариантов использования

4. Дизайн интерфейса

4.1 Внутренний интерфейс

Внутренние интерфейсы в основном делятся на две категории:

• Административный интерфейс: /qualitis/api/v1/admin/*
• Пользовательский интерфейс: /qualitis/api/v1/projector/*

Разделение прав доступа пользователей осуществляется с помощью двух разных методов определения интерфейсов.

4.2 Внешний интерфейс

Внешний интерфейс определяется по URL: /qualitis/outer/api/v1/* Для вызова этого типа интерфейса необходимо добавить следующие параметры в запрос:

App_id и appToken должны быть предоставлены администратором внешней системе.

5. Инженерный дизайн системы

Структура системы может быть разделена на два уровня: веб-уровень и основной уровень.

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