Architektura zestawu danych dla źródeł strumieniowych w Qlik Open Lakehouse

Źródła strumieniowe mają własną architekturę w Qlik Open Lakehouse, 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, Qlik Open Lakehouse 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 Qlik Open Lakehouse, 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.

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ń.

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.

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.

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).

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

Prior partycja

Changes partycja

Asset_state partycja

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: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

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: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

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

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.

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 i Widoki.