java - 本地 Blazegraph : Expected an RDF value here, 上的维基数据发现 '' [第 1 行]

Question

我们(Thomas 和 Wolfgang)已经按照此处的说明在本地安装了 wikidata 和 blazegraph:https://github.com/wikimedia/wikidata-query-rdf/blob/master/docs/getting-started.md

mvn package command was successful

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] parent ............................................. SUCCESS [ 54.103 s]
[INFO] Shared code ........................................ SUCCESS [ 23.085 s]
[INFO] Wikidata Query RDF Testing Tools ................... SUCCESS [ 11.698 s]
[INFO] Blazegraph extension to improve performance for Wikibase SUCCESS [02:12 min]
[INFO] Blazegraph Service Package ......................... SUCCESS [01:02 min]
[INFO] Wikidata Query RDF Tools ........................... SUCCESS [02:19 min]
[INFO] Wikibase RDF Query Service ......................... SUCCESS [ 25.466 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

我们都在用

java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)

我们都下载了 latest-all.ttl.gz 例如

31064651574 Jan  3 19:30 latest-all.ttl.gz

来自 https://dumps.wikimedia.org/wikidatawiki/entities/这花了大约 4 个小时。

.munge 在 data/split 中创建了 424 个文件作为“wikidump-000000001.ttl.gz”

~/wikidata/wikidata-query-rdf/dist/target/service-0.3.0-SNAPSHOT$ ./munge.sh -f data/latest-all.ttl.gz -d data/split -l en,de 
#logback.classic pattern: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
08:23:02.391 [main] INFO  org.wikidata.query.rdf.tool.Munge - Switching to data/split/wikidump-000000001.ttl.gz
08:24:21.249 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 10000 entities at (105, 47, 33)
08:25:07.369 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 20000 entities at (162, 70, 41)
08:25:56.862 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 30000 entities at (186, 91, 50)
08:26:43.594 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 40000 entities at (203, 109, 59)
08:27:24.042 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 50000 entities at (224, 126, 67)
08:28:00.770 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 60000 entities at (244, 142, 75)
08:28:32.670 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 70000 entities at (272, 161, 84)
08:29:12.529 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 80000 entities at (261, 172, 91)
08:29:47.764 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 90000 entities at (272, 184, 98)
08:30:20.254 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 100000 entities at (286, 196, 105)
08:30:20.256 [main] INFO  org.wikidata.query.rdf.tool.Munge - Switching to data/split/wikidump-000000002.ttl.gz
08:30:55.058 [main] INFO  org.wikidata.query.rdf.tool.Munge - Processed 110000 entities at (286, 206, 112)

当 Thomas 试图用 blazegraph 加载一个文件时

./loadRestAPI.sh -n wdq -d data/split/wikidump-000000001.ttl.gz

他得到了下面的错误。尝试从 blazegraph 的更新选项卡导入也没有用。

如何解决这个问题？

