共计 14171 个字符,预计需要花费 36 分钟才能阅读完成。
本文搭配同主题分享视频浏览更佳,《多数据源的数据治理实际》
如果你装好某款数据库产品,比方:分布式图数据库 NebulaGrpah,蠢蠢欲动的第一步是不是就让它干活搞数据呢?好的,当初问题来了,如何把绝对原始的数据处理、建模并导入 NebulaGraph 呢?本文是一个端到端的示例演示,从多数据源聚合数据,清理、利用 dbt 转换成 NebulaGraph 建模的属性图点边记录,最初导入成图谱的全流程。
构建常识图谱
当初假如你是一个相似于 Netflix、爱奇艺之类的视频服务提供商,咱们须要利用图数据库搭建一个 用户 - 电影
的常识图谱,来 辅助、撑持视频举荐、问答和举荐理由等常见由图谱撑持的场景。因为工夫的关系,这里先用咱们相熟的老朋友——图数据库 NebulaGraph 来搞定常识图谱。
一般来说,常识图谱须要的数据会有不同的数据起源,比方一些公开的 API、数仓中的不同数据库、动态文件。这时候,咱们如果要构建常识图谱,须要以下 3 个步骤:
- 剖析可能获取的数据;
- 选取关怀的关联关系,图建模;
- 抽取关联关系,导入图数据库。
数据源
这里咱们会用到两个数据源 OMDB 和 MovieLens。
OMDB 是一个凋谢的电影数据库,将用来模仿公司外部的业务数据。咱们能够取得的信息有:
- 电影
- 电影的分类
- 电影中的工作人员,包含:导演、动作领导、演员、后期制作等人员信息
- 电影封面、宣传片等电影信息
MovieLens 是一个凋谢的数据集,用来模仿公司外部的用户数据。咱们能够取得的信息有:
- 用户
- 电影
- 用户对电影的评分交互
图建模
在之前的文章《基于图数据库的举荐零碎》里咱们介绍了举荐零碎的图数据库根本用法。在那篇文章中,内容过滤偏重关注 用户 --> 电影
、 电影 --> 分类
、 电影 --> 演员
、 电影 --> 导演
等关系,协同过滤则关注 用户 --> 电影
的关系,以及举荐理由服务关注以上所有的关系。
总结起来,咱们须要的边有:
- watched(rate(double))
- with_genre
- directed_by
- acted_by
联合已有信息,绝对应地将顶点中可能须要被关注的信息作为属性,给出点 tag 的初始布局:
- user(user_id)
- movie(name)
- person(name, birthdate)
- genre(name)
表数据到常识图谱的映射
有了指标的图谱构造定义,咱们来看看手上的数据如何映射到它。
OMDB 数据
首先是 OMDB 数据,它由很多表组成,比方 all_movies
这张表,存储了所有的电影、以及它们在不同语言下的名字:
movie_id | name | language_iso_639_1 | official_translation |
---|---|---|---|
1 | Cowboy Bebop | de | 1 |
1 | Cowboy Bebop | en | 1 |
2 | Ariel – Abgebrannt in Helsinki | de | 0 |
3 | Shadows in Paradise | en | 0 |
3 | Im Schatten des Paradieses | de | 0 |
3 | Schatten im Paradies | de | 1 |
而 all_casts
表格中保有所有电影相干的工作人员:
movie_id | person_id | job_id | role | position |
---|---|---|---|---|
11 | 1 | 21 | 1 | |
11 | 1 | 13 | 1 | |
11 | 2 | 15 | Luke Skywalker | 1 |
11 | 3 | 15 | Han Solo | 3 |
11 | 4 | 15 | Leia Organa | 2 |
然而这里的每一个人的姓名等信息、以及他 / 她在电影中任职的职位,则别离在表 job_names
和 all_people
中:
这里解说下 job_names
表,1 代表编剧、2 代表制作人。有意思的是,和上表的电影 id 与 name 字段一样,job_id 到 name 也是一对多的关系,因为 OMDB 中的数据都是多语言的。
job_id | name | language_iso_639_1 |
---|---|---|
1 | Autoren | de |
1 | Writing Department | en |
1 | Departamento de redacción | es |
1 | Département écriture | fr |
1 | Scenariusz | pl |
2 | Produzenten | de |
2 | Production Department | en |
上面这张表是 all_people
:
id | name | birthday | deathday | gender |
---|---|---|---|---|
1 | George Lucas | 1944-05-14 | \N | 0 |
2 | Mark Hamill | 1951-09-25 | \N | 0 |
3 | Harrison Ford | 1942-07-13 | \N | 0 |
4 | Carrie Fisher | 1956-10-21 | 2016-12-27 | 1 |
5 | Peter Cushing | 1913-05-26 | 1994-08-11 | 0 |
6 | Anthony Daniels | 1946-02-21 | \N | 0 |
这是在数据起源是表构造、RDBMS 中,是一个很典型的状况,所以对于 movie <-[directed_by]-(person)
这个关系,就波及了 all_movies
,all_casts
,all_people
,job_names
四个表格:
-
directed_by
- 终点 person_id 在
all_casts
之中 -
起点 movie_id 在
all_casts
之中- 条件是 job_id 为
job_names
之中的“director”
- 条件是 job_id 为
- 终点 person_id 在
-
movie
- person_id 在
all_casts
之中 - 名字来自
all_movies
中按 id 查找,language 为“en”
- person_id 在
-
person
- movie_id 在
all_casts
之中 - name、birthday 在
all_people
之中
- movie_id 在
所有 OMDB 中咱们关怀的表的关联如图:
MovieLens 数据集
下面咱们讲述了单数据源的场景,只有繁多数据源、数据表或者数仓的数据。但在实在场景中,咱们还须要从其余源头收取数据,并聚合起来。在本例中,咱们还须要从 MovieLens 的数据集中抽取须要的常识。
这里,波及到 MovieLens 数据集,咱们利用的只有:用户 --> 电影
,这一条关系。
movies.csv
数据:
movieId | title | genres |
---|---|---|
1 | Toy Story (1995) | Adventure |
2 | Jumanji (1995) | Adventure |
3 | Grumpier Old Men (1995) | Comedy |
4 | Waiting to Exhale (1995) | Comedy |
ratings.csv
数据:
userId | movieId | rating | timestamp |
---|---|---|---|
1 | 1 | 4 | 964982703 |
1 | 3 | 4 | 964981247 |
1 | 6 | 4 | 964982224 |
从两个表的数据预览仿佛能够得出:
-
watched
- 终点来自于
ratings.csv
中的 userId - 起点来自于
ratings.csv
中的 movieId - 评分来自于
ratings.csv
中的 rating
- 终点来自于
-
user
- 来自于
ratings.csv
中的 userId
- 来自于
然而,仔细的你们肯定发现 MovieLens 数据集中的 movieId 和来自于 OMDB 中的电影 id 齐全是不同的两套体系。如果咱们须要让它们关联起来,须要将 MovieLens 里的 movieId 转换成为 OMDB 中的电影 id,而它们之间的关联条件则是电影的题目。
然而,通察看咱们晓得:
- OMDB 电影中题目是多语言的
- MovieLens 中的题目结尾带有
(1995)
这样的年份信息
所以咱们最终的论断为
-
watched
- 终点来自于
ratings.csv
中的 userId - 起点来自于
ratings.csv
中的 movieId,起点要从movies.csv
中的 title,在 OMDB 之中查找,失去 OMDB 的 movie_id。查找条件为去掉年份,从 OMDB 的英文题目中进行匹配 - 评分来自于
ratings.csv
中的 rating
- 终点来自于
-
user
- 来自于
ratings.csv
中的 userId
- 来自于
当初,这个表格之间的关系如下
映射数据到图谱(属性图)
到这里小结下,咱们须要对多个数据源中的不同表格(或者表格模式的 CSV 文件)进行聚合,这样的对应关系如图所示:蓝色虚线示意图中顶点的数据信息起源,粉色虚线示意边信息的起源。
此外,咱们还要对不同表中个体的 id 进行格式化,比方 user_id,是自增的数字,咱们要转换成全局惟一的 vertex_id。比拟不便的办法是在现有 id 的根底上减少字符串前缀,比方 u_
。
最终,以 user -[watched]-> movie
关系为例,咱们能够解决失去这样的表构造数据:
user_id | rating | title | omdb_movie_id |
---|---|---|---|
u_1 | 5 | Seven (a.k.a. Se7en) | 807 |
u_1 | 5 | Star Wars: Episode IV – A New Hope | 11 |
u_1 | 5 | Star Wars: Episode IV – A New Hope | 10 |
u_1 | 4 | Mask, The | 832 |
u_1 | 3 | Mrs. Doubtfire | 832 |
其中每一行记录中存在三个图上的构造信息:
- user 顶点 id
- movie 顶点 id
- watched 边的 rating 值
数据工具
好的,咱们当初曾经实现了数据的剖析与建模设计,在进入”抽取关联关系,导入图数据库“环节之前,先介绍一下咱们要用到的工具。
”抽取关联关系“能够简略认为是 ETL 中的 Extract 和 Transform。实质上就是工程上执行数据映射与转换的工作,市面上有很多不同格调的工具、开源我的项目能够做 ETL 这件事。这里咱们用到我集体比拟喜爱的工具:dbt。
数据转换利器 dbt
dbt 是一个开源的数据转换工具,它有十分成熟的社区和生态,能够在大多数支流数仓之中进行高效、可控、高质量的数据转换工作。无论是长期的转换工作(ad-hoc),还是在给定的定时 pipeline 中进行简单编排,dbt 都能够很好胜任。它的一大特色就是应用 SQL LIKE 语言去形容数据转换的规定。此外,它还基于 GitOps 能够十分优雅地多人合作、保护超大规模数据团队里简单的数据处理作业。而 dbt 内置的数据测试能力能够很好地控制数据品质,可复现、控制数据问题。
dbt 不仅有许多集成的子项目,还能和像是 Meltano、Airflow、Amundsen、Superset 之类的优良开源我的项目有机地联合,造成一整套古代的数据基础设施体系。对具体实际感兴趣的同学能够浏览文末「参考资料中」的数据治理实际。
简略来说,dbt 是一个 Python 写的命令行工具。针对不同的我的项目,咱们能够用 dbt 创立特定格局的我的项目文件夹,它会自带一个 .yaml
配置文件。咱们要在配置文件里指定数据转换的起源信息在哪里,指标在哪里(解决之后的数据存储的中央,可能是 PostgreSQL、BigQuery、Spark 等)。在数据源中,咱们用 yaml 文件和 .sql
文件一起形容了”从哪里取哪些数据,如何做变换,输入什么“的信息。
这个截图就是 dbt 官网文档中的示例我的项目中的文件和配置,能够看到 models/example
里的信息就是最外围的数据转换 transform 的规定,而所有的其余数据都是和这个数据转换相干的元数据,这些 dbt 我的项目文件非常适合用 git 来进行保护,进行古代、自动化的 DataOps。
NebulaGraph 数据导入
通过 dbt 对数据进行解决之后,咱们能够失去间接映射到不同类型的顶点、边、及其属性的表构造的两头数据,它们能够是 CSV 的文件模式,也能够是数仓中的表,甚至可能是 Spark 中的 DataFrame。而将它们导入 NebulaGraph 有不同的抉择,能够选数据导入工具 NebulaGraph Exchange、NebulaGraph Importer、NebulaGraph Spark Connector 的任意一款。
在这里,用最简略的 NebulaGraph Importer 作为例子。
NebulaGraph Importer 是一个用 Golang 写的开源数据工具。它能够编译成一个单文件的二进制,通过预配置的 yaml 格局的文件,读取指定 CSV 文件映射到 NebulaGraph 中点、边关系数据。
实操
当初,咱们来实操下如何利用 dbt + NebulaGraph Importer 进行多数据源聚合、转换,再导入 NebulaGraph 的过程。整个我的项目的代码曾经开源,仓库在 https://github.com/wey-gu/movie-recommendation-dataset 上,欢送大家参考、共建。
整个实操过程如下:
- 将源数据简略荡涤、导入数仓 PostgreSQL(EL)
- 用 dbt 对数据进行转换 Transform、导出为 CSV 文件
- 用 NebulaGraph Importer 将 CSV 导入 NebulaGraph(L)
筹备 dbt 环境
dbt 是一个 Python 我的项目,咱们在一个虚构的 Python 3 环境里装置好 dbt 和 dbt-postgres。
python3 -m venv .venv
source .venv/bin/activate
pip install dbt-postgres
创立一个 dbt 我的项目,并进入到空的我的项目里:
dbt init dbt_project
cd dbt_project
看看里边的文件吧:
$ tree .
.
|-- README.md # 我的项目阐明 README
|-- analyses
|-- dbt_project.yml # 我的项目配置文件
|-- macros
|-- models # transform 起源
| \-- example
| |-- my_first_dbt_model.sql # 一个形容了如何从元数据中 SELECT 并解决的规定
| |-- my_second_dbt_model.sql
| \-- schema.yml # 规定文件的元数据配置,形容了 sql 规定的属性
|-- seeds # 源数据如果是 CSV 文件,能够放到 seeds 里
|-- snapshots
\-- tests
7 directories, 5 files
最初,咱们拉一个容器里的 Postgres 当做咱们这个我的项目的数仓。如果你曾经有各种其余数仓,就不须要这一步了,不过要把我的项目中的配置文件作相应的批改,并装置相应的 dbt 插件。
docker run --rm --name postgres \
-e POSTGRES_PASSWORD=nebula \
-e POSTGRES_USER=nebula \
-e POSTGRES_DB=warehouse -d \
-p 5432:5432 postgres
数据下载与预处理
咱们把数据放到我的项目的 raw_data
下吧。
mkdir -p raw_data
cd raw_data
留神,假如 raw_data
在 dbt_proeject
之下:
tree ..
..
|-- README.md
|-- analyses
|-- dbt_project.yml
|-- macros
|-- models
| \-- example
| |-- my_first_dbt_model.sql
| |-- my_second_dbt_model.sql
| \-- schema.yml
|-- raw_data # 新建的目录
|-- seeds
|-- snapshots
\-- tests
8 directories, 5 files
咱们把 OMDB 数据下载之后,再解压:
wget www.omdb.org/data/all_people.csv.bz2
wget www.omdb.org/data/all_people_aliases.csv.bz2
wget www.omdb.org/data/people_links.csv.bz2
wget www.omdb.org/data/all_casts.csv.bz2
wget www.omdb.org/data/job_names.csv.bz2
wget www.omdb.org/data/all_characters.csv.bz2
wget www.omdb.org/data/movie_categories.csv.bz2
wget www.omdb.org/data/movie_keywords.csv.bz2
wget www.omdb.org/data/category_names.csv.bz2
wget www.omdb.org/data/all_categories.csv.bz2
wget www.omdb.org/data/all_movie_aliases_iso.csv.bz2
bunzip2 *.bz2
而后是 MovieLens 数据集的下载、解压:
wget https://files.grouplens.org/datasets/movielens/ml-latest-small.zip
unzip ml-latest-small.zip
rm *.zip
在导入数仓进行转换 Transform 之前咱们做一些数据的预处理,把它们放到 seeds
之下。
# 因为是试验我的项目,咱们简略粗犷地去掉带有本义的引号的数据,因为它们会被认为是有效字符,解决之后的后果放到 seeds 下边。grep -v '\\"' raw_data/all_movie_aliases_iso.csv > seeds/all_movie_aliases_iso.csv
grep -v '\\"' raw_data/all_casts.csv > seeds/all_casts.csv
grep -v '\\"' raw_data/all_characters.csv > seeds/all_characters.csv
grep -v '\\"' raw_data/all_people.csv > seeds/all_people.csv
grep -v '\\"' raw_data/category_names.csv > seeds/category_names.csv
grep -v '\\"' raw_data/job_names.csv > seeds/job_names.csv
# 下边的文件无需解决,间接放到 seeds 下边。cp raw_data/movie_categories.csv seeds/movie_categories.csv
cp raw_data/movie_keywords.csv seeds/movie_keywords.csv
cp raw_data/all_categories.csv seeds/all_categories.csv
cp raw_data/ml-latest-small/ratings.csv seeds/movielens_ratings.csv
cp raw_data/ml-latest-small/movies.csv seeds/movielens_movies.csv
有了 seeds 下边的文件之后,能够用一个命令把他们导入到数仓里:
dbt seed
执行过程因数仓而异,用本地的 Postgres 可能要等一会儿能力实现,执行后果大略是这样的:
$ dbt seed
05:58:27 Running with dbt=1.3.0
05:58:27 Found 2 models, 4 tests, 0 snapshots, 0 analyses, 289 macros, 0 operations, 11 seed files, 0 sources, 0 exposures, 0 metrics
05:58:28
05:58:28 Concurrency: 8 threads (target='dev')
05:58:28
05:58:28 1 of 11 START seed file public.all_casts ....................................... [RUN]
...
07:10:11 1 of 11 OK loaded seed file public.all_casts ................................... [INSERT 1082228 in 4303.78s]
07:10:11
07:10:11 Finished running 11 seeds in 1 hours 11 minutes and 43.93 seconds (4303.93s).
07:10:11
07:10:11 Completed successfully
07:10:11
07:10:11 Done. PASS=11 WARN=0 ERROR=0 SKIP=0 TOTAL=11
撰写 Transform model
咱们创立 model 如下:
mkdir models/movie_recommedation
touch models/movie_recommedation/user_watched_movies.sql
touch models/movie_recommedation/schema.yml
这时候 models 中的文件构造大略是这样的:
$ tree models
models
\-- movie_recommedation
|-- user_watched_movies.sql
\-- schema.yml
这个 model 下边目前只有一个规定,就是负责解决用户观看电影这条边上数据的 SQL 语句。
咱们心愿输入三列,所以 schema.yml
中的内容是:
version: 2
models:
- name: user_watched_movies
description: "The edges between users and movies they have watched"
columns:
- name: user_id
description: "user id"
tests:
- not_null
- name: movie_id
description: "movie id"
tests:
- not_null
- name: rating
description: "rating given by user to movie"
tests:
- not_null
留神,这里的 tests
的表白是对数据验证、测试的束缚。有了它,我能够用 dbt 轻松地对数据品质进行测试、验收,比方:咱们要求这里的三个字段都是 not_null
。
而后,咱们来写 SQL 吧,user_watched_movies.sql
:
{{config(materialized='table') }}
/*
JOIN the movieielens_ratings table with the movieielens_movies table, and removing the movie title tailing the year of release
*/
WITH user_watched_movies AS(
SELECT moveielens_ratings."userId",
moveielens_ratings."movieId",
moveielens_ratings.rating,
REGEXP_REPLACE(moveielens_movies.title, '\(\d{4}\)$', '') AS title,
moveielens_movies.genres AS movielens_genres
FROM moveielens_ratings
JOIN moveielens_movies ON moveielens_movies."movieId" = moveielens_ratings."movieId"
)
/*
JOIN user_watched_movies table with all_movie_aliase_iso table where language is English
the join condition is the movie title
*/
SELECT concat('u_',user_watched_movies."userId") AS user_id,
user_watched_movies.rating,
user_watched_movies.title,
all_movie_aliases_iso."movie_id" AS OMDB_movie_id,
user_watched_movies.movielens_genres
FROM user_watched_movies
JOIN all_movie_aliases_iso ON user_watched_movies.title LIKE CONCAT(all_movie_aliases_iso.name, '%')
AND all_movie_aliases_iso.language_iso_639_1 = 'en'
而这个 SQL 做的事件就是绿色圆圈标注的局部:
-
从
movielens_ratings
当选 user id、movie id、rating、movie title(去掉年份),存成user_watched_movies
的两头表格- movie title 从
movielens_movies
中JOIN
,通过movie_id
雷同的匹配条件获得
- movie title 从
-
从
user_watched_movies
当选 user id(减少前缀u_
)、rating、title、OMDB_movie_id- OMDB_movie_id 从
all_movie_aliases_iso
中JOIN
,通过类似的电影姓名匹配 OMDB 电影中英文题目获得 - 最终的字段作为输入
- OMDB_movie_id 从
当然,咱们能够在 Postgres 的连接器中通过减少 LIMIT 疾速调试本人的 SQL 语句。
当初咱们来通过 dbt 执行、测试刚刚的规定:
dbt run -m user_watched_movies
之后,咱们应该就能够在 Postgres(数仓)中看到咱们转换之后的一个表了。
相似的,如法炮制所有其余局部的 Transform 规定,咱们就取得了这么多 model 了:
$ tree models
models
\-- movie_recommedation
|-- acted_by.sql
|-- directed_by.sql
|-- genres.sql
|-- movies.sql
|-- people.sql
|-- schema.yml
|-- user_watched_movies.sql
\-- with_genre.sql
再对他们别离执行 transform:
dbt run -m acted_by
dbt run -m directed_by
dbt run -m with_genre
dbt run -m people
dbt run -m genres
dbt run -m movies
导出数据为 CSV
实际上,NebulaGraph Exchange 自身就反对把很多数据源(Postgres,ClickHouse,MySQL,Hive 等等)导入 NebulaGraph。只是在这个例子中,咱们解决的数据量对于 NebulaGraph 来说十分十分小(只有百万级别的边而已),所以应用最轻量级的 NebulaGraph Importer 就足够了。而 NebulaGraph Importer 能生产的数据只有 CSV 文件,所以咱们把方才的表都输入为文件。
首先,咱们进入 Postgres 的 Console,执行 COPY
命令
COPY acted_by TO '/tmp/acted_by.csv' WITH DELIMITER ',' CSV HEADER;
COPY directed_by TO '/tmp/directed_by.csv' WITH DELIMITER ',' CSV HEADER;
COPY with_genre TO '/tmp/with_genre.csv' WITH DELIMITER ',' CSV HEADER;
COPY people TO '/tmp/people.csv' WITH DELIMITER ',' CSV HEADER;
COPY movies TO '/tmp/movies.csv' WITH DELIMITER ',' CSV HEADER;
COPY genres TO '/tmp/genres.csv' WITH DELIMITER ',' CSV HEADER;
-- 对于 user_watched_movies 咱们不输出表头,因为这个文件中记录了两种点、一种边,没法让 importer 通过约定好的表头主动导入,只能通过无表头的状况下指定第几列对应什么字段
COPY user_watched_movies TO '/tmp/user_watched_movies.csv' WITH DELIMITER ',' CSV;
再把 Postgres 容器里的文件导入到 to_nebulagraph
这个文件夹里:
mkdir -p to_nebulagraph
docker cp postgres:/tmp/. to_nebulagraph/
导入 NebulaGraph
创立 NebulaGraph 集群
咱们能够用 Nebula Up 一键拉起一个测试的 NebulaGraph 单机集群,导入所需数据:
curl -fsSL nebula-up.siwei.io/install.sh | bash
创立 Schema
首先,咱们创立一个叫做 moviegraph
的图空间。针对后面的建模,创立点边类型的构造 Schema:
先进入 NebulaGraph 的 Console:
~/.nebula-up/console.sh
再执行如下 DDL(Data Definiation Language):
CREATE SPACE moviegraph(partition_num=10,replica_factor=1,vid_type=fixed_string(32));
:sleep 20
USE moviegraph;
CREATE TAG person(name string, birthdate string);
CREATE TAG movie(name string);
CREATE TAG genre(name string);
CREATE TAG user(user_id string);
CREATE EDGE acted_by();
CREATE EDGE directed_by();
CREATE EDGE with_genre();
CREATE EDGE watched(rate float);
exit
创立 NebulaGraph Importer 配置文件
这个文件是一个形容 CSV 文件和集群中点边数据对应关系的 YAML 文件。具体的格局能够参考文档:https://docs.nebula-graph.com.cn/master/nebula-importer/use-importer/,或者视频教程:https://www.bilibili.com/video/BV1ny4y1u7i4。
最终的配置文件我曾经为大家写好了,在 https://github.com/wey-gu/movie-recommendation-dataset/blob/main/nebula-importer.yaml 能够下载失去。
这里,咱们就间接下载我写好了的配置文件。留神,这个文件不应该是 dbt 我的项目文件的一部分,所以咱们退出目录,向上一层,把它放到 dbt_proeject
外边:
cd ..
wget https://raw.githubusercontent.com/wey-gu/movie-recommendation-dataset/main/nebula-importer.yaml
开始导入
这一步,咱们用容器化的 NebulaGraph Importer,防止了装置的步骤:
docker run --rm -ti \
--network=nebula-net \
-v ${PWD}:/root/ \
-v ${PWD}/dbt_project/to_nebulagraph/:/data \
vesoft/nebula-importer:v3.2.0 \
--config /root/nebula-importer.yaml
很快,所有的数据就导入到 NebulaGraph 之中了。当初,咱们能够通过 NebulaGraph Console,执行一些查问看看后果:
进入 Console:
~/.nebula-up/console.sh
进入图空间、执行 SHOW STATS
:
USE moviegraph;
SHOW STATS;
后果:
(root@nebula) [moviegraph]> SHOW STATS;
+---------+---------------+---------+
| Type | Name | Count |
+---------+---------------+---------+
| "Tag" | "genre" | 14397 |
| "Tag" | "movie" | 20701 |
| "Tag" | "person" | 263907 |
| "Tag" | "user" | 610 |
| "Edge" | "acted_by" | 673763 |
| "Edge" | "directed_by" | 101949 |
| "Edge" | "watched" | 31781 |
| "Edge" | "with_genre" | 194009 |
| "Space" | "vertices" | 299615 |
| "Space" | "edges" | 1001502 |
+---------+---------------+---------+
Got 10 rows (time spent 1693/15136 us)
通过 NebulaGraph Studio,咱们也能够在可视化界面摸索这个图谱。比方:在其中执行这个查问,看一下给用户 u_124
举荐电影 1891
的理由可能是什么?
FIND NOLOOP PATH FROM "u_124" TO "1891" over * BIDIRECT UPTO 4 STEPS yield path as `p` | LIMIT 20
它的后果是:已经喜爱的星战电影的大部分演职人员都也参加了这部同样是“奥斯卡获奖”且“经典”的电影。
总结
当咱们打算把海量数据利用图数据库的能力进行常识转化、洞察剖析的时候,往往第一步就是要做多数据源到图数据的转换、解决、建模。对于无从下手的老手们来说,一个可行的思路是从所有的相干信息登程,去构想最关注的关联关系,把边写进去,而后再列举能够获得的点、以及须要的点、边上的属性。确定了初始的建模之后,就能够利用 ETL 工具把原始的数据荡涤、ETL 成点、边类型的表构造,最初,利用导入工具导入 NebulaGraph。
借助于 dbt,咱们能够版本控制、测试、迭代建模与数据转换,一点点进化、丰盛构建的常识图谱。
参考资料
- 数据血统治理:https://discuss.nebula-graph.com.cn/t/topic/11729
- dbt 上手文档:https://docs.getdbt.com/docs/get-started/getting-started-dbt-core
- 如何抉择 NebulaGraph 数据导入工具:www.siwei.io/sketches/nebula-data-import-options
- Postgres 文档:https://www.postgresql.org/docs/current/sql-copy.html
- 基于图数据库的举荐零碎:https://discuss.nebula-graph.com.cn/t/topic/11491
谢谢你读完本文 (///▽///)
要来近距离疾速体验一把图数据库吗?当初能够用用 NebulaGraph Cloud 来搭建本人的图数据系统哟,快来节俭大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天收费应用中,点击链接来用用图数据库吧~
想看源码的小伙伴能够返回 GitHub 浏览、应用、(^з^)-☆ star 它 -> GitHub;和其余的 NebulaGraph 用户一起交换图数据库技术和利用技能,留下「你的名片」一起游玩呢~