4.4 HBase. Масштабируемая колоночная база данных

Question 1

Типы нереляционных БД

Answer 1

1) Key-Value хранилища, они хранят базы данных в виде ключа и значения. В каждой её ячейке хранятся данные произвольного типа, а каждому значению присвоен уникальный ключ, по которому это значение можно найти.

2) Колоночные БД, куда относится и Apache HBase. Данные группируются для хранения не по строкам, а по столбцам. Если строго придерживаться позиционирования, то HBase это БД ориентированная на семейство колонок.

3) Документоориентированные БД, в них данные хранятся в виде иерархических структур (документов) с произвольным набором полей и их значений. Документы объединяются в коллекции. Яркий представитель — MongoDB.

4) Гра́фовые база данных — разновидность баз данных с реализацией сетевой модели в виде графа и его обобщений. Это Neo4j или InfiniteGraph.

Question 2

Плюсы и минусы Key-Value БД

Answer 2

Наиболее быстрыми и удобными для доступа к записи в БД по ключу являются хранилища типа Key-Value (ключ-значение). Для таких БД характерна сложность алгоритма доступа к элементу равная О(1), т.е. условно-константная.

Но для таких БД неудобно создавать batch-обработки, т.к. они созданы для максимально быстрого доступа к единичным записям. Для таких обработок больше подходят хранилища на HDFS, например, Apache Hive.

Question 3

Преимущества Apache HBase

Answer 3

• эффективный способ доступа по ключу (быстрый доступ к единичным записям);
• поддерживает Scan (доступ к диапазонам ключей, batch-обработки).

Question 4

RowKey

Answer 4

Каждая запись в таблице проиндексирована при помощи первичного ключа, который называется RowKey.

Question 5

ColumnFamily

Answer 5

Колонки группируются в группы колонок (ColumnFamily). Это контейнер для полей, который мы можем определять в момент вставки. На момент создания таблицы колонки не определяются, а определяются только ColumnFamily. Они объединены или бизнес-логикой, или близостью данных, которые мы хотим хранить вместе. Например, персональная информация и адреса.

Колонки не определяются схемой и могут быть добавлены «на лету». Внутри ColumnFamily мы можем создавать колонки и указывать их (колонки) только в момент вставки в БД. Это дает гибкость в хранении и использовании данных, избегая дополнительных накладных расходов.
Таблицы являются разреженными. Пустые значения не требуют дополнительного места для хранения.

Question 6

Типы данных в HBase

Answer 6

В HBase нет такого понятия — “тип данных”, все по умолчанию определяется как массив byte. Мы сами должны знать какие данные и в каком виде мы записываем в таблицу.

Question 7

Версии атрибутов в HBase

Answer 7

Для каждого атрибута может храниться несколько версий. Каждая версия имеет свой Timestamp. На уровне ColumnFamily мы можем настраивать дополнительную атрибутику по управлению количеством версий полей.

Записанное в Hbase значение не может быть изменено. Вместо этого необходимо добавить новую версию с более свежим timestamp’ом.

Question 8

TTL

Answer 8

Есть возможность выставлять TTL (диапазон времени), который позволяет нам автоматически удалять устаревшие записи. Стоит использовать с осторожностью.

Question 9

Удаление записи

Answer 9

Для удаления записи помечаются специальным маркером о совершении данной операции. Удаление данных из таблицы в HBase не происходит физически, а производится на другой стадии.

Question 10

Краткая модель данных

Answer 10

• Распределенное, многомерное, разреженное, сортированное отображение
• (Table, RowKey, ColumnFamily, Column, Timestamp) -> value

Question 11

Иерархия хранения данных

Answer 11

(Table, RowKey, ColumnFamily, Column, Timestamp) -> value

• Table - SortedMap<RowKey, Row> Таблица представляет из себя сортированный массив, который состоит из ключа (RowKey) и значения (Row - сама строка)
• Row - List<ColumnFamily> Строка является списком контейнеров под колонки (ColumnFamily)</ColumnFamily>
• ColumnFamily - SortedMap<Column, List<Entry>> Семейство колонок представляет из себя сортированный массив, состоящий из ключа (колонки) и значения (список значений колонки).</Entry>
• Entry - Tuple<Timestamp, Value> Значения поля является парой timestamp-а и самого значения

