Како да ја зголемите брзината на читање од HBase до 3 пати и од HDFS до 5 пати

Високите перформанси се еден од клучните барања при работа со големи податоци. Во одделот за вчитување податоци во Сбербанк, ги вметнуваме речиси сите трансакции во нашиот облак на податоци базиран на Hadoop и затоа се справуваме со навистина големи текови на информации. Секако, ние секогаш бараме начини да ги подобриме перформансите и сега сакаме да ви кажеме како успеавме да ги закрпиме RegionServer HBase и клиентот HDFS, благодарение на што можевме значително да ја зголемиме брзината на операциите за читање.


Сепак, пред да преминете на суштината на подобрувањата, вреди да се зборува за ограничувања кои, во принцип, не можат да се заобиколат ако седите на HDD.

Зошто HDD и брзото читање со случаен пристап се некомпатибилни
Како што знаете, HBase и многу други бази на податоци, складираат податоци во блокови со големина од неколку десетици килобајти. Стандардно е околу 64 KB. Сега да замислиме дека треба да добиеме само 100 бајти и бараме од HBase да ни ги даде овие податоци користејќи одреден клуч. Бидејќи големината на блокот во HFiles е 64 KB, барањето ќе биде 640 пати поголемо (само една минута!) отколку што е потребно.

Следно, бидејќи барањето ќе оди преку HDFS и неговиот механизам за кеширање на метаподатоци ShortCircuitCache (што овозможува директен пристап до датотеките), ова води до читање веќе 1 MB од дискот. Сепак, ова може да се прилагоди со параметарот dfs.client.read.shortcircuit.buffer.size и во многу случаи има смисла да се намали оваа вредност, на пример на 126 KB.

Да речеме дека го правиме ова, но дополнително, кога почнуваме да читаме податоци преку java api, како што се функциите како FileChannel.read и бараме од оперативниот систем да ја прочита одредената количина на податоци, тој чита „за секој случај“ 2 пати повеќе , т.е. 256 KB во нашиот случај. Ова е затоа што Java нема лесен начин да го постави знамето FADV_RANDOM за да го спречи ова однесување.

Како резултат на тоа, за да ги добиете нашите 100 бајти, 2600 пати повеќе се читаат под хаубата. Се чини дека решението е очигледно, ајде да ја намалиме големината на блокот на килобајт, да го поставиме споменатото знаме и да добиеме големо просветлувачко забрзување. Но, проблемот е што со намалување на големината на блокот за 2 пати, го намалуваме и бројот на читани бајти по единица време за 2 пати.

Може да се добие одредена добивка од поставувањето на знамето FADV_RANDOM, но само со висока мулти-нишка и со големина на блок од 128 KB, но ова е максимум неколку десетици проценти:

Тестовите беа извршени на 100 датотеки, секоја со големина од 1 GB и лоцирани на 10 HDD.

Ајде да пресметаме на што можеме, во принцип, да сметаме со оваа брзина:
Да речеме дека читаме од 10 дискови со брзина од 280 MB/s, т.е. 3 милиони пати 100 бајти. Но, како што се сеќаваме, податоците што ни се потребни се 2600 пати помалку од прочитаните. Така, 3 милиони делиме со 2600 и добиваме 1100 записи во секунда.

Депресивно, нели? Тоа е природата Случаен пристап пристап до податоци на HDD - без оглед на големината на блокот. Ова е физичката граница на случаен пристап и ниту една база на податоци не може да притисне повеќе под такви услови.

Како тогаш базите на податоци постигнуваат многу поголеми брзини? За да одговориме на ова прашање, да погледнеме што се случува на следната слика:

Овде гледаме дека за првите неколку минути брзината е навистина околу илјада рекорди во секунда. Сепак, понатаму, поради фактот што се чита многу повеќе отколку што се барало, податоците завршуваат во buff/cache на оперативниот систем (linux) и брзината се зголемува на попристојни 60 илјади во секунда.

Така, понатаму ќе се занимаваме со забрзување на пристапот само до податоците што се во кешот на ОС или се наоѓаат во уреди за складирање SSD/NVMe со споредлива брзина на пристап.

Во нашиот случај, ќе спроведеме тестови на клупа од 4 сервери, од кои секој се наплаќа на следниов начин:

Процесор: Xeon E5-2680 v4 @ 2.40 GHz 64 нишки.
Меморија: 730 GB.
Java верзија: 1.8.0_111

И тука клучната точка е количината на податоци во табелите што треба да се прочитаат. Факт е дека ако читате податоци од табела што е целосно сместена во кешот HBase, тогаш нема да дојде ни до читање од баф/кешот на оперативниот систем. Бидејќи HBase стандардно доделува 40% од меморијата на структура наречена BlockCache. Во суштина ова е ConcurrentHashMap, каде што клучот е името на датотеката + поместување на блокот, а вредноста е вистинскиот податок на ова поместување.

Така, кога читаме само од оваа структура, ние гледаме одлична брзина, како милион барања во секунда. Но, да замислиме дека не можеме да одвоиме стотици гигабајти меморија само за потребите на базата на податоци, бидејќи има многу други корисни работи кои работат на овие сервери.

На пример, во нашиот случај, обемот на BlockCache на еден RS е околу 12 GB. Слетавме два РС на еден јазол, т.е. 96 GB се распределени за BlockCache на сите јазли. И има многу пати повеќе податоци, на пример нека бидат 4 табели, по 130 региони, во кои датотеките се со големина од 800 MB, компресирани со FAST_DIFF, т.е. вкупно 410 GB (ова се чисти податоци, т.е. без да се земе предвид факторот на репликација).

Така, BlockCache е само околу 23% од вкупниот волумен на податоци и ова е многу поблиску до реалните услови на она што се нарекува BigData. И тука започнува забавата - бидејќи очигледно, колку помалку хитови на кешот, толку е полоша изведбата. На крајот на краиштата, ако пропуштите, ќе треба да направите многу работа - т.е. одете до повикување на функциите на системот. Сепак, ова не може да се избегне, па да погледнеме сосема поинаков аспект - што се случува со податоците во кешот?

Да ја поедноставиме ситуацијата и да претпоставиме дека имаме кеш што одговара само на 1 објект. Еве пример за тоа што ќе се случи кога ќе се обидеме да работиме со волумен на податоци 3 пати поголем од кешот, ќе мораме:

1. Ставете го блокот 1 во кешот
2. Отстранете го блокот 1 од кешот
3. Ставете го блокот 2 во кешот
4. Отстранете го блокот 2 од кешот
5. Ставете го блокот 3 во кешот

Завршени 5 акции! Сепак, оваа ситуација не може да се нарече нормална, всушност, ја тераме HBase да направи еден куп сосема бескорисна работа. Постојано ги чита податоците од кешот на оперативниот систем, ги става во BlockCache, за да ги исфрли речиси веднаш бидејќи пристигна нов дел од податоците. Анимацијата на почетокот на објавата ја покажува суштината на проблемот - собирачот на ѓубре се намалува, атмосферата се вжештува, малата Грета во далечната и жешка Шведска се вознемирува. И ние, информатичарите, навистина не сакаме кога децата се тажни, па почнуваме да размислуваме што можеме да направиме за тоа.

Што ако не ги ставите сите блокови во кешот, туку само одреден процент од нив, за да не се прелее кешот? Да почнеме со едноставно додавање на само неколку линии код на почетокот на функцијата за ставање податоци во BlockCache:

  public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
    if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
      if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
        return;
      }
    }
...

Поентата овде е следна: поместување е позицијата на блокот во датотеката и неговите последни цифри се случајно и рамномерно распоредени од 00 до 99. Затоа, ќе ги прескокнеме само оние што спаѓаат во опсегот што ни треба.

На пример, поставете cacheDataBlockPercent = 20 и видете што ќе се случи:

Резултатот е очигледен. На графиконите подолу, станува јасно зошто дошло до такво забрзување - заштедуваме многу ресурси на GC без да ја извршиме сизифовската работа за ставање податоци во кешот само за веднаш да ги фрлиме во одводот на марсовските кучиња:

Во исто време, искористеноста на процесорот се зголемува, но е многу помала од продуктивноста:

Исто така, вреди да се напомене дека блоковите зачувани во BlockCache се различни. Повеќето, околу 95%, се самите податоци. А останатото се метаподатоци, како што се филтрите за Блум или LEAF_INDEX и т.д.. Овој податок не е доволен, но е многу корисен, бидејќи пред директно да пристапи до податоците, HBase се свртува кон мета за да разбере дали е неопходно да се пребарува понатаму овде и, ако е така, каде точно се наоѓа блокот на интерес.

