HBase에서 최대 3배, HDFS에서 최대 5배 읽기 속도를 높이는 방법

고성능은 빅데이터 작업 시 중요한 요구 사항 중 하나입니다. Sberbank의 데이터 로딩 부서에서는 거의 모든 거래를 Hadoop 기반 데이터 클라우드로 펌핑하여 매우 많은 양의 정보 흐름을 처리합니다. 당연히 우리는 항상 성능을 향상시킬 수 있는 방법을 찾고 있으며 이제 읽기 작업 속도를 크게 향상시킬 수 있었던 덕분에 RegionServer HBase 및 HDFS 클라이언트를 패치할 수 있었던 방법을 알려 드리고자 합니다.


그러나 개선 사항의 본질을 다루기 전에 원칙적으로 HDD를 사용하면 피할 수 없는 제한 사항에 대해 이야기할 가치가 있습니다.

HDD와 빠른 랜덤 액세스 읽기가 호환되지 않는 이유
아시다시피 HBase 및 기타 여러 데이터베이스는 수십 킬로바이트 크기의 블록에 데이터를 저장합니다. 기본적으로 약 64KB입니다. 이제 100바이트만 가져와야 하고 HBase에 특정 키를 사용하여 이 데이터를 제공하도록 요청한다고 가정해 보겠습니다. HFiles의 블록 크기가 64KB이므로 요청은 필요한 것보다 640배(단 XNUMX분!) 더 커집니다.

다음으로 요청은 HDFS와 해당 메타데이터 캐싱 메커니즘을 거치게 되므로 ShortCircuit캐시 (파일에 직접 액세스할 수 있음) 이로 인해 디스크에서 이미 1MB를 읽게 됩니다. 그러나 이는 매개변수를 사용하여 조정할 수 있습니다. dfs.client.read.shortcircuit.buffer.size 많은 경우 이 값을 예를 들어 126KB로 줄이는 것이 좋습니다.

이렇게 한다고 가정해 봅시다. 하지만 추가적으로 FileChannel.read와 같은 함수 등 Java API를 통해 데이터 읽기를 시작하고 운영 체제에 지정된 양의 데이터를 읽도록 요청하면 “just in if”를 2배 더 읽습니다. , 즉. 우리의 경우에는 256KB입니다. 이는 Java에 이 동작을 방지하기 위해 FADV_RANDOM 플래그를 설정하는 쉬운 방법이 없기 때문입니다.

결과적으로 100바이트를 얻으려면 내부적으로 2600배 더 많은 내용을 읽어야 합니다. 해결책은 분명한 것 같습니다. 블록 크기를 2킬로바이트로 줄이고, 언급된 플래그를 설정하고 큰 깨달음 가속화를 얻으세요. 하지만 문제는 블록 크기를 2배로 줄임으로써 단위 시간당 읽는 바이트 수도 XNUMX배로 줄어든다는 것입니다.

FADV_RANDOM 플래그 설정으로 일부 이득을 얻을 수 있지만 높은 멀티스레딩과 128KB의 블록 크기에서만 얻을 수 있지만 이는 최대 수십 퍼센트입니다.

테스트는 각각 크기가 100GB이고 1개의 HDD에 있는 10개의 파일에 대해 수행되었습니다.

원칙적으로 이 속도에서 기대할 수 있는 것이 무엇인지 계산해 보겠습니다.
10MB/초의 속도로 280개의 디스크를 읽는다고 가정해 보겠습니다. 3만 x 100바이트. 그러나 우리가 기억하는 것처럼 우리에게 필요한 데이터는 읽은 것보다 2600배 적습니다. 따라서 3백만을 2600으로 나누면 다음과 같은 결과가 나옵니다. 초당 1100개의 레코드.

우울하지 않나요? 그게 자연이야 랜덤 액세스 블록 크기에 관계없이 HDD의 데이터에 액세스합니다. 이는 임의 액세스의 물리적 한계이며 이러한 조건에서는 어떤 데이터베이스도 더 많은 것을 짜낼 수 없습니다.

그렇다면 데이터베이스는 어떻게 훨씬 더 빠른 속도를 달성할 수 있을까요? 이 질문에 답하기 위해 다음 그림에서 무슨 일이 일어나고 있는지 살펴보겠습니다.

여기서 우리는 처음 몇 분 동안 속도가 실제로 초당 약 60개의 레코드라는 것을 알 수 있습니다. 그러나 요청한 것보다 훨씬 더 많은 양의 읽기가 이루어지기 때문에 데이터는 운영 체제(Linux)의 버프/캐시에 들어가고 속도는 초당 XNUMX으로 증가합니다.

