基于Scylla和JanusGraph的可伸缩图形数据库

提交此表格即表示您确认已阅读并同意我们的隐私政策。

ZeoTap是一个客户智能平台，使品牌能够更好地了解客户并更好地预测他们的行为。它们跨多个社交媒体、广告技术、Martech和CRM平台集成和关联数据。该公司总部设在德国，强调消费者隐私和数据安全，拥有多种认证(如GDPR)，以确保跨市场的端到端合规性。

在我们的Scylla峰会上，ZeoTap工程副总裁Sathish K S和首席数据工程师Saurabh Verma分享了ZeoTap如何应对身份解析和集成的挑战。他们展示了Saurabh所说的“由Scylla支持的世界上最大的原生JanusGraph数据库”，以满足跟踪和关联200亿个用户及其设备ID的需求。

ZeoTap使用Scylla和JanusGraph作为其Connect产品的一部分，这是一个确定性身份解决方案，可以将离线客户CRM数据与在线数字标识符关联起来。ZeoTAP从80多个合作伙伴那里获取数据，将这些数据分发到40多个目的地。

作为身份解析的一个例子，Sathish举了一个人的例子，他可能有一到两部手机、一台平板电脑、一台IP电视，并且可能属于任何数量的忠诚度计划或俱乐部。这些设备和程序中的每一个都将为您生成一个标识符，外加您访问的每个站点的所有设备上的Cookie标识符。

萨蒂什强调，“身份之间的联系，或者说联系，比个人身份更有价值。”这背后的商业案例，匹配测试和导出这些ID的能力，都是ZeoTap可以赚钱的。例如，客户可以提供一组100万个电子邮件地址，并询问其中有多少百分比可以与ZeoTap的已知用户数据进行匹配。他们还可以建立到表示该已知用户的其他标识符的传递链接。然后，用户可以将该数据导出到他们自己的系统。

最重要的是，ZeoTap维护着完整的报告和合规机制，包括支持选择退出。他们还必须确保身份质量，并将其数据与多个第三方集成，同时保持数据“新鲜度”的短期服务级别协议。“这意味着您需要具有真正快速的接收和真正快速的查询性能。”

他们最初的MVP实现使用Apache Spark批处理来关联他们所有的合作伙伴数据，并将输出结果存储到S3。然后，用户通过Amazon Athena查询和其他针对Amazon RedShift数据仓库的Apache Spark作业访问数据，以生成匹配测试、导出和报告。但是，当ZeoTap开始跨越30亿ID的规模时，他们看到他们的处理时间超过了一整天(24小时)，而他们的SLA通常在2到6小时的范围内。

ZeoTap查看了他们的要求。他们需要一个同时支持高级别读取和写入的系统。因为即使在分析数据的同时，您仍然可以有更多的数据涌入系统。在他们拥有30亿个ID的时候，他们的SLA最低为每秒50k次写入。他们还在寻找一种能够为数据提供开箱即用的生存时间(TTL)的数据库解决方案。

对于读取工作负载，ZeoTap需要进行大量分析来匹配ID并检索(导出)链接ID上的数据，通常基于ID类型(Android、iOS、网站cookie)或属性(新近、质量分数或国家)等条件。

萨蒂什随后谈到了他们的商业模式。ZeoTap不会从他们的合作伙伴那里购买数据。取而代之的是，他们提供了收入分享协议。因此，所有数据都必须标记，以注明是哪个数据合作伙伴提供的。当合作伙伴的数据被访问时，他们将获得ZeoTap赚取的收入的一部分。计数器对于计算合作伙伴从数据利用中获得的收入至关重要。

深度过滤器是一种计算在结束一条连接线之前遍历图形的距离的方法。因此，他们的客户可以设置限制-在间接深度为4、5或10之后停止扫描。

“是时候改变了。如果你看看我一直在说的，像“传递性”，“深度”，“联系”，“联系”之类的术语--这些都是你们在大学里学的图论。所以我们想，‘有没有一种ID图可以直接取代我的存储，并提供所有开箱即用的东西？’这就是ZeoTap开始评估图形数据库的过程。

ZeoTap依靠Apache Spark处理来自其合作伙伴的数据，并根据ID集为其客户提供分析以测试匹配，并基于其链接导出。他们的问题是图形数据库是否能够进行扩展以满足其苛刻的工作负载。

Saurabh随后描述了查找本地图形数据库的过程。他们的解决方案需要提供四个属性：

Saurabh再次强调，链接(边)比顶点更重要。这些链接有很多元数据。链接多久了？哪个数据合作伙伴向我们提供了此信息？质量分数也是链接属性。这就是为什么他们需要联系才能成为一等公民的原因。

此外，看看他们的数据分析师团队，他们想要的东西对他们来说是可以理解的。这就是他们关注Apache Gremlin/Tinkerop的原因。在过去，执行SQL查询意味着他们必须进行更复杂的重量级连接，以便更深入地遍历。使用Gremlin，查询非常相似，也更容易理解。

(SELECT*FROM IDMVP WHERE ID1='；75d630a9-2d34-433e-b05f-2031a0342e42'；，IDTYPE1='；id_MID_13'；以及ID2='；5c557df3-df47-4603-64bc-5a9a63f22245'；，IDTYPE2='；id_MID_4'；)//深度=1联合(SELECT*FROM IDMPT1，IDMVP T2 WHERE t1.id1='；75d630a9-2d34-433e-b05f-2031a0342e42'；，t1.idtype1='；ID_MID_13'；以及t2.id2='；5c557df3-df47-4603-64bc-5a9a63f22245'；和t2.idtype2='；id_MID_4'；)//Depth=2联合(SELECT*FROM IDMVP T1，IDMVP T2，IDMVP T3，其中t1.id1='；75d630a9-2d34-433e-b05f-2031a0342e42'；和t1.idtype1='；id_MID_13'；以及t3.id2='；5c557df3-df47-4603-64bc-5a9a63f22245'；和t3.idtype2='；ID_MID_4'；)//深度=3？

