《大数据集成(1)》一1.2 大数据集成:挑战

简介:

本节书摘来自华章出版社《大数据集成(1)》一书中的第1章,第1.2节,作者 [美] 董欣(Xin Luna Dong)戴夫士·斯里瓦斯塔瓦(Divesh Srivastava),更多章节内容可以访问云栖社区“华章计算机”公众号查看

1.2 大数据集成:挑战

  为了更好地理解大数据集成带来的各种挑战,我们给出5个最近的案例研究,实验性地检查大数据集成中的Web数据源的各种特征,以及对这些特征自然分类的维度。
  “当你能度量你所说的,并能将它表示成数字,那么你就认识它一些了。”
  ——Lord Kelvin

1.2.1 “V”维度

  大数据集成在多个维度上不同于传统数据集成,类似于大数据不同于传统数据库的维度。
  1.海量性(Volume)
  在大数据时代,不仅数据源包含大量的数据,而且数据源的数目也增长到千万级;即使对于单个领域,数据源的数目也增长到成万到十万甚至百万的级别。
  很多情境下,单一的数据源可能包含大规模的数据,如社交媒体、电信网络以及金融等。
  单个领域中包含大量数据源的情境,可以考虑我们给出的航班的例子。假设我们想把它扩展到世界上所有航空公司和机场,从而可以支持灵活的国际旅行的航行计划。由于全世界有成百上千个航空公司和4万多个机场1,需要被集成的数据源数目很容易就上万乃至十万了。
  更一般地,我们将在1.2.2节、1.2.3节和1.2.5节中讨论的案例研究中量化包含结构化数据的Web数据源的数目,结果显示这些数目大大超过了传统数据集成中所考虑的数据源的数目。
  2.高速性(Velocity)
  数据被采集和不断被可用化的速度直接导致大多数数据源都是动态的,而且数据源的数目也是飞速增长的。
  动态数据源的情境可以考虑我们给出的航班的例子,其中上万个数据源在提供随时间不断变化的信息。有些信息的变化粒度是小时和分钟,例如航班的估计出发和到达时间,以及航班当前的位置等。其他一些信息变化得更慢些,以月、星期或天为变化粒度,例如航班原定的出发和到达时间的变化。为所有这些数据源上的动态变化的数据提供一个集成的视图,是传统数据集成方法无法做到的。
  为了说明数据源数目的增长速度,我们在1.2.2节中讨论的案例研究显示了几年内深网数据源数目的爆炸性增长。毫无疑问,这些数目现在可能变得更大了。
  3.多样性(Variety)
  来自不同领域的数据源自然是多样的,因为它们描述不同类型的实体和关系,经常要在支持复杂应用时需要被集成起来。另外,即使同一领域的数据源也常常是异构的,主要体现在模式级别如何结构化它们的数据和在实例级别如何描述同一现实世界中的实体,即使对非常类似的实体也会显示很大的多样性。最后,这些领域、源模式以及实体表达会随着时间演化,更增加了大数据集成中需要处理的多样性和异构性。
  再次考虑我们的航班例子。假设我们想把它扩展到其他交通类型(如飞机、轮船、火车、大巴、出租车等)来支持复杂的国际旅行计划的制订。需要被集成的数据源的多样性将大大提高。除了世界上的航空公司和机场,又有世界上近千个活跃的海港和内陆港,世界范围内1?000多个大巴公司,以及差不多相同数目的火车公司。234
  我们在1.2.2节、1.2.4节和1.2.5节给出的案例研究量化了Web数据源中实际存在的巨大的多样性。
  4.真实性(Veracity)
  不同数据源的质量千差万别,在数据的覆盖面、精确度以及时效性等方面存在着巨大差异。
  我们的航班例子显示了实际中可能存在的一些具体的质量问题。随着数据源数目和多样性的不断增长,这些质量问题只会更加恶化,因为实际中数据源之间会互相复制而且存在着不同类型的相关性。
  我们在1.2.3节、1.2.4节和1.2.6节中给出的案例研究显示了即使在同一领域的Web数据源中可能存在的严重的数据覆盖和质量问题。这也说明为什么“三个商业领导者中间就有一个不相信他们用来做决策的信息”。5

1.2.2 案例研究:深网数据量

  深网包含大量的数据源,其数据被存储在数据库中并且只能通过查询Web 表单来获得。[He at al. 2007]和[Madhavan et al. 2007]实验性地研究了深网中数据源的海量性、高速性和领域级的多样性等性质。
  1.主要问题
  这两个研究集中在以下两个与1.2.1节中给出的“V”维度相关的主要问题。
  * 深网的规模有多大?
  例如,Web上有多少个数据库的查询界面?通过这样的查询界面可以存取多少个Web数据库?多少Web数据源提供这样的数据库查询界面?这些有关深网的数字是如何随时间变化的?
  * Web数据库的领域分布是什么?
  例如,是否深网的数据源主要是关于电子商务的,如商品搜索?还是Web数据库存在着相当程度的领域级的多样性?这些领域级的多样性和浅层网比较起来如何?
  2.研究方法
  由于没有一个对深网数据源的较完全的索引,两个研究都是用采样的方法来量化这些问题的答案。
  [He at el. 2007]使用一种IP采样的方法搜集服务器样本,即随机采样2004年的1百万个IP地址,使用WgetHTTP客户端下载HTML页面,然后人工判定和分析此样本中的Web数据库,以此来推算22亿个有效IP地址。这一研究使用下面的方法来区分深网数据源、Web数据库(一个深网数据源可以包含多个Web数据库)和查询界面(一个Web数据库可能被多个查询界面所存取)。
  1)从每个Web数据源的根页面开始向下爬取三层,然后判定爬取到的页面上的所有HTML查询界面。
  一个数据源上的多个查询界面可能指向同一底层的数据库。这可以通过下面的方法来判定:先人工随机选择一个查询界面上返回的一组对象,然后看是否每个对象也可以通过另外一个查询界面获取。
  2)Web数据库的领域分布通过对Web数据库人工进行分类的方法来确定。分类的类别是Yahoo(http://yahoo.com)分类结构中最顶层的所有类别。
  [Madhavan et al. 2007]从Google 2006年的索引中随机采样2?500万个网页,然后用规则驱动的方法判定这些页面上的深网查询界面,并最终将他们的估计推算至Google索引中的10亿多页面上。沿用[He et al. 2007]中的术语,这一研究主要检查了深网中查询界面的数目,而不是不同深网数据库的数目。他们使用的方法如下。
  1)由于许多HTML 表单(form)可能出现在多个网页上,他们为每个表单计算了一个签名,具体把表单动作中的主机名和可视输入项合在一起得到。这被用来得到不同HTML 表单的数目的下界。
  2)从这一数字出发,他们删去了非查询表单(如密码输入项)和网站搜索框,并只计算那些至少有一个文本输入域且包含2~10个输入项的表单。
  3.主要结果
  我们按照几个“V”维度来归类这些研究得到的主要结果。
  (1)海量性、高速性
  [He et al. 2007]在2004年估计深网大概含有307?000个数据源,450?000个Web数据库,以及1 258 000个不同查询界面。这是从他们随机选择的IP样本中判定的总共126个深网数据源(包含190个Web数据库和406个查询界面)推算得到的。由于判定的深网数据源的数目不大,使得他们能用人工判定查询界面的方法来完成他们大部分的分析工作。
  [Madhavan et al. 2007]在2006年估计深网有超过1?000万个不同的查询界面。这是从他们随机采样的网页中判定的647 000个不同查询界面中推算出的。判定这样大量的查询界面需要使用自动的方法来区分深网查询界面和非查询界面。Madhavan等估计出的查询界面的数目大于He等估计出的数目也部分反映了深网数据源的数目在这两个研究点的时间段内快速增长的速度。
  (2)多样性
  [He et al. 2007]的研究显示深网数据库具有很大的领域级多样性,在他们样本中被判定出来的190个Web数据库中,51%属于非电子商务领域,如健康、社会文化、教育、艺术人文、科学等,只有49%属于电子商务领域。表1-10给出了He等人研究中判定的领域类别分布,表明了在大数据集成中数据的领域级多样性。Web数据库的领域级多样性与浅层网形成鲜明对比,之前的一个研究表明浅层网中83%的网站是电子商务类的。
  [Madhavan et al. 2007]的研究也肯定了深网数据源中的语义内容也很广,分布在大部分类别上。
image
image

