ٹیم پیش کرتا ہے۔ Clairvoyant سے انجینئر راہول بھاٹیہ نے بتایا کہ بگ ڈیٹا میں کون سے فائل فارمیٹس ہیں، ہڈوپ فارمیٹس کی سب سے عام خصوصیات کیا ہیں اور کون سا فارمیٹ استعمال کرنا بہتر ہے۔
مختلف فائل فارمیٹس کی ضرورت کیوں ہے؟
HDFS سے چلنے والی ایپلی کیشنز جیسے MapReduce اور Spark کے لیے کارکردگی کی ایک بڑی رکاوٹ وہ وقت ہے جو ڈیٹا کو تلاش کرنے، پڑھنے اور لکھنے میں لیتا ہے۔ یہ مسائل بڑے ڈیٹا سیٹس کو سنبھالنے میں دشواری کی وجہ سے بڑھ جاتے ہیں اگر ہمارے پاس ایک طے شدہ کی بجائے ایک ابھرتی ہوئی اسکیما ہے، یا اگر ذخیرہ کرنے کی کچھ رکاوٹیں ہیں۔
بڑے ڈیٹا پر کارروائی کرنے سے سٹوریج سب سسٹم پر بوجھ بڑھ جاتا ہے - ہڈوپ فالٹ ٹولرنس حاصل کرنے کے لیے ڈیٹا کو بے کار طریقے سے اسٹور کرتا ہے۔ ڈسک کے علاوہ، پروسیسر، نیٹ ورک، ان پٹ/آؤٹ پٹ سسٹم، اور اسی طرح لوڈ ہوتے ہیں۔ جیسے جیسے ڈیٹا کا حجم بڑھتا ہے، اسی طرح اس کی پروسیسنگ اور ذخیرہ کرنے کی لاگت بھی بڑھتی ہے۔
میں مختلف فائل فارمیٹس خاص طور پر ان مسائل کو حل کرنے کے لئے ایجاد کیا. مناسب فائل فارمیٹ کا انتخاب کچھ اہم فوائد فراہم کر سکتا ہے:
- تیز پڑھنے کا وقت۔
- تیز تر ریکارڈنگ کا وقت۔
- مشترکہ فائلیں۔
- اسکیما ارتقاء کے لیے معاونت۔
- توسیع شدہ کمپریشن سپورٹ۔
کچھ فائل فارمیٹس عام استعمال کے لیے ہیں، دوسرے زیادہ مخصوص استعمال کے لیے، اور کچھ مخصوص ڈیٹا کی خصوصیات کو پورا کرنے کے لیے بنائے گئے ہیں۔ تو انتخاب واقعی کافی بڑا ہے۔
ایورو فائل فارمیٹ
کے لیے ڈیٹا سیریلائزیشن Avro بڑے پیمانے پر استعمال کیا جاتا ہے - یہ تار کی بنیاد پر، یعنی ہڈوپ میں اسٹرنگ ڈیٹا اسٹوریج کی شکل۔ یہ اسکیما کو JSON فارمیٹ میں اسٹور کرتا ہے، جس سے کسی بھی پروگرام کو پڑھنا اور تشریح کرنا آسان ہوجاتا ہے۔ ڈیٹا خود بائنری فارمیٹ میں ہے، کمپیکٹ اور موثر ہے۔
ایورو کا سیریلائزیشن سسٹم لینگویج نیوٹرل ہے۔ فائلوں کو مختلف زبانوں میں پروسیس کیا جا سکتا ہے، فی الحال C، C++، C#، Java، Python اور Ruby۔
ایرو کی ایک اہم خصوصیت ڈیٹا اسکیموں کے لیے اس کا مضبوط تعاون ہے جو وقت کے ساتھ بدلتے رہتے ہیں، یعنی ارتقا۔ Avro اسکیما تبدیلیوں کو سمجھتا ہے — حذف کرنا، شامل کرنا، یا فیلڈز کو تبدیل کرنا۔
ایرو مختلف قسم کے ڈیٹا ڈھانچے کو سپورٹ کرتا ہے۔ مثال کے طور پر، آپ ایک ایسا ریکارڈ بنا سکتے ہیں جس میں ایک صف، ایک شمار شدہ قسم، اور ایک ذیلی ریکارڈ شامل ہو۔
یہ فارمیٹ ڈیٹا لیک کے لینڈنگ (ٹرانزیشن) زون میں لکھنے کے لیے مثالی ہے، یا ڈیٹا جھیل - براہ راست ڈیٹا کے ذرائع کے علاوہ مختلف قسم کے ڈیٹا کو ذخیرہ کرنے کی مثالوں کا مجموعہ)۔
لہذا، یہ فارمیٹ درج ذیل وجوہات کی بناء پر ڈیٹا لیک کے لینڈنگ زون میں لکھنے کے لیے بہترین ہے:
- اس زون کے ڈیٹا کو عام طور پر ڈاون اسٹریم سسٹم کے ذریعے مزید پروسیسنگ کے لیے مکمل طور پر پڑھا جاتا ہے - اور اس معاملے میں قطار پر مبنی فارمیٹ زیادہ موثر ہے۔
- ڈاؤن اسٹریم سسٹم آسانی سے فائلوں سے اسکیما ٹیبلز کو بازیافت کرسکتے ہیں - بیرونی میٹا اسٹوریج میں اسکیموں کو الگ سے اسٹور کرنے کی ضرورت نہیں ہے۔
- اصل اسکیما میں کسی بھی تبدیلی پر آسانی سے کارروائی کی جاتی ہے (اسکیما ارتقاء)۔
پارکیٹ فائل فارمیٹ
Parquet Hadoop کے لیے ایک اوپن سورس فائل فارمیٹ ہے جو اسٹور کرتا ہے۔ فلیٹ کالمی فارمیٹ میں نیسٹڈ ڈیٹا سٹرکچرز.
روایتی قطار کے نقطہ نظر کے مقابلے میں، پارکیٹ اسٹوریج اور کارکردگی کے لحاظ سے زیادہ موثر ہے۔
یہ خاص طور پر ان سوالات کے لیے مفید ہے جو وسیع (بہت سے کالم) ٹیبل سے مخصوص کالم پڑھتے ہیں۔ فائل فارمیٹ کا شکریہ، صرف ضروری کالم پڑھے جاتے ہیں، لہذا I/O کو کم سے کم رکھا جاتا ہے۔
ایک چھوٹا سا اختلاف اور وضاحت: Hadoop میں Parquet فائل فارمیٹ کو بہتر طور پر سمجھنے کے لیے، آئیے دیکھتے ہیں کہ کالم پر مبنی - یعنی کالم - فارمیٹ کیا ہے۔ یہ فارمیٹ ہر کالم کے لیے ایک جیسی اقدار کو ایک ساتھ اسٹور کرتا ہے۔
، ریکارڈ میں ID، نام، اور محکمہ کے فیلڈز شامل ہیں۔ اس صورت میں، تمام ID کالم کی قدریں ایک ساتھ ذخیرہ کی جائیں گی، جیسا کہ نام کالم کی قدریں، وغیرہ۔ ٹیبل کچھ اس طرح نظر آئے گا:
ID
نام
شعبہ
1
emp1
d1
2
emp2
d2
3
emp3
d3
سٹرنگ فارمیٹ میں، ڈیٹا کو اس طرح محفوظ کیا جائے گا:
1
emp1
d1
2
emp2
d2
3
emp3
d3
کالم فائل فارمیٹ میں، وہی ڈیٹا اس طرح محفوظ کیا جائے گا:
1
2
3
emp1
emp2
emp3
d1
d2
d3
کالم فارمیٹ زیادہ کارآمد ہوتا ہے جب آپ کو ایک ٹیبل سے متعدد کالموں سے استفسار کرنے کی ضرورت ہوتی ہے۔ یہ صرف مطلوبہ کالم پڑھے گا کیونکہ وہ ملحقہ ہیں۔ اس طرح، I/O آپریشنز کو کم سے کم رکھا جاتا ہے۔
مثال کے طور پر، آپ کو صرف NAME کالم کی ضرورت ہے۔ میں ڈیٹاسیٹ میں ہر ریکارڈ کو لوڈ کرنے، فیلڈ کے لحاظ سے تجزیہ کرنے، اور پھر NAME ڈیٹا کو نکالنے کی ضرورت ہے۔ کالم فارمیٹ آپ کو براہ راست نام کے کالم میں ڈرل ڈاؤن کرنے کی اجازت دیتا ہے کیونکہ اس کالم کی تمام قدریں ایک ساتھ محفوظ ہوتی ہیں۔ آپ کو پوری ریکارڈنگ کو اسکین کرنے کی ضرورت نہیں ہے۔
اس طرح، کالم فارمیٹ استفسار کی کارکردگی کو بہتر بناتا ہے کیونکہ مطلوبہ کالموں تک پہنچنے کے لیے اسے کم تلاش کرنے کا وقت درکار ہوتا ہے اور I/O آپریشنز کی تعداد کو کم کرتا ہے کیونکہ صرف مطلوبہ کالم پڑھے جاتے ہیں۔
منفرد خصوصیات میں سے ایک کیا اس فارمیٹ میں یہ کر سکتا ہے۔ نیسٹڈ ڈھانچے کے ساتھ ڈیٹا اسٹور کریں۔. اس کا مطلب ہے کہ ایک Parquet فائل میں، نیسٹڈ سٹرکچر میں تمام فیلڈز کو پڑھے بغیر بھی نیسٹڈ فیلڈز کو انفرادی طور پر پڑھا جا سکتا ہے۔ پارکیٹ گھوںسلا ڈھانچے کو ذخیرہ کرنے کے لیے ایک ٹکڑا اور اسمبلی الگورتھم کا استعمال کرتا ہے۔
Hadoop میں Parquet فائل فارمیٹ کو سمجھنے کے لیے، آپ کو درج ذیل شرائط جاننا ہوں گی۔
- قطار گروپ (قطار گروپ): ڈیٹا کی قطاروں میں منطقی افقی تقسیم۔ ایک قطار گروپ ڈیٹا سیٹ میں ہر کالم کے ایک ٹکڑے پر مشتمل ہوتا ہے۔
- کالم کا ٹکڑا (کالم کا حصہ): ایک مخصوص کالم کا ایک ٹکڑا۔ یہ کالم کے ٹکڑے قطاروں کے ایک مخصوص گروپ میں رہتے ہیں اور فائل میں متصل ہونے کی ضمانت دی جاتی ہے۔
- صفحہ (صفحہ): کالم کے ٹکڑے یکے بعد دیگرے لکھے گئے صفحات میں تقسیم ہوتے ہیں۔ صفحات کا ایک مشترکہ عنوان ہے، لہذا آپ پڑھتے وقت غیر ضروری کو چھوڑ سکتے ہیں۔
یہاں عنوان صرف جادوئی نمبر پر مشتمل ہے۔ PAR1 (4 بائٹس) جو فائل کو پارکیٹ فائل کے طور پر شناخت کرتا ہے۔
فوٹر مندرجہ ذیل کہتا ہے:
- فائل میٹا ڈیٹا جس میں ہر کالم کے میٹا ڈیٹا کے ابتدائی نقاط شامل ہیں۔ پڑھتے وقت، آپ کو سب سے پہلے فائل کا میٹا ڈیٹا پڑھنا چاہیے تاکہ دلچسپی کے تمام کالم کے ٹکڑے تلاش کریں۔ اس کے بعد کالم کے حصوں کو ترتیب وار پڑھنا چاہیے۔ دیگر میٹا ڈیٹا میں فارمیٹ ورژن، اسکیما، اور کوئی بھی اضافی کلیدی قدر کے جوڑے شامل ہیں۔
- میٹا ڈیٹا کی لمبائی (4 بائٹس)۔
- جادوئی نمبر PAR1 (4 بائٹس)۔
ORC فائل فارمیٹ
آپٹمائزڈ قطار کالم فائل فارمیٹ (آپٹمائزڈ قطار کالم، ) ڈیٹا کو ذخیرہ کرنے کا ایک بہت موثر طریقہ پیش کرتا ہے اور اسے دوسرے فارمیٹس کی حدود کو دور کرنے کے لیے ڈیزائن کیا گیا تھا۔ ڈیٹا کو بالکل کمپیکٹ شکل میں اسٹور کرتا ہے، جس سے آپ غیر ضروری تفصیلات کو چھوڑ سکتے ہیں - بڑے، پیچیدہ یا دستی طور پر برقرار رکھنے والے اشاریہ جات کی تعمیر کی ضرورت کے بغیر۔
ORC فارمیٹ کے فوائد:
- ایک فائل ہر کام کی آؤٹ پٹ ہوتی ہے، جو NameNode (نام نوڈ) پر بوجھ کو کم کرتی ہے۔
- Hive ڈیٹا کی اقسام کے لیے سپورٹ، بشمول DateTime، اعشاریہ اور پیچیدہ ڈیٹا کی قسمیں (سٹرکچر، فہرست، نقشہ اور یونین)۔
- مختلف RecordReader عمل کے ذریعے ایک ہی فائل کو بیک وقت پڑھنا۔
- مارکر کو اسکین کیے بغیر فائلوں کو تقسیم کرنے کی صلاحیت۔
- فائل فوٹر میں معلومات کی بنیاد پر پڑھنے/لکھنے کے عمل کے لیے زیادہ سے زیادہ ممکنہ ہیپ میموری ایلوکیشن کا تخمینہ۔
- میٹا ڈیٹا کو پروٹوکول بفرز بائنری سیریلائزیشن فارمیٹ میں محفوظ کیا جاتا ہے، جو فیلڈز کو شامل اور ہٹانے کی اجازت دیتا ہے۔
ORC سٹرنگز کے مجموعوں کو ایک فائل میں اسٹور کرتا ہے، اور مجموعے کے اندر، سٹرنگ ڈیٹا کو کالم کی شکل میں اسٹور کیا جاتا ہے۔
ایک ORC فائل فائل کے فوٹر میں لائنوں کے گروپوں کو اسٹور کرتی ہے جنہیں پٹی اور معاون معلومات کہتے ہیں۔ فائل کے آخر میں پوسٹ اسکرپٹ میں کمپریشن پیرامیٹرز اور کمپریسڈ فوٹر کا سائز ہوتا ہے۔
پہلے سے طے شدہ پٹی کا سائز 250 MB ہے۔ اتنی بڑی پٹیوں کی وجہ سے، HDFS سے پڑھنا زیادہ مؤثر طریقے سے انجام دیا جاتا ہے: بڑے ملحقہ بلاکس میں۔
فائل فوٹر فائل میں لین کی فہرست، فی لین قطاروں کی تعداد، اور ہر کالم کے ڈیٹا کی قسم کو ریکارڈ کرتا ہے۔ ہر کالم کے لیے گنتی، کم از کم، زیادہ سے زیادہ اور جمع کی قیمت بھی وہاں لکھی جاتی ہے۔
پٹی کے فوٹر میں سٹریم کے مقامات کی ڈائرکٹری ہوتی ہے۔
ٹیبلز کو اسکین کرتے وقت قطار کا ڈیٹا استعمال کیا جاتا ہے۔
انڈیکس ڈیٹا میں ہر کالم کے لیے کم از کم اور زیادہ سے زیادہ اقدار اور ہر کالم میں قطاروں کی پوزیشن شامل ہوتی ہے۔ ORC اشاریہ جات کا استعمال صرف پٹیوں اور قطاروں کے گروپس کو منتخب کرنے کے لیے کیا جاتا ہے، سوالات کا جواب دینے کے لیے نہیں۔
مختلف فائل فارمیٹس کا موازنہ
Parquet کے مقابلے میں Avro
- Avro ایک قطار سٹوریج کی شکل ہے، جبکہ Parquet کالموں میں ڈیٹا ذخیرہ کرتا ہے۔
- تجزیاتی استفسارات کے لیے پارکیٹ بہتر موزوں ہے، یعنی پڑھنے کے عمل اور استفسار کرنے والا ڈیٹا تحریروں سے کہیں زیادہ موثر ہے۔
- ایورو میں تحریری کارروائیاں پارکیٹ کی نسبت زیادہ موثر طریقے سے انجام دی جاتی ہیں۔
- ایرو سرکٹ کے ارتقاء کے ساتھ زیادہ پختگی کے ساتھ معاملہ کرتا ہے۔ Parquet صرف اسکیما کے اضافے کو سپورٹ کرتا ہے، جبکہ Avro ملٹی فنکشنل ارتقاء کی حمایت کرتا ہے، یعنی کالموں کو شامل کرنا یا تبدیل کرنا۔
- ایک کثیر کالم ٹیبل میں کالموں کے ذیلی سیٹ سے استفسار کرنے کے لیے پارکیٹ مثالی ہے۔ Avro ETL آپریشنز کے لیے موزوں ہے جہاں ہم تمام کالموں سے استفسار کرتے ہیں۔
ORC بمقابلہ پارکیٹ
- پارکیٹ نیسٹڈ ڈیٹا کو بہتر طریقے سے اسٹور کرتا ہے۔
- ORC پش ڈاؤن کی پیش گوئی کرنے کے لیے بہتر موزوں ہے۔
- ORC ACID خصوصیات کو سپورٹ کرتا ہے۔
- ORC ڈیٹا کو بہتر طور پر کمپریس کرتا ہے۔
موضوع پر اور کیا پڑھنا ہے۔:
- .
- .
- .
ماخذ: www.habr.com