使用jupyter进行表格数据筛选（Hansel和Gretel以及使用图表的大数据分析）

使用jupyter进行表格数据筛选（Hansel和Gretel以及使用图表的大数据分析）第3步 -图形遍历的下一步从商家2开始，查看商家的所有付款。在找到与商家2相关的所有付款（付款21 22 23和25）后，对于这些付款，“已访问”累加器值被标记为“真”，有效地标记了林中的树（顶点）（图）鹅卵石（蓄积器）。步骤2 -接下来，图形遍历引擎移动到并行线程中的每个支付（使用TigerGraph的MPP - 大规模并行处理体系结构）并查看与这些支付链接的客户帐户。找到客户帐户（客户1 2 3和4）后，这些帐户的“已访问”累加器值标记为“真”。让我们通过一个例子深入探讨这个主题。考虑两个商家，商家1和商家2.客户1 2 3和4在商家1购物，而顾客1 2 3和5在商家2购物，多个支付交易连接商家和他们的顾客。基于关系数据库的传统解决方案将为每个实体类型提供单独的表：商家，客户帐户（例如信用卡或借记卡）和付款。为了找到普通客户，我们需要加入这三个表来构建一个新的“答案”表。随着表格的大小

了解特定NoSQL数据库及其查询语言如何使执行图遍历和查找数据点之间的关系变得更加容易。

一个高中生，上周听到我和一位客户聊天，并问我：“你为什么继续关于GSQL和称为累加器的东西？有什么大不了的？” 当我想到解释累加器的最佳方法时，TigerGraph的图形查询语言 - GSQL中的一个关键特性 - 我意识到它与我们童年的故事 - 汉塞尔和格莱特尔的故事有一些共同之处。

在故事中，汉塞尔和格莱特尔在他们的口袋里放着白色鹅卵石，并在他们走进森林深处时不断丢弃鹅卵石，这样他们就能记住他们走过的路，并能找到回家的路。GSQL中的累加器可以作为图遍历算法中的“卵石”。更重要的是，累加器还带有内置的计算功能和数据结构，最重要的是，它们设计用于并行计算。就好像我们有一支Hansels和Gretels军队，他们也是数据科学家。我们将涵盖这三个方面中的每一个 - 路径遍历，计算和并行 - 在下面的示例中一次一个。

让我们考虑一下由TigerGraph在多个行业（包括金融服务，制药，医疗保健，电信，互联网和政府）中回答的常见问题 - 给出一组商业实体，例如两个金融服务商或两个医疗保健医生，如何他们有关系吗？他们是否有共同的客户或患者，他们的关系如何在一段时间内发展？

用关系数据库理解两个商人的关系

让我们通过一个例子深入探讨这个主题。考虑两个商家，商家1和商家2.客户1 2 3和4在商家1购物，而顾客1 2 3和5在商家2购物，多个支付交易连接商家和他们的顾客。基于关系数据库的传统解决方案将为每个实体类型提供单独的表：商家，客户帐户（例如信用卡或借记卡）和付款。为了找到普通客户，我们需要加入这三个表来构建一个新的“答案”表。随着表格的大小增加到数百万的支付和数十万甚至数百万的客户，回答一个简单的问题，“这些商家的共同客户是谁”需要很长时间。当我们希望分析并从数据中获得洞察力时，这变得更加耗时且计算成本更高。例如，按周，按月向普通客户添加付款，并了解关系中一段时间​​内的更改。随着时间的推移，这种关系会变得更强还是更弱？是否有特定客户随着时间的推移更频繁地与这两个商家一起购物，而其他客户正在减少他们的购物频率？是否存在基于付款时间戳的特定模式，例如，商家1在一两小时内首先跟随商家2购买的单一客户？并了解这段关系中一段时间​​内的变化。随着时间的推移，这种关系会变得更强还是更弱？是否有特定客户随着时间的推移更频繁地与这两个商家一起购物，而其他客户正在减少他们的购物频率？是否存在基于付款时间戳的特定模式，例如，商家1在一两小时内首先跟随商家2购买的单一客户？并了解这段关系中一段时间​​内的变化。随着时间的推移，这种关系会变得更强还是更弱？是否有特定客户随着时间的推移更频繁地与这两个商家一起购物，而其他客户正在减少他们的购物频率？是否存在基于付款时间戳的特定模式，例如，商家1在一两小时内首先跟随商家2购买的单一客户？

