HBase からの読み取り速度を最大 3 倍、HDFS からの読み取り速度を最大 5 倍向上させる方法

ビッグ データを扱う場合、高いパフォーマンスが重要な要件の 1 つです。 Sberbank のデータ読み込み部門では、ほぼすべてのトランザクションを Hadoop ベースのデータ クラウドに送り込むため、非常に大量の情報フローを処理します。当然のことながら、私たちはパフォーマンスを向上させる方法を常に模索しています。そして今回は、RegionServer HBase と HDFS クライアントにどのようにパッチを適用したのかを説明したいと思います。そのおかげで、読み取り操作の速度を大幅に向上させることができました。


ただし、改善の本質に進む前に、HDD を使用している場合は原則として回避できない制限について話しておく価値があります。

HDD と高速ランダムアクセス読み取りに互換性がない理由
ご存知のとおり、HBase やその他の多くのデータベースは、サイズが数十キロバイトのブロックにデータを保存します。デフォルトでは約 64 KB です。ここで、100 バイトだけを取得する必要があり、特定のキーを使用してこのデータを提供するように HBase に要求すると想像してみましょう。 HFiles のブロック サイズは 64 KB であるため、リクエストは必要なサイズの 640 倍 (わずか XNUMX 分!) になります。

次に、リクエストは HDFS とそのメタデータ キャッシュ メカニズムを通過するため、 短絡キャッシュ (ファイルへの直接アクセスが可能になります)、これにより、ディスクからすでに 1 MB が読み取られることになります。 ただし、これはパラメータで調整できます dfs.client.read.shortcircuit.buffer.size そして多くの場合、この値をたとえば 126 KB に減らすことが合理的です。

これを実行するとします。ただし、さらに、FileChannel.read などの関数などの Java API を介してデータの読み取りを開始し、指定された量のデータを読み取るようにオペレーティング システムに要求すると、「念のため」さらに 2 倍の読み取りが行われます。 、つまり私たちの場合は 256 KB。これは、Java には、この動作を防ぐための FADV_RANDOM フラグを設定する簡単な方法がないためです。

その結果、100 バイトを取得するために、内部では 2600 倍以上のデータが読み取られます。 解決策は明らかだと思われます。ブロック サイズを 2 キロバイトに削減し、前述のフラグを設定して、啓発を大幅に加速しましょう。 しかし問題は、ブロック サイズを 2 倍に減らすと、単位時間あたりに読み取られるバイト数も XNUMX 倍に減少することです。

FADV_RANDOM フラグを設定すると、ある程度の利益が得られますが、これは高マルチスレッドでブロック サイズが 128 KB の場合に限られますが、これは最大で数十パーセントです。

テストは、100 台の HDD 上にある 1 GB のサイズの 10 個のファイルに対して実行されました。

原則として、この速度で何が期待できるかを計算してみましょう。
10 枚のディスクから 280 MB/秒の速度で読み取るとします。 3万×100バイト。しかし、覚えているとおり、必要なデータは読み取られるデータの 2600 分の 3 です。したがって、2600 万を XNUMX で割ると、次のようになります。 1100 秒あたり XNUMX レコード。

憂鬱ですね。 それが自然です ランダムアクセス ブロックサイズに関係なく、HDD 上のデータにアクセスできます。これはランダム アクセスの物理的な制限であり、このような条件下ではデータベースはこれ以上に絞り出すことができません。

では、データベースはどのようにして高速化を実現できるのでしょうか?この質問に答えるために、次の図で何が起こっているかを見てみましょう。

ここで、最初の数分間の速度は、実際には 60 秒あたり約 XNUMX レコードであることがわかります。ただし、要求されたよりもはるかに多くのデータが読み取られるため、データはオペレーティング システム (Linux) のバフ/キャッシュに保存され、速度はさらにまともな XNUMX 秒あたり XNUMX に増加します。

したがって、OS キャッシュ内にあるデータ、または同等のアクセス速度の SSD/NVMe ストレージ デバイスにあるデータのみへのアクセスの高速化にさらに対処します。

私たちの場合、4 台のサーバーからなるベンチでテストを実施します。各サーバーには次のように課金されます。

CPU: Xeon E5-2680 v4 @ 2.40GHz 64 スレッド。
メモリ：730GB。
Java バージョン: 1.8.0_111

ここで重要な点は、読み取る必要があるテーブル内のデータの量です。実際、HBase キャッシュに完全に配置されているテーブルからデータを読み取る場合、オペレーティング システムの buff/キャッシュからの読み取りは行われません。これは、HBase がデフォルトでメモリの 40% を BlockCache と呼ばれる構造に割り当てるためです。基本的にこれは ConcurrentHashMap で、キーはファイル名 + ブロックのオフセット、値はこのオフセットの実際のデータです。

