Архитектура базы данных в облачном хранилище данных
Интеграция данных Qlik Cloud позволяет создавать, управлять и контролировать конвейер с аналитическими данными и поставлять данные потребителям на любом этапе конвейера. Если генерирование данных в облачном хранилище данных производится с помощью Интеграция данных Qlik Cloud, создаются таблицы хранения, таблицы изменений и виды.
Благодаря интуитивно понятному интерфейсу и инструкциям системы, пользователь может строить, моделировать и выполнять конвейеры данных. Автоматически создавайте схемы для хранилищ оперативных (ODS) и исторических данных (HDS), не прибегая к ручному написанию кода.
Архитектура для конвейера данных Интеграция данных Qlik Cloud с использованием Qlik Data Gateway — Data Movement и CDC
-
Промежуточное хранение
Задача промежуточного хранения в Интеграция данных Qlik Cloud управляет непрерывным потоком данных из источников данных в зону промежуточного хранения. В этом примере диаграмма описывает использование Qlik Data Gateway — Data Movement для доступа к источникам данных, в которых обновление данных производится через CDC. Можно также использовать подключения к источнику Qlik Cloud для выполнения полной загрузки, которую можно перезагружать регулярно по расписанию.
Примечание к информацииТаблицы в зоне промежуточного хранения генерируются задачами хранения данных Интеграция данных Qlik Cloud для внутреннего использования. Не используйте таблицы промежуточного хранения в нижестоящих процессах. -
Хранилище
Задача хранилища контролирует, когда данные применяются к таблицам хранилища, а также создает таблицы и внешние виды и позволяет управлять ими.
-
Внешние виды
При работе с данными лучше всего использовать виды. Виды обеспечивают ряд преимуществ по сравнению с таблицами, включая более эффективный параллельный доступ к данным.
Использование видов в реальном времени
Виды в реальном времени позволяют получать доступ к текущим (ODS) и исторический данным (HDS). В видах этого типа представлены таблицы с изменениям, которые еще не были применены к текущим или предшествующим таблицам. Это позволяет просматривать измененные данные с меньшей задержкой без необходимости частого применения данных. Меняя задержку слияния, можно снизить стоимость обработки и упростить требования к обработке на целевой платформе.
Это позволяет загружать полностью вычислительный уровень только некоторое время.
-
Промежуточное хранение может быть направлено на хранилище, определенное явным образом; размер такого хранилища может быть меньше, так как при этом используются операции INSERT для быстрого выполнения.
-
Для обработки, связанной с процессом хранения, выполняемым, например, раз в сутки, в некоторых случаях требуется достаточно большой вычислительный уровень.
-
Задержку можно оптимизировать, если нет необходимости применять изменения в течение всего дня. Как только новые вставленные записи становятся доступными в таблице изменений, они немедленно появляются в видах реального времени.
Схемы
Артефакты генерируются во внутренних схемах, а также в схемах задач данных.
-
Внутренняя схема содержит таблицы с физическими данными.
-
Схема задач данных содержит виды, которые можно использовать для работы с данными.
Когда схема связана с несколькими задачами данных, каждая задача данных должна использовать уникальный префикс для таблиц и видов. Префикс можно настроить в параметрах задачи данных.
Только внутренние схемы проверяются на предмет конфликтов имен. Остальные схемы необходимо самостоятельно проверять, чтобы исключить конфликты имен таблицы. Рекомендуется использовать для внутренней схемы то же имя, что для схемы задачи данных с добавлением _internal. Это эффективный способ обеспечения уникальности каждой комбинации схемы и префикса.
Таблицы
Во внутренних схемах создаются следующие таблицы.
-
Текущая таблица (ODS)
Эта таблица содержит реплику источника данных, обновленную с учетом изменений, собранных за последний рабочий интервал.
-
Предшествующая таблица (HDS)
В этой таблице содержится второй тип данных — исторические данные. Таблица генерируется, если в настройках задачи обработки данных выбран параметр Журнал (History).
Новые записи добавляются в предшествующую таблицу каждый раз после обновления исходной таблица. Историческая запись — это копия предыдущей текущей записи плюс информация о том, что было обновлено и когда запись была актуальна.
Используйте исторический вид, а также исторический вид реального времени для просмотра исторических данных. Для получения дополнительной информации см. разделы Исторический вид и Исторический вид в реальном времени.
-
Таблица изменений
В этой таблице собраны все изменения, которые еще не были применены к текущей таблице. Она генерируется только в режиме промежуточного хранения Полная нагрузка и CDC (Full load and CDC).
Виды
В схеме ресурсов данных создаются следующие виды. Создание видов зависит от того, включены ли виды реального времени и исторические виды, а также производится ли обработка изменений.
-
Текущий вид
-
Вид в реальном времени
-
Вид с изменениями
-
Исторический вид
-
Исторический вид в реальном времени
Текущий вид
Создание имени: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_current
В структуру таблицы добавляются следующие поля заголовков.
| Поле | Тип | Описание |
|---|---|---|
| hdr__key_hash | varbinary(20) |
Хэш всех первичных ключей записей. Формат хэша — SHA1. Столбцы разделяются символом backspace. Этот столбец не генерируется в задачах Киоск данных. |
| hdr__key_id | int64 |
Последовательность увеличивается на запись. Этот столбец генерируется только в задачах Киоск данных. |
| hdr__from_timestamp | метка времени |
Метка времени в формате UTC
|
| hdr__operation | string(1) |
Последняя операция по этой записи.
|
| hdr__inserted_timestamp | метка времени | Временная метка (UTC) первого добавления ключа. Если используется полная загрузка, начальное время полной нагрузки. |
| hdr__modified_timestamp | метка времени | Временная метка (UTC) последнего обновления. |
Вид в реальном времени
Виды в реальном времени показывают для каждой выбранной исходной таблицы вид, объединяющий таблицу с данными из таблицы изменений. Благодаря этому при выполнении запросов используется вид данных в реальном времени, так что не требуется ждать следующего цикла применения. Изменения, объединенные из вида таблицы изменений, не согласованы по транзакциям между таблицами.
Виды в реальном времени создаются только в том случае, если в настройках задачи данных активен параметр Виды в реальном времени.
Создание имени: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>< суффикс для видов в реальном времени>
| Поле | Тип | Описание |
|---|---|---|
| hdr__key_hash | varbinary(20) |
Хэш всех первичных ключей записей. Формат хэша — SHA1. Столбцы разделяются символом backspace. Этот столбец не генерируется в задачах Киоск данных. |
| hdr__key_id | int64 |
Последовательность увеличивается на запись. Этот столбец генерируется только в задачах Киоск данных. |
| hdr__from_timestamp | метка времени |
Метка времени в формате UTC
|
| hdr__operation | string(1) |
Последняя операция по этой записи.
|
| hdr__inserted_timestamp | метка времени | Временная метка (UTC) первого добавления ключа. Если используется полная загрузка, начальное время полной нагрузки. |
| hdr__modified_timestamp | метка времени | Временная метка UTC последнего обновления. |
| hdr__store | varchar(10) |
Указывает, где находится запись.
|
Вид с изменениями
Это вид таблицы изменений в схеме промежуточного хранения для каждой выбранной исходной таблицы.
Создание имени: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_changes
В структуру таблицы добавляются следующие поля заголовков.
| Поле | Тип | Описание |
|---|---|---|
| hdr__change_identifier | string(50) |
Идентификатор изменения представляет собой строку, которая состоит из двух частей:
|
| hdr__operation | string(1) |
Последняя операция по этой записи.
|
| hdr__timestamp | метка времени |
Метка времени в формате UTC. |
| hdr__key_hash | binary(20) |
Хэш всех первичных ключей записей. Этот столбец не генерируется в задачах Киоск данных. |
| hdr__key_id | int64 |
Последовательность увеличивается на запись. Этот столбец генерируется только в задачах Киоск данных. |
Исторический вид
Исторический вид генерируется в схеме ресурсов данных по каждой выбранной исходной таблице, если в настройках задачи данных выбрано Журнал (History). Добавляются следующие поля заголовков.
Создание имени: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>< Suffix for history views>
| Поле | Тип | Описание |
|---|---|---|
| hdr__key_hash | binary(20) |
Хэш всех первичных ключей записей. Этот столбец не генерируется в задачах Киоск данных. |
| hdr__key_id | int64 |
Последовательность увеличивается на запись. Этот столбец генерируется только в задачах Киоск данных. |
| hdr__store | varchar(10) |
Указывает, где находится запись.
|
| hdr__operation | string(1) |
Последняя операция по этой записи.
|
| hdr__deleted | bit |
Указывает, является ли запись обратимо удаленной, в зависимости от того, имеет ли hdr__operation значение D или d. |
| hdr__was _current_from_timestamp | метка времени |
Временная метка в формате UTC, указывающая, когда впервые запись была текущей. |
| hdr__was _current_to_timestamp | метка времени |
Временная метка в формате UTC, указывающая, когда в последний раз запись была текущей. |
Исторический вид в реальном времени
Исторический вид в реальном времени генерируется в схеме ресурсов данных для каждой выбранной исходной таблицы, объединенной с изменениями из таблицы изменений. Добавляются следующие поля заголовков.
Создание имен: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>< Suffix for live history views>
| Поле | Тип | Описание |
|---|---|---|
| hdr__key_hash | binary(20) |
Хэш всех первичных ключей записей. Этот столбец не генерируется в задачах Киоск данных. |
| hdr__key_id | int64 |
Последовательность увеличивается на запись. Этот столбец генерируется только в задачах Киоск данных. |
| hdr__store | varchar(10) |
Указывает, где находится запись.
|
| hdr__operation | string(1) |
Последняя операция по этой записи.
|
| hdr__deleted | bit |
Указывает, является ли запись обратимо удаленной, в зависимости от того, имеет ли hdr__operation значение D или d. |