Real proqramlarda ClickHouse istifadə nəzəriyyəsi və təcrübəsi. Aleksandr Zaitsev (2018)

İndi demək olar ki, hər yerdə çoxlu məlumatların olmasına baxmayaraq, analitik verilənlər bazaları hələ də kifayət qədər ekzotikdir. Onlar zəif tanınır və onlardan daha səmərəli istifadə edə bilirlər. Çoxları digər ssenarilər üçün nəzərdə tutulmuş MySQL və ya PostgreSQL ilə “kaktus yeməyə” davam edir, NoSQL-dən əziyyət çəkir və ya kommersiya həlləri üçün artıq ödəniş edir. ClickHouse oyunun qaydalarını dəyişir və analitik DBMS dünyasına daxil olmaq üçün həddi xeyli aşağı salır.

BackEnd Conf 2018-dən hesabat və spikerin icazəsi ilə dərc olunur.

Mən kiməm və niyə ClickHouse haqqında danışıram? Mən ClickHouse istifadə edən LifeStreet-də inkişaf direktoruyam. Həmçinin, mən Altinity-nin yaradıcısıyam. Bu, ClickHouse-u təşviq edən və Yandex-in ClickHouse-u daha uğurlu etməyə kömək edən Yandex tərəfdaşıdır. Həmçinin ClickHouse haqqında bilikləri paylaşmağa hazırdır.

Mən Petya Zaitsevin qardaşı deyiləm. Məndən tez-tez bu barədə soruşurlar. Xeyr, biz qardaş deyilik.

ClickHouse-u "hamı bilir":

• Çox sürətli,
• Çox rahat
• Yandex-də istifadə olunur.

Hansı şirkətlərdə və necə istifadə edildiyi bir az daha az məlumdur.

Yandex-dən başqa ClickHouse-un niyə, harada və necə istifadə edildiyini sizə xəbər verəcəyəm.

Mən sizə müxtəlif şirkətlərdə ClickHouse-un köməyi ilə konkret tapşırıqların necə həll edildiyini, tapşırıqlarınız üçün hansı ClickHouse alətlərindən istifadə edə biləcəyinizi və onların müxtəlif şirkətlərdə necə istifadə edildiyini söyləyəcəyəm.

ClickHouse-u müxtəlif açılardan göstərən üç nümunə götürdüm. Məncə maraqlı olacaq.

Birinci sual: “Niyə bizə ClickHouse lazımdır?”. Bu, kifayət qədər açıq bir sual kimi görünür, lakin ona birdən çox cavab var.

• İlk cavab performans üçündür. ClickHouse çox sürətlidir. ClickHouse-da analitika da çox sürətlidir. Tez-tez başqa bir şeyin çox yavaş və ya çox pis olduğu yerlərdə istifadə edilə bilər.
• İkinci cavab xərcdir. Və ilk növbədə, miqyaslaşdırmanın dəyəri. Məsələn, Vertica tamamilə əla verilənlər bazasıdır. Çox terabayt məlumatınız yoxdursa, bu, çox yaxşı işləyir. Lakin söhbət yüzlərlə terabayt və ya petabaytdan gedirsə, lisenziya və dəstəyin dəyəri kifayət qədər əhəmiyyətli məbləğə keçir. Və bahadır. Və ClickHouse pulsuzdur.
• Üçüncü cavab əməliyyat xərcləridir. Bu bir az fərqli yanaşmadır. RedShift əla analoqdur. RedShift-də çox tez qərar verə bilərsiniz. Bu, yaxşı işləyəcək, lakin eyni zamanda, hər saat, hər gün və hər ay Amazon-a olduqca baha ödəyəcəksiniz, çünki bu, əhəmiyyətli dərəcədə bahalı xidmətdir. Google BigQuery də. Əgər kimsə bundan istifadə edibsə, onda bilir ki, orada bir neçə sorğu göndərə və birdən-birə yüzlərlə dollarlıq hesab ala bilərsiniz.

ClickHouse-da bu problemlər yoxdur.

ClickHouse hazırda harada istifadə olunur? Yandex-dən əlavə, ClickHouse bir çox müxtəlif müəssisə və şirkətlərdə istifadə olunur.

• Əvvəla, bu, veb tətbiqi analitikasıdır, yəni bu Yandex-dən gələn bir istifadə nümunəsidir.
• Bir çox AdTech şirkəti ClickHouse istifadə edir.
• Müxtəlif mənbələrdən əməliyyat qeydlərini təhlil etməli olan çoxsaylı şirkətlər.
• Bir neçə şirkət təhlükəsizlik qeydlərini izləmək üçün ClickHouse-dan istifadə edir. Onları ClickHouse-a yükləyir, hesabatlar hazırlayır və lazım olan nəticələri əldə edirlər.
• Şirkətlər ondan maliyyə təhlilində istifadə etməyə başlayırlar, yəni tədricən böyük bizneslər də ClickHouse-a yaxınlaşırlar.
• bulud alovu. Əgər kimsə ClickHouse-u izləyirsə, yəqin ki, bu şirkətin adını eşitmişlər. Bu, cəmiyyətin əsas töhfələrindən biridir. Və onların çox ciddi bir ClickHouse quraşdırması var. Məsələn, ClickHouse üçün Kafka Mühərriki yaratdılar.
• Telekommunikasiya şirkətləri istifadə etməyə başladı. Bir neçə şirkət ClickHouse-dan ya konsepsiyanın sübutu kimi, ya da artıq istehsalda istifadə edir.
• Bir şirkət istehsal proseslərinə nəzarət etmək üçün ClickHouse-dan istifadə edir. Mikrosxemləri sınaqdan keçirirlər, bir dəstə parametri yazırlar, təxminən 2 xüsusiyyət var. Və sonra oyunun yaxşı və ya pis olduğunu təhlil edirlər.
• Blockchain analitikası. Rusiyada Bloxy.info kimi bir şirkət var. Bu, ethereum şəbəkəsinin təhlilidir. Bunu ClickHouse-da da etdilər.

Və ölçüsünün əhəmiyyəti yoxdur. Bir kiçik serverdən istifadə edən bir çox şirkət var. Və onların problemlərini həll etməyə imkan verir. Və daha çox şirkət çoxlu serverlərdən və ya onlarla serverdən ibarət böyük klasterlərdən istifadə edir.

Və qeydlərə baxsanız, onda:

