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

Потоковые источники имеют собственную архитектуру в Открытое озеро данных Qlik, поскольку им не требуется Data Movement gateway для загрузки данных в блок промежуточного хранения, а они работают на базе кластера lakehouse.

При приеме данных из файлов, содержащих шаблон данных в имени файла, кластер lakehouse может выполнять целевые операции со списками в S3, что значительно ускоряет время чтения списка файлов. Кроме того, Открытое озеро данных Qlik может прогнозировать поступающие файлы на основе шаблона даты. Задаче потокового промежуточного хранения не нужно каждый раз составлять список всего блока, вместо этого она может запрашивать файлы из S3 в определенном диапазоне дат. Меньший список файлов приводит к повышению производительности. Дополнительную настройку Удалить после загрузки можно использовать для поддержания небольшого количества файлов. Полная загрузка не выполняется, первые записи считаются вставленными изменениями.

В Открытое озеро данных Qlik задача потокового преобразования заменяет задачу хранения. Эта задача используется для преобразования и хранения данных промежуточного хранения в виде таблиц Iceberg. Задачу потокового преобразования можно добавить только после задачи потокового промежуточного хранения. Задача потокового преобразования поддерживает два режима обновления записей:

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

• Применить изменения (Объединить): Обновляет существующие записи и вставляет новые записи на основе ключевых полей. Этот режим дает возможность использовать мягкое удаление или сохранять исторические данные (Тип 2).

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

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

Таблицы промежуточного хранения

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

Схемы

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

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

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

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

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

Таблицы

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

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Эта таблица содержит пять разделов в режиме Применить изменения (Объединить), каждый из которых служит определенной цели в обработке и хранении данных. Каждый раздел использует подмножество столбцов таблицы в зависимости от его роли в жизненном цикле данных. В режиме Только добавление таблица не имеет разделов и ведет себя как раздел Current (ODS).

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

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

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

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

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

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

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

    • На вкладке Общие для параметра Метод обновления установлено значение 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 добавляются следующие поля заголовка: