数据总量的一直增长，使得负责为客户提供策略解决方案的企业面临日益严厉的业务挑战。好消息是，随着云端新型数据库技术的衰亡，种种创新型办法的呈现令这些挑战变得更易于解决。数据仓库曾经成为剖析团队高度关注的一种风行选项；除此之外，开发人员也心愿寻求更多替代性办法，应用更加多样化的技术扭转组织内商务智能的运作形式。对于心愿转换本身剖析平台的企业而言，图数据库无疑是个现实的抉择。得益于Amazon Neptune的无力反对，Thermo Fisher Scientific公司团队利用数据仓库平台构建起一套图数据库，其中囊括可用于反对组织内整体商务智能剖析性能的弱小工具。

Thermo Fisher Scientific公司是一家生命科学企业，致力于为科学研究、开发与制作需要提供广泛支持，旨在让整个世界更加衰弱、清洁与平安。Thermo Fisher Scientific商业团队是一个高度面向剖析的业务部门，致力于构建创新型应用程序以改善组织外部的业务经营形式，借此与须要要害工作产品的大型迷信客户群体建设起密切联系。作为寰球翻新团队的一部分，咱们应用Amazon Neptune构建常识图谱，借此反对工程师、分析师与数据科学家的利用程序开发流程，进而推动本身业务的全面倒退。咱们应用这套常识图谱为火线业务人员构建了举荐零碎，依据类似客户行为向客户提供产品倡议。咱们的业务团队应用这套举荐零碎在适当机会为客户提供满足客户需要的产品。在本文中，咱们将重要介绍Thermo如何立足现有亚马逊云科技数据仓库生态系统构建起Amazon Neptune常识图谱，以及如何将策略关系整合至常识图谱内以将其拓展为一套弱小的举荐零碎。

想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注在上海、北京、深圳三地举办的2021亚马逊云科技中国峰会！点击图片报名吧～

关系数据库对图数据库

凭借着杰出的简略性与广泛应用范畴，治理数据仓库的业务剖析人员能够应用关系数据库查问（SQL）轻松执行数据操作与查问工作。然而，某些特定剖析工作可能须要在多个数据层内进行遍历联接与聚合能力取得所需的后果。剖析中波及的实体越多，须要进行多层简单数据操作的可能性就越大。这不仅令整个申明性编码过程变得非常复杂，也可能导致每次运行查问都可能带来高提早。另外，这些查问可能往往难以了解与破译——如果编写查问的人员没有为相干逻辑增加解释，后来者甚至根本无法跟上思路。

在另一方面，图数据库是专为数据关系建设起的解决方案。对这些关系进行遍历以获取实质上的特色，这就缩小了跨域检索互连数据所消耗的工夫与复杂性。以此为根底，分析师可能明确理解本人的查问从哪里开始、到哪里完结。图查询语言中还内置有弱小的算法，可帮忙大家应用关系数据库所无奈实现的逐渐遍从来解决问题。这意味着图数据库特地善于从高度互联数据集中，为最终用户及应用程序提取深刻的见解。

但问题在于，图数据库中提供的查问性能往往很难在数据仓库中间接复制；更要命的是，数据仓库自身的实用性极强，曾经成为剖析生态系统中不可代替的重要一环。数据仓库易于应用、性能杰出，特地适宜受过SQL专业培训的用户应用。通过立足云端对各类剖析解决方案进行宽泛摸索，咱们的团队得出结论——数据仓库与图数据库应该在剖析生态系统中严密合作，保障在不同性质及复杂度的工作负载中别离应用对应的最佳工具。图数据库特地适宜多维分析这类难以使用关系数据库执行的工作，而关系数据库则侧重于图数据库无奈搞定的高强度计算密集型批处理工作负载聚合。那么，咱们的团队该如何构建起一套可能与数据仓库协同运作的常识图谱呢？Thermo Fisher Scientific商业团队设计出连通桥梁，解决方案当中蕴含一套弱小的数据仓库，可通过扩大构建起常识图谱，且整个体系齐全运行在亚马逊云科技云之上。

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

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

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

图数据库ETL过程

在用于将Amazon Redshift中现有关系数据迁徙至Amazon Neptune中图模型内的解决方案中，咱们充沛联合了Amazon Redshift的弱小数据转移性能与Amazon Neptune的批量加载性能。在下图中，咱们将整个流程简化为四个根本步骤。

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

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

