Podejście do zmniejszania kosztów przetwarzania danych na przykładzie Azure Databricks

geek.justjoin.it 1 rok temu

Big data to siła napędowa biznesu. Posiadanie dużej ilości danych pomaga organizacjom działać bardziej efektywnie i znajdować nowe sposoby na lepsze pomaganie swoim klientom. Niestety istnieje także kwestia kosztów — rozwiązania na dużą skalę generują duże koszty.

Dobrą wiadomością jest to, iż wydatki również można skalować. Jak to osiągnąć? Umiejętności i wiedza na pewno są pomocne, ale gotowość do zajrzenia „pod maskę” i determinacja mogą być równie ważne. Wyjaśnię to na przykładzie zrealizowanego przez nas projektu.

Dążenie do obniżenia wydatków na chmurę

Jakiś czas temu podjęliśmy współpracę z firmą świadczącą usługi wspierające lotniska, takie jak obsługa ładunków, usługi naziemne itp. Ich klienci, czyli linie lotnicze, mogą rezerwować usługi za pośrednictwem portalu internetowego. Rozwiązanie to jest jednym z kluczowych usług dla naszego klienta, generującym duże ilości danych.

W momencie przystąpienia do projektu organizacja otrzymywała 4 miliony publicznych zapytań i 26,4 miliona wiadomości dziennie, co daje łącznie 3,42 TB danych przetwarzanych każdego dnia. Przy generowaniu tak dużej ilości danych, kluczową kwestią było odpowiednie zarządzanie nimi.

Organizacja potrzebowała specjalistycznych narzędzi do zarządzania, przetwarzania i generowania informacji z tak wielkiej ilości sygnałów i źródeł. Stąd decyzja o wprowadzeniu dedykowanej platformy danych.

Pierwsze próby redukcji kosztów chmury

Pierwsza wersja rozwiązania spełniała swoją funkcję, ale była kosztowna. Przetwarzanie danych w ten sposób kosztowało naszego klienta 1 milion funtów rocznie. Nic dziwnego, iż firmie zależało na obniżeniu kosztów.

Zrewidowane podejście opierało się na własnej, wewnętrznej platformie. Rozwiązanie było oparte o Azure Event Hubs i Azure Databricks. Mimo iż to podejście nieco obniżyło koszty, przez cały czas wynosiły one około 700 tysięcy funtów rocznie.

Kwota 700 tysięcy to niemało, o wiele więcej niż planowane koszty, więc dalszy los projektu stanął pod znakiem zapytania.

Firma chciała obniżyć koszt do poziomu poniżej 60 tysięcy funtów. Z punktu widzenia bieżących kosztów był to bardzo ambitny cel, ale jako zespół wierzyliśmy, iż istnieje sposób, aby go osiągnąć.

Czas na FinOps!

Stanęliśmy przed klasycznym problemem FinOps: jak sprawić, żeby klient używał dokładnie tyle zasobów, ile potrzebuje, płacił za nie jak najmniej, a jednocześnie osiągnął swój cel biznesowy?

Na takie pytanie nigdy nie ma prostych odpowiedzi. Najpierw więc spróbowaliśmy zrozumieć obecny sposób wykorzystania zasobów. Ile danych przetwarza Azure Databricks i co się z nimi dzieje?

Podczas przetwarzania danych, Azure Databricks zapisuje zarówno przetworzone dane jak i punkty kontrolne strumieni. W rezultacie operacje zapisu generują największe koszty na platformie.

Jednym z zaproponowanych sposobów optymalizacji była zmiana częstotliwości, z jaką Azure Databricks wykonuje zapisy serii danych. Innymi słowy, jeżeli usługa wykonywałaby „automatyczne zapisy danych” rzadziej, powinno to zmniejszyć obciążenie systemu i w konsekwencji koszty.

Niestety, po wprowadzeniu zmiany, koszty zostały tylko nieznacznie obniżone.

Nie zbliżyliśmy się do celu, którym było 60 tysięcy funtów. Nadszedł czas na głębszą analizę.

Zanurzenie się w Azure Databricks

Kolejnym pomysłem było przyjrzenie się bliżej mechanizmom wewnętrznym Azure Databricks, aby sprawdzić, czy można je zoptymalizować. I tutaj temat zrobił się interesujący.

Aby to wyjaśnić, najpierw przejdźmy przez wewnętrzną strukturę usługi Azure Databricks. Oto diagram architektury od Microsoftu:

Analizując tę architekturę, próbowaliśmy znaleźć miejsca, gdzie moglibyśmy obniżyć koszty.

Maszyny wirtualne nie byłyby zbyt interesującym elementem, ponieważ obciążenia wynikające z przetwarzania były mniej więcej stałe. Zamiast tego zwróciliśmy uwagę na DBFS (Databricks File System), który wykorzystuje Blob Storage do operacji zapisu.

Oszczędzanie kosztów chmury poprzez wymianę domyślnych komponentów

Apache Spark, który jest silnikiem strumieniowania strukturalnego wykorzystywanym przez Azure Databricks, domyślnie korzysta z implementacji systemu plików HDFS (Hadoop Distributed File System) do przechowywania stanu. W większości przypadków działa on doskonale, jednak czasami może prowadzić do opóźnień w GC (Garbage Collection) z powodu przeciążonej pamięci.

Dobra wiadomość jest taka, iż w przypadkach, gdy HDFS nie jest odpowiedni, istnieje alternatywa. W Azure Databricks można użyć RocksDB do przechowywania stanu. Przy dużych wolumenach danych (osiągając miliony rekordów na raz) zachowuje się on bardziej wydajnie z perspektywy odczytu i dokonuje zapisów danych dzięki efektywnemu wykorzystaniu pamięci i lokalnych dysków SSD.

Skorzystaliśmy z tej możliwości i zmieniliśmy system zarządzania stanem na RocksDB. Jak się możecie już domyślać, koszt rozwiązania zmalał i to poniżej założonego celu (obecnie wynosi kilkadziesiąt tysięcy rocznie). Bingo!

Czego się nauczyliśmy oprócz tego jak umożliwić klientowi zaoszczędzenie DUŻEJ ILOŚCI pieniędzy? Nigdy nie akceptuj zastanej sytuacji. Domyślnym komponentem w Azure Databricks (i niektórych innych usług opartych na Spark) jest HDFS, podczas gdy w niektórych scenariusz RocksDB sprawdza się rewelacyjnie.

Nigdy nie akceptuj domyślnych ustawień i komponentów. Podejmij wyzwanie ich zmiany!

Optymalizacja kosztów na poziomie architektury

Udało się nam sprawić, aby klient zaoszczędził pieniądze, optymalizując usługę używaną przez rozwiązanie. Starannie przeanalizowaliśmy jej architekturę i wybraliśmy inny, bardziej wydajny w tym przypadku komponent przechowywania stanu w Azure Databricks. Nie spowodował on żadnych zmian funkcjonalnych, za to udało się obniżyć koszty platformy klienta o ponad 90% w porównaniu z pierwotnym podejściem.

Jeśli chciał*byś dowiedzieć się więcej, szczegóły techniczne są opisane w dokumentacji poniżej.