Моделът на уплътняване се променя драстично с CDH 5/HBase 0.96. Ето какво трябва да знаете.
Apache HBase е разпределено хранилище за данни, базирано на лог-структурирано дърво за сливане, така че оптималната производителност на четене би дошла от наличието само на един файл на магазин (Семейство колони). Този идеал обаче не е възможен по време на периоди на тежки входящи записи. Вместо това HBase ще се опита да комбинира HFiles, за да намали максималния брой търсения на диск, необходими за четене. Този процес се нарича уплътняване .
Уплътненията избират някои файлове от един магазин в даден регион и ги комбинират. Този процес включва четене на KeyValues във входните файлове и изписване на всички KeyValues, които не са изтрити, са във времето за живот (TTL) и не нарушават броя на версиите. След това новосъздаденият комбиниран файл замества входните файлове в региона.
Сега, когато клиент поиска данни, HBase знае, че данните от входните файлове се съхраняват в един последователен файл на диска - следователно е необходимо само едно търсене, докато преди това може да се изисква едно за всеки файл. Но IO на диска не е безплатен и без внимателно внимание пренаписването на данни отново и отново може да доведе до сериозен прекомерен абонамент за мрежа и диск. С други думи, уплътняването е свързано с търгуване на дисково IO сега за по-малко търсения по-късно.
В тази публикация ще научите повече за използването и последиците от уплътненията в CDH 4, както и за промените в модела на уплътняване в CDH 5 (който ще бъде повторно базиран на HBase 0.96).
Уплътняване в CDH 4
Идеалното уплътняване би избрало файловете, които ще намалят най-много търсения при предстоящи четения, като същевременно ще избере файлове, които ще се нуждаят от най-малко IO. За съжаление, този проблем не може да бъде решен без знания за бъдещето. Като такъв, това е просто идеал, към който HBase трябва да се стреми, а не нещо, което някога е наистина постижимо.
Вместо невъзможния идеал, HBase използва евристика, за да опита да избере кои файлове в магазина вероятно ще бъдат добри кандидати. Файловете се избират въз основа на интуицията, че подобни файлове трябва да се комбинират с подобни файлове – което означава, че файловете с приблизително еднакъв размер трябва да се комбинират.
Правилата по подразбиране в HBase 0.94 (доставка в CDH 4) преглежда списъка с HFiles, опитвайки се да намери първия файл с размер, по-малък от общия размер на всички файлове, умножен по hbase.store.compaction.ratio. След като този файл бъде намерен, HFile и всички файлове с по-малки идентификатори на последователност се избират да бъдат уплътнени.
За случая по подразбиране най-големите файлове са най-старите, този подход работи добре:
Въпреки това, това предположение за корелацията между възрастта и размера на файловете е погрешно в някои случаи, което кара настоящия алгоритъм да избира неоптимално. По-скоро групово заредените файлове могат и понякога се сортират много различно от по-нормално изчистените HFiles, така че те са страхотни примери:
Промени в уплътняването в CDH 5
Уплътненията се промениха значително напоследък. За HBase 0.96 и CDH 5 алгоритъмът за избор на файлове беше направен конфигурируем чрез HBASE-7516 – така че вече е възможно да имате предоставени от потребителя политики за уплътняване. Тази промяна позволява на по-опитни потребители да тестват и повтарят как искат да изпълняват уплътнения.
Алгоритъмът за избор на уплътняване по подразбиране също беше променен на ExploringCompactionPolicy. Тази политика е различна от старата по подразбиране по това, че гарантира, че всеки един файл в предложеното уплътняване е в рамките на даденото съотношение. Освен това, той не просто избира първия набор от файлове, които имат размери в рамките на съотношението на уплътняване; вместо това разглежда всички възможни набори, които не нарушават никакви правила, и след това избира нещо, което изглежда най-въздействащо за най-малко очаквано количество IO. За да направи това, ExploringCompactionPolicy избира уплътняване, което ще премахне най-много файлове в рамките на съотношението и ако има равенство, предпочитание се дава на набора от файлове, които са с по-малък размер:
Планирани са още промени за бъдещи издания, включително уплътняване на нива, уплътняване на райета и уплътняване на базата на нива.
Заключение
За някои случаи на употреба тази работа няма да има никакво въздействие. Това е хубаво нещо, тъй като уплътненията вече бяха доста добре проучени. Въпреки това, за потребители, които имат големи скокове в трафика или които използват насипни товари, тази работа може да доведе до големи подобрения във времето за изчакване на IO и латентността на заявката. За конкретен случай на използване на насипно натоварване наблюдаваме 90% намаление на IO на диска поради уплътнения.
Ето резултати от тестов случай в PerfTestCompactionPolicies на HBase:
Вижте тази работа в CDH 5 (в бета версия към момента на писане), когато става въпрос за клъстер близо до вас.
Допълнително четене:
- Проучване на правилата за уплътняване
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
