Używanie ponownego partycjonowania do optymalizowania przetwarzania za pomocą usługi Azure Stream Analytics

  • Artykuł

W tym artykule pokazano, jak używać ponownego partycjonowania do skalowania zapytania usługi Azure Stream Analytics w scenariuszach, które nie mogą być w pełni zrównane.

Może nie być możliwe użycie przetwarzania równoległego , jeśli:

  • Nie kontrolujesz klucza partycji dla strumienia wejściowego.
  • Źródło "rozpyla" dane wejściowe w wielu partycjach, które później należy scalić.

Ponowne partycjonowanie lub przetasowanie jest wymagane w przypadku przetwarzania danych w strumieniu, który nie jest podzielony na fragmenty zgodnie z naturalnym schematem danych wejściowych, takim jak PartitionId dla usługi Event Hubs. Podczas ponownego partycjonowania każdy fragment może być przetwarzany niezależnie, co umożliwia liniowe skalowanie potoku przesyłania strumieniowego.

Jak ponownie partycjonować

Dane wejściowe można ponownie partycjonować na dwa sposoby:

  1. Użyj oddzielnego zadania usługi Stream Analytics, które wykonuje ponowne partycjonowanie
  2. Użyj pojedynczego zadania, ale najpierw wykonaj ponowne partycjonowanie przed niestandardową logiką analizy

Tworzenie oddzielnego zadania usługi Stream Analytics w celu ponownego partycjonowania danych wejściowych

Zadanie odczytujące dane wejściowe i zapisu w danych wyjściowych centrum zdarzeń można utworzyć przy użyciu klucza partycji. To centrum zdarzeń może następnie służyć jako dane wejściowe dla innego zadania usługi Stream Analytics, w którym implementujesz logikę analizy. Podczas konfigurowania tych danych wyjściowych centrum zdarzeń w zadaniu należy określić klucz partycji, za pomocą którego usługa Stream Analytics będzie ponownie partycjonować dane.

-- For compat level 1.2 or higher
SELECT * 
INTO output
FROM input

--For compat level 1.1 or lower
SELECT *
INTO output
FROM input PARTITION BY PartitionId

Ponowne partycjonuj dane wejściowe w ramach jednego zadania usługi Stream Analytics

Możesz również wprowadzić krok w zapytaniu, który najpierw ponownie partycjonuje dane wejściowe, które następnie mogą być używane przez inne kroki zapytania. Jeśli na przykład chcesz ponownie partycjonować dane wejściowe na podstawie identyfikatora DeviceId, zapytanie będzie:

WITH RepartitionedInput AS 
( 
    SELECT * 
    FROM input PARTITION BY DeviceID
)

SELECT DeviceID, AVG(Reading) as AvgNormalReading  
INTO output
FROM RepartitionedInput  
GROUP BY DeviceId, TumblingWindow(minute, 1)

Poniższe przykładowe zapytanie łączy dwa strumienie ponownie partycjonowanych danych. Po połączeniu dwóch strumieni danych podzielonych na partycje strumienie muszą mieć ten sam klucz partycji i liczbę. Wynik jest strumieniem, który ma ten sam schemat partycji.

WITH step1 AS 
(
    SELECT * FROM input1 
    PARTITION BY DeviceID
),
step2 AS 
(
    SELECT * FROM input2 
    PARTITION BY DeviceID
)

SELECT * INTO output 
FROM step1 PARTITION BY DeviceID 
UNION step2 PARTITION BY DeviceID

Schemat danych wyjściowych powinien być zgodny z kluczem schematu strumienia i liczbą, aby każdy podstream mógł być opróżniany niezależnie. Strumień może być również scalany i ponownie partycjonowany przez inny schemat przed opróżnieniem, ale należy unikać tej metody, ponieważ zwiększa ogólne opóźnienie przetwarzania i zwiększa wykorzystanie zasobów.

Jednostki przesyłania strumieniowego na potrzeby ponownego partycjonowania

Poeksperymentuj i obserwuj użycie zasobów zadania, aby określić dokładną liczbę potrzebnych partycji. Liczba jednostek przesyłania strumieniowego (SU) musi być dostosowywana zgodnie z zasobami fizycznymi wymaganymi dla każdej partycji. Ogólnie rzecz biorąc, dla każdej partycji potrzebne są sześć jednostek jednostki jednostki SU. Jeśli do zadania przypisano niewystarczające zasoby, system zastosuje ponowne partycjonowania tylko wtedy, gdy skorzysta z zadania.

Ponowne partycjonacje dla danych wyjściowych SQL

Gdy zadanie używa bazy danych SQL na potrzeby danych wyjściowych, użyj jawnego ponownego partycjonowania, aby dopasować optymalną liczbę partycji do zmaksymalizowania przepływności. Ponieważ program SQL działa najlepiej z ośmioma składnikami zapisywania, ponowne partycjonowanie przepływu do ośmiu przed opróżnieniem lub gdzieś dalej niżej niżej, może przynieść korzyści z wydajności pracy.

Jeśli istnieje więcej niż osiem partycji wejściowych, dziedziczenie schematu partycjonowania wejściowego może nie być odpowiednim wyborem. Rozważ użycie funkcji INTO w zapytaniu, aby jawnie określić liczbę składników zapisywania danych wyjściowych.

Poniższy przykład odczytuje dane wejściowe, niezależnie od tego, czy jest on naturalnie partycjonowany, i ponownie dzieli strumień dziesięć razy zgodnie z wymiarem DeviceID i opróżnia dane do danych wyjściowych.

SELECT * INTO [output] 
FROM [input] 
PARTITION BY DeviceID INTO 10

Aby uzyskać więcej informacji, zobacz Dane wyjściowe usługi Azure Stream Analytics w usłudze Azure SQL Database.

Następne kroki