HBase простыми словами

Место HBase в экосистеме больших данных

Когда дело доходит до хранения больших данных, большинство людей в первую очередь думают о Hadoop и модуле HDFS в Hadoop. Хорошо известные Spark и MapReduce от Hadoop можно рассматривать как вычислительную среду. А HDFS можно рассматривать как уровень хранения, обслуживающий вычислительную среду. Поэтому, будь то Spark или MapReduce, HDFS необходимо использовать в качестве уровня постоянного хранилища по умолчанию. Так что же такое HBase, где его можно использовать и какие проблемы он может решить? Просто мы можем думать, что HBase — это уровень хранения, аналогичный базе данных, а это означает, что HBase подходит для структурированного хранения. и HBase — это столбцовая распределенная база данных, созданная на основе статьи BigTable, опубликованной Google в том же году. Однако здесь также следует отметить, что нижний уровень HBase по-прежнему использует HDFS в качестве физического хранилища, аналогичного Hive.

Некоторым читателям может быть интересно узнать разницу между HBase и Hive, давайте вкратце разберем сценарии применения Hive и HBase:

Hive подходит для анализа и запроса данных за определенный период времени, например, для расчета тенденций или журнала веб-сайта. Hive не следует использовать для запросов в реальном времени (Hive не предназначен для поддержки запросов в реальном времени). Поскольку для возврата результатов требуется много времени, HBase очень подходит для запросов больших данных в реальном времени, например, Facebook использует HBase для сообщений и анализа в реальном времени. Для развёртывания Hive и HBase тоже есть некоторые отличия, как правило, Hive может работать, пока есть Hadoop. И HBase также нуждается в помощи Zookeeper (Zookeeper, служба, используемая для распределенной координации, эти службы включают в себя службы конфигурации, обслуживание метаинформации и службы пространства имен). Опять же, HBase Он предоставляет только интерфейс Java API и не поддерживает напрямую запросы операторов SQL, в то время как Hive может напрямую использовать HQL (язык, подобный SQL). Если вы хотите использовать SQL на HBase, вам нужно использовать Apache Phonenix вместе или Hive и HBase вместе. Однако, как упоминалось выше, если интеграция использует Hive для запроса данных HBase, MapReduce не может быть обойдена, и все равно существует определенная потеря производительности в реальном времени. Комбинация Phoenix и HBase не проходит через фреймворк MapReduce, поэтому при использовании Phoneix Благодаря составу HBase производительность в реальном времени будет лучше, чем комбинация Hive и HBase, и мы покажем, как использовать их в будущем. Наконец, давайте упомянем уровень хранения, используемый Hive и HBase.По умолчанию уровнем хранения Hive и HBase является HDFS. Но в некоторых особых случаях HBase также может напрямую использовать родную файловую систему. Например, служба AMS в Ambari запускает HBase непосредственно в локальной файловой системе.

Различия между HBase и традиционными реляционными базами данных

Сначала давайте разберемся, что такое ACID. ACID относится к аббревиатуре четырех основных элементов для правильного выполнения транзакций базы данных, включая атомарность, согласованность, изоляцию и долговечность. Для системы базы данных, которая поддерживает транзакции, она должна иметь эти четырехарактеристикаВ противном случае корректность данных не может быть гарантирована в процессе транзакции (Обработка транзакции), и процесс транзакции может не соответствовать требованиям стороны транзакции. Ниже мы кратко расскажем об этом Значение 4 характеристики.

Атомарность означает, что транзакция либо выполняется полностью, либо не выполняется вообще. Другими словами, транзакция не может остановиться на полпути. Например, вещь может быть выполнена в два шага, тогда два шага должны быть выполнены одновременно, иначе один шаг не будет выполнен, и он никогда не останется в промежуточном состоянии. Если при выполнении вещи возникает ошибка, система откатывает состояние вещи до исходного состояния.

Непротиворечивость означает, что операция транзакции не изменяет согласованность данных в базе данных. То есть независимо от того, сколько одновременных транзакций существует, данные должны быть гарантированно переведены из одного согласованного состояния в другое согласованное состояние. Например, есть две учетные записи a и b, каждая из которых равна 10. Когда a увеличится на 5, b также изменится, а общее значение 20 не изменится.

