ډیلټا: د معلوماتو همغږي کول او بډایه کولو پلیټ فارم

په نرخ کې د نوي جریان د پیل په تمه د معلوماتو انجنیر موږ د زړه پورې موادو ژباړه چمتو کړې ده.

عمومي کتنه

موږ به د کافي مشهور نمونې په اړه وغږیږو چې له مخې یې غوښتنلیکونه ډیری ډیټا پلورنځي کاروي ، چیرې چې هر پلورنځی د خپلو اهدافو لپاره کارول کیږي ، د مثال په توګه ، د ډیټا کینونیکي بڼه ذخیره کولو لپاره (MySQL ، او داسې نور) ، د پرمختللي لټون وړتیا چمتو کوي (ElasticSearch, etc.)، caching (Memcached، etc.) او نور. عموما، کله چې ډیری ډیټا پلورنځي کاروي، یو یې د لومړني پلورنځي په توګه کار کوي او بل یې د مشتق پلورنځیو په توګه. یوازینۍ ستونزه دا ده چې څنګه د دې ډیټا پلورنځیو همغږي کول.

موږ یو شمیر مختلف نمونو ته کتنه وکړه چې هڅه یې کړې د ډیری پلورنځیو همغږي کولو ستونزه حل کړي ، لکه ډبل لیکونه ، توزیع شوي لیږدونه او داسې نور. په هرصورت، دا طریقې د حقیقي ژوند کارولو، اعتبار، او ساتنې په برخه کې د پام وړ محدودیتونه لري. د ډیټا همغږي کولو سربیره ، ځینې غوښتنلیکونه د بهرنیو خدماتو په زنګ وهلو سره ډیټا بډایه کولو ته هم اړتیا لري.

ډیلټا د دې ستونزو د حل لپاره رامینځته شوی. ډیلټا په نهایت کې د معلوماتو همغږي کولو او بډایه کولو لپاره یو ثابت ، د پیښې پرمخ وړل پلیټ فارم چمتو کوي.

شته حلونه

دوه ځله ننوتل

د دوه ډیټا پلورنځیو په ترکیب کې ساتلو لپاره ، تاسو کولی شئ دوه ګونی لیک وکاروئ ، کوم چې یو پلورنځي ته لیکي او بیا سمدلاسه وروسته بل ته لیکي. لومړی ثبت کول بیا هڅه کیدی شي او دوهم یې لغوه کیدی شي که چیرې لومړی د هڅو شمیر پای ته رسیدو وروسته ناکام شي. په هرصورت، دوه ډیټا پلورنځي ممکن د همغږۍ څخه بهر شي که چیرې دویم پلورنځي ته لیکل ناکام شي. دا ستونزه معمولا د بیا رغونې پروسې رامینځته کولو سره حل کیږي چې کولی شي په دوره توګه د لومړي ذخیرې څخه دوهم ته ډیټا بیا لیږد کړي ، یا دا یوازې هغه وخت ترسره کړي کله چې په ډیټا کې توپیرونه وموندل شي.

ستونزې:

د بیا رغونې طرزالعمل ترسره کول یو ځانګړی دنده ده چې نشي کارول کیدی. برسېره پردې، د ذخیره کولو ځایونو ترمنځ ډاټا د همغږۍ څخه بهر پاتې کیږي تر هغه چې د بیا رغونې پروسه ترسره شي. حل خورا پیچلی کیږي که چیرې له دوه څخه ډیر ډیټا ذخیره وکارول شي. په نهایت کې ، د بیا رغونې پروسه کولی شي د اصلي معلوماتو سرچینې ته بار اضافه کړي.

د ننوتلو میز بدل کړئ

کله چې بدلونونه د میزونو سیټ کې واقع کیږي (لکه د ریکارډ داخلول، تازه کول، او حذف کول)، د بدلون ریکارډونه د ورته لیږد د یوې برخې په توګه د لاګ میز ته اضافه کیږي. بله تار یا پروسه په دوامداره توګه د لاګ جدول څخه د پیښو غوښتنه کوي او یو یا ډیرو ډیټا پلورنځیو ته یې لیکي ، که اړتیا وي ، د ټولو پلورنځیو لخوا د ریکارډ تایید وروسته د لاګ میز څخه پیښې لرې کول.