咱们在Amazon Neptune中保持数据更新的办法，是应用Amazon Step Functions配置自动化计划，借此在数据仓库与Amazon Neptune之间疾速复制变更的数据。在起步阶段，咱们的图谱规模绝对较小（20万个顶点，关系边少于1000万条），因而能够通过调度删除并从新加载图谱以随时保持数据更新。但随着图规模的继续扩大，在集群上执行残缺革除-从新加载操作的效率越来越低。尽管能够间接应用现成的并发解决形式以放慢图删除办法，但咱们依然决定开发一款自定义利用以实现增量化加载操作。这种增量式数据捕捉，相似于在事务与剖析零碎之间捕获变更数据的传统ETL办法。只管目前仍在开发当中，但其曾经可能剖析Amazon Neptune最新加载数据的相干元数据，而后通过各个原始数据源在Amazon Redshift中增加或更改的字段实现变更确定。为了进一步解决异样问题，咱们还决定持续在保护期间按计划执行残缺的历史数据刷新。

应用Amazon Neptune实现数据分析

当初，图曾经加载就绪且源数据刷新也实现了自动化，咱们能够开始进行剖析了。在以下示例中，咱们将执行之前具体介绍过的批量加载过程，将表（LABS）与表（PRODUCTS）的简略行为关系加载至Amazon 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提供产品举荐？请参阅以下代码：

1g.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().23limit(25).toList()4

依据另一lab的行为，此查问可能会给出lab X尚未购买、但却最感兴趣的25种产品。答复此类问题，有助于咱们开发出一款举荐工具，应用咱们的Amazon Neptune常识图谱建设举荐引擎。以往，应用关系数据库解决方案执行SQL查问以答复此类问题时，咱们须要进行大量批处理与计算操作；但现在，Amazon Neptune帮忙咱们将整个流程简化为繁多Gremlin查问。咱们能够间接加载两个实体（labs与 products）之间的关系以间接答复这类问题。

当初设想一下，如果将其余战略性关系集成至这份常识图谱中，又将迸发出怎么的能量。首先，咱们须要提出应用图办法解决的问题，而后应用通过Amazon Redshift优化的数据加工处理过程，将适当的关系数据批量加载至Amazon Neptune当中。以此为根底，进一步编写查问以解决问题，并将查问与上游应用程序集成起来。这就是一套功能强大的解决方案，不仅能够充分发挥图数据库的劣势，同时也凭借着上游弱小的数据仓库解决方案打消了高强度的数据处理需要。

总结

图数据库解决方案正疾速成为剖析团队在剖析业务体系内建设独特劣势的必要条件。但须要强调的是，除了图数据库这一弱小工具之外，咱们还须要参考策略设计流程构建起有见解的平台。

依据咱们的教训，只有将牢靠的数据仓库模型，同咱们对于心愿通过图算法答复的特定问题类型的深刻理解交融起来，能力真正为图数据库模型总结出清晰明确的设计框架。对咱们来说，最重要的就是从繁多关系起步，逐步将关系数据模型迁徙至图数据模型，最终帮忙咱们解决与客户行为及产品举荐相干的具体问题。咱们曾经应用这套合作平台向客户提供举荐，并取得了良好的收效。

如果不应用图数据库解决方案，咱们也能够构建自定义算法，通过多层数据批处理与模型训练实现相似的成果。但很显著，咱们应用Amazon Neptune的图解决方案取得了相似的效力，同时得以间接应用图数据库内置的客户行为关系遍历查问等惯例策略。数据工程曾经成为构建高性能商务智能解决方案中的外围前提，但当初的咱们才刚刚跨出摸索的第一步。展望未来，咱们深信随着对图数据库的试验，其中蕴藏的更多劣势终将为咱们所用。咱们的下一步打算，包含应用数据仓库中的其余数据集进一步扩大常识图谱，借此应用剖析生态中的全副有价值数据，同时通过图算法扩大上游应用程序。

图数据库自身实用性惊人，但对于无意将图数据库集成至现有剖析平台的团队而言，从零开始配置零碎往往是一项资源密集投入的工作。咱们举荐大家应用Amazon Neptune，其不仅可能简化流程，同时业务相干团队轻松上手。亚马逊云科技提供了详尽的阐明文档，疏导大家通过Amazon Neptune控制台轻松实现各项配置工作。与其余图数据库服务相比，Amazon Neptune的后续倒退态势还有待察看；但联合咱们目前的应用经验，Amazon Neptune十分弱小而且将来可期。

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

免责申明：本文内容与观点来自第三方作者。亚马逊云科技对本文内容或表述准确性不承当任何责任。