სერვერის ანალიტიკური სისტემები

ეს არის სტატიების სერიის მეორე ნაწილი ანალიტიკური სისტემების შესახებ (ბმული 1 ნაწილზე).

დღეს უკვე აღარ არის ეჭვი, რომ მონაცემთა ფრთხილად დამუშავება და შედეგების ინტერპრეტაცია შეუძლია დაეხმაროს თითქმის ნებისმიერი ტიპის ბიზნესს. ამ მხრივ, ანალიტიკური სისტემები სულ უფრო და უფრო იტვირთება პარამეტრებით და იზრდება ტრიგერებისა და მომხმარებლის მოვლენების რაოდენობა აპლიკაციებში.
ამის გამო, კომპანიები თავიანთ ანალიტიკოსებს სულ უფრო მეტ ნედლეულ ინფორმაციას აწვდიან, რათა გაანალიზონ და გადაიზარდონ გონივრული გადაწყვეტილებები. კომპანიისთვის ანალიტიკური სისტემის მნიშვნელობა არ უნდა შეფასდეს და თავად სისტემა უნდა იყოს საიმედო და სტაბილური.

კლიენტების ანალიტიკოსები

მომხმარებელთა ანალიტიკა არის სერვისი, რომელსაც კომპანია უკავშირებს თავის ვებსაიტს ან აპლიკაციას ოფიციალური SDK-ის მეშვეობით, აერთიანებს საკუთარ კოდების ბაზაში და ირჩევს მოვლენის ტრიგერებს. ამ მიდგომას აშკარა მინუსი აქვს: ყველა შეგროვებული მონაცემი შეიძლება არ დამუშავდეს ზუსტად ისე, როგორც თქვენ გსურთ, თქვენს მიერ არჩეული ნებისმიერი სერვისის შეზღუდვის გამო. მაგალითად, ერთ სისტემაზე ადვილი არ იქნება MapReduce ამოცანების შესრულება, მეორეზე თქვენ ვერ შეძლებთ თქვენი მოდელის გაშვებას. კიდევ ერთი მინუსი იქნება მომსახურების რეგულარული (შთამბეჭდავი) გადასახადი.
ბაზარზე ბევრი მომხმარებლის ანალიტიკური გადაწყვეტაა, მაგრამ ადრე თუ გვიან ანალიტიკოსები დგანან იმ ფაქტის წინაშე, რომ არ არსებობს ერთი უნივერსალური სერვისი, რომელიც შესაფერისია ყველა ამოცანისთვის (მაშინ როცა ყველა ამ სერვისის ფასები მუდმივად იზრდება). ასეთ ვითარებაში კომპანიები ხშირად წყვეტენ შექმნან საკუთარი ანალიტიკური სისტემა ყველა საჭირო მორგებული პარამეტრით და შესაძლებლობებით.

სერვერის ანალიტიკოსები

სერვერის ანალიტიკა არის სერვისი, რომელიც შეიძლება განთავსდეს კომპანიის შიგნით საკუთარ სერვერებზე და (ჩვეულებრივ) საკუთარი ძალისხმევით. ამ მოდელში, მომხმარებლის ყველა მოვლენა ინახება შიდა სერვერებზე, რაც დეველოპერებს საშუალებას აძლევს სცადონ სხვადასხვა მონაცემთა ბაზები და აირჩიონ ყველაზე მოსახერხებელი არქიტექტურა. და მაშინაც კი, თუ თქვენ კვლავ გსურთ გამოიყენოთ მესამე მხარის კლიენტების ანალიტიკა ზოგიერთი ამოცანისთვის, ეს მაინც შესაძლებელი იქნება.
სერვერის ანალიტიკა შეიძლება განთავსდეს ორი გზით. პირველი: აირჩიეთ ღია კოდის რამდენიმე პროგრამა, განათავსეთ ისინი თქვენს მანქანებზე და განავითარეთ ბიზნეს ლოგიკა.

დადებითი
Cons

თქვენ შეგიძლიათ დააკონფიგურიროთ ყველაფერი, რაც გსურთ
ეს ხშირად ძალიან რთულია და მოითხოვს ცალკეულ დეველოპერებს

მეორე: მიიღეთ SaaS სერვისები (Amazon, Google, Azure) იმის ნაცვლად, რომ თავად განათავსოთ იგი. SaaS-ზე უფრო დეტალურად მესამე ნაწილში ვისაუბრებთ.

დადებითი
Cons

