图数据库

本文整顿自 NebulaGraph PD 方扬在「NebulaGraph x KubeBlocks」meetup 上的演讲，次要包含以下内容： NebulaGraph 3.x 倒退历程NebulaGraph 最佳实际 建模篇导入篇查问篇NebulaGraph 3.x 的倒退历程NebulaGraph 自 2019 年 5 月开源公布第一个 alpha 版本以来，陆陆续续公布了 2.0 GA，到当初 v3.6.0，曾经是 v3.x 版本中比拟前期的版本了。从 3.x 开始，基本上放弃了三个月（一个季度）发一个 y 版本的节奏，从 v3.1 到 v3.2，到当初的 v3.6。（演讲时 v3.6 尚未公布，所以没有相干内容展现） 而这几个版本次要是在齐备性、性能，稳定性以及易用性上的优化。从 NebulaGraph 作为一款图数据库的产品定位上来说，外围利用场景是 TP 场景，而对 TP 型数据库产品来说，有几个个性是十分重要的： 稳固：数据库作为底层的基础设施，许多业务是基于数据库运行的，是在线的零碎，因而稳定性是一个十分重要的个性。在 NebulaGraph v3.4 版本，包含最新版本的 v3.6 版本中，零碎的稳定性失去了十分大的晋升和改善；性能：因为 NebulaGraph 定位是一个 TP 的数据库产品，因而性能，包含高吞吐量是至关重要的；易用：一个好的产品要如何让用户更好地用起来，升高用户的学习老本，也是须要思考到的；针对这些个性，咱们在 v3.x 这 5 个版本中做了这些尝试： 稳定性在 v3.x 开始，NebulaGraph 引入 fuzzer，极大晋升测试效率。fuzzer 可基于 nGQL（NebulaGraph 的查询语言）的语法进行灵便组合，生成人为不能拟定的查问语句，由此让测试更加欠缺，从而进步了稳定性。 此外，版本新个性局部还新增 Memory Tracker。图数据库不同于其余数据库，数据始终处于继续地遍历、迭代中，因为即使是数据量不大的状况下，数据的迭代会导致它的后果异样大，这就造成了内存的治理压力。在 v3.4 版本中，NebulaGraph 引入了 Memory Tracker 机制，从论坛的用户反馈上，能够看得出来相干的 OOM 问题大幅度缩小了。这里能够浏览下《内存治理实际之 Memory Tracker》； ...

前段时间 NebulaGraph 3.5.0 公布，@whitewum 吴老师倡议我把前段时间 NebulaGraph 社区里开启的新我的项目 ng_ai 公开给大家。 所以，就有了这个系列文章，本文是该系列的开篇之作。 ng_ai 是什么ng_ai 的全名是：Nebulagraph AI Suite，顾名思义，它是在 NebulaGraph 之上跑算法的 Python 套件，心愿能给 NebulaGraph 的用户一个天然、简洁的高级 API。简略来说，用很少的代码量就能够执行图上的算法相干的工作。 ng_ai 这个开源我的项目的指标是，疾速迭代、公开探讨、继续演进，一句话概述便是： Simplifying things in surprising ways.这个 ng_ai 的专属 url：https://github.com/wey-gu/nebulagraph-ai 能够帮你理解更全面的它。 ng_ai 的特点为了让 NebulaGraph 社区的小伙伴领有顺滑的算法体验，ng_ai 有以下特点： 与 NebulaGraph 紧密结合，不便从其中读、写图数据反对多引擎、后端，目前反对 Spark（NebulaGraph Algorithm）、NetworkX，之后会反对 DGL、PyG敌对、合乎直觉的 API 设计与 NebulaGraph 的 UDF 无缝联合，反对从 Query 中调用 ng_ai 工作敌对的自定义算法接口，不便用户本人实现算法（尚未实现）一键试玩环境（基于 Docker Extensions）你能够这么用 ng_ai跑分布式 PageRank 算法能够在一个大图上，基于 nebula-algorithm 分布式地跑 PageRank 算法，像是这样： from ng_ai import NebulaReader# scan 模式，通过 Spark 引擎读取数据reader = NebulaReader(engine="spark")reader.scan(edge="follow", props="degree")df = reader.read()# 运行 PageRank 算法pr_result = df.algo.pagerank(reset_prob=0.15, max_iter=10)写回算法后果到 NebulaGraph假如咱们要跑一个 Label Propagation 算法，而后把后果写回 NebulaGraph，咱们能够这么做： ...

人之初，性本鸽。 大家好，我叫储惠龙（实名上网），你能够叫我小龙人，00 后一枚。目前从事后端开发工作。 明天给大家带来一个简略的为 NebulaGraph 提供 GraphQL 查问反对的 DEMO，为什么是简略的，因为原本想实现更多工作再给大家介绍的，然而上个月太忙加上下个月更忙，然而我又很想白嫖一下 Nebula 官网的奖品，所以就连忙端上来了。 体验 NebulaGraphQL先上我的项目地址：https://github.com/Dragonchu/NebulaGraphQL GraphQL 是什么先简略介绍一下 GraphQL，https://graphql.cn/ 具体的信息官网介绍得都很清晰。说一下我的了解，GraphQL 并不是对标 Cypher 这种查询语言，而是对标 REST 的一种 API 设计格调。 所以，严格意义上，不是说应用 GraphQL 查问图数据库，而是应用一种 GraphQL 格调的 API 查问图数据库，或者说是将 Cypher 封装了一样。这个实质工作和大家做利用开发时，基于 NebulaGraph 写一些通过的 REST 接口是一样的。 API 查问示例本文的测试数据集应用的 NebulaGraph 官网的 basketballplayer 数据集https://docs.nebula-graph.io/2.0/basketballplayer-2.X.ngql举个例子，如果我想“依据科比的名字失去科比的全副信息”，可能会应用上面这样的 nGQL 语句： LOOKUP ON player WHERE player.name == "Kobe Bryant" YIELD id(vertex) as vertexId | FETCH PROP ON player $-.vertexId YIELD properties(vertex);尽管说 nGQL 曾经很不便浏览了，然而如果让一个齐全 0 根底的萌新来看也是看不懂的，并且这个语句的返回值是不明确的，至多没有方法从查问看到后果。而返回值的解析始终也是很多人的苦楚。 ...

（预计浏览工夫：6分钟） 最近，TuGraph团队发展了一项令人振奋的优化工作，胜利将Antlr4 C++ target的并发性能晋升超过10倍！这一优化计划已被Antlr4开源社区激情接收，将给寰球的Antlr C++生态开发者带来更好的应用体验。PR地址： https://github.com/antlr/antlr4/pull/4237 图查问引擎是一种用于查问图数据库的工具，它应用特定的查询语言（如Cypher或ISO GQL）来执行和操作图数据库。这些查询语言容许用户形容图模式并查问图数据，例如查找特定节点或查找节点之间的门路。 对于Antlr4Antlr4是一款备受欢送的开源解析器生成器，可能依据语法规定疾速生成自定义解析器。其反对LL(*)解析，领有更弱小的错误处理能力和更快的解析速度。不仅如此，Antlr4还反对Java、Python、C++、JavaScript、Go等10种目标语言，广泛应用于多种开发语言生态中。简略易用的API和文档使得开发人员可能疾速上手。无论是编程语言、数据格式、编译器还是解释器等畛域，Antlr4都施展着重要作用。 驰名的开源我的项目如Apache Spark、Eclipse IDE和MongoDB等都抉择了Antlr4。对于语言工具开发者而言，Antlr4是不可或缺的工具，能大幅提高开发效率和代码品质。 当TuGraph遇见Antlr4ISO GQL（ISO/IEC 39075）是一种标准化的图数据库查询语言，蚂蚁团体是其次要贡献者之一。因而，Antlr4作为一种弱小的解析器生成器，成为了蚂蚁图数据库TuGraph生成GQL解释器的现实抉择。Antlr4可能帮忙团队更快、更精确地构建图数据库的查询语言，从而进步产品性能和用户体验。 然而，当咱们从开发场景来到生产场景，超高的并发量带来一个重大问题：Antlr4 C++ target的并发性能不足以反对所需的超高并发GQL申请。通过调研并与Antlr开源社区探讨，咱们发现并发性能这个问题普遍存在，并且在过来5年中继续困扰着C++生态的开发者。咱们决定解决这个问题。 咱们做了哪些工作在调研探讨的过程中咱们发现，多位开发者在论坛提出其耗时甚至多于Java target数倍之多，见文末参考【1，2，3，4】。因而，咱们决定从问题和开源代码登程，来定位、解决问题。 这是一个典型的并发程序优化问题，依据以往的程序优化教训，咱们分步推动该问题的解决： （1）辨认问题 通过对程序运行时的性能数据进行收集和剖析，咱们找到了程序运行瓶颈所在，通过调用剖析，初步将问题定位为数据竞争导致的并发问题。 （2）深刻浏览Antlr4开源代码 接下来，咱们对Antlr4的源代码进行认真的浏览和了解，把握其外部的构造和外围逻辑，找出了外围的数据结构和要害的调用链路。为咱们破解性能难题和剖析批改的正确性做好了筹备。 （3）梳理数据竞争链路 根据上述剖析，咱们判断问题的症结极大概率是数据竞争造成的。造成数据竞争至多有两个条件：一是线程之间共享内存数据，二是至多存在两个线程去读写某个共享内存。 进一步地，咱们通过分析程序中的并发拜访状况，找到了可能引发数据竞争的所有代码段和共享变量（次要为DFA、ATN等构造），拼接出了数据竞争的残缺链路。 （4）破解数据竞争问题 数据竞争问题是多线程程序中常见而又简单的问题，能够思考通过破解多种竞争条件来解决。就本文问题来说，也存在多种破解计划抉择，如何制订最优的解决方案是一项极具挑战的工作，次要难点有两个： （i）保障批改后程序的正确性/稳定性 （ii）保障计划的有效性（低成本） 重复推演后，咱们抉择了提交给社区的优化计划（PR地址见参考【6】），即通过扭转要害数据的ownership接触对锁的依赖。针对上述两个难点的剖析如下： 通过源码剖析并与开源社区探讨，咱们确认要害数据结构的初始化构建是十分耗时的，但能够通过“只调用一次”（\`call_once\`）伎俩将老本均摊，而后续的增量构建绝对开销较低，并且也可均摊。因而该优化计划的低工夫老本是能够保障的。 对于程序正确性的保障，咱们通过双重验证来保障。首先在设计之初咱们曾经从源代码角度，推断出共享数据依然是平安的，其次咱们也设计了试验对此进行了验证，验证后果与咱们的剖析统一（见下图）。 奉献和成绩优化的成果非常显著，32线程的并发性能晋升超过18倍，如下图所示（16外围CPU测试平台，性能测试代码仓库见【5】）。思考到理论生产服务器性能远高于测试机型，理论的性能晋升成果将比测试后果更高，优化后GQL解析能力已能齐全满足企业业务的须要。 充斥播种的社区互动 提案的互动过程波折也充斥乐趣。当波及到多线程代码的批改时，官网开发团队会分外审慎，因为这波及到零碎的稳定性和性能。他们会进行认真的测试和评估，确保批改不会引入新的问题或升高零碎的性能。为此社区引入了多达7名评审专家（个别提案的评审人多为1~2人），长达60屡次的重复探讨不仅是评审专家了解提案的过程，也让咱们理解了很多Antlr4代码背地深层的设计理念，能够更好地利用它来构建高性能、可保护的语法分析器。 通过此项优化工作，咱们播种了更多与其余社区贡献者合作的教训，多位Antlr4社区成员也对TuGraph团队的工作表白了感激，Antlr4负责人评估该提案为“一个重大的奉献”（a major contribution）。 参考文献【1】antlr4 doesn't scale on a computer with 8 or more cores, https://github.com/antlr/antlr4/issues/2454 【2】Parsing with C++ target 5x slower than Java, https://github.com/antlr/antlr4/issues/2584 【3】Performance Issues Running Cpp Runtime on Many Threads, https://github.com/antlr/antlr4/issues/3938 ...

本⽂整顿⾃ NebulaGraph x 阿⾥云计算巢专场中众安保险的⼤数据应⽤⾼级专家曾⼒带来的《众安资产在 NebulaGraph 的应⽤实际》分享，视频⻅链接。⼤家好，我是众安数据迷信应⽤中⼼的曾⼒，明天很⾼兴在这⾥能够跟⼤家分享 NebulaGraph 在众安资产的实际。 01 基于事件的数据资产平台设计在理解这⼀切之前，咱们须要先晓得什么是资产治理平台以及它能够解决什么样的问题。 资产治理平台是全域的元数据中⼼，它能够对数据资产进行治理监控，解决企业外部的数据孤岛问题，开掘数据价值并对业务赋能。它次要解决咱们数据找不到、数据从哪⼉取，排查门路⻓、数据复⽤率低这四个十分核⼼的关键问题。 设计指标 对于资产治理平台，咱们有三个⾮常重要的设计⽬标—— 强扩大：是指实体关系定义、资产操作以及资产查问的扩展性。低耦合：是指资产平台与其余零碎对接时，对接入零碎业务流程零影响。高时效：是指须要近实时的数据采集、疾速的数据处理和查问性能。外围性能 数据资产治理平台核⼼性能包含以下三个： 类型定义：需提供⼀个形象的设计定义不同的实体/关系，以及它们蕴含的属性。每个定义的实体/关系均须要定义唯一性束缚，用于数据判重。在此基础上咱们能够扩大一些定义类型，比方标签、术语、标签流传等等。元数据采集：次要有通过周期性、流式和手工录入三种形式进行数据采集。元数据管理：数据存储常见的选型是关系型数库存储定义或数据，搜索引擎存储数据、变动记录、统计类信息，图数据库则负责关系查问。数据分析常见的场景是数据地图、血统及影响性剖析、全链路血统剖析。数据利用则是在相干数据采集到平台后，能够疾速实现资产割接、数据安全治理以及数据治理等更高层次利用需要。类型定义 开源零碎 Apache Atlas借鉴于开源零碎 Apache Atlas 和 DataHub，咱们来初步理解类型定义设计的外围因素。 Atlas 的类型定义模式是一套基于 JSON 的 TypeSystem，能够自定义扩大，它的外围概念是实体、关系和属性，并在此基础上扩大出分类、术语、业务数据等定义设计。 DataHub 则采纳 Avro 进行事件模型的定义、PEGASUS 建模语言进行实体、关系和属性的建模，值得一提的是 Aspect 这个概念，其形容实体特定方面的属性汇合，同一实体关联的的多个 Aspect 能够独立更新，雷同的 Aspect 也能够再多个实体间共享。DataHub 预置了一些实体和关系模型，咱们能够复用这些模式或自定义新模型。 通过两个开源零碎的类型定义设计，咱们不难看出实体、关系、属性是元数据系统当中最根底的三个外围类型定义的元素。基于整体的架构、外部数据模型场景、数据存储选型、学习老本等方面因素的思考，众安数据资产平台的类型定义是参照 Apache Atlas 的 TypeSystem 设计，定义一套独立的类型定义零碎。 实体类型定义 EntityDef 的外围因素是类型名称、父类型名称和属性列表。 对于类型名称，须要单租户下束缚惟一；对于父类型名称，其实就是对一些公共属性集的复用，相似于 Java 类的继承机制，咱们能够通过获取父类型及其超类的所有属性。目前为不便类型解析，一个实体仅能定义一个父类型。对于属性列表，一个实体能够有 1~n 个属性，且至多有一个唯一性属性。 关系定义 RelationshipDef 的外围因素是定义名称、关系类别、起始/完结端点定义和属性定义； 对于类型名称，须要单租户下束缚惟一；对于关系类别，依据是否容器关系和端点实体生命周期分为三类。 Association 关系：是一种非容器关系，比拟典型的例子是调度作业的依赖关系，两者之间不为蕴含关系，且生命周期独立。Aggregation 关系：是一种容器关系，但端点实体的生命周期独立，比方咱们的报表零碎，数据模型和画布关系，画布蕴含模型，但模型能够独立于画布而出存在，生命周期独立。Composition 关系：是一种容器关系，且端点生命周期完全一致，最直观的例子是表和列之间的蕴含关系，删除表的时候列实体主动被删除。对于端点定义 RelationshipEndDef，端点即是实体关系中关系实体的映射，所以须要定义起源和指标两个端点。每个端点定义须要端点的实体类型名称以及是否为容器。如果关系类别是⼀个容器类型的关系的话，须要设置某⼀个端点容器标记为 true，此时边方向是子项实体指向容器实体。如果关系类别是非容器的关系的话，所有的端点容器标记都须要设置为 false，此时边方向是端点 1 实体指向端点 2 实体。 ...

2023 年 03 月 26 日 14:00-16:30，TuGraph MeetUp 第二期-北京站，带来图技术利用场景实战，来自金融、电力科技领域的 4 位资深技术专家，将就图技术利用场景实战进行深度分享。大家也可就各自感兴趣的畛域，与嘉宾探讨图技术的潜在利用能力。期待与大家线下见面！ ☆ 解锁图技术利用场景实战 ☆ 走进蚂蚁北京，与技术大咖面对面，参加现场互动 ☆ 技术交换，答疑解惑 线下会场：蚂蚁团体北京办公室 （北京市朝阳区环球金融中心东塔 8 楼国子监会议室） 线上直播：https://www.modb.pro/event/801 扫码入群报名 社区 官网：https://tugraph.antgroup.com/ GitHub：https://github.com/TuGraph-family/tugraph-db Gitee：https://gitee.com/tugraph/tugraph-db ▼ 关注蚂蚁图计算，理解最新资讯 END

如果你读过「NebulaGraph 错题解析第一期」，大略晓得在错题解析未进去之前，NebulaGraph 专业技能认证 NGCP（全称 NebulaGraph Certified Professional）的通过率仅有 16.7%。然而，通过上一轮 NebulaGraph 认证考试出题人错题解析的致力下，这次 NGCP 的通过率回升 0.1%，当初变成了 16.8%。出题人痛定思痛，决定再开一期错题解析，如果你两期都看了，运气足够好，当初去考 NGCP 闭眼就是 19 分起步了，你导再也不放心你从零考起了。 上面，来看一眼这期错题解析有哪些难题呢？ 题 1：「判断题」目前 NebulaGraph Studio、Explorer、Dashboard 社区版、Dashboard 企业版登录时的身份验证是基于 NebulaGraph 自身的身份认证逻辑。 正确答案：谬误 解析： NebulaGraph Studio、Explorer 和 Dashboard 社区版登录时须要输出 NebulaGraph 自身的账密，然而 Dashboard 企业版因为须要治理所有 NebulaGraph 集群，所以有本人的独自一套权限管理系统，登录时能够应用多种账户类型。参考文档：https://docs.nebula-graph.com.cn/3.3.0/nebula-dashboard-ent/5.account-management/ 题 2：「单选题」NebulaGraph 的第一个开源版本是 A. v0.1.0 B. v0.0.1 C. v1.0.0 D. v0.0.1 正确答案：A 解析： 2019.5 公布了 v0.1.0 alpha 版本并开源。参考文档：https://docs.nebula-graph.com.cn/3.3.0/20.appendix/history/ 题 3：「单选题」下列对于大小写的说法，谬误的是 A. 标识符辨别大小写 B. 保留关键字不辨别大小写 C. 函数不辨别大小写 D. 非保留关键字辨别大小写 ...