用TigerGraph绘制两个商人之间的关系

TigerGraph是一个原生图形平台，这意味着商家，客户帐户和支付被表示为业务实体，它们之间的关系包含在数据模型中。从图中可以看出，在TigerGraph的图形用户界面（GUI）GraphStudio中，可以很容易地在两个商家之间找到共同的客户。但是，作为实时GSQL查询的一部分，您如何找到并导出普通客户？您如何在普通客户中累计支出？这是累加器进来的地方。

走路或遍历图表以找到共同的客户

步骤1 -图形遍历从商家1开始，然后通过资金转移链接返回到商家的所有付款。TigerGraph将在每次付款时使用标记，例如“已访问”，以记住作为步行或遍历图表的一部分访问了哪些付款。此标志或局部变量是GSQL中的累加器。就像Hansel和Gretel使用白色鹅卵石来记住森林中的路径一样，TigerGraph分析引擎使用“访问过的”累加器（“卵石”）来记住已经访问过的付款。

步骤2 -接下来，图形遍历引擎移动到并行线程中的每个支付（使用TigerGraph的MPP - 大规模并行处理体系结构）并查看与这些支付链接的客户帐户。找到客户帐户（客户1 2 3和4）后，这些帐户的“已访问”累加器值标记为“真”。

第3步 -图形遍历的下一步从商家2开始，查看商家的所有付款。在找到与商家2相关的所有付款（付款21 22 23和25）后，对于这些付款，“已访问”累加器值被标记为“真”，有效地标记了林中的树（顶点）（图）鹅卵石（蓄积器）。

步骤4 -在最后一步中，图表遍历从与Merchant 2链接的所有付款开始，然后查找累加器访问的客户顶点设置为true。这些是Merchant 1和Merchant 2之间的常见客户。

GSQL中的Magical Pebbles，又名累加器

GSQL中的累加器不仅仅记住在遍历拓扑结构时遍历图形或用作标记时所采用的路径。存在可用于收集商业实体（例如，支付，客户，商家）和实体之间的边缘或关系（例如，来自客户的支付或支付给商家）的全球累积器，其满足特定标准。

在此示例中，全局累加器可用于收集业务实体或顶点以及关系或边缘，并将该集合提供给TigerGraph GraphStudio或外部可视化引擎，以便用户可以看到显示Merchant 1和商家1之间关系的子图。商家2.从三个普通客户（客户1，客户2和客户3）开始，可以将图表遍历到相关的两个商家，商家1和商家2并行，收集链接到普通客户的付款，并存储它们在名为“CommonPayments”的SetAccum全局累加器中。在这种情况下，CommonPayments将为商家1收取付款11 12和13，为商家2收取付款21 22和23。接下来，

除了充当局部变量或全局变量之外，累加器还提供诸如Min，Max，Average和Sum之类的计算功能，并且能够保存单个值或业务实体和关系的集合。您可以在TigerGraph文档中浏览累加器。

将累加器与TigerGraph的大规模并行处理（MPP）引擎相结合

累加器旨在利用TigerGraph的MPP引擎，并支持每个顶点和每个边缘的并行计算，以最大限度地提高每个查询的硬件吞吐量。

想象一下，如果Hansel和Gretel（MPP线程）复制自己并在森林（图形）中沿着多条路径运行，同时使用鹅卵石（累加器）来跟踪每个被访问的顶点并计算这些顶点的摘要信息（例如总和）对于拥有商家的客户的总支付额而言，没有相互绊倒 - 这就是累积器与TigerGraph MPP相结合为各种规模的数据集提供的。在跟踪每条路径并执行复杂计算的同时并行遍历图形的能力对于累加器和TigerGraph MPP的组合是唯一的。

事实上，虽然我们展示了四个步骤（步骤1 2 3和4）来确定两个商家之间的共同客户，但TigerGraph平台与累加器相结合的并行性质允许我们只需两步即可执行此步骤商家1和商家2同时进行以找到共同的客户。实际上，步骤1（从商家1开始）和步骤3（从商家2开始）同时执行。步骤2和步骤4也同时执行，以便更快地找到普通客户以及为这些客户付款。

TigerGraph团队正在使用图形查询语言（GQL）计划来添加累加器作为图形查询语言的标准功能。通过下载TigerGraph Developer Edition，体验TigerGraph GSQL的完整性能，可扩展性和优雅，包括累加器和图形分析引擎。