საშუალო მოცულობებზე შეიძლება იაფი იყოს, მაგრამ დიდი ზრდით მაინც ძალიან ძვირი გახდება
ყველა პარამეტრის კონტროლი შეუძლებელი იქნება

ადმინისტრირება მთლიანად გადადის მომსახურების მიმწოდებლის მხრებზე
ყოველთვის არ არის ცნობილი, რა არის სერვისის შიგნით (შეიძლება არ იყოს საჭირო)

როგორ შევაგროვოთ სერვერის ანალიტიკა

თუ გვსურს თავი დავანებოთ კლიენტის ანალიტიკის გამოყენებას და ავაშენოთ საკუთარი, პირველ რიგში უნდა ვიფიქროთ ახალი სისტემის არქიტექტურაზე. ქვემოთ მე გეტყვით ეტაპობრივად, რა უნდა გაითვალისწინოთ, რატომ არის საჭირო თითოეული ნაბიჯი და რა ინსტრუმენტები შეგიძლიათ გამოიყენოთ.

1. მონაცემების მიღება

ისევე, როგორც მომხმარებელთა ანალიტიკის შემთხვევაში, პირველ რიგში, კომპანიის ანალიტიკოსები ირჩევენ მოვლენების ტიპებს, რომელთა შესწავლა სურთ მომავალში და აგროვებენ მათ სიაში. როგორც წესი, ეს მოვლენები ხდება კონკრეტული თანმიმდევრობით, რომელსაც ეწოდება "მოვლენის ნიმუში".
შემდეგი, წარმოიდგინეთ, რომ მობილურ აპლიკაციას (საიტს) ჰყავს რეგულარული მომხმარებლები (მოწყობილობები) და მრავალი სერვერი. მოვლენების უსაფრთხოდ გადასატანად მოწყობილობებიდან სერვერებზე, საჭიროა შუალედური ფენა. არქიტექტურიდან გამომდინარე, შეიძლება იყოს რამდენიმე განსხვავებული მოვლენის რიგი.
Apache Kafka - რამდენად pub/sub queue, რომელიც გამოიყენება ღონისძიებების შეგროვების რიგში.

მიხედვით პოსტი Quora-ზე 2014 წელს Apache Kafka-ს შემქმნელმა გადაწყვიტა დაერქვა პროგრამული უზრუნველყოფა ფრანც კაფკას სახელით, რადგან „ეს არის წერისთვის ოპტიმიზირებული სისტემა“ და იმიტომ, რომ მას უყვარდა კაფკას ნამუშევრები. - ვიკიპედია

ჩვენს მაგალითში არის მრავალი მონაცემთა მწარმოებელი და მონაცემთა მომხმარებელი (მოწყობილობები და სერვერები) და კაფკა ეხმარება მათ ერთმანეთთან დაკავშირებაში. მომხმარებლები უფრო დეტალურად იქნება აღწერილი შემდეგ ნაბიჯებში, სადაც ისინი იქნებიან მთავარი სუბიექტები. ახლა განვიხილავთ მხოლოდ მონაცემთა მწარმოებლებს (მოვლენებს).
კაფკა აერთიანებს რიგისა და დანაყოფის ცნებებს; უმჯობესია ამის შესახებ უფრო კონკრეტულად წაიკითხოთ სხვაგან (მაგალითად, დოკუმენტაცია). დეტალების შესწავლის გარეშე, წარმოვიდგინოთ, რომ მობილური აპლიკაცია გაშვებულია ორი განსხვავებული OS-ისთვის. შემდეგ თითოეული ვერსია ქმნის თავის ცალკეულ მოვლენათა ნაკადს. პროდიუსერები უგზავნიან მოვლენებს კაფკას, ისინი იწერება შესაფერის რიგში.

(სურათი აქედან გამომდინარე,)

ამავდროულად, კაფკა საშუალებას გაძლევთ წაიკითხოთ ნაწილებად და დაამუშავოთ მოვლენების ნაკადი მინი პარტიებში. კაფკა არის ძალიან მოსახერხებელი ხელსაწყო, რომელიც კარგად ერწყმის მზარდ საჭიროებებს (მაგალითად, მოვლენების გეოლოკაციით).
ჩვეულებრივ, ერთი ნატეხი საკმარისია, მაგრამ სკალირებისას ყველაფერი უფრო რთულდება (როგორც ყოველთვის). ალბათ არავის სურს გამოიყენოს მხოლოდ ერთი ფიზიკური ნატეხი წარმოებაში, რადგან არქიტექტურა უნდა იყოს შეცდომის შემწყნარებლობა. გარდა კაფკასა, არსებობს კიდევ ერთი ცნობილი გამოსავალი - RabbitMQ. ჩვენ არ გამოგვიყენებია ის წარმოებაში, როგორც რიგი მოვლენების ანალიტიკისთვის (თუ თქვენ გაქვთ ასეთი გამოცდილება, გვითხარით ამის შესახებ კომენტარებში!). თუმცა, ჩვენ გამოვიყენეთ AWS Kinesis.

