🥇របៀបវិភាគទិន្នន័យប្រជាធិបតេយ្យរបស់ Google BigQuery ។ ភាគ២

សួស្តី ហាប! ការចុះឈ្មោះសម្រាប់វគ្គសិក្សាថ្មីគឺបើកឥឡូវនេះនៅ OTUS "វិស្វករទិន្នន័យ". នៅក្នុងការរំពឹងទុកនៃការចាប់ផ្តើមនៃវគ្គសិក្សានេះ យើងបានរៀបចំជាប្រពៃណីនូវការបកប្រែនៃសម្ភារៈដែលគួរឱ្យចាប់អារម្មណ៍សម្រាប់អ្នក។

ជារៀងរាល់ថ្ងៃ មនុស្សជាងមួយរយលាននាក់បានចូលមើល Twitter ដើម្បីស្វែងរកអ្វីដែលកំពុងកើតឡើងនៅក្នុងពិភពលោក ហើយពិភាក្សាអំពីវា។ រាល់ tweet និងរាល់សកម្មភាពរបស់អ្នកប្រើផ្សេងទៀតបង្កើតព្រឹត្តិការណ៍មួយដែលមានសម្រាប់ការវិភាគទិន្នន័យខាងក្នុងរបស់ Twitter ។ បុគ្គលិករាប់រយនាក់វិភាគ និងមើលឃើញទិន្នន័យនេះ ហើយការកែលម្អបទពិសោធន៍របស់ពួកគេគឺជាអាទិភាពចម្បងសម្រាប់ក្រុម Twitter Data Platform ។

យើងជឿជាក់ថា អ្នកប្រើប្រាស់ដែលមានជំនាញបច្ចេកទេសយ៉ាងទូលំទូលាយ គួរតែអាចស្វែងរកទិន្នន័យ និងអាចចូលប្រើឧបករណ៍វិភាគ និងរូបភាពដែលផ្អែកលើ SQL ដែលដំណើរការបានល្អ។ នេះនឹងអនុញ្ញាតឱ្យក្រុមថ្មីទាំងមូលនៃអ្នកប្រើប្រាស់បច្ចេកទេសតិច រួមទាំងអ្នកវិភាគទិន្នន័យ និងអ្នកគ្រប់គ្រងផលិតផល ទាញយកការយល់ដឹងពីទិន្នន័យ ដែលអនុញ្ញាតឱ្យពួកគេយល់កាន់តែច្បាស់ និងប្រើប្រាស់សមត្ថភាពរបស់ Twitter ។ នេះជារបៀបដែលយើងធ្វើប្រជាធិបតេយ្យការវិភាគទិន្នន័យនៅលើ Twitter ។

ដោយសារឧបករណ៍ និងសមត្ថភាពវិភាគទិន្នន័យខាងក្នុងរបស់យើងមានភាពប្រសើរឡើង យើងបានឃើញ Twitter ប្រសើរឡើង។ ទោះយ៉ាងណាក៏ដោយនៅតែមានកន្លែងសម្រាប់កែលម្អ។ ឧបករណ៍បច្ចុប្បន្នដូចជា Scalding ត្រូវការបទពិសោធន៍សរសេរកម្មវិធី។ ឧបករណ៍វិភាគដែលមានមូលដ្ឋានលើ SQL ដូចជា Presto និង Vertica មានបញ្ហាដំណើរការតាមមាត្រដ្ឋាន។ យើងក៏មានបញ្ហាក្នុងការចែកចាយទិន្នន័យនៅទូទាំងប្រព័ន្ធច្រើនដោយមិនមានការចូលប្រើប្រាស់វាជាប្រចាំ។

កាលពីឆ្នាំមុនយើងបានប្រកាស កិច្ចសហការថ្មីជាមួយ Googleដែលក្នុងនោះយើងផ្ទេរផ្នែកខ្លះរបស់យើង។ ហេដ្ឋារចនាសម្ព័ន្ធទិន្នន័យ នៅលើ Google Cloud Platform (GCP) ។ យើងបានសន្និដ្ឋានថាឧបករណ៍ Google Cloud ទិន្នន័យធំ អាចជួយយើងជាមួយនឹងការផ្តួចផ្តើមរបស់យើងដើម្បីធ្វើប្រជាធិបតេយ្យការវិភាគ ការមើលឃើញ និងការរៀនម៉ាស៊ីននៅលើ Twitter៖

