Архитектура набора данных для потоковых источников в Открытое озеро данных Qlik

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

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

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

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

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

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

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

Промежуточные таблицы

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

Схемы

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

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

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

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

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

Таблицы

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

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

Эта таблица содержит пять разделов в режиме Apply changes (Merge), каждый из которых выполняет свою уникальную функцию в обработке и хранении данных. Каждый раздел работает с некоторым подмножеством столбцов таблицы в зависимости от своей роли в жизненном цикле данных. В режиме только добавления таблица не имеет разделов и ведет себя как Текущий раздел (ODS).

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

• Раздел 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 раздел доступен, если на вкладке General в настройках задачи хранения данных активирован параметр Keep historical records and archive of change records.

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

• Раздел Reload

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

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

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

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

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

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

Current раздел

Prior раздел

Changes раздел

Asset_state раздел

Reload раздел

Столбцы в Reload разделе аналогичны столбцам в Current разделе.

Виды

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

Текущие данные

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

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

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

История

Вид «История» генерируется в схеме ресурсов данных по каждой выбранной исходной таблице, если в настройках задачи данных активен параметр «История». Представление истории объединяет данные из раздела Prior и раздела Changes. В нем представлена полная история изменений, поэтому этот вид идеально подходит для аудита или исторического анализа.

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

В вид «История» добавляются следующие поля заголовков.

Отображение столбцов заголовков в представлениях

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

Задача потокового промежуточного хранения

Чтобы показать столбцы заголовков, включите Показать столбцы заголовков справа от поля поиска.

Задача потокового преобразования

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

• Скрыть столбцы заголовков: По умолчанию.

• Показать столбцы заголовков

  • Стандартный: Выберите, чтобы отобразить столбцы заголовков для стандартных видов.

  • История: Выберите, чтобы отобразить столбцы заголовков для представлений истории. Обратите внимание, что эта опция будет доступна только если Создать хранилище исторических данных (тип 2) включена в настройках задачи или набора данных.

Описание доступных столбцов заголовка см. Промежуточные таблицы и Виды.