Analiza petabajtów danych w czasie rzeczywistym bez wpływu na bazę danych
Jak analizować petabajty danych w czasie rzeczywistym bez spowalniania produkcyjnej bazy danych?
Rozwijające się aplikacje osiągają ten sam punkt zwrotny, w którym firma chce odpytywać bazę danych PostgreSQL lub MySQL zawierającą petabajty danych w sposób, do którego nigdy nie została zaprojektowana.
Rezultat: zapytanie do pulpitu nawigacyjnego, które powinno zająć 200 ms, trwa 40 sekund, ponieważ analityka skanuje 500 mln wierszy, obciążając procesor i operacje wejścia/wyjścia. Użytkownicy czekają zbyt długo na wyniki zapytań, a w efekcie cała umowa SLA wisi na włosku.
To nie jest problem, który można rozwiązać poprzez dostrajanie; wymaga on zmiany architektury: musisz przestać uruchamiać ciężkie zapytania na swojej produkcyjnej bazie danych.
W tym artykule poznasz wzorzec architektury służący do oddzielenia OLTP od OLAP, dowiesz się, jak bezpiecznie przesyłać dane do ClickHouse oraz dlaczego usługa zarządzana OVHcloud jest odpowiednim rozwiązaniem dla zespołów SaaS, FinTech, AdTech i e-commerce skalujących się do miliardów wierszy.
Dlaczego produkcyjna baza danych jest niewłaściwym miejscem do uruchamiania analityki
Produkcyjna instancja bazy danych Public Cloud jest zbudowana do transakcji, a nie do analityki. Gdy zespoły biznesowe zaczynają prosić o pulpity nawigacyjne w czasie rzeczywistym, wykrywanie oszustw lub zapytania dotyczące segmentacji klientów na terabajtach danych historycznych… cóż, wydajność drastycznie spada.
Dzieje się tak nie tyle dlatego, że infrastruktura jest słaba, ale dlatego, że aplikacja używa niewłaściwego narzędzia do tego zadania.
OLTP a OLAP
OLTP (przetwarzanie transakcyjne online) i OLAP (przetwarzanie analityczne online) znajdują się na przeciwległych końcach spektrum architektury danych.
Systemy OLTP priorytetowo traktują poprawność i precyzję na poziomie transakcji, obsługując tysiące małych, szybkich zapisów i odczytów na sekundę. Przechowują dane wiersz po wierszu, zoptymalizowane pod kątem wyszukiwania pojedynczego rekordu klienta lub aktualizacji statusu zamówienia w milisekundach.
Systemy OLAP natomiast są zaprojektowane do skanowania bilionów wierszy w celu wykonywania złożonych agregacji. Wykorzystują one przechowywanie kolumnowe, w którym każda kolumna jest przechowywana niezależnie. Oznacza to, że gdy wykonujesz zapytanie SUM(revenue) WHERE date > '2025-01-01', baza danych odczytuje tylko kolumny revenue i date, pomijając wszystko inne. Na przykład w ClickHouse operacje są wykonywane w ramach wektorowego przetwarzania. ClickHouse przetwarza całe tablice wartości jednocześnie, zamiast pojedynczych wierszy, co drastycznie zmniejsza obciążenie procesora i maksymalizuje wykorzystanie pamięci podręcznej.
Żadna ilość indeksowania danych, optymalizacji zapytań ani modernizacji sprzętu nie sprawi, że baza danych zorientowana wierszowo będzie wydajna w skanowaniu kolumnowym. Te architektury są fundamentalnie różne.
Dlaczego repliki odczytu nie rozwiążą tego problemu
Repliki odczytu w Public Cloud Databases są najczęstszą pierwszą odpowiedzią na presję analityczną wywieraną na produkcyjne bazy danych. Odciążają one ruch odczytu z węzła głównego, ale nie rozwiązują niedopasowania architektonicznego.
Replika odczytu może zmniejszyć rywalizację o zasoby w Twojej głównej bazie danych, ale kiedy uruchamiasz SELECT SUM(revenue), COUNT(*) FROM events WHERE date >= '2024-01-01' dla 500 mln wierszy, replika nadal odczytuje i odrzuca prawie każdy wiersz.
Te zapytania analityczne konkurują z transakcjami produkcyjnymi o CPU, pamięć i I/O. Opóźnienia aplikacji rosną, SLA są zagrożone, a przypadki użycia w czasie rzeczywistym, takie jak wykrywanie oszustw czy monitorowanie anomalii, stają się niemożliwe.
Zapytanie 40-sekundowe, które powinno zająć 200 ms
Oto typowy scenariusz dla firmy typu SaaS scale-up lub platformy FinTech, która osiąga punkt zwrotny w danych. Uruchamiane jest zapytanie, którego celem jest agregacja dziennych przychodów według segmentu klientów w okresie 18 miesięcy (500 mln wierszy),
Oczekiwany czas wykonania w modelu domenowym OLAP wynosi 200 ms, ale rzeczywisty czas na platformie OLTP kończy się na 40 sekundach. Dlaczego? Oto co dzieje się w tle:
Pełne skanowanie tabeli: Platforma PostgreSQL/MySQL musi odczytać wszystkie 500 mln wierszy, ponieważ indeks nie pomaga przy szerokich agregacjach.
Przetwarzanie wiersz po wierszu: Każdy wiersz jest dekompresowany, analizowany i oceniany indywidualnie.
Wąskie gardło I/O: Odczyty z dysku dominują – większość odczytanych danych jest odrzucana.
Marnotrawstwo CPU: Cykle procesora zużywane na analizę wierszy zamiast na jakość agregacji.
Obciążenie pamięci: Duże sortowania i złączenia haszujące są przenoszone na dysk.
Wpływ na biznes jest natychmiastowy i narastający, ponieważ pulpit nawigacyjny danych, który powinien być aktualizowany co godzinę, w praktyce może być generowany tylko raz dziennie, co opóźnia decyzje biznesowe.
Decyzje biznesowe są opóźnione, ponieważ analityka minutowa staje się zbyt kosztowna, a funkcje czasu rzeczywistego stają się niemożliwe do zrealizowania na dużą skalę. I to ma znaczenie – responsywność w czasie rzeczywistym jest niezbędna w przypadkach użycia takich jak wykrywanie oszustw, personalizacja i monitorowanie anomalii. Te przypadki użycia nie są wykonalne przy opóźnieniu zapytania wynoszącym 40 sekund.
Wzorzec architektury: oddzielenie OLTP od OLAP
Rozwiązaniem jest separacja architektoniczna: uruchamianie transakcji na instancji bazy danych OLTP i przesyłanie danych strumieniowo do oddzielnej instancji OLAP, stworzonej do skanowania miliardów wierszy w czasie poniżej sekundy. Każdy system robi to, do czego został zaprojektowany, bez wpływu na drugi.
Wyjaśnienie przechowywania kolumnowego i wykonywania wektorowego
PostgreSQL i MySQL przechowują dane wiersz po wierszu, co ma sens w przypadku transakcji inżynieryjnych pobierających pojedyncze rekordy, ale jest fatalne dla analityki agregującej jedną kolumnę w miliardach wierszy. ClickHouse przechowuje dane kolumnowo.
Gdy wykonujesz zapytanie SUM(przychód) dla 5 miliardów wierszy, odczytywana jest tylko kolumna przychodu, z pominięciem wszystkiego innego. Zmniejsza to operacje wejścia/wyjścia o 90% lub więcej i umożliwia agresywną kompresję, ponieważ wartości w kolumnie są do siebie podobne.
Wykonywanie wektorowe jest drugim czynnikiem zwiększającym wydajność. Tradycyjne bazy danych przetwarzają jeden wiersz na raz. ClickHouse przetwarza całe tablice wartości jednocześnie, ładując fragment kolumny przychodu do pamięci podręcznej procesora i wykonując operacje na całym wektorze w ramach jednej instrukcji. To drastycznie zmniejsza obciążenie procesora.
To połączenie umożliwia wykonywanie zapytań w czasie poniżej sekundy na miliardach wierszy. Przechowywanie kolumnowe minimalizuje odczyty z dysku; wykonywanie wektorowe minimalizuje pracę procesora. ClickHouse potrafi zagregować 10 miliardów wierszy w czasie poniżej sekundy, podczas gdy instancja PostgreSQL zajmuje to minuty.
Zmaterializowane widoki: preagregacja w czasie pozyskiwania danych
Nawet przy kolumnowym przechowywaniu danych, skanowanie surowych danych za każdym razem jest kosztowne. Zmaterializowane widoki wstępnie obliczają agregaty w momencie pozyskiwania danych.
W ClickHouse zmaterializowany widok jest aktywnym potokiem, a nie pasywną migawką. Podczas wstawiania danych, ClickHouse automatycznie ocenia zapytanie widoku i zapisuje wyniki do oddzielnej tabeli.
Jeśli pozyskujesz 100 000 zdarzeń na sekundę z widokiem agregującym według minuty i segmentu, ClickHouse oblicza te agregaty w czasie rzeczywistym.
Twój pulpit nawigacyjny odpytuje wstępnie zagregowaną tabelę zamiast skanować surowe zdarzenia. Przenosi to koszt z czasu zapytania na czas pozyskiwania danych, akceptując niewielki narzut zapisu dla natychmiastowej odpowiedzi na zapytanie. W przypadku pulpitów nawigacyjnych działających w czasie rzeczywistym (minuta po minucie) i wykrywania oszustw, zmaterializowane widoki eliminują opóźnienia między dotarciem danych a możliwością ich odpytania.
Umożliwiają one również analitykę wielorozdzielczą: zachowaj surowe dane do celów kryminalistycznych, utrzymując jednocześnie godzinowe/dzienne agregaty dla pulpitów nawigacyjnych. W miarę starzenia się danych, odpytuj bardziej ogólne agregaty, utrzymując stałą wydajność podczas skalowania od terabajtów do petabajtów.
Warstwowe przechowywanie danych pozwala utrzymać liniowe koszty w skali petabajtów
Przechowywanie petabajtów na dyskach SSD jest zaporowo drogie. Warstwowe przechowywanie przenosi starsze dane do tańszej pamięci obiektowej, utrzymując jednocześnie najnowsze dane na szybkich dyskach lokalnych.
Na przykład, OVHcloud Managed ClickHouse implementuje to natywnie w narzędziach z przetwarzaniem strumieniowym OVHcloud Object Storage (zgodnym z S3)*. Najnowsze dane (30–90 dni) pozostają w strumieniu na dyskach NVMe SSD.
Starsze dane automatycznie migrują do zasobnika OVHcloud Object Storage za ułamek kosztów, wciąż umożliwiając szybkie zapytania, ponieważ ClickHouse odczytuje tylko potrzebne kolumny. Koszty dla inżynierów pozostają liniowe w miarę skalowania: każdy dodatkowy terabajt kosztuje tyle samo przy 10 TB, co przy 100 TB.
ClickHouse odpytuje dane z OVHcloud Object Storage bez użycia Athena, Presto czy Spark. Gorące dane na SSD, zimne dane na S3, wszystko przez ten sam interfejs SQL. Eliminuje to konieczność utrzymywania oddzielnych systemów dla danych gorących i zimnych.
Warstwowe przechowywanie danych upraszcza również ich długoterminowe retencję: przechowuj surowe dane bezterminowo w celu zapewnienia zgodności z przepisami, nie wydając przy tym fortuny. Chcesz przeszukiwać dane sprzed 18 miesięcy na potrzeby dochodzeń? ClickHouse odczytuje je z OVHcloud Object Storage S3*, który jest wolniejszy, ale wciąż wystarczająco szybki do analizy ad-hoc.
Jak dostarczać dane do warstwy analitycznej
Gdy już oddzielisz instancję OLTP od narzędzi OLAP, musisz przenieść dane ze swojej produkcyjnej bazy danych do ClickHouse. Istnieją trzy główne wzorce, z których każdy wiąże się z różnymi kompromisami w zakresie opóźnień, złożoności i narzutu operacyjnego.
Batch ETL z użyciem Airflow, dbt lub zadań cron
Batch ETL to najprostszy punkt wyjścia. Wyodrębniaj dane ze swojej produkcyjnej bazy danych zgodnie z harmonogramem (co godzinę lub codziennie), przekształcaj je za pomocą dbt i ładuj do ClickHouse. Airflow zarządza potokiem danych lub proste skrypty obsługiwane są przez zadania cron.
To rozwiązanie sprawdza się, gdy nie potrzebujesz danych aktualizowanych z minutową dokładnością. Godzinowe raporty są wystarczające w wielu przypadkach biznesowych, a przetwarzanie wsadowe jest łatwiejsze w debugowaniu i monitorowaniu. Nieudane zadania są ponawiane zgodnie z harmonogramem, a uzupełnianie danych historycznych jest proste.
Kompromisem jest opóźnienie, które w ten sposób tworzysz. Dane między partiami są nieaktualne, więc wykrywanie oszustw w czasie rzeczywistym lub personalizacja na żywo nie są możliwe. Uruchamiasz również ciężkie zapytania ekstrakcyjne na produkcji w oknie wsadowym, co może powodować rywalizację o zasoby, jeśli nie zaplanujesz ich na okresy niskiego ruchu. Batch ETL jest odpowiedni, gdy zaczynasz pracę z ClickHouse, brakuje Ci doświadczenia w strumieniowaniu lub akceptujesz godzinne opóźnienie danych.
Analityka CDC w czasie rzeczywistym z Apache Kafka i Debezium
Change Data Capture (CDC) przesyła każde wstawienie, aktualizację i usunięcie z produkcji do ClickHouse niemal w czasie rzeczywistym. Debezium odczytuje dziennik transakcji Twojej bazy danych (WAL dla PostgreSQL, binlog dla MySQL) i publikuje zmiany w Apache Kafka. ClickHouse pobiera dane z Kafki i natychmiast je wstawia.
Narzędzia CDC osiągają opóźnienia od ułamków sekundy do kilku sekund, umożliwiając prawdziwą analitykę danych w czasie rzeczywistym: wykrywanie oszustw, które identyfikuje i blokuje transakcje w momencie ich wystąpienia, monitorowanie anomalii, które alarmuje w ciągu sekund, personalizację, która reaguje natychmiast, wspierając zachowania użytkowników.
Choć złożoność konfiguracji jest wyższa, CDC jest standardem dla analityki czasu rzeczywistego na dużą skalę. Narzut jest uzasadniony, gdy decyzje biznesowe zależą od świeżości danych. Wiele zespołów korzysta z zarządzanej Kafki, aby zmniejszyć obciążenie, lub zaczyna od przetwarzania wsadowego i migruje do CDC, gdy wartość czasu rzeczywistego zostanie potwierdzona.
Bezpośrednie zapisy z aplikacji są wydajne w przypadku obciążeń czysto zdarzeniowych
Twoja aplikacja zapisuje dane bezpośrednio do narzędzi ClickHouse równolegle z krytyczną bazą danych OLTP. Działa to najlepiej w przypadku obciążeń sterowanych zdarzeniami, gdzie każde działanie użytkownika jest zdarzeniem wartym analizy: wyświetlenia stron, kliknięcia, wywołania API, dane z czujników. Aplikacja wysyła zdarzenie do obu systemów równolegle lub używa ClickHouse jako głównego systemu i synchronizuje dane z PostgreSQL dla transakcji.
Eliminuje to całkowicie warstwę ETL. Bez Kafki, bez Debezium, bez zadań wsadowych. Aplikacja zapisuje raz, dane są natychmiast gotowe do zapytania, a opóźnienie jest minimalne.
Dlaczego ClickHouse jest właściwym silnikiem OLAP do analityki czasu rzeczywistego
ClickHouse został zbudowany od podstaw z myślą o analityce czasu rzeczywistego na ogromnych zbiorach danych. W przeciwieństwie do ogólnych hurtowni danych, które optymalizują się pod kątem obciążeń wsadowych lub interaktywnej analityki BI, ClickHouse priorytetyzuje opóźnienia zapytań poniżej sekundy, nawet podczas skanowania miliardów wierszy.
To czyni go właściwym wyborem dla firm z branży SaaS, FinTech, AdTech i e-commerce, które potrzebują analityki dotrzymującej kroku ich systemom produkcyjnym.
Wydajność zapytań poniżej sekundy :
ClickHouse osiąga opóźnienia poniżej sekundy w zapytaniach skanujących miliardy wierszy dzięki kolumnowemu przechowywaniu danych, wektorowej egzekucji i agresywnej kompresji. Potrafi agregować 10 miliardów wierszy w czasie poniżej sekundy, podczas gdy PostgreSQL zajmuje to minuty, a inne hurtownie od kilku do kilkudziesięciu sekund.
ClickHouse kontra Redshift kontra BigQuery :
ClickHouse zapewnia stabilny, oparty na zasobach model cenowy z wysoką współbieżnością i wydajnym skalowaniem, idealny do interaktywnej analityki w czasie rzeczywistym. Redshift najlepiej sprawdza się w hurtowniach danych zorientowanych na przetwarzanie wsadowe, z przewidywalnymi obciążeniami i istniejącą infrastrukturą AWS. BigQuery przoduje w analityce bezserwerowej w przypadku sporadycznych zapytań oraz dla zespołów, które chcą wyeliminować narzut operacyjny.
ClickHouse SQL :
ClickHouse wykorzystuje dialekt SQL, który jest w 90% kompatybilny ze standardowym środowiskiem programistycznym SQL, jednak istnieją kluczowe różnice. Funkcje agregujące wykorzystują tabele MergeTree ze specyficzną składnią silnika. Większość zapytań SELECT tłumaczy się bezpośrednio, ale złożone operacje JOIN i podzapytania mogą wymagać optymalizacji.
Wskazówki dotyczące migracji obejmują: najpierw przetestowanie zapytań na reprezentatywnym zbiorze danych hosta, użycie funkcji EXPLAIN w ClickHouse do optymalizacji planów wykonania sesji oraz wykorzystanie zmaterializowanych widoków do wstępnego obliczania agregacji złożonych stosów narzędzi.
Dlaczego warto wybrać OVHcloud Managed ClickHouse
OVHcloud Managed ClickHouse to jedyna natywna usługa zarządzanego ClickHouse oferowana przez europejskiego dostawcę chmury, obok naszych sprawdzonych Managed Databases for PostgreSQL . Oznacza to brak routingu danych przez podmioty trzecie, brak zależności od ClickHouse Cloud oraz brak przepływów danych między dostawcami.
Zarządzany ClickHouse od dostawcy z UE: OVHcloud jest jedynym dostawcą chmury w regionie europejskim oferującym natywny silnik zarządzanego ClickHouse. W przeciwieństwie do konkurencji, gdzie dane przesyłane są przez usługi podmiotów trzecich, OVHcloud uruchamia ClickHouse bezpośrednio na własnej infrastrukturze.
Automatyzacja do OVHcloud Object Storage: Zimne dane są automatycznie migrowane do zgodnego z S3* magazynu OVHcloud Object Storage, co pozwala utrzymać liniowe koszty w skali petabajtów. Najnowsze dane (30–90 dni) pozostają na dyskach NVMe SSD dla zapewnienia maksymalnej szybkości, podczas gdy starsze dane są przenoszone do OVHcloud Object Storage za ułamek kosztów. Co istotne, nie ma żadnych opłat za transfer danych na zewnątrz (egress fees).
Wdrożenia w 3 strefach dostępności (AZ) w Paryżu i Mediolanie : Klastry produkcyjne działają w trzech strefach dostępności w Paryżu lub Mediolanie z SLA na poziomie 99,99% w 3 strefach dostępności, całodobowym wsparciem technicznym oraz replikacją wielowęzłową zapewniającą wysoką dostępność. Usługa Gen3 (od sierpnia 2025 r.) zapewnia 5-krotnie większą pamięć masową, 4-krotnie większą przepustowość, 2-krotnie wyższą liczbę transakcji na sekundę (TPS) i 1,5-krotnie szybszy start w porównaniu z poprzednią generacją; wszystko to sprzyja skalowaniu.
Zgodność z RODO z założenia, brak narażenia na Cloud Act: OVHcloud to francuska firma podlegająca wyłącznie prawu francuskiemu/unijnemu. Wszystkie dane analityczne pozostają w europejskich centrach danych, bez narażenia na Cloud Act, który dotyczy dostawców z USA. Jest to szczególnie istotne w przypadku danych behawioralnych, transakcji finansowych oraz danych objętych RODO.
Ponadto usługi OVHcloud posiadają certyfikaty ISO/IEC 27001/27017/27018/27701 oraz są zgodne z HDS, a certyfikacja SecNumCloud jest w toku. Obejmuje to nasze Managed Apache Kafka dla potoków CDC oraz nasz OVHcloud Object Storage (zgodny z S3)*.
Dla europejskich firm z sektora SaaS, FinTech, AdTech i e-commerce, przetwarzających dane klientów z UE, ta gwarancja suwerenności eliminuje ryzyko prawne związane z dostępem władz USA do danych przechowywanych u amerykańskich dostawców chmury.
Rozpocznij: wdróż ClickHouse i połącz go ze swoją bazą produkcyjną
Chcesz odciążyć swoją bazę produkcyjną od ciężkich zapytań analitycznych? Wdrożenie OVHcloud Managed ClickHouse zajmuje zaledwie kilka minut za pośrednictwem panelu sterowania lub API.
Zapewniamy, że Twoje dane pozostają w europejskich centrach danych, co gwarantuje prywatność i pełną obserwowalność, bez opłat za transfer wychodzący, a warstwowe przechowywanie danych w OVHcloud Object Storage zgodnym z S3 sprawia, że koszty pozostają przewidywalne w miarę skalowania od terabajtów do petabajtów.
Uruchom swój klaster oprogramowania ClickHouse już dziś i przekonaj się, dlaczego ponad 2000 firm, w tym Tesla, Bloomberg i Anthropic, polega na ClickHouse w zakresie analityki w czasie rzeczywistym.
* S3 jest znakiem towarowym zastrzeżonym przez Amazon Technologies, Inc. Usługi OVHcloud nie są sponsorowane, wspierane ani w żaden sposób powiązane z Amazon Technologies, Inc.