Udostępnij za pośrednictwem

Monitorowanie zmaterializowanych widoków

  • Artykuł

Dotyczy: ✅Microsoft Fabric✅Azure Data Explorer

Monitoruj kondycję zmaterializowanego widoku w następujący sposób:

  • Monitorowanie zmaterializowanych metryk widoków w witrynie Azure Portal przy użyciu Azure Monitor. Użyj zmaterializowanej metryki wieku widoku, MaterializedViewAgeSeconds, jako podstawowej metryki, aby monitorować świeżość widoku.

Uwaga

Materializacja nigdy nie pomija żadnych danych, nawet jeśli występują stałe błędy. Widok jest zawsze gwarantowany, aby zwrócić najbardziej aktualną migawkę zapytania na podstawie wszystkich rekordów w tabeli źródłowej. Stałe błędy znacznie obniżają wydajność zapytań, ale nie powodują nieprawidłowych wyników w zapytaniach wyświetlania.

Rozwiązywanie problemów ze zmaterializowanymi widokami w złej kondycji

Jeśli metryka MaterializedViewAge stale rośnie, a metryka MaterializedViewHealth pokazuje, że widok jest w złej kondycji, wykonaj następujące zalecenia, aby zidentyfikować główną przyczynę:

  • Sprawdź liczbę zmaterializowanych widoków w klastrze i bieżącą pojemność dla zmaterializowanych widoków:

    .show capacity 
