Я не совсем уверен, ссылаетесь ли вы на получение информации из HBase или нет. Я предполагаю, что вы хотите создать агрегирующее приложение, которое выполняет вычисления «sum», «count», «avg» и т. Д., Как операции с данными, хранящимися в HBase, для генерации графиков/визуализации.
В этом случае конкретный ответ будет зависеть от характера данных, которые вы пытаетесь проанализировать. Одно из таких приложений будет http://opentsdb.net от StumpleUpon.
Его довольно легко написать сборщики данных на HBase, поскольку это может быть достигнуто с помощью MapReduce. http://hbase.apache.org/docs/r0.89.20100726/apidocs/org/apache/hadoop/hbase/mapred/package-summary.html
В нашей организации мы используем Solr для выполнения запросов и функций агрегации для финансовых отчетов, а затем мы храним их в CMS для рендеринга. Таким образом, мы можем настроить рендеринг для одного набора данных. Если вы заинтересованы в хранении его в CMS на HBase + Solr в следующем режиме будет интересно -
И если вы хотите получить доступ к данным только при доступе к постоянное хранение и заинтересованность в ORM, вы можете использовать следующее, а затем другое, пожалуйста, проигнорируйте его. Следующее копируется из - Java ORM for Hbase Другой ответ от меня.
Сила HBase, как я вижу, заключается в поддержании динамических столбцов в статических семействах столбцов. Из моего опыта разработки приложений с HBase я обнаружил, что не так просто, как SQL, определять определители и значения ячеек.
Например, книга, в которой написано столько авторов, в зависимости от ваших шаблонов доступа, авторских прав, реализация кэша на уровне приложения, вы можете захотеть сохранить весь автор в таблице книг (то есть автор находится в 2 таблице, автор таблицу и таблицу книг) или только идентификатор автора. Более того, сборник может быть сохранен в одну ячейку как XML/JSON или отдельные ячейки для отдельных авторов.
С таким пониманием я пришел к выводу, что полномасштабный ОРМ, такой как Hibernate, будет не только очень сложным, но и не может быть окончательным. Таким образом, я использовал другой подход, гораздо более похожий на iBatis на Hibernate.
Позвольте мне объяснить, как это работает. Для этого я буду использовать исходные коды от here и here.
- Первой и главной задачей является реализация интерфейса ObjectRowConverter, в данном случае SessionDataObjectConverter. Абстрактный класс инкапсулирует основные передовые методы, как обсуждалось и узнано из сообщества HBase. Расширение в основном дает вам 100% -ный контроль над тем, как преобразовать ваш объект в строку HBase и наоборот. Для этого только ограничение API заключается в том, что ваши объекты домена должны реализовывать интерфейс PersistentDTO, который используется внутри для создания Put, Delete, do byte [] для объекта id и наоборот.
- Следующая задача - связать зависимости, как это сделано в HBaseImplModule. Пожалуйста, дайте мне знать, если вы заинтересованы, я буду проходить инъекции зависимости.
И вот оно. Как они используются, доступны here. Он в основном использует CommonReadDao, CommonWriteDao для чтения и записи данных в HBase и обратно. Общее чтение dao реализует многопоточное преобразование строк в объект по запросам, многопоточный get by ids, get by id и имеет свои критерии Hibernate, такие как API, для запроса к HBase через Scan (нет доступных функций агрегации). Common write dao реализует общий код, связанный с записью, с некоторыми дополнительными возможностями, такими как оптимистичная/пессимистическая блокировка, контроль за исключением/слиянием ячейки (не) -существование при сохранении, обновлении, удалении и т. Д.
Этот ORM был разработан для наших внутренняя цель, и я дошел до моей шеи и, следовательно, пока не могу сделать некоторую документацию. Но если вы заинтересованы, дайте мне знать, и я будет сделать время для документации с приоритетом.