როგორ მოვაწყვეთ უაღრესად ეფექტური და იაფი DataLake და რატომ არის ეს ასე

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

ტყუილად არ არის, რომ უფრო გამოცდილი კოლეგები, თავიანთი თავებით მოფენილი შეცდომებით და, შესაბამისად, უკვე ნაცრისფერით, ფიქრობენ "კონტეინერების" პაკეტების "კუბებში" წარმოუდგენლად სწრაფად განთავსებაზე ათობით სერვერზე "მოდური ენების" ჩაშენებული მხარდაჭერით. ასინქრონული არა-დაბლოკვის I/O, მოკრძალებული ღიმილი. და ისინი ჩუმად აგრძელებენ „man ps“-ის ხელახლა კითხვას, იკვლევენ „nginx“-ის საწყის კოდს, სანამ თვალებიდან სისხლი არ გაუღვივდებათ და წერენ, წერენ, წერენ ერთეულ ტესტებს. კოლეგებმა იციან, რომ ყველაზე საინტერესო მაშინ დადგება, როცა „ეს ყველაფერი“ ერთ დღეს საახალწლო ღამეს ფსონი გახდება. და მათ დაეხმარება მხოლოდ Unix-ის ბუნების ღრმა გაგება, დამახსოვრება TCP/IP მდგომარეობის ცხრილი და ძირითადი დახარისხება-ძიების ალგორითმები. სისტემის გაცოცხლება ზარის დარტყმის დროს.

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

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

ძირითადი ტექნიკური ანალიტიკა Bitrix24-ში

რამდენიმე წლის წინ, Bitrix24 სერვისის გაშვების პარალელურად, ჩვენ აქტიურად ჩავდეთ დრო და რესურსი მარტივი და სანდო ანალიტიკური პლატფორმის შესაქმნელად, რომელიც დაგვეხმარება სწრაფად დაინახოს პრობლემები ინფრასტრუქტურაში და დავგეგმოთ შემდეგი ნაბიჯი. რა თქმა უნდა, მიზანშეწონილი იყო მზა ხელსაწყოების აღება, რაც შეიძლება მარტივი და გასაგები. შედეგად, nagios შეირჩა მონიტორინგისთვის და munin ანალიტიკისთვის და ვიზუალიზაციისთვის. ახლა ჩვენ გვაქვს ათასობით ჩეკი nagios-ში, ასობით ჩარტი მუნინში და ჩვენი კოლეგები მათ წარმატებით იყენებენ ყოველდღე. მეტრიკა მკაფიოა, გრაფიკები ნათელია, სისტემა რამდენიმე წელია მუშაობს საიმედოდ და მას რეგულარულად ემატება ახალი ტესტები და გრაფიკები: როდესაც ახალ სერვისს ვაყენებთ ექსპლუატაციაში, ვამატებთ რამდენიმე ტესტს და გრაფიკს. Წარმატებები.

Finger on the Pulse - გაფართოებული ტექნიკური ანალიტიკა

პრობლემების შესახებ ინფორმაციის მიღების სურვილმა „რაც შეიძლება სწრაფად“ მიგვიყვანა აქტიურ ექსპერიმენტებამდე მარტივი და გასაგები ინსტრუმენტებით - pinba და xhprof.

Pinba-მ გამოგვიგზავნა სტატისტიკა UDP პაკეტებში PHP-ში ვებ გვერდების ნაწილების მუშაობის სიჩქარის შესახებ და ჩვენ შეგვიძლია ვნახოთ ონლაინ MySQL საცავში (Pinba-ს გააჩნია საკუთარი MySQL ძრავა სწრაფი მოვლენების ანალიტიკისთვის) პრობლემების მოკლე ჩამონათვალი და პასუხის გაცემა. მათ. და xhprof-მა ავტომატურად მოგვცა საშუალება შეგვეგროვებინა კლიენტებისგან ყველაზე ნელი PHP გვერდების შესრულების გრაფიკები და გავაანალიზოთ, თუ რა შეიძლება გამოიწვიოს ამას - მშვიდად, ჩაის დალევა ან რაიმე უფრო ძლიერი.

