Szybki dashboard Qlik pokazuje, jak sprawnie potrafi odpowiedzieć na pytanie, a nie jak niedawno dotarły do niego dane o działaniach biznesowych. Zamówienie może już być zatwierdzone w systemie operacyjnym, podczas gdy dashboard nadal pokazuje poprzedni stan. Samo skrócenie czasu reakcji wykresów nie usuwa tej rozbieżności.
Aby określić miarodajne wymagania dotyczące aktualności danych, prześledź całą drogę zdarzenia do widoku użytkownika: zatwierdzenie transakcji w źródle, przechwycenie zmiany lub ekstrakcję, zapis w warstwie docelowej, transformację, udostępnienie do analizy i wyświetlenie. Podczas diagnozowania wydajności dashboardu traktuj szybkość odpowiedzi i maksymalny dopuszczalny wiek danych jako osobne wymagania. Oba należą do tych samych kryteriów odbioru, ale mierzą co innego.
Zacznij od trybu dostępu do danych w Qlik
W typowym dla Qlik Sense trybie in-memory przeładowanie aplikacji pobiera dane i aktualizuje migawkę, którą analizują użytkownicy. Przeładowania można uruchamiać zgodnie z harmonogramem lub wyzwalać z zewnątrz. Użytkownicy odpytują tę migawkę w aplikacji, zamiast kierować zapytania bezpośrednio do pierwotnego źródła, co opisuje dokumentacja aplikacji analitycznych Qlik.
Oznacza to, że przechwytywanie zmian i przeładowanie aplikacji są odrębnymi etapami. Mechanizm przechwytywania mógł już dostarczyć zmianę do hurtowni, ale aplikacja in-memory nadal musi załadować dane, które ją zawierają. Z kolei częstsze przeładowywanie aplikacji nie sprawi, że zbiór danych na wcześniejszym etapie stanie się bardziej aktualny.
Direct Query w Qlik Cloud odczytuje bazy SQL bez importowania ich danych do pamięci. W tym trybie prześledź odpytywaną bazę i żądanie, które wygenerowało wyświetlany wynik, zamiast zakładać, że przeładowanie aplikacji in-memory jest ostatnim etapem udostępniania danych. W ocenie aktualności uwzględnij też sposób działania pamięci podręcznej i odświeżania widoku właściwy dla danego wdrożenia.
To praktyczne rozróżnienie: ustal, z jakiej ścieżki danych korzysta każda istotna wizualizacja. Nie traktuj określeń „połączono z bazą danych”, „włączono CDC” i „zaplanowano przeładowanie” jako równoważnych opisów aktualności danych.
Strumieniowe zasilanie to tylko część drogi
Prezentacja IBM Cloud poświęcona architekturze lakehouse opisuje ciągły zapis danych z tematów Kafka w formacie Parquet w pamięci obiektowej. Łączy też stopniowy napływ danych z gromadzeniem się małych plików i opisuje dalsze przetwarzanie służące poprawie wydajności oraz przygotowaniu danych do wykorzystania w warstwie semantycznej.
Ta architektura ujawnia ważną granicę. Obecność rekordu w zapisanym pliku nie przesądza o tym, kiedy stanie się on częścią przygotowanego zbioru używanego przez analitykę. Jeśli dashboard korzysta z przygotowanej tabeli, śledź publikację tej tabeli, a nie tylko pojawienie się danych w pamięci masowej. Jeśli dalsze przetwarzanie nie leży na ścieżce udostępniania danych użytkownikowi, nie doliczaj go jako obowiązkowego czasu oczekiwania. To rzeczywiste zależności decydują, gdzie narasta opóźnienie.
Ustalenie, gdzie wykonywać transformacje w architekturze Qlik i lakehouse, jest osobną decyzją projektową. Przy ocenie aktualności trzeba przede wszystkim wskazać transformacje, które muszą się zakończyć, aby zdarzenie biznesowe mogło zostać poprawnie odwzorowane.
Odmienne podejście przedstawia koncepcja LTAP zaprezentowana podczas wystąpienia Databricks. Databricks zaproponował ujednolicenie warstwy przechowywania danych operacyjnych i analitycznych zamiast utrzymywania tradycyjnego potoku kopiowania. W prezentacji wdrożenie tej funkcji było dopiero zapowiadane. Ideą architektoniczną jest usunięcie etapu transferu. Nie ustanawia to wymogu integracji z Qlik ani nie eliminuje potrzeby mierzenia, kiedy zatwierdzona zmiana staje się widoczna dla użytkownika.
Prześledź zdarzenie biznesowe, a potem sprawdź kompletność
Rozważ przykładowe zamówienie przechodzące przez aplikację in-memory. Korzystaj ze znaczników czasu pochodzących z zsynchronizowanych zegarów i zachowaj stały identyfikator zamówienia, aby każda obserwacja odnosiła się do tego samego zdarzenia. Zapis przebiegu powinien obejmować:
source_commit_at: moment zatwierdzenia transakcji operacyjnej, a nie moment pierwotnego wprowadzenia zamówienia.captured_at: moment, w którym mechanizm przechwytywania lub ekstrakcji wykrył zatwierdzoną zmianę.landed_at: moment udostępnienia zmiany w docelowej warstwie zapisu.prepared_at: moment, w którym wymagane przetwarzanie opublikowało poprawne odwzorowanie danych do analizy.analytics_available_at: moment udostępnienia migawki aplikacji zawierającej zamówienie.visible_at: moment, w którym wynik wyświetlany użytkownikowi faktycznie uwzględnił zamówienie.
Czas od source_commit_at do visible_at mierzy drogę tego zdarzenia. Różnice między sąsiednimi znacznikami wskazują, gdzie na tej ścieżce występuje oczekiwanie i przetwarzanie. W przypadku Direct Query zastąp etap udostępnienia migawki odpowiednim przebiegiem wykonania zapytania i dostarczenia wyniku. Obserwuj wyświetlany wynik, zamiast zakładać, że już otwarty widok uległ zmianie.
Załóżmy teraz, że zamówienie nie trafiło do przygotowanego zbioru danych, z którego korzysta przeładowanie. Przeładowanie może pomyślnie przetworzyć ten zbiór, nie uwzględniając zamówienia. Niedawny znacznik zakończenia opisuje operację przeładowania. Nie dowodzi, że dotarły wszystkie oczekiwane zdarzenia z wcześniejszych etapów. Pojawienie się nowszego zamówienia w innej części danych również nie dowodzi obecności tego zamówienia.
Na tym polega różnica między aktualnością a kompletnością. Śledź widoczność zdarzeń, ale także uzgadniaj oczekiwane rekordy i ich stany po obu stronach istotnego etapu. Używaj rekordów testowych, na których wykorzystanie masz zgodę, i porównuj wynikowe odwzorowanie biznesowe ze źródłem. Jeśli pozwala na to konektor i projekt systemu docelowego, w testach odbiorowych uwzględnij rekordy zmienione i usunięte, a nie tylko nowo utworzone.
Interpretuj etykiety znaczników czasu dosłownie. Dokumentacja aktualności zbiorów danych Qlik odnosi tę miarę do ostatniego zdarzenia w źródle dla CDC, a dla metody Reload and compare do ostatniego uruchomienia potoku. To różne punkty odniesienia. Żadnego z nich nie należy bez wyjaśnienia przedstawiać jako momentu, do którego dashboard zawiera kompletne dane.
Ustal wymagania dotyczące aktualności także po przerwie w działaniu
Zdefiniuj wymagania z perspektywy decyzji biznesowej: jakie zdarzenia muszą być widoczne, jakie opóźnienie jest dopuszczalne i jakie kontrole kompletności muszą zakończyć się pomyślnie. Oddziel normalne działanie od odtwarzania po przerwie. Ustal też, co użytkownicy powinni zobaczyć, gdy nie można potwierdzić aktualności: ostrzeżenie, wyraźnie oznaczony ostatni znany stan czy ograniczenie wykorzystania wyniku do podejmowania decyzji operacyjnych.
Sam harmonogram nie wystarczy. Dokumentacja Qlik Cloud wskazuje ograniczenia czasu trwania przeładowania i oczekiwania w kolejce wynikającej z limitów współbieżności, których osiągnięcie może spowodować niepowodzenie przeładowania. Monitoruj rzeczywiste zakończenie operacji i zakres uwzględnionych danych, zamiast traktować skonfigurowaną częstotliwość jako zapewnioną aktualność.
Oprzyj monitoring na etapach zapisanych w przebiegu zdarzenia. Rejestruj postęp przechwytywania, dostępność danych w miejscu docelowym, publikację przygotowanego zbioru, dostępność aplikacji i zaobserwowany stan wyświetlania, korzystając z interfejsów dostępnych w danym wdrożeniu. Przypisz odpowiedzialność za każde opóźnienie. Oddziel status operacyjny od zweryfikowanej pozycji „dane kompletne do”, czyli punktu w źródle, do którego uzgadnianie danych zakończyło się pomyślnie.
Bardziej rygorystyczne cele oceniaj w odniesieniu do pracy potrzebnej do ich osiągnięcia. Częstsza ekstrakcja lub przeładowania mogą oznaczać więcej odczytów ze źródła i więcej przetwarzania. Mniejsze partie publikacji mogą skrócić oczekiwanie, a jednocześnie zwiększyć narzut przetwarzania. Przy bezpośrednim dostępie do bazy oceń obciążenie, jakie nakładają na nią zapytania analityczne. Porównuj te opcje względem tych samych wymagań dotyczących widoczności i kompletności, a nie tylko najkrótszego skonfigurowanego interwału.
Na koniec przerwij i wznów przepływ w środowisku testowym, w którym masz zgodę na takie działania. Sprawdź, czy odtwarzanie przywraca oczekiwany stan biznesowy, jak długo trwa nadrobienie zaległości i czy dashboard pozostaje wyraźnie oznaczony, gdy nadal jest opóźniony. Ponowne uruchomienie procesu nie musi oznaczać, że nadrobił on zaległości.
Jeśli dashboard Qlik działa szybko, ale aktualność jego danych pozostaje niepewna, porozmawiaj z Digiventi o ścieżce danych w Qlik. Zacznij od zdarzenia biznesowego, które musi być widoczne, i prześledź etapy między zatwierdzeniem transakcji a ekranem.