1.2.3 案例研究:抽取的领域数据

  浅层网的文档中包含了大量结构化的数据,可以用信息抽取的技术得到。[Dalvi et al. 2012]实验性地研究了某些领域(如餐馆、旅店)内的这些结构化数据(即实体和它们的属性)的数量和覆盖特性。
  1.主要问题
  这一研究集中在以下两个与1.2.1节中给出的“V”维度相关的主要问题。

  • 要为一个给定领域(甚至限定一组属性)构建一个完全的数据库需要多少数据源?
      例如,要构建一个完全的数据库(如覆盖领域内95%的信息),是否已经建好的主要信息聚集网站(如餐馆领域的http://yelp.com)就包含了绝大部分信息,还是要去访问一些长尾数据源?是否有足够的需求要构建一个完全的数据库,例如用对长尾实体的需求来衡量?
  • 发现一个给定领域的数据源和实体有多容易?
      例如,是否可以从几个数据源或种子实体出发迭代地发现大部分(如99%)数据?主要信息聚集网站在这一数据源发现过程中的作用有多关键?

  2.研究方法
  回答这些问题的一种方法是在各种领域内实际进行Web规模的信息抽取,然后计算出需要的数值;但这是一个极具挑战的任务,好的解决方法仍在研究中。相反,[Dalvi et al. 2012]采用的方法是研究具有以下三个特性的领域。
  1)有一个包含该领域内实体的较完全的结构化数据库可以被访问。
  2)实体可以由网页上的一些关键属性值所唯一标识。
  3)包含实体的关键属性的(近乎)所有网页可以被访问。
  Dalvi等给出了9个这样的领域:图书、餐馆、汽车、银行、图书馆、学校、旅店和借宿、零售和购物,以及家居和园艺。图书可以被ISBN所唯一标识,而其他领域内的实体可以用电话号码和/或主页URL来唯一标识。对每个领域,他们找到Yahoo!网页缓存中每个页面上实体的标识属性,将网页按照主机名分组,每个组对应一个数据源,然后将每个数据源的所有网页上发现的实体聚集在一起。
  他们用一个实体和数据源之间的二分图来为数据源和实体发现容易程度问题建模。边(E, S)表示实体E在数据源S中被发现。图的一些诸如二分图的连接度等性质有助于理解迭代信息抽取算法相对于种子实体和初始数据源选择的鲁棒性。类似地,图的直径可以指出需要多少次迭代才可以收敛。这样,他们不需要实际进行信息抽取,只要研究他们数据库中已有的实体信息分布即可。尽管这种方法有一定的局限性,它为这一主题的研究提供了一个很好的开始。
  3.主要结果
  我们按照几个“V”维度来归类这一研究得到的主要结果。
  海量性
  第一,他们发现研究的所有领域具有上万到上十万的数据源(见图1-2中所示的餐馆领域中的电话号码数量)。这些数目大大超出了传统数据集成中考虑的数据源数目。
  第二,他们显示长尾数据源含有大量的信息,即使对餐馆这样具有很好的主要信息聚集网站的领域。例如,http://yelp.com包含少于70%的餐馆电话号码和少于40%的餐馆主页。从前10个数据源(按数据源所包含的实体个数降序排列)可以抽取出约93%的餐馆电话号码;从前100个数据源可以抽取出接近100%的餐馆电话号码,如图1-2所示。然而,对于一个不太常见的属性,如主页URL,情况就大不同了:要抽取95%的餐馆主页URL需要至少10 000个数据源。
  第三,他们使用k-coverage(数据库中出现在至少k个数据源中的实体所占的比例)来调查信息的冗余度,以使得抽取出的信息具有更高的置信度。例如,他们显示要获得90%餐馆电话号码的5-coverage需要5000个数据源(而10个数据源就足以获得93%电话号码的1-coverage),见图1-2。
image

  第四,他们(使用用户生成的对餐馆的评论)显示从长尾数据源中抽取出的信息具有很大的价值。具体地,尽管对评论信息的需求和评论信息的数量都在向尾部递减,但是评论信息的数量递减得更快,说明长尾抽取是有价值的,尽管对其需求相对较低。
  第五,如图1-3所示,他们观察到存在着大量的数据冗余(平均每个实体出现在几十个到几百个数据源中),以及同一领域的数据很好地互联在一起。这一数据冗余性和良好的互联性在大数据集成的发现数据源和实体过程中非常关键。具体地,对于几乎所有的(领域,属性)对而言,超过99%的实体存在于二分图的最大连接子图,说明即使随机选择一小组实体作为种子也足以到达领域中的大部分实体。另外,一个小的直径长度(6~8)意味着迭代算法会很快收敛。最后,他们显示即使在去掉前10个信息聚集型数据源,二分图仍然保持良好的互联性(连接超过90%的实体),表明这一互联性不仅仅依赖于主要的聚集型数据源。

image

1.2.4 案例研究:深网数据的质量

  [He et al. 2007]和[Madhavan et al. 2007]中的研究展示了深网数据的海量性、高速性,以及领域级多样性,但没有调查这些数据源中的数据质量的问题。为了弥补这一缺陷,[Li et al. 2012]实验性地研究了深网数据的真实性问题。
  1.主要问题
  这一研究集中在以下两个与1.2.1节中给出的“V”维度相关的主要问题。
  * 深网数据的质量如何?
  例如,深网数据源之间是否存在大量的冗余数据?一个领域的不同数据源中的数据是否一致?某些领域的数据质量是否优于其他领域?
  * 深网数据源的质量如何?
  例如,数据源是否高度准确?正确的数据是否被大多数数据源提供?在数据源出现不一致时,是否存在一个可以被信任的权威数据源而所有其他数据源均可以忽略?数据源是否和其他数据源共享或相互复制数据?
  2.研究方法
  回答这些问题的一种方法是在每个领域实际地进行跨所有深网数据源的大数据集成;但这是一个极具挑战的任务,还未被解决。相反,[Li et al. 2012]采用的方法是研究具有以下特性的一些领域。
  1)这些领域内的深网数据源被频繁使用,而且被认为是干净的因为错误数据会对人们的生活产生负面影响。
  2)这些领域内的实体在数据源之间被一些关键属性一致地唯一标识,这使得易于跨深网数据源链接信息。
  3)集中研究一部分较流行的数据源足够理解这些领域中用户所体验到的数据质量问题。
  [Li et al. 2012]的研究给出了两个这样的领域:股票和航班。股票用股票代号(如T表示AT&T公司,GOOG表示Google公司)可以被跨数据源一致地唯一标识;航班号(如UA 48)和出发/到达机场代码(如EWR和SFO)一般可以被用来跨数据源地唯一标识某天内的航班。他们用以下方法确定了每个领域内较流行的一组深网数据源:i)使用领域特定的词汇搜索通用搜索引擎,然后在返回的前200个结果中人工判断深网数据源;ii)选出那些使用GET方法(即查询表单的数据被编码在URL中)而不是使用Javascript的数据源。这样他们在股票领域得到55个数据源(包括流行的金融信息聚集网站如Yahoo! Finance、Google Finance和MSN Money,官方的股票交易数据源如NASDAQ,以及一些金融新闻数据源如Bloomberg和MarketWatch),在航班领域得到38个数据源(包括3个航空公司数据源、8个枢纽机场数据源,以及27个第三方数据源如Orbitz、Travelocity等)。
  在股票领域,他们从Dow Jones、NASDAQ和Russell 3000选择了1000只股票代号,在2011年7月的每个工作日用每只股票代号分别查询55个数据源。查询在每天股票市场结束一小时后提交。从不同数据源抽取出的属性被人工匹配来判断那些全局不同的属性;其中16个常见属性的值在股票市场结束后较稳定(如每日收盘价),再被进一步详细分析。他们在5个流行金融数据源用多数表决的结果为200个股票代号生成了一组标准数据。
  在航班领域,他们集中研究了从三大航空公司(联合航空、大陆航空和美国航空)的枢纽机场出发和到达的1200个航班,在2011年12月的每一天,在其原定到达时间至少一小时之后查询每个航班。从不同数据源抽取出的属性被人工匹配来判断那些全局不同的属性;其中6个常见属性被进一步详细分析。他们用相应的航空公司数据源提供的数据为100个航班生成一组标准数据。
  3.主要结果
  类似于前面的案例研究,我们按照1.2.1节中的“V”维度来归类这一研究得到的主要结果。
  尽管这一研究的目标主要集中在数据的真实性,这一研究的结果同时显示了深网数据源模式级的多样性。
  (1)多样性
  [Li et al. 2012]在所调查的深网数据源中发现相当大的模式级的多样性。例如,股票领域的55个数据源提供了不同数目的属性,属性个数最少的是3,最多的是71,总共有333个属性。人工匹配了不同数据源的属性后,他们得到了153个全局不同的属性,其中许多属性用其他属性计算得到(如52个星期的最高和最低价格)。提供这些属性的数据源数目的分布是非常偏斜的,仅有13.7%的属性(共21个)由三分之一以上的数据源所提供,而86%的属性由少于25%的数据源提供。航班领域的模式多样性较小,38个数据源共提供了43个属性,经过人工匹配后得到15个全局不同的属性。
  (2)真实性
  虽然所研究的领域内的数据被认为应该是很干净的,但数据质量并不如所期望的那样高。具体地,这些领域的数据展示了很强的不一致性。例如,在股票领域,同一数据项的不同值(允许一定值容差后)的个数最少是1,最大是13,平均是3.7;另外,超过60%的数据项的不一致值由不同数据源所提供。在航班领域,值的不一致程度低很多,同一数据项的不同值(允许一定值容差后)的个数最少是1,最大是5,平均是1.45;另外,少于40%的数据项的不一致值由不同数据源所提供。不同的原因造成观察到的数据的不一致性,包括语义歧义性、过期数据以及错误。图1-4展示了两个领域的数据项的不同值的数目的分布。Li等人表明这些不一致性不能用简单的多数表决方法来解决,表决结果的精度常常低于使用单一数据源得到的最高精度。
  另外,他们观察到深网数据源的准确度变化很大。在股票领域,数据源的平均准确度为0.86,而且只有35%的数据源的准确度超过0.9。尽管大多数权威数据源的准确度超过0.9,但是它们的覆盖率都低于0.9,意味着一个应用无法只依赖于某个单一的权威数据源而忽略所有其他数据源。在航班领域,数据源的平均准确率更低,只有0.8,29%的数据源的准确率低于0.7。这一领域中权威数据源的准确度超过0.9,但是它们的覆盖率都低于0.9。