Изоляция относится к состоянию, в котором две или более транзакций не выполняются с чередованием. Потому что это может привести к несогласованности данных. Если есть несколько транзакций, работающих одновременно и выполняющих одну и ту же функцию, изоляция транзакции гарантирует, что каждая транзакция в системе будет думать, что только эта транзакция использует систему. Это свойство иногда называютсериалЧтобы избежать путаницы между транзакционными операциями, запросы должны быть сериализованы или сериализованы так, чтобы в каждый момент времени был только один запрос на одни и те же данные.

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

Прежде чем подробно представить HBase, давайте кратко сравним разницу между HBase и традиционной реляционной базой данных (RDBMS, полное название — Relational Database Management System). Как показано в таблице 1.

Таблица 1. Различия между HBase и RDBMS

	HBase	RDBMS
аппаратная архитектура	Распределенные кластеры типа Hadoop с низкими затратами на оборудование	Традиционные многоядерные системы, дорогое оборудование
Отказоустойчивость	Благодаря программной архитектуре, поскольку состоит из нескольких узлов, не нужно беспокоиться об одном или нескольких простоях.	Как правило, для реализации механизма высокой доступности требуются дополнительные аппаратные устройства.
размер базы данных	PB	ГБ, ТБ
расположение данных	Разреженная распределенная многомерная карта	организованы в строки и столбцы
тип данных	Bytes	Богатые типы данных
вещи поддерживают	ACID поддерживает только один уровень строки	Полная поддержка ACID для строк и таблиц
язык запросов	Поддерживает только Java API (если не используется с другими фреймворками, такими как Phoenix, Hive)	SQL
показатель	Поддерживается только Row-key, если он не используется с другими технологиями, такими как Phoenix, Hive.	служба поддержки
пропускная способность	млн запросов в секунду	тысяч запросов в секунду

Разобравшись с приведенной выше таблицей, давайте посмотрим, как упорядочиваются данные в HBase и RDBMS. Во-первых, расположение данных в СУБД примерно такое, как показано в таблице 2.

Таблица 2. Пример расположения данных в СУБД

ID	фамилия	название	пароль	отметка времени
1	Лист	три	111	20160719
2	слива	Четыре	222	20160720

Итак, как будет выглядеть макет данных в HBase? Как показано в Таблице 3 (это просто логическое расположение).

Таблица 3. Расположение данных в HBASE (логично)

Row-Key	Значение (CF, определитель, версия)
1	info{'Фамилия': 'Чжан', 'Имя': 'Три'} pwd{'пароль': '111'}
2	Информация { 'имя': 'Ли', 'имя': 'четыре'} PWD {'пароль': '222'}

Из приведенной выше таблицы примеров мы видим, что в HBase сначала будет концепция семейства столбцов, называемая CF. CF обычно используется для объединения связанных столбцов (Column). Физически HBase фактически хранится в CF и только связывает столбцы в соответствующем CF в соответствии с ключом строки. Расположение физических данных может быть примерно таким, как показано в таблице 4.

Таблица 4. Расположение данных в HBase

Row-Key	CF:Column-Key	отметка времени	Cell Value
1	info:fn	123456789	три
1	info:ln	123456789	Лист
2	info:fn	123456789	Четыре
2	info:ln	123456789	слива

Мы уже упоминали, что HBase хранит данные в соответствии с CF. В Таблице 3 мы видим два CF, info и pwd. info хранит данные для столбцов, связанных с именами, а pwd — для данных, связанных с паролями. Вышеприведенная таблица представляет собой расположение данных информации, CF, хранящейся в Hbase. Структура данных Pwd аналогична. Fn и ln в приведенной выше таблице называются Column-key или Qulifimer. В Hbase Row-key плюс CF плюс Qulifier плюс временная метка могут найти данные ячейки (каждая ячейка в Hbase имеет 3 данные версии с отметкой времени). Новичкам поначалу легко спутать эти понятия. Фактически и CF, и Qulifier определяются заказчиком. То есть при создании таблицы в HBase вам необходимо указать CF, Row-key и Qulifier таблицы. Мы постараемся конкретизировать эти связанные понятия в последующих введениях для лучшего понимания. Здесь мы сначала понимаем взаимосвязь между логическим расположением данных и физическим расположением данных в HBase на следующем рисунке.