• Yandex: 500+ server, orada gündə 25 milyard qeyd saxlayırlar.
• LifeStreet: 60 server, gündə təxminən 75 milyard qeyd. Yandex-dən daha az server, daha çox qeyd var.
• CloudFlare: 36 server, onlar gündə 200 milyard qeyd saxlayır. Onların daha az serverləri var və daha çox məlumat saxlayırlar.
• Bloomberg: 102 server, gündə təxminən bir trilyon giriş. Rekord sahibi.

Coğrafi baxımdan bu da çoxdur. Buradakı bu xəritə ClickHouse-un dünyada istifadə olunduğu yerin istilik xəritəsini göstərir. Burada Rusiya, Çin, Amerika açıq şəkildə seçilir. Avropa ölkələri azdır. Və 4 klaster var.

Bu, müqayisəli təhlildir, mütləq rəqəmlər axtarmağa ehtiyac yoxdur. Bu, Altinity saytında ingilisdilli materialları oxuyan ziyarətçilərin təhlilidir, çünki orada rusdillilər yoxdur. Rusiya, Ukrayna, Belarusiya, yəni cəmiyyətin rusdilli hissəsi ən çox istifadəçidir. Sonra ABŞ və Kanada gəlir. Çin çox yetişir. Altı ay əvvəl orada Çin demək olar ki, yox idi, indi Çin artıq Avropanı ötüb və böyüməkdə davam edir. Köhnə Avropa da geri qalmır və ClickHouse-un istifadəsində lider, qəribə də olsa, Fransadır.

Bütün bunları niyə deyirəm? ClickHouse-un böyük məlumatların təhlili üçün standart həllə çevrildiyini və artıq bir çox yerlərdə istifadə olunduğunu göstərmək üçün. Əgər ondan istifadə edirsinizsə, doğru trenddəsiniz. Əgər hələ də istifadə etmirsinizsə, o zaman tək qalacağınızdan və heç kimin sizə kömək etməyəcəyindən qorxa bilməzsiniz, çünki çoxları artıq bunu edir.

Bunlar bir neçə şirkətdə real ClickHouse istifadəsinin nümunələridir.

• Birinci misal reklam şəbəkəsidir: Vertica-dan ClickHouse-a miqrasiya. Mən Vertica-dan keçmiş və ya keçid prosesində olan bir neçə şirkət tanıyıram.
• İkinci misal ClickHouse-da əməliyyat yaddaşıdır. Bu, antipattern üzərində qurulmuş bir nümunədir. Tərtibatçıların məsləhəti ilə ClickHouse-da edilməməli olan hər şey burada edilir. Və o qədər effektiv şəkildə həyata keçirilir ki, işləyir. Və tipik əməliyyat həllindən daha yaxşı işləyir.
• Üçüncü nümunə ClickHouse-da paylanmış hesablamadır. ClickHouse-un Hadoop ekosisteminə necə inteqrasiya oluna biləcəyi ilə bağlı sual yarandı. Mən bir şirkətin çox qeyri-ciddi bir tapşırığı hesablamaq üçün ClickHouse-da xəritə azaltma konteynerinə bənzər bir şeyi necə etdiyini, məlumatların lokalizasiyasını izlədiyini və s.

• LifeStreet bir reklam şəbəkəsi ilə gələn bütün texnologiyaya sahib bir Reklam Texnologiyası şirkətidir.
• O, reklamların optimallaşdırılması, proqram təklifləri ilə məşğul olur.
• Çoxlu məlumat: gündə təxminən 10 milyard hadisə. Eyni zamanda oradakı hadisələri bir neçə alt-hadisələrə bölmək olar.
• Bu məlumatların çoxlu müştəriləri var və bunlar təkcə insanlar deyil, daha çox - bunlar proqramlı tenderlə məşğul olan müxtəlif alqoritmlərdir.

Şirkət uzun və çətin bir yol keçmişdir. Mən bu barədə HighLoad-da danışdım. Əvvəlcə LifeStreet MySQL-dən (Oracle-da qısa dayanmaqla) Vertica-ya keçdi. Və bu barədə bir hekayə tapa bilərsiniz.

Və hər şey çox yaxşı idi, amma tez məlum oldu ki, məlumat artır və Vertica bahadır. Buna görə də müxtəlif alternativlər axtarılırdı. Onlardan bəziləri burada verilmişdir. Və əslində, biz 13-cü ildən 16-cı ilə qədər bazarda mövcud olan və funksionallıq baxımından təxminən uyğun olan demək olar ki, bütün verilənlər bazalarının konsepsiya sübutunu və ya bəzən performans testini etdik. Mən də HighLoad-da onlardan bəziləri haqqında danışdım.

Tapşırıq ilk növbədə Vertica-dan köçmək idi, çünki məlumatlar böyüdü. Və illər keçdikcə eksponent olaraq böyüdülər. Sonra rəfə getdilər, amma buna baxmayaraq. Və bu artımı, bir növ analitikanın aparılması lazım olan məlumatların həcminə dair biznes tələblərini proqnozlaşdırsaq, petabaytların tezliklə müzakirə ediləcəyi aydın idi. Petabaytlar üçün ödəniş isə onsuz da çox bahadır, ona görə də hara getmək üçün alternativ axtarırdıq.

Hara getməli? Və uzun müddət hara getmək lazım olduğu heç də aydın deyildi, çünki bir tərəfdən kommersiya bazaları var, onlar yaxşı işləyirlər. Bəziləri demək olar ki, Vertica kimi işləyir, bəziləri isə daha pisdir. Amma onların hamısı bahadır, daha ucuz və daha yaxşısını tapmaq mümkün deyil.

Digər tərəfdən, çox sayda olmayan açıq mənbəli həllər var, yəni. analitika üçün onları barmaqlarla saymaq olar. Və onlar pulsuz və ya ucuzdur, lakin yavaşdır. Və onlar tez-tez lazımi və faydalı funksionallıqdan məhrumdurlar.

Ticarət verilənlər bazalarında olan yaxşıları və açıq mənbədə olan bütün pulsuzları birləşdirəcək heç bir şey yox idi.

Yandex gözlənilmədən ClickHouse-u papaqdan sehrbaz, dovşan kimi çıxarana qədər heç nə yox idi. Və bu, gözlənilməz bir qərar idi, onlar hələ də sual verirlər: “Niyə?”, Ancaq buna baxmayaraq.

