Bu, analitik sistemlər haqqında məqalələr silsiləsinin ikinci hissəsidir ().
Bu gün heç bir şübhə yoxdur ki, məlumatların diqqətlə işlənməsi və nəticələrin təfsiri demək olar ki, istənilən biznes növünə kömək edə bilər. Bu baxımdan, analitik sistemlər getdikcə daha çox parametrlərlə yüklənir və tətbiqlərdə triggerlərin və istifadəçi hadisələrinin sayı artır.
Bu səbəbdən şirkətlər öz analitiklərinə təhlil etmək və sağlam qərarlara çevrilmək üçün getdikcə daha çox xam məlumat verirlər. Şirkət üçün analitik sistemin əhəmiyyəti küçümsenməməli, sistemin özü etibarlı və sabit olmalıdır.
Müştəri analitikləri
Müştəri analitikası şirkətin rəsmi SDK vasitəsilə vebsaytına və ya tətbiqinə qoşulduğu, öz kod bazasına inteqrasiya etdiyi və hadisə tetikleyicilerini seçdiyi xidmətdir. Bu yanaşmanın açıq bir mənfi tərəfi var: seçdiyiniz hər hansı xidmətin məhdudiyyətlərinə görə toplanmış bütün məlumatlar tam olaraq istədiyiniz kimi işlənməyə bilər. Məsələn, bir sistemdə MapReduce tapşırıqlarını yerinə yetirmək asan olmayacaq, digər sistemdə modelinizi işlədə bilməyəcəksiniz. Digər bir çatışmazlıq xidmətlər üçün müntəzəm (təsirli) qanun layihəsi olacaqdır.
Bazarda bir çox müştəri analitik həlləri var, lakin gec-tez analitiklər hər bir tapşırıq üçün uyğun olan universal xidmətin olmaması ilə üzləşirlər (bütün bu xidmətlərin qiymətləri hər zaman yüksəlir). Belə bir vəziyyətdə şirkətlər tez-tez bütün lazımi fərdi parametrlər və imkanlarla öz analitik sistemlərini yaratmağa qərar verirlər.
Server analitikləri
Server tərəfi analitika bir şirkət daxilində öz serverlərində və (adətən) öz səyləri ilə yerləşdirilə bilən bir xidmətdir. Bu modeldə bütün istifadəçi hadisələri daxili serverlərdə saxlanılır, tərtibatçılara müxtəlif saxlama verilənlər bazalarını sınamağa və ən əlverişli arxitekturanı seçməyə imkan verir. Bəzi tapşırıqlar üçün hələ də üçüncü tərəf müştəri analitikasından istifadə etmək istəsəniz belə, bu, hələ də mümkün olacaq.
Server tərəfində analitika iki şəkildə yerləşdirilə bilər. Birincisi: bəzi açıq mənbə kommunal proqramları seçin, onları maşınlarınıza yerləşdirin və biznes məntiqini inkişaf etdirin.
Pros
Eksiler
İstədiyiniz hər şeyi fərdiləşdirə bilərsiniz
Bu, çox vaxt çox çətindir və ayrıca tərtibatçılar tələb edir
İkincisi: SaaS xidmətlərini (Amazon, Google, Azure) özünüz yerləşdirmək əvəzinə götürün. SaaS haqqında üçüncü hissədə daha ətraflı danışacağıq.
Pros
Eksiler
Orta həcmdə daha ucuz ola bilər, lakin böyük artımla yenə də çox bahalaşacaq
Bütün parametrlərə nəzarət etmək mümkün olmayacaq
İdarəetmə tamamilə xidmət təminatçısının çiyinlərinə verilir
Xidmətin içərisində nə olduğu həmişə məlum deyil (lazım olmaya bilər)
Server analitikasını necə toplamaq olar
Əgər müştəri analitikasından istifadə etməkdən uzaqlaşmaq və özümüzü qurmaq istəyiriksə, ilk növbədə yeni sistemin arxitekturası üzərində düşünməliyik. Aşağıda sizə nəyi nəzərə almalı olduğunuzu, hər bir addımın nə üçün lazım olduğunu və hansı vasitələrdən istifadə edə biləcəyinizi addım-addım izah edəcəyəm.
1. Məlumatların qəbulu
Müştəri analitikasında olduğu kimi, ilk növbədə şirkət analitikləri gələcəkdə öyrənmək istədikləri hadisələrin növlərini seçib siyahıya toplayırlar. Tipik olaraq, bu hadisələr "hadisə nümunəsi" adlanan müəyyən bir ardıcıllıqla baş verir.
Sonra, təsəvvür edin ki, mobil proqramın (veb-saytın) daimi istifadəçiləri (cihazları) və çoxlu serverləri var. Hadisələri cihazlardan serverlərə təhlükəsiz ötürmək üçün ara qat lazımdır. Memarlıqdan asılı olaraq, bir neçə fərqli hadisə növbəsi ola bilər.
- Mi hadisələrin toplanması üçün növbə kimi istifadə olunur.
Uyğun olaraq 2014-cü ildə Apache Kafka-nın yaradıcısı proqram təminatına Frans Kafkanın adını qoymağa qərar verdi, çünki “bu, yazı üçün optimallaşdırılmış bir sistemdir” və Kafkanın əsərlərini sevdiyi üçün. —
Bizim nümunəmizdə çoxlu məlumat istehsalçıları və məlumat istehlakçıları (cihazlar və serverlər) var və Kafka onları bir-birinə bağlamağa kömək edir. İstehlakçılar əsas mövzular olacaq növbəti addımlarda daha ətraflı təsvir olunacaq. İndi biz yalnız məlumat istehsalçılarını (hadisələri) nəzərdən keçirəcəyik.
Kafka növbə və bölmə anlayışlarını əhatə edir; bu barədə başqa yerdə daha ətraflı oxumaq daha yaxşıdır (məsələn, ). Təfərrüatlara varmadan, iki fərqli ƏS üçün mobil proqramın işə salındığını təsəvvür edək. Sonra hər bir versiya öz ayrıca hadisə axını yaradır. Prodüserlər hadisələri Kafkaya göndərir, uyğun növbəyə yazılır.
(şəkil )
Eyni zamanda, Kafka sizə hissə-hissə oxumağa və hadisələrin axınını mini-toplarda emal etməyə imkan verir. Kafka artan ehtiyaclarla (məsələn, hadisələrin geolokasiyası ilə) yaxşı miqyas alan çox rahat bir vasitədir.
Adətən bir parça kifayətdir, lakin miqyaslandırarkən işlər daha da mürəkkəbləşir (həmişə olduğu kimi). Yəqin ki, heç kim istehsalda yalnız bir fiziki parçadan istifadə etmək istəməz, çünki arxitektura xətaya dözümlü olmalıdır. Kafka ilə yanaşı, daha bir məşhur həll var - RabbitMQ. Biz ondan hadisə analitikası üçün növbə kimi istehsalda istifadə etməmişik (belə təcrübəniz varsa, şərhlərdə bu barədə bizə məlumat verin!). Bununla belə, biz AWS Kinesis-dən istifadə etdik.
Növbəti mərhələyə keçməzdən əvvəl sistemin daha bir əlavə qatını - xam log saxlama yerini qeyd etməliyik. Bu tələb olunan təbəqə deyil, lakin nəsə səhv olarsa və Kafkadakı hadisə növbələri sıfırlanırsa faydalı olacaq. Xam logların saxlanması mürəkkəb və bahalı bir həll tələb etmir, sadəcə onları düzgün qaydada (hətta sabit diskdə) bir yerə yaza bilərsiniz.
2. Hadisə axınlarının işlənməsi
Bütün hadisələri hazırladıqdan və onları müvafiq növbələrə yerləşdirdikdən sonra emal mərhələsinə keçirik. Burada sizə ən çox yayılmış iki emal variantı haqqında məlumat verəcəyəm.
Birinci seçim Apache sistemində Spark Streaming-i aktivləşdirməkdir. Bütün Apache məhsulları fayl replikaları ilə təhlükəsiz fayl sistemi olan HDFS-də yaşayır. Spark Streaming, axın məlumatlarını idarə edən və miqyasını yaxşı idarə edən istifadəsi asan bir vasitədir. Bununla belə, onu saxlamaq çətin ola bilər.
Başqa bir seçim öz hadisə işləyicinizi qurmaqdır. Bunun üçün sizə, məsələn, Python proqramı yazmaq, onu Docker-də qurmaq və Kafka növbəsinə abunə olmaq lazımdır. Tətiklər docker işləyicilərinə çatdıqda, emal başlayacaq. Bu üsulla siz proqramları daim işlək vəziyyətdə saxlamalısınız.
Tutaq ki, yuxarıda təsvir edilən variantlardan birini seçmişik və emalın özünə keçək. Prosessorlar məlumatların etibarlılığını yoxlamaq, zibilləri süzgəcdən keçirmək və “sınmış” hadisələrlə başlamalıdırlar. Doğrulama üçün adətən istifadə edirik . Bundan sonra, məlumatların xəritələşdirilməsini edə bilərsiniz: müxtəlif mənbələrdən alınan məlumatlar ümumi cədvələ əlavə etmək üçün normallaşdırılır və standartlaşdırılır.
3. Verilənlər bazası
Üçüncü addım normallaşdırılmış hadisələri saxlamaqdır. Hazır analitik sistemlə işləyərkən biz onlara tez-tez daxil olmalı olacağıq, ona görə də rahat verilənlər bazası seçmək vacibdir.
Məlumat sabit sxemə yaxşı uyğun gəlirsə, seçə bilərsiniz və ya başqa sütunlu verilənlər bazası. Bu şəkildə birləşmələr çox tez işləyəcək. İşin mənfi tərəfi odur ki, sxem sərt şəkildə sabitlənmişdir və buna görə də dəyişiklik etmədən ixtiyari obyektləri əlavə etmək mümkün olmayacaq (məsələn, qeyri-standart hadisə baş verdikdə). Ancaq həqiqətən çox tez saya bilərsiniz.
Strukturlaşdırılmamış məlumatlar üçün NoSQL-i götürə bilərsiniz, məsələn, . HDFS-də işləyir, yaxşı təkrarlanır, bir çox nümunələri qaldıra bilərsiniz və səhvlərə dözümlüdür.
Siz həmçinin daha sadə bir şey qaldıra bilərsiniz, məsələn, . Olduqca yavaş və kiçik həcmlər üçün. Ancaq artı odur ki, çox sadədir və buna görə də başlanğıc üçün uyğundur.
4. Aqreqasiyalar
Bütün hadisələri diqqətlə saxladıqdan sonra, gələn partiyadan bütün vacib məlumatları toplamaq və verilənlər bazasını yeniləmək istəyirik. Qlobal miqyasda biz müvafiq tablolar və ölçülər əldə etmək istəyirik. Məsələn, hadisələrdən bir istifadəçi profili toplayın və davranışı bir şəkildə ölçün. Hadisələr toplanır, toplanır və yenidən saxlanılır (istifadəçi cədvəllərində). Eyni zamanda, siz bir sistem qura bilərsiniz ki, siz həm də aqreqator-koordinatora filtr qoşa biləsiniz: istifadəçiləri yalnız müəyyən bir hadisə növündən toplayın.
Bundan sonra, komandada kiməsə yalnız yüksək səviyyəli analitika lazımdırsa, xarici analitika sistemləri qoşula bilər. Siz yenidən Mixpanel qəbul edə bilərsiniz. lakin kifayət qədər bahalı olduğundan, bütün istifadəçi hadisələri ora göndərilmir, ancaq lazım olanlar. Bunu etmək üçün bəzi xam hadisələri və ya əvvəllər özümüz birləşdirdiyimiz bir şeyi xarici sistemlərə, API-lərə və ya reklam platformalarına köçürəcək bir koordinator yaratmalıyıq.
5. Frontend
Yaradılmış sistemə frontend qoşmaq lazımdır. Yaxşı bir nümunə xidmətdir , tablosunu yaratmağa kömək edən verilənlər bazası GUI-dir. Qarşılıqlı əlaqə necə işləyir:
- İstifadəçi SQL sorğusu edir.
- Cavab olaraq bir işarə alır.
- Bunun üçün "yeni vizuallaşdırma" yaradır və özünüz üçün saxlaya biləcəyiniz gözəl bir qrafik əldə edir.
Xidmətdəki vizuallaşdırmalar avtomatik yenilənir, siz monitorinqinizi fərdiləşdirə və izləyə bilərsiniz. Redash öz-özünə ev sahibliyi edirsə pulsuzdur, lakin SaaS olaraq ayda 50 dollara başa gələcək.
Nəticə
Yuxarıdakı bütün addımları tamamladıqdan sonra siz server analitikanızı yaradacaqsınız. Nəzərə alın ki, bu, müştəri analitikasını birləşdirmək qədər sadə deyil, çünki hər şeyi özünüz konfiqurasiya etməlisiniz. Buna görə də, öz sisteminizi yaratmazdan əvvəl, ciddi analitik sistemə olan ehtiyacı ona ayırmağa hazır olduğunuz resurslarla müqayisə etməyə dəyər.
Əgər riyaziyyatla məşğul olmusunuzsa və xərclərin çox yüksək olduğunu görmüsünüzsə, növbəti hissədə server tərəfi analitikanın daha ucuz versiyasını necə etmək barədə danışacağam.
Oxuduğunuz üçün təşəkkür edirik! Şərhlərdə suallar verməkdən məmnun olaram.
Mənbə: www.habr.com