Hive与ES集成过程,错误记录

一、基础准备

1,查看es对应版本,下载版本号一样的jar包, 测试环境用的es7.8.0

下载地址https://jar-download.com/artifacts/org.elasticsearch/elasticsearch-hadoop-hive

2,将下载好的jar包elasticsearch-hadoop-hive-7.8.0.jar上传到hdfs中

 

 

放在存储hive udf的目录下。

3,引入jar包

先查看已经引入的jar包有哪些

list jars;

引入jelasticsearch-hadoop-hive-7.8.0.jar

add jar hdfs://nameservice1/user/hive/udf/elasticsearch-hadoop-hive-7.8.0.jar

创建hive表并导入测试数据

CREATE EXTERNAL TABLE test.dxt_test_to_es (
    order_zhu string,
    order_zi string,
    create_time string,
    jifei_status string,
    fuwufei  string,
    num_id string,
    zhubo_id string,
    neirong_id string,
    zhubo_nick string
)
STORED BY 'org.elasticsearch.hadoop.hive.EsStorageHandler'
TBLPROPERTIES('es.resource' = 'dxt_test_to_es/info',
    'es.index.auto.create' = 'false',
    'es.nodes' = 'es.xxxx.com',
    'es.nodes.wan.only'='true',
    'es.read.metadata'='true',
    'es.port'='80',
    'es.mapping.names'='order_zhu:order_zhu, order_zi:order_zi, create_time:create_time, jifei_status:jifei_status, fuwufei:fuwufei, num_id:num_id, zhubo_id:zhubo_id, neirong_id:neirong_id, zhubo_nick:zhubo_nick'
    
);

insert overwrite table test.dxt_test_to_es select order_zhu,order_zi,create_time,jifei_status,fuwufei,num_id,zhubo_id,neirong_id,zhubo_nick from v_tese_order

报错1

org.elasticsearch.hadoop.EsHadoopIllegalArgumentException: Cannot detect ES version - typically this happens if the network/Elasticsearch cluster is not accessible or when targeting a WAN/Cloud instance without the proper setting 'es.nodes.wan.only'

去linux中使用命令交互方式操作hive,发现是连接es服务超时被拒绝,因为9200被Nginx代理了,不能直接访问9200,通过域名+80端口的方式可以通过。

继续 insert overwrite 

报错2

Task with the most failures(4): 
-----
Task ID:
  task_1602569057109_12652_m_000000

URL:
  http://0.0.0.0:8088/taskdetails.jsp?jobid=job_1602569057109_12652&tipid=task_1602569057109_12652_m_000000
-----
Diagnostic Messages for this Task:
Error: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/apache/commons/httpclient/Credentials
    at org.apache.hadoop.hive.ql.exec.mr.ExecMapper.map(ExecMapper.java:169)
    at org.apache.hadoop.mapred.MapRunner.run(MapRunner.java:54)
    at org.apache.hadoop.mapred.MapTask.runOldMapper(MapTask.java:465)
&nbs