Рисунок 1. Связь между логическим расположением данных и физическим расположением в Hbase

Нажмите, чтобы увеличить изображение

Из приведенного выше рисунка видно, что данные от Row1 до Row5 распределены по двум CF, и каждый CF соответствует HFile. И логически, данные одной ячейки в каждой строке соответствуют строке в HFile, а затем, когда пользователь запрашивает данные в соответствии с Row-key, HBase будет проходить два HFiles и использовать один и тот же идентификатор Row-Key для идентификации соответствующих ячеек. grid организован в строки и возвращается, так что есть логические данные строки. После объяснения этого у нас есть общее представление о формате макета данных в HBase и некоторых отличиях от RDBMS.

Для СУБД SQL обычно используется в качестве основного метода доступа. А HBase — это база данных NoSQL. «NoSQL» — это общий термин для базы данных и

является СУБД. Сегодня на рынке представлено множество типов баз данных NoSQL, например, BerkeleyDB является примером локальной базы данных NoSQL, а HBase — большой распределенной базой данных NoSQL. Технически HBase больше похож на «хранилище данных», чем на «базу данных» (и HBase, и HDFS являются уровнями хранения больших данных). Поэтому в HBase отсутствуют многие функции СУБД, такие как типы столбцов, вторичные индексы, триггеры и расширенные языки запросов. Однако HBase также имеет множество других функций, поддерживающих как линеаризацию, так и модульное масштабирование. Самый очевидный способ, мы можем масштабироваться, увеличив количество региональных серверов. HBase. А HBase можно разместить на обычных серверах, например, при расширении кластера с 5 до 10 Region Servers одновременно можно удвоить и объем хранения, и вычислительную мощность. Конечно, СУБД тоже можно хорошо расширить, но только для одной точки, особенно для одного сервера БД, для лучшей производительности часто требуется специальное оборудование и устройства хранения (часто очень дорогие).

Модули, связанные с HBase, и функции таблиц HBase

Здесь давайте разберемся, какие модули есть у HBase, и общий рабочий процесс. Ранее мы упоминали, что HBase также построен на HDFS, что правильно, но не совсем правильно. На самом деле, HBase также поддерживает запуск непосредственно в локальной файловой системе, но такой HBase может работать только на одной машине, поэтому для распределенной среды больших данных это бессмысленно (это также так называемый автономный режим HBase). Как правило, он используется только для тестирования или проверки функции определенного HBase.Позже мы подробно рассмотрим несколько режимов работы HBase. Здесь нам просто нужно помнить, что в распределенной производственной среде HBase должен работать на HDFS. Кроме того, HDFS используется в качестве базового хранилища. Верхний уровень HBase предоставляет уровень API Java для доступа к данным, который используется приложениями для доступа к данным, хранящимся в HBase. Кластер HBase в основном состоит из главного и регионального серверов, а также Zookeeper. Конкретные модули показаны на следующем рисунке.

Рисунок 2. Связанные модули HBase

Нажмите, чтобы увеличить изображение

Далее мы кратко представим функции связанных модулей в HBase.

Master
HBase Master используется для координации нескольких региональных серверов, определения состояния каждого регионального сервера и балансировки нагрузки между региональными серверами. Еще одна обязанность HBase Master — назначать регионы региональным серверам. HBase позволяет сосуществовать нескольким основным узлам, но для этого требуется помощь Zookeeper. Однако при сосуществовании нескольких Мастер-узлов только один Мастер предоставляет услуги, а остальные Мастер-узлы находятся в режиме ожидания. Когда Мастер за работой Когда узел выйдет из строя, другие Мастера возьмут на себя управление кластером HBase.
Region Server
Для целей региона сервера, который включает в себя числовую область. Регион Сервера только сервис по управлению ролью и операции по чтению и записи. Клиент непосредственно регионный сервер и приобретает данные связи HBase. Для региона именно True HBase хранить данные, где он говорит, что регион - это базовая доступность блока и распределение HBase. Если и когда большой стол, при составной основе множеством CF, то данные будут храниться в таблице среди множества региона, а также будут связаны с множеством блоков хранения (магазин) в каждом регионе.
Zookeeper
Для HBase роль Zookeeper имеет решающее значение. Во-первых, Zookeeper — это решение высокой доступности для HBase Master. То есть Zookeeper гарантирует, что хотя бы один мастер HBase запущен. А Zookeeper отвечает за регистрацию регионов и серверов регионов. Фактически разработка Zookeeper на сегодняшний день стала стандартной основой для обеспечения отказоустойчивости в распределенных средах больших данных. Не только HBase, но и почти все фреймворки с открытым исходным кодом, связанные с распределенными большими данными, полагаются на Zookeeper. Внедрить ХА.

