# Архитектура набора данных для потоковых источников в Открытое озеро данных Qlik Источники потоковой передачи имеют собственную архитектуру в Открытое озеро данных Qlik, поскольку им не требуется Data Movement gateway для загрузки данных в блок промежуточного хранения, но они работают на базе кластера lakehouse. Когда вы загружаете данные из файлов, которые включают шаблон данных в имени файла, это позволяет кластеру lakehouse выполнять целевые операции со списками в S3, что значительно ускоряет время чтения списка файлов. Кроме того, Открытое озеро данных Qlik может предсказывать поступающие файлы на основе шаблона даты. Задача потокового промежуточного хранения не должна перечислять весь блок каждый раз, но вместо этого может запрашивать файлы из S3 в пределах определенного диапазона дат. Наличие меньшего списка файлов приводит к лучшей производительности. Необязательная настройка Удалить после загрузки может использоваться для поддержания небольшого количества файлов. Не выполняется полная загрузка, первые записи считаются вставленными изменениями. В Открытое озеро данных Qlik, задача преобразования потоковых данных заменяет задачу хранения данных. Эта задача используется для преобразования и хранения поступивших данных в виде таблиц Iceberg. Задача преобразования потока может быть добавлена только после задачи промежуточного хранения потока. Задача потокового преобразования поддерживает два режима обновления записей: * Только добавление: Добавляет новые записи без изменения существующих данных, и ограничения ключа не применяются, если поступают дублирующиеся записи. * Применить изменения (Объединить): Обновляет существующие записи и вставляет новые записи на основе ключевых полей. Этот режим позволяет использовать мягкое удаление или сохранять исторические данные (тип 2). Задача преобразования потоковых данных является задачей, основанной на целевом объекте, которая сопоставляет данные между источником и целевым объектом и включает возможности эволюции схемы. Он предоставляет расширенные возможности преобразования, включая развертывание вложенных структур и выравнивание массивов. Для получения дополнительной информации о функциях, которые можно использовать в задаче Steaming Transform, см. [Функции преобразования](https://help.qlik.com/ru-RU/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/transformation-functions.htm). При приеме данных из потокового источника вы можете настроить разделение Iceberg, управление хранением, сортировку столбцов, срок действия снимков для контроля затрат на хранение и оптимизации производительности запросов. Архитектура для потокового Открытое озеро данных Qlik конвейера данных в режиме только добавления Архитектура для потокового Открытое озеро данных Qlik конвейера данных в режиме только добавления Архитектура для потокового Открытое озеро данных QlikОткрытое озеро данных Qlik конвейера данных в режиме только добавления ![Open lakehouse architecture in append only mode](https://help.qlik.com/ru-RU/cloud-services/Subsystems/Hub/Content/Resources/Images/open_lakehouse_streaming_append.png) Архитектура для потокового Открытое озеро данных Qlik конвейера данных в режиме слияния Архитектура для потокового Открытое озеро данных Qlik конвейера данных в режиме слияния Архитектура для потокового Открытое озеро данных QlikОткрытое озеро данных Qlik конвейера данных в режиме слияния ![Open lakehouse architecture in merge mode](https://help.qlik.com/ru-RU/cloud-services/Subsystems/Hub/Content/Resources/Images/open_lakehouse_streaming_merge.png) ## Промежуточные таблицы Следующие поля заголовков добавляются в таблицы промежуточного хранения. Эти столбцы всегда существуют в данных промежуточного хранения, но не включаются в последующую задачу преобразования потока по умолчанию. Вы можете добавить их в задачу потокового преобразования, используя Добавить столбец из источника, или ссылаться на них в построителе выражений при добавлении или редактировании столбца. Столбцы заголовков добавлены для источников Kafka | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_kafka\_partition | Long (Длинный) | Раздел Kafka | | hdr\_\_kafka\_topic | Строка | Топик Kafka | | hdr\_\_kafka\_offset | Long (Длинный) | Нарастающее значение в разделе | | hdr\_\_kafka\_key | Строка | Base64-закодированный ключ. Установить в NULL строку, если недоступно. | | hdr\_\_kafka\_headers | Строка | JSON со всеми заголовками сообщений. Установить в NULL-строку, если недоступно. | Добавлены столбцы заголовков для источников Amazon Kinesis | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_kinesis\_stream | Строка | Amazon Kinesis поток | | hdr\_\_kinesis\_shard | Строка | Amazon Kinesis сегмент | | hdr\_\_kinesis\_offset | Строка | Amazon Kinesis смещение | Столбцы заголовков добавлены для источников Amazon S3 | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_file\_name | Строка | Имя файла | | hdr\_\_file\_size | Long (Длинный) | Размер файла в байтах. | ## Схемы Артефакты генерируются во внутренних схемах, а также в схемах задач данных. * Внутренняя схема содержит физическую таблицу с несколькими разделами. * Схема задач данных содержит виды, которые можно использовать для работы с данными. Когда схема связана с несколькими задачами данных, каждая задача данных должна использовать уникальный префикс для таблиц и видов. Префикс можно настроить в параметрах задачи данных. Только внутренние схемы проверяются на предмет конфликтов имен. Для других схем необходимо убедиться в отсутствии конфликтов имен в именах таблиц. Рекомендуется использовать для внутренней схемы то же имя, что для схемы задачи данных, добавив \_internal. Это сделает комбинацию схемы и префикса уникальной. Примечание к информацииВсеми таблицами и видами управляет Qlik Talend Data Integration. Не используйте другие инструменты для изменения данных. ## Таблицы Для каждой таблицы-источника во внутренней схеме создается таблица с суффиксом \_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 раздел | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_хеш\_ключа | VARBINARY (20) | Хэш всех первичных ключей записей. Формат хэша — SHA1. Столбцы разделяются символом backspace. | | hdr\_\_from\_timestamp | TIMESTAMP | Метка времени в формате UTC:

| | hdr\_\_операция | VARCHAR (1) | Последняя операция по этой записи.

| | hdr\_\_вставленная\_Метка времени | TIMESTAMP | Временная метка (UTC) первого добавления ключа. Если используется полная загрузка, начальное время полной нагрузки. | | hdr\_\_modified\_timestamp | TIMESTAMP | Временная метка в формате UTC последнего обновления. | ### Prior раздел | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_хеш\_ключа | VARBINARY (20) | Хэш всех первичных ключей записей. | | hdr\_\_from\_timestamp | TIMESTAMP | Метка времени в формате UTC. | | hdr\_\_to\_timestamp | TIMESTAMP | Метка времени в формате UTC. | | hdr\_\_операция | STRING (1) | Последняя операция по этой записи.

| | hdr\_\_was\_current\_from\_timestamp | TIMESTAMP | Временная метка в формате UTC, указывающая, когда впервые запись была текущей. | | hdr\_\_была\_текущей\_до\_Метка времени | TIMESTAMP | Временная метка в формате UTC, указывающая, когда в последний раз запись была текущей. | ### Changes раздел | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_change\_identifier | VARCHAR (50) | Идентификатор изменения представляет собой строку, которая состоит из двух частей:

| | hdr\_\_операция | VARCHAR (1) | Последняя операция по этой записи.

