اسپارک 3.0 اور ڈیلٹا لیک کے ساتھ ڈیٹا پروسیسنگ کو بہتر بنانا

جمع کرنا، پروسیسنگ کرنا، اور تجزیہ کرنا محرومی ڈیٹا، صنعتوں میں جیسے کہ ایڈ ٹیک میں شدید ڈیٹا انجینئرنگ شامل ہے۔ روزانہ پیدا ہونے والا ڈیٹا بہت بڑا ہوتا ہے (100 GB ڈیٹا) اور بعد کے مراحل کے لیے ڈیٹا پر کارروائی کرنے کے لیے ایک اہم پروسیسنگ وقت درکار ہوتا ہے۔

ایک اور چیلنج بصیرت حاصل کرنے کے لیے ڈیٹا سیٹس میں شامل ہونا ہے۔ ہر عمل میں اوسطاً 10 سے زیادہ ڈیٹاسیٹ ہوتے ہیں اور ایک سے زیادہ کلیدوں کے ساتھ مساوی تعداد میں شمولیت ہوتی ہے۔ ہر کلید کے لیے تقسیم کا سائز ہر رن پر غیر متوقع ہے۔

اور، آخر میں، اگر بعض مواقع پر ڈیٹا کی مقدار زیادہ ہو جاتی ہے، تو اسٹوریج کی میموری ختم ہو سکتی ہے۔ اس کا مطلب یہ ہے کہ یہ عمل حتمی تحریروں کے وسط میں ختم ہو جائے گا، جس سے صارفین ان پٹ ڈیٹا فریموں کو واضح طور پر پڑھ سکیں گے۔

اس بلاگ میں، ہم ایک جائزہ کا احاطہ کریں گے ڈیلٹا لیکساس کے فوائد، اور ڈیلٹا جھیل میں منتقل ہو کر اور Spark 3.0 سے Spark 2.4 میں منتقل ہو کر مندرجہ بالا چیلنجوں پر کیسے قابو پایا جا سکتا ہے۔ 

ڈیلٹا جھیل کیا ہے؟

Databricks میں تیار کردہ، "Delta Lake ایک اوپن سورس ڈیٹا سٹوریج کی تہہ ہے جو موجودہ ڈیٹا لیک پر چلتی ہے اور اس کے ساتھ مکمل تعاون کرتی ہے۔ اپاچی چمک APIs ACID ٹرانزیکشنز اور اسکیل ایبل میٹا ڈیٹا ہینڈلنگ کو لاگو کرنے کی صلاحیت کے ساتھ، ڈیلٹا لیکس سٹریمنگ اور بیچ ڈیٹا پروسیسنگ کو بھی متحد کر سکتی ہے۔ 

ڈیلٹا لیک کلاؤڈ میں ڈیٹا ذخیرہ کرنے کے لیے ورژن والی پارکیٹ فائلوں کا استعمال کرتی ہے۔ ایک بار کلاؤڈ لوکیشن کنفیگر ہونے کے بعد، ڈیلٹا لیک ACID ٹرانزیکشنز فراہم کرنے کے لیے ٹیبل یا بلاب اسٹور ڈائرکٹری میں کی گئی تمام تبدیلیوں کو ٹریک کرتا ہے۔ 

ڈیلٹا لیکس کے استعمال کے فوائد 

ڈیلٹا جھیل ہزاروں ڈیٹا کو متوازی طور پر چلنے کی اجازت دیتی ہے، آپٹیمائزیشن اور پارٹیشن چیلنجز کو ایڈریس کرتی ہے، تیز میٹا ڈیٹا آپریشنز، ٹرانزیکشنل لاگ کو برقرار رکھتی ہے اور ڈیٹا کو مسلسل اپ ڈیٹ کرتی رہتی ہے۔ ذیل میں ہم چند اہم فوائد پر بات کرتے ہیں: 

ڈیلٹا لیک ٹرانزیکشن لاگ

