使用 Amazon Neptune 通过数据仓库构建知识图谱，借此补充商务智能体系

本文为Thermo Fisher Scientific软件工程师Shahria Hossain与销售运营主管Mikael Graindorge的客座文章。

数据总量的不断增长，使得负责为客户提供战略解决方案的企业面临日益严峻的业务挑战。好消息是，随着云端新型数据库技术的兴起，种种创新型方法的出现令这些挑战变得更易于解决。数据仓库已经成为分析团队高度关注的一种流行选项；除此之外，开发人员也希望寻求更多替代性方法，使用更加多样化的技术改变组织内商务智能的运作方式。对于希望转换自身分析平台的企业而言，图数据库无疑是个理想的选择。得益于Amazon Neptune的有力支持，Thermo Fisher Scientific公司团队利用数据仓库平台构建起一套图数据库，其中囊括可用于支持组织内整体商务智能分析功能的强大工具。

Thermo Fisher Scientific公司是一家生命科学企业，致力于为科学研究、开发与制造需求提供广泛支持，旨在让整个世界更加健康、清洁与安全。Thermo Fisher Scientific商业团队是一个高度面向分析的业务部门，致力于构建创新型应用程序以改善组织内部的业务运营方式，借此与需要关键任务产品的大型科学客户群体建立起密切联系。作为全球创新团队的一部分，我们使用Neptune构建知识图谱，借此支持工程师、分析师与数据科学家的应用程序开发流程，进而推动自身业务的全面发展。我们使用这套知识图谱为前线业务人员构建了推荐系统，根据相似客户行为向客户提供产品建议。我们的业务团队使用这套推荐系统在适当时机为客户提供满足客户需求的产品。在本文中，我们将重要介绍Thermo如何立足现有AWS数据仓库生态系统构建起Neptune知识图谱，以及如何将战略关系整合至知识图谱内以将其拓展为一套强大的推荐系统。

关系数据库对图数据库

凭借着出色的简单性与广泛应用范围，管理数据仓库的业务分析人员可以使用关系数据库查询（SQL）轻松执行数据操作与查询任务。但是，某些特定分析任务可能需要在多个数据层内进行遍历联接与聚合才能获得所需的结果。分析中涉及的实体越多，需要进行多层复杂数据操作的可能性就越大。这不仅令整个声明性编码过程变得非常复杂，也可能导致每次运行查询都可能带来高延迟。另外，这些查询可能往往难以理解与破译——如果编写查询的人员没有为相关逻辑添加解释，后来者甚至根本无法跟上思路。

在另一方面，图数据库是专为数据关系建立起的解决方案。对这些关系进行遍历以获取本质上的特征，这就减少了跨域检索互连数据所耗费的时间与复杂性。以此为基础，分析师能够明确了解自己的查询从哪里开始、到哪里结束。图查询语言中还内置有强大的算法，可帮助大家使用关系数据库所无法实现的逐步遍历来解决问题。这意味着图数据库特别擅长从高度互连数据集中，为最终用户及应用程序提取深入的见解。

但问题在于，图数据库中提供的查询功能往往很难在数据仓库中直接复制；更要命的是，数据仓库本身的实用性极强，已经成为分析生态系统中不可替代的重要一环。数据仓库易于使用、性能出色，特别适合受过SQL专业培训的用户使用。通过立足云端对各类分析解决方案进行广泛探索，我们的团队得出结论——数据仓库与图数据库应该在分析生态系统中紧密协作，保证在不同性质及复杂度的工作负载中分别使用对应的最佳工具。图数据库特别适合多维分析这类难以使用关系数据库执行的任务，而关系数据库则侧重于图数据库无法搞定的高强度计算密集型批处理工作负载聚合。那么，我们的团队该如何构建起一套能够与数据仓库协同运作的知识图谱呢？Thermo Fisher Scientific商业团队设计出连通桥梁，解决方案当中包含一套强大的数据仓库，可通过扩展构建起知识图谱，且整个体系完全运行在AWS云之上。