したがって、この構造だけを読み取ると、 素晴らしいスピードが見られますXNUMX 秒あたり XNUMX 万件のリクエストのようなものです。 しかし、データベースのニーズのためだけに数百ギガバイトのメモリを割り当てることはできないと想像してください。これらのサーバーでは他にも便利な機能がたくさん実行されているからです。

たとえば、私たちの場合、12 つの RS 上の BlockCache のボリュームは約 96 GB です。 4 つのノードに 130 つの RS を配置しました。つまり、すべてのノードで BlockCache に 800 GB が割り当てられます。そして、その何倍ものデータがあります。たとえば、410 つのテーブル、それぞれ XNUMX 領域があり、ファイルのサイズが XNUMX MB で、FAST_DIFF で圧縮されているとします。合計 XNUMX GB (これは純粋なデータ、つまりレプリケーション係数を考慮していない)。

したがって、BlockCache は総データ量の約 23% にすぎず、これはいわゆる BigData の実際の状態にはるかに近いものになります。そして、ここからが楽しみの始まりです。明らかに、キャッシュ ヒットが少ないほど、パフォーマンスが低下するからです。結局のところ、逃した場合は、多くの作業を行う必要があります。システム関数の呼び出しに進みます。ただし、これは避けられないので、まったく別の側面、つまりキャッシュ内のデータはどうなるのかを見てみましょう。

状況を単純化して、1 つのオブジェクトのみに適合するキャッシュがあると仮定しましょう。 以下は、キャッシュの 3 倍のデータ ボリュームを処理しようとすると何が起こるかの例です。次のことを行う必要があります。

1. ブロック 1 をキャッシュに配置します
2. ブロック 1 をキャッシュから削除します
3. ブロック 2 をキャッシュに配置します
4. ブロック 2 をキャッシュから削除します
5. ブロック 3 をキャッシュに配置します

5つのアクションが完了しました！ ただし、この状況は正常とは言えません。実際、HBase にまったく無駄な作業を強制していることになります。 常に OS キャッシュからデータを読み取り、BlockCache に配置しますが、データの新しい部分が到着したため、ほぼすぐにデータを破棄します。 投稿の冒頭のアニメーションは問題の本質を示しています - ガベージコレクターは規模を超え、雰囲気は加熱しており、遠く離れた暑いスウェーデンの小さなグレタさんは動揺しています。 そして、私たち IT 担当者は、子供たちが悲しんでいるのが本当に嫌なので、それに対して何ができるかを考え始めます。

キャッシュがオーバーフローしないように、すべてのブロックをキャッシュに入れるのではなく、特定の割合だけをキャッシュに入れたらどうなるでしょうか? まずは、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 リソースを節約しているのですが、ただちに火星の犬のドブに捨てているだけです。

同時に、CPU 使用率も増加しますが、生産性よりもはるかに低くなります。

BlockCache に保存されるブロックが異なることにも注意してください。ほとんど (約 95%) はデータそのものです。残りはブルーム フィルターや LEAF_INDEX などのメタデータです。 т.д.。 このデータは十分ではありませんが、データに直接アクセスする前に HBase がメタを参照して、ここでさらに検索する必要があるかどうか、必要な場合は対象のブロックが正確にどこにあるかを理解するため、非常に役立ちます。

したがって、コードにはチェック条件があります。 buf.getBlockType().isData() このメタのおかげで、いかなる場合でもキャッシュに残しておきます。

次に、負荷を増やして機能を一度に少し締めてみましょう。 最初のテストではカットオフ パーセンテージ = 20 に設定し、BlockCache はわずかに十分に活用されていませんでした。 次に、これを 23% に設定し、100 分ごとに 5 スレッドを追加して、どの時点で飽和が発生するかを確認してみましょう。

ここでは、元のバージョンでは 100 秒あたり約 300 リクエストがほぼすぐに上限に達していることがわかります。一方、パッチでは最大 XNUMX の加速が得られます。同時に、さらなる高速化がもはや「無料」ではなくなっていることは明らかであり、CPU 使用率も増加しています。

ただし、これはあまり洗練された解決策ではありません。キャッシュに必要なブロックの割合が事前に分からず、負荷プロファイルに依存するからです。したがって、読み取り操作のアクティビティに応じてこのパラメータを自動的に調整するメカニズムが実装されました。

これを制御するために 3 つのオプションが追加されました。

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%

