របៀបដែលយើងរៀបចំ DataLake ដែលមានប្រសិទ្ធភាពខ្ពស់ និងមានតំលៃថោក ហើយហេតុអ្វីបានជាវាដូច្នេះ

យើងរស់នៅក្នុងពេលវេលាដ៏អស្ចារ្យមួយ នៅពេលដែលអ្នកអាចភ្ជាប់ឧបករណ៍ប្រភពបើកចំហជាច្រើនដែលត្រៀមរួចជាស្រេចបានយ៉ាងរហ័ស និងងាយស្រួល រៀបចំពួកវាដោយ "បិទការដឹងខ្លួន" របស់អ្នកតាមការណែនាំរបស់ stackoverflow ដោយមិនគិតពី "អក្សរច្រើន" និងចាប់ផ្តើម។ ពួកគេចូលទៅក្នុងប្រតិបត្តិការពាណិជ្ជកម្ម។ ហើយនៅពេលដែលអ្នកត្រូវការអាប់ដេត/ពង្រីក ឬនរណាម្នាក់បើកម៉ាស៊ីនពីរបីឡើងវិញដោយចៃដន្យ - អ្នកដឹងថាប្រភេទនៃសុបិនអាក្រក់ដែលស្រមើស្រមៃបានចាប់ផ្តើមហើយ អ្វីគ្រប់យ៉ាងបានក្លាយទៅជាភាពស្មុគស្មាញខ្លាំងហួសពីការទទួលស្គាល់ គ្មានការវិលត្រឡប់មកវិញ អនាគតគឺមិនច្បាស់លាស់ និងមានសុវត្ថិភាពជាង។ ជំនួសឱ្យការសរសេរកម្មវិធី បង្កាត់ឃ្មុំ និងធ្វើឈីស។

វាមិនមែនសម្រាប់មិត្តរួមការងារដែលមានបទពិសោធន៍ច្រើនជាងនោះទេ ដោយក្បាលរបស់ពួកគេប្រឡាក់ដោយកំហុស ហើយដូច្នេះពណ៌ប្រផេះរួចទៅហើយ ដោយគិតអំពីការដាក់ពង្រាយកញ្ចប់ "កុងតឺន័រ" យ៉ាងឆាប់រហ័សមិនគួរឱ្យជឿនៅក្នុង "គូប" នៅលើម៉ាស៊ីនមេរាប់សិបនៅក្នុង "ភាសាទាន់សម័យ" ជាមួយនឹងការគាំទ្រដែលភ្ជាប់មកជាមួយសម្រាប់ I/O ដែលមិនរារាំងអសមកាល ញញឹមដោយសុភាព។ ហើយពួកគេបន្តអាន "man ps" ឡើងវិញដោយស្ងៀមស្ងាត់ ស្វែងយល់ពីកូដប្រភព "nginx" រហូតដល់ភ្នែករបស់ពួកគេហូរឈាម ហើយសរសេរ សរសេរ សរសេរការធ្វើតេស្តឯកតា។ សហសេវិកដឹងថាអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនឹងមកនៅពេលដែល "អ្វីៗទាំងអស់នេះ" នៅថ្ងៃណាមួយត្រូវបានភ្នាល់នៅពេលយប់នៅថ្ងៃចូលឆ្នាំសកល។ ហើយពួកវានឹងត្រូវបានជួយដោយការយល់ដឹងយ៉ាងស៊ីជម្រៅអំពីធម្មជាតិនៃយូនីក តារាងស្ថានភាព TCP/IP ដែលទន្ទេញចាំ និងក្បួនដោះស្រាយការតម្រៀប-ស្វែងរកជាមូលដ្ឋាន។ ដើម្បីធ្វើឲ្យប្រព័ន្ធមានជីវិតឡើងវិញ នៅពេលដែលសំឡេងរោទិ៍។

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

មួយរយៈមុននេះ យើងបានយល់ដឹងថាក្រុមហ៊ុនកាន់តែច្រើនឡើងៗត្រូវការផលផ្លែទាំងផលិតផល និងការវិភាគបច្ចេកទេស (មិននិយាយពីការស្រុះលើនំខេកក្នុងទម្រង់នៃការរៀនម៉ាស៊ីន) និងដើម្បីយល់ពីនិន្នាការ និងហានិភ័យ - យើងត្រូវប្រមូល និងវិភាគ ម៉ែត្រកាន់តែច្រើនឡើង ៗ ។

ការវិភាគបច្ចេកទេសជាមូលដ្ឋាននៅក្នុង Bitrix24

កាលពីប៉ុន្មានឆ្នាំមុន ក្នុងពេលដំណាលគ្នាជាមួយនឹងការបើកដំណើរការសេវាកម្ម Bitrix24 យើងបានវិនិយោគពេលវេលា និងធនធានយ៉ាងសកម្មក្នុងការបង្កើតវេទិកាវិភាគដ៏សាមញ្ញ និងអាចទុកចិត្តបាន ដែលនឹងជួយមើលឃើញបញ្ហាក្នុងហេដ្ឋារចនាសម្ព័ន្ធយ៉ាងឆាប់រហ័ស និងរៀបចំផែនការជំហានបន្ទាប់។ ជាការពិតណាស់ គួរតែយកឧបករណ៍ដែលត្រៀមរួចជាស្រេច ដែលមានលក្ខណៈសាមញ្ញ និងអាចយល់បានតាមដែលអាចធ្វើទៅបាន។ ជាលទ្ធផល nagios ត្រូវបានជ្រើសរើសសម្រាប់ការត្រួតពិនិត្យ និង munin សម្រាប់ការវិភាគ និងការមើលឃើញ។ ឥឡូវនេះយើងមានការត្រួតពិនិត្យរាប់ពាន់នៅក្នុង nagios តារាងរាប់រយនៅក្នុង munin ហើយសហការីរបស់យើងប្រើប្រាស់វាដោយជោគជ័យជារៀងរាល់ថ្ងៃ។ រង្វាស់គឺច្បាស់លាស់ ក្រាហ្វិកច្បាស់លាស់ ប្រព័ន្ធបានដំណើរការដោយភាពជឿជាក់ជាច្រើនឆ្នាំ ហើយការធ្វើតេស្ត និងក្រាហ្វិចថ្មីត្រូវបានបន្ថែមជាទៀងទាត់ទៅវា៖ នៅពេលយើងដាក់សេវាកម្មថ្មីឱ្យដំណើរការ យើងបន្ថែមការធ្វើតេស្ត និងក្រាហ្វជាច្រើន។ សំណាងល្អ។