通过数据仓库构建知识图谱

我们的分析生态系统重度依赖于数据仓库。我们根据客户行为、内部运营、营销活动、客户账户结构等数据提供有深入的见解，借此改善公司的业务运营。我们首先从各种内部及外部源系统中获取交易数据，而后对其进行整理、分析，并将结果集成至应用程序当中以供最终用户访问。下图所示，为如何使用Python从各种源系统处收集数据集，进而实现整个数据工程流程。

使用Python脚本与SQL转换，我们可以为数据仓库构建自定义数据提取管道，借此满足下游看板、报告与应用程序的需求。这套方案获得了良好的收效，能够集中收集来自多个数据源的数据。事实也证明，保留我们的Amazon Redshift数据仓库并将其集中在分析生态系统之内，确实给分析工作带来了强大助力。因此，我们将Neptune知识图谱作为Amazon Redshift数据仓库的衍生产品。下一节中，我们将重点介绍如何构建大规模数据集成管道以桥接这两个彼此独立的平台。

图数据库ETL过程

在用于将Amazon Redshift中现有关系数据迁移至Neptune中图模型内的解决方案中，我们充分结合了Amazon Redshift的强大数据转移功能与Neptune的批量加载功能。在下图中，我们将整个流程简化为四个基本步骤。

• 步骤1与步骤2——使用适当的批量加载格式，对来自Amazon Redshift的数据以CSV文件格式导出。
• 步骤3——将文件复制到与Neptune处于同一区域的Amazon Simple Storage Service (Amazon S3)存储桶当中。
• 步骤4——调用Neptune指加载器API，加载CSV文件中的特定关系。

Neptune批量加载器API帮助我们轻松便捷地加载大量关系。在本用例中，我们在10分钟内加载了超过30万个顶点与1600万条边。Amazon Redshift的快速批量导出功能与Neptune的快速批量加载功能相结合，使得在数据仓库与图数据库之间高效迁移大量数据成为可能。只要明确了需要从数据仓库迁移至图数据库的实体与关系，即可轻松添加多个数据集。但除了执行分析之外，我们还需要认真考虑图数据库的维护问题。

我们在Neptune中保持数据更新的方法，是使用AWS Step Functions配置自动化方案，借此在数据仓库与Neptune之间快速复制变更的数据。在起步阶段，我们的图谱规模相对较小（20万个顶点，关系边少于1000万条），因此可以通过调度删除并重新加载图谱以随时保持数据更新。但随着图规模的持续扩展，在集群上执行完整清除-重新加载操作的效率越来越低。虽然可以直接使用现成的并发处理方式以加快图删除方法，但我们仍然决定开发一款自定义应用以实现增量化加载操作。这种增量式数据捕获，类似于在事务与分析系统之间捕捉变更数据的传统ETL方法。尽管目前仍在开发当中，但其已经能够分析Neptune最新加载数据的相关元数据，而后通过各个原始数据源在Amazon Redshift中添加或更改的字段实现变更确定。为了进一步解决异常问题，我们还决定继续在维护期间按计划执行完整的历史数据刷新。

使用Neptune实现数据分析

现在，图已经加载就绪且源数据刷新也实现了自动化，我们可以开始进行分析了。在以下示例中，我们将执行之前详细介绍过的批量加载过程，将表（LABS）与表（PRODUCTS）的简单行为关系加载至Neptune当中。这里，我们将数据仓库的关系数据库模型转换为图数据模型，如下图所示。

只需使用两个顶点之间的关系，我们就能回答商务智能层面的种种复杂问题，例如：

• 我们应该根据过往交互关系，向 lab推荐哪些产品？
• 相距最多五个跃点的两个lab之间，存在着哪些行为重叠？
• 与特定lab相似度最高/最低的lab是什么？
• lab购买了，但与之最相似的另一lab却没有购买的产品是什么？

我们使用Gremlin作为遍历语言构建查询，旨在帮助解决这类问题以提供原型验证。参考Apache TinkerPop项目等拥有丰富资料的同类项目，我们的Gremlin遍历语言学习过程变得非常简单易行。我们从简单查询开始，逐步探索图谱中的秘密：