სანამ შემდეგ ეტაპზე გადავალთ, უნდა აღვნიშნოთ სისტემის კიდევ ერთი დამატებითი ფენა - ნედლეული ჟურნალის შენახვა. ეს არ არის აუცილებელი ფენა, მაგრამ სასარგებლო იქნება, თუ რამე არასწორედ მოხდება და კაფკაში მოვლენის რიგები გადატვირთულია. ნედლი მორების შენახვა არ საჭიროებს რთულ და ძვირადღირებულ გადაწყვეტას; შეგიძლიათ უბრალოდ დაწეროთ ისინი სადმე სწორი თანმიმდევრობით (თუნდაც მყარ დისკზე).

2. მოვლენების ნაკადების დამუშავება

მას შემდეგ რაც მოვამზადებთ ყველა ღონისძიებას და მოვათავსებთ შესაბამის რიგებში, გადავდივართ დამუშავების ეტაპზე. აქ მე გეტყვით დამუშავების ორ ყველაზე გავრცელებულ ვარიანტზე.
პირველი ვარიანტი არის Spark Streaming-ის ჩართვა Apache სისტემაში. Apache-ს ყველა პროდუქტი ცხოვრობს HDFS-ზე, უსაფრთხო ფაილურ სისტემაზე ფაილების რეპლიკებით. Spark Streaming არის ადვილად გამოსაყენებელი ინსტრუმენტი, რომელიც კარგად ამუშავებს ნაკადის მონაცემებს და მასშტაბებს. თუმცა, მისი შენარჩუნება შეიძლება რთული იყოს.
კიდევ ერთი ვარიანტია საკუთარი მოვლენის დამმუშავებლის შექმნა. ამისათვის საჭიროა, მაგალითად, დაწეროთ პითონის აპლიკაცია, ააწყოთ იგი Docker-ში და გამოიწეროთ კაფკას რიგში. როდესაც ტრიგერები მივა დოკერის დამმუშავებელებთან, დამუშავება დაიწყება. ამ მეთოდით, თქვენ გჭირდებათ აპლიკაციების მუდმივად გაშვება.
დავუშვათ, რომ ავირჩიეთ ზემოთ აღწერილი ვარიანტებიდან ერთ-ერთი და გადავიდეთ თავად დამუშავებაზე. პროცესორებმა უნდა დაიწყონ მონაცემთა სისწორის შემოწმებით, ნაგვის გაფილტვრით და „გატეხილი“ მოვლენებით. დასადასტურებლად ჩვენ ჩვეულებრივ ვიყენებთ Cerberus. ამის შემდეგ, თქვენ შეგიძლიათ გააკეთოთ მონაცემთა რუქა: სხვადასხვა წყაროდან მიღებული მონაცემები ნორმალიზდება და სტანდარტიზებულია, რათა დაემატოს საერთო ცხრილში.

3. მონაცემთა ბაზა

მესამე ნაბიჯი არის ნორმალიზებული მოვლენების შენარჩუნება. მზა ანალიტიკურ სისტემასთან მუშაობისას ხშირად მოგვიწევს მათზე წვდომა, ამიტომ მნიშვნელოვანია მოსახერხებელი მონაცემთა ბაზის არჩევა.
თუ მონაცემები კარგად ჯდება ფიქსირებულ სქემაში, შეგიძლიათ აირჩიოთ clickhouse ან სხვა სვეტების მონაცემთა ბაზა. ამ გზით აგრეგაციები ძალიან სწრაფად იმუშავებს. მინუსი არის ის, რომ სქემა მკაცრად არის დაფიქსირებული და, შესაბამისად, შეუძლებელი იქნება თვითნებური ობიექტების დამატება ცვლილების გარეშე (მაგალითად, როდესაც ხდება არასტანდარტული მოვლენა). მაგრამ თქვენ შეგიძლიათ დათვალოთ ძალიან სწრაფად.
არასტრუქტურირებული მონაცემებისთვის შეგიძლიათ აიღოთ NoSQL, მაგალითად, Apache cassandra. ის მუშაობს HDFS-ზე, კარგად იმეორებს, შეგიძლიათ მრავალი მაგალითის დაყენება და ხარვეზების შემწყნარებელია.
თქვენ ასევე შეგიძლიათ წამოიწიოთ რაღაც უფრო მარტივი, მაგალითად, MongoDB. საკმაოდ ნელია და მცირე მოცულობისთვის. მაგრამ პლიუსი ის არის, რომ ის ძალიან მარტივია და ამიტომ შესაფერისია დასაწყებად.