逆に、この機能はオーバーヘッドが正になるまでキャッシュされたブロックの割合を増やします。

以下は、これが実際のデータでどのように見えるかを示す例です。 0%に到達しようとする必要はありません、それは不可能です。約 30 ～ 100% にすると非常に優れており、これは短期間のサージ中に最適化モードが早期に終了することを回避するのに役立ちます。

hbase.lru.cache.heavy.eviction.overhead.coefficient — 結果を得るまでの時間を設定します。 読み取りがほとんど長く、待ちたくないことが確実にわかっている場合は、この比率を高めて、より速く高いパフォーマンスを得ることができます。

たとえば、この係数を 0.01 に設定します。これは、結果としてオーバーヘッド (上記を参照) にこの数値が乗算され、キャッシュされたブロックの割合が減少することを意味します。オーバーヘッド = 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 分後、マルチゲットをオフにします (再びスキャンのみが残ります)。

10000 つの実行を行います。最初に hbase.lru.cache.heavy.eviction.count.limit = 0 (実際に機能を無効にします)、次に、limit = XNUMX (機能を有効にします) を設定します。

以下のログでは、この機能がオンになってオーバーシュートが 14 ～ 71% にリセットされる様子がわかります。時々負荷が減少すると、バックプレッシャーがオンになり、HBase は再びより多くのブロックをキャッシュします。

