Jak zaoszczędzić pieniądze w Microsoft Azure?

Poradnik, który przekazuję w Wasze ręce zawiera 5 podstawowych sposobów na znalezienie oszczędności dla rozwiązania Data Integration w chmurze Azure. Mam szczerze nadzieję, że w niniejszym materiale znajdziecie coś dla siebie, choć zaznaczam, że poniższe porady są raczej dla początkujących niż doświadczonych specjalistów.

Część I - Azure Databricks i 5 praktycznych sposobów na optymalizację kosztów

1) Dostosuj wielkość klastra do własnych potrzeb.

Do zadań developerskich nie potrzebujesz największego klastra. Ograniczaj ilość przetwarzanych danych i zmniejsz wielkość klastra do minimum. Często nawet najniższa wersja jest wystarczająca!

2) Używaj opcji wyłączania klastra przy braku aktywności

Możesz ustawić czas nieaktywności, po którym klaster wyłączy się automatycznie. Tą opcję polecam szczególnie dla developerskich klastrów, dzięki niej nie zapomnisz wyłączyć klastra po skończonej pracy. Hint! Upewnij się ze posiadasz na klastrze tylko te biblioteki, z których obecnie korzystasz. Dlaczego? Otóż przy uruchamianiu klastra musimy poczekać na skończenie instalacji bibliotek co przy dużej ich ilości może trwać naprawdę długo!

3) Upewnij się czy na pewno potrzebujesz ciągle aktywnego klastra.

Czy twoje joby naprawdę przetwarzają/lądują dane nieprzerwanie?

W wielu przypadkach „real time” dla klienta to tak na dobrą sprawę jest godzina, dwie, czasem dłużej. Jednak często nasz job wykonuje się w 5 minut, a przez pozostały czas stoi bezczynny. W takich wypadkach warto włączyć tryb „auto wyłączanie”, nawet jeśli oznacza to, że musimy włączać i wyłączać ten klaster wiele razy.

Jak rozumiem, na pewno nie chcesz przerabiać swoich streamingowych notebooków na ładowanie batchowe. Na szczęście istnieje rozwiązanie tego problemu. Z pomocą przychodzi nam metoda trigger:

 writeStream  
 .trigger(Trigger.Once)

Pozwala on na wysłanie/odebranie nowych eventów po czym zamyka stream. Pamiętajmy, że niezbędne jest uprzednie zaimportowanie biblioteki:

 import org.apache.spark.sql.streaming.Trigger

Następnie należy ustawić joba na wybranym notebooku uruchamiającego go co godzinę (lub inny wybrany okres czasu).

Wyobraźmy sobie sytuacje, w której wysyłasz 500 wiadomości do EventHub’a co godzinę. Trwa to dosłownie parę sekund, następnie klaster jest bezczynny, lecz pobiera pieniądze za funkcjonowanie w tle. Za pomocą Trigger.Once możesz osiągnąć to samo, a następnie przy klastrze ustawionym na wyłączanie się przy braku aktywności przez pozostałe 55 minut oszczędzasz środki.

4) Po zapisie danych do Delta Table pamiętaj, by stosować OPTIMIZE i VACUUM.

Delta tables są naprawdę bardzo użyteczne, jest to dobry krok naprzód w porównaniu do formatu Parquet. Jednakże, warto czasem spojrzeć co się dzieje na ADL. Jeśli naszym źródłem jest wiele małych plików to zapis do Delty również będzie tworzył wiele małych plików w tym formacie.

Stwarza nam to dwa zasadnicze problemy:

1. Wydajnościowy - przetwarzanie danych najefektywniej działa na plikach wielkości około 1GB.

2. Kosztowy - jeśli zwrócimy uwagę na cennik Azure Data Lake, to przy informacji na temat kosztów transakcji zauważymy, że koszty za transakcje są liczone per plik, do 4MB wielkości. W związku z tym zapis 100 plików po 10KB będzie 100 razy droższy niż zapis 1 pliku 1MB.

Z FAQ cennika:

By uniknąć obu wcześniej wymienionych problemów, używamy następującej komendy:

1. OPTIMIZE

Optimize pozwala nam połączyć wszystkie małe pliki w partycji w pliki o wielkości do 1GB. Wygląda to następująco:

%SQL
OPTIMIZE events
 
OPTIMIZE events WHERE date >= '2017-01-01'
 
OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

Jednak OPTIMIZE nie usuwa nam starych plików. Tutaj z pomocą przychodzi nam kolejna komenda. 2. VACUUM

Komenda ta czyści pliki związane z tabelą.

 VACUUM [db_name.]table_name|path [RETAIN num HOURS] [DRY RUN]

Użycie opcji DRY RUN wyświetli nam pliki, które zostaną usunięte. Domyślnie VACUUM nie można przeprowadzić na plikach młodszych niż 168 godzin. Jednak zabezpieczenie to możemy wyłączyć, jeśli jesteśmy pewni, że nic nie stracimy, lub możemy łatwo dostać się do tych plików raz jeszcze.

spark.databricks.delta.retentionDurationCheck.enabled to false

Uwaga: Usuwając stare pliki tracimy opcje cofnięcia się do poprzednich wersji plików!

5) Upewnij się, że twoje ADF’owe pipeline nie tworzą nowych klastrów Azure Databricks

Może się to wydawać oczywiste, ale wielokrotnie byłem świadkiem, jak ktoś przez nieuwagę przy tworzeniu pipeline i triggerowaniu notebooka nie zaznaczył istniejącego klastra. Wówczas job ten tworzył za każdym razem nowy klaster po czym go wyłączał mimo że inny był aktywny i bezczynny.

Podsumowując, jak widać istnieją konkretne sposoby na pozyskanie konkretnych oszczędności. Wierzę, że znaleźliście coś dla siebie i dzięki temu zaoszczędzicie klientowi trochę środków na subskrypcji. Na pewno będzie wam wdzięczny!

Maciej Replin

BI Developer w BitPeak

maciej.replin@bitpeak.pl

Zachęcamy do śledzenia naszego bloga, już niedługo kolejne artykułu z serii Azure Tips&Tricks.