ستونزې:

دا نمونه باید د کتابتون په توګه پلي شي، او په مثالي توګه د غوښتنلیک کوډ بدلولو پرته چې دا کاروي. په پولیګلوټ چاپیریال کې، د داسې کتابتون پلي کول باید په هره اړینه ژبه کې شتون ولري، مګر د ژبو په اوږدو کې د فعالیت او چلند دوام ډاډمن کول خورا ستونزمن کار دی.

بله ستونزه په سیسټمونو کې د سکیما بدلونونو ترلاسه کولو کې ده چې د لیږد سکیما بدلونونو ملاتړ نه کوي [1][2]، لکه MySQL. له همدې امله، د بدلون کولو نمونه (د مثال په توګه، د سکیما بدلون) او د لیږد په توګه یې د بدلون لاګ جدول کې ثبت کول به تل کار ونکړي.

توزیع شوي لیږدونه

توزیع شوي لیږدونه د ډیری متفاوت ډیټا پلورنځیو کې د لیږد ویشلو لپاره کارول کیدی شي ترڅو عملیات یا د ټولو کارول شوي ډیټا پلورنځیو ته ژمن وي ، یا هیڅ یو ته ژمن ندي.

ستونزې:

توزیع شوي لیږدونه د متفاوت ډیټا پلورنځیو لپاره خورا لویه ستونزه ده. د دوی د طبیعت له مخې، دوی کولی شي یوازې د شامل سیسټمونو ترټولو ټیټ عام ډینومینټر باندې تکیه وکړي. د مثال په توګه، د XA لیږد اجرا کول بندوي که چیرې د غوښتنلیک پروسه د چمتووالي په مرحله کې ناکامه شي. برسیره پردې، XA د تعدیل کشف یا ملاتړ نه کوي د خوشبینۍ کنټرول سکیمونو ملاتړ کوي. برسېره پردې، ځینې سیسټمونه لکه ElasticSearch د XA یا کوم بل متفاوت لیږد ماډل ملاتړ نه کوي. په دې توګه، د مختلفو معلوماتو ذخیره کولو ټیکنالوژیو کې د لیکلو اتومیت یقیني کول د غوښتنلیکونو لپاره خورا ننګونکي کار پاتې دی [3].

دلتا

ډیلټا د موجوده ډیټا ترکیب حلونو محدودیتونو ته د رسیدو لپاره ډیزاین شوی او همدارنګه د الوتنې په جریان کې د معلوماتو بډایه کول وړوي. زموږ هدف دا و چې دا ټولې پیچلتیاوې د غوښتنلیک پراختیا کونکو څخه لرې کړو ترڅو دوی وکولی شي د سوداګرۍ فعالیت پلي کولو باندې بشپړ تمرکز وکړي. بیا به موږ د "فلم لټون" تشریح کړو، د Netflix ډیلټا لپاره د اصلي کارونې قضیه.

Netflix په پراخه کچه د مایکرو سرویس معمارۍ کاروي، او هر مایکرو خدمت عموما یو ډول ډیټا خدمت کوي. د فلم په اړه بنسټیز معلومات د فلم خدمت په نوم په مایکرو سرویس کې شتون لري، او اړونده ډاټا لکه د تولید کونکو، لوبغاړو، پلورونکو او داسې نورو په اړه معلومات د ډیری نورو مایکرو خدماتو لخوا اداره کیږي (د ډیل خدمت، د استعداد خدمت او پلورونکي خدمت).
په Netflix سټوډیوز کې سوداګریز کارونکي اکثرا اړتیا لري د مختلف فلم معیارونو لټون وکړي ، له همدې امله دا د دوی لپاره خورا مهم دی چې وکولی شي د فلم پورې اړوند ټولو معلوماتو کې لټون وکړي.

د ډیلټا دمخه، د فلم لټون ټیم ته اړتیا درلوده چې د فلم ډیټا لیست کولو دمخه د ډیری مایکرو خدماتو څخه ډاټا راوباسي. برسېره پردې، ټیم باید یو سیسټم رامینځته کړي چې په دوره توګه د نورو مایکرو خدماتو څخه د بدلونونو غوښتنه کولو سره د لټون شاخص تازه کړي، حتی که هیڅ بدلون نه وي. دا سیسټم په چټکۍ سره پیچلی او ساتل ستونزمن شو.