image

  最后,[Li et al. 2012]观察到每个领域中的深网数据源间存在着复制现象。一些情况下的复制被明确说明,但其他情况下的复制是通过观察嵌入的界面和查询重定向来检测出的。有趣的是,被复制的原始数据源的准确度并不总是很高,在股票领域其变化范围是0.75~0.92,在航班领域是0.53~0.93。

1.2.5 案例研究:浅网结构化数据

  浅层网上的静态HTML页面上明显地含有大量的无结构数据,也包含大量的结构数据,体现在HTML表格(table)中,如图1-5所示的表格。[Cafarella et al. 2008b]和[Lautert et al. 2013]实验性地研究了网上这些表格的数量和结构多样性。

image

  这一工作的研究动机是浅层网通常被视为一组超链接起来的非结构化文档,因而忽略了Web文档中所包含的关系数据。例如,大多是维基百科(Wikipedia)网页含有高质量的关系数据,为几乎每个主题提供有价值的信息。通过识别这些爬取器可访问到的浅层网上的关系表,Web搜索引擎就可以为用户的关键词查询返回这类表格了。
  1.主要问题
  这些研究集中在以下两个与1.2.1节中给出的“V”维度相关的主要问题。

  • 浅层网上具有多少高质量的关系表?如何将它们和HTML表格的其他使用(如表单布局)区分开来?
      * 这些表格的异构程度如何?

  例如,表格的大小,即行和列的数目,是如何分布的?多少这样的表格具有比传统的关系表更丰富的结构(如嵌套表、列联表)?
  2.研究方法
  [Cafarella et al. 2008b]从Google爬取的几十亿个英文网页出发,使用一个HTML解析器获得网页上的所有table标签。其中只有一小部分发现的表格是高质量的关系表,他们使用以下方法将这些表格和那些非关系表的HTML标签区分开来。
  1)他们使用解析器将那些明显的非关系表格去掉,包括极小表格(少于2行或2列),嵌在HTML 表单中的表格(用于可视化用户输入域的布局),以及日历。
  2)他们在剩下的表格中选取一部分样本,然后人工标注来估计高质量关系表的比例。
  3)他们基于各式各样表级的特征训练了一个分类器来区分关系表和HTML table标签的其他用法,如页面布局和属性表(property sheet)等。接下来,他们用分类器的输出结果收集有关分布的统计数据。
  [Lautert et al. 2013]观察到Web上即使高质量的表格也是异构的,有水平、垂直和矩阵的结构,一些单元格跨多个行或列,一些单元格中有多个值,等等。他们使用下面的方法量化Web上表格的异构性。
  1)他们从Wikipedia、电子商务、新闻、大学等数据源出发爬取了一组网页,然后抽取出网页上所有的HTML表格,共访问了174?927个HTML页面,抽取出342?795个不同的HTML表格。
  2)他们使用包括页面布局、HTML和词汇方面的25个特征,开发了一个有监督的神经网络分类器将表格分到不同类别。训练数据集含有4000个Web表格。
  3.主要结果
  我们按照几个“V”维度来归类这些研究得到的主要结果。
  (1)海量性
  首先,[Cafarella et al. 2008b]从所爬取的页面中抽取出大约141亿个HTML表格。其中89.4%(或者125亿)被去掉了,因为解析器判断它们是明显的非关系表(大部分是极小表格)。在剩下的表格中,用人工在一个样本集上判断的结果推断有大约10.4%(或者1.1%的初始HTML表格)是高质量关系表。从而可以估计Web上大约有15?400个高质量的关系表格。
  其次,[Cafarella et al. 2008b]使用诸如行数、列数、大部分为NULL值的行数、非字符串数值的列数、单元格中字符串长度的平均值和标准差等为特征,训练了一个分类器来判别高质量关系表格,其查全率较高,为0.81,而查准率则较低,只有0.41。使用分类器的结果,他们得到了高质量关系表的行数和列数的分布统计数据。93%以上的这些表具有2~9列;非常少的高质量表格具有非常多的属性列。相反,高质量表的行数呈现较大的多样性,如表1-11所示。