BigQuery៖ ឃ្លាំងទិន្នន័យសហគ្រាសដែលមានម៉ាស៊ីន SQL ផ្អែកលើ Dremelដែលល្បីល្បាញសម្រាប់ល្បឿន ភាពសាមញ្ញ និងអាចទប់ទល់បាន។ ការរៀនម៉ាស៊ីន.
ស្ទូឌីយោទិន្នន័យ៖ ឧបករណ៍មើលឃើញទិន្នន័យធំជាមួយនឹងមុខងារសហការដូច Google Docs ។

នៅក្នុងអត្ថបទនេះ អ្នកនឹងរៀនអំពីបទពិសោធន៍របស់យើងជាមួយនឹងឧបករណ៍ទាំងនេះ៖ អ្វីដែលយើងបានធ្វើ អ្វីដែលយើងបានរៀន និងអ្វីដែលយើងនឹងធ្វើបន្ទាប់ទៀត។ ឥឡូវនេះយើងនឹងផ្តោតលើការវិភាគជាបាច់ និងអន្តរកម្ម។ យើងនឹងពិភាក្សាអំពីការវិភាគពេលវេលាជាក់ស្តែងនៅក្នុងអត្ថបទបន្ទាប់។

ប្រវត្តិនៃហាងទិន្នន័យ Twitter

មុនពេលចូលទៅក្នុង BigQuery វាមានតម្លៃរំលឹកឡើងវិញយ៉ាងខ្លីអំពីប្រវត្តិនៃឃ្លាំងទិន្នន័យ Twitter ។ ក្នុងឆ្នាំ 2011 ការវិភាគទិន្នន័យ Twitter ត្រូវបានអនុវត្តនៅក្នុង Vertica និង Hadoop ។ យើងបានប្រើ Pig ដើម្បីបង្កើតការងារ MapReduce Hadoop ។ ក្នុងឆ្នាំ 2012 យើងបានជំនួស Pig ជាមួយ Scalding ដែលមាន Scala API ជាមួយនឹងអត្ថប្រយោជន៍ដូចជាសមត្ថភាពក្នុងការបង្កើតបំពង់ស្មុគស្មាញ និងភាពងាយស្រួលនៃការធ្វើតេស្ត។ ទោះយ៉ាងណាក៏ដោយ សម្រាប់អ្នកវិភាគទិន្នន័យ និងអ្នកគ្រប់គ្រងផលិតផលជាច្រើនដែលមានផាសុកភាពក្នុងការធ្វើការជាមួយ SQL វាគឺជាខ្សែកោងនៃការរៀនសូត្រដ៏ចោត។ ប្រហែលឆ្នាំ 2016 យើងបានចាប់ផ្តើមប្រើ Presto ជាចំណុចប្រទាក់ SQL ទៅកាន់ទិន្នន័យ Hadoop ។ Spark ផ្តល់ជូននូវចំណុចប្រទាក់ Python ដែលធ្វើឱ្យវាក្លាយជាជម្រើសដ៏ល្អសម្រាប់វិទ្យាសាស្ត្រទិន្នន័យ និងការសិក្សាដោយម៉ាស៊ីន។

ចាប់តាំងពីឆ្នាំ 2018 មក យើងបានប្រើប្រាស់ឧបករណ៍ខាងក្រោមសម្រាប់ការវិភាគទិន្នន័យ និងការមើលឃើញរូបភាព៖

Scalding សម្រាប់ conveyors ផលិតកម្ម
Scalding and Spark សម្រាប់ការវិភាគទិន្នន័យ ad hoc និងការរៀនម៉ាស៊ីន
Vertica និង Presto សម្រាប់ ad hoc និងការវិភាគ SQL អន្តរកម្ម
Druid សម្រាប់ការចូលប្រើអន្តរកម្មទាប ការរុករក និងការយឺតយ៉ាវទាបចំពោះរង្វាស់ស៊េរីពេលវេលា
Tableau, Zeppelin និង Pivot សម្រាប់ការមើលឃើញទិន្នន័យ

