互联网信息搜索服务管理规定

第一条 为规范互联网信息搜索服务,促进互联网信息搜索行业健康有序发展,保护公民、法人和其他组织的合法权益,维护国家安全和公共利益,根据《全国人民代表大会常务委员会关于加强网络信息保护的决定》和《国务院关于授权国家互联网信息办公室负责互联网信息内容管理工作的通知》,制定本规定。

第二条 在中华人民共和国境内从事互联网信息搜索服务,适用本规定。

本规定所称互联网信息搜索服务,是指运用计算机技术从互联网上搜集、处理各类信息供用户检索的服务。

第三条 国家互联网信息办公室负责全国互联网信息搜索服务的监督管理执法工作。地方互联网信息办公室依据职责负责本行政区域内互联网信息搜索服务的监督管理执法工作。

第四条 互联网信息搜索服务行业组织应当建立健全行业自律制度和行业准则,指导互联网信息搜索服务提供者建立健全服务规范,督促互联网信息搜索服务提供者依法提供服务、接受社会监督,提高互联网信息搜索服务从业人员的职业素养。

第五条 互联网信息搜索服务提供者应当取得法律法规规定的相关资质。

第六条 互联网信息搜索服务提供者应当落实主体责任,建立健全信息审核、公共信息实时巡查、应急处置及个人信息保护等信息安全管理制度,具有安全可控的防范措施,为有关部门依法履行职责提供必要的技术支持。

第七条 互联网信息搜索服务提供者不得以链接、摘要、快照、联想词、相关搜索、相关推荐等形式提供含有法律法规禁止的信息内容。

第八条 互联网信息搜索服务提供者提供服务过程中发现搜索结果明显含有法律法规禁止内容的信息、网站及应用,应当停止提供相关搜索结果,保存有关记录,并及时向国家或者地方互联网信息办公室报告。

第九条 互联网信息搜索服务提供者及其从业人员,不得通过断开相关链接或者提供含有虚假信息的搜索结果等手段,牟取不正当利益。

第十条 互联网信息搜索服务提供者应当提供客观、公正、权威的搜索结果,不得损害国家利益、公共利益,以及公民、法人和其他组织的合法权益。

第十一条 互联网信息搜索服务提供者提供付费搜索信息服务,应当依法查验客户有关资质,明确付费搜索信息页面比例上限,醒目区分自然搜索结果与付费搜索信息,对付费搜索信息逐条加注显著标识。

互联网信息搜索服务提供者提供商业广告信息服务,应当遵守相关法律法规。

第十二条 互联网信息搜索服务提供者应当建立健全公众投诉、举报和用户权益保护制度,在显著位置公布投诉、举报方式,主动接受公众监督,及时处理公众投诉、举报,依法承担对用户权益造成损害的赔偿责任。

第十三条 本规定自2016年8月1日起施行。

奇虎360回应网信办规定:积极拥护搜索服务新规

6月25日,国家互联网信息办公室发布《互联网信息搜素服务管理规定》。国家互联网信息办公室有关负责人表示,出台《规定》旨在规范互联网信息搜索服务,促进互联网信息搜索行业健康有序发展,保护公民、法人和其他组织的合法权益,维护国家安全和公共利益。奇虎360公司表示,对《规定》的出台表示积极拥护,将在此前工作的基础上,切实对照《规定》加强管理,为网民提供客观、公正、权威的搜索结果。

奇虎360表示,自2012年360搜索服务上线以来,始终严格按照相关法律法规和全行业最严的自律规范,履行自身社会责任。2016年5月3日,为积极响应国家相关要求, 360搜索即在行业内率先作出放弃一切商业医疗推广业务的决定,受到网民广泛支持。目前,鉴于医疗广告良莠不齐,不仅搜索业务,360整个商业推广平台均已将医疗广告100%下线。奇虎360还表示,网民可通过360搜索举报平台http://info.so.com/web_report.html对不良信息进行投诉,360不仅将及时处理,用户还可获得360搜索提供的奖励。

奇虎360表示,作为网民最主要的上网入口,搜索引擎是信息安全的第一道屏障。360搜索全面吸收了360的“安全”基因,一直秉承“干净、安全、可信赖”的产品理念,肩负着重大的互联网信息安全责任。360搜索通过共享360网盾拦截技术和安全大数据资源,平均每天为网民拦截1亿多次欺诈、钓鱼等恶意网站。360搜索一直明确杜绝虚假医疗广告、垃圾广告、欺诈钓鱼网站、干预排名等,以最严格的标准审核一切商业推广信息,将用户体验优先于商业利益之上。在行业内率先推出推广欺诈全赔计划,用户因360推广信息遭遇网络诈骗后,符合条件者将获得全额赔付。360搜索还先后推出“网站名片”、“诚信电商”、“红番茄点评”等功能,帮助网民辨别虚假网站,同时也借此发动网民和全社会力量,不断完善对网站的信用评价大数据体系。

奇虎360还表示,呼吁所有互联网企业加强行业自律,不仅是搜索引擎,一切互联网从业者都必须总结和推广“最佳实践或做法”,积极落实主体责任和企业社会责任,履行“用户至上”价值观,彻底解决影响行业健康发展的问题和矛盾,以保障广大网民的切身利益。

Facebook推出搜索服务挑战谷歌

过去几周,一些Facebook用户注意到了iOS应用的小改动。当发布状态更新时,除了添加照片、圈出好友、选择表情,或分享位置之外,他们还看到了另一个图标。这一图标将转向“添加链接”页面。

通过这一页面,用户将看到来自整个互联网、关于特定关键词的相关搜索结果。随后,用户可以方便快捷地与好友分享搜索结果。

Facebook一名发言人表示:“我们正在尝试一种向Facebook内容和评论添加链接的新方法。”换句话说,这是Facebook的自主搜索引擎。而这可能将成为谷歌的噩梦。

目前,如果用户希望分享链接,那么需要在应用之间进行切换,并进行复制/粘贴操作。尽管这并不复杂,但用户仍需要多次点击,并花费较长的时间。更重要的是,用户花费的大部分时间都发生在Facebook服务之外,并且主要是在谷歌搜索引擎中。

这是Facebook希望解决的一个问题。Facebook并不希望用户在其服务之外花太多时间。尤其考虑到,在移动广告市场,谷歌是Facebook的主要竞争对手。这就像是将一大笔收入拱手让人。

IHS Technology高级分析师埃勒尼·马鲁利(Eleni Marouli)表示:“增加应用内搜索功能将确保移动用户的活动向Facebook平台内集中。如果应用能提供更多功能,那么Facebook就能给广告主带来更多的用户参与。”

因此近期,Facebook致力于提供一站式服务。自去年秋季以来,Facebook计划在网站上直接提供来自主要发行商的内容,而不仅仅是链接。这一服务最快将于本月内推出。根据《华尔街日报》的报道,在这样的合作中,BuzzFeed和《纽约时报》等媒体将获得内容产生的大部分收入,而Facebook将帮助用户节约8秒钟的链接打开时间,这些时间将可以用于展示广告。

确保移动用户留在应用内对Facebook而言非常重要。近期的财报显示,上一季度,Facebook的73%广告收入来自移动设备,近90%的用户通过移动设备访问Facebook。根据IHS的数据,Facebook目前在全球移动显示广告市场的营收份额为46.8%,远远高于排名第二谷歌的23.6%。