一、NebulaGraph ExplorerNebulaGraph Explorer 是一款能够通过 Web 拜访的可视化图摸索工具。基于 NebulaGraph 内核与图数据进行可视化交互，反对从简单关系和大量数据中疾速查找友邻关系、剖析可疑指标、执行图计算剖析，并以可视化的形式展现图数据。帮忙用户轻松地进行业务数据的剖析和摸索，疾速发现数据中的关联关系。 发版信息版本号：NebulaGraph Explorer v3.2.0 发版日期：2022.11.08 可用性阐明NebulaGraph Explorer 为企业版产品，如需获取安装包，请分割咱们。 点击开启 Explorer 30 天收费试用点击云上疾速开始（30 天收费）部署环境：反对 Linux 零碎和 Ubuntu 零碎，目前仅反对 x86_64 架构。提供 tar/deb/rpm 三种格局的包供装置部署，同时也反对在云上部署。 浏览器兼容状况：Chrome >= 84 内核兼容状况：兼容 NebulaGraph v3.3.0 亮点性能本次公布的最新版本 v3.2.0 次要在产品易用性和安全性方面做了较大的晋升。 易用性方面，一是优化了图查问+图计算+图交互式剖析等方面的操作，包含可视化建模、iFrame 模式，二是在性能、加载速度上有了很大晋升。 安全性方面，此版本开始反对 OAuth2.0 认证，进一步晋升平台与数据安全性。 更新详情性能图建模 Schema 草图：反对间接在画板上通过利落形式设计 Schema，并一键利用至图空间，便于更加高效直观地建设业务场景模型图建模 图建模 demo 图查问 查问语句模版化：反对在控制台间接将nGQL语句制作为模版，后续可间接调用模版，填入参数即可查问。图查问 demo 图剖析 边聚合：反对对画布上终点、起点、边类型雷同的边进行聚合，使得哪些点之间存在大量关系高深莫测。并反对对聚合边的属性进行计算。 自定义图标库及点边款式：内置十种不同类型图标分类，并反对上传自定义图标图片，使得图剖析过程更加直观活泼。 图计算 工作流增加 Node2Vec 算法：新增图特色算法 Node2Vec，实用于节点性能相似性比拟、节点构造相似性比拟、社团聚类等场景。可集成 iFrame 模式：反对将画布间接 iframe 集成至第三方页面中应用，缩小大量开发成本。数据安全 数据库用户治理：反对以可视化的形式治理数据库用户、对指定图空间受权等操作，隔离不同业务畛域，保障数据安全。 - **OAuth 2.0 认证**：反对开启 OAuth2.0 认证，保障平台和数据安全，轻松进行企业治理。体验优化 ...

NebulaGraph 3.3.0 反对了 GET SUBGRAPH 和 GetNeighbors 的点过滤、引入了大量性能优化，同时，开始对无 tag 顶点的反对默认敞开。 优化优化了 k-hop 查问性能。#4560 #4736 #4566 #4582 #4558 #4556 #4555 #4516 #4531 #4522 #4754 #4762优化 GO 语句 JOIN 性能。 #4599 #4750反对 GET SUBGRAPH 过滤点。 #4357反对 GetNeighbors 过滤点。 #4671优化了 FIND SHORTEST PATH 的循环解决。 #4672反对工夫戳和日期工夫互相转换。 #4626反对模式表达式援用部分定义变量。 #4498优化 job manager。 #4446 #4442 #4444 #4460 #4500 #4633 #4654 #4663 #4722 #4742增加试验性能的 flag，TOSS 的 enable_toss 和 BALANCE DATA 的 enable_data_balance。 #4728启动过程时统计日志打印到控制台。 #4550反对 JSON_EXTRACT 函数。 #4743 ...

近期，杭州悦数科技有限公司与阿里云计算巢达成单干，NebulaGraph 作为首款图数据库产品正式入驻阿里云计算巢，为用户带来了云端一键部署企业级图数据库集群的全新体验。同时，该服务集成了多款 NebulaGraph 周边可视化图数据库管理工具，让用户在云端也能够疾速从数据中取得洞察力。 近年来，图数据库的概念被越来越多的企业重复提及。图（Graph）是一种存储实体，及实体之间关系的数据结构，而图数据库（Graph Database）则是一个应用图数据进行存储，同时应用图构造进行语义查问的数据库。 图数据库可能高效地将关联数据的实体作为顶点（vertex）存储，关系作为边（edge）存储，并容许对这些点边构造进行高性能的检索和查问，也能够为这些点和边增加属性。正因为具备这些个性，才使得图数据库可能以最靠近直观认知的模式存储数据，并且可能将这些关系完满地出现进去。 01 图数据库的发展趋势为什么要应用图数据库，而不是关系型数据库？关系型数据库实现了疾速的逐行拜访和数据一致性（ACID 事务），但当数据规模变大且数据间关系变得复杂时，应用关系模型检索时须要多个表的属性执行连贯操作，数据写入时也需思考外键束缚，从而导致较大的额定开销，对性能有极高的要求。而图数据库则在解决简单关系上有着人造劣势，尤其在海量数据多对多的简单实体分割场景中有着异样突出的体现，次要体现在性能、灵活性和敏捷性三个方面。 <center>关系数据库 vs 图数据库（多跳查问）</center> 其次，图数据库是基于图模型以一种直观的形式存储和展现这些关系。因为是基于事物关系的模型表白，图因而也具备人造的可解释性。 目前，图数据技术因其在解决海量关联数据时的人造劣势和合乎人脑直观印象的展现模式正被利用在多个行业的生产环境和业务实际场景中。例如，数据集成（常识图谱）、个性化举荐、欺诈与威逼检测、危险剖析与合规、身份（与控制权）验证、IT 根底 设施治理、供应链与物流、社交网络钻研等，甚至于 AI 机器学习、NLP（自然语言解决）、区块链等新兴技术畛域，你都能够看到图数据技术的身影。 上云的趋势在减速，对于弹性能力提出更高要求依据 Gartner 的预计，云服务始终放弃较快的增速和渗透率。大量的商业软件，正在从 10 年前齐全公有本地逐渐转向基于云服务的商业模式。云服务的一大长处是其提供了近乎有限的弹性能力，这也要求各种基于云基础设施的软件必须有更好的疾速弹性扩缩容能力。 在此背景下，开源分布式图数据库 NebulaGraph 成为了阿里云计算巢上第一家图数据库合作伙伴，与阿里云一起帮忙更多企业用户更好地进行低成本、高效率的云上图数据库部署。 “对于数据库产品来说，底层基础设施的稳定性以及安全性对于客户来说至关重要。阿里云是国内当先的云计算提供商，咱们看重其稳固的基础设施和安全性，此次与阿里云计算巢的单干，通过阿里云计算巢更高效地利用底层资源的弹性扩缩容以及便捷的服务编排等能力，能够使咱们的客户释怀、省心地应用基于云上的 NebulaGraph 产品。”NebulaGraph 创始人兼 CEO 叶小萌示意。 什么是云原生图数据库？云原生，即云上内生的云能力，人造就“生于云，长于云”，基于对立的架构和云原生基础设施，实现多云/混合云解决方案、边云协同等能力。云原生时代下，企业应用数据的形式产生了根本性变动，即基于对立云基础设施的云原生数据库、大数据解决方案，将成为企业数字化转型的数据底座。 传统模式下，企业洽购硬件资源，数据库部署在自建 IDC 并由企业监管和运维。企业的开发人员则采纳 DevOps 模式或安顿 IT 人员来管控数据库。接入业务后要时刻关注数据库集群状态来保障可用性，这对数据库外部实现不太理解的用户来说是个微小的挑战。而云计算作为技术载体，人造具备逾越时空的劣势，云技术正在从繁多的计算能力倒退为体系化的翻新。对于企业来说，“上云”是一个技术抉择、是企业数字化的终点，而基于云构建新的生产关系，打造新的业务增长引擎则是一个策略抉择。 NebulaGraph 是一个牢靠的分布式、线性扩容、性能高效的图数据库，其 Shared Nothing 和存储计算拆散的底层架构让它具备了云原生的特色，能够无效降低成本和弹性扩缩容。而云端部署则屏蔽了数据库部署、性能调优、运维等繁冗过程，几分钟内就能够在云上创立一个图数据库，并疾速扩大计算、存储等资源。 作为可能包容海量关联数据并进行毫秒级查问延时的高性能图数据库产品，NebulaGraph 曾经被多家行业当先的科技和通信公司利用在反欺诈、危险管制、社区发现等场景，其中某头部互联网公司的 NLP 团队也基于 NebulaGraph 搭建了本人的图数据库平台，目前曾经有 60 多条业务线接入应用，在智能助理、搜寻召回等业务场景均已落地。 NebulaGraph 在阿里云上部署的架构图 02 在云上部署 NebulaGraph 有哪些益处？开箱即用：疾速部署更不便因为云厂商提供了对立的基础设施，企业无需自行洽购硬件，还能够依据业务的灵便度和资源需要弹性调配云资源，实现疾速上线。基于阿里云计算巢提供的 ROS（资源编排），NebulaGraph 实现了云上自动化部署，几分钟内即可交付一个图数据库集群，相比传统以天、甚至以周为单位的交付周期，有极大的晋升。 其次，NebulaGraph Cloud 反对包年包月与按量付费的灵便付费形式，节俭新购设施、自建机房等一次性建设费用，当不再须要的时候能够及时销毁，显著升高了研发老本。为了进一步的优化体验，下一阶段 NebulaGraph 还将联合本身在云上的优化个性和测试后果，陆续推出高性价比的云服务器规格套餐，让用户以更低的价格取得更高的性能，大家无妨也刮目相待一下。 ...

本文首发于 NebulaGraph 公众号 前言图数据可视化是古代 Web 可视化技术中比拟常见的一种展现形式，NebulaGraph Explorer 作为基于 NebulaGraph 的可视化产品，在可视化图数据畛域，尤其是在图形渲染性能等畛域积攒了较丰盛的教训。本文将系统性分享 NebulaGraph Explorer 在 3D 图数据展现上的一些利用。以下演示皆可在 https://explorer.nebula-graph... 在线试用。二维力导图目前业界罕用的图数据展现都采纳 2D 力导图的逻辑，如下图所示：这种二维化的可视化模式，在图形语义上对物理世界数据进行了降维，通过点、边形态来形容实体和关系，合乎人脑的习惯性直觉，简化了图数据的了解老本。D3-force，G6 等所采纳的就是这样一种布局模式，也是大部分图类场景的根底算法。其布局的力导算法则是大部分基于经典的 Fruchterman 布局算法，模仿弹簧的胡克定律和物体的万有引力，制作互相牵引和排挤的力算法，再通过模仿冷却收敛，最终失去缩小穿插、步长等距、点拆散独立 的二维图布局。这也是可视化的根本诉求，即可能无遮挡地清晰查看各类繁冗的数据。然而，2D 场景并不一定实用所有场景，次要有以下起因：空间信息展现局部数据具备原生的空间坐标信息，且这部分信息也不可降维，如分子结构、经纬度的球坐标展现、具备层级高度的数据等。这类数据通过 3D 展示会更合乎人的习惯和直觉。大数据量布局展现在较大的数据集状况下，因为 2D 没有深度，导致所有的数据须要被平铺在画布上，能够设想一个西瓜的所有西瓜籽平铺的状况，占地面积要远远大于西瓜自身。因而这种状况须要将数据自身信息可视化还原，就须要 3D 可视化技术来实现了。图数据 3D 可视化图数据的 3D 可视化在逻辑上和 2D 比拟像，咱们个别仍然是采纳 2D 的 Fruchterman 力导图逻辑，也仍然须要尽量避免穿插遮挡，但维度升了一维，逻辑简单的也回升不少。因而咱们从新自研了 3D 力导向算法来取得更好的成果和性能。能够看到下图同样的简单网络关系中，3D 显示则会有较为明确的关系展现。提供不同角度的图构造对于高密度的点边，能够像 3D 游戏一样，将视角转移，切换，察看到不同角度的图数据结构 雷同的数据也能够有齐全不同的可视化成果。提供鸟瞰视角在 3D 鸟瞰状况下，能够将点再空间方向散射开，同样数据量下，画布能清晰的标识出节点团簇，也能够轻松的辨认出超级节点。通过屏幕内的整体色彩散布，能大抵看进去整个可视化图中的节点 Tag 占比。身临其境的体验感用户能够再整个空间内搜寻节点，间接定位到对应节点上，查看相干连的其余节点数据。高性能可视化目前咱们的 3D 可视化能够反对 10w 点，10w 边同时渲染。渲染数量是由渲染性能，布局计算性能，内存占用，网络速率，NebulaGraph 性能等各方面因素综合决定的，下限次要由硬件和内部条件限度(网速，客户度机器配置，NebulaGraph机器性能)决定，上限则是由图形渲染及布局算法决定。咱们为了进步上限，自研了图形渲染和布局算法局部，失去了较好的成果。海量数据渲染WebGL 是 web 端间接利用 GPU 进行渲染的形式。咱们为了进步每一帧的图形渲染能力，在 3D 模式下采纳 WebGL 来进行渲染。并且反对高下性能模式： 别离通过原生 shader 和 Mesh 绘制，用户能够依据本人电脑终端的硬件状况抉择对应的渲染模式。其中高性能模式下，咱们通过自研优化的 shader，利用 GPU 并行计算的能力，将一些渲染成果放到着色器中计算，极大的进步了渲染速率，让渲染性能不再成为瓶颈。这也基本上达到了目前浏览器的极限。疾速算法布局在图布局算法方面，咱们用八叉树优化了力导过程的算力耗费，并且针对应用 LinLog 模型对超级点进行了受力优化，因为算法性能耗费比拟大，咱们应用 Golang 对八叉树算法和力导算法进行了重写，最终能够反对在 20w 图元的状况下，预热实现后稳固在 1s 以下实现一次运算。另外为了图布局计算不影响前台页面渲染，咱们利用多个 worker 过程，将不同的 CPU 工作散布上来，这样木桶的各个短板不会影响渲染和交互的长板，用户在布局的时候仍然能够灵便的操作。利用上述的一些伎俩，咱们将 3D 可视化的性能简直晋升到浏览器极限，对于一些不大的图空间数据，齐全能够一次性载入剖析。后续方向因为 3D 模式的开发复杂度较 2D 晋升较多，因而目前仅用于一种非凡的图数据展现形式。在将来，咱们会综合理论的业务场景，进行更多的体验优化。时序及 GIS 畛域的图布局映射图数据坐标到渲染中减少边的相干交互行为 ...

本文首发于 Nebula Graph Community 公众号作者介绍大家好，我是 Anyzm，graph-ocean（GitHub：https://github.com/nebula-con...）我的项目发起人，目前就任于 360数科，岗位是高级 JAVA 开发工程师。 介绍完本人，这里来介绍下 graph-ocean 是什么？ graph-ocean 简介graph-ocean 是一款基于 nebula-java 客户端的 ORM（Object Relational Mapping）框架，相熟 ORM 的小伙伴应该都晓得 ORM 是创立可在编程语言里应用的“虚构对象数据库”，让开发人员更高效地开发业务。 而我将 Java ORM 取名为 graph-ocean 源自 Ocean 与 Nebula Graph 的 Nebula（星辰）相响应，意为星辰大海。 为什要设计一款 Java ORM社区用户如果对 360数科相熟的话，读过咱们技术团队写的《JanusGraph 到 NebulaGraph 迁徙》（链接：https://discuss.nebula-graph....）便晓得咱们在 Nebula Graph 很晚期便开始应用它，在官网正式公布 v1.0.0 之前就曾经在测试环境跑起来了。 在 360数科应用 Nebula Graph v1.0.0 过程中，咱们 Java 客户端是用枚举来呈列用到的 Tag 和 Edge 数据，而将 API 解析成 nGQL 的过程中也强依赖枚举，对业务代码侵入性强。 所以，在起初接触我的项目的过程中我就信心扭转这种场面。 解决代码入侵问题咱们都晓得无论是什么框架与数据库连贯，框架最终都是会解析成数据库所能辨认的语言。对于 Nebula Graph 而言，用户能够应用 openCypher，也能够应用 Nebula Graph 原生查询语言 nGQL。 ...

本文首发于 Nebula Graph Community 公众号前言Nebula Graph 自身提供了高性能的 OLTP 查问能够较好地实现各种实时的查问场景，同时它也提供了基于 Spark GraphX 的 nebula-algorithm 库以便反对实时的图算法，这里给 Nebula 点个赞，很不错！ 但实际过程中，我发现局部 OLAP 场景中，想实现模式匹配剖析，Nebula 的撑持就显得不那么欠缺了。 这里我对模式匹配的解释是：在一张大图中，依据特定的规定抽取出对应的子图。 举一个简略的例子，比方想要对每个点都进行二度扩散，并依照肯定逻辑过滤，最终保留符合要求的二度扩散的子图，这样的工作用 nebula-algorithm 就不太好实现了。 当然，下面这个例子咱们能够通过编写 nGQL 语句——查问出对应的数据，但 Nebula 的劣势在 OLTP 场景，针对特定点进行查问。对于全图数据的计算，无论是计算架构还是内存大小都不是特地适宜的。所以，为了补充该局部（模式匹配）的性能，这里应用 Spark GraphX 来满足 OLAP 的计算需要。 GraphX 介绍GraphX 是 Spark 生态的一个分布式图计算引擎，提供了许多的图计算接口，不便进行图的各项操作。对于 GraphX 的基础知识我这里不进行过多的介绍了，次要是介绍一下实现模式匹配的思路。 实现模式匹配次要是依赖于一个重要的 API：PregelAPI，它是一种 BSP（BSP：Bulk Synchronous Parallel，即整体同步并行）计算模型，一次计算是由一系列超步实现的。 只看定义不是特地好了解，所以间接介绍它在 GraphX 中的实现，理解它是如何应用的。 Pregel 运行原理源码定义如下： def pregel[A: ClassTag]( initialMsg: A, maxIterations: Int = Int.MaxValue, activeDirection: EdgeDirection = EdgeDirection.Either)( vprog: (VertexId, VD, A) => VD, sendMsg: EdgeTriplet[VD, ED] => Iterator[(VertexId, A)], mergeMsg: (A, A) => A) : Graph[VD, ED] = { Pregel(graph, initialMsg, maxIterations, activeDirection)(vprog, sendMsg, mergeMsg) } 相干参数含意如下： ...