Такая чёткая иерархия позволяет точно производить навигацию по структуре данных без дополнительных накладных расходов на считывание всей строки и отсечения ненужных полей (как это происходит в обычных реляционных БД).

Question 12

Get

Answer 12

получить все атрибуты для заданного ключа.

Question 13

Put

Answer 13

добавить новую запись в таблицу (если записи не было) или обновить (если запись была). Timestamp этой записи может быть задан вручную, иначе он будет установлен автоматически, как текущее время.

Question 14

Scan

Answer 14

позволяет итерироваться по диапазону ключа. Можно указать запись с которой начинается чтение, запись до которой нужно прочитать, количество записей которые необходимо считать, Column Family из которой будет производиться чтение и максимальное количество версий для каждой записи.

Question 15

Delete

Answer 15

позволяет пометить запись как удаленную. HBase не удаляет данные сразу, а ставит маркер “могильный камень” — tombstone. Физическое удаление произойдет на Major Compaction.

Question 16

Утилита HBase shell

Answer 16

HBase shell – командная оболочка HBase. Доступна сразу после установки HBase на любой ноде кластера. HBase shell представляет из себя jruby-консоль (синтаксис команд подобен языку ruby) cо встроенной поддержкой всех основных операций по работе с HBase (создание БД, таблиц, добавление данных, сканы и т.д.). Разработчики как правило не используют HBase shell в работе, в отличие от администраторов..

Question 17

Архитектура HBase (компоненты)

Answer 17

1) HMaster

2) Zookeeper

3) Region Server

4) Region

5) Write Ahead Log (WAL) или HLog

6) MemStore

Question 18

HMaster

Answer 18

главный сервер, который мониторит, управляет и координирует процессы в кластере. Управляет распределением регионов по Region Server’ам, ведет реестр регионов, управляет запусками регулярных задач. В ранних версиях был один, далее их стало несколько.

Функции:
* Главный процесс в HBase, ведет реестр всех активных регионов.

• Обслуживает DDL операции (create and delete tables), распределяет регионы по всем серверам.
• Управляет и координирует работу Region Server (как NameNode управляет DataNode в HDFS).
• Назначает Region в Region Server при восстановлении и load balancing (перебалансировка Region-ов между оставшимися RegionServer).
• Мониторит Region Server (используя Zookeeper) и производит восстановление Region Server в случае падения.

Question 19

Zookeeper

Answer 19

инструмент для поддержки информации о конфигурации, системных настройках и обеспечения синхронизации. Хранит информацию о расположении метатаблицы в HBase, в которой описана вся топология кластера, а также настройки подключения к HMaster-у. Является точкой входа для клиента (приложения). Может быть несколько нод Zookeeper-a.

Т.е. клиент сперва обращается к Zookeeper-у, чтобы узнать топологию и как подключаться к кластеру HBase.

Zookeper:
1) Специальный сервис, используемый для координации сервисов. Представляет из себя очень «живучую» key-value базу данных, поддерживающая механизмы Pub/Sub (публикация и подписка на изменения по ключу).

2) Каждый Region Server и HMaster Server периодически отправляют heartbeat в Zookeeper и он проверяется статус. В случае потери инициирует сообщения о необходимости восстановления.

3) Активный HMaster отравляет сообщения в Zookeeper, inactive HMaster следит за активным. В случае падения сам становится активным.

4) Если Region Server не отправляет уведомления HMaster запускает процесс восстановления.

5) Zookeeper обслуживает путь до .META таблицы.

Question 20

Region Server

Answer 20

Все операции клиент производит не через HMaster, а напрямую с серверами, которые называются Region Server. Region Server представляет из себя либо сервер, либо виртуальную машину, которая управляет данными, которые хранятся в HBase. Обслуживает, хранит и управляет одним или несколькими регионами.

Question 21

Region

Answer 21