在搜索广告方面,谷歌仍处于领先。不过有分析师认为,这样的局面或许很快就将被打破。目前,全球移动广告市场正在增长,但Facebook主导了大部分的增长。

业内人士认为,“添加链接”功能将给Facebook和用户带来双赢。用户可以在自己的Facebook消息流内安全地浏览,而Facebook则可以从谷歌手中抢走搜索广告收入。

搜索服务网站付费信息须明确标注 否则将被举报

(央视财经讯)国家网信办发布《互联网信息搜索服务管理规定》。《规定》要求,提供付费搜索信息服务应当依法查验客户有关资质,明确付费搜索信息页面比例上限,醒目区分自然搜索结果与付费搜索信息,对付费搜索信息应逐条加注显著标识。

国家互联网信息办公室有关负责人介绍,搜索引擎在对网上信息进行整合、方便用户查阅方面发挥了重要作用,但同时也存在不少问题。部分搜索结果含有谣言、淫秽、色情、暴力、凶杀、恐怖等违法信息;部分搜索结果有失客观公正,违反行业道德和规范,误导和影响公众判断。这些问题破坏了网络生态,扰乱了互联网信息传播秩序,侵害了公众利益,广大网民深恶痛绝,呼吁尽快出台信息搜索服务的有关管理规定。

《规定》明确,国家互联网信息办公室负责全国互联网信息搜索服务的监督管理执法工作,地方互联网信息办公室依据职责负责本行政区域内互联网信息搜索服务的监督管理执法工作。

《规定》要求,互联网信息搜索服务提供者应当落实主体责任,建立健全信息审核、公共信息实时巡查等信息安全管理制度,不得以链接、摘要、联想词等形式提供含有法律法规禁止的信息内容;提供付费搜索信息服务应当依法查验客户有关资质,明确付费搜索信息页面比例上限,醒目区分自然搜索结果与付费搜索信息,对付费搜索信息逐条加注显著标识;不得通过断开相关链接等手段,牟取不正当利益。

国家互联网信息办公室有关负责人强调,互联网信息搜索服务提供者应当切实承担企业社会责任,依照相关法律法规加强自身管理,为网民提供客观、公正、权威的搜索结果。同时,企业要提高互联网信息搜索服务从业人员的职业素养,建立健全投诉、举报受理处置和用户权益保护制度,主动接受公众监督。国家互联网信息办公室欢迎广大网民继续对网上相关违法和不良信息进行监督举报,共同促进网络空间更加清朗。互联网违法和不良信息举报中心网址:www.12377.cn,举报电话:12377,举报邮箱:jubao@12377.cn。

明略讲堂 基于RDF的知识图谱管理 一个厉害的搜索服务优化方案

「明略讲堂」

「明略讲堂」又开讲啦!今天我们来讲讲知识图谱。我们在公安、金融、工业领域拿知识图谱这个技术做了不少事儿,前不久我们还发布了国内首个知识图谱数据库“蜂巢”。在知识图谱领域里,知识图谱背后的搜索快不快,决定了好用程度,那么怎么快起来?

快来看下面的分享~

本文转自AI大事件(ID:ai-dashijian)

编辑|陈思

2010 年 Google 利用知识图谱优化了其搜索服务以来,知识图谱得到了迅速发展。无论是工业界还是学术界,都出现了各种各样的知识库。为了灵活共享知识图谱,使其具有一定可读性,同时保证机器也能够方便理解知识,事实上,大部分的开放的知识图谱,都是以 RDF 形式对外开放。

那么什么是 RDF?RDF 有什么优点?我们整理了来自明略数据的 SCOPA 技术顾问邵蓥侠老师在 AI 前线微信群做过的的分享:基于 RDF 的知识图谱管理,希望可以为你解答这些问题。

全文约6600字,阅读时间大约需要13分钟。

大家好,我是来自明略数据的邵蓥侠。今天我跟大家分享的主题是基于 RDF 的知识图谱管理。本次分享主要包括三部分内容,分别是 RDF 的基础概念、RDF 的查询技术和 RDF 的存储技术。

RDF 的基础概念

在具体介绍 RDF 相关的内容之间,我们先简单介绍下知识图谱与 RDF 之间的关系。从 2010 年 Google 利用知识图谱优化了其搜索服务以来,知识图谱得到了迅速发展。无论是工业界还是学术界,都出现了各种各样的知识库。

上图展示了多个典型的代表,例如 Yago,freebase,DBpedia,musicBrainz,pubMend 等。这些知识图谱为各类智能应用带来了大量结构化知识,像 Google 的 knowledge graph 包含 700 亿个事实 (facts)。

为了灵活共享上述知识图谱,使其具有一定的可读性,同时保证机器也能够方便理解知识,事实上,大部分的开放的知识图谱,都是以 RDF 形式对外开放。

以 DBpedia 为例,其官方文档里有这么一段话,“DBpedia 以 RDF 作为一个灵活的数据模型用来表示抽取的信息,并发布到网上”。下图展示了 DBPedia 知识库中以 RDF 表示的知识样例。

RDF 全称为 Resource Deion Framework,即资源描述框架。它最初是在语义网背景下设计出来,以三元组形式描述资源的一种数据模型。简单地,可以把 RDF 数据模型与关系数据库中的 Entity-Relationship 模型,或者面向对象语言中的类图等概念进行类比,都是对数据的一种抽象描述。

右图描绘出了 RDF 在整个语义网络技术栈中所处的位置,从中可以看出,RDF 主要负责数据交换,并通过 RDFS 能让机器理解网络中的数据真正的含义,而不仅仅是简单的字符串。

接下来介绍 RDF 相关的基础概念,也包括为什么是 RDF,RDF 的结构和基于 RDF 的知识表示等三部分。

什么是 RDF?

首先,从 RDF 的命名我们可以清楚的理解 RDF 的内涵。

  • R 代表 Resource,即资源,任何可以被唯一标识的对象,都可以称为资源。例如,网页、地点、人、事件、餐馆等;

  • D 代表 Deion,也就是说对资源的描述,包括资源属性的描述和资源间关系的描述;

  • F 则是指 Framework,即 RDF 为资源描述提供了描述的语言和模型。

举个具体的例子,为了让机器知道“哈利波特的作者是 JK 罗琳”这个事实,RDF 则提供了一套语言和模型来描述哈利波特是一本书,JK 罗琳是一个人,两种之间是被创作关系等。综上,RDF 就是一套为描述资源属性和关系提供语法和模型的框架。

RDF 结构

RDF 为描述资源提供的基本元素有 IRI,字面值和空节点 (blank node)。IRI 就是一个符合特定语法的 UINICODE 字符串,如 2019/20190426A/F019685 , 跟 URL 的形式比较类似。其实 URL 属于 IRI 的一种。

字面值可以理解为像时间、人名、数字等常量的表示,由字符串和表示数据类型的 IRI 构成。例如数字 1 的字面值可以表示为”1″^^xs:integer,其中 xs:integer 是表示整型数据类型的 IRI。

空节点是指没有 IRI 的匿名节点。一般是 RDF 内部使用的一个特殊结构,不可被引用。

