本文由微信大众号 「AI 前哨」原创（ID：ai-front），未经授权不得转载。

当我向他人解说咱们在 Dgraph 实验室所做的东西时，常常会有人问我是不是曾经在 Facebook 作业过，或许咱们正在做的东西是否遭到 Facebook 的启示。许多人都知道 Facebook 在社交图服务方面做了许多作业，由于他们宣布了多篇关于怎样构建图基础设施的文章。

在说到谷歌时，一般仅限于常识图谱服务，但却没有人说到过其内部基础设施是怎样回事。其实谷歌有专门用于供给常识图谱的体系。现实上，咱们(在谷歌的时分)在图服务体系方面也做了许多的作业。早在 2010 年，我就冒险进行了两次测验，看看能够做出些什么东西。

谷歌需求构建一个图服务体系，不只能够处理常识图数据中的杂乱联系，还能够处理一切能够拜访结构化数据的 OneBox。服务体系需求遍历现实数据，并具有足够高的吞吐量和足够低的推迟，以应对许多的 Web 查找。但没有现成可用的体系或数据库能够一起满意这三个要求。

我现已答复了为什么谷歌需求构建一个图服务体系，在本文的其余部分，我将带你回忆咱们构建图服务体系的整个旅程。

我是怎样知道这些的?我先毛遂自荐一下，2006 年到 2013 年期间，我在谷歌作业。先是实习生，然后是 Web 查找基础设施的软件工程师。2010 年，谷歌收买了 Metaweb，那时我的团队刚刚推出了 Caffeine。我想做一些异乎寻常的东西，所以开端与 Metaweb 的人(在旧金山)协作。我的方针是弄清楚怎样运用常识图谱来改善 Web 查找。