SQL查询与Gremlin查询的并列比较。SQL查询包含629个字符，而Gremlin查询只有229个字符。如果需要更多级别的查询深度，则SQL查询将显著更长。

ZeoTAP随后从2018年8月开始进行概念验证(POC)，考虑适当的底层AWS EC2服务器群集上的一系列开源数据库：

对于PoC，所有这些群集的复制系数仅为1。他们还在3x c5.18xLarge实例上创建了客户端群集配置。

虽然Aerospike不是一个原生图形数据库，但ZeoTap对它很熟悉，并将其作为“B计划”选项，利用Aerospike中的UDF。

他们的目标是测试代表其当时现有生产工作负载三倍的工作负载，以便能够根据当前的增长预期进行扩展。然而，Saurabh再次提醒观众，自那以后，他们已经增长到超过150亿个ID。

他们的工作与标签属性图(LPG)模型非常一致，而不是资源描述框架(RDF)模型。(如果您不熟悉其中的区别，可以在此处阅读有关它们的更多信息。)。LPG模式达到了他们的预期，降低了数据的基数。

ZeoTap研究了整个系统的成本。Aerospike解决方案的成本会更高，因为它的内存(RAM)使用率很高。最终，他们决定将ScyllaDB支持的JanusGraph安装在SSD上，因为它价格实惠。

“图形DB数据模型承诺了两件事：一是模式演化方面的极端灵活性，二是领域的表现力，”Sathish插话说。然后，为了证明这一点，Saurabh分享了ZeoTap数据模型的这个例子：

每个顶点(白框)代表用户的数字身份，与其属性一起存储在JanusGraph中。它们可以包括设备的操作系统(Android或iOS)、国家(上面有西班牙和意大利的数据点)等等。

边缘(连接方框的线)表示ZeoTap的合作伙伴提供的链接。在这些文件中，您可以看到共享该特定链接的数据合作伙伴的ID(DP1、DP2等)。在特定时间(T1、T2等)。他们还会给出一个质量分数。

第一个是及物链。ZeoTap不存储预计算链接。每个查询都是在遍历时处理的。

第二种是基于存储在顶点和边中的元数据过滤遍历。例如，基于国家/地区的过滤对于维护GDPR合规性至关重要。同样的做法也可以基于质量分数来完成。客户可能只想通过高质量的链接获得结果。

三是数据模型的可扩展性。他们不能拥有要求他们根据数据模型的更改停止和重新启动数据库的数据库。所有更改都需要能够在运行中完成。在上面的示例中，“linkSource”被添加到其中一条边。如果不是数据合作伙伴，而是ZeoTap自己的启发式方法提供了联系，他们可以使用这一点。

在生产中，ZeoTap在多个区域的AWS i3.4x大型节点上运行，每个区域有三个或四个节点。

ZeoTap在他们的MVP中开始是一个批量摄取过程，但在首先通过数据的重复数据消除和丰富过程后，变成了混合流和使用Apache Kafka批量摄取到JanusGraph中。这从最初的仅批处理流程中消除了许多令人痛苦的失败，并极大地减少了每天接收数亿个新数据点所需的时间。

他们还发现，将顶点和边负载拆分成单独的Kafka流对于实现更高级别的每秒查询(QPS)非常重要，因为写入行为是不同的。顶点是单次写入，而边是查找和写入(先读后写)。

ZeoTAP工程师不仅开始测量每个节点的性能，还开始深入研究CPU利用率。他们观察到每个服务器核心每秒处理5k个事务(TPS)。

对于遍历，Sathish警告用户要注意他们的“超级节点”，他将其分为两类。第一种情况是连接到许多其他节点的节点。第二个是它的深度不断增加的地方。

萨蒂什提供的另一条建议是玩弄你的压缩策略。使用LevelTiered，ZeoTap每秒能够获得2.5倍以上的查询，并且并发客户端得到了更好的处理。

他还展示了在服务器端过滤数据可能会如何导致延迟。对某些条件进行查询过滤可能需要2.3秒，而仅提取所有未过滤的数据可能只需要1秒。因此，对于他们来说，基于属性(属性和深度)的过滤是在应用层完成的。

Saurabh随后谈到了ZeoTap开发的质量评分。它基于他们所谓的“AD评分”，即边缘一致性(A)除以边缘不一致性(D)的比率。它们还根据新近评分，然后通过事件稀有性调整对其进行修改，以得出最终质量分数。

ZeoTap还具有跨图遍历功能。这就是除了他们自己的数据之外，他们还可以搜索存储在单独的图形数据库中的第三方合作伙伴数据的地方。ZeoTap能够将这些第三方数据保存为Scylla中的单独密钥空间。针对这些的查询不是在数据库中链接在一起的，而是在应用层上链接在一起的。

最后，ZeoTAP运行ID图质量分析，其结果被反馈到他们的OLTP和OLAP系统中，以一致地确保最高质量的数据。

您可以通过观看下面的完整视频或查看我们技术讲座页面上的幻灯片来了解更多详细信息，以及了解ZeoTap的主要要点。如果您对Scylla上的JanusGraph在您自己的环境中如何工作有更多的问题，我们鼓励您与我们联系，或者加入我们的松弛来询问您在我们在线社区的同行。