RDF 中对资源的一个描述称为陈述 (statement),一般用 Subject-Predicate-Object(SPO) 三元组 (triple) 表示。

其中,subject 的取值可以为 IRI,blank node; predicate 取值为 IRI,object 的取值则是 IRI,blank node 和 predicate。

例如,“a person named Eric Miller”在 RDF 中基本形式为 (xs1:me, xs2:fullName, “Eric Miller”)。

一个 RDF 数据集由一组相关的三元组的组成。由于这个三元组集合可以抽象为一张 graph,因此也称为 RDF graph。

右图展示了一个简单的 RDF graph,记录了一个名叫 Bob 的人的出生年月、他的朋友和他喜欢的名画信息。对应的 RDF 三元组位于下方。

之前我们也看到了一些三元组的各种表示形式,下面具体介绍 RDF 几种重要的序列化表示形式,这些形式一来可以用于数据交换,二来也保证了可读性。

首先介绍 RDF 基于 XML 的表述语法,RDF/XML 语法是目前唯一个符合 W3C 标准的语法。

右图是一个简单的例子。为了避免数据中频繁出现冗余的字符串,一般可以定义一个简写的前缀表示形式,如这里的 xmlns:cd 表示 http://www.recshop.fake/cd#。

接下来每一个资源对应一个 < rdf:Deion > 标签,其中 rdf:about 给出了该资源的 IRI,也是三元组中的 subject。

< rdf:Deion > 标签里的其他子标签分别对应着 predicate 和 object. XML 形式紧凑,从图模型的角度分析,它是以顶点为基本单元进行 RDF graph 的描述。

另一种,流行且更常用的格式是 turtle 格式,它是 RDF 1.1 中的标准语法。Turtle 中直接以三元组形式进行表示,三元组中的 subject,predicate,object 之间用空格隔开,用”.”表示一个三元组的结束。

但是,为了对于同一个 subject 的三元组进行简化表示,允许 subject 的省略,同时三元组的结尾用”;”表示省略的 subject 同上一个三元组。

上一页中以 XML 表示的例子可以简化为如右图所示的 turtle 形式。相比与 XML 语法,省略了大量标签语言,使得文件内容更加简洁。

另外,还有两种表示形式,分别是 N-Triples 和 N-Quads。N-Triples 是 Turtle 的简化版,去掉了 Turtle 中的高级语法,一行就是一个 triple,没有简写的格式。因此,能够处理的 Turtle 的 parser 同样能够接受 N-Triples 的数据格式。

而 N-Quads 则是在三元组的基础上增加了一个维度,成为四元组。新增加的维度表示 graph name,即元组所属的 RDF graph 的名称,这就能够进一步区分 SPO,有利于进行数据融合和管理。

RDF 知识库构建

有了上述不同表示形式,那么接下来就是如何将文本数据或者是现实世界中的知识表示成 RDF 数据。这就需要 RDF 字典,即一般所说的数据的 schema。

例如,用 RDF 描述一本书,RDF 字典就需要定义一本书需要包含作者、书名、页数、出版时间、语言类型等。RDF 字典定义了数据建模的元数据项,这些元数据项主要包括两种类型 class 和 property。

Class 是指对象实例的集合,可以理解为面向对象编程里的 class;Property 还分为两种子类型:一个是表示 class 的属性 (attribute),另一个是表示多个 class 之间的关系 (relationship)。

另外,RDF 字典的定义自身也是一个 RDF graph。这也是说明 RDF 是自描述的数据模型,是一种 schema-free 的数据模型。

这张图清楚的展示了 class,attribute 和 relationship 三者之间的关系。第一层中的元素是 class,如 RegisteredOrganisation 和 Addrees;第二层则是 class 对应的实例,而实例之间的 site property 即为 relationship,地址实例 http://example.com/site/1234 的 fullAddress property 则是属性 (attribute) 类的 property. 简单的理解,一般情况下 attribute 类型的 property 的 object 是字面值;而 relationship 类型的 property 的 object 也是一个 IRI。

有了完整的 schema,用户可以方便的将现实中的知识映射成 RDF graph. 通过复用 RDF schema 有利于数据的开放共享,同时避免重复劳动。目前为止已经有许多定义好的 RDF 字典,不过英文的居多,例如 FOAF,schema.org 等。这个2019/20190426A/F019710 网站专门汇总了互联网上公开的 RDF 字典。

从去年开始,国内也开始关注这块内容的标准化,出现了 cnschema。Cnschema 主要针对 schema.org 进行翻译,同时结合中文特点进行定制和扩充,形成可复用的符合中文事实的知识图谱的数据字典。 通过复用 RDF 字典可以大大降低知识图谱构建的成本,同时也有利于形成数据的标准化。

当然,在现有的 RDF 字典无法满足我们的实际需求的时候,可以结合 RDF schema 和 OWL 两种语言进行字典的自定义。下图给出了一个样例,我们自定义了一个 PublicService 类。

RDF 的查询技术

目前,我们简单地介绍了 RDF 的基本概念、表示方法以及构建思路。接下来将介绍如何对构建好的 RDF 进行查询。本部分主要介绍 SPARQL 语言以及一些用户友好的查询思路,比如使用自然语言查询。

SPARQL 是针对 RDF 数据进行结构化查询的语言,类似于关系数据模型上的 SQL 语句,不同的是 SPARQL 查询中以 Triple Pattern 为基础构造查询条件,而不是针对行列的限制。自 2008 年 1 月起,SPARQL 也成为了 W3C 的标准。SPARQL 的提出一定程度上简化了 RDF 数据的访问,也为 RDF 的管理提供了一个统一的入口。

SPARQL 中查询类语句主要包括四种,分别是 SELECT,DESCRIBE,CONSTRUCT,AKS。

  • SELECT 是从 RDF 中选择出满足条件的资源或者属性;

  • CONSTRUCT 则是根据条件获取满足条件的 Triple 并以此生成一个新的 RDF 数据集;

  • DESCRIBE 则是获取用户输入的资源的所有属性描述;

  • ASK 则是 SELECT 的优化版本,它只检查是否存在满足条件的资源或者属性,但不需要全部找出。

另外,在构造查询的条件时,类似 SQL,可以使用常见的关键词对操作进行限制,比如 FILTER,OPTIONAL,LIMIT,ORDER BY 等。

这里我们展示了 SPARQL 查询的一个样例,“找出所有实体的 legalName”。

首先,与 RDF 序列化格式类似,为了简化书写,我们可以定义 IRI 的前缀,然后再书写具体的查询语句。

SPARQL 中查询的变量用“?<字符串>”的形式表示。

SELECT 关键词表示语句类型,其后跟着的事具体需要查询的变量,

WHERE 语句中则是具体的查询条件。

在 SPARQL 中,查询条件由 Triple pattern 定义。Triple Pattern 的书写格式类似 RDF 的 N-Triple 的格式,把未知的 SPO 用变量替代,其他元素即为 IRI,字面值和空节点。

接下来,我们来看看 SPARQL 查询的逻辑模型。

由前面关于 RDF 的介绍可以知道,RDF 数据集是一个 RDF Graph,即一个带标签的有向图。

WHERE 条件语句中的 Triple pattern 也对应了一个含有变量信息的 RDF graph,那么 SPARQL 查询问题就转化为了一个图模式匹配问题。