따라서 더 나아가 OS 캐시에 있거나 유사한 액세스 속도의 SSD/NVMe 스토리지 장치에 있는 데이터에 대해서만 액세스를 가속화하는 방법을 다룰 것입니다.

우리의 경우에는 4개의 서버로 구성된 벤치에서 테스트를 수행할 것이며 각 서버에는 다음과 같이 요금이 부과됩니다.

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 스레드.
메모리: 730GB.
자바 버전: 1.8.0_111

그리고 여기서 중요한 점은 읽어야 하는 테이블의 데이터 양입니다. 사실 HBase 캐시에 완전히 배치된 테이블에서 데이터를 읽으면 운영 체제의 버프/캐시에서도 읽히지 않습니다. HBase는 기본적으로 BlockCache라는 구조에 메모리의 40%를 할당하기 때문입니다. 본질적으로 이것은 ConcurrentHashMap입니다. 여기서 키는 파일 이름 + 블록의 오프셋이고 값은 이 오프셋의 실제 데이터입니다.

따라서 이 구조에서만 읽을 때 우리는 속도가 엄청나네요, 초당 백만 개의 요청과 같습니다. 하지만 이러한 서버에서 실행되는 다른 유용한 것들이 많이 있기 때문에 데이터베이스 요구 사항에만 수백 기가바이트의 메모리를 할당할 수 없다고 가정해 보겠습니다.

예를 들어, 우리의 경우 RS 하나의 BlockCache 볼륨은 약 12GB입니다. 우리는 하나의 노드에 두 개의 RS를 착륙시켰습니다. 모든 노드의 BlockCache에 96GB가 할당됩니다. 그리고 훨씬 더 많은 데이터가 있습니다. 예를 들어 4개의 테이블, 각각 130개의 영역이 있고 파일 크기는 800MB이고 FAST_DIFF로 압축됩니다. 총 410GB(복제 요소를 고려하지 않은 순수 데이터)

따라서 BlockCache는 전체 데이터 양의 약 23%에 불과하며 이는 BigData라고 불리는 실제 조건에 훨씬 더 가깝습니다. 그리고 여기서 재미가 시작됩니다. 캐시 적중 횟수가 적을수록 성능이 저하되기 때문입니다. 결국, 놓치면 많은 일을 해야 할 것입니다. 시스템 기능 호출로 이동합니다. 그러나 이는 피할 수 없으므로 완전히 다른 측면, 즉 캐시 내부의 데이터는 어떻게 되는지 살펴보겠습니다.

상황을 단순화하고 하나의 개체에만 맞는 캐시가 있다고 가정해 보겠습니다. 다음은 캐시보다 1배 더 큰 데이터 볼륨으로 작업하려고 할 때 어떤 일이 발생하는지에 대한 예입니다.

1. 블록 1을 캐시에 배치
2. 캐시에서 블록 1을 제거합니다.
3. 블록 2을 캐시에 배치
4. 캐시에서 블록 2을 제거합니다.
5. 블록 3을 캐시에 배치

5가지 작업이 완료되었습니다! 그러나 이러한 상황은 정상이라고 할 수 없으며 실제로 우리는 HBase가 완전히 쓸모없는 작업을 수행하도록 강요하고 있습니다. OS 캐시에서 지속적으로 데이터를 읽고 이를 BlockCache에 저장한 후 데이터의 새로운 부분이 도착하면 거의 즉시 폐기합니다. 게시물 시작 부분의 애니메이션은 문제의 본질을 보여줍니다. Garbage Collector가 규모를 벗어나고 분위기가 뜨거워지고 멀고 뜨거운 스웨덴에 있는 작은 Greta가 화를 내고 있습니다. 그리고 우리 IT 사람들은 아이들이 슬퍼하는 것을 정말 좋아하지 않기 때문에 우리가 할 수 있는 일이 무엇인지 생각하기 시작합니다.

캐시가 오버플로되지 않도록 모든 블록을 캐시에 넣지 않고 특정 비율만 캐시에 넣으면 어떻게 될까요? BlockCache에 데이터를 저장하는 함수의 시작 부분에 몇 줄의 코드만 추가하는 것으로 시작해 보겠습니다.

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

여기서 요점은 다음과 같습니다. offset은 파일에서 블록의 위치이며 마지막 숫자는 00에서 99까지 무작위로 균등하게 분포됩니다. 따라서 필요한 범위에 속하는 숫자만 건너뜁니다.

예를 들어, 캐시DataBlockPercent = 20을 설정하고 어떤 일이 발생하는지 확인하세요.