| where Resource == "MaterializedView"
| project Resource, Total, Consumed

    wyjściowe

    Zasób Łączny Spożywane
    Zmaterializowany widok 1 0
    • Liczba zmaterializowanych widoków, które mogą być uruchamiane współbieżnie, zależy od pojemności wyświetlanej w kolumnie Total, a kolumna Consumed pokazuje liczbę zmaterializowanych widoków aktualnie uruchomionych. Za pomocą zmaterializowane zasady wydajności widoków określić minimalną i maksymalną liczbę operacji współbieżnych, zastępując domyślny poziom współbieżności systemu. System określa bieżącą współbieżność pokazaną w Totalna podstawie dostępnych zasobów klastra. Poniższy przykład zastępuje decyzję systemu i zmienia minimalne operacje współbieżne z jednego do trzech:
    .alter-merge cluster policy capacity '{  "MaterializedViewsCapacity": { "ClusterMinimumConcurrentOperations": 3 } }'
    • Jeśli te zasady jawnie zmienisz, monitoruj kondycję klastra i upewnij się, że inne obciążenia nie mają wpływu na tę zmianę.

  • Sprawdź, czy podczas procesu materializacji występują błędy przy użyciu .show materialized-view failures.

    • Jeśli błąd jest trwały, system automatycznie wyłącza zmaterializowany widok. Aby sprawdzić, czy jest wyłączona, użyj polecenia .show materialized-view i sprawdź, czy wartość w kolumnie IsEnabled jest false. Następnie sprawdź dziennika dla wyłączonego zdarzenia za pomocą polecenia .show journal. Przykładem trwałej awarii jest zmiana schematu tabeli źródłowej, która sprawia, że jest niezgodna z zmaterializowanym widokiem. Aby uzyskać więcej informacji, zobacz polecenie .create materialized-view.
    • Jeśli błąd jest przejściowy, system automatycznie ponawia próbę wykonania operacji. Jednak awaria może opóźnić materializację i zwiększyć wiek zmaterializowanego widoku. Ten typ awarii występuje na przykład w przypadku osiągnięcia limitów pamięci lub przekroczenia limitu czasu zapytania. Zapoznaj się z poniższymi zaleceniami, aby uzyskać więcej sposobów rozwiązywania problemów z błędami przejściowymi.

  • Przeanalizuj proces materializacji przy użyciu polecenia .show commands-and-queries. Zastąp Databasename i ViewName, aby filtrować określony widok:

    .show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"

    • Sprawdź użycie pamięci w kolumnie MemoryPeak, aby zidentyfikować wszelkie operacje, które zakończyły się niepowodzeniem z powodu osiągnięcia limitów pamięci, takich jak uruchamianie zapytań. Domyślnie proces materializacji jest ograniczony do szczytu pamięci 15 GB na węzeł. Jeśli zapytania lub polecenia wykonywane podczas procesu materializacji przekraczają tę wartość, materializacja kończy się niepowodzeniem z powodu limitów pamięci. Aby zwiększyć szczyt pamięci na węzeł, zmień grupę obciążeń widoków $materialized. W poniższym przykładzie zmieniono zmaterializowaną grupę obciążeń widoków, aby podczas materializacji używać maksymalnie 64 GB pamięci na węzeł:

      .alter-merge workload_group ['$materialized-views'] ```
{
  "RequestLimitsPolicy": {
    "MaxMemoryPerQueryPerNode": {
      "Value": 68719241216
    }
  }
}

      Uwaga

      MaxMemoryPerQueryPerNode nie może przekroczyć 50% całkowitej ilości pamięci dostępnej w każdym węźle.

    • Sprawdź, czy proces materializacji osiąga zimną pamięć podręczną. W poniższym przykładzie przedstawiono statystyki pamięci podręcznej w ciągu ostatniego dnia dla zmaterializowanego widoku, ViewName:

      .show commands-and-queries 
| where ClientActivityId startswith "DN.MaterializedViews;ViewName"
| where StartedOn > ago(1d)
| extend HotCacheHits = tolong(CacheStatistics.Shards.Hot.HitBytes), 
         HotCacheMisses = tolong(CacheStatistics.Shards.Hot.MissBytes), 
         HotCacheRetrieved = tolong(CacheStatistics.Shards.Hot.RetrieveBytes), 
         ColdCacheHits = tolong(CacheStatistics.Shards.Cold.HitBytes), 
         ColdCacheMisses = tolong(CacheStatistics.Shards.Cold.MissBytes), 
         ColdCacheRetrieved = tolong(CacheStatistics.Shards.Cold.RetrieveBytes)
| summarize HotCacheHits = format_bytes(sum(HotCacheHits)), 
            HotCacheMisses = format_bytes(sum(HotCacheMisses)),
            HotCacheRetrieved = format_bytes(sum(HotCacheRetrieved)), 
            ColdCacheHits =format_bytes(sum(ColdCacheHits)), 
            ColdCacheMisses = format_bytes(sum(ColdCacheMisses)),
            ColdCacheRetrieved = format_bytes(sum(ColdCacheRetrieved))

      wyjściowe

      HotCacheHits HotCacheMisses HotCacheRetrieved ColdCacheHits ColdCacheMisses ColdCacheRetrieved
      26 GB 0 bajtów 0 bajtów 1 GB 0 bajtów 866 MB

    • Sprawdź, czy materializacja skanuje stare rekordy, sprawdzając ScannedExtentsStatistics za pomocą polecenia .show queries. Jeśli liczba skanowanych zakresów jest wysoka, a MinDataScannedTime jest stara, cykl materializacji musi skanować wszystkie lub większość zmaterializowane części widoku. Skanowanie jest wymagane do znalezienia przecięcia z różnicowym. Aby uzyskać więcej informacji na temat różnicowych i zmaterializowanej części, zobacz Jak zmaterializowane widoki działają. Poniższe zalecenia zawierają sposoby zmniejszenia ilości danych skanowanych w zmaterializowanych cyklach przez zminimalizowanie przecięcia z różnicą.

  • Jeśli cykl materializacji skanuje dużą ilość danych, potencjalnie w tym zimną pamięć podręczną, rozważ wprowadzenie następujących zmian w zmaterializowanej definicji widoku:

    • Uwzględnij datetime grupowanie według klucza w definicji widoku. Może to znacznie zmniejszyć ilość skanowanych danych, tak długo, jak nie ma późno przychodzących danych w tej kolumnie. Aby uzyskać więcej informacji, zobacz porady dotyczące wydajności . Należy utworzyć nowy zmaterializowany widok, ponieważ aktualizacje kluczy grupowania nie są obsługiwane.
    • Użyj lookback w ramach definicji widoku. Aby uzyskać więcej informacji, zobacz .create materialized view supported properties.
  • Sprawdź, czy jest wystarczająca pojemność pozyskiwania, sprawdzając, czy metryka MaterializedViewResult, czy ingestionUmetric pokaże wartości InsufficientCapacity. Pojemność pozyskiwania można zwiększyć, skalując dostępne zasoby (preferowane) lub zmieniając zasady wydajności pozyskiwania .
  • Sprawdź, czy pojemność pozyskiwania jest wystarczająca, sprawdzając, czy metrykiMaterializedViewResult są wyświetlane InsufficientCapacity wartości. Pojemność pozyskiwania można zwiększyć, skalując dostępne zasoby.

  • Jeśli zmaterializowany widok jest nadal w złej kondycji, usługa nie ma wystarczającej pojemności ani zasobów, aby zmaterializować wszystkie dane na czas. Rozważ następujące opcje:

    • Skalowanie klastra w poziomie przez zwiększenie minimalnej liczby wystąpień. zoptymalizowane autoskalowanie nie uwzględnia zmaterializowanych widoków i nie skaluje klastra automatycznie, jeśli zmaterializowane widoki są w złej kondycji. Należy ustawić minimalną liczbę wystąpień, aby zapewnić klastrowi więcej zasobów, aby uwzględnić zmaterializowane widoki.
    • Skalowanie w poziomie usługi Eventhouse w celu zapewnienia większej ilości zasobów w celu uwzględnienia zmaterializowanych widoków. Aby uzyskać więcej informacji, zobacz Włączanie minimalnego użycia.
    • Podziel zmaterializowany widok na kilka mniejszych widoków, z których każdy obejmuje podzestaw danych. Można na przykład podzielić je na podstawie klucza o wysokiej kardynalności z kluczy grupowania zmaterializowanego widoku. Wszystkie widoki są oparte na tej samej tabeli źródłowej, a każdy widok filtruje według SourceTable | where hash(key, number_of_views) == i, gdzie i jest częścią zestawu {0,1,…,number_of_views-1}. Następnie można zdefiniować składowaną funkcję, która unii wszystkich mniejszych zmaterializowanych widoków. Użyj tej funkcji w zapytaniach, aby uzyskać dostęp do połączonych danych.

    Podczas dzielenia widoku może zwiększyć użycie procesora CPU, zmniejsza szczyt pamięci w cyklach materializacji. Zmniejszenie szczytu pamięci może pomóc, jeśli pojedynczy widok kończy się niepowodzeniem z powodu limitów pamięci.

MaterializedViewResult metryka

Metryka MaterializedViewResult zawiera informacje o wyniku cyklu materializacji i może służyć do identyfikowania problemów w zmaterializowanym widoku stanu kondycji. Metryka zawiera Database wymiar i i MaterializedViewNameResult .

Wymiar Result może mieć jedną z następujących wartości:

  • Powodzenie: materializacja została ukończona pomyślnie.

  • SourceTableNotFound: tabela źródłowa zmaterializowanego widoku została porzucona, więc zmaterializowany widok jest automatycznie wyłączony.

  • SourceTableSchemaChange: schemat tabeli źródłowej został zmieniony w sposób niezgodny z zmaterializowaną definicją widoku. Ponieważ zmaterializowane zapytanie widoku nie pasuje już do zmaterializowanego schematu widoku, zmaterializowany widok jest automatycznie wyłączony.

  • InsufficientCapacity: wystąpienie nie ma wystarczającej pojemności, aby zmaterializować zmaterializowany widok z powodu braku pojemności pozyskiwania. Chociaż niewystarczające błędy pojemności mogą być przejściowe, jeśli często się powtarzają, spróbuj skalować wystąpienie lub zwiększyć odpowiednią pojemność w zasadach.
  • InsufficientCapacity: Wystąpienie nie ma wystarczającej pojemności, aby zmaterializować zmaterializowany widok z powodu braku pojemności pozyskiwania. Niewystarczające błędy pojemności mogą być przejściowe, jeśli często się powtarzają, spróbuj skalować wystąpienie lub zwiększyć pojemność. Aby uzyskać więcej informacji, zobacz Planowanie rozmiaru pojemności.
  • InsufficientResources: baza danych nie ma wystarczających zasobów (procesora CPU/pamięci), aby zmaterializować zmaterializowany widok. Chociaż niewystarczające błędy zasobów mogą być przejściowe, jeśli często się powtarzają, spróbuj skalować w górę lub skalować w poziomie. Aby uzyskać więcej pomysłów, zobacz Rozwiązywanie problemów ze złą kondycją zmaterializowanych widoków.

Zmaterializowane widoki w kolejnych bazach danych

Zmaterializowane widoki można zdefiniować w bazach danych obserwowanych. Jednak monitorowanie tych zmaterializowanych widoków powinno być oparte na bazie danych lidera, w której zdefiniowany jest zmaterializowany widok. Szczególnie:

  • Metryki związane z zmaterializowanym wykonywaniem widoku (MaterializedViewResult, MaterializedViewExtentsRebuild) są obecne tylko w bazie danych lidera. Metryki związane z monitorowaniem (MaterializedViewAgeSeconds, MaterializedViewHealth, MaterializedViewRecordsInDelta) są również wyświetlane w kolejnych bazach danych.

Śledzenie użycia zasobów

Zmaterializowane użycie zasobów widoków: zasoby używane przez zmaterializowany proces materializacji widoków można śledzić za pomocą .show commands-and-queries polecenia . Przefiltruj rekordy dla określonego widoku przy użyciu następujących wartości (zastąp DatabaseName i ViewName):

.show commands-and-queries 
| where Database  == "DatabaseName" and ClientActivityId startswith "DN.MaterializedViews;ViewName;"

Powiązana zawartość