Megosztás a következőn keresztül:

Apache HBase-tanácsadások az Azure HDInsightban

  • Cikk

Ez a cikk számos olyan tanácsadást ismertet, amelyekkel optimalizálhatja az Apache HBase teljesítményét az Azure HDInsightban.

A HBase optimalizálása a legutóbb írt adatok olvasásához

Ha a használati eset a legutóbb írt adatok HBase-ből való beolvasását foglalja magában, ez a tanácsadás segíthet Önnek. A nagy teljesítmény érdekében optimális, hogy a HBase-olvasások a távoli tároló helyett a -ből memstorelegyenek kiszolgálva.

A lekérdezési tanácsadás azt jelzi, hogy egy tábla egy adott oszlopcsaládja esetében a rendszer > 75%-os olvasási adatokat olvas, amelyeket a rendszer kiszolgál.memstore Ez a mutató azt sugallja, hogy még akkor is, ha a memstore legutóbbi fájl kiürítése történik, hozzá kell férni, és a gyorsítótárban kell lennie. Az adatok először a rendszerbe vannak írva memstore , és ott férnek hozzá a legutóbbi adatokhoz. Előfordulhat, hogy a belső HBase-öblítőszálak észlelik, hogy egy adott régió elérte a 128 M (alapértelmezett) méretet, és kiürítést indíthat el. Ez a forgatókönyv még a legutóbbi adatokkal is előfordul, amelyeket akkor írtak, amikor az memstore körülbelül 128 M méretű volt. Ezért előfordulhat, hogy a legutóbbi rekordok későbbi olvasásához nem a fájlból, hanem egy fájlolvasásra memstorevan szükség. Ezért érdemes optimalizálni, hogy még a legutóbb kiürített adatok is a gyorsítótárban legyenek.

A gyorsítótárban lévő legutóbbi adatok optimalizálásához vegye figyelembe a következő konfigurációs beállításokat:

  1. Állítsa a hbase.rs.cacheblocksonwrite elemet true értékre. Ez az alapértelmezett konfiguráció a HDInsight HBase-ben , trueezért ellenőrizze, hogy nem áll-e alaphelyzetbe false.

  2. Növelje az hbase.hstore.compactionThreshold értéket, hogy elkerülje a tömörítés beindulását. Alapértelmezés szerint ez az érték: 3. A értékét magasabb értékre növelheti, például 10: .

  3. Ha a 2. lépést követi, és beállítja a compactionThreshold értéket, akkor váltson hbase.hstore.compaction.max magasabb értékre például 100, és növelje a konfiguráció hbase.hstore.blockingStoreFiles értékét magasabb értékre, például 300.

  4. Ha biztos abban, hogy csak a legutóbbi adatokat kell olvasnia, állítsa a hbase.rs.cachecompactedblocksonwrite konfigurációt BE értékre. Ez a konfiguráció azt jelzi a rendszernek, hogy még tömörítés esetén is az adatok a gyorsítótárban maradnak. A konfigurációk családi szinten is beállíthatók.

    A HBase-rendszerhéjban futtassa a következő parancsot a konfiguráció beállításához hbase.rs.cachecompactedblocksonwrite :

    alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}

  5. A blokkgyorsítótár ki lehet kapcsolni egy tábla egy adott családját. Győződjön meg arról, hogy be van kapcsolva a legutóbbi adatolvasást használó családok esetében. Alapértelmezés szerint a blokkgyorsítótár be van kapcsolva a táblázatban lévő összes család esetében. Ha letiltotta egy család blokkgyorsítótárát, és be kell kapcsolnia, használja a hbase rendszerhéj alter parancsát.

    Ezek a konfigurációk segítenek biztosítani, hogy az adatok elérhetők legyenek a gyorsítótárban, és hogy a legutóbbi adatok ne legyenek tömörítve. Ha a forgatókönyvben TTL is lehetséges, fontolja meg a dátumszintű tömörítés használatát. További információ: Apache HBase referencia-útmutató: Date Tiered Compaction

A kiürítési üzenetsor optimalizálása

Ez a tanácsadás azt jelzi, hogy a HBase-kiürítések hangolást igényelhetnek. Előfordulhat, hogy a kiürítési kezelők jelenlegi konfigurációja nem elég magas ahhoz, hogy olyan írási forgalommal kezeljen, amely a kiürítések lelassulásához vezethet.

A régiókiszolgáló felhasználói felületén figyelje meg, hogy a kiürítési üzenetsor 100-nál nagyobbra nő-e. Ez a küszöbérték azt jelzi, hogy a kiürítések lassúak, és előfordulhat, hogy hangolnia kell a konfigurációt hbase.hstore.flusher.count . Alapértelmezés szerint az érték 2. Győződjön meg arról, hogy a maximális öblítőszálak nem növekednek 6-ot meghaladóan.

