sql >> Database >  >> NoSQL >> HBase

Hoe HBase in CDP de S3 van Amazon kan benutten

Cloudera Data Platform (CDP) biedt een kant-en-klare oplossing waarmee Apache HBase-implementaties Amazon Simple Storage Service (S3) kunnen gebruiken als de belangrijkste persistentielaag voor het opslaan van tabelgegevens. Amazon S3 is een object store die een hoge mate van duurzaamheid biedt met een pay-per-use kostenstructuur. Er is geen server-side component om uit te voeren of te beheren voor S3 - het enige dat nodig is, zijn de S3-clientbibliotheek en AWS-referenties. HBase vereist echter een consistent en atomair bestandssysteem, wat betekent dat het S3 niet rechtstreeks kan gebruiken omdat het een uiteindelijk consistente objectopslag is. Zowel CDH als HDP hebben HBase alleen geleverd met alleen HDFS, omdat er al lang bestaande belemmeringen zijn die verhinderden dat HBase S3 native gebruikte. Om deze problemen aan te pakken, hebben we een kant-en-klare oplossing gebouwd die we voor het eerst via CDP leveren. Wanneer u een Operational Database (HBase)-cluster op CDP start, worden HBase StoreFiles (de backing-bestanden voor HBase-tabellen) opgeslagen in S3 en worden HBase-write-ahead-logs (WAL) opgeslagen in een HDFS-instantie die zoals gebruikelijk naast HBase wordt uitgevoerd.

We zullen in het kort elk onderdeel beschrijven dat in deze architectuur past en de rol die elk vervult.

De S3A-bestandssysteemadapter wordt door Hadoop geleverd om toegang te krijgen tot gegevens in S3 via de standaard FileSystem-API's. Met de S3A-adapter kunnen applicaties die zijn geschreven tegen Hadoop-API's toegang krijgen tot gegevens in S3 met behulp van een URI van de vorm "s3a://my_bucket/" in plaats van "hdfs://namenode:8020/" zoals bij HDFS. De mogelijkheid om een ​​standaard te gebruiken "bestandssysteem" te specificeren, maakt migraties in "lift-and-shift"-stijl van on-prem clusters met HDFS naar cloudgebaseerde clusters met S3 uiterst eenvoudig. HBase kan worden geconfigureerd met een basisopslaglocatie (bijvoorbeeld een directory in HDFS of een S3-bucket) voor alle applicatiegegevens waardoor HBase hetzelfde kan functioneren, ongeacht of die gegevens zich in HDFS of S3 bevinden.

S3Guard maakt deel uit van het Apache Hadoop-project dat een consistente directorylijst en objectstatus voor de S3A-adapter biedt, transparant voor de toepassing. Om dit te bereiken, gebruikt S3Guard een consistente, gedistribueerde database om wijzigingen in S3 bij te houden en garandeert het dat een client altijd de juiste status van S3 ziet. Zonder S3Guard ziet HBase mogelijk geen nieuwe StoreFile die aan een HBase-tabel is toegevoegd. Als HBase een bestand zelfs tijdelijk niet heeft waargenomen, kan dit leiden tot gegevensverlies in HBase. S3guard biedt echter niet alles wat HBase nodig heeft om S3 te gebruiken.

HBase Object Store Semantics (of gewoon "HBOSS") is een nieuw softwareproject onder het Apache HBase-project dat speciaal is gebouwd om de kloof tussen S3Guard en HBase te overbruggen. HBOSS is een façade bovenop de S3A-adapter en S3Guard die een gedistribueerd slot gebruikt om ervoor te zorgen dat HBase-bewerkingen atomisch kunnen zijn bestanden manipuleren op S3. Een voorbeeld waarbij HBase atomiciteit vereist, is het hernoemen van directory's. Met de S3-client wordt een hernoeming geïmplementeerd als een kopie van de brongegevens naar de bestemming, gevolgd door een verwijdering van de brongegevens. Zonder de vergrendeling die HBOSS biedt, kan HBase de hernoemingsbewerking in uitvoering zien, wat kan leiden tot gegevensverlies. Om deze gedistribueerde vergrendeling te realiseren, gebruikt HBOSS Apache ZooKeeper. Hergebruik van ZooKeeper is inherent aan het ontwerp, aangezien HBase al een ZooKeeper-instantie vereist om ervoor te zorgen dat alle HBase-services samen werken. Het opnemen van HBOSS vereist dus geen extra servicebeheerlast en sluit de kloof over wat HBase nodig heeft om S3 te gebruiken met S3Guard.

Het configureren van HBase om S3 te gebruiken voor zijn StoreFiles heeft veel voordelen voor onze gebruikers. Een van die voordelen is dat gebruikers hun opslag en rekenkracht kunnen ontkoppelen. Als er momenten zijn waarop geen toegang tot HBase nodig is, kan HBase netjes worden afgesloten en kunnen alle computerresources worden teruggewonnen om eventuele bedrijfskosten te elimineren. Wanneer HBase-toegang weer nodig is, kan het HBase-cluster opnieuw worden gemaakt, verwijzend naar dezelfde gegevens in S3. Bij het opstarten kan HBase zichzelf alleen opnieuw initialiseren op basis van de gegevens in S3.

Het gebruik van S3 om HBase StoreFiles op te slaan heeft enkele uitdagingen. Een zo'n probleem is de verhoogde latentie voor een willekeurige lookup naar een bestand in S3 in vergelijking met HDFS. Verhoogde latentie in S3-toegang zou ertoe leiden dat HBase Gets en Scans langer duren dan normaal met HDFS. S3-latenties variëren van 10 tot 100 milliseconden in vergelijking met het bereik van 0,1 tot 9 milliseconden met HDFS. CDP kan de impact van deze S3-latentie verminderen door HBase automatisch te configureren om de BucketCache te gebruiken. Als BucketCache is ingeschakeld, treden S3-latenties alleen op de eerste keer dat een StoreFile uit S3 wordt uitgelezen. Nadat HBase een bestand heeft gelezen, zal het proberen de onbewerkte gegevens in de cache op te slaan om langzame S3-lezingen te vervangen door snelle lokale geheugenlezingen. Wanneer een HBase-cluster wordt gestart via CDP, wordt het automatisch geconfigureerd om recent gelezen gegevens van S3 in het geheugen in de cache op te slaan om snellere uitlezingen van "hot" gegevens te leveren.

We zijn zeer verheugd om deze nieuwe mogelijkheden aan onze gebruikers te kunnen bieden. Probeer HBase vandaag nog uit op S3 in de Operational Database-sjabloon in CDP!


  1. Serieel herhalen over een mongodb-cursor (wachten op callbacks voordat u naar het volgende document gaat)

  2. redis inzetten voor heroku kan geen verbinding maken

  3. Wat is het verschil tussen findAndModify en update in MongoDB?

  4. PooledRedisClientManager geeft geen verbindingen vrij