{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Theorie und Praxis der Nutzung von HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Guten Tag! Mein Name ist Danil Lipovoy, unser Team bei Sbertech hat begonnen, HBase als Speicher f\u00fcr operationale Daten zu verwenden. Im Laufe der Untersuchung haben wir Erfahrungen gesammelt, die wir systematisieren und beschreiben wollten (wir hoffen, dass viele davon profitieren werden). Alle nachfolgend aufgef\u00fchrten Experimente wurden mit den Versionen HBase 1.2.0-cdh5.14.2 und 2.0.0-cdh6.0.0-beta1 durchgef\u00fchrt. <\/p>\n

    \n
  1. Allgemeine Architektur <\/li>\n
  2. Datenaufnahme in HBASE<\/li>\n
  3. Datenlesung aus HBASE<\/li>\n
  4. Daten-Caching<\/li>\n
  5. Batch-Verarbeitung von Daten MultiGet\/MultiPut<\/li>\n
  6. Strategie zur Aufteilung von Tabellen in Regionen (Sharding)<\/li>\n
  7. Fehlertoleranz, Kompaktion und Datenlokalit\u00e4t<\/li>\n
  8. Einstellungen und Leistung<\/li>\n
  9. Lasttest<\/li>\n
  10. Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. Allgemeine Architektur<\/h2>\n

    \n\"Theorie
    \nDer Backup-Master h\u00f6rt das Heartbeat des aktiven Masters auf dem ZooKeeper-Knoten und \u00fcbernimmt im Falle eines Ausfalls die Funktionen des Masters. <\/p>\n

    2. Datenaufnahme in HBASE<\/h2>\n

    \nZun\u00e4chst betrachten wir den einfachsten Fall \u2013 das Hinzuf\u00fcgen eines Schl\u00fcssel-Wert-Paares in eine Tabelle mit put(rowkey). Der Client muss zuerst herausfinden, wo sich der Root Region Server (Root Region Server \u2014 RRS) befindet, der die Tabelle hbase:meta speichert. Diese Information erh\u00e4lt er von ZooKeeper. Danach wendet er sich an den RRS und liest die Tabelle hbase:meta, aus der er die Information entnimmt, welcher RegionServer (RS) f\u00fcr die Speicherung der Daten f\u00fcr den angegebenen Schl\u00fcssel rowkey in der gew\u00fcnschten Tabelle verantwortlich ist. F\u00fcr die weitere Verwendung wird die Metadaten-Tabelle im Client zwischengespeichert, sodass nachfolgende Anfragen schneller direkt zum RS gehen.<\/p>\n

    Nachdem der RS die Anfrage erhalten hat, wird sie zuerst im WriteAheadLog (WAL) aufgezeichnet, was f\u00fcr die Wiederherstellung im Falle eines Fehlers notwendig ist. Dann speichert er die Daten im MemStore. Dies ist ein Puffer im Speicher, der eine sortierte Menge von Schl\u00fcsseln dieser Region enth\u00e4lt. Die Tabelle kann in Regionen (Partitionen) unterteilt werden, von denen jede eine nicht \u00fcberlappende Menge von Schl\u00fcsseln enth\u00e4lt. Das erm\u00f6glicht, die Regionen auf verschiedenen Servern zu platzieren, um eine h\u00f6here Leistung zu erzielen. Dennoch, trotz der Offensichtlichkeit dieser Aussage, werden wir sehen, dass dies nicht in allen F\u00e4llen funktioniert.<\/p>\n

    Nach der Ablage des Eintrags im MemStore erh\u00e4lt der Client eine R\u00fcckmeldung, dass der Eintrag erfolgreich gespeichert wurde. Tats\u00e4chlich wird er jedoch nur im Puffer gehalten und gelangt erst nach einem bestimmten Zeitintervall oder bei Auff\u00fcllung mit neuen Daten auf die Festplatte. <\/p>\n

    \"Theorie
    \nBei der Durchf\u00fchrung der Operation \u00abDelete\u00bb erfolgt keine physische L\u00f6schung der Daten. Sie werden lediglich als gel\u00f6scht markiert, und die tats\u00e4chliche Zerst\u00f6rung erfolgt zum Zeitpunkt des Aufrufs der Funktion major compact, die im Detail in Punkt 7 beschrieben wird.<\/p>\n

    Dateien im HFile-Format sammeln sich im HDFS an, und von Zeit zu Zeit wird der Prozess minor compact gestartet, der einfach kleine Dateien zu gr\u00f6\u00dferen zusammenf\u00fcgt, ohne etwas zu l\u00f6schen. Dies wird im Laufe der Zeit zu einem Problem, das sich nur beim Lesen von Daten zeigt (darauf kommen wir sp\u00e4ter zur\u00fcck). <\/p>\n

    Neben dem oben beschriebenen Ladeprozess gibt es ein viel effizienteres Verfahren, das gewisserma\u00dfen die gr\u00f6\u00dfte St\u00e4rke dieser Datenbank darstellt \u2013 BulkLoad. Dabei erstellen wir selbst HFiles und legen sie auf die Festplatte, was eine hervorragende Skalierbarkeit erm\u00f6glicht und ziemlich anst\u00e4ndige Geschwindigkeiten erreicht. Im Grunde genommen ist die Grenze hier nicht HBase, sondern die M\u00f6glichkeiten der Hardware. Im Folgenden sind die Ladeergebnisse in einem Cluster aufgef\u00fchrt, das aus 16 RegionServers und 16 NodeManagers YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Threads) besteht, Version HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Theorie
    \n
    \nHier ist zu sehen, dass mit zunehmender Anzahl der Partitionen (Regionen) in der Tabelle sowie der Spark-Executor die Ladegeschwindigkeit zunimmt. Die Geschwindigkeit h\u00e4ngt auch vom Umfang der Schreibvorg\u00e4nge ab. Gro\u00dfe Bl\u00f6cke f\u00fchren zu einer Zunahme in MB\/Sekunde, kleine in der Anzahl der pro Zeiteinheit eingef\u00fcgten Datens\u00e4tze, bei gleichen Bedingungen. <\/p>\n

    Es ist auch m\u00f6glich, die Ladeprozesse in zwei Tabellen gleichzeitig zu starten und somit die Geschwindigkeit zu verdoppeln. Unten ist zu sehen, dass das gleichzeitige Schreiben von 10 KB-Bl\u00f6cken in zwei Tabellen mit etwa 600 MB\/Sekunde in jede Tabelle erfolgt (insgesamt 1275 MB\/Sekunde), was mit der Schreibgeschwindigkeit in eine Tabelle von 623 MB\/Sekunde \u00fcbereinstimmt (siehe Nr. 11 oben).<\/p>\n

    \"Theorie
    \nDer zweite Versuch mit Aufzeichnungen von 50 KB zeigt jedoch, dass die Ladegeschwindigkeit nur noch geringf\u00fcgig steigt, was auf eine Ann\u00e4herung an die Grenzwerte hinweist. Dabei ist zu beachten, dass die Belastung f\u00fcr HBASE hier praktisch nicht entsteht; alles, was von ihm ben\u00f6tigt wird, ist zun\u00e4chst die \u00dcbermittlung der Daten aus hbase:meta, und nach der Ablage der HFiles die Daten im BlockCache zu leeren und den MemStore-Puffer auf die Festplatte zu speichern, falls er nicht leer ist.<\/p>\n

    3. Lesen von Daten aus HBASE<\/h2>\n

    \nWenn man davon ausgeht, dass der gesamte Inhalt aus hbase:meta bereits beim Kunden vorliegt (siehe Punkt 2), dann geht die Anfrage sofort an denjenigen RS, der den ben\u00f6tigten Schl\u00fcssel speichert. Zuerst erfolgt die Suche in MemCache. Unabh\u00e4ngig davon, ob dort Daten vorhanden sind oder nicht, wird die Suche auch im BlockCache durchgef\u00fchrt und, falls n\u00f6tig, in HFiles. Wenn die Daten in der Datei gefunden werden, werden sie im BlockCache abgelegt und bei der n\u00e4chsten Anfrage schneller zur\u00fcckgegeben. Die Suche in HFile erfolgt relativ schnell dank der Verwendung des Bloom-Filters, d.h. durch das Einlesen eines kleinen Datenvolumens kann sofort festgestellt werden, ob diese Datei den ben\u00f6tigten Schl\u00fcssel enth\u00e4lt, und wenn nicht, wird zur n\u00e4chsten \u00fcbergegangen.<\/p>\n

    \"Theorie
    \nNachdem die Daten aus diesen drei Quellen abgerufen wurden, erstellt der RS eine Antwort. Insbesondere kann er mehrere gefundene Versionen des Objekts \u00fcbermitteln, wenn der Kunde Versionshistorie angefordert hat.<\/p>\n

    4. Daten-Caching<\/h2>\n

    \nDie Puffer MemStore und BlockCache nehmen bis zu 80 % des zugewiesenen On-Heap-Speichers des RS ein (der Rest ist f\u00fcr die Dienstleistungsaufgaben des RS reserviert). Wenn der typische Nutzungsmodus so ist, dass Prozesse diese Daten schreiben und sofort wieder lesen, macht es Sinn, BlockCache zu reduzieren und MemStore zu erh\u00f6hen, da bei der Speicherung die Daten nicht in den Lesecache gelangen. Die Nutzung des BlockCaches w\u00fcrde seltener erfolgen. Der BlockCache-Puffer besteht aus zwei Teilen: LruBlockCache (immer On-Heap) und BucketCache (in der Regel Off-Heap oder auf SSD). BucketCache sollte verwendet werden, wenn es viele Leseanfragen gibt, die nicht in den LruBlockCache passen, was zu einer aktiven Arbeit des Garbage Collectors f\u00fchrt. Dabei ist mit einer radikalen Leistungssteigerung durch die Nutzung des Lesecaches nicht zu rechnen, jedoch werden wir in Punkt 8 noch darauf zur\u00fcckkommen.<\/p>\n

    \"Theorie
    \nDer BlockCache ist f\u00fcr den gesamten RS einheitlich, w\u00e4hrend MemStore f\u00fcr jede Tabelle spezifisch ist (jeweils eines f\u00fcr jede Column Family).<\/p>\n

    Wie beschrieben<\/a><\/noindex> in der Theorie gelangen Daten beim Schreiben nicht in den Cache, und tats\u00e4chlich sind solche Parameter wie CACHE_DATA_ON_WRITE f\u00fcr die Tabelle und \"Cache DATA on Write\" f\u00fcr den RS auf false gesetzt. In der Praxis jedoch, wenn Daten in MemStore geschrieben, dann auf die Festplatte abgelegt werden (was ihn somit leert), und wenn dann die resultierende Datei gel\u00f6scht wird, erhalten wir beim Ausf\u00fchren einer get-Anfrage erfolgreich die Daten. Selbst wenn wir den BlockCache vollst\u00e4ndig deaktivieren und die Tabelle mit neuen Daten f\u00fcllen, dann MemStore auf die Festplatte zur\u00fccksetzen, diese l\u00f6schen und aus einer anderen Sitzung anfragen, werden die Daten dennoch irgendwoher abgerufen. Somit speichert HBase nicht nur Daten, sondern auch mysteri\u00f6se R\u00e4tsel.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nTabelle ns:magic erstellt\nDauer: 1.1533 Sekunden\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'versuche_mich_zu_l\u00f6schen'\nDauer: 0.2610 Sekunden\nhbase(main):003:0> flush 'ns:magic'\nDauer: 0.6161 Sekunden\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, value=versuche_mich_zu_l\u00f6schen\n<\/code><\/pre>\n
    \nDer Parameter \u201eCache DATA on Read\u201c ist auf false gesetzt. Wenn Sie Ideen haben, sind Sie herzlich eingeladen, dies in den Kommentaren zu diskutieren.<\/p>\n
    5. Batch-Datenverarbeitung MultiGet\/MultiPut<\/h2>\n
    \nDie Verarbeitung einzelner Anfragen (Get\/Put\/Delete) ist eine recht kostenintensive Operation, daher sollten diese nach M\u00f6glichkeit in eine Liste zusammengefasst werden, was eine signifikante Leistungssteigerung erm\u00f6glicht. Dies gilt insbesondere f\u00fcr Schreiboperationen, w\u00e4hrend beim Lesen ein gewisses Problem auftritt. Im Diagramm unten ist die Lesezeit von 50.000 Datens\u00e4tzen aus MemStore dargestellt. Das Lesen erfolgte in einem einzigen Thread, und auf der horizontalen Achse ist die Anzahl der Schl\u00fcssel in der Anfrage angegeben. Hier ist zu sehen, dass die Ausf\u00fchrungszeit bei einer Erh\u00f6hung auf bis zu tausend Schl\u00fcssel in einer Anfrage sinkt, d.h. die Geschwindigkeit steigt. Bei aktivem MSLAB-Modus beginnt jedoch nach diesem Schwellenwert ein drastischer Leistungsabfall, wobei die Arbeitszeit mit dem Datenvolumen im Datensatz steigt. <\/p>\n
    \"Theorie
    \n
    \nDie Tests wurden auf einer virtuellen Maschine mit 8 Kernen, Version HBase 2.0.0-cdh6.0.0-beta1, durchgef\u00fchrt.<\/p>\n
    Der MSLAB-Modus soll die Fragmentierung des Heaps reduzieren, die durch die Vermischung neuer und alter Datengenerationen entsteht. Um das Problem zu l\u00f6sen, werden die Daten beim Aktivieren von MSLAB in relativ kleine Zellen (Chunks) platziert und in Portionen verarbeitet. Das Ergebnis ist, dass die Leistung drastisch abnimmt, wenn das Volumen im angeforderten Datenpaket die zugewiesene Gr\u00f6\u00dfe \u00fcberschreitet. Andererseits ist das Deaktivieren dieses Modus ebenfalls unerw\u00fcnscht, da dies zu Pausen aufgrund von GC w\u00e4hrend intensiver Datenverarbeitung f\u00fchrt. Eine gute L\u00f6sung besteht darin, die Chunk-Gr\u00f6\u00dfe zu erh\u00f6hen, wenn gleichzeitig durch put geschrieben wird und gelesen wird. Es ist zu beachten, dass das Problem nicht auftritt, wenn nach dem Schreiben der Befehl flush ausgef\u00fchrt wird, der MemStore auf die Festplatte schreibt, oder wenn der Ladevorgang mit BulkLoad erfolgt. In der folgenden Tabelle ist zu sehen, dass Abfragen aus MemStore mit gr\u00f6\u00dferem Datenvolumen (und gleicher Anzahl) zu einer Verlangsamung f\u00fchren. Durch Erh\u00f6hung der Chunk-Gr\u00f6\u00dfe kann die Verarbeitungszeit jedoch wieder auf den Normalwert zur\u00fcckgef\u00fchrt werden.<\/p>\n
    \"Theorie
    \nNeben der Erh\u00f6hung der chunksize hilft die Datenaufteilung nach Regionen, d.h. das Splitten von Tabellen. Dies f\u00fchrt dazu, dass weniger Anfragen pro Region eingehen und wenn diese in einer Zelle untergebracht sind, bleibt die Antwort gut.<\/p>\n
    6. Strategie zur Aufteilung von Tabellen in Regionen (Splitting)<\/h2>\n
    \nDa HBase ein Key-Value-Speicher ist und die Partitionierung nach Schl\u00fcssel erfolgt, ist es \u00e4u\u00dferst wichtig, die Daten gleichm\u00e4\u00dfig auf alle Regionen zu verteilen. Beispielsweise f\u00fchrt die Partitionierung einer solchen Tabelle in drei Teile dazu, dass die Daten auf drei Regionen aufgeteilt werden:<\/p>\n
    \"Theorie
    \nEs kann vorkommen, dass dies zu einer erheblichen Verlangsamung f\u00fchrt, wenn die sp\u00e4ter hochgeladenen Daten \u00fcberwiegend lange Werte enthalten, die alle mit derselben Ziffer beginnen, z.B.:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Da die Schl\u00fcssel als Byte-Array gespeichert werden, beginnen alle gleich und geh\u00f6ren zu einer Region #1, die diesen Schl\u00fcsselbereich speichert. Es gibt mehrere Aufteilungsstrategien:<\/p>\n
    HexStringSplit \u2013 Wandelt den Schl\u00fcssel in einen String mit hexadezimaler Kodierung im Bereich \u201e00000000\u201c => \u201eFFFFFFFF\u201c um, und f\u00fcllt ihn links mit Nullen auf.<\/p>\n
    UniformSplit \u2013 Wandelt den Schl\u00fcssel in ein Byte-Array mit hexadezimaler Kodierung im Bereich \u201e00\u201c => \u201eFF\u201c um und f\u00fcllt es rechts mit Nullen auf.<\/p>\n
    Au\u00dferdem kann ein beliebiger Bereich oder Satz von Schl\u00fcsseln f\u00fcr die Aufteilung angegeben und das Autospilitting konfiguriert werden. Eine der einfachsten und effektivsten Methoden ist jedoch UniformSplit und die Verwendung der Verkettung des Hashes, z.B. des vorderen Bytes des Schl\u00fcssels, der durch die Funktion CRC32(rowkey) gejagt wird, und des eigentlichen rowkey:<\/p>\n
    hash + rowkey<\/p>\n
    Dann werden alle Daten gleichm\u00e4\u00dfig auf die Regionen verteilt. Beim Lesen werden die ersten beiden Bytes einfach verworfen und der urspr\u00fcngliche Schl\u00fcssel bleibt erhalten. Au\u00dferdem \u00fcberwacht der RS die Menge der Daten und Schl\u00fcssel in der Region und teilt sie automatisch in Teile auf, wenn die Grenzen \u00fcberschritten werden. <\/p>\n
    7. Fehlertoleranz und Datenspeicherlokalit\u00e4t<\/h2>\n
    \nDa jeder Satz von Schl\u00fcsseln nur f\u00fcr eine Region verantwortlich ist, besteht die L\u00f6sung f\u00fcr Probleme, die mit RS-Abst\u00fcrzen oder der Stilllegung verbunden sind, darin, alle erforderlichen Daten in HDFS zu speichern. Bei einem Absturz entdeckt der Master dies durch den fehlenden Heartbeat auf dem ZooKeeper-Knoten. Er weist den verwalteten Region einem anderen RS zu, und da die HFiles in einem verteilten Dateisystem gespeichert sind, liest der neue Besitzer sie ein und setzt die Datenbereitstellung fort. Da jedoch ein Teil der Daten m\u00f6glicherweise im MemStore vorhanden ist und es nicht rechtzeitig zu den HFiles geschafft hat, wird zum Wiederherstellen der Betriebsabl\u00e4ufe WAL verwendet, die ebenfalls in HDFS gespeichert werden. Nach der \u00dcbertragung der \u00c4nderungen kann der RS auf Anfragen reagieren, jedoch f\u00fchrt der Umzug dazu, dass ein Teil der Daten und die zur Bereitstellung dieser Daten dienenden Prozesse auf verschiedenen Knoten liegen, was die Lokalisierung verringert. <\/p>\n
    Die L\u00f6sung des Problems besteht in der Major Compaction \u2013 dieses Verfahren verschiebt Dateien auf die Knoten, die daf\u00fcr verantwortlich sind (dort, wo sich ihre Regionen befinden), wodurch w\u00e4hrend dieses Verfahrens die Belastung des Netzwerks und der Festplatten erheblich steigt. In der Folge wird jedoch der Zugriff auf die Daten deutlich beschleunigt. Dar\u00fcber hinaus f\u00fchrt die Major Compaction die Zusammenf\u00fchrung aller HFiles in eine Datei innerhalb der Region durch und bereinigt die Daten gem\u00e4\u00df den Tabelleneinstellungen. Beispielsweise kann die Anzahl der Versionen eines Objekts festgelegt werden, die beibehalten werden sollen, oder die Lebensdauer des Objekts, nach deren Ablauf es physisch gel\u00f6scht wird.<\/p>\n
    Dieses Verfahren kann sich \u00e4u\u00dferst positiv auf die Leistung von HBase auswirken. Im Bild unten ist zu sehen, wie die Leistung aufgrund aktiver Datenschreibvorg\u00e4nge abgenommen hat. Hier ist ersichtlich, wie in eine Tabelle 40 Threads schrieben und 40 Threads gleichzeitig Daten lasen. Die schreibenden Threads erzeugen immer mehr HFiles, die von anderen Threads eingelesen werden. In der Folge m\u00fcssen immer mehr Daten aus dem Speicher gel\u00f6scht werden, und schlie\u00dflich beginnt der GC zu arbeiten, der die gesamte Arbeit praktisch l\u00e4hmt. Der Start der Major Compaction f\u00fchrte zur Bereinigung der entstandenen Stauungen und zur Wiederherstellung der Leistung.<\/p>\n
    \"Theorie
    \nDer Test wurde auf 3 DataNodes und 4 RS (CPU Xeon E5-2680 v4 @ 2,40 GHz * 64 Threads) durchgef\u00fchrt. HBase-Version 1.2.0-cdh5.14.2<\/p>\n
    Es ist zu beachten, dass der Start der Major Compaction auf einer \u201elebenden\u201c Tabelle durchgef\u00fchrt wurde, in die aktiv Daten geschrieben und gelesen wurden. Es wurde in der Community behauptet, dass dies zu inkorrekten Antworten beim Lesen von Daten f\u00fchren kann. Zur \u00dcberpr\u00fcfung wurde ein Prozess gestartet, der neue Daten generierte und sie in die Tabelle schrieb. Anschlie\u00dfend wurde sofort gelesen und \u00fcberpr\u00fcft, ob der erhaltene Wert mit dem \u00fcbereinstimmt, was geschrieben wurde. W\u00e4hrend dieses Prozesses wurde etwa 200 Mal eine Major Compaction durchgef\u00fchrt und es wurden keine Fehler festgestellt. M\u00f6glicherweise tritt das Problem selten auf und nur bei hoher Auslastung, weshalb es sicherer ist, die Schreib- und Lesevorg\u00e4nge planm\u00e4\u00dfig zu stoppen und die Bereinigung ohne solche GC-Drops durchzuf\u00fchren.<\/p>\n
    Die Major Compaction hat au\u00dferdem keinen Einfluss auf den Zustand des MemStore. Um ihn auf die Festplatte zu schreiben und zu kompakti\ufb01zieren, muss flush verwendet werden (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Einstellungen und Leistung<\/h2>\n
    \nWie bereits erw\u00e4hnt, zeigt HBase den gr\u00f6\u00dften Erfolg dort, wo es nichts tun muss, bei der Durchf\u00fchrung von BulkLoad. Dies gilt jedoch f\u00fcr die meisten Systeme und Menschen. Dieses Tool ist eher f\u00fcr das massenhafte Einf\u00fcllen von Daten in gro\u00dfen Bl\u00f6cken geeignet, w\u00e4hrend, wenn der Prozess viele konkurrierende Lese- und Schreibanfragen erfordert, die oben beschriebenen Get- und Put-Befehle verwendet werden. Zur Bestimmung der optimalen Parameter wurden Testl\u00e4ufe mit verschiedenen Kombinationen von Tabelleneinstellungen und Parametern durchgef\u00fchrt:<\/p>\n