Airbnb为成为端到端旅行平台，构建知识图谱存储和提供结构化数据。文章介绍了知识图谱基础设施，包括图存储、图形查询API和存储更改器；阐述运用分类法对旅行世界分类；还提及为用户提供旅行环境的功能。同时指出面临的数据质量和性能问题，正用先进技术解决。
我想你去洛杉矶旅行。 第一步是访问A irbnb.com并搜索“洛杉矶”。在后端，查询“洛杉矶”被翻译成地图上的一个区块; 此块中的可用房屋将在许多搜索结果页面中返回。 这足以让你制定旅行计划吗？
随着Airbnb逐渐走向成为端到端的旅行平台 ，我们越来越重要的是提供旅行见解，帮助人们决定何时旅行，去哪里以及旅行时 做些什么 。 例如，洛杉矶最受欢迎的地标和社区是什么？ 是否有任何即将举行的音乐会或体育赛事可能与我的旅行相符？ 哪些Airbnb房源最适合家庭？ 去洛杉矶一年中最实惠的时间是什么？ 所有这些内容和背景对度假计划者都有帮助，我们可以提供的准确，有用的旅行信息越多，我们的用户就越信任我们。
为了扩展我们回答这些旅行查询的能力，我们需要一种系统的方法来存储和提供有关实体 （例如城市，地标，事件等）的高质量信息以及它们之间的关系 （例如，城市中最受欢迎的地标） ，玉米饼最好的邻居等）。 为了解决这个问题，我们在过去一年中建立并应用了一个知识图表来存储和提供结构化数据 ，这些数据连接了我们的库存独特之处，用户所寻找的内容以及旅行世界所提供的内容。
在我们之前的文章中 ，我们分享了对Airbnb的知识图及其工作原理的高级概述。 在这篇文章中，我们将深入探讨如何构建知识图基础架构并在此过程中分享我们的知识。 我们还将介绍如何使用知识图对我们的库存进行分类并将整个平台置于上下文中。
基础设施
下图说明了截至今天Airbnb的知识图服务的架构。 它可以分为3个组件： 图形存储， 图形查询API和存储更改器 。 在本节中，我们将详细介绍每个细节。
知识图形基础结构的体系结构
图存储
我们为知识图基础架构构建的第一件事是图形存储模块 。 我们采用了一个内部关系数据存储作为底层数据库，我们在其上实现了一个节点存储和边缘存储 ，以便可以直接在节点（实体）上执行CRUD（创建，读取，更新和删除）操作。边（关系），而不是处理数据库表中的行。 为每个节点或边缘分配全局唯一标识符 （GUID）。 我们可以使用GUID获取节点和边缘; 此外，我们还可以获取连接某些节点的特定类型的边。
为了将本体和关系构建到知识图中，图存储中的节点被划分为不同的节点类型。 此外，每个节点类型都由唯一的模式定义。 例如， 地点节点由名称和GPS坐标定义，而事件节点类型由名称，日期和地点定义。 这些不同的节点类型存储在底层数据库的单独表中。
类似地，边缘可以是不同的边缘类型，以反映实体之间的不同类型的关系（例如， 城市中的地标和国内的语言 ）。 与RDFS中的域和范围相对应，每个边类型对于从其开始和连接的节点类型具有可配置约束。 例如， 城市中的地标必须从地标节点连接到城市节点。
此外，图存储设计用于存储来自不同数据源的边，以便多个团队（作为数据所有者）可以向知识图提供数据。 因此，每个边缘还存储每个边缘的源和置信度分数 。 为了保证数据所有者的操作不太可能影响其他团队的数据，我们将每个数据源的边缘存储在底层数据库的单独表中。 存储还可以存储边缘的额外有效载荷; 一个例子是Home列表与地标附近的地标之间的距离。
在Airbnb，知识图中的数据并不总是通过在线查询消费，因此我们还将节点和边缘的每日快照转储到数据仓库中以供离线使用 。 应用程序（例如我们的自动完成服务）依赖于知识图的数据转储来满足其产品需求。 此外，我们还在数据转储上应用机器学习技术，用于图形嵌入 ， 知识推理等目的。
最后，我们很乐意反思我们对图形存储的底层数据库的选择。 为什么我们采用关系数据库而不是图数据库 ？ 简短的回答是操作开销 。 当时，我们在Airbnb上没有生产就绪的图形数据库，使用现有的关系数据库具有以下优点：
- 我们的内部关系数据库因其被广泛使用而被证明是可靠的。 它还带有许多有用的功能，例如易于使用的客户端，架构迁移工具，监视和警报以及每日数据导出。
- 使用图形数据库意味着我们必须在Airbnb的基础上进行设置，调试任何可靠性/性能问题，并开发我们需要的其他功能。 它会减慢我们的进度并分散我们对知识图本身的关注。
到目前为止，图存储与关系数据库具有令人满意的性能。 我们还仔细地封装和整合逻辑以一起处理数据库并将其隐藏在知识图代码库的其余部分。 通过这样做，我们可以灵活地在将来需要时替换底层数据库。
图形查询API
当我们开始在生产中使用知识图时，我们注意到大多数产品用例需要遍历子图并从遍历中检索节点和边。 例如，在Airbnb的产品详细信息页面（PDP或列表页面）中，查询知识图以显示主页列表附近的兴趣点，以及所提及的每个餐馆，博物馆或地标的照片。 利用图论中的术语，该查询需要遍历（1）连接到特定Home列表节点的所有场所节点，以及（2）与在前一步骤中获取的场所节点连接的照片节点。
为了支持这些产品需求，除知识图API模块中的节点和边缘的CRUD端点外，我们还实现了图形查询端点。 通过图形查询，可以通过指定路径来遍历图形，路径是一系列边缘类型和数据过滤器 ，从某些节点开始，并以结构化格式接收遍历的子图。 图形查询API具有递归接口，使得可以通过多个步骤遍历知识图。
为了给你一个品味，让我们看一个例子：如果想要找到所有与城市节点“ Beijing ”连接的地点节点，边缘类型为“ contains_location” ，那么他们（1）周围有超过5,000个列表和（2） ）属于“ 风景 ”类别。 该查询可以写成如下。
如上所述，知识图旨在存储来自多个数据源的数据。 通过我们的知识图API，可以查询来自所有来源的数据。 在图形查询中，可以指定要从中查询数据的数据源。 同时，我们还在开发一个数据协调层，旨在汇总来自不同来源的数据 ， 协调冲突，并在用户不知道要信任哪些数据源时提供一致的数据视图 。
到目前为止，知识图可以完美地支持用例，例如在Airbnb上获取靠近Home的所有地标 ，因为它可以转换为图形查询。 但是，有些用例无法通过图形查询直接支持 - 例如， 获取 主页周围 最受欢迎的 地标。 我们现在正积极投入努力来处理这种模糊查询 ，方法是通过ML合并地标的元数据和用户的个性化信号 。
存储Mutator
对于我们的许多产品用例，我们需要不断将数据导入图存储并将这些突变传播到下游。 有些情况下，通过知识图API同步写入数据是不理想的，原因如下：
- 在将数据写入知识图的每个管道中同步调用知识图API是一个操作负担，因为管道是在不同的技术堆栈（例如Airflow ， IDL服务等）中实现的，并且每个管道需要处理速率限制，重试异常等问题
- 通过API编写数据可能会与知识图的其他重要在线用法（例如，搜索，PDP等）进行交互，尤其是在写入流量出现峰值或图形存储上的写入路径出错时。
在图存储之上，我们构建了一个存储更改器来解决此问题。 除了调用API之外，数据管道还可以通过向我们的Kafka消息总线发送具有特定Kafka主题的消息来向知识图发送变异请求; 突变消费者订阅该主题并在接收消息时相应地将数据写入知识图。 这种模式有助于从各种管道将数据写入知识图的过程，现在是我们导入数据的主要方式。 我们还计划将其用于存储回滚和第三方数据提取等功能 。
在存储mutator中，我们还构建了一个变异发布者，将数据突变传播到Kafka消息总线。 下游管道可以为其产品用例使用这些消息。 一个例子是搜索索引管道，其中知识图通过该模式将分类数据填充到搜索索引中。 我们将在下一节中深入研究这个用例。
运用分类法对旅行世界进行分类
如今，Airbnb上有超过500万家庭。 为了帮助旅行者找到最佳旅行之家，我们首先需要对我们平台上的每个家庭建立深刻的理解。 例如，哪些房屋最适合家庭，哪些房屋可以24小时办理登机手续？ 为了支持这个用例，我们在知识图中构建了一个丰富的分类法 ，并将其用于对Airbnb的所有库存进行分类 。
在悉尼寻找“海滨”住宅
分类
为了丰富知识图中的语义 ，我们构建了一个分类法作为我们本体的一部分，这是我们用来描述我们的库存和我们周围世界的词汇。 分类法采用层次结构，表示不同粒度级别的概念，以便我们可以将更高级别的概念映射到非常具体的概念。 例如，上面屏幕截图中的“Beachfront”是我们分类中的标签，而其父标签是“Nature Venue”，祖父母标签是“Venue”。
Airbnb的分类标准的子集
我们的分类法甚至在知识图之前就开始了，目的是在Airbnb上对经验进行分类。 之后，分类法作为一种特殊类型的节点迁移到知识图中。 如今，该分类法被修订为通用的，适用于Airbnb的所有业务垂直（ 家庭 ， 经验 ， 餐馆等）以及存储在其中的其他类型的实体（如地点 ， 事件等）。知识图。
鉴于分类法在知识图中发挥的基本作用，我们将分类法节点与其他类型的节点区别对待。 对分类标准的任何编辑都需要由一个由内容策略师，产品经理和工程师组成的跨职能团队进行讨论和批准，然后才能执行。
分类
为了对Airbnb的库存进行分类，每个体验，家庭或餐馆都需要使用分类中的相关节点进行标记。 这个过程一直充满挑战。 一方面，人力分类昂贵且难以扩展; 另一方面，自动分类工作需要额外的工作来确保准确性。 以下是我们探索过的几种不同方法。
Airbnb体验由全球运营团队手动标记。 为了促进这一过程，我们构建了一个管理标记工具，其中包含简洁的UI。 （将来，我们的主机可能会承担一些此过程。）
手动分类体验的工具
对于自动分类，我们测试了几种不同的方法。 首先，我们直接从库存元数据中进行知识推断 。 为了对具有位置设施的房屋进行分类（例如上面示例中的“海滨”）， 供应动态团队正在采用将kd树应用于家庭位置以及从家庭描述和客人评论中提取文本的组合。 他们还为主机建立了一个反馈循环（见下文），以确认他们的推理结果。
主人可以确认他们家的位置设施
此外， AI Labs团队还应用Airbnb Homes嵌入了Home的描述，Home邻居的描述和主持人的个人资料描述。 基于嵌入，他们正在积极致力于推断Airbnb家庭可能缺少的设施。 AI实验室将发布一篇关于他们工作细节的文章。
为用户提供旅行环境
到目前为止，我们已经探索了一些产品接触点，以便在预订流程中为用户提供上下文旅行洞察。 以下是Airbnb知识图授权的一些功能。
鼓励用户选择目的地
为了帮助用户选择目的地开始搜索，我们在主页上推出了一系列鼓舞人心的目的地轮播。 我们在知识图中存储了数百张目的地照片，然后向用户提供最相关的旅行创意。
Airbnb主页上的一组热门欧洲旅游目的地
帮助用户选择一个家庭预订
选择目的地后，用户开始决定一个家庭。 为了帮助指导用户，我们使用知识图来表达目的地中的住宅的背景和洞察力。 在某些情况下，我们重点介绍热门设施（见下文），顶级地标或有趣的社区。
建议用户预订带游泳池的房屋，因为“去年访问洛杉矶的客人中有33％搜索了带游泳池的房屋”
提供有关房屋的更多背景信息
我们从研究中了解到，用户经常希望找到一个接近特定兴趣点的房屋，无论是迪斯尼乐园还是卢浮宫。 为了帮助用户了解特定列表与关键地标的关系，我们使用知识图来展示特定家庭附近的内容，并在PDP上显示该信息（见下文）。
显示洛杉矶一个家的当地背景
最后的想法
我们在知识图中的工作已经帮助我们极大地增强和个性化了Airbnb的搜索，供应分组和内容交付。 也存在挑战，特别是在数据质量和在线性能方面。
为了解决这些问题，我们正在利用最先进的机器学习，统计，优化模型和算法。 具体来说，我们正在建立卷积神经网络（CNN）来审查标记的质量。 此外，我们正在部署上下文多臂强盗模型，以推荐在线服务中的个性化内容。 此外，通过利用产品，用户和搜索查询嵌入技术，我们希望生成以前在人工定义的分类集中不可用的新类别。 目前，这些方法还处于试验阶段，敬请期待！
我们开始使用知识图，以便为清理，当前和完整的有关我们的库存和整个旅行世界的结构化数据提供一致的界面 。 通过提供连接 的高质量数据，我们相信知识图有很大机会改善Airbnb的访客和主机体验。 在2019年，我们将不断投资使用我们的知识图来丰富我们对旅行世界（ 分类 ）的理解，并在旅行计划和决策过程的每一步为每位旅行者提供更多旅行内容（ 情境化 ）。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