这里展示了一个具体的例子。左图是用 SPARQL 语句表示的“查询 card:i 认识的人的主页”,右图则是对应的一个模式图。

图模式匹配的算法根据不同的数据物理存储模型,具体的解决思路有两种。第一种是以图模型为基础的执行,就直接利用图操作解决图模式匹配问题;第二种则是以关系代数为基础的执行,利用 join 操作解决图模式匹配问题。具体的 RDF 存储思路再后续章节中介绍。

下面我们再来看看 SPARQL 的一些不足。

虽然 SPARQL 提供了一种结构化的查询接口,看似能够像 SQL 语句一样简洁,为 RDF 数据的管理带来真正灵活方便的接口。

然而,现实是残酷的。由于 RDF 是一种 schema-free 的数据组织方式,一个公开的 RDF 数据集涉及的数据字典往往规模庞大,命名复杂。

例如,Freebase 中就包含至少 7000 种关系。这直接提升了 SPARQL 的书写难度,是因为 SPARQL 在执行过程中,需要精确匹配这些字典和 IRI。

这里也有个例子,“查询 Godfather 这部电影的导演的其他作品”,左图是用户习惯书写的格式,而右图是在 dbpedia 上系统能够正确识别的查询。

两者虽然结构相似,但是使用的 IRI 的表述十分不同。实际要熟练快速的编写 SPARQL 语句,不仅要了解其语法,而且要对处理的 RDF 中使用的数据字典足够清楚。

为了解决这个问题,提升 SPARQL 的易用性,现在有不少研究工作期望提出用户友好的查询。让用户以更加简洁清晰的方式表达查询,系统自动的将其转化为标准的 SPARQL。这里举三个例子。

第一个是类 SPARQL 的查询。类似上一页 PPT 中图片所示,用户以 SPARQL 形式书写一个使用非标准数据字典的查询,系统通过匹配模型,自动的将相关表述映射到标准的数据字典上,这就避免了记忆大量数据字典的难题。

第二个工作则是基于 Example 的查询。很多时候,当查询 RDF 的知识图谱时,用户已经拥有几个预期的答案,想找到更加完整的答案集合。基于 Example 的查询则是通过收集用户预期的答案和不断的迭代最终推测出用户真正的查询,从而把其他满足条件的结果返回给用户。

第三个则是基于知识图谱问答系统常用的交互接口之一,即用户直接以自然语言形式输入查询条件,系统通过自然语言理解技术将非结构化的查询转化为 SPARQL 查询。上述三个工作都是对现有 RDF 查询技术的探索,期望能够找到更加用户友好的方式去使用 RDF 数据。

RDF 的存储技术

最后跟大家分享下,为了保证 RDF 的查询效率,如何设计相关的存储方案。

RDF 的存储方案主要有两大类:其一是基于 RDBMS 的存储方案,典型的系统有 Bhyper,Graphium RDF;另一个则是原生 (native) 的存储方案,根据 RDF 的数据访问特点而专门设计的存储方法。

第二类方案进一步可以分为以图数据模型为基础的存储方案和自定义数据存储格式的方案。前者的代表系统有 Trinity.RDF,Virtuoso.RDF;后者有 RDF3x,Hexastore,Jena TDB。

经典的基于 RDBMS 的存储方案其发展过程可以分为两个阶段:在早期,人们把 RDF 中的 Triples 当做一张完整的只有 SPO 三列的大关系表,并直接存储于像 MySQL,Postgresql 等 RDBMS 系统。

此法的优点是元组数据更新快,数据库 schema 简单,但不足是无法高效支持 join 操作,使得复杂的查询性能不佳。

后来,有研究人员将 RDF 中的 Triple 根据其 Predicate 值分类,将 predicate 一样的数据存储于同一个关系表,称为属性表。

此设计方案,在给定 predicate 值时,查询 subject 和 object 十分高效,但是数据库的 Schema 难以维护,数据库表的数目与 predicate 的种类成线性增长。

2008 年,Weiss 在前人的基础上,对上述方法进一步优化,主要是通过建立索引的方式来加速不同查询的效率。

作者根据 RDF 三元组的限制,对 SPO 的排列组合进行枚举,建立了 6 个索引,同时为每个索引中存储部分元组的统计信息加速查找。

此法的优点是 6 个不同的索引使得不同的查询模式可以选在不同的查询策略进行优化,缺点是直接利用 RDBMS 中的索引机制失去了针对 RDF 数据访问特性的细粒度优化的机会。

针对这些问题,Weikum 在 08 年提出了基于原生的数据存储格式的 RDF 管理系统,RDF3x。

作者根据 RISC 架构的设计思想,重新设计 RDF 管理系统,并开发了多个针对 RDF 的优化技巧,使得 RDF3x 成为当时单机性能最好的 RDF 管理系统。

RDF3x 沿用了传统数据库的查询优化思路,对用户的查询先通过优化器找到一个合适的执行计划,具体的 join 的顺序,然后再执行查询获得结果。

另外,RDF3x 采用了精心设计的多种索引结构来减少外存的 IO 操作,提升查询性能。

首先,RDF3x 将 RDF 中的一个 Triple 视为基础元素,把它作为一行数据进行存储。

其次,为了降低存储空间,提高访问效率,将 RDF 中的字符串统一映射为数字 ID,形成字典表。

最后,设计了 15 个压缩的聚集 B+-tree 索引。其中,6 个 SPO 排列组合的索引,支持完整的三元组的查找;6 个 2 维度的索引,支持部分元组信息和统计信息的快速查找,以及 3 个 1 维度的索引。Triple 在索引中以字典序进行管理,利用 merged join 可以进一步减少 IO 操作。

此图展示了 RDF3x 中对三元组的存储样例。一个原始的 RDF 数据集转化了一张字典表和一个 Triple 表。

此图展示了 RDF3x 中的 15 个索引 (左侧绿色的三角形)。每一个都是对一个特定模型的进行索引的压缩的 B+ 树。另外,为了实现数据集的更新,利用差分的方式对索引进行更新。

最后,介绍一个以图模型为基础的进行管理的分布式 RDF 存储系统,Trinity.RDF。

此系统是 MSRA 基于其内部的图数据库 Trinity 开发的一个分布式 RDF 存储引擎。

它把 RDF 作为带标签的有向图利用图划分技术分布式地存储于内存云中,具体的管理方式可以参考 Trinity 的技术文档。

在执行 SPARQL 查询,为了避免 join 操作,利用图的节点扩展的操作进行图模式匹配。

本系统主要通过减少中间结果规模及降低通信量来保证系统的查询效率。

右图展示了该系统中具体的分布式查询流程,当用户提交查询时,首先通过 String 服务器,将查询涉及的 IRI 映射为数字 ID,然后结合 RDF 的划分情况,利用代价模型,对 SPARQL 中的查询模式图进行合理切分,生成分布式的执行计划,交给 Trinity 的 worker 进行分布式的查询。

本次分享主要介绍了 RDF 在管理知识图谱方面的基本概念和技术。RDF 是目前开发知识图谱的常用序列化形式;SPARQL 作为 RDF 的标准查询语言,对于用户而言仍然不够十分友好,需要探索更加简洁方便的查询方式;针对 RDF 的存储,基本思路有基于 RDBMS 和基于 native 等两种存储方案。每一种方式都有各自的优缺点,需要根据实际情况进行选择。