Və dərhal 2016-cı ilin yayında biz ClickHouse-un nə olduğuna baxmağa başladıq. Və məlum oldu ki, bəzən Vertica-dan daha sürətli ola bilər. Fərqli sorğular üzrə müxtəlif ssenariləri sınaqdan keçirdik. Və əgər sorğu yalnız bir cədvəldən istifadə edirdisə, yəni heç bir qoşulma (qoşulma) olmadan, onda ClickHouse Vertica-dan iki dəfə sürətli idi.

Mən çox tənbəl deyildim və ötən gün Yandex testlərinə baxdım. Orada da eynidir: ClickHouse Vertica-dan iki dəfə sürətlidir, ona görə də tez-tez bu barədə danışırlar.

Ancaq sorğularda birləşmələr varsa, hər şey çox birmənalı deyil. ClickHouse isə Vertica-dan iki dəfə yavaş ola bilər. Əgər sorğunu bir az düzəldib yenidən yazsanız, onlar təxminən bərabərdir. Pis deyil. Və pulsuz.

Və test nəticələrini aldıqdan sonra və fərqli bucaqlardan baxaraq, LifeStreet ClickHouse-a getdi.

16-cı ildir, xatırladıram. Bu, siçanların zarafata oxşayırdı ki, ağlayır və özlərini sancır, lakin kaktusları yeməyə davam edirdi. Və bu ətraflı təsvir edildi, bu barədə bir video var və s.

Ona görə də bu barədə ətraflı danışmayacağam, yalnız nəticələrdən və o zaman danışmadığım bir neçə maraqlı şeydən danışacağam.

Nəticələr bunlardır:

• Uğurlu köç və bir ildən çox sistem artıq istehsalda işləyir.
• Məhsuldarlıq və çeviklik artdı. Gündə və sonra qısa müddətə saxlaya biləcəyimiz 10 milyard qeyddən LifeStreet indi gündə 75 milyard qeyd saxlayır və bunu 3 ay və ya daha çox müddətə edə bilər. Əgər zirvədə hesablasanız, bu, saniyədə bir milyon hadisəyə qədərdir. Gündə bir milyondan çox SQL sorğusu bu sistemə əsasən müxtəlif robotlardan daxil olur.
• Vertica ilə müqayisədə ClickHouse üçün daha çox serverdən istifadə olunmasına baxmayaraq, onlar həm də aparata qənaət etmişlər, çünki Vertica-da kifayət qədər bahalı SAS diskləri istifadə olunurdu. ClickHouse SATA istifadə edir. Bəs niyə? Çünki Vertica-da insert sinxrondur. Sinxronizasiya isə disklərin çox yavaşlamamasını, həmçinin şəbəkənin çox yavaşlamamasını, yəni kifayət qədər bahalı əməliyyat tələb edir. Və ClickHouse-da daxiletmə asinxrondur. Üstəlik, hər zaman hər şeyi yerli olaraq yaza bilərsiniz, bunun üçün heç bir əlavə xərc yoxdur, belə ki, məlumatlar Vertika-dan daha sürətli, hətta daha yavaş disklərdə də ClickHouse-a daxil edilə bilər. Və oxumaq təxminən eynidir. SATA-da oxumaq, əgər onlar RAID-dədirlərsə, bu, kifayət qədər sürətlidir.
• Lisenziya ilə məhdudlaşmır, yəni 3 serverdə 60 petabayt məlumat (20 server bir replikadır) və faktlar və birləşmələrdə 6 trilyon qeyd. Vertica-da belə bir şey əldə edilə bilməz.

İndi bu nümunədə praktiki şeylərə müraciət edirəm.

• Birincisi səmərəli sxemdir. Çox şey sxemdən asılıdır.
• İkincisi səmərəli SQL nəslidir.

Tipik bir OLAP sorğusu seçimdir. Sütunların bəziləri qruplaşdırmağa, bəzi sütunlar isə ümumi funksiyalara keçir. Bir kub dilimi kimi təmsil oluna bilən bir yer var. Bütün qrup bir proyeksiya kimi düşünülə bilər. Və buna görə də çoxvariantlı məlumatların təhlili adlanır.

Və tez-tez bu, bir ulduz sxemi şəklində modelləşdirilir, bu faktın mərkəzi faktı və xüsusiyyətləri tərəflər boyunca, şüalar boyunca olduqda.

Və fiziki dizayn baxımından, masaya necə uyğun gəlir, onlar adətən normallaşdırılmış bir təqdimat edirlər. Siz qeyri-normallaşdıra bilərsiniz, lakin bu, diskdə bahadır və sorğularda çox səmərəli deyil. Buna görə də, onlar adətən normallaşdırılmış təqdimat, yəni fakt cədvəli və çoxlu ölçü cədvəlləri yaradırlar.

Amma ClickHouse-da yaxşı işləmir. İki səbəb var:

• Birincisi, ClickHouse-un çox yaxşı birləşmələri olmadığı üçün, yəni birləşmələr var, lakin onlar pisdir. Pis olsa da.
• İkincisi, cədvəllərin yenilənməməsidir. Adətən ulduz dövrəsinin ətrafında olan bu lövhələrdə nəyisə dəyişmək lazımdır. Məsələn, müştəri adı, şirkət adı və s. Və işləmir.

Bundan çıxış yolu ClickHouse-da var. hətta iki:

• Birincisi, lüğətlərdən istifadədir. Xarici Lüğətlər 99% ulduz sxemi, yeniləmələr və s. ilə problemi həll etməyə kömək edən şeydir.
• İkincisi, massivlərin istifadəsidir. Massivlər də birləşmələrdən və normallaşma problemlərindən qurtulmağa kömək edir.

• Qoşulma tələb olunmur.
• Təkmilləşdirilə bilər. 2018-ci ilin mart ayından etibarən lüğətləri, yəni dəyişdirilmiş qeydləri qismən yeniləmək üçün sənədsiz bir fürsət yarandı (bunu sənədlərdə tapa bilməzsiniz). Praktik olaraq masaya bənzəyir.
• Həmişə yaddaşdadır, buna görə lüğətə qoşulmaq diskdə olan bir cədvəldən daha sürətli işləyir və onun keşdə olması hələ bir fakt deyil, çox güman ki, yox.