ម្រាមដៃនៅលើជីពចរ - ការវិភាគបច្ចេកទេសកម្រិតខ្ពស់

បំណងប្រាថ្នាដើម្បីទទួលបានព័ត៌មានអំពីបញ្ហា "ឱ្យបានលឿនតាមដែលអាចធ្វើបាន" បាននាំយើងទៅរកការពិសោធន៍សកម្មជាមួយនឹងឧបករណ៍សាមញ្ញ និងអាចយល់បាន - pinba និង xhprof ។

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

មួយរយៈមុន កញ្ចប់ឧបករណ៍ត្រូវបានបំពេញបន្ថែមជាមួយនឹងម៉ាស៊ីនដ៏សាមញ្ញ និងអាចយល់បានមួយផ្សេងទៀតដោយផ្អែកលើក្បួនដោះស្រាយការដាក់លិបិក្រមបញ្ច្រាស ដែលត្រូវបានអនុវត្តយ៉ាងល្អឥតខ្ចោះនៅក្នុងបណ្ណាល័យ Lucene រឿងព្រេងនិទាន - Elastic/Kibana ។ គំនិតសាមញ្ញនៃការកត់ត្រាឯកសារច្រើនខ្សែទៅក្នុងលិបិក្រម Lucene បញ្ច្រាសដោយផ្អែកលើព្រឹត្តិការណ៍នៅក្នុងកំណត់ហេតុ និងការស្វែងរករហ័សតាមរយៈពួកវាដោយប្រើការបែងចែក facet ប្រែទៅជាមានប្រយោជន៍។

ទោះបីជាមានរូបរាងបែបបច្ចេកទេសនៃការមើលឃើញនៅក្នុង Kibana ជាមួយនឹងគោលគំនិតកម្រិតទាបដូចជា "ដាក់ធុង" "ហូរឡើង" និងភាសាដែលបានបង្កើតឡើងវិញនៃពិជគណិតទំនាក់ទំនងដែលមិនទាន់ត្រូវបានបំភ្លេចចោលទាំងស្រុងក៏ដោយ ឧបករណ៍បានចាប់ផ្តើមជួយយើងបានយ៉ាងល្អក្នុងកិច្ចការខាងក្រោម៖

• តើមានកំហុស PHP ប៉ុន្មានដែលម៉ាស៊ីនភ្ញៀវ Bitrix24 មាននៅលើវិបផតថល p1 ក្នុងម៉ោងចុងក្រោយ ហើយមួយណា? យល់ អត់ទោស និងកែតម្រូវឱ្យបានឆាប់។
• តើការហៅជាវីដេអូចំនួនប៉ុន្មានត្រូវបានធ្វើឡើងនៅលើវិបផតថលក្នុងប្រទេសអាឡឺម៉ង់ក្នុងរយៈពេល 24 ម៉ោងមុន ជាមួយនឹងគុណភាពអ្វី ហើយតើមានការពិបាកជាមួយឆានែល/បណ្តាញដែរឬទេ?
• តើមុខងាររបស់ប្រព័ន្ធ (ផ្នែកបន្ថែម C របស់យើងសម្រាប់ PHP) ដែលចងក្រងពីប្រភពនៅក្នុងការអាប់ដេតសេវាកម្មចុងក្រោយបំផុត និងដាក់ឱ្យប្រើប្រាស់សម្រាប់អតិថិជន តើដំណើរការបានល្អប៉ុណ្ណា? តើមានកំហុសទេ?
• តើទិន្នន័យអតិថិជនសមនឹងអង្គចងចាំ PHP ទេ? តើមានកំហុសណាមួយអំពីការលើសអង្គចងចាំដែលត្រូវបានបម្រុងទុកសម្រាប់ដំណើរការ៖ "អស់សតិ" ទេ? ស្វែងរកនិងបន្សាប។

នេះជាឧទាហរណ៍ជាក់ស្តែង។ ទោះបីជាមានការសាកល្បងហ្មត់ចត់ និងច្រើនកម្រិតក៏ដោយ អតិថិជនដែលមានករណីមិនស្តង់ដារ និងទិន្នន័យបញ្ចូលដែលខូច បានទទួលនូវកំហុសដែលរំខាន និងមិននឹកស្មានដល់ សំឡេងស៊ីរ៉ែនបានបន្លឺឡើង ហើយដំណើរការនៃការជួសជុលវាយ៉ាងឆាប់រហ័សបានចាប់ផ្តើម៖

លើសពីនេះទៀត kibana អនុញ្ញាតឱ្យអ្នករៀបចំការជូនដំណឹងសម្រាប់ព្រឹត្តិការណ៍ដែលបានបញ្ជាក់ហើយក្នុងរយៈពេលដ៏ខ្លីឧបករណ៍នៅក្នុងក្រុមហ៊ុនបានចាប់ផ្តើមប្រើប្រាស់ដោយបុគ្គលិករាប់សិបនាក់មកពីនាយកដ្ឋានផ្សេងៗគ្នា - ពីជំនួយបច្ចេកទេសនិងការអភិវឌ្ឍន៍ទៅ QA ។

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

ការវិភាគអាជីវកម្មមូលដ្ឋាន

មនុស្សគ្រប់គ្នាដឹងថាការវិភាគអាជីវកម្មនៅក្នុងក្រុមហ៊ុនជារឿយៗចាប់ផ្តើមជាមួយនឹងការប្រើប្រាស់យ៉ាងសកម្មបំផុតនៃ បាទ Excel ។ ប៉ុន្តែរឿងសំខាន់គឺថាវាមិនបញ្ចប់នៅទីនោះទេ។ Google Analytics ដែលមានមូលដ្ឋានលើពពកក៏បន្ថែមឥន្ធនៈដល់ភ្លើងផងដែរ - អ្នកចាប់ផ្តើមស៊ាំនឹងរបស់ល្អយ៉ាងឆាប់រហ័ស។

