د تولید چاپیریالونو وروستیو عملیاتو پر بنسټ، د سیارټونینل CDC (Change Data Capture) کارولو لپاره سټینرونه لکه Oracle، MySQL، او SQL Server، او سره د کاروونکو په پراخه کچه د پیژندنې په ګډه، زه دا مقاله نوشتم ترڅو تاسو سره مرسته وکړي چې د سیارټونینل د سیارټونینل پیژندل کولو پروسه درک کړي. د محتوا په عمده توګه د سیارټون د درې مرحلهونو کې شامل دي: Snapshot، Backfill، او Incremental. د CDC درې مراحل د CDC ډاټا لوستلو په عمومي توګه پروسه کولی شي په درې مهمو مرحلهونو کې تقسیم شي: Snapshot (د بشپړ لوډ) پیژندل اضافي 1. د Snapshot مرحله د Snapshot مرحله معنی خورا حساس دی: د اوسني ډاټا ډاټا ټابلیټ ډاټا snapshot کړئ او د JDBC له لارې بشپړ ټابلیټ سکن ترسره کړئ. د MySQL په توګه د مثال په توګه، د اوسني binlog موقعیت په snapshot کې ثبت کیږي: SHOW MASTER STATUS; File Position Binlog_Do_DB Binlog_Ignore_DB Executed_Gtid_Set binlog.000011 1001373553 بڼه 000011 1001373553 SeaTunnel د فایل او موقعیت په توګه ثبت کوي . low watermark یادونه: دا یوازې یو ځل کار نه کوي، ځکه چې SeaTunnel د سپیکټونه چټکولو لپاره خپل ځان د سپیکټ کټ کولو منطق جوړ کړ. یادونه: دا یوازې یو ځل کار نه کوي، ځکه چې SeaTunnel د سپیکټونه چټکولو لپاره خپل ځان د سپیکټ کټ کولو منطق جوړ کړ. د MySQL Snapshot Splitting میکانیزم (Split) د Global Parallelism په توګه د 10 ده: SeaTunnel به لومړی د ټولو جدولونو او د دوی د لومړني کلید / ځانګړي کلید لړونو تحلیل کړي او د مناسب تقسیم کولین انتخاب کړي. دا د دې لړۍ د حداکثري او حداکثري ارزښتونو په اساس تقسیم کیږي، د snapshot.split.size = 8096 معیار سره. لوی جدولونه کولی شي په سینټونو کې تقسیم شي، کوم چې د شمولر له خوا د زیرمهال د غوښتنو په ترتیب سره د 10 متوازن چینلونو ته تادیه شوي دي (که په عمومي توګه د توازن توزیع ته چمتو کیږي). Table-level sequential processing (schematic): // Processing sequence: // 1. Table1 -> Generate [Table1-Split0, Table1-Split1, Table1-Split2] // 2. Table2 -> Generate [Table2-Split0, Table2-Split1] // 3. Table3 -> Generate [Table3-Split0, Table3-Split1, Table3-Split2, Table3-Split3] Split-level parallel allocation: // Allocation to different subtasks: // Subtask 0: [Table1-Split0, Table2-Split1, Table3-Split2] // Subtask 1: [Table1-Split1, Table3-Split0, Table3-Split3] // Subtask 2: [Table1-Split2, Table2-Split0, Table3-Split1] هر Split په حقیقت کې یو پوښتنه ده چې د رینج شرایط لري، د مثال په توګه: SELECT * FROM user_orders WHERE order_id >= 1 AND order_id < 10001; هر Split په انفرادي ډول د خپل ټیټ اوبو ټیټ / لوړ اوبو ټیټ ثبت کوي. Crucial: نه جوړ کړئ ډیر کوچني؛ د ډیری Splits په لټه کې اړتیا نلري، او د روزنې او د یادښت په لټه کې به ډیر لوی وي. Practical Advice: split_size 2. Backfill مرحله تصور وکړئ چې تاسو د ټابلیټ بشپړ snapshot کاروي چې په اغیزمن ډول په نامه کې وي. کله چې تاسو د 100th لړۍ وګورئ، ممکن چې د 1st لړۍ ډاټا به بدل شوي وي. که تاسو یوازې د snapshot وګورئ، د ډاټا چې تاسو په بشپړولو کې لري، په واقعیت کې "انقباض" دی (د برخه پرله دی، برخه نوی دی). Why is Backfill needed? The role of Backfill is to compensate for the "data changes that occurred during the snapshot" so that the data is eventually consistent. د دې مرحله چلند په عمده توګه د سیسټم جوړښت پورې اړه لري. پارامترونه exactly_once 2.1 په ساده ډول ( ) exactly_once = false دا د معياري حالت ده؛ د منطق نسبتا ساده او مستقیم دی، او دا د مینو کیش ته اړتیا نلري: Direct Snapshot Emission: د snapshot معلوماتو وګورئ او دا په مستقیم ډول پرته پرته د کیش ته ورسیږي. Direct Log Emission: د Binlog په ورته وخت کې وګورئ او دا په مستقیم ډول ډاونلوډ کوي. ممکن د مطابقت: که څه هم په منځ کې دوپلیکیټونه به وي (د قدیم A په لومړي کې، بیا د نوي B) ، په داسې حال کې چې د زیربنا د idempotent چاپونو ملاتړ کوي (چې د MySQL د INTO بدلون په توګه) ، د پایلې پایله مطابقت لري. د 2 اونۍ په اړه ( ) exactly_once = true دا د SeaTunnel CDC تر ټولو اغیزمن برخه ده، او دا د ډاټا تضمین کولو راز دی چې د معلوماتو "نه کولی شي کولی شي، نه تکرار شي." د Deduplication لپاره. memory buffer (Buffer) تصور وکړئ چې د معلم تاسو ته پوښتنه چې په دې وخت کې په ټولګي کې کتنه ورکړئ (Snapshot مرحله). په هرصورت، په ټولګي کې د زده کونکو ډېر ناڅاپي دي؛ په داسې حال کې چې تاسو کڅوړه کوي، خلک په او بهر (د معلوماتو بدلونونه). که تاسو یوازې خپل دماغ په نیټه کې حساب کړئ، د پایلې به په بشپړ ډول غلط وي کله چې تاسو ختم کړئ. Simple Explanation: SeaTunnel دا په دې ډول کار کوي: د عکس په لومړي ډول (Snapshot): لومړی په ټولګي کې د خلکو شمېر محاسبه او دا په یو کوچني نوټ کې (د حافظه حافظه) ثبت کړئ؛ د اصلي (د ډاونلوډ) نه وايي. د Surveillance (Backfill) وګورئ: د هغه وخت لپاره چې تاسو حساب وکړئ، د څارنې ویډیو (Binlog لګښت) ترلاسه کړئ. د ریکارډونو د اصلاح (Merge): که څارنه ښیي چې یو څوک یوازې وارد شو، مګر تاسو دوی لټون نه کوي -> دوی اضافه کړئ. که څارنه ښیي چې یو څوک یوازې له لاسه ورکړی، مګر تاسو یې په -> د دوی له لاسه ورکړئ. که څارنه ښيي چې یو څوک د خپل لباس بدل کړئ -> د نوي لباسونو لپاره د ریکارډ بدل کړئ. رسولو کورس (رسول): د اصلاح وروسته، ستاسو په لاس کې د کوچني نوټ په بشپړه توګه دقیق لیست دی؛ اوس دا له اصلي ته ورکړئ. معنی Summary for Beginners: exactly_once = true "hold it in and don't send it until it's clearly verified." ګټور: د ترلاسه شوي ډاټا لاندې په بشپړه توګه پاک دی، د دوپلیټونو یا ناقانونه نلري. د لګښت: ځکه چې دا باید "په" وي، دا باید د معلوماتو ذخیره کولو لپاره ځینې حافظه مصرف کړي. که جدول په ځانګړي ډول لوی وي، د حافظه کولی شي ناقانونه وي. 2.3 د دوو اصلي پوښتنو او ځوابونه په کوډ کې لیکل شوي؟ چرا د Backfill مرحله کې د READ واقعې نه شتون لري؟ Q1: Why is case READ: throw Exception د READ واقعیت د SeaTunnel ځان لخوا تعریف کیږي، په ځانګړې توګه د "د سټاک ډاټا له snapshot څخه وګورئ". د Backfill مرحله د ډاټا بیلګ راټول کوي. Binlog یوازې د "د اضافهاتو، حذفاتو او تعدیلاتو" (INSERT / UPDATE / DELETE) ثبت کوي او هیڅکله "کڅوړه د ډاټا ټوټه ته پوښتنه" ثبت کوي. له دې امله، که تاسو د Backfill مرحله کې د READ واقعې وګورئ، دا معنی لري چې د کوډ منطق غلط دی. Q2: If it's placed in memory, can the memory hold it? Will it OOM? دا د کلې جدول په یادښت کې نه ورکوي: SeaTunnel پروسسونه په برخه کې. Splits کوچني دي: د معياري Splits یوازې د 8096 لړۍ ډاټا لري. د کارولو وروسته له لاسه ورکړئ: د تقسیم کولو پروسس وروسته، دا وساتي، د حافظه پاک کړئ، او بل پروسس کړئ. د حافظه پوښونو فورمول ≈ : د پارليالیت × Split اندازه × Single row معلوماتو اندازه. 2.4 د کلیدي تفصيل: د ډیری Splits تر منځ د Watermark توازن دا یو خورا مخکښ، مګر خورا مهم موضوع دی. که نه په ښه توګه کار واخلئ، it will lead to data being either lost or repeated. د چټک / چټک چلونکي ستونزه: تصور وکړئ چې د دوو زده کونکو (Split A او Split B) کورس (Backfill معلوماتو) کاپي کوي. Plain Language Explanation: Student A (fast): Copied to page 100 and finished at 10:00. د زده کونکي B (تولید شوی): د 200 پايلې ته کاپی شوی او یوازې په 10:05 کې بشپړ شوی. اوس، د معلم (Incremental ورکشاپ) ته اړتيا لري چې د نوي درس (د Binlog مطالعه) د هغه ځای څخه زده کړي چې دوی د کاپي بشپړ کړي. د معلم باید چیرې پیل شي؟ که د 200: زده کونکي B څخه پیل کیږي، مګر زده کونکي A د 100 او 200 پايلې په منځ کې (که د 10:00 او 10:05) په بشپړه توګه کولی شي. که د 100: د زده کونکي A سره اړیکه ونیسئ، مګر زده کونکي B به شکایت وکړي: "د زده کونکي، زه د 100 څخه د 200 څخه د موادو کاپي کړم!" دا د تکرار لپاره مننه کوي. د SeaTunnel د حل: د لومړي ځل څخه پیل کړئ او د هغه څه لپاره چې تاسو اوس هم شنیده اید، خپل گوشونه پوښئ: د SeaTunnel یو د ستراتیژۍ: "Minimum Watermark Starting Point + Dynamic Filtering" د پیل مشخص کړئ (د چټک یو لپاره د مراقبت): د معلم په پایله کې د 100 څخه پیل کول (د ټولو تقسیمونو کې لږ تر لږه د اوبو ټانک). د متحرک فلټرنېټ (نه د هغه څه چې شنیدلي نه): په داسې حال کې چې د زده کونکي (د Binlog وګورئ)، دوی یو لیست لري: { A: 100, B: 200 }. When the teacher reaches page 150: د لیست وګورئ؛ آیا دا د A؟ 150 > 100 لپاره دی، د A نه وګورئ، ثبت کړئ (رسول کړئ). د لیست وګورئ؛ آیا دا د B؟ 150 < 200، B به د دې کاپي، په مستقیم ډول له لاسه ورکړئ (Discard). د بشپړ سرعت موډل (هرڅه د سنګاري بشپړ شوی): کله چې د معلم د 201 پاڼه ته ورسیږي او پدې کې چې هرڅه د دې څخه دمخه پوه شي، دوی د لیست ته اړتیا نلري. سره : د اضافي مرحله په سخت ډول د "start offset + split range + د عالي watermark" ترکیب له مخې فلټرول کیږي. Summary in one sentence: exactly_once د : د انټرنیټ مرحله د ساده "د یوه ځانګړي پیل د توازن له خوا sequential consumption" وي. exactly_once 3. د اضافي مرحله وروسته د Backfill (د ) یا د Snapshot مرحله پای ته ورسیږي، دا د خالص اضافي مرحله ته ورسیږي: exactly_once = true MySQL: د Binlog پر بنسټ. Oracle: پر بنسټ د redo / logminer. SQL سرور: د سوداګرۍ ژور / LSN پر بنسټ. PostgreSQL: د WAL پر بنسټ. د SeaTunnel په اضافي مرحله کې د اغیزمن Debezium سره ډېر نزدیک دی: په offset ترتیب کې د پروګرامونه کاروي. د هر بدلون لپاره د واقعاتو لکه INSERT / UPDATE / DELETE جوړوي. کله چې precisely_once = true، د توازن او تقسیم حالت په چک پټ کې شامل دي ترڅو د ناکامې د بدعت وروسته د "exactly-once" سمینیک ترلاسه کړي. 4 خلاصې د SeaTunnel CDC اصلي ډیزاین فلسفه دا ده چې د بشپړ توازن تر لاسه کړي او "Fast" (parallel snapshots) "Stable" (data consistency). موږ د کلې پروسه مهمو نقطې راټول کوو: Slicing (Split) د paralel acceleration بنسټ دی: د لوی جدولونه په کوچني ټوټهونو کې پرې کول ترڅو ډیری سیمونه په ورته وخت کې کار وکړي. Snapshot مسؤلیت لري چې د سټاک حرکت کوي: د سټاکونو کارولو لپاره د تاریخي معلوماتو په دوامداره توګه وګورئ. Backfill مسؤلیت لري چې د نښلیدو د نښلیدو لپاره: دا تر ټولو مهم قدم دی. دا د snapshot په وخت کې د بدلونونو توازن کوي او د حافظه مرکزي ارګرامونو په کارولو سره د Exactly-Once ترلاسه کولو لپاره دوپلیکیټونه ازمايښتوي. Incremental د واقعي وخت synchronization مسؤلیت لري: د Backfill مرحله سره په چټکۍ سره اړیکه ونیسئ او په دوامداره توګه د ډاټا لیګونو مصرف کوي. د دې ټریلیولوژۍ په اړه او همدارنګه همدارنګه د په دې کې دا ده چې په حقیقت کې د SeaTunnel CDC اساسي پوهه ورکړي. "Snapshot -> Backfill -> Incremental" "Watermarks"