• Sizin də birləşmələrə ehtiyacınız yoxdur.
• Bu, 1-dən çoxa qədər yığcam təqdimatdır.
• Və mənim fikrimcə, seriallar geeks üçün hazırlanır. Bunlar lambda funksiyaları və s.

Bu qırmızı sözlər üçün deyil. Bu, çox sadə və zərif bir şəkildə bir çox şeyi etməyə imkan verən çox güclü bir funksionallıqdır.

Massivləri həll etməyə kömək edən tipik nümunələr. Bu nümunələr kifayət qədər sadə və aydındır:

• Teqlər üzrə axtarın. Əgər orada hashtaglarınız varsa və hashtag ilə bəzi yazılar tapmaq istəyirsinizsə.
• Açar-dəyər cütləri üzrə axtarın. Dəyəri olan bəzi atributlar da var.
• Başqa bir şeyə tərcümə etməli olduğunuz açarların siyahılarının saxlanması.

Bütün bu vəzifələr massivlər olmadan həll edilə bilər. Teqlər müəyyən bir sətirdə yerləşdirilə və müntəzəm ifadə ilə və ya ayrıca cədvəldə seçilə bilər, lakin sonra birləşmələr etməlisiniz.

ClickHouse-da isə heç nə etmək lazım deyil, hashtaglar üçün sətir massivini təsvir etmək və ya açar-dəyər sistemləri üçün iç-içə struktur yaratmaq kifayətdir.

İç-içə quruluş ən yaxşı ad olmaya bilər. Bunlar adında ümumi bir hissəyə və bəzi əlaqəli xüsusiyyətlərə malik olan iki massivdir.

Və etiketlə axtarış etmək çox asandır. Bir funksiyası var has, massivdə elementin olub olmadığını yoxlayır. Hər kəs konfransımıza aid olan bütün yazıları tapdı.

Subid üzrə axtarış bir az daha mürəkkəbdir. Əvvəlcə açarın indeksini tapmalıyıq, sonra bu indekslə elementi götürüb bu dəyərin bizə lazım olduğunu yoxlamaq lazımdır. Bununla belə, çox sadə və yığcamdır.

Hamısını bir sətirdə saxlasanız, yazmaq istədiyiniz müntəzəm ifadə, ilk növbədə, yöndəmsiz olardı. İkincisi, o, iki massivdən daha uzun müddət işləyirdi.

Başqa bir misal. ID-ni saxladığınız massiviniz var. Və onları adlara çevirə bilərsiniz. Funksiya arrayMap. Bu tipik lambda funksiyasıdır. Orada lambda ifadələrini keçirsiniz. Və o, lüğətdən hər bir şəxsiyyət üçün adın dəyərini çıxarır.

Axtarış eyni şəkildə edilə bilər. Elementlərin uyğunluğunu yoxlayan predikat funksiyası ötürülür.

Bu şeylər dövrəni çox sadələşdirir və bir çox problemi həll edir.

Ancaq qarşılaşdığımız və qeyd etmək istədiyim növbəti problem səmərəli sorğulardır.

• ClickHouse-un sorğu planlayıcısı yoxdur. Qətiyyən.
• Buna baxmayaraq, mürəkkəb sorğular hələ də planlaşdırılmalıdır. Hansı hallarda?
• Sorğuda bir neçə birləşmə varsa, onları alt seçimlərə sarırsınız. Və onların icra olunma qaydası önəmlidir.
• Və ikincisi - sorğu paylandıqda. Çünki paylanmış sorğuda yalnız ən daxili alt seçim paylanmış icra olunur və qalan hər şey qoşulduğunuz və orada icra etdiyiniz bir serverə ötürülür. Buna görə, bir çox birləşmə (qoşulma) ilə paylanmış sorğular etsəniz, sifarişi seçməlisiniz.

Və hətta daha sadə hallarda, bəzən planlaşdırıcının işini yerinə yetirmək və sorğuları bir az yenidən yazmaq lazımdır.

Budur bir nümunə. Sol tərəfdə ilk 5 ölkəni göstərən sorğu var. Və mənim fikrimcə 2,5 saniyə çəkir. Və sağ tərəfdə eyni sorğu, lakin bir qədər yenidən yazılmışdır. Sətirə görə qruplaşdırmaq əvəzinə, düymə (int) ilə qruplaşdırmağa başladıq. Və daha sürətli. Və sonra nəticəyə lüğət bağladıq. 2,5 saniyə əvəzinə sorğu 1,5 saniyə çəkir. Bu yaxşıdır.

Filtrlərin yenidən yazılması ilə oxşar bir nümunə. Burada Rusiyaya müraciət var. 5 saniyəyə işləyir. Əgər onu elə bir şəkildə yenidən yazsaq ki, yenidən bir sətir deyil, Rusiyaya aid olan bəzi düymələr dəsti ilə rəqəmləri müqayisə etsək, bu, daha sürətli olacaq.

Belə hiylələr çoxdur. Və onlar artıq sürətli işlədiyini və ya əksinə, yavaş işlədiyini düşündüyünüz sorğuları əhəmiyyətli dərəcədə sürətləndirməyə imkan verir. Onları daha sürətli etmək olar.

• Paylanmış rejimdə maksimum iş.
• Minimum növlərə görə çeşidləmə, ints ilə etdiyim kimi.
• Hər hansı bir qoşulma (qoşulma), lüğətlər varsa, onları son çarə kimi etmək daha yaxşıdır, ən azı qismən qruplaşdırılmış məlumatlarınız olduqda, qoşulma əməliyyatı və ya lüğət çağırışı daha az dəfə çağırılacaq və daha sürətli olacaq. .
• Filtrlərin dəyişdirilməsi.

Yalnız nümayiş etdirdiklərim deyil, başqa üsullar da var. Və onların hamısı bəzən sorğuların icrasını əhəmiyyətli dərəcədə sürətləndirə bilər.

Növbəti nümunəyə keçək. ABŞ-dan X şirkəti. O nə edir?

Bir tapşırıq var idi:

• Reklam əməliyyatlarının oflayn əlaqələndirilməsi.
• Müxtəlif bağlama modellərinin modelləşdirilməsi.

Ssenari nədir?

Adi bir ziyarətçi ayda 20 dəfə müxtəlif elanlardan gəlir və ya bu saytı xatırladığı üçün bəzən reklamsız gəlir. Bəzi məhsullara baxır, onları səbətə qoyur, səbətdən çıxarır. Və sonda bir şey satın alır.