本文首发于 Nebula Graph Community 公众号 “为了反对城市简单场景下各类需要，中科大脑常识图谱团队设计开发了一套蕴含本体可视化设计、数据映射、数据抽取、数据写入、图数据摸索的一体化平台，而本文则具体介绍了他们的业务背景、技术选型、平台建设等内容。” 01 背景介绍中科大脑作为一家城市级的数字资产运营商，一方面要对各种类型的数据进行高效存储，另一方面面临如何将各类数据充分利用的问题，传统 NoSQL、SQL 不能齐全满足数据的存储和利用，以图数据库为根底的常识图谱肯定水平上能够解决这些问题，常识图谱组件（KBU）是脑库城市大脑产品的核心部件。 中科大脑外部对常识图谱的需要，总体来说有以下 3 方面： 政务常识图谱，将政策法规、证件资料、事项流程、组织架构等信息纳入常识图谱。目前建设了面向公安户政、电子政务畛域事项办理常识图谱，针对不同的职能部门建设有不同的常识图谱，晋升了服务效率和品质。资产设施治理图谱，对城市中大量公共设施、不动产、物联网设施等建设常识图谱，造成联动治理与运维。事理常识图谱，对城市重大事件、突发事件、集中投诉事件等建设事理图谱，包含事件的工夫、地点、主体及热度等，发现事件间的关联关系和演变法则，提供决策反对。实际中，不同板块的常识图谱间并非齐全孤立，而是依据利用需要进行交融，充分发挥图谱的关系链接个性，将城市本体因素买通，实现联动，解决数据的关联存储和开掘。02 图数据库选型在数据高度结构化、一致性强场景下，个别抉择应用传统的关系型数据库；在数据具备宏大潜在关联场景下，图数据存储及基于此的常识图谱技术将会是正当的抉择。调研中发现，与关系数据库或其余 NoSQL 数据库相比，图数据库的数据模型也更加简略，更具表现力。图数据库在社交网络、金融风控、个性化举荐、网络安全等畛域利用宽泛。咱们在图数据库选型方面次要思考点：1）功能齐全、性能弱小；2)我的项目开源，反对灵便的二次开发；3）安全可靠，国产优先； 中科大脑早起进行了一些性能和性能比照，也参考美团、腾讯相干测评，从测试后果看 Nebula Graph 在数据导入、实时写入及多跳查问方面性能均优于竞品。此外，Nebula Graph 社区沉闷，对相干 issue 的响应速度快，所以团队最终抉择了基于 Nebula Graph 作为图数据库平台根底。 03 常识图谱构建平台常识图谱构建包含业务规定制订、本体构建、常识抽取、常识交融、数据存储等流程，往往须要业务专家、工程、算法、项目管理等人员参加配合。有机整合以上环节和分工，将大大减少常识图谱落地速度，目前尚未有开源产品满足此需要。为了反对城市简单场景下各类需要，咱们设计开发了一套蕴含本体可视化设计、数据映射、数据抽取（结构化、非结构化）、数据写入、图数据摸索的一体化平台，平台构造如图。 项目管理常识图谱平台将不同畛域常识图谱作为我的项目单元，每个我的项目独立进行常识全流程构建与治理。我的项目中包含本体设计、数据映射、数据抽取，依照流程一步步进行（step-by-step），不同的阶段做到“术”、“业”专攻。平台实现了企业外部常识图谱构建的标准化和部门合作，缩小了不同阶段人员间的沟通老本、数据安全性问题，大大提高了效率。 本体设计常识图谱的建设不齐全是技术工作，在本体设计阶段，业务工作可能占据一半以上工作。业务专家往往又不理解常识 schema 设计，通常的流程是业务专家以非标准形式标记常识，带来了较多的返工，不同专家之间和专家与技术之间存在合作问题。针对这些痛点，构建平台借鉴开源我的项目实现本体的在线设计，反对多种格局（OWL、RDF、RDFS）的文件导入、导出，兼容性较好，经测试OpenKG中90%以上资源可间接接入。可视化的构建形式真正实现了以图构图。 数据抽取本体构建实现，对结构化数据，反对对 EXCEL、CSV 等关系型数据与本体建设映射，实现图数据的写入。对非结构化数据的图谱抽取，平台内置了模型服务进行三元组抽取。内置模型分为两种，第一种是基于开源数据集，如百度 DuIE 2.0，满足通用数据抽取，另一种从本身业务登程，设计模型。咱们设计了针对市民热线的事件及要害信息抽取模型，从图谱角度开掘市民热线不同函件间的关联关系，对事件抽取设计了联结抽取模型，联结抽取模型较管线式模型（pipeline）在时效和准确率上有较大晋升。 图摸索结构化数据导入和非构造数据化抽取后果将被写入到 Nebula Graph 数据库，图摸索能够不便地实现对写入常识的查问显示，同时能够通过常识搜寻框间接对点和边信息进行搜寻。构建者更加简略地实现了常识检索、摸索和聚合。产品性能要点： 常识展示，为了能对图谱有直观查阅，在图谱摸索阶段，退出了主动展现子图性能，相似 Neo4j中 MATCH (n) RETURN n LIMIT 25），次要是通过简略算法发现图谱中心点，再由度数来管制从中心点登程的子图大小，同时避免了展现爆炸。常识搜寻，反对点和边进行含糊匹配，更好地实现常识发现和举荐；常识计算，内置轻量级图算法，能够对节点出入度、核心度、族群、类似节点类等进行计算。 为了满足本身产品利用，咱们基于 Nebula Graph、Elasticsearch、NetworkX 等底层接口，开发了一系列 API 利用接口，将来咱们 API 接口实现也将积极参与到开源中。 04 业务落地智能问答围绕公安户政常识建设了畛域常识图谱，设计常识图谱问答（KBQA）零碎 ，反对多实体多跳（Multi-hop）匹配和推理。基于脑库常识图谱组件和脑库时空构建组件将空间和非空间数据联合，实现空间推理，市民可能会征询，“能够办理出国签证的机构都在哪儿？”通过常识图谱语义问答和 GIS 的联合，将地位和相应的属性精准返回，实现常识和地图的可拜访及互操作，为城市服务提供便捷。 ...

背景现实生活中的很多数据都能够建模成图（Graph）这一形象的构造。这种高效紧凑的数据模式能够示意出拓扑、属性、时序等丰盛的信息，而图计算的指标就是从图构造中挖掘出有价值的常识或法则，例如频繁模式、因果关系等。随着信息时代的到来，数据规模呈爆炸式增长，产生了对大规模的图数据进行高效解决的需要，图计算曾经成为了工业界和学术界的热点话题，并因而诞生了一系列的图计算零碎及优化钻研工作。简单的业务场景，以致图数据的计算类型也是多种多样的。目前，存在着三种最次要的图计算类型，别离是图查问、图剖析和图学习，上面咱们就逐个地进行介绍。图查问通常来说，图数据十分宏大，而图数据的交互式查问只关怀其中满足条件的比拟大量的点和边。如下图所示，这些点和边会造成特定的门路，或者子图模式。例如，从一个中央到另一个中央的最优路线，或者物流的门路信息，都是典型的门路查问场景。子图模式是另一种类型的图查问，它用子图示意某种模式，而后用这个子图在全图中进行匹配查问。 门路查问（右）和子图查问（左）门路查问的实质是图的遍历，通常依照如下的步骤进行：首先将图上特定的顶点设为待查点；而后每个待查点通过本人所连贯的满足条件的边找到指标端点汇合，查看指标端点是否满足查问指标；如果满足则将该指标端点放入后果集，否则将该指标端点设置为新的待查点。始终反复这样的步骤，直到没有待查点。简略来说，就是在图查问的整个过程中，依照用户指定的条件，一步一步在图上游走遍历，并最终取得想要的后果。另一种类型的图查问，即子图查问，其实践根底是子图同构。用户须要给定待查问的子图（点、边以及它们所要满足的条件），而后从数据图上查找所有满足条件的后果，使得：每个后果是数据图上的子图；该子图和查问图是同构的；且该子图所映射的点和边满足查问图上对应点和边的查问条件。简略来说，就是在大图中去寻找用户关怀的某种特定构造。图查问最典型的两大支流语言，别离是 Gremlin[1] 和 Cypher[2]。Gremlin 基于 Groovy，但有许多语言变体，容许开发者以 Java、Python 等编程语言原生编写查问。它既蕴含命令式也蕴含申明式的语义，能不便表白图遍历的逻辑，所以被泛滥图数据库系统采纳，例如 JanusGraph、InfiniteGraph、Cosmos DB、DataStax Enterprise(5.0+)、Amazon Neptune 等。另一种图查询语言 Cypher 则采纳了基于形容式的模式匹配。因为与 SQL 相似，具备语法简略和灵活性高的特点，因而被 neo4j、RedisGraph、AgensGraph 等零碎采纳。例如，在蕴含 person 和 location 类型点的图中，查问与 mike 一起寓居的人，用 Gremlin 和 Cypher 编写的查问语句别离如下所示。 # Gremling.V().has('name', 'mike').as('a').out('lives').in('lives').where(neq('a')).values('name') # Cypher MATCH(src:person{name:"mike"})-[:lives]->()<-[:lives]-(dst:person)RETURN dst.name比照其余类型的数据处理，图查问具备显明的计算特色。海量数据和局部性差的特点，须要零碎在分布式工作划分、负载平衡、通信调度等方面进行优化；高计算复杂度和用户的低提早要求让零碎的并发能力变得尤为重要；超点导致的内存收缩、交互环境内存受限等特点，给零碎的内存治理带来了很大的挑战。图剖析图查问，个别只拜访满足特定条件的大量点或边，并实时返回后果，如从某个点登程按肯定条件走两跳，返回满足条件的门路。而图剖析则个别蕴含更简单的计算，侧重于剖析、开掘全图的整体特色或实体之间的关联信息，例如把全图所有点按肯定规定进行聚类。事实上，图论是一个已有几百年钻研历史的传统数学分支，因而无关图剖析的算法也是举不胜举。从最短门路、连通重量等经典算法，到社区发现、协同过滤、模式开掘等人工智能畛域的理论问题，图剖析被利用在了越来越多的场景中，大规模图剖析也成为了一个钻研热点。参考 GraphX，常见的图剖析算法分类包含： 简略的图剖析算法 PageRankShortest pathGraph coloringConnected component社区发现类的算法 Triangle countingK-core decompositionK-Truss模式匹配类的算法 Graph simulation(Sub)graph isomorphismKeyword search协同举荐类的算法 Alternating least squares (ALS)Stochastic gradient descent (SGD)Tensor Factorization构造预测类的算法 Loopy belief propagationMax-product linear programsGibbs sampling2010年 Google 公开的 Pregel[3] 零碎是首个专门用于剖析大规模图数据的分布式系统，它首次提出了以点为核心的编程模型，并催生了后续一系列的学术研究和开源零碎。这种编程模型采纳部分的、面向点的计算思维，促使用户“像点一样思考”。因为这一模型具备人造的可扩展性和并行性，因此被宽泛应用。连续这一模型的零碎也从编程接口、工作划分、执行机制等各个角度对其进行优化，如 PowerGraph[4] 的经典编程模型 GAS。另一类零碎采取了更加高级的编程模型，如 Giraph++[5] 率先提出将子图作为计算的根本单元，因此执行效率更高。GRAPE[6] 提出的 PIE 模型能够将单机图算法主动并行化，在兼具高效性能的同时，大大降低了用户的编程难度。图数据的复杂性，使得图剖析零碎在设计上有很多须要思考的难点，比方：如何更无效地利用底层硬件资源，如何划分数据和保护分布式一致性，更高效的执行模式和任务调度策略，更先进的计算模式和编程模型，以及更好的零碎容错机制等等。图学习图学习，即基于图的机器学习，旨在将图的构造信息整合到机器学习模型中。随着以深度学习为代表的人工智能技术广泛应用，且图构造具备更强的表达能力，图学习成为了一个热点话题，也在因果关系、可解释性方面带来了冲破停顿。当初，图学习曾经被利用在了搜寻举荐、广告、金融风控、智能交通、医疗、城市等各个领域。另一方面，图学习也面临着一些新的技术挑战，例如数据规模宏大、点和边的异构性、多模态的属性特色、构造或属性随工夫动态变化等。图学习的传统办法，是表征学习。图表征学习（Graph Embedding），就是将图中的每一个顶点都示意成一个低维向量，并使该向量可能尽可能多的保留图的构造和内容信息。该示意向量能够作为特色用于后续的学习工作，如链接预测、顶点分类等。下图展现了一个经典的例子，其中右边是原始的图构造，左边是表征学习失去的一种映射计划，它把图A中的每个顶点转化成了二维坐标系中的一个点，也就是一个二维向量。原始图中严密相连的点（即雷同色彩的点）在映射失去的坐标空间中，仍然间隔较近。 Graph Embedding示例 (https://dl.acm.org/doi/abs/10...)对于图表征学习这一问题，曾经发展了十分多的钻研工作。这些工作针对同构图、异构图、属性图、动态图等不同类型的数据，提出了各式各样的计划，包含经典算法 DeepWalk[7]、LINE[8]、Node2Vec[9] 等。这些工作的根本做法是基于随机游走生成数据，而后通过训练优化参数，生成概率模型。另一种图学习的重要类型是图神经网络。传统的神经网络只能解决欧式空间的问题，要求数据是残缺、参差、规定的。例如一张照片，每个像素点固定与八个点相邻，因而每个点能够对应一个等长向量，蕴含了它自身的信息和街坊信息。而图神经网络（GNN），将经典神经网络模型如 Recurrent Neural Networks（RNN） 、Convolutional Neural Networks（CNN）等扩大到了图上。它解决的是非欧式空间的问题，这是因为图构造是不规则的，每个点的街坊个数不一样，导致部分的维度不定长。与图表征学习试图学习出每个点的 embedding 不同，图神经网络的目标其实是学习出聚合函数，所有点通过同一个函数就能够利用部分信息计算出本身的 embedding。即便是图构造发生变化，甚至是齐全新的图，也能用原来的函数计算出有意义的后果。无关图神经网络，也曾经诞生了一系列经典算法，读者能够浏览无关文献[10]做进一步的理解。总结因为图数据具备依赖性强、局部性差、不规则散布、构造多样等特点，导致传统的数据并行零碎难以实用。另外，不同类型的计算特色和计算范式，也给图计算零碎的设计带来了多元化的要求。一个现实的图计算零碎，应该兼具通用性、高性能和易用性。在通用性上，咱们心愿它反对图查问、图剖析、图学习等多种类型的计算，同时，兼容语言规范与业界生态。在性能方面，能够实现低延时的交互式查问，具备高性能的图剖析能力，反对大规模图存储，提供高可扩展性等。在易用性上，应该提供对立的编程模型，高度形象、简略灵便的语言，并且实现零碎部署简略、集群方便管理，提供可视化的界面等等。应答图计算零碎面临的种种挑战、满足实在利用场景的需要、提供一站式高效的解决方案，正是 GraphScope 的设计初衷。GraphScope 零碎提出了多个重要的创新性技术，同时也在继续疾速迭代着，曾经证实在多个要害互联网畛域 （如风控、电商举荐、广告、网络安全、常识图谱等）实现了重要的业务新价值，并致力于助力越来越多的重要利用场景。参考资料[1]Gremlin: https://tinkerpop.apache.org/...[2]Cypher: https://dl.acm.org/doi/abs/10...[3]Pregel: https://dl.acm.org/doi/abs/10...[4]PowerGraph: https://www.usenix.org/confer...[5]Giraph++: https://dl.acm.org/doi/abs/10...[6]GRAPE: https://dl.acm.org/doi/abs/10...[7]DeepWalk: https://dl.acm.org/doi/abs/10...[8]LINE: https://dl.acm.org/doi/abs/10...[9]Node2Vec: https://dl.acm.org/doi/abs/10...[10]无关文献: https://www.sciencedirect.com... ...

图数据库原理尽管神秘莫测，然而其利用场景却日渐丰富多彩，利用成果直观明了。 人与人在线上和线下的分割，在会集了海量的 “关系” 数据后，人造造成了一张图，可能撑持社区发现、舆论追踪、用户举荐等丰盛的利用场景。 每个病人都会积攒病情特色、电子病历、历史用药、药物成分、临床试验、保险状况等多维数据。利用这些结构化和非结构化的数据，就能够绘制以病人为核心的图数据，从而实现智能诊断，进步诊断效率和准确性。 在物联网时代，图模型通过构建人、地位、事件、物的关系图，实现智能交通、路线布局、安全城市、钓鱼网站辨认等，惠及民生。 更进一步，某些立功是团伙作案，那么追踪团伙中某个人的行为轨迹，如乘坐的交通工具、所住酒店等信息，利用图数据库就可疾速标识出整个团伙的特色。 同样利用图数据库即可查问企业股东及其关联人账户的多层行为，即穿透性治理，利用企业图谱收集合乎监管要求的关联账户，能够全面评估金融机构与企业的交易危险。 对于这些新型利用场景，传统的关系型数据库个别无能为力，或者性能体现不佳，让用户不得不舍弃。 相较于关系型数据库，图数据库在解决关联关系上性能晋升上千倍，可能深挖关联关系，开释数据潜在的价值。 图数据库前景广大，利用场景增多 5G、物联网、AI等技术的倒退利用让数据呈指数倍增长，也为图数据库倒退提供了更广大的利用空间。 市场调研机构Reports and Data的最新预测表明，寰球图数据库市场的规模2027年将达74亿美元，而在泛金融、IT、电信、生物医药、物流、电商批发、政府等畛域的图数据库利用将来将蕴含逾千亿美元市场规模。 2019年，Gartner首次将图数据库列为 “2019 年十大数据和剖析趋势” 之一。Gartner公布的2021年最新报告预测，随着对数据隐性关联实时洞察日益增长的需要，到2023年，寰球30%的企业都将应用图技术来撑持其智能商业决策；到2024年，图存储和图剖析将全面代替旧有的目录式数据资产治理，成为新的数据资产治理计划。 从Gartner的预测来看，将来几年，图数据库将是增速较快的数据库畛域之一。 IDC最近公布的《IDC TechBrief：图数据库》则揭示了图数据库倒退的根本状况。 从寰球来看，图数据利用仍处于晚期阶段，市场饱和度有余5%。且大多数用例是在银行、金融服务以及能源部门。 因为目前不足相干的图剖析工具和人才，图数据库用户往往集中在可能本人独立建设的图剖析的大型企业，通常服务于财务、营销和经营部门。 图数据库用例次要集中在欺诈检测、人际关系剖析（执法部门）和预测剖析（营销和商业打算）等。 IDC报告认为，从久远来看，中国当先的挪动互联网环境、微小的社会和市场规模，将来对图数据库的利用需要将远超其余国家。 一方面，随着数据经济的倒退，在数据量减少的同时，市场上对解决海量、简单、关联、多变的网状数据的需要一直减少，而传统的关系型数据库产品曾经很难胜任这种海量简单的剖析需要。 在这类场景下，图数据库成为泛滥用户的首选工具，在发现和剖析数据间关联关系方面，图数据库的性能远远高出传统的数据管理和剖析伎俩。 其中，属性图可用于发现异常行为，如可疑数据拜访、信用卡欺诈、身份偷盗和恶意程序；用于语义剖析的图（常识图谱）通常能够摄取和描述自然语言内容，用于查找关联文档或内容是否存在有意义的关系。 另一方面，图数据库实用的利用场景正在一直增多，在金融交易、征信、反欺诈、社交网络、智能营销、生物工程的应用需要大量涌现。 图数据库技术和市场蓬勃发展 2021年12月出炉的《“十四五” 软件和信息技术服务业倒退布局》指出，软件作为信息技术要害载体和产业交融的要害纽带，将成为我国 “十四五” 期间抢抓新技术反动时机的策略支点。 布局部署聚力攻坚根底软件，减速分布式数据库、混合事务剖析解决数据库、共享内存数据库集群等产品研发和利用推广。 在数据库方面，布局专题要求冲破全内存高速数据引擎、高牢靠数据存储引擎、分布式数据处理与任务调度架构、大规模并行图数据处理等关键技术，推动高性能数据库在金融、 电信、能源等重点行业要害业务零碎利用。 由此可见，“软件定义” 是新一轮科技反动和产业改革的新特色和新标记，已成为驱动将来倒退的重要力量。减速分布式数据库、“大规模并行图数据处理” 等关键技术的研发与利用推广已被列为国家软件倒退的重要战略目标。 资本是嗅觉最灵活的，2021年国内外多家图数据库企业在取得了大笔融资，融资用于产品的技术研发和利用的市场推广，以便更好地为客户提供服务，用图数据库帮忙客户赋能更多的业务场景，开掘数据价值。 什么样的图数据库最受宠？ 令人欣慰的是，目前我国图数据库畛域展示良好的回升势头，呈现了不少自主研发的图数据库与常识图谱平台，将来将是中国图数据库利用的主导力量。 从技术方向来看，分布式图数据库成为支流。作为国内当先的大数据根底软件供应商，星环科技向市场提供基于自主研发的分布式图数据库StellarDB，并失去了宽泛的利用。 StellarDB在分布式扩大、分布式架构容灾计划等方面进行了翻新设计，从多个方面确保图数据库贮存、查问、剖析、计算高性能运行，同时领有可靠性高、可用性好、可扩展性好等劣势。 从性能来看，领有自主可控技术的图数据库性能体现更优异。作为一款为企业级图利用而打造的分布式图数据库，Transwarp StellarDB可能存储PB级大规模图数据，数量能够达到千亿节点万亿边，反对原生图存储。 在性能上，StellarDB能够提供高性能的图存储、计算、剖析、查问和展现服务；具备10+层的深度链路剖析能力，提供丰盛的图剖析算法和深度图算法；反对标准图查询语言并兼容openCypher，且具备高性能3D图展现能力。 从商用化水平来看上来看，自主研发的图数据库公司领有更多的胜利利用世界。StellarDB克服了海量关联图数据存储的难题，通过集群化存储和丰盛算法，实现了传统数据库无奈提供的低延时多层关系查问，曾经用于金融、政府、交通等泛滥行业，用于反洗钱、危险管制、营销等多种场景。 星环科技是国内同时具备图数据库、常识图谱平台、图开掘利用开发能力的企业，其全栈能力，能够助力金融机构疾速构建常识图谱利用。 星环科技StellarDB作为一款自主研发多年的分布式图数据库，其产品能力已通过中国信息通信研究院《图数据库根底能力评测》测试，并领有多项专利。在国产化适配方面，可兼容河汉麒麟、中标麒麟等国产操作系统。 产品荣誉方面：曾获第二届浦发银行国际金融科技翻新大赛金奖、2020服贸会科技翻新服务示范案例、中国证券业协会2021年重点课题钻研立项、作为加强数据分析代表入围Gartner《Hype Cycle for ICT in China, 2021》、入选Gartner《中国数据库市场指南》数据库畛域代表厂商。 规范参编方面：星环科技产品研发团队参加编写了中国电子技术标准化研究院出版的《常识图谱标准化白皮书》、《常识图谱选型与施行指南》、IEEE-P2907课题《信息技术 人工智能 常识图谱技术框架》（国标打算号20192137-T-469），一直为行业标准制订建言献策。 近期，星环科技将正式公布StellarDB 4.0，减少更多新性能，性能将失去进一步晋升，为用户带来更极致的性能体验，敬请关注

本周让咱们持续NoSQL家族的访谈之旅，本次咱们的采访对象Neo4J学生。为什么要有Neo4J？各种数据库事实上都是在形容事实世界上中数据之间的分割，事实世界中一个比拟典型的场景就是关系数据库力有不逮的中央，那就是社交网络，这种重分割的数据。如下图所示: A和B、C、D、E都是好敌人，这在关系型数据库是典型的多对多关系, 对于多对多的关系，个别关系型的策略是建设一张两头表来形容这种多对多的关系。然而在关系型数据库中形容分割更常见的场景是形容不同数据的建模关系，比方学生和课程表的关系，选课表就存储学生ID，课程表ID等其余必要信息，学生和课程形容的对象是不同的，下面的图形容的数据是雷同的，可能都是社交圈的人。咱们该如何存储这种分割，一张自分割的表？ 存储跟他分割的信息？ 像上面这样: 那如果我当初的需要是查问A的敌人的敌人呢，那一个简略而无脑的操作就是我想看我敌人的敌人，这只是一层， 对应的SQL其实很好写: # 请原谅我还是从Student还是 SELECT * FROM Student WHERE id in ( SELECT studentReleationId FROM student_releation WHERE studentId in (SELECT studentReleationId FROM student_releation WHERE studentId = '1')# 转成join的话,先找出我敌人的敌人的Id,而后再做join，或者子查问SELECT s2.studentReleationId FROM student_releation s1 INNER JOIN student_releation s2 on s1.studentReleationId = s2.studentIdWHERE s1.studentId = '1'但其实并不举荐join，假如一个人的社交好友有100个，有的其实会更高，那我存储个人信息如果只有三万集体的话，那么存储分割的表就是三百万条数据，这个其实还不算穿插意识的。对于关系型数据库来说大表的join是一场劫难，但对于社交软件来说，三万个用户来说是相当少的数据量，对于成熟的社交产品来说，三百万，三千万都有可能。再比方电影关系图，查看某个导演的电影参演的演员，对于关系型数据库来说这个也不是不能做，只是数量下来之后，咱们查问速度是一直在降落的，因为对于表与表之间的关系根本靠join，join的越多速度越慢。由此咱们就引出了图数据库的利用场景，多对多建模、存取数据。图数据库对关联查问个别都进行针对性优化，比方存储模型上、数据结构、查问算法等，避免部分数据的查问引发全副数据的读取。 关系型数据库有不同的实现，MySQL，Oracle, SQL Server 一样，图数据库也有不同的实现: Neo4j，JanusGraph，HugeGraph。关系型数据库的查询语言是SQL，图数据库的查询语言是: Gremlin、Cypher.本次咱们介绍的就是Neo4j。 用起来我首先还是来到Neo4j官网心愿有收费试用的，因为我不想本人装。而后我看到了收费试用: 而后我就不装了，间接开始用。咱们首先还是先介绍根本的语法: 创立 创立结点 CREATE (Person { name: "Emil", from: "Sweden", klout: 99 }) Person是这个结点的标签,{}外面是这个标签的属性。创立分割 ...

本文首发于 Nebula Graph Community 公众号 常常看技术文章的小伙伴可能会留意到除了正在浏览的那篇文章，在文章页面的注释下方或者右侧区域会有若干同主题、同作者的文章等你浏览；常常逛淘宝、京东的小伙伴可能发现了，一旦你购买或者查看过某个商品之后，猜你喜爱的举荐商品会贴近你刚拔草的商品…这些日常生活中常遇到的事件，可能是由一个名叫图学习的“家伙”提供技术支持。 图学习，顾名思义是基于图的机器学习，依照本期我的项目介绍的参赛队伍——图学习趣味小队队长杨鑫的话就是，图学习是一个通过深度学习办法，基于图的构造与属性生成一个向量作为点、边或者整个图的表征。 在之前 Nebula Hackathon 2021 年的参赛我的项目中，图学习趣味小队“豪气”地说要让 Nebula Graph 具备反对图学习的能力，在本文接下来的内容中，你将理解到他们是怎么实现这一指标的。 图学习小课堂在讲述我的项目实现之前，我的项目负责人杨鑫先给大家上了一课“图解图学习”。 以获取顶点的向量表征为例来解说下图学习过程，第一步须要对图中顶点街坊进行采样拿到街坊的拓扑构造以及属性；第二步便是通过自定义的聚合函数聚合街坊顶点蕴含的信息进行计算；最初一步基于聚合信息失去图中各顶点的向量示意。 杨鑫示意，掂量一个图学习算法的好坏是通过生成向量中蕴含图中顶点属性及拓扑构造的丰盛水平来判断的。 故事的开始在抉择图学习框架时，图学习趣味小队有本人的一套选型规范：首先它是开源组件，不便二次开发，其次它反对分布式，最初框架自身和图数据库的耦合水平要低不便定制化开发。通过深刻调研，因为 DGL（链接：https://www.dgl.ai/）同底层的图数据库耦合过高，PYG（链接：https://pytorch-geometric.readthedocs.io/en/latest/）不反对分布式，最终他们采纳了 Euler（GitHub 地址：https://github.com/alibaba/euler），而在 Nebula Hackathon 2021 中，图学习趣味小队的重点工作便是用 Nebula Graph 替换 Euler 原生图数据库，让社区用户能够基于 Nebula Graph 低成本尝试图学习能力。 设计思路 在方案设计上，架构分为三层：底层是 Nebula Graph 图数据库，中间层是图采样算子层，为下层 Euler 图算法提供多种采样图数据的能力。图采样算子则是他们本次工作的重点——重写 22 个 TF 采样算子、6 种 nGQL 采样语法。 高强度的开发量以全局带权采样语法设计为例， 这里采纳了预计算（离线）+ 计算下推（实时）的形式来实现全局采样，次要过程为（上图 1-4） graphd 提交异步构建工作给 metad；metad 下发工作给各个 storaged 节点进行计算；storaged 将计算结果上报给 metad 汇总；metad 通过心跳将后果同步给 graphd。具体开展来讲，在图学习训练过程中，数据采样是一个十分高频的操作，采样性能好坏对图学习训练耗时影响很大。 在这里，杨鑫他们采纳别名采样算法作为全局带权采样语法的外围算法，它的基本原理是首先对进行采样的全副数据依据各自的权重计算出一份采样表，采样表由行号（sid）、vid1、采样概率（prob）、vid2 四局部组成，其中行号是从 0 开始的编号，vid1、vid2 示意能够被采样的某个顶点的 vid；采样流程是首先在表中随机抉择一行，而后再随机生成一个 0~1 之间的值 p，如果 p < prob，则本次采样的数据是 vid1，否则采样 vid2。 ...

本文首发于 Nebula Graph Community 公众号 本文次要介绍了天文空间数据（Geospatial Data）以及它在 Nebula Graph 中的具体实际。 Geospatial Data 在 Nebula Graph 中的实际什么是 Geospatial Data天文空间数据（Geospatial Data）是蕴含简略天文空间因素信息的数据，比方点（point）、线（linestring）、多边形（polygon），或是其余更简单的形态。 Nebula Graph 在 2.6 版本中引入了对 Geospatial Data 残缺的反对，包含天文空间数据的存储、计算，以及索引。Nebula Graph 目前反对 Geography 类型的天文空间数据，Geography 类型是建模在地球空间坐标系上由经纬度坐标对示意的地理位置信息。 Geospatial Data -- 天文空间数据应用创立 Schema这里仅以 Tag 为例，当然 Edgetype 上同样能够将 Geography 类型作为属性列。 Nebula 目前反对点、线、多边形三种空间数据类型。上面介绍一下如何如何创立 Geography 类型属性以及如何插入天文空间数据到 Nebula 中。 CREATE TAG any_shape(geo geography);CREATE TAG only_point(geo geography(point));CREATE TAG only_linestring(geo geography(linestring));CREATE TAG only_polygon(geo geography(polygon));当 geography 属性前面没有指定具体的天文形态信息时，代表该列能够存储任意天文形态的数据；当指定形态类型时，则代表只能存储该形态的天文数据，比方 geography(point)，就代表该列只能存储 point 形态的地理位置信息。 插入数据向 Tag any_shape 的 geo 列插入数据： ...

作者：杨涛涛 资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 MySQL 数据库能够用来解决绝大多数在线业务场景，而且能解决得很好，无论从单节点性能，或者说从多机扩大后的总体吞吐量来讲，都很占优势。不过，万事无相对，MySQL 在某些场景下性能并不能达到预期。例如在各种繁冗的关系解决方面，MySQL解决起来就有些吃力。此类场景下，NoSQL 就比关系型数据库要更加适合。本篇咱们用图数据库Neo4J（NoSQL的一种）来举例说明在这种场景下如何补救 MySQL 的有余。 这里先用简略的人物关系来举例说明。 对于简略的人物关系，比如说小宋、小李、小杨、小爱、小徐、小娜、小乔几个人之间的关系链条可能如下： 小宋 “意识” 小李。小李 ”意识“ 小杨。小杨 “意识“ 小爱。小爱 ”意识” 小徐。小徐 “意识“ 小娜。小娜 ”意识” 小乔。其中 “意识” 即为几个人之间的关系。 这样的关系有很多种，比方 “意识”、“见过”、”好友“、”共事“，”暗恋“、”恋人“ 等等。本篇咱们先来看根本的关系：”意识“。也就是说关系仅仅“意识”而已，别无其他。 假如有如下三个需要：找出用户总数目。找出“意识” 小杨 并且 小杨 又 “意识” 的人。找出小杨 “意识” 的 “意识” 的 “意识” 的 “意识” 的人。对于这样几个需要，咱们先基于 MySQL 来设计两张表：（如果仅仅实现最初两个需要，只须要表 2 即可。）表1：用户表，存储用户记录；表2：用户关系表，存储用户之间的关系。 为了简化起见，两张表无主键，由MySQL 外部调配。 mysql:ytt>create table user1 (name varchar(64));Query OK, 0 rows affected (0.09 sec)mysql:ytt>insert user1 values ("小宋"),("小李"),("小杨"),("小爱"),("小徐"),("小娜"),("小乔");Query OK, 7 rows affected (0.01 sec)Records: 7 Duplicates: 0 Warnings: 0mysql:ytt>create table relation1 (user_name varchar(64),friend_name varchar(64));Query OK, 0 rows affected (0.07 sec)mysql:ytt>insert relation1 values ("小宋","小李"),("小李","小杨"),("小杨","小爱"),("小爱","小徐"),("小徐","小娜"),("小娜","小乔");Query OK, 6 rows affected (0.01 sec)Records: 6 Duplicates: 0 Warnings: 0那咱们来实现以上三个需要： ...

继星课堂新品深度解读系列之后，由南京大学联结星环科技重磅推出的 “星云” 大讲堂前沿数据技术分享系列直播流动行将开启，并于本周三（11月3日）19：30正式开讲！ 此次直播系列流动，由南京大学-星环科技 “星云” 数据技术联结钻研核心主办，星环大数据产业技术倒退促成核心协办，内容涵盖大数据、人工智能等前沿技术热点。 流动将分为7期（6期线上分享+1期线下论坛），每期会依据不同的技术方向主题，包含图数据库，边缘计算，常识图谱，分布式数据库，大数据平台，数据隐衷等，邀请星环科技技术专家与内部技术专家进行技术分享，赋能企业把握攻克前沿技术难题的外围办法，为企业改善业务模式、促成人才倒退、晋升经济效益提供智慧化解决方案。 本周三（11月3日），“星云” 大讲堂前沿数据技术分享系列直播流动第一期将正式开播，主题将围绕 “图数据库及其在工业互联网中的摸索与利用” 进行分享。 随着社交、电商、金融、批发、物联网等行业的疾速倒退，事实社会织起了一张宏大而简单的关系网，传统数据库很难解决关系运算。大数据行业须要解决的数据之间的关系随数据量呈几何级数增长，亟需一种反对海量简单数据关系运算的数据库，图数据库因而应运而生。 StellarDB是一款为企业级图利用而打造的分布式图数据库，用于疾速查找数据间的关联关系，并提供弱小的算法剖析能力。StellarDB克服了海量关联图数据存储的难题，通过自定义图存储格局和集群化存储，实现了传统数据库无奈提供的低延时多层关系查问，在社交网络、公安、金融畛域都有很大利用后劲。 本期就将给大家具体介绍图数据库的底层原理，以及星环科技StellarDB在行业中的利用和获得的显著功效，更多详情见下图： 扫描海报二维码即可报名讲师介绍： 秦元坤：星环科技AI技术专家、高级培训师，计算机硕士，多年研发和教学教训。在机器学习、NLP、计算机视觉和图计算等畛域有丰盛的教训。先后对南京大学、北航、上期所、浦发银行等多家高校及企业进行AI和图数据库培训。 “星云” 大讲堂前沿数据技术分享系列直播 下一讲 11月10日（下周三）将为你带来 “星环Edge平台在云边一体方向的摸索”  敬请期待！

