從實測出發，掌握 NebulaGraph Exchange 性能最大化的祕密
自從開發完 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=64
NebulaGraph 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 的文檔來獲得更詳細的説明：http://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.conf
07. 測試結果
在測試中，我們修改了 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 文檔：http://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" 的異常，參考論壇帖子：http://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 數據導入工具的分佈圖：
感興趣的小夥伴可以閲讀文檔 http://docs.nebula-graph.com.cn/3.3.0/20.appendix/write-tools/ 瞭解具體的選擇事項。
謝謝你讀完本文 (///▽///)
要來近距離快速體驗一把圖數據庫嗎？現在可以用用 NebulaGraph Cloud 來搭建自己的圖數據系統喲，快來節省大量的部署安裝時間來搞定業務吧~ NebulaGraph 阿里雲計算巢現 30 天免費使用中，點擊鏈接來用用圖數據庫吧~
想看源碼的小夥伴可以前往 GitHub 閲讀、使用、(^з^)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用户一起交流圖數據庫技術和應用技能，留下「你的名片」一起玩耍呢~
「其他文章」
- 圖數據庫在中國移動金融風控的落地應用
- 記一次 rr 和硬件斷點解決內存踩踏問題
- 用圖技術搞定附近好友、時空交集等 7 個典型社交網絡應用
- 用圖技術搞定附近好友、時空交集等 7 個典型社交網絡應用
- 圖數據庫中的“分佈式”和“數據切分”（切圖）
- 揭祕可視化圖探索工具 NebulaGraph Explore 是如何實現圖計算的
- 連接微信羣、Slack 和 GitHub：社區開放溝通的基礎設施搭建
- 圖數據庫認證考試 NGCP 錯題解析 vol.02：這 10 道題竟無一人全部答對
- 如何判斷多賬號是同一個人？用圖技術搞定 ID Mapping
- 複雜場景下圖數據庫的 OLTP 與 OLAP 融合實踐
- 如何運維多集羣數據庫？58 同城 NebulaGraph Database 運維實踐
- 有了 ETL 數據神器 dbt，表數據秒變 NebulaGraph 中的圖數據
- 基於圖的下一代入侵檢測系統
- 從實測出發，掌握 NebulaGraph Exchange 性能最大化的祕密
- 讀 NebulaGraph源碼 ｜ 查詢語句 LOOKUP 的一生
- 當雲原生網關遇上圖數據庫，NebulaGraph 的 APISIX 最佳實踐
- 從全球頂級數據庫大會 SIGMOD 看數據庫發展趨勢
- 「實操」結合圖數據庫、圖算法、機器學習、GNN 實現一個推薦系統
- 如何輕鬆做數據治理？開源技術棧告訴你答案
- 圖算法、圖數據庫在風控場景的應用