Elasticsearch应用过程中的问题？

ES使用场景:
主要用来进行明细模糊搜索，用户通过关键字进行明细搜索，现在默认搜索区间是2年，ES中要存储10年数据。按照现在数据量，一年越400亿条数据。
集群部署方案：
物理机的配置为36core + 384GB + ssd磁盘，一共19台物理机，每台物理机只部署一个es节点。
3个master节点+16个data节点，堆内存配置为31GB。
建索引的方案：
索引文档定义情况：strict严格模式共定义了35个字段，9个中文字段采用standard分词且字符串长度在30以内，其余字段基本是keyword类型。400个主分片，复制分片个数为2，一个索引共400个主分片，800个复制分片，refresh_interval为2秒。
索引的id生成方式为5业务主键拼接。
终态为保存最近十年数据，按年建索引，比如2013到2022共十个年的数据，每年的数据放一个索引，共3000亿条数据，单条数据0.3k。

数据现状：
目前集群有三个索引2020，2021、2022，2023数据量分别为几百万条、400亿条，400亿条、30亿条。
无数据倾斜，通过es的监控api确认了16个data节点上每个data节点的数据量均匀，每一个索引在每个data节点上的分片数均匀，每个分片的的数据量均匀。
单个分片大小约为20GB

ES访问情况
实时写：两个机房增量数据7*24小时不停的写，因为不停有交易数据产生，每日写入2.2亿条，最高TPS为4k左右
批量写：夜间对于存量的数据做批量bluk导入，一个bulk条数为5000条。
现在写入都是指定id方式，没有使用ES自己生成ID的方式。因双机房双写的场景，实时写入场景无法使用自动生成id的方式。

五个现象：
1批量写数的时候有一两台es节点的物理机cpu特别高，90以上，其他很低，10%左右，重启该es节点之后，会变成其它节点的cpu特别高，问题没有解决，只是发生了转移。
2批量写较慢，当索引数据量小的时候TPS能到10万，目前索引数据量300亿条时，批量写的TPS只能到4万
3日间实时写的时候采用的是es的sdk中的Hi Level Rest 批量写入，bulk策略为（3秒、5M、1000条），超时时间2秒，会偶然出现超时问题，持续时间较短1-2分钟，此时es的监控并没有什么异常。
4夜间离线导数的时候，由于导入的数据量较大，实时写入的的超时报错比日间更严重。
5目前为内测查询阶段，只有几十个账户可用查询，根据es返回json中的took值发现，查询时间不稳定，具体分布还在统计，会有一定机率出现耗时较长的查询（超过1s），对用户体验影响较大。 查询指定了routing，采用了filter过滤，只查询当前用户的数据，对9个中文字段做multi query，只查询第一页数据。