كيف يتم تقسيم سجلات عملية Hadoop عبر حدود كتلة؟




split mapreduce (4)

أراه على النحو التالي: InputFormat هو المسؤول عن تقسيم البيانات إلى انشقاقات منطقية مع الأخذ في الاعتبار طبيعة البيانات.
لا شيء يمنعه من القيام بذلك ، على الرغم من أنه يمكن أن يضيف وقتًا كبيرًا للوظيفة - سيحدث كل المنطق والقراءة حول حدود الحجم المقسومة المطلوبة في وظيفة.
أبسط سجل إدراك نسق الإدخال هو TextInputFormat. تعمل على النحو التالي (بقدر ما فهمت من التعليمات البرمجية) - تنسيق الإدخال إنشاء انقسامات حسب الحجم ، بغض النظر عن الخطوط ، ولكن LineRecordReader دائماً:
أ) تخطي السطر الأول في التقسيم (أو جزء منه) ، إذا لم يكن هو التقسيم الأول
ب) قراءة سطر واحد بعد حدود التقسيم في النهاية (إذا كانت البيانات متوفرة ، لذلك فهي ليست الانقسام الأخير).

وفقا ل Hadoop - The Definitive Guide

لا تتناسب السجلات المنطقية التي تحددها FileInputFormats بشكل صحيح في كتل HDFS. على سبيل المثال ، السجلات المنطقية لـ TextInputFormat هي خطوط ، والتي سوف تتجاوز حدود HDFS في أكثر الأحيان. لا يؤثر ذلك على أداء برنامجك - فالخطوط لا يتم تفويتها أو كسرها ، على سبيل المثال ، ولكن الأمر يستحق أن تعرف ، لأنه يعني أن خرائط البيانات المحلية (أي الخرائط التي تعمل على نفس المضيف مثل بيانات الإدخال) سوف تؤدي بعض القراءات عن بعد. النفقات العامة الطفيفة هذه الأسباب ليست كبيرة عادة.

لنفترض أن سطرًا قياسيًا مقسم إلى مجموعتين (b1 و b2). سيلاحظ مخطط الخرائط الذي يعالج الكتلة الأولى (b1) أن السطر الأخير لا يحتوي على فاصل EOL وأن يجلب المتبقي من الخط من الكتلة التالية من البيانات (b2).

كيف يقرر مخطط الخرائط الذي يعالج الكتلة الثانية (b2) أن السجل الأول غير مكتمل ويجب أن يبدأ من السجل الثاني في الكتلة (b2)؟


خوارزمية Reduece Map لا تعمل على الكتل الفعلية للملف. وهو يعمل على تقسيم المدخلات المنطقية. يعتمد انقسام الإدخال على مكان كتابة السجل. قد يمتد السجل اثنين من مصممي الخرائط.

الطريقة التي تم بها إعداد HDFS ، تقوم بتقسيم ملفات كبيرة جدًا إلى كتل كبيرة (على سبيل المثال ، قياس 128 ميجابايت) ، وتخزين ثلاث نسخ من هذه الكتل على العقد المختلفة في المجموعة.

لا يتعرف نظام HDFS على محتوى هذه الملفات. قد يكون قد بدأ السجل في Block-a ولكن قد يكون نهاية هذا السجل موجودة في Block-b .

لحل هذه المشكلة ، يستخدم Hadoop تمثيلًا منطقيًا للبيانات المخزنة في كتل الملفات ، والمعروفة باسم انقسامات الإدخال. عندما يقوم عميل مهمة MapReduce بحساب انقسامات الإدخال ، فإنه يستنتج أين يبدأ أول سجل كامل في كتلة وحيث ينتهي السجل الأخير في الكتلة .

النقطة الرئيسية:

في الحالات التي يكون فيها السجل الأخير في كتلة غير مكتمل ، يتضمن تقسيم الإدخال معلومات الموقع للكتلة التالية وإزاحة البايت للبيانات المطلوبة لإكمال السجل.

إلقاء نظرة على الرسم البياني أدناه.

إلقاء نظرة على هذه article وسؤال SE ذات الصلة: حول تقسيم ملف Hadoop / HDFS

يمكن قراءة المزيد من التفاصيل من documentation

يعتمد إطار Map-Reduce على InputFormat للمهمة من أجل:

  1. التحقق من صحة المدخلات-تحديد الوظيفة.
  2. تقسيم ملف (ملفات) الإدخال إلى InputSplits منطقية ، يتم تعيين كل منها إلى مخطط معين.
  3. يتم بعد ذلك تخصيص كل InputSplit لمخطط الخرائط الشخصي للمعالجة. الانقسام يمكن أن يكون tuple . InputSplit[] getSplits(JobConf job,int numSplits ) هي واجهة برمجة التطبيقات (API) للعناية بهذه الأشياء.

FileInputFormat ، والتي تمتد ينفذ getSplits طريقة getSplits (). إلقاء نظرة على internals من هذه الطريقة في grepcode


لا يتعين على مصممي الخرائط الاتصال. كتل الملفات موجودة في HDFS ويمكن أن يقوم مخطط الخرائط الحالي (RecordReader) بقراءة الكتلة التي تحتوي على الجزء المتبقي من الخط. هذا يحدث خلف الكواليس.


من كود مصدر hadoop من LineRecordReader.java المنشئ: أجد بعض التعليقات:

// If this is not the first split, we always throw away first record
// because we always (except the last split) read one extra line in
// next() method.
if (start != 0) {
  start += in.readLine(new Text(), 0, maxBytesToConsume(start));
}
this.pos = start;

من هذا أعتقد أن hadoop سيقرأ سطرًا إضافيًا لكل انقسام (في نهاية التقسيم الحالي ، وقراءة السطر التالي في التقسيم التالي) ، وإذا لم يكن الانقسام الأول ، فسيتم التخلص من السطر الأول. بحيث لا يتم فقد أي سجل خط وغير مكتمل







hdfs