Google|谷歌知识图谱系统发展内幕:从MetaWeb到Cerebro 直到放弃


Google|谷歌知识图谱系统发展内幕:从MetaWeb到Cerebro 直到放弃文章插图
前谷歌前开发者Dgraph创始人Manish Rai Jain撰写了关于谷歌内部在知识图谱领域的探索和发展 。 他以一个开发和技术前驱者论述了"为什么谷歌需要一个知识图谱系统" , 并且知识图谱在谷歌的探索尝试的历程 , 虽然由于种种原因他们的项目最后被放弃了 , 但是整个发展探索的历程是一个非常棒的知识图谱技术学习的材料和项目管理经典案例 , 所以虫虫引用过来和一起学习 , “它山之石 , 可以攻玉”希望能对大家有所帮助 。
背景谷歌知识图谱系统的创建源于2010年 , 并于2012年在搜索引擎中提供了改功能 。 为了实现该功能 , 需要构建一个图服务系统 , 不仅可以处理知识图数据中的复杂关系 , 还要连接交互OneBoxes , 处理和访问所有结构化数据 。 该图服务系统需要能遍历数据 , 具有足够高的吞吐量和足够低的延迟 , 可以支持巨量的网络搜索查询 。 当时业界还没有可用的系统或数据库能够满足这三个需求 , 所以谷歌内部就有图谱系统的探索 。
Metaweb的故事谷歌在2010年收购了Metaweb 。 Metaweb使用多种技术构建了一个高质量的知识图谱 , 包括抓取和解析维基百科 , 以及使用类似维基百科的多来源数据通过Freebas网站提供服务 。 所有这些功能都由他们内部构建的图形数据库驱动的 , 该数据库名为Graphd , 是一个图形守护程序 。 谷歌已经在GitHub上开源(地址为 github:/google/graphd) 。
Graphd有一些非常典型的属性 。 像一般守护进程一样 , 它在一台服务器上运行 , 所有数据都放在内存中 。 整个Freebase网站都都基于Graphd 。
谷歌基于一般商品级别的硬件和分布式软件构建了搜索帝国 。 单个服务器数据库永远满足不了其巨大的蜘蛛爬虫 , 索引和搜索服务 。 为此谷歌构建了SSTable , 进化到了Bigtable , 它可以横向扩展到数百或数千台服务器 , 协同运行PB级的数据 。 还构建了Borg(K8s的前驱)分配机器 , 使用Stubby(gRPC前驱)进行通信 , 通过Borg的名称服务解析IP地址(BNS , K8s组件之一) , 数据存储在Google文件系统GFS上(Hadoop FS) 。 基于分布式架构 , 在谷歌体系中"进程会死 , 机器会崩 , 服务永不down" 。
【Google|谷歌知识图谱系统发展内幕:从MetaWeb到Cerebro 直到放弃】所以收购后Graphd必须面对这样架构文化 , 服务于在单个服务器上运行的数据库的想法与Google架构大相径庭 。 而且Graphd需要至少64GB的内存才能运行 , 而当时谷歌大多数服务器的最大内存为32GB 。 为了满足Graphd的需要 , 谷歌就要额外采购 。
基于上面提到了问题 , 重构Graphd以分布式方式运行的被提上议题 。 但是图系统不同于一般的键值数据库 , 需要大量的连接和遍历操作 , 需要以特定方式构建软件 。
一个选择是使用名为MindMeld(IIRC)的项目 。 利用该项目可以通过网络可以更快地访问另一台服务器的内存 。 据推测 , 这会比正常的RPC更快 , 足以快速复制内存数据库所需的虚拟复制直接进行异机内存访问 。
实际上采纳的是另一个方案构建一个真正的分布式图服务系统 。 不仅可以取代Graphd , 还可以为将来的所有知识工作服务 。 该项目被命名为Dgraph , 分布式图 , graph守护进程 。
Cerebro:一个知识引擎无意中构建了图服务系统 。 Manish当时在谷歌的任务是改进搜索引擎 。 他和Metaweb的工程师DH(建立了Cubed) , 基于Cubed和Squared打算重建一个系统用于改进搜索引擎 。
首先是一个搜索项目 , 它提供了一种方法 , 可以实现高度准确地理解哪些词可以合并起来 。 比如 , 对于[tom hanks movies]这样的短语时 , 它可以判定 [tom]和[hanks]属于一个词 。 同样 , 从[san francisco weather] , [san]和[francisco]应该合并到一起 。 对于人类而言 , 这是显而易见的 。
第二部分是理解语法 。 当查询[books by french authors]时 , 机器可以其解析为[books]和[french authors](即法国人写的书) 。 但它也可以解释为[french books]和[authors](即任何作者的法语书籍) 。 系统使用了斯坦福的Part-Of-Speech(POS)标记器来更好地理解语法并构建一棵树 。
第三部分是理解实体 。[french]可能意味着许多事情 。 它可以是国家(地区) , 国籍(指法国人) , 菜肴(指食物)或语言 。 可以使用上一部分获取的单词或短语可以对到的实体列表 。
第四部分是了解实体之间的关系 。 现在系统可以将单词关联到短语 , 短语应该执行的顺序 , 即语法 , 以及它们可以对应的实体 , 需要一种方法来找到这些实体之间的关系以创建机器解释 。 例如 , 一个查询说[books by french authors]和POS的结果[french authors]的[books] 。 有多个[french]的实体 , 也有多个[authors]的实体 , 算法需要确定它们的连接方式 。 例如可以通过出生地连接起来:即出生在法国的作者(但可能是英文写作);或者是法国人作者;或者说写法语(但可能与法国 , 国家无关)的作者;或者只喜欢法国美食的作家 。