რამდენიმე ხნის წინ, ინსტრუმენტთა ნაკრები შეივსო კიდევ ერთი საკმაოდ მარტივი და გასაგები ძრავით, რომელიც დაფუძნებულია საპირისპირო ინდექსირების ალგორითმზე, იდეალურად დანერგილი ლეგენდარული Lucene ბიბლიოთეკაში - Elastic/Kibana. დოკუმენტების მრავალძალიანი ჩაწერის მარტივი იდეა შებრუნებულ ლუცენის ინდექსში, ჟურნალებში მოვლენებზე დაფუძნებული და მათში სწრაფი ძებნა ასპექტის გაყოფის გამოყენებით, მართლაც სასარგებლო აღმოჩნდა.

მიუხედავად კიბანაში ვიზუალიზაციის საკმაოდ ტექნიკური გარეგნობისა, დაბალი დონის ცნებებით, როგორიცაა „bucket“ „მიდია ზევით“ და ჯერ კიდევ არ არის სრულიად მივიწყებული რელაციური ალგებრის ხელახლა გამოგონილი ენა, ინსტრუმენტი კარგად დაგვეხმარა შემდეგ ამოცანებში:

• რამდენი PHP შეცდომა ჰქონდა Bitrix24 კლიენტს p1 პორტალზე ბოლო საათში და რომელი? გაიგე, აპატიე და სწრაფად გამოასწორე.
• რამდენი ვიდეოზარი განხორციელდა გერმანიაში პორტალებზე წინა 24 საათის განმავლობაში, რა ხარისხით და იყო თუ არა რაიმე სირთულე არხთან/ქსელთან?
• რამდენად კარგად მუშაობს სისტემის ფუნქციონალობა (ჩვენი C გაფართოება PHP-ისთვის), რომელიც შედგენილია წყაროდან უახლესი სერვისის განახლებაში და გადაცემულია კლიენტებისთვის? არის სეგფურცლები?
• ჯდება თუ არა მომხმარებლის მონაცემები PHP მეხსიერებაში? არის თუ არა შეცდომები პროცესებზე გამოყოფილი მეხსიერების გადაჭარბებასთან დაკავშირებით: „მეხსიერების გარეშე“? იპოვეთ და გაანეიტრალეთ.

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

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

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

ძირითადი ბიზნეს ანალიტიკა

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

ჩვენს ჰარმონიულად განვითარებად კომპანიაში აქა-იქ უფრო დიდი მონაცემებით უფრო ინტენსიური მუშაობის „წინასწარმეტყველები“ ​​გამოჩნდნენ. რეგულარულად დაიწყო უფრო სიღრმისეული და მრავალმხრივი მოხსენებების საჭიროება და სხვადასხვა განყოფილების ბიჭების ძალისხმევით, რამდენიმე ხნის წინ მოეწყო მარტივი და პრაქტიკული გადაწყვეტა - ClickHouse და PowerBI-ის კომბინაცია.

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

აქ მნიშვნელოვანია კარგად გვესმოდეს, რომ ClickHouse, ისევე როგორც Druid, როგორიცაა Vertica, ისევე როგორც Amazon RedShift (რომელიც დაფუძნებულია postgres-ზე), არის ანალიტიკური ძრავები, რომლებიც ოპტიმიზირებულია საკმაოდ მოსახერხებელი ანალიტიკისთვის (ჯამები, აგრეგაციები, მინიმალური-მაქსიმალური სვეტების მიხედვით და რამდენიმე შესაძლო შეერთება. ), რადგან ორგანიზებული ურთიერთობითი ცხრილების სვეტების ეფექტური შესანახად, MySQL-ისა და ჩვენთვის ცნობილი სხვა (სტრიქონზე ორიენტირებული) მონაცემთა ბაზებისგან განსხვავებით.

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