ERROR: uri=[file:/home/tsc/projects/TestSPARQL/wikidata-query-rdf-0.2.1/dist/target/service-0.2.1/data/split/wikidump-000000001.ttl.gz], context-uri=[] java.util.concurrent.ExecutionException: org.openrdf.rio.RDFParseException: Expected an RDF value here, found '' [line 1] at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at com.bigdata.rdf.sail.webapp.BigdataServlet.submitApiTask(BigdataServlet.java:281) at com.bigdata.rdf.sail.webapp.InsertServlet.doPostWithURIs(InsertServlet.java:397) at com.bigdata.rdf.sail.webapp.InsertServlet.doPost(InsertServlet.java:116) at com.bigdata.rdf.sail.webapp.RESTServlet.doPost(RESTServlet.java:303) at com.bigdata.rdf.sail.webapp.MultiTenancyServlet.doPost(MultiTenancyServlet.java:192) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:808) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:497) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:748) Caused by: org.openrdf.rio.RDFParseException: Expected an RDF value here, found '' [line 1] at org.openrdf.rio.helpers.RDFParserHelper.reportFatalError(RDFParserHelper.java:441) at org.openrdf.rio.helpers.RDFParserBase.reportFatalError(RDFParserBase.java:671) at org.openrdf.rio.turtle.TurtleParser.reportFatalError(TurtleParser.java:1306) at org.openrdf.rio.turtle.TurtleParser.parseValue(TurtleParser.java:637) at org.openrdf.rio.turtle.TurtleParser.parseSubject(TurtleParser.java:449) at org.openrdf.rio.turtle.TurtleParser.parseTriples(TurtleParser.java:383) at org.openrdf.rio.turtle.TurtleParser.parseStatement(TurtleParser.java:261) at org.openrdf.rio.turtle.TurtleParser.parse(TurtleParser.java:216) at org.openrdf.rio.turtle.TurtleParser.parse(TurtleParser.java:159) at com.bigdata.rdf.sail.webapp.InsertServlet$InsertWithURLsTask.call(InsertServlet.java:556) at com.bigdata.rdf.sail.webapp.InsertServlet$InsertWithURLsTask.call(InsertServlet.java:414) at com.bigdata.rdf.task.ApiTaskForIndexManager.call(ApiTaskForIndexManager.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ... 1 more

Answer 1

loadRestAPI.sh 脚本基本上就是下面提到的那个:

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

因此应该可以直接使用命令行工具而不是 REST API。

而且整个过程好像挺尴尬的。该工具依赖于 .gz 文件，该文件比 .bz2 文件大 25%，下载时间更长。解压缩 .bz2 文件比 munge 过程更快。我的假设是处理解压缩的 230GB 文件，例如

230033083334 1 月 4 日 07:29 wikidata-20180101-all-BETA.ttl

以“分块”方式可能效果更好。但首先我们需要了解导致导入阻塞的原因。

我的第一个问题是 shell 脚本 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

虽然我怀疑这有多大关系。

实际调用

./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

在 Ubuntu 16.04 LTS 服务器和 Java 1.8.0_151 上为我工作，所以我相信我们必须研究更多细节来解决 Thomas 的问题。

另见 https://wikitech.wikimedia.org/wiki/Nova_Resource:Wikidata-query/Documentation

了解更多详情。

为了检查结果，我使用了到我的 ubuntu 服务器的 ssh 隧道

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

给出结果

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

鉴于导入经验，我会说 munge 和 loadRestAPI 调用可以在某种程度上并行运行，因为 loadRestAPI 步骤显然较慢。

导入每个 gz 文件大约需要 5 分钟。这后来下降了，一些文件实际上在 Wolfgang 的服务器上花费了 1 小时 15 分钟。

在 Wolfgang 的第一台机器上加载所有数据可能需要 10 天或更长时间，因此请继续关注最终结果。

目前 440 个文件中的 358 个是在这台机器上 158 小时后导入的。此时 wikidata.jnl 文件大小为 250 GBytes，已导入约 17 亿条语句。

加载统计数据非常尴尬。在 Wolfgang 的机器上加载 *.ttl.gz 文件之一需要 87 到 11496 秒。此时平均为 944 秒。看起来在导入过程中的某些步骤中，每个 gz 文件的时间会增加，例如从 805 秒到 4943 秒或从 4823 秒到 11496 秒——在那之后时间似乎稳定在一个更高的水平，然后回到 293 秒或 511 秒。这种计时行为使得预测完整导入需要多长时间变得非常困难。

鉴于加载时间太长，Wolfgang 配置的第二台进口机器略有不同。

1. 机器:8 核、56 GB RAM、6 TB 5.400 rpm 硬盘
2. 机器:8 核、32 GByte RAM、1 512 GByte 7.200 rpm 硬盘和 1 480 GByte SSD

第二台机器在 7.200 rpm 硬盘上有要导入的数据，在 SSD 上有 blazegraph 日志文件。

第二台机器导入在导入完成 3.8 天后显示出更好的计时行为，具有以下统计数据:

    |  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 |

第一台机器10天了还没做完

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 |