ដីសណ្តរ៖ ការធ្វើសមកាលកម្មទិន្នន័យ និងការពង្រឹងវេទិកា

នៅក្នុងការរំពឹងទុកនៃការចាប់ផ្តើមនៃលំហូរថ្មីមួយនៅក្នុងអត្រា "វិស្វករទិន្នន័យ" យើងបានរៀបចំការបកប្រែនៃសម្ភារៈដែលគួរឱ្យចាប់អារម្មណ៍។

ទិដ្ឋភាពទូទៅ

យើងនឹងនិយាយអំពីគំរូដ៏ពេញនិយមមួយដែលកម្មវិធីប្រើប្រាស់កន្លែងផ្ទុកទិន្នន័យច្រើន ដែលហាងនីមួយៗត្រូវបានប្រើសម្រាប់គោលបំណងផ្ទាល់ខ្លួនរបស់វា ឧទាហរណ៍ ដើម្បីរក្សាទុកទម្រង់ Canonical នៃទិន្នន័យ (MySQL ។ល។) ផ្តល់នូវសមត្ថភាពស្វែងរកកម្រិតខ្ពស់ (ElasticSearch, etc.) .), ឃ្លាំងសម្ងាត់ (Memcached, etc.) និងផ្សេងៗទៀត។ ជាធម្មតា នៅពេលប្រើប្រាស់កន្លែងផ្ទុកទិន្នន័យច្រើន មួយក្នុងចំណោមពួកវាដើរតួជាហាងចម្បង និងមួយទៀតជាហាងដេរីវេ។ បញ្ហាតែមួយគត់គឺរបៀបធ្វើសមកាលកម្មកន្លែងផ្ទុកទិន្នន័យទាំងនេះ។

យើងបានពិនិត្យមើលគំរូផ្សេងៗគ្នាជាច្រើនដែលព្យាយាមដោះស្រាយបញ្ហានៃការធ្វើសមកាលកម្មហាងជាច្រើន ដូចជាការសរសេរពីរដង ប្រតិបត្តិការចែកចាយជាដើម។ ទោះជាយ៉ាងណាក៏ដោយ វិធីសាស្រ្តទាំងនេះមានដែនកំណត់យ៉ាងសំខាន់នៅក្នុងលក្ខខណ្ឌនៃការប្រើប្រាស់ជីវិតពិត ភាពជឿជាក់ និងការថែទាំ។ បន្ថែមពីលើការធ្វើសមកាលកម្មទិន្នន័យ កម្មវិធីមួយចំនួនក៏ត្រូវការបង្កើនទិន្នន័យដោយការហៅទៅសេវាកម្មខាងក្រៅផងដែរ។

Delta ត្រូវបានបង្កើតឡើងដើម្បីដោះស្រាយបញ្ហាទាំងនេះ។ Delta ទីបំផុតផ្តល់នូវវេទិកាដែលជំរុញដោយព្រឹត្តិការណ៍ស្របគ្នា សម្រាប់ការធ្វើសមកាលកម្មទិន្នន័យ និងការពង្រឹងបន្ថែម។

ដំណោះស្រាយដែលមានស្រាប់

ការចូលទ្វេដង

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

បញ្ហា៖

ការអនុវត្តនីតិវិធីសង្គ្រោះគឺជាការងារជាក់លាក់ដែលមិនអាចប្រើឡើងវិញបានទេ។ លើសពីនេះ ទិន្នន័យរវាងទីតាំងផ្ទុកនៅតែមិនស៊ីសង្វាក់គ្នា រហូតទាល់តែដំណើរការស្ដារកើតឡើង។ ដំណោះស្រាយកាន់តែស្មុគស្មាញ ប្រសិនបើកន្លែងផ្ទុកទិន្នន័យច្រើនជាងពីរត្រូវបានប្រើប្រាស់។ ជាចុងក្រោយ នីតិវិធីស្ដារអាចបន្ថែមការផ្ទុកទៅប្រភពទិន្នន័យដើម។

ផ្លាស់ប្តូរតារាងកំណត់ហេតុ

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

បញ្ហា៖