Затоа, во кодот гледаме услов за проверка buf.getBlockType().isData() и благодарение на оваа мета, во секој случај ќе ја оставиме во кешот.

Сега да го зголемиме оптоварувањето и малку да ја затегнеме функцијата со едно движење. Во првиот тест го направивме процентот на исклучување = 20 и BlockCache беше малку недоволно искористен. Сега да го поставиме на 23% и да додадеме 100 нишки на секои 5 минути за да видиме во која точка се случува заситеноста:

Овде гледаме дека оригиналната верзија речиси веднаш го погодува плафонот со околу 100 илјади барања во секунда. Додека фластерот дава забрзување до 300 илјади. Во исто време, јасно е дека понатамошното забрзување повеќе не е толку „бесплатно“; користењето на процесорот исто така се зголемува.

Сепак, ова не е многу елегантно решение, бидејќи однапред не знаеме колкав процент од блоковите треба да се кешираат, тоа зависи од профилот на оптоварување. Затоа, беше имплементиран механизам за автоматско прилагодување на овој параметар во зависност од активноста на операциите за читање.

Додадени се три опции за да се контролира ова:

hbase.lru.cache.heavy.eviction.count.limit — поставува колку пати треба да се извршува процесот на исфрлање податоци од кешот пред да почнеме да користиме оптимизација (т.е. прескокнување блокови). Стандардно е еднакво на MAX_INT = 2147483647 и всушност значи дека функцијата никогаш нема да почне да работи со оваа вредност. Бидејќи процесот на иселување започнува на секои 5 - 10 секунди (зависи од оптоварувањето) и 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 години. Сепак, можеме да го поставиме овој параметар на 0 и да ја направиме функцијата да работи веднаш по стартувањето.

Сепак, има и носивост во овој параметар. Ако нашето оптоварување е такво што краткорочното читање (да речеме во текот на денот) и долгорочното читање (ноќе) постојано се испреплетуваат, тогаш можеме да се увериме дека функцијата е вклучена само кога се во тек операциите за долго читање.

На пример, знаеме дека краткорочните читања обично траат околу 1 минута. Нема потреба да се започне со исфрлање блокови, кешот нема да има време да стане застарен и тогаш можеме да го поставиме овој параметар еднаков на, на пример, 10. Ова ќе доведе до фактот дека оптимизацијата ќе почне да работи само кога долго- терминот активно читање започна, т.е. за 100 секунди. Така, ако имаме краткорочно читање, тогаш сите блокови ќе влезат во кешот и ќе бидат достапни (освен оние што ќе бидат исфрлени од стандардниот алгоритам). И кога правиме долгорочни читања, функцијата е вклучена и би имале многу повисоки перформанси.

hbase.lru.cache.heavy.eviction.mb.size.limit — поставува колку мегабајти би сакале да ставиме во кешот (и, се разбира, иселување) за 10 секунди. Функцијата ќе се обиде да ја достигне оваа вредност и да ја одржи. Поентата е следна: ако внесеме гигабајти во кешот, тогаш ќе треба да ги исфрлиме гигабајтите, а ова, како што видовме погоре, е многу скапо. Сепак, не треба да се обидувате да го поставите премногу мал, бидејќи тоа ќе предизвика предвремено излегување од режимот за прескокнување блок. За моќни сервери (околу 20-40 физички јадра), оптимално е да поставите околу 300-400 MB. За средната класа (~10 јадра) 200-300 MB. За слаби системи (2-5 јадра) 50-100 MB може да се нормални (не се тестирани на овие).

Ајде да погледнеме како функционира ова: да речеме дека поставивме hbase.lru.cache.heavy.eviction.mb.size.limit = 500, има некој вид на оптоварување (читање) и потоа на секои 10 секунди пресметуваме колку бајти имало протерани со помош на формулата:

Надземни = Ослободени бајти Збир (MB) * 100 / Ограничување (MB) - 100;

Ако всушност биле иселени 2000 MB, тогаш надземните трошоци се еднакви на:

2000 * 100 / 500 - 100 = 300%

Алгоритмите се обидуваат да одржуваат не повеќе од неколку десетици проценти, така што функцијата ќе го намали процентот на кеширани блокови, а со тоа ќе имплементира механизам за автоматско подесување.

