Архитектура набора данных в Открытое озеро данных Qlik

При создании наборов данных в Открытое озеро данных Qlik таблицы хранения, таблицы изменений и представления генерируются автоматически с помощью Qlik Talend Data Integration. Вы можете выполнять запросы к этим представлениям для доступа к текущим и историческим данным, хранящимся в формате открытых таблиц Iceberg.

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

Схемы

Артефакты генерируются во внутренней схеме и схеме задачи данных.

• Внутренняя схема содержит физическую таблицу с несколькими разделами.

• Схема задачи данных содержит представления, которые можно использовать для потребления данных.

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

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

Таблицы

Для каждой исходной таблицы во внутренней схеме создается таблица с суффиксом _internal в следующем формате:

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

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

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

• Раздел Changes – Прием данных в реальном времени

  Все изменения из исходной системы — вставки, обновления и удаления — сначала добавляются в раздел Changes.

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

  • Каждое изменение помечается типом (I, U или D), указывающим, как оно обрабатывается.

  • События фиксируются из источника по мере их возникновения. Раздел обновляется почти в реальном времени.

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

    • На вкладке Общие для параметра Метод обновления установлено значение CDC.

    • Включена полная загрузка.

• Раздел Asset_state - Отслеживание прогресса

  По мере приема изменений в разделе Asset_state регистрируются две ключевые метки времени:

  • Когда изменения были в последний раз добавлены в раздел Changes.

  • Когда изменения были в последний раз применены к разделу Current.

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

• Раздел Current (ODS) – Последняя реплика источника

  Изменения из раздела Changes периодически применяются к разделу Current для поддержания актуальной, оптимизированной для запросов копии исходных данных.

  • Фоновая задача запускается автоматически для применения этих обновлений. Это зависит от объема накопленных изменений, а не от фиксированного расписания.

  • Начальная полная загрузка записывается непосредственно в раздел Current.

  • Этот раздел отражает текущее состояние данных и предназначен для эффективного выполнения запросов.

• Раздел Prior (HDS) – Исторические данные

  При обновлении или удалении записи в разделе Current копия предыдущей версии записывается в раздел Prior. 

  • Записи содержат метаданные, включая историю изменений и диапазон дат, когда данные действительны.

  • Это поддерживает медленно меняющееся измерение типа 2 (SCD2).

  • Раздел Prior доступен, если параметр Сохранять исторические записи и архив записей об изменениях включен на вкладке Общие в настройках задачи данных хранения.

  • Когда обновленная версия записи попадает в раздел Current, предыдущая запись перемещается в раздел Prior для отслеживания истории.

• Раздел Reload

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

  • Новые данные сначала записываются в раздел Reload.

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

  • Данные сравниваются с разделом Current, и в раздел Current перемещаются только различия.

  • Раздел Reload очищается по завершении операции.

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

Раздел Current

Раздел Prior

Раздел Changes

Раздел Asset_state

Раздел Reload

Столбцы, используемые разделом Reload, идентичны разделу Current.

Представления

Все созданные представления обновляются почти в реальном времени. Для упрощения выполнения запросов и создания отчетов доступны следующие представления:

Current

Представление Current отражает самое последнее состояние данных. Это представление представляет собой реплику исходной таблицы, обновляемую почти в реальном времени. Оно объединяет данные из разделов Current и Changes.

Имя: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

В структуру таблицы не добавляются столбцы заголовков.

History

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

Имя: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

В представление History добавляются следующие поля заголовка: