Arquitectura del conjunto de datos en un Qlik Open Lakehouse
Cuando genera conjuntos de datos en un Qlik Open Lakehouse, las tablas de almacenamiento, las tablas de modificación y las vistas son generadas automáticamente por Qlik Talend Data Integration. Puede consultar estas vistas para acceder a los datos actuales e históricos almacenados en formato de tabla abierta Iceberg.
Una interfaz de usuario intuitiva y guiada le ayuda a construir, modelar y ejecutar canalizaciones de datos. Puede generar automáticamente esquemas para almacenes de datos operativos (ODS) y almacenes de datos históricos (HDS) sin codificación manual.
Arquitectura para una canalización de datos de Qlik Open Lakehouse que utiliza Pasarela de movimiento de datos de Qlik. Los datos aterrizan en S3 y se almacenan un lakehouse abierto Iceberg. Opcionalmente, como se muestra a continuación, las tablas pueden reflejarse en un almacén de datos.

Esquemas
Los artefactos se generan en un esquema interno y un esquema de tarea de datos.
-
El esquema interno contiene una tabla física con múltiples particiones.
-
El esquema de tarea de datos contiene las vistas que puede usar para consumir los datos.
Cuando un esquema de base de datos está asociada a más de una tarea de datos, cada tarea de datos ha de utilizar un prefijo único para tablas y vistas. Puede fijar el prefijo en la configuración de la tarea de datos.
Solo los esquemas internos se comprueban en busca de conflictos de nombres. Para otros esquemas, debe asegurarse de que no existan conflictos de denominación en los nombres de las tablas. La práctica recomendada es asignar al esquema interno el mismo nombre que al esquema de la tarea de datos y añadir _interno. Esto garantiza que cada combinación de esquema y prefijo sea única.
Tablas
Para cada tabla fuente, se crea una tabla en el esquema interno con el sufijo _internal, utilizando el formato:
<INTERNAL_SCHEMA>.<TABLE_NAME>_internal
Esta tabla contiene cinco particiones, cada una de las cuales cumple una función distinta en la forma en que se procesan y almacenan los datos. Cada partición aprovecha un subconjunto de columnas de la tabla en función de su papel en el ciclo de vida de los datos.
El conjunto de datos interno está estructurado para gestionar eficazmente los datos entrantes de su sistema fuente, admitiendo la ingesta en tiempo real y el seguimiento histórico. El flujo de datos se gestiona a través de varias particiones especializadas, cada una de las cuales se describe a continuación:
-
La partición Cambios - Ingesta en tiempo real
Todos los cambios del sistema fuente: inserciones, actualizaciones y eliminaciones, se añaden primero a la partición Cambios.
-
Actuando como un registro de cambios en bruto, la partición proporciona una alimentación completa de la actividad de la fuente antes de que se produzca cualquier transformación.
-
Cada cambio se etiqueta con un tipo (I, U o D), que indica cómo se procesa.
-
Los eventos se capturan desde la fuente a medida que se producen. La partición se actualiza casi en tiempo real.
-
La partición Cambios está disponible cuando se aplican los siguientes ajustes en la tarea de aterrizaje de datos en el lago.
-
En la pestaña General, el método de actualización debe ser CDC.
-
La Carga completa debe estar activada.
-
-
-
La partición Asset_state - Seguimiento del progreso
A medida que se ingieren los cambios, la partición Asset_state registra dos marcas de tiempo clave:
-
Cuándo se añadieron por última vez los cambios a la partición Cambios.
-
Cuándo se aplicaron los cambios por última vez a la partición actual.
Esto proporciona una visibilidad completa de toda la canalización de sincronización y ayuda a supervisar o solucionar los retrasos.
-
-
La partición Actual (ODS) – Última réplica de la fuente
Los cambios de la partición Cambios se aplican periódicamente a la partición Actual para mantener una copia actualizada y optimizada de los datos fuente.
-
Una tarea en segundo plano se ejecuta automáticamente para aplicar esas actualizaciones. Esto se basa en el volumen de cambios acumulados, más que en un calendario fijo.
-
La Carga completa inicial se escribe directamente en la partición Actual.
-
Esta partición refleja el estado actual de los datos y está diseñada para una consulta eficaz.
-
-
La partición Previa (HDS) - Datos históricos
Cuando se actualiza o elimina un registro en la partición Actual, se escribe una copia de la versión anterior en la partición Anterior.
-
Los registros contienen metadatos, incluido el historial de cambios y el intervalo de fechas en que los datos son válidos.
-
Esto es compatible con el tipo 2 de dimensión que cambia lentamente (SCD2).
-
La partición Anterior está disponible cuando se activa Conservar registros históricos y archivo de registros de cambios en la pestaña General de la configuración de la tarea de almacenamiento de datos.
-
Cuando una versión actualizada de un registro entra en la partición Actual, el registro anterior se traslada a la partición Anterior para realizar un seguimiento histórico.
-
-
La partición Recarga
La partición de recarga actúa como zona de espera temporal durante las recargas completas manuales o programadas:
-
Los nuevos datos se escriben primero en la partición de recarga.
-
Las tareas de mantenimiento regulares borran cualquier cambio pendiente antes de que se pongan en pausa.
-
Los datos se comparan con la partición Actual, y solo las diferencias se trasladan a la partición Actual.
-
La partición Recargar se borra cuando finaliza la operación.
Este proceso garantiza una interrupción mínima del conjunto de datos principal durante las operaciones de recarga completa.
-
Partición actual
| Campo | Tipo | Descripción |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash de todas las claves primarias del registro. El formato de hash es SHA1. Las columnas van separadas por un carácter de retroceso. |
| hdr__from_timestamp | TIMESTAMP |
Fecha-hora en UTC:
|
| hdr__operation | VARCHAR (1) |
Última operación de este registro.
|
| hdr__inserted_timestamp | TIMESTAMP | Marca de tiempo UTC de la primera vez que se agregó la clave. Cuando se usa carga completa, la hora de inicio de la carga completa. |
| hdr__modified_timestamp | TIMESTAMP | Fecha-hora UTC de cuando se realizó la última actualización. |
Partición Previa
| Campo | Tipo | Descripción |
|---|---|---|
| hdr__key_hash | VARBINARY (20) | Hash de todas las claves primarias del registro. |
| hdr__from_timestamp | TIMESTAMP | Fecha-hora en UTC. |
| hdr__to_timestamp | TIMESTAMP | Fecha-hora en UTC. |
| hdr__operation | STRING (1) |
Última operación de este registro.
|
| hdr__was_current_from_timestamp | TIMESTAMP | Fecha-hora en UTC de la primera vez que el registro fue actual. |
| hdr__was_current_to_timestamp | TIMESTAMP | Fecha-hora en UTC de la última vez que el registro fue actual. |
Partición Cambios
| Campo | Tipo | Descripción |
|---|---|---|
| hdr__change_identifier | VARCHAR (50) |
El identificador de cambio es una cadena con dos partes:
|
| hdr__operation | VARCHAR (1) |
Última operación de este registro.
|
| hdr__timestamp | TIMESTAMP | Fecha-hora en UTC. |
| hdr__key_hash | BINARY (20) | Hash de todas las claves primarias del registro. |
| hdr__inserted_timestamp | TIMESTAMP | Fecha-hora UTC del momento en que el cambio fue procesado por Qlik. |
Partición Asset_state
| Campo | Tipo | Descripción |
|---|---|---|
| hdr__apply_change_identifier | VARCHAR (50) | El identificador del último cambio aplicado a la partición Actual. |
| hdr__copy_change_identifier | VARCHAR (50) | El identificador del último cambio añadido a la partición de Cambios. |
Partición de Recarga
Las columnas utilizadas por la partición Recarga son idénticas a las de la partición Actual.
Vistas
Todas las vistas creadas se actualizan casi en tiempo real. Las siguientes vistas están disponibles para simplificar la consulta y la elaboración de informes:
Actual
La vista Actual refleja el estado más reciente de los datos. Esta vista representa una réplica de la tabla de origen, actualizada casi en tiempo real. Fusiona los datos de las particiones Actual y Cambios.
Nombre: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>
No se añaden columnas de cabecera a la estructura de la tabla.
Historial
Se genera una vista del Historial en el esquema del activo de datos para cada tabla de origen seleccionada cuando se activa el Historial en los ajustes de la tarea de datos. La vista Historial fusiona los datos de las particiones Anterior y Cambios. Proporciona una cronología completa de los cambios, ideal para auditorías o análisis históricos.
Nombre: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>
Los siguientes campos de cabecera se añaden a la vista del Historial:
| Campo | Tipo | Descripción |
|---|---|---|
| hdr__key_hash | BINARY (20) | Hash de todas las claves primarias del registro. |
| hdr__from_timestamp | TIMESTAMP | La fecha-hora en que se produjo el cambio en el sistema fuente. Esto refleja el momento en que el usuario realizó el cambio originalmente. |
| hdr__to_timestamp | TIMESTAMP | La fecha-hora en que se anuló o actualizó el cambio en el sistema fuente. |
| hdr__store | VARCHAR (10) |
Indica dónde reside el registro:
|
| hdr__operation | STRING (1) |
Última operación de este registro.
|
| hdr__deleted | BIT | Indica si el registro se elimina temporalmente, en función de si la operación hdr__ es D o d. |
| hdr__was _current_from_timestamp | TIMESTAMP | La hora (UTC) en que esta fila entró en la partición Actual. Esto suele ocurrir cuando se ejecuta el trabajo de almacenamiento y se aplica el cambio. |
| hdr__was _current_to_timestamp | TIMESTAMP | La hora (UTC) en que se eliminó la fila de la tabla Actual, por ejemplo, debido a que hay una versión más reciente. |