Cechy HDFS Erasure Coding
Największą zaletą EC (Erasure Coding) w porównianiu do replikacji to redukcja zajętości miejsca. Przy domyślnej replikacji (3) te same dane w EC zajmują połowę powierzchni dyskowych. Dane są przechowywane w różnych lokalizacjach, gdzie nadal mamy pewność, że w przypadku utraty dysku jesteśmy w stanie odbudować brakujące informacje. Zauważmy, że poziom bezpieczeństwa jest taki sam jak w przypadku replikacji tj. mamy 3 kopie. Wygląda to super i tak w rzeczywistości jest, ale.
Jeden z poważniejszych minusów takiego przechowywania to brak lokalności rekordów (danych). Istotna funkcjonalność HDFS to block locality, którą tracimy wraz z uruchomieniem EC, dlatego że pocięte bloki danych są rozrzucane po DataNodach tzn. lokalnie nie mamy pełnej informacji nad którą możemy pracować. Sama obsługa danych w Erasure Coding to proces wymagający większego zaangażowania zasobów.
Erasure Coding to świetny sposób na archiwizacje zimnych danych lub też tworzenie punktów Disaster Recovery.
D A N E
^
└─ D'───D'
/ \ / \
/ \/ \
d' d'' d'''
^^^^^^^^^^^^^^
Cechy replikacji w HDFS
Podstawową strategią utrzymywania danych w wysokiej dostępności w HDFS jest replikacja. Tworzenie kopii bloków pomaga w ciągłej pracy klastra w przypadku awarii dysku/dysków, węzła/węzłów (np. DN) czy nawet całego zespołu serwerów dla konfiguracji (z wdrożonym podziałem na kilka Rack). Teoretycznie (przy replikacji równej n) w idealnych warunkach (każdy blok danych n-repliki znajduje się w tej samej grupie DataNodów - z podziałem na równe grupy) utrata n-1/n maszyn w klastrze nie powinna przerwać jego działania.
Przechowywanie wielu kopii daje również duży zysk w przypadku zrównoleglenia odczytu (np. hot) danych przez klientów, gdyż każdy klient czyta z wybranych DN (DataNodów).
Replikacja a lokalizacja zasobów
Są dwa podejścia do wykonania replikacji.
- W obrębie klastra wykorzystując wbudowane narzędzia lub własne do kopiowania danych pomiędzy instancjami w klastrze i po za nim (np. do AWS S3)
- Tworzyć i zarządzać strumieniami dbając o ciągłe przesyłanie informacji do wybranych klastrów lub elementów po za HDFSem (np. ELK Stack)
Dla replikacji w aplikacjach jest kilka narzędzi, które mają wbudowane opisane mechanizmy.
Apache HBase
Przykładem jest baza danych Apache HBase, gdzie algorytm pomaga przenosić wszystkie modyfikacje w cf (column family) na inny klaster. Istnieje również kompleksowe rozwiązanie typu master-master czy master-follower, gdzie każdy zapis jest w czasie rzeczywistym wysyłany na klaster. Idealnym (optymalnym) środowiskiem jest tu połączenie sieciowe o wysokiej przepustowości i niskiej latency (punkty są ‘blisko siebie’). Należy pamiętać, że to nie zastępuje backupu.
Apache Kafka
Innym przykładem jest Apache Kafka, która potrafi przenosić dane do jednego lub wielu klastwów Hadoop.
Apache Flume
Świetnym narzędziem jest opisywany na blogu Apache Flume http://bigdatapassion.pl/categories/apache-flume/. Narzędzie strumieniuje dane z wielu źródeł do wielu lokalizacji.
Apache Nifi
Coraz częściej spotkamy Apache Nifi jako zamiennik / następca, który obsługuje dużą liczbę komponentów. Nifi zarządza przepływem informacji pomiędzy różnymi systemami, łączy je i zarządza ich dalszym losem.
Apache Oozie
Tu Apache Oozie dobrze współpracuje pomiędzy zasobami przechowywania danych (storage) a bazami danych w różnych kombinacjach. Przykładem jest zrównoleglony odczyt danych z HBase i zapis na HDFS.
Podsumowanie
Do całości można dodać funkcjonalność tworzenia migawek snapshot, która jest demonem prędkości podczas przywracania danych po awarii. Pamiętajmy, że to nadal nie jest pełnoprawna kopia zapasowa, gdyż nie zastąpuje to Disaster Recovery (DR).
