共计 5155 个字符，预计需要花费 13 分钟才能阅读完成。
数据总量的一直增长，使得负责为客户提供策略解决方案的企业面临日益严厉的业务挑战。好消息是，随着云端新型数据库技术的衰亡，种种创新型办法的呈现令这些挑战变得更易于解决。数据仓库曾经成为剖析团队高度关注的一种风行选项；除此之外，开发人员也心愿寻求更多替代性办法，应用更加多样化的技术扭转组织内商务智能的运作形式。对于心愿转换本身剖析平台的企业而言，图数据库无疑是个现实的抉择。得益于 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().
2
3limit(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 的客座文章。
免责申明：本文内容与观点来自第三方作者。亚马逊云科技对本文内容或表述准确性不承当任何责任。
