[Elasticsearch] ES更新问题踩坑记录

drop table if exists tmp.test_create_table;

create table if not exists tmp.test_create_table(

id int,

name string

) stored as parquet;

问题排查

发现ES创建表的状态没有正常更新 yn 还是0

查看日志, 截取部分关键信息:

ReceiverController] [4eb1c8fd7b 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 6987ae] - 接收的hive元数据为:{“data”: …

“eventType”:“DROP_TABLE” …

ReceiverController] [d1aa226b8739d352] - 接收的hive元数据为:{“data”: …

“eventType”:“CREATE_TABLE” …

[Kafka-Consume-Thread-bigdata_aa-0] [ec812addb0bf424d] - update table data to es: … “yn”:0}

[Kafka-Consume-Thread-bigdata_aa-0] [3085b7329053aaac] - update table data to es: … “yn”:1}

日志里有几个关键线索：

1. 建表与删除表的Hive元数据信息正常上报上来了

2. 建表删表事件都执行了更新数据到ES的操作， [Kafka-Consume-Thread-bigdata_aa-0] 可以看出是单线程更新ES， 所以不会存在多线程并发的问题

3. 基本可以定位是在es更新这块出问题了

final TableDocBean docBean = baseSearchService.getById(id);

setValueForBean(afterColumns, docBean);

log.info(“update table data to es: {}”, JSON.toJSONString(docBean));

baseSearchService.update(docBean);

代码先通过表id 获取对应ES文档，然后赋值 执行更新数据操作

这块没有看出什么问题，考虑到两个事件同时执行时间间隔较短，采用了在代码里Thread.sleep(1000) 睡眠下试试，发现两条SQL语句同时执行的基本每次都成功，可以在ES搜索到.

这种操作不免让人觉得ES里执行更新操作，肯定是有延迟的，具体为什么延迟，就需要看下ES的更新原理

更新原理

[正在上传…重新上传取消​](()