Как да увеличите скоростта на четене от HBase до 3 пъти и от HDFS до 5 пъти

Високата производителност е едно от ключовите изисквания при работа с големи данни. В отдела за зареждане на данни в Sberbank ние изпомпваме почти всички транзакции в нашия базиран на Hadoop Data Cloud и следователно се справяме с наистина големи потоци от информация. Естествено, ние винаги търсим начини за подобряване на производителността и сега искаме да ви кажем как успяхме да закърпим 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/sec, т.е. 3 милиона пъти по 100 байта. Но както си спомняме, данните, от които се нуждаем, са 2600 пъти по-малко от това, което се чете. Така разделяме 3 милиона на 2600 и получаваме 1100 записа в секунда.

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

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

Тук виждаме, че за първите няколко минути скоростта наистина е около хиляда записа в секунда. Освен това обаче, поради факта, че се чете много повече от поисканото, данните се озовават в buff/cache на операционната система (linux) и скоростта се увеличава до по-приличните 60 хиляди в секунда

По този начин по-нататък ще се занимаваме с ускоряване на достъпа само до данните, които са в кеша на операционната система или се намират в SSD/NVMe устройства за съхранение със сравнима скорост на достъп.

В нашия случай ще проведем тестове на стенд от 4 сървъра, всеки от които се таксува, както следва:

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

И тук ключовият момент е количеството данни в таблиците, които трябва да бъдат прочетени. Факт е, че ако четете данни от таблица, която е изцяло поставена в кеша на HBase, тогава дори няма да се стигне до четене от buff/cache на операционната система. Тъй като HBase по подразбиране разпределя 40% от паметта на структура, наречена BlockCache. По същество това е ConcurrentHashMap, където ключът е името на файла + отместването на блока, а стойността е действителните данни при това отместване.

По този начин, когато четем само от тази структура, ние виждаме отлична скорост, като милион заявки в секунда. Но нека си представим, че не можем да отделим стотици гигабайти памет само за нуждите на базата данни, защото има много други полезни неща, работещи на тези сървъри.

Например, в нашия случай обемът на BlockCache на един RS е около 12 GB. Кацнахме две RS на един възел, т.е. 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, само за да ги изхвърли почти веднага, защото е пристигнала нова порция данни. Анимацията в началото на публикацията показва същността на проблема - Garbage Collector излиза от мащаба, атмосферата се нажежава, малката Грета в далечна и гореща Швеция се разстройва. И ние, хората от ИТ, наистина не харесваме, когато децата са тъжни, така че започваме да мислим какво можем да направим по въпроса.

Ами ако поставите не всички блокове в кеша, а само определен процент от тях, така че кешът да не се препълва? Нека започнем, като просто добавим само няколко реда код в началото на функцията за поставяне на данни в 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%, са самите данни. А останалото са метаданни, като Bloom филтри или 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 са изгонени и Overhead става отрицателен (така нареченото превишаване):

200 * 100 / 500 - 100 = -60%

Напротив, функцията ще увеличи процента на кешираните блокове, докато Overhead стане положителен.

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

hbase.lru.cache.heavy.eviction.overhead.coefficient — задава колко бързо бихме искали да получим резултата. Ако знаем със сигурност, че нашите четения са предимно дълги и не искаме да чакаме, можем да увеличим това съотношение и да постигнем висока производителност по-бързо.

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

Подобна логика на „обратно налягане“ също е приложена за отрицателни стойности на Overhead (превишаване). Тъй като винаги са възможни краткосрочни колебания в обема на четения и изгонвания, този механизъм ви позволява да избегнете преждевременното излизане от режима на оптимизация. Обратното налягане има обърната логика: колкото по-силно е превишаването, толкова повече блокове се кешират.

Код за внедряване

        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 минути добавете multi-gets (25 нишки, партида = 100)
3. След 5 минути изключете multi-gets (отново остава само сканиране)

Правим две стартирания, първо hbase.lru.cache.heavy.eviction.count.limit = 10000 (което всъщност деактивира функцията) и след това задаваме limit = 0 (активира я).

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

Регистрирайте RegionServer
изгонено (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 цикъла на изваждане).

Пълният код може да бъде намерен в Pull Request HBASE 23887 в github.

Въпреки това, 300 хиляди четения в секунда не е всичко, което може да се постигне на този хардуер при тези условия. Факт е, че когато имате нужда от достъп до данни чрез HDFS, се използва механизмът ShortCircuitCache (наричан по-нататък SSC), който ви позволява да осъществявате директен достъп до данните, като избягвате мрежови взаимодействия.

Профилирането показа, че въпреки че този механизъм дава голяма печалба, той също в даден момент се превръща в пречка, тъй като почти всички тежки операции се извършват вътре в ключалката, което води до блокиране през повечето време.

След като осъзнахме това, разбрахме, че проблемът може да бъде заобиколен чрез създаване на масив от независими SSC:

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. Заедно двете оптимизации осигуряват до 4 пъти ускорение.

Направен е и PR за тази оптимизация [HDFS-15202], който беше обединен и тази функционалност ще бъде налична в бъдещи версии.

И накрая, беше интересно да се сравни ефективността на четене на подобна база данни с широки колони, Cassandra и HBase.

За да направим това, стартирахме екземпляри на стандартната YCSB помощна програма за тестване на натоварване от два хоста (общо 800 нишки). От страна на сървъра - 4 инстанции на RegionServer и Cassandra на 4 хоста (не тези, на които работят клиентите, за да избегнем влиянието им). Показанията идват от таблици с размери:

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

Cassandra - 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