Ağlabatan suallar: "Lazım olduqda, reklam üçün kim pul ödəməlidir?" və “Əgər varsa, ona hansı reklam təsir etdi?”. Yəni niyə alıb və bu adam kimiləri də necə alsın?

Bu problemi həll etmək üçün internet saytında baş verən hadisələri düzgün şəkildə əlaqələndirmək, yəni onların arasında hansısa yolla əlaqə qurmaq lazımdır. Sonra onlar analiz üçün DWH-yə göndərilir. Və bu təhlil əsasında kimin və hansı reklamların göstəriləcəyi ilə bağlı modellər qurun.

Reklam əməliyyatı, reklamın göstərilməsi ilə başlayan əlaqəli istifadəçi hadisələri toplusudur, sonra nəsə baş verir, sonra alış-veriş ola bilər və sonra satınalma çərçivəsində alışlar ola bilər. Məsələn, bu mobil proqram və ya mobil oyundursa, adətən proqramın quraşdırılması pulsuz həyata keçirilir və orada bir şey edilirsə, bunun üçün pul tələb oluna bilər. Və bir insan tətbiqdə nə qədər çox xərcləyirsə, bir o qədər dəyərlidir. Ancaq bunun üçün hər şeyi birləşdirmək lazımdır.

Çox bağlayıcı modellər var.

Ən populyarları bunlardır:

• Qarşılıqlı əlaqənin klik və ya təəssürat olduğu sonuncu qarşılıqlı əlaqə.
• İlk Qarşılıqlı Əlaqə, yəni insanı sayta gətirən ilk şey.
• Xətti birləşmə - hamısı bərabərdir.
• Zəifləmə.
• Və s.

Və hamısı ilk növbədə necə işlədi? Runtime və Cassandra var idi. Cassandra əməliyyat anbarı kimi istifadə olunurdu, yəni bütün əlaqəli əməliyyatlar orada saxlanılırdı. Və Runtime-da hansısa hadisə gələndə, məsələn, hansısa səhifəni və ya başqa bir şeyi göstərəndə, o zaman Kassandraya müraciət edildi - belə bir insan var, ya yox. Daha sonra ona aid olan əməliyyatlar əldə edilib. Və əlaqə quruldu.

Sorğunun əməliyyat identifikatoru olması şanslıdırsa, bu, asandır. Ancaq ümumiyyətlə şans yoxdur. Buna görə də son əməliyyatı və ya son kliklə əməliyyatı tapmaq lazım idi və s.

Bağlama son kliklə qədər olduğu müddətdə hamısı çox yaxşı işlədi. Çünki bir aya pəncərə qoysaq, deyək ki, gündə 10 milyon, ayda 300 milyon klik var. Cassandra-da sürətli işləmək üçün hamısı yaddaşda olmalıdır, çünki Runtime tez cavab verməlidir, buna təxminən 10-15 server lazım idi.

Və bir əməliyyatı ekrana bağlamaq istədikdə, dərhal o qədər də əyləncəli olmadığı ortaya çıxdı. Bəs niyə? 30 dəfə daha çox hadisələrin saxlanması lazım olduğunu görmək olar. Və müvafiq olaraq, 30 dəfə daha çox serverə ehtiyacınız var. Və belə çıxır ki, bu bir növ astronomik rəqəmdir. Runtime-da əhəmiyyətli dərəcədə az server olmasına baxmayaraq, əlaqə yaratmaq üçün 500-ə qədər server saxlamaq, onda bu bir növ səhv rəqəmdir. Və nə edəcəklərini düşünməyə başladılar.

Və biz ClickHouse-a getdik. Bunu ClickHouse-da necə etmək olar? İlk baxışdan belə görünür ki, bu, anti-naxışlar toplusudur.

• Tranzaksiya böyüyür, biz ona getdikcə daha çox hadisə bağlayırıq, yəni dəyişkəndir və ClickHouse dəyişən obyektlərlə çox yaxşı işləmir.
• Ziyarətçi bizə gələndə biz onun əməliyyatlarını açarla, ziyarət id nömrəsi ilə çıxarmalıyıq. Bu da bir nöqtə sorğusudur, onlar bunu ClickHouse-da etmirlər. Adətən ClickHouse-un böyük ... skanları olur, lakin burada bəzi qeydlər əldə etməliyik. Həm də antipattern.
• Bundan əlavə, əməliyyat json-da idi, lakin onlar onu yenidən yazmaq istəmədilər, ona görə də json-u strukturlaşdırılmamış şəkildə saxlamaq və lazım gələrsə, ondan bir şey çıxarmaq istədilər. Və bu da bir antipatterndir.

Yəni, bir sıra antipatternlər.

Ancaq buna baxmayaraq, çox yaxşı işləyən bir sistem meydana çıxdı.

Nə edildi? Logların atıldığı, qeydlərə bölündüyü ClickHouse göründü. ClickHouse-dan qeydləri qəbul edən atributlu xidmət ortaya çıxdı. Bundan sonra, hər giriş üçün, ziyarət id-si ilə mən hələ emal olunmamış əməliyyatları və üstəgəl snapshotları, yəni artıq bağlanmış əməliyyatları, yəni əvvəlki işin nəticəsini aldım. Mən artıq onlardan məntiq qurdum, düzgün əməliyyat seçdim, yeni hadisələri bağladım. Yenidən daxil oldu. Jurnal ClickHouse-a qayıtdı, yəni daimi dövri sistemdir. Üstəlik, orada təhlil etmək üçün DWH-yə getdim.

Məhz bu formada çox yaxşı işləmədi. ClickHouse-u asanlaşdırmaq üçün ziyarət id-si ilə sorğu olduqda, onlar bu sorğuları 1-000 ziyarət id-si bloklarında qruplaşdırdılar və 2-000 nəfər üçün bütün əməliyyatları çıxardılar. Və sonra hər şey işlədi.

ClickHouse-un içərisinə baxsanız, bütün bunlara xidmət edən yalnız 3 əsas cədvəl var.

Qeydlərin yükləndiyi ilk cədvəl və qeydlər demək olar ki, işlənmədən yüklənir.