شکل 1. ډیلټا ته د رایې ورکولو سیسټم
د ډیلټا کارولو وروسته، سیسټم د پیښې پرمخ وړونکي سیسټم ته ساده شوی لکه څنګه چې په لاندې شکل کې ښودل شوي. CDC (Change-Data-Capture) پیښې د Delta-Connector په کارولو سره د کیسټون کافکا موضوعاتو ته لیږل کیږي. د ډیلټا غوښتنلیک د ډیلټا سټریم پروسس کولو چوکاټ په کارولو سره رامینځته شوی (د فلنک پراساس) د یوې موضوع څخه د CDC پیښې ترلاسه کوي ، د نورو مایکرو خدماتو په زنګ وهلو سره بډایه کوي ، او په پای کې بډایه شوي ډاټا په Elasticsearch کې د لټون شاخص ته لیږدوي. ټوله پروسه تقریبا په ریښتیني وخت کې ترسره کیږي، دا دی، هرڅومره ژر چې بدلونونه د معلوماتو ګودام ته ژمن وي، د لټون شاخصونه تازه کیږي.

شکل 2. د ډیلټا په کارولو سره د معلوماتو پایپ لاین
په لاندې برخو کې، موږ به د ډیلټا نښلونکي عملیات تشریح کړو، کوم چې د ذخیره کولو سره نښلوي او د ټرانسپورټ پرت ته د CDC پیښې خپروي، کوم چې د ریښتیني وخت ډیټا لیږد زیربنا ده چې د CDC پیښې د کافکا موضوعاتو ته لیږدول کیږي. او په پای کې، موږ به د ډیلټا سټریم پروسس کولو چوکاټ په اړه وغږیږو، کوم چې د غوښتنلیک پراختیا کونکي کولی شي د ډیټا پروسس کولو او بډایه کولو منطق لپاره وکاروي.

CDC (بدلون - ډاټا - نیول)

موږ د Delta-Connector په نوم د CDC خدمت رامینځته کړی ، کوم چې کولی شي په ریښتیني وخت کې د ډیټا سټور څخه ژمن بدلونونه ونیسي او جریان ته یې ولیکي. د ریښتیني وخت بدلونونه د لیږد لاګ او ذخیره کولو ډمپونو څخه اخیستل کیږي. ډمپونه کارول کیږي ځکه چې د لیږد لاګونه معمولا د بدلونونو ټول تاریخ نه ساتي. بدلونونه په عموم ډول د ډیلټا پیښو په توګه سریال شوي دي، نو ترلاسه کونکي باید اندیښنه ونلري چې بدلون له کوم ځای څخه راځي.

Delta-Connector د څو اضافي ځانګړتیاوو ملاتړ کوي لکه:

• د کافکا څخه تیر شوي دودیز محصول ډیټا لیکلو وړتیا.
• په هر وخت کې د ټولو میزونو، یو ځانګړي میز، یا ځانګړي لومړني کیلي لپاره د لاسي ډمپونو فعالولو وړتیا.
• ډمپونه په ټوټو کې ترلاسه کیدی شي، نو د ناکامۍ په صورت کې د بیا پیل کولو اړتیا نشته.
• په میزونو کې تالاشۍ ځای په ځای کولو ته اړتیا نشته، کوم چې د دې ډاډ ترلاسه کولو لپاره خورا مهم دی چې د ډیټابیس لیکلو ټرافیک هیڅکله زموږ د خدماتو لخوا بند شوی نه وي.
• د AWS موجودیت زونونو کې د بې ځایه مثالونو له امله لوړ شتون.

موږ دا مهال د MySQL او Postgres ملاتړ کوو، په شمول د AWS RDS او Aurora کې ځای پرځای کول. موږ د کاسیندرا (ملټي ماسټر) ملاتړ هم کوو. تاسو کولی شئ دلته د Delta-Connector په اړه نور معلومات ومومئ د بلاګ پوسټ.

کافکا او د ترانسپورت پرت

د ډیلټا د پیښې ټرانسپورټ پرت د پلیټ فارم پیغام رسولو خدمت کې جوړ شوی دنړۍ پر.