결과는 분명합니다. 아래 그래프에서 이러한 가속이 발생한 이유가 분명해졌습니다. 캐시에 데이터를 배치하여 즉시 화성의 개 배수구에 버리는 Sisyphean 작업을 수행하지 않고도 많은 GC 리소스를 절약할 수 있습니다.

동시에 CPU 사용률은 증가하지만 생산성보다는 훨씬 낮습니다.

BlockCache에 저장된 블록이 다르다는 점도 주목할 가치가 있습니다. 대부분(약 95%)은 데이터 그 자체입니다. 나머지는 Bloom 필터나 LEAF_INDEX와 같은 메타데이터이며 т.д.. 이 데이터는 충분하지 않지만 데이터에 직접 액세스하기 전에 HBase가 메타를 참조하여 여기에서 추가 검색이 필요한지, 그렇다면 관심 있는 블록이 정확히 어디에 있는지 이해하기 때문에 매우 유용합니다.

따라서 코드에는 확인 조건이 표시됩니다. buf.getBlockType().isData() 그리고 이 메타 덕분에 우리는 어떤 경우에도 그것을 캐시에 남겨둘 것입니다.

이제 부하를 늘리고 한 번에 기능을 약간 강화해 보겠습니다. 첫 번째 테스트에서는 컷오프 비율을 20으로 설정했고 BlockCache는 약간 덜 활용되었습니다. 이제 이를 23%로 설정하고 100분마다 5개의 스레드를 추가하여 어느 지점에서 포화가 발생하는지 살펴보겠습니다.

여기서는 원본 버전이 초당 약 100만 요청으로 거의 즉시 상한선에 도달하는 것을 볼 수 있습니다. 패치는 최대 300의 가속을 제공합니다. 동시에 추가 가속은 더 이상 "무료"가 아니며 CPU 사용률도 증가하고 있다는 것이 분명합니다.

그러나 이는 캐시해야 하는 블록의 비율을 미리 알 수 없고 로드 프로필에 따라 다르기 때문에 매우 우아한 솔루션은 아닙니다. 따라서 읽기 작업 활동에 따라 이 매개변수를 자동으로 조정하는 메커니즘이 구현되었습니다.

이를 제어하기 위해 세 가지 옵션이 추가되었습니다.

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~400MB를 설정하는 것이 가장 좋습니다. 중산층(~10개 코어)의 경우 200-300MB. 약한 시스템(2~5개 코어)의 경우 50~100MB가 정상일 수 있습니다(이것에서는 테스트되지 않음).

이것이 어떻게 작동하는지 살펴보겠습니다. hbase.lru.cache.heavy.eviction.mb.size.limit = 500으로 설정하고 일종의 로드(읽기)가 있으며 약 10초마다 바이트 수를 계산한다고 가정해 보겠습니다. 다음 공식을 사용하여 퇴거됩니다.

오버헤드 = 해제된 바이트 합계(MB) * 100 / 제한(MB) - 100;

실제로 2000MB가 제거된 경우 오버헤드는 다음과 같습니다.

2000 * 100 / 500 - 100 = 300%

알고리즘은 수십 퍼센트 이하를 유지하려고 시도하므로 이 기능은 캐시된 블록의 비율을 줄여 자동 조정 메커니즘을 구현합니다.

그러나 로드가 떨어지면 200MB만 제거되고 오버헤드가 음수(소위 오버슈팅)가 된다고 가정해 보겠습니다.

200 * 100 / 500 - 100 = -60%

반대로 이 기능은 오버헤드가 양수가 될 때까지 캐시된 블록의 비율을 증가시킵니다.

다음은 실제 데이터에서 이것이 어떻게 보이는지에 대한 예입니다. 0%에 도달하려고 노력할 필요는 없습니다. 불가능합니다. 약 30~100%일 때 매우 좋습니다. 이는 단기 급증 중에 최적화 모드에서 조기 종료를 방지하는 데 도움이 됩니다.

hbase.lru.cache.heavy.eviction.overhead.coefficient — 결과를 얼마나 빨리 얻고 싶은지 설정합니다. 읽기가 대부분 길고 기다리기를 원하지 않는다는 것을 확실히 알고 있다면 이 비율을 높이고 고성능을 더 빠르게 얻을 수 있습니다.

예를 들어 이 계수를 0.01로 설정합니다. 이는 오버헤드(위 참조)에 이 숫자를 결과 결과로 곱하고 캐시된 블록의 비율이 감소함을 의미합니다. 오버헤드 = 300%, 계수 = 0.01이라고 가정하면 캐시된 블록의 비율이 3% 감소합니다.