គំរូនេះគួរតែត្រូវបានអនុវត្តជាបណ្ណាល័យ ហើយតាមឧត្ដមគតិដោយមិនផ្លាស់ប្តូរកូដនៃកម្មវិធីដែលប្រើវា។ នៅក្នុងបរិយាកាសពហុកោណ ការអនុវត្តបណ្ណាល័យបែបនេះគួរតែមានជាភាសាចាំបាច់ណាមួយ ប៉ុន្តែការធានាឱ្យមានភាពស៊ីសង្វាក់គ្នានៃមុខងារ និងអាកប្បកិរិយាទូទាំងភាសាគឺពិបាកណាស់។

បញ្ហាមួយទៀតស្ថិតនៅក្នុងការទទួលបានការផ្លាស់ប្តូរគ្រោងការណ៍នៅក្នុងប្រព័ន្ធដែលមិនគាំទ្រការផ្លាស់ប្តូរគ្រោងការណ៍ប្រតិបត្តិការ [1][2] ដូចជា MySQL ជាដើម។ ដូច្នេះ លំនាំនៃការផ្លាស់ប្តូរ (ឧទាហរណ៍ ការផ្លាស់ប្តូរគ្រោងការណ៍) និងការកត់ត្រាវានៅក្នុងតារាងកំណត់ហេតុនៃការផ្លាស់ប្តូរនឹងមិនដំណើរការជានិច្ចទេ។

ប្រតិបត្តិការចែកចាយ

ប្រតិបត្តិការដែលបានចែកចាយអាចត្រូវបានប្រើដើម្បីបំបែកប្រតិបត្តិការមួយនៅទូទាំងកន្លែងផ្ទុកទិន្នន័យផ្សេងគ្នាជាច្រើន ដូច្នេះប្រតិបត្តិការត្រូវបានប្តេជ្ញាចិត្តចំពោះហាងទិន្នន័យទាំងអស់ដែលបានប្រើ ឬមិនប្តេជ្ញាចំពោះពួកគេណាមួយ។

បញ្ហា៖

ប្រតិបត្តិការចែកចាយគឺជាបញ្ហាដ៏ធំមួយសម្រាប់កន្លែងផ្ទុកទិន្នន័យខុសៗគ្នា។ តាមធម្មជាតិ ពួកគេអាចពឹងផ្អែកលើភាគបែងរួមទាបបំផុតនៃប្រព័ន្ធដែលពាក់ព័ន្ធ។ ឧទាហរណ៍ ប្រតិបត្តិការ XA រារាំងការប្រតិបត្តិ ប្រសិនបើដំណើរការកម្មវិធីបរាជ័យក្នុងដំណាក់កាលរៀបចំ។ លើសពីនេះ XA មិនផ្តល់នូវការរកឃើញការជាប់គាំង ឬគាំទ្រគម្រោងត្រួតពិនិត្យរូបិយប័ណ្ណដែលមានសុទិដ្ឋិនិយមនោះទេ។ លើសពីនេះទៀត ប្រព័ន្ធមួយចំនួនដូចជា ElasticSearch មិនគាំទ្រ XA ឬគំរូប្រតិបត្តិការខុសធម្មតាផ្សេងទៀតទេ។ ដូច្នេះ ការធានានូវអាតូមិកនៃការសរសេរនៅក្នុងបច្ចេកវិទ្យាផ្ទុកទិន្នន័យផ្សេងៗនៅតែជាកិច្ចការដ៏លំបាកសម្រាប់កម្មវិធី [3] ។

ដីសណ្តរ

Delta ត្រូវបានរចនាឡើងដើម្បីដោះស្រាយដែនកំណត់នៃដំណោះស្រាយការធ្វើសមកាលកម្មទិន្នន័យដែលមានស្រាប់ ហើយថែមទាំងអាចបង្កើនទិន្នន័យនៅលើយន្តហោះផងដែរ។ គោលដៅរបស់យើងគឺដើម្បីអរូបីភាពស្មុគ្រស្មាញទាំងអស់នេះឱ្យនៅឆ្ងាយពីអ្នកបង្កើតកម្មវិធីដើម្បីឱ្យពួកគេអាចផ្តោតទាំងស្រុងលើការអនុវត្តមុខងារអាជីវកម្ម។ បន្ទាប់យើងនឹងរៀបរាប់អំពី "ការស្វែងរកភាពយន្ត" ដែលជាករណីប្រើប្រាស់ជាក់ស្តែងសម្រាប់ក្រុមហ៊ុន Netflix's Delta ។