នៅក្នុងក្រុមហ៊ុនដែលកំពុងអភិវឌ្ឍប្រកបដោយភាពសុខដុមរមនារបស់យើង នៅទីនេះ និងទីនោះ "ហោរា" នៃការងារដែលពឹងផ្អែកខ្លាំងជាមួយនឹងទិន្នន័យធំជាងបានចាប់ផ្តើមលេចឡើង។ តម្រូវការសម្រាប់របាយការណ៍ស៊ីជម្រៅ និងពហុភាគី បានចាប់ផ្តើមលេចឡើងជាទៀងទាត់ ហើយតាមរយៈការខិតខំប្រឹងប្រែងរបស់បុរសមកពីនាយកដ្ឋានផ្សេងៗគ្នា មួយរយៈមុនដំណោះស្រាយដ៏សាមញ្ញ និងជាក់ស្តែងត្រូវបានរៀបចំឡើង - ការរួមបញ្ចូលគ្នានៃ ClickHouse និង PowerBI ។

អស់រយៈពេលជាយូរណាស់មកហើយ ដំណោះស្រាយដែលអាចបត់បែនបាននេះបានជួយច្រើន ប៉ុន្តែបន្តិចម្តងៗ ការយល់ដឹងបានចាប់ផ្តើមមកថា ClickHouse មិនមែនជាកៅស៊ូ ហើយមិនអាចត្រូវបានគេចំអកដូចនោះទេ។

នៅទីនេះវាសំខាន់ណាស់ក្នុងការយល់ច្បាស់ថា ClickHouse ដូចជា Druid ដូចជា Vertica ដូចជា Amazon RedShift (ដែលផ្អែកលើ postgres) គឺជាម៉ាស៊ីនវិភាគដែលត្រូវបានកែលម្អសម្រាប់ការវិភាគដែលងាយស្រួលដោយស្មើភាព (ផលបូក ការប្រមូលផ្តុំ អប្បបរមា-អតិបរមាដោយជួរឈរ និងការចូលរួមដែលអាចធ្វើបានមួយចំនួន។ ), ដោយសារតែ រៀបចំសម្រាប់ការផ្ទុកជួរឈរនៃតារាងទំនាក់ទំនងប្រកបដោយប្រសិទ្ធភាព មិនដូច MySQL និងមូលដ្ឋានទិន្នន័យផ្សេងទៀត (តម្រង់ជួរ) ដែលស្គាល់យើង។

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

តម្រូវការ python និងអ្នកវិភាគ

ក្រុមហ៊ុនរបស់យើងមានអ្នកអភិវឌ្ឍន៍ជាច្រើនដែលសរសេរកូដស្ទើរតែរាល់ថ្ងៃក្នុងរយៈពេល 10-20 ឆ្នាំនៅក្នុង PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash ។ វាក៏មានអ្នកគ្រប់គ្រងប្រព័ន្ធដែលមានបទពិសោធន៍ជាច្រើនដែលបានជួបប្រទះគ្រោះមហន្តរាយមិនគួរឱ្យជឿច្រើនជាងមួយដែលមិនសមស្របនឹងច្បាប់នៃស្ថិតិ (ឧទាហរណ៍ នៅពេលដែលថាសភាគច្រើននៅក្នុងការវាយឆ្មក់-10 ត្រូវបានបំផ្លាញដោយការវាយប្រហារដោយរន្ទះខ្លាំង)។ ក្នុងកាលៈទេសៈបែបនេះ អស់រយៈពេលជាយូរមកហើយ វាមិនច្បាស់ថា "អ្នកវិភាគពស់ថ្លាន់" ជាអ្វីនោះទេ។ Python គឺដូចជា PHP ដែរ មានតែឈ្មោះវែងជាងនេះបន្តិច ហើយមានដានតិចតួចនៃសារធាតុដែលផ្លាស់ប្តូរចិត្តនៅក្នុងកូដប្រភពរបស់អ្នកបកប្រែ។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលដែលរបាយការណ៍វិភាគកាន់តែច្រើនត្រូវបានបង្កើតឡើង អ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍បានចាប់ផ្តើមយល់កាន់តែច្បាស់អំពីសារៈសំខាន់នៃឯកទេសតូចចង្អៀតនៅក្នុងឧបករណ៍ដូចជា numpy, pandas, matplotlib, seaborn ។
តួនាទីដែលសម្រេចបាន ភាគច្រើនទំនងជាត្រូវបានលេងដោយការដួលសន្លប់ភ្លាមៗរបស់និយោជិតពីការរួមបញ្ចូលគ្នានៃពាក្យ "តំរែតំរង់ផ្នែកដឹកជញ្ជូន" និងការបង្ហាញពីការរាយការណ៍ប្រកបដោយប្រសិទ្ធភាពលើទិន្នន័យធំដោយប្រើ បាទ បាទ pyspark ។

Apache Spark ដែលជាគំរូមុខងាររបស់វាដែលពិជគណិតទំនាក់ទំនងសមឥតខ្ចោះ ហើយសមត្ថភាពរបស់វាបានធ្វើឱ្យមានការចាប់អារម្មណ៍ចំពោះអ្នកអភិវឌ្ឍន៍ដែលធ្លាប់ប្រើ MySQL ដែលតម្រូវការក្នុងការពង្រឹងចំណាត់ថ្នាក់ជាមួយអ្នកវិភាគដែលមានបទពិសោធន៍កាន់តែច្បាស់ដូចថ្ងៃ។

ការព្យាយាមបន្ថែមទៀតរបស់ Apache Spark/Hadoop ដើម្បីដកចេញ ហើយអ្វីដែលមិនដំណើរការទៅតាមស្គ្រីប