问答环节

问:想问一下邵老师,现在开源的 RDF 存储数据库和 SPARQL 查询引擎都有哪些?有什么可以推荐的吗?

答:开源的单机 RDF 数据库推荐使用 Virtuoso.RDF 和 Jena,分布式的话,推荐北大 zou lei 老师团队开发的分布式 RDF 存储系统。

问:感谢分享,使用自然语言进行友好查询的优化方法同样适用于 neo4j 吗?

答:同样适用于 neo4j,但是 neo4j 的 cypher 查询语言没有 SPARQL 那么标准。对于自然语言转化出来的结构化信息到 cypher 的转换的方法需要重新设计。NLU 这块的工作是相同的。

问:RDF 现在存储的数据库通过今天的讲座听来是比较有限的,除了刚提到的还有其他的数据库么?

答:RDF 数据库其实很多,但是多数确实是学术界的产物。公开的成熟的不像 RDBMS 那么多。目前推荐尝试使用的是 virtuoso。

问:索引的问题,索引占据的空间是原数据的数倍,索引的查询有没有可能使用 ElasticSearch 而不是自己搭建 native 的系统?

答:RDF3x 从研究成果来看,通过压缩以后,索引空间与实际数据相当。使用 ES 肯定是一种方式,现在有集群资源的情况下,通过优化 ES 也可以获得不错的查询性能。

问:RDF 的数据库系统的数据灌入感觉是一个巨大的工程,这方面有什么解决方案没?

答: 数据灌入确实是个问题,目前我了解的并没有特别好的通用的方法。

问:明略采用 RDF 的 entity 和 edge 的数量级是多少?有一些问题:为什么不考虑类似 neo4j,OrientDB,Titan 这类的图库,而要采用 SparQL,是因为数据量很大?

答:为了更好的支持智能化应用,在明略关于 RDF 的存储管理是处于探索阶段。目前我们实际的 SCOPA 系统是采用了自研的蜂巢知识图谱数据库,并对外提供的是 native 的 API。

问:感觉 rdf 存储不如图数据库,那么用 rdf 的理由是因为通用,为了能更好的做进一步的处理与挖掘么?

答:对于行业领域,在没有复用数据字典的情况下,要取开发一个全新的 rdf 数据集确实代价比较高。采用 rdf 的好处是开放共享,有标准的访问接口,进而能够支持像推理和挖掘分析这样的应用。

问:中文的非结构化 Web 数据抽取成知识图谱相比于英语,达到同样的质量水平,是否需要更加复杂的算法设计或更大量级的数据 ?

答:结合我个人的实践体验来说,关键在于积累。中文 NLP 的积累比英文弱很多,从开源的组件和数据集就可以发现。开源的中文 RDF 数据几乎为 0,那就很难有复用或者扩充的机会。像英文的知识图谱也不是从 0 开始,RDF 中的 RDF Schema 是基于 OWL 扩充,同时开源的 RDF 数据集,如 dbpedia,在抽取的时候都会依赖 wordnet 这样的 ontology. 我个人的观点还是,积累上,导致现在想做一个不错的知识图谱成本太高。

问:“对于自然语言转化出来的结构化信息到 cypher 的转换的方法需要重新设计”,这个能举个例子?或者再详细解释一下?

答:这个我想表达的意思是虽然 NLU 的输出是一样的,但是转化为 cpyher 和 SPARQL,是两种不同的形式。因此在转化过程中,需要根据具体的语言表达特性进行特定的转化。目前,我个人是没看到比较好的通用的转化方法。

作者介绍

邵蓥侠

明略数据 SCOPA 技术顾问。北京大学博士后,主要研究方向包括大规模图计算优化、图挖掘应用以及复杂网络分析等,并在相关领域发表学术论文 10 余篇,包括 SIGMOD,VLDB,TKDE 等国际一流学术会议和期刊。曾获 2014 年 Google 博士奖学金、微软学者等称号。目前作为明略数据 SCOPA 技术顾问,主要参与图挖掘、图分析、知识工程等相关工作。

点击阅读原文,了解更多明略数据知识图谱数据库相关信息。

北京管局约谈三家搜索服务提供商?要求切断骚扰电话软件等信息来源

近日,北京市通信管理局针对互联网上发现的骚扰电话软件销售推广信息的问题,集中约谈了百度、奇虎360、搜狗等搜索服务提供商。

约谈中,北京管局指出,搜索服务提供商要认真履行社会责任,严格落实工业和信息化部等十三部门综合整治骚扰电话专项行动的相关要求,从源头上切断骚扰电话相关软件、设备的信息来源。针对网络上依然存在的“喵池”、“改号APP”等骚扰电话软件、设备的变体词、关联词组等问题要进行全面清理排查,建立动态监测和屏蔽机制,对骚扰电话软件和设备信息要发现一起屏蔽一起。三家搜索服务提供商表示,将严格贯彻落实工业和信息化部及北京管局的要求,深化骚扰电话源头治理工作,全面排查存在的问题,立即进行整改。

北京管局将以首善标准持续深入推进综合整治骚扰电话专项行动工作。一是加强源头打击,通过管理和技术手段全面清理各类骚扰软件和设备的传播。二是充分利用科技创新手段,持续优化骚扰电话精准拦截能力,建立企业间骚扰电话黑名单共享机制,及时共享相关信息。三是督促基础电信企业加强通信资源管控。严格规范语音专线管理,严查利用透传技术虚拟主叫号码的违规行为,对未通过鉴权的呼叫一律拦截。为首都营造良好的通信环境,以优异的成绩迎接祖国七十周年华诞。

来源:北京市通信管理局

互联网信息搜索服务管理规定

映日荷SEO优化提醒不知道最近大家是否有感受到你的网站排名异常,收录异常,可能这一秒你在首页,刷新了一下就变成了2页或者3页。或者直接就没了收录,排名都没有了。或者是抓取的描述不是你的网站描述,而是网页里的某些内容。

标题

网站的页面标题是经常会被一些客户堆切了很多的关键词,而网页标题恰恰是搜索引擎十分看重的一块地方,堆切了很多相关或者不相关的关键词,很容易就给搜索引擎的算法判断成这个网站存在作弊行为,最后导致搜索引擎封杀站点。标题针对关键词的写法上,建议一个网页对应1-2个关键词即可,网页的正文内容要与网页标题的主题高度吻合网页标题切忌频繁更改。一个不稳定的网站,百度是不会喜欢的,在建站之初,就应该把网站的各个细节都考虑好,一旦建立,便不再轻易更改。

采集

搜索引擎是喜新厌旧的,如果一个网站的内容都是在网络上高度重复的,那么排名绝对不会好,采集的网站百度会收,但是收录后会被慢慢的 k掉,而且很少会给改过自新的机会,哪怕之后天天更新原创文章,也无济于事。但是这并不意味着不可以采集,我们可以针对采集来的文章做一些更改,比如替换内容、更改标题等。

内部链接.

很多的SEO工程师都知道,一个网站中有某些网页的权重特别高,喜欢在权重高的网页上堆切大量的关键词链接。不可否认,在权重高的网站页面上加重点的关键词链接对目标关键词的搜索引擎排名提升会起到帮助,但是在权重高的网页堆积了过量的关键词链接,也会被搜索引擎处罚。建议对于高权重的网页放置重点目标关键词链接,不要超过10个,而且这些链接放置的位置也是相当重要

