自從開發完 NebulaGraph Exchange，混跡在各個 NebulaGraph 微信群的我經常會看到一類提問是：NebulaGraph Exchange 的效能如何？哪些引數調整下可以有更好的效能？…索性來一篇文章從實測出發，和大家講講如何用好這個資料工具。在本文你將獲得 NebulaGraph Exchange 的最佳使用姿勢。
01. 環境準備
硬體：
- Spark 叢集：三臺機器，每臺 96 core，256 G 記憶體
- NebulaGraph 叢集：三臺機器，每臺 128 core，252 G 記憶體，SSD，雙萬兆網路卡
- 資料：LDBC sf100 資料
軟體：
- Spark 版本：2.4.4
- NebulaGraph 版本：3.3.0
02. NebulaGraph 最佳化配置
在進行大批次資料匯入時，可以調整 NebulaGraph Storage 服務和 Graph 服務的配置，以達到最大匯入效能。請根據 NebulaGraph 的配置描述和你的實際環境資源進行引數調整。
在本次實踐中，NebulaGraph 的叢集配置針對以下幾個配置項進行了修改，其他均採用預設配置：
"storaged":
--rocksdb_block_cache=81920,
--heartbeat_interval_secs=10,
--reader_handlers=64,
--num_worker_threads=64,
--rocksdb_db_options={"max_subcompactions":"64","max_background_jobs":"64"}
"graphd":
--storage_client_timeout_ms=360000,
--session_idle_timeout_secs=2880,
--max_sessions_per_ip_per_user=500000,
--num_worker_threads=64NebulaGraph Storage 服務最佳化
在這裡簡單講一下幾個 Storage 服務最佳化配置項：
--rocksdb_block_cache資料在記憶體快取大小，預設是 4 MB，大批次資料匯入時可以設定到當前記憶體的 1/3；--num_worker_threadsstoraged 的 RPC 服務的工作執行緒數量，預設 32；--query_concurrently為true表示 storaged 會併發地讀取資料，false表示 storaged 是單執行緒取數；--rocksdb_db_options={"max_subcompactions":"48","max_background_jobs":"48"}：可用來加速自動 Compaction 過程；--rocksdb_column_family_options={"write_buffer_size":"67108864","max_write_buffer_number":"5"}，在剛開始匯入大量資料時可以將disable_auto_compaction選項設定為true，提升寫入的效能；--wal_ttl=600在大量資料匯入時，若磁碟不充裕，那麼該引數需調小，不然可能會因為產生大量的 wal 導致磁碟空間被撐滿。
NebulaGraph Graph 服務最佳化
再簡單地羅列下 Graph 服務相關的一些最佳化配置項：
--storage_client_timeout_ms為 graphd 與 storaged 通訊的超時時間；--max_sessions_per_ip_per_user是單使用者單 IP 客戶端允許建立的最大 session 數；--system_memory_high_watermark_ratio設定記憶體使用量超過多少時停止計算，表示資源的佔用率，一般設定為 0.8～1.0 之間；--num_worker_threads為 graphd 的 RPC 服務的工作執行緒數量，預設 32。
03. NebulaGraph DDL
下面，我們透過這些語句來建立下 Schema 方便後續匯入資料：
CREATE SPACE sf100(vid_type=int64,partition_num=100,replica_factor=3);
USE sf100;
CREATE TAG IF NOT EXISTS `Place`(`name` string,`url` string,`type` string);
CREATE TAG IF NOT EXISTS `Comment`(`creationDate` string,`locationIP` string,`browserUsed` string,`content` string,`length` int);
CREATE TAG IF NOT EXISTS `Organisation`(`type` string,`name` string,`url` string);
CREATE TAG IF NOT EXISTS `Person`(`firstName` string,`lastName` string,`gender` string,`birthday` string,`creationDate` string,`locationIP` string,`browserUsed` string);
CREATE TAG IF NOT EXISTS `Tagclass`(`name` string,`url` string);
CREATE TAG IF NOT EXISTS `Forum`(`title` string,`creationDate` string);
CREATE TAG IF NOT EXISTS `Post`(`imageFile` string,`creationDate` string,`locationIP` string,`browserUsed` string,`language` string,`content` string,`length` int);
CREATE TAG IF NOT EXISTS `Tag`(`name` string,`url` string);
CREATE EDGE IF NOT EXISTS `IS_PART_OF`();
CREATE EDGE IF NOT EXISTS `LIKES`(`creationDate` string);
CREATE EDGE IF NOT EXISTS `HAS_CREATOR`();
CREATE EDGE IF NOT EXISTS `HAS_INTEREST`();
CREATE EDGE IF NOT EXISTS `IS_SUBCLASS_OF`();
CREATE EDGE IF NOT EXISTS `IS_LOCATED_IN`();
CREATE EDGE IF NOT EXISTS `HAS_MODERATOR`();
CREATE EDGE IF NOT EXISTS `HAS_TAG`();
CREATE EDGE IF NOT EXISTS `WORK_AT`(`workFrom` int);
CREATE EDGE IF NOT EXISTS `REPLY_OF`();
CREATE EDGE IF NOT EXISTS `STUDY_AT`(`classYear` int);
CREATE EDGE IF NOT EXISTS `CONTAINER_OF`();
CREATE EDGE IF NOT EXISTS `HAS_MEMBER`(`joinDate` string);
CREATE EDGE IF NOT EXISTS `KNOWS`(`creationDate` string);
CREATE EDGE IF NOT EXISTS `HAS_TYPE`();04. LDBC sf100 資料集的資料量
該表展示了各類點邊的資料量
| Label | Amount |
|---|---|
| Comment | 220,096,052 |
| Forum | 4,080,604 |
| Organisation | 7,955 |
| Person | 448,626 |
| Place | 1,460 |
| Post | 57,987,023 |
| Tag | 16,080 |
| Tagclass | 71 |
| CONTAINER_OF | 57,987,023 |
| HAS_CREATOR | 278,083,075 |
| HAS_INTEREST | 10,471,962 |
| HAS_MEMBER | 179,874,360 |
| HAS_MODERATOR | 4,080,604 |
| HAS_TAG | 383,613,078 |
| HAS_TYPE | 16,080 |
| IS_LOCATED_IN | 278,539,656 |
| IS_PART_OF | 1,454 |
| IS_SUBCLASS_OF | 70 |
| KNOWS | 19,941,198 |
| LIKES | 341,473,012 |
| REPLY_OF | 2,200,960,52 |
| STUDY_AT | 359,212 |
| WORK_AT | 976,349 |
05. NebulaGraph Exchange 配置
重點來了，看好這個配置，如果下次還有小夥伴配置配錯了導致資料匯入報錯的話，我可是要丟這篇文章的連結了。app.conf 如下：
{
# Spark 相關配置
spark: {
app: {
name: Nebula Exchange
}
}
# NebulaGraph 相關配置
nebula: {
address:{
graph:["192.168.xx.8:9669","192.168.xx.9:9669","192.168.xx.10:9669"] //因為實驗環境是叢集，這裡配置了 3 臺機器的 graphd 地址
meta:["192.168.xx.8:9559"] //無需配置多臺機器的 meta 地址，隨機配一個就行
}
user: root
pswd: nebula
space: sf100 // 之前 Schema 建立的圖空間名
# NebulaGraph 客戶端連線引數設定
connection {
timeout: 30000 //超過 30000ms 無響應會報錯
}
error: {
max: 32
output: /tmp/errors
}
# 使用 Google 的 RateLimiter 限制傳送到 NebulaGraph 的請求
rate: {
limit: 1024
timeout: 1000
}
}
# 這裡開始處理點資料，進行之前的 Schema 和資料對映
tags: [
{
name: Person // tagName 為 Person
type: {
source: csv //指定資料來源型別
sink: client //指定如何將點資料匯入 NebulaGraph，client 或 sst
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person.csv" // 資料檔案的所在路徑，如果檔案儲存在 HDFS 上，用雙引號括起路徑，以 hdfs:// 開頭，例如 "hdfs://ip:port/xx/xx"。如果檔案儲存在本地，用雙引號括起路徑，以 file:// 開頭，例如 "file:///tmp/xx.csv"。
fields: [_c1,_c2,_c3,_c4,_c5,_c6,_c7] // 無表頭，_cn 表示表頭
nebula.fields: [firstName,lastName,gender,birthday,creationDate,locationIP,browserUsed] // tag 的屬性對映，_c1 對應 firstName
vertex: _c0 // 指定 vid 的列
batch: 2000 // 單次請求寫入多少點資料
partition: 180 // Spark partition 數
separator: | // 屬性分隔符
header: false // 無表頭設定，false 表示無表頭
}
{
name: Place
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/place.csv"
fields: [_c1,_c2,_c3]
nebula.fields: [name, type, url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
{
name: Organisation
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/organisation.csv"
fields: [_c1,_c2,_c3]
nebula.fields: [name, type,url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
{
name: Post
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post.csv"
fields: [_c1,_c2,_c3,_c4,_c5,_c6,_c7]
nebula.fields: [imageFile,creationDate,locationIP,browserUsed,language,content,length]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
{
name: Comment
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment.csv"
fields: [_c1,_c2,_c3,_c4,_c5]
nebula.fields: [creationDate,locationIP,browserUsed,content,length]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
{
name: Forum
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum.csv"
fields: [_c1,_c2]
nebula.fields: [creationDate,title]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
{
name: Tag
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tag.csv"
fields: [_c1,_c2]
nebula.fields: [name,url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
{
name: Tagclass
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tagclass.csv"
fields: [_c1,_c2]
nebula.fields: [name,url]
vertex: _c0
batch: 2000
partition: 180
separator: |
header: false
}
]
# 開始處理邊資料
edges: [
{
name: KNOWS //邊型別
type: {
source: csv //檔案型別
sink: client //同上 tag 的 sink 說明
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_knows_person.csv" //同上 tag 的 path 說明
fields: [_c2] //無表頭的，設定 _c2 為表頭
nebula.fields: [creationDate] // 屬性值和表頭對映，這裡為 KNOW 型別邊中的 creationDate 屬性
source: {
field: _c0 // 源資料中作為 KNOW 型別邊起點的列
}
target: {
field: _c1 // 源資料中作為 KNOW 型別邊終點的列
}
batch: 2000 // 單批次寫入的最大邊資料
partition: 180 //同上 tag 的 partition 說明
separator: | //同上 tag 的 separator 說明
header: false // 同上 tag 的 header 說明
}
{
name: LIKES
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_likes_comment.csv"
fields: [_c2]
nebula.fields: [creationDate]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: LIKES
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_likes_post.csv"
fields: [_c2]
nebula.fields: [creationDate]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_TAG
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_hasTag_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_TAG
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_hasTag_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_TAG
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post_hasTag_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_TYPE
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tag_hasType_tagclass.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_MODERATOR
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_hasModerator_person.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_MEMBER
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_hasMember_person.csv"
fields: [_c2]
nebula.fields: [joinDate]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_INTEREST
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_hasInterest_tag.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_CREATOR
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post_hasCreator_person.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: HAS_CREATOR
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_hasCreator_person.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: IS_PART_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/place_isPartOf_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: CONTAINER_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/forum_containerOf_post.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/post_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: IS_LOCATED_IN
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/organisation_isLocatedIn_place.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: REPLY_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_replyOf_comment.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: REPLY_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/comment_replyOf_post.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: STUDY_AT
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_studyAt_organisation.csv"
fields: [_c2]
nebula.fields: [classYear]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: WORK_AT
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/dynamic/person_workAt_organisation.csv"
fields: [_c2]
nebula.fields: [workFrom]
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
{
name: IS_SUBCLASS_OF
type: {
source: csv
sink: client
}
path: "hdfs://192.168.xx.2:9000/ldbc/sf100/social_network/static/tagclass_isSubclassOf_tagclass.csv"
fields: []
nebula.fields: []
source: {
field: _c0
}
target: {
field: _c1
}
batch: 2000
partition: 180
separator: |
header: false
}
]
}在上面的第一次配置 tag 和 edge 的時候，我增加了一些欄位說明，具體的大家可以翻閱下 NebulaGraph Exchange 的文件來獲得更詳細的說明：https://docs.nebula-graph.com.cn/3.3.0/nebula-exchange/use-exchange/ex-ug-import-from-csv/
06. Spark 提交引數配置
Spark 叢集有三個節點，每個節點配置為 96 core， 256 G 記憶體。
配置的 Spark 提交命令如下：
spark-submit --master "spark://127.0.0.1:7077" \
--driver-memory=2G \
--executor-memory=30G \
--total-executor-cores=120 \
--executor-cores=10 \
--num-executors=3 \ // 對 standalone 模式無效
--class com.vesoft.nebula.exchange.Exchange \
nebula-exchange_spark_2.4-3.3.0.jar -c app.conf07. 測試結果
在測試中，我們修改了 NebulaGraph Exchange 配置檔案中的 batch 數、partition 數和 spark-submit 提交命令中的 total-executor-cores 數來調整匯入的併發度，匯入結果如下：
| Dataset | Data Amount | NebulaGraph storaged.conf: max_subcompactions | NebulaGraph storaged.conf: disable_auto_compaction | Spark: total-executor-cores | Spark:executor-cores | Spark:executor-memory | Exchange conf : batch | Exchange conf: partition | duration |
|---|---|---|---|---|---|---|---|---|---|
| LDBC sf100 | vertex:282,386,021，edge:1,775,513,185 | 4 | FALSE | 120 | 10 | 30 G | 2,000 | 360 | 1.9 h |
| LDBC sf100 | vertex:282,386,021，edge:1,775,513,185 | 64 | FALSE | 120 | 10 | 30 G | 2,000 | 360 | 1.0 h |
| LDBC sf100 | vertex:282,386,021，edge:1,775,513,185 | 64 | FALSE | 180 | 10 | 30 G | 2,000 | 360 | 1.1 h |
| LDBC sf100 | vertex:282,386,021，edge:1,775,513,185 | 64 | FALSE | 180 | 10 | 30 G | 3,000 | 360 | 1.0 h |
| LDBC sf100 | vertex:282,386,021，edge:1,775,513,185 | 64 | FALSE | 90 | 10 | 30 G | 2,000 | 180 | 1.1 h |
當 max_subcompaction 為 64 時，NebulaGraph 機器的磁碟和網路 io 使用情況（時間 15：00 之後的部分）如下：
在進行匯入時，storaged 服務的 max_subcompaction 配置對匯入效能有很大影響。當 NebulaGraph 機器的 io 達到極限時，應用層的配置引數對匯入效能影響甚微。
08. 關鍵效能欄位
這裡，再單獨拉出來關鍵欄位來講下，大家可以根據自身的資料量、機器配置來調整相關引數。
NebulaGraph Exchange 的 app.conf
這裡需要重點關注前面兩個欄位，當然後面的欄位也不是不重要：
partition，根據 Spark 叢集的機器核數決定 partition 配置項的值。partition 的值是 spark-submit 命令中配置的總核數的 2-3 倍，其中：總核數 = num-executors * executor-cores。batch，client 向 graphd 傳送的一個請求中有多少條資料。在該實踐中採用的 LDBC 資料集的 tag 屬性不超過 10 個，設定的 batch 數為 2,000。如果 tag 或 edgeType 屬性多且位元組數多，batch 可以調小，反之，則調大。nebula.connection.timeout，NebulaGraph 客戶端與服務端連線和請求的超時時間。若網路環境較差，資料匯入過程出現 "connection timed out"，可適當調大該引數。（read timed out 與該配置無關）nebula.error.max，允許發生的最大失敗次數。當客戶端向服務端傳送請求的失敗數超過該值，則 NebulaGraph Exchange 退出。nebula.error.output，匯入失敗的資料會被存入該目錄。nebula.rate.limit，採用令牌桶限制 NebulaGraph Exchange 向 NebulaGraph 傳送請求的速度，limit 值為每秒向令牌桶中建立的令牌數。nebula.rate.timeout，當速度受阻無法獲取令牌時，允許最大等待的時間，超過該時間獲取不到令牌則 NebulaGraph Exchange 退出。單位：ms。
Spark 的 spark-submit
這裡主要講下 spark-submit 命令關鍵性使用指引，詳細內容可參考 Spark 文件：https://spark.apache.org/docs/latest/spark-standalone.html
spark-submit 有多種提交方式，這裡以 standalone 和 yarn 兩種為例：
- standalone 模式：
spark://master_ip:port - yarn 模式：由於 yarn cluster 模式下會隨機選擇一臺機器作為 driver 進行 job 提交。如果作為 driver 的那個機器中沒有 NebulaGraph Exchange 的 jar 包和配置檔案，會出現 "ClassNotFound" 的異常，參考論壇帖子：https://discuss.nebula-graph.com.cn/t/topic/9766。所以，yarn 模式下需要在 spark-submit 命令中配置以下引數：
--files app.conf \
--conf spark.driver.extraClassPath=./ \ // 指定 NebulaGraph Exchange jar 包和配置檔案所在的目錄
--conf spark.executor.extraClassPath=./ \ // 指定 NebulaGraph Exchange jar 包和配置檔案所在的目錄除了提交模式之外，spark-submit 還有一些引數需要關注下：
--driver-memory，給 spark driver 節點分配的記憶體。client 模式（還有 sst 模式）匯入時，該值可採用預設值不進行配置，因為沒有 reduce 操作需要用到 driver 記憶體。--executor-memory，根據源資料的 size M 和 partition 數 p 進行配置，可配置成 2*（ M/p）。--total-executor-cores，standalone 模式下 Spark 應用程式可用的總 cores，可根據 Spark 叢集的總 cores 來配。--executor-cores，每個 executor 分配的核數。在每個 executor 內部，多個 core 意味著多執行緒共享 executor 的記憶體。可以設定為 5-10，根據叢集節點核數自行調節。--num-executors，yarn 模式下申請的 executor 的數量，根據叢集節點數來配置。可以設定為((節點核數-其他程式預留核數)/executor-cores)*叢集節點數，根據節點資源自行調節。比如，一個 Spark 叢集有三臺節點，每節點有 64 核，executor-cores 設定為 10，節點中為其他程式預留 14 核，則 num-executors 可設定為 15，由公式推斷而出((64-14)/10)*3 = 15。
其他調優
在該實踐中，NebulaGraph 除第二步驟提到的最佳化配置，其他配置均採用系統預設配置，NebulaGraph Exchange 的匯入併發度最小為 90，batch 為 2,000。當提高應用程式的併發度時或 batch 數時，匯入效能無法再提升。因此可以在最佳化 NebulaGraph storaged 配置的基礎上，適當調整併發度和 batch 數，在自己環境中得到兩者的平衡，使匯入過程達到一個最佳效能。
關於 Spark 的 total-executor-cores、executor-cores、num-executors 和配置檔案中的 partition 的關係：
- 在 standalone 模式下，啟動多少個 executor 是由
--total-executor-cores和--executor-cores兩個引數來決定的，如果設定的--total-executor-cores是 10，--executor-cores是 5，則一共會啟動兩個 executor。此時給應用程式分配的總核數是total-executor-cores的值。 - 在 yarn 模式下，啟動多少個 executor 是由
num-executors來決定的，此時給應用程式分配的總核數是executor-cores * num-executors的值。 - 在 Spark 中可執行任務的 worker 一共是分配給應用程式的總 cores 數個，應用程式中的任務數有 partition 數個。如果任務數偏少，會導致前面設定的 executor 及 core 的引數無效，比如 partition 只有 1，那麼 90% 的 executor 程式可能就一直在空閒著沒有任務可執行。Spark 官網給出的建議是 partition 可設定為分配的總 cores 的 2-3 倍，如 executor 的總 CPU core 數量為 100，那麼建議設定 partition 為 200 或 300。
0. 如何選擇資料匯入工具
想必透過上面的內容大家對 NebulaGraph Exchange 的資料匯入效能有了一定的瞭解，下圖為 NebulaGraph 資料匯入工具的分佈圖：
感興趣的小夥伴可以閱讀文件 https://docs.nebula-graph.com.cn/3.3.0/20.appendix/write-tools/ 瞭解具體的選擇事項。
謝謝你讀完本文 (///▽///)
要來近距離快速體驗一把圖資料庫嗎？現在可以用用 NebulaGraph Cloud 來搭建自己的圖資料系統喲，快來節省大量的部署安裝時間來搞定業務吧~ NebulaGraph 阿里雲端計算巢現 30 天免費使用中，點選連結來用用圖資料庫吧~
想看原始碼的小夥伴可以前往 GitHub 閱讀、使用、(^з^)-☆ star 它 -> GitHub；和其他的 NebulaGraph 使用者一起交流圖資料庫技術和應用技能，留下「你的名片」一起玩耍呢~