ទោះជាយ៉ាងណាក៏ដោយ ភ្លាមៗនោះ វាច្បាស់ណាស់ថា អ្វីមួយមិនត្រឹមត្រូវជាប្រព័ន្ធជាមួយ Spark ឬវាគ្រាន់តែជាការចាំបាច់ក្នុងការលាងដៃរបស់អ្នកឱ្យបានប្រសើរជាងមុន។ ប្រសិនបើជង់ Hadoop/MapReduce/Lucene ត្រូវបានធ្វើឡើងដោយអ្នកសរសេរកម្មវិធីដែលមានបទពិសោធន៍ត្រឹមត្រូវ ដែលជាក់ស្តែងប្រសិនបើអ្នកក្រឡេកមើលយ៉ាងដិតដល់នូវប្រភពកូដនៅក្នុង Java ឬគំនិតរបស់ Doug Cutting នៅក្នុង Lucene នោះ Spark ស្រាប់តែត្រូវបានសរសេរជាភាសាកម្រនិងអសកម្ម Scala ដែលជា មានភាពចម្រូងចម្រាសយ៉ាងខ្លាំងពីទស្សនៈនៃការអនុវត្តជាក់ស្តែង ហើយបច្ចុប្បន្នមិនមានការអភិវឌ្ឍន៍ទេ។ ហើយការធ្លាក់ចុះនៃការគណនាជាប្រចាំនៅលើចង្កោម Spark ដោយសារតែការងារមិនសមហេតុផល និងមិនមានតម្លាភាពជាមួយនឹងការបែងចែកអង្គចងចាំសម្រាប់កាត់បន្ថយប្រតិបត្តិការ (សោជាច្រើនមកដល់ក្នុងពេលតែមួយ) បានបង្កើត halo ជុំវិញវានៃអ្វីមួយដែលមានកន្លែងសម្រាប់រីកចម្រើន។ លើសពីនេះ ស្ថានការណ៍កាន់តែធ្ងន់ធ្ងរឡើងដោយច្រកបើកចំឡែកមួយចំនួនធំ ឯកសារបណ្ដោះអាសន្នដែលដុះនៅកន្លែងដែលមិនអាចយល់បានបំផុត និងឋាននរកនៃភាពអាស្រ័យ - ដែលបណ្តាលឱ្យអ្នកគ្រប់គ្រងប្រព័ន្ធមានអារម្មណ៍មួយដែលត្រូវបានគេស្គាល់តាំងពីកុមារភាព៖ ការស្អប់យ៉ាងខ្លាំងក្លា (ឬប្រហែលជា ពួកគេត្រូវលាងដៃជាមួយសាប៊ូ)។

ជាលទ្ធផល យើងបាន "រស់រានមានជីវិត" នូវគម្រោងវិភាគផ្ទៃក្នុងជាច្រើន ដែលប្រើប្រាស់យ៉ាងសកម្ម Apache Spark (រួមទាំង Spark Streaming, Spark SQL) និងប្រព័ន្ធអេកូឡូស៊ី Hadoop (ហើយដូច្នេះនៅលើជាដើម)។ ទោះបីជាការពិតដែលថាយូរ ៗ ទៅយើងបានរៀនរៀបចំនិងតាមដាន "វា" យ៉ាងល្អហើយ "វា" ស្ទើរតែឈប់គាំងភ្លាមៗដោយសារតែការផ្លាស់ប្តូរនៃធម្មជាតិនៃទិន្នន័យនិងភាពមិនស្មើគ្នានៃការបែងចែក RDD ឯកសណ្ឋានបំណងប្រាថ្នាចង់យកអ្វីមួយដែលរួចរាល់។ បានធ្វើបច្ចុប្បន្នភាព និងគ្រប់គ្រងកន្លែងណាមួយក្នុងពពកកាន់តែរឹងមាំ និងកាន់តែខ្លាំង។ វាគឺនៅពេលនេះដែលយើងព្យាយាមប្រើការផ្គុំពពកដែលត្រៀមរួចជាស្រេចនៃសេវាកម្មគេហទំព័រ Amazon - EMR ហើយជាបន្តបន្ទាប់ ព្យាយាមដោះស្រាយបញ្ហាដោយប្រើវា។ EMR គឺជាកម្មវិធី Apache Spark ដែលរៀបចំដោយ Amazon ជាមួយនឹងកម្មវិធីបន្ថែមពីប្រព័ន្ធអេកូឡូស៊ី ដូចជា Cloudera/Hortonworks builds។

ការផ្ទុកឯកសារកៅស៊ូសម្រាប់ការវិភាគគឺជាតម្រូវការបន្ទាន់

បទពិសោធន៍នៃការ "ធ្វើម្ហូប" Hadoop/Spark ជាមួយនឹងការរលាកដល់ផ្នែកផ្សេងៗនៃរាងកាយគឺមិនឥតប្រយោជន៍ទេ។ តម្រូវការក្នុងការបង្កើតកន្លែងផ្ទុកឯកសារតែមួយ តម្លៃថោក និងអាចទុកចិត្តបាន ដែលអាចធន់នឹងការបរាជ័យផ្នែករឹង ហើយវាអាចផ្ទុកឯកសារក្នុងទម្រង់ផ្សេងៗគ្នាពីប្រព័ន្ធផ្សេងៗ និងបង្កើតគំរូប្រកបដោយប្រសិទ្ធភាព និងពេលវេលាសម្រាប់របាយការណ៍ពីទិន្នន័យនេះកាន់តែខ្លាំងឡើង។ ច្បាស់។

ខ្ញុំក៏ចង់បានដែរថា ការអាប់ដេតកម្មវិធីនៃវេទិកានេះមិនប្រែទៅជាសុបិន្តអាក្រក់ឆ្នាំថ្មីជាមួយនឹងការអានដាន Java 20 ទំព័រ និងការវិភាគកំណត់ហេតុលម្អិតនៃចង្កោមដែលមានប្រវែងរាប់គីឡូម៉ែត្រដោយប្រើ Spark History Server និងកែវពង្រីកខាងក្រោយ។ ខ្ញុំចង់មានឧបករណ៍សាមញ្ញ និងតម្លាភាពដែលមិនត្រូវការការជ្រមុជទឹកជាប្រចាំនៅក្រោមក្រណាត់ ប្រសិនបើសំណើស្តង់ដារ MapReduce របស់អ្នកអភិវឌ្ឍន៍បានបញ្ឈប់ការប្រតិបត្តិ នៅពេលដែលបុគ្គលិកកាត់បន្ថយទិន្នន័យធ្លាក់ចេញពីសតិ ដោយសារក្បួនដោះស្រាយការបែងចែកទិន្នន័យប្រភពមិនបានជ្រើសរើសយ៉ាងល្អ។