近年来，人工智能、图计算、区块链等为代表的新兴技术倒退方兴未艾，推动着金融业数字化转型进入深水区。作为科技翻新大潮下的外围根底技术之一，图计算技术凭借在数据分析和解决畛域的独特劣势，逐步在金融业数字化转型中施展着愈来愈重要的作用。 目前，金融行业常识图谱利用正处于暴发期。星环科技首席金融行业架构师曾晨光介绍，在国内，利用企业自研的国产图数据库、常识图谱平台和常识开掘利用教训，齐全能够构建监管和金融行业的常识图谱计划，既能满足用户金融风险监管、精准营销、投资剖析交易等外围利用场景的需要，又能满足自主可控与平安的要求。 作为国内大数据与人工智能根底软件的领头羊，星环科技利用自研的具备自主知识产权分布式图数据库Transwarp StellarDB和常识图谱平台Sophon KG，与金融行业的头部机构单干，构建了多个畛域的常识图谱利用场景，波及团体派别常识图谱、银行对公常识图谱和批发常识图谱，证券公司反洗钱常识图谱、投研常识图谱等利用，并获得了杰出的利用成果。 01 金融行业图利用 正从监管、大银行向中小银行浸透 从2019年底开始，图数据库等开始在国内的监管机构、各大交易所、大型银行等开始利用。这些机构纷纷抉择国产自主研发的企业级分布式图数据库和常识图谱平台，构建常识图谱利用。 与此同时，国产的图数据库、常识图谱平台以及常识开掘利用技术与产品不断涌现，常识图谱全栈整体解决方案逐步欠缺。到了2021年，图技术商业化的步调一直放慢，在监管、金融行业的利用也将从大型银行，走向老本敏感的中小型金融机构。 曾晨光介绍，目前，金融机构常识图谱利用倒退面临的挑战次要有两个： 一是图数据源匮乏。受反对图谱表白和存储的实体、关系、属性三元组的图数据源获取瓶颈的制约，晚期常识图谱最早利用于监管和大银行的危险图谱，如反洗钱、反欺诈图谱利用等，获得了不错的成果。这类利用个别都属于同构图，整个图谱Schema中只蕴含一类实体和一类关系，绝对容易实现。 而大于一类实体和关系的异构图近年来倒退迅速，包含工商数据网络、司法数据、供应链、产业链、价值链、担保链、社交网络等利用场景的异构图数据源不断丰富，预示着将来2-3年，异构图常识图谱将是金融行业利用的主战场。 二是图技术的成熟度。金融机构在常识图谱利用中的次要投入除了图数据源以外，次要包含图数据库、常识图谱建模平台选购，以及常识图谱利用构建等。因为图数据库+常识图谱PaaS+图开掘利用等技术成熟度不高，导致常识图谱商业化落地很难实现标准化。而定制化水平越高的新技术投入的估算就越高，只有大型金融机构才有资金实力投入预研性质的开发或者选型，限度了常识图谱的利用与推广。 面对金融机构的关系发现和关系查问等需要，传统关系型数据库须要一直地多表关联，跨表查问，在面对图构造大于10度以上的关系搜寻时就会呈现重大的性能瓶颈，甚至呈现算不进去的景象。 传统的关系型数据库显然无奈满足金融机构金融监管、金融风控、金融投研等图计算的需要，而分布式图数据库因为能够解决超大规模的图计算利用，因此受到金融机构的青眼。同时领有图数据库、常识图谱平台、图开掘利用开发的供应商更受用户的欢送。 02 星环科技 实现金融行业三大图计算利用场景 星环科技利用自研的分布式图数据库Transwarp StellarDB和常识图谱平台Sophon KG，以及图开掘利用开发的丰盛教训，与金融行业的头部机构单干，构建了多个不同类型的常识图谱利用场景。 曾晨光介绍，星环科技胜利落地的常识图谱利用能够分为金融监管+危险合规类、精准营销类、投资钻研类的三类，别离面向金融机构三大业务条线。 危险是金融的命根子，也是国家监管科技的骨干。金融监管+危险合规的常识图谱是星环科技最早开始投入建设和技术研发的方向。面向超大规模图网络，星环科技率先公布了反对空间3D的图展现，防止了二维图的展现对于超过万节点的图无奈清晰体现的弊病；同时联合反洗钱网络图谱利用属性图中节点带有天文定位属性，构建了跨境可疑资金转正图网络，对于可疑跨境交易高深莫测。 明天，大型金融机构可能存在上千万家的B端或者C端用户，如何实现针对不同用户的精准营销？在营销常识图谱方面，星环科技面向银行开发了对公常识图谱的技术，实现了在营销端积淀业务知识，充分发挥图谱价值，帮忙银行实现诸如疫情期间小微企业信贷精准投放等利用。 在金融和资本市场，最重要的金融业务就是投资，利用常识图谱刻画人类研究成果，进行常识图谱化表白和构建，也是多家券商和基金公司在摸索金融科技赋能投资收益成果的倒退路线图。在投资常识图谱方面，星环科技通过全栈能力，深度交融NLP+常识图谱技术，通过常识示意学习等当先的常识图谱技术，实现智能投研常识图谱，赋能投资钻研场景利用。 在数据的获取、存储、计算、散发、治理的全生命周期中，须要大数据、云计算、人工智能三大技术的交融零碎。星环科技提供ABC交融的一体化技术解决方案，应用对立一套引擎去驱动不同的数据模型，满足异质性数据多模型和多源性数据多模态的解决需要，加强统一性，升高零碎的危险，减少可靠性和稳定性，实现从数据到业务畅通进行。 星环科技为用户串联起了从底层的关系型数据库、大数据平台到中层的图数据库，再到下层常识图谱利用的全栈产品，实现了从最底层独立的“点”剖析到关系的“线”剖析再到事件的“面”剖析，最终造成行业全面的“体”剖析的全栈智能剖析赋能。从点到面再到体的一站式剖析工具提供，能够搭建严密相扣的工作流链路，对于用户而言，可能大量节俭开发成本和根底算力，显著晋升剖析性能。 星环科技针对常识开掘利用具备从底层到顶层的残缺解决方案。在底层，星环科技领有极速大数据大数据平台TDH、大数据利用开发工具TDS和智能剖析工具Sophon，依靠平台上的Transwarp StellarDB分布式图数据库，能够进行海量图数据的存储与实时操作。在图数据库下层，有基于用户交互的图可视化治理与剖析平台Sophon KG。 基于以上产品，能够赋予用户构建残缺图利用生态的能力。整套零碎以分布式文件系统为根底，具备超大规模的节点边解决能力。同时也具备极强的可扩展性，能够横向进行灵便扩大，以应答数据的增长与解决能力要求的进步。同时，整个平台具备独立的零碎构架，能够灵便便捷地与各类零碎进行疾速耦合。 03 国产自研技术 与产品金融行业图计算利用大显神通 国内头部金融机构在常识图谱利用中，大多优先选择国产自研的图数据库和常识图谱平台，其起因不外乎三个： 一是金融和监管关系到国家金融平安与倒退稳固，抉择自主可控的产品，防止被国外技术“卡脖子”。 其次，放眼世界监管和金融畛域，中国金融机构C端或B端客户数量是最多的，国外的产品往往很难遇到这么大规模的数据计算场景，产品具备先天的缺点。而国产产品从诞生起，就针对用户宏大图数量来研发产品，可能满足金融机构的利用需要。 另外，在图数据库和常识图谱平台产品倒退上，国内企业与国内企业简直同时起步，而自主研发的国产技术与产品在技术上并不比国外企业差，在一些技术上还超过了国外的产品。 星环图数据库是国内第一款自研分布式图数据库，可反对万亿边规模图数据存储，具备查问速度快、剖析能力强、稳定性高的特点。如星环科技的分布式图数据库产品StellarDB就可能存储大规模图，数量能够达到百亿节点千亿边；反对的图剖析算法丰盛，性能体现优异；自主研发，曾经用于泛滥金融行业，用于反洗钱、危险管制、营销等多种场景。 星环科技是国内同时具备图数据库、常识图谱平台、图开掘利用开发能力的企业，其全栈能力，能够助力金融机构疾速构建常识图谱利用。

Neo4j是一款开源图数据库，应用Python语言拜访Neo4j能够应用Py2neo。本文介绍了应用Py2neo拜访Neo4j，批量创立节点和关系的办法。Py2neo提供了间接执行Cypher语句的办法，也提供了诸如Node、Relationship、Path一系列的数据结构，在不同的场景下能够灵便应用。 本文应用的Py2neo是2021.1之后的版本，手册请戳这里：The Py2neo Handbook 装置Py2neo应用pip装置Py2neo，执行： pip install py2neo查看已装置的Py2neo是什么版本的： pip show py2neoName: py2neoVersion: 2021.1.5Summary: Python client library and toolkit for Neo4jHome-page: https://py2neo.org/连贯Neo4j数据库本文中会用到多种数据类型，在此一并援用 import numpy as npimport pandas as pdfrom py2neo import Node,Relationship,Graph,Path,Subgraph配置Neo4j数据库的拜访地址、用户名和明码 neo4j_url = 'http://localhost:7474/'user = 'neo4j'pwd = 'admin'2021.1之前拜访数据库的形式为： graph = Graph(neo4j_url, username=user, password=pwd)2021.1之后的版本拜访数据库的形式为（就是这么不兼容）： graph = Graph(neo4j_url, auth=(user, pwd))1. 应用graph.run执行Cypher语句创立节点如果相熟Cypher语句的话，能够通过应用graph.run执行Cypher语句来实现创立节点等操作，办法如下所示： cypher_ = "CREATE (:Person {name:'王王', age:35, work:'宇宙电子厂'}),\(:Person {name:'李李', age:20, work:'宇宙电子厂'})"graph.run(cypher_)这样就在Neo4j中创立了两个label为Person的节点，第一个节点的name属性为“王王”，age属性为35，work属性为“宇宙电子厂”，第二个节点的name属性为“李李”，age属性为20，work属性为“宇宙电子厂”。同样，能够通过调用graph.run执行Cypher语句创立关系。 cypher_ = "MATCH (from:Person{name:'王王'}),\(to:Person{name:'李李'}) MERGE (from)-[r:共事]->(to)"graph.run(cypher_)这样在Neo4j中就有了具备共事关系的两个Person节点。 2. 应用Node数据结构创立节点Py2neo也提供graph.create办法来创立节点和关系 node = Node("Person", name="李李", age=20, work="宇宙电子厂")graph.create(node)与执行Cypher语句的成果雷同，在Neo4j中创立了一个Person节点。 ...

这是由社区用户——繁凡撰写的一篇他的实际分享，次要解说如何进行 Nebula 性能测试以及数据导入局部的性能调优。下文中呈现的“我”代指用户繁凡。 0. 概要之前在做 Nebula 的调研工作，而后又针对应用上做了性能测试，期间屡次求教了 Nebula 的官网人员，在这里对官网人员表示感谢，大佬辛苦了！ 我把本人测试的过程整顿一下，心愿对大家有一点启发，如果大家有更好的意见，请不吝赐教！ 1.部署 Nebula 集群首先筹备了 4 台实体机：1、2、3、4，每台配置，CPU：96C，内存：512G， 磁盘：SSD。机子调配： 1：meta，storage2：storage3：storage4：graphd装置过程就不再详述了，应用的是 rpm 的形式。其余插件：nebula-import-2.0，nebula-bench-2.0，下载源码编译即可，装置在 4 节点。 2.导入数据本次导入的数据数据结构为 7 种点类型、15 种边类型，数据量并不大，构造也很简略，数据量总计 3400w，不过要提前解决成这么多个点边表。 先创立 space，设置 vid=100 ，replica_factor=3，partition_num=100。 nebula-importer 数据导入优化应用 nebula-importer 进行导入，间接开干，速度只有 3w/s 的样子，这也太慢了吧。查看import的文档，整个应用的参数也就只有concurrency，channelBufferSize ，batchsize 先调整一下试试吧，轻易改了改，成果并不显著, 发帖求教大佬了。详见论坛帖子 nebula-import 2.0 导入速度太慢，求教完之后，播种很大，先改 yaml 参数 concurrency：96 # cpu核数channelBufferSize：20000batchsize：2500速度差不多 7-8w 了，嗯，看起来的确快了很多，再搞大点，graphd 间接崩掉了，看来还是不能过大，所以这几个参数要尽量大然而不能过大。 而后再确认下磁盘和网络，居然用的是机械磁盘和千 M 网络。。。改成SSD的，而后再切换成万 M 网络，速度间接再晋升一倍多，大略 17w/s，看起来硬件还是很重要。 而后我再想会不会跟数据有关系，留神到 vid 和partition_num，vid 挺长的想着设置短一点然而没方法改，因为的确有这么长的，而后是 partition_num，看了下官网阐明，磁盘的 2-10 倍，改为了 15，的确有影响，速度达到了 25w/s。到这里也算比较满意了，可能再批改还会有晋升，不过曾经满足要求了先告一段落吧。 小结concurrency 设置为 CPU 核数，channelBufferSize 和 batchsize 尽可能大，然而不能超过集群的负载。硬件要用 SSD 和万 M 网络space 的分区 partition_num 要正当，不能太多猜想 vid 长度，属性数量，graphd 的个数都有影响，但还未尝试3.压力测试依据业务上应用的指标，选取了一个进行测试。指标如下： ...

摘要： 图数据库，如果是刚接触的人，可能会被其字面意思所误导。其实，图数据库并不是指存储图片、图像的数据库，而是指存储图这种数据结构的数据库。那么图又是什么呢？本文分享自华为云社区《图数据库到底是个啥》，原文作者：你好_TT 。 近些年来，在大数据处理过程中有一种被宽泛提及和应用的数据库，那就是图数据库。那么图数据库到底是什么呢？ 图数据库，如果是刚接触的人，可能会被其字面意思所误导。其实，图数据库并不是指存储图片、图像的数据库，而是指存储图这种数据结构的数据库。那么图又是什么呢？ 什么是图咱们通过上面的例子来认识一下。 东汉末年，孙权、刘备联军曾在赤壁一带以火攻敌船之计大破曹军。 如果咱们把各营垒之间的关系形象一下，以营垒作为点，营垒之间的关系作为边，这样咱们就能够用如下的图来形象地示意上述关系： 以上就是这里所谓的图（的可视化展现）。 咱们把这种存储实体和实体之间关系的数据结构，称为图，Graph，图由点和边组成，一个点就是一个实体，比方上述实例中的营垒，两个实体之间的关系则用有方向或无方向的边来示意，比方刘备和孙权之间的联盟关系等。这种通用的构造能够对事实中的各种场景进行建模，从交通运输零碎到组织架构治理，从工艺流程设计到社交网络。 什么是图数据库晓得了图的概念，你就能够了解什么是图数据库了。简略来说，图数据库就是用来解决图这种数据结构的工具。 不同于传统的应用二维表格存储数据的关系型数据库，图数据库在传统意义上被归类为NoSQL(Not Only SQL)数据库的一种，也就是说图数据库属于非关系型数据库。 个别的图数据库至多蕴含图存储、图查问、图剖析这三种性能。 为什么要用图数据库那咱们为什么要用图数据库呢？咱们还是用东汉末年的例子来解说一下图数据库绝对于关系型数据库的劣势。 假如某关系型数据库中有三张表，别离是东汉末年人物表、东汉末年战斗表和东汉末年人物参战表。 当咱们想晓得“樊城之战的守方是谁”，查问个别会比拟快，从表2能够间接失去，但当咱们想晓得“刘备团体动员了哪些和平”的时候，只管咱们也能够从表2查到答案，然而咱们可能须要遍历整个表2，查问效率会霎时升高。而当咱们要查问诸如“关羽出战过刘备团体动员的哪些和平”的时候，咱们来看一下执行这条查问时关系型数据库是怎么做的： A. 首先通过东汉末年人物表找到关羽对应的人物IDB. 再应用东汉末年人物参战表找到其参战的战斗C. 最初通过东汉末年战斗表找到其参战的哪些战斗的攻方是刘备团体 咱们会发现，这个查问切实是太繁琐了。 而如果咱们将以上表格转化为如下的一张关系图谱，那么谁和谁是什么关系就高深莫测了。 这么说兴许你还没有真正领略到图数据库的微小威力，咱们再来看一个最经典的社交网络中查问性能比照的数据。 在《Neo4j in Action》这本书中，作者做了一个测试：在一个蕴含100万人，每个人约有50个敌人的社交网络中找最大深度为5的敌人的敌人，失去的试验后果如下： 测试结果表明，深度为2时两种数据库的性能差异不大，都很迅速；当深度为3时，关系型数据库须要半分钟实现查问，图数据库仍旧在1秒内搞定；当深度为4时，关系型数据库消耗了靠近半小时返回后果，图数据库不到2秒；而当深度达到5当前，关系型数据库就迟迟无奈响应了，图数据库却仍旧能够「秒杀」，体现出了十分良好的性能。 据此，咱们能够从以下几个方面了解为什么要用图数据库： 关系型数据库不善于解决数据之间的关系，而图数据库在解决数据之间关系方面灵便且高性能咱们不可否认关系型数据库自上世纪80年代以来始终都是数据库畛域倒退的主力，以后，随着社交、物联网、金融、电商等畛域的疾速倒退，由此产生的数据出现指数级的增长，而传统的关系型数据库在解决简单关系的数据上体现很差，这是因为关系型数据库是通过外键的束缚来实现多表之间的关系援用的。查问实体之间的关系须要JOIN操作，而JOIN操作通常十分耗时。 而图数据库的原始设计动机就是更好地形容实体之间的关系。图数据库与关系型数据库最大的不同就是免索引邻接。图数据模型中的每个节点都会保护与它相邻的节点关系，这就意味着查问工夫与图的整体规模无关，只与每个节点的邻点数量无关，这使得图数据库在解决大量简单关系时也能保持良好的性能。 另外，图的构造决定了其易于扩大的个性。咱们不用在模型设计之初就把所有的细节都思考到，因为在后续减少新的节点、新的关系、新的属性甚至新的标签都很容易，也不会毁坏已有的查问和利用性能。 数据之间的关系越来越重要当咱们在问图数据库为什么如此重要时，其实就是在问，数据之间的关系为何如此重要？正如大家都晓得人际关系的价值，其实数据的价值也在于它们之间的关联关系上。 举个例子。最近直播带货十分火，如果某个主播在微博上有几百万的粉丝，这个数据如果不利用起来，价值并不大，但如果他直播带货，把关注他的粉丝和可能来他直播间购物的顾客分割起来时，这些数据立马展现出微小的商业价值。 应用图的形式表白事实世界中的很多事物更间接，更直观，也更易于了解自然界中有各种各样的关系，而关系型数据库只能把这些拍扁成表格状态的行列数据，而图数据基于图模型以一种直观的形式去模仿这些关系，因此更形象。另外，当初大部分的图数据库都提供了可视化的图展现，使得查问和剖析变得很直观。 业余的图剖析算法为理论场景提供解决方案图数据库起源于图实践，借助于业余的图剖析算法，可能为理论场景提供适合的解决方案。 图数据库如何存储、查问、剖析图存储图数据库如何存储图，对查问和剖析效率至关重要。图数据库应用图模型来操作图数据。所谓的图模型是指图数据库形容和组织图数据的形式。 目前支流的图数据库抉择的图模型是属性图。属性图由点、边、标签和属性组成，咱们联合一个具体的属性图实例来看一下。 以上属性图能够帮忙咱们了解一些相干概念： 1） 能够为点设置标签，比方 person, war等，领有雷同标签的点咱们认为它们属于一个分组，是一个汇合，这样刘备和曹操属于一个分组；2） 同样能够为边设置标签，标签能够为 relation等；3） 节点能够领有很多属性，比方 style name、year等，这些属性值以键值对的模式示意，例如：刘备的style name是玄德；4） 边也能够领有属性，比方army等；5） 边容许有方向，例如刘备和汉中之战之间的边的方向是由刘备指向汉中之战的；6） 元数据是用来形容点和边的属性信息的，元数据由若干标签组成，每个标签由若干属性组成。 图查问如果咱们想晓得刘备的籍贯在哪，刘备和曹操是什么关系，汉中之战的动员方是谁等等，这些都属于图查问的领域。 咱们晓得，SQL是关系型数据库的查询语言，然而图数据库的查询语言并没有复用SQL。这是因为实质上图数据库解决的是高维数据，而SQL所实用的是二维的数据结构，其并不善于关系的查问和操作。应用专门的图查询语言比SQL更加高效。 目前支流的图查询语言包含Gremlin和Cypher等。 图剖析图剖析是指通过各种图算法来开掘图信息的一门技术。 外围的图算法能够分成三类：门路搜寻类、核心性剖析类和社区发现类。 门路搜寻是摸索图中节点通过边建设的间接或间接的分割。例如在下图中，通过门路搜寻，咱们发现了这样一条门路：孙策-[夫妻]-大乔-[姐妹]-小乔-[夫妻]-周瑜,据此得悉孙策和周瑜是连襟的关系。门路搜寻类算法宽泛用于物流配送、社交关系剖析等场景。 核心性剖析是指剖析特定节点在图中的重要水平及其影响力。例如在上图中，直观来看，孙权是一个重要的人物，因为与他间接相连的边的数量最多。核心性剖析类算法个别用于网页排序、意见首领开掘、流感流传等场景。 社区发现意在发现图中分割更严密的群体构造。如果把更多的三国人物和关系加到上图中，利用Louvain等社团开掘类算法，咱们很容易发现这些人物分属三个营垒，如下图所示。 社区发现类算法可用于犯罪团伙开掘等场景。 图数据库有什么用介绍完图数据库的次要性能，咱们再来看看图数据库都有哪些利用场景。图数据库善于的应用领域包含： 社交畛域：Facebook, Twitter用它来进行社交关系治理、好友举荐咱们相熟的好友举荐。就能够采纳举荐好友的好友的办法。 徐庶和司马徽向刘备举荐诸葛亮能够通过下图形象地展现 电商畛域：华为商城用它来实现商品实时举荐通过剖析指标用户和其余用户的爱好商品，找到类似的其余用户，把这些用户购买过的商品举荐给指标用户。 金融畛域：中国工商银行、摩根大通用它来做风控治理目前来看，金融畛域对图数据库的需要很迫切，以贷款为例，在整个贷款周期中，图数据库都能施展微小的作用。 安平畛域：公安用它来进行嫌疑关系审查、犯罪团伙开掘东汉末年，曹操刺杀董卓，貂蝉调唆董卓父子关系，吕布斩杀董卓，然而董卓却不晓得，这些事件幕后主凶之一都有王允，如下图所示。事实中也可能是这样，幕后真凶可能与指标案件没有间接关系，只有间接的关系。 ...