ក្រុមហ៊ុន Netflix ប្រើប្រាស់យ៉ាងទូលំទូលាយនូវស្ថាបត្យកម្មមីក្រូសេវាកម្ម ហើយសេវាមីក្រូនីមួយៗជាធម្មតាបម្រើទិន្នន័យមួយប្រភេទ។ ព័ត៌មានជាមូលដ្ឋានអំពីខ្សែភាពយន្តមាននៅក្នុងសេវាកម្មមីក្រូដែលហៅថាសេវាភាពយន្ត ហើយទិន្នន័យដែលពាក់ព័ន្ធដូចជាព័ត៌មានអំពីអ្នកផលិត តួសម្តែង អ្នកលក់ និងអ្វីៗផ្សេងទៀតត្រូវបានគ្រប់គ្រងដោយមីក្រូសេវាផ្សេងៗជាច្រើន (ដូចជាសេវាចែកចាយ សេវាកម្មទេពកោសល្យ និងសេវាកម្មអ្នកលក់)។
អ្នកប្រើប្រាស់អាជីវកម្មនៅ Netflix Studios ជារឿយៗត្រូវស្វែងរកតាមលក្ខណៈវិនិច្ឆ័យភាពយន្តផ្សេងៗ ដែលនេះជាមូលហេតុដែលវាមានសារៈសំខាន់ខ្លាំងណាស់សម្រាប់ពួកគេដើម្បីអាចស្វែងរកនៅគ្រប់ទិន្នន័យដែលទាក់ទងនឹងភាពយន្ត។

មុនពេល Delta ក្រុមស្វែងរកភាពយន្តត្រូវការទាញទិន្នន័យពីសេវាមីក្រូជាច្រើន មុនពេលធ្វើលិបិក្រមទិន្នន័យភាពយន្ត។ លើសពីនេះ ក្រុមការងារត្រូវបង្កើតប្រព័ន្ធដែលនឹងធ្វើបច្ចុប្បន្នភាពសន្ទស្សន៍ស្វែងរកតាមកាលកំណត់ ដោយស្នើសុំការផ្លាស់ប្តូរពីសេវាមីក្រូផ្សេងទៀត បើទោះបីជាមិនមានការផ្លាស់ប្តូរអ្វីទាំងអស់។ ប្រព័ន្ធនេះកាន់តែស្មុគស្មាញ និងពិបាកក្នុងការថែទាំយ៉ាងឆាប់រហ័ស។

រូបភាពទី 1. ប្រព័ន្ធបោះឆ្នោតទៅកាន់តំបន់ដីសណ្ត
បន្ទាប់ពីប្រើ Delta ប្រព័ន្ធនេះត្រូវបានធ្វើឱ្យសាមញ្ញទៅជាប្រព័ន្ធជំរុញព្រឹត្តិការណ៍ដូចបានបង្ហាញក្នុងរូបខាងក្រោម។ ព្រឹត្តិការណ៍ CDC (Change-Data-Capture) ត្រូវបានផ្ញើទៅកាន់ប្រធានបទ Keystone Kafka ដោយប្រើ Delta-Connector ។ កម្មវិធី Delta ដែលត្រូវបានបង្កើតឡើងដោយប្រើប្រាស់ Delta Stream Processing Framework (ផ្អែកលើ Flink) ទទួលព្រឹត្តិការណ៍ CDC ពីប្រធានបទមួយ ធ្វើអោយពួកវាប្រសើរឡើងដោយការហៅទៅកាន់ microservices ផ្សេងទៀត ហើយចុងក្រោយបញ្ជូនទិន្នន័យដែលសំបូរទៅដោយលិបិក្រមស្វែងរកនៅក្នុង Elasticsearch។ ដំណើរការទាំងមូលកើតឡើងស្ទើរតែក្នុងពេលវេលាជាក់ស្តែង ពោលគឺដរាបណាការផ្លាស់ប្តូរត្រូវបានប្តេជ្ញាចិត្តចំពោះឃ្លាំងទិន្នន័យ លិបិក្រមស្វែងរកត្រូវបានធ្វើបច្ចុប្បន្នភាព។

