Estou pesquisando o Titan (no HBase) como candidato a um grande banco de dados de gráficos distribuídos. Exigimos o acesso OLTP (consultas rápidas e de vários saltos no gráfico) e o acesso OLAP (carregando todo - ou pelo menos uma grande parte - do gráfico no Spark para análise).

Pelo que entendi, posso usar o servidor Gremlin para lidar com consultas no estilo OLTP, onde meu conjunto de resultados será pequeno. Como minhas consultas serão geradas por uma interface do usuário, posso usar uma API para fazer interface com o servidor Gremlin. Por enquanto, tudo bem.

O problema está relacionado ao caso de uso OLAP. Como os dados no HBase serão co-localizados com os executores do Spark, seria eficiente ler os dados no Spark usando umHDFSInputFormat. Seria ineficiente (impossível, de fato, dado o tamanho do gráfico projetado) executar uma consulta Gremlin a partir do driver e depois distribuir os dados de volta aos executores.

A melhor orientação que encontrei é uma discussão não concluída do repositório Titan GitHub (https://github.com/thinkaurelius/titan/issues/1045), o que sugere que (pelo menos para um back-end do Cassandra) o padrãoTitanCassandraInputFormat devemos trabalhar para ler tabelas Titan. Nada é reivindicado sobre os backends do HBase.

No entanto, ao ler sobre o modelo de dados subjacente do Titan (http://s3.thinkaurelius.com/docs/titan/current/data-model.html) parece que partes dos dados do gráfico "bruto" são serializadas, sem explicação sobre como reconstruir um gráfico de propriedades a partir do conteúdo.

E então, eu tenho duas perguntas:

1) Tudo o que afirmei acima está correto ou perdi / não entendi nada?

2) Alguém conseguiu ler um gráfico Titan "bruto" do HBase e reconstruí-lo no Spark (no GraphX ou como DataFrames, RDDs etc.)? Se sim, você pode me dar alguma dica?