отсортированная часть строк таблицы (диапазон записей в таблице соответствующих определенному диапазону подряд идущих RowKey). Каждый регион содержит:

1) Write Ahead Log (WAL) или HLog

2) MemStore

Question 22

Write Ahead Log (WAL) или HLog

Answer 22

последовательный append-only лог произведённых операций. Так как данные при записи попадают в Memstore, существует некоторый риск потери данных из-за сбоя. Для того чтобы этого не произошло все операции перед осуществлением манипуляций попадают в специальный лог-файл. Это позволяет восстановить данные после любого сбоя.

Question 23

MemStore

Answer 23

буфер на запись, хранилище данных, которые поступают в таблицу. Данные в MemStore накапливаются и хранятся некоторое время. При наполнении MemStore до некоторого критического значения данные записываются в новый файл HFile, а MemStore очищается.
HBase не работает с конкретными датанодами на HDFS, но HBase работает с клиентом HDFS, и не управляет тем, где физически хранятся данные.

MemStore:
* кэш на запись. В MemStore хранятся которые еще не были записаны на диск (HFile),

• записи сортируются перед записью на диск,
• 1 MemStore приходится на пару (Column Family, Region),
• представляет из себя отсортированный словарь, в котором в качестве ключа – значение ключа из таблицы, в качестве значения – конкретное значение поля, версия и timestamp.

Question 24

HFile

Answer 24

При наполнении MemStore до некоторого критического значения данные записываются в новый файл HFile:

• свой формат хранения,
• отсортированный по RowKey набор значений в определенной ColumnFamily (Memstore дамп),
• «твёрдая» копия данных, хранящихся в MemStore.

Question 25

Server flush

Answer 25

Memstore имеет ограниченное системным параметром значение (объем памяти). И есть threshold — отсечка (задаётся системным параметром), после которой нужно производить сброс того, что хранится на Memstore на HDFS. Если один из MemStore текущего региона переполняется, производится операция записи всех MemStore региона на HDFS в виде HFile. Эта операция называется flush . Данные из Memstore записываются в HFile и попадает на HDFS. В каждом HFile, вместе с данными, сохраняется идентификатор операции которой эти данные были записаны. Этот идентификатор присваивается в момент попадания операции в WAL. Это позволяет определить какие данные попали в HDFS.

Question 26

Процесс записи данных в HBase

Answer 26

Клиент при подключении к HBase считывает служебную информацию из таблицы .META, — там хранится информация о том, какие RegionServer есть и за какие таблицы и регионы эти сервера отвечают. Поэтому, при необходимости формирования новой записи, клиенту не составляет труда определить куда нужно обратиться для обработки этой записи. Определившись с регионом, выполняется операция Put — при этом операция записи логгируется в WAL регион-сервера, а данные попадают в MemStores, которые отвечают за семейства колонок текущего региона. Как только данные появились в MemStore, происходит отправка пакета подтверждающего что данные успешно записаны в таблицу и эта запись доступна для чтения для всех клиентов системы.

Question 27

Описание проблемы и идеи Compaction (какие виды есть)

Answer 27

Так как при переполнении одного из MemStore региона, происходит синхронный сброс всех Memstore этого региона на HDFS в виде HFiles, то не заполненные MemStore формируют, как бы, не укомплектованные файлы малого размера, тогда как полный MemStore формирует полноценный файл. Накопление неполных HFiles порождает "проблему Мелких файлов на HDFS". При интенсивной работе HBase у нас будет появляться все больше и больше мелких файлов. Это влияет на скорость получения информации из HFile — скорость падает. Для решения этой проблемы родилась идея Compaction. Compaction — это объединение небольших HFile в HFile большого размера. Они разделяются на два вида

Question 28

Minor compaction

Answer 28

Minor compaction — запускается автоматически, работает в фоновом режиме и объединяет мелкие HFile. Имеет низкий приоритет по сравнению с другими операциями. HFile являются отсортированными по ключу, каждому Memstore соответствуют собственные HFile. Для того, чтобы слить два HFile, которые соответствуют одному и тому же Memstore используется алгоритм сортировки слиянием.

Question 29

Major compaction

Answer 29

