Przyspieszamy: indeksy sumaryczne na platformie Splunk

Splunk to wydajny, wieloźródłowy panel analityczny ogólnego zastosowania. Z uwagi jednak na skalę przetwarzanych danych, realizacja niektórych zapytań trwa. Co zrobić, gdy czas realizacji zapytania Splunk wydłuża się? Jak odciążyć system? Jak efektywnie budować raporty okresowe? Odpowiedzią na takie wyzwania może być wykorzystanie na platformie Splunk indeksów sumarycznych i dedykowanych komend, które je tworzą. W niniejszym artykule skupię się na aspekcie praktycznym tego problemu. Pokażę, czym są indeksy sumaryczne, kiedy ich używać i jak je budować.

Upraszczając: indeks sumaryczny to agregat szeregu zapytań analitycznych języka SPL. Charakteryzując tego rodzaju konstrukt bardziej precyzyjnie:

• indeks sumaryczny zestawia wyniki rozłożonych w czasie zapytań SPL;
• zapytania budujące indeksy sumaryczne mają charakter cykliczny i realizowane są najczęściej w równych interwałach;
• zdarzenia wynikowe zapytań odkładane są w indeksie wtórnym wobec odpytywanego – ten indeks wtórny to właśnie indeks sumaryczny;
• wiązki zdarzeń wynikowych odkładane w indeksie sumarycznym opatrzone są etykietą (tagiem), definiowaną podczas realizacji zapytania źródłowego;
• etykieta taka stanowi identyfikator wykorzystywany podczas odpytywania indeksu sumarycznego.

Poniższy rysunek przedstawia schemat rozrostu indeksów sumarycznych:

Widać tu (lewa część wykresu), że zapytania analityczne inicjowane są około północy w trzy następujące po sobie dni. Wyniki tych zapytań (środkowa część rysunku) odkładane są w indeksie sumarycznym. Lokowanie cyklicznych agregatów w indeksie sumarycznym realizowane jest dzięki komendzie collect.

Załóżmy, że jako firmę sprzedającą produkty w internecie interesuje nas cykliczny raport podsumowujący wielkość strat finansowych wynikających, najogólniej mówiąc, z błędów na poziomie infrastruktury oraz źródła tych błędów. Chcielibyśmy wykorzystać do tego celu indeks sumaryczny. Uproszczona, symboliczna implementacja zapytania realizującego ten cel mogłaby składać się z dwóch zapytań i wyglądać następująco:

indeks=transactions_idx earliest=-24h status>200 action=purchase
| fields basket_value status
| collect index=summary_idx marker="search_name=/"lost_income\""

Pierwsze zapytanie – zapytanie źródłowe – budujące indeks sumaryczny, realizowane codziennie i uwzględniające okres ostatnich 24 godzin, definiuje indeks pierwotny (primary_idx), wykorzystuje komendę collect, wskazuje docelowy indeks sumaryczny (summary_idx) jako repozytorium wyników zapytania źródłowego oraz definiuje etykietę (my_identifier), dzięki której będziemy mogli odwołać się w zapytaniu docelowym do wybranych treści obecnych w indeksie sumarycznym. Zapytanie drugie – docelowe – mogłoby wyglądać następująco:

index=summary_idx search_name=my_identifier earliest=-30d
| stats sum(basket_value) as lost_money by status

Drugie zapytanie – zapytanie docelowe – wykorzystuje przygotowane wcześniej i odkładane systematycznie w indeksie sumarycznym informacje.

Przykłady pokazanych tu zapytań mają charakter demonstracyjny. Istnieją jednak trzy przynajmniej przesłanki wykorzystania indeksów sumarycznych:

1. gdy oczekiwany wynik zapytania dotyczy relatywnie długiego okresu lub implikuje przetworzenie znacznej ilości zdarzeń rozłożonych w czasie;
2. gdy natura samego zapytania SPL ma charakter złożony, np. zapytanie koreluje wiele źródeł danych (podzapytania, czy też komenda join), prowadząc do znacznego obciążenia systemu;
3. gdy można racjonalnie oszacować zysk wydajnościowy wynikający z użycia indeksów sumarycznych.

Jeśli chodzi o tę ostatnią kwestię, warto podejść do niej metodycznie. Przypuśćmy, że we wspomnianym medium internetowym odnotowujemy około miliona transakcji dziennie. Wydajność przetwarzania danych przez przykładową platformę Splunk to 10 tysięcy transakcji przetwarzanych w ciągu sekundy. Powiedzmy też, że z wcześniejszych analiz wiadomo, że transakcje nie dochodzą do rezultatu z powodu 10 możliwych błędów (status odpowiedzi HTTP > 200). Oznacza to, że aby poznać wyniki analizy wielkości i źródeł utraty wpływów w ciągu doby w naszkicowanej tu sytuacji w odwołaniu do indeksu pierwotnego, opisującego transakcje, na realizację zapytania musimy zaczekać około dwóch minut (dokładnie 100 sekund). Gdybyśmy zdecydowali się użyć indeksu sumarycznego i odkładać wyniki zapytania cząstkowego co pięć minut, zapytanie do indeksu sumarycznego obejmujące analogiczny okres zrealizowane zostanie w czasie ułamka sekundy (0,288 sekundy). Jak widać, jest o co powalczyć.

Powiązane wpisy:

Relacyjne bazy danych jako źródło zdarzeń dla Splunk