მოთხოვნა პითონზე და ანალიტიკოსებზე

ჩვენს კომპანიას ჰყავს ბევრი დეველოპერი, რომლებიც კოდებს თითქმის ყოველდღე წერენ 10-20 წლის განმავლობაში PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. ასევე არის მრავალი გამოცდილი სისტემის ადმინისტრატორი, რომლებმაც განიცადეს ერთზე მეტი აბსოლუტურად წარმოუდგენელი კატასტროფა, რომელიც არ ჯდება სტატისტიკის კანონებში (მაგალითად, როდესაც Raid-10 დისკების უმეტესობა განადგურებულია ძლიერი ელვისებური დარტყმით). ასეთ ვითარებაში, დიდი ხნის განმავლობაში გაურკვეველი იყო, რა იყო "პითონის ანალიტიკოსი". პითონი ჰგავს PHP-ს, მხოლოდ სახელი ცოტა გრძელია და თარჯიმნის საწყის კოდში გონების შემცვლელი ნივთიერებების ოდნავ ნაკლები კვალია. თუმცა, რაც უფრო და უფრო მეტი ანალიტიკური ანგარიშები იქმნებოდა, გამოცდილმა დეველოპერებმა დაიწყეს უფრო მეტად გააცნობიერონ ვიწრო სპეციალიზაციის მნიშვნელობა ისეთ ინსტრუმენტებში, როგორიცაა numpy, pandas, matplotlib, seaborn.
გადამწყვეტი როლი, სავარაუდოდ, ითამაშა თანამშრომლების უეცარმა დაღლილობამ სიტყვების „ლოგისტიკური რეგრესიის“ კომბინაციით და დიდი მონაცემების ეფექტური მოხსენების დემონსტრირებამ, დიახ, დიახ, pyspark-ის გამოყენებით.

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

Apache Spark/Hadoop-ის შემდგომი მცდელობები აფრენისთვის და რა არ წავიდა სცენარის მიხედვით

თუმცა, მალე გაირკვა, რომ რაღაც სისტემურად არ იყო კარგად სპარკთან, ან უბრალოდ საჭირო იყო ხელების უკეთ დაბანა. თუ Hadoop/MapReduce/Lucene სტეკი დამზადდა საკმაოდ გამოცდილი პროგრამისტების მიერ, რაც აშკარაა, თუ ყურადღებით დავაკვირდებით წყაროს კოდს Java-ში ან Doug Cutting-ის იდეებს Lucene-ში, მაშინ Spark, მოულოდნელად, დაიწერება ეგზოტიკურ ენაზე Scala, რომელიც არის ძალიან საკამათოა პრაქტიკულობის თვალსაზრისით და ამჟამად არ ვითარდება. და Spark კლასტერზე გამოთვლების რეგულარულმა ვარდნამ ალოგიკური და არც თუ ისე გამჭვირვალე მუშაობის გამო მეხსიერების გამოყოფით შემცირების ოპერაციებისთვის (ბევრი კლავიატურა ერთდროულად მოდის) მის ირგვლივ რაღაცის ჰალო შექმნა, რომელსაც ზრდის ადგილი აქვს. გარდა ამისა, სიტუაციას ამძიმებდა დიდი რაოდენობით უცნაური ღია პორტები, დროებითი ფაილები, რომლებიც იზრდებოდა ყველაზე გაუგებარ ადგილებში და ჯოჯოხეთური დამოკიდებულებები - რამაც სისტემის ადმინისტრატორებს გაუჩინა ერთი გრძნობა, რომელიც კარგად იყო ცნობილი ბავშვობიდან: სასტიკი სიძულვილი (ან შესაძლოა მათ სჭირდებოდათ ხელების საპნით დაბანა).