ڈیلٹا لیک ٹرانزیکشن لاگز صرف ایک ضمیمہ فائل ہے اور اس میں ڈیلٹا لیک ٹیبل پر کی گئی تمام لین دین کا آرڈرڈ ریکارڈ ہوتا ہے۔ ٹرانزیکشن لاگ مختلف صارفین کو دی گئی میز پر متوازی طور پر پڑھنے اور لکھنے کی اجازت دیتا ہے۔ یہ سچائی کے واحد ذریعہ یا مرکزی ذخیرہ کے طور پر کام کرتا ہے جو صارف کے ذریعہ میز میں کی گئی تمام تبدیلیوں کو لاگ کرتا ہے۔ یہ جوہری صلاحیت کو برقرار رکھتا ہے اور ڈیلٹا جھیل پر ہونے والے لین دین کو مسلسل دیکھتا ہے۔

جیسا کہ اوپر بتایا گیا ہے، اسپارک کسی بھی نئے لین دین کے لیے ڈیلٹا لاگ کو چیک کرتا ہے، جس کے بعد ڈیلٹا لیک اس بات کو یقینی بناتا ہے کہ صارف کا ورژن ہمیشہ ماسٹر ریکارڈ کے ساتھ مطابقت رکھتا ہے۔ یہ اس بات کو بھی یقینی بناتا ہے کہ میز پر کوئی متضاد تبدیلیاں نہیں کی جا رہی ہیں۔ اگر عمل ڈیلٹا لاگ کو اپ ڈیٹ کرنے سے پہلے کریش ہو جاتا ہے، تو فائلیں پڑھنے کے کسی بھی عمل کے لیے دستیاب نہیں ہوں گی کیونکہ ریڈز ہمیشہ ٹرانزیکشن لاگ سے گزرتی ہیں۔

ٹرانزیکشن لاگ ورکنگ اور اٹامک کمٹ

ڈیلٹا جھیل ہر دس کمٹ پر ایک چیک پوائنٹ کرتی ہے۔ چیک پوائنٹ والی فائل میں Parquet فارمیٹ میں ڈیٹا کی موجودہ حالت ہوتی ہے جسے تیزی سے پڑھا جا سکتا ہے۔ جب متعدد صارفین ایک ہی وقت میں ٹیبل میں ترمیم کرنے کی کوشش کرتے ہیں، ڈیلٹا لیک پرامید کنکرنسی کنٹرول کا استعمال کرتے ہوئے تنازعات کو حل کرتی ہے۔

میٹا ڈیٹا کا اسکیما مندرجہ ذیل ہے: 

کالم	قسم	Description
فارمیٹ	سٹرنگ	ٹیبل کی شکل، یعنی "ڈیلٹا"۔
id	سٹرنگ	ٹیبل کی منفرد ID
نام	سٹرنگ	میز کا نام جیسا کہ میٹاسٹور میں بیان کیا گیا ہے۔
تفصیل	سٹرنگ	جدول کی تفصیل۔
محل وقوع	سٹرنگ	میز کا مقام
پر بنایا گیا	ٹائمسٹیمپ	جب میز بنایا گیا تھا۔
آخری ترمیم شدہ	ٹائمسٹیمپ	جب میز میں آخری بار ترمیم کی گئی تھی۔
پارٹیشن کالم	تاروں کی صف	پارٹیشن کالم کے نام اگر ٹیبل تقسیم کیا گیا ہے۔
numFiles	طویل	ٹیبل کے تازہ ترین ورژن میں فائلوں کی تعداد
خصوصیات	سٹرنگ سٹرنگ کا نقشہ	تمام خصوصیات اس ٹیبل کے لیے سیٹ کی گئی ہیں۔
minReaderVersion	int	قارئین کا کم از کم ورژن (لاگ پروٹوکول کے مطابق) جو ٹیبل کو پڑھ سکتے ہیں۔
minWriterVersion	int	قارئین کا کم از کم ورژن (لاگ پروٹوکول کے مطابق) جو ٹیبل پر لکھ سکتے ہیں۔