យើងបានរកឃើញថា ខណៈពេលដែលឧបករណ៍ទាំងនេះផ្តល់នូវសមត្ថភាពខ្លាំង យើងមានការលំបាកក្នុងការធ្វើឱ្យសមត្ថភាពទាំងនេះអាចរកបានសម្រាប់ទស្សនិកជនកាន់តែទូលំទូលាយនៅលើ Twitter ។ តាមរយៈការពង្រីកវេទិការបស់យើងជាមួយ Google Cloud យើងកំពុងផ្តោតលើការធ្វើឱ្យឧបករណ៍វិភាគរបស់យើងងាយស្រួលសម្រាប់ Twitter ទាំងអស់។

ឃ្លាំងទិន្នន័យ BigQuery របស់ Google

ក្រុមជាច្រើននៅ Twitter បានដាក់បញ្ចូល BigQuery ទៅក្នុងបំពង់ផលិតកម្មរបស់ពួកគេរួចហើយ។ ដោយប្រើជំនាញរបស់ពួកគេ យើងបានចាប់ផ្តើមវាយតម្លៃសមត្ថភាពរបស់ BigQuery សម្រាប់ករណីប្រើប្រាស់ Twitter ទាំងអស់។ គោលដៅរបស់យើងគឺផ្តល់ជូន BigQuery ដល់ក្រុមហ៊ុនទាំងមូល ហើយធ្វើស្តង់ដារ និងគាំទ្រវានៅក្នុងសំណុំឧបករណ៍ Data Platform ។ នេះគឺពិបាកសម្រាប់ហេតុផលជាច្រើន។ យើងចាំបាច់ត្រូវអភិវឌ្ឍហេដ្ឋារចនាសម្ព័ន្ធមួយដើម្បីអាចជឿទុកចិត្តបាននូវបរិមាណដ៏ធំនៃទិន្នន័យ គាំទ្រការគ្រប់គ្រងទិន្នន័យទូទាំងក្រុមហ៊ុន ធានាបាននូវការគ្រប់គ្រងការចូលប្រើប្រាស់បានត្រឹមត្រូវ និងធានាភាពឯកជនរបស់អតិថិជន។ យើងក៏ត្រូវបង្កើតប្រព័ន្ធសម្រាប់ការបែងចែកធនធាន ការត្រួតពិនិត្យ និងការគិតប្រាក់ត្រឡប់មកវិញ ដើម្បីឱ្យក្រុមអាចប្រើប្រាស់ BigQuery ប្រកបដោយប្រសិទ្ធភាព។

នៅក្នុងខែវិច្ឆិកា ឆ្នាំ 2018 យើងបានចេញផ្សាយការចេញផ្សាយអាល់ហ្វាទូទាំងក្រុមហ៊ុននៃ BigQuery និង Data Studio ។ យើងផ្តល់ជូនបុគ្គលិក Twitter មួយចំនួននៃសៀវភៅបញ្ជីដែលប្រើញឹកញាប់បំផុតរបស់យើងជាមួយនឹងការសម្អាតទិន្នន័យផ្ទាល់ខ្លួន។ BigQuery ត្រូវបានប្រើប្រាស់ដោយអ្នកប្រើប្រាស់ជាង 250 នាក់មកពីក្រុមផ្សេងៗគ្នា រួមទាំងវិស្វកម្ម ហិរញ្ញវត្ថុ និងទីផ្សារ។ ថ្មីៗនេះ ពួកគេកំពុងដំណើរការសំណើប្រហែល 8k ដំណើរការប្រហែល 100 PB ក្នុងមួយខែ ដោយមិនរាប់បញ្ចូលសំណើដែលបានកំណត់ពេលនោះទេ។ បន្ទាប់ពីទទួលបានមតិកែលម្អជាវិជ្ជមាន យើងបានសម្រេចចិត្តឆ្ពោះទៅមុខ និងផ្តល់ជូន BigQuery ជាធនធានចម្បងសម្រាប់ការធ្វើអន្តរកម្មជាមួយទិន្នន័យនៅលើ Twitter ។

នេះគឺជាដ្យាក្រាមកម្រិតខ្ពស់នៃស្ថាបត្យកម្មឃ្លាំងទិន្នន័យ Google BigQuery របស់យើង។