រូបភាពទី 2. បំពង់បង្ហូរទិន្នន័យដោយប្រើតំបន់ដីសណ្ត
នៅក្នុងផ្នែកខាងក្រោម យើងនឹងពណ៌នាអំពីប្រតិបត្តិការរបស់ Delta-Connector ដែលភ្ជាប់ទៅកន្លែងផ្ទុក និងផ្សព្វផ្សាយព្រឹត្តិការណ៍ CDC ទៅកាន់ស្រទាប់ដឹកជញ្ជូន ដែលជាហេដ្ឋារចនាសម្ព័ន្ធបញ្ជូនទិន្នន័យតាមពេលវេលាជាក់ស្តែង ដែលបញ្ជូនព្រឹត្តិការណ៍ CDC ទៅកាន់ប្រធានបទ Kafka។ ហើយនៅចុងបញ្ចប់ យើងនឹងនិយាយអំពីគ្រោងការណ៍ដំណើរការស្ទ្រីម Delta ដែលអ្នកអភិវឌ្ឍន៍កម្មវិធីអាចប្រើសម្រាប់ដំណើរការទិន្នន័យ និងតក្កវិជ្ជាពង្រឹង។

CDC (ផ្លាស់ប្តូរ-ទិន្នន័យ-ចាប់យក)

យើងបានបង្កើតសេវាកម្ម CDC ដែលហៅថា Delta-Connector ដែលអាចចាប់យកការផ្លាស់ប្តូរដែលបានប្តេជ្ញាចិត្តពីឃ្លាំងទិន្នន័យក្នុងពេលវេលាជាក់ស្តែង ហើយសរសេរពួកវាទៅស្ទ្រីម។ ការផ្លាស់ប្តូរតាមពេលវេលាជាក់ស្តែងត្រូវបានយកចេញពីកំណត់ហេតុប្រតិបត្តិការ និងកន្លែងចាក់សំរាម។ ការចាក់សំរាមត្រូវបានប្រើ ពីព្រោះកំណត់ហេតុប្រតិបត្តិការជាធម្មតាមិនរក្សាទុកប្រវត្តិនៃការផ្លាស់ប្តូរទាំងមូលទេ។ ការផ្លាស់ប្តូរជាធម្មតាត្រូវបានដាក់ជាស៊េរីជាព្រឹត្តិការណ៍ Delta ដូច្នេះអ្នកទទួលមិនចាំបាច់ព្រួយបារម្ភអំពីកន្លែងដែលការផ្លាស់ប្តូរនេះមកពីណានោះទេ។

Delta-Connector គាំទ្រមុខងារបន្ថែមមួយចំនួនដូចជា៖

• សមត្ថភាពក្នុងការសរសេរទិន្នន័យលទ្ធផលផ្ទាល់ខ្លួនឆ្លងកាត់ Kafka ។
• សមត្ថភាពក្នុងការធ្វើឱ្យការបោះចោលដោយដៃនៅពេលណាមួយសម្រាប់តារាងទាំងអស់ តារាងជាក់លាក់ ឬសម្រាប់សោចម្បងជាក់លាក់។
• ការចាក់សំរាមអាចយកមកវិញជាកំណាត់ ដូច្នេះមិនចាំបាច់ចាប់ផ្តើមម្តងទៀតទេ ក្នុងករណីបរាជ័យ។
• មិនចាំបាច់ដាក់សោនៅលើតុទេ ដែលមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការធានាថា ទិន្នន័យនៃការសរសេរចរាចរមិនត្រូវបានរារាំងដោយសេវាកម្មរបស់យើងឡើយ។
• ភាពអាចរកបានខ្ពស់ដោយសារតែករណីដែលលែងប្រើក្នុង AWS Availability Zones។

