Научете за дизайнерските решения зад новата поддръжка на HBase за MOB.
Apache HBase е разпределена, мащабируема, производителна, последователна база данни с ключови стойности, която може да съхранява различни видове двоични данни. Той се отличава със съхраняването на много относително малки стойности (<10K) и осигуряването на четене и запис с ниска латентност.
Въпреки това има нарастващо търсене за съхранение на документи, изображения и други умерени обекти (MOB) в HBase, като същевременно се поддържа ниска латентност за четене и запис. Един такъв случай на използване е банка, която съхранява подписани и сканирани клиентски документи. Като друг пример транспортните агенции може да искат да съхраняват моментни снимки на трафика и движещите се автомобили. Тези MOB обикновено се записват еднократно.
За съжаление, производителността може да се влоши в ситуации, при които много стойности с умерен размер (100K до 10MB) се съхраняват поради непрекъснато нарастващото I/O налягане, създадено от уплътненията. Помислете за случая, когато 1TB снимки от камери за трафик, всяка с размер 1MB, се съхраняват в HBase всеки ден. Части от съхранените файлове се уплътняват многократно чрез малки уплътнения и в крайна сметка данните се пренаписват чрез големи уплътнения. Заедно с натрупването на тези MOB, I/O, създаден от уплътненията, ще забави уплътненията, ще блокира допълнително прочистването на memstore и евентуално ще блокира актуализациите. Голям MOB магазин ще предизвика често разделяне на региони, намалявайки наличността на засегнатите региони.
За да се справят с тези недостатъци, инженерите на Cloudera и Intel са внедрили поддръжка на MOB в клон на HBase (hbase-11339:HBase MOB). Този клон ще бъде обединен с главния в HBase 1.1 или 1.2 и вече присъства и се поддържа и в CDH 5.4.x.
Операциите върху MOB обикновено са интензивни за запис, с редки актуализации или изтривания и сравнително рядко четене. MOB обикновено се съхраняват заедно с техните метаданни. Метаданните, свързани с MOB, могат да включват например номер на автомобила, скорост и цвят. Метаданните са много малки в сравнение с MOB. Метаданните обикновено са достъпни за анализ, докато MOB обикновено се достъпват на случаен принцип само когато са изрично поискани с ключове за редове.
Потребителите искат да четат и записват MOBs в HBase с ниска латентност в същите API и искат силна последователност, сигурност, моментна снимка и репликация на HBase между клъстери и т.н. За да се постигнат тези цели, MOBs бяха преместени от главния I/O път на HBase в нов I/O път.
В тази публикация ще научите за този подход на проектиране и защо е избран.
Възможни подходи
Имаше няколко възможни подхода към този проблем. Първият подход, който разгледахме, беше да съхраняваме MOBs в HBase с настроени политики за разделяне и уплътняване – по-голям желан MaxFileSize намалява честотата на разделяне на региона и по-малко или никакво уплътняване може да избегне наказанието за усилване при запис. Този подход би подобрил значително забавянето на запис и пропускателната способност. Въпреки това, заедно с нарастващия брой съхранени файлове, ще има твърде много отворени четци в един магазин, дори повече от това, което е разрешено от ОС. В резултат на това ще се изразходва много памет и производителността на четене ще се влоши.
Друг подход беше да се използва модел HBase + HDFS за съхраняване на метаданните и MOB отделно. В този модел един файл е свързан чрез запис в HBase. Това е клиентско решение и транзакцията се контролира от клиента - не се консумират памети от страна на HBase от MOB. Този подход би работил за обекти по-големи от 50MB, но за MOB много малки файлове водят до неефективно използване на HDFS, тъй като размерът на блока по подразбиране в HDFS е 128MB.
Например, да кажем, че NameNode има 48 GB памет и всеки файл е 100 KB с три реплики. Всеки файл заема повече от 300 байта в паметта, така че NameNode с 48GB памет може да побере около 160 милиона файла, което би ни ограничило до съхраняване само на 16TB MOB файлове общо.
Като подобрение бихме могли да сглобим малките MOB файлове в по-големи – тоест файлът може да има множество MOB записи – и да съхраняваме отместването и дължината в таблицата HBase за бързо четене. Поддържането на последователност на данните и управлението на изтрити MOB и малки MOB файлове в уплътнения са трудни.
Освен това, ако използваме този подход, ще трябва да обмислим нови политики за сигурност, да загубим свойствата за атомарност на записите и потенциално да загубим архивирането и възстановяването след бедствие, предоставени от репликация и моментни снимки.
HBase MOB дизайн
В крайна сметка, тъй като повечето от притесненията около съхраняването на MOBs в HBase включват I/O, създадени от уплътненията, ключът беше да се преместят MOBs извън управлението от нормални региони, за да се избегне разделяне на региони и уплътняване там.
Дизайнът на HBase MOB е подобен на подхода HBase + HDFS, защото съхраняваме метаданните и MOB отделно. Разликата обаче се крие в дизайна от страна на сървъра:memstore кешира MOB-овете, преди те да бъдат прехвърлени на диск, MOB-овете се записват в HFile, наречен „MOB файл” при всяко изтриване и всеки MOB файл има множество записи вместо един файл в HDFS за всеки MOB. Този MOB файл се съхранява в специален регион. Цялото четене и запис може да се използва от текущите API на HBase.
Пишете и четете
Всяка MOB има праг:ако дължината на стойността на клетка е по-голяма от този праг, тази клетка се счита за MOB клетка.
Когато MOB клетките се актуализират в регионите, те се записват в WAL и memstore, точно както нормалните клетки. При изтриване, MOB файловете се прехвърлят към MOB файлове, а метаданните и пътищата на MOB файловете се изтриват, за да се съхраняват файлове. Последователността на данните и функциите за репликация на HBase са естествени за този дизайн.
Редакциите на MOB са по-големи от обикновено. При синхронизирането съответният I/O също е по-голям, което може да забави синхронизиращите операции на WAL. Ако има други региони, които споделят същия WAL, латентността при запис на тези региони може да бъде засегната. Въпреки това, ако са необходими последователност на данните и непроменливост, WAL е задължителен.
На клетките е разрешено да се движат между съхранени файлове и MOB файлове в уплътненията чрез промяна на прага. Прагът по подразбиране е 100 КБ.
Както е илюстрирано по-долу, клетките, които съдържат пътищата на MOB файловете, се наричат референтни клетки . Таговете се запазват в клетките, така че можем да продължим да разчитаме на механизма за защита на HBase.
Референтните клетки имат референтни тагове, които ги отличават от нормалните клетки. Референтният маркер предполага MOB клетка в MOB файл и по този начин е необходимо допълнително разрешаване при четене.
При четене скенерът на магазина отваря скенери за memstore и съхранява файлове. Ако е изпълнена референтна клетка, скенерът чете пътя на файла от стойността на клетката и търси същия ключ на реда от този файл. Блоковият кеш може да бъде активиран за MOB файловете в сканиране, което може да ускори търсенето.
Не е необходимо да отваряте четци за всички MOB файлове; само един е необходим, когато е необходимо. Това произволно четене не се влияе от броя на MOB файловете. Така че не е необходимо да уплътняваме MOB файловете отново и отново, когато са достатъчно големи.
Името на MOB файла е четливо и се състои от три части:MD5 на стартовия ключ, последната дата на клетките в този MOB файл и UUID. Първата част е стартовият ключ на региона, откъдето се изтрива този MOB файл. Обикновено MOB имат дефиниран от потребителя TTL, така че можете да намерите и изтриете MOB файлове с изтекъл срок, като сравните втората част с TTL.
Моментна снимка
За да бъдат по-удобни за моментната снимка, MOB файловете се съхраняват в специална фиктивна област, при която моментната снимка, експортирането/клонирането на таблицата и архивът работят според очакванията.
Когато съхранявате моментна снимка в таблица, човек създава MOB региона в моментната снимка и добавя съществуващите MOB файлове в манифеста. Когато възстановявате моментната снимка, създайте връзки към файлове в MOB региона.
Почистване и уплътняване
Има две ситуации, когато MOB файловете трябва да бъдат изтрити:когато MOB файлът е изтекъл и когато MOB файлът е твърде малък и трябва да се обедини в по-големи, за да се подобри ефективността на HDFS.
HBase MOB има работа в master:сканира MOB файловете, намира изтеклите, определени от датата в името на файла, и ги изтрива. По този начин дисковото пространство се възстановява периодично чрез стареене на изтекли MOB файлове.
MOB файловете може да са сравнително малки в сравнение с HDFS блок, ако пишете редове, където само няколко записа се квалифицират като MOB; също така може да има изтрити клетки. Трябва да пуснете изтритите клетки и да обедините малките файлове в по-големи, за да подобрите използването на HDFS. MOB уплътняванията уплътняват само малките файлове и големите файлове не се докосват, което избягва многократното уплътняване до големи файлове.
Някои други неща, които трябва да имате предвид:
- Разберете кои клетки са изтрити. При всяко основно уплътняване на HBase маркерите за изтриване се записват във файл del, преди да бъдат изхвърлени.
- В първата стъпка от MOB уплътненията тези del файлове се обединяват в по-големи.
- Избрани са всички малки MOB файлове. Ако броят на малките файлове е равен на броя на съществуващите MOB файлове, това уплътняване се счита за основно и се нарича ALL_FILES уплътняване.
- Тези избрани файлове са разделени по началния ключ и датата в името на файла. Малките файлове във всеки дял се уплътняват с del файлове, така че изтритите клетки могат да бъдат изтрити; Междувременно се генерира нов HFile с нови референтни клетки, компакторът записва новия MOB файл и след това групово зарежда този HFile в HBase.
- След приключване на уплътненията във всички дялове, ако е включено ALL_FILES уплътняване, del файловете се архивират.
Жизненият цикъл на MOB файловете е илюстриран по-долу. По принцип те се създават, когато memstore се изтрива и се изтриват от HFileCleaner от файловата система, когато не са посочени от моментната снимка или са изтекли в архива.
Заключение
В обобщение, новият дизайн на HBase MOB измества MOB от главния вход/изход на HBase, като същевременно запазва повечето функции за сигурност, уплътняване и моментно снимане. Той се грижи за характеристиките на операциите в MOB, прави усилването при запис на MOB по-предвидимо и поддържа ниски латентности както при четене, така и при писане.
Jincheng Du е софтуерен инженер в Intel и сътрудник на HBase.
Jon Hsieh е софтуерен инженер в Cloudera и член на HBase committer/PMC. Той също така е основател на Apache Flume и сътрудник на Apache Sqoop.