შედეგად, ჩვენ გადავრჩით რამდენიმე შიდა ანალიტიკურ პროექტს, რომლებიც აქტიურად იყენებენ Apache Spark-ს (მათ შორის Spark Streaming, Spark SQL) და Hadoop-ის ეკოსისტემას (და ასე შემდეგ და ა.შ.). იმისდა მიუხედავად, რომ დროთა განმავლობაში ჩვენ ვისწავლეთ "მის" მომზადება და მონიტორინგი საკმაოდ კარგად, და "ის" პრაქტიკულად შეწყვიტა მოულოდნელად ავარია მონაცემთა ბუნების ცვლილებისა და RDD ერთგვაროვანი ჰეშირების დისბალანსის გამო, უკვე მზად არის რაღაცის აღების სურვილი. , განახლებული და ადმინისტრირებული სადღაც ღრუბელში ძლიერდებოდა და ძლიერდებოდა. სწორედ ამ დროს ვცადეთ ამაზონის ვებ სერვისების მზა ღრუბლოვანი ასამბლეის გამოყენება - EMR და, შემდგომში, ცდილობდა პრობლემების გადაჭრას მისი გამოყენებით. EMR არის Apache Spark, რომელიც მომზადებულია ამაზონის მიერ ეკოსისტემიდან დამატებითი პროგრამული უზრუნველყოფით, ისევე როგორც Cloudera/Hortonworks-ის კონსტრუქციები.

ანალიტიკისთვის რეზინის ფაილების შენახვა გადაუდებელი საჭიროებაა

სხეულის სხვადასხვა ნაწილების დამწვრობით Hadoop/Spark-ის „მომზადების“ გამოცდილება უშედეგო არ ყოფილა. სულ უფრო და უფრო ძლიერდებოდა ფაილების ერთიანი, იაფი და საიმედო შენახვის საჭიროება, რომელიც მდგრადი იქნებოდა ტექნიკის გაუმართაობის მიმართ და რომელშიც შესაძლებელი იქნებოდა ფაილების სხვადასხვა ფორმატში შენახვა სხვადასხვა სისტემისგან და ეფექტური და დროში ეფექტური ნიმუშების გაკეთება ამ მონაცემებიდან მოხსენებებისთვის. ნათელი.

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

არის Amazon S3 DataLake-ის კანდიდატი?

Hadoop/MapReduce-ის გამოცდილებამ გვასწავლა, რომ ჩვენ გვჭირდება მასშტაბირებადი, საიმედო ფაილური სისტემა და მასზე მაშტაბური მუშები, რომლებიც „მოდიან“ უფრო ახლოს მონაცემებთან, რათა არ გადავიტანოთ მონაცემები ქსელში. მუშებს უნდა შეეძლოთ წაიკითხონ მონაცემები სხვადასხვა ფორმატში, მაგრამ სასურველია არ წაიკითხონ არასაჭირო ინფორმაცია და შეეძლოთ მონაცემების წინასწარ შენახვა მუშაკებისთვის მოსახერხებელ ფორმატებში.

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

რა მოხდება, თუ ფაილებს ინახავთ ნაცნობ და კარგად ცნობილ მასშტაბირებად ღრუბლოვან საცავში Amazon S3, Hadoop-ისგან საკუთარი კუპების მომზადების გარეშე?

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

ამაზონის ვებ სერვისების კლასტერ-ბიგდატა-ანალიტიკური ეკოსისტემა - ძალიან მარტივი სიტყვებით

თუ ვიმსჯელებთ AWS-თან ჩვენი გამოცდილებით, Apache Hadoop/MapReduce უკვე დიდი ხანია აქტიურად გამოიყენება იქ სხვადასხვა სოუსების ქვეშ, მაგალითად DataPipeline სერვისში (მშურს ჩემი კოლეგების, მათ ისწავლეს მისი სწორად მომზადება). აქ ჩვენ დავაყენეთ სარეზერვო ასლები სხვადასხვა სერვისებიდან DynamoDB ცხრილებიდან:


და ისინი უკვე რამდენიმე წელია რეგულარულად მუშაობენ ჩაშენებულ Hadoop/MapReduce კლასტერებზე, როგორიცაა საათის მექანიზმი. "დააყენე და დაივიწყე":

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

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

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

AWS წებო - ლამაზად შეფუთული Apache Spark სტეროიდებზე

აღმოჩნდა, რომ AWS-ს აქვს "Hive/Pig/Spark" სტეკის საკუთარი ვერსია. ჰავის როლი, ე.ი. ფაილების კატალოგს და მათ ტიპებს DataLake-ში ახორციელებს „მონაცემთა კატალოგი“ სერვისი, რომელიც არ მალავს მის თავსებადობას Apache Hive ფორმატთან. თქვენ უნდა დაამატოთ ინფორმაცია ამ სერვისში იმის შესახებ, თუ სად მდებარეობს თქვენი ფაილები და რა ფორმატშია ისინი. მონაცემები შეიძლება იყოს არა მარტო s3-ში, არამედ მონაცემთა ბაზაშიც, მაგრამ ეს არ არის ამ პოსტის თემა. აი, როგორ არის ორგანიზებული ჩვენი DataLake მონაცემთა დირექტორია:

ფაილები დარეგისტრირებულია, კარგია. თუ ფაილები განახლებულია, ჩვენ ვაწარმოებთ კრეულერებს ხელით ან გრაფიკის მიხედვით, რომლებიც განაახლებს მათ შესახებ ინფორმაციას ტბიდან და შეინახავს მათ. შემდეგ შეიძლება ტბიდან მიღებული მონაცემების დამუშავება და შედეგების სადმე ატვირთვა. უმარტივეს შემთხვევაში ვტვირთავთ s3-ზეც. მონაცემთა დამუშავება შეიძლება განხორციელდეს ნებისმიერ ადგილას, მაგრამ რეკომენდებულია დამუშავების კონფიგურაცია Apache Spark კლასტერზე გაფართოებული შესაძლებლობების გამოყენებით AWS Glue API-ს მეშვეობით. სინამდვილეში, თქვენ შეგიძლიათ აიღოთ ძველი და ნაცნობი პითონის კოდი pyspark ბიბლიოთეკის გამოყენებით და დააკონფიგურიროთ მისი შესრულება გარკვეული სიმძლავრის კლასტერის N კვანძებზე მონიტორინგით, Hadoop-ის ნაწლავებში ჩაღრმავებისა და დოკერ-მოკერის კონტეინერების გადაზიდვისა და დამოკიდებულების კონფლიქტების აღმოფხვრის გარეშე. .

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

ამრიგად, თუ თქვენ გჭირდებათ რაიმეს გამოთვლა Spark კლასტერზე s3-ის მონაცემების გამოყენებით, ჩვენ ვწერთ კოდს python/pyspark-ში, ვამოწმებთ მას და წარმატებებს ვუსურვებთ ღრუბელს.

რაც შეეხება ორკესტრს? რა მოხდება, თუ დავალება დაეცა და გაქრა? დიახ, შემოთავაზებულია ლამაზი მილსადენის გაკეთება Apache Pig-ის სტილში და ჩვენ კი ვცადეთ ისინი, მაგრამ ახლა გადავწყვიტეთ გამოვიყენოთ ჩვენი ღრმად მორგებული ორკესტრირება PHP-სა და JavaScript-ში (მე მესმის, არის კოგნიტური დისონანსი, მაგრამ მუშაობს, წლები და შეცდომების გარეშე).

ტბაში შენახული ფაილების ფორმატი შესრულების გასაღებია

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

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

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

AWS Athena - ჯეკ-ში-ყუთი

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