image

  (2)多样性
  [Lautert et al. 2013]确定在Web上的高质量表格中存在着相当大的结构多样性。只有17.8%的高质量Web表格类似于传统关系数据库中的表格(每个单元格含有单个值,不跨多行或多列)。Web表格不同于RDBMS中表的两大主要原因是:i)74.9%的表格含有包含多个值(相同或不同数据类型)的单元格。ii)12.9%的表格含有跨多个行或列的单元格。

1.2.6 案例研究:抽取的知识三元组

  我们最后一个案例研究是关于使用Web规模的信息抽取技术获得的领域无关的结构化数据,即被表示为<主语,谓词,宾语>的知识三元组。在我们的航班例子里,三元组和表示Airline1航空公司的49号航班的出发和到达机场分别是EWR和SFO。[Dong et al. 2014b]实验性地研究了通过爬取大量网页并从中抽取获得的这样的知识三元组的数量和真实性。
  这一工作的起因是要完成自动构建大规模知识库的任务,即通过使用多个抽取器从每个数据源为每个数据项抽取出(可能相互冲突的)值,然后解决抽取出的三元组中存在的歧义性,最后构建一个高质量的知识库。
  1.主要问题
  这一研究集中在以下两个与1.2.1节中给出的“V”维度相关的主要问题。

  • 从Web网页上可以被抽取出的知识三元组的数目和分布特性是什么?
      例如,从网页的DOM树结构中抽取出的三元组数目和使用自然语言处理技术从非结构文本中抽取出的三元组数目。

  * 抽取出的三元组的质量以及抽取器的准确度如何?
  2.研究方法
  [Dong et al. 2014]爬取了超过10亿个Web页面,使用以下方法从4类网页内容中抽取知识三元组。
  1)他们从4类页面内容中抽取三元组:i)文本文档,通过检查短语和句子;ii)DOM树,出现在浅层网页中(如Web列表)以及深网数据源中;iii)Web表格,包含高质量关系信息,其中行表示三元组中的主语,列表示谓词,对应单元格中的值是宾语;iv)Web标注,由网站管理员使用标准的Web本体(如http://schema.org)手工创建。
  2)他们限定抽取的三元组中的主语和谓词必须已经存在于已有的知识库如Freebase [Bollacker et al. 2008]中。
  3)抽取出的知识的质量用Freebase知识库作为标准来衡量。具体地,如果一个抽取出的三元组存在于Freebase中,则为真;如果不在Freebase中,但在,则抽取出的三元组被视为假;否则其不被包含在标准结果集中。
  3.主要结果
  我们按照几个“V”维度来归类这一研究得到的主要结果。
  (1)海量性
  首先,[Dong et al. 2014b]抽取出16亿不同三元组,其中80%来自DOM树结构,19%来自文本文档。不同类型的Web页面内容抽取出的三元组重叠部分很小,如图1-6所示。

