W świecie inżynierii danych rachunki chmurowe rzadko eksplodują z dnia na dzień. Dużo częściej budżet wycieka w tle, powoli i niepostrzeżenie, by po kilku miesiącach zmusić Cię do nieprzyjemnej rozmowy z dyrektorem finansowym. Adam Zuzo, inżynier danych występujący na MeetUpie SO/DO, przeanalizował operacyjne wyzwania DataOps na przestrzeni różnych etapów dojrzałości technologicznej.
Większość problemów na wczesnym etapie wdrażania analityki danych (do 5 TB pamięci masowej) nie wynika ze złożoności infrastruktury, a z tzw. hype trainu. Inżynierowie chcą używać potężnych i modnych systemów Big Data, takich jak hurtownie danych Amazon Redshift, nawet jeśli analizują jedynie kilkaset gigabajtów prostych plików CSV. Utrzymanie klastra, który działa w trybie provisioned (płatność per godzina za węzeł obliczeniowy), generuje w takich sytuacjach rachunki rzędu tysięcy dolarów za instancję, która przez większość dnia po prostu stoi pusta (w trybie idle).
Adam Zuzo podkreśla, że w małej skali kluczem do sukcesu jest Brzytwa Ockhama, czyli celowe dążenie do prostoty. Zamiast płacić za kosztowne, pracujące w tle węzły hurtowni danych, wystarczy przenieść ciężar na technologie serverless (np. odpytywanie danych z S3 za pomocą Amazon Athena oraz lekkie funkcje AWS Lambda). Przejście z modelu opłat za czas działania na model oparty o wolumen zeskanowanych bajtów (Athena) potrafi obniżyć koszty infrastruktury DataOps nawet o ponad 90%. Podobna zasada dotyczy oprogramowania Business Intelligence – używanie przez zespół sześciu różnych narzędzi analitycznych (Tableau, PowerBI, Superset) tworzy decentralizację wiedzy i podwójne koszty licencyjne, dlatego w małej skali unifikacja do jednego rozwiązania BI drastycznie redukuje przepalanie budżetu.
Gdy organizacja wchodzi w średnią skalę analityczną, gdzie rośnie liczba tabel i użytkowników (analityków biznesowych), koszty zaczynają wymykać się spod kontroli z powodu nieoptymalnych zapytań (queries). Odpytywanie niespartycjonowanej tabeli o rozmiarze 10 TB oznacza, że silnik bazodanowy zmuszony jest skanować wszystkie wiersze, by dopiero na samym końcu odfiltrować z nich interesujący użytkownika wycinek czasu (np. ubiegły tydzień). Ten mechanizm uderza w chmurowy budżet z podwójną siłą.
Rozwiązaniem tego problemu jest bezwzględne wprowadzenie partycjonowania i tzw. partition pruning. Jeśli dane na storage’u zostaną fizycznie podzielone na mniejsze kawałki według klucza (np. daty lub segmentu rynkowego), silnik z góry pominie odczyt całego zbioru i pobierze z AWS S3 zaledwie niewielki odsetek informacji. To drastycznie zmniejsza ilość przeskanowanych megabajtów. Ważnym wyzwaniem DataOps na tym etapie jest także zignorowanie ślepego zaufania do konkretnego narzędzia BI. Przykładowo, popularny Apache Superset wysyła zapytania za pomocą zdefiniowanego pod spodem silnika analitycznego. Podmiana samego konektora analitycznego z Ateny na Snowflake (lub odwrotnie), potrafi na tych samych dashboardach dziesięciokrotnie zbić rachunki za odpytywania, w zależności od preferowanego modelu cennika (płatność za skan vs. czas zapytania).
Przy skali mikro (powyżej 100 terabajtów lub nawet petabajtach danych) pozornie nieznaczne, nudne detale techniczne uderzają w finanse ze zdwojoną mocą. Standardem dla zespołów Big Data powinno być cykliczne przenoszenie archiwalnych, rzadziej używanych logów i metryk do chłodniejszych, tańszych klas pamięci masowej, np. z S3 Standard do S3 Infrequent Access. Podstawą zarządzania oszczędnościami w wielkiej skali na AWS jest wdrożenie i obserwacja dedykowanych dashboardów S3 Storage Lens.
O tym, czy system zadziała poprawnie w skali makro, ostatecznie decyduje sama architektura wybranego pliku. Ekspert uświadamia zespołom inżynieryjnym, że rozszerzenie .json a .parquet czy .orc to fundamentalnie inna budowa fizyczna danych. Pliki kolumnowe, takie jak Parquet skompresowane algorytmem Snappy, są genialne do odpytywania olbrzymich tabel na hurtowniach, podczas gdy silniki bazujące na AWS Athena mogą się całkowicie „zadławić” przy odczycie tysięcy malutkich plików CSV lub ORC. Ponadto silniejsze algorytmy kompresji (np. GZIP) zmniejszają co prawda koszt storage’u o ułamki dolarów w porównaniu do standardów branżowych, ale dekompresja takiego pliku w czasie rzeczywistym bywa tak zasobożerna i długa dla klastra obliczeniowego, że firma całkowicie traci poczynione początkowo oszczędności.
Utrzymywanie skomplikowanej chmury obliczeniowej bez znajomości optymalizacji to najprostsza droga do zrujnowania budżetu. Chcesz zobaczyć wszystkie wykresy kosztowe udostępnione przez Adama oraz pogłębić wiedzę o DataOps?
Pełne nagranie prelekcji dostępne tutaj: DataOps i koszty: operacyjne wyzwania danych – Adam Zuzo
Nadchodzące eventy
Znajdź nas na:
Dochód z działalności komercyjnej jest przeznaczony na realizację celów statutowych Fundacji SysOps/DevOpsPolska.
