《Elasticsearch 在derbysoft日志平台的优化实践.pdf》由会员分享,可在线阅读,更多相关《Elasticsearch 在derbysoft日志平台的优化实践.pdf(31页珍藏版)》请在三个皮匠报告上搜索。
1、中国开发者大会 2023ES在derbysoft的优化实践黄绍平,数据平台负责人德比软件 derbysoft,2023/04/08中国开发者大会 2023 日志系统简介分享嘉宾写入ES(Kafka Connect)成本优化其他优化从2015年开始接触大数据相关技术,对Kafka,Hadoop,Elasticsearch 相关技术有多年经验,目前主要专注于基于AWS云的企业数据湖数据仓库平台建设中国开发者大会 2023 日志系统架构简介日志系统架构简介中国开发者大会 2023 日志格式:timestamp:2023-03-29T11:39:58.943,app_name:abc-app,host
2、:10.0.0.1,region:cn-north-1,version:v2,process:Book,process_result:Success,process_duration:32,./基于不同事件会有其他字段日志系统简介日志系统简介每日size:5TB每日document数:120亿Indexing rate:12w/s*按照写入ES后的单复本统计ES版本为 6.8,以我个人的理解本分享的经验也完全适用7.x版本。写入ES(Kafka Connect)中国开发者大会 2023 日志写入日志写入ESES方案方案早期我们完全自己实现了一套写入ES的组件,存在如下问题:依赖MySQL实现任
3、务分布式分发控制,过于复杂,并且不稳定数据转换逻辑和整个工程耦合新方案改用Kafka ConnectKafka Connect:分布式任务控制交给Kafka Connect实现数据转换逻辑解耦,仅需开发数据转换逻辑代码,以插件的形式部署通过升级Kafka Connect,以及Connect ES Sink插件配合上下游系统升级中国开发者大会 2023 新方案需要满足的需求新方案需要满足的需求实现kafka topic和ES index 多对多的映射通过配置实现基于日期时间分索引,如按年,按月,按日可实现自定义的数据转换逻辑可实现数据字段格式类型校验,确保写入ES数据类型正确异常消息进死信Top
4、ic,并写入ES,便于排查问题数据写入任务的管理(创建,配置,启动,停止)中国开发者大会 2023 基于基于Kafka Connect Kafka Connect 写入写入ESES的架构的架构 Connector 本质上是一个Consumer Group,来消费Topic数据,每个Connector对应写一个ES Index Transform即执行自定义的数据转换逻辑代码 Kafka Connect 提供了Connector创建,更新,暂停,删除,状态获取等HTTP API 死信Index,用于排查问题 Log Ops Tool,自研的一个配置和任务管理工具实现 200+Kafka Topi
5、c通过100+Connector 将数据写入对应 100+索引.中国开发者大会 2023 ConnectorConnector配置配置topics:topicA,topicB,#指定消费数据的topic列表#指定是一个ES的sink connector,以及ES对应的连接配置信息connector.class:io.confluent.connect.elasticsearch.ElasticsearchSinkConnector,connection.url:https:/10.0.0.1:9200,#指定定制的Transformation,功能包括:a)完成定制数据转换逻辑;b)执行数据类
6、型的校验transforms:eventlog,transforms.eventlog.type:com.derbysoft.kafka.connect.transforms.EventLog,#通过API获取日志schema的定义,作为数据类型校验的依据transforms.eventlog.fields.whitelist.url:http:/10.0.0.2:8080/api/field/schema,#自定义index名称,并基于dateFormat实现按日期时间划分索引transforms.eventlog.index.pattern:myindex-yyyyMMdd,#开启死信队列
7、,当Transformation过程中有格式异常或类型异常的消息进入死信队列kafka Topicerrors.deadletterqueue.topic.name:dlq_kafka-connect-es,errors.deadletterqueue.context.headers.enable:true,*上述省略了部分必要配置中国开发者大会 2023 死信消息入死信消息入ESES中国开发者大会 2023 自研运维工具自研运维工具中国开发者大会 2023 优势优势数据的消费和写入ES交由kafka connect和ES connector插件完成,仅需开发Transformation插件,
8、减少开发工作量结合自己开发的运维工具大大简化运维配置工作通过将死信写入ES,提高排查问题效率成本优化中国开发者大会 2023 优化前优化前型号vCPU内存(GiB)实例存储(GB)按需每小时费率数量每小时成本i3.4xlarge161222 个 1900 NVMe SSD1.248 USD1417.472d2.4xlarge1612212 个 2000 HDD2.76 USD1130.36基于AWS EC2 安装部署14天的数据 14天的数据中国开发者大会 2023 优化前的问题优化前的问题1.Warm节点资源利用率非常低2.Hot to Warm 每天都会导致几个TB数据的移动,耗费大量资源
9、3.Hot节点负载高,负载不均衡实时的写入负载在Hot节点上,近期数据被读的更频繁,所以大部分的读负载也在Hot节点上。这是导致Warm节点资源利用率低,以及Hot节点负载高的主要原因。Hot Hot 节点节点CPU Load(CPU Load(一天一天)Warm Warm 节点节点CPU Load(CPU Load(一天一天)中国开发者大会 2023 WarmWarm节点资源利用率低问题解决节点资源利用率低问题解决思路一,给思路一,给WarmWarm节点降级节点降级,选用更少CPU的机型,一方面我们使用了EC2的实例存储实例存储,降级就意味着磁盘容量的减少,容量减少不可接受。当然也可以选择不
10、用实例存储,而是采用通用机型加EBS,但是成本会高出不少,而且没有实例存储性能好。另外为了支持Hot to Warm,仍然需要预置足够的资源,当非Hot to Warm的时段,资源利用率还是会很低。思路二,去掉思路二,去掉Hot to WarmHot to Warm,因为Warm的读取请求本来就比较少,为了这些少量的读请求去移动大量数据是不经济的。这样只有一个分层,所有写入负载和读取负载都落到这一层。一方面减一方面减少了移动数据带来的资源损耗,另一方面消除了资源利用率低的问题。少了移动数据带来的资源损耗,另一方面消除了资源利用率低的问题。结论:采用去掉结论:采用去掉Hot to WarmHot
11、 to Warm方案方案中国开发者大会 2023 机型的选择机型的选择Total CPU coresTotal Mem GBTotal Disk (TB)Cost saving现状i3.4xlarge(hot)d2.4xlarge(warm)hot:224warm:176total:400hot:1,792warm:1,342total:3,134hot(SSD):52warm(HDD):253total:305方案Ais4gen.4xlarge2561,536(SSD)240-22%方案Bim4gn.4xlarge4001600(SSD)187.5-23%方案Cd3.4xlarge2562,
12、048(HDD)384-33%从存储空间上来看方案B刚好够用,但是无法应对未来数据的增长,并且CPU资源过剩。从CPU资源来看,方案A,C也都是够用的,所以综合来看方案C是最经济,同时又能得到更充足资源的。唯一的问题是磁盘的类型是HDD。中国开发者大会 2023 HDDHDD如何玩如何玩d3.4xlarge 12 x 2TB HDD虽然是HDD,但其实是12块盘组成的,所以理论上可以通过RAID0 使聚合磁盘吞吐达到2+GB/s.机型机型BSR/WIOPS吞吐量吞吐量(MB/s)d3.4xlarge(HDD)16k随机读432369随机写468975顺序读3525450顺序写顺序写128897
13、2014.2i3.4xlarge(SSD)16k随机读1575092461.9随机写769511202.4顺序读1940003031.3顺序写910741423.4中国开发者大会 2023 d3.4xlarge(HDD)d3.4xlarge(HDD)加入生产集群做验证加入生产集群做验证和i3.4xlarge(SSD)做对比发现如下问题:CPU Load非常高Processes blocked指标比较高系统调用fdatasync 时间占比比较高%time seconds usecs/call calls errors syscall-55.25 670.980206 128960 5203 ep
14、oll_wait31.65 384.390424 10657 36068 5498 futex5.76 69.998450 29560 2368 fdatasync5.23 63.463618 961569 66 27 restart_syscall1.14 13.852722 133 104096 write0.39 4.731353 876 5397 read0.24 2.855333 3587 796 writev中国开发者大会 2023 index.translog.durabilityindex.translog.durability参数参数index.translog.durabi
15、lityWhether or not to fsync and commit the translog after every index,delete,update,or bulk request.This setting accepts the following parameters:request(default)(default)fsync and commit after every request.In the event of hardware failure,all acknowledged writes will already have been committed to
16、 disk.asyncfsync and commit in the background every sync_interval.In the event of a failure,all acknowledged writes since the last automatic commit will be discarded.index.translog.sync_intervalHow often the translog is fsynced to disk and committed,regardless of write operations.Defaults to 5s.Valu
17、es less than 100ms are not allowed.中国开发者大会 2023 调整调整index.translog.durability index.translog.durability 为为asyncasync CPU Load大幅下降 Processed Blocked明显改善 fdatasync系统调用时间占比非常小,0.x%虽然数据可靠性有略微降低,但是对于日志系统来说,完全可以接受。中国开发者大会 2023 总结总结执行操作:去掉Hot to Warm,只有一层数据节点 将原有的节点类型(14台i3.4xlarge+11台 d2.4xlarge)替换为18台d3.
18、4xlarge 对12块HDD盘做RAID0 将所有日志索引参数index.translog.durability调整为async收益:硬件成本下降20+%节点数减少7台,减少相应的License成本 架构更简单,运维更简单 整体磁盘容量提升40%更多的节点来承担写入负载(因为写入负载远大于读负载)其他优化写负载不均衡大量小索引中国开发者大会 2023 写负载不均衡写负载不均衡虽然已经完成节点类型的替换,并且承载写负载的机器数量增加到18台,但是各机器上的负载非常不均衡,这其实也会造成资源的浪费。虽然集群级别的balance会确保shard数在所有node中尽可能的均衡,但是因为同时存在大索引
19、和小索引,可能会出现大索引的shard集中都分配到某几个节点,导致某几个节点过热。中国开发者大会 2023 调整参数调整参数通过设置index.routing.allocation.total_shards_per_node参数为2,确保大索引shard分散开,不会集中到个别node上。官方文档解释:index.routing.allocation.total_shards_per_nodeThe maximum number of shards(replicas and primaries)that will be allocated to a single node.Defaults to
20、 unbounded.中国开发者大会 2023 小索引问题小索引问题小索引即数据吞吐比较小的索引,因为我们是基于业务主题来分索引,某些业务索引每天数据量可能都不到1GB.一个shard底层为一个lucene索引,会消耗一定文件句柄,内存,cpu等。来自官方的提示:分片过小会导致段过小,进而致使开销增加。您要尽量将分片的平均大小控制在至少几 GB 到几十 GB 之间。对时序型数据用例而言,分片大小通常介于 20GB 至 40GB 之间。每个节点上可以存储的分片数量与可用的堆内存大小成正比关系,但是 Elasticsearch 并未强制规定固定限值。这里有一个很好的经验法则:确保对于节点上已配置的
21、每个 GB,将分片数量保持在 20 以下。如果某个节点拥有 30GB 的堆内存,那其最多可有 600 个分片,但是在此限值范围内,您设置的分片数量越少,效果就越好中国开发者大会 2023 通过通过rolloverrollover机制解决小索引问题机制解决小索引问题按天分索引的方式改为基于rollover的机制按大小和时间自动分索引。比如,原来每天1GB数据,1个索引,1个shard,14天总共14个shard,每个shard 1GB。改为rollover机制后,设定max size为40GB,max age为14天。则总共只会产生1个索引1个shard。大大减少了shard的数量。最终优化总结
22、中国开发者大会 2023 1.通过Kafka Connect实现数据写入ES,结合自研的运维工具,提升了开发运维排错的工作效率2.通过去掉Hot-Warm机制,以及更换节点类型实现成本的降低和资源利用率的上升,(涉及参数调整:index.translog.durability)1.通过参数的调整解决负载不均衡问题(涉及参数调整:index.routing.allocation.total_shards_per_node)1.通过Rollover机制解决小索引shard过多问题中国开发者大会 2023感谢观看中国开发者大会 2023 专业、垂直、纯粹的 Elastic 开源技术交流社区https:/