តើ Amazon S3 ជាបេក្ខជនសម្រាប់ DataLake ដែរឬទេ?

បទពិសោធន៍ជាមួយ Hadoop/MapReduce បានបង្រៀនយើងថា យើងត្រូវការប្រព័ន្ធឯកសារដែលអាចធ្វើមាត្រដ្ឋានបាន ដែលអាចទុកចិត្តបាន និងបុគ្គលិកដែលអាចធ្វើមាត្រដ្ឋានបាននៅលើវា "ចូលមក" កាន់តែជិតទិន្នន័យ ដើម្បីកុំឱ្យជំរុញទិន្នន័យនៅលើបណ្តាញ។ កម្មករគួរតែអាចអានទិន្នន័យក្នុងទម្រង់ផ្សេងៗគ្នា ប៉ុន្តែគួរតែកុំអានព័ត៌មានដែលមិនចាំបាច់ និងអាចរក្សាទុកទិន្នន័យជាមុនជាទម្រង់ដែលងាយស្រួលសម្រាប់កម្មករ។

ជាថ្មីម្តងទៀតគំនិតជាមូលដ្ឋាន។ មិនមានបំណងប្រាថ្នាដើម្បី "ចាក់" ទិន្នន័យធំចូលទៅក្នុងម៉ាស៊ីនវិភាគចង្កោមតែមួយទេ ដែលនឹងឆាប់ឬក្រោយមកច្របូកច្របល់ ហើយអ្នកនឹងត្រូវបំបែកវាយ៉ាងអាក្រក់។ ខ្ញុំចង់រក្សាទុកឯកសារ គ្រាន់តែជាឯកសារក្នុងទម្រង់ដែលអាចយល់បាន និងអនុវត្តសំណួរវិភាគប្រកបដោយប្រសិទ្ធភាពលើពួកវាដោយប្រើឧបករណ៍ផ្សេងៗ ប៉ុន្តែអាចយល់បាន។ ហើយវានឹងមានឯកសារកាន់តែច្រើនឡើងៗក្នុងទម្រង់ផ្សេងៗគ្នា។ ហើយវាជាការប្រសើរក្នុងការ shard មិនមែនម៉ាស៊ីន, ប៉ុន្តែទិន្នន័យប្រភព។ យើងត្រូវការ DataLake ដែលអាចពង្រីកបាន និងជាសកល យើងបានសម្រេចចិត្ត...

ចុះបើអ្នករក្សាទុកឯកសារនៅក្នុងឃ្លាំងផ្ទុកពពកដែលអាចធ្វើមាត្រដ្ឋានបាន និងល្បីឈ្មោះ Amazon S3 ដោយមិនចាំបាច់រៀបចំកំណាត់ផ្ទាល់ខ្លួនរបស់អ្នកពី Hadoop?

វាច្បាស់ណាស់ថាទិន្នន័យផ្ទាល់ខ្លួនគឺ "ទាប" ប៉ុន្តែចុះយ៉ាងណាចំពោះទិន្នន័យផ្សេងទៀតប្រសិនបើយើងយកវាចេញពីទីនោះ ហើយ "ជំរុញវាឱ្យមានប្រសិទ្ធភាព"?

Cluster-bigdata-analytics ecosystem នៃ Amazon Web Services - ជាពាក្យសាមញ្ញបំផុត។

ដោយវិនិច្ឆ័យតាមបទពិសោធន៍របស់យើងជាមួយ AWS Apache Hadoop/MapReduce ត្រូវបានប្រើប្រាស់យ៉ាងសកម្មនៅទីនោះអស់រយៈពេលជាយូរក្រោមទឹកជ្រលក់ផ្សេងៗ ឧទាហរណ៍នៅក្នុងសេវាកម្ម DataPipeline (ខ្ញុំច្រណែននឹងសហការីរបស់ខ្ញុំ ពួកគេបានរៀនពីរបៀបរៀបចំវាឱ្យបានត្រឹមត្រូវ)។ នៅទីនេះយើងរៀបចំការបម្រុងទុកពីសេវាកម្មផ្សេងៗពីតារាង DynamoDB៖


ហើយពួកគេបានដំណើរការជាទៀងទាត់នៅលើចង្កោម Hadoop/MapReduce ដែលបានបង្កប់ដូចជាការងារនាឡិកាអស់រយៈពេលជាច្រើនឆ្នាំឥឡូវនេះ។ "កំណត់វាហើយបំភ្លេចវា":

អ្នកក៏អាចចូលរួមយ៉ាងមានប្រសិទ្ធភាពនៅក្នុងលទ្ធិសាតាំងទិន្នន័យដោយដំឡើងកុំព្យូទ័រយួរដៃ Jupiter នៅក្នុងពពកសម្រាប់អ្នកវិភាគ និងប្រើប្រាស់សេវាកម្ម AWS SageMaker ដើម្បីបណ្តុះបណ្តាល និងដាក់ពង្រាយម៉ូដែល AI ចូលទៅក្នុងសមរភូមិ។ នេះជាអ្វីដែលវាមើលទៅសម្រាប់យើង៖

បាទ/ចាស អ្នកអាចយកកុំព្យូទ័រយួរដៃសម្រាប់ខ្លួនអ្នក ឬអ្នកវិភាគក្នុងពពក ហើយភ្ជាប់វាទៅចង្កោម Hadoop/Spark ធ្វើការគណនា ហើយបន្ទាប់មកដាក់អ្វីៗគ្រប់យ៉ាងចុះក្រោម៖

ពិតជាងាយស្រួលសម្រាប់គម្រោងវិភាគបុគ្គល ហើយសម្រាប់អ្នកខ្លះ យើងបានប្រើប្រាស់សេវាកម្ម EMR ដោយជោគជ័យសម្រាប់ការគណនា និងវិភាគខ្នាតធំ។ ចុះដំណោះស្រាយប្រព័ន្ធសម្រាប់ DataLake តើវានឹងដំណើរការដែរឬទេ? នៅពេលនេះ ពួកយើងស្ថិតនៅជិតអស់សង្ឃឹម និងអស់សង្ឃឹម ហើយបន្តការស្វែងរក។

