يشمل Hadoop المنتجات التي يمكن أن تعمل مع ملفات بتنسيقات مختلفة. لقد بحثت مرارا وتكرارا عن أي تنسيق أفضل. عندما واجهت تنسيق ORC بشكل عشوائي نسبيًا ، أصبحت مهتمة وقراءة (وحتى مشفرة قليلاً) ، وهذا ما فهمته - من الخطأ مقارنة التنسيقات على هذا النحو. بتعبير أدق ، عادة ما تتم مقارنتها ، في رأيي ، بطريقة غير صحيحة. في الواقع ، مقال حول هذا الموضوع ، وكذلك حول تنسيق Apache ORC (من الناحية الفنية) والفرص التي يوفرها.

سأبدأ بالسؤال: ماذا يمكن أن يكون حجم جدول علائقي (بالبايت تقريبًا تقريبًا) ، يتكون من 10 آلاف صف (حقلان صحيحان لكل صف)؟ عادة ما يضعون القات هنا ، ويتم وضع الإجابة تحت القات - سأجيب هنا: 628 بايت. وسوف التفاصيل والتاريخ نقل تحت القط.

كيف بدأ كل شيء: لقد أنشأت مكتبة للعمل مع Apache ORC (راجع الصفحة الرئيسية للمشروع - https://orc.apache.org ) وقمت بتجميع مثالهم الخاص حول الكتابة إلى ORC (لكسر رأسك - نبدأ بما ينجح) كان يحتوي على حقلين و 10 آلاف سطر فيه. لقد بدأت تشغيله - تلقيت ملف orc ، لأنني فعلت ذلك في مكان ما خارج المكتب - فقط في حالة إعادة كتابة المكتبة والملف على محرك أقراص فلاش USB (في عجلة من أمرنا - لم أنظر إلى الحجم ، وأعتقد أن محرك الأقراص المحمول يمكنه التعامل معه).

ولكن بطريقة ما أنا تتوافق بسرعة ... نظرت إلى حجم - 628 بايت. اعتقدت أنه كان خطأ ، جلست وبدأت أفهم. أطلقت الأداة المساعدة لعرض ORC من نفس المكتبة المترجمة - تظهر محتويات الملف أن كل شيء صادق - 10 آلاف سطر. بعد ذلك ، تساءلت كيف يمكن لعشرة آلاف سطر أن تتلاءم مع 628 بايت (كنت أعرف بالفعل القليل عن ORC بحلول ذلك الوقت وأدركت أن هناك أيضًا بيانات وصفية - كان التنسيق مكتفيًا ذاتيًا). متفهم ، حصة.

حول تنسيق ORC

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

سرعة

يمكن أن تكون السرعة مختلفة ، فيما يتعلق بالبيانات - على الأقل سرعة القراءة أو الكتابة (يمكنك التعمق أكثر ، ولكن دعنا نتوقف الآن). نظرًا لأن Hadoop مذكورة صراحة في الشعار أعلاه ، فسننظر أولاً في سرعة القراءة.

للإقتباس أكثر قليلاً من وثائق ORC:

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

سوف أترجم قليلاً:

• تنسيق الأمثل لتدفق قراءة كميات كبيرة
• في الوقت نفسه يحتوي على دعم للبحث السريع عن الخطوط اللازمة
• يتيح لك قراءة البيانات التي تحتاجها فقط

حجم

لم يكن هناك اقتباس ، سأقول بكلماتي الخاصة

• شكل يخزن على النحو الأمثل المعلومات الفوقية
• تحقيق توازن بين تدفق سرعة القراءة والتخزين المضغوط
• دعم مدمج للتخزين الأكثر ضغطًا لقيم الأعمدة

توفير الفرص

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

لنرى الشكل الذي يوفره التنسيق للسرعة والاكتناز.

تخزين العمود والشريط

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

مؤشرات

يتضمن تنسيق ORC مؤشرات تتيح لك تحديد ما إذا كان الشريط (أو بالأحرى ، الأجزاء الشريطية لكل منها 10 آلاف صف ، ما يسمى "مجموعة الصفوف") تحتوي على البيانات التي تبحث عنها أم لا. فهارس مبنية على كل من الأعمدة. هذا يؤثر على سرعة القراءة ، وزيادة الحجم. عند تدفق فهارس القراءة ، بالمناسبة ، لا يمكنك القراءة.

ضغط

يتم تخزين جميع البيانات الوصفية في شكل مضغوط ، وهذا

• معلومات إحصائية وصفية (يسمح لك التنسيق بإعادة إنشاء الجدول المخزن فيه ، بما في ذلك أسماء وأنواع الحقول)
• مؤشرات
• تقسيم المعلومات (إلى خطوط وتيارات)

(أدناه سنرى أن البيانات الوصفية جزء أساسي من الملف)

يتم أيضًا تخزين قيم الأعمدة في شكل مضغوط. في الوقت نفسه ، من الممكن قراءة وفك حزمة البيانات المطلوبة فقط (أي ، لا يتم ضغط الملف وليس الشريط بأكمله). يؤثر الضغط على كل من الحجم وسرعة القراءة.

الترميز

يتم تخزين قيم الأعمدة - ويخزن الملف هذه القيم بالضبط - في شكل مشفر. في الإصدار الحالي من التنسيق (ORC v1) للأعداد الصحيحة ، على سبيل المثال ، تتوفر 4 خيارات تشفير. في الوقت نفسه ، لا يتم تشفير العمود بأكمله ، يتم تشفير أجزاء من العمود ، ويمكن تشفير كل جزء بالطريقة المثلى لهذا الجزء (تسمى هذه الأجزاء "التشغيل" في المواصفات). وبالتالي ، يتم تحقيق الحد الأدنى من الطول الكلي للبيانات المخزنة. مرة أخرى ، التأثير على الحجم والسرعة.

دعونا نرى ملف ORC

دعونا ننظر بإيجاز شديد إلى ما هو داخل ملف ORC (الملف نفسه هو 628 بايت). بالنسبة لأولئك غير المهتمين بالتفاصيل الفنية ، انتقل لأسفل إلى القسم التالي (حول مقارنة التنسيق).

هكذا تم تعريف جدولنا في سجل المثال في ORC:

الفوقية

معلومات حول الأطوال (أعطي لقطات من دفتر jupyter ، أعتقد أنه واضح بما فيه الكفاية)

ما نراه هنا:

• في "عرقوب" (وهذا هو بوستسكريبت + تذييل + بيانات التعريف) فقط 1 + 23 + 115 + 50 = 189 بايت
• في شريط واحد ، فقط 3 + 436 = 439 بايت ، إجمالي 628 بايت
• يحتوي الشريط على فهرس (73 بايت) ، بيانات (276 بايت) ، تذييل (87 بايت)

دعونا نلاحظ هنا نسبة حجم البيانات والبيانات الوصفية (276 إلى 352 بايت). لكن هذه البيانات التي يبلغ عددها 276 بايت ليست أيضًا بيانات فقط ، حيث تحتوي البيانات على القليل من "الزائدة" (هنا من أجل الإيجاز ، لا أعطي لقطات شاشة - إنها فترة طويلة معهم ، وسأديرها فقط مع تعليقاتي) ، والتي يتم تضمينها في البيانات:

• تيارات حالية لكل عمود ، هناك ثلاثة منها (بما في ذلك بنية العمود الزائف الشائعة) - 20 بايت لكل ، إجمالي 60 بايت
• تدفقات البيانات (هنا لا يمثل العمود الزائف) - 103 و 113 بايت (العمودين "x" و "y" ، على التوالي)

التدفقات الحالية عبارة عن سلاسل بت تتيح لك معرفة مكان أعمدة NULL. على سبيل المثال ، يبدو وجودهم غريبًا (في إحصائيات ملفنا مكتوب بشكل واضح أنه لا توجد بيانات فارغة في البيانات - فلماذا تتضمن PRESENT؟ يبدو أنه خطأ ...)

في المجموع ، البيانات نفسها تحتل 216 بايت ، بيانات التعريف - 352.

يمكن أيضًا ملاحظة من البيانات الأولية أن كلا العمودين قد تم ترميزهما باستخدام طريقة DIRECT_V2 (بالنسبة للأعداد الصحيحة ، فهي تسمح بـ 4 أنواع من التمثيلات ، للحصول على تفاصيل أشير إلى المواصفات - إنها موجودة على موقع المشروع على الويب).

معطيات

دعنا نرى (مرة أخرى بدون لقطات شاشة للإيجاز) كيف تتناسب 10 آلاف أرقام مع 103 بايت (للعمود "x"):

• يتم استخدام تشفير دلتا ، حيث تكون المعلمات هي القيمة والخطوة الأولية (يتم تبسيطها قليلاً للإيجاز)
• لدينا دائمًا خطوة واحدة ، القيمة الأولية للتشغيل الأول هي 0 ، ثم 511 ، 1022 ، إلخ.
• المدى (مجموعة من البيانات المشفرة بطريقة واحدة) في حالتنا تحتوي على 511 قيمة (الحد الأقصى للقيمة الممكنة لترميز دلتا)
• يتراوح طول كل تشغيل في الملف من 4 إلى 6 بايت (ينمو طول التشغيل نظرًا لحقيقة أن القيمة الأولية يتم تمثيلها باستخدام متعرج)
• الإجمالي للعمود "x" الذي نحصل عليه في الملف 20 عمليات تشغيل بطول إجمالي يبلغ 103 بايت (راجعت - كل شيء مناسب)

في ختام مراجعة العرض التقديمي لجدولنا البسيط في ملف ، سأقول أن المؤشرات في هذا المثال تتدهور - فهي تشير إلى بداية تدفق البيانات. سوف أتعامل مع الفهارس باستخدام أمثلة واقعية ، وسأقوم على الأرجح بوصفها في مقالة منفصلة.

للمهتمين: تحت الرابط ، يمكنك العثور على دفتر jupyter ، والذي "فهمت" التنسيق الداخلي به. يمكنك استخدامه وتكرار (ملف ORC مرفق أيضًا هناك).

أنا متأكد من أن العديد من القراء "ضائعون" - نعم ، تنسيق ORC ليس بسيطًا (سواء من حيث فهم التفاصيل أو من حيث استخدام الميزات المتوفرة).

حول مقارنة الشكل

الآن دعنا ننتقل إلى النقطة الرئيسية - مقارنة التنسيق غير صحيحة.

عدد مرات مقارنة التنسيقات: دعنا نقارن حجم الملفات بالتنسيق A و B ، وسرعة القراءة (أنواع مختلفة من القراءة - عشوائية ، وتدفق ، وما إلى ذلك) بالتنسيق A و B. قارن ، استنتجنا أن التنسيق A أفضل من التنسيق B.

باستخدام مثال آخر أدوات الضغط (الترميز) المذكورة أعلاه: هل يمكن تشفير البيانات في ORC على النحو الأمثل؟ نعم ، هناك فرص - انظر أعلاه. ولكن فقط كذلك ، لا يمكنك القيام بذلك! يعتمد ذلك على "الكاتب" (كاتب في مصطلحات ORC): في المثال أعلاه ، يمكن للكاتب القيام بذلك. لكن يمكنه أن يكتب مرتين فقط بعشرة آلاف رقم وسيكون هذا صحيحًا أيضًا من حيث الشكل. وبمقارنة التنسيقات "حسب الحجم" ، فإننا لا نقارن التنسيقات فحسب ، وليس التنسيقات بقدر جودة المقارنة الحسابية لأنظمة التطبيق التي تستخدم هذه التنسيقات .

من هو "الكاتب" في Hadoop؟ هناك العديد منها - على سبيل المثال ، Hive ، الذي ينشئ جدولًا يخزن بياناته في ملفات بتنسيق ORC. مقارنة ، على سبيل المثال ، ORC مع الباركيه في Hadoop ، نحن في الواقع تقييم جودة تنفيذ خوارزمية تحويل البيانات المطبقة في خلية. نحن لا نقارن التنسيقات (على هذا النحو).

سمة مهمة من Hadoop

في العالم الترابطي الكلاسيكي ، لم يكن لدينا أي طريقة للتأثير على حجم الجدول في Oracle - لقد تم تخزينه بطريقة أو بأخرى ولم يعرف سوى Oracle. في Hadoop ، يكون الموقف مختلفًا بعض الشيء: يمكننا أن نرى كيف يتم تخزين هذا الجدول أو ذاك (إلى أي مدى تمكن Hive ، على سبيل المثال ، من "ترميزه"). وإذا رأينا أنه يمكن تحسين هذا الأمر ، فلدينا فرصة حقيقية لذلك: لإنشاء ملف ORC الأمثل الخاص بنا وإعطاءه لـ Hive كجدول خارجي.

قارن ORC و QVD

لقد وصفت مؤخرًا تنسيق QVD الذي يستخدمه QlikVew / QlikSense بنشاط. دعونا نوضح بإيجاز شديد هذين التنسيقين من حيث القدرات التي توفرها لتحقيق أقصى سرعة قراءة وتقليل الحجم. موصوفة قدرات ORC أعلاه ، كما هو الحال في QVD:

تخزين العمود

يمكن اعتبار QVD تنسيقًا "عموديًا" ، وليس هناك ازدواجية في قيم الأعمدة - يتم تخزين القيم الفريدة مرة واحدة. لكنه لا يسمح بمعالجة متوازية - أولاً ، تحتاج إلى قراءة قيم جميع الأعمدة بالكامل ، ثم يمكنك قراءة الصفوف بشكل متواز.

وهناك ازدواجية في مستوى الصف - تخزن الصفوف قيم فهرس مكررة في جدول أحرف.

ضغط

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

مؤشرات

لا توجد وسيلة لفهم ملف QVD في أي جزء منه يحتاج إلى قراءته. في الممارسة العملية ، يجب عليك تحليل بايت جدول البايت (كل!) ، وليس بطريقة فعالة للغاية ...

الترميز

لا يتم استخدام الترميز في QVD ، فمن الممكن رسم تشبيه لمؤشر البتات في جدول من السلاسل مع الترميز ، لكن هذا القياس "يتم تعويضه" عن طريق مضاعفة الأرقام بسلاسل في جداول الأحرف (للحصول على التفاصيل ، راجع المقالة ، باختصار - يتم تمثيل قيمة العمود باختصار في السلسلة والأرقام).

الاستنتاج بشأن هذه المقارنة القصيرة التي توصلت إليها شخصيًا هو هذا - تنسيق QVD عمليًا لا يحتوي على إمكانات تتيح تخزينًا مضغوطًا وقراءة سريعة للبيانات الموجودة في ملفات هذا التنسيق.

(بدا الأمر مهينًا بطريقة ما بالنسبة لـ QVD ، سأضيف قليلاً - تم إنشاء التنسيق منذ وقت طويل ، يتم استخدام QlikView / QlikSense فقط ، ويقومون "بتخزين" جميع البيانات الموجودة في الذاكرة. أعتقد أن ملف QVD يقرأ ببساطة "كما هي" في الذاكرة ، ومن ثم ، فإن هذه المنتجات الرائعة من جميع النواحي تعمل بسرعة كبيرة مع هذا العرض التقديمي - هنا هم أسياد ...)

بدلا من الاستنتاج

انتقد ولم يعرض أي شيء حتى الآن ... - أقترح.

يبدو لي أن التنسيقات يجب مقارنتها ليس بمثال تنفيذها المحدد ، فالأشكال تحتاج إلى المقارنة من حيث الأدوات المتضمنة فيها والقدرة على استخدام هذه الأدوات لحل مشاكلنا المحددة. تتزايد سرعة المعالجات باستمرار ، والآن يمكننا تحمل تكلفة أي خوارزميات تحويل بيانات تقريبًا بعد قراءتها - على أي حال ، ستكون القراءة من القرص أبطأ. هذا هو السبب في أن "الوسائل التعبيرية" للتنسيقات مهمة.

أعلاه ، قمت بإيجاز بإدراج إمكانات تنسيق ORC في رأيي. ما زلت لا أحصل على إحصائيات حول كيفية عمل الأشياء (أي من هذه الميزات وإلى أي مدى تستخدم Hive ، على سبيل المثال). عندما يظهر - سأكتب. تتمثل الخطط الفورية في إجراء مراجعة مماثلة لتنسيق تخزين مشهور آخر - الباركيه.

حسنًا - وفي الختام - يوجد في العالم الحديث الكثير من المعلومات ، للأسف ، جزء من هذه المعلومات سطحي للغاية. لن نستسلم ، سننظر إلى الجوهر.