发布于: Feb 8, 2022
图数据库 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 中保持数据更新的方法，是使用 Amazon Step Functions 配置自动化方案，借此在数据仓库与 Neptune 之间快速复制变更的数据。在起步阶段，我们的图谱规模相对较小（ 20 万个顶点，关系边少于 1000 万条），因此可以通过调度删除并重新加载图谱以随时保持数据更新。但随着图规模的持续扩展，在集群上执行完整清除-重新加载操作的效率越来越低。虽然可以直接使用现成的并发处理方式以加快图删除方法，但我们仍然决定开发一款自定义应用以实现增量化加载操作。这种增量式数据捕获，类似于在事务与分析系统之间捕捉变更数据的传统ETL方法。尽管目前仍在开发当中，但其已经能够分析 Neptune 最新加载数据的相关元数据，而后通过各个原始数据源在 Amazon Redshift 中添加或更改的字段实现变更确定。为了进一步解决异常问题，我们还决定继续在维护期间按计划执行完整的历史数据刷新。
使用 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 与l ab 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，其不仅能够简化流程，同时业务相关团队轻松上手。亚马逊云科技提供了详尽的说明文档，引导大家通过 Neptune 控制台轻松完成各项配置工作。与其他图数据库服务相比，Neptune 的后续发展态势还有待观察；但结合我们目前的使用经历，Neptune 非常强大而且未来可期。
相关文章