5

Buduję system raportowania metryk na flocie instancji zawierającej ponad 100 000 instancji front-end. Dla każdego żądania każde wystąpienie będzie miało czas odpowiedzi. Potrzebuję rozkładu czasu reakcji każdego rodzaju wniosku na całą flotę. Na przykład [Percentile 50, Percentile 90, Percentile 99, Percentile99.9 ...] z [requestType1, requestType2 ... requestType1000].Jak obliczyć rozkład (Histogram) dużej ilości danych w systemie rozproszonym?

Każde wystąpienie będzie zbierać czas reakcji odbywa się w środku. Tak więc ponad minutę, co jedna instancja zbiera w pamięci, to listy czasu odpowiedzi wszystkich typów requestTypes. Na przykład requestType1 - [1, 2, 3, 4, 1, 2], requestType2 - [2, 2, 3, 2, 1] ...... To, co muszę zrobić, to przetworzyć te dane i wyprodukować Wynik końcowy.

Próbowałem wiele wzorów, moje główne punkty bólowe są ogromne wielkość punktów danych Zebrałem od każdego RequestType, a koszty komunikacji pomiędzy przypadkach. Wyjaśnię mój obecny projekt poniżej, ale chcę również wiedzieć, czy istnieją lepsze projekty, czy też niektóre fantazyjne algorytmy mogą agregować histogramy?

Obecnie najbardziej obiecująca jest taka: każda instancja front-end prześle dane do losowej instancji floty instancji klasy średniej. W tej flocie średniej warstwy każde wystąpienie będzie agregować wszystkie punkty danych, które otrzymuje w krótkim okresie czasu, np. 5 sekund. (Nie ma wystarczającej ilości pamięci do przechowywania przez dłuższy czas). Następnie instancja warstwy pośredniej dystrybuuje zagregowane dane według wartości mieszania requestTypes do instancji back-end. Oznacza to, że wszystkie instancje warstwy pośredniej wyślą punkty danych o tych samych requestTypes do tej samej instancji zaplecza. Następnie w instancji zaplecza mogę użyć kontenera Histogram innej firmy (histogram CodaHale lub HdrHistogram) do obliczenia P50, P90, P99 przychodzących punktów danych ... Powodem, dla którego potrzebuję floty instancji warstwy pośredniej, jest przesyłanie danych od przodu. instancje końcowe są drogie, więc chcę, aby wszystkie dane były wysyłane jednocześnie, ale nie muszą wykonywać 100 połączeń z 100 różnymi instancjami zaplecza.

Głównym problemem może myślę o tej konstrukcji jest stosunkowo wysoka złożoność, a jeśli jeden z powrotem instancji jest w dół, mogę utrata wszystkich danych niektórych requestTypes. Więc jeśli chodzi o część do projektowania systemu, ktoś ma lepsze pomysły?

Innym sposobem jest znalezienie fantazyjnego algorytmu do agregowania istniejących histogramów. Powyższy projekt, dane, które otrzymam będą w 100% dokładne. Ale w rzeczywistości mogę tolerować pewne błędy. Na przykład w histogramie CodaHale i HdrHistogram, jestem pewien, że faktycznie nie zapisują wszystkich punktów danych, ale zastosowali kilka zaawansowanych algorytmów matematycznych, aby uzyskać stosunkowo wysoką dokładność przy bardzo niskich kosztach. I mogę użyć biblioteki Histogram w instancjach front-end lub mid-layer. Ale problem polega na tym, że mogę uzyskać [P50, P90, P99 ...] każdej instancji front-end lub instancji warstwy pośredniej przy niskim koszcie, nie mogłem znaleźć sposobu na ich agregację. Ponieważ różne instancje front-end mogą obsługiwać różne typy żądań, a dystrybucja żądań do front-endowych instancji jest nieznana, więc po prostu oblicz, że średnia wartość ALL P50, P90, P99 będzie miała dużą nieścisłość. Czy ktoś ma pomysł, w jaki sposób mogę zebrać razem wiele histogramów CodaHale lub HdrHistogram? A może są jakieś algorytmy, które pomogą zebrać histogramy w jeden?

============================================= ===========================

Mam nowy pomysł zeszłej nocy. Ponieważ P50 i P90 mierzą "średnią" wszystkich danych, myślę, że proste zastosowanie średniej ważonej na wszystkich P50 i P90 obliczonych w każdej instancji warstwy pośredniej powinno być wystarczająco dobre. Ale P99, P99.9 i P99.99 mierzą te odległe dane, więc średnia P99 podzbioru może nie być dokładna.

Ale jeśli założymy, że dane w instancji warstwy pośredniej są rozmieszczone stosunkowo losowo, mogę uzyskać 5% punktów danych w każdej instancji warstwy pośredniej i wysłać je do zaplecza. 5% wszystkich datapunktów warstwy pośredniej wynosi 5% całkowitych punktów danych. I mam więcej pewności, że P80 tych 5% danych jest zbliżone do P99 ogólnych danych, P98 z tych 5% danych jest bliskie P99.9 ogólnych danych, a P99.8 z 5% danych jest zbliżone do P99 .99 ogólnych danych.

Mam nadzieję, że w ten sposób mogę przenieść tylko 5% ogólnych danych, ale otrzymam wynik wysokiej dokładności. Co myślisz w ten sposób? projekt

+0

można stwierdzić, że 'Na każde żądanie, każdy przypadek będzie miał time.' odpowiedź, która brzmi dla mnie jak każdy przykład będzie obsługiwać każdą prośbę ty broadcast, ale później mówisz: 'Ponieważ różne instancje typu front-end mogą obsłużyć różne typy żądań, a dystrybucja żądań do front-endowych instancji jest nieznana [...]' co implikuje coś innego. Czy możesz wyjaśnić nieco więcej, jak działa obsługa żądań? –

+1

Czy rzeczywiście otrzymujesz czasy odpowiedzi jako liczby całkowite (lub czy zaokrąglasz do liczb całkowitych)? Sugerowałoby to, że (stosując sortowanie zliczające lub coś podobnego) i zakodowanie danych za pomocą RLE powinno przyspieszyć komunikację. –

+0

Po wysłaniu żądania do floty front-end system wybierze jedną instancję do obsługi żądania. To czarne pudełko, więc nie wiem, które wystąpienie obsłuży żądanie. Ale na pewno jest jedna i tylko jedna instancja do obsługi jednego żądania. –

Odpowiedz

1

System:

Jeśli połączenia są drogie, to może można przesyłać dane? W twoim opisie nie widzę prawdziwych zalet tego średniego poziomu - dlaczego koszty frontend-> midtier call są niższe niż frontend-> backend?

Jeśli chodzi o utratę danych, masz dwie opcje:

  • wysyłania zdarzeń do wielu węzłów. Ale będziesz musiał w jakiś sposób uniknąć duplikacji podczas ich przetwarzania.
  • napisać wszystko do trwałego log (Kafka mógł wykonywać pracę tutaj)

Wszystko zależy od ilości zdarzeń (1/min/frontend lub 10k/s/frontend) i odległości między frontend i zaplecza (to samo centrum danych lub urządzenia mobilne -> centrum danych?).

Jeśli jest to to samo centrum danych, z którym można się komunikować za pomocą protokołu trwałego, rozwiązuje to problem z utratą danych. Jeśli istnieje wiele wydarzeń można agregować je na nakładki i wcisnąć agregaty downstream

Aggregation:

Istnieją różne algorytmy, na przykład q-digest, t-digest. Zobacz Quantiles over Data Streams: An Experimental Study

Warto również zauważyć, że HdrHistograms can be combined

Powiązane problemy