keywords和deion

一些刚接触SEO的朋友,很喜欢在keywords和deion标签的内容里,堆积一大堆的相关关键词。于keywords和deion标签在搜索引擎优化中的作用,基本上被主流的搜索引擎算法降低为0或者非常低。在keywords和deion上堆积关键词的优化方法,只会起到负面的搜索引擎优化反应

域名空间

域名一定要选择简短好记,能够让人记忆深刻的,比如baidu众里寻他千百度。空间的话,根据我个人站点,最近的一些变化,我建议大家都选择国内备案空间,因为备案的稳定,而且今年年末百度也根据国家政策,在打压这一块,根据自身以及朋友站点,我总结出,只要你是香港空间,美国空间,那种免备案的,都会或多或少的出现异常。比方收录减少,没有了收录,排名异常,今天首页,过两天第三页,可能还会有100开外的。

文章内容质量

可能有的人为了省事,直接去选择买外链,这样的我是不建议的。本人很多原创手写文章,都会有很稳定的收录。而且不会有收录问题。空间也刚刚由香港的搬迁到了国内。所以现在关键词济南SEO 直接上了首页位置。

在网站设计过程中,很多网站都特别重视首页的内链建设,这些项目包括网站的面包削导航、Logo、图片、文章、友链等等,合理的锚文本布局是完善网站内部结构的重要方法,很多网站在首页的内链做的相对较好,唯一存在争议的是关键词的堆积密度,因为很多时候都是用关键词做锚文本的,有的时候刻意制造锚文本,如果被搜索引擎判断为关键词堆积,反而适得其反的作用,总之,在这方面需要特别在意。

再说网站内页的内链建设,在网站建设过程中,内页内链建设分为两个步骤,一个网站设计人员根据网站的需求,将网站分为主页和内页,通常网站设计人员在这方面拥有丰富的经验,他们会知道如何让内页和主页之间进行友好的沟通,并且尽量不让搜索引擎迷路

而内页的内链建设还有一个步骤就是网站的内容更新,这些内容更新包括产品、图片、资讯等,尤其是资讯内容更新,如何设计内链呢?常规来说,一般不超过三个,当然太多了容易被认为是关键词堆积。内部链接必须保证URL的唯一性。特别是动态网站静态化处理过的,只能保留一个链接。我们应该写入robots规则将动态的url屏蔽掉,否则搜索引擎无法判断那个是正确的链接页面,造成网站内容重复。

随着网站内容的增多,如何有条理的将重要的内容、次要的内容有机的连为一体,其实是一件很繁琐的事情,比如说网站导航最初可能只是一些简单的内容,当某一产品、某一内容获得较高关注度的时候,是不是需要特别做一个链接,起到推波助澜的作用。

当网站内容足够多的时候,如何将这些文章归类,相关文章是一个不错的方式,使用相关文章功能,具有这几点好处,相关文章因为内容相近,因此会增加页面主要关键词的出现频率,对于关键词权重的提升有一些帮助。同时,相关文章还可以提升用户的阅读体验,让用户阅读到更加详细的内容。在内容页面里,可以将与该内容页相关的文章列表加入到页面尾部,引导搜索引擎根据这些链接来抓取相关页面进行索引,为了方便搜索引擎抓取,相关文章的列表不要放在JS文件里,而是加在页面内容里。

在内页,有些站仅仅体现的是本页的内容以及上一篇文章或下一篇文章,这是完全不够的。内页的链接建设也十分重要,这关系着访客以及蜘蛛能不能够顺利转移,如果不能顺利转移或者转来转去又回到起点,那么你的网站就存在死胡同或者圆圈了,这样的话,访客和蜘蛛就只能靠岸或搁浅。

成都映日荷网站管家SEO流程系统隶属于映日荷软件旗下子公司,至今映日荷核心团队研发人员“超过50人”,成都映日荷网站管家SEO流程系统现已为全国合作伙伴及终端用户提供SEO精细化流程管理服务。

映日荷产品:整合CMS建站系统/站群营销系统/关键词计费系统/手机报价系统/选词系统/及下单系统等……

映日荷至今在全国服务过的终端用户超过10000家;全国各地区合作伙伴超过500家;成为了许多众多中小企业网络信息营销的领航员!!!!

Airbnb个性化搜索服务架构

导语:业务快速增长给搜索带来什么样的挑战?针对类似场景如何设计通用的平台?本文详细讲述Airbnb大型搜索服务的演进之路。

去年,Airbnb到了需要可扩展、分布式存储系统的时候了。例如,搜索个性化数据超过了单机的承载能力。当我们提升了个性化服务的纵向扩展能力的时候,意识到其他服务也有同样的需求,因此决定设计一个通用平台,简化其他服务需要做的事情。

除了通常的请求/响应模式,其他服务有不同的需求,例如,从数据源(例如,MySQL数据库)做周期性批量同步,引入新的数据源(例如,新的搜索特性),从数据流中消费增量更新(我们的场景中是Kafka),或者提供数据分析能力,并且为网站流量提供低延迟的数据服务。随着公司的持续增长,我们有很多应用积累了越来越多的数据。如果我们能挖掘出有用的信息并且反馈给应用,那么这些数据可以为我们的产品提供巨大价值。

摘要

让我们从个性化搜索开始。这需要保留我们的用户行为历史。要求能记录实时用户行为,并且能立即获得记录,以优化个性化搜索结果(并且改善其他产品)。提供其他应用能用的数据快照(例如分析或者验证)。需要周期性的聚合并且截断历史数据,批量导入一批特征(离线计算)到系统中。

这些需求贯穿公司很多应用。因此我们决定设计一个通用存储平台,以支持这些需求,并帮助其他服务负责人聚焦他们特殊的业务逻辑。我们计划在这个系统中满足下面这些需求:

  1. 网站流量提供低延迟操作(毫秒级别)
  2. 实时数据流提供增量更新
  3. 便捷高效的数据批量操作
  4. 保证公司增长的数据和流量可扩展
  5. 维护成本小

注意,我们将“批量操作”定义为快照和压缩完整存储库的操作,用新快照替换现有快照以进行服务,将完整的新信号合并到存储库中,用新集合替换现有信号数据以及完整数据集上的任何其他操作Nebula是一个平台,我们这个存储上满足了所有的这些需求。

什么是Nebula?

Nebula是一个无模式版本化的数据存储服务,提供实时随机数据访问和离线批量数据管理。它包含一个支持增量数据(最近一段时间的更新)的动态数据存储的独立服务,和一个支持批量操作的静态数据存储的快照数据存储。我们选择DynamoDB作为动态数据存储(主要原因是它有很低的读延迟,使用AWS的维护成本低),和HFileService(Airbnb内部使用的可扩展的静态存储,支持分区和本地硬盘到HFile格式的预处理)存储静态的快照。

随机数据访问的抽象存储

Nebula为底层物理存储提供了统一的API。API为应用提供了通用K-V存储API,增量和静态数据内部合并,这样,应用不需要为实时数据和批量数据分别部署。所以,它能灵活的迁移到不同的物理存储,上层应用不需要修改API。