摘要：Gremlin是图数据库查问应用最广泛的根底查询语言。Gremlin的图灵齐备性，使其可能编写非常复杂的查问语句。对于简单的问题，咱们该如何编写一个简单的查问？以及咱们该如何了解已有的简单查问？本文带你逐渐抽丝剥茧，实现简单查问的调试。本文分享自华为云社区《简单Gremlin查问的调试办法》，原文作者：Uncle_Tom。 1. Gremlin简介Gremlin是Apache TinkerPop 框架下的图遍历语言。Gremlin是一种函数式数据流语言，能够使得用户应用简洁的形式表述简单的属性图（property graph）的遍历或查问。每个Gremlin遍历由一系列步骤（能够存在嵌套）组成，每一步都在数据流（data stream）上执行一个原子操作。 Gremlin是一种用于形容属性图中行走的语言。图形遍历分两个步骤进行。 1.1. 遍历源（TraversalSource）开始节点抉择(Start node selection)。所有遍历都从数据库中抉择一组节点开始，这些节点充当图中行走的终点。Gremlin中的遍历是从TraversalSource开始的。 GraphTraversalSource提供了两种遍历办法。 GraphTraversalSource.V（Object … ids）：从图形的顶点开始遍历（如果未提供id，则为所有顶点）。GraphTraversalSource.E（Object … ids）：从图形的边缘开始遍历（如果未提供id，则为所有边）。1.2. 图遍历（GraphTraversal）走图(Walking the graph)。从上一步中抉择的节点开始，遍历会沿着图形的边前进，以依据节点和边的属性和类型达到相邻的节点。遍历的最终目标是确定遍历能够达到的所有节点。您能够将图遍历视为子图形容，必须执行该子图形容能力返回节点。 V()和E()的返回类型是GraphTraversal。 GraphTraversal保护许多返回GraphTraversal的办法。GraphTraversal反对性能组合。 GraphTraversal的每种办法都称为一个步骤(step)，并且每个步骤都以五种惯例形式之一调制(modulates)前一步骤的后果。 map：将传入的遍历对象转换为另一个对象（S→E）。flatMap：将传入的遍历对象转换为其余对象的迭代器（S\subseteq E^*S⊆E∗）。filter：容许或禁止遍历器进行下一步（S→S∪∅）。sideEffect：容许遍历器放弃不变，但在过程中产生一些计算上的副作用（S↬S）。branch：拆分遍历器并将其发送到遍历中的任意地位（S→{S1→E^，…，S_n→E^S1→E∗，…，Sn→E∗}→E*）。GraphTraversal中简直每个步骤都从MapStep，FlatMapStep，FilterStep，SideEffectStep或BranchStep扩大失去。举例：找到makro意识的人gremlin> g.V().has('name','marko').out('knows').values('name') ==>vadas==>josh 1.3. Gremlin是图灵齐备的（Turing Complete）这也就时说任何简单的问题，都能够用Gremlin形容。 上面就调试和编写简单的gremlin查问，给出领导思路和方法论。 2. 简单Gremlin查问的调试Gremlin的查问都是由简略的查问组合成简单的查问。所以对于简单Gremlin查问能够分为以下三个步骤，并逐渐迭代实现所有语句的验证，此办法同样实用编写简单的Gremlin查问。 2.1. 迭代调试步骤 拆分剖析步骤，划大为小，逐渐求证；输入分步骤的后果，明确步骤的具体输入内容；对输入后果进行推导和测验。根据后果扩充或放大剖析步骤，回到步骤1持续，直到分明所有后果。注: 此办法参照Stephen Mallette gremlins-anatomy的剖析逻辑和用例。 2.2. 用例2.2.1. 图构造gremlin> graph = TinkerGraph.open()==>tinkergraph[vertices:0 edges:0]gremlin> g = graph.traversal()==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]gremlin>g.addV().property('name','alice').as('a'). addV().property('name','bobby').as('b'). addV().property('name','cindy').as('c'). addV().property('name','david').as('d'). addV().property('name','eliza').as('e'). addE('rates').from('a').to('b').property('tag','ruby').property('value',9). addE('rates').from('b').to('c').property('tag','ruby').property('value',8). addE('rates').from('c').to('d').property('tag','ruby').property('value',7). addE('rates').from('d').to('e').property('tag','ruby').property('value',6). addE('rates').from('e').to('a').property('tag','java').property('value',10). iterate()gremlin> graph==>tinkergraph[vertices:5 edges:5] 2.2.2. 查问语句gremlin>g.V().has('name','alice').as('v'). repeat(outE().as('e').inV().as('v')). until(has('name','alice')). store('a'). by('name'). store('a'). by(select(all, 'v').unfold().values('name').fold()). store('a'). by(select(all, 'e').unfold(). store('x'). by(union(values('value'), select('x').count(local)).fold()). cap('x'). store('a').by(unfold().limit(local, 1).fold()).unfold(). sack(assign).by(constant(1d)). sack(div).by(union(constant(1d),tail(local, 1)).sum()). sack(mult).by(limit(local, 1)). sack().sum()). cap('a')==>[alice,[alice,bobby,cindy,david,eliza,alice],[9,8,7,6,10],18.833333333333332]好长，好简单！头大! ...

一、前言关上手机‘北京地铁’APP，输出起始点：霍营，起点：北京南站，发现零碎给咱们举荐了两条路线。最短时间路线与起码换乘路线，并且别离给出了耗时与乘坐里程费。看到这里，不禁开启了靓仔疑难，如果给你地铁站相干数据，如何构建这样的关系网络呢？（尽量少写代码，毕竟我这个人懒的不行，花起码的功夫，整最炫的成果，咦） 1.整顿地铁站点数据，解决成echarts图表所须要的构造2.整顿地铁站点数据，本人写代码实现，能实现（好累啊...）3.整顿地铁站点数据，导入 Neo4j 中，点击查看 剖析：计划一，不仅要解决数据还要搞echarts款式，算了吧。计划二，间接PASS，还是计划三省力，正好我的电脑上之前装置过 Neo4j 图数据库，哈哈哈，开搞开搞！软件下载地址：http://doc.we-yun.com:1008/neo4j-chs软件装置教程：https://www.cnblogs.com/jstar... 二、数据筹备既然须要展现地铁关系，那么首先须要的就是北京所有地铁站的信息，以及站点之间的关系，间隔，耗时。搜寻了一圈，最初在北京地铁官方网站，发现了全副地铁线路，站点名称，站点与站点之间间隔等信息。然而短少了具体站点与站点之间的乘车耗时，行吧，先将就着用吧！具体数据样例如下： 数据起源地址：https://www.bjsubway.com/stat... 站点关系一共18条线路，一顿复制粘贴和 Notepad++ 文本替换之后，咱们失去了一个 Excel文件，蕴含了所有站点之间的关系数据，如下: 获取站点复制所有站点进入Excel文件的某一个sheet，抉择数据去重，失去所有站点名称。 解决CSV将站点关系与站点数据处理成CSV文件格式，不便导入 Neo4j 数据库中，建设图节点与关系。操作也就是 notepad++ 替换‘ ’为‘,’,另存为 .CSV 文件，具体失去下列文件。（因为不便 Neo4j 数据库不同的路线显示不同的色彩，我顺便将站点关系数据拆解成了多个地铁线的CSV文件，如果不思考显示，能够一个CSV文件，导入站点关系即可） 备注：将所有CSV文件，放入 Neo4j 装置目录下的 import 文件夹中（没有就新建），如下： 文件下载地址：https://files-cdn.cnblogs.com... 三、建设地铁关系网Neo4j 反对导入本地以及网络资源中的 CSV 文件数据，并且能够从CSV文件数据中，间接建设图形节点以及节点关系。具体 cypher 语句，如下： 建设地铁站点LOAD CSV WITH HEADERS FROM "file:///station.csv" AS lineMERGE (p:Station{id:line.id,name:line.name});建设站点连贯LOAD CSV WITH HEADERS FROM "file:///line1.csv" AS line1match (from1:Station{name:line1.sn}),(to1:Station{name:line1.en})merge (from1)-[r1:一号线{jl:line1.jl,xl:line1.xl}]->(to1);LOAD CSV WITH HEADERS FROM "file:///line2.csv" AS line2match (from2:Station{name:line2.sn}),(to2:Station{name:line2.en})merge (from2)-[r2:二号线{jl:line2.jl,xl:line2.xl}]->(to2);LOAD CSV WITH HEADERS FROM "file:///line4.csv" AS line4match (from4:Station{name:line4.sn}),(to4:Station{name:line4.en})merge (from4)-[r4:四号线{jl:line4.jl,xl:line4.xl}]->(to4);LOAD CSV WITH HEADERS FROM "file:///line5.csv" AS line5match (from5:Station{name:line5.sn}),(to5:Station{name:line5.en})merge (from5)-[r5:五号线{jl:line5.jl,xl:line5.xl}]->(to5);LOAD CSV WITH HEADERS FROM "file:///line6.csv" AS line6match (from6:Station{name:line6.sn}),(to6:Station{name:line6.en})merge (from6)-[r6:六号线{jl:line6.jl,xl:line6.xl}]->(to6);LOAD CSV WITH HEADERS FROM "file:///line7.csv" AS line7match (from7:Station{name:line7.sn}),(to7:Station{name:line7.en})merge (from7)-[r7:七号线{jl:line7.jl,xl:line7.xl}]->(to7);LOAD CSV WITH HEADERS FROM "file:///line8.csv" AS line8match (from8:Station{name:line8.sn}),(to8:Station{name:line8.en})merge (from8)-[r8:八号线{jl:line8.jl,xl:line8.xl}]->(to8);LOAD CSV WITH HEADERS FROM "file:///line9.csv" AS line9match (from9:Station{name:line9.sn}),(to9:Station{name:line9.en})merge (from9)-[r9:九号线{jl:line9.jl,xl:line9.xl}]->(to9);LOAD CSV WITH HEADERS FROM "file:///line10.csv" AS line10match (from10:Station{name:line10.sn}),(to10:Station{name:line10.en})merge (from10)-[r10:十号线{jl:line10.jl,xl:line10.xl}]->(to10);LOAD CSV WITH HEADERS FROM "file:///line13.csv" AS line13match (from13:Station{name:line13.sn}),(to13:Station{name:line13.en})merge (from13)-[r13:十三号线{jl:line13.jl,xl:line13.xl}]->(to13);LOAD CSV WITH HEADERS FROM "file:///line14.csv" AS line14match (from14:Station{name:line14.sn}),(to14:Station{name:line14.en})merge (from14)-[r14:十四号线{jl:line14.jl,xl:line14.xl}]->(to14);LOAD CSV WITH HEADERS FROM "file:///line15.csv" AS line15match (from15:Station{name:line15.sn}),(to15:Station{name:line15.en})merge (from15)-[r15:十五号线{jl:line15.jl,xl:line15.xl}]->(to15);LOAD CSV WITH HEADERS FROM "file:///linebt.csv" AS linebtmatch (frombt:Station{name:linebt.sn}),(tobt:Station{name:linebt.en})merge (frombt)-[rbt:八通线{jl:linebt.jl,xl:linebt.xl}]->(tobt);LOAD CSV WITH HEADERS FROM "file:///linecp.csv" AS linecpmatch (fromcp:Station{name:linecp.sn}),(tocp:Station{name:linecp.en})merge (fromcp)-[rcp:昌平线{jl:linecp.jl,xl:linecp.xl}]->(tocp);LOAD CSV WITH HEADERS FROM "file:///lineyz.csv" AS lineyzmatch (fromyz:Station{name:lineyz.sn}),(toyz:Station{name:lineyz.en})merge (fromyz)-[ryz:亦庄线{jl:lineyz.jl,xl:lineyz.xl}]->(toyz);LOAD CSV WITH HEADERS FROM "file:///linedx.csv" AS linedxmatch (fromdx:Station{name:linedx.sn}),(todx:Station{name:linedx.en})merge (fromdx)-[rdx:大兴线{jl:linedx.jl,xl:linedx.xl}]->(todx);LOAD CSV WITH HEADERS FROM "file:///linefs.csv" AS linefsmatch (fromfs:Station{name:linefs.sn}),(tofs:Station{name:linefs.en})merge (fromfs)-[rfs:房山线{jl:linefs.jl,xl:linefs.xl}]->(tofs);LOAD CSV WITH HEADERS FROM "file:///linejc.csv" AS linejcmatch (fromjc:Station{name:linejc.sn}),(tojc:Station{name:linejc.en})merge (fromjc)-[rjc:机场线{jl:linejc.jl,xl:linejc.xl}]->(tojc);执行成果备注：Neo4j浏览器须要开启多语句执行配置，否则会报语句执行谬误，配置界面如下： ...

作者| 西湖数据智能研究院高级研发工程师 无极 大千世界纷繁复杂，万物之间总会有千头万绪的关系。随着古代商业社会的倒退，事物的关联关系越发盘根错节，传统的关系存储曾经不能满足咱们的业务需要。“图”作为关系摸索将来倒退的风向标，能够更为直观地帮忙人们认知事物，开掘数据之间的神秘，为数据价值的体现开拓了新天地。 作为业余的数据智能上市公司，个推在图利用剖析方面也进行了丰盛的实际。本文将讲述图的常见业务场景、Neo4j在个推的落地利用案例和优化动作，并在此基础上创新性地提出了个推独有的Neo4j社区版 HA（High Availability） 计划。 01 图驰名的柯尼斯堡七桥问题拉开了图的新篇章。1736年， 莱昂哈德·欧拉针对该问题，进行了数学形象，用二维矩阵予以示意，奠定了图论的根底。 图片来源于neo4j.com 什么是图？ 图的定义指出，图G由两个汇合形成，记作G=<V,E> 。其中V是顶点的非空无限汇合，E是边的无限汇合，边是顶点的无序对或有序对汇合。为了更好地了解图，咱们能够看看上面的例子。 图片来源于neo4j.com 图中展现了3200个机场与60000条航线。对应图的定义，每个机场就是 V汇合，航线则是E汇合。 图有哪些存储形式？ • 图的邻接矩阵 • 图的邻接表 • 有向图的十字链表存储示意 • 无向图的邻接多重表存储示意 图有哪些遍历形式？ • 深度优先遍历(DFS) • 广度优先遍历(BFS) 图数据库 图数据库(GraphDatabase) 并非指存储图片的数据库，而是指反对以图数据结构存储和查问数据的数据库。图数据库是一种在线数据库管理系统，具备解决图数据模型的创立、读取、更新和删除（CRUD）操作。 图片来源于amazon.com 图存储 一些图数据库应用原生图存储，这类存储是通过优化的，并且是专门为了存储和治理图而设计的。并不是所有图数据库都应用原生图存储，也有一些图数据库将图数据序列化，而后保留到关系型数据库、面向对象数据库，或其余通用数据存储中。 图解决引擎 原生图解决（也称为无索引邻接）因为其连贯的节点在数据库中能够物理地指向彼此，因而被认为是解决图数据的最无效的办法。非原生图解决应用其余办法来解决CRUD操作。 图常见业务场景 图片来源于amazon.com 上图中展现了图在 社交网络、举荐零碎、常识图谱、欺诈检测、生命科学、网络运维等业务场景中的利用。举荐零碎是图的一个典型利用，比方当咱们想要查问难看的影片之时，售票软件会依据咱们常常看的类型和格调帮咱们举荐相似的电影。 图数据库排名 依据 DB-Engines 统计， 2020 年图数据库受欢迎水平排行榜清晰地表明Neo4j 曾经抢占了图数据库的半壁江山。 02 Neo4j 图数据库Neo4j是一个高性能的NOSQL图形数据库，它将结构化数据存储在网络上而不是表中。它是一个嵌入式的、基于磁盘的、具备齐全的事务个性的Java长久化引擎，也能够被看作是一个高性能的图引擎，该引擎具备成熟数据库的所有个性。 Neo4j让程序员工作在一个面向对象的、灵便的网络结构下而不是严格、动态的表中——但他们能够还能享受到具备齐全的事务个性、企业级的数据库的所有益处。 图片来源于neo4j.com 图中展现了Neo4j图数据库从存储到剖析的平台生态。 Neo4j 社区版(4.0.6)存储剖析 图片来源于neo4j.com ...