4. აგრეგაციები

ყველა მოვლენის გულდასმით შენახვის შემდეგ, ჩვენ გვინდა შევაგროვოთ ყველა მნიშვნელოვანი ინფორმაცია ჩამოსული პარტიიდან და განაახლოთ მონაცემთა ბაზა. გლობალურად, ჩვენ გვინდა მივიღოთ შესაბამისი დაფები და მეტრიკა. მაგალითად, შეაგროვეთ მომხმარებლის პროფილი მოვლენებიდან და როგორმე გაზომეთ ქცევა. მოვლენები გროვდება, გროვდება და კვლავ ინახება (მომხმარებლების ცხრილებში). ამავდროულად, თქვენ შეგიძლიათ ააწყოთ სისტემა ისე, რომ თქვენ ასევე შეაერთოთ ფილტრი აგრეგატორ-კოორდინატორთან: შეაგროვეთ მომხმარებლები მხოლოდ გარკვეული ტიპის ღონისძიებიდან.
ამის შემდეგ, თუ გუნდში ვინმეს სჭირდება მხოლოდ მაღალი დონის ანალიტიკა, შესაძლებელია გარე ანალიტიკური სისტემების დაკავშირება. შეგიძლიათ კვლავ მიიღოთ Mixpanel. მაგრამ რადგან ეს საკმაოდ ძვირია, ყველა მომხმარებლის ღონისძიება არ იგზავნება იქ, მაგრამ მხოლოდ ის, რაც საჭიროა. ამისათვის ჩვენ უნდა შევქმნათ კოორდინატორი, რომელიც გადასცემს ზოგიერთ ნედლეულ მოვლენას ან რაიმეს, რომელიც ჩვენ თვითონ მოვახდინეთ ადრე აგრეგირებული გარე სისტემებზე, API-ებზე ან სარეკლამო პლატფორმებზე.

5. ფრონტენდი

თქვენ უნდა დაუკავშიროთ წინა ნაწილი შექმნილ სისტემას. კარგი მაგალითია მომსახურება გაწითლება, არის მონაცემთა ბაზის GUI, რომელიც ეხმარება დაფების შექმნას. როგორ მუშაობს ურთიერთქმედება:

1. მომხმარებელი აკეთებს SQL შეკითხვას.
2. პასუხად ის იღებს ნიშანს.
3. ის ქმნის მისთვის „ახალ ვიზუალიზაციას“ და იღებს ლამაზ გრაფიკს, რომელიც შეგიძლიათ შეინახოთ თქვენთვის.

სერვისში ვიზუალიზაცია ავტომატურად განახლდება, შეგიძლიათ დააკონფიგურიროთ და თვალყური ადევნოთ თქვენს მონიტორინგს. Redash უფასოა, თუ მასპინძლობს, მაგრამ როგორც SaaS ის თვეში $50 ეღირება.

დასკვნა

ყველა ზემოთ მოყვანილი ნაბიჯის დასრულების შემდეგ, თქვენ შექმნით თქვენი სერვერის ანალიტიკას. გთხოვთ გაითვალისწინოთ, რომ ეს არ არის ისეთი მარტივი, როგორც უბრალოდ მომხმარებელთა ანალიტიკის დაკავშირება, რადგან ყველაფერი თავად უნდა იყოს კონფიგურირებული. ამიტომ, სანამ შექმნით საკუთარ სისტემას, ღირს სერიოზული ანალიტიკური სისტემის საჭიროების შედარება იმ რესურსებთან, რომლებიც მზად ხართ მას გამოყოთ.
თუ თქვენ გააკეთეთ მათემატიკა და აღმოაჩინეთ, რომ ხარჯები ძალიან მაღალია, შემდეგ ნაწილში მე ვისაუბრებ იმაზე, თუ როგორ შევქმნათ სერვერის ანალიტიკის უფრო იაფი ვერსია.

Მადლობა წაკითხვისთვის! სიამოვნებით დავსვამ კითხვებს კომენტარებში.

წყარო: www.habr.com