Athena ძრავა იკვებება მონაცემებით s3-ში დაფუძნებულია ლეგენდარულზე Presto - MPP (მასიური პარალელური დამუშავება) მიდგომების ოჯახის წარმომადგენელი მონაცემთა დამუშავებისადმი, მონაცემების აღება იქ, სადაც ის დევს, s3-დან და Hadoop-დან კასანდრამდე და ჩვეულებრივი ტექსტური ფაილებით. თქვენ უბრალოდ უნდა სთხოვოთ ათენას შეასრულოს SQL მოთხოვნა და შემდეგ ყველაფერი "სწრაფად და ავტომატურად იმუშავებს". მნიშვნელოვანია აღინიშნოს, რომ Athena არის "ჭკვიანი", ის მიდის მხოლოდ საჭირო გახეხილ საქაღალდეებში და კითხულობს მხოლოდ მოთხოვნაში საჭირო სვეტებს.

ასევე საინტერესოა ათენასთან მოთხოვნის ფასი. ჩვენ ვიხდით სკანირებული მონაცემების მოცულობა. იმათ. არა წუთში კლასტერში მანქანების რაოდენობაზე, არამედ... 100-500 აპარატზე რეალურად დასკანირებული მონაცემებისთვის, მხოლოდ მოთხოვნის შესასრულებლად საჭირო მონაცემები.

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

სხვათა შორის, აი, როგორ ვანაწილებთ ჩვენს მონაცემებს s3-ში:

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

მაგრამ ჩვენ უფრო შორს წავედით და დავიწყეთ ღრუბელთან სიარული პასუხების მისაღებად ODBC დრაივერის საშუალებით: ანალიტიკოსი წერს SQL შეკითხვას ნაცნობ კონსოლში, რომელიც 100-500 მანქანაზე „პენინებისთვის“ აგზავნის მონაცემებს s3-ზე და უბრუნებს პასუხს ჩვეულებრივ რამდენიმე წამში. კომფორტული. და სწრაფად. მე მაინც არ მჯერა.

შედეგად, გადავწყვიტეთ მონაცემების შენახვა s3-ში, ეფექტური სვეტური ფორმატით და მონაცემთა გონივრული გაზიარებით საქაღალდეებში... მივიღეთ DataLake და სწრაფი და იაფი ანალიტიკური ძრავა - უფასოდ. და ის ძალიან პოპულარული გახდა კომპანიაში, რადგან... ესმის SQL და ამუშავებს მასშტაბების ბრძანებებს უფრო სწრაფად, ვიდრე კლასტერების დაწყება/შეჩერება/დაყენება. ”და თუ შედეგი იგივეა, რატომ უნდა გადაიხადოთ მეტი?”

ათენას მიმართ თხოვნა ასე გამოიყურება. თუ სასურველია, რა თქმა უნდა, შეგიძლიათ საკმარისად ჩამოყალიბება რთული და მრავალგვერდიანი SQL მოთხოვნა, მაგრამ ჩვენ შემოვიფარგლებით მარტივი დაჯგუფებით. ვნახოთ რა პასუხების კოდები ჰქონდა კლიენტს რამდენიმე კვირის წინ ვებ სერვერის ჟურნალებში და დავრწმუნდეთ, რომ შეცდომები არ არის:

დასკვნები

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

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

მოგზაურობის დასაწყისში ჩემი თავი იშლებოდა ღია და დახურული პროგრამული უზრუნველყოფის მრავალი ველური ზოოპარკიდან და მესმოდა შთამომავლების წინაშე პასუხისმგებლობის ტვირთი. უბრალოდ დაიწყეთ თქვენი DataLake-ის შექმნა მარტივი ხელსაწყოებიდან: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., შეაგროვეთ გამოხმაურება და ღრმად გაიგეთ მიმდინარე პროცესების ფიზიკა. ყველაფერი რთული და ბუნდოვანი - მიეცით მტრებს და კონკურენტებს.

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

წყარო: www.habr.com