• 计算图中的顶点数量 – g.V().count()
• 计算图中的lab顶点数量 – g.V().hasLabel(‘lab’).count()
• 查找所有已购买产品 – g.E().hasLabel(‘purchased’).outV().hasLabel(‘product’)

以此为基础，我们逐步丰富查询功能，希望能以更复杂的方式解决更困难的问题，例如：

根据lab X与lab Y之间购买行为的相似之处，我们该如何为lab X提供产品推荐？请参阅以下代码：

g.V().has(‘lab’, ‘lab_name’, ‘X’).as(‘Laboratory’).     out(‘purchased’).aggregate(‘self’).in(‘purchased’).where(neq(‘Laboratory’)).groupCount().order(local).by(values,desc).limit(local,1).select(keys).out('purchased').where(without('self)).values('product_name').dedup().

limit(25).toList()

根据另一lab的行为，此查询可能会给出lab X尚未购买、但却最感兴趣的25种产品。回答此类问题，有助于我们开发出一款推荐工具，使用我们的Neptune知识图谱建立推荐引擎。以往，使用关系数据库解决方案执行SQL查询以回答此类问题时，我们需要进行大量批处理与计算操作；但如今，Neptune帮助我们将整个流程简化为单一Gremlin查询。我们可以直接加载两个实体（labs与 products）之间的关系以直接回答这类问题。

现在想象一下，如果将其他战略性关系集成至这份知识图谱中，又将迸发出怎样的能量。首先，我们需要提出使用图方法解决的问题，而后使用经过Amazon Redshift优化的数据加工处理过程，将适当的关系数据批量加载至Neptune当中。以此为基础，进一步编写查询以解决问题，并将查询与下游应用程序集成起来。这就是一套功能强大的解决方案，不仅可以充分发挥图数据库的优势，同时也凭借着上游强大的数据仓库解决方案消除了高强度的数据处理需求。

总结

图数据库解决方案正快速成为分析团队在分析业务体系内建立独特优势的必要条件。但需要强调的是，除了图数据库这一强大工具之外，我们还需要参考战略设计流程构建起有见解的平台。

根据我们的经验，只有将可靠的数据仓库模型，同我们对于希望通过图算法回答的特定问题类型的深刻理解融合起来，才能真正为图数据库模型总结出清晰明确的设计框架。对我们来说，最重要的就是从单一关系起步，逐渐将关系数据模型迁移至图数据模型，最终帮助我们解决与客户行为及产品推荐相关的具体问题。我们已经使用这套协作平台向客户提供推荐，并获得了良好的收效。

如果不使用图数据库解决方案，我们也可以构建自定义算法，通过多层数据批处理与模型训练实现类似的效果。但很明显，我们使用Neptune的图解决方案获得了类似的效能，同时得以直接使用图数据库内置的客户行为关系遍历查询等常规策略。数据工程已经成为构建高性能商务智能解决方案中的核心前提，但现在的我们才刚刚跨出探索的第一步。展望未来，我们坚信随着对图数据库的实验，其中蕴藏的更多优势终将为我们所用。我们的下一步计划，包括使用数据仓库中的其他数据集进一步扩展知识图谱，借此使用分析生态中的全部有价值数据，同时通过图算法扩展下游应用程序。

图数据库本身实用性惊人，但对于有意将图数据库集成至现有分析平台的团队而言，从零开始配置系统往往是一项资源密集投入的工作。我们推荐大家使用Neptune，其不仅能够简化流程，同时业务相关团队轻松上手。AWS提供了详尽的说明文档，引导大家通过Neptune控制台轻松完成各项配置工作。与其他图数据库服务相比，Neptune的后续发展态势还有待观察；但结合我们目前的使用经历，Neptune非常强大而且未来可期。

免责声明：本文内容与观点来自第三方作者。AWS对本文内容或表述准确性不承担任何责任。