1

Тема: Построение базы знаний с использованием Hbase

Добрый день.
В качестве системы хранения данных была выбрана Hbase.
Критерии выбора:
есть опыт работы; хранится будет разреженный массив данных; храниться в итоге будет большой объем данных, причем график заполнения будет расти экспоненциально.
Данные делятся на два больших класса:
1) Источники информации (это текстовая, графическая, видео и аудио информация), которые не являются в своем исходном состоянии семантизированными. Происходит их парсинг и вся необходимая информация описывается DC + DCTERMS. В итоге получается источник информации с RDF описанием. Это первый из классов хранимой информации (сюда входят второстепенные данные, описывающие Человека, Организацию и тд, описываемые VCard и хранящиеся каждый в своей таблице).
Вопросы:
Какой способ организации хранения тут лучше использовать? Планируется ресурс-ориентированный подход к хранению данных, то есть ключ строки - ID субъекта (индивида), Семейство и квалификатор столбца задают, в качестве значения на пересечении ячеек хранятся объекты. То есть: "В строке URI статьи" "dc:creator=<personID>", но такой подход не позволит задать более одно автора, второй автор будет записан в ячейку с другой меткой времени, но это не совсем верно, потому что тогда теряется возможность отслеживать историю версий (что желательно). "В строке URI статьи" "dc:<personID>=creator" - в этом случая проблема пропадает, но насколько такой подход оправдан с точки зрения удобства работы с данными? Есть ли другие решения этого вопроса?
Куда при построении XML/RDF документа с помощью jena помещать сам текст источника информации? Может ли в самом тексте присутствовать семантическое описание (например ссылка на связный источник) и как это оформить лучше? Использовать RDFa?
2) Полученная информация. Полученную информацию выделяют эксперты из источника. Также планируется использовать ресурс-ориентированный подход. Но тут необходимо связать данные из разных столбцов. Связывать планируется меткой времени (timestamp). К примеру: Ключ строки="Вещество конкретный ID" Ключ столбца="имеет свойство" Значение="Свойство ID") Индивид свойства в свою очередь представлен в отдельной таблице свойств и имеет значение, единицы измерения и тд. Каждое вещество кроме свойства должно иметь условия измерения этого свойства, то есть само значение свойства и условия должны быть связаны. Так вот, если предположить, что связывание происходит по метке времени, то эта метка времени будет использована в качестве счетчика фреймов стека, то есть мы теряем версии значений...(желательно бы их оставить) Можно конечно пойти в отрицательную сторону, но тогда количество предыдущих версий ограничивается одной (то есть если действующее значение ID = 45, то предыдущая версия ID=-45).
Если использовать факт-ориентированный подход, то есть вместо "Вещество ID" использовать "Измерение ID" а в столбцах поместить Субъект, Предикт и Объект, то Ключ строки="Измерение конкретный ID": Ключ столбца="Вещество" Значение="Вещество ID"; Ключ столбца="имеет свойство" Значение="Свойство ID"; Ключ столбца="имеет условие измерения" Значение="Условие ID"; то люди, которые это использовали говорили что будут проблемы с дублированием данных, а если использовать для проверки хеш, то огромная нагрузка при занесении каждого значения на проверку и пересчет хеша как я понял...
Хотелось бы услышать ваше мнение по этому поводу. Какие варианты можно еще рассмотреть?

Еще вопросы:
3) Нужно ли хранить иерархию классов непосредственно в базе данных, разбив ее на составляющие? Или лучше хранить ее в формате XML/RDF? Или и так и так?

4) Хотелось бы строить онтологию не локально, а вклиниться в существующую, выбор пока пал на SWEET от nasa. Процесс вклинивания нашей онтологии предметной области в SWEET - это просто наследование от их класса Property и Quantity? Если да. то насколько правильно будет отвержение их иерархии ниже Property и внедрение своей (Для нашей предметной области классификация отличается)? Нужно ли отображать в нашей онтологии эквивалентные классы из онтологии SWEET (Допустим в глубине дочерних узлов Property скрывается свойство, которое присутствует и в нашей онтологии, но у нас иерархия от Property к этому узлу отличается от той что в SWEET, нужно ли указывать что эти классы эквивалентны?)