យើងចម្លងទិន្នន័យពីក្រុម Hadoop នៅនឹងកន្លែងទៅ Google Cloud Storage (GCS) ដោយប្រើឧបករណ៍ Cloud Replicator ខាងក្នុង។ បន្ទាប់មកយើងប្រើ Apache Airflow ដើម្បីបង្កើតបំពង់ដែលប្រើ "bq_load» ដើម្បីផ្ទុកទិន្នន័យពី GCS ទៅក្នុង BigQuery ។ យើងប្រើ Presto ដើម្បីសាកសួរសំណុំទិន្នន័យ Parquet ឬ Thrift-LZO នៅក្នុង GCS ។ BQ Blaster គឺជាឧបករណ៍ Scalding ខាងក្នុងសម្រាប់ផ្ទុកសំណុំទិន្នន័យ HDFS Vertica និង Thrift-LZO ចូលទៅក្នុង BigQuery ។

នៅក្នុងផ្នែកខាងក្រោម យើងពិភាក្សាអំពីវិធីសាស្រ្ត និងជំនាញរបស់យើងក្នុងផ្នែកនៃភាពងាយស្រួលនៃការប្រើប្រាស់ ការអនុវត្ត ការគ្រប់គ្រងទិន្នន័យ សុខភាពប្រព័ន្ធ និងតម្លៃ។

ភាពងាយស្រួលនៃការប្រើប្រាស់

យើងបានរកឃើញថាវាងាយស្រួលសម្រាប់អ្នកប្រើប្រាស់ក្នុងការចាប់ផ្តើមជាមួយ BigQuery ព្រោះវាមិនត្រូវការការដំឡើងកម្មវិធីទេ ហើយអ្នកប្រើប្រាស់អាចចូលប្រើវាបានតាមរយៈចំណុចប្រទាក់គេហទំព័រដែលវិចារណញាណ។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកប្រើប្រាស់ចាំបាច់ត្រូវស្គាល់លក្ខណៈ និងគំនិតមួយចំនួនរបស់ GCP រួមទាំងធនធានដូចជាគម្រោង សំណុំទិន្នន័យ និងតារាង។ យើងបានបង្កើតឯកសារអប់រំ និងការបង្រៀនដើម្បីជួយអ្នកប្រើប្រាស់ចាប់ផ្តើម។ ជាមួយនឹងការយល់ដឹងជាមូលដ្ឋានដែលទទួលបាន អ្នកប្រើប្រាស់បានរកឃើញថាវាងាយស្រួលក្នុងការរុករកសំណុំទិន្នន័យ មើលគ្រោងការណ៍ និងទិន្នន័យតារាង ដំណើរការសំណួរសាមញ្ញ និងមើលឃើញលទ្ធផលនៅក្នុង Data Studio។

គោលដៅរបស់យើងសម្រាប់ការបញ្ចូលទិន្នន័យទៅក្នុង BigQuery គឺដើម្បីបើកដំណើរការផ្ទុកសំណុំទិន្នន័យ HDFS ឬ GCS ដោយចុចតែម្តង។ យើងបានពិចារណា Cloud Composer (គ្រប់គ្រងដោយ Airflow) ប៉ុន្តែមិនអាចប្រើវាបានទេ ដោយសារគំរូសុវត្ថិភាពនៃការចែករំលែក Domain Restricted Sharing (បន្ថែមលើបញ្ហានេះនៅក្នុងផ្នែកគ្រប់គ្រងទិន្នន័យខាងក្រោម)។ យើងបានសាកល្បងប្រើប្រាស់សេវាកម្មផ្ទេរទិន្នន័យ Google (DTS) ដើម្បីរៀបចំបន្ទុកការងារ BigQuery ។ ខណៈពេលដែល DTS មានភាពរហ័សរហួនក្នុងការរៀបចំ វាមិនមានភាពបត់បែនសម្រាប់ការសាងសង់បំពង់ដែលមានភាពអាស្រ័យ។ សម្រាប់ការចេញផ្សាយអាល់ហ្វារបស់យើង យើងបានកសាងក្របខ័ណ្ឌ Apache Airflow ផ្ទាល់ខ្លួនរបស់យើងនៅក្នុង GCE ហើយកំពុងរៀបចំវាឱ្យដំណើរការនៅក្នុងផលិតកម្ម និងអាចគាំទ្រប្រភពទិន្នន័យបន្ថែមទៀតដូចជា Vertica ជាដើម។

