نصائح Apache HBase في Azure HDInsight

توضح هذه المقالة العديد من النصائح لمساعدتك على تحسين أداء Apache HBase في Azure HDInsight.

تحسين HBase لقراءة أحدث البيانات المكتوبة

إذا كانت حالة الاستخدام الخاصة بك تتضمن قراءة أحدث البيانات المكتوبة من HBase، يمكن أن تساعدك هذه النصائح الإرشادية. للحصول على أداء عال، من الأمثل أن يتم تقديم قراءات HBase من memstore، بدلا من التخزين البعيد.

تشير النصائح الإرشادية للاستعلام إلى أنه بالنسبة لعائلة أعمدة معينة في جدول > ، يقرأ 75٪ يتم تقديمها من memstore. يشير هذا المؤشر إلى أنه حتى إذا حدث تدفق على memstore الملف الأخير يجب الوصول إليه ويجب أن يكون في ذاكرة التخزين المؤقت. تتم كتابة البيانات أولا إلى memstore النظام للوصول إلى البيانات الأخيرة هناك. من المحتمل أن تكتشف مؤشرات ترابط مسح HBase الداخلي أن منطقة معينة قد وصلت إلى حجم 128 ميغابايت (افتراضي) ويمكن أن تؤدي إلى المسح. يحدث هذا السيناريو حتى لأحدث البيانات التي تمت كتابتها عندما memstore كان حجمها حوالي 128M. لذلك، قد تتطلب قراءة لاحقة لهذه السجلات الأخيرة قراءة ملف بدلا من memstore. ومن ثم من الأفضل تحسين إمكانية وجود حتى البيانات الحديثة التي تم مسحها مؤخرا في ذاكرة التخزين المؤقت.

لتحسين أحدث البيانات في ذاكرة التخزين المؤقت، خذ بعين الاعتبار إعدادات التكوين التالية:

1. عيّن hbase.rs.cacheblocksonwrite إلى true. هذا التكوين الافتراضي في HDInsight HBase هو true، لذا تحقق من عدم إعادة تعيينه إلى false.

2. قم بزيادة قيمة hbase.hstore.compactionThreshold بحيث يمكنك تجنب الضغط من الحركة. تكون هذه القيمة افتراضيًا هي 3. يمكنك زيادتها إلى قيمة أعلى مثل 10.

3. إذا اتبعت الخطوة 2 وعينت حد الضغط، قم بتغيير hbase.hstore.compaction.max إلى قيمة أعلى، على سبيل المثال 100، ثم قم أيضا بزيادة قيمة التكوين hbase.hstore.blockingStoreFiles إلى قيمة أعلى، على سبيل المثال 300.

4. إذا كنت متأكدًا من أنك تحتاج إلى قراءة البيانات الحديثة فقط، قم بتعيين التكوين hbase.rs.cachecompactedblocksonwrite على تشغيل. يخبر هذا التكوين النظام أنه حتى في حالة حدوث ضغط، تبقى البيانات في ذاكرة التخزين المؤقت. يمكن تعيين التكوينات على مستوى العائلة أيضًا.

   في Shell HBase، قم بتشغيل الأمر التالي لتعيين التكوين hbase.rs.cachecompactedblocksonwrite:

   alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
   

5. يمكن إيقاف تشغيل ذاكرة التخزين المؤقت للكتلة لعائلة معينة في جدول. تأكد من تشغيلها للعائلات التي لديها أحدث قراءة للبيانات. بشكل افتراضي، يتم تشغيل ذاكرة التخزين المؤقت للكتلة لكافة العائلات في الجدول. في حالة تعطيل ذاكرة التخزين المؤقت للكتلة لعائلة وتحتاج إلى تشغيلها، استخدم أمر التعديل من hbase shell.

   تساعد هذه التكوينات على ضمان توفر البيانات في ذاكرة التخزين المؤقت وأن البيانات الأخيرة لا تخضع للضغط. إذا كان TTL ممكنا في السيناريو الخاص بك، خذ بعين الاعتبار استخدام الضغط على مستوى التاريخ. لمزيد من المعلومات، راجع دليل Apache HBase المرجعي: الضغط على مستوى التاريخ

تحسين قائمة انتظار المسح

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