AWS Glue - កញ្ចប់ Apache Spark យ៉ាងស្អាតនៅលើស្តេរ៉ូអ៊ីត

វាបានប្រែក្លាយថា AWS មានកំណែផ្ទាល់ខ្លួននៃជង់ "Hive/Pig/Spark" ។ តួនាទីរបស់ Hive, i.e. កាតាឡុកឯកសារ និងប្រភេទរបស់វានៅក្នុង DataLake ត្រូវបានអនុវត្តដោយសេវាកម្ម "កាតាឡុកទិន្នន័យ" ដែលមិនលាក់ភាពឆបគ្នារបស់វាជាមួយទម្រង់ Apache Hive ទេ។ អ្នកត្រូវបន្ថែមព័ត៌មានទៅសេវាកម្មនេះអំពីកន្លែងដែលឯកសាររបស់អ្នកស្ថិតនៅ និងក្នុងទម្រង់បែបណា។ ទិន្នន័យអាចមិនត្រឹមតែនៅក្នុង s3 ប៉ុណ្ណោះទេប៉ុន្តែក៏មាននៅក្នុងមូលដ្ឋានទិន្នន័យផងដែរ ប៉ុន្តែនោះមិនមែនជាប្រធានបទនៃការប្រកាសនេះទេ។ នេះជារបៀបដែលថតទិន្នន័យ DataLake របស់យើងត្រូវបានរៀបចំ៖

ឯកសារត្រូវបានចុះឈ្មោះ ល្អណាស់។ ប្រសិនបើឯកសារត្រូវបានអាប់ដេត យើងបើកដំណើរការកម្មវិធី crawlers ដោយដៃ ឬតាមកាលវិភាគ ដែលនឹងធ្វើបច្ចុប្បន្នភាពព័ត៌មានអំពីពួកវាពីបឹង និងរក្សាទុកវា។ បន្ទាប់មកទិន្នន័យពីបឹងអាចត្រូវបានដំណើរការ ហើយលទ្ធផលដែលបានបង្ហោះនៅកន្លែងណាមួយ។ ក្នុងករណីសាមញ្ញបំផុត យើងក៏អាប់ឡូតទៅ s3 ផងដែរ។ ដំណើរការទិន្នន័យអាចត្រូវបានធ្វើគ្រប់ទីកន្លែង ប៉ុន្តែវាត្រូវបានស្នើឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធដំណើរការនៅលើក្រុម Apache Spark ដោយប្រើសមត្ថភាពកម្រិតខ្ពស់តាមរយៈ AWS Glue API ។ តាមពិតទៅ អ្នកអាចយកកូដ python ចាស់ និងធ្លាប់ស្គាល់ដោយប្រើបណ្ណាល័យ pyspark ហើយកំណត់រចនាសម្ព័ន្ធការប្រតិបត្តិរបស់វានៅលើ N nodes នៃ cluster នៃសមត្ថភាពមួយចំនួនជាមួយនឹងការត្រួតពិនិត្យ ដោយមិនចាំបាច់ជីកចូលទៅក្នុងប្រហោងរបស់ Hadoop និងអូសធុង docker-moker និងលុបបំបាត់ជម្លោះអាស្រ័យ .

ជាថ្មីម្តងទៀតគំនិតសាមញ្ញ។ មិនចាំបាច់កំណត់រចនាសម្ព័ន្ធ Apache Spark ទេ អ្នកគ្រាន់តែត្រូវសរសេរកូដ python សម្រាប់ pyspark សាកល្បងវានៅលើកុំព្យូទ័ររបស់អ្នក ហើយបន្ទាប់មកដំណើរការវានៅលើចង្កោមធំក្នុងពពក ដោយបញ្ជាក់កន្លែងដែលទិន្នន័យប្រភព និងកន្លែងដែលត្រូវដាក់លទ្ធផល។ ពេលខ្លះវាចាំបាច់ និងមានប្រយោជន៍ ហើយនេះជារបៀបដែលយើងរៀបចំវា៖

ដូច្នេះ ប្រសិនបើអ្នកត្រូវការគណនាអ្វីមួយនៅលើ Spark cluster ដោយប្រើទិន្នន័យក្នុង s3 យើងសរសេរកូដនៅក្នុង python/pyspark សាកល្បងវា ហើយសំណាងល្អទៅ cloud ។

ចុះការប្រគុំតន្រ្តីវិញ? ចុះ​បើ​កិច្ចការ​ធ្លាក់​ហើយ​បាត់​ទៅ​វិញ? បាទ / ចាស វាត្រូវបានស្នើឡើងដើម្បីបង្កើតបំពង់បង្ហូរប្រេងដ៏ស្រស់ស្អាតនៅក្នុងរចនាប័ទ្ម Apache Pig ហើយយើងថែមទាំងបានសាកល្បងពួកវាផងដែរ ប៉ុន្តែសម្រាប់ពេលនេះ យើងបានសម្រេចចិត្តប្រើការ orchestration ផ្ទាល់ខ្លួនយ៉ាងជ្រាលជ្រៅរបស់យើងនៅក្នុង PHP និង JavaScript (ខ្ញុំយល់ថាមានភាពមិនស៊ីសង្វាក់គ្នានៃការយល់ដឹងប៉ុន្តែវាដំណើរការសម្រាប់ ឆ្នាំនិងដោយគ្មានកំហុស) ។

ទម្រង់ឯកសារដែលរក្សាទុកក្នុងបឹងគឺជាគន្លឹះនៃដំណើរការ

វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការស្វែងយល់ពីចំណុចសំខាន់ពីរបន្ថែមទៀត។ ដើម្បីឱ្យសំណួរលើទិន្នន័យឯកសារនៅក្នុងបឹងត្រូវបានប្រតិបត្តិឱ្យបានលឿនតាមដែលអាចធ្វើបាន និងការអនុវត្តមិនធ្វើឱ្យខូចទ្រង់ទ្រាយនៅពេលព័ត៌មានថ្មីត្រូវបានបន្ថែម អ្នកត្រូវ៖