ログ領域サーバー
エビクション (MB): 0、比率 0.0、オーバーヘッド (%): -100、ヘビーエビクション カウンタ: 0、現在のキャッシュ データブロック (%): 100
エビクション (MB): 0、比率 0.0、オーバーヘッド (%): -100、ヘビーエビクション カウンタ: 0、現在のキャッシュ データブロック (%): 100
エビクション (MB): 2170、比率 1.09、オーバーヘッド (%): 985、ヘビーエビクション カウンタ: 1、現在のキャッシュ データブロック (%): 91 < 開始
エビクション (MB): 3763、比率 1.08、オーバーヘッド (%): 1781、ヘビーエビクション カウンタ: 2、現在のキャッシュ データブロック (%): 76
エビクション (MB): 3306、比率 1.07、オーバーヘッド (%): 1553、ヘビーエビクション カウンタ: 3、現在のキャッシュ データブロック (%): 61
エビクション (MB): 2508、比率 1.06、オーバーヘッド (%): 1154、ヘビーエビクション カウンタ: 4、現在のキャッシュ データブロック (%): 50
エビクション (MB): 1824、比率 1.04、オーバーヘッド (%): 812、ヘビーエビクション カウンタ: 5、現在のキャッシュ データブロック (%): 42
エビクション (MB): 1482、比率 1.03、オーバーヘッド (%): 641、ヘビーエビクション カウンタ: 6、現在のキャッシュ データブロック (%): 36
エビクション (MB): 1140、比率 1.01、オーバーヘッド (%): 470、ヘビーエビクション カウンタ: 7、現在のキャッシュ データブロック (%): 32
エビクション (MB): 913、比率 1.0、オーバーヘッド (%): 356、ヘビーエビクション カウンタ: 8、現在のキャッシュ データブロック (%): 29
エビクション (MB): 912、比率 0.89、オーバーヘッド (%): 356、ヘビーエビクション カウンタ: 9、現在のキャッシュ データブロック (%): 26
エビクション (MB): 684、比率 0.76、オーバーヘッド (%): 242、ヘビーエビクション カウンタ: 10、現在のキャッシュ データブロック (%): 24
エビクション (MB): 684、比率 0.61、オーバーヘッド (%): 242、ヘビーエビクション カウンタ: 11、現在のキャッシュ データブロック (%): 22
エビクション (MB): 456、比率 0.51、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 12、現在のキャッシュ データブロック (%): 21
エビクション (MB): 456、比率 0.42、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 13、現在のキャッシュ データブロック (%): 20
エビクション (MB): 456、比率 0.33、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 14、現在のキャッシュ データブロック (%): 19
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 15、現在のキャッシュ データブロック (%): 19
エビクション (MB): 342、比率 0.32、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 16、現在のキャッシュ データブロック (%): 19
エビクション (MB): 342、比率 0.31、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 17、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.3、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 18、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.29、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 19、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.27、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 20、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.25、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 21、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.24、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 22、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.22、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 23、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.21、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 24、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.2、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 25、現在のキャッシュ データブロック (%): 19
エビクション (MB): 228、比率 0.17、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 26、現在のキャッシュ データブロック (%): 19
エビクション (MB): 456、比率 0.17、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 27、現在のキャッシュ DataBlock (%): 18 < 追加された取得 (ただしテーブルは同じ)
エビクション (MB): 456、比率 0.15、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 28、現在のキャッシュ データブロック (%): 17
エビクション (MB): 342、比率 0.13、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 29、現在のキャッシュ データブロック (%): 17
エビクション (MB): 342、比率 0.11、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 30、現在のキャッシュ データブロック (%): 17
エビクション (MB): 342、比率 0.09、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 31、現在のキャッシュ データブロック (%): 17
エビクション (MB): 228、比率 0.08、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 32、現在のキャッシュ データブロック (%): 17
エビクション (MB): 228、比率 0.07、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 33、現在のキャッシュ データブロック (%): 17
エビクション (MB): 228、比率 0.06、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 34、現在のキャッシュ データブロック (%): 17
エビクション (MB): 228、比率 0.05、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 35、現在のキャッシュ データブロック (%): 17
エビクション (MB): 228、比率 0.05、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 36、現在のキャッシュ データブロック (%): 17
エビクション (MB): 228、比率 0.04、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 37、現在のキャッシュ データブロック (%): 17
エビクション (MB): 109、比率 0.04、オーバーヘッド (%): -46、ヘビーエビクション カウンタ: 37、現在のキャッシュ データブロック (%): 22 < バック プレッシャー
エビクション (MB): 798、比率 0.24、オーバーヘッド (%): 299、ヘビーエビクション カウンタ: 38、現在のキャッシュ データブロック (%): 20
エビクション (MB): 798、比率 0.29、オーバーヘッド (%): 299、ヘビーエビクション カウンタ: 39、現在のキャッシュ データブロック (%): 18
エビクション (MB): 570、比率 0.27、オーバーヘッド (%): 185、ヘビーエビクション カウンタ: 40、現在のキャッシュ データブロック (%): 17
エビクション (MB): 456、比率 0.22、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 41、現在のキャッシュ データブロック (%): 16
エビクション (MB): 342、比率 0.16、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 42、現在のキャッシュ データブロック (%): 16
エビクション (MB): 342、比率 0.11、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 43、現在のキャッシュ データブロック (%): 16
エビクション (MB): 228、比率 0.09、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 44、現在のキャッシュ データブロック (%): 16
エビクション (MB): 228、比率 0.07、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 45、現在のキャッシュ データブロック (%): 16
エビクション (MB): 228、比率 0.05、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 46、現在のキャッシュ データブロック (%): 16
エビクション (MB): 222、比率 0.04、オーバーヘッド (%): 11、ヘビーエビクション カウンタ: 47、現在のキャッシュ データブロック (%): 16
エビクション (MB): 104、比率 0.03、オーバーヘッド (%): -48、ヘビーエビクション カウンタ: 47、現在のキャッシュ データブロック (%): 21 < 割り込みの取得
エビクション (MB): 684、比率 0.2、オーバーヘッド (%): 242、ヘビーエビクション カウンタ: 48、現在のキャッシュ データブロック (%): 19
エビクション (MB): 570、比率 0.23、オーバーヘッド (%): 185、ヘビーエビクション カウンタ: 49、現在のキャッシュ データブロック (%): 18
エビクション (MB): 342、比率 0.22、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 50、現在のキャッシュ データブロック (%): 18
エビクション (MB): 228、比率 0.21、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 51、現在のキャッシュ データブロック (%): 18
エビクション (MB): 228、比率 0.2、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 52、現在のキャッシュ データブロック (%): 18
エビクション (MB): 228、比率 0.18、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 53、現在のキャッシュ データブロック (%): 18
エビクション (MB): 228、比率 0.16、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 54、現在のキャッシュ データブロック (%): 18
エビクション (MB): 228、比率 0.14、オーバーヘッド (%): 14、ヘビーエビクション カウンタ: 55、現在のキャッシュ データブロック (%): 18
エビクション (MB): 112、比率 0.14、オーバーヘッド (%): -44、ヘビーエビクション カウンタ: 55、現在のキャッシュ データブロック (%): 23 < バック プレッシャー
エビクション (MB): 456、比率 0.26、オーバーヘッド (%): 128、ヘビーエビクション カウンタ: 56、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.31、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 57、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 58、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 59、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 60、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 61、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 62、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 63、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.32、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 64、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 65、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 66、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.32、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 67、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 68、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.32、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 69、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.32、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 70、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 71、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 72、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 73、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 74、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 75、現在のキャッシュ データブロック (%): 22
エビクション (MB): 342、比率 0.33、オーバーヘッド (%): 71、ヘビーエビクション カウンタ: 76、現在のキャッシュ データブロック (%): 22
エビクション (MB): 21、比率 0.33、オーバーヘッド (%): -90、ヘビーエビクション カウンタ: 76、現在のキャッシュ データブロック (%): 32
エビクション (MB): 0、比率 0.0、オーバーヘッド (%): -100、ヘビーエビクション カウンタ: 0、現在のキャッシュ データブロック (%): 100
エビクション (MB): 0、比率 0.0、オーバーヘッド (%): -100、ヘビーエビクション カウンタ: 0、現在のキャッシュ データブロック (%): 100