Схематическая диаграмма принципа работы полной распределенной HBase выглядит следующим образом:

Рисунок 3. Как работает HBase

Нажмите, чтобы увеличить изображение

На диаграмме выше нам нужно обратить внимание на несколько понятий, которые мы не упоминали ранее: Store, MemStore, StoreFile и HFile. Благодаря этим новым концепциям мы полностью разбираем весь рабочий процесс HBase.

Прежде всего, нам нужно знать, что кластер HBase координируется Zookeeper перед машиной, то есть связь между HBase Master и Region Server поддерживается Zookeeper. Когда клиенту необходимо получить доступ к кластеру HBase, ему необходимо сначала связаться с Zookeeper, а затем найти соответствующий региональный сервер. Каждый региональный сервер управляет многими регионами. Для HBase регион является базовой единицей распараллеливания HBase. Поэтому данные также хранятся в Область. Здесь нам нужно обратить особое внимание, каждый регион хранит данные только одного семейства столбцов, и это сегмент в CF (разделенный на несколько регионов в соответствии с интервалом строки). Существует верхний предел размера данных, которые может хранить регион. Когда верхний предел (порог) будет достигнут, регион будет разделен, а данные будут разделены на несколько регионов, что может улучшить распараллеливание данных. и емкость данных. Каждый регион содержит несколько объектов Store. Каждое хранилище содержит MemStore и один или несколько файлов HFiles. MemStore Это сущность данных в памяти, и она обычно упорядочена. Когда данные записываются в регион, они сначала будут записаны в MemStore. Когда данные в MemStore необходимо сбросить в базовую файловую систему (например, объем данных в MemStore достигает максимального значения, настроенного MemStore), Store создает StoreFile, а StoreFile является уровнем инкапсуляции для H-файл. Таким образом, данные в MemStore в конечном итоге будут записаны в HFile, который является дисковым вводом-выводом. Поскольку HBase полагается на HDFS внизу, HFiles хранятся в в ХДФС. Это краткое описание того, как работает весь HBase.

Мы понимаем общий принцип работы HBase, так как обеспечить надежность данных в рабочем процессе HBase? С этим вопросом давайте понять роль HLOG. Механизм HLOG в HBASe является реализацией WAL, а WAL (в целом переведен в качестве журнала для записи) - это обычная реализация последовательности в механизмах транзакций. В каждом регионе будет экземпляр HLOG на каждом регионе. Сервер региона сначала будет записывать операцию обновления (например, поставить, удалить) к WAL (то есть HLog), а затем записывать его в мемстал магазина, а также Наконец мемстал Данные будут записаны на постоянный HFile (MEMSTORE достигает настроенного порога памяти). Это обеспечивает надежность записи HBase. Если нет WAL, когда сервер региона снижается, мемстар не был записан на HFILE, или StageFile не был сохранен, и данные будут потеряны. Некоторые читатели могут беспокоиться о том, будет ли сам HFile будет потерян, что гарантируется HDFS. Данные в HDFS будут иметь 3 копии по умолчанию. Поэтому надежность самого HFILE здесь не рассматривается.

Ранее мы много раз упоминали HFile, то есть файл постоянного хранилища HBase. Некоторые читатели могут не до конца понять HFile, здесь мы подробно рассмотрим структуру HFile, как показано ниже.

Рисунок 4. Структура HFile

Нажмите, чтобы увеличить изображение

Из рисунка видно, что HFile состоит из множества блоков данных (Block) и имеет фиксированный конечный блок. Блок данных состоит из заголовка и нескольких пар ключ-значение. Блок данных в конце содержит индексную информацию, связанную с данными, и система также находит данные в HFile через индексную информацию в конце. Размер блока в HFile по умолчанию составляет 64 КБ. Если сценарий доступа к базе данных HBase в основном представляет собой упорядоченный доступ, рекомендуется установить для этого значения большее значение. Если сцена в основном представляет собой произвольный доступ, рекомендуется установить это значение на меньшее значение. Как правило, производительность HBase можно повысить, настроив это значение.