បច្ចុប្បន្នយើងគាំទ្រ MySQL និង Postgres រួមទាំងការដាក់ពង្រាយនៅលើ AWS RDS និង Aurora ។ យើងក៏គាំទ្រ Cassandra (ពហុមេ) ផងដែរ។ អ្នកអាចស្វែងយល់បន្ថែមអំពី Delta-Connector នៅទីនេះ ការប្រកាសកំណត់ហេតុបណ្ដាញ.

Kafka និងស្រទាប់ដឹកជញ្ជូន

ស្រទាប់ដឹកជញ្ជូនព្រឹត្តិការណ៍របស់ Delta ត្រូវបានបង្កើតឡើងនៅលើសេវាកម្មផ្ញើសាររបស់វេទិកា ក្រុមហ៊ុន Keystone.

ជាប្រវត្តិសាស្ត្រ ការបង្ហោះនៅលើ Netflix ត្រូវបានធ្វើឱ្យប្រសើរសម្រាប់ភាពងាយស្រួលជាជាងភាពជាប់បានយូរ (សូមមើលខាងក្រោម)។ អត្ថបទមុន) ការដោះដូរគឺជាភាពមិនស៊ីសង្វាក់គ្នានៃទិន្នន័យឈ្មួញកណ្តាលនៅក្នុងសេណារីយ៉ូគែមផ្សេងៗ។ ឧទាហរណ៍, ការបោះឆ្នោតមេដឹកនាំមិនស្អាត ទទួលខុសត្រូវចំពោះអ្នកទទួលដែលអាចមានព្រឹត្តិការណ៍ស្ទួន ឬបាត់បង់។

ជាមួយនឹងក្រុមហ៊ុន Delta យើងចង់បានការធានាដែលរឹងមាំជាងមុន ដើម្បីធានាបាននូវការចែកចាយព្រឹត្តិការណ៍ CDC ទៅកាន់ហាងដែលទទួលបាន។ ចំពោះគោលបំណងនេះ យើងបានស្នើរនូវចង្កោម Kafka ដែលបានរចនាយ៉ាងពិសេសជាវត្ថុថ្នាក់ដំបូង។ អ្នកអាចមើលការកំណត់ឈ្មួញកណ្តាលមួយចំនួននៅក្នុងតារាងខាងក្រោម៖

នៅក្នុងចង្កោម Keystone Kafka, ការបោះឆ្នោតមេដឹកនាំមិនស្អាត ជាធម្មតារួមបញ្ចូលដើម្បីធានាភាពងាយស្រួលរបស់អ្នកបោះពុម្ពផ្សាយ។ នេះអាចបណ្តាលឱ្យបាត់បង់សារ ប្រសិនបើការចម្លងដែលមិនសមកាលកម្មត្រូវបានជ្រើសរើសជាអ្នកដឹកនាំ។ សម្រាប់ចង្កោម Kafka ដែលអាចរកបានខ្ពស់ថ្មី ជម្រើស ការបោះឆ្នោតមេដឹកនាំមិនស្អាត បានបិទដើម្បីការពារការបាត់បង់សារ។

យើងក៏បានកើនឡើងផងដែរ។ កត្តាចម្លង ពី 2 ទៅ 3 និង ការចម្លង insync អប្បបរមា 1 ដល់ 2. អ្នកបោះពុម្ពផ្សាយដែលសរសេរទៅចង្កោមនេះទាមទារ acks ពីអ្នកផ្សេងទៀតទាំងអស់ ដោយធានាថា 2 ក្នុងចំណោម 3 ចម្លងមានសារបច្ចុប្បន្នច្រើនបំផុតដែលផ្ញើដោយអ្នកបោះពុម្ពផ្សាយ។