• រក្សាទុកជួរឈរនៃឯកសារដោយឡែកពីគ្នា (ដូច្នេះអ្នកមិនចាំបាច់អានបន្ទាត់ទាំងអស់ដើម្បីយល់ពីអ្វីដែលមាននៅក្នុងជួរឈរ) ។ សម្រាប់ការនេះយើងបានយកទម្រង់ parquet ជាមួយនឹងការបង្ហាប់
• វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការបំបែកឯកសារទៅក្នុងថតដូចជា៖ ភាសា ឆ្នាំ ខែ ថ្ងៃ សប្តាហ៍។ ម៉ាស៊ីនដែលយល់ពីប្រភេទនៃការ sharding នេះនឹងមើលតែ folders ចាំបាច់ប៉ុណ្ណោះ ដោយមិនចាំបាច់រុះរើទិន្នន័យទាំងអស់ក្នុងមួយជួរ។

ជាសំខាន់ តាមវិធីនេះ អ្នកដាក់ចេញទិន្នន័យប្រភពក្នុងទម្រង់ដ៏មានប្រសិទ្ធភាពបំផុតសម្រាប់ម៉ាស៊ីនវិភាគដែលព្យួរនៅខាងលើ ដែលសូម្បីតែនៅក្នុងថតដែលបានបំបែកអាចជ្រើសរើសបញ្ចូល និងអានតែជួរឈរចាំបាច់ពីឯកសារប៉ុណ្ណោះ។ អ្នកមិនចាំបាច់ "បំពេញ" ទិន្នន័យគ្រប់ទីកន្លែងទេ (ការផ្ទុកនឹងផ្ទុះឡើង) - គ្រាន់តែដាក់វាដោយឆ្លាតវៃភ្លាមៗនៅក្នុងប្រព័ន្ធឯកសារក្នុងទម្រង់ត្រឹមត្រូវ។ ជាការពិតណាស់ វាគួរតែច្បាស់នៅទីនេះថា ការរក្សាទុកឯកសារ csv ដ៏ធំមួយនៅក្នុង DataLake ដែលដំបូងត្រូវតែអានតាមបន្ទាត់ដោយចង្កោម ដើម្បីទាញយកជួរឈរនោះ មិនត្រូវបានណែនាំទេ។ គិតអំពីចំណុចទាំងពីរខាងលើម្តងទៀតប្រសិនបើវាមិនទាន់ច្បាស់ថាហេតុអ្វីបានជារឿងទាំងអស់នេះកើតឡើង។

AWS Athena - jack-in-the-box

ហើយបន្ទាប់មក ខណៈពេលកំពុងបង្កើតបឹងមួយ យើងបានឆ្លងកាត់ Amazon Athena ដោយចៃដន្យ។ ភ្លាមៗនោះវាបានប្រែក្លាយថាដោយរៀបចំយ៉ាងប្រុងប្រយ័ត្ននូវឯកសារកំណត់ហេតុដ៏ធំរបស់យើងទៅក្នុង folder shards ក្នុងទម្រង់ជួរឈរត្រឹមត្រូវ (parquet) អ្នកអាចធ្វើការជ្រើសរើសព័ត៌មានយ៉ាងរហ័សពីពួកវា និងបង្កើតរបាយការណ៍ដោយគ្មាន ដោយគ្មាន Apache Spark/Glue cluster ។

ម៉ាស៊ីន Athena ដំណើរការដោយទិន្នន័យនៅក្នុង s3 គឺផ្អែកលើរឿងព្រេងនិទាន Presto - អ្នកតំណាងនៃគ្រួសារ MPP (ដំណើរការប៉ារ៉ាឡែលដ៏ធំ) នៃវិធីសាស្រ្តក្នុងការដំណើរការទិន្នន័យ យកទិន្នន័យពីកន្លែងដែលវាស្ថិតនៅ ពី s3 និង Hadoop ទៅ Cassandra និងឯកសារអត្ថបទធម្មតា។ អ្នកគ្រាន់តែត្រូវសុំឱ្យ Athena ប្រតិបត្តិសំណួរ SQL ហើយបន្ទាប់មកអ្វីៗទាំងអស់ "ដំណើរការយ៉ាងរហ័ស និងដោយស្វ័យប្រវត្តិ"។ វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថា Athena គឺ "ឆ្លាត" វាទៅតែថតដែលចាំបាច់និងអានតែជួរឈរដែលត្រូវការនៅក្នុងសំណើ។

តម្លៃសម្រាប់ការស្នើសុំទៅ Athena ក៏គួរឱ្យចាប់អារម្មណ៍ផងដែរ។ យើងចំណាយសម្រាប់ បរិមាណទិន្នន័យដែលបានស្កេន. ទាំងនោះ។ មិន​មែន​សម្រាប់​ចំនួន​ម៉ាស៊ីន​ក្នុង​ចង្កោម​ក្នុង​មួយ​នាទី​នោះ​ទេ ប៉ុន្តែ... សម្រាប់​ទិន្នន័យ​ដែល​ត្រូវ​បាន​ស្កេន​លើ​ម៉ាស៊ីន 100-500 គឺ​មាន​តែ​ទិន្នន័យ​ដែល​ចាំបាច់​ដើម្បី​បំពេញ​សំណើ។

ហើយដោយការស្នើសុំតែជួរឈរចាំបាច់ពីថតដែលបានបំបែកត្រឹមត្រូវ វាបានប្រែក្លាយថាសេវាកម្ម Athena មានតម្លៃរាប់សិបដុល្លារក្នុងមួយខែ។ ល្អណាស់ ស្ទើរតែឥតគិតថ្លៃ បើប្រៀបធៀបទៅនឹងការវិភាគលើចង្កោម!

និយាយអីញ្ចឹង នេះជារបៀបដែលយើងចែករំលែកទិន្នន័យរបស់យើងនៅក្នុង s3៖