作者| 西湖数据智能研究院高级研发工程师 无极 大千世界纷繁复杂，万物之间总会有千头万绪的关系。随着古代商业社会的倒退，事物的关联关系越发盘根错节，传统的关系存储曾经不能满足咱们的业务需要。“图”作为关系摸索将来倒退的风向标，能够更为直观地帮忙人们认知事物，开掘数据之间的神秘，为数据价值的体现开拓了新天地。 作为业余的数据智能上市公司，个推在图利用剖析方面也进行了丰盛的实际。本文将讲述图的常见业务场景、Neo4j在个推的落地利用案例和优化动作，并在此基础上创新性地提出了个推独有的Neo4j社区版 HA（High Availability） 计划。 01 图驰名的柯尼斯堡七桥问题拉开了图的新篇章。1736年， 莱昂哈德·欧拉针对该问题，进行了数学形象，用二维矩阵予以示意，奠定了图论的根底。 图片来源于neo4j.com 什么是图？ 图的定义指出，图G由两个汇合形成，记作G=<V,E> 。其中V是顶点的非空无限汇合，E是边的无限汇合，边是顶点的无序对或有序对汇合。为了更好地了解图，咱们能够看看上面的例子。 图片来源于neo4j.com 图中展现了3200个机场与60000条航线。对应图的定义，每个机场就是 V汇合，航线则是E汇合。 图有哪些存储形式？ • 图的邻接矩阵 • 图的邻接表 • 有向图的十字链表存储示意 • 无向图的邻接多重表存储示意 图有哪些遍历形式？ • 深度优先遍历(DFS) • 广度优先遍历(BFS) 图数据库 图数据库(GraphDatabase) 并非指存储图片的数据库，而是指反对以图数据结构存储和查问数据的数据库。图数据库是一种在线数据库管理系统，具备解决图数据模型的创立、读取、更新和删除（CRUD）操作。 图片来源于amazon.com 图存储 一些图数据库应用原生图存储，这类存储是通过优化的，并且是专门为了存储和治理图而设计的。并不是所有图数据库都应用原生图存储，也有一些图数据库将图数据序列化，而后保留到关系型数据库、面向对象数据库，或其余通用数据存储中。 图解决引擎 原生图解决（也称为无索引邻接）因为其连贯的节点在数据库中能够物理地指向彼此，因而被认为是解决图数据的最无效的办法。非原生图解决应用其余办法来解决CRUD操作。 图常见业务场景 图片来源于amazon.com 上图中展现了图在 社交网络、举荐零碎、常识图谱、欺诈检测、生命科学、网络运维等业务场景中的利用。举荐零碎是图的一个典型利用，比方当咱们想要查问难看的影片之时，售票软件会依据咱们常常看的类型和格调帮咱们举荐相似的电影。 图数据库排名 依据 DB-Engines 统计， 2020 年图数据库受欢迎水平排行榜清晰地表明Neo4j 曾经抢占了图数据库的半壁江山。 02 Neo4j 图数据库Neo4j是一个高性能的NOSQL图形数据库，它将结构化数据存储在网络上而不是表中。它是一个嵌入式的、基于磁盘的、具备齐全的事务个性的Java长久化引擎，也能够被看作是一个高性能的图引擎，该引擎具备成熟数据库的所有个性。 Neo4j让程序员工作在一个面向对象的、灵便的网络结构下而不是严格、动态的表中——但他们能够还能享受到具备齐全的事务个性、企业级的数据库的所有益处。 图片来源于neo4j.com 图中展现了Neo4j图数据库从存储到剖析的平台生态。 Neo4j 社区版(4.0.6)存储剖析 图片来源于neo4j.com ...

本文首发于 Nebula Graph 官网博客：https://nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin/摘要：在本文中，BOSS 直聘大数据开发工程师次要分享一些他们外部的技术指标和选型，以及很多小伙伴感兴趣的 Dgraph 比照应用教训。 业务背景在 Boss 直聘的平安风控技术中，须要用到大规模图存储和开掘计算，之前次要基于自建的高可用 Neo4j 集群来保障相干利用，而在实时行为剖析方面，须要一个反对日增 10 亿关系的图数据库，Neo4j 无奈满足利用需要。 针对这个场景，后期咱们次要应用 Dgraph，踩过很多坑并和 Dgraph 团队连线会议，在应用 Dgraph 半年后最终还是抉择了更贴合咱们需要的 Nebula Graph。具体的比照 Benchmark 曾经有很多团队在论坛分享了，这里就不再赘述，次要分享一些技术指标和选型，以及很多小伙伴感兴趣的 Dgraph 比照应用教训。 技术指标硬件配置如下： 处理器：Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz 80(cores)内存：DDR4，128G存储：1.8T SSD网络：万兆Nebula Graph 部署 5 个节点，按官网倡议 3 个 metad / 5 个 graphd / 5 个 storaged 软件Nebula Graph 版本：V1.1.0操作系统：CentOS Linux release 7.3.1611 (Core)配置次要调整的配置和 storage 相干# 依照文档倡议，配置内存的 3 分之 1--rocksdb_block_cache=40960# 参数配置减小内存应用--enable_partitioned_index_filter=true--max_edge_returned_per_vertex=100000指标目前平安行为图保留 3 个月行为，近 500 亿边，10 分钟聚合写入一次，日均写入点 3,000 万，日均写入边 5.5 亿，插入延时 <=20 ms。 ...

本文为微众银行大数据平台：周可在 nMeetup 深圳场的演讲这里文字稿，演讲视频参见：B站 自我介绍下，我是微众银行大数据平台的工程师：周可，明天给大家分享一下 Nebula Graph 在微众银行 WeDataSphere 的实际状况。 先来说下图数据库利用背景。 WeDataSphere 图数据库架构是基于 JanusGraph 搭建，正如邸帅在演讲《NebulaGraph - WeDataSphere 开源介绍》中提及的那样，次要用于解决微众银行数据治理中的数据血统问题。在应用 JanusGraph 过程中，微众银行发现 JanusGraph 自身依赖组件较多，数据存储在 HBase 中，索引存储在 Eleasticsearch 中，而因为受分布式高可用和两地三核心架构标准要求，要搭建一套残缺的图数据库系统波及技术点较多，比方高可用问题，再加上三个组件串联，须要解决很多技术问题。而且，自身 JanusGraph 这块数据写入性能也存在问题，当然自身咱们对 JanusGraph 的优化也较少，次要集中在参数调整和平安性能晋升。 过后用这套零碎解决的数据量大略是每天 60 万个点，百万级的边，差不多一天要花 5 个小时左右能力实现写入。这就导致业务方须要应用血统数据时，大数据平台不能及时提供。 至于微众银行大数据平台为什么选用 Nebula Graph，微众银行晚期调研过一些商用、开源的图数据库解决方案，测试局部这里不做赘述，能够参考下 Nebula Graph 社区 美团、腾讯云平安团队和 Boss 直聘 做的性能测评。 这里说下方才 60 万个点、百万级别边这个场景的状况，在单节点低配机器部署状况下，微众银行导入数据基本上在 20 分钟内实现。Nebula Graph 的写入性能十分好，微众银行大数据平台这块业务对查问的性能要求并不高，Nebula Graph 也能满足大数据平台这块的查问要求。 微众银行的图数据库抉择还有一个分量考核点，高可用和容灾的架构反对。这个考核项，Nebula Graph 自身的架构存在肯定劣势，合乎微众银行行内硬性的架构要求和标准。加上大数据平台自身旨在构建一个残缺的数据流生态，Nebula Graph 提供了一些大数据相干开源组件，比方：Connector，Exchange，这些工具能很好地同大数据平台进行联合。 最初一点，回归到人的问题——微众银行同开源社区的交换等同于跟其余技术人的交换。和 Nebula Graph 社区交换过程中发，微众银行发现不论是在 PoC 微信群，还是在 Nebula Graph 社区论坛上提问题，官网反馈十分及时。印象较深的一点是，有一天早晨 10 点多，大数据平台在 Nebula Graph 研发人员领导下优化了一个参数，咱们在微信群里和 Nebula Graph 反馈，这个参数调整之后解决了生产问题，Nebula Graph 研发同学还给咱们发了一个 666 的表情。[手动狗头] 哈哈哈哈挺好。 ...

大家好，我是洋仔，JanusGraph图解系列文章，实时更新~ 图数据库文章总目录：整顿所有图相干文章，请移步(超链)：图数据库系列-文章总目录 源码剖析相干可查看github（码文不易，求个star~）： https://github.com/YYDreamer/janusgraph下述流程高清大图地址：https://www.processon.com/view/link/5f471b2e7d9c086b9903b629 版本：JanusGraph-0.5.2 转载文章请保留以下申明： 作者：洋仔聊编程微信公众号：匠心Java原文地址：https://segmentfault.com/u/yoylee注释JanusGraph的数据导入过程次要分为三阶段：prepare（筹备）、serialize（序列化）、commit（提交）；不同阶段有不同的作用，如下： 上面咱们别离从导入vertex节点和edge边两局部来剖析写流程 倡议根据源码同步看本文章，便于了解！一：vertex数据写流程上面vertex节点数据的导入， prepare阶段次要是根据以后给定的参数，组装出对应的vertex 或者 edge 对象；对象中蕴含对应的id、索引信息、属性信息和锁信息等； 过程中蕴含以下几种作用： 默认增加vertex exist属性，值为true，标识以后节点是否存在默认增加label edge边，标识以后的节点 或者 边是什么label生成vertex、edge、property的全局分布式惟一id自定义属性验证是否满足唯一性束缚次要流程如下图（倡议按照源码一块查看，上述github地址已给出）： serialize阶段次要是对上述prepare阶段筹备好的数据进行序列化为二进制数据，为存储二进制数据到backend storage做筹备； 另外获取本地锁 + 分布式锁数据插入（此处只是将数据插入到Hbase，插入胜利并不代表获取胜利） 过程中蕴含以下几种作用： 序列化所有relation数据并存储，蕴含属性、label edge、normal edge获取属性对应index须要更新的数据，并序列化存储； 蕴含组合索引和mixed index的解决获取基于图实例的本地锁获取了本地锁的前提前，获取edge lock 和 index lock分布式锁（此处的获取锁只是将对应的KLV存储到Hbase中！存储胜利并不代表获取锁胜利，在commit阶段才会去查看是不是获取分布式锁胜利！）次要流程如下图： commit阶段次要是获取本地锁+分布式锁胜利后，将对应序列化后的数据增加到对应的backend storage中；实现图数据插入过程！ 在此阶段才会对图库中的实在数据开始影响，才会波及到事务的回滚机制； 过程中蕴含以下几种作用： 判断分布式锁的状态，获取胜利则进行数据长久化；不胜利则失败长久化relation数据长久化index数据，蕴含组合索引存储到第三方存储；mixed index存储到第三方索引库中删除对应的本地锁 和 分布式锁的占用次要流程如下图： 二：edge数据写流程针对于edge的写数据流程，整体的流程和vertex节点的数据写入雷同，有几点不同，上面一一列出： 1、生成分布式惟一id的过程 导入Edge数据在生成edge的惟一id时，partition id的获取不再是随机获取，而是尝试获取边对应的out vertex的partition id； id的组成部分也不同，没有idPadding局部； 具体解释请看：《JanusGraph-分布式id生成策略》文章 2、在edge的导入中，没有同vertex数据导入，增加默认的节点是否存在属性和节点和节点对应label的边 3、获取edge对应的属性的index update时不同 在导入vertex数据时，将节点对应的属性作为relation寄存在addRelation中，而后收集所有的属性relation循环获取index uodate；如下伪代码： for (InternalRelation add : Iterables.filter(addedRelations,filter)) { if (add.isProperty()) mutatedProperties.put(vertex,add); // 此处只操作属性类型的 mutations.put(vertex.longId(), add);}// 此处，收集节点对应属性对应的索引须要更新的数据、减少或删除节点时才有作用； 针对于插入edge的操作，不波及此处for (InternalVertex v : mutatedProperties.keySet()) { indexUpdates.addAll(indexSerializer.getIndexUpdates(v,mutatedProperties.get(v)));}而在edge数据导入中，只将edge这条边作为relation插入到addRelation中，所以无奈获取属性relation，转而通过收集过程中，对每个edge对应的所有属性进行别离获取；如下伪代码： ...

上一篇文章：不晓得为什么掘金我发不出文章，找不到那里违规了，上一篇文章我公布到思否了： https://segmentfault.com/a/11... 如何装置neo4j - apoc 插件有英语浏览能力倡议参考官网文档：https://neo4j.com/developer/n... 1. 下载neo4j - apoc 插件进入github ： https://github.com/neo4j-cont... 找到和以后neo4j 匹配的版本， 我抉择3.5.0.12 的版本 这里提供我的：链接：https://pan.baidu.com/s/1Tb7f... 提取码：bzwh 2. 具体的装置步骤下载好之后，放入到 D:\zxd\tool\neo4j-community-3.5.12-windows\neo4j-community-3.5.12\plugins 上面执行neo4j stop，敞开neo4j 服务进入 ~/conf 上面，找到neo4j.conf ~示意你的neo4j 装置地位批改#dbms.security.procedures.whitelist=apoc.coll.*,apoc.load.* 在这一行的上面减少dbms.security.procedures.unrestricted=apoc.*的配置，装置apoc插件上面的图看起来就像这样：\#dbms.security.procedures.whitelist=apoc.coll.,apoc.load.dbms.security.procedures.unrestricted=apoc.* 输出 neo4j start 启动neo4j 服务在可视化界面，输出return apoc.version() ,如果报错阐明没装置对，显示如下页面，证实apoc 插件装置胜利 Neo4j 集成到java外面1. 配置maven，退出依赖<!-- neo4j 依赖包 --><dependency> <groupId>org.neo4j.driver</groupId> <artifactId>neo4j-java-driver</artifactId> <version>1.5.0</version></dependency>2. 应用neo4j 集成java实战这是之前实战的是用的形式，这里说下我大抵的设计记录 需要： neo4j 实现插拔式配置，没有配置的状况下进行连贯不会影响程序运行所有的配置都须要放在application_setting.xml当中如果连贯neo4j 失败，不做解决形象接口在core 包外面， 设计专用凋谢接口。 /** * 构建neo4j url地址 * @return */ String buildUrl(); /** * 构建neo4j 用户名 * @return */ String buildUsername(); /** * 构建neo4j 明码 * @return */ String buildPassword(); /** * 构建neo4j 配置， 目前应用默认 配置 * @return */ Config buildConfig(); /** * 是否开启自定义配置 * @return */ boolean enableCustomConfig(); /** * 构建 Neo4j csv同步地址的前置 * 默认为 file:/// * * @return */ String buildCvsPrefix(); /** * 构建 neo4j csv同步的一般标签文件名 * @return */ String buildNormalTagSyncFileName(); /** * 构建 neo4j csv同步的业务标签文件名 * @return */ String buildBusinessTagSyncFileName(); /** * 构建 neo4j csv同步的用户标签文件名 * @return */ String buildUserTagSyncFileName(); /** * 一般标签和业务标签的关联csv文件名称 * @return */ String buildNormalTagBizSyncFileName(); /** * 一般标签和用户标签的关联csv文件名称 * @return */ String buildNormalTagUserSyncFileName(); /** * 业务标签和用户标签的关联csv文件名称 * @return */ String buildBizTagUserSyncFileName(); /** * 主题分类（业务）标签子父关联csv文件名称 * @return */ String buildBizChildSyncFileName(); /** * 一般标签标签子父关联csv文件名称 * TODO: 目前一般标签没有子父关联关系，后续须要拓展请凋谢此接口 by zhaoxudong * @return */// String buildNormalChildSyncFileName(); /** * 用户标签的子父关联csv文件名称 * @return */ String buildUserChildSyncFileName();具体实现maven的其余我的项目工程，只有实现了下面的接口，就能够依据本人的设定去设置如何读取配置，上面给出案例 ...

不同起源的异构数据间存在着千头万绪的关联，这种数据之间暗藏的关联关系和网络结构个性对于数据分析至关重要，图计算就是以图作为数据模型来表白问题并予以解决的过程。 一、背景随着网络信息技术的飞速发展，数据逐步向多源异构化方向倒退，且不同起源的异构数据之间也存在的千头万绪的关联，这种数据之间暗藏的关联关系和网络结构个性对于数据分析至关重要。但传统关系型数据库在剖析大规模数据关联个性时存在性能缺点、表白无限等问题，因而有着更弱小表达能力的图数据受到业界极大器重，图计算就是以图作为数据模型来表白问题并予以解决的过程。图能够交融多源多类型的数据，除了能够展现数据动态根底个性之外，还可通过图计算展现暗藏在数据之间的图构造个性和点对关联关系，成为社交网络、举荐零碎、常识图谱、金融风控、网络安全、文本检索等畛域重要的剖析伎俩。 二、算法利用为了撑持大规模图计算的业务需要，Nebula Graph 基于 GraphX 提供了 PageRank 和 Louvain 社区发现的图计算算法，容许用户通过提交 Spark 工作的模式执行算法利用。此外，用户也能够通过 Spark Connector 编写 Spark 程序调用 GraphX 自带的其余图算法，如 LabelPropagation、ConnectedComponent 等。 PageRankPageRank 是谷歌提出的用于解决链接剖析中网页排名问题的算法，目标是为了对互联网中数以亿计的网页进行排名。 PageRank 简介美国斯坦福大学的 Larry Page 和 Sergey Brin 在钻研网页排序问题时采纳学术界评判论文重要性的办法，即看论文的援用量以及援用该论文的论文品质，对应于网页的重要性有两个假如： 数量假如：如果一个网页 A 被很多其余网页链接到，则该网页比拟重要；品质假如：如果一个很重要的网页链接到网页 A，则该网页的重要性会被进步。并基于这两个假如提出 PageRank 算法。 PageRank 利用场景社交利用的类似度内容举荐在对微博、微信等社交平台进行社交网络分析时，能够基于 PageRank 算法依据用户通常浏览的信息以及停留时间实现基于用户的类似度的内容举荐； 剖析用户社交影响力在社交网络分析时依据用户的 PageRank 值进行用户影响力剖析； 文献重要性钻研依据文献的 PageRank 值评判该文献的品质，PageRank 算法就是基于评判文献品质的想法来实现设计。 此外 PageRank 在数据分析和开掘中也有很多的利用。 算法思路GraphX 的 PageRank 算法是基于 Pregel 计算模型的，该算法流程包含 3 步骤： 为图中每个节点（网页）设置一个同样的初始 PageRank 值；第一次迭代：沿边发送音讯，每个节点收到所有关联边上对点的信息，失去一个新的 PageRank 值；第二次迭代：用这组新的 PageRank 按不同算法模式对应的公式造成节点本人新的 PageRank。Louvain 社区发现Louvain 是用来进行社会网络开掘的社区发现算法，属于图的聚类算法。 ...

