3

我们（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 的 UPDATE 选项卡导入也不起作用。

可以做些什么来解决这个问题？

错误：uri=[file:/home/tsc/projects/TestSPARQL/wikidata-query-rdf-0.2.1/dist/target/service-0.2.1/data/split/wikidump-000000001.ttl.gz]，上下文-uri=[] java.util.concurrent.ExecutionException: org.openrdf.rio.RDFParseException: 这里需要一个 RDF 值，在 java.util.concurrent.FutureTask.report(FutureTask.java:122 ) 在 java.util.concurrent.FutureTask.get(FutureTask.java:192) 在 com.bigdata.rdf.sail.webapp.BigdataServlet.submitApiTask(BigdataServlet.java:281) 在 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) 在 com.bigdata.rdf.sail.webapp.MultiTenancyServlet.doPost(MultiTenancyServlet.java:192) 在 javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 在 javax.servlet.http.HttpServlet.service(HttpServlet.java:790) 在 org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder .java:808）在 org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587) 在 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) 在 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) 在 org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) 在 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) 在 org.eclipse 。码头。server.handler.ContextHandler.doScope(ContextHandler.java:1061) 在 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) 在 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle( ContextHandlerCollection.java:215) 在 org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) 在 org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) 在 org .eclipse.jetty.server.Server.handle(Server.java:497) 在 org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) 在 org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection .java:257) 在 org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) 在 org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) 在 org.eclipse .jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:748) 原因：org.openrdf.rio.RDFParseException: Expected an RDF value here, found '' [第 1 行] 在 org.openrdf.rio.helpers.RDFParserBase.reportFatalError(RDFParserBase.java:671) 在 org.openrdf.rio 的 org.openrdf.rio.helpers.RDFParserHelper.reportFatalError(RDFParserHelper.java:441) .turtle.TurtleParser.reportFatalError(TurtleParser.java:1306) 在 org.openrdf.rio.turtle.TurtleParser.parseValue(TurtleParser.java:637) 在 org.openrdf.rio.turtle.TurtleParser.parseSubject(TurtleParser.java:449 ) 在 org.openrdf.rio.turtle.TurtleParser.parseStatement(TurtleParser.java:261) 在 org.openrdf.rio.turtle.TurtleParser 的 org.openrdf.rio.turtle.TurtleParser.parseTriples(TurtleParser.java:383)。解析（TurtleParser.java:216）在 org.openrdf.rio.turtle.TurtleParser.parse(TurtleParser.java:159) 在 com.bigdata.rdf.sail.webapp.InsertServlet$InsertWithURLsTask.call(InsertServlet.java:556)在 com.bigdata.rdf.sail.webapp.InsertServlet$InsertWithURLsTask.call(InsertServlet.java:414) 在 com.bigdata.rdf.task.ApiTaskForIndexManager.call(ApiTaskForIndexManager.java:68) 在 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 个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) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ... 还有 1 个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) 在 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 在 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ... 还有 1 个

4

1 回答 1

2

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

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

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

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

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

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

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

给出结果

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 天或更长时间，因此请继续关注最终结果。

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

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

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

  1. 机器：8 核，56 GB RAM，6 Terrabyte 5.400 rpm 硬盘
  2. 机器：8 核、32 GB RAM、1 512 GB 7.200 rpm 硬盘和 1 480 GB 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 |
于 2018-01-05T08:49:33.527 回答