image

  其次,这些抽取到的三元组与Freebase中的4?300万个主语和4?500个谓词(3.37亿个(主语,谓词)对)有关。大部分分布(如每个主语的三元组数目)是高度偏斜的,有很长的长尾;例如,前5个实体每个具有100万个以上的三元组,而56%的实体每个只抽取出不超过10个三元组。
  (2)真实性
  在抽取出的16亿三元组中,40%(或65?000万个)三元组具有标准结果,其中2亿个被认为是真的。从而,抽取出的三元组的总体准确度仅约为30%。大部分的错误是抽取错误,但也有一小部分是由于数据源提供了错误信息造成的。
  此研究显示不同抽取器的准确度存在巨大差异。

相关文章
|
1月前
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
109 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
4月前
|
分布式计算 DataWorks 关系型数据库
MaxCompute 生态系统中的数据集成工具
【8月更文第31天】在大数据时代,数据集成对于构建高效的数据处理流水线至关重要。阿里云的 MaxCompute 是一个用于处理大规模数据集的服务平台,它提供了强大的计算能力和丰富的生态系统工具来帮助用户管理和处理数据。本文将详细介绍如何使用 DataWorks 这样的工具将 MaxCompute 整合到整个数据处理流程中,以便更有效地管理数据生命周期。
142 0
|
1月前
|
分布式计算 大数据 OLAP
AnalyticDB与大数据生态集成:Spark & Flink
【10月更文挑战第25天】在大数据时代,实时数据处理和分析变得越来越重要。AnalyticDB(ADB)是阿里云推出的一款完全托管的实时数据仓库服务,支持PB级数据的实时分析。为了充分发挥AnalyticDB的潜力,将其与大数据处理工具如Apache Spark和Apache Flink集成是非常必要的。本文将从我个人的角度出发,分享如何将AnalyticDB与Spark和Flink集成,构建端到端的大数据处理流水线,实现数据的实时分析和处理。
62 1
|
4月前
|
消息中间件 分布式计算 大数据
RabbitMQ与大数据平台的集成
【8月更文第28天】在现代的大数据处理架构中,消息队列作为数据传输的关键组件扮演着重要的角色。RabbitMQ 是一个开源的消息代理软件,它支持多种消息协议,能够为分布式系统提供可靠的消息传递服务。本篇文章将探讨如何使用 RabbitMQ 与 Hadoop 和 Spark 进行集成,以实现高效的数据处理和分析。
45 1
|
4月前
|
分布式计算 大数据 数据处理
【大数据管理新纪元】EMR Delta Lake 与 DLF 深度集成:解锁企业级数据湖的无限潜能!
【8月更文挑战第26天】随着大数据技术的发展,Apache Spark已成为处理大规模数据集的首选工具。亚马逊的EMR服务简化了Spark集群的搭建和运行流程。结合使用Delta Lake(提供ACID事务保证和数据版本控制)与DLF(加强数据访问控制及管理),可以显著提升数据湖的可靠性和性能。本文通过一个电商公司的具体案例展示了如何在EMR上部署集成Delta Lake和DLF的环境,以及这一集成方案带来的几大优势:增强的可靠性、细粒度访问控制、性能优化以及易于管理的特性。这为数据工程师提供了一个高效且灵活的数据湖平台,简化了数据湖的建设和维护工作。
62 1
|
4月前
|
机器学习/深度学习 设计模式 人工智能
面向对象方法在AIGC和大数据集成项目中的应用
【8月更文第12天】随着人工智能生成内容(AIGC)和大数据技术的快速发展,企业面临着前所未有的挑战和机遇。AIGC技术能够自动产生高质量的内容,而大数据技术则能提供海量数据的支持,两者的结合为企业提供了强大的竞争优势。然而,要充分利用这些技术,就需要构建一个既能处理大规模数据又能高效集成机器学习模型的集成框架。面向对象编程(OOP)以其封装性、继承性和多态性等特点,在构建这样的复杂系统中扮演着至关重要的角色。
70 3
|
5月前
|
存储 JSON DataWorks
DataWorks产品使用合集之如何通过数据集成将API接口产生的数据集成到DataWorks
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
分布式计算 DataWorks 调度
DataWorks产品使用合集之在使用MaxCompute进行数据集成同步到OSS时,出现表名和OSS文件名不一致且多了后缀,该如何处理
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
数据采集 分布式计算 大数据
MaxCompute产品使用合集之数据集成中进行数据抽取时,是否可以定义使用和源数据库一样的字符集进行抽取
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
6月前
|
分布式计算 Hadoop Java
优化大数据处理:Java与Hadoop生态系统集成
优化大数据处理:Java与Hadoop生态系统集成

热门文章

最新文章