ជាលទ្ធផល ក្នុងរយៈពេលដ៏ខ្លី នាយកដ្ឋានផ្សេងគ្នាទាំងស្រុងនៅក្នុងក្រុមហ៊ុន ចាប់ពីសុវត្ថិភាពព័ត៌មាន រហូតដល់អ្នកវិភាគ បានចាប់ផ្តើមធ្វើការស្នើសុំយ៉ាងសកម្មទៅកាន់ Athena ហើយភ្លាមៗ ក្នុងរយៈពេលប៉ុន្មានវិនាទី ទទួលបានចម្លើយដ៏មានប្រយោជន៍ពីទិន្នន័យ "ធំ" ក្នុងរយៈពេលដ៏យូរគួរសម៖ ខែ។ កន្លះឆ្នាំ។ល។ P.

ប៉ុន្តែ​យើង​បាន​ទៅ​កាន់​តែ​ឆ្ងាយ​ទៀត ហើយ​ចាប់​ផ្ដើម​ទៅ​កាន់​ពពក​ដើម្បី​រក​ចម្លើយ តាមរយៈកម្មវិធីបញ្ជា ODBC៖ អ្នកវិភាគសរសេរសំណួរ SQL នៅក្នុងកុងសូលដែលធ្លាប់ស្គាល់ ដែលនៅលើម៉ាស៊ីន 100-500 “សម្រាប់កាក់” បញ្ជូនទិន្នន័យទៅ s3 ហើយត្រឡប់ចម្លើយជាធម្មតាក្នុងរយៈពេលពីរបីវិនាទី។ មាន​ផា​សុខភាព។ ហើយលឿន។ ខ្ញុំនៅតែមិនជឿ។

ជាលទ្ធផល ដោយបានសម្រេចចិត្តរក្សាទុកទិន្នន័យនៅក្នុង s3 ក្នុងទម្រង់ជួរឈរប្រកបដោយប្រសិទ្ធភាព និងជាមួយនឹងការចែករំលែកទិន្នន័យសមហេតុផលទៅក្នុងថតឯកសារ... យើងបានទទួល DataLake និងម៉ាស៊ីនវិភាគលឿន និងថោក - ដោយឥតគិតថ្លៃ។ ហើយគាត់ទទួលបានប្រជាប្រិយភាពយ៉ាងខ្លាំងនៅក្នុងក្រុមហ៊ុនដោយសារតែ ... យល់អំពី SQL និងដំណើរការលំដាប់នៃរ៉ិចទ័រលឿនជាងតាមរយៈការចាប់ផ្តើម/បញ្ឈប់/រៀបចំចង្កោម។ «​ហើយ​បើ​លទ្ធផល​ដូចគ្នា ហេតុ​អ្វី​បាន​ជា​ត្រូវ​ចំណាយ​ច្រើន?

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

ការរកឃើញ

ដោយបានឆ្លងកាត់ ដោយមិននិយាយផ្លូវវែងឆ្ងាយ ប៉ុន្តែឈឺចាប់ ដោយវាយតម្លៃឱ្យបានគ្រប់គ្រាន់នូវហានិភ័យ និងកម្រិតនៃភាពស្មុគស្មាញ និងតម្លៃនៃការគាំទ្រ យើងបានរកឃើញដំណោះស្រាយសម្រាប់ DataLake និងការវិភាគដែលមិនដែលឈប់ធ្វើឱ្យយើងពេញចិត្តទាំងល្បឿន និងតម្លៃនៃភាពជាម្ចាស់។

វាបានប្រែក្លាយថាការកសាងប្រសិទ្ធភាព លឿន និងថោកដើម្បីដំណើរការ DataLake សម្រាប់តម្រូវការនៃនាយកដ្ឋានផ្សេងគ្នាទាំងស្រុងរបស់ក្រុមហ៊ុនគឺស្ថិតនៅក្នុងសមត្ថភាពរបស់អ្នកអភិវឌ្ឍន៍ដែលមានបទពិសោធន៍ទាំងស្រុងដែលមិនធ្លាប់ធ្វើការជាស្ថាបត្យករ និងមិនដឹងពីរបៀបគូរការ៉េនៅលើការ៉េ។ ព្រួញ និងដឹង 50 ពាក្យពីប្រព័ន្ធអេកូឡូស៊ី Hadoop ។

នៅដើមដំបូងនៃការធ្វើដំណើរ ក្បាលរបស់ខ្ញុំបានបែកចេញពីសួនសត្វព្រៃជាច្រើននៃកម្មវិធីបើក និងបិទ និងការយល់ដឹងអំពីបន្ទុកនៃការទទួលខុសត្រូវចំពោះកូនចៅ។ គ្រាន់តែចាប់ផ្តើមបង្កើត DataLake របស់អ្នកពីឧបករណ៍សាមញ្ញ៖ nagios/munin -> elastic/kibana -> Hadoop/Spark/s3... ប្រមូលមតិកែលម្អ និងស្វែងយល់យ៉ាងស៊ីជម្រៅអំពីរូបវិទ្យានៃដំណើរការដែលកើតឡើង។ អ្វីគ្រប់យ៉ាងដែលស្មុគស្មាញនិងស្រពិចស្រពិល - ផ្តល់ឱ្យវាទៅសត្រូវនិងគូប្រជែង។

ប្រសិនបើអ្នកមិនចង់ទៅពពក ហើយចូលចិត្តគាំទ្រ ធ្វើបច្ចុប្បន្នភាព និងជួសជុលគម្រោងប្រភពបើកចំហ អ្នកអាចបង្កើតគ្រោងការណ៍ស្រដៀងនឹងរបស់យើងនៅក្នុងមូលដ្ឋាន លើម៉ាស៊ីនការិយាល័យដែលមានតំលៃថោកជាមួយ Hadoop និង Presto ពីលើ។ រឿងចំបងគឺមិនត្រូវឈប់ ហើយដើរទៅមុខ រាប់ រកមើលដំណោះស្រាយសាមញ្ញ និងច្បាស់លាស់ ហើយអ្វីៗនឹងដំណើរការទៅយ៉ាងពិតប្រាកដ! សូមសំណាងល្អទាំងអស់គ្នា ហើយជួបគ្នាម្តងទៀត!

ប្រភព: www.habr.com