Nebula使用版本化列式存储,类似于BigTable和HBase。版本化列式存储比起原始K-V存储,能让服务负责人更便捷地定义他们的数据模型。必要的时候,版本能解决冲突和跟踪数据变更时间。应用每行和列能存多少个版本没有任何限制。

Nebula支持<行,列,版本>级别的原子操作。并发写同样的<行,列>会有不同的版本,这样数据能合理的存储。每列都有自己的版本,并且所有的写直接追加到各自的列上(通过版本存储)。用户随机访问需要通过给定<行,列>获取一个或者多个版本的数据。获取多列或者多行的多次请求可以合并到一个单独的多请求中。

使用个性化数据的一个例子,数据模型如下:

每行表示一个用户的数据,每列表示一个用户交互类型(又叫用户事件),比如前面提到的搜索,每个版本是用户事件发生时候的时间戳。在产品中,我们有很多用户事件,每个事件列积累了大量的不同时间戳的事件。

为了支持一个搜索请求,搜索服务查找给定用户对应的事件数据,用这些个性化数据在排序模型中决定向用户展示的有序列表。因为这是搜索请求路径,所以我们有很严格的延迟和可用性要求。

数据能通过增量数据流(包含个人用户事件)以单元格为单位和离线管道批量(压缩历史数据或者按列引导/合并/替换数据)的方式被更新。

内置批量数据处理

Nebula使用离线管道为每个仓库的增量数据做快照,与前面的快照合并,然后使用新的快照提供服务。这些任务跟在线服务分开执行,对网站流量的影响非常小。

管道可以根据要求进行高级配置。例如,每个应用可以定义他们自己的策略,如何合并新老数据(例如,新数据覆盖老数据,使用版本聚合,丢弃老数据等等),如何压缩历史数据(保留N个版本,删除某段时间之前的数据等等),如何调度管道,等等。

Nebula给用户提供定义良好的接口,用于他们定制数据并且自动加载到系统中。用户可以将他们的数据放在公共的地方,修改一些Nebula配置,然后管道将选择并且合并数据到系统中以供使用。

应用负责人能在数据快照上,将他们的特殊需求定制的逻辑放到管道上。他们的逻辑将在最新的快照数据上执行,所以,这是一个处理逻辑的有效方式。

在个性化搜索场景中,我们在下列情况下使用管道:

  1. 定期生成快照,合并增量数据和静态数据
  2. 按列进行压缩和过滤过期事件,保证数据大小可控
  3. 离线特征计算以创建新的特征,批量导入新特征到存储中
  4. 定制验证用户事件的逻辑,合理的状态检查

所有的个性化数据都版本化,不管什么时候发现数据问题,Nebula可以回滚到以前的好快照,并在版本(时间戳)之前丢弃任何不良数据。回滚逻辑根据应用决定,但是Nebula的批量接口让回滚逻辑实现很简单。

架构

这是整个系统的架构(如下)和设计选型。

一个Nebula读请求查询两个数据源。增量数据存储仅仅包含最新的数据,快照存储包含完整的数据。两个存储都支持读查询,但是只有动态存储接收写请求。快照存储的更新通过切换底层快照。数据存储通过Zookeeper协作。

动态数据存储DynamoDB

我们选择DynamoDB是因为低延迟的要求,但是也可以根据其他要求使用其他的物理存储(例如HBase)替换。作为Nebula的底层存储,物理存储只需要支持主键和排序二级索引。尽管底层实现不同上层接口却是一致的,对于系统上的任何应用(和用户)来说,替换物理存储是透明的。

我们不准备去设计另外的物理存储,使用DynamoDB作为底层的存储能让我们非常快速的组建一个系统。

数据输入流被写入动态存储中;它允许随机更新,并且支持很高的QPS。DynamoDB的读延迟很低,所以能很好的满足我们平均10毫秒的延迟要求。我们做了一个优化,为了保证DynamoDB表的大小容易管理,每天将数据分区到新的表。所以,我们的每个表仅仅占据一部分DynamoDB的分区以保证有高的QPS。

批量数据存储HFileService

Nebula根据动态更新合并起来的实时查看的最新快照存储在HFileService集群中。

HFileService以低延迟高吞吐量从本地磁盘中提供静态的HFiles(快照格式)。而且,数据加载过程对读请求几乎没有影响,所以离线数据合并操作不影响对数据的实时访问。

HFileService通过动态分片机制对数据分区,所以水平扩展能力依赖数据的总大小。尽管是静态数据,复制策略非常简单并且能随着流量的增长去调整。

使用离线管道做快照、压缩和定制逻辑

Nebula支持在线随机数据访问和批量操作。批量操作不影响在线访问。下图描述Nebula的离线架构:

定期从增量存储导出批量更新数据到分布式文件系统(Amazon S3)。数据导出之后,启动一个离线Spark任务将批量更新和历史数据合并。我们经常有其他的离线产生数据的情况,例如机器学习特征,需要批量上传到系统中。合并阶段经常有这样的情况,新快照通过合并批量更新、历史数据和定制离线数据进行创建。我们在合并过程中添加合理的检查,避免坏数据进入到我们的系统。

最新的快照存在S3上,等待下一轮合并。它也会被保存到我们的历史数据存储中。贯穿整个导出-合并-加载过程,实时存储一直保留这些导出到S3的增量数据,直到新的快照生成成功并且保存到历史数据存储中才会删除。这保证了读请求总通过实时和历史存储能获取到完整数据。

S3上的完整快照被用于其他的离线数据分析。

流式更新输出

除了对快照的随机访问和批量处理,Nebula还支持流式更新,以保证应用及时感知数据的更新。通过DynamoDB的流API来支持流式更新。一个单独的组件使用Kinesis消费者中的流,并将其发布到特定的Kafka流中,因此任何感兴趣的服务都可以订阅它。

其他场景:搜索索引基础设施

说完了Nebula,接下来讲讲我们如何使用Nebula重构Airbnb的搜索索引。我们先聊一下为何要重构。

由于Airbnb大部分使用Rails / MySQL作为前端,因此搜索索引会监听(并且仍然)对数据库表进行更改,维护当前搜索索引文档的缓存,并使用新文档更新搜索实例(如果有任何更改)。由于使用轮询加载器加载,以及从数据一致性的数据源定期同步,因此性能不确定。新的搜索机器可以通过从缓存中缓慢流式传输来引导其索引。

下面是我们决定使用这个系统的原因:

  1. 端到端的低延迟操作(平均时间小于1秒)
  2. 能够通过批量任务离线处理并且合并消费的特征到索引中
  3. 能够使用实时特征
  4. 离线生成索引(能够共享索引到离线分片)
  5. 快速回滚有问题的分片
  6. 快速扩展新的搜索实例
  7. 审核搜索索引文档的更新
  8. 索引数据增长的时候可扩展

Nebula系统上面的这些特性很完美的解决了我们所有的需求。版本化列式存储意味着我们能审核搜索文档,支持批量任务意味着我们能离线生成索引(以及合并列表特征)并且直接部署到搜索中。因为这些索引基于快照构建和部署,出现坏的索引数据我们能快速的回滚。新生成的索引被用于新的搜索实例快速启动(仅仅通过下载索引)。

