Викиданные на локальном Blazegraph: здесь ожидается значение RDF, найдено "" [строка 1]

https://wiki.blazegraph.com/wiki/index.php/Bulk_Data_Load#Command_line

поэтому должна быть возможность использовать инструмент командной строки напрямую вместо REST API.

К тому же весь процесс кажется довольно неудобным. Инструмент использует файл .gz, который на 25% больше, чем файл .bz2, и его загрузка занимает больше времени. Распаковка файла .bz2 происходит быстрее, чем процедура munge. Я предполагаю, что обработка распакованного файла 230 ГБ, например.

230033083334 4 января, 07:29 wikidata-20180101-all-BETA.ttl

"по частям" может работать лучше. Но сначала нам нужно посмотреть, что мешает импорту.

Моя первая проблема заключалась в том, что сценарий оболочки runBlazegraph.sh выдавал ошибку при отсутствии файла mwservices.json.

Я предполагаю, что файл вроде https://github.com/wikimedia/wikidata-query-deploy/blob/master/mwservices.json.

Итак, я попытался исправить это с помощью

хотя я сомневаюсь, что это имеет большое значение.

wget https://raw.githubusercontent.com/wikimedia/wikidata-query-deploy/master/mwservices.json

Фактический звонок

работал у меня на сервере Ubuntu 16.04 LTS с Java 1.8.0_151, поэтому я считаю, что нам нужно изучить более подробную информацию, чтобы исправить проблему Томаса.

./loadRestAPI.sh -n wdq -d data/split/wikidump-000000001.ttl.gz 
Loading with properties...
quiet=false
verbose=0
closure=false
durableQueues=true
#Needed for quads
#defaultGraph=
com.bigdata.rdf.store.DataLoader.flush=false
com.bigdata.rdf.store.DataLoader.bufferCapacity=100000
com.bigdata.rdf.store.DataLoader.queueCapacity=10
#Namespace to load
namespace=wdq
#Files to load
fileOrDirs=data/split/wikidump-000000001.ttl.gz
#Property file (if creating a new namespace)
propertyFile=/home/wf/wikidata/wikidata-query-rdf/dist/target/service-0.3.0-SNAPSHOT/RWStore.properties
<?xml version="1.0"?><data modified="0" milliseconds="493832"/>DATALOADER-SERVLET: Loaded wdq with properties: /home/wf/wikidata/wikidata-query-rdf/dist/target/service-0.3.0-SNAPSHOT/RWStore.properties

см. также https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-query/Documentation

Больше подробностей.

Чтобы проверить результаты, я использовал ssh-туннель к моему серверу ubuntu

а потом

ssh -L 9999:localhost:9999 user@server

http://localhost:9999/bigdata/namespace/wdq/sparql

в браузере моего локального компьютера (ноутбука) браузер.

Второй импорт тоже работал нормально.

Затем я проверил содержимое базы данных с помощью следующего запроса SPARQL:

давая результат

SELECT ?type (COUNT(?type) AS ?typecount)
WHERE {
  ?subject a ?type.
}
GROUP by ?type
ORDER by desc(?typecount)
LIMIT 7

учитывая опыт импорта, я бы сказал, что вызовы munge и loadRestAPI могут выполняться несколько параллельно, поскольку шаг loadRestAPI, по-видимому, медленнее.

type                                          typecount
<http://wikiba.se/ontology#BestRank>            2938060
schema:Article                                  2419109
<http://wikiba.se/ontology#QuantityValue>.        78105
<http://wikiba.se/ontology#TimeValue>.            61553
<http://wikiba.se/ontology#GlobecoordinateValue>  57032
<http://wikiba.se/ontology#GeoAutoPrecision>       3462
<http://www.wikidata.org/prop/novalue/P17>.         531

Для импорта каждого файла gz требуется около 5 минут. Позже это исчезнет, ​​и некоторые файлы фактически заняли до 1 часа 15 минут на сервере Вольфганга.

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

В настоящее время 358 из 440 файлов импортируются через 158 часов на этом компьютере. В настоящее время размер файлов wikidata.jnl составляет 250 ГБ, и было импортировано около 1700 миллионов операторов.

Статистика загрузки довольно неудобная. Загрузка одного из файлов * .ttl.gz на машине Вольфганга занимает от 87 до 11496 секунд. Среднее значение на данный момент составляет 944 секунды. Похоже, что на определенных этапах импорта время на файл gz увеличивается, например от 805 до 4943 секунд или с 4823 до 11496 - после этого время, кажется, стабилизируется на более высоком уровне и возвращается всего к 293 или 511 секундам. Такое временное поведение очень затрудняет прогнозирование того, сколько времени займет полный импорт.

Учитывая, что загрузка заняла так много времени, Вольфганг настроил вторую машину импорта несколько иначе.

у второй машины есть данные для импорта на жесткий диск 7.200 об / мин и файл журнала blazegraph на SSD.

1. Машина: 8 ядер, 32 ГБ ОЗУ, 1 512 ГБ жесткий диск со скоростью 7.200 об / мин и 1480 ГБ SSD.
2. Как вы загружаете данные?

Второй импорт машин показывает лучшее временное поведение после 3,8 дня, когда импорт завершился со следующей статистикой:

первая машина все еще не закончена через 10 дней

    |  sum d |   sum h |         mins |         secs |
----+--------+---------+--------------+--------------+
MIN |  0.0 d |   0.0 h |     1.2 mins |      74 secs |      
MAX |  0.0 d |   1.1 h |    64.4 mins |    3863 secs |
AVG |  0.0 d |   0.2 h |    12.3 mins |     738 secs | 
TOT |  3.8 d |  90.2 h |  5414.6 mins |  324878 secs |

Машина: 8 ядер, 56 ГБ ОЗУ, 6 террабайтных жестких диска со скоростью 5,400 об / мин

SUM | 10.5 d | 252.6 h | 15154.7 mins |  909281 secs |
----+--------+---------+--------------+--------------+
MIN |  0.0 d |   0.0 h |     1.5 mins |      87 secs |
MAX |  0.3 d |   7.3 h |   440.5 mins |   26428 secs |
AVG |  0.0 d |   0.6 h |    36.4 mins |    2185 secs |
TOT | 11.1 d | 267.1 h | 16029.0 mins |  961739 secs |
----+--------+---------+--------------+--------------+
ETA |  0.6 d |  14.6 h |   874.3 mins |   52458 secs |