Если мы хотим резюмировать HBase в коротком предложении, мы можем думать, что HBase — это упорядоченная многомерная карта, в которой каждый ключ-строка отображает множество данных, которые хранятся в столбцах в CF. Мы можем использовать следующую диаграмму, чтобы представить это предложение.

Рисунок 5. Отношение отображения данных HBase

Нажмите, чтобы увеличить изображение

Предложения HBASE

Ранее я рассказал о многих различиях между HBase и RDBMS, а также о некоторых преимуществах. Итак, когда HBase больше всего нужен или может HBase заменить исходную СУБД? Для решения этой проблемы мы всегда должны помнить, что HBase подходит не для всех задач, и цель его разработки — не замена СУБД, а важное дополнение к СУБД, особенно для сценариев с большими данными. При рассмотрении HBase в качестве альтернативы нам необходимо провести следующее исследование.

Прежде всего, убедитесь, что данных достаточно, если есть сотни миллионов или сотни миллиардов строк данных, HBase будет хорошим кандидатом. Во-вторых, необходимо убедиться, что бизнес не может полагаться на дополнительные возможности СУБД, такие как типы данных столбцов, вторичные индексы, язык запросов SQL и т. д. Опять же, вам нужно убедиться, что у вас достаточно оборудования. Не говоря уже о HBase, при нормальных обстоятельствах, когда в кластере HDFS меньше 5 узлов данных, он ничего не может сделать (по умолчанию HDFS будет выполнять резервное копирование данных каждого блока на 3 точки), плюс NameNode.

Ниже я даю несколько советов по дизайну таблиц при использовании HBase, и читатели смогут понять их смысл. Но я не хочу, чтобы эти предложения стали догмой для использования HBase, в конце концов, есть некоторые неразумные места. Во-первых, эффективность базы данных HBase во многом зависит от дизайна Row-Key. Поэтому, как спроектировать Row-key — очень важная тема при использовании HBase. Строки-ключи разрабатываются по-разному в зависимости от того, как осуществляется доступ к данным. Однако в целом есть только одна цель — выбрать как можно больше Row-Key, который может сделать ваши данные равномерно распределенными в кластере. Это также легко понять, потому что HBase Это распределенная среда.Клиенты обращаются к различным региональным серверам для получения данных. Если данные равномерно распределены по разным узлам, то пакеты Клиентов могут получать данные с разных Региональных серверов вместо узкого места на определенном узле, и производительность, естественно, улучшится. Обычно у нас есть несколько конкретных предложений:

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

Выше мы говорили о дизайне Row-Key, затем нам нужно подумать о том, потребуется ли семейству столбцов разный дизайн в разных сценах. Ответ — да, но CF проще по сравнению с row-key, но это не значит, что дизайн CF — тривиальная тема. В системе СУБД мы знаем, что если информация о пользователе рассредоточена по разным таблицам, ей необходимо выполнять операции JOIN по ключу. В HBase нам нужно спроектировать CF для объединения всех пользователей. Просто необходимо агрегировать данные (или функцию) в одном или нескольких СР. Таким образом, этот тип информации может быть получен в соответствии с CF. Выше мы объяснили, что регион соответствует CF. Таким образом, если в таблице определено несколько CF, должно быть несколько регионов. Когда клиент запрашивает данные, необходимо запрашивать несколько регионов. Такая производительность, естественно, будет снижаться, особенно когда REGON хвастается машиной. Таким образом, в большинстве случаев таблица не будет превышать 2-3 CF, а во многих случаях все еще есть 1 CF.

Использование Феникса