នៅពេលដែលឈ្មួញកណ្តាលបញ្ចប់ វត្ថុថ្មីជំនួសកន្លែងចាស់។ ទោះជាយ៉ាងណាក៏ដោយ ឈ្មួញកណ្តាលថ្មីនឹងត្រូវតាមទាន់ការចម្លងដែលមិនសមកាលកម្ម ដែលអាចចំណាយពេលច្រើនម៉ោង។ ដើម្បីកាត់បន្ថយពេលវេលានៃការស្តារឡើងវិញសម្រាប់សេណារីយ៉ូនេះ យើងបានចាប់ផ្តើមប្រើប្រាស់ការផ្ទុកទិន្នន័យប្លុក (Amazon Elastic Block Store) ជំនួសឱ្យថាសឈ្មួញកណ្តាលក្នុងស្រុក។ នៅពេលដែលវត្ថុថ្មីជំនួសឧទាហរណ៍ឈ្មួញកណ្តាលដែលបានបញ្ចប់ វាភ្ជាប់បរិមាណ EBS ដែលវត្ថុដែលបានបិទនោះមាន ហើយចាប់ផ្តើមទទួលសារថ្មី។ ដំណើរការនេះកាត់បន្ថយពេលវេលាបោសសំអាតការត្រឡប់មកវិញពីច្រើនម៉ោងទៅនាទី ពីព្រោះវត្ថុថ្មីមិនចាំបាច់ចម្លងពីស្ថានភាពទទេទៀតទេ។ សរុបមក ការផ្ទុកដាច់ដោយឡែក និងវដ្តជីវិតរបស់ឈ្មួញកណ្តាលកាត់បន្ថយផលប៉ះពាល់នៃការប្តូរឈ្មួញកណ្តាលយ៉ាងសំខាន់។

ដើម្បីបង្កើនការធានានៃការចែកចាយទិន្នន័យបន្ថែមទៀត យើងបានប្រើ ប្រព័ន្ធតាមដានសារ ដើម្បី​រក​ឃើញ​ការ​បាត់​បង់​សារ​ណា​មួយ​នៅ​ក្នុង​លក្ខខណ្ឌ​ធ្ងន់ធ្ងរ (ឧទាហរណ៍ ការ​ធ្វើ​សមកាលកម្ម​នាឡិកា​នៅ​ក្នុង​ប្រធាន​ភាគ)។

គ្រោងការណ៍ដំណើរការស្ទ្រីម

ស្រទាប់ដំណើរការរបស់ Delta ត្រូវបានបង្កើតឡើងនៅលើកំពូលនៃវេទិកា Netflix SPaaS ដែលផ្តល់នូវការរួមបញ្ចូល Apache Flink ជាមួយនឹងប្រព័ន្ធអេកូ Netflix ។ វេទិកានេះផ្តល់នូវចំណុចប្រទាក់អ្នកប្រើដែលគ្រប់គ្រងការដាក់ពង្រាយការងារ Flink និងការរៀបចំក្រុម Flink នៅលើកំពូលនៃវេទិកាគ្រប់គ្រងធុង Titus របស់យើង។ ចំណុចប្រទាក់ក៏គ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធការងារ និងអនុញ្ញាតឱ្យអ្នកប្រើធ្វើការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធដោយថាមវន្តដោយមិនចាំបាច់ចងក្រងការងារ Flink ឡើងវិញ។

Delta ផ្តល់នូវក្របខ័ណ្ឌដំណើរការស្ទ្រីមដោយផ្អែកលើ Flink និង SPaaS ដែលប្រើ ផ្អែកលើចំណារពន្យល់ DSL (Domain Specific Language) ទៅកាន់ព័ត៌មានលម្អិតបច្ចេកទេសអរូបី។ ឧទាហរណ៍ ដើម្បីកំណត់ជំហានដែលព្រឹត្តិការណ៍នឹងត្រូវបានពង្រឹងដោយការហៅទៅសេវាកម្មខាងក្រៅ អ្នកប្រើប្រាស់ត្រូវសរសេរ DSL ខាងក្រោម ហើយក្របខ័ណ្ឌនឹងបង្កើតគំរូដោយផ្អែកលើវា ដែលនឹងត្រូវបានប្រតិបត្តិដោយ Flink ។

រូបភាពទី 3. ឧទាហរណ៍នៃការពង្រឹងលើ DSL នៅក្នុង Delta

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

