Чтение большого графика от Titan (на HBase) в Spark

Question

Я изучаю Titan (на HBase) в качестве кандидата для большой распределенной базы данных графа. Нам нужен как OLTP-доступ (быстрые, многопроцессорные запросы по графику), так и OLAP-доступ (загрузка всего - или, по крайней мере, большой части - графика в Spark для аналитики).

Из того, что я понимаю, я могу использовать сервер Gremlin для обработки запросов в стиле OLTP, где мой результирующий набор будет небольшим. Поскольку мои запросы будут созданы с помощью пользовательского интерфейса, я могу использовать API для взаимодействия с сервером Gremlin. Все идет нормально.

Проблема относится к случаю использования OLAP. Поскольку данные в HBase будут совместно расположены с исполнителями Spark, было бы полезно прочитать данные в Spark, используя HDFSInputFormat. Было бы неэффективно (на самом деле, учитывая прогнозируемый размер графика) выполнить запрос Гремлина из драйвера, а затем распространить данные обратно на исполнителей.

Лучшее руководства я нашел маркированное завершившееся обсуждение с репо Titan GitHub (https://github.com/thinkaurelius/titan/issues/1045), который наводит на мысль, что (по крайней мере, для Кассандры фонового) стандартного TitanCassandraInputFormatдолжны работы для чтения таблиц Titan. Ничто не претендует на бэкэнды HBase.

Однако, прочитав о базовой модели данных Titan (http://s3.thinkaurelius.com/docs/titan/current/data-model.html), выяснилось, что части «сырые» данные графа сериализуются без объяснения того, как восстановить граф свойств из содержимого.

И так, у меня есть два вопроса:

1) все, что я уже говорил выше, правильно, или я пропустил/неправильно поняли что-нибудь?

2) Кто-нибудь смог прочитать «сырой» график Титана из HBase и восстановить его в Spark (либо в GraphX, либо в DataFrames, RDD и т. Д.)? Если да, можете ли вы дать мне какие-либо указания?

Answer 1

Около года назад я столкнулся с тем же вызовом, который вы описали - у нас был очень большой экземпляр Titan, но мы не могли запускать на нем какие-либо процессы OLAP.

Я изучил этот вопрос довольно глубоко, но любое найденное мной решение (SparkGraphComputer, TitanHBaseInputFormat) было либо очень медленным (вопросы дней или недель в нашем масштабе), либо просто ошибками и пропущенными данными. Основной причиной медленности было то, что все они использовали основной API HBase, который оказался узким местом для скорости.

Итак, я реализовал Mizo - это Spark RDD для Titan на HBase, который обходит основной API HBase и анализирует HBase internal data files (называемый HFiles).

Я проверил его на довольно крупном масштабе - график Титана с сотнями миллиардов элементов, весом около 25 ТБ.

Поскольку он не полагается на API сканирования, который предоставляет HBase, он намного быстрее. Например, подсчет ребер в упомянутом графе занимает около 10 часов.