Когда новому бизнесу необходимо использовать HBase, вполне возможно использовать Java API для разработки приложений HBase для реализации определенной бизнес-логики. Но если вы привыкли использовать RDBMS SQL или хотите напрямую перенести приложения, которые использовали JDBC, на HBase, это невозможно. Эта ностальгия по прошлому породила Феникса. Итак, какие функции может предоставить Phoenix? Проще говоря, Phoenix предоставляет функции, связанные с OLTP, поверх HBase, такие как полная поддержка ACID, SQL, вторичные индексы и т. д. Кроме того, Phoenix также предоставляет стандартные JDBC API. С помощью Phoenix пользователи СУБД могут легко использовать HBase и перенести свой первоначальный бизнес на HBase. Давайте кратко рассмотрим, как использовать Phoenix поверх HBase.

Во-первых, нам нужно скачать установочный пакет Phoenix, соответствующий версии HBase, с сайта Phoenix. HBase моей среды развертывается через Ambari HDP2.4, а версия HBase — 1.1, поэтому я скачал phoenix-4.7.0-HBase-1.1 на картинке ниже.

Рисунок 6. Страница загрузки Phoenix

Нажмите, чтобы увеличить изображение

После загрузки вам необходимо разархивировать tar-пакет Phoenix, скопировать все jar-файлы в $HBASE_HOME/lib на каждом компьютере с региональным сервером и перезапустить все региональные серверы. Для HBase, развернутого Ambari, его каталог HBASE_HOME — это /usr/hdp/2.4.0.0-169/hbase/lib/. После добавления пакета Jar в этот каталог вы можете перезапустить весь HBase непосредственно в веб-интерфейсе Ambari. После перезапуска мы можем войти в каталог Phoenix, который мы только что разархивировали, и войти в его подкаталог. мусорное ведро В этом каталоге Phoenix предоставляет сценарий sqlline.py. Мы можем подключиться к HBase через этот скрипт и протестировать соответствующие операторы SQL. Мы видим файл hbase-site.xml в каталоге bin, если нам нужно установить соответствующие параметры для Phoenix, нам нужно изменить файл и синхронизировать файл с HBase. Самый простой способ использовать Sqlline.py — напрямую использовать имя компьютера Zookeeper в качестве параметра, как показано ниже:

Рисунок 7. Схематическая диаграмма использования Sqlline.py

Нажмите, чтобы увеличить изображение

На приведенном выше рисунке мы также используем команду таблицы, поддерживаемую sqlline.py, которая может отображать все таблицы в HBase. Здесь следует отметить, что Phoenix не поддерживает прямое отображение таблиц, созданных в HBase Shell (HBase поставляется с инструментом доступа CLI, который будет представлен в последующих статьях). Причина проста: когда Phoenix создает таблицу, Phoenix собирает ее заново. Таблица Phoenix, созданная HBase Shell, не была обработана, поэтому ее нельзя отобразить напрямую. Если вам нужно связать таблицу, созданную в HBase Shell, с Phoenix, вам нужно просмотреть ее в Phoenix. Создайте представление в Phoenix для ассоциации. Например, теперь мы создаем таблицу «table1» в оболочке HBase и вставляем несколько строк данных следующим образом.

hbase(main):022:0> scan 'table1'
ROW              COLUMN+CELL                                              
row1           column=cf1:name, timestamp=1469498246529, value=test     
row2           column=cf1:age, timestamp=1469497088506, value=26        
row2           column=cf1:name, timestamp=1469497072735, value=sang

Затем мы выполняем команду «!table» в терминале Sqlline.py и обнаруживаем, что table1 нет. Далее выполняем следующую команду:

create view "table1" (pk VARCHAR PRIMARY KEY, "cf1"."name" VARCHAR, "cf1"."age" VARCHAR);

Затем используйте команду !table, и результат будет следующим:

Рис. 8. Результаты запроса Phoenix Execute Table

Нажмите, чтобы увеличить изображение

Мы видим, что в результате есть дополнительное представление table1, поэтому Phoenix связывает содержимое таблицы table1 с представлением Phoenix. Мы можем получить доступ к его содержимому, используя такие операторы, как select следующим образом:

Рис. 9. Результат выполнения запроса Phoenix

Нажмите, чтобы увеличить изображение

