Cloudera Data Platform (CDP) zapewnia gotowe rozwiązanie, które umożliwia wdrożeniom Apache HBase korzystanie z usługi Amazon Simple Storage Service (S3) jako głównej warstwy trwałości do zapisywania danych tabel. Amazon S3 to sklep obiektowy, który oferuje wysoki stopień trwałości ze strukturą kosztów pay-per-use. Nie ma komponentu po stronie serwera do uruchomienia lub zarządzania dla S3 — wystarczy biblioteka klienta S3 i poświadczenia AWS. Jednak HBase wymaga spójnego i atomowego systemu plików, co oznacza, że nie może bezpośrednio używać S3, ponieważ jest to ostatecznie spójna składnica obiektów. Zarówno CDH, jak i HDP dostarczyły HBase tylko przy użyciu HDFS, ponieważ istniały od dawna przeszkody, które uniemożliwiały HBase natywne korzystanie z S3. Aby rozwiązać te problemy, stworzyliśmy gotowe rozwiązanie, które po raz pierwszy dostarczamy za pośrednictwem CDP. Po uruchomieniu klastra operacyjnej bazy danych (HBase) na CDP, HBase StoreFiles (pliki zapasowe dla tabel HBase) są przechowywane w S3, a dzienniki zapisu z wyprzedzeniem (WAL) HBase są przechowywane w wystąpieniu HDFS uruchamianym razem z HBase jak zwykle.
Pokrótce opiszemy każdy komponent, który wchodzi w tę architekturę, oraz rolę, jaką każdy spełnia.
Adapter systemu plików S3A jest dostarczany przez Hadoop, aby uzyskać dostęp do danych w S3 za pośrednictwem standardowych interfejsów API systemu plików. Adapter S3A umożliwia aplikacjom napisanym za pomocą interfejsów API Hadoop dostęp do danych w S3 przy użyciu identyfikatora URI w postaci „s3a://my_bucket/” zamiast „hdfs://namenode:8020/”, jak w przypadku HDFS. Możliwość określenia domyślnego „systemu plików” do użycia sprawia, że migracje w stylu „podnieś i przesuń” z lokalnych klastrów z HDFS do klastrów w chmurze z S3 są niezwykle proste. HBase można skonfigurować z podstawową lokalizacją przechowywania (np. katalog w HDFS lub wiadro S3) dla wszystkich danych aplikacji, co pozwala HBase działać tak samo, niezależnie od tego, czy dane są w HDFS czy S3.
S3Guard jest częścią projektu Apache Hadoop, który zapewnia spójną listę katalogów i status obiektów dla adaptera S3A, niewidoczną dla aplikacji. Aby to osiągnąć, S3Guard wykorzystuje spójną, rozproszoną bazę danych do śledzenia zmian wprowadzanych w S3 i gwarantuje, że klient zawsze widzi prawidłowy stan z S3. Bez S3Guard HBase może nie widzieć nowego StoreFile, który został dodany do tabeli HBase. Jeśli HBase nawet tymczasowo nie zaobserwował pliku, może to spowodować utratę danych w HBase. Jednak S3guard nie zapewnia wszystkiego, czego HBase wymaga do korzystania z S3.
HBase Object Store Semantics (lub po prostu „HBOSS”) to nowy projekt oprogramowania w ramach projektu Apache HBase stworzony specjalnie w celu wypełnienia luki między S3Guard i HBase. HBOSS to fasada na szczycie adaptera S3A i S3Guard, która wykorzystuje rozproszoną blokadę, aby zapewnić, że operacje HBase mogą atomowo manipulować jego plikami na S3. Jednym z przykładów, w których HBase wymaga niepodzielności, jest zmiana nazwy katalogu. W przypadku klienta S3 zmiana nazwy jest implementowana jako kopia danych źródłowych do miejsca docelowego, po której następuje usunięcie danych źródłowych. Bez blokowania zapewnianego przez HBOSS, HBase może zobaczyć trwającą operację zmiany nazwy, która może spowodować utratę danych. Aby zrealizować to rozproszone blokowanie, HBOSS używa Apache ZooKeeper. Ponowne użycie ZooKeeper jest zgodne z projektem, ponieważ HBase wymaga już wystąpienia ZooKeeper, aby zapewnić, że wszystkie usługi HBase działają razem. W związku z tym włączenie HBOSS nie wymaga dodatkowych obciążeń związanych z zarządzaniem usługami i wypełnia lukę w zakresie tego, czego wymaga HBase do korzystania z S3 z S3Guard.
Skonfigurowanie HBase do korzystania z S3 dla StoreFiles ma wiele zalet dla naszych użytkowników. Jedną z takich korzyści jest to, że użytkownicy mogą oddzielić swoją pamięć i obliczenia. Jeśli zdarzają się sytuacje, w których nie jest konieczny dostęp do HBase, HBase można czysto zamknąć i odzyskać wszystkie zasoby obliczeniowe, aby wyeliminować wszelkie koszty operacyjne. Gdy dostęp HBase jest ponownie potrzebny, można odtworzyć klaster HBase, wskazując te same dane w S3. Po uruchomieniu HBase może ponownie zainicjować się wyłącznie z danych w S3.
Używanie S3 do przechowywania HBase StoreFiles wiąże się z pewnymi wyzwaniami. Jednym z takich problemów jest zwiększone opóźnienie losowego wyszukiwania pliku w S3 w porównaniu z HDFS. Zwiększone opóźnienie w dostępie S3 spowodowałoby, że pobieranie i skanowanie HBase trwałoby dłużej niż normalnie zajęłoby to w przypadku HDFS. Opóźnienia S3 wahają się od 10 do 100 milisekund w porównaniu z zakresem od 0,1 do 9 milisekund w przypadku HDFS. Protokół CDP może zmniejszyć wpływ tego opóźnienia S3, automatycznie konfigurując HBase do korzystania z BucketCache. Po włączeniu BucketCache opóźnienia S3 występują tylko przy pierwszym odczytaniu StoreFile z S3. Gdy HBase odczyta plik, spróbuje buforować nieprzetworzone dane, aby zastąpić powolne odczyty S3 szybkimi odczytami z pamięci lokalnej. Gdy klaster HBase jest uruchamiany przez CDP, jest on automatycznie konfigurowany do buforowania ostatnio odczytanych danych z pamięci S3, aby zapewnić szybsze odczyty „gorących” danych.
Jesteśmy niezmiernie zadowoleni, że możemy udostępnić te nowe możliwości naszym użytkownikom. Wypróbuj HBase działającego na S3 w szablonie operacyjnej bazy danych w CDP już dziś!