음의 오버헤드(오버슈팅) 값에 대해서도 유사한 "배압" 논리가 구현됩니다. 읽기 및 제거 볼륨의 단기 변동은 항상 가능하므로 이 메커니즘을 사용하면 최적화 모드에서 조기 종료를 방지할 수 있습니다. BackPressure에는 반전된 논리가 있습니다. 즉, 오버슈팅이 강할수록 더 많은 블록이 캐시됩니다.

구현 코드

        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분 후 멀티겟 꺼짐 (다시 스캔만 남음)

우리는 두 번의 실행을 수행합니다. 먼저 hbase.lru.cache.heavy.eviction.count.limit = 10000(실제로 기능을 비활성화함)을 설정한 다음 제한 = 0(활성화)을 설정합니다.

아래 로그에서는 이 기능이 어떻게 켜져 있고 오버슈팅을 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회 제거 주기) 지연시켰습니다.

전체 코드는 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 - 그래픽)를 늘립니다. 세로축은 캐시가 XNUMX개인 경우에 비해 SSC가 증가하여 발생하는 가속도를 나타냅니다.

그래프를 읽는 방법: 하나의 캐시로 100KB 블록에서 64만 읽기를 실행하는 데 78초가 소요됩니다. 반면 캐시가 5개이면 16초가 걸립니다. 저것들. ~5배의 가속도가 있습니다. 그래프에서 볼 수 있듯이 병렬 읽기 수가 적을 때는 효과가 크게 눈에 띄지 않지만 스레드 읽기가 50개 이상일 때 눈에 띄는 역할을 하기 시작합니다. 이상에서는 성능이 크게 향상되지 않습니다.

참고 1: 테스트 결과는 매우 불안정하므로(아래 참조) 3번의 실행을 수행하고 결과 값을 평균화했습니다.

참고 2: 임의 액세스 구성으로 인한 성능 향상은 동일하지만 액세스 자체는 약간 느려집니다.

그러나 HBase의 경우와 달리 이러한 가속이 항상 무료는 아니라는 점을 분명히 할 필요가 있습니다. 여기서 우리는 잠금에 매달리는 대신 더 많은 작업을 수행할 수 있는 CPU 기능을 "잠금 해제"합니다.

여기서는 일반적으로 캐시 수가 증가하면 CPU 사용률이 대략 비례하여 증가한다는 것을 알 수 있습니다. 그러나 약간 더 많은 승리 조합이 있습니다.

예를 들어 SSC = 3 설정을 자세히 살펴보겠습니다. 해당 범위의 성능 향상은 약 3.3배입니다. 아래는 세 가지 개별 실행의 결과입니다.

CPU 소비는 약 2.8배 증가합니다. 그 차이는 그리 크지 않지만 어린 그레타는 이미 행복해하며 학교에 다니고 수업을 받을 시간이 있을 수도 있습니다.

따라서 이는 애플리케이션 코드가 가볍고(즉, 플러그가 HDFS 클라이언트 측에 있음) 무료 CPU 성능이 있는 경우 HDFS에 대한 대량 액세스를 사용하는 모든 도구(예: Spark 등)에 긍정적인 영향을 미칠 것입니다. . 이를 확인하기 위해 BlockCache 최적화와 SSC 튜닝을 결합하여 HBase에서 읽기에 어떤 영향을 미치는지 테스트해 보겠습니다.

이러한 조건에서는 개선된 테스트(처리 없이 읽기)만큼 효과가 크지 않지만 여기에서 추가로 80K를 짜내는 것이 가능하다는 것을 알 수 있습니다. 두 가지 최적화를 함께 사용하면 최대 4배의 속도 향상이 가능합니다.

이 최적화에 대한 PR도 작성되었습니다. [HDFS-15202]가 병합되었으며 이 기능은 향후 릴리스에서 제공될 예정입니다.

그리고 마지막으로 유사한 와이드 컬럼 데이터베이스인 Cassandra와 HBase의 읽기 성능을 비교하는 것이 흥미로웠습니다.

이를 위해 두 호스트(총 800개 스레드)에서 표준 YCSB 로드 테스트 유틸리티의 인스턴스를 시작했습니다. 서버 측 - 4개의 호스트에 있는 4개의 RegionServer 및 Cassandra 인스턴스(클라이언트의 영향을 피하기 위해 클라이언트가 실행 중인 호스트가 아님). 판독값은 다음과 같은 크기의 표에서 나왔습니다.

HBase – HDFS에서 300GB(100GB 순수 데이터)

Cassandra - 250GB(복제 인자 = 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만 건의 읽기를 달성할 수 있습니다.

우리는 이 정보가 생산성을 위해 분투하고 있는 누군가에게 유용할 수 있기를 바랍니다.

출처 : habr.com