İkinci masa. Maddiləşdirilmiş görünüş vasitəsilə, bu jurnallardan hələ aid edilməmiş, yəni əlaqəsi olmayan hadisələr dişlənmişdir. Və materiallaşdırılmış görünüş vasitəsilə, bir anlıq görüntü yaratmaq üçün əməliyyatlar bu qeydlərdən çıxarıldı. Yəni, xüsusi materiallaşdırılmış görünüş snapshot qurdu, yəni əməliyyatın son yığılmış vəziyyəti.

Budur SQL-də yazılmış mətn. Oradakı bir neçə vacib məqamı şərh etmək istərdim.

Birinci vacib şey ClickHouse-da json-dan sütun və sahələri çıxarmaq bacarığıdır. Yəni ClickHouse-un json ilə işləmək üçün bəzi üsulları var. Onlar çox, çox primitivdirlər.

visitParamExtractInt json-dan atributları çıxarmağa imkan verir, yəni ilk hit işləyir. Və bu yolla siz əməliyyat id-ni çıxara və ya id-i ziyarət edə bilərsiniz. Bu vaxt.

İkincisi, burada çətin bir maddiləşdirilmiş sahə istifadə olunur. Bunun mənası nədi? Bu o deməkdir ki, siz onu cədvələ daxil edə bilməzsiniz, yəni daxil edilmir, daxil edildikdə hesablanır və saxlanılır. Yapışdırarkən, ClickHouse sizin üçün işləyir. Daha sonra sizə lazım olan şey artıq json-dan çıxarılıb.

Bu halda, materiallaşdırılmış görünüş xam sıralar üçündür. Və praktiki olaraq xam logları olan ilk cədvəl yalnız istifadə olunur. Və o nə edir? Birincisi, çeşidləməni dəyişir, yəni çeşidləmə indi ziyarət id-si ilə gedir, çünki biz onun əməliyyatını müəyyən bir şəxs üçün tez bir zamanda çıxarmalıyıq.

İkinci vacib şey index_granularity. MergeTree-ni görmüsünüzsə, o, adətən standart olaraq index_granularity 8-dir. Bu nədir? Bu, indeksin seyrəklik parametridir. ClickHouse-da indeks seyrəkdir, heç vaxt hər girişi indeksləşdirmir. Bunu hər 192-dən bir edir. Və bu, çoxlu məlumatların hesablanması tələb olunduqda yaxşıdır, lakin az olduqda pisdir, çünki böyük yük var. İndeksin qranulyarlığını azaltsaq, əlavə xərcləri azaldırıq. Onu birinə endirmək olmaz, çünki kifayət qədər yaddaş olmaya bilər. İndeks həmişə yaddaşda saxlanılır.

Snapshot bəzi digər maraqlı ClickHouse xüsusiyyətlərindən də istifadə edir.

Birincisi, bu AggregatingMergeTree-dir. AggregatingMergeTree isə argMax-ı saxlayır, yəni bu, son vaxt damğasına uyğun gələn əməliyyatın vəziyyətidir. Əməliyyatlar hər zaman müəyyən bir ziyarətçi üçün yaradılır. Və bu əməliyyatın ən son vəziyyətində bir hadisə əlavə etdik və yeni bir vəziyyətimiz var. ClickHouse-u yenidən vurdu. Və bu maddiləşdirilmiş görünüşdə argMax vasitəsilə biz həmişə cari vəziyyəti əldə edə bilərik.

• Bağlama Runtime-dan "decoupled" olunur.
• Ayda 3 milyarda qədər əməliyyat saxlanılır və emal edilir. Bu, Kassandrada, yəni tipik bir əməliyyat sistemində olduğundan daha böyük bir sıradır.
• 2x5 ClickHouse serverlərinin çoxluğu. 5 server və hər serverin replikası var. Klikə əsaslanan atribusiya etmək üçün bu, Cassandra-da olduğundan daha azdır və burada bizdə təəssürat əsaslıdır. Yəni serverlərin sayını 30 dəfə artırmaq əvəzinə, azaltmağa nail olublar.

Son misal isə səhm qiymətlərindəki dəyişikliklərin korrelyasiyasını təhlil edən Y maliyyə şirkətidir.

Və tapşırıq belə idi:

• Təxminən 5 səhm var.
• Hər 100 millisaniyədə sitatlar məlumdur.
• Məlumatlar 10 il ərzində yığılıb. Görünür, bəzi şirkətlər üçün daha çox, bəziləri üçün azdır.
• Ümumilikdə təxminən 100 milyard sıra var.

Və dəyişikliklərin korrelyasiyasını hesablamaq lazım idi.

Budur iki səhm və onların kotirovkaları. Biri yüksəlirsə, digəri qalxırsa, bu müsbət korrelyasiyadır, yəni biri yüksəlir, digəri yüksəlir. Qrafikin sonunda olduğu kimi biri yuxarı qalxırsa, digəri aşağı enirsə, bu mənfi korrelyasiyadır, yəni biri yüksəldikdə digəri düşür.

Bu qarşılıqlı dəyişiklikləri təhlil edərək maliyyə bazarında proqnozlar vermək olar.

Amma iş çətindir. Bunun üçün hansı işlər görülür? Bizim 100 milyard qeydimiz var: vaxt, səhm və qiymət. Qiymət alqoritmindən çalışan fərqi ilk 100 milyard dəfə hesablamalıyıq. RunningDifference ClickHouse-da iki sətir arasındakı fərqi ardıcıl olaraq hesablayan funksiyadır.

Və bundan sonra korrelyasiyanı hesablamaq lazımdır və korrelyasiya hər bir cüt üçün hesablanmalıdır. 5 səhm üçün cütlər 000 milyondur. Və bu çox şeydir, yəni 12,5 dəfə məhz belə bir korrelyasiya funksiyasını hesablamaq lazımdır.

Əgər kimsə unudubsa, onda ͞x və ͞y matdır. seçmə gözləntisi. Yəni təkcə kökləri və cəmləri hesablamaq yox, bu məbləğlərin içərisində daha bir məbləğ də hesablamaq lazımdır. Bir dəstə hesablamanı 12,5 milyon dəfə etmək və hətta saatlara görə qruplaşdırmaq lazımdır. Bizim də saatlarımız çoxdur. Və bunu 60 saniyə ərzində etməlisən. Bu zarafatdır.

Heç olmasa nədənsə vaxt lazım idi, çünki ClickHouse gələnə qədər bütün bunlar çox, çox yavaş işləyirdi.

