以elasticsearch-hadoop 向elasticsearch 导数，丢失数据的问题排查

实际这是很久之前的问题了，当时没时间记录

这里简单回顾

 

项目基于

 

数据架构不方便说太细，最精简的

 

somedata-> [kafka]->spark-stream->elasticsearch

 

在 spark-streaming 引用了elasticsearch-hadoop(实际用的是为支持upsert doc自已打包的，见elasticsearch-hadoop 扩展定制 官方包以支持 update upsert doc)

 

问题是somedata定入kafka 200w条，最后到elasticsearch 190w条，有10w条不见了，也不报任何错误，批处理任务都是成功的。

 

首先排入kafka的消费问题，基于kafka自已实现了一套offset偏移维护的机制，不可能在消费kafka这一步丢数

 

唯一可能的就是 elasticsearch-hadoop 写 elasticsearch 这一步了

 

class SparkDStreamFunctions(ds: DStream[_]) extends Serializable {
    def saveToEs(resource: String): Unit = { EsSparkStreaming.saveToEs(ds, resource) }
    def saveToEs(resource: String, cfg: Map[String, String]): Unit = { EsSparkStreaming.saveToEs(ds, resource, cfg) }
    def saveToEs(cfg: Map[String, String]): Unit = { EsSparkStreaming.saveToEs(ds, cfg) }
  }

写入es调用包内的saveToEs方法，scala Unit 类似java 的void 这个方法是无返回值的。这里看不出什么线索

 

隐约能感觉到问题在哪里。

 

elasticsearch 是以乐观锁，版本号来实现基本的事务控制

 

操作elasticsearch时，相信大部分人都遇到过版本冲突的问题，报错类似

{
  "error" : "VersionConflictEngineException[[website][2] [blog][1]:
             version conflict, current [2], provided [1]]",
  "status" : 409
}

 

但saveToEs这个方法是没有返回值的？？？？也就是说能保证不会碰到这个错误？

 

当然不是，查看源码后发现

 

saveToEs无返回值，不代表就这批数据就完全成功了

 

实际会打印错误日志，不过只是在对这个包开启debug后才会打印，默认的情况下是不开的。包的开发者们认为这种版本冲突的错，如果抛到顶层，让整个任务失败太小题大作了，因此也不会往外抛，只会对比较"大"的异常才会抛到顶层。

 

实际上 elasticsearch-hadoop 会在一批任务写入失败后，隔一段时间重试，重试几次后，直接跳过这组数据，这数据等于就丢弃了。（代码就不贴了，因为github上最新的代码和我当时排查时不一样，可能有变化，问题已经解决，这次回顾也没精力细究了，如果贴错了还误人子弟）

 

官方的配置文档

https://www.elastic.co/guide/en/elasticsearch/hadoop/current/configuration.html

es.batch.write.retry.count (default 3)
Number of retries for a given batch in case Elasticsearch is overloaded and data is rejected. Note that only the rejected data is retried. If there is still data rejected after the retries have been performed, the Hadoop job is cancelled (and fails). A negative value indicates infinite retries; be careful in setting this value as it can have unwanted side effects.
es.batch.write.retry.wait (default 10s)
Time to wait between batch write retries that are caused by bulk rejections.

 

这两个参数就是重试相关的配置。

 

加了这3个参数后，就解决丢数的问题

 

"es.batch.write.retry.count" -> "-1",
"es.batch.write.retry.wait" -> "60s",
"es.batch.size.entries" -> "50"

 

es.batch.write.retry.count 表示无限重试，这个得谨慎着用最主要是改这个，我手里这套系统正好可以这么用。

es.batch.write.retry.wait 重试间隔由默认的10s改为60s，这个只是优化的

 

es.batch.size.entries也是优化的

es.batch.size.entries (default 1000)
Size (in entries) for batch writes using Elasticsearch bulk API - (0 disables it). Companion to es.batch.size.bytes, once one matches, the batch update is executed. Similar to the size, this setting is per task instance; it gets multiplied at runtime by the total number of Hadoop tasks running.

 

elasticsearch集群本身不提供权限控制，大部分架构都会在之前加个nginx

 

如果单个文档都很大的话，默认的1000个，可能会超过nginx 限制的单独http的body大小，nginx直接就让请求失败了，把这个数改小，是为了避免这种情况。