Delen via

Prestatieproblemen van Apache Hbase in Azure HDInsight oplossen

  • Artikel

In dit artikel worden verschillende richtlijnen voor het afstemmen van prestaties van Apache HBase en tips beschreven voor optimale prestaties in Azure HDInsight. Veel van deze tips zijn afhankelijk van de specifieke werkbelasting en het patroon lezen/schrijven/scannen. Voordat u configuratiewijzigingen in een productieomgeving toepast, moet u deze grondig testen.

Inzichten in HBase-prestaties

Het belangrijkste knelpunt in de meeste HBase-workloads is het Write Ahead Log (WAL). Dit heeft ernstige gevolgen voor schrijfprestaties. HDInsight HBase heeft een gescheiden opslag-rekenmodel. Gegevens worden op afstand opgeslagen in Azure Storage, ook al hosten virtuele machines de regioservers. Tot voor kort werd de WAL ook naar Azure Storage geschreven. In HDInsight heeft dit gedrag dit knelpunt versterkt. De functie Versneld schrijven is ontworpen om dit probleem op te lossen. De WAL wordt geschreven naar door Azure Premium SSD beheerde schijven. Dit biedt enorm veel voordelen voor schrijfprestaties en het helpt veel problemen met een aantal schrijfintensieve workloads.

Als u een aanzienlijke verbetering in leesbewerkingen wilt krijgen, gebruikt u premium blok-blobopslagaccount als uw externe opslag. Deze optie is alleen mogelijk als de WAL-functie is ingeschakeld.

Compressie

Compactie is een ander potentieel knelpunt dat fundamenteel is overeengekomen in de gemeenschap. Standaard is zware compressie uitgeschakeld voor HDInsight HBase-clusters. Compressie is uitgeschakeld omdat klanten, ook al is het een resource-intensief proces, volledige flexibiliteit hebben om het te plannen op basis van hun workloads. Ze kunnen het bijvoorbeeld plannen tijdens daluren. Gegevenslocatie is ook geen probleem omdat onze opslag extern is (ondersteund door Azure Storage) in plaats van naar een lokaal Hadoop Distributed File System (HDFS).

Klanten moeten op hun gemak grote compressie plannen. Als ze dit onderhoud niet uitvoeren, zal compressie de leesprestaties in de lange termijn nadelig beïnvloeden.

Voor scanbewerkingen moeten latenties die veel hoger zijn dan 100 milliseconden, een oorzaak van zorg zijn. Controleer of de primaire compressie nauwkeurig is gepland.

Apache Phoenix-workload

Als u de volgende vragen beantwoordt, krijgt u meer inzicht in uw Apache Phoenix-workload:

  • Worden al uw 'leesbewerkingen' vertaald naar scans?
    • Zo ja, wat zijn de kenmerken van deze scans?
    • Hebt u uw Phoenix-tabelschema geoptimaliseerd voor deze scans, inclusief de juiste indexering?
  • Hebt u de EXPLAIN instructie gebruikt om inzicht te krijgen in de queryplannen die uw 'leesbewerkingen' genereren?
  • Zijn uw schrijfbewerkingen 'upsert-selects'?
    • Zo ja, dan doen ze ook scans. De verwachte latentie voor scans bedraagt ongeveer 100 milliseconden, vergeleken met 10 milliseconden voor punten in HBase.

Testmethodologie en bewaking van metrische gegevens

Als u benchmarks zoals Yahoo! gebruikt Cloud Serving Benchmark, JMeter of Pherf om de prestaties te testen en af te stemmen, moet u ervoor zorgen dat:

  • De clientcomputers worden geen knelpunt. Hiervoor controleert u het CPU-gebruik op clientcomputers.

  • Configuraties aan de clientzijde, zoals het aantal threads, worden op de juiste wijze afgestemd op verzadiging van de clientbandbreedte.

  • Testresultaten worden nauwkeurig en systematisch vastgelegd.

Als uw query's plotseling veel erger zijn geworden dan voorheen, controleert u op mogelijke fouten in uw toepassingscode. Worden er plotseling grote hoeveelheden ongeldige gegevens gegenereerd? Als dat zo is, kunnen leeslatenties worden verhoogd.

Migratieproblemen

Als u migreert naar Azure HDInsight, moet u ervoor zorgen dat uw migratie systematisch en nauwkeurig wordt uitgevoerd, bij voorkeur via automatisering. Vermijd handmatige migratie. Zorg voor het volgende:

  • Tabelkenmerken worden nauwkeurig gemigreerd. Kenmerken kunnen worden opgenomen als compressie, bloeifilters, enzovoort.

  • De zoutinstellingen in Phoenix-tabellen worden op de juiste wijze toegewezen aan de nieuwe clustergrootte. Het aantal zoutbuckets moet bijvoorbeeld een veelvoud zijn van het aantal werkknooppunten in het cluster. En u moet een veelvoud gebruiken dat een factor is van de hoeveelheid hot spotting.

Configuratie-afstemming aan serverzijde

In HDInsight HBase worden HFiles opgeslagen in externe opslag. Wanneer er een cache ontbreekt, zijn de kosten van leesbewerkingen hoger dan on-premises systemen, omdat gegevens op on-premises systemen worden ondersteund door lokale HDFS. Voor de meeste scenario's is intelligent gebruik van HBase-caches (blokcache en bucketcache) ontworpen om dit probleem te omzeilen. In gevallen waarin het probleem niet wordt omzeild, kan het gebruik van een Premium-blok-blobaccount dit probleem helpen. Het Windows Azure Storage Blob-stuurprogramma is afhankelijk van bepaalde eigenschappen, zoals fs.azure.read.request.size het ophalen van gegevens in blokken op basis van wat de leesmodus (opeenvolgend versus willekeurig) is, zodat er mogelijk nog steeds exemplaren van hogere latenties met leesbewerkingen zijn. Via empirische experimenten hebben we vastgesteld dat het instellen van de blokgrootte voor leesaanvragen (fs.azure.read.request.size) op 512 kB en het aanpassen van de blokgrootte van de HBase-tabellen aan dezelfde grootte het beste resultaat oplevert in de praktijk.

Voor de meeste grote knooppuntenclusters biedt bucketcache HDInsight HBase een bestand op een lokale Premium SSD die is gekoppeld aan de virtuele machine, die wordt uitgevoerd regionservers. Het gebruik van off-heap-cache kan in plaats daarvan enige verbetering bieden. Deze tijdelijke oplossing heeft de beperking van het gebruik van beschikbaar geheugen en is mogelijk kleiner dan de cache op basis van bestanden, dus het is mogelijk niet altijd de beste keuze.

Hieronder volgen enkele van de andere specifieke parameters die we hebben afgestemd en die leek te helpen in verschillende mate:

  • Vergroot memstore de grootte van standaard 128 MB tot 256 MB. Deze instelling wordt doorgaans aanbevolen voor zware schrijfscenario's.

  • Verhoog het aantal threads dat is toegewezen voor compressie, van de standaardinstelling van 1 tot en met 4. Deze instelling is relevant als we frequente kleine compressies observeren.

  • Voorkom het blokkeren memstore van leegmaken vanwege de opslaglimiet. Als u deze buffer wilt opgeven, verhoogt u de Hbase.hstore.blockingStoreFiles instelling tot 100.

  • Gebruik de volgende instellingen om leegmaken te beheren:

    • Hbase.regionserver.maxlogs: 140 (vermijdt leegmaken vanwege WAL-limieten)

    • Hbase.regionserver.global.memstore.lowerLimit: 0,55

    • Hbase.regionserver.global.memstore.upperLimit: 0,60

  • Phoenix-specifieke configuraties voor het afstemmen van threadpools:

    • Phoenix.query.queuesize: 10000

    • Phoenix.query.threadpoolsize: 512

  • Andere Phoenix-specifieke configuraties:

    • Phoenix.rpc.index.handler.count: 50 (als er grote of veel indexzoekacties zijn)

    • Phoenix.stats.updateFrequency: 1 uur

    • Phoenix.coprocessor.maxmetadatacachetimetolivems: 1 uur

    • Phoenix.coprocessor.maxmetadatacachesize: 50 MB

  • RPC-time-outs: 3 minuten

    • RPC-time-outs omvatten time-out voor HBase RPC, time-out voor HBase-clientscanner en time-out voor Phoenix-query's.
    • Zorg ervoor dat de hbase.client.scanner.caching parameter is ingesteld op dezelfde waarde aan zowel het server- als het clienteindpunt. Als ze niet hetzelfde zijn, leidt deze instelling tot client-endfouten die zijn gerelateerd aan OutOfOrderScannerException. Deze instelling moet worden ingesteld op een lage waarde voor grote scans. We stellen deze waarde in op 100.

Andere overwegingen

Hieronder vindt u aanvullende parameters voor het afstemmen:

  • Hbase.rs.cacheblocksonwrite – deze instelling is standaard ingesteld op true in HDI.

  • Instellingen voor het uitstellen van kleine compressie voor later gebruik.

  • Experimentele instellingen, zoals het aanpassen van percentages van wachtrijen die zijn gereserveerd voor lees- en schrijfaanvragen.

Volgende stappen

Als uw probleem onopgeloste blijft, gaat u naar een van de volgende kanalen voor meer ondersteuning:

  • Krijg antwoorden van Azure-experts via de ondersteuning van De Azure-community.

  • Maak verbinding met @AzureSupport. Dit is het officiële Microsoft Azure-account voor het verbeteren van de klantervaring. Hiermee wordt de Azure-community verbonden met de juiste resources: antwoorden, ondersteuning en experts.

  • Als u meer hulp nodig hebt, kunt u een ondersteuningsaanvraag indienen via Azure Portal. Selecteer Ondersteuning in de menubalk of open de Help + ondersteuningshub . Raadpleeg hoe u een ondersteuning voor Azure aanvraag maakt voor meer informatie. Uw Microsoft Azure-abonnement omvat toegang tot ondersteuning voor abonnementsbeheer en facturering, en technische ondersteuning wordt geboden via een van de ondersteuning voor Azure-abonnementen.