Metaweb 的故事之前现已说过，谷歌在 2010 年收买了 Metaweb。Metaweb 现已运用多种技能构建了一个高质量的常识图谱，包含爬取和解析维基百科。一切这些都是由他们内部构建的一个图数据库驱动的，这个数据库叫作 Graphd——一个图看护程序(现在现已发布在 GitHub 上：https://github.com/google/graphd)。

Graphd 有一些十分典型的特点。和看护程序相同，它运转在单台服务器上，一切数据都保存在内存中。Freebase 网站让 Graphd 不堪重负，在被收买之后，谷歌面对的一个应战是怎样持续运营 Freebase。

谷歌在商用硬件和分布式软件范畴建立了一个帝国。单台服务器数据库永久无法支撑与查找相关的爬取、索引和服务作业负载。谷歌先是推出了 SSTable，然后是 Bigtable，能够横向扩展到数百乃至数千台机器，为数 PB 数据供给处理才干。他们运用 Borg(K8s 的前身)来装备机器，运用 Stubby(gRPC 的前身)进行通讯，经过 Borg 称号服务解析 IP 地址(BNS，已集成到 K8s 中)，并将数据存储在谷歌文件体系(GFS)上。进程或许会逝世，机器或许会溃散，但体系会一向作业。

Graphd 其时就处在这样的环境中。运用单个数据库为运转在单台服务器上的网站供给服务，这种主意与谷歌(包含我自己)的风格方枘圆凿。特别是，Graphd 需求 64GB 或更多的内存才干运转。假如你以为这样的内存要求很搞笑，那么请注意，那是在 2010 年。其时大多数谷歌服务器的***内存为 32GB，所以谷歌有必要购买装备足够多内存的特别机器来支撑 Graphd。

替换 Graphd有关替换或重写 Graphd 并让它支撑分布式的主意开端冒了出来，但这关于图数据库来说是一件十分困难的作业。它们不像键值数据库那样，能够将一大块数据移动到另一台服务器上，在查询时供给键就能够了。图数据库许诺的是高效的衔接和遍历，需求以特定的办法来完成。

其间的一个主意是运用一个叫作 MindMeld(IIRC)的项目。这个项目许诺若经过网络硬件能够更快地拜访另一台服务器内存。这应该比正常的 RPC 要快，快到足以伪仿制内存数据库所需的直接内存拜访。但这个主意并没有走得太远。

另一个主意(实践上是一个项目)是构建一个真实的分布式图服务体系，不只能够代替 Graphd，还能够为将来的一切常识供给服务。它便是 Dgraph——一种分布式图看护程序。

Dgraph 实验室和开源项目 Dgraph 的命名便是从谷歌的这个项目开端的。

当我在本文中说到 Dgraph 时，指的是谷歌的内部项目，而不是咱们后来构建的开源项目。

Cerebro 的故事：一个常识引擎虽然我知道 Dgraph 的方针是要代替 Graphd，但我的方针却是做出一些东西来改善 Web 查找。我在 Metaweb 找到了一位研讨工程师 DH，Cubed(https://blog.dgraph.io/refs/freebase-cubed.pdf)便是他开发的。

谷歌纽约办公室的一些工程师开发了 Squared(https://en.wikipedia.org/wiki/Google_Squared)。DH 则更进一步，开发了 Cubed。虽然 Squared 没有什么用，但 Cubed 却令人形象深入。我开端想怎样也在谷歌开发一个这样的东西，究竟谷歌现已有一些现成的东西能够运用。

首要是一个查找项目，它供给了一种办法，可用于高度精确地分辩哪些单词应该合在一起。例如，关于 [tom hanks movies] 这样的短语，它会告知你 [tom] 和 [hanks] 应该合在一起。相同，在 [san francisco weather] 这个短语中，[san] 和 [francisco] 应该合在一起。关于人类而言，这些都是清楚明了的作业，但对机器来说可不是这么回事。

第二个是了解语法。在查询 [books by french authors] 时，机器能够将其解说成由 [french authors] 所写的 [books](即法国作家所著的书本)。但它也能够被解说成 [authors] 所写的 [french books](即作家所著的法语书本)。我运用了斯坦福的词性(POS)符号器来更好地了解语法，并构建了语法树。

第三个是了解实体。[french] 能够指许多东西，它能够是指国家(区域)、国籍(法国人)、菜肴(指食物)或言语。我运用了另一个项目来获取单词或短语所对应的实体列表。

第四个是了解实体之间的联系。现在我现已知道怎样将单词关联成短语、短语的履行次序，即语法，以及它们对应的实体，我还需求一种办法来找到这些实体之间的联系，以便创立机器解说。例如，关于查询 [books by french authors]，POS 会告知咱们，它指的是 [french authors] 所著的 [books]。咱们有一些 [french] 的实体和 [authors] 的实体，算法需求确认怎样衔接它们。它们能够经过出生地衔接在一起，即出生在法国的作家(但或许运用英文写作)，或许是法国藉的作家，或许说法语或运用法语写作(但或许与法国无关)的作家，或许仅仅喜爱法国美食的作家。

依据查找索引的图体系为了确认某些实体是否是衔接在一起的，以及是怎样衔接在一起的，我需求一个图体系。常识图谱数据运用了三元组的格局，即每个现实经过三个部分来表明，主语(实体)、谓词(联系)和宾语(另一个实体)。查询有必要是 [S P]→[O]、[P O]→[S]，有时分是 [S O]→[P]。

我运用了谷歌的查找索引体系，为每个三元组分配了一个 docid，并构建了三个索引，分别为 S、P 和 O。别的，索引答应顺便附件，所以我附上了每个实体的类型信息。

我构建了这个图服务体系，知道它有衔接深度问题(下面会解说)，而且不适用于杂乱的图查询。现实上，当 Metaweb 团队的某个人要求我开放体系拜访时，被我回绝了。

现在，为了确认联系，我会履行一些查询，看看会发生哪些成果。[french] 和 [author] 会发生什么成果吗?挑选这些成果，并看看它们怎样与 [books] 衔接在一起。这样会生成多个机器解说。例如，当你查询 [tom hanks movies] 时，它会生成 [movies directed by tom hanks]、[movies starring tom hanks]、[movies produced by tom hanks] 这样的解说，并主动回绝像 [movies named tom hanks] 这样的解说。

关于每一个解说，它将生成一个成果列表——图中的有用实体——而且还将回来实体的类型(存在于附件中)。这个功用十分强壮，由于在了解了成果的类型后，就能够进行过滤、排序或进一步扩展。关于电影类型的成果，你能够依照发行年份、电影的长度(短片、长片)、言语、获奖状况等对电影进行排序。

这个项目看起来很智能，咱们(DH 作为这个项意图常识图谱专家)将它叫作 Cerebro，与《X 战警》中呈现的设备同名。

Cerebro 常常会展现出一些人们开端没有查找过的十分风趣的现实。例如，假如你查找 [us presidents]，Cerebro 知道总统是人类，而人类会有身高，你就能够依照身高对总统进行排序，然后会告知你 Abraham Lincoln 是美国身高***的总统。还能够经过国籍来过滤查找成果。在这个比如中，它显现的是美国和英国，由于美国有一位英国人总统——George Washington。(免责声明：这个成果是依据其时的 KG 状况，所以不保证这些成果的正确性。)

蓝色链接与常识图谱Cerebro 其实是有或许真实了解用户的查询的。假如图中有数据，就能够为查询生成机器解说和成果列表，并依据对成果的了解进跋涉一步的探究。如上所述，在知道了正在处理的是电影、人类或书本之后，就能够启用特定的过滤和排序功用。还能够遍历图的边来显现衔接数据，从 [us presidents] 到 [schools they went to]，或许 [children they fathered]。DH 在另一个叫作 Parallax(https://vimeo.com/1513562)的项目中演示了从一个成果列表跳转到另一个成果列表的才干。

Cerebro 令人形象深入，Metaweb 的领导层也很支撑它。即使是图服务部分也供给了较好的功用和功用。我把它叫作常识引擎(查找引擎的晋级)，但谷歌管理层(包含我的司理)对此并不感爱好。后来，有人告知我应该去找谁交流这件事，所以我才有时机向查找方面的一位高档担任人展现它。

但得到的回应并不是我所期望的那样。这位担任人向我展现了运用谷歌查找 [books by french authors] 的成果，其间显现了十个蓝色链接，并坚持说谷歌能够做相同的作业。此外，他们不期望网站的流量被抢走，由于那样的话这些网站的一切者必定会气愤。

假如你以为他是对的，那么请想一下：谷歌查找其实并不能真实了解用户查找的是什么。它只会在正确的相对方位查找正确的关键字，并对页面进行排名。虽然它是一个极点杂乱的体系，但依然不能真实了解查找或查找成果意味着什么。***，用户还需求自己检查成果，并从中解析和提取他们需求的信息，并进跋涉一步的查找，然后将完好的成果组合在一起。

例如，关于 [books by french authors] 这个查找，用户首要需求对成果列表进行组合，而这些成果或许不会呈现在同一个页面中。然后依照出书年份对这些书本进行排序，或许依照出书社等条件进行过滤——一切这些都需求进行许多的链接盯梢、进一步的查找和手动聚合。Cerebro 有或许能够削减这些作业量，让用户交互变得简略而***。

可是，这在其时是一种典型的获取常识的办法。管理层不确认常识图谱是否真的有用，或许不确认怎样将其用在查找中。关于一个现现已过向用户供给许多超链接而取得成功的企业来说，这种获取常识的新途径并不简单了解。

在与管理层磨合了一年之后，我没有爱好再持续下去了。2011 年 6 月，谷歌上海办公室的一位司理找到我，我把项目交给了他。他为这个项目组建了一个由 15 名工程师组成的团队。我在上海呆了一个星期，把相关的东西都移交给了这个团队的工程师。DH 也参加了这个项目，并长时刻辅导团队。

衔接深度问题我为 Cerebro 开发的图服务体系存在衔接深度问题。当一个查询的后续部分需求用到前面部分的成果时，就需求履行衔接。典型的衔接一般触及到 SELECT 操作，即对通用数据集进行过滤，取得某些成果，然后运用这些成果来过滤数据集的另一部分。我将用一个比如来阐明。

假定你想知道 [people in SF who eat sushi]，而且人们现已同享了他们的数据，包含谁住在哪个城市以及他们喜爱吃哪些食物的信息。

上面的查询是一个单级衔接。假如数据库外部的应用程序正在履行这个衔接，它将先履行一个查询，然后再履行多个查询(每个成果一个查询)，找出每个人都吃些什么，然后挑选出吃寿司的人。

第二步存在扇出(fan-out)问题。假如***步有一百万个成果(依据旧金山人口)，那么第二步需求将每个成果放入查询中，找出他们的饮食习惯，然后进行过滤。

分布式体系工程师一般会经过播送来处理这个问题。他们依据分片函数将成果分红多个批次，然后查询集群中的每一台服务器。他们能够经过这种办法完成衔接，但会导致严峻的查询推迟。

在分布式体系中运用播送并不是个好主意。谷歌大牛 Jeff Dean 在他的“Achieving Rapid Response Times in Large Online Services”讲演(视频：https://www.youtube.com/watch?v=1-3Ahy7Fxsc，幻灯片：https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44875.pdf)中很好地解说了这个问题。查询的总推迟总是大于最慢组件的推迟。单台机器的一丁点推迟会跟着机器数量的增多而戏曲性地增加查询总推迟。

幻想一下，有一台服务器，它的 50 百分位推迟为 1 毫秒，99 百分位推迟为 1 秒。假如查询只触及一台服务器，那么只要 1%的恳求会占用一秒钟时刻。但假如查询触及 100 台服务器，那么就会有 63%的恳求占用一秒钟时刻。

因而，播送会给查询推迟带来晦气的影响。假如需求进行两次、三次或更屡次的衔接，关于实时(OLTP)履行来说就会显得很慢。

大多数非原生图数据库都存在这种高扇出播送问题，包含 Janus Graph、Twitter 的 FlockDB 和 Facebook 的 TAO。

分布式衔接是一个大难题。现有的原生图数据库经过将通用数据集保存在一台机器(独立数据库)上，并在衔接时不拜访其他服务器来防止这个问题，如 Neo4j。

Dgraph：恣意深度衔接在完毕 Cerebro 之后，我具有了构建图服务体系的阅历。随后，我加入了 Dgraph 项目，成为该项意图三位技能主管之一。Dgraph 的规划理念十分新颖，并处理了衔接深度问题。

Dgraph 以一种十分共同的办法对图数据进行分片，能够在单台机器上履行衔接。回到 SPO 这个问题上，Dgraph 的每个实例都将保存与该实例中的每个谓词相对应的一切主语和宾语。Dgraph 实例将保存多个谓词和完好的谓语。

这样就能够履行恣意深度的衔接，一起防止了扇出播送问题。以 [people in SF who eat sushi] 为例，不论集群巨细是怎样的，这个查询最多需求两次网络调用。***次调用会找到一切住在旧金山的人，第2次调用会将这个名单与一切吃寿司的人进行交集操作。然后咱们能够增加更多束缚或扩展，每个过程依然会触及最多一次网络调用。

这导致了单台服务器上的谓语会变得十分大，不过能够经过进一步拆分谓语服务器来处理这个问题。可是，在最极点的状况下，即一切数据只对应一个谓语，那么依据整个集群拆分谓语是一种最糟糕的行为。但在其他状况下，依据谓语对数据进行分片的规划能够在实践体系中完成更低的查询推迟。

分片并不是 Dgraph 的仅有立异。一切的宾语都被分配了一个整型 ID，然后经过排序，保存在倒排列表中，能够与其他倒排列表进行快速的交集操作。这样能够加速衔接期间的过滤、查找公共引证等操作。这儿还运用了谷歌 Web 服务体系的一些主意。

经过 Plasma 联合 OneBoxe谷歌的 Dgraph 并不是一个数据库，而是一个服务体系，相当于谷歌的 Web 查找服务体系。此外，它需求对实时更新做出呼应。作为一个实时更新的服务体系，它需求一个实时的图索引体系。由于之前参加过 Caffeine(https://googleblog.blogspot.com/2010/06/our-new-search-index-caffeine.html)的作业，所以我在实时增量索引体系方面也具有了许多阅历。

后来我又启动了一个新项目，依据这个图索引体系将谷歌一切的 OneBox 联合在一起，包含气候、航班、工作，等等。你或许不知道 OneBox 是什么，但你必定见过它们。OneBox 是独自的显现框，会在运转某些类型的查找时呈现，谷歌能够在这些显现框中显现更多的信息。

在开端这个项目之前，每个 OneBox 由独立的后端供给支撑，并由不同的团队担任保护。它们有一组丰厚的结构化数据，但显现框之间并不会同享这些数据。保护这些后端不只触及许多的作业，而且由于缺少常识同享，约束了谷歌能够呼应的查询类型。

例如，[events in SF] 能够显现工作，[weather in SF] 能够显现气候，但假如 [events in SF] 知道其时在下雨，而且知道工作是在室内仍是在室外进行，那么它就能够依据气候(假如下暴雨，看电影或听交响乐或许是***的挑选)对工作进行过滤(或排序)。

在 Metaweb 团队的协助下，咱们将一切数据转换为 SPO 格局，并在一个体系中对其进行索引。我将这个体系命名为 Plasma，一个用于 Dgraph 的实时图索引体系。

管理层变化与 Cerebro 相同，Plasma 也是一个缺少资金支撑的项目，但仍在持续生长。***，当管理层意识到 OneBoxe 行将运用这个项目时，他们需求找到“适宜的人”担任这方面的作业。在这场政治游戏中，咱们阅历了三次管理层变化，但他们都没有这方面的阅历。

在这次管理层变化过程中，支撑 Spanner(一个全球分布式 SQL 数据库，需求 GPS 时钟来保证全球一致性)的管理层以为 Dgraph 过于杂乱。

***，Dgraph 项目被取消了，不过 Plasma 幸免于难。一个新团队接管了这个项目，这个团队的担任人直接向***履行官报告。这个新团队(他们其实对与图相关的问题缺少了解)决议构建一个依据谷歌现有查找索引的服务体系(就像我为 Cerebro 所做的那样)。我主张运用我为 Cerebro 开发的那个体系，但被回绝了。我修改了 Plasma，让它爬取并将每个常识主题扩展出几个等级，这个体系就能够将其视为一个 Web 文档。他们称之为 TS(这仅仅个缩写)。

这意味着新的服务体系将无法履行深度衔接。我看到许多公司的工程师们在一开端就过错地以为“图实践上是一个很简略的问题，能够经过在另一个体系之上构建一个层来处理”。

几个月之后，也便是 2013 年 5 月，我脱离了谷歌，那个时分我在 Dgraph/Plasma 项目上大约现已作业了两年时刻。

后边的故事几年后，“Web 查找基础设施”被重命为“Web 查找和常识图谱基础设施”，之前我向他演示 Cerebro 的那个人担任领导这方面的作业。他们计划运用常识图谱代替蓝色链接——尽或许为用户查询供给最直接的答案。

当上海的 Cerebro 团队行将在出产环境中布置这个项目时，项目却被谷歌纽约办公室抢走了。***，它面目一新成了“Knowledge Strip”。假如你查找 [tom hanks movies]，会在顶部看到它。自***发布以来，它有了一些改善，但依然无法到达 Cerebro 能够供给的过滤和排序水平。

参加 Dgraph 作业的三位技能主管(包含我)终究都脱离了谷歌。据我所知，其他两位主管现在正在微柔和 LinkedIn 作业。

我取得了两次提升，假如算上其时我以高档软件工程师的身份脱离谷歌，总共是三次。

当时版别的 TS 实践上十分挨近 Cerebro 的规划，主语、谓语和宾语都有一个索引。因而，它依然存在衔接深度问题。

尔后，Plasma 被重写和改名，但依然是一个支撑 TS 的实时图索引体系。它们持续托管着谷歌的一切结构化数据，包含常识图谱。

谷歌在深度衔接方面的力不从心在许多当地都能够看出来。首要，咱们依然没有看到 OneBoxe 之间的数据联合：[cities by most rain in asia] 并不会生成城市列表，虽然气候和 KG 数据是可用的。[events in SF] 无法依据气候进行过滤，[US presidents] 的成果不能进跋涉一步的排序、过滤或扩展。我置疑这也是他们停止运用 Freebase 的原因之一。

Dgraph：凤凰涅槃脱离谷歌两年之后，我决议重新开端 Dgraph(https://github.com/dgraph-io/dgraph)。在谷歌之外，我看到了与最初相似的状况。这个范畴有许多不成熟的自定义处理方案，他们仓促苍茫地在联系型数据库或 NoSQL 数据库之上增加了一个层，或许将其作为多模型数据库的很多功用之一。假如存在原生处理方案，会遇到可弹性性问题。

在我看来，没有人能够在高功用和可弹性规划方面一路走下去。构建一个具有水平可弹性性、低推迟且可进行恣意深度衔接的图数据库是一件十分困难的作业。我期望咱们在构建 Dgraph 这件作业上不会走错路。

在曩昔的三年里，除了我自己的阅历，Dgraph 团队还在规划中加入了许多原创研讨，开发出了这款***的图数据库。其他公司能够挑选这个强壮、可弹性且高功用的处理方案，而不是另一个不成熟的处理方案。

英文原文：

https://blog.dgraph.io/post/why-google-needed-graph-serving-system/