スキャンは、XNUMX つのキャッシュ セクション (これまでにリクエストされたことがないブロック) とマルチ (少なくとも XNUMX 回「リクエストされた」データがここに保存される) の XNUMX つのキャッシュ セクション間の関係をグラフの形式で示すために、同じプロセスを表示する必要がありました。

最後に、パラメーターの操作がグラフの形式でどのように見えるかを示します。 比較のために、最初にキャッシュが完全にオフになり、その後キャッシュを使用して HBase が起動され、最適化作業の開始が 5 分 (30 エビクション サイクル) 遅延されました。

完全なコードはプルリクエストにあります HBASE 23887 github で。

ただし、この条件下でこのハードウェアで達成できるのは 300 秒あたり XNUMX 万読み取りだけではありません。 実際、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 の増加による加速度を示します。

グラフの見方: 100 つのキャッシュを使用した 64 KB ブロックでの 78 万回の読み取りの実行時間は 5 秒かかります。 一方、16 つのキャッシュでは 5 秒かかります。 それらの。 約50倍の加速があります。 グラフからわかるように、並列読み取りの数が少ない場合、効果はあまり顕著ではありませんが、スレッド読み取りが 6 を超えると顕著な役割を果たし始めます。また、SSC の数が XNUMX から増加していることも注目に値します。以上の場合、パフォーマンスの向上は大幅に小さくなります。

注 1: テスト結果は非常に不安定であるため (下記を参照)、3 回の実行を実行し、結果の値を平均しました。

注 2: ランダム アクセスの構成によるパフォーマンスの向上は同じですが、アクセス自体は若干遅くなります。

ただし、HBase の場合とは異なり、この高速化は常に無料であるわけではないことを明確にする必要があります。 ここでは、ロックに依存するのではなく、CPU の能力を「ロック解除」して、より多くの作業を実行できるようにします。

ここでは、一般に、キャッシュの数が増加すると、CPU 使用率もほぼ比例して増加することがわかります。ただし、もう少し多くの勝ちの組み合わせがあります。

たとえば、SSC = 3 の設定を詳しく見てみましょう。レンジでのパフォーマンスの向上は約 3.3 倍です。以下は、XNUMX つの個別の実行すべての結果です。

ただし、CPU 消費量は約 2.8 倍になります。その差はそれほど大きくありませんが、小さなグレタさんはすでに幸せで、学校に通ってレッスンを受ける時間があるかもしれません。

したがって、アプリケーション コードが軽量 (つまり、プラグが HDFS クライアント側にある) で、CPU パワーに空きがある場合、これは HDFS への一括アクセスを使用するツール (Spark など) にとってプラスの効果があります。 。 確認するために、BlockCache の最適化と HBase からの読み取り用の SSC チューニングを組み合わせて使用​​するとどのような影響があるかをテストしてみましょう。

このような条件下では、効果は洗練されたテスト (処理を行わずに読み取る) ほど大きくないことがわかりますが、ここでさらに 80K を絞り出すことは十分に可能です。両方の最適化を組み合わせると、最大 4 倍の高速化が実現します。

今回の最適化についてもPRを行いました [HDFS-15202]、これはマージされており、この機能は将来のリリースで利用できるようになる予定です。

最後に、同様のワイドカラム データベースである Cassandra と HBase の読み取りパフォーマンスを比較するのは興味深いことでした。

これを行うために、標準の YCSB 負荷テスト ユーティリティのインスタンスを 800 つのホスト (合計 4​​4 スレッド) から起動しました。 サーバー側 - XNUMX つのホスト上に、RegionServer と Cassandra の XNUMX つのインスタンス (クライアントの影響を避けるため、クライアントが実行されているホストではありません)。 測定値は次のサイズのテーブルから取得されました。

HBase – HDFS 上で 300 GB (純粋なデータは 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 秒あたり XNUMX 万回の読み取りを達成することが可能になります。

この情報が、生産性を求めるエキサイティングな闘いの最中に誰かの役に立つことを願っています。

出所： habr.com