Delta Stream Processing Framework មានម៉ូឌុលសំខាន់ពីរគឺ ម៉ូឌុល DSL & API និងម៉ូឌុលពេលដំណើរការ។ ម៉ូឌុល DSL & API ផ្តល់ DSL និង UDF (User-Defined-Function) APIs ដូច្នេះអ្នកប្រើប្រាស់អាចសរសេរតក្កវិជ្ជាដំណើរការផ្ទាល់ខ្លួនរបស់ពួកគេ (ដូចជាការត្រង ឬការបំប្លែង)។ ម៉ូឌុល Runtime ផ្តល់នូវការអនុវត្តឧបករណ៍ញែក DSL ដែលបង្កើតតំណាងផ្ទៃក្នុងនៃជំហានដំណើរការនៅក្នុងគំរូ DAG ។ សមាសភាគប្រតិបត្តិបកស្រាយគំរូ DAG ដើម្បីចាប់ផ្តើមសេចក្តីថ្លែងការណ៍ Flink ពិតប្រាកដ ហើយចុងក្រោយដំណើរការកម្មវិធី Flink ។ ស្ថាបត្យកម្មនៃក្របខ័ណ្ឌត្រូវបានបង្ហាញក្នុងរូបខាងក្រោម។

រូបភាពទី 4. ស្ថាបត្យកម្មក្របខ័ណ្ឌដំណើរការ Delta Stream

វិធីសាស្រ្តនេះមានអត្ថប្រយោជន៍ជាច្រើន៖

• អ្នកប្រើប្រាស់អាចផ្តោតលើតក្កវិជ្ជាអាជីវកម្មរបស់ពួកគេដោយមិនចាំបាច់ស្វែងយល់ពីលក្ខណៈជាក់លាក់នៃ Flink ឬរចនាសម្ព័ន្ធ SPaaS ។
• ការបង្កើនប្រសិទ្ធភាពអាចត្រូវបានធ្វើតាមរបៀបដែលមានតម្លាភាពចំពោះអ្នកប្រើប្រាស់ ហើយកំហុសអាចត្រូវបានជួសជុលដោយមិនចាំបាច់មានការផ្លាស់ប្តូរណាមួយចំពោះកូដអ្នកប្រើប្រាស់ (UDF)។
• បទពិសោធន៍កម្មវិធី Delta ត្រូវបានធ្វើឱ្យសាមញ្ញសម្រាប់អ្នកប្រើប្រាស់ ដោយសារតែវេទិកានេះផ្តល់នូវភាពបត់បែន និងភាពធន់ចេញពីប្រអប់ ហើយប្រមូលនូវរង្វាស់លម្អិតជាច្រើនដែលអាចប្រើបានសម្រាប់ការជូនដំណឹង។

ការប្រើប្រាស់ផលិតកម្ម

Delta បានដំណើរការអស់រយៈពេលជាងមួយឆ្នាំហើយ និងដើរតួយ៉ាងសំខាន់នៅក្នុងកម្មវិធី Netflix Studio ជាច្រើន។ នាងបានជួយក្រុមអនុវត្តករណីប្រើប្រាស់ដូចជា ការបង្កើតលិបិក្រមស្វែងរក ការផ្ទុកទិន្នន័យ និងលំហូរការងារដែលជំរុញដោយព្រឹត្តិការណ៍។ ខាងក្រោមនេះគឺជាទិដ្ឋភាពទូទៅនៃស្ថាបត្យកម្មកម្រិតខ្ពស់នៃវេទិកា Delta ។

រូបភាពទី 5. ស្ថាបត្យកម្មកម្រិតខ្ពស់របស់ Delta ។

ការដឹងគុណ

យើងសូមថ្លែងអំណរគុណចំពោះមនុស្សដូចខាងក្រោមដែលបានចូលរួមនៅក្នុងការបង្កើត និងអភិវឌ្ឍន៍ Delta នៅ Netflix៖ Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang និង Zhenzhong Xu ។

ប្រភព។

1. dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
2. dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
3. Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: ដំណើរការព្រឹត្តិការណ៍តាមអ៊ីនធឺណិត។ កុម្មុយនិស្ត។ ACM 62(5): 43–49 (2019)។ DOI៖ doi.org/10.1145/3312527

ចុះឈ្មោះសម្រាប់ webinar ឥតគិតថ្លៃ៖ "ឧបករណ៍បង្កើតទិន្នន័យសម្រាប់ Amazon Redshift Storage ។"

ប្រភព: www.habr.com