როგორ მოახდინა Google-ის BigQuery-მა მონაცემთა ანალიზის დემოკრატიზაცია. Ნაწილი 2

ჰეი ჰაბრ! კურსის ახალი ნაკადისთვის ჩარიცხვა ღიაა OTUS-ში ახლავე მონაცემთა ინჟინერი. კურსის დაწყების მოლოდინში ვაგრძელებთ თქვენთვის სასარგებლო მასალის გაზიარებას.

წაიკითხეთ ნაწილი პირველი

Მონაცემთა მართვა

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

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

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

• დომენის შეზღუდული გაზიარება: ბეტა ფუნქცია, რათა მომხმარებლებს არ გაუზიარონ BigQuery მონაცემთა ნაკრები მომხმარებლებს Twitter-ის გარეთ.
• VPC სერვისის კონტროლი: კონტროლი, რომელიც ხელს უშლის მონაცემთა ექსფილტრაციას და მოითხოვს მომხმარებლებს წვდომას BigQuery IP მისამართის ცნობილი დიაპაზონიდან.

ჩვენ განვახორციელეთ ავთენტიფიკაციის, ავტორიზაციისა და აუდიტის (AAA) მოთხოვნები უსაფრთხოებისთვის შემდეგნაირად:

• ავტორიზაცია: ჩვენ გამოვიყენეთ GCP მომხმარებლის ანგარიშები ad hoc მოთხოვნებისთვის და სერვისის ანგარიშები წარმოების მოთხოვნებისთვის.
• ავტორიზაცია: ჩვენ მოვითხოვეთ, რომ თითოეულ მონაცემთა ბაზას ჰქონდეს მფლობელის სერვისის ანგარიში და მკითხველთა ჯგუფი.
• აუდიტი: ჩვენ ექსპორტირებულია BigQuery stackdriver ჟურნალები, რომლებიც შეიცავდა დეტალურ ინფორმაციას შეკითხვის შესრულების შესახებ, BigQuery მონაცემთა ბაზაში მარტივი ანალიზისთვის.

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

ჩვენ გადავხედეთ Google-ს Cloud Data Loss Prevention API, რომელიც იყენებს მანქანურ სწავლებას სენსიტიური მონაცემების კლასიფიკაციისა და რედაქტირებისთვის, მაგრამ გადაწყვიტეს მონაცემთა ნაკრების ხელით ანოტაცია სიზუსტის გამო. ჩვენ ვგეგმავთ გამოვიყენოთ მონაცემთა დაკარგვის პრევენციის API მორგებული ანოტაციის გასაძლიერებლად.

Twitter-ზე, ჩვენ შევქმენით მონაცემთა კონფიდენციალურობის ოთხი კატეგორია BigQuery-ში, რომლებიც ჩამოთვლილია აქ მგრძნობელობის კლებადობით:

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

რაც შეეხება ჟურნალს, ჩვენ გამოვიყენეთ დაგეგმილი ამოცანები BigQuery მონაცემთა ნაკრების დასათვლელად და მონაცემთა წვდომის ფენით დარეგისტრირებისთვის (DAL), Twitter მეტამონაცემების საცავი. მომხმარებლები გააკეთებენ ანოტაციას მონაცემთა ნაკრებებს კონფიდენციალურობის ინფორმაციით და ასევე მიუთითებენ შენახვის პერიოდს. რაც შეეხება დასუფთავებას, ჩვენ ვაფასებთ ორი ვარიანტის შესრულებას და ღირებულებას: 1. მონაცემთა ნაკრების გაწმენდა GCS-ში ისეთი ხელსაწყოების გამოყენებით, როგორიცაა Scalding და ჩატვირთვა BigQuery-ში; 2. BigQuery DML განცხადებების გამოყენება. ჩვენ სავარაუდოდ გამოვიყენებთ ორივე მეთოდის კომბინაციას სხვადასხვა ჯგუფისა და მონაცემების მოთხოვნების დასაკმაყოფილებლად.

სისტემის ფუნქციონირება

იმის გამო, რომ BigQuery არის მართული სერვისი, არ იყო საჭირო Twitter-ის SRE გუნდის ჩართვა სისტემების მენეჯმენტში ან სამაგიდო მოვალეობებში. ადვილი იყო მეტი ტევადობის უზრუნველყოფა როგორც შენახვისთვის, ასევე გამოთვლისთვის. ჩვენ შეგვიძლია შევცვალოთ სლოტის დაჯავშნა Google-ის მხარდაჭერით ბილეთის შექმნით. ჩვენ გამოვავლინეთ სფეროები, რომლებიც შეიძლება გაუმჯობესებულიყო, როგორიცაა თვითმომსახურების სლოტების გამოყოფა და დაფის გაუმჯობესება მონიტორინგისთვის, და ეს მოთხოვნები Google-ს გავუგზავნეთ.

ღირებულება

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