په تاریخي توګه، په Netflix کې پوسټ کول د اوږد عمر پرځای د لاسرسي لپاره غوره شوي (لاندې وګورئ). پخوانۍ مقاله). د سوداګرۍ بند په مختلف څنډه سناریوګانو کې د بروکر ډیټا احتمالي تضاد و. د مثال په ډول، ناپاک مشر ټاکنې د ترلاسه کونکي لپاره مسؤل دی چې احتمالي نقل یا ورک شوي پیښې ولري.

د ډیلټا سره ، موږ د قوي دوام تضمین غواړو ترڅو ترلاسه شوي پلورنځیو ته د CDC پیښو تحویل یقیني کړو. د دې هدف لپاره، موږ د لومړي درجې اعتراض په توګه د کافکا کلستر په ځانګړي ډول ډیزاین شوی. تاسو کولی شئ په لاندې جدول کې د بروکر ځینې تنظیمات وګورئ:

د کیسټون کافکا کلسترونو کې، ناپاک مشر ټاکنې معمولا د خپرونکي لاسرسي ډاډ ترلاسه کولو لپاره شامل دي. دا کیدی شي د پیغام له لاسه ورکولو پایله ولري که چیرې غیر همغږي شوي نقل د مشر په توګه وټاکل شي. د نوي لوړ شتون کافکا کلستر لپاره، اختیار ناپاک مشر ټاکنې د پیغام له لاسه ورکولو مخنیوي لپاره غیر فعال شوی.

موږ هم زیات شو د تکثیر عامل له 2 څخه تر 3 پورې او لږترلږه د انسینک نقلونه 1 څخه تر 2. خپرونکي چې دې کلستر ته لیکي د نورو ټولو څخه اکسونو ته اړتیا لري، دا ډاډه کوي چې د 2 نقلونو څخه 3 د خپرونکي لخوا لیږل شوي ترټولو اوسني پیغامونه لري.

کله چې د بروکر مثال پای ته ورسیږي، یو نوی مثال د زاړه ځای بدلوي. په هرصورت، نوی بروکر به اړتیا ولري چې د غیر همغږي شوي نقلونو سره ځان ونیسي، کوم چې ممکن څو ساعته وخت ونیسي. د دې سناریو لپاره د بیا رغونې وخت کمولو لپاره، موږ د محلي بروکر ډیسکونو پر ځای د بلاک ډیټا ذخیره (Amazon Elastic Block Store) کارول پیل کړل. کله چې یو نوی مثال د لغوه شوي بروکر مثال بدلوي، دا د EBS حجم سره ضمیمه کوي چې ختم شوي مثال درلود او د نوي پیغامونو سره نیول پیل کوي. دا پروسه د بیکلاګ پاکولو وخت له ساعتونو څخه دقیقو ته راټیټوي ځکه چې نوې بیلګه نور اړتیا نلري له خالي حالت څخه نقل شي. په ټولیز ډول، جلا ذخیره او د بروکر ژوند د پام وړ د بروکر سویچینګ اغیز کموي.

د ډیټا تحویلي تضمین لا زیاتولو لپاره ، موږ کارولی د پیغام تعقیب سیسټم په سختو شرایطو کې د کوم پیغام ضایع کیدو کشف کول (د مثال په توګه، د برخې په مشر کې د ساعت غیر همغږي کول).

د جریان پروسس کولو چوکاټ

د ډیلټا پروسس کولو پرت د Netflix SPaaS پلیټ فارم په سر کې جوړ شوی، کوم چې د Netflix ایکوسیستم سره د اپاچي فلنک ادغام چمتو کوي. پلیټ فارم یو کارن انٹرفیس چمتو کوي چې زموږ د ټایټس کانټینر مدیریت پلیټ فارم په سر کې د فلنک دندو ګمارنه او د فلنک کلسترونو آرکیسټریشن اداره کوي. انٹرفیس د دندې تشکیلات هم اداره کوي او کاروونکو ته اجازه ورکوي چې د فلنک دندې له سره تنظیم کولو پرته په متحرک ډول د تشکیلاتو بدلونونه رامینځته کړي.