<think>首先,用户的问题是:排查使用代码通过HiveElasticsearch写入数据时数据量少的问题。用户提供了几个引用,我需要参考这些引用来回答。 回顾引用: - 引用 [1]:讨论Elasticsearch的优势,比如解决了存储查询数据的问题,提到了竞品如HDFSHive。 - 引用 [2]:Hive表的字段数量统计分析,显示了字段数量的分布。 - 引用 [3]:关于Hive集群性能监控故障排查的概述。 - 引用 [4]:TDH大数据平台中HIVE作业长时间运行的排查。 - 引用 [5]:关于关键词匹配SQL查询。 用户的问题是关于数据写入时数据量少,我需要构建一个系统的方法来排查这个问题。 关键点: - 数据通过代码从Hive写入Elasticsearch。 - 写入的数据量少,意思是预期写入的数据没有全部到达ES,或者部分数据丢失。 排查步骤(结构化): 1. **确认问题范围**:首先确认数据少的程度。是整个数据集写入少,还是部分数据丢失?是否每次运行都少? 2. **检查数据源(Hive)**:确保Hive表中的数据量是正确的。查询Hive表的总行数或相关统计,以验证数据源没有问题。 3. **检查写入过程**:代码执行写入时,是否有错误日志?查看日志文件,找出是否有错误或警告。 4. **代码逻辑检查**:review代码逻辑。代码是如何从Hive读取数据并写入ES的?是否有过滤条件、限制或转换导致数据丢失? 5. **连接配置检查**:检查HiveES之间的连接配置。包括网络连接、认证、ES集群状态等。 6. **分批写入超时**:如果数据量大,代码可能分批写入。检查批次大小、超时设置或重试机制是否导致数据丢失。 7. **ES索引确认**:写入后,查询ES索引的数据量,确认数据是否实际写入。使用ES的API检查文档计数。 8. **性能监控**:参考引用 [3],使用监控工具检查Hive作业的性能,是否有瓶颈或失败的任务。 9. **特定平台的考虑**:如果使用引用 [4] 提到的TDH平台,注意它的特异性,可能参数不同。 整合引用: - 引用 [1] 提到ES的优势,这里可以强调ES对于实时搜索的优势,但问题在于写入。 - 引用 [2] 是Hive表字段统计,可能不直接相关,但如果字段映射有问题可能导致写入失败。 - 引用 [3] 关于监控,建议使用监控工具如Ganglia、Ambari等监控Hive作业。 - 引用 [4] 提到TDH平台,如果用户在这个平台上,需要考虑其特殊性。 - 引用 [5] 不直接相关。 结构化回答: - 一步步引导用户排查。 - 使用中文。 - 遵循系统指令:行内数学用$...$,独立公式用$$...$$,但这里可能少用数学。语法正确。 - 末尾添加引用标识。 - 生成相关问题。 回答结构: 1. **引言**:简述问题。 2. **排查步骤**:列出详细步骤,参考引用。 3. **总结**:一般建议。 4. **相关问题**:生成相关问题。 确保内容真实可靠: - 基于常见的大数据实践。 - 引用相关的部分。 最终回答: - 开头:基于您的查询,我将指导您排查使用代码通过HiveElasticsearch写入数据时数据量少的问题。 - 然后分步骤。 </think>### 排查使用代码通过HiveElasticsearch写入数据时数据量少的问题 当您使用代码(如Java、Python或Spark作业)通过Hive将数据写入ElasticsearchES)时,出现数据量少于预期的现象,这可能源于多个环节的错误。我将基于大数据领域的常见实践,为您提供系统化的排查方法。排查的核心思路是:**从数据源到目标端逐步验证,识别瓶颈或丢失点**。以下步骤参考了您提供的引用内容(如Hive性能监控ES优势分析),并结合了Hive-ES集成的最佳实践。每一步都包含具体操作建议潜在原因。 #### 1. **确认数据源(Hive端)是否正确** - **操作**: 首先验证Hive表中的原始数据量是否正常。使用HQL查询表的总行数关键字段统计: ```sql SELECT COUNT(*) AS total_rows FROM your_hive_table; -- 检查总行数 SELECT column_name, COUNT(*) AS non_null_count FROM your_hive_table GROUP BY column_name; -- 检查字段完整性 ``` - 如果引用[2]中的字段数量分布显示异常(如字段缺失率高),可能导致数据过滤: > "单表字段数区间(0,100]数量83412546...占比94.65%",若您的表字段数超出常见范围,数据写入时可能因schema不匹配被丢弃[^2]。 - **潜在原因**: - Hive表数据本身不足(如上游ETL作业失败)。 - 分区或过滤条件错误:代码中指定的Hive查询可能包含`WHERE`子句,或引用了过期分区。 - **排查工具**: 使用Hive元数据监控(如引用[3]推荐的性能监控系统),检查作业是否成功完成: > "通过对Hive集群性能监控...筑牢了坚实的‘防线’",建议集成Ganglia或Prometheus监控Hive作业状态[^3]。 #### 2. **检查代码逻辑日志** - **操作**: 审查您的写入代码(如Spark或MapReduce作业),重点关注: - **数据读取环节**: 确认代码从Hive读取数据时未添加意外过滤(如`filter`或`limit`子句)。 - **数据转换环节**: 检查字段映射是否对齐ES索引schema。例如,如果Hive字段类型(如`STRING`)ES字段(如`keyword`)不兼容,数据可能被静默丢弃。 - **写入环节**: 验证ES写入配置,如`bulk_size`(批次大小)`retry_on_failure`(重试机制)。代码示例(Python使用`elasticsearch`库): ```python from elasticsearch import Elasticsearch es = Elasticsearch(hosts=[{'host': 'your_es_host', 'port': 9200}], timeout=60) # 增加超时避免写入中断 # 读取Hive数据(示例使用PySpark) df = spark.sql("SELECT * FROM your_hive_table") # 写入ES时添加错误日志 df.write.format("org.elasticsearch.spark.sql") \ .option("es.nodes", "es_host") \ .option("es.resource", "index_name/type") \ .option("es.mapping.id", "id_field") \ .mode("append") \ .save() ``` - 确保代码捕获并记录错误(如在`try-except`块中输出日志)。 - **潜在原因**: - 批次大小设置不当:如果`bulk_size`过大,可能导致写入超时;过小则效率低下,部分数据未提交。 - 转换错误:字段值包含特殊字符(如JSON格式错误),触发ES拒绝写入。 - 权限问题:代码缺少ES写入权限(如认证失败)。 - **排查工具**: 检查Hive作业日志(如YARN Application Logs),搜索`ERROR`或`WARN`关键词。引用[4]提到TDH平台的特定性: > "星环的TDH大数据平台中的HIVE...参数不通用的",若您使用TDH,需验证其特有配置(如`inceptor`参数)是否兼容ES写入[^4]。 #### 3. **验证Elasticsearch端状态** - **操作**: 直接查询ES索引,确认实际写入的数据量: - 使用ES API获取文档计数: ```bash curl -X GET "http://es_host:9200/index_name/_count" # 返回{"count":实际文档数} ``` - 比较ES计数Hive源数据量:如ES计数显著小于Hive,则写入过程有丢失。 - 检查ES索引健康状态: ```bash curl -X GET "http://es_host:9200/_cluster/health?pretty" # 查看status(应为green/yellow) ``` - **潜在原因**: - ES集群问题:节点故障、磁盘满或内存不足导致写入失败(引用[1]强调ES的优势在于分布式存储查询性能,但写入瓶颈常见于资源不足)[^1]。 - 映射冲突:ES索引的`mapping`定义Hive数据不符(如类型不匹配),数据被拒绝。 - 版本兼容性:Hive-ES连接器(如`elasticsearch-hadoop`库)版本不匹配。 - **排查工具**: 使用Kibana或ES原生监控工具,分析`bulk`请求的错误率。 #### 4. **检查网络中间件性能** - **操作**: 测试HiveES的网络连接吞吐量: - 网络延迟:使用`ping`或`traceroute`检查Hive集群ES集群间的延迟。 - 吞吐量限制:监控写入时的带宽使用(如`iftop`工具),确保未达网络上限。 - 中间件瓶颈:如果使用Spark作为中间引擎,检查Executor资源(CPU/内存)是否充足。 - **潜在原因**: - 网络抖动导致写入超时,数据批次被丢弃。 - Hive集群负载高:引用[3]提到性能监控的重要性,Hive资源争抢可能延迟或中断写入作业[^3]。 - **排查工具**: 集成集群监控系统(如Ambari或Grafana),查看写入期间的CPU、内存I/O指标。 #### 5. **通用优化验证测试** - **快速测试**: 缩小问题范围: - 步骤1:使用小数据集(如Hive中的100行数据)重新运行写入代码,验证是否成功。 - 步骤2:如果小数据成功,逐步增大数据量,定位丢失点(如当数据量超过$10^5$行时失败)。 - **优化建议**: - 增加写入重试:在代码中添加重试逻辑(如指数退避策略)。 - 调整批次大小:从默认1000条开始迭代测试,公式优化:$$ \text{批次大小} = \min(\text{集群内存限制}, \text{网络带宽} / \text{文档平均大小}) $$。 - 启用详细日志:在HiveES端设置日志级别为`DEBUG`。 - **引用整合**: 引用[5]提到模糊匹配SQL查询思路,可应用于日志分析: > "根据关键词模糊匹配...转化成了一个SQL的like查询",建议在日志中搜索关键字如`failed`或`dropped`[^5]。 #### 总结 数据量少的问题通常源于三个环节:**Hive数据源异常、代码逻辑错误(过滤/转换)或ES写入失败**。优先从Hive端验证数据完整性,再逐步检查代码ES配置。参考引用[3],强化监控: > "Hive集群性能监控故障排查...使其能够在大数据的海洋中乘风破浪",建议建立端到端监控流水线,捕获写入延迟错误率[^3]。如果您使用特定平台(如TDH),请查阅其文档以适配参数。一般能通过以上步骤定位90%的问题。
评论 4
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值