Меѓутоа, ако оптоварувањето падне, да речеме дека само 200 MB се исфрлени и надземниот дел станува негативен (т.н. прескокнување):

200 * 100 / 500 - 100 = -60%

Напротив, функцијата ќе го зголеми процентот на кеширани блокови додека Overhead не стане позитивен.

Подолу е пример за тоа како ова изгледа на реални податоци. Нема потреба да се обидувате да достигнете 0%, тоа е невозможно. Многу е добро кога е околу 30 - 100%, ова помага да се избегне предвремено излегување од режимот за оптимизација при краткорочни бранови.

hbase.lru.cache.heavy.eviction.overhead.коефициент — одредува колку брзо би сакале да го добиеме резултатот. Ако знаеме со сигурност дека нашите читања се главно долги и не сакаме да чекаме, можеме да го зголемиме овој сооднос и побрзо да добиеме високи перформанси.

На пример, го поставивме овој коефициент = 0.01. Ова значи дека надземните (види погоре) ќе се помножат со овој број со добиениот резултат и процентот на кеширани блокови ќе се намали. Да претпоставиме дека Overhead = 300% и коефициент = 0.01, тогаш процентот на кеширани блокови ќе се намали за 3%.

Слична логика „Позадински притисок“ е имплементирана и за негативните надземни (надминување) вредности. Бидејќи секогаш се можни краткорочни флуктуации во обемот на читања и иселувања, овој механизам ви овозможува да избегнете предвремено излегување од режимот за оптимизација. Назадниот притисок има превртена логика: колку е посилно надминувањето, толку повеќе блокови се кешираат.

Код за имплементација

        LruBlockCache cache = this.cache.get();
        if (cache == null) {
          break;
        }
        freedSumMb += cache.evict()/1024/1024;
        /*
        * Sometimes we are reading more data than can fit into BlockCache
        * and it is the cause a high rate of evictions.
        * This in turn leads to heavy Garbage Collector works.
        * So a lot of blocks put into BlockCache but never read,
        * but spending a lot of CPU resources.
        * Here we will analyze how many bytes were freed and decide
        * decide whether the time has come to reduce amount of caching blocks.
        * It help avoid put too many blocks into BlockCache
        * when evict() works very active and save CPU for other jobs.
        * More delails: https://issues.apache.org/jira/browse/HBASE-23887
        */

        // First of all we have to control how much time
        // has passed since previuos evict() was launched
        // This is should be almost the same time (+/- 10s)
        // because we get comparable volumes of freed bytes each time.
        // 10s because this is default period to run evict() (see above this.wait)
        long stopTime = System.currentTimeMillis();
        if ((stopTime - startTime) > 1000 * 10 - 1) {
          // Here we have to calc what situation we have got.
          // We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
          // and can calculte overhead on it.
          // We will use this information to decide,
          // how to change percent of caching blocks.
          freedDataOverheadPercent =
            (int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
          if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
            // Now we are in the situation when we are above the limit
            // But maybe we are going to ignore it because it will end quite soon
            heavyEvictionCount++;
            if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
              // It is going for a long time and we have to reduce of caching
              // blocks now. So we calculate here how many blocks we want to skip.
              // It depends on:
             // 1. Overhead - if overhead is big we could more aggressive
              // reducing amount of caching blocks.
              // 2. How fast we want to get the result. If we know that our
              // heavy reading for a long time, we don't want to wait and can
              // increase the coefficient and get good performance quite soon.
              // But if we don't sure we can do it slowly and it could prevent
              // premature exit from this mode. So, when the coefficient is
              // higher we can get better performance when heavy reading is stable.
              // But when reading is changing we can adjust to it and set
              // the coefficient to lower value.
              int change =
                (int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
              // But practice shows that 15% of reducing is quite enough.
              // We are not greedy (it could lead to premature exit).
              change = Math.min(15, change);
              change = Math.max(0, change); // I think it will never happen but check for sure
              // So this is the key point, here we are reducing % of caching blocks
              cache.cacheDataBlockPercent -= change;
              // If we go down too deep we have to stop here, 1% any way should be.
              cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
            }
          } else {
            // Well, we have got overshooting.
            // Mayby it is just short-term fluctuation and we can stay in this mode.
            // It help avoid permature exit during short-term fluctuation.
            // If overshooting less than 90%, we will try to increase the percent of
            // caching blocks and hope it is enough.
            if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
              // Simple logic: more overshooting - more caching blocks (backpressure)
              int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
              cache.cacheDataBlockPercent += change;
              // But it can't be more then 100%, so check it.
              cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
            } else {
              // Looks like heavy reading is over.
              // Just exit form this mode.
              heavyEvictionCount = 0;
              cache.cacheDataBlockPercent = 100;
            }
          }
          LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
            "heavy eviction counter: {}, " +
            "current caching DataBlock (%): {}",
            freedSumMb, freedDataOverheadPercent,
            heavyEvictionCount, cache.cacheDataBlockPercent);

          freedSumMb = 0;
          startTime = stopTime;
       }