Наконец, давайте вернемся и объясним команду, которая только что создала представление. При создании связанного представления нам нужно убедиться, что имена представлений и столбцов точно совпадают с именами исходных таблиц. Phoenix по умолчанию использует верхний регистр, поэтому, когда в HBase Shell используются строчные буквы, нам нужно использовать двойные кавычки для ссылки на связанное имя. Если исходное имя написано прописными буквами, двойные кавычки можно не ставить. Pk — это имя первичного ключа, которое мы определили (вы можете определить его по желанию), потому что в HBase Shell нет концепции первичного ключа, поэтому Row-key не имеет имени. Комбинация cf1 и name используется для указания на ячейку (Cell) в HBase, в примере команды я связываю две ячейки (вы можете связать только одну, если хотите). установлен После Phoenix мы должны стараться избегать прямого использования HBase Shell для создания таблиц, а вместо этого использовать Phoenix напрямую. Например, на рисунке ниже я использовал Phoenix для создания таблицы t1 с двумя столбцами name и age и вставил две строки данных. Конкретная команда выглядит следующим образом:

Рисунок 10. Как создать таблицу в Phoenix

Нажмите, чтобы увеличить изображение

Увидев эти команды, читатели, знакомые с SQL, безусловно, не чувствуют себя незнакомыми. Это одна из наиболее важных функций Phoenix предоставляет - поддержка SQL. Мы можем видеть, что в Phoenix мы используем богатые типы данных, такие как Integer и Varchar. Они не доступны прямо в HBASE. Заинтересованные читатели могут попробовать больше операторов SQL в SQLLINE.PY. Когда вам нужно выйти из SQLLINE.PY, вы можете выполнить команду! Quit (вы можете увидеть больше команд, используя! Справка). После выхода из SQLLINE.PY, давайте начнем оболочку HBase Посмотрите, как будет выглядеть таблица, созданная Phoenix. следующее:

hbase(main):002:0> scan 'T1'

ROW                                        COLUMN+CELL

\x80\x00\x00\x01           column=0:AGE, timestamp=1469539501199, value=\x80\x00\x00\x16

\x80\x00\x00\x01           column=0:NAME, timestamp=1469539501199, value=zhang san

\x80\x00\x00\x01           column=0:_0, timestamp=1469539501199, value=x

\x80\x00\x00\x02           column=0:AGE, timestamp=1469539516700, value=\x80\x00\x00\x1E

\x80\x00\x00\x02           column=0:NAME, timestamp=1469539516700, value=li si

\x80\x00\x00\x02 column=0:_0, timestamp=1469539516700, value=x

Мы можем ясно видеть, что Phoenix реорганизовал приведенные выше данные, чтобы сформировать то, что показано на рисунке 10. До сих пор мы кратко представили простое использование Phoenix. Важно подчеркнуть, что в этой главе показана лишь малая часть того, что может предложить Phoenix. Phoenix, как сторонник стандартного API JDBC, исходное приложение, построенное на JDBC, может напрямую обращаться к HBase через Phoenix, например, с помощью графического клиента SQL, такого как Squirrel. Конечно, вы также можете получить прямой доступ к базе данных HBase через JDBC в коде Java без использования Java API HBase был переработан. Читатели, которые хотят узнать больше о возможностях Phoenix, могут просмотреть их в официальной документации Apache Phoenix, например, вторичные индексы.

Суммировать

Еще многое предстоит рассказать о HBase, например, о разработке приложений с использованием Java API, быстром развертывании (включая режимы развертывания Ambari и HBase), оболочке HBase и о том, как интегрировать Hive и HBase. В настоящее время существует множество сценариев применения HBase, особенно в фоновом хранилище информации интернет-компаний, таких как Taobao и т. д., которые используют HBase. Я считаю, что после понимания HBase вы сможете использовать решения для больших данных в лучшей архитектуре.Пространство здесь ограничено, и позже будет представлен дополнительный контент.

Справочные ресурсы

связанная тема

Посетите сайт developerWorks в КитаеЦентр ресурсов IBM Bluemix: в этом разделе представлено множество учебных ресурсов, таких как статьи, учебные пособия и демонстрации, которые помогут вам понять Bluemix от простого до глубокого.
Посетите сайт developerWorksЗона облачных вычислений, сообщество разработчиков облачных вычислений и технические ресурсы для разработчиков и профессионалов. Вы можете узнать больше об облачных вычислениях, получить техническую документацию, статьи с практическими рекомендациями, обучение, файлы для загрузки, информацию о продуктах и другие актуальные технические ресурсы, а также принять участие в обсуждениях сообщества.