「分布式RDF流处理和推理」- 任向南 在巴黎东部大学完成的软件工程博士论文

分布式RDF流处理和推理任向南引用此版本：湘南任。分布式RDF流处理和推理。软件工程[cs.SE]。巴黎东部大学，2018年。英语NNT：2018PESC 1139。电话：02083973HAL Id：tel-02083973https://theses.hal.science/tel-020839732019年3月29日提交HAL是一个多学科的开放获取档案馆，用于存放和传播科学研究文件，无论它们是否已这些文件可能来自法国或国外的教学和研究机构，或来自公共或私人研究中心。L’archive ouverte pluridisciplinaireEcoleDoctoraleMath'ematiquesetSTICTh'esepr'esen'eepourobtenirlegradededocteur学科：信息学Traitement et RaisonnementDistribuesdesFluxRDF任向南Atos，InnovationLabUniversit'edeP-Est计算机科学报告员：Jeff Z. Pan教授Pascal Molli检查员：屁股oc。 教授 博士奥利维耶·库雷Zakia Kazi-Aoul博士副教授发布日期：2018年11月19日3宣言我在此声明，我是我的论文的唯一作者和作曲家，没有其他来源或学习辅助工具，除了那些列出的，已经使用。此外，我声明，我已经通过提供所述工作的详细参考而承认了他人的工作我在此声明，我的论文没有准备另一次考试或任务，无论是全部或摘录。地点、日期和签名51. 确认7摘要实时处理来自传感器的数据流正在成为工业场景中的常见任务在物联网（IoT）上下文中，数据从异构流源发出，即，例如，来自不同的领域和数据模型。这要求物联网应用程序有效地处理数据集成机制。RDF数据流的处理因此成为一个重要的研究领域。这一趋势使广泛的创新应用，其中实时和推理方面是普遍的。这种应用程序的关键实现目标包括有效地处理大量传入的数据流，并支持异常检测等高级数据分析服务然而，现代RSP引擎必须解决大数据时代遇到的容量和速度在一个正在进行的工业项目中，我们发现一个24/7可用的流处理引擎通常面临着大量的数据量，动态变化的数据结构和工作负载特性。这些因素影响发动机的性能和可靠性。为了解决这些问题，我们提出了Strider，一个混合自适应分布式RDF流处理引擎，根据数据流的状态优化Strider旨在保证重要的工业属性，如可扩展性，高可用性，容错，高吞吐量和可接受的延迟。这些保证是通过使用Spark和Kafka等最先进的Apache组件设计引擎架构来实现的此外，在RSP引擎上执行的越来越多的处理作业需要推理机制。它通常以在数据吞吐量、延迟和表达性推理的计算成本之间找到折衷为代价。因此，我们扩展Strider以支持实时RDFS+（i.例如，RDFS+sameAs）推理能力。 我们将Strider与查询重写方法相结合，SPARQL得益于知识库的智能编码该系统沿着不同的维度和多个数据集进行评估，以强调其性能。最后，我们进一步探索了RDF流推理，8答案集编程的片段。我们这部分的研究工作主要是出于这样一个事实，即越来越多的流应用程序需要更有表现力和复杂的推理任务。主要的挑战是以可扩展和支持推理的方式处理最近在这方面的努力仍然缺乏系统的可扩展性方面的流推理。因此，我们的目标是探索现代分布式计算框架在大数据流上处理高度表达的知识推理查询要做到这一点，我们认为查询表示为一个积极的片段LARS（一个时间逻辑框架的基础上回答集编程），并提出解决方案来处理这样的查询，基于两个主要的并行和分布式执行框架所采用的主要执行模型：批量同步并行（BSP）和记录的时间（RAT）。我们实现了名为BigSR的解决方案，并进行了一系列评估。我们的实验表明，BigSR实现了高吞吐量超过百万三倍每秒使用一个相当小的机器集群。9R'esum'edeT'eseLetra i teme ntentempsr'eeldesfluxdedon'ees'emana ntdescapacitorsde ve nuunetouchachecoura ntedansdeno mbreuxs c'enariosindustriels. 在物联网（IoT）的文本中，这些不存在的东西 是 通 过 流 量 源 产 生 的 ， 这 是 一 个 领 域 的 问 题 ， 也 是 不 存 在 的 东 西 的 问 题 。Celaimposeauxapplicationsdel'IoT ded e g ′ erer efficaceme n t l'i n t ′ egration de donn ′ ees ` a partir de resources diverses.Letraiteme ntdesfluxRDFestd`eslorsde venuundomainede reccheim porta nt. Cetted'emarcheba'esurdestechnologiesduWebS'emantique超级重要的实际应用，不影响任何概念的应用，有时候你会觉得自己很有道理。 这是一个很好的应用程序。特别是，她的一个主要目标是有效地减少不合格品的流动性，并通过对不合格品的分析提供服务。例如，在一个实施例中，检查异常。然而，RDF流处理（RSP）的一个现代化的驱动程序正在考虑大数据中的学习和访问问题。在一个喷气发动机行业中，我们需要一个24/7全天候的流量分配系统，它不需要一个真正的流量分配系统，因为它的结构和系统的特性都是动态变化的。 这对电机的性能和可靠性没有影响。 由于我们的R′esoud recesprobl`emes，我们 支 持 我 们 的 Strider ， 一 个 用 于 处 理 RDF 流 分布的电机， hybrideetadaptatifquioptimizeleplanderequire uproximetelogiqueselonl 'etatdesfluxdedonn′ees。Stridera'eeeconcampuupourgaran ntird'im porta n te s propr i 'e t'es industriellestelles que l ' e volutivi t'e，la haute disp on i bili t'e，la to l'eranceaux pannes，le haut d'ebit et une lattence acceptable. 这些保证是在考虑大数据不可控制的组件的基础上获得的对我们来说，一个没有真正意义上的十字架并不是为了实现更大的RSP而进行的。Ilssetraduisentg'en'eralementparuncompromisentreled'ebitdedonn'ees，lalatenceetlecoutcomputationneldesin f'eethees. 因此，我们要把大步佬带到我们面前，10capacit'ederaisonnemententempsr'eelavecunsupportd例如，RDFS +sameAs）。我们将Strider与要求的R'e'ecriture相结合，以满足S PA R QL的要求，S P A RQL无法有 效 地 将 信 息 传 递 给 我 们 的 知 识 基 础 。 Lesys t`emeest'e val u'eselondiff'erentesdimensionsetsurplusieursjeuxdedon'ees，pourmettreen'evidencesesper formances.最后，我们将在一个ASP（Ans wer Set Programming）的框架中探索RDF在一个复杂的tologiesexprimes中的合理性。 Laconsi d'erationdecetteprob l'ematiquedere c her cheestprincipalementmoti v'eeparlefa itquedeplusenplusd'applications de streaming n'ecessite n tdes t a benches de raisonneme n t plus expressi v es et complex. 效率主要包括行为学效率的各个方面和潜在方面。在这个领域里所作的努力并不意味着系统的通过是不合理的。 此外，我们还将探索系统的容量分布，以满足您在流量方面的需求。 我们认为LARS的一个框架中的需求是可扩展的，并提出了针对我们的需求的解决方案，其中包括两个基于分布式系统的需求：Bu l k Syn chronous P artifact（BSP）和Record-at-A-Time（R A T）。我们的决心在我们的解决方案命名我的大SReteffectuonsunes'eried''evaluations。Nosexp'eriencesmontrentqueBigSRatteintund'ebit'elev'eau-dela`dumilliondetripletsparsecondeenutilisantunpetitgroupedemachines.11内容1. 鸣谢52. 一、导言212.1. 动机212.2. 用例232.3. 捐款242.3.1.对区域战略方案业绩评价的242.3.2. 混合自适应分布式RDF流处理引擎。242.3.3. 大规模RDF流推理（RDF++和sameAs） cloud. ............................242.3.4. BigSR：现代大数据平台上实时表达RDF流推理的实证研究。.....242.4. 出版物252.5. 第26章大纲3. 背景知识273.1. RDF和SPARQL273.2. RDF数据的存储3.3. 语义网知识库（KB）和推理323.4. 流模型和连续查询处理343.4.1.RDF流模型343.4.2. 连续SPARQL查询处理353.4.3. 流处理的执行语义373.5. 数据库和应答集编程（ASP）383.5.1.数据库/ASP基础383.5.2. LARS Framework forRDF Streams393.6. 分布式流处理引擎（DSPE）404. 相关工作47124.1. 可吸入悬浮粒子基准484.2. RSPSystems494.3. 数据库、应答集编程和RDF流推理5. RSP性能评估575.1. 一、导言. 575.2. C-SPARQL、CQELS和RSP基准5.3. 评估计划585.3.1.业绩指标595.4. 实验615.4.1.时间驱动：C-SPARQL615.4.2. 数据驱动：CQELS655.5. 结果讨论结论676. StriderArchitecture716.1. 动机716.2. 系统架构726.2.1.72岁6.2.2. 架构概述737. Strider77中的混合自适应连续SPARQL查询处理7.1.RDF到RDBMS映射777.2. 混合自适应查询处理787.2.1.查询处理大纲触发层787.2.2.查询计划生成807.2.3.F-AQP847.3. 实验867.3.1.实验装置877.3.2.评价结果887.4. 结论. 928. 基于Litemat93的Strider分布式RDF流推理8.1. 导言. 938.2. StriderR概览95138.3. 连续推理查询978.4. 对概念和属性层次结构的8.4.1.标准重写：添加UNION子句1008.4.2. 适用于流推理的1018.5. 使用sameAs属性进行1068.5.1.SameAs团编码1068.5.2. 基于代表性（RB）的推理1078.5.3. SAM推理1098.6. 评价1158.6.1.计算设置1158.6.2. 数据集、可扩展性和性能指标1168.6.3. 通过推理方法量化连接和联合1178.6.4. 结果评价8.6.5. SAM方法的成本分析1228.7. 结论1239. BigSR：An Empirical Study of Real-time Expressive RDFStreamReasoning on Modern BigData Platforms1259.1. 导言. 1259.2. BSP和RAT模型中使用LARS的流推理1279.2.1.并行数据库评估1279.2.2. Spark和Flink127上的流模型9.3. 分布式流推理1299.3.1.BigSR129的架构9.3.2. 数据结构9.3.3. BigSR131中的窗口操作9.3.4. 程序计划生成。..................................................................................1329.3.5. Spark133上的分布式流推理9.3.6. Flink135上的分布式流推理9.3.7.讨论1379.4. 评价1389.4.1.基准设计1399.4.2. 评价结果讨论140149.5. 结论14210.结论和今后的工作145A. 第五章评价的依据149B. 第七章评价的标准153C. 第8章评价的标准157C.1. 肛门157C.1.1. 基于概念层次结构的推理的推理157C.1.2. 通过属性层次结构的推断进行查询157C.1.3. 在概念和属性上都有推论的推理158C.1.4. 通过owl：sameAs属性158进行推断的查询C.1.5. 对概念、属性层次结构和owl进行推理的方法：sameAs159C.2. 关于我们的连续查询扩展159的详细信息D. 第9章评价的标准161D.1. Waves数据集，非递归161D.2. SRBench数据集，非递归162参考书目16515图目录3.1.G128的图形表示3.2. Q_（1- 30）的无向连通图3.3. LUBM本体的可视化表示的片段333.4. Storm拓扑架构433.5. Spark Streaming上的离散流处理443.6. Flink环境454.1. C-SPARQL架构504.2. CQELS架构514.3. C-SPARQL架构524.4. C-SPARQL架构525.1. 水资源管理背景。595.2. 流速率和流数量对执行时间关于C-SPARQL................................................................................................. 615.3. Q163内存消耗的实时监控5.4. 在C-SPARQL中，（a）流速率和（b）静态数据大小对内存消耗的影响。645.5. 三元组个数和静态数据大小对查询执行的影响时间在CQELS。................................................................................................655.6. CQELS中三元组的数量和静态数据大小对内存消耗的影响。....................676.1. Strider Architecture.蓝色箭头和绿色箭头分别指到流程74，7.1. 从RDF到RDBMS的7.2. Strider混合查询优化797.3. UCG创建807.4. UCG权重初始化817.5. Q882的动态查询计划生成167.6. 初始化UCG权重，寻找路径覆盖并生成查询计划。.837.7. 适应战略的决策者847.8. RSP引擎吞吐量（三倍/秒）。 D/L-S：分布式/局部模式静态优化。D/L-A：分布式/局部模式自适应优化。SR：SRBench数据集的SR：Risk。 W：Waves数据集的Waves。........................................................... 887.9. Strider的查询延迟（毫秒）（在分布式模式下）897.10.Strider上的吞吐量记录。 （a）-第七季的吞吐量;（b）-吞吐量九方907.11. 在Strider90上为q 9放置7.12. Strider上Q4、Q5、Q6的可扩展性评估（a）吞吐量;（b）-延迟918.1. StriderRFunctional Architecture968.2. LUBM8.3. 基于DStream104的并行部分编码8.4. sameAs表示解决方案1088.5.Q6查询的SAM重写1138.6.Q8查询113的SAM重写8.7. LiteMat+RB和UNION+SAM的吞吐量比较第一季度至第五季度1188.8. LiteMat+RB和UNION+SAM之间的延迟比较Q1至Q51198.9. LiteMat+RB和UNION+SAM的吞吐量比较对于Q6，通过改变团的大小。.....................................................................1208.10. LiteMat+RB和UNION+SAM之间的延迟比较Q6通过改变团的大小。.................................................................................1208.11. LiteMat+RB和UNION+SAM的吞吐量比较对于Q7，Q8，通过改变团的大小。........................................................... 1218.12. LiteMat+RB和UNION+SAM之间的延迟比较Q7，Q8通过改变团的大小。....................................................................... 1219.1. 阻塞和非阻塞查询处理。...............................................................................1289.2. BigSR系统架构1299.3. 在Spark和Flink查询D.2的逻辑计划1319.4. Spark上的窗口操作符的翻译........................................................................ 1329.5. Flink上的窗口操作符的翻译..........................................................................132179.6. 在Spark和Flink上的递归程序（P0）评估....................................................1339.7. Spark和Flink在Q1到Q11期间的系统吞吐量（三倍/秒）。1419.8. 第1季度到第11季度Spark和Flink上的查询延迟（毫秒）.......................... 14219表的列表3.1. 不同DSPE的比较...............................................................................................424.1. RSP引擎的比较 TiW： 基于时间的窗口TpW：基于三重的窗口TD：时间驱动。 BD：批量驱动。我的天数据驱动。.........................................................................................................495.1. C-SPARQL中考虑的查询的最大速率。......................................................... 625.2. 第一季、第二季、第三及第六季的执行时间（以秒计）688.1. 对LUBM本体103的概念层级的提取的编码8.2. 用于相同推理1078.3. LOD数据集上的统计数据相同（ipc =每个相同的不同个体的数量作为团，max和avg分别表示ipc的最大值和平均值，*：仅包含具有DBpedia的sameAs三元组的子集，生物模型包含相同形式的三元组1178.4. LiteMat + RB（LMRB）和UNION + SAM（USAM）方法的每个查询的连接、联合和过滤器数量。在这里，UNION的数量对应于UNION关键字的数量。USAM*依赖于简化的LUBM本体1189.1. BSP和RAT138之间的直观比较9.2. 测试查询和数据集。.......................................................................................1399.3. 无状态查询延迟（毫秒）; Spark微批处理大小= 500毫秒。142