BigQuery-ში მონაცემების შენახვამ GCS ხარჯებთან ერთად მოიტანა ხარჯებიც. ინსტრუმენტები, როგორიცაა Scalding, საჭიროებს მონაცემთა ნაკრებებს GCS-ში და BigQuery-ზე წვდომისთვის, ჩვენ უნდა ჩატვირთოთ იგივე მონაცემთა ნაკრები BigQuery ფორმატში CAPACITOR. ჩვენ ვმუშაობთ BigQuery მონაცემთა ნაკრებებთან Scalding კავშირზე, რომელიც აღმოფხვრის მონაცემთა ნაკრების შენახვის საჭიროებას როგორც GCS-ში, ასევე BigQuery-ში.

იშვიათი შემთხვევებისთვის, რომლებიც საჭიროებდა ათეულ პეტაბაიტიან იშვიათ შეკითხვებს, ჩვენ გადავწყვიტეთ, რომ მონაცემთა ნაკრების შენახვა BigQuery-ში არ იყო ეკონომიური და გამოვიყენეთ Presto უშუალოდ მონაცემთა ნაკრებებზე წვდომისათვის GCS-ში. ამისათვის ჩვენ ვუყურებთ BigQuery მონაცემთა გარე წყაროებს.

შემდეგი ნაბიჯები

ჩვენ ვნახეთ დიდი ინტერესი BigQuery-ის მიმართ ალფა გამოშვების შემდეგ. ჩვენ ვამატებთ უფრო მეტ მონაცემთა ნაკრებებს და მეტ ბრძანებებს BigQuery-ს. ჩვენ ვამუშავებთ კონექტორებს მონაცემთა ანალიტიკური ხელსაწყოებისთვის, როგორიცაა Scalding, წაკითხვისა და ჩაწერისთვის BigQuery საცავში. ჩვენ განვიხილავთ ისეთ ინსტრუმენტებს, როგორიცაა Looker და Apache Zeppelin, რათა შევქმნათ საწარმოს ხარისხის ანგარიშები და შენიშვნები BigQuery მონაცემთა ნაკრების გამოყენებით.

ჩვენი თანამშრომლობა Google-თან იყო ძალიან პროდუქტიული და მოხარული ვართ, რომ გავაგრძელოთ და განვავითაროთ ეს პარტნიორობა. ჩვენ ვიმუშავეთ Google-თან, რათა განვახორციელოთ საკუთარი პარტნიორის საკითხების ტრეკერიშეკითხვის გაგზავნა პირდაპირ Google-ში. ზოგიერთი მათგანი, როგორიცაა BigQuery Parquet loader, უკვე დანერგილია Google-ის მიერ.

აქ არის რამდენიმე ჩვენი მაღალი პრიორიტეტული ფუნქციების მოთხოვნა Google-ისთვის:

• ინსტრუმენტები მონაცემთა მოსახერხებელი მიღებისა და LZO-Thrift ფორმატის მხარდაჭერისთვის.
• საათობრივი სეგმენტაცია
• წვდომის კონტროლის გაუმჯობესება, როგორიცაა ცხრილის, მწკრივის და სვეტის დონის ნებართვები.
• bigquery გარე მონაცემთა წყაროები Hive Metastore ინტეგრაციით და LZO-Thrift ფორმატის მხარდაჭერით.
• მონაცემთა კატალოგის გაუმჯობესებული ინტეგრაცია BigQuery მომხმარებლის ინტერფეისში
• თვითმომსახურება სლოტების გამოყოფისა და მონიტორინგისთვის.

დასკვნა

მონაცემთა ანალიტიკის, ვიზუალიზაციისა და მანქანათმცოდნეობის უსაფრთხო გზით დემოკრატიზაცია მონაცემთა პლატფორმის გუნდის მთავარი პრიორიტეტია. ჩვენ დავადგინეთ Google BigQuery და Data Studio, როგორც ინსტრუმენტები, რომლებიც დაგვეხმარება ამ მიზნის მიღწევაში, და გამოვაქვეყნეთ BigQuery Alpha კომპანიაში გასულ წელს.

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

საერთო ჯამში, BigQuery კარგად მუშაობს ზოგადი SQL ანალიზისთვის. ჩვენ ვხედავთ დიდ ინტერესს BigQuery-ის მიმართ და ვმუშაობთ მეტი მონაცემთა ნაკრების მიგრაციაზე, მეტი გუნდის მოზიდვაზე და BigQuery-ით მეტი მილსადენის აშენებაზე. Twitter იყენებს მრავალფეროვან მონაცემებს, რომლებიც საჭიროებს ინსტრუმენტების კომბინაციას, როგორიცაა Scalding, Spark, Presto და Druid. ჩვენ ვაპირებთ გავაგრძელოთ ჩვენი მონაცემთა ანალიტიკის ინსტრუმენტების გაძლიერება და მივცეთ მკაფიო მითითებები ჩვენს მომხმარებლებს, თუ როგორ გამოიყენონ ჩვენი შეთავაზებები საუკეთესოდ.

მადლიერების სიტყვები

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

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

მონაცემთა ხარისხი DWH-ში - მონაცემთა საწყობის თანმიმდევრულობა

წყარო: www.habr.com