5) В базе данных можно создать множество таблиц, каждая из который отображает свой класс, а можно создать одну общую, где задать универсальный ID, и универсальные Семейства столбцов: Субъект, Предикт, Объект. Какой подход использовать лучше? До какого момента разбивать таблицы? (каждый корневой класс-таблица? каждый класс - таблица? или все зависит от предметной области?)

6) Возможно ли использование двойного уровня хранения - Hbase для хранения и меп-редьюс анализа. Virtuoso - для SPARQL запросов? Или что лучше прикрутить к Hbase, чтоб SPARQL были не так медлительны?

PS: Спасибо за ваш ресурс о SW, очень нужный и интересный.
С уващением Дмитрий.

Отредактировано ji (2011-12-14 14:33:24)

2

Re: Построение базы знаний с использованием Hbase

Хранить иерархию классов надо, разумеется, в виде фактов в графе. Редактировать "снаружи" --- как удобнее, обычно используют либо turtle и обычный текстовый редактор, либо нечто специализированное (= дорогое).

Для версионирования никто не запрещает создавать по графу на версию плюс предикат "граф текущей версии данного графа".
Либо документ лежит в графе с "правильным" именем, а предыдущие версии --- в графах с "патченными" именами, плюс опять-таки предикаты для связи между ними.

Из описанного, непонятен выбор Hbase. Я, разумеется, предвзят, но если уж вы решаете разобраться с Virtuoso, то все остальные задачи хранения можно решить в ней же (а если интересует скорость, то и нужно).

3

Re: Построение базы знаний с использованием Hbase

iv_an_ru пишет:

Хранить иерархию классов надо, разумеется, в виде фактов в графе.

То есть все классы, их иерархия и ограничения - все хранится не в базе, а в виде документов, к примеру XML/RDF? Таким способом хранистя вся информация, необходимая для логического построения данных, а сами данные хранятся в базе... правильно?
Приведу пример:
Объектное свойство: "иметь свойство"

Класс: "Вещество"

Класс: "Свойство"
Класс: "Физическое свойство" (подкласс Свойства).
Класс: "Термальное свойство" (подкласс Физического свойства).
Класс: "Температура плавления" (подкласс Термального свойства).
Это все описание и хранится в виде документа.

"(Вещество) Индивид 1" "имеет свойство" "(Температура плавления) Индивид 12"
Это непосредственно данные, которые хранится в базе.
Правильно понял?

iv_an_ru пишет:

Для версионирования никто не запрещает создавать по графу на версию плюс предикат "граф текущей версии данного графа".
Либо документ лежит в графе с "правильным" именем, а предыдущие версии --- в графах с "патченными" именами, плюс опять-таки предикаты для связи между ними.

Это конечно хорошо, но у Hbase есть встроенное средство контроля версий(timestamp), не вижу смысла огород городить, вижу смысл организовать хранение так чтоб не задействовать timestamp в качестве счетчика стека. Но чего-то никак не могу сообразить какая структура хранения должна быть (все-таки первый раз с семантик технологиями работаю).

iv_an_ru пишет:

Из описанного, непонятен выбор Hbase. Я, разумеется, предвзят, но если уж вы решаете разобраться с Virtuoso, то все остальные задачи хранения можно решить в ней же (а если интересует скорость, то и нужно).

Скажите, Виртуозио насколько я понял не является распределенной БД, поэтому встает вопрос: как она поведет при 100+Tb данных? Кроме SPARQL запросов хотелось бы использовать быстрый MapReduce Hbase. Ну и организация дискового хранилища под виртуозио будет совсем не дешевым, поэтому всю информацию планируется хранить именно Hbase, а что-то более быстрое (операция чтения) - для запросов SPARQL, причем информация в это более быстрое будет подгружаться по мере надобности и удаляться динамически (что-то вроде кеша наверно).

PS: это первый опыт работы с семантик технологиями, поэтому так много вопросов.

Отредактировано ji (2011-12-15 16:53:48)

4

Re: Построение базы знаний с использованием Hbase

То есть все классы, их иерархия и ограничения - все хранится не в базе, а в виде документов, к примеру XML/RDF? Таким способом хранистя вся информация, необходимая для логического построения данных, а сами данные хранятся в базе... правильно?

