ClickHouse — a platform stackjének valós idejű analitikai motorja
A 4buildsite stackjének része a ClickHouse — egy kifejezetten nagy adatmennyiség elemzésére készült, oszlopalapú adatbázis. Erre épül a platform forgalmi és értékesítési statisztikai modulja (fejlesztés alatt): az adatok a tieid maradnak, a kimutatásokat a ClickHouse készíti, a webhelyed kiszolgálása pedig külön marad ettől — így terveztük az architektúrát.
Mi az a ClickHouse, és miért használjuk
A ClickHouse oszlopalapú OLAP- (online elemzési) adatbázis, amelyet a Yandexnél fejlesztettek a Yandex.Metrica számára — ez a világ egyik legnagyobb webanalitikai rendszere —, majd 2016-ban Apache 2.0 licenc alatt nyílt forráskódúvá tettek. Egyetlen feladatra készült, azt viszont kiemelkedően végzi: gyors összesítésekre óriási adatmennyiségen. A 4buildsite architektúrájában a ClickHouse a statisztikai réteg motorja: minden látogatásból, kattintásból és rendelésből esemény lesz, amely elemezhetővé válik.
A titok az oszloponkénti tárolás: ahelyett, hogy minden „sort” teljes egészében beolvasna, a ClickHouse csak azokat az oszlopokat olvassa be, amelyekre a kimutatásnak szüksége van, és nagy blokkokban, vektorizáltan dolgozza fel őket. Ezért kap egy olyan kérdés, mint „hány látogatóm volt tegnap oldalanként és forrásonként”, több millió esemény mellett is másodperc alatti választ — olyasmit, amivel egy klasszikus, soralapú adatbázis jóval nehezebben birkózik meg.
Nem valamiféle réstechnológiáról van szó: a Cloudflare a globális léptékű HTTP-forgalom elemzésére használja, az Uber, az eBay és a Spotify pedig analitikára és naplófeldolgozásra, hatalmas mennyiségben. A 4buildsite-on ugyanez a motor a platform stackjének része — anélkül, hogy adatmérnöki csapatot kellene felvenned.
Valós idejű statisztika a webhely kiszolgálásától elkülönítve — így épül fel a modul
A platform statisztikai modulja fejlesztés alatt áll, az architektúrája pedig egyszerű: a forgalmi események gyűjtése aszinkron módon történik, és a ClickHouse-ba kerülnek, teljesen elkülönítve azoktól a kiszolgálóktól, amelyek az oldalakat szolgálják ki. A kimutatások futása nem része a látogatók oldalbetöltésének. Nincs nehéz, külső fél által működtetett követőszkript — a gyűjtés minimális, és saját tulajdonú.
A panel.4buildsite.net kimutatásai közvetlenül a ClickHouse-ban készülnek majd: oldalankénti forgalom, látogatói források, konverziók, termékenkénti értékesítés. A gyakori összesítéseket Materialized View-k számolják ki előre minden íráskor, így az irányítópultnak nem kell minden megnyitáskor újraszámolnia a nehéz összesítéseket.
- Élő forgalom: látogatások, oldalak, források és eszközök — a gyűjtés után lekérdezhetők
- Termékenkénti értékesítés, rendelések és konverziók a boltodban, összesítve
- Hónapokra és évekre visszamenő előzmények olcsón — az oszloponkénti tömörítés a nyers adatok többszörösével csökkenti a tárhelyigényt
- A gyűjtés aszinkron, a kiértékelés külön rendszeren fut, elkülönítve a webhely kiszolgálásától
PostgreSQL és ClickHouse: miért használjuk mindkettőt
A platform stackje két adatbázist kombinál, mert alapvetően más a dolguk. A PostgreSQL a tranzakciós nyilvántartás (OLTP): rendelések, fizetések, készlet, felhasználói fiókok — olyan műveletek, amelyeknek egyesével tökéletesen pontosnak kell lenniük, tranzakciós garanciákkal. A ClickHouse az elemzőterem (OLAP): egyszerre több millió eseményt olvas be, hogy megválaszolja a forgalomra és az értékesítésre vonatkozó kérdéseidet.
Ha a nehéz kimutatások ugyanazon az adatbázison futnának, amelyik a rendeléseket dolgozza fel, minden egyes kimutatás az éppen fizető vásárlókkal versengene. Az OLTP és az OLAP szétválasztása megszünteti ezt a konfliktust: a vásárló rendelése nem vár a kimutatásodra, a kimutatásod pedig nem vár mások rendeléseire. Mindkét motor pontosan azt csinálja, amire épült.
- PostgreSQL: rendelések, Stripe-fizetések, készlet, ügyfelek — tranzakciós pontosság
- ClickHouse: forgalmi események, kimutatások, statisztikák — összesítés nagy mennyiségen
- A terv szerint a lényeges tranzakciós adatok eseményként kerülnek a ClickHouse-ba, így az értékesítési kimutatások soha nem érintik a boltot kiszolgáló adatbázist
Saját, adatvédelembarát analitika — a Google Analytics helyett
A statisztikai modul alapelve: a webhelyed adatai a platform infrastruktúráján maradnak. Nem kerülnek át a Google-höz vagy más hirdetési hálózatokhoz, nem adjuk el őket, és nem fésüljük össze külső felhasználói profilokkal. Ez a szó szoros értelmében saját tulajdonú analitika: a látogatóidról szóló adatok a tieid.
Mivel a megközelítés nem használ külső fél által elhelyezett követőcookie-kat, a GDPR-megfelelés jóval egyszerűbbé válik. A háttér is számít: 2022-ben az osztrák, a francia és az olasz adatvédelmi hatóság a Google Analytics használatát az Egyesült Államokba irányuló adattovábbítás miatt GDPR-ellenesnek nyilvánította. Saját, Európában üzemeltetett analitikával ez a kockázati kategória eleve megszűnik.
Van egy közvetlen gyakorlati előnye is: a ClickHouse-ban kiszámolt kimutatások nem mintavételezettek, hanem teljes számokat mutatnak.
Bolti és piactéri kimutatások — mit fog nyújtani a modul
Egy webáruház esetében a ClickHouse válaszokat ad majd a lényegi kérdésekre: mely termékek fogynak, milyen forrásokból érkeznek a vásárlók, hol hagyják ott a kosarat. Egy több eladót kiszolgáló piactéren ugyanezek az összesítések futnak majd az összes rendelésen: eladónkénti forgalom, jutalékok, kategóriánkénti legjobb termékek — kézi exportok és táblázatkezelés nélkül.
Nagy léptékben is olcsó és kezelhető marad minden. Az oszloponkénti tömörítés a nyers formátum többszörösével csökkenti az adatok méretét, így évekre visszamenő előzményeket őrizhetsz meg alacsony tárolási költséggel. És amikor a forgalom több ezerről több millió eseményre nő, az összesítések ugyanazzal a motorral készülnek — a motort a kezdetektől több milliárd sorra tervezték, nem utólag igazították hozzá.
Előnyök és korlátok
Előnyök
- Több millió eseményt összesít másodperc alatti nagyságrendben, oszlopalapú, vektorizált feldolgozással.
- Az analitika a webhelyet kiszolgáló rendszertől elkülönített rendszeren fut.
- A forgalmi adatok a tieid maradnak, a platform infrastruktúráján — a Google és a hirdetési hálózatok felé továbbítás nélkül.
- Nincsenek külső fél által elhelyezett követőcookie-k — egyszerűbb GDPR-megfelelés.
- Erős oszloponkénti tömörítés — évekre visszamenő előzmények alacsony tárolási költséggel.
- Nyílt forráskódú (Apache 2.0), mennyiségalapú licencdíjak nélkül — a költség nem szalad el, amikor nő a forgalom.
Korlátok
- Nem tranzakciós adatbázis — egy-egy sor módosítása vagy törlése nehéz művelet; ezért maradnak a rendelések és a fizetések a PostgreSQL-ben.
- Nagy kötegekben történő írásra optimalizált; a sok apró, gyakori beszúrás kötegelést igényel — ezt a platform kezeli, de a motornak ez valós korlátja.
- Az összetett JOIN-ok kevésbé rugalmasak, mint a PostgreSQL-ben — az eseménysémát már az elején elemzésre kell megtervezni.
- Egyetlen sor keresése (point lookup) lassabb, mint egy indexelt OLTP-adatbázisban — nem váltja ki a bolt fő adatbázisát.
Rövid értékelés
A ClickHouse a helyes választás nagy mennyiségű adat elemzésére: valós idejű forgalmi és értékesítési statisztika, a saját adataiddal, a webhely kiszolgálásától elkülönítve. A rendelések, a fizetések és a készlet marad a PostgreSQL-en — ezért kombinálja a 4buildsite stackje mindkettőt, mindegyiket abban, amiben a legjobb. A ClickHouse-ra épülő statisztikai modul fejlesztés alatt áll.
Specifikációs táblázat
| Képesség | Korlát / küszöb | Jellemző felhasználás | |
|---|---|---|---|
| Analitikai összesítések | Másodperc alatt több millió eseményen (oszlopalapú és vektorizált) | Lassú egyetlen sor keresésekor — nem OLTP-lekérésekre való | Forgalmi és értékesítési kimutatások (statisztikai modul, fejlesztés alatt) |
| Eseménybefogadás | Nagy mennyiség, kötegekben írva | Az apró, gyakori beszúrások kötegelést vagy aszinkron beszúrást igényelnek | Oldalmegtekintések, kattintások, rendelések gyűjtése |
| Tárolás és tömörítés | Oszloponkénti tömörítés (LZ4/ZSTD), a nyers méret többszörösével kevesebb | A nagyon véletlenszerű adatok rosszabbul tömöríthetők | Hónapokra és évekre visszamenő eseményelőzmények, olcsón |
| Frissítések és törlések | Aszinkron mutations az alkalmi javításokhoz | Egyedi sorok gyakori UPDATE-jeire nem alkalmas | GDPR szerinti törlések (egy felhasználó adatai, kérésre) |
| Materialized View-k | Minden íráskor előre kiszámított összesítések | Az összesítéseket kimutatásonként előre meg kell határozni | Irányítópultok: értékesítés nap, termék és forrás szerint |
| Valós idejűség | Az események a bekövetkezésük után lekérdezhetők | Nem ezredmásodperces nagyságrendű streamingrendszer | Élő forgalmi és konverziós statisztika |
ClickHouse, PostgreSQL és Google Analytics / BigQuery — analitikára
| Szempont | ClickHouse (4buildsite) | PostgreSQL (analitikára) | Google Analytics / BigQuery |
|---|---|---|---|
| Összesítési sebesség nagy mennyiségen | Másodperc alatt több millió soron | Több tízmillió sornál érezhetően visszaesik (soralapú tárolás) | A BigQuery gyors; a GA4 előre összesített alapkimutatásokat ad, szabad lekérdezések nélkül |
| Adatok feletti rendelkezés / GDPR | A te adataid, a platform infrastruktúráján, Európában | A te adataid, a saját kiszolgálóidon | Az adatok a Google-nél vannak; a GA egyesült államokbeli adattovábbításait 2022-ben uniós hatóságok GDPR-ellenesnek nyilvánították |
| Cookie-k és hozzájárulás | Külső fél által elhelyezett követőcookie-k nélkül | A saját megvalósítástól függ | A követéshez hozzájárulási sáv szükséges |
| Valós idejűség | Az adatok a gyűjtés után lekérdezhetők | Lehetséges, de a nehéz kimutatások terhelik a tranzakciós adatbázist | A GA4 alapkimutatásai órákat késhetnek; a BigQuery streamingje külön költség |
| Költség nagy mennyiségnél | Nyílt forráskódú — a költség csupán az infrastruktúra, amelyet az előfizetés tartalmaz | Nagy mennyiségnél nő az indexekkel, a vacuummal és a hardverrel | A BigQuery a lekérdezett mennyiség alapján számláz; a GA vállalati változata drága |
| Hatás a webhely sebességére | Elkülönített: aszinkron gyűjtés, kiértékelés külön rendszeren | A kimutatások ugyanazon az adatbázison versenghetnek a rendelésekkel | Külső szkript (gtag.js) az oldalon — többlet JavaScript és külső kérések |
Gyakori kérdések
Lelassítja a ClickHouse a webhelyemet vagy a boltomat?
Nem. A ClickHouse az oldalakat kiszolgálótól elkülönített rendszeren fut — így terveztük az architektúrát. A forgalmi események aszinkron módon kerülnek elküldésre, a kimutatások pedig soha nem érintik a bolt adatbázisát.
Miért nem egyszerűen a Google Analyticsöt használjátok?
Három okból. Az adatok a tieid maradnak, a platform infrastruktúráján, nem a Google-nél. Nincs szükség külső fél által elhelyezett követőcookie-kra, így a GDPR-megfelelés egyszerűbb — 2022-ben osztrák, francia és olasz hatóságok GDPR-ellenesnek nyilvánították a GA-t. A kimutatások pedig teljes körűek, nem mintavételezettek.
Mi a különbség a ClickHouse és a PostgreSQL között — miért mindkettő?
A PostgreSQL a tranzakciós adatbázis (OLTP): a rendeléseket, a fizetéseket és a készletet egyesével dolgozza fel, pontossági garanciákkal. A ClickHouse az analitikai adatbázis (OLAP): egyszerre több millió eseményt olvas be a kimutatásokhoz. A szétválasztás azt jelenti, hogy a nehéz kimutatások nem a vásárlóid rendeléseit feldolgozó adatbázison futnak.
Biztonságban vannak a forgalmi adataim, és megfelelnek a GDPR-nak?
Igen — már a tervezésből adódóan. A statisztika saját tulajdonú: a platform európai infrastruktúráján marad, nem adjuk el, és nem osztjuk meg hirdetési hálózatokkal. A megközelítés külső fél által elhelyezett követőcookie-k nélkül működik, egy felhasználó adatai pedig kérésre, a GDPR-nak megfelelően törölhetők.
Mennyire „valós idejű” a statisztika?
Egy esemény — egy látogatás, egy kattintás, egy rendelés — a bekövetkezése után megjelenik a kimutatásokban. A hosszú időszakokra (hónapokra, évekre) vonatkozó összesítések szintén a ClickHouse-ra épülnek, mert pontosan az ilyen lekérdezésekre készült.
Be kell állítanom valamit ahhoz, hogy statisztikám legyen a webhelyemről?
Nem lesz rá szükség. A statisztikai modul fejlesztés alatt áll, és a platform részeként készül: amint elérhetővé válik az adminisztrációs felületen, a gyűjtés automatikusan elindul a közzétett webhelyeknél — nincs telepítendő szkript és nincsenek külső fiókok.