Bunu Hadoop-da, Spark-da, Greenplum-da hesablamağa çalışdılar. Və bütün bunlar çox yavaş və ya bahalı idi. Yəni, birtəhər hesablamaq mümkün idi, amma sonra baha idi.

Və sonra ClickHouse gəldi və işlər daha yaxşı oldu.

Xatırladıram ki, məlumatların yerləşməsi ilə bağlı problemimiz var, çünki korrelyasiyaları lokallaşdırmaq mümkün deyil. Verilənlərin bir hissəsini bir serverə, bəzilərini digərinə qoyub hesablaya bilmərik, bizdə bütün məlumatlar hər yerdə olmalıdır.

Onlar nə etdilər? Əvvəlcə məlumatlar lokallaşdırılır. Hər bir server müəyyən səhmlər dəstinin qiymətinə dair məlumatları saxlayır. Və üst-üstə düşmürlər. Buna görə də logReturn-u paralel və müstəqil hesablamaq mümkündür, bütün bunlar indiyə qədər paralel və paylanmış şəkildə baş verir.

Sonra ifadəliliyi itirmədən bu məlumatları azaltmağa qərar verdik. Massivlərdən istifadəni azaldın, yəni hər dövr üçün bir sıra səhmlər və bir sıra qiymətlər yaradın. Buna görə də, daha az məlumat sahəsi tutur. Və onlarla işləmək bir az daha asandır. Bunlar demək olar ki, paralel əməliyyatlardır, yəni biz qismən paralel oxuyuruq və sonra serverə yazırıq.

Bundan sonra onu təkrarlamaq olar. "R" hərfi bu məlumatları təkrarladığımız deməkdir. Yəni hər üç serverdə eyni məlumatlara sahibik - bunlar massivlərdir.

Və sonra hesablanması lazım olan bu 12,5 milyon korrelyasiya dəstindən xüsusi bir skriptlə paketlər edə bilərsiniz. Yəni, 2 cüt korrelyasiya ilə 500 tapşırıq. Və bu tapşırıq xüsusi bir ClickHouse serverində hesablanmalıdır. O, bütün məlumatlara malikdir, çünki məlumatlar eynidir və onları ardıcıl olaraq hesablaya bilir.

Yenə də belə görünür. Birincisi, bu strukturda bütün məlumatlar var: vaxt, səhmlər, qiymət. Sonra logReturn hesabladıq, yəni eyni strukturun məlumatları, lakin qiymət əvəzinə bizdə artıq logReturn var. Sonra onlar yenidən işləndi, yəni səhmlər və qiymətlər üçün vaxt və groupArray əldə etdik. Replikasiya edilmişdir. Və bundan sonra biz bir dəstə tapşırıq yaratdıq və onları saymaq üçün ClickHouse-a verdik. Və işləyir.

Konsepsiyanın sübutuna görə, tapşırıq bir alt tapşırıq idi, yəni daha az məlumat alındı. Və yalnız üç server.

İlk iki mərhələ: Log_return-un hesablanması və massivlərə sarılması təxminən bir saat çəkdi.

Korrelyasiyanın hesablanması isə təxminən 50 saatdır. Amma 50 saat kifayət deyil, çünki əvvəllər həftələrlə işləyirdilər. Bu, böyük uğur idi. Əgər hesablasanız, saniyədə 70 dəfə bu klasterdə hər şey sayılırdı.

Ancaq ən vacibi odur ki, bu sistem praktiki olaraq darboğazsızdır, yəni demək olar ki, xətti şəkildə miqyaslanır. Və yoxladılar. Onu uğurla genişləndirdi.

• Düzgün sxem döyüşün yarısıdır. Və düzgün sxem bütün lazımi ClickHouse texnologiyalarının istifadəsidir.
• Summing/AggregatingMergeTrees xüsusi hal kimi vəziyyətin görüntüsünü cəmləşdirməyə və ya nəzərdən keçirməyə imkan verən texnologiyalardır. Və bir çox şeyi çox asanlaşdırır.
• Materiallaşdırılmış Baxışlar bir indeks limitini keçməyə imkan verir. Ola bilsin ki, çox aydın deməmişəm, amma biz logları yükləyəndə xam loglar bir indekslə cədvəldə, atribut qeydləri isə cədvəldə, yəni eyni verilənlər yalnız süzülüb, lakin indeks tamamilə başqaları. Eyni məlumat kimi görünür, lakin müxtəlif çeşidləmə. Və Materiallaşdırılmış Görünüşlər sizə ehtiyac duyarsanız, belə bir ClickHouse məhdudiyyətindən yan keçməyə imkan verir.
• Nöqtə sorğuları üçün indeks qranulyarlığını azaldın.
• Və məlumatları ağıllı şəkildə paylayın, məlumatları server daxilində mümkün qədər lokallaşdırmağa çalışın. Və sorğuların mümkün olduğu qədər lokalizasiyadan da istifadə etməsini təmin etməyə çalışın.

Və bu qısa nitqi yekunlaşdıraraq deyə bilərik ki, ClickHouse indi həm kommersiya bazalarının, həm də açıq mənbə verilənlər bazalarının ərazisini, yəni xüsusi olaraq analitika üçün möhkəm şəkildə işğal edib. O, bu mənzərəyə mükəmməl uyğunlaşır. Üstəlik, o, yavaş-yavaş başqalarını sıxışdırmağa başlayır, çünki ClickHouse-a sahib olduğunuz zaman sizə InfiniDB lazım deyil. Normal SQL dəstəyi edərsə, Vertika tezliklə lazım olmaya bilər. Zövq alın!

-Hesabat üçün təşəkkür edirik! Çox maraqlı! Apache Phoenix ilə müqayisələr olubmu?

Xeyr, heç kimin müqayisə etdiyini eşitməmişəm. Biz və Yandex müxtəlif verilənlər bazaları ilə bütün ClickHouse müqayisələrini izləməyə çalışırıq. Çünki birdən nəyinsə ClickHouse-dan daha sürətli olduğu ortaya çıxarsa, Leşa Milovidov gecələr yata bilmir və sürətlə sürətləndirməyə başlayır. Mən belə bir müqayisə eşitməmişəm.