"хранится в графе" означает, ровно наоборот, хранение в виде фактов в базе знаний, просто все эти факты разумно разместить в одном или нескольких выделенных графах, не смешивая с графами, в которых будут только данные. У "онтологических" фактов и у фактов, выделенных из "простых" источников данных, слишком разные свойства, чтобы их смешивать. Онтологии компактны, редко меняются и запросы над ними отличаются "замысловатостью" (много тяжёлых для имполнения рекурсий и неиндексируемых поисков). В противоположность этому, данных много, они постоянно пополняются.устаревают и если их действительно много, то запрос или полностью делается доступами по индексам или принципиально не может быть выполнен за разумное время.

Виртуозио насколько я понял не является распределенной БД, поэтому встает вопрос: как она поведет при 100+Tb данных?

Терабайт терабайту рознь, в зависимости от ширины строки таблицы, характерной для данного приложения и степени сжатия, характерной для данной схемы хренения на данном сервере. Если речь, скажем, про 100терабайт данных RDF-H (TPC-H в формате RDF), то это ~15 триллионов фактов, что раз в 50 больше любого известного хранилища (считая и те, в которые данные загрузить удалось, ради рекламы, а выполнять запросы --- уже нет smile
Кроме того, Virtuoso как раз и репликацию поддерживает и работу на кластере, так что с "распределённостью" всех видов у неё всё в порядке. Вот только обычно приходится выбирать между географической распределённостью и масштабируемостью.

Ну и организация дискового хранилища под виртуозио будет совсем не дешевым

Жёсткие диски обычно составляют 5-10% от общей цены железа под базу знаний. То есть выбирать надо объём ОЗУ и матплату, которая в состоянии уместить нужное число нужных процов и планок памяти.

5

Re: Построение базы знаний с использованием Hbase

По первому - понял, спс за разъяснение.

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

Речь идет о сохраненных данных в виде текста (именно этот объем занимает 150+Tb, сама база фактов будет занимать меньше), который содержит различные факты о Веществах.
Тут кстати появляется вопрос - хранение фактов осуществляется отдельно от самого текста? К примеру у нас есть статья, которая содержит факты из словаря Дублин Кор (автор, заголовок и тд..). Как правильно организовать хранение? Отдельно факты в виде триплетов - отдельно текст? Или текст в формате RDFa?

Кроме того, Virtuoso как раз и репликацию поддерживает и работу на кластере, так что с "распределённостью" всех видов у неё всё в порядке. Вот только обычно приходится выбирать между географической распределённостью и масштабируемостью.

Тут смысл в том, что у нас есть большое количество персональных компьютеров, Hbase позволяет объединить их и использовать как кластер с распределенным хранением и обработкой информации. Поддерживает ли Virtuoso работу на платформе Hadoop? Если нет, то какова технология организации распределенного хранения и обработки информации для Virtuoso?

Отредактировано ji (2011-12-19 16:12:14)

6

Re: Построение базы знаний с использованием Hbase

Тексты отдельно -- факты отдельно. При обновление текста, из которого берутся факты, никто не запрещает автоматически стереть весь граф с данными из этого текста и внести новые, или что-то в этом роде. Если текст содержит некую стандартную разметку (RDFa, XHTML+microdata и т.п.), то для этого есть готовая поддержка, если что-то нестандартное, то можно дописать так называемые "картриджи", которые будут автоматически вызываться в подходящих случаях.

Тут смысл в том, что у нас есть большое количество персональных компьютеров, Hbase позволяет объединить их и использовать как кластер с распределенным хранением и обработкой информации. Поддерживает ли Virtuoso работу на платформе Hadoop? Если нет, то какова технология организации распределенного хранения и обработки информации для Virtuoso?

Virtuoso "сама по себе", у неё собственное хранилище и это единственный способ выполнять запросы быстро. И я проконсультировался сейчас, и Orri Erling сказал, что 150Tb текстов это точно не проблема и что прямо сейчас он собирается тестировать BSBM scale 10G, и пока что самые большие проблемы не с базой как таковой, а с генератором данных бенчмарки, так что тераквады уже кажутся целью, достижимой для относительно небольших кластеров.

В то же время попытки делать мало-мальски сложные запросы на слабой сети из слабых ящиков обречены на провал. Заведомо. Наверное, в каждой моей заметке на этом сайте я вынужденно возвращаюсь к этому вопросу. Сэкономить на оборудовании хочется всем, и мне тоже. Но скорость света это вредная константа, которая не хочет подчиниться чему-то наподобие закона Мура, и мы обречены на покупку дорогих толстых ящиков при обилии простаивающих дешёвых мелких ящичков. Максимум, чего можно добиться --- втиснуть некоторые задачи в комодные серверы, избежав закупки мейнфреймов.

Кстати, тот же Orri Erling сказал, что если задача научная, а не коммерческая, и тем более если данные пойдут в открытый доступ, то мы бесплатно поможем с настройкой и т.п.

7

Re: Построение базы знаний с использованием Hbase

ji пишет:

Речь идет о сохраненных данных в виде текста (именно этот объем занимает 150+Tb, сама база фактов будет занимать меньше), который содержит различные факты о Веществах.

Объем данных в виде неструктурированного текста мало что говорит о будущем размере базы в виде квадов. Например, есть датасеты, в которых литералы занимают больше 64K (UniProt или Ordnance Survey). Вам надо попробовать оценить такие параметры, как:
- соотношение числа RDF-вершин к числу квадов
- соотношение URI/literals
- распределение литералов по типам (строковые, даты, числа и тд)
- распределение длин строковых литералов.
Думаю, подобный статистический анализ должно быть реально провести.
Сложнее всего большинству современным СУБД приходится именно с датасетами, где много уникальных RDF-вершин (особенно литералов).

8

Re: Построение базы знаний с использованием Hbase

PavelK пишет:

Сложнее всего большинству современным СУБД приходится именно с датасетами, где много уникальных RDF-вершин (особенно литералов).

Не всё так страшно. Между неповторяемыми данными и случайными данными все равно остаётся огромная статистическая разница, которая даёт оптимизатору возможность "выжить".
Кроме того, уникальность растёт по-разному для разных колонок. Скажем, в базе про пациентов, госпитализации и медицинские процедуры никто не будет загонять в базу факты вроде
<пациент#123> <получил_диагноз_при_госпитализации#456> <болячка#789>
вместо этого будет что-то вроде
<госпитализация#456> <пациент> <пациент#123> ; <диагноз> <болячка#789>
и словарь предикатов будет оставаться немногочисленным.

При малой повторяемости литералов возможны два сценария:

Сценарий 1. "Тяжело в учении --- легко в бою". Загрузка идёт со стабильной скоростью, но раза в 2--3 медленнее обычного, потому что интенсивно пополняются таблицы-словари и к тому же уменьшается степень сжатия таблицы квадов. Тем не менее, если данные всё же при этом остаются приемлемых размеров и активное подмножество не вылезает из доступного ОЗУ, селективность условий в запросах оказывается в средем выше, что сокращает переборы и приводит к уменьшению времени исполнения запроса. (селективный подзапрос) join (селективный подзапрос) оказывается в среднем намного быстрее нормы,
(неселективный подзапрос) join (единичный поиск) оказывается чуть медленнее нормы,
(неселективный подзапрос) join (неселективный подзапрос) оказывается сильно медленнее "нормы", но на большом объёме данных он все равно был настолько неисполним, что разница между "очень-очень плох" и "очень-очень-очень плох" никого не интересует.
Проблема может оказаться в том, что для нормального функционирования железа потребуется "больше среднего", а выросшая при этом средняя производительность окажется избыточной. В случае lod.openlinksw.com с его значительной уникальностью, мы эту проблему не заметили, потому что число обращений все равно растёт по экспоненте и любая мощность будет съедена если не сегодня, то завтра. То ли дело "почти персональные" установки. Если пользователей строго m (m-малое), а оборудования надо купить на $N (N-большое), то денег жалко.

Сценарий 2. "Тяжело в лечении --- легко в гробу". Если таблица квадов и раньше сжималась не очень, то теперь она начинает испытывать и структурные проблемы, в результате скорость загрузки в процессе загрузки не выходит на некое длинное плато, а падает, падает и падает. Дальше --- хуже. Попытки собрать достоверную статистику по частотам вхождения предикатов проваливаются, оценки кардинальностей join-ов выдают очень неправдоподобные значения, оптимизатор оптимизирует запросы, основываясь на неверных предположениях... и вот готов очередной пресс-релиз, в котором сообщается об успешной загрузке рекордно большого датасета, но ничего не сообщается о том, какие запросы успешно выполняются над данным датасетом.

9

Re: Построение базы знаний с использованием Hbase

Я не говорю, что "страшно". Я говорю, что для большинства СУБД это наименее приятная ситуация (про Virtuoso я вообще ничего не утверждаю, поскольку не знаком), именно из-за более интенсивного IO (хуже сжатие, больше словари, хуже работают кэши).
C мыслью "тяжело в учении легко в бою" я вполне согласен, проблема только в том, что посчитать за приемлимое время статистику селективности для БД с огромным число уникальных вершин значительно сложнее. При этом проблема в основном не в селективности предикатов (их-то относительно немного), а в оценке кардинальности join'ов c bound objects, а-ля:
?s :p1 :o1
?s :p2 "some literal"
?s :p3 ?o
В данном случае, например, это star join и в нормальных условиях мой код в Stardog'e оценивает кардинальность таких штук в ошибкой менее чем в 2 раза в подавляющем большинстве случаев (причем за миллисекунды). Но где-то в районе пары сотен миллионов уникальных o-вершин, сбор статистики начинает тормозить.
Ну и есть еще куча аналогичных проблем, вроде обламывающегося предположения о независимости предикатов и т.д.
В результате повышается вероятность сценария 2.

10

Re: Построение базы знаний с использованием Hbase

PavelK пишет:

посчитать за приемлимое время статистику селективности для БД с огромным число уникальных вершин значительно сложнее. При этом проблема в основном не в селективности предикатов (их-то относительно немного), а в оценке кардинальности join'ов c bound objects, а-ля:
?s :p1 :o1
?s :p2 "some literal"
?s :p3 ?o

Мы собираем нужные статистики прямо во время работы оптимизатора, on demand, в результате большое число уникальных значений в индексе перестаёт мешать. Код сервера, правда, становится очень сложным, но результат того стоит.

11

Re: Построение базы знаний с использованием Hbase

Позволь мне усомниться, что Virtuoso собирает нужную статистику *только* во время планирования выполнения запроса (хоть ты этого и не говорил smile. Дело в том, что при таком подходе нельзя, например, выглядеть хорошо в BSBM бенчмарке, поскольку на 10-100M там запросы выполняются за 10-50мс (в отличие от, например, SP2B). Т.е. оптимизатор физически не может себе позволить потратить, скажем, 20мс на планировку, а соответственно все необходимые данные должны быть уже готовы и я более чем уверен, что Virtuoso сохраняет нужные статистики если не во время загрузки данных, то не позднее чем в warm-up runs.

Но ладно, это уже махровый флейм пошел.

PS. Кстати, ты не в курсе, почему ваш Kingsley такой агрессивный тип? smile

12

Re: Построение базы знаний с использованием Hbase

Некоторые виды анализа выполняются статически, но они "не про RDF". Скажем, часто интересно оценить, сколько различных значений хранится в колонке таблицы, прочитав случайно выбранную малую долю всех строк. Это, конечно, делается впрок.

P.S. Кингсли --- аггрессивный? Не знаю, я его обычно видел добрым и улыбающимся. И вообще, не зря же нас за организацию и спонсорство большого количества семвебоских вечеринок обозвали "OpenDrink Software".
Да, он резко высказывается о некоторых, так скажем, видных деятелях сообщества. Но в этом я с ним частенько соглашаюсь.
Да, он может заговорить до смерти ненароком, потому что вколачивать свои идеи в чужие головы он умеет с эффективностью электромолотка. Но это тоже не аггрессивность smile

13

Re: Построение базы знаний с использованием Hbase

Некоторые виды анализа выполняются статически, но они "не про RDF". Скажем, часто интересно оценить, сколько различных значений хранится в колонке таблицы, прочитав случайно выбранную малую долю всех строк. Это, конечно, делается впрок.

Хм, ну ладно. "Не про RDF" мне пока не очень интересно, я с этим не работаю. Sampling мы тоже используем.

А насчет Кингсли, вживую я с ним сталкивался только на Semantic Web meet-up'ах в MIT и меня просто поражало его стремление поспорить со всеми и по-любому поводу (причем не особо так слушая собеседника). Ну да ладно, я пришел к выводу, что это аспект ведения бизнеса такой, типа ничего личного.