Emellett ellenőrizze, hogy van-e javaslat a régiók számának finomhangolásához. Ha igen, javasoljuk, hogy próbálja ki a régió finomhangolását, és ellenőrizze, hogy ez segít-e a gyorsabb kiürítésben. Ellenkező esetben az öblítőszálak finomhangolása segíthet.

Régiók számának finomhangolása

A régiószám finomhangolási tanácsadása azt jelzi, hogy a HBase blokkolta a frissítéseket, és a régiószám meghaladhatja az optimálisan támogatott halommemória-méretet. A halommemória méretét, memstore méretét és régiószámát hangolhatja.

Példaforgatókönyvként:

  • Tegyük fel, hogy a régiókiszolgáló halommérete 10 GB. Alapértelmezés szerint a hbase.hregion.memstore.flush.size értéke 128M. A alapértelmezett értéke hbase.regionserver.global.memstore.size a következő: 0.4. Ez azt jelenti, hogy a 10 GB-ból 4 GB van lefoglalva memstore (globálisan).

  • Tegyük fel, hogy az írási terhelés egyenletesen oszlik el az összes régión, és feltételezve, hogy minden régió legfeljebb 128 MB-ra nő, akkor a beállításban szereplő régiók maximális száma régiók.32 Ha egy adott régiókiszolgáló 32 régióra van konfigurálva, a rendszer jobban elkerüli a frissítések blokkolását.

  • Ezekkel a beállításokkal a régiók száma 100. A globális 4 GB-os csomag memstore jelenleg 100 régióra oszlik. Így gyakorlatilag minden régió csak 40 MB-ot kap a számára memstore. Ha az írások egységesek, a rendszer gyakran ürít és kisebb méretű 40 MB-os megrendelést < . Ha sok öblítőszál van, az növelheti a kiürítési sebességet hbase.hstore.flusher.count.

A tanácsadás azt jelenti, hogy érdemes megfontolni a kiszolgálókonkénti régiók számát, a halomméretet és a globális memstore méretkonfigurációt, valamint a kiürítési szálak finomhangolását, hogy a frissítések ne legyenek blokkolva.

Tömörítési várólista finomhangolása

Ha a HBase tömörítési üzenetsora 2000-nél többre nő, és rendszeres időközönként megtörténik, a tömörítési szálakat nagyobb értékre növelheti.

Ha túl sok fájlt kell tömöríteni, az több halommemória-használathoz vezethet azzal kapcsolatban, hogy a fájlok hogyan kommunikálnak az Azure fájlrendszerével. Ezért jobb, ha a tömörítést a lehető leggyorsabban befejezi. A régebbi fürtökben bizonyos esetekben a szabályozáshoz kapcsolódó tömörítési konfigurációk lassabb tömörítési sebességhez vezethetnek.

Ellenőrizze a konfigurációkat és hbase.hstore.compaction.throughput.higher.bounda elemethbase.hstore.compaction.throughput.lower.bound. Ha már 50M és 100M értékre vannak állítva, hagyja meg őket. Ha azonban alacsonyabb értékre konfigurálta ezeket a beállításokat (a régebbi fürtök esetében ez volt a helyzet), módosítsa a korlátokat 50 M és 100M értékre.

A konfigurációk a hbase.regionserver.thread.compaction.small és hbase.regionserver.thread.compaction.large (az alapértelmezett értékek egyenként 1). A konfiguráció maximális értékének korlátja 3-nál kisebb legyen.

Teljes táblázatos vizsgálat

A teljes táblavizsgálati tanácsadás azt jelzi, hogy a kiadott vizsgálatok több mint 75%-a teljes tábla-/régióvizsgálat. A lekérdezési teljesítmény javítása érdekében újra áttekintheti, hogy a kód hogyan hívja meg a vizsgálatokat. Vegye figyelembe az alábbi eljárásokat:

  • Állítsa be a megfelelő kezdő és leállítási sort minden vizsgálathoz.

  • Használja a MultiRowRangeFilter API-t, hogy egy vizsgálati hívás különböző tartományait kérdezhesse le. További információ: MultiRowRangeFilter API-dokumentáció.

  • Azokban az esetekben, amikor teljes tábla- vagy régióvizsgálatra van szükség, ellenőrizze, hogy lehetséges-e elkerülni a gyorsítótár használatát ezeknél a lekérdezéseknél, hogy a gyorsítótárat használó más lekérdezések ne zárják ki a gyakori elérésű blokkokat. Annak érdekében, hogy a vizsgálatok ne használjanak gyorsítótárat, használja a scan API-t a setCaching(false) beállítással a kódban:

    scan#setCaching(false)

Következő lépések

Az Apache HBase optimalizálása az Ambari használatával