HBase
 sql >> база данни >  >> NoSQL >> HBase

Как HBase в CDP може да използва S3 на Amazon

Cloudera Data Platform (CDP) предоставя готово решение, което позволява на внедряванията на Apache HBase да използват услугата Amazon Simple Storage Service (S3) като основен постоянен слой за запазване на таблични данни. Amazon S3 е магазин за обекти, който предлага висока степен на издръжливост със структура на разходите за заплащане на употреба. Няма компонент от страна на сървъра, който да стартира или управлява за S3 — всичко, което е необходимо, е клиентската библиотека на S3 и идентификационните данни на AWS. Въпреки това, HBase изисква последователна и атомарна файлова система, което означава, че не може директно да използва S3, тъй като в крайна сметка е последователно хранилище на обекти. И CDH, и HDP са предоставили HBase само с помощта на HDFS, тъй като има дългогодишни пречки, които не позволяват на HBase да използва S3. За да разрешим тези проблеми, ние изградихме готово решение, което доставяме за първи път чрез CDP. Когато стартирате клъстер с оперативна база данни (HBase) на CDP, HBase StoreFiles (подкрепящите файлове за HBase таблици) се съхраняват в S3, а HBase дневниците с предварителна запис (WAL) се съхраняват в HDFS екземпляр, изпълняван заедно с HBase както обикновено.

Ще опишем накратко всеки компонент, който влиза в тази архитектура, и ролята, която всеки изпълнява.

Адаптерът на файлова система S3A се предоставя от Hadoop за достъп до данни в S3 чрез стандартните API на FileSystem. S3A адаптерът позволява на приложения, написани срещу API на Hadoop, да имат достъп до данни в S3, използвайки URI от формата „s3a://my_bucket/“ вместо „hdfs://namenode:8020/“, както при HDFS. Възможността да посочите „файлова система“ по подразбиране, която да се използва, прави миграциите в стил „повдигане и преместване“ от on-prem клъстери с HDFS към облачни клъстери със S3 изключително лесни. HBase може да бъде конфигуриран с базово място за съхранение (например директория в HDFS или S3 кофа) за всички данни на приложението, което позволява на HBase да функционира еднакво, независимо дали тези данни са в HDFS или S3.

S3Guard е част от проекта Apache Hadoop, който осигурява последователен списък на директории и статус на обекти за адаптера S3A, прозрачен за приложението. За да постигне това, S3Guard използва последователна, разпределена база данни за проследяване на промените, направени в S3, и гарантира, че клиентът винаги вижда правилното състояние от S3. Без S3Guard HBase може да не види нов StoreFile, който е добавен към таблица на HBase. Ако HBase дори временно не наблюдава файл, това може да причини загуба на данни в HBase. Въпреки това, S3guard не предоставя всичко, което HBase изисква за използване на S3.

HBase Object Store Semantics (или просто „HBOSS“) е нов софтуерен проект в рамките на проекта Apache HBase, специално създаден за преодоляване на пропастта между S3Guard и HBase. HBOSS е фасада върху S3A адаптера и S3Guard, която използва разпределено заключване, за да гарантира, че операциите на HBase могат атомно манипулирайте неговите файлове на S3. Един пример, в който HBase изисква атомарност, е преименуването на директория. С клиента S3 преименуването се изпълнява като копие на изходните данни до местоназначението, последвано от изтриване на изходните данни. Без заключването, което предоставя HBOSS, HBase може да види в ход операцията по преименуване, което може да причини загуба на данни. За да постигне това разпределено заключване, HBOSS използва Apache ZooKeeper. Повторното използване на ZooKeeper е по проект, тъй като HBase вече изисква екземпляр на ZooKeeper, за да се гарантира, че всички услуги на HBase работят заедно. По този начин включването на HBOSS не изисква допълнителна тежест за управление на услугите и затваря празнината относно това, което HBase изисква, за да използва S3 със S3Guard.

Конфигурирането на HBase да използва S3 за своите StoreFiles има много предимства за нашите потребители. Едно такова предимство е, че потребителите могат да отделят своето съхранение и изчисление. Ако има моменти, в които не е необходим достъп до HBase, HBase може да бъде напълно изключен и всички изчислителни ресурси да бъдат възстановени, за да се елиминират всякакви разходи за работа. Когато отново е необходим достъп до HBase, клъстерът HBase може да бъде пресъздаден, насочвайки към същите данни в S3. При стартиране HBase може да се инициализира отново само от данните в S3.

Използването на S3 за съхраняване на HBase StoreFiles има някои предизвикателства. Един такъв проблем е увеличената латентност за произволно търсене на файл в S3 в сравнение с HDFS. Повишената латентност при достъпа до S3 би довела до получаването и сканирането на HBase да отнема повече време, отколкото обикновено с HDFS. Латенциите на S3 варират от 10 до 100 милисекунди в сравнение с диапазона от 0,1 до 9 милисекунди с HDFS. CDP може да намали въздействието на това забавяне на S3 чрез автоматично конфигуриране на HBase да използва BucketCache. С активиран BucketCache, латентностите на S3 се наблюдават само при първото четене на StoreFile от S3. След като HBase прочете файл, той ще се опита да кешира необработените данни, за да замени бавното четене на S3 с бързо четене от локалната памет. Когато HBase клъстер се стартира чрез CDP, той автоматично се конфигурира да кешира наскоро прочетени данни от S3 в паметта, за да осигури по-бързо четене на „горещи“ данни.

За нас е изключително удоволствие да предоставим тези нови възможности на нашите потребители. Изпробвайте HBase, работещ на S3 в шаблона за оперативна база данни в CDP днес!


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Издание на CDH 6.2:Какво е новото в HBase

  2. Spark-on-HBase:HBase конектор, базиран на DataFrame

  3. Достъпност до оперативна база данни

  4. Използване на Hive за взаимодействие с HBase, част 1

  5. Подобрения в производителността на оперативната база данни в CDP Private Cloud Base 7 срещу CDH5