上一篇文章：不晓得为什么掘金我发不出文章，找不到那里违规了，上一篇文章我公布到思否了： https://segmentfault.com/a/11... 如何装置neo4j - apoc 插件有英语浏览能力倡议参考官网文档：https://neo4j.com/developer/n... 1. 下载neo4j - apoc 插件进入github ： https://github.com/neo4j-cont... 找到和以后neo4j 匹配的版本， 我抉择3.5.0.12 的版本 这里提供我的：链接：https://pan.baidu.com/s/1Tb7f... 提取码：bzwh 2. 具体的装置步骤下载好之后，放入到 D:\\zxd\\tool\\neo4j-community-3.5.12-windows\\neo4j-community-3.5.12\\plugins 上面执行neo4j stop，敞开neo4j 服务进入 ~/conf 上面，找到neo4j.conf ~示意你的neo4j 装置地位批改#dbms.security.procedures.whitelist=apoc.coll.*,apoc.load.* 在这一行的上面减少dbms.security.procedures.unrestricted=apoc.*的配置，装置apoc插件上面的图看起来就像这样：\#dbms.security.procedures.whitelist=apoc.coll.,apoc.load.dbms.security.procedures.unrestricted=apoc.* 输出 neo4j start 启动neo4j 服务在可视化界面，输出return apoc.version() ,如果报错阐明没装置对，显示如下页面，证实apoc 插件装置胜利 Neo4j 集成到java外面1. 配置maven，退出依赖<!-- neo4j 依赖包 --><dependency> <groupId>org.neo4j.driver</groupId> <artifactId>neo4j-java-driver</artifactId> <version>1.5.0</version></dependency>2. 应用neo4j 集成java实战这是之前实战的是用的形式，这里说下我大抵的设计记录 需要： neo4j 实现插拔式配置，没有配置的状况下进行连贯不会影响程序运行所有的配置都须要放在application_setting.xml当中如果连贯neo4j 失败，不做解决形象接口在core 包外面， 设计专用凋谢接口。 /** * 构建neo4j url地址 * @return */ String buildUrl(); /** * 构建neo4j 用户名 * @return */ String buildUsername(); /** * 构建neo4j 明码 * @return */ String buildPassword(); /** * 构建neo4j 配置， 目前应用默认 配置 * @return */ Config buildConfig(); /** * 是否开启自定义配置 * @return */ boolean enableCustomConfig(); /** * 构建 Neo4j csv同步地址的前置 * 默认为 file:/// * * @return */ String buildCvsPrefix(); /** * 构建 neo4j csv同步的一般标签文件名 * @return */ String buildNormalTagSyncFileName(); /** * 构建 neo4j csv同步的业务标签文件名 * @return */ String buildBusinessTagSyncFileName(); /** * 构建 neo4j csv同步的用户标签文件名 * @return */ String buildUserTagSyncFileName(); /** * 一般标签和业务标签的关联csv文件名称 * @return */ String buildNormalTagBizSyncFileName(); /** * 一般标签和用户标签的关联csv文件名称 * @return */ String buildNormalTagUserSyncFileName(); /** * 业务标签和用户标签的关联csv文件名称 * @return */ String buildBizTagUserSyncFileName(); /** * 主题分类（业务）标签子父关联csv文件名称 * @return */ String buildBizChildSyncFileName(); /** * 一般标签标签子父关联csv文件名称 * TODO: 目前一般标签没有子父关联关系，后续须要拓展请凋谢此接口 by zhaoxudong * @return */// String buildNormalChildSyncFileName(); /** * 用户标签的子父关联csv文件名称 * @return */ String buildUserChildSyncFileName();具体实现maven的其余我的项目工程，只有实现了下面的接口，就能够依据本人的设定去设置如何读取配置，上面给出案例 ...

本文由美团 NLP 团队高辰、赵登昌撰写首发于 Nebula Graph 官方论坛：https://discuss.nebula-graph.com.cn/t/topic/1377 1. 前言近年来，深度学习和常识图谱技术倒退迅速，相比于深度学习的“黑盒子”，常识图谱具备很强的可解释性，在搜寻举荐、智能助理、金融风控等场景中有着宽泛的利用。美团基于积攒的海量业务数据，联合应用场景进行充沛地开掘关联，逐渐建设起包含美食图谱、游览图谱、商品图谱在内的近十个畛域常识图谱，并在多业务场景落地，助力本地生存服务的智能化。 为了高效存储并检索图谱数据，相比传统关系型数据库，抉择图数据库作为存储引擎，在多跳查问上具备显著的性能劣势。以后业界出名的图数据库产品有数十款，选型一款可能满足美团理论业务需要的图数据库产品，是建设图存储和图学习平台的根底。咱们联合业务现状，制订了选型的根本条件： 开源我的项目，对商业利用敌对 领有对源代码的控制力，能力保障数据安全和服务可用性。反对集群模式，具备存储和计算的横向扩大能力 美团图谱业务数据量能够达到千亿以上点边总数，吞吐量可达到数万 qps，单节点部署无奈满足存储需要。可能服务 OLTP 场景，具备毫秒级多跳查问能力 美团搜寻场景下，为确保用户搜寻体验，各链路的超时工夫具备严格限度，不能承受秒级以上的查问响应工夫。具备批量导入数据能力 图谱数据个别存储在 Hive 等数据仓库中。必须有疾速将数据导入到图存储的伎俩，服务的时效性能力失去保障。咱们试用了 DB-Engines 网站上排名前 30 的图数据库产品，发现少数出名的图数据库开源版本只反对单节点，不能横向扩大存储，无奈满足大规模图谱数据的存储需要，例如：Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。通过调研比拟，最终纳入评测范畴的产品为：NebulaGraph（原阿里巴巴团队守业开发）、Dgraph（原 Google 团队守业开发）、HugeGraph（百度团队开发）。 2. 测试概要2.1 硬件配置数据库实例：运行在不同物理机上的 Docker 容器。单实例资源：32 外围，64GB 内存，1TB SSD 存储。【Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz】实例数量：32.2 部署计划Nebula v1.0.1Metad 负责管理集群元数据，Graphd 负责执行查问，Storaged 负责数据分片存储。存储后端采纳 RocksDB。 实例 1实例 2实例 3MetadMetadMetadGraphdGraphdGraphdStoraged[RocksDB]Storaged[RocksDB]Storaged[RocksDB]Dgraph v20.07.0Zero 负责管理集群元数据，Alpha 负责执行查问和存储。存储后端为 Dgraph 自有实现。 实例 1实例 2实例 3ZeroZeroZeroAlphaAlphaAlphaHugeGraph v0.10.4HugeServer 负责管理集群元数据和查问。HugeGraph 尽管反对 RocksDB 后端，但不反对 RocksDB 后端的集群部署，因而存储后端采纳 HBase。 ...

在上一篇[1]中，咱们通过 NetworkX 和 Gephi 展现了<势力的游戏>中的人物关系。在本篇中，咱们将展现如何通过 NetworkX 拜访图数据库 Nebula Graph。 NetworkXNetworkX [2] 是一个用 Python 语言开发的图论与简单网络建模工具，内置了大量罕用的图与简单网络分析算法，能够不便地进行简单网络数据分析、仿真建模等工作，功能丰富，简略易用。 在 NetworkX 中，图是由顶点、边和可选的属性形成的数据结构。顶点示意数据，边是由两个顶点惟一确定的，示意两个顶点之间的关系。顶点和边也能够领有更多的属性，以存储更多的信息。 NetworkX 反对 4 种类型的图： Graph：无向图DiGraph: 有向图MultiGraph: 多重无向图MultiDiGraph: 多重有向图在 NetworkX 中创立一个无向图： import networkx as nxG = nx.Graph()增加顶点： G.add_node(1)G.add_nodes_from([2,3,4])G.add_node(2,name='Tom',age=23)增加边： G.add_edge(2,3)G.add_edges_from([(1,2),(1,3)])g.add_edge(1, 2, start_year=1996, end_year=2019)在上一篇文章（一）中，咱们曾经演示了 NetworkX 的 Girvan-Newman 社区发现算法。 图数据库 Nebula GraphNetworkX 通常应用本地文件作为数据源，这在动态网络钻研的时候没什么问题，但如果图网络常常会发生变化——例如某些核心节点曾经不存在(Fig.1)或者引入了重要的网络拓扑变动(Fig.2)——每次生成全新的动态文件再加载剖析就有些麻烦，最好整个变动过程能够长久化在一个数据库中，并且能够实时地间接从数据库中加载子图或者全图做剖析。本文选用 Nebula Graph [3]作为存储图数据的图数据库。 Fig. 1 Fig. 2 Nebula Graph 提供了两种形式来获取图构造： 编写一个查问语句，拉取一个子图；全量扫描底层存储，获取一个残缺的全图。第一种形式适宜在一个大规模的图网络中通过精密的过滤和剪枝条件来获取合乎需要的若干个点和边。第二种形式更适宜于全图的剖析，这通常是在项目前期对全图进行一些启发式摸索，当有进一步认知后再用第一种形式做精密的剪枝剖析。 剖析完 Nebula Graph 两种获取图构造形式后，上面来查看 Nebula Graph 的 Python 客户端代码，nebula-python/nebula/ngStorage/StorageClient.py 与 nebula-python/nebula/ngMeta/MetaClient.py 就是和底层存储交互的 API, 外面有扫描点、扫描边、读取一堆属性等等一系列丰盛的接口。 ...

本文系腾讯云平安团队李航宇、邓昶博撰写图数据库在开掘黑灰团伙以及建设平安常识图谱等平安畛域有着人造的劣势。为了能更好的服务业务，抉择一款高效并且贴合业务倒退的图数据库就变得尤为要害。本文筛选了几款业界较为风行的开源图数据库与 Nebula Graph 进行了多角度的比照。 图数据库介绍Neo4jNeo4j 是目前业界宽泛应用的图数据库，蕴含社区版本和商用版本，本文中应用社区版本。 HugeGraphHugeGraph 是百度基于 JanusGraph 改良而来的分布式图数据库，次要利用场景是解决百度平安事业部所面对的反欺诈、威逼情报、黑产打击等业务的图数据存储和图建模剖析需要。具备良好的读写性能。 Nebula GraphNebula Graph 是一款开源的分布式图数据库，采纳 shared-nothing 分布式架构，善于解决千亿节点万亿条边的超大规模数据集，从而更好地服务企业级利用。 测试硬件环境 性能比照咱们应用不同量级的图从入库工夫，一度好友查问，二度好友查问，独特好友查问几个方面进行了比照，后果如下： 能够看到在导入性能上，数据量小的时候 Nebula Graph 的导入效率稍慢于 Neo4j，但在大数据量的时候Nebula Graph 的导入显著优于其余两款图数据库；在 3 种查问场景下， Nebula Graph 的效率都显著高于 Neo4j，与 HugeGraph 相比也有肯定的劣势。 查询语言比照 从查问语句的角度登程，Gremlin 比较复杂，nGQL 和 Cypher 比拟简练，从可读性角度登程，nGQL 比拟类 SQL 化，比拟合乎大家的应用习惯。 可视化比照 在可视化方面，所有的平台都还只处于可用状态，Nebula Graph 的选择性扩大在团伙开掘中是一个加分项，然而在二度后果展现晦涩度，展现后果自定义展现方面还有优化空间。 在比拟了多款业内次要应用的开源数据库后，咱们从性能，学习老本和与业务的贴合水平多个角度思考，最终抉择了性能出众，上手简略，能大幅提高业务效率的 Nebula Graph 图数据库。 本文首发于 Nebula Graph 论坛，浏览本文的你有任何疑难，欢送返回论坛和作者进行探讨，原帖传送门：https://discuss.nebula-graph.com.cn/t/topic/1013

因为 Nebula Graph 的底层存储应用了 RocksDB，出于运维治理须要，咱们的社区用户 @chenxu14 在 pr#2243 为 Nebula Graph 奉献了 RocksDB 统计信息收集的性能 ???????? 通过在 storage 服务配置文件中批改 --enable_rocksdb_statistics = true  即可开启收集 RocksDB 统计信息的性能。开启后，将会定期将统计信息转储到每个 DB 服务的日志文件中。 最近，chenxu14 为此性能带来了新的用法——反对通过 storage 服务自带的 Web 接口获取统计信息。此次 pr 提供了 3 种通过 Web 服务获取统计信息的办法： 获取全副统计信息；获取指定条目标信息；反对把后果以 json 格局返回。上面让咱们来体验一下这次的新性能吧~ 在 storage 的配置文件中批改：--enable_rocksdb_statistics = true 以开启收集 RocksDB 统计信息，批改后重启 storage 服务即可失效 拜访 http://storage_ip:port/rocksdb_stats 获取 RocksDB 全副统计信息（局部截图展现） 拜访 http://storage_ip:port/rocksdb_stats?stats=stats_name 获取局部 RocksDB 统计信息 在返回局部后果的查问地址根底上增加 & returnjson 获取局部 RocksDB 统计信息并以 json 格局返回 ...

Nebula Graph：一个开源的分布式图数据库。作为唯一能够存储万亿个带属性的节点和边的在线图数据库，Nebula Graph 不仅能够在高并发场景下满足毫秒级的低时延查询要求，还能够实现服务高可用且保障数据安全性。图数据库 Nebula RC1 主要更新本次 RC1 主要增强了 nGQL，新增 LIMIT , GROUP BY 等语句；算法方面增加了最短路径，全路径搜索。 Storage 层新增 PUT/GET 接口，支持 scale out/in，以及新增了 Golang 客户端以及多线程 Golang 数据导入工具。 nGQL新增 LIMIT 指定返回的记录数。(#750)管道操作中支持 YIELD 指定返回类型。(#745)新增 ORDER BY 对结果集进行排序 (#537)新增 udf_is_in 来查询特定集合的数据。(#1096)新增 DELETE VERTEX 删除指定的 vertex 和相关联的出入边。 (#868)新增 UUID() 函数生成唯一值. (#958, #961, #1031)支持逻辑运算符 XOR、OR、AND 和 NOT. (#858)支持 TIMESTAMP 数据类型. (#843)针对 STRING 数据类型，支持更多函数操作，比如 upper(), trim(), lower(), substr() 等. (#841)逻辑运算中支持类型转换 (#964)新增 SHOW CONFIGS 获取指定服务 [meta/storage/graph] 的配置项, GET CONFIGS 获取指定配置项值 and UPDATE CONFIGS 修改配置项值. (#504)SHOW HOSTS 新增 Leader 信息。(#918)支持 FIND PATH 最短路径、全路径搜索 (#847)GO 支持多个 edge types 的图查询。(#699)优化了源代码的编译流程。 (#1047, #948, #1083)Storage新增 PUT/GET 接口. (#977)支持 Leader balance. (#731, #881)支持 HTTP API 获取性能指标。(比如 QPS, Latency AVG/ P99/ P999 等)  (#872, #1136)支持 Scaling out/in。 (#421, #444, #795, #881, #998)Meta client 支持重试, 默认是 3 次. (#814)Tools新增 Golang Importer 工具，支持多线程从 CSV 导入数据.Change更改了 storaged 的配置模板Others将 metad ,  storaged  和 graphd  拆到不同 Image 中。增加 Dockerfiles 创建镜像。 (#923)新增 Golang 客户端，将客户端移到各自的 Repositories 下（vesoft-inc/nebula-go 和 vesoft-inc/nebula-java）。Coming Soon支持数据 Snapshot, 数据回滚功能增强从 Hive 数据导入功能Storage 层支持集群缩容引入 CI/CD附录最后是 Nebula 的 GitHub 地址，欢迎大家试用，有什么问题可以向我们提 issue。GitHub 地址：https://github.com/vesoft-inc/nebula；加入 Nebula Graph 交流群，请联系 Nebula Graph 官方小助手微信号：NebulaGraphbot ...

Nebula Graph 是一个高性能的分布式开源图数据库，本文为大家介绍 Nebula Graph 的整体架构。 一个完整的 Nebula 部署集群包含三个服务，即  Query Service，Storage Service 和 Meta Service。每个服务都有其各自的可执行二进制文件，这些二进制文件既可以部署在同一组节点上，也可以部署在不同的节点上。 Meta Service上图为 Nebula Graph 的架构图，其右侧为 Meta Service 集群，它采用 leader / follower 架构。Leader 由集群中所有的 Meta Service 节点选出，然后对外提供服务。Followers 处于待命状态并从 leader 复制更新的数据。一旦 leader 节点 down 掉，会再选举其中一个 follower 成为新的 leader。 Meta Service 不仅负责存储和提供图数据的 meta 信息，如 schema、partition 信息等，还同时负责指挥数据迁移及 leader 的变更等运维操作。 存储计算分离在架构图中 Meta Service 的左侧，为 Nebula Graph 的主要服务，Nebula 采用存储与计算分离的架构，虚线以上为计算，以下为存储。 存储计算分离有诸多优势，最直接的优势就是，计算层和存储层可以根据各自的情况弹性扩容、缩容。 存储计算分离还带来的另一个优势：使水平扩展成为可能。 此外，存储计算分离使得 Storage Service 可以为多种类型的个计算层或者计算引擎提供服务。当前 Query Service 是一个高优先级的计算层，而各种迭代计算框架会是另外一个计算层。 ...