# Arquitectura de conjunto de datos para fuentes de streaming en un Qlik Open Lakehouse Las fuentes de streaming tienen su propia arquitectura en Qlik Open Lakehouse, ya que no requieren la pasarela de datos Data Movement gateway para cargar datos en el depósito de destino, sino que funcionan con el clúster del lakehouse. Cuando ingiere datos de archivos que incluyen un patrón de datos en el nombre del archivo, esto permite al clúster del lakehouse realizar operaciones de lista dirigidas en S3, lo que acelera drásticamente el tiempo de lectura de la lista de archivos. Además, Qlik Open Lakehouse puede predecir los archivos entrantes basándose en el patrón de fecha. La tarea de destino de streaming no tiene que mostrar todo el depósito cada vez, sino que puede solicitar los archivos de S3 dentro de un rango de fechas específico. Tener una lista de archivos más pequeña conduce a un mejor rendimiento. La configuración opcional Eliminar después de la carga se puede usar para mantener un recuento de archivos pequeño. No se realiza ninguna Carga completa, los primeros registros se consideran cambios insertados. En un Qlik Open Lakehouse, la tarea de transformación de streaming reemplaza la tarea de almacenamiento. Esta tarea se utiliza para transformar y almacenar datos de destino como tablas Iceberg. Una tarea de transformación de streaming solo se puede añadir después de una tarea de destino de streaming. La tarea de transformación de streaming admite dos modos para actualizar registros: * Solo anexar: agrega nuevos registros sin modificar los datos existentes y las restricciones de clave no se aplican si llegan registros duplicados. * Aplicar cambios (Combinar): actualiza los registros existentes e inserta nuevos registros basándose en campos clave. Este modo le ofrece la opción de usar una eliminación lógica o retener datos históricos (Tipo 2). La tarea de transformación de streaming es una tarea basada en destino, que asocia entre origen y destino e incluye capacidades de evolución de esquema. Proporciona capacidades de transformación ampliadas, incluyendo la desanidación de estructuras anidadas y el aplanamiento de matrices. Para obtener más información sobre las funciones que puede utilizar en la tarea de transformación de streaming, consulte [Funciones de transformación](https://help.qlik.com/es-ES/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/transformation-functions.htm). Cuando ingiere datos desde una fuente de transmisión o streaming, tiene la capacidad de configurar la partición de Iceberg, la gestión de retención, el orden de las columnas, la caducidad de las capturas para controlar los costes de almacenamiento y optimizar el rendimiento de las consultas. Arquitectura para una canalización de datos en streaming de Qlik Open Lakehouse en modo solo anexar Arquitectura para una canalización de datos en streaming de Qlik Open Lakehouse en modo solo anexar Arquitectura para una canalización de datos en streaming de Qlik Open LakehouseQlik Open Lakehouse en modo solo anexar ![Arquitectura de lakehouse abierta en modo solo anexar](https://help.qlik.com/es-ES/cloud-services/Subsystems/Hub/Content/Resources/Images/open_lakehouse_streaming_append.png) Arquitectura para un proceso de datos de Qlik Open Lakehouse en modo de fusión Arquitectura para un proceso de datos de Qlik Open Lakehouse en modo de fusión Arquitectura para un proceso de datos de Qlik Open LakehouseQlik Open Lakehouse en modo de fusión ![Arquitectura de lakehouse abierta en modo de fusión](https://help.qlik.com/es-ES/cloud-services/Subsystems/Hub/Content/Resources/Images/open_lakehouse_streaming_merge.png) ## Tablas de destino Las siguientes columnas de encabezado se añaden a las tablas de destino. Estas columnas siempre existen en los datos de destino, pero no se incluyen en la tarea de transformación de streaming posterior por defecto. Puede añadirlos a la tarea de transformación de streaming usando Añadir columna desde el origen, o hacer referencia a ellos en el generador de expresiones al añadir o editar una columna. Columnas de encabezado añadidas para fuentes de Kafka | Campo | Tipo | Descripción | | --- | --- | --- | | hdr\_\_kafka\_partition | Long | Partición de Kafka | | hdr\_\_kafka\_topic | Cadena | Tema de Kafka | | hdr\_\_kafka\_offset | Long | Valor en ejecución en la partición | | hdr\_\_kafka\_key | Cadena | Clave codificada en Base64. Establecer en cadena NULL si no está disponible. | | hdr\_\_kafka\_headers | Cadena | JSON con todos los encabezados de mensaje. Establecer en cadena NULL si no está disponible. | Columnas de encabezado añadidas para fuentes de Amazon Kinesis | Campo | Tipo | Descripción | | --- | --- | --- | | hdr\_\_kinesis\_stream | Cadena | Flujo de Amazon Kinesis | | hdr\_\_kinesis\_shard | Cadena | Fragmento de Amazon Kinesis | | hdr\_\_kinesis\_offset | Cadena | Desplazamiento de Amazon Kinesis | Columnas de encabezado añadidas para fuentes de Amazon S3 | Campo | Tipo | Descripción | | --- | --- | --- | | hdr\_\_file\_name | Cadena | Nombre de archivo | | hdr\_\_file\_size | Long | Tamaño del archivo en bytes. | ## 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. Nota informativaTodas las tablas y vistas son administradas por Qlik Talend Data Integration. No modifique los datos con otras herramientas. ## 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 en modo Aplicar cambios (Combinar), 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. En modo Solo anexar, la tabla no tiene particiones y se comporta como la partición Current (ODS). Nota informativaLa tabla del esquema interno está sujeta a cambios sin previo aviso. Debe utilizar principalmente vistas para consumir datos siempre que sea posible. 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 Changes – Ingesta en tiempo real Todos los cambios del sistema fuente —inserciones, actualizaciones y eliminaciones— se añaden primero a la partición Changes. * 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 prácticamente en tiempo real. * La partición Changes 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 Changes. * Cuándo se aplicaron por última vez los cambios a la partición Current. Esto ofrece una visibilidad completa de toda la canalización o proceso de sincronización y ayuda a supervisar o solucionar los retrasos. * La partición Current (ODS) – Última réplica de la fuente Los cambios de la partición Changes se aplican periódicamente a la partición Current a fin de mantener una copia actualizada y optimizada para consultas 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 definido. * La carga completa inicial se escribe directamente en la partición Current. * Esta partición refleja el estado actual de los datos y se ha diseñado para una consulta eficaz. * La partición Prior (HDS) – Datos históricos Cuando se actualiza o elimina un registro en la partición Current, se escribe una copia de la versión anterior en la partición Prior. * 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 Prior está disponible cuando Conservar registros históricos y archivo de registros de cambios está activo 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 Current, el registro anterior se traslada a la partición Prior para realizar un seguimiento histórico. * La partición Reload La partición Reload actúa como un área de espera temporal durante las recargas completas manuales o programadas: * Los nuevos datos se escriben primero en la partición Reload. * Las tareas de mantenimiento regulares borran cualquier cambio pendiente antes de que se pongan en pausa. * Los datos se comparan con la partición Current y solo las diferencias se trasladan a la partición Current. * La partición Reload 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. ### La partición Current | 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. | ### La partición Prior | 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. | ### La partición Changes | Campo | Tipo | Descripción | | --- | --- | --- | | hdr\_\_change\_identifier | VARCHAR (50) | El identificador de cambio es una cadena de caracteres 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. | ### La partición Asset\_state | Campo | Tipo | Descripción | | --- | --- | --- | | hdr\_\_apply\_change\_identifier | VARCHAR (50) | El identificador del último cambio aplicado a la partición Current. | | hdr\_\_copy\_change\_identifier | VARCHAR (50) | El identificador del último cambio añadido a la partición Changes. | ### La partición Reload Las columnas utilizadas por la partición Reload son idénticas a las de la partición Current. ## 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 prácticamente en tiempo real. Fusiona los datos de las particiones Current y Changes. 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 de Historial fusiona los datos de las particiones Prior y Changes. Ofrece 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 Current. 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 Current, por ejemplo, debido a una versión más reciente. | Nota informativaLas vistas de Actual e Historial se basan en la partición Changes y siempre están cerca del tiempo real. Sin embargo, si experimenta un rendimiento lento en las consultas, puede deberse a un gran número de cambios que aún no se han aplicado en las particiones Current o Prior. Los deltas no fusionados requieren más procesamiento en el momento de la consulta, lo que hace que el acceso sea más lento. ### Mostrar columnas de encabezado en vistas Puede controlar si se muestran u ocultan las columnas de encabezado. Las opciones varían según el tipo de tarea. Nota informativaLas columnas de encabezado se rellenan automáticamente con datos y son de solo lectura. #### Tarea de aterrizaje de streaming Para mostrar las columnas de encabezado, active Mostrar columnas de encabezado a la derecha del cuadro de búsqueda. #### Tarea de transformación de streaming A la derecha del cuadro de búsqueda hay disponible una lista desplegable con las siguientes opciones. * Ocultar columnas de cabecera:El valor predeterminado. * Mostrar columnas de cabecera * Estándar:selecciónelo para mostrar las columnas de cabecera en las vistas estándar. * Historial: selecciónelo para mostrar las columnas de encabezado para las vistas de historial. Tenga en cuenta que esta opción solo estará disponible si Crear un almacén de datos históricos (Tipo 2) está habilitado en la configuración de la tarea o del conjunto de datos. Para una descripción de las columnas de encabezado disponibles, vea [Tablas de destino](https://help.qlik.com/es-ES/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/lakehouse-datasets-architecture-streaming.htm#Landing) y [Vistas](https://help.qlik.com/es-ES/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/lakehouse-datasets-architecture-streaming.htm#Views). Govnote-not-inNo compatible en Qlik Cloud Government.