По сравнению с Minor compaction не просто объединяет мелкие файлы большие, но и производит удаление записей, которые были помечены на удаление меткой tombstone. Имеет высокий приоритет и может существенно замедлить работу кластера. Эту операцию рекомендуется выполнять при невысокой нагрузке на кластер. Например, по ночам или на выходных.

Question 30

Итоги по Compaction

Answer 30

Compaction — механизм слияния данных в HBase, при котором HFile сливаются в один файл большего размера. Minor Compaction: * Происходят постоянно автоматически в фоне * Почти не снижают производительность * Не удаляют записи, только сливают несколько маленьких HFile в один большего размера Major Compaction: * Запускаются вручную или по расписанию * Значительное снижение производительности * Записи с tombstone удаляются физически Обе операции, кроме вышеперечисленного, еще и способствуют объединению данных. Грубо говоря, если данные физически хранятся на разных машинах (HFiles за разный промежуток времени сохранены на разных серверах), то при объединении данных, они будут скомпонованы локально в одном месте, что, при чтении данных способствует сокращению межсетевых операций.

Question 31

Region split

Answer 31

Region split — это стратегия разделения таблиц на регионы, для повышения производительности работы вашей базы данных. У нас есть таблица, которая состоит из одного региона. Мы начинаем добавлять в нее данные. Один первоначальный регион обслуживает Region server. С накоплением данных, превышающих системный параметр hbase.hregion.max.filesize, происходит Region split. Наш Region server понимает, что он обслуживает регион размера большего,чем должен. Поэтому он берет у этого региона начальные и конечные значения ключей, находит условную середину и разделят его на два региона. В этом случае Region server обслуживает два региона одной и той же таблицы. При ребалансировке второй регион может быть переназначен HMaster'ом на другой Region server. Надо помнить, что обслуживание региона на новом Region server не будет максимально эффективным пока не произойдет Compaction.

Question 32

Recovery (этапы, как происходит)

Answer 32

Recovery — восстановление после сбоев. Оно происходит в два этапа: 1) Если наступает момент, когда какой-то из RegionServer перестает отправлять на Zookeeper пакет со своим состоянием, Zookeeper дает сигнал Мастерноде (HBase), что данный сервер вышел из строя. Тогда HMaster принимает решение делегировать управление операциями над данными за которые отвечал отключившийся сервер, другому ReginServer. Все данные, которые сохранены в HDFS доступны всем нодам, поэтому нет необходимости выполнять дополнительные операции по перегону данных и прочего. Вместе с данными новому серверу доступен и журнал событий WAL старого RegionServer (он тоже хранится на HDFS). 2) Вторым этапом производится восстановление данных, которые хранились в MemStores и не успели попасть в HFiles и сохранится в HDFS физически. Для этого новый RegionServer анализирует WAL и воспроизводит операции (Put, Delete...), в свои MemStores с последующей записью в HFiles. После выполнения всех операций Memstore восстанавливается до состояния, которое предшествовало падению Region server. После наполнения Memstore всеми операциями (которые были в WAL), происходит принудительный спрос содержания Memstore в виде HFIle на HDFS.

Question 33

Особенности HBase

Answer 33

1) Нет типов данных (только массив байт) 2) Колоночная структура (ColumnFamily хранятся и обрабатываются независимо) 3) При разрастании Region производится его разделение (split) 4) Гибкие параметры хранения для ColumnFamily (количество версий, сжатие, TTL) 5) Служебная таблица .META с данными о топологии кластера. Расположение таблицы хранится в Zookeeper 6) Данные надежно хранятся на HDFS, что позволяет проводить переназначение регионов и восстановление после сбоев

Question 34

Проблема выбора RowKey

Answer 34

RowKey: * Первичный ключ и ключ сортировки * Алгоритм формирования обычно выбирается один раз при заведении таблицы * RowKey должен быть равномерным * При неправильном выборе RowKey может возникнуть ”Hot Region” – регион, нагрузка на который на порядок выше чем на другие регионы * Очень сложно поменять RowKey в таблице с сотнями терабайт данных (по факту требуется перезаливка всех данных)