Analiza petabajtów danych w czasie rzeczywistym bez spowalniania produkcyjnej bazy danych
Oddziel transakcje od analizy danych
W rezultacie wykonanie zapytania z pulpitu nawigacyjnego, które powinno zająć 200 ms, trwa 40 sekund, ponieważ zapytania analityczne skanują 500 mln wierszy, obciążając procesor i operacje wejścia/wyjścia. Użytkownicy czekają zbyt długo na wyniki zapytań, a w końcu cała umowa SLA wisi na włosku. Tego problemu nie da się rozwiązać przez samą optymalizację konfiguracji, konieczna jest zmiana architektury: musisz przestać wykonywać zapytania silnie obciążające produkcyjną bazę danych.
Pozostaw obsługę transakcyjnych operacji odczytu i zapisu bazie PostgreSQL, a zapytania analityczne powierz usłudze OVHcloud Managed ClickHouse. W przypadku analizy petabajtów danych w czasie rzeczywistym pamięć obiektowa zgodna z S3 zapewnia dodatkową, skalowalną warstwę przechowywania danych, uzupełniającą podstawową pamięć masową o wysokiej wydajności i umożliwiającą rozbudowę środowiska analitycznego bez konieczności powiększania produkcyjnej bazy danych.
Wydajność i kontrola nawet przy dużej skali działania
![[object Object]](https://assets.ovhcloud.com/1fipjkCd6Fynpkj2pu4pL37bz_sYmY1YjFkODJlY2IyOGI5/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_79aa0c4f.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fiX5E4qzpXh67Ljo5AmdpyC4_sOTg4ZGYwMzQ5ZmJhOTY0/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_2d4e9ac8.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fipChngFS3mvuo2AkLC4LAjh_sZGYyMTFhOGIzZGFjOWVm/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_1f60228d.svg){kind=small}
![[object Object]](https://assets.ovhcloud.com/1fid6rzboLjodqmFX8pbmmpr8_sZDc4MTgzZjQ2OTg2NTIw/1c4b1724-8eb2-433e-817d-75cffa9e8203_ite_0703c5fb.svg){kind=small}
Dlaczego skalowanie produkcyjnych baz danych nie wystarcza, aby sprostać potrzebom analitycznym
Obciążenie transakcyjnych baz danych
Transakcyjne bazy danych doskonale sprawdzają się w szybkim wyszukiwaniu rekordów oraz wstawianiu i aktualizowaniu danych. Analiza petabajtów danych w czasie rzeczywistym stawia jednak inne wymagania: skanowanie dużych zbiorów danych, złożone operacje łączenia tabel i wielokrotne agregacje konkurują z bieżącymi operacjami produkcyjnymi o zasoby procesora, pamięć RAM i prędkość transmisji danych pamięci masowej. Produkcyjna instancja bazy danych Public Cloud jest przeznaczona do obsługi transakcji, a nie do analizy danych. Gdy zespoły biznesowe zaczynają potrzebować pulpitów nawigacyjnych działających w czasie rzeczywistym, wykrywania oszustw lub zapytań służących do segmentacji klientów na podstawie terabajtów danych historycznych… wydajność gwałtownie spada.
Ograniczenia replik odczytu
Repliki odczytu w Public Cloud Databases są najczęściej pierwszym rozwiązaniem stosowanym, gdy zapytania analityczne zaczynają obciążać produkcyjne bazy danych. Odciążają one węzeł główny, przejmując obsługę operacji odczytu, ale nie rozwiązują problemu niedostosowania architektury do obciążeń analitycznych. Replika odczytu może zmniejszyć konkurencję o zasoby głównej bazy danych, ale gdy wykonujesz zapytanie SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' na zbiorze 500 mln wierszy, nadal musi odczytać i odrzucić niemal wszystkie wiersze. Te zapytania analityczne konkurują z transakcjami produkcyjnymi o zasoby procesora, pamięć RAM i operacje wejścia/wyjścia (I/O). Rosną opóźnienia w działaniu aplikacji, pojawia się ryzyko niedotrzymania warunków SLA, a realizacja use case’ów wymagających działania w czasie rzeczywistym, takich jak wykrywanie oszustw czy monitorowanie anomalii, staje się niemożliwa.
Trwałe rozdzielenie obciążeń
Trwałym rozwiązaniem jest rozdzielenie obciążeń roboczych. Apache Kafka przesyła strumieniowo zdarzenia po zatwierdzeniu transakcji do wyspecjalizowanej platformy przeznaczonej do analizy petabajtów danych. Produkcyjne bazy danych nadal obsługują transakcje, a środowisko analityczne można niezależnie skalować na potrzeby przetwarzania dużych ilości danych, strumieniowej analizy danych, sztucznej inteligencji i analityki biznesowej.
Dobierz odpowiedni silnik do każdego rodzaju obciążenia
Przechowują dane wiersz po wierszu i są zoptymalizowane pod kątem wyszukiwania pojedynczego rekordu klienta lub aktualizacji statusu zamówienia w czasie liczonym w milisekundach.
Systemy OLAP są natomiast zaprojektowane do skanowania bilionów wierszy w celu wykonywania złożonych agregacji. Wykorzystują przechowywanie kolumnowe, w którym każda kolumna jest zapisywana niezależnie od pozostałych. Oznacza to, że podczas wykonywania zapytania SUM(revenue) WHERE date > '2025-01-01' baza danych odczytuje tylko kolumny revenue i date, pomijając wszystkie pozostałe. Na przykład w ClickHouse operacje są wykonywane wektorowo. ClickHouse przetwarza jednocześnie całe tablice wartości, a nie pojedyncze wiersze, co znacznie zmniejsza obciążenie procesora i maksymalizuje wykorzystanie pamięci podręcznej.
Żadne indeksowanie danych, optymalizacja zapytań ani modernizacja sprzętu nie sprawią, że baza danych o architekturze wierszowej będzie wydajna podczas skanowania kolumnowego. Architektury te różnią się od siebie zasadniczo.
Dobierz odpowiednią metodę ładowania danych dla każdego źródła
Przetwarzanie strumieniowe
Przesyłaj dane o zdarzeniach w sposób ciągły, gdy operacyjne pulpity nawigacyjne i alerty wymagają wyników analiz z niewielkim opóźnieniem.
Przetwarzanie wsadowe
Wykorzystuj przetwarzanie wsadowe ETL z użyciem Airflow, aby zgodnie z harmonogramem uzupełniać dane historyczne, okresowo eksportować dane i masowo ładować dane ze źródeł.
Przechwytywanie zmian danych (CDC)
Przesyłaj zatwierdzone zmiany w bazie danych, ograniczając dodatkowe obciążenie źródłowej bazy transakcyjnej.
Bezpośrednie ładowanie danych
Pozwól aplikacjom bezpośrednio zapisywać zdarzenia analityczne, gdy Twoje zespoły definiują kontrakt zdarzeń i zarządzają nim.
Oddzielenie OLTP od OLAP
Gdy wykonujesz zapytanie SUM(revenue) obejmujące 5 miliardów wierszy, baza danych odczytuje tylko kolumnę revenue, pomijając wszystkie pozostałe. Pozwala to ograniczyć liczbę operacji wejścia/wyjścia (I/O) o co najmniej 90% i uzyskać wysoki stopień kompresji, ponieważ wartości w obrębie jednej kolumny są do siebie podobne.
Wykonywanie wektorowe jest drugim czynnikiem zwiększającym wydajność. Tradycyjne bazy danych przetwarzają wiersze pojedynczo. ClickHouse przetwarza jednocześnie całe tablice wartości, wczytując fragment kolumny revenue do pamięci podręcznej procesora i wykonując operacje na całym wektorze za pomocą jednej instrukcji. Pozwala to znacznie zmniejszyć obciążenie procesora.
Połączenie tych dwóch rozwiązań umożliwia wykonywanie zapytań obejmujących miliardy wierszy w czasie krótszym niż sekunda. Przechowywanie kolumnowe minimalizuje liczbę odczytów z dysku, a wykonywanie wektorowe – obciążenie procesora. ClickHouse może przeprowadzić agregację danych z 10 miliardów wierszy w czasie krótszym niż sekunda, podczas gdy instancja PostgreSQL potrzebuje na to kilku minut.
![[object Object]](https://assets.ovhcloud.com/1fiz3Ewd3ACopFnjLbkLvoSdp_sYjBlNTU5YjQyYWVjNjdl/76542f62-8c49-48e5-92ec-910825c8d69c_ima_e302634e.png)
Projektuj z myślą o aktualności danych, szybkości działania, odporności na awarie i zarządzaniu
Przetwarzanie wsadowe ETL
Przetwarzanie wsadowe ETL to najprostsze rozwiązanie na początek.
Pobieraj dane z produkcyjnej bazy danych zgodnie z harmonogramem (co godzinę lub codziennie), przekształcaj je za pomocą dbt i ładuj do ClickHouse. Potokiem danych może zarządzać Airflow, a w przypadku prostych skryptów wystarczą zadania cron.
Takie rozwiązanie sprawdza się, gdy dane nie muszą być aktualizowane co minutę. Pulpity nawigacyjne aktualizowane co godzinę sprawdzają się w wielu zastosowaniach biznesowych, a przetwarzanie wsadowe jest łatwiejsze do monitorowania i diagnozowania błędów.
Wadą tego rozwiązania jest jednak wynikające z niego opóźnienie. Między kolejnymi cyklami przetwarzania wsadowego dane tracą aktualność, przez co wykrywanie oszustw i personalizacja w czasie rzeczywistym nie są możliwe. Przetwarzanie wsadowe ETL to odpowiednie rozwiązanie, gdy dopiero zaczynasz korzystać z ClickHouse, nie masz doświadczenia w przetwarzaniu strumieniowym lub możesz zaakceptować dane z godzinnym opóźnieniem.
Przechwytywanie zmian danych (CDC) w czasie rzeczywistym
Mechanizm przechwytywania zmian danych (CDC) przesyła strumieniowo do ClickHouse informacje o każdej operacji wstawiania, aktualizacji i usuwania danych w produkcyjnej bazie danych, niemal w czasie rzeczywistym. Debezium odczytuje dziennik transakcji Twojej bazy danych (WAL w przypadku PostgreSQL, binlog w przypadku MySQL) i publikuje informacje o zmianach w Apache Kafka. ClickHouse pobiera dane z Apache Kafka i natychmiast zapisuje je w bazie danych.
Narzędzia CDC zapewniają opóźnienia od ułamków sekundy do kilku sekund, umożliwiając prawdziwą analizę danych w czasie rzeczywistym: wykrywanie oszustw pozwalające identyfikować i blokować nieuczciwe transakcje w momencie ich realizacji, monitorowanie anomalii z alertami generowanymi w ciągu kilku sekund oraz personalizację, która natychmiast reaguje na zachowania użytkowników, wspierając ich działania.
Warstwowe przechowywanie danych pozwalające utrzymać liniowy wzrost kosztów przy skali petabajtowej
Przechowywanie petabajtów danych na dyskach SSD jest zbyt kosztowne. Warstwowe przechowywanie danych umożliwia przenoszenie starszych danych do tańszej pamięci obiektowej, podczas gdy nowsze dane pozostają na szybkich dyskach lokalnych.
Na przykład usługa OVHcloud Managed ClickHouse obsługuje ten mechanizm natywnie, wykorzystując narzędzia do przetwarzania strumieniowego oraz usługę OVHcloud Object Storage (zgodną z S3)*. Najnowsze dane (z ostatnich 30–90 dni) pozostają na dyskach SSD NVMe.
Starsze dane są automatycznie przenoszone do zasobnika usługi OVHcloud Object Storage, gdzie można je przechowywać za ułamek kosztów, zachowując możliwość szybkiego wykonywania zapytań, ponieważ ClickHouse odczytuje tylko potrzebne kolumny. Z punktu widzenia zespołów inżynierskich koszty rosną liniowo wraz ze skalowaniem – każdy dodatkowy terabajt kosztuje tyle samo, niezależnie od tego, czy przechowujesz 10 TB, czy 100 TB.
Wstępna agregacja na etapie ładowania danych
Nawet w przypadku przechowywania kolumnowego każdorazowe skanowanie surowych danych jest kosztowne.
Widoki zmaterializowane umożliwiają wstępne obliczanie agregatów na etapie ładowania danych.
W ClickHouse widok zmaterializowany jest aktywnym potokiem przetwarzania danych, a nie pasywnym snapshotem. Podczas wstawiania danych ClickHouse automatycznie wykonuje zapytanie definiujące widok i zapisuje wyniki w oddzielnej tabeli.
Jeśli ładujesz 100 000 zdarzeń na sekundę i korzystasz z widoku agregującego dane w podziale na minuty i segmenty, ClickHouse oblicza te agregaty w czasie rzeczywistym.
Dlaczego ClickHouse jest właściwym silnikiem do analizy danych w czasie rzeczywistym
Dzięki przechowywaniu kolumnowemu, wykonywaniu wektorowemu i wysokiemu stopniowi kompresji ClickHouse wykonuje zapytania skanujące miliardy wierszy w czasie krótszym niż sekunda. Potrafi agregować 10 miliardów wierszy w czasie krótszym niż sekunda, podczas gdy PostgreSQL potrzebuje na to kilku minut, a inne hurtownie danych – od kilku do kilkudziesięciu sekund.
ClickHouse oferuje stabilny model rozliczeń oparty na wykorzystaniu zasobów, obsługę dużej liczby jednoczesnych zapytań i efektywne skalowanie, dzięki czemu doskonale nadaje się do interaktywnej analizy danych w czasie rzeczywistym. Redshift najlepiej sprawdza się w hurtowniach danych opartych na przetwarzaniu wsadowym, przy przewidywalnym obciążeniu roboczym i wykorzystaniu istniejącej infrastruktury AWS. BigQuery doskonale sprawdza się w bezserwerowej analizie danych przy sporadycznie wykonywanych zapytaniach oraz w przypadku zespołów, które chcą całkowicie wyeliminować nakład pracy związany z obsługą operacyjną.
ClickHouse wykorzystuje dialekt SQL, który jest w 90% zgodny ze standardowym sposobem pracy z SQL, jednak występują pewne istotne różnice. Funkcje agregujące wykorzystują tabele MergeTree, które wymagają specyficznej składni silnika. Większość zapytań SELECT można przenieść bez zmian, ale złożone operacje JOIN i podzapytania mogą wymagać optymalizacji.
Poznaj usługę OVHcloud Managed ClickHouse lub skorzystaj z pomocy naszych specjalistów, aby dobrać architekturę o odpowiedniej skali, uwzględniając ilość danych, wymagania dotyczące ich aktualności i okresu przechowywania oraz liczbę jednocześnie wykonywanych zapytań.