使用 ByConity 作为存储引擎
创建时间：2024-09-23 最近修改时间：2024-12-30
#1. 简介
ByConity (opens new window) 是字节跳动基于 ClickHouse（最新同步自 ClickHouse v23.3）Fork 的项目，支持存算分离。
自 6.6 版本起，DeepFlow 支持通过调整部署参数决定使用 ClickHouse 还是 ByConity，默认使用 ClickHouse，可调整为使用 ByConity。
提示
ByConity 共有 17 个 Pod，其中 9 个 Pod 的 Request 和 Limit 为 1.1C 1280M，1 个 Pod 的 Request 和 Limit 为 1C 1G，1 个 Pod 的 Request 和 Limit 为 1C 512M。组件 byconity-server、vw-default 和 vw-writer 的本地 Disk Cache 可通过 lru_max_size 配置修改，日志数据存储上限可通过 size、count 配置修改。
资源需求：
- CPU: 建议 Kubernetes 集群至少剩余 12C 可分配资源，实际会消耗更高的资源。
- 内存: 建议 Kubernetes 集群至少剩余 14G 可分配资源，实际会消耗更高的资源。
- 磁盘: 建议每个数据节点磁盘容量超过 180G，其中本地 Disk Cache
byconity-server、vw-default和vw-writer各 40G，日志数据byconity-server、vw-default和vw-writer各 20G。
#1.1 部署参数
ByConity 默认对接对象存储，修改 values-custom.yaml，注意将 endpoint，region，bucket，path，ak_id，ak_secret 修改为对象存储的正确参数。建议将 byconity-server、vw-default 和 vw-writer 副本数量调整至与 deepflow-server 或节点数量相同，在修改 vw-default 和 vw-writer 参数之前，请先将以下 defaultWorker、virtualWarehouses 内容拷贝到 values-custom.yaml 文件中，并在此基础上进行相应修改：
global:
storageEngine: byconity
clickhouse:
enabled: false
byconity:
enabled: true
byconity:
configOverwrite:
storage_configuration:
disks:
server_s3_disk_0:
endpoint: https://oss-cn-beijing-internal.aliyuncs.com
region: cn-beijing
bucket: FIX_ME_BUCKET
path: byconity0
ak_id: FIX_ME_ACCESS_KEY
ak_secret: FIX_ME_ACCESS_SECRET
server:
replicas: 1 # Number of replicas of pod byconity-server
storage:
localDisk:
pvcSpec:
storageClassName: openebs-hostpath #replace to your storageClassName
log:
pvcSpec:
storageClassName: openebs-hostpath #replace to your storageClassName
configOverwrite:
logger:
level: trace
size: 2000M # Log file size limit
count: 10 # Limitation of the number of log files
disk_cache_strategies:
simple:
lru_max_size: 42949672960 # 40Gi # disk Maximum cache space 40 X 1024 X 1024 X 1024
tso:
storage:
localDisk:
pvcSpec:
storageClassName: openebs-hostpath #replace to your storageClassName
log:
pvcSpec:
storageClassName: openebs-hostpath #replace to your storageClassName
defaultWorker: &defaultWorker
hostNetwork: false
livenessProbe:
exec:
command: [ "/opt/byconity/scripts/lifecycle/liveness" ]
failureThreshold: 6
initialDelaySeconds: 5
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 20
readinessProbe:
exec:
command: [ "/opt/byconity/scripts/lifecycle/readiness" ]
failureThreshold: 5
initialDelaySeconds: 10
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 10
storage:
localDisk:
pvcSpec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi
storageClassName: openebs-hostpath #replace to your storageClassName
log:
pvcSpec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
storageClassName: openebs-hostpath #replace to your storageClassName
configOverwrite:
logger:
level: trace
size: 2000M # Log file size limit
count: 10 # Limitation of the number of log files
disk_cache_strategies:
simple:
lru_max_object_num: 4000000 # Limit the total number of files
lru_max_size: 42949672960 # 40Gi
# timezone: Etc/UTC
virtualWarehouses:
- <<: *defaultWorker
name: vw_default
replicas: 1 # Number of replicas of pod vw-default
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: byconity-vw
operator: In
values:
- "vw_default"
- key: byconity-role
operator: In
values:
- "worker"
topologyKey: kubernetes.io/hostname
- <<: *defaultWorker
name: vw_write
replicas: 1 #Number of replicas of pod vw-write
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: byconity-vw
operator: In
values:
- "vw_write"
- key: byconity-role
operator: In
values:
- "worker"
topologyKey: kubernetes.io/hostname
fdb:
clusterSpec:
processes:
general:
volumeClaimTemplate:
spec:
storageClassName: openebs-hostpath #replace to your storageClassName
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
重新部署 DeepFlow：
helm del deepflow -n deepflow
helm install deepflow -n deepflow -f values-custom.yaml deepflow/deepflow
1
2
2
#1.2 注意事项
- ByConity 只支持 AMD64 架构。
- 如果出现部分
byconity-fdb-storagePod 启动失败的情况，请调整内核参数：sudo sysctl -w fs.inotify.max_user_watches=2099999999 sudo sysctl -w fs.inotify.max_user_instances=2099999999 sudo sysctl -w fs.inotify.max_queued_events=20999999991
2
3 - Byconity 依赖于 FoundationDB 集群（简称 FDB），该集群用于存储 Byconity 的元数据。若对 FDB 集群进行删除或重建操作，将会导致 FDB 数据的丢失，进而引发 Byconity 数据的丢失。因此，在卸载 Byconity 的过程中，不会删除 FDB 组件。若确实需要删除该组件，请执行相应的删除操作：
kubectl delete FoundationDBCluster --all -n deepflow1 - 使用私有仓库导致 FDB 部分组件无法拉取镜像情况，可以使用如下命令解决：
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}' -n deepflow kubectl delete pod -n deepflow -l foundationdb.org/fdb-cluster-name=deepflow-byconity-fdb1
2