ដើម្បីបំប្លែងទិន្នន័យទៅជា BigQuery អ្នកប្រើប្រាស់បង្កើតបំពង់បញ្ជូនទិន្នន័យ SQL សាមញ្ញដោយប្រើសំណួរដែលបានកំណត់ពេល។ សម្រាប់បំពង់បង្ហូរឧស្ម័នពហុដំណាក់កាលស្មុគ្រស្មាញជាមួយនឹងភាពអាស្រ័យ យើងមានគម្រោងប្រើទាំង Airflow framework របស់យើងផ្ទាល់ ឬ Cloud Composer រួមជាមួយនឹង លំហូរពពក.

ផលិតភាព

BigQuery ត្រូវបានរចនាឡើងសម្រាប់គោលបំណងទូទៅ SQL queries ដែលដំណើរការទិន្នន័យយ៉ាងច្រើន។ វាមិនមានបំណងសម្រាប់ភាពយឺតយ៉ាវទាប សំណួរឆ្លងកាត់ខ្ពស់ដែលទាមទារដោយមូលដ្ឋានទិន្នន័យប្រតិបត្តិការ ឬសម្រាប់ការវិភាគស៊េរីពេលវេលា latency ទាបដែលត្រូវបានអនុវត្ត កម្មវិធី Apache Druid. សម្រាប់សំណួរវិភាគអន្តរកម្ម អ្នកប្រើប្រាស់របស់យើងរំពឹងថានឹងមានពេលវេលាឆ្លើយតបតិចជាងមួយនាទី។ យើងត្រូវតែរចនាការប្រើប្រាស់ BigQuery របស់យើងដើម្បីបំពេញតាមការរំពឹងទុកទាំងនេះ។ ដើម្បីផ្តល់នូវការអនុវត្តដែលអាចទស្សន៍ទាយបានសម្រាប់អ្នកប្រើប្រាស់របស់យើង យើងបានប្រើប្រាស់មុខងារ BigQuery ដែលអាចរកបានសម្រាប់អតិថិជននៅលើមូលដ្ឋានថ្លៃដើមដែលអនុញ្ញាតឱ្យម្ចាស់គម្រោងកក់កន្លែងអប្បបរមាសម្រាប់សំណួររបស់ពួកគេ។ រន្ធដោត BigQuery គឺជាឯកតានៃថាមពលកុំព្យូទ័រដែលត្រូវការដើម្បីប្រតិបត្តិសំណួរ SQL ។

យើងបានវិភាគសំណួរជាង 800 ដែលដំណើរការទិន្នន័យប្រហែល 1 TB ហើយបានរកឃើញថាពេលវេលាប្រតិបត្តិជាមធ្យមគឺ 30 វិនាទី។ យើងក៏បានរៀនផងដែរថាការអនុវត្តគឺពឹងផ្អែកយ៉ាងខ្លាំងទៅលើការប្រើប្រាស់រន្ធដោតរបស់យើងនៅក្នុងគម្រោង និងកិច្ចការផ្សេងៗ។ យើងត្រូវកំណត់ឱ្យបានច្បាស់លាស់នូវផលិតកម្ម និងទុនបម្រុងរន្ធដោតផ្ទាល់ខ្លួនរបស់យើង ដើម្បីរក្សាដំណើរការសម្រាប់ករណីប្រើប្រាស់ផលិតកម្ម និងការវិភាគលើអ៊ីនធឺណិត។ នេះមានឥទ្ធិពលយ៉ាងខ្លាំងលើការរចនារបស់យើងសម្រាប់ការកក់រន្ធដោត និងឋានានុក្រមគម្រោង។

យើងនឹងនិយាយអំពីការគ្រប់គ្រងទិន្នន័យ មុខងារ និងតម្លៃនៃប្រព័ន្ធនៅប៉ុន្មានថ្ងៃខាងមុខនេះនៅក្នុងផ្នែកទីពីរនៃការបកប្រែ ប៉ុន្តែឥឡូវនេះយើងសូមអញ្ជើញអ្នកគ្រប់គ្នាមក webinar បន្តផ្ទាល់ដោយឥតគិតថ្លៃក្នុងអំឡុងពេលដែលអ្នកនឹងអាចរៀនលម្អិតអំពីវគ្គសិក្សា ក៏ដូចជាសួរសំណួរទៅកាន់អ្នកជំនាញរបស់យើង - Egor Mateshuk (វិស្វករទិន្នន័យជាន់ខ្ពស់ MaximaTelecom)។