في واجهة مستخدم خادم المنطقة، لاحظ إذا كانت قائمة انتظار المسح تزداد لأكثر من 100. يشير هذا الحد إلى أن التدفقات بطيئة وقد تضطر إلى ضبط تكوين hbase.hstore.flusher.count. تكون القيمة 2 بشكل افتراضي. تأكد من أن أقصى حد لمؤشرات ترابط المسح لا تزيد عن 6.

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

ضبط عدد المناطق

تشير النصائح الخاصة بضبط عدد المناطق إلى أن HBase قد حظر التحديثات، وقد يكون عدد المناطق أكبر من حجم كومة الذاكرة المؤقتة المعتمدة بشكل أمثل. يمكنك ضبط حجم memstore كومة الذاكرة المؤقتة وحجمها وعدد المناطق.

وعلى سبيل المثال السيناريو التالي:

• افترض أن حجم كومة الذاكرة المؤقتة لخادم المنطقة هو 10 غيغابايت. افتراضيا hbase.hregion.memstore.flush.size هو 128M. القيمة الافتراضية لـ hbase.regionserver.global.memstore.size هي 0.4. مما يعني أنه من بين 10 غيغابايت، يتم تخصيص 4 غيغابايت ( memstore عالميا).

• افترض أن هناك توزيع متساو لتحميل الكتابة على كافة المناطق وبافتراض أن كل منطقة تنمو حتى 128 ميغابايت فقط، فإن الحد الأقصى لعدد المناطق في هذا الإعداد هو 32 من المناطق. إذا تم تكوين خادم منطقة معينة لـ 32 منطقة، من الأفضل أن يتجنب النظام حظر التحديثات.

• مع وجود هذه الإعدادات، يكون عدد من المناطق هو 100. يتم الآن تقسيم السعة العمومية memstore التي تبلغ 4 غيغابايت عبر 100 منطقة. لذلك تحصل كل منطقة بشكل فعال على 40 ميغابايت فقط ل memstore. عندما تكون عمليات الكتابة موحدة، يقوم النظام بعمليات مسح متكررة ويصغر حجم الطلب < 40 ميغابايت. قد يؤدي وجود العديد من مؤشرات ترابط المسح إلى زيادة سرعة المسح hbase.hstore.flusher.count.

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

ضبط قائمة انتظار الضغط

إذا زادت قائمة انتظار ضغط HBase إلى أكثر من 2000 وحدث ذلك بشكل دوري، يمكنك زيادة مؤشرات ترابط الضغط إلى قيمة أكبر.

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

تحقق من التكوينات hbase.hstore.compaction.throughput.lower.bound وhbase.hstore.compaction.throughput.higher.bound. إذا تم تعيينها بالفعل إلى 50M و100M، فاتركها كما هي. ومع ذلك، إذا قمت بتكوين هذه الإعدادات إلى قيمة أقل (وهو ما كان عليه الحال مع أنظمة المجموعات القديمة) ، قم بتغيير الحدود إلى 50 ميغابايت و100 ميغابايت على التوالي.

التكوينات hbase.regionserver.thread.compaction.small وhbase.regionserver.thread.compaction.large (الإعدادات الافتراضية هي 1 لكل منهما). اجعل الحد الأقصى لقيمة هذا التكوين أقل من 3.

فحص الجدول الكامل

تشير نصيحة فحص الجدول الكامل إلى أن أكثر من 75% من عمليات المسح الصادرة هي عمليات فحص كامل للجدول/المنطقة. يمكنك إعادة النظر في الطريقة التي تستدعي بها التعليمات البرمجية عمليات الفحص لتحسين أداء الاستعلام. خذ بعين الاعتبار الممارسات التالية:

• تعيين البداية المناسبة ووقف الصف لكل عملية فحص.

• استخدم واجهة برمجة تطبيقات MultiRowRangeFilter بحيث يمكنك الاستعلام عن نطاقات مختلفة في مكالمة فحص واحدة. لمزيد من المعلومات، راجع وثائق واجهة برمجة تطبيقات MultiRowRangeFilter.

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

  scan#setCaching(false)
  

الخطوات التالية

تحسين Apache HBase باستخدام Ambari