• (Aleksey Milovidov) Apache Phoenix, Hbase tərəfindən təchiz edilmiş SQL mühərrikidir. Hbase əsasən açar-dəyər iş ssenarisi üçündür. Orada, hər bir sətirdə ixtiyari adlarla ixtiyari sayda sütun ola bilər. Bunu Hbase, Cassandra kimi sistemlər haqqında demək olar. Və onlar üçün normal işləməyəcək dəqiq ağır analitik sorğulardır. Və ya ClickHouse ilə heç bir təcrübəniz yoxdursa, onların yaxşı işlədiyini düşünə bilərsiniz.

• Təşəkkür

  • Günortanız Xeyir Mən artıq bu mövzu ilə kifayət qədər maraqlanıram, çünki mənim analitik alt sistemim var. Ancaq ClickHouse-a baxanda, ClickHouse-un hadisələrin təhlili üçün çox uyğun olduğunu, dəyişkən olduğunu hiss edirəm. Bir dəstə böyük cədvəllə bir çox iş məlumatını təhlil etməliyəmsə, başa düşdüyüm qədər ClickHouse mənim üçün çox uyğun deyil? Xüsusilə də dəyişsələr. Bu düzgündür, yoxsa bunu təkzib edə biləcək nümunələr varmı?

  • Bu doğrudur. Bu, əksər ixtisaslaşmış analitik verilənlər bazalarına aiddir. Onlar dəyişən bir və ya daha çox böyük cədvəlin və yavaş-yavaş dəyişən bir çox kiçik cədvəlin olması üçün hazırlanmışdır. Yəni, ClickHouse Oracle kimi deyil, burada hər şeyi yerləşdirə və çox mürəkkəb sorğular qura bilərsiniz. ClickHouse-dan səmərəli istifadə etmək üçün siz ClickHouse-da yaxşı işləyən bir sxem qurmalısınız. Yəni, həddindən artıq normallaşmadan qaçın, lüğətlərdən istifadə edin, daha az uzun keçidlər yaratmağa çalışın. Əgər sxem bu şəkildə qurulubsa, o zaman oxşar biznes tapşırıqları ənənəvi əlaqəli verilənlər bazasından daha effektiv şəkildə ClickHouse-da həll edilə bilər.

Hesabat üçün təşəkkür edirik! Son maliyyə işi ilə bağlı sualım var. Onların analitikası var idi. Onların necə yuxarı və aşağı getdiyini müqayisə etmək lazım idi. Mən başa düşürəm ki, siz sistemi xüsusi olaraq bu analitika üçün qurmusunuz? Əgər sabah, məsələn, onlara bu məlumatla bağlı başqa hesabat lazımdırsa, sxemi yenidən qurmaq və məlumatları yükləmək lazımdırmı? Yəni sorğunu almaq üçün bir növ ön emal etmək?

Əlbəttə ki, bu, çox xüsusi bir tapşırıq üçün ClickHouse-un istifadəsidir. Daha ənənəvi olaraq Hadoop daxilində həll edilə bilər. Hadoop üçün bu ideal bir işdir. Ancaq Hadoop-da çox yavaşdır. Və mənim məqsədim nümayiş etdirməkdir ki, ClickHouse adətən tamamilə fərqli vasitələrlə həll olunan, lakin eyni zamanda bunu daha effektiv şəkildə yerinə yetirən vəzifələri həll edə bilir. Müəyyən bir tapşırıq üçün hazırlanmışdır. Aydındır ki, oxşar bir şeylə bağlı problem varsa, o zaman oxşar şəkildə həll edilə bilər.

Aydındır. Dediniz ki, 50 saat işlənib. Əvvəldəndir, məlumatları nə vaxt yükləmisiniz və ya nəticələri aldınız?

Bəli, bəli.

Oldu, çox sağ olun.

Bu 3 server klasterindədir.

salamlar! Hesabat üçün təşəkkür edirik! Hər şey çox maraqlıdır. Bir az funksionallıq haqqında deyil, stabillik baxımından ClickHouse-un istifadəsi haqqında soruşacağam. Yəni sizdə var idi, bərpa etməli idiniz? ClickHouse bu halda necə davranır? Bəs sizin də bir replikanız var idi? Məsələn, ClickHouse hələ də limitdən çıxanda və aşağı düşəndə ​​problemlə qarşılaşdıq.

Təbii ki, ideal sistemlər yoxdur. ClickHouse-un da öz problemləri var. Bəs siz Yandex.Metrica-nın uzun müddət işləməməsi haqqında eşitmisiniz? Yəqin ki, yox. ClickHouse-da 2012-2013-cü ildən etibarlı şəkildə işləyir. Mən öz təcrübəm haqqında eyni şeyi deyə bilərəm. Heç vaxt tam uğursuzluqlarımız olmayıb. Bəzi qismən şeylər baş verə bilər, lakin onlar heç vaxt biznesə ciddi təsir edəcək qədər kritik olmayıblar. Heç baş vermədi. ClickHouse olduqca etibarlıdır və təsadüfi qəzaya uğramır. Bu barədə narahat olmaq lazım deyil. Bu xam bir şey deyil. Bu, bir çox şirkətlər tərəfindən sübut edilmişdir.

Salam! Siz dərhal məlumat sxemi üzərində düşünməyiniz lazım olduğunu söylədiniz. Bəs baş vermiş olsaydı? Məlumatlarım tökülür və tökülür. Altı ay keçir və başa düşürəm ki, belə yaşamaq mümkün deyil, məlumatları yenidən yükləməliyəm və onlarla nəsə etməliyəm.

Bu, əlbəttə ki, sisteminizdən asılıdır. Faktiki olaraq dayanmadan bunu etməyin bir neçə yolu var. Məsələn, siz materiallaşdırılmış Görünüş yarada bilərsiniz ki, bunda unikal şəkildə xəritələndirilə bilsə, fərqli məlumat strukturu yarada bilərsiniz. Yəni, ClickHouse istifadə edərək xəritələşdirməyə imkan verirsə, yəni bəzi şeyləri çıxarın, əsas açarı dəyişdirin, bölməni dəyişdirin, onda siz Materialized View edə bilərsiniz. Orada köhnə məlumatların üzərinə yazın, yeniləri avtomatik olaraq yazılacaq. Və sonra sadəcə Materialized View istifadəsinə keçin, sonra qeydi dəyişdirin və köhnə cədvəli öldürün. Bu, ümumiyyətlə, dayanmayan bir üsuldur.

Təşəkkür edirik.

Mənbə: www.habr.com