ډیلټا د فلنک او SPaaS پراساس د جریان پروسس کولو چوکاټ چمتو کوي چې کاروي د تبصرې پر بنسټ DSL (د ډومین ځانګړې ژبه) د تخنیکي توضیحاتو خلاصولو لپاره. د مثال په توګه، د هغه ګام تعریف کولو لپاره چې پیښې به د بهرنیو خدماتو په زنګ وهلو سره بډایه شي، کاروونکي اړتیا لري چې لاندې DSL ولیکئ، او چوکاټ به د هغې پر بنسټ یو ماډل رامینځته کړي، کوم چې د فلنک لخوا اجرا کیږي.

شکل 3. په ډیلټا کې په DSL کې د بډای کولو بیلګه

د پروسس کولو چوکاټ نه یوازې د زده کړې وکر کموي، بلکې د عام عملیاتي ستونزو د حل کولو لپاره د عادي جریان پروسس کولو ځانګړتیاوې لکه تخریب، سکیماتیزیشن، او انعطاف او انعطاف هم چمتو کوي.

د ډیلټا سټریم پروسس کولو چوکاټ دوه کلیدي ماډلونه لري، د DSL او API ماډل او د چلولو ماډل. د DSL او API ماډل DSL او UDF (د کارونکي تعریف شوي فنکشن) APIs چمتو کوي ترڅو کارونکي وکولی شي خپل د پروسس کولو منطق (لکه فلټر کول یا بدلونونه) ولیکي. د Runtime ماډل د DSL پارسر پلي کول چمتو کوي چې د DAG ماډلونو کې د پروسس مرحلو داخلي نمایش رامینځته کوي. د اجرایی برخه د DAG ماډلونه تشریح کوي ترڅو ریښتیني فلنک بیانات پیل کړي او په نهایت کې د فلنک غوښتنلیک پرمخ بوځي. د چوکاټ جوړښت په لاندې انځور کې ښودل شوی.

شکل 4. د ډیلټا سټریم پروسس کولو چوکاټ جوړښت

دا طریقه ډیری ګټې لري:

• کاروونکي کولی شي د دوی د سوداګرۍ منطق باندې تمرکز وکړي پرته لدې چې د فلنک یا SPaaS جوړښت مشخصاتو ته ځان ورسوي.
• اصلاح کول په داسې طریقه ترسره کیدی شي چې کاروونکو ته شفاف وي، او غلطۍ د کاروونکي کوډ (UDF) کې کوم بدلون ته اړتیا پرته حل کیدی شي.
• د ډیلټا غوښتنلیک تجربه د کاروونکو لپاره ساده شوې ځکه چې پلیټ فارم د بکس څخه بهر انعطاف او انعطاف چمتو کوي او مختلف تفصیلي میټریکونه راټولوي چې د خبرتیاو لپاره کارول کیدی شي.

د تولید کارول

ډیلټا د یو کال راهیسې په تولید کې دی او د ډیری Netflix سټوډیو غوښتنلیکونو کې کلیدي رول لوبوي. هغې د ټیمونو سره د کارونې قضیې پلي کولو کې مرسته وکړه لکه د لټون شاخص کول ، د معلوماتو ذخیره کول ، او د پیښې لخوا پرمخ وړل شوي کاري جریان. لاندې د ډیلټا پلیټ فارم د لوړې کچې جوړښت یوه عمومي کتنه ده.

شکل 5. د ډیلټا د لوړې کچې جوړښت.

اعترافونه

موږ غواړو د لاندې خلکو څخه مننه وکړو چې په Netflix کې د ډیلټا په جوړولو او پراختیا کې ښکیل وو: الن وانګ، چارلس ژاو، جیبین یون، جوش سنایډر، کستوري چترجي، مارک چو، اولوف جوهانسن، پیوش ګویل، پرشانت رامداس، راګورام اونتي سرینواسن، سندیپ ګپتا، سټیون وو، تارنگا ګامیتیګ، یون وانګ او ژینژونګ سو.

سرچینې

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. مارتین کلیپمن، الیسټر آر بیرسفورډ، بورج سوینګین: د آنلاین پیښو پروسس کول. کمیون. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

د وړیا ویبینار لپاره لاسلیک وکړئ: "د ایمیزون ریډ شفټ ذخیره کولو لپاره د ډیټا جوړونې وسیله."

سرچینه: www.habr.com