MAPREDUCE结果导入elastic

hadoop连接es配置

Configuration conf = new Configuration();

//禁止speculative机制，该机制会启动多个相同task，使数据重复索引
conf.setBoolean("mapred.map.tasks.speculative.execution", false);
conf.setBoolean("mapred.reduce.tasks.speculative.execution", false);
//设置ES集群中任意节点的IP地址和端口号
conf.set("es.nodes", "*.*.*.*:9200");
conf.set("es.net.http.auth.user", "username");
conf.set("es.net.http.auth.pass", "userped");

//设置要索引的index/type
conf.set("es.resource", "typename/indexname");
//设置输入的数据格式为json
conf.set("es.input.json", "yes");
//设置json中文档id对应的字段名，不写时默认生产id
 //conf.set("es.mapping.id", "userid")

job.setOutputFormatClass(EsOutputFormat.class);

注意问题：

JSON格式一定要正确，数值类型时，json不能前导为0，否则报错，可以设置为字符串格式

 

常见的问题：

1. 数据是否会丢，怎么保证数据完整性。

2. 并发如何控制，写入es

       写入数据的api使用了es的http bulk接口，以下几个参数是控制这个bulk请求的这个地方用好了 数据就不会丢。

       org.elasticsearch.hadoop.rest.bulk/BulkProcessor

       elasticsearch-hadoop/mr/src/main/java/org/elasticsearch/hadoop/rest/bulk/BulkProcessor.java

       http层可选配置

                 es.http.timeout（默认1m）   与Elasticsearch的HTTP / REST连接超时。

                 es.http.retries（默认3）建立（损坏的）http连接的重试次数。 使用Elasticsearch节点对每个会话应用重试。 重试耗尽后，连接将自动重新连接到下一个可用的Elasticsearch节点（基于es.nodes的声明，然后是已发现的节点 – 如果已启用）。

       bulk接口可选配置

                 es.batch.size.bytes（默认1mb）Elasticsearch _bulk API进行批量写入的大小（以字节为单位）。

这个参数是具体任务实例的批量写入大小，一个job的整体并行写入量 应该是 es.batch.size.bytes*任务实例数目。

                 es.batch.size.entries（默认1000）使用Elasticsearch _bulk API进行批量写入的大小（控制条目） -（0禁用）。和es.batch.size.bytes一样，一旦匹配，就会执行批量更新。此设置是每个任务实例;在运行时乘以运行的Hadoop任务总数才是整体的并发。

                 es.batch.write.refresh（默认为true）是否在_bulk更新完成后调用索引刷新。请注意，只有在执行了整个写入（意味着多个批量更新）之后才会调用此方法。

                es.batch.write.retry.count（默认3） Elasticsearch过载且数据被拒绝的情况下给定批次的重试次数。请注意，仅重试被拒绝的数据。如果在执行重试后仍有数据被拒绝，则Hadoop作业将被取消（并失败）。负值表示无限重试;设置此值时要小心，因为它可能会产生不必要的副作用。

                es.batch.write.retry.limit 最大重试次数 默认50 count 和 limit 配合使用： 如果 count 设置-1 就是无限， count 大于0 两者取最大值。

                es.batch.write.retry.wait（默认10秒）批量拒绝导致批量写入重试之间的等待时间。

数据完整性

       按照默认设置，reject的的数据会被重试，任务失败数据会有部分写入，一次写入无法保证数据完整。

      如果设置es.mapping.id 唯一id 和 es.write.operation = update 重新运行后能保证数据完整(没有数据重复)。

      总之事务性是保证不了的，只能有条件的保证完整性

并发控制

      单任务：

      1） 要在任务层面进行控制

              有reduce的任务 mapred.reduce.tasks 控制reduce任务的数目

              只有map任务 mapred.max.split.size 控制map任务的数目

      2） 结合_bulk的参数控制整体任务的并发。

              多个任务：

              1）例如 有100个任务，不知道会什么时候执行，如何控制并发？

              多个任务实际上是没有好的控制方案的，单个任务的控制并不能影响到整体的并发。 如果是Mapreduce类的任务控制reduce数目控制并发。

               但是如果利用前面的失败机制做es的反向代理仅对 _bulk请求进行流控，就能控制整体的并发 ，保障es的稳定。bulk reject后，客户端会默认等待10秒（默认配置 es.batch.write.retry.wait），利用这个机制。 反向代理服务根据 _bulk进行流控，返回bulk reject ，控制 bulk的集群任务并发。reject的处理会比较复杂，改写 elasticsearch-hadoop 也会比较复杂，原因是reject 是具体的某个item而不是整批数据。

                以下 es-hadoop客户端如果对特殊httpcode（429）做处理，实现了retry和流控。

                1) 改写的eshadoop 配合hive 和 mr 任务使用 https://github.com/whomm/elasticsearch-hadoop

                2)  服务器反向代理 https://github.com/whomm/hrproxy 这两个配合即可实现bulk qps流控。