| | hdr\_\_timestamp | TIMESTAMP | Метка времени в формате UTC. | | hdr\_\_хеш\_ключа | BINARY (20) | Хэш всех первичных ключей записей. | | hdr\_\_вставленная\_Метка времени | TIMESTAMP | Метка времени UTC, соответствующая времени, когда изменение было обработано в Qlik. | ### Asset\_state раздел | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_apply\_change\_identifier | VARCHAR (50) | Идентификатор последнего изменения, примененного к разделу Current текущих данных. | | hdr\_\_copy\_change\_identifier | VARCHAR (50) | Идентификатор последнего изменения, добавленного в раздел Changes текущих данных. | ### Reload раздел Столбцы в Reload разделе аналогичны столбцам в Current разделе. ## Виды Все созданные виды обновляются практически в режиме реального времени. Следующие виды позволяют упростить работу с запросами и отчетами: ### Текущие данные В виде «Текущие данные» показано самое последнее состояние данных. Это представление представляет собой копию исходной таблицы, обновляемую практически в режиме реального времени. В нем объединены данные из разделов Current и Changes. Имя: <EXTERNAL\_SCHEMA>.[<PREFIX>]<TABLE\_NAME> В структуру таблицы не добавляются поля заголовков. ### История Вид «История» генерируется в схеме ресурсов данных по каждой выбранной исходной таблице, если в настройках задачи данных активен параметр «История». Представление истории объединяет данные из раздела Prior и раздела Changes. В нем представлена полная история изменений, поэтому этот вид идеально подходит для аудита или исторического анализа. Имя: <EXTERNAL\_SCHEMA>.[<PREFIX>]<TABLE\_NAME>\_<Suffix for history views> В вид «История» добавляются следующие поля заголовков. | Поле | Тип | Описание | | --- | --- | --- | | hdr\_\_хеш\_ключа | BINARY (20) | Хэш всех первичных ключей записей. | | hdr\_\_from\_timestamp | TIMESTAMP | Метка времени, когда изменение произошло в системе-источнике. Соответствует времени, когда пользователь в первый раз сделал изменение. | | hdr\_\_to\_timestamp | TIMESTAMP | Метка времени, когда изменение было отменено или обновлено в системе-источнике. | | hdr\_\_store | VARCHAR (10) | Указывает, где находится запись:

| | hdr\_\_операция | STRING (1) | Последняя операция по этой записи.

| | hdr\_\_deleted | BIT | Указывает, является ли запись обратимо удаленной (в зависимости от того, имеет ли hdr\_\_operation значение D или d). | | hdr\_\_was\_current\_from\_timestamp | TIMESTAMP | Время (UTC), когда эта строка попала в Current раздел. Обычно это происходит, когда выполнялась задача хранения и было применено изменение. | | hdr\_\_была\_текущей\_до\_Метка времени | TIMESTAMP | Время (UTC), когда строка была удалена из Current таблицы, например, в связи с появлением новой версии. | Примечание к информацииВиды «Текущие данные» и «История» формируются по данным из Changes раздела и всегда меняются в режиме, близком к реальному времени. Однако низкая производительность запросов может быть вызвана накоплением большого количества изменений, не примененных к Current или Prior разделам. Необъединенные дельты обрабатываются дольше во время запроса, что замедляет доступ. ### Отображение столбцов заголовков в представлениях Вы можете управлять отображением или скрытием столбцов заголовка. Параметры отличаются в зависимости от типа задачи. Примечание к информацииСтолбцы заголовков автоматически заполняются данными и доступны только для чтения. #### Задача потокового промежуточного хранения Чтобы показать столбцы заголовков, включите Показать столбцы заголовков справа от поля поиска. #### Задача потокового преобразования Раскрывающийся список со следующими параметрами доступен справа от поля поиска. * Скрыть столбцы заголовков: По умолчанию. * Показать столбцы заголовков * Стандартный: Выберите, чтобы отобразить столбцы заголовков для стандартных видов. * История: Выберите, чтобы отобразить столбцы заголовков для представлений истории. Обратите внимание, что эта опция будет доступна только если Создать хранилище исторических данных (тип 2) включена в настройках задачи или набора данных. Описание доступных столбцов заголовка см. [Промежуточные таблицы](https://help.qlik.com/ru-RU/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/lakehouse-datasets-architecture-streaming.htm#Landing) и [Виды](https://help.qlik.com/ru-RU/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/lakehouse-datasets-architecture-streaming.htm#Views). Govnote-not-inНе поддерживается в Qlik Cloud для правительства.