上图展示了基于Nebula的搜索架构。数据快照作为离线数据合并的一部分每天生成。索引构建器的作业对此快照进行操作以构建分片索引,然后像普通的二进制部署一样定期部署搜索。这个系统使用了Nebula的特性,只需要实现定制逻辑关联搜索索引。

展望

我们在Nebula之上构建了很多服务,包括刚刚提到的搜索索引管道,个性化基础设施,Airbnb的价格服务数据仓库。为每个应用提供了很多TB的数据,平均延迟在10毫秒。我们想鼓励其他的团队使用Nebula构建更多的应用。

我们也计划把我们的系统跟我们的数仓深度结合,即,存储历史快照到Hive,共享更多数据流消费逻辑,等等。为分析功能提高数据的可用性和一致性,让系统管理和操作更便捷,这样对开发者来说才能更容易构建他们的应用。

鸣谢

很多人的付出才把这个系统做起来。我们想感谢Alex Guziel为这个项目所做的突出贡献,感谢Jun He, Liyin Tang, Jingwei Lu等人的慷慨相助,还有很多人通过搜索,应用基础设施,数据基础设施,产品基础设施和其他团队所有以各种方式帮助的人。

原文地址:

https://medium.com/airbnb-engineering/nebula-as-a-storage-platform-to-build-airbnbs-search-backends-ecc577b05f06

本文作者 Charles He, Soumyadip Banerjee, Tao Tao, Krishna Puttaswamy,邓启明翻译。转载本文请注明出处,欢迎更多小伙伴加入翻译及投稿文章的行列,详情请戳公众号菜单「联系我们」。

前沿 我们需要什么样的互联网信息搜索服务

来源: 新华网

日期:2016年6月27日

摘要:信息搜索服务提供者要放下傲慢,倾听网民的呼声,建立健全公众投诉、举报和用户权益保护制度,主动接受公众监督,及时处理公众投诉、举报,依法承担对用户权益造成损害的赔偿责任。

在信息时代,搜索引擎成为我们获取信息乃至知识的重要手段,在正确的时间搜索到正确的信息正变得越来越重要。如何正确地利用信息搜索服务,与使用者的知识、技能、判断甚至阅历相关,也取决于搜索服务提供者及整个行业环境。

6月25日,国家互联网信息办公室针对当前搜索引擎服务中存在的违法违纪、违反道德准则、误导和影响公众判断等现象,发布《互联网信息搜索服务管理规定》(以下简称《规定》),抓住了令社会公众深恶痛绝的突出问题,制定了对症下药的具体措施,引起了广泛关注和好评。可以预见,《规定》将对整治信息搜索服务乱象、规范行业健康可持续发展发挥重要作用。《规定》从守法、自律、担当、监督等多个方面,对行业企业提出了明确的要求,对“我们需要什么样的互联网信息搜索服务”进行了解答。

不违法,严守法律底线。《规定》针对九类典型的违反法律法规禁止信息内容,明确提出互联网信息搜索服务提供者不得以链接、摘要、快照、联想词、相关搜索、相关推荐等形式提供含有法律法规禁止的信息内容。客观地讲,在直接提供搜索结果上,国内的互联网信息搜索服务提供者还是遵循我国法律底线的,但是在快照、联想词、相关搜索等方面存在的一些问题有待进一步完善。在提供服务过程中,发现搜索结果明显含有法律法规禁止内容的信息、网站及应用时,服务提供者在及时、主动停止提供相关搜索结果、保存有关记录并向有关部门通报等方面做的还不够。

不作恶,加强企业自律。通过信息自由有序地流通造福大众,是很多搜索领域的技术引领者们最初的梦想。但随着技术的日益发展,信息搜索服务正演化成为一种有利可图的信息公权力,如果不加以约束,就有可能导致这一权力滥用,有的服务提供者就有可能成为信息不对称的制造者。我们需要相关法律法规为信息搜索服务提供者划定红线,但更需要技术创新者加强自律,不要走到最初梦想的反面。如果在灰色利益甚至不正当利益面前把持不住,技术创新者事业发展的帆船就将不可避免地走向迷失的边缘。

敢斗恶,勇于担当责任。在很多创新领域,往往是聪明人引领创新,骗子利用创新坑蒙拐骗,而普通大众则会由于自身的善良、轻信和信息缺失成为待宰的羔羊。正所谓“能力大、责任就大”,在新技术应用领域,技术引领者必须勇于承担责任,抵御恶势力对自身创新领地的侵袭。在涉及国家安全、社会稳定等大是大非面前更要立场坚定,自觉成为国家、人民长远利益的“同心圆”,积极主动发挥自身作用。

不傲慢,接受社会监督。网民是互联网企业的力量来源,再伟大的公司,都离不开广大网民的参与、支持和理解。企业的服务被广大网民所接受,一方面是对自身技术、产品的肯定,另一方面也是值得感恩的荣幸。信息搜索服务提供者要放下傲慢,倾听网民的呼声,建立健全公众投诉、举报和用户权益保护制度,主动接受公众监督,及时处理公众投诉、举报,依法承担对用户权益造成损害的赔偿责任。

《规定》的出台,开启了互联网信息搜索服务新的发展阶段。我们有理由相信,社会大众将用上更加放心、安全的搜索服务,能够获得更加真实、客观、公正的搜索结果,能够有效屏蔽无用信息的干扰,能够有效避免有害信息的侵蚀;我们可以安心地让自己的孩子自由搜索,可以让善良、单纯甚至有点“迷糊”的普通大众有一个安全的搜索之旅。聪明的技术创新者们,这就是社会大众需要的信息搜索服务,你们明明可以靠才华和创新吃饭,请不要迷失在邪性的苟且之中。

(作者为国家信息中心政务外网发展规划处处长)

丁道师:对网信办 搜索服务13条 新规的3点看法

在各方的期待下,搜索引擎服务的相关法律规定比预想的更早出台。6月25日上午,国家互联网信息办公室6月25日发布《互联网信息搜索服务管理规定》。国家互联网信息办公室有关负责人表示,出台《规定》旨在规范互联网信息搜索服务,促进互联网信息搜索行业健康有序发展,保护公民、法人和其他组织的合法权益,维护国家安全和公共利益。

《新规》虽然在周六早上发布,但还是引发了业界极大的关注。事实上,不管是中国网民还是全球其他地区的网民,乃至各大科研机构、组织,通过搜索引擎查找资料都是获取信息的重要来源渠道,搜索引擎是互联网最重要的服务之一。如此重要的战略级服务,近几年高速发展,取得了巨大的成果,然而行业在高速发展的时候,相关企业却忽略了从技术、机制等方面对其平台的索引内容进行把控的责任,甚至为了谋取利益人为的进行搜索结果排序,进而为虚假信息提供传播的温床,极大的对网民获取信息带来了误解和困扰。

笔者注意到《规定》总共有13条,其中特别提到:互联网信息搜索服务提供者应当落实主体责任,建立健全信息审核、公共信息实时巡查等信息安全管理制度,不得以链接、摘要、联想词等形式提供含有法律法规禁止的信息内容;提供付费搜索信息服务应当依法查验客户有关资质,明确付费搜索信息页面比例上限,醒目区分自然搜索结果与付费搜索信息,对付费搜索信息逐条加注显著标识;不得通过断开