فائل کو شامل کریں اور ہٹا دیں۔

جب بھی کوئی فائل شامل کی جاتی ہے یا موجودہ فائل کو ہٹا دیا جاتا ہے، یہ اعمال لاگ ان ہوتے ہیں۔ فائل کا راستہ منفرد ہے اور اسے اس کے اندر موجود فائلوں کے سیٹ کے لیے بنیادی کلید سمجھا جاتا ہے۔ جب ٹیبل میں پہلے سے موجود پاتھ پر ایک نئی فائل شامل کی جاتی ہے، تو اس راستے پر موجود اعدادوشمار اور دیگر میٹا ڈیٹا کو پچھلے ورژن سے اپ ڈیٹ کیا جاتا ہے۔ اسی طرح، ہٹانے کی کارروائی ٹائم اسٹیمپ کے ذریعہ اشارہ کی جاتی ہے۔ ہٹانے کی کارروائی میز میں مقبرے کے پتھر کی طرح رہتی ہے جب تک کہ اس کی میعاد ختم نہ ہو جائے۔ ایک مقبرہ کی میعاد ختم ہو جاتی ہے جب TTL (ٹائم ٹو لائیو) سے زیادہ ہو جاتا ہے۔

چونکہ دی گئی ڈیلٹا فائل کے اندر کارروائیوں کے ترتیب میں لاگو ہونے کی ضمانت نہیں ہے، اس لیے یہ ایک ہی ورژن میں ایک ہی راستے کے ساتھ متعدد فائل آپریشنز کے لیے درست نہیں ہے۔

'ایڈ' یا 'ہٹائیں' پر ڈیٹا چینج فلیگ کو غلط پر سیٹ کیا جا سکتا ہے تاکہ ہم آہنگی آپریشنز کے تنازعات کو کم کیا جا سکے۔

ایڈ ایکشن کا سکیما مندرجہ ذیل ہے:

فیلڈ کا نام	ڈیٹا کی قسم	Description
راستہ	سلک	ایک رشتہ دار راستہ، ٹیبل کی جڑ سے، ایک فائل تک جسے ٹیبل میں شامل کیا جانا چاہیے۔
تقسیم کی قدریں	نقشہ[سٹرنگ،سٹرنگ]	اس فائل کے لیے تقسیم کالم سے قیمت تک کا نقشہ۔
سائز	لانگ	بائٹس میں اس فائل کا سائز
ترمیم کا وقت	لانگ	اس فائل کو بننے کا وقت، عہد کے بعد سے ملی سیکنڈ کے طور پر
ڈیٹا کی تبدیلی	بولین	غلط ہونے پر فائل کا پہلے سے ہی ٹیبل میں موجود ہونا ضروری ہے یا شامل فائل میں ریکارڈ اسی ورژن میں ایک یا زیادہ ہٹانے کی کارروائیوں میں ہونا ضروری ہے۔
اعدادوشمار	شماریات کا ڈھانچہ	اس فائل میں ڈیٹا کے بارے میں اعداد و شمار (مثلاً، گنتی، کالم کے لیے کم سے کم/زیادہ سے زیادہ اقدار) پر مشتمل ہے
ٹیگز	نقشہ[سٹرنگ،سٹرنگ]	اس فائل کے بارے میں میٹا ڈیٹا پر مشتمل نقشہ

ہٹانے کی کارروائی کا اسکیما مندرجہ ذیل ہے:

فیلڈ کا نام	ڈیٹا قسم	Description
راستہ	سٹرنگ	کسی فائل کا مطلق یا رشتہ دار راستہ جسے ٹیبل سے ہٹا دیا جانا چاہیے۔
حذف کرنے کا ٹائم اسٹیمپ	طویل	حذف ہونے کا وقت، عہد کے بعد سے ملی سیکنڈز کے طور پر دکھایا گیا ہے۔
ڈیٹا کی تبدیلی	بولین	غلط ہونے پر ہٹائی گئی فائل میں موجود ریکارڈز کو اسی ورژن میں ایک یا زیادہ فائل ایکشنز میں شامل ہونا چاہیے۔
توسیع شدہ فائل میٹا ڈیٹا	بولین	صحیح ہونے پر فیلڈز پارٹیشن ویلیوز، سائز اور ٹیگز موجود ہوتے ہیں۔
تقسیم کی قدریں	نقشہ[سٹرنگ، سٹرنگ]	اس فائل کے لیے تقسیم کالم سے قیمت تک کا نقشہ۔ پارٹیشن ویلیو سیریلائزیشن بھی دیکھیں
سائز	لانگ	بائٹس میں اس فائل کا سائز
ٹیگز	نقشہ[سٹرنگ، سٹرنگ]	اس فائل کے بارے میں میٹا ڈیٹا پر مشتمل نقشہ

میٹا ڈیٹا کا اسکیما ہر ایک ایڈ/ریمو ایکشن پر فائل پاتھ پر مشتمل ہوتا ہے اور اسپارک پڑھنے کے عمل کو فائل لسٹنگ حاصل کرنے کے لیے مکمل اسکین کرنے کی ضرورت نہیں ہوتی ہے۔

اگر کوئی تحریر ٹرانزیکشن لاگ کو اپ ڈیٹ کیے بغیر ناکام ہو جاتی ہے، چونکہ صارف کی ریڈنگ ہمیشہ میٹا ڈیٹا سے گزرتی ہے، اس لیے ان فائلوں کو نظر انداز کر دیا جائے گا۔ 

Spark 3.0 میں منتقل ہونے کے فوائد

ڈیلٹا لیک کے فوائد سے فائدہ اٹھانے کے علاوہ، Spark 3.0 میں منتقل ہونے سے درج ذیل طریقوں سے ڈیٹا پروسیسنگ میں بہتری آئی:

Skewed Join Optimization

ڈیٹا سکیو ایک ایسی حالت ہے جس میں ٹیبل کا ڈیٹا کلسٹر میں پارٹیشنز کے درمیان غیر مساوی طور پر تقسیم کیا جاتا ہے اور سوالات کی کارکردگی کو شدید طور پر گھٹا سکتا ہے، خاص طور پر جوائنز والے۔ ترچھا پن کلسٹر میں انتہائی عدم توازن کا باعث بن سکتا ہے جس سے ڈیٹا پروسیسنگ کا وقت بڑھ جاتا ہے۔

ڈیٹا سکیو حالت کو بنیادی طور پر تین طریقوں سے سنبھالا جا سکتا ہے۔

1. زیادہ یکساں طور پر تقسیم شدہ ڈیٹا پر ہم آہنگی بڑھانے کے لیے کنفیگریشن "spark.sql.shuffle.partitions" کا استعمال۔
2. کنفیگریشن spark.sql.autoBroadcastJoinThreshold کا استعمال کرتے ہوئے براڈکاسٹ ہیش جوائن تھریشولڈ کو ٹیبل کے بائٹس میں زیادہ سے زیادہ سائز تک بڑھانا جسے جوائن کرنے کے دوران تمام ورکر نوڈس پر براڈکاسٹ کرنا ہوتا ہے۔
3. کلیدی سالٹنگ (ایک ہی کلید کو مختلف بنانے کے لیے ترچھی کلیدوں میں سابقہ ​​شامل کریں اور پھر ڈیٹا کی تقسیم کو ایڈجسٹ کریں)۔

اسپارک 3.0 نے نئے انڈیپٹیو ایگزیکیوشن فریم ورک کے ساتھ رن ٹائم کے اعدادوشمار کی بنیاد پر آٹو ہینڈلنگ سکیو جوائن میں ایک اصلاح شامل کی ہے۔

ترچھی تقسیم کی حالت

اسپارک 2.4 کے پچھلے ورژن میں موجود سکیوڈ پارٹیشنز کے چیلنج نے نیٹ ورک کے وقت اور کسی خاص کام کے عمل کے وقت پر بہت زیادہ اثر ڈالا۔ مزید یہ کہ اس سے نمٹنے کے طریقے زیادہ تر دستی تھے۔ Spark 3.0 ان چیلنجوں پر قابو پاتا ہے۔

ٹیڑھی تقسیم کا اثر نیٹ ورک ٹریفک اور ٹاسک کی تکمیل کے وقت پر پڑے گا، کیونکہ اس خاص کام میں کارروائی کے لیے بہت زیادہ ڈیٹا ہوگا۔ آپ کو یہ بھی جاننے کی ضرورت ہے کہ یہ سائبرسیکیوریٹی کو کیسے متاثر کرتا ہے۔ نیٹ ورک ٹریفک کا حجم ایک ایسی چیز ہے جس کا ہیکر فائدہ اٹھاتے ہیں۔.

رن ٹائم میپ کے اعدادوشمار سے ڈیٹا کے سائز اور قطار کی گنتی کے حساب سے سکیوڈ جوائن پارٹیشن کا حساب لگایا جاتا ہے۔

کی اصلاح

مندرجہ بالا جدول سے، ڈیٹا فریم مہمات ڈیٹا فریم تنظیموں کے ساتھ شامل ہوتی ہیں۔ تنظیموں میں سے ایک پارٹیشن (پارٹیشن 0) بڑا اور ترچھا ہے۔ پارٹیشن 0 پچھلے مرحلے (Map-9 سے Map-0) کے 8 نقشوں کا نتیجہ ہے۔ Spark کا OptimizeSkewedJoin قاعدہ پارٹیشن کو 3 میں تقسیم کرے گا اور پھر 3 الگ الگ ٹاسک بنائے گا جن میں سے ہر ایک پارٹیشن 0 سے جزوی پارٹیشن ہے (Map-0 سے Map-2، Map-3 سے Map-5، اور Map-6 سے Map-9) اور کمپینز پارٹیشن 0 کے ساتھ شامل ہو جاتا ہے۔ اس طریقہ کار کے نتیجے میں ٹیبل آرگنائزیشنز کے جزوی پارٹیشنز کی تعداد کے برابر ٹیبل مہمات کے پارٹیشن 0 کو پڑھ کر اضافی لاگت آتی ہے۔

نتیجہ اخذ کریں

ڈیلٹا لیک اور اسپارک 3.0 کا استعمال کرتے ہوئے، ہم نے ایڈ ٹیک فرم کے لیے درج ذیل نتائج کو فعال کیا:

• ڈیٹا پروسیسنگ کا وقت 15 گھنٹے سے کم کر کے 5-6 گھنٹے کر دیا گیا۔
• AWS EMR لاگت میں 50% کمی
• ڈیٹا کے ضائع ہونے اور عمل کی موت کو روکنا جو کہ اکثر ایسا ہوتا تھا جب سسٹم میموری سے باہر ہو جاتا تھا یا سسٹم میں خرابی کی وجہ سے پروسیسنگ رک جاتی تھی۔
• مانیٹرنگ اور الرٹنگ فیچرز انسٹال کیے گئے تھے تاکہ عمل ناکام ہونے کی صورت میں مطلع کیا جا سکے۔
• عمل کے درمیان مکمل آٹومیشن اور انحصار کا انتظام حاصل کرنے کے لیے ایئر فلو کا استعمال کرتے ہوئے آرکیسٹریشن مکمل کریں۔

ماخذ: https://www.smartdatacollective.com/improving-data-processing-with-spark-3-delta-lake/