{"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 Speichersystem f\u00fcr operative Daten zu nutzen. Im Laufe unserer Untersuchungen haben wir Erfahrungen gesammelt, die wir systematisieren und dokumentieren wollten (wir hoffen, dass viele davon profitieren k\u00f6nnen). Alle nachfolgend aufgef\u00fchrten Experimente wurden mit den HBase-Versionen 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. Datenschreibung in HBase<\/li>\n
  3. Datenlesen aus HBase<\/li>\n
  4. Daten-Caching<\/li>\n
  5. Batchverarbeitung von Daten MultiGet\/MultiPut<\/li>\n
  6. Tabelle-Regionen-Split-Strategie<\/li>\n
  7. Fehlertoleranz, Kompaktierung und Datenlokalit\u00e4t<\/li>\n
  8. Einstellungen und Leistung<\/li>\n
  9. Lasttest<\/li>\n
  10. Fazit<\/li>\n<\/ol>\n

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

    1. Allgemeine Architektur<\/h2>\n

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

    2. Datenschreibung in HBase<\/h2>\n

    \nZuerst betrachten wir den einfachsten Fall \u2013 das Schreiben eines Schl\u00fcssel-Wert-Objekts in eine Tabelle mithilfe von put(rowkey). Der Client muss zuerst herausfinden, wo sich der Root Region Server (RRS) befindet, der die Tabelle hbase:meta speichert. Diese Informationen erh\u00e4lt er von ZooKeeper. Anschlie\u00dfend wendet er sich an den RRS und liest die Tabelle hbase:meta, aus der er die Informationen dar\u00fcber entnimmt, welcher RegionServer (RS) f\u00fcr die Speicherung der Daten f\u00fcr den angegebenen Schl\u00fcssel rowkey in der von ihm interessierten Tabelle verantwortlich ist. Zur weiteren Verwendung wird die Metatabelle vom Client zwischengespeichert, sodass nachfolgende Zugriffe schneller direkt zum RS erfolgen.<\/p>\n

    Danach schreibt RS, nachdem es die Anfrage erhalten hat, zun\u00e4chst in das WriteAheadLog (WAL), was f\u00fcr die Wiederherstellung im Falle eines Ausfalls erforderlich ist. Danach werden die Daten im MemStore gespeichert. Dies ist ein Speicherpuffer, der eine sortierte Menge von Schl\u00fcsseln f\u00fcr diese Region enth\u00e4lt. Die Tabelle kann in Regionen (Partitionen) unterteilt werden, von denen jede eine nicht \u00fcberschneidende Menge von Schl\u00fcsseln enth\u00e4lt. Dadurch kann durch die Verteilung der Regionen auf verschiedene Server eine h\u00f6here Leistung erzielt werden. Trotz der offensichtlichen Natur dieser Aussage werden wir jedoch sehen, dass dies nicht in allen F\u00e4llen funktioniert.<\/p>\n

    Nach dem Ablegen des Eintrags im MemStore erh\u00e4lt der Kunde eine R\u00fcckmeldung, dass der Eintrag erfolgreich gespeichert wurde. Tats\u00e4chlich wird er jedoch nur im Puffer gespeichert und gelangt erst auf die Festplatte, nachdem ein gewisser Zeitraum vergangen ist oder wenn er mit neuen Daten gef\u00fcllt wird. <\/p>\n

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

    HFile-Dateien sammeln sich im HDFS und gelegentlich wird ein Minor Compact-Prozess gestartet, der einfach kleine Dateien zu gr\u00f6\u00dferen zusammenf\u00fchrt, ohne etwas zu l\u00f6schen. Im Laufe der Zeit f\u00fchrt dies zu einem Problem, das sich nur beim Lesen von Daten bemerkbar macht (darauf kommen wir sp\u00e4ter zur\u00fcck). <\/p>\n

    Neben dem oben beschriebenen Upload-Prozess gibt es ein viel effizienteres Verfahren, das wohl die st\u00e4rkste Seite dieser Datenbank ist \u2013 BulkLoad. Dabei erstellen wir HFiles selbst und legen sie auf die Festplatte, was eine hervorragende Skalierbarkeit und durchaus respektable Geschwindigkeiten erm\u00f6glicht. Letztlich ist hier nicht HBase die Grenze, sondern die M\u00f6glichkeiten der Hardware. Nachfolgend sind die Ergebnisse des Uploads in einem Cluster mit 16 RegionServern und 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2,40 GHz * 64 Threads), Version HBase 1.2.0-cdh5.14.2, aufgef\u00fchrt. <\/p>\n

    \"Theorie
    \n
    \nHier ist zu erkennen, dass die Erh\u00f6hung der Anzahl der Partitionen (Regionen) in der Tabelle sowie der Spark-Executors die Upload-Geschwindigkeit steigert. Zudem h\u00e4ngt die Geschwindigkeit vom Volumen der Schreibvorg\u00e4nge ab. Gro\u00dfe Bl\u00f6cke f\u00fchren zu einem Anstieg in MB\/s, kleine hingegen erh\u00f6hen die Anzahl der eingef\u00fcgten Datens\u00e4tze pro Zeiteinheit, unter ansonsten gleichen Bedingungen. <\/p>\n

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

    \"Theorie
    \nDer zweite Durchlauf mit 50-KB-Eintr\u00e4gen zeigt, dass die Ladegeschwindigkeit nur geringf\u00fcgig steigt, was auf ann\u00e4hernde Grenzwerte hinweist. Dabei sollte ber\u00fccksichtigt werden, dass die Belastung f\u00fcr HBASE praktisch nicht entsteht; alles, was von ihm gefordert wird, besteht darin, zuerst die Daten aus hbase:meta bereitzustellen und nach der Ablage von HFiles die Daten im BlockCache zur\u00fcckzusetzen und den MemStore-Puffer auf die Festplatte zu speichern, sofern dieser nicht leer ist.<\/p>\n

    3. Daten aus HBASE lesen<\/h2>\n

    \nWenn man davon ausgeht, dass der Kunde bereits alle Informationen aus hbase:meta hat (siehe Punkt 2), wird die Anfrage sofort an den RS gesendet, wo der ben\u00f6tigte Schl\u00fcssel gespeichert ist. Zun\u00e4chst erfolgt die Suche in MemCache. Unabh\u00e4ngig davon, ob dort Daten vorhanden sind oder nicht, wird auch im BlockCache und bei Bedarf in HFiles gesucht. Wenn die Daten in der Datei gefunden werden, werden sie in den BlockCache gelegt und bei der n\u00e4chsten Anfrage schneller zur\u00fcckgegeben. Die Suche in HFile erfolgt relativ schnell dank der Verwendung des Bloom Filters, d.h. nachdem eine kleine Datenmenge gelesen wurde, kann sofort festgestellt werden, ob diese Datei den ben\u00f6tigten Schl\u00fcssel enth\u00e4lt. Falls nicht, wird zur n\u00e4chsten gewechselt.<\/p>\n

    \"Theorie
    \nNachdem Daten aus diesen drei Quellen erhalten wurden, formt der RS die Antwort. Insbesondere kann er mehrere gefundene Versionen des Objekts gleichzeitig \u00fcbermitteln, wenn der Kunde nach Versionsverwaltung gefragt hat.<\/p>\n

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

    \nDie MemStore- und BlockCache-Puffer nehmen bis zu 80 % des zugewiesenen on-heap Speichers des RS ein (der Rest ist f\u00fcr die Dienstaufgaben des RS reserviert). Wenn der typische Nutzungsmodus so ist, dass Prozesse diese Daten schreiben und sofort wieder lesen, macht es Sinn, den BlockCache zu reduzieren und den MemStore zu erh\u00f6hen, da beim Schreiben die Daten nicht in den Lesekernel gelangen und der BlockCache seltener verwendet wird. Der BlockCache besteht aus zwei Teilen: LruBlockCache (immer on-heap) und BucketCache (in der Regel off-heap oder auf SSD). Den BucketCache sollte man verwenden, wenn es viele Leseanfragen gibt, die nicht im LruBlockCache Platz finden, was zu einer aktiven Arbeit des Garbage Collectors f\u00fchrt. Dabei sollte man jedoch keine radikalen Leistungssteigerungen durch die Verwendung des Lesekerns erwarten; darauf kommen wir in Punkt 8 zur\u00fcck.<\/p>\n

    \"Theorie
    \nDer BlockCache ist f\u00fcr den gesamten RS einheitlich, w\u00e4hrend der MemStore f\u00fcr jede Tabelle individuell ist (je einer f\u00fcr jede Spaltenfamilie).<\/p>\n

    Wie beschrieben<\/a><\/noindex> In der Theorie gelangen Daten beim Schreiben nicht in den Cache, und tats\u00e4chlich sind die Parameter CACHE_DATA_ON_WRITE f\u00fcr die Tabelle und \u201eCache DATA on Write\u201c f\u00fcr RS auf false gesetzt. In der Praxis jedoch, wenn Daten in den MemStore geschrieben und dann auf die Festplatte zur\u00fcckgesp\u00fclt werden (somit gel\u00f6scht), erhalten wir beim Ausf\u00fchren einer Abrufanfrage dennoch erfolgreich die Daten. Selbst wenn wir den BlockCache komplett deaktivieren und die Tabelle mit neuen Daten f\u00fcllen, dann den MemStore auf die Festplatte zur\u00fccksp\u00fclen, sie l\u00f6schen und aus einer anderen Sitzung anfordern, werden sie trotzdem irgendwoher abgerufen. HBase speichert also nicht nur Daten, sondern auch geheimnisvolle R\u00e4tsel.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nCreated table ns:magic\nTook 1.1533 seconds\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nTook 0.2610 seconds\nhbase(main):003:0> flush 'ns:magic'\nTook 0.6161 seconds\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, value=try_to_delete_me\n<\/code><\/pre>\n
    \nDer Parameter \u201eCache DATA on Read\u201c ist auf false gesetzt. Wenn es Ideen gibt, sind Sie herzlich eingeladen, dies in den Kommentaren zu besprechen.<\/p>\n
    5. Batch-Datenverarbeitung MultiGet\/MultiPut<\/h2>\n
    \nDie Verarbeitung einzelner Anfragen (Get\/Put\/Delete) ist eine recht kostspielige Operation, daher sollten sie nach M\u00f6glichkeit in einer Liste zusammengefasst werden, um eine betr\u00e4chtliche Leistungssteigerung zu erzielen. Dies gilt insbesondere f\u00fcr Schreiboperationen, w\u00e4hrend beim Lesen ein weiterer Stolperstein zu beachten ist. Im unteren Diagramm 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 angezeigt. Hier ist zu sehen, dass bei einer Erh\u00f6hung auf bis zu tausend Schl\u00fcssel in einer Anfrage die Ausf\u00fchrungszeit sinkt, d.h. die Geschwindigkeit steigt. Allerdings tritt beim standardm\u00e4\u00dfig aktivierten MSLAB-Modus nach diesem Schwellenwert ein drastischer Leistungsabfall auf, und je gr\u00f6\u00dfer das Datenvolumen im Datensatz ist, desto l\u00e4nger dauert die Verarbeitung. <\/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 wurde entwickelt, um die Fragmentierung des Heaps zu reduzieren, die durch das Mischen von Daten neuer und alter Generationen entsteht. Um dieses Problem zu l\u00f6sen, werden beim Aktivieren von MSLAB die Daten in relativ kleine Einheiten (Chunks) eingeordnet und in Portionen verarbeitet. Dadurch sinkt die Leistung erheblich, wenn die Gr\u00f6\u00dfe des angeforderten Datenpakets den zugewiesenen Speicher \u00fcberschreitet. Andererseits ist das Deaktivieren dieses Modus ebenfalls unerw\u00fcnscht, da dies zu Stopps durch GC w\u00e4hrend intensiver Datenverarbeitung f\u00fchrt. Eine gute L\u00f6sung ist die Erh\u00f6hung der Chunk-Gr\u00f6\u00dfe, wenn gleichzeitig Daten durch Put geschrieben und gelesen werden. Es ist erw\u00e4hnenswert, dass das Problem nicht auftritt, wenn nach dem Schreiben der Befehl Flush ausgef\u00fchrt wird, der den MemStore auf die Festplatte zur\u00fcckschreibt, oder wenn der Upload mithilfe von BulkLoad erfolgt. Die folgende Tabelle zeigt, dass Anfragen aus dem MemStore mit gr\u00f6\u00dferem Volumen (und der gleichen Anzahl) zu einer Verlangsamung f\u00fchren. Allerdings wird die Verarbeitungszeit durch Erh\u00f6hung der Chunk-Gr\u00f6\u00dfe wieder auf das Normalniveau zur\u00fcckgebracht.<\/p>\n
    \"Theorie
    \nZus\u00e4tzlich zur Erh\u00f6hung der Chunkgr\u00f6\u00dfe hilft die Aufteilung der Daten nach Regionen, also dem Splitten von Tabellen. Dadurch erh\u00e4lt jede Region weniger Anfragen, und wenn sie in eine Zelle passen, bleibt die Antwortzeit gut.<\/p>\n
    6. Strategie zur Aufteilung von Tabellen auf Regionen (Splitting)<\/h2>\n
    \nDa HBase ein Key-Value-Speicher ist und die Partitionierung nach dem Schl\u00fcssel erfolgt, ist es entscheidend, 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 passieren, dass dies zu einer erheblichen Verlangsamung f\u00fchrt, wenn die anschlie\u00dfend geladenen Daten beispielsweise lange Werte enthalten, die gr\u00f6\u00dftenteils mit derselben Ziffer beginnen, zum Beispiel:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Da die Schl\u00fcssel als Byte-Arrays gespeichert werden, werden sie alle gleich anfangen und zu einer Region #1 geh\u00f6ren, die diesen Schl\u00fcsselbereich speichert. Es gibt mehrere Strategien f\u00fcr die Aufteilung:<\/p>\n
    HexStringSplit \u2013 Wandelt den Schl\u00fcssel in eine Zeichenfolge mit hexadezimaler Kodierung im Bereich von \u201e00000000\u201c bis \u201eFFFFFFFF\u201c um und f\u00fcllt links mit Nullen auf.<\/p>\n
    UniformSplit \u2013 Wandelt einen Schl\u00fcssel in ein Byte-Array mit einer hexadezimalen Kodierung im Bereich von \u00ab00\u00bb bis \u00abFF\u00bb um und f\u00fcllt ihn rechts mit Nullen auf.<\/p>\n
    Dar\u00fcber hinaus kann ein beliebiger Bereich oder eine Gruppe von Schl\u00fcsseln f\u00fcr die Aufteilung angegeben und das Autoplenning konfiguriert werden. Eine der einfachsten und effektivsten Methoden ist jedoch UniformSplit und die Verwendung der Hash-Konkatenation, etwa des vorderen Byte-Paares aus der Anwendung der Funktion CRC32(rowkey) auf den Schl\u00fcssel und dem 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 RS die Menge der Daten und Schl\u00fcssel in der Region und teilt sie automatisch in Teile auf, wenn die Limits \u00fcberschritten werden. <\/p>\n
    7. Fehlertoleranz und Datenlokalit\u00e4t<\/h2>\n
    \nDa jedes Region nur f\u00fcr einen Satz von Schl\u00fcsseln verantwortlich ist, besteht die L\u00f6sung f\u00fcr Probleme im Zusammenhang mit dem Ausfall von RS oder Stilllegungen darin, alle erforderlichen Daten in HDFS zu speichern. Wenn ein RS ausf\u00e4llt, erkennt der Master dies durch das Fehlen eines Heartbeats am ZooKeeper-Knoten. Er weist den betroffenen Region einem anderen RS zu, und da die HFiles in einem verteilten Dateisystem gespeichert sind, kann der neue Besitzer sie auslesen und die Daten weiterhin bereitstellen. Allerdings kann es sein, dass ein Teil der Daten im MemStore verbleibt und noch nicht in HFiles \u00fcberf\u00fchrt wurde. Zur Wiederherstellung der Operationshistorie wird das WAL verwendet, das ebenfalls in HDFS gespeichert ist. Nach dem Aufspielen der \u00c4nderungen kann der RS wieder auf Anfragen reagieren, jedoch f\u00fchrt der Umzug dazu, dass einige Daten und die Prozesse, die deren Verwaltung \u00fcbernehmen, sich auf verschiedenen Knoten befinden, was die Lokalit\u00e4t verringert. <\/p>\n
    Die L\u00f6sung des Problems ist die major compaction \u2013 ein Verfahren, das die Dateien auf die Knoten verschiebt, die f\u00fcr sie verantwortlich sind (dort, wo sich ihre Regionen befinden). Dadurch steigt w\u00e4hrend dieses Prozesses die Belastung des Netzwerks und der Festplatten signifikant. Allerdings wird der Zugriff auf die Daten danach 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 basierend auf den Tabelleneinstellungen. So kann beispielsweise die Anzahl der Versionen des Objekts festgelegt werden, die aufbewahrt werden sollen, oder die Lebensdauer, nach deren Ablauf das Objekt physisch gel\u00f6scht wird.<\/p>\n
    Dieses Verfahren kann sich sehr positiv auf die Leistung von HBase auswirken. Das Bild unten zeigt, wie die Leistung durch aktives Schreiben von Daten degradiert wurde. Hier sieht man, wie 40 Threads in eine Tabelle schreiben und 40 Threads gleichzeitig Daten lesen. Die schreibenden Threads erzeugen immer mehr HFiles, die von anderen Threads gelesen werden. Infolgedessen m\u00fcssen immer mehr Daten aus dem Speicher entfernt werden, und schlie\u00dflich beginnt der Garbage Collector zu arbeiten, was die gesamte Arbeit praktisch l\u00e4hmt. Der Start einer Major Compaction f\u00fchrte zur Bereinigung der entstandenen R\u00fcckst\u00e4nde und zur Wiederherstellung der Leistung.<\/p>\n
    \"Theorie
    \nDer Test wurde auf 3 DataNodes und 4 RegionServern (CPU Xeon E5-2680 v4 @ 2,40 GHz * 64 Threads) durchgef\u00fchrt. HBase Version 1.2.0-cdh5.14.2<\/p>\n
    Es ist anzumerken, dass die Durchf\u00fchrung einer major compaction auf einer \"lebenden\" Tabelle stattfand, in die aktiv Daten geschrieben und gelesen wurden. In der Community wurde behauptet, dass dies zu inkorrekten Antworten beim Lesen von Daten f\u00fchren k\u00f6nnte. Zur \u00dcberpr\u00fcfung wurde ein Prozess gestartet, der neue Daten generierte und in die Tabelle schrieb. Anschlie\u00dfend wurden diese sofort gelesen und mit den gespeicherten Werten abgeglichen. W\u00e4hrend dieses Prozesses wurde die major compaction etwa 200 Mal durchgef\u00fchrt, und es wurden keine Fehler festgestellt. M\u00f6glicherweise tritt das Problem selten und nur bei hoher Auslastung auf, weshalb es sicherer ist, die Schreib- und Leseprozesse programmatisch zu stoppen und die Bereinigung durchzuf\u00fchren, um solche GC-Einbr\u00fcche zu vermeiden.<\/p>\n
    Au\u00dferdem hat die major compaction keinen Einfluss auf den Zustand des MemStore; um ihn auf die Festplatte zu leeren und zu kompaktiifizieren, 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, wenn es nichts tun muss, w\u00e4hrend es BulkLoad ausf\u00fchrt. Dies gilt jedoch f\u00fcr die meisten Systeme und Menschen. Dieses Tool eignet sich besser f\u00fcr die Massenablage von Daten in gro\u00dfen Bl\u00f6cken. Wenn der Prozess jedoch viele konkurrierende Lese- und Schreibanfragen erfordert, werden die oben beschriebenen Befehle Get und Put verwendet. Um die optimalen Parameter zu bestimmen, wurden mehrere L\u00e4ufe mit unterschiedlichen Kombinationen von Tabelleneinstellungen und Konfigurationen durchgef\u00fchrt.<\/p>\n