# Architektura zestawu danych dla źródeł strumieniowych w Otwarty lakehouse Qlik

Źródła strumieniowe mają własną architekturę w Otwarty lakehouse Qlik, ponieważ nie wymagają Data Movement gateway do ładowania danych do zasobnika umieszczania, ale są zasilane przez klaster lakehouse.

Gdy pozyskujesz dane z plików, które zawierają wzorzec danych w nazwie pliku, umożliwia to klastrowi lakehouse wykonywanie ukierunkowanych operacji listowania w S3, co znacznie przyspiesza czas odczytu listy plików. Ponadto, Otwarty lakehouse Qlik może przewidywać nadchodzące pliki na podstawie wzorca daty. Zadanie umieszczania strumieniowego nie musi za każdym razem wyświetlać całej zawartości zasobnika, ale zamiast tego może żądać plików z S3 w określonym zakresie dat. Mniejsza lista plików prowadzi do lepszej wydajności. Opcjonalne Usuń po załadowaniu ustawienie może być użyte do utrzymania małej liczby plików. Nie jest wykonywane pełne ładowanie, pierwsze rekordy są traktowane jako wstawione zmiany.

W Otwarty lakehouse Qlik, zadanie transformacji strumieniowej zastępuje zadanie przechowywania. To zadanie służy do transformowania i przechowywania pozyskanych danych jako tabele Iceberg. Zadanie transformacji strumieniowej może być dodane tylko po zadaniu umieszczania strumieniowego. Zadanie transformacji strumieniowej obsługuje dwa tryby aktualizacji rekordów:

* Tylko dołączanie: Dodaje nowe rekordy bez modyfikowania istniejących danych, a ograniczenia klucza nie są wymuszane, jeśli pojawią się zduplikowane rekordy.

* Zastosuj zmiany (Scal): Aktualizuje istniejące rekordy i wstawia nowe rekordy na podstawie pól kluczowych. Ten tryb daje możliwość użycia miękkiego usuwania lub zachowania danych historycznych (typ 2).

Zadanie transformacji strumieniowej jest zadaniem opartym na obiekcie docelowym, które mapuje między obiektem źródłowym a obiektem docelowym i obejmuje możliwości ewolucji schematu. Zapewnia rozszerzone możliwości transformacji, w tym rozwijanie zagnieżdżonych struktur i spłaszczanie tablic. Więcej informacji na temat funkcji, których można używać w zadaniu Steaming Transform, zobacz [Funkcje transformacji](https://help.qlik.com/pl-PL/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/transformation-functions.htm).

Podczas pozyskiwania danych ze źródła strumieniowego masz możliwość skonfigurowania partycjonowania Iceberg, zarządzania przechowywaniem, sortowania kolumn, wygasania migawek w celu kontroli kosztów przechowywania i optymalizacji wydajności zapytań.

Architektura dla strumieniowego potoku danych Otwarty lakehouse Qlik w trybie tylko dołączania

Architektura dla strumieniowego potoku danych Otwarty lakehouse Qlik w trybie tylko dołączania

Architektura dla strumieniowego potoku danych Otwarty lakehouse QlikOtwarty lakehouse Qlik w trybie tylko dołączania ![Open lakehouse architecture in append only mode](https://help.qlik.com/pl-PL/cloud-services/Subsystems/Hub/Content/Resources/Images/open_lakehouse_streaming_append.png)

Architektura dla strumieniowego potoku danych Otwarty lakehouse Qlik w trybie scalania

Architektura dla strumieniowego potoku danych Otwarty lakehouse Qlik w trybie scalania

Architektura dla strumieniowego potoku danych Otwarty lakehouse QlikOtwarty lakehouse Qlik w trybie scalania ![Open lakehouse architecture in merge mode](https://help.qlik.com/pl-PL/cloud-services/Subsystems/Hub/Content/Resources/Images/open_lakehouse_streaming_merge.png)

## Tabele związane z umieszczaniem

Do tabel umieszczania dodawane są następujące kolumny nagłówka. Te kolumny zawsze istnieją w danych umieszczania, ale nie są domyślnie uwzględniane w późniejszym zadaniu transformacji strumieniowej. Możesz dodać je do zadania przekształcania strumieniowego, używając Dodaj kolumnę ze źródła, lub odwołać się do nich w konstruktorze wyrażeń podczas dodawania lub edytowania kolumny.

Kolumny nagłówkowe dodane dla źródeł Kafka

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_kafka\_partition | LONG | Partycja Kafka |
| hdr\_\_kafka\_topic | Ciąg znaków | Temat Kafka |
| hdr\_\_kafka\_offset | LONG | Narastająca wartość w partycji |
| hdr\_\_kafka\_key | Ciąg znaków | Klucz zakodowany w Base64. Ustaw na wartość NULL, jeśli niedostępne. |
| hdr\_\_kafka\_headers | Ciąg znaków | JSON ze wszystkimi nagłówkami wiadomości. Ustaw na ciąg znaków NULL, jeśli niedostępne. |

Dodano kolumny nagłówkowe dla źródeł Amazon Kinesis

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_kinesis\_stream | Ciąg znaków | Amazon Kinesis strumień |
| hdr\_\_kinesis\_shard | Ciąg znaków | Amazon Kinesis fragment |
| hdr\_\_kinesis\_offset | Ciąg znaków | Amazon Kinesis przesunięcie |

Dodano kolumny nagłówka dla źródeł Amazon S3

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_file\_name | Ciąg znaków | Nazwa pliku |
| hdr\_\_file\_size | LONG | Rozmiar pliku w bajtach. |

## Schematy

Artefakty są generowane w schemacie wewnętrznym i schemacie zadania danych.

* Schemat wewnętrzny zawiera fizyczną tabelę z wieloma partycjami.

* Schemat zadania danych zawiera widoki, które można wykorzystać do korzystania z danych.

  Gdy schemat jest powiązany z więcej niż jednym zadaniem danych, każde zadanie danych musi używać unikatowego prefiksu dla tabel i widoków. Prefiks można ustawić w ustawieniach zadania danych.

Tylko schematy wewnętrzne są sprawdzane pod kątem konfliktów nazw. W przypadku innych schematów należy sprawdzić, czy w nazwach tabel nie występują konflikty nazw. Najlepsza praktyka polega na nadawaniu schematowi wewnętrznemu takiej samej nazwy jak schematowi zadania danych z dodanym elementem \_internal. To skutecznie zapewni, że każda kombinacja schematu i prefiksu będzie unikatowa.

InformacjaWszystkimi tabelami i widokami zarządza Qlik Talend Data Integration. Nie zmieniaj danych przy użyciu innych narzędzi.

## Tabele

Dla każdej tabeli źródłowej tworzona jest tabela w schemacie wewnętrznym z przyrostkiem \_internal, przy użyciu formatu:

<INTERNAL\_SCHEMA>.<TABLE\_NAME>\_internal

Tabela ta zawiera pięć partycji w trybie Zastosuj zmiany (Scalanie), każda służąca odrębnemu celowi w zakresie przetwarzania i przechowywania danych. Każda partycja wykorzystuje podzbiór kolumn tabeli na podstawie jej roli w cyklu życia danych. W trybie tylko do dołączania tabela nie ma partycji i zachowuje się jak bieżąca partycja (ODS).

InformacjaTabele w schemacie wewnętrznym mogą ulec zmianie bez powiadomienia. Tam, gdzie to możliwe, należy przede wszystkim używać widoków do korzystania z danych.

Wewnętrzny zbiór danych ma strukturę umożliwiającą efektywne zarządzanie danymi przychodzącymi z systemu źródłowego, wspierając pozyskiwanie danych w czasie rzeczywistym i śledzenie danych historycznych. Przepływ danych jest zarządzany przez kilka wyspecjalizowanych partycji, z których każda została opisana poniżej:

* Partycja zmian – pozyskiwanie w czasie rzeczywistym

  Wszystkie zmiany z systemu źródłowego – wpisy, aktualizacje i usunięcia – są najpierw dołączane do Partycji Changes zmian.

  * Działając jako surowy dziennik zmian, partycja zapewnia pełną informację o aktywności źródła przed wystąpieniem jakichkolwiek przekształceń.

  * Każda zmiana jest oznaczona typem (I, U lub D), wskazującym sposób jej przetwarzania.

  * Zdarzenia są przechwytywane ze źródła w momencie ich wystąpienia. Partycja jest aktualizowana niemal w czasie rzeczywistym.

  * Partycja Changes zmian jest dostępna po zastosowaniu następujących ustawień w zadaniu umieszczania danych w jeziorze.

    * W zakładce Ogólne opcja Metoda aktualizacji jest ustawiona na CDC.

    * Pełne ładowanie jest włączone.

* Partycja asset\_state – śledzenie postępu

  Po wprowadzeniu zmian partycja Asset\_state Asset\_state rejestruje dwa znaczniki czasu:

  * Kiedy zmiany zostały ostatnio dodane do partycji Changes.

  * Kiedy zmiany zostały ostatnio zastosowane do partycji Current.

  Zapewnia to pełny wgląd w potok synchronizacji i pomaga w monitorowaniu lub rozwiązywaniu problemów z opóźnieniami.

* Bieżąca partycja (ODS) – najnowsza replika źródła

  Zmiany z partycji Changes są okresowo stosowane do partycji Current w celu utrzymania aktualnej, zoptymalizowanej pod kątem zapytań kopii źródła danych.

  * Zadanie w tle działa automatycznie, aby zastosować te aktualizacje. Jest to oparte na ilości skumulowanych zmian, a nie na ustalonym harmonogramie.

  * Początkowe pełne ładowanie jest zapisywane bezpośrednio w partycji Current.

  * Partycja ta odzwierciedla aktualny stan danych i została zaprojektowana z myślą o wydajnym wyszukiwaniu.

* Wcześniejsza partycja (HDS) – dane historyczne

  Gdy rekord jest aktualizowany lub usuwany w Current partycji, kopia poprzedniej wersji jest zapisywana w Prior partycji.

  * Rekordy zawierają metadane, w tym historię zmian i zakres dat, kiedy dane są ważne.

  * Obsługiwane są powoli zmieniające się wymiary typu 2 (SCD2).

  * Partycja Prior jest dostępna, gdy opcja Zachowaj rekordy historyczne i archiwizuj rekordy zmian jest włączona na karcie Ogólne w ustawieniach zadania przechowywania danych.

  * Gdy zaktualizowana wersja rekordu wchodzi do Current partycji, poprzedni rekord jest przenoszony do Prior partycji w celu śledzenia historycznego.

* Partycja przeładowania

  Partycja Reload działa jako tymczasowy obszar przejściowy podczas ręcznego lub zaplanowanego pełnego przeładowania:

  * Nowe dane są najpierw zapisywane w partycji Reload.

  * Regularne zadania konserwacyjne czyszczą wszelkie oczekujące zmiany przed ich wstrzymaniem.

  * Dane są porównywane z partycją Current i tylko różnice są przenoszone do partycji Current.

  * Partycja Reload jest czyszczona po zakończeniu operacji.

  Proces ten zapewnia minimalne zakłócenia głównego zbioru danych podczas operacji pełnego przeładowania.

### Current partycja

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_key\_hash | VARBINARY (20) | Skrót wszystkich kluczy podstawowych rekordów. Format skrótu to SHA1. Kolumny są oddzielone znakiem cofania. |
| hdr\_\_from\_timestamp | TIMESTAMP | Znacznik czasu w UTC:<br><br><ul> <li> <p>W przypadku danych pobranych z pełnego ładowania, jest to czas rozpoczęcia pełnego ładowania.</p> </li> <li> <p>W przypadku zmiany pochodzącej z <span>Changes</span> partycji, jest to pole znacznika czasu rekordu.</p> </li> </ul> |
| hdr\_\_operation | VARCHAR (1) | Ostatnia operacja tego rekordu.<br><br><ul> <li> <p>D – usunięte z <span>Changes</span> partycji.</p> </li> <li> <p>U – zaktualizowane z <span>Changes</span> partycji.</p> </li> <li> <p>I - wstawione z <span>Changes</span> partycji.</p> </li> <li> <p>L — wstawiono przez zadanie pełnego ładowania.</p> </li> <li> <p>d - usunięte z funkcji porównaj i zastosuj.</p> </li> <li> <p>u - zaktualizowane z funkcji porównaj i zastosuj.</p> </li> <li> <p>i – wstawione z funkcji porównania i zastosowania.</p> </li> </ul> |
| hdr\_\_inserted\_timestamp | TIMESTAMP | Znacznik czasowy UTC pierwszego dodania klucza. W przypadku korzystania z pełnego ładowania, czas rozpoczęcia pełnego ładowania. |
| hdr\_\_modified\_timestamp | TIMESTAMP | Znacznik czasu UTC określający, kiedy została zastosowana ostatnia aktualizacja. |

### Prior partycja

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_key\_hash | VARBINARY (20) | Skrót wszystkich kluczy podstawowych rekordów. |
| hdr\_\_from\_timestamp | TIMESTAMP | Znacznik czasu w UTC. |
| hdr\_\_to\_timestamp | TIMESTAMP | Znacznik czasu w UTC. |
| hdr\_\_operation | ŁAŃCUCH (1) | Ostatnia operacja tego rekordu.<br><br><ul> <li> <p>D – usunięte z <span>Changes</span> partycji.</p> </li> <li> <p>U – zaktualizowane z <span>Changes</span> partycji.</p> </li> <li> <p>I - wstawione z <span>Changes</span> partycji.</p> </li> <li> <p>L — wstawiono przez zadanie pełnego ładowania.</p> </li> <li> <p>d - usunięte z funkcji porównaj i zastosuj.</p> </li> <li> <p>u - zaktualizowane z funkcji porównaj i zastosuj.</p> </li> <li> <p>i – wstawione z funkcji porównania i zastosowania.</p> </li> </ul> |
| hdr\_\_był\_aktualny\_od\_znacznika\_czasu | TIMESTAMP | Znacznik czasu w UTC dla pierwszego razu, kiedy rekord był aktualny. |
| hdr\_\_był\_aktualny\_do\_znacznika\_czasu | TIMESTAMP | Znacznik czasu w UTC dla ostatniego razu, kiedy rekord był aktualny. |

### Changes partycja

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_change\_identifier | VARCHAR (50) | Identyfikator zmiany to ciąg znaków składający się z dwóch części:<br><br><ul> <li> <p>Znacznik czasu rozpoczęcia uruchomienia partii w milisekundach od 01.01.1970 r. (ciąg 10 cyfr).</p> </li> <li> <p>Sekwencja zmian z bramy replikacji (35 znaków).</p> </li> </ul> |
| hdr\_\_operation | VARCHAR (1) | Ostatnia operacja tego rekordu.<br><br><ul> <li> <p>D – usunięte z <span>Changes</span> partycji.</p> </li> <li> <p>U – zaktualizowane z <span>Changes</span> partycji.</p> </li> <li> <p>I - wstawione z <span>Changes</span> partycji.</p> </li> <li> <p>L — wstawiono przez zadanie pełnego ładowania.</p> </li> <li> <p>d - usunięte z funkcji porównaj i zastosuj.</p> </li> <li> <p>u - zaktualizowane z funkcji porównaj i zastosuj.</p> </li> <li> <p>i – wstawione z funkcji porównania i zastosowania.</p> </li> </ul> |
| hdr\_\_timestamp | TIMESTAMP | Znacznik czasu w UTC. |
| hdr\_\_key\_hash | BINARNY (20) | Skrót wszystkich kluczy podstawowych rekordów. |
| hdr\_\_inserted\_timestamp | TIMESTAMP | Znacznik czasu UTC, w którym zmiana została przetworzona przez Qlik. |

### Asset\_state partycja

| Pole | Typ | Opis |
| --- | --- | --- |
| Zastosuj identyfikator zmiany | VARCHAR (50) | Identyfikator ostatniej zmiany zastosowanej do Current partycji. |
| Kopiuj identyfikator zmiany | VARCHAR (50) | Identyfikator ostatniej zmiany zastosowanej do partycji Changes. |

### Reload partycja

Kolumny używane przez Reload partycję są takie same, jak w Current partycji.

## Widoki

Wszystkie utworzone widoki są aktualizowane niemal w czasie rzeczywistym. W celu uproszczenia zapytań i raportowania dostępne są następujące widoki:

### Bieżący

Widok bieżący odzwierciedla najnowszy stan danych. Widok ten reprezentuje replikę tabeli źródłowej, aktualizowaną w czasie zbliżonym do rzeczywistego. Scala dane z partycji Current i Changes.

Nazwa: &lt;EXTERNAL\_SCHEMA&gt;.[&lt;PREFIX&gt;]&lt;TABLE\_NAME&gt;

Do struktury tabeli nie są dodawane kolumny nagłówka.

### Historia

Widok historii jest generowany w schemacie zasobu danych dla każdej wybranej tabeli źródłowej, jeśli w ustawieniach zadania danych włączona jest opcja Historia. Widok historii scala dane z partycji Prior i Changes. Zapewnia pełną oś czasu zmian, idealną do audytu lub analizy historycznej.

Nazwa: &lt;EXTERNAL\_SCHEMA&gt;.[&lt;PREFIX&gt;]&lt;TABLE\_NAME&gt;\_&lt;Suffix for history views&gt;

Do widoku historii dodawane są następujące pola nagłówka.

| Pole | Typ | Opis |
| --- | --- | --- |
| hdr\_\_key\_hash | BINARNY (20) | Skrót wszystkich kluczy podstawowych rekordów. |
| hdr\_\_from\_timestamp | TIMESTAMP | Znacznik czasu wystąpienia zmiany w systemie źródłowym. Odzwierciedla to, kiedy użytkownik pierwotnie dokonał zmiany. |
| hdr\_\_to\_timestamp | TIMESTAMP | Znacznik czasu wystąpienia zmiany lub aktualizacji w systemie źródłowym. |
| hdr\_\_store | VARCHAR (10) | Oznacza miejsce, w którym znajduje się rekord:<br><br><ul> <li> <p>CURRENT — jeśli rekord znajduje się w <span>Current</span> partycji.</p> </li> <li> <p>PRIOR — jeśli rekord znajduje się w <span>Prior</span> partycji z danymi historycznymi.</p> </li> </ul> |
| hdr\_\_operation | ŁAŃCUCH (1) | Ostatnia operacja tego rekordu.<br><br><ul> <li> <p>D – usunięte z <span>Changes</span> partycji.</p> </li> <li> <p>U – zaktualizowane z <span>Changes</span> partycji.</p> </li> <li> <p>I - wstawione z <span>Changes</span> partycji.</p> </li> <li> <p>L — wstawiono przez zadanie pełnego ładowania.</p> </li> <li> <p>d - usunięte z funkcji porównaj i zastosuj.</p> </li> <li> <p>u - zaktualizowane z funkcji porównaj i zastosuj.</p> </li> <li> <p>i – wstawione z funkcji porównania i zastosowania.</p> </li> </ul> |
| hdr\_\_deleted | BIT | Wskazuje, czy rekord jest miękko usuwany, na podstawie tego, czy hdr\_\_operation to D lub d. |
| hdr\_\_był\_aktualny\_od\_znacznika\_czasu | TIMESTAMP | Czas (UTC), kiedy ten wiersz wszedł do Current partycji. Zazwyczaj jest to wtedy, gdy zadanie przechowywania zostało uruchomione i zmiana została zastosowana. |
| hdr\_\_był\_aktualny\_do\_znacznika\_czasu | TIMESTAMP | Czas (UTC), kiedy wiersz został usunięty z tabeli Current, na przykład z powodu nowszej wersji. |

InformacjaWidoki Bieżący i Historia opierają się na partycji Changes i zawsze działają w czasie zbliżonym do rzeczywistego. Jeśli jednak wydajność zapytań jest niska, może to być spowodowane dużą liczbą zmian, które nie zostały jeszcze zastosowane w partycjach Current lub Prior. Niescalone delty wymagają więcej przetwarzania w czasie zapytania, co spowalnia dostęp.

### Wyświetlanie kolumn nagłówkowych w widokach

Możesz kontrolować, czy wyświetlać, czy ukrywać nagłówki kolumn. Opcje różnią się w zależności od typu zadania.

InformacjaKolumny nagłówkowe są automatycznie wypełniane danymi i tylko do odczytu.

#### Zadanie umieszczania strumieniowego

Aby wyświetlić kolumny nagłówka, włącz Pokaż kolumny nagłówka po prawej stronie pola wyszukiwania.

#### Zadanie transformacji strumieniowania

Lista rozwijana z następującymi opcjami jest dostępna po prawej stronie pola wyszukiwania.

* Ukryj kolumny nagłówka: Domyślnie.

* Pokaż kolumny nagłówka

  * Standard: Wybierz, aby wyświetlić kolumny nagłówkowe dla widoków standardowych.

  * Historia: Zaznacz, aby wyświetlić kolumny nagłówka dla widoków historii. Pamiętaj, że ta opcja będzie dostępna tylko wtedy, gdy Utwórz magazyn danych historycznych (typ 2) jest włączona w ustawieniach zadania lub zestawu danych.

Opis dostępnych kolumn nagłówka zawiera [Tabele związane z umieszczaniem](https://help.qlik.com/pl-PL/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/lakehouse-datasets-architecture-streaming.htm#Landing) i [Widoki](https://help.qlik.com/pl-PL/cloud-services/Subsystems/Hub/Content/Sense_Hub/DataIntegration/Lakehouse/lakehouse-datasets-architecture-streaming.htm#Views).

Govnote-not-inNieobsługiwane w Qlik Cloud Government.