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

Podczas generowania rekordów danych w Otwarty lakehouse Qlik, w Qlik Talend Data Integration są automatycznie generowane tabele pamięci masowej, tabele zmian i widoki. Widoki te można przeszukiwać w celu uzyskania dostępu do bieżących i historycznych danych przechowywanych w otwartym formacie tabeli Iceberg.

Intuicyjny interfejs użytkownika pomaga budować, modelować i wykonywać potoki danych. Użytkownik może automatycznie generować schematy dla magazynów danych operacyjnych (ODS) i magazynów danych historycznych (HDS) bez konieczności ręcznego kodowania.

Architektura dla potoku danych Otwarty lakehouse Qlik z wykorzystaniem Brama danych Qlik — ruch danych. Dane umieszczane są w S3 i przechowywane w Open Lakehouse Iceberg. Opcjonalnie, jak pokazano poniżej, tabele mogą być odzwierciedlane w hurtowni danych.

Architektura dla potoku danych Otwarty lakehouse Qlik z wykorzystaniem Brama danych Qlik — ruch danych. Dane umieszczane są w S3 i przechowywane w Open Lakehouse Iceberg. Opcjonalnie, jak pokazano poniżej, tabele mogą być odzwierciedlane w hurtowni danych.

Architektura dla potoku danych Otwarty lakehouse QlikOtwarty lakehouse Qlik z wykorzystaniem Brama danych Qlik — ruch danychBrama danych Qlik — ruch danych. Dane umieszczane są w S3 i przechowywane w Open Lakehouse Iceberg. Opcjonalnie, jak pokazano poniżej, tabele mogą być odzwierciedlane w hurtowni danych. ![](https://help.qlik.com/pl-PL/cloud-services/Subsystems/Hub/Content/Resources/Images/Upsolver/open_lakehouse_architecture.png)

## 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, z których każda służy 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.

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żąca

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.