Ајде сега да го погледнеме сето ова користејќи вистински пример. Ја имаме следната тест скрипта:

1. Ајде да започнеме со Скенирање (25 нишки, серија = 100)
2. По 5 минути, додадете мулти-добива (25 нишки, серија = 100)
3. По 5 минути, исклучете ги multi-gets (останува само скенирањето повторно)

Ние правиме две работи, прво hbase.lru.cache.heavy.eviction.count.limit = 10000 (што всушност ја оневозможува функцијата), а потоа постави ограничување = 0 (го овозможува).

Во дневниците подолу гледаме како функцијата е вклучена и го ресетира Overshooting на 14-71%. Од време на време оптоварувањето се намалува, што го вклучува Backpressure и HBase повторно кешира повеќе блокови.

Пријавете се РегионСервер
исфрлени (MB): 0, сооднос 0.0, надземни (%): -100, тешки бројачи за иселување: 0, тековно кеширање DataBlock (%): 100
исфрлени (MB): 0, сооднос 0.0, надземни (%): -100, тешки бројачи за иселување: 0, тековно кеширање DataBlock (%): 100
иселени (MB): 2170, сооднос 1.09, надземни (%): 985, тежок бројач за иселување: 1, тековно кеширање DataBlock (%): 91 < почеток
иселени (MB): 3763, сооднос 1.08, надземни (%): 1781, тежок бројач за иселување: 2, тековно кеширање DataBlock (%): 76
иселени (MB): 3306, сооднос 1.07, надземни (%): 1553, тежок бројач за иселување: 3, тековно кеширање DataBlock (%): 61
иселени (MB): 2508, сооднос 1.06, надземни (%): 1154, тежок бројач за иселување: 4, тековно кеширање DataBlock (%): 50
иселени (MB): 1824, сооднос 1.04, надземни (%): 812, тежок бројач за иселување: 5, тековно кеширање DataBlock (%): 42
иселени (MB): 1482, сооднос 1.03, надземни (%): 641, тежок бројач за иселување: 6, тековно кеширање DataBlock (%): 36
иселени (MB): 1140, сооднос 1.01, надземни (%): 470, тежок бројач за иселување: 7, тековно кеширање DataBlock (%): 32
иселени (MB): 913, сооднос 1.0, надземни (%): 356, тежок бројач за иселување: 8, тековно кеширање DataBlock (%): 29
иселени (MB): 912, сооднос 0.89, надземни (%): 356, тежок бројач за иселување: 9, тековно кеширање DataBlock (%): 26
иселени (MB): 684, сооднос 0.76, надземни (%): 242, тежок бројач за иселување: 10, тековно кеширање DataBlock (%): 24
иселени (MB): 684, сооднос 0.61, надземни (%): 242, тежок бројач за иселување: 11, тековно кеширање DataBlock (%): 22
иселени (MB): 456, сооднос 0.51, надземни (%): 128, тежок бројач за иселување: 12, тековно кеширање DataBlock (%): 21
иселени (MB): 456, сооднос 0.42, надземни (%): 128, тежок бројач за иселување: 13, тековно кеширање DataBlock (%): 20
иселени (MB): 456, сооднос 0.33, надземни (%): 128, тежок бројач за иселување: 14, тековно кеширање DataBlock (%): 19
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 15, тековно кеширање DataBlock (%): 19
иселени (MB): 342, сооднос 0.32, надземни (%): 71, тежок бројач за иселување: 16, тековно кеширање DataBlock (%): 19
иселени (MB): 342, сооднос 0.31, надземни (%): 71, тежок бројач за иселување: 17, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.3, надземни (%): 14, тежок бројач за иселување: 18, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.29, надземни (%): 14, тежок бројач за иселување: 19, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.27, надземни (%): 14, тежок бројач за иселување: 20, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.25, надземни (%): 14, тежок бројач за иселување: 21, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.24, надземни (%): 14, тежок бројач за иселување: 22, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.22, надземни (%): 14, тежок бројач за иселување: 23, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.21, надземни (%): 14, тежок бројач за иселување: 24, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.2, надземни (%): 14, тежок бројач за иселување: 25, тековно кеширање DataBlock (%): 19
иселени (MB): 228, сооднос 0.17, надземни (%): 14, тежок бројач за иселување: 26, тековно кеширање DataBlock (%): 19
исфрлени (MB): 456, сооднос 0.17, надземни (%): 128, тежок бројач за иселување: 27, тековно кеширање DataBlock (%): 18 < додадени добива (но табела иста)
иселени (MB): 456, сооднос 0.15, надземни (%): 128, тежок бројач за иселување: 28, тековно кеширање DataBlock (%): 17
иселени (MB): 342, сооднос 0.13, надземни (%): 71, тежок бројач за иселување: 29, тековно кеширање DataBlock (%): 17
иселени (MB): 342, сооднос 0.11, надземни (%): 71, тежок бројач за иселување: 30, тековно кеширање DataBlock (%): 17
иселени (MB): 342, сооднос 0.09, надземни (%): 71, тежок бројач за иселување: 31, тековно кеширање DataBlock (%): 17
иселени (MB): 228, сооднос 0.08, надземни (%): 14, тежок бројач за иселување: 32, тековно кеширање DataBlock (%): 17
иселени (MB): 228, сооднос 0.07, надземни (%): 14, тежок бројач за иселување: 33, тековно кеширање DataBlock (%): 17
иселени (MB): 228, сооднос 0.06, надземни (%): 14, тежок бројач за иселување: 34, тековно кеширање DataBlock (%): 17
иселени (MB): 228, сооднос 0.05, надземни (%): 14, тежок бројач за иселување: 35, тековно кеширање DataBlock (%): 17
иселени (MB): 228, сооднос 0.05, надземни (%): 14, тежок бројач за иселување: 36, тековно кеширање DataBlock (%): 17
иселени (MB): 228, сооднос 0.04, надземни (%): 14, тежок бројач за иселување: 37, тековно кеширање DataBlock (%): 17
исфрлени (MB): 109, сооднос 0.04, надземни (%): -46, тежок бројач за иселување: 37, тековно кеширање DataBlock (%): 22 < заден притисок
иселени (MB): 798, сооднос 0.24, надземни (%): 299, тежок бројач за иселување: 38, тековно кеширање DataBlock (%): 20
иселени (MB): 798, сооднос 0.29, надземни (%): 299, тежок бројач за иселување: 39, тековно кеширање DataBlock (%): 18
иселени (MB): 570, сооднос 0.27, надземни (%): 185, тежок бројач за иселување: 40, тековно кеширање DataBlock (%): 17
иселени (MB): 456, сооднос 0.22, надземни (%): 128, тежок бројач за иселување: 41, тековно кеширање DataBlock (%): 16
иселени (MB): 342, сооднос 0.16, надземни (%): 71, тежок бројач за иселување: 42, тековно кеширање DataBlock (%): 16
иселени (MB): 342, сооднос 0.11, надземни (%): 71, тежок бројач за иселување: 43, тековно кеширање DataBlock (%): 16
иселени (MB): 228, сооднос 0.09, надземни (%): 14, тежок бројач за иселување: 44, тековно кеширање DataBlock (%): 16
иселени (MB): 228, сооднос 0.07, надземни (%): 14, тежок бројач за иселување: 45, тековно кеширање DataBlock (%): 16
иселени (MB): 228, сооднос 0.05, надземни (%): 14, тежок бројач за иселување: 46, тековно кеширање DataBlock (%): 16
иселени (MB): 222, сооднос 0.04, надземни (%): 11, тежок бројач за иселување: 47, тековно кеширање DataBlock (%): 16
иселени (MB): 104, сооднос 0.03, надземни (%): -48, тежок бројач за иселување: 47, тековно кеширање DataBlock (%): 21 < прекинот добива
иселени (MB): 684, сооднос 0.2, надземни (%): 242, тежок бројач за иселување: 48, тековно кеширање DataBlock (%): 19
иселени (MB): 570, сооднос 0.23, надземни (%): 185, тежок бројач за иселување: 49, тековно кеширање DataBlock (%): 18
иселени (MB): 342, сооднос 0.22, надземни (%): 71, тежок бројач за иселување: 50, тековно кеширање DataBlock (%): 18
иселени (MB): 228, сооднос 0.21, надземни (%): 14, тежок бројач за иселување: 51, тековно кеширање DataBlock (%): 18
иселени (MB): 228, сооднос 0.2, надземни (%): 14, тежок бројач за иселување: 52, тековно кеширање DataBlock (%): 18
иселени (MB): 228, сооднос 0.18, надземни (%): 14, тежок бројач за иселување: 53, тековно кеширање DataBlock (%): 18
иселени (MB): 228, сооднос 0.16, надземни (%): 14, тежок бројач за иселување: 54, тековно кеширање DataBlock (%): 18
иселени (MB): 228, сооднос 0.14, надземни (%): 14, тежок бројач за иселување: 55, тековно кеширање DataBlock (%): 18
исфрлени (MB): 112, сооднос 0.14, надземни (%): -44, тежок бројач за иселување: 55, тековно кеширање DataBlock (%): 23 < заден притисок
иселени (MB): 456, сооднос 0.26, надземни (%): 128, тежок бројач за иселување: 56, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.31, надземни (%): 71, тежок бројач за иселување: 57, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 58, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 59, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 60, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 61, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 62, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 63, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.32, надземни (%): 71, тежок бројач за иселување: 64, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 65, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 66, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.32, надземни (%): 71, тежок бројач за иселување: 67, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 68, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.32, надземни (%): 71, тежок бројач за иселување: 69, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.32, надземни (%): 71, тежок бројач за иселување: 70, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 71, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 72, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 73, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 74, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 75, тековно кеширање DataBlock (%): 22
иселени (MB): 342, сооднос 0.33, надземни (%): 71, тежок бројач за иселување: 76, тековно кеширање DataBlock (%): 22
исфрлени (MB): 21, сооднос 0.33, надземни (%): -90, тешки бројачи за иселување: 76, тековно кеширање DataBlock (%): 32
исфрлени (MB): 0, сооднос 0.0, надземни (%): -100, тешки бројачи за иселување: 0, тековно кеширање DataBlock (%): 100
исфрлени (MB): 0, сооднос 0.0, надземни (%): -100, тешки бројачи за иселување: 0, тековно кеширање DataBlock (%): 100

Скенирањето беше потребно за да се прикаже истиот процес во форма на график на односот помеѓу два секции на кешот - единечни (каде блокови што никогаш претходно не биле побарани) и мулти (податоци „барани“ барем еднаш се зачувани овде):

И конечно, како изгледа операцијата на параметрите во форма на график. За споредба, кешот беше целосно исклучен на почетокот, а потоа беше лансиран HBase со кеширање и одложување на почетокот на работата за оптимизација за 5 минути (30 циклуси на иселување).

Целосниот код може да се најде во барањето за повлекување HBASE 23887 на github.

Сепак, 300 илјади читања во секунда не се сè што може да се постигне на овој хардвер под овие услови. Факт е дека кога треба да пристапите до податоци преку HDFS, се користи механизмот ShortCircuitCache (во натамошниот текст SSC), кој ви овозможува директно да пристапите до податоците, избегнувајќи мрежни интеракции.

Профилирањето покажа дека иако овој механизам дава голема добивка, тој во одреден момент станува и тесно грло, бидејќи скоро сите тешки операции се случуваат во бравата, што доведува до блокирање поголемиот дел од времето.

Откако го сфативме ова, сфативме дека проблемот може да се заобиколи со создавање низа независни SSCs:

private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
  this.shortCircuitCache[i] = new ShortCircuitCache(…);

И потоа работете со нив, исклучувајќи ги раскрсниците, исто така, на последната офсет цифра:

public ShortCircuitCache getShortCircuitCache(long idx) {
    return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}

Сега можете да започнете со тестирање. За да го направите ова, ќе читаме датотеки од HDFS со едноставна апликација со повеќе нишки. Поставете ги параметрите:

conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10

И само прочитајте ги датотеките:

FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
    position += 65536;
    if (position > 900000000)
        position = 0L;
    int res = in.read(position, byteBuffer, 0, 65536);
}

Овој код се извршува во посебни нишки и ќе го зголемиме бројот на истовремено прочитани датотеки (од 10 на 200 - хоризонтална оска) и бројот на кешови (од 1 до 10 - графички). Вертикалната оска го покажува забрзувањето што произлегува од зголемувањето на SSC ​​во однос на случајот кога има само еден кеш.

Како да го прочитате графикот: Времето на извршување за 100 илјади читања во блокови од 64 KB со еден кеш бара 78 секунди. Додека со 5 кешови потребни се 16 секунди. Оние. има забрзување од ~ 5 пати. Како што може да се види од графиконот, ефектот не е многу забележлив за мал број паралелни читања, тој почнува да игра забележлива улога кога има повеќе од 50 читања на нишки. Забележливо е и зголемувањето на бројот на SSC ​​од 6 а погоре дава значително помало зголемување на перформансите.

Забелешка 1: бидејќи резултатите од тестот се прилично испарливи (види подолу), беа извршени 3 вртења и добиените вредности беа просечни.

Забелешка 2: добивката од перформансите од конфигурирање на случаен пристап е иста, иако самиот пристап е малку побавен.

Сепак, неопходно е да се разјасни дека, за разлика од случајот со HBase, ова забрзување не е секогаш бесплатно. Овде ја „отклучуваме“ способноста на процесорот да работи повеќе, наместо да виси на брави.

Овде можете да забележите дека, генерално, зголемувањето на бројот на кешовите дава приближно пропорционално зголемување на искористеноста на процесорот. Сепак, има малку повеќе добитни комбинации.

На пример, ајде внимателно да ја разгледаме поставката SSC ​​= 3. Зголемувањето на перформансите на опсегот е околу 3.3 пати. Подолу се резултатите од сите три одделни трки.

Додека потрошувачката на процесорот се зголемува за околу 2.8 пати. Разликата не е многу голема, но малата Грета е веќе среќна и можеби има време да оди на училиште и да земе часови.

Така, ова ќе има позитивен ефект за секоја алатка што користи масовен пристап до HDFS (на пример Spark, итн.), под услов кодот на апликацијата да е лесен (т.е. приклучокот е на страната на клиентот HDFS) и да има бесплатно напојување на процесорот . За да провериме, да тестираме каков ефект ќе има комбинираната употреба на оптимизација на BlockCache и подесување на SSC ​​за читање од HBase.

Може да се види дека во такви услови ефектот не е толку голем како во рафинираните тестови (читање без никаква обработка), но сосема е можно да се исцедат дополнителни 80K овде. Заедно, двете оптимизации обезбедуваат до 4x забрзување.

За оваа оптимизација беше направен и ПР [HDFS-15202], која е споена и оваа функционалност ќе биде достапна во идните изданија.

И, конечно, беше интересно да се споредат перформансите за читање на слична база на податоци со широки колони, Касандра и HBase.

За да го направите ова, лансиравме примероци на стандардната алатка за тестирање на оптоварување YCSB од два домаќини (вкупно 800 нишки). На страната на серверот - 4 примери на RegionServer и Cassandra на 4 хостови (не оние каде што работат клиентите, за да се избегне нивното влијание). Читањата дојдоа од табели со големина:

HBase – 300 GB на HDFS (100 GB чисти податоци)

Касандра - 250 GB (фактор на репликација = 3)

Оние. волуменот беше приближно ист (во HBase малку повеќе).

HBase параметри:

dfs.client.short.circuit.num = 5 (Оптимизација на HDFS клиент)

hbase.lru.cache.heavy.eviction.count.limit = 30 - тоа значи дека лепенката ќе почне да работи по 30 иселувања (~5 минути)

hbase.lru.cache.heavy.eviction.mb.size.limit = 300 — целен волумен на кеширање и иселување

Дневниците на YCSB беа анализирани и компајлирани во графикони на Excel:

Како што можете да видите, овие оптимизации овозможуваат да се споредат перформансите на овие бази на податоци под овие услови и да се постигнат 450 илјади читања во секунда.

Се надеваме дека оваа информација може